Open1ヶ月前にコメント追加12

ひとりLean/Agileに小説を書く

agile

lean

たとえば😄

従来採用してきた手法(時系列)

1. 思いつき型アプローチ 😅

概観
- Phase 1. 思いつく
  - 唐突に、物語が、具体的なシーンの連続として包括的に、思いつく
- Phase 2. 文にする
  - 思いついたものを、そのまま文章にする。
    - [[DoD: 完成の定義]]
      - 思いつきが全て文章になった段階で完成
        
        ※どこかで文章にならなければ、それは十分に思いついていなかった(十分に具体的ではなかった, 十分に包括的でなかった)ということで、未完成のまま停止する
採用した状況
- 2019.08 1本目の掌編を書いたとき
  - ※意図的に採用したわけではなく、ただ思いついただけ
この型の良さ
- 勢いで書ける。迷わない
- 思いもよらないものが書ける
この型の課題
- Phase 1. に関する課題
  - 物語の全てが思いつかない限り、何も書けない
    - それでもいいとは思っている
    - だが、プロではないなあとも思う
      - ある1シーンや1つのモチーフを物語に膨らませていく技量があってこそのストーリーテラーという気もする
- Phase 2. に関する課題
  - 文章にしている間に、最初の思いつきを忘れる/確信が持てなくなる
    - ※5-10日程度で書けるものならこの限りではないのだが
  - 手が止まった瞬間、なす術がない
    - 思いついていなかったことになってしまう
    - 現に、ノートに、途中で停止した草稿がたくさんある
  - 書き上がったところで手が止まりやすい
    - 1. 書き直そう/upgradeしようという気になれない。
      - 自分が書いたものというよりも、与えられたものなので。自分の手を入れようという気持ちになりにくい。
    - 1. 謎に向き合う羽目になる。
      - 書かれているのはただの思いつきであり、意識下における意図とは紐づいていない。発展させるためには、無意識を掘っていったり、解釈して意義を見出したり、新しい方向性を見つけたりする必要がある。これにコストがかかる。初稿はあまりにもただの思いつきなので、とっかかりを見つけにくい。
- 横断的な課題
  - (思いつかない)

2. ウォーターフォール型アプローチ ❌

概観
- Phase 1. ささやかに思いつく
  - ある1シーンや1つのモチーフが、私の知らない物語を孕んでいそうな/私の知らない物語の一部であったかのような予感がする
- Phase 2. 発散する
  - ありうる構成、またそれを満たしうる要素を全て列挙する
- Phase 3. 統合する/決定する
  - 最も望ましい構成と要素を決定する
- Phase 4. 書く
- Phase 5. レビュー
  - 出来上がったテクストが、当初決定した構成と要素に従っているか(十分に達成しているか)を確認する
- Phase 6. 改善する
  - if 出来上がったテクストが、当初決定した構成と要素を十分に達成していれば、構成/要素の改善の余地を洗い出し、また決定する
    - (Phase2, 3を繰り返す)
    - 決定した構成と要素に従うよう、改稿する
      - (Phase 4を繰り返す)
  - if 出来上がったテクストが、当初決定した構成と要素を十分に達成していなければ、書き直す
    - (Phase 4. に戻る)
  - if 出来上がったテクストが、当初決定した構成と要素を十分に達成していないものの、より優れていれば、構成と要素を見直す
    - (Phase 3. に戻る)
採用した状況
- 2019.09 2本目の小説を書き始めたとき
  - ※未完成
  - ※意図的に採用したわけではなく、何も考えていなかった
この型の良さ
- 理論上は、決めた通りに書けばいいので、楽に見える
  - ※私の場合は異なる。一定数の人もそうだろう
この型の課題
- Phase 1. に関する課題
  - (思いつかない)
- Phase 2. に関する課題
  - ありえないほど時間がかかる、というか終わらない
    - 発散は無限にできてしまうので
- Phase 3. に関する課題
  - ありえないほど労力/精神的負担がかかる
    - 発散していればいるほど、統合するのに困難を抱える
- Phase 4. に関する課題
  - つまらないし、疲れる
    - 事前に決めた通りに書かなければいけないので
      - 事前に決められた要素が多いと肩の荷が重くて疲れる。少ないと判断で疲れる。
  - 過去の自分(が下した決定)を信頼できない
- Phase 5. に関する課題
  - やる気が出ない(ことがある)
    - レビューの意義を確信できない(ことがある)。Phase 3. の段階で決めた構成/要素が、初稿を書き上げた際の自分には、従う価値のあるほどのものに思えない(ことがある)ので
- Phase 6. に関する課題
  - ifの分岐が多い。判断コストがかかる。
  - 機能しない。ifの分岐の判断の根拠が、その時の自分の主観に大きく依存している。
- 横断的な課題
  - 途中(任意のタイミング)で何か思いついてしまった/別のアイデアが湧いた場合、どうしたらいいか判断に困り、手が止まる。そしてこれは頻繁に起こる。1日に何回も起こる。
    - 判断に困ったときに考えてしまうこと
      - Phase 3. 決定するに戻るのか？
      - 一旦このまま書き進めるのか？
        
        このアイデアを盛り込んだら、そもそも書かれるべき物語そのものが変質してしまうのに、今のversionを一応完遂させることに何の意味があるのか？
解釈
- ウォーターフォール型アプローチは「事前に全て洗い出して、終わったら実行すればいいじゃん」という前提に立っている
  - この前提に大きな問題がある、無理がある。なぜなら
    - 発散は無限にできてしまう。いつdoneにしていいかわからない。無限にコストがかかる
    - 発散(要望, 要求, 要件を全て列挙すること)が十分にできることは絶対にない。絶対に後から追加, 変更が出てくる。
    - 発散しすぎると、統合する/決定するのに無限にコストがかかる
    - 自分が決めた構成/要素は、任意の時点の自分にとって従う意味がない。後の自分から見ると、前の自分は劣っているので。あるいは、自分は変化するので。

3. 初稿アウトライン模倣型 + 改稿ウォーターフォール型アプローチ 😅

概観
- Phase 1. 模倣する作品を決める
- Phase 2. アウトラインに抽象化し、定める
  - 作品の質を保ったまま、構成と要素に還元する
    - 文体やその他一切を捨象するとも言える
  - アウトラインの具体的イメージ
    - 10-100くらいの(筋の切れ目ごとの)パーツの群
- Phase 3. 模倣を制約にして、大喜利をして書き始める
  - 制約
    - アウトラインの冒頭から2-3個程度、パーツが指定する通りに書くこと
  - 大喜利
    - 筋を模倣する範囲で、一番面白そうなお話(人物, 設定)を書き始める
- Phase 4. 書き上げるまで書き進める
  - if 手が止まったら、Phase 2. で定めたアウトラインに従うか、それを基に新しい展開を考える
- Phase 5. レビュー
  - アウトラインを抽出した元の作品と比べて、劣化していないかを確認する
    - if 劣化していた場合
      - 捨てる
- Phase 6. 改善する
  - 1. ウォーターフォール型アプローチのPhase 2. 以降を行うことになる
採用した状況
- 2020.08 2本目の掌編を書き上げたとき
  - ※ただ気づいて、試してみただけだが、存外うまくいった
この型の良さ
- ラク
  - 自由度が低い
  - と同時に、思いつきを盛り込む余地がある
この型の課題
- Phase 1. に関する課題
  - (思いつかない)
- Phase 2. に関する課題
  - 手が止まる瞬間がある
    - e.g.
      - 元作品において、筋としてみれば些細なある「部分」が、全体において重要な意味を持っている時に、捨象できない
      - 元作品において、メタなラインが複数錯綜している時など、疲れる(遂行できない)
  - 時間がかかる
    - 元作品に長編や複雑な短編を選んでしまうと、無理
- Phase 3. に関する課題
  - (思いつかない)
- Phase 4. に関する課題
  - 手が止まることはある
- Phase 5. に関する課題
  - (思いつかない)
- Phase 6. に関する課題
  - 1. ウォーターフォール型アプローチのすべての課題がここで起こる
- 横断的な課題
  - (思いつかない)
解釈
- 初稿アウトライン模倣型アプローチは悪くない手段の1つ
  - リバースエンジニアリング, 翻案, 換骨奪胎あたりは関連してそう(違うかも)
- 改稿ウォーターフォール型はやはりダメっぽいな

たとえば😄

ウォーターフォールのここがやばい！2024
- 以下再掲:
  - ウォーターフォール型アプローチは「事前に全て洗い出して、終わったら実行すればいいじゃん」という前提に立っている
    - この前提に大きな問題がある、無理がある。なぜなら
      - 発散は無限にできてしまう。いつdoneにしていいかわからない。無限にコストがかかる
      - 発散(要望, 要求, 要件を全て列挙すること)が十分にできることは絶対にない。絶対に後から追加, 変更が出てくる。
      - 発散しすぎると、統合する/決定するのに無限にコストがかかる
      - 自分が決めた構成/要素は、任意の時点の自分にとって従う意味がない。後の自分から見ると、前の自分は劣っているので。あるいは、自分は変化するので。
- ※昔から言われてるだろうけど

たとえば😄

LeanでAgileに行こう

Why [[Lean/リーン]]+[[Agile/アジャイル]]?

Q. 発散(「こう書くと面白そう」「これ書くと面白そう」の列挙)をどう絞り込むか？どう終わらせるか？その中でどう実験的に書くか？
- A. 以下の掛け合わせ
  - A1. 絞り込み方: 「絶対に盛り込む意味がある」要素だけを盛り込む
    - 「面白いけど、検討の結果、反映されなかった」ことが後でわかる要素に関して、そもそも検討の時間をかけないようにする
  - A2. 終わらせ方: 終わらせない。全体が「十分」になるまで無限に続ける。代わりに、1weekなどで区切りを設け、iterationを繰り返す。
  - A3. 実験の仕方: 「試してみたい」ものを盛り込み、iterationに載せ、サッとcheapに書き上げて「良さげ」かを検証する。良さげ/掘ったら面白そうの判断はその時の自分を信じる。
Q. 「書き始める前の自分と書き上げた自分では、判断や評価の基準が異なる」問題や、「絶対に途中で変えたい/追加したい要素が出てくる」問題をどう解決するか？
- A. 検討→実行、を細かく刻む。
  - 自分n-1と自分nの差分を小さくする
  - 思いつきは自分n+1に判断させる
    - 今実行中に思いついたこと(追加, 変更)は、次の検討段階に載せれば良い
これってLeanとAgileの反映では？(言い過ぎかも)
- [[Lean/リーン]]
  - 無駄を省く/時間を有効活用するために
    - 小さなバッチでの実行
    - 事前の大まかな計画とジャストインタイムの詳細な計画
    - 事前の大まかな要求獲得とジャストインタイムでの要求の詳細化
  - リリースを重視する
    - 動かしてみないとわからない主義
- [[Agile/アジャイル]]
  - ユーザ目線で見た価値で全てを管理する
    - ≒ まずリリースし、十分かどうかの判断は顧客(読者: 自分)に委ねる
  - 柔軟で適応的に、激しい変化に対応するために
    - 短いリリースサイクル

How [[Lean/リーン]]+[[Agile/アジャイル]]?

ルール
- Cycle(e.g. 1week)内に完遂を確約（コミットメント）できるものだけを計画し、実行する
- Cycleの途中に思いついた任意のアイデアはすべて[[PB: プロダクトバックログ]]に積み直す
- Cycleごとに、物語を完結させることを最優先にする
  - e.g.
    - Cycle 1
      - 彼はロンドンに行って、東京に帰ってきた。
    - Cycle 2
      - 彼はロンドンに行って、マグカップを得て、東京に帰ってきた。
    - Cycle 3
      - 彼はロンドンに行って、現地でキャリーケースを盗まれた。
      - しかし彼は、マグカップを得て、携えて東京に帰ってきた。
  - ※完結した物語でないと、評価が確定しないから
- 月曜にレビューと計画を行う。火曜から金曜に書く。土日は頭を冷やす(レビューのため)。
Cycleごとにやること
- Cycleの開始時: レビューと計画 on DR(Decision Record)
  - 前Cycleの成果物のレビュー
    - ベロシティ・レビュー
      - 手続きの達成度/ベロシティの確認
      - 当初確約したこと([[DoD: 完成の定義]], [[AC: 受け入れ基準]])を達成しているか？どれだけ達成できたか？を、ドキュメントや前Cycleの[[PB: プロダクトバックログ]]と照らし合わせチェックする
        
        →達成していることもあるし、していないこともある
        
        必要であれば、継続/改善のための[[プロダクトバックログアイテム]]を積む
    - クオリティ・レビュー
      - 十分性/クオリティの確認
      - 前Cycleの成果物は、クオリティ面で十分か？を、顧客(読者としての自分)が確認する
        
        →大抵、十分ではない
        
        改善のための[[プロダクトバックログアイテム]]を積む
  - 次Cycleに向けて計画
    - [[PB: プロダクトバックログ]]の剪定
      - [[プロダクトバックログアイテム]]を、ready-to-doになるまで詳細化する
    - Cycleに載せ、計画, [[DoD: 完成の定義]], [[AC: 受け入れ基準]]をfixし、[[Commitment/コミットメント]]する
{{[[TODO]]}} 他にない？
懸念/注意点
- [[Product vision/プロダクト・ビジョン]]の重要性
  - [[[[Book]][[Radhika Dutt/ラディカ・ダット]]ラディカル・プロダクト・シンキング]]いわく、[[Lean/リーン]]にも[[Agile/アジャイル]]にも、ゴールを示す力は備わっていない