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

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

システム構築が抱える特殊性として「専門知識のない人が考える必要工数の肌感覚と、実際に必要な工数の乖離が大きい」ことを挙げました。
簡単な例を挙げますと、極めて初歩的なプログラミングの課題として「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問題よりも非常に複雑で、前提が曖昧で、ゴールが明確でない処理を大量に実装していくことになります。
この中で、同一システム内における各プログラム間であっても、見積もり時の前提が実情と異なっていて設計通りに実装ができず、関連プログラム間での仕様のすり合わせが必要になることは日常茶飯事ですし、連携する外部システム側の仕様が誤って伝わっているだとか、そもそも当該システム・外部システムともに現状仕様を誰も把握していない、ということも非常に頻繁に見られるケースです。
そのような中で、誤差が誤差を産み指数関数的に工数が膨らんでいく、というのがよくある炎上パターンでしょう。

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

>>>このストーリーの詳細・続きは以下のURLからご覧いただけます！

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