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

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

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

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. 改善する
    • 2. ウォーターフォール型アプローチ のPhase 2. 以降を行うことになる
• 採用した状況
  • 2020.08 2本目の掌編を書き上げたとき
    • ※ただ気づいて、試してみただけだが、存外うまくいった
• この型の良さ
  • ラク
    • 自由度が低い
    • と同時に、思いつきを盛り込む余地がある
• この型の課題
  • Phase 1. に関する課題
    • (思いつかない)
  • Phase 2. に関する課題
    • 手が止まる瞬間がある
      • e.g.
        • 元作品において、筋としてみれば些細なある「部分」が、全体において重要な意味を持っている時に、捨象できない
        • 元作品において、メタなラインが複数錯綜している時など、疲れる(遂行できない)
    • 時間がかかる
      • 元作品に長編や複雑な短編を選んでしまうと、無理
  • Phase 3. に関する課題
    • (思いつかない)
  • Phase 4. に関する課題
    • 手が止まることはある
  • Phase 5. に関する課題
    • (思いつかない)
  • Phase 6. に関する課題
    • 2. ウォーターフォール型アプローチ のすべての課題がここで起こる
  • 横断的な課題
    • (思いつかない)
• 解釈
  • 初稿 アウトライン模倣型アプローチ は悪くない手段の1つ
    • リバースエンジニアリング, 翻案, 換骨奪胎あたりは関連してそう(違うかも)
  • 改稿 ウォーターフォール型 はやはりダメっぽいな

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/アジャイル]]にも、ゴールを示す力は備わっていない