長編書きの為の連載フレームワーク提案

01_03:ウォーターフォール系統の亜種

　さて、ウォーターフォール・モデルについてざっくり説明しました。

　でも『こうじゃねえんだよなー』と言う人もいるでしょう。

　01_02でも書いたように『とりあえず書いちゃう』人です。

　そういう人はウォーターフォール・モデルの亜種として、２つのフレームワークを使用している可能性があります。

－－－－－－－－－－－－－－－－－－－－－－－－－

　１．プロトタイプ・モデル

　２．スパイラル・モデル

－－－－－－－－－－－－－－－－－－－－－－－－－

　ではざっくり説明していきましょう。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

【１．プロトタイプ・モデル】

　ある程度の要件定義と設計をした段階で試作製品（プロトタイプ）を作成します。

　その後確認と評価を行い、足りない点や必要な機能をリストアップ。

　さらにプロトタイプを作成し、確認・評価を行う。

　これを繰り返すことで最終的な成果物を作成し、運用(≒脱稿)するのが基本的な仕組みです。

　未完成を前提に、省力化したウォーターフォールを繰り返すと言う形ですね。モノカキ的に言うと『とりま書いて、推敲すりゃいいか』でしょう。

　実物が早い段階でカタチになるため、終盤で『変更したい』等という要望に答えやすいのが特徴です。

　ただし一度やればわかりますが、評価ポイントを絞らないと非常に負荷が高くなります。

　例えば私は4,000字の文章を推敲するにあたり、一通りさらうのに１時間かかります。

　つまりポイントを抑えない場合、プロトタイプを作成するたびに永続的に１時間という時間を消費するわけです。

　例では4,000字ですが、倍の8,000文字になったら？

　あるいは１冊分の分量とされる10万文字になっては？

　プロトタイプを作成するたびに全て推敲していては、とても追いつけませんしやってられません。筆者はやりたくないです。

　個人的には『とりま書く』は試作短編（トライアル）以外では採用しないことをオススメします。

【２．スパイラル・モデル】

　プロトタイプのような開発単位について、試作ではなく完成まで持っていくモデルとなります。

　ある特定の区切り（1話や1節、序破急のそれぞれのタイミング）で区切って開発を進めます。

　区切り方と同時にプロトタイプ的に進めるか、ウォーターフォール的に進めるかの２パターンです。

　メリットは開発（≒執筆）する範囲が小さくなるため、成果物を早く、かつ高品質に展開できる点です。

　例えば１０万文字中の１万文字で分割執筆する様を想像してください。

　デメリットは開発初期段階で全体が見えないことです。

　つまり分割した最初の１万文字の時点で、８万文字以降の展開が見えづらい。

　最終的な文字数見積もりもしづらいでしょう。

　また分割して作成するため、後半に入ってから大幅修正が入ると負荷が非常に高いです。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　というわけでウォーターフォール・モデル系統の２形態のご紹介でした。

　現在取り組まれている殆どの執筆者の方は、いずれかの手法で進めているモノと思います。

　この時点で『おや？』と疑問に思われた方は非常に正しい。

　そう、肝心の『スクラム』という単語が一切出てきていないのです。

　では次からＳＷの基底となるスクラム、そのジャンルであるAjail（あじゃいる）の概要について説明します。