ソフトウェア開発の失敗は上流工程のレビュー強化では対策にならない

ソフトウェア開発の失敗の原因には上流工程での品質に問題があるとよく聞くことがおいいですね。

IPAでも「設計レビュー・要件定義強化のススメ」とタイトルを付けた資料を公開しています。

ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」を公開 ～定量的データに基づくソフトウェア開発のプロセス改善を目指して～：IPA 独立行政法人 情報処理推進機構

 資料自体は、ダウンロード前にユーザ登録と資料の利用目的のアンケートに答えるだけで無料でダウンロードできます。

ページを捲るとP8に図2.1-1上流工程（基本設計〜製作）強化モデルが目に入ります。

引用　IPA「設計レビュー・要件定義強化のススメ」P8

上流工程はどこの局面か

まず上流工程の定義についてP1で次のように定義されているのですが、

「本書のスコープは上流工程（要件定義、基本設計、詳細設計及び製作）の品質マネジメントである。」

この定義は一般的なんですかね。個人的な見解としての上流工程は、

要件定義及び基本設計

までだと思っていましたが。詳細設計以降はそれこそ労働集約型の工程に遷移しますし、実際にエンジニアの工数の山積みは詳細設計以降から上昇し、結合試験以降に降下するので。

強化策の違和感

もう一度図を出して確認してみましょう。

下から上に登る図です。向上を目指す図だから上に向かって矢印をむけたのでしょう。

さて、本題ですが、設計文書充実化とは文字面から設計文書を増やすことで表現漏れを防止しようとしたいと読み取れます。

ひとつ上に登ると設計レビュー強化とあり、質と量の増強とあります。まあ、設計文書を充実したのであれば量的に設計レビューは増えるのは当然として、従来の文書の設計レビューのカバーを増やしなさい、と言われているわけです。

この前提には、

「今までのソフトウェア開発において設計レビューは十分でなかった」

と懺悔していると読めるのですが。

モヤっとするのは設計レビューの質の向上です。これは現場において設計レビューの観点を持っていないということの証左ではないかと疑いを持たざるを得ません。実際、それが現実なのでしょうけれど。

これらの設計レビューを質的、量的に強化という名のカバーを増やすことで上流工程の不具合を検出することで、結果的に上流工程での設計レビューを通過した後に発現する不良を減らそう、と言っている図でしかありません。

強化すること自体がおかしい

いつも書いていることですが、品質を「強化する」という表現はおかしいです。業務要件をITで実現するためのソフトウェア開発なのに、不具合が多いから強化するなんて。

本来は、業務要件をITで実現しなければならないスコープの漏れのない仕組みを作業プロセスとして設計、実行するのです。

さらに、業務要件からITで実現する機能仕様を定義し、実装した機能仕様を検証する試験を行うことで業務要件が実現されていることを担保するのです。

その観点から言えば、信頼性向上とか「何言っているんだ、お前」なのです。

必要なもの（ドキュメント）を作り、実現できていることを検証する

ソフトウェア開発で必要な作業は、作業した結果であるアウトプットを次工程のインプットとした場合に価値を産むかどうかで作業プロセスを設計しなければなりません。

これは絶対に守らないとあったらいいねとか前回のソフトウェア開発で作っていたからと云われの不明で利用価値のないドキュメントを作る時間を割いてしまうことになります。

ソフトウェア開発でアウトプットとして作ってしまうとそれが正しいかを次工程に回す前に検査が必要になり、価値がないアウトプットであってもレビューが必要になることで価値のないレビューを行い、工数を消化してしまうのです。

上流工程が起因によるソフトウェア開発での失敗の対策は、次の３点でおこなれなければなりません。

・価値ある作業プロセスだけで作業標準プロセスを構成する
・作業を行うことで価値をアウトプットする
・価値を計測することで要件が実現できているかを検証する

レビューの強化なんて対処療法です。