浮遊する無名作家の浅慮

SE技術から物語構造を考える③ ウォーターフォール・モデル

SE技術から物語構造を考える③ ウォーターフォール・モデル



こんにちは。

今回からは、物語構造を作るにあたり、システム仕様構築技術から引用した場合の作り方について見ていきます。
やはり、餅は餅屋と言うべきなのか。システムの仕様設計は、どうも論理・計算的思考に寄っている気がしますね。

 ウォーターフォールモデルを考える

全ての仕様設計の基礎となる考え方でもある、ウォーターフォールモデルについて考えていきます。
前回の記事で「まるで下流に向かう水のように」とお話した通り、各工程に従って順番に降りて行き、試験をもって終了とする考え方です。

・要件定義
そもそも目的となっている内容を、分析・検討する。
システム的にどのような解決が考えられるのか、解決方法があるのかどうか。

例)クラス名簿を管理したい。その時、それぞれの得意科目とテストの点数成績を保存しておいて、ランキングが付けられるような機能も欲しい、とした場合。

どのようなシステムが考えられるのか? 目的を達成するためには、一体何が出来ている必要があるのか?
それを達成するに当たり、必要になってくる技術ってなんだろう?
意思決定から開発、最終完成段階のスケジュールラインはどうなるのだろう?

・基本設計
システムの外観や、根幹的な枠組みを決定する為の工程。

技術的には○○を利用していこう。デザインはどうしたら良いか?
より使い易いユーザインターフェースは? システム開発に向けて、大まかに開発工程を分けられる部分は?
そのシステム仕様は、要件定義にて設計した内容と照らし合わせて無理がないか?

作業分担にも関わって来ますが、まあ物語は大体ワンマンなので分担はしません。

・詳細設計
実際の開発・構築内容を決定する為の工程。

○○の機能は、具体的にプログラミングに落とし込んだ場合、どのように作ればいい?
必要な関数(早い話が、プログラムにおいて『機能』扱いとなる最小の単位です)は? 解決手順は?

この段階まで落ちて来ると、もうプログラムを組んでいるのと然程変わらない段階に入って来ます。
わざわざ仕様にするのは、主に基本設計との差異が生じていないかを確認しなければならないから。

ウォーターフォールモデルは、基本的には一度決めた内容を変えない方針で進んでいきます。例外が発生しても、前段階の工程に戻る事は殆どありません。
だから、仕様設計の段階が確実に完成となるまで、落とし込んで行く必要性があるのですね。

・構築
ゴリゴリゴリゴリゴリゴリゴリゴリ

・単体テスト
見る場所は、主に詳細設計で書いて行った内容。

若しも詳細設計が無理の無い方法で記述されていたとしたなら、それぞれの機能は予定通りに動くはずだ。

そのような視点で試験を進めていきます。

・結合テスト
作り上げた機能に、相互的に問題はないか、予定通りに動いているかを試験する段階です。

個々の機能には、問題が無いことが大前提。だってそれは、単体テストの段階でOKになっている筈ですからね。
相関関係を持っている機能同士で、認識の相違が無いかどうかを確認していきます。

・総合テスト
全ての機能を通して、要件定義通りに開発が出来たかどうかを確認する段階。
さすがの総合試験です。ここで大きく食い違うようだと、プロジェクトが破綻すること間違い無しです。

→リリース

 内容についてはわかった

問題は、これらをどうやって物語構造に当て嵌めるか……という事になりますが、なんとなく想像が付いて来ましたか?

・要件定義 → どんな物語を作ろう? 作品を通して、何が見える事を目的としようか?
・基本設計 → 物語の外観は、どのように決めていこうか? 達成するために必要な機能(シーン)って何だろう?
・詳細設計 → それぞれのシーンで見えて来なければいけないのは何だろう? 解決の手順は?
・単体試験 → シーンは思った通りの動き方をしているだろうか? 無理はないか?
・結合試験 → 前後関係のあるシーン同士で問題は発生しないか? 目的と行動は矛盾していないか?
・総合試験 → 要件定義通りの作品が出来上がっているか?
→公開

という手順になる訳です。
如何にも辻褄が合ったように見える、如何にも合理的な手段ではありませんか!

 如何にもって何?

はい、先に結論から申し上げておきます。

ウォーターフォールモデルのように、下流に沿って書いていく物語は、物書きとして一度は作っておく必要があると筆者は感じます。

但し、この開発モデルに縛られていると、逆に行動が制限されて来ます。後で詳しく説明しますが……
プロットが出回る場合(舞台や映画、ドラマのシナリオ等)以外は、あまり縛られ過ぎない方が無難です。

※例外として、開発段階で多人数と共有する必要が有る場合は、このウォーターフォールモデルは意識合わせの為に大変重要になってきます。完成形を美しくする為にも、一度物語を最後まで書くことが出来るようになった段階で、技術として身に付けてしまいましょう。

さて、どうして行動が制限されて来るのか? ……何となく分かって来たでしょうか。

仮定:ウォーターフォールモデルの開発について、もしも手前の工程が完全なものであるならば、上流工程に遡る必要はない。

この仮定が意味する内容に、大きなメリットと大きなデメリットが存在するのです。
次回、もっと詳細に追い掛けて行きましょう。


スポンサーリンク
スポンサーリンク

0 件のコメント :

コメントを投稿