ソフトウェア工学をつつく7ープロセスモデル。ちゃんと作業を区切ろう。

ソフトウェア工学がもたらした成果の中で、一番重要かもしれない概念が プロセスモデルピヨ♪今回はそのプロセスモデルをつつくピヨ♪
プロセスモデルを簡単に言うと、システム開発とシステム運用の工程を細かく区切って定義したものピヨ。これは工学でお馴染みの考えピヨね♪みんな、工場見学もしくはTVとかで工場内の様子を見たこと事ある？見たことがあるのならば、箱だけを作る工程、箱に入れるものだけを作る工程・・・などが明確に区切られて、機械で大量生産されているのを知っていると思う。このように、明確に作業を定義する事により作業の自動化や生産性の向上を期待できるんだ。そのソフトウェアバージョンがプロセスモデルと思えばいいピヨ♪
その中で一番古く単純なのがウォーターフォールモデルピヨ♪これはソフトウェア開発を6個の工程で区切るプロセスモデルなんだ。その工程を列挙するから見てね♪


【ウォーターフォールモデルの手順】

• 基本計画・・・既存のシステムがある場合、その問題点を調査し、システム分析を行い、システム用件、問題点の解決法を考えるピヨ。そして新規の場合も再構築の場合も、システムのユーザーの要求、システム導入会社の要求等を正しくまとめて要求定義書にするピヨ♪
• 外部設計・・・要求定義書に基づいて、ユーザインタフェース（画面、印刷物のレイアウト等）、コード設計などをおこうなうピヨ。この工程で定めた事は、外部設計書に書くんだ。
• 内部設計・・・外部設計書に基づき、オブジェクトのデザインやモジュールの設計をするピヨ。この工程で定めた事は内部設計書にするんだ。
• プログラム設計・・・内部設計書に基づきコーディングをするピヨォ♪
• テスト・・・出来上がったプログラムをテストするピヨ。
• 運用・・・ここまで来たらソフトウェアシステムは完成だから実際に運用して、今後の為に問題点などを書いておくピヨ。

上記の一覧を見たら分かると思うけど、ウォーターフォールモデルの特徴は、 各工程を滝が流れるように順番に進めていく所にあるピヨ♪ ってこれぐらいならば、どの教科書にも書いてあるからつついているとは言わないよね。皆も現実を知りたいだろうから、中の人（このブログの作者）の実体験を踏まえながらもっと詳しくつついていくピヨ♪じゃあ行くぞ！鳥やー
※先に断っておくけど、これは中の人の体験に基づくものだから、情報産業全体のことではないピヨ。


バサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサ



【基本計画の現実】
中の人の仕事はフリーな何でも屋エンジニアだから全工程を担当することが多いんだ。だかも勿論この工程も経験済み♪その時の事を踏まえて基本計画をつつくいていくピヨ♪
教科書では大層な事を書いているけど、現実はそんなにたいしたものではないピヨね。日本では良くある事で、契約書での壮絶な心理合戦、責任範囲の不毛な擦り付け合い、美麗字句の言い合い、名刺交換、無意味な会議・・・などで費やされるピヨ♪とてもじゃなけど、巷で考えられているような華麗な工程ではないピヨね。実際は、泥臭い人間模様としか言いようがないそうだよ。勿論、情報産業は広いからもっと優雅な所もあるんだろうけど、残念ながら中の人は体験した事が無いピヨね。
先ほど書いたように、この工程は今後の全てを定める重要な工程なんだけど、実際は後の工程に押し付けられる事が多いピヨ。だってぇ、ココの工程で出てくる人の大半は情報処理技術を知らない人だもんね。そんな人達が、ソフトウェア工学に基づいてシステムを定める事を期待できるでしょうか（笑） その結果生まれるのが意味のない要求仕様書ピヨね・・・


【外部設計】
本来はしっかりとした完璧な要求定義書が必要なんだけど、現実はえてして意味のない要求定義書しかないからこの工程では、システムを使う顧客の要望を推理する事から始まるピヨ♪中の人の場合は仕方が無いから、無意味な会議中に勇気を振り絞って、情報の断片を聞き出して、この工程で推理をするそうだッピヨ。でも当然のことながら開発者はエスパーじゃないから、ウォーターフォールモデルでは禁止されている後戻りが何度も発生するピヨ。それでも完全な要望を顧客から聞きだすのは不可能に近い事ピヨ。だって、お客様も要望が定まっていない場合が多いからね。それは無理もない事だよ。お客様にしたら異文化以外の何ものでもないし、本来一番詳しくあるべきプロジェクトの責任者が情報処理技術を知らないもんだから上手くいくはずがないピヨ。 こんな調子だからやはり、ここで仕上がる外部設計書は不完全なものピヨ・・・もうだめぇ


【内部設計】
不完全な外部設計書と格闘しつつ、技術者が職人魂を発揮してデスマーチの下にソフトウェアの全体像を考えるピヨ。この工程はえてして、プログラム設計と同時進行されるピヨ。その様は地獄としか言いようが無いピヨね。今までツテがここに押し込まれているという事だね。本来ならば内部設計書を作るべきなんだけど、デスマーチではちゃんとしたものは作られない傾向があるピヨ。


【プログラム設計】
本来ならば内部設計書を見て行うこの肯定だけど、先述の通り内部設計と同時に行われる事が多いピヨ。もう世間の優雅なイメージとは逆で、阿鼻叫喚絵図だピヨ。ここで多くの人間ドラマが発生するピヨ。もちろん、悪い意味でね。デスマーチ中に職場恋愛なんて生まれない。生まれるのは負の感情だけさ。


【テスト】
ウォーターフォールモデル型開発では、実際は殆ど行われていないピヨ。これで本当に大丈夫ぅ？


【運用】
テストがろくにされていないものだから、当然お客様からのクレームが来るピヨ。当たり前だよね。無計画かつ、お客様の要望をろくに聞かないで成功するはずが無い。日本では責任者は責任を取らず、デスマーチの被害者である技術者達にに責任を押し付ける場合が多いんだ。それでも職人魂に燃える技術者達には「今こそ本当のシステム開発の始まりだ。お客様の声がやっと聞こえるぞー。」という強者が多いピヨね・・・・


どうかな？これで強烈にウォーターフォールモデルの弱点が分かったと思う。それはソフトウェア開発は完璧に進められないという事ピヨ。ウォーターフォールモデルでは、全工程が正しい事を前提としていけるけど、現実はそんなに甘くないピヨ。仮に要求定義を完璧にしたとしても、時が経てばシステムに対する要求が変化するからね。そんな現実を無視したプロセスモデルは通用しないピヨって事だね。だけど、このモデルは非常に重要ピヨ。このプロセスモデルを反面教師として、多くの犠牲を払いながら開発プロセスの研究がさらに進んだんだ。この先が気になると思うけど、長くなるからここで一旦おしまい。