ITシステム開発における
問題プロジェクトが発生する原因とは？

　ITシステム開発の現場では、しばしば工期遅延や予算超過、出来上がったシステムの品質が充分でないといった問題プロジェクトが発生しています。先に述べたシステムの証明書誤交付の事例も、品質が充分でないまま、一般利用者にリリースされてしまったことにより発生した問題プロジェクト案件といえます。

　日本情報システム・ユーザー協会が東証上場企業とそれに準じる企業の計4,500社を対象とした調査をおこなった「企業IT動向調査報告書2023」によると、ITシステム開発において、予定より工期が超過した件数や予算が超過した件数、品質に不満がある件数の割合は、以下の通りとなっています。

　このように、ITシステム開発においては、工期遅延や予算超過、品質への不満が非常に高い割合で起こっており、特に大規模なプロジェクトほど、その傾向が顕著であることが分かります。

　同調査は、民間企業を対象としたものですが、公共分野を専門として、システム開発やプロジェクトマネジメント（PM）に従事してきた経験に照らし合わせても、公共システムの開発の場合も、上記と同様の傾向にあると感じます。では、なぜITシステム開発では、このような問題プロジェクトが多く発生するのでしょうか。

　先ほど示した「企業IT動向調査報告書2023」によれば、工期遅延や予算超過の主な要因として、「計画時の考慮不足」「仕様変更の多発」「想定以上の現行業務・システムの複雑さ」が挙げられています。また、品質の要因として「ベンダーのスキル不足」を挙げる企業の割合が多い結果となっています。しかし、このようなトラブルが多くのITシステム開発プロジェクトで発生している現状から、ITシステム開発プロジェクトには、上記のような表層的な問題ではなく、もっと本質的な問題が潜んでいるように思います。

　ITシステム開発プロジェクトが問題になりやすい要因について、建設のプロジェクトと比較して考えてみましょう。

　大規模な建設工事プロジェクトの場合、概略設計→予備設計→詳細設計、と設計を具体化し、その設計に基づき施工を実施します。設計の各段階では、力学的な裏付けに基づき設計を検証・詳細化し、設計に基づき工法を決定し施工実施に至ります。一連のプロセスにおいて、現場合わせの対応などはあるにせよ、計画に基づいた設計・施工をすることでプロジェクトの完遂を目指します。支配するのは、物理的法則に基づく作業量と工法ごとの実績に基づく生産性であり、この点において変動性は低いと言えます。

　これをITシステム開発のプロジェクトに照らし合わせて考えてみましょう。プロジェクトを要件定義→外部設計→詳細設計→実装・試験という工程ごとに詳細化しながら進める、という点は類似していますが、その内訳は大きく異なります。

　まず、1つは作業量を見積もる難しさです。画面数や入出力の数等に基づいて規模を計測する試みは、以前からなされてきましたが、現場では「単純な機能を10個作る」よりも、「難しい機能1つを作る」ほうが作業量は大きくなる場合もあり得ます。

　また、「使いやすさ」「機能の充分さ」というような数字で計れない価値尺度は、実際にシステムを触らないと充分に評価することができず、システムがある程度出来上がってから設計・実装をやり直す、といった局面に至った場合、数値に基づいた作業規模の予測から徐々に乖離していくことになります。

　もう1つは、生産性を定量的に測る難しさです。建設の場合での工法にあたる、開発ツールやシステムを構成するミドルウェア等は、ITシステム開発の場合、技術の進歩やトレンドにより短いサイクルで変化する傾向にあります。変化に適合せず、使い慣れた開発ツールやミドルウェアを使い続けると、製品のサポート切れや開発ツールの有識者不足に悩まされるジレンマを抱えているため、開発ツールの変化に合わせて、短いサイクルで開発手法も見直しを図らざるを得ません。結果として、各開発手法での生産性を定量的に見積もることができないという状況にあります。

　このように、マクロな視点から考えると、作業量の見通しをつけることも難しく、生産性も一様には測れないというITシステム開発の本質的な性質が「計画時の考慮不足」や「ベンダーのスキル不足」と受注者から指摘される要因になっているのではないでしょうか。

　このようなITシステム開発の性質を理解した上で、プロジェクトをもっと柔軟にマネジメントしようという試みは、以前から広く行われています。

　昨今、多くの現場で受け入れられるようになった「アジャイル開発」は、反復と評価を細かなサイクルで行うことで、計量しづらい作業量を予測しやすくするプロジェクトマネジメント（PM）の手法です。そして、その結果を次のサイクルの計画にフィードバックし、さらに生産性の予測精度を上げ、プロジェクト全体としての目標達成を目指します。「アジャイル開発」は、複雑性に富むプロジェクトを管理するための手法として高い評価を受けています。

　一方で、アジャイル開発の手法は、プロジェクトを遂行する側がコスト・品質・期間を一定の裁量でコントロールできないと実行が難しいという指摘があります。これは、予想よりも工数が膨れた場合、「コストを増やすか？」「作る機能を減らすか？」の判断を開発主体でやりくり出来ないと辻褄が合わなくなる、という指摘です。

　そのため、組織内でコントロールの効く、内製化を行っているプロジェクトではアジャイル開発は有用ですが、日本の多くの企業や行政システムの開発で行われている受託開発の体制では、契約面においてアジャイル開発を実行に移すのは難しいのが現状です。

　では、ITシステム開発の性質を踏まえた上で、問題プロジェクトを起こさないためには何が必要なのでしょうか。

　まず、基本に立ち返り発注者がその責務をしっかり負うことが大事です。上述した建設プロジェクトのように変動性の低いプロジェクトであれば、仕様を確定させれば、完工までのプロセスはおおむね「お任せ」しても、定点で確認すれば問題はおきづらいです。一方で、ITシステム開発を同じ感覚でとらえてはうまくいきません。しかしながら、開発はベンダーに「お任せ」となっているプロジェクトも少なくありません。そうではなく、発注者はITシステムを資産として有するオーナーの自覚をもち、受託者の報告や提案を評価し、開発・運用のフェーズを通じてITシステム全体をマネジメントする意識を持つべきです。

　また、受託者である開発ベンダーも、発注者側にも開発の状況を随時把握できるような手段を提供し、その上で、プロジェクト遂行上の課題・リスクが明らかになった際には、ITシステム開発のプロフェッショナルとして堂々と対策を提案できる矜持と技術力を持つことが重要です。そして、発注者・受諾者ともに、お互いの立場からプロジェクトの達成に向けて意見をぶつけ合い、協調しながらITシステム開発のプロジェクトを運営していくことが、問題プロジェクトを本質的に抑制することにつながると考えます。

　ITシステム開発においては、発注側の意図が最大限反映されるべきです。同時に、ITシステム開発は本質的に難しいものであり、遂行のためには開発力を持ったプロフェッショナルによる活躍が必要不可欠と考えています。つまり、発注者側と受託者側がプロジェクトの課題を随時把握・共有し、双方が納得のいく判断を積み上げることが、問題プロジェクトを起こさないための一番の方策です。

　このようなことを実践することで、たとえ受託開発の形態であっても、複雑性の高いITシステム開発に適応したプロジェクトマネジメント（PM）が行えるのではないでしょうか？