20年も前の話になる。バッチ処理が主力を占めていた時代に，ソフト開発プロジェクトは極めて厳重な管理体制の下で進められていた。いわゆるソフトウエア・エンジニアリングの視点で，開発プロジェクトは上流工程から下流工程まで複数に分割され，標準化規約に基づいて作業結果をドキュメント化することが求められた。
例えば，大型プロジェクトの工程は以下のようになる。
すなわち，(1)システム企画，(2)システム基本設計，(3)システム概要設計，(4)システム詳細設計，(5)プログラム設計，(6)フローチャート作成，(7)コーディング，(8)デスク・デバッグ，(9)マシン・デバッグ（単体テスト），(10)連結テスト（統合テスト）などである。それぞれの段階でドキュメントが作成される。上司のレビューを受ける。さらに顧客の承認を得て，次の段階の工程に進むという方法が採られた。
今の若手ソフト技術者は，ずいぶんと「まどろっこしい」やり方と思われるかもしれない。しかし，こうすることによって数百万ステップに及ぶ大規模開発を破綻なく完了させることができたのである。
この手法には，上司がドキュメントを各段階で直接レビューするので，間違いが次の段階に及ばないという大きなメリットがあった。したがってプロジェクトが全体の何％まで完了しているのか，いわゆる進捗状況を正しく把握することが可能だった。最終段階でテストしたら，全く動かないということはまず起こらなかった。
これに対し，現在のソフト開発のやり方はずいぶん違う。
たとえばWWWシステムやWindowsベースの業務システムのフロントエンド・システムだと，開発手法としてプロトタイピング（試作開発）が一般的に使われる。開発のためのドキュメントを作成しないで，いきなりコンピュータを用いてプログラミングを始めることが当たり前になっている。上司が内容を子細にレビューすることがなくなり，本人の申告だけを頼りに管理する傾向が強い。
確かに当初は，こうした開発手法が効率的だった面がある。システムの規模が小さく，ユーザ・インタフェースさえキチンとすれば良いようなものが多かったからだ。しかしシステムの大規模化と複雑化にともない，このところ欠陥が目につき始めた。開発されたシステムの信頼性低下につながりかねない状況が生まれている。
問題を大きくしている背景には，インターネット絡みのシステムが戦略システムへと格上げされたことがある。複数の業務システムと連携したり，エンド・ユーザや企業との取引を直接行うなどの役割を担うようになってきた。単純なフロントエンド・システムではなくなったのだ。とりわけe-ビジネスのためのシステムは，重要度がぐっと増している。
こうしたシステムは，当然のことながら開発規模が大きい。ユーザ・インタフェースも高度だし，アルゴリズムも複雑だ。最先端の開発ツールが駆使されるが，それだけでは十分といえない。開発の進捗状況とその信頼度が確認できないような開発手法をとっていると，信頼性の面で不安が残る。納期がきて全体の連結テストをしたら動かないということが，頻繁に起きる可能性がある。
取材してみると，プロトタイピングをベースとした開発方式が引き起こす納期遅れや信頼性の低下が，いろいろなところで顕在化しているようである。
従来の開発方式なら，問題が生じたときに上司が火消し役を務めることもできた。しかし，現在の方式では担当者に任せきりになってしまう。途中で介入して正常な状態に持っていくことはまずできない。可能なのは，最初から作り直すことだ。当然，開発マネージャはやる気をなくしてしまう。ぜんぜん進んでいない作業でも，進捗を聞かれると「予定通り進んでいます」と答えてしまう一部現場の責任感の低さも問題を複雑にしているようだ。
挙げ句の果てには，問題が露見してしまってチーム全員が退職してしまった例もあると聞く。信じられない思いだが，開発現場の実状を直視しなければならない。
このような状況を考慮して，レビューの在り方など開発手法や開発体制を根本的に見直す時期にきているのではないだろうか。
（上村 孝樹＝コンピュータ局主席編集委員）
