こんにちは。
今回は、ウォーターフォールモデルを実際の物語構築に当て嵌めながら、考えて行きたいと思います。
先ずは要件定義からです。
要件定義
どのような物語を作るかについて、考えてみます。ここで気にしなければならない事は、以下の様な事柄でしょう。
・物語に触れた相手方に対し、どのような感動を起こす事が狙いなのか。
・物語の核となる要素は、一体どのような部分にあるのか。
これら二点は同じ事を言っていますが、別々の視点で考えると分かり易いです。
何を目的として、それをどう達成するのか。両方の視点から、考えてみましょう。
基本設計
概要が出来た後は、早速基本設計に入ります。ここでは、中身の詳細はさて置いて、基軸となる部分について考えて行きます。
・ストーリーラインは一体どの辺りを重点に置くのか。
・必要になって来るシーンをざっくばらんに書き出してみる。
・それに伴い、主要な登場人物がある程度、決定する。
・見た目の部分は、どのような見栄えを目指すのか（台詞回しの重い・軽い、詩的・現実的等が代表例）。
・タイトルはどうなるのか。
これらを詰めていく事で、物語においての軸が出来上がって来ます。
作る内容を具体的にどうやって決めていくのかは、過去の記事を参考にして頂ければ嬉しいです。
詳細設計
詳細と言っても、一体何を作れば良いのだろうか……いやいや、まだあります。ここでは、こんな事を考えて行きましょう。
・各シーンにおける、各登場人物の目的と行動を明確にする。
・それに伴い、各シーンでどのような感情が扱われるべきなのかを決定する。
・相互的に問題が無いかを確認する。
・必要であれば、後のシーンの為に伏線となる内容を追加したり、シーンを追加したりする。
簡単に言っていますが、この作業が物語構築至上最も難しく、また時間の掛かる作業になります。
ですが、ここを丁寧に作って行く事で物語に深みが生まれ、心折れずに最後まで書く事も可能になります。
事前準備って大事です。きっちりやって行きましょう。
構築
実際に台詞を書いて行きます。今までに準備した事柄により、大体の内容は決定しています。
気を付けなければならないのは、説明的にならないこと。
後が分かっているからと言って、登場人物の思考にまでそれを持ち込んではいけません。
登場人物の行動・目的に沿う事で、実際に当事者達が考える内容に近くなっていきます。
単体テスト
ここでは、詳細設計で詰めた内容について試験する段階になります。試験と言っても、何をすれば良いの？ 当然、読み返すは読み返すのですが……気にしなければいけない事があります。
・各シーンにて、目的とされる行動・感情が達成されているかどうかを確認する。
・無理の無い展開であれば、読んだ時に違和感無く、次のシーンに進む事が出来るはず。
・無理があれば、登場人物の『やっていること』と『感じていること』に相違があるので、そこを修正していく。
・誤字脱字を修正する。
詳細設計の次に時間の掛かる作業です。
何しろ、自分が書いたシーンを自分で読み直しても、おかしな部分というのは特定し辛いものだからです。
この辺りも、プログラムと類似する部分がありますね。
友人に見て貰う事が可能ならば、これらの部分について説明した上で読んで貰いましょう。
結合テスト
デザインや全体的な価値観についての試験の段階です。個々のシーンは問題が無い前提なので、ここでは読み飛ばしていきます。
・全体的な雰囲気が、当初想定していたものと合っているか
・読み終えた時の読了感、読了スピード、テンポが想定したものと合っているか。
・おかしいようであれば、何処かのシーンが全体から考えて浮いている場合が多いので、そこを修正する。
ここで修正が出るとキツいです……しかし、作品の価値を上げる為にも頑張って行きましょう。
さて、実際のプログラム開発でもこの辺りで問題が発生すると、大騒ぎになります。
その理由は以下。
総合テスト
・当初想定していたテーマ通りになっているかどうかを確認する。
・物語の核となる部分が予定通りに際立ち、メッセージになっている事を確認する。
最早、ここで問題は出せません。
問題が発生すると、構築から以下の作業が全て『やり直し』になります。
一部の部分を修正して……等という、抜け道は存在しません。
ウォーターフォール・モデルの弱点とは
さて、読み進めて行けば分かると思うのですが――……この構築方法を使うと、『試験で問題があった場合に、後から発見されれば発見される程、出戻りが困難』になります。
また上流工程に戻る事は許されない為、作っている途中でより良いシーンを思い付いたとしても、反映させる事は極めて難しいです。
何故なら、予め考えられたそれぞれのシーンには関連性があり、容易く前にしたり後にしたり、挿入したり削除したりといった事は出来ないからです。
やるとすれば、それぞれのシーンを逐一確認して、問題が無いかどうか、どこを修正しなければならないかを『プロット上で』確認していかなければなりません！
こんなに面倒臭い事があるだろうか！
……と書いていきましたが、プログラム開発における『ウォーターフォールモデル』についても、全く同じ事が言えます。
最近余り使われていないのは、そういった理由からだったのですね。
「ウォーターフォールモデルで作る事が出来るシステムは、既に一度作った事があるものだけだ」等と言われたりすることも。
うわあ……
じゃあ、どうしてこのモデルを使って作るの？
その理由は、『今の段階で作る事が出来るものを、最大限のクオリティで作る』為だったりします。上記の指摘通り、今までに作った事が無いものは（詳細設計における想定不足、実際の構築時の食い違い等が多い事から）問題が多量に発生し、寧ろ創作の邪魔をしてしまう可能性が高いです。
ですが、一度作った事のある物語や発想から構築までが単純なものに限って言えば、クオリティを上げる為に設計書（プロット）が役に立つ事が多く、これを行う事によって自身がスキルアップしていく、という魅力があります。
漠然と作品を作って行っても、勝手にスキルアップする事はあまり無いです。
きちんと狙った通りのモノが作れるようになって、それが初めて『技術』として昇華されていく、という事もあります。
考えられる簡単な物語、シナリオ。一度はウォーターフォールモデルを使って仕様に落とし込むと、違った発見があるものです。
では、初めての試みで物語を作りたい場合は、一体どうしたら良いのでしょうか？
という事で、『反復型開発モデル』に進みます。
詳細は次回！
スポンサーリンク
スポンサーリンク
0 件のコメント :
コメントを投稿