ITシステム開発のフェーズを2つに大別すると・・・政府調達に見るIT投資の無駄遣い

『要件定義／基本設計／詳細設計／開発・単体テスト／結合テスト／総合テスト』というシステム開発全体を通して、2つに大別するとフェーズをどのように分けることができるのか、という質問をいろいろな人にしてみたところ、面白い傾向が見受けられました。

まず、答えの大半は2パターンのいずれかでした。一番多かったのはこの区分です。

【回答１】 Ｖモデルによる区分パターン
要件定義／基本設計／詳細設計 vs 開発・単体テスト／結合テスト／総合テスト

システム開発には必ずテストフェーズがあります。テストフェーズでは、要件・設計に基づいた開発がしっかりと行えているかを試験項目に沿って検証するので、必然的に、「開発・単体テスト」は直前フェーズの「詳細設計」で決めたことができているかを確かめることになります。同じように、「結合テスト」は「基本設計」で決めたことの確認、「総合テスト」は「要件定義」で決めたことの確認をします。

このため、要件・設計フェーズとテストフェーズの2つに大別できるという考え方が回答１です。クライアントの業界（通信・金融・官公庁など）に関係なく、様々な人たちがこの回答をしていました。

一方、回答１に次いで多かったのがこれです。

【回答２】 調達単位による区分パターン
要件定義 vs 基本設計／詳細設計／開発・単体テスト／結合テスト／総合テスト

回答２を挙げてくれた人たちは、明らかにクライアントの業界において偏りが見られました。それは、官公庁の案件に関わる機会が多い人からの回答が多かったのです。

官公庁や半官半民と言われる企業の場合、特定フェーズを担ったベンダーは別のフェーズを受注してはならないとしていることがあります。これは分離調達と呼ばれる官公庁由来の調達制限の仕組みです。ひとつのシステム開発が数十億円に上る官公庁では、これを1社に独占させてしまうと、「規模の大きいベンダーしか受注できなくて不公平である」ということで、小規模ベンダーにも案件受注のチャンスを広げるために、わざわざこのような制度ができました。

分離調達の場合、システム開発の案件をフェーズによって分割することになります。一般的なのは、要件定義フェーズ／設計・開発・テストフェーズに分けるケースです。要件定義まではユーザー側の業務支援という位置づけですが、設計フェーズ以降はシステム開発の受託者ということでユーザ側との役割が明確に線引きされるので、ここをもってフェーズを分けるのが一番インパクトが少ないというのが理由です。

他にも、規模が超大な案件では、結合テスト・総合テストフェーズも別のベンダーに発注するケースがあります。なんとも非効率に思えますが、要件定義からテストまで1つのベンダーに任せてしまうことで失われる競争原理と中小ベンダーへの機会不平等を踏まえると、分離調達というのはやむを得ない措置というのが発注側の言い分です。

では、回答２（分離調達）を挙げた人が回答１（Ｖモデル）を否定したかというと、そんなことはありませんでした。むしろ、「まあその方が普通の分け方だね」と自嘲するような言い方が目立ったように思えます。反対に回答１を挙げた人に回答２の考え方を伝えると、官公庁の案件に関わったことのない人たちは、「それは不自然だし、むしろ悪影響なのでは？」との疑問の声が聞かれます。

この声と同じ考えを、実は政府中枢の人間も持っています。たとえば、2010年12月の「最適化、調達の高度化に向けた調査結果」というＣＩＯ補佐官等連絡会議の資料では、次のような問題意識が発表されています。
http://www.kantei.go.jp/jp/singi/it2/denshigyousei/dai5/siryou3_1.pdf

• 分離調達によって、（フェーズ間の）整合性をとるための費用が増加。・・・安値入札によるロックインでトータルコストの増大。開発失敗リスクによる捨て金の増加。
• 能力不足のベンダーが受注するリスクや期間内に受注が確定できないリスクは増えた。
• 多くの業者が調達に関わり、仕様・要件に対する共通理解が困難。・・・基盤受注業者が個別受注業者の責任まで負わせられ、そのコスト負担を強いられる。

他にもさまざまな問題点が挙げられていますが、残念なことに、2年以上前の問題提起も空しく、まだ現場ではこれらを解消しようとする動きは大きくありません。

開発以前のフェーズとその後ろのフェーズは明確に性質が異なるので、担当チーム（もしくはベンダー）を分けることは、品質検証という意味はありますし、その意味でテストチームは開発チームと分けているプロジェクトというのは一般的です。（ベンダーを分けるところまでやるのは超大規模な案件に限られますが）

しかし、要件定義と設計フェーズを分断するのは、システム開発上のポジティブな意味はほとんどありません。むしろ、設計に責任を持たない人たちが好き勝手に要件定義を行って、絵に描いた餅が出来上がってしまうリスクを高めます。そうさせないためには、要件定義をしたベンダーが責任を持ってい設計・開発を行うように調達計画を定めなければなりませんが、今の仕組みはそうなっていません。

官公庁の案件に関わっている人たちは、是非、調達計画の仕組みの不自然さについて声を上げてみてください。政府中枢で最適化計画の調達の仕組みに関わっている人たちに、その声が届けば、特許庁の55億円の無駄金、そのほか下記リンクに示したIT投資の無駄遣いが減って、日本の国のシステム開発はもう少しマシになるのではないかと思います。

『電子政府構想は無駄遣いの温床： 8754万円の電子申請システムが4年間使われず』
http://it-ura.seesaa.net/article/127063402.html

• 沖縄県駐留軍用地の返還にともなう給付金支給申請システム（初期費用：3.9億円、ランニング費用：0.4億円/年、利用件数：4件/年）
• 政治資金・政党助成申請・届出オンラインシステム（初期費用：5.7億円、ランニング費用：2.9億円/年、利用件数：0件/年）
• 公益法人の事業計画書及び収支報告書の届出システム（初期費用：5.2億円、ランニング費用：0.4億円/年、利用件数：29件/年）
• 高校卒業程度認定試験の合格証の交付手続きシステム（初期費用：11.8億円、ランニング費用：1.1億円/年、利用件数：115件/年）
• 製造タバコの小売販売業の許可等239手続きシステム（初期費用：0.5億円、ランニング費用：0.1億円/年、利用件数：55件/年）
• 恩給申請手続きシステム（初期費用：1.9億円、ランニング費用：0.6億円/年、利用件数：476件/年） 等