ITシステム構築プロジェクトの勘所

昨今、DXに対する意識の高まりも背景に、企業活動においてなんらかのプロジェクトを立ち上げる際には、システムの構築であったり、ツールの導入であったりを伴うケースが大半です。
しかしながら某メガバンクの例を挙げるまでもなく、ツールの導入やシステムの構築プロジェクトには、大なり小なり炎上の影がつきまといます。
今回は、システム構築を伴うプロジェクトにおいて、炎上を避けるための勘所についてご紹介します。

ソフトウェア開発の特性

そもそも、システム構築の特殊性とはどのようなところにあるのでしょうか？
筆者個人の考えにはなりますが、

• 専門知識のない人が考える必要工数の肌感覚と、実際に必要な工数の乖離が大きい
• 専門知識があっても工数の見積もり自体の誤差が大きい

の2点が大きいのではないかと思います。次項以降で詳しく解説していきます。

必要工数の肌感覚との乖離

システム構築が抱える特殊性として「専門知識のない人が考える必要工数の肌感覚と、実際に必要な工数の乖離が大きい」ことを挙げました。
簡単な例を挙げますと、極めて初歩的なプログラミングの課題として「FizzBuzz問題」というものが知られています。その課題の内容は以下のようなものになります。

1から100まで順に数を数え上げていき、3の倍数なら「Fizz」、5の倍数なら「Buzz」、両方の倍数（15の倍数）なら「Fizz Buzz」、いずれでもなければその数を出力するプログラムを作成する。

（そういえば、「3の倍数と3が付く数字のときだけアホになる」芸人の方がいらっしゃいましたね）
この記事をご覧の方でしたら「なんだ、簡単な問題じゃないか」と感じることでしょう。
実際、人間がやる分には初歩的な算数の問題ですから、非常に簡単です。
しかしながら、この問題をプログラムとして実装する際には
「まず“1”という入力に対して判定を行う。
もし“1”が15の倍数であれば“FizzBuzz”と出力して次の処理に進む。
15の倍数でなければ、5の倍数かどうか判定を行う。
もし“1”が5の倍数であれば“Buzz”と出力して次の処理に進む。
15の倍数でも5の倍数でもなければ、3の倍数かどうか判定を行う。
もし“1”が3の倍数であれば“Fizz”と出力して次の処理に進む。
15の倍数でも5の倍数でも3の倍数でもなければ、“1”と出力する。
入力の“1”に1を足して最初に戻り同じ処理を行う。
100に達するまで順次繰り返す。」
といったような内容を、プログラミング言語で記述することになります。

なんとなく、想像していたよりも3～5倍くらい面倒に感じるのではないでしょうか。
また、FizzBuzz問題であれば「3の倍数」「5の倍数」「3と5の両方の倍数（15の倍数）」に対して判定を行えばよい、ということは自明ですが、実際のシステム構築の際には、このように行うべき処理が自明であることは稀です。言うなればその前段の、「FizzBuzz問題のように、MECEな条件で簡潔な問題を定義する」部分から検討し、実装を行う必要があり、工数はより膨らみます。

さらに、仕様の検討～実装だけでなく、実装したプログラムのテストも非常に重要です。
今回のFizzBuzz問題の例では「1～100の数字」と前提条件が固定されていますが、実際のシステム構築では前提条件から仕様化し、テストを実施する必要があります。
1～100の範囲では正常に動作したけれども、これが負の値の場合は？0だったら？そもそも何桁までの数字であれば正常に扱うことができるのか？数字ではなく文字が入ってきたら？全角の場合は？などなど、検証しようと思えばほとんど無限に検証項目を列挙できるでしょう。
このように条件を積み重ねていくと、肌感覚と優に10倍以上の乖離が出ることも珍しくはありません。
これが「現在の業務フローを洗い出し、不要なプロセスを削って標準化するプロジェクト」であれば、現在の業務フローに精通していない人の肌感覚であっても、さほど大きな乖離は出てこないのではないかと思います。（それでも2倍～5倍程度の乖離はざらに有り得ますが……）
専門知識の有無による、肌感覚の大きな乖離は、システム構築系プロジェクトが持つ特殊性ではないかと考えています。
（筆者の経験ですが、過去在籍していた会社で「Googleカレンダーのような機能を実装したい。あんなものは無料で使える簡単なアプリだから、そっくり真似すれば50万円くらいで作れるでしょう？」と相談を受けて頭を抱えたことがあります。実際に作ろうとすれば軽くその10倍～100倍はかかります。）

工数見積もりそのものが抱える誤差

前項では、専門知識のない方が肌感覚で考える必要工数と、専門知識を持った人の考える必要工数で、大きな乖離が発生する、という点をご説明しました。
実際のシステム構築系プロジェクトにおいては、通常構築を担当するベンダーの技術者によって（場合によっては設計と並行して）工数見積もりが行われることになります。
しかしながら、この見積もりもかなりの誤差を抱えています。これが、システム構築における特殊性の2つ目です。

前項でFizzBuzz問題を取り上げましたが、実際のシステム構築においては、このFizzBuzz問題よりも非常に複雑で、前提が曖昧で、ゴールが明確でない処理を大量に実装していくことになります。
この中で、同一システム内における各プログラム間であっても、見積もり時の前提が実情と異なっていて設計通りに実装ができず、関連プログラム間での仕様のすり合わせが必要になることは日常茶飯事ですし、連携する外部システム側の仕様が誤って伝わっているだとか、そもそも当該システム・外部システムともに現状仕様を誰も把握していない、ということも非常に頻繁に見られるケースです。
そのような中で、誤差が誤差を産み指数関数的に工数が膨らんでいく、というのがよくある炎上パターンでしょう。

建設現場に例えるのであれば、地中のガス管・水道管や、地下水果ては地下鉄のトンネルに到るまで、誰も詳しい所在を把握できていない状態から工事が始まり、基礎工事のために杭を打てばガス管が破裂し、穴を掘っていったら地下鉄のトンネルに穴を開け、事前の設計通りに部屋を作ったものの廊下にも外にも繋がっていない孤立した開かずの間が大量に作られ、工事中に毎日足場が崩落する、というような世紀末的プロジェクトが、システム構築においては日常と言えるのです。

QCDコントロールでうまくいく？

システム構築を成功させるためには、QCDのコントロールが重要、という話はよく聞かれます。
QCDコントロールとは、
Q=Quality（品質）
C＝Cost（費用）
D=Delivery（納期）
の頭文字を取ったもので、すなわちこの３つのバランスを上手く取ることが大事、という教訓です。
しかしながら、ここにも落とし穴が潜んでいます。

そもそも、システム構築プロジェクトにおいて、一定以上に品質を下げる選択肢を取ることは困難です。

コストと納期を重視するから、FizzBuzz問題で言えば“Fizz”の部分は上手く動いていなくても良いや、とはならないでしょう。品質を疎かにすれば情報漏洩など、節約したコストを簡単に上回るほどの負債を生むことは想像に難くなく、またコストと納期には糸目を付けないからとにかく品質を向上させる、という選択ができるプロジェクトもまず存在しないことから、実際には品質は固定とならざるを得ません。

また、コストはどうか？と言えば、こちらも基本的には固定でしょう。当初の想定よりも工数が膨らみそうだから、費用を2倍払ってくださいと言われて素直に払う顧客は存在しませんし、逆に当初想定よりも実装が簡単だったので費用は1/2で良いですよ、と言ってくるベンダーもいないでしょう。もしそのような奇跡的な場面が発生したとしても、顧客から見てもではその分の費用で別のことをやってください、となるのが普通です。

では納期は？といえば、システム構築プロジェクトの特殊性としてご説明したように、そもそも開始時点から無理のあるスケジュールでプロジェクトが走り始めることが通常です。ですので、納期は伸ばすことはできても縮めることはできないものと捉えるのが自然です。

結論として、得られる効果に対してQ×C×Dの掛け算の値が小さくなるほど費用対効果は高くなるわけですが、実際のところは
Q（固定）×C（固定）×D（増えることはあっても減ることはない）
ということになります。そもそもQCDのバランスを取りコントロールする、という発想自体が絵に描いた餅である、というのが現実です。

システム構築プロジェクトを炎上させないためには

それではシステム構築を成功させるために何ができるか、と言えばこれは実装を進める前の事前準備に他なりません。
つまり、そのシステムを構築することによりどんな効果を得たいのか？という、本質的なゴールを明確に定義することが必要です。
また、ゴールを明確にすると同時に、実現すべき要件についても、明確な優先順位を付ける必要があります。
「ファーストステップでの実装スコープの要件は全て最優先、何一つ落とすことはできない」というような例を見かけることは多いですが、本当にすべての要件が実装必須、という場合であればコストもしくは納期の面では妥協をせざるを得なくなります。
明確なゴールを定め、その実現に絶対に必要な要件のみを最優先とする、という整理をまず行うべきで、個人的には最優先の要件は実装スコープ内の要件のうち1/10～1/5程度まで厳選することが望ましいのではないかと考えています。

また、優先順位を付ける上では、当然のことながらその要件の実装にかかるコスト・工数も無視することはできません。
ゴールに到達するための重要度は高いものの必要工数も大きい要件1つに対し、重要度としては1段落ちるものの同時に実装することで同じ工数で要件を2つや3つ実装できる、となれば費用対効果を考え後者の要件を実装優先度は高く設定する、というような判断も重要になりますが、このような判断を行うためにはどうしても専門知識が求められます。

システム構築系のプロジェクトは、企業活動において昨今非常に大きな割合を占めるようになっていますが、システム構築・ソフトウェア開発そのものの特殊性もあり、専門知識を持った人員の参画は必須となります。
一方で、企業におけるシステム構築系プロジェクトを成功させるためには、明確な優先順位の設定と、そのそもそもの前提となる、システム構築の目的であるビジネスゴールの定義も必要不可欠で、どちらか一方が欠けてもプロジェクトの成功確率は大きく下がってしまいます。
自社で技術面・ビジネス面の両面を推進できる人材がいればそれに越したことはありませんが、もしそのような人材が不足しているようでしたら、システム構築における専門知識・戦略も含めたビジネスコンサルティングの両面において高度な知見を持ち、豊富な実績のあるファーストデジタルに是非ご相談ください。