目次
業務アプリケーションのシステム開発
くだもの小僧と申します。
かつては、業務アプリケーションのシステム開発に携わっておりました。
システム開発は、結局はプログラミングをしてロジックを通さないと、動くものはできません。
家を建てる時でも、図面だけ書いても家はできません。大工さんなどが、基礎を作って柱を組み立てて、壁や窓や屋根を作っていくことで、家は出来上がります。
しかしながら、設計をして図面を書かなければ、家を作ることはできません。
設計と施工の両方が必要です。
システム開発でも似たようなことが言えます。いきなりプログラムを書こうとしても、たいていのプログラマーは書けません。設計書を提示しないと書けません。
いくつかの設計と実装（プログラミング）とテストが必要です。
と言うことで、業務アプリケーションのシステム開発では、いくつかの工程があって、その手順に従ってシステム開発を行なうことになります。
ソフトウェアの場合、ぱっと見て分かりにくいので、歪んだシステム開発が続行されてしまう場合があります。
ウォーターフォール型開発
「設計→プログラミング→テスト」が上から下へと実施されるウォー
ターフォールモデル
業務アプリケーションのシステム開発には、いくつかの方法があると言われますが、私はほとんど、ウォーターフォール型開発しか経験したことがありません。
アジャイル型開発というものをよく聞きますが、現場での経験として、一人ないし数名のユーザと小規模のプログラムを作ったことはあります。それはひょっとしたら、アジャイル開発だったのかも知れません。
しかしながら、それはごく小規模のものです。
下記にウォーターフォール型開発の図の一例を掲示します。（出典：ITトレンド）
一番下にある「システム実装」と言うのが、プログラミングのことです。プログラミングは専門学校や企業研修または独学で学ばないと、習得できません。なぜならプログラミングは、規則を覚えないとできないからです。何も学ばずにいきなり書けたら、天才です。
この図では「システム実装」の右に「・テスト」と書いてありますが、これはプログラマーが、ちゃんとプログラムが作られたかどうかを確認するレベルのものです。あまり書かれないものですが、まともなプログラマーならこのテストをやっています。
やってなかったら、単体テストで沢山のバグ（不具合）が出る可能性が大きくなります。
システム開発の責任の所在
要件定義と受入テストはユーザの責任です。他の工程はベンダーの責任です。
要件定義も受入テストも、責任はユーザですが、ユーザとベンダーの共同作業になります。
なぜなら、ユーザはシステム開発のスキルが不十分な場合が多いからです。
それでも、ユーザが自分の仕事をちゃんと行えば、システム開発は回ります。
システム開発がとん挫する多くの原因の一つは、ユーザが自分の責任（仕事）を行なっていない場合です。
例えば、要件定義の責任はベンダー側にあると思い違いしている場合や、経営陣がシステム開発のGOサインを出したにも関わらず、日々の業務が忙しいからと言って、要件定義をないがしろにする場合です。
そういう場合、システム開発が既に進んでだいぶ後の工程になってから、「ここはこうして欲しい。」と言うユーザの声が多々出てきます。
後戻りが甚だしくても、「それを何とかするのがプロでしょう。」と、涼しい顔をして言うユーザもいます。日本独特の悪習だと思います。
多大なコストがかかります。この場合、ユーザに非があります。
それでいて、納期厳守を声高に叫ぶユーザが多かったです。
また、出来上がったものが見えないと判断できない、というユーザがいます。
作り終えてから、こんなふうに直してほしいと、大幅な修正を要求します。費用も大幅に増えます。
これを解消するには、プロトタイプ型開発のコストを負担する必要があります。
後一つは、ユーザとベンダーのコミュニケーションが噛み合ってないまま、作業工程が進んでしまっていく場合です。
どちらに非があったのか、両方ともか、様々なケースがあると思いますが、ベンダーに非があるケースも見たことがあります。
ベンダーが海外のネームバリューの高い会社でしたが、日本法人はレベルが低く、業務知識がほとんど無く、海外親会社に胡坐をかいているような日本法人でした。
それでいて、ユーザがスケジュール通りに作業してない、と言う点ばかりをとりあげて責任逃れをしておりました。ひどい会社だなと思いました。
結局、その会社はネームバリューは高いが、本当はシステム開発を十分に分かっていなかったのです。
結局、その会社は途中で引き揚げてしまって、他の会社が後を引き継ぐ（尻拭いをする）ことになりました。
ある地方のユーザです。ベンダーは、月曜日は移動日と言って午後から出てきて、金曜日は午後には帰ってしまってました。交通費・宿泊費もユーザ持ちです。
これは極端な例でした。
要件定義でコミュニケーションが噛み合ってないと、悲劇が起きるのです。「だろう」でミーティングを進めてはいけないのです。確認が必要です。
とにかく、要件定義は最初の肝心なところなので、ここで力を入れないと、システム開発は十中八九うまくいかないです。
ウォーターフォールは「滝」ですから、一方向に流れます
上図で示したように、ウォーターフォールの工程は、一方向に流れます。
つまり、上から下に流れます。
ですので各工程は、その工程でのやるべきことを十分にやり遂げており、検証も十分行ったうえで、次の工程に進むのが理想です。
ところが、現実は逆向きの流れがあります。というか、ほとんどの場合、逆向きの流れが多発します。つまり手戻りです。
もし、単体テストでバグが発見されたら、そこは逆向きの流れではなく、当然差戻しになってプログラミングの修正です。これは正常な流れです。
しかしながら、プログラミングを正しく行ったのに、逆向きの流れが行われることがあります。
例えばユーザの要求が変わって、やり直しになる場合です。要件定義をないがしろにしていたケースです。これには、余分に大きな工数がかかります。
本当のプロなら、ウォーターフォール型開発の原則に逆らった作業は、極力やらないように心がけます。
これをやってしまうと、システム開発は上手くいかず、大幅な工数超過に陥ります。
家で例えると、壁をすっかり作ってしまった後に、ここには窓を作って欲しいというような場合です。あるいは、作った後から、間取りを変えてほしいというような場合です。
家の場合なら、それがどれだけ大変なことか見て分かりますが、ソフトウェアの場合だと、「そんなもん、ちょっと変えたらええことやないか。」と考えるユーザもいるのです。
誰かが被らないといけなくなります。
もし、ユーザでもなく元請けでもなく、下請けが被ってしまった場合は、資金力が乏しい下請は悲惨な状況に陥ります。
強調したいことは、上流工程での調査・分析が不十分であり、やり残した作業を下流工程に押し付ける現実があるということです。
プロトタイプ型開発
アジャイル型開発は、大規模システム開発には難しいです。アジャイルと言いたがる人は多いのですが、実際中身を見てみると、ただのウォーターフォール型開発だったこともありました。
プロトタイプは試作品ということです。
プロトタイプ型開発では現実的には、簡易的に動くシステムを作って見せて、ユーザに確実な判断をしてもらう手法です。
ウォーターフォール型開発では、ドキュメントを見せます。
ドキュメントは動かないので、「動くものを見せてもらわないと判断のしようがない。」というユーザが出てきます。
簡易的にでも動くものを見せれば、ユーザはかなりの確度で判断ができるといういことです。
しかしながら、簡易的とは言っても、工数がそれなりにかかります。Excelの関数やマクロを使うのか、Accessを使うのか、または別のツールを使うのか、どちらにしても工数が余計にかかります。費用がかかります。
それらツールで作ったものが、そのまま本番で使えるシステムに発展するわけではないので、ツールで作ったものはあくまで参考です。
この工数がもったいなく納期が延びるので、プロトタイプ型開発は採用されづらいのだと思います。
そして、ウォーターフォール型開発ではドキュメントでのコミュニケーションとなり、それが不十分な場合、いびつなシステム、動かないシステム（致命的に失敗）が作られてしまうのです。
検証（レビュー）が不十分なためいびつなものができる
下記にウォーターフォール型開発の図を再掲します。（出典：ITトレンド）
赤い丸で囲まれた「検証」という文字が目立ちますが、下段に記された
「工程ごとにレビュー（成果物の確認）を行なう」の作業が大切です。
例えば、要件定義でのレビューを十分に行ってからでないと、次の工程に移ってはいけないということです。
以下の工程も同様です。
ところが、PM（プロジェクトマネージャー）は、納期優先と言う名目で、レビューを不十分にして次の工程に進むことがあります。
ウォーターフォール型開発の原則を自ら壊しているのです。
本当は、各工程を十分に行ってから、次の工程に移る方が、結果的にシステム開発は早く完成するのです。
ところが、プロジェクトにはマイルストーンがありますので、不十分でもそこに到達したということにして、プロジェクトの進捗を偽ってしまうのです。
これは本物のPMではありません。
こうして、プロジェクトは失敗します。
最後に
本投稿では、徒然なるままに、システム開発での体験談を書きました。
なぜ多くのＰＭが「前倒し」をやたら主張して、結局納期遅延をもたらすのか、
もっと言うと、システム開発の失敗をもたらすのか。
システム開発は、多くの犠牲者を生み出すプロジェクトです。
