見積り時にはすでに失敗が見えている
国際的なプロジェクトマネジメント標準であるPMBOK（Project Management Body of Knowledge：プロジェクトマネジメント知識体系）では、プロジェクトの見積り精度について、以下のように示されていました。
建築業界では、ほとんどの工事は見積り額の-10～+10％に入るといわれており、多少誤差はありますがこのPMBOKの定義とほぼ一致していることになります（元々、ITのマネジメント技術の殆どは建築業界から模倣したものが多いので、当然と言えば当然ですが）。
これに対しシステム開発では、最終的にはどのくらいの見積り精度なのでしょう。
感覚値ですが、トラブルプロジェクトはいったん置いておくとして、おそらくは-20～+100％ぐらいになっているのではないかと感じています。元々不確実性コーンなどと呼ばれている図にもあるようにITプロジェクトは初期段階に近ければ近いほど、見積もりや計画制度は低くなるものです。
これは、そもそもプロジェクト初期の段階ではお客さま自身に明確なビジョンが出来上がっていないため、どうしても進行していく中で当初計画とのギャップが生まれ、その調整をするたびに見積もりや計画に影響が出やすい…という特性があるためです。
だからこそ計画を軽視し、プロジェクトマネジメントをその場の思い付きで実施するようなプロジェクトマネージャーもたくさん見かけてきましたが、そんな経験則だけを頼りにしたようなマネジメントは、どんなに成功を収めたとしてもあまりオススメはできません。
なぜなあお客さまの立場から見た場合、そのような個人の感覚や勘などに頼ったような進め方ではどうしても結果が出るまでギャンブルとなってしまうため、ビジネスの場において何千万、何億というお金を動かすには信用も信頼もしにくいという側面があるためです。
日本ではついつい
「結果よければすべてよし」
などという考え方をしがちですが、ビジネスにおいてはいかに不誠実であるか自覚しておきましょう。仮に結果が悪かった場合に、個人として責任が取れるというのであればかまいませんが、そうでないのであればお客さまにも企業にも、当然チームにも大迷惑をかけることになります。
では、さらに精度が上がらない理由をもう少し具体的に見ていきましょう。
機能の洗い出しが不十分
確定（正式）見積りを算出するため、あるいは実現性の高い計画を立案するには、プロジェクトで開発する「システムの機能」とその「難易度」が分からないといけません。
しかし、見積りを算出する段階であったり、プロジェクト初期に計画を立てる段階であったりするなかでそもそも機能要件や機能仕様はすべて明確になっているかと言うと、多くのプロジェクトにおいて残念ながらそれはありえません。
それらが明確になるのはクローズドクエスチョンができるようになり始めてから…すなわち設計書やモックなどが完成して、お客さまに見ていただけて、イメージが具体的に沸くようになってからです。
そうした仕様が明確でないのに見積りを提出しているとすれば、その精度はそもそも期待できなくて当然です。
見積り技術が確立していない
システム開発においては見積る人によって金額に倍の開きが出た、というような話をよく聞きます。
大まかな機能内容を見て、「エイヤ！」で見積もるなんていうのは乱暴このうえない話であり、人によって大きなばらつきが出るのは当然です。
見積手法や技法にもいくつかありますが、実際目にしてみるとほぼ大半のプロジェクトでは論理性はほとんど存在することなく、経験則と感覚にまかせた
類推見積もり
を採用しているプロジェクトは非常に多いのではないでしょうか。
PMBOKでは類推見積もりのほかにも４～５つほどありますが、仮に類推見積もりを用いない場合は、おそらくＦＰ見積もりを次点で採用しているところが多い気がします。これはこれで盲目的に採用しているプロジェクトはナンセンスと言わざるを得ません。
仮に要件定義や基本設計も終盤に差し掛かり、機能仕様が明確になって「これから請負契約で…」という際にはＦＰ見積もりもわかります。そもそも機能…functionがハッキリしているからこそ機能数や機能規模から機械的に見積もることができるわけで、機能仕様がはっきりしていないうちからＦＰ見積もりを採用したところで
「何も考えていません」
と自白しているようにしか見えません。
そしてそうしたバランスの悪さを隠すように、あるいはそうした盲目的な見積もりによって自分たちだけが被害を被らなくてもいいように、多少見積りがわかっている人はそれをプラス方向にブレさせるよう調整します。わかりやすく言うと「リスクを積む」といいながら"ぼったくる"わけです。この積む割合が大きければ大きいほど、見積りに自信がないことがわかります。
このような見積りをしている限り、見積り精度の向上は期待できません。
予備をきちんと確保しない
プロジェクト…中でもＢ２Ｂにおけるプロジェクトの特徴は、あらかじめ契約を結ぶところからビジネスが始まる都合上、
期限が決まっているという「有期性」
毎回違う仕事をするという「独自性」
絶対と呼べる回答が存在しないという「不確実性」
にあると言われています。
その中でも特にこの"独自性"が、プロジェクトのリスクの大きな要因となっています。
つまり、毎回同じ仕事をしているのであればだんだんと仕事にも慣れて失敗する確率を下げることができるのですが、プロジェクトは常に新しく、常に違う（100%同じにはならない）条件で開発をおこなうために、どうしても未知のリスクが発生する可能性があり、失敗する可能性がつきまとうのです。
このようにプロジェクトには常に何かしらのリスクが存在するため、それに対処するために何らかの準備・予備を用意しておく必要があります。
ところが、日本ではリスクマネジメントの考え方があまり定着していないために、このような準備や予備を上乗せすると、
「何を甘いことを考えているんだ。
そんなリスクは発生しないように頑張れ」
などといわれ、根性論に走らされるＩＴ企業やプロジェクトマネージャーも少なくありません。この点はＩＴ企業だけでなく、ＩＴを利用する"顧客"企業側も意識の改善が必要な部分になります。
しかも、このリスクに対する予備を「開発予算」としてお客さまに要求しようとするプロジェクトマネージャーなんかも存在していたりします。
これはおそらくリスクマネジメントの正しい行い方を知らないせいでもあるのでしょうが、本来そうした予備費はお客さまの予算の中で捻出しておいてもらうだけのもので、いざとなったときにお客さまの懐から出していただくようにしなければなりません。
そうしないと、一度契約の中で開発予算の中に組み込んでしまうと、実際にリスクが顕在化しなかった場合でも、ＩＴ企業はお客さまに予備費を請求することになってしまうからです。
リスクが顕在化しなかった場合、何もしていないのに請求だけ行うというおかしな図式が成り立ってしまいます。
本来、このような方法は（お客さまが自覚しているしていないに関わらず）よろしくないのですが、ＩＴ企業の多くは利益率が高ければ手放しで褒め称え、評価し、あわよくば出世させようとする経営者も多いため、こうしたモラルに反した見積もりをあえて実施しようとするプロジェクトマネージャーや管理職などもちらほらいたりします。
ＩＴ企業に依頼をする際には
コンティンジェンシー予備費などを考慮に入れているか
コンティンジェンシー予備費をだれの懐で管理させるか
この２点をきちんと明確にしてもらうといいでしょう。
この時、考慮に入れていないＩＴ企業であれば見積もり技法が未熟な可能性もあるためトラブルに発展したり、スケジュールやコストがコロコロを変更されるリスクを負う懸念や心配をした方がいいでしょう。
考慮に入れたうえで自分たちの懐にしまおうとするＩＴ企業であれば「カモ」にされているだけかもしれません。お客さまの利益や適正なビジネスよりも自分たちの収益に重きを置いている証拠です。「それでも予算的に困らない」という場合を除いては、今一度ベンダー選定をやりなおすか、今後の選定方法を改めたほうがいいかもしれません。
ちなみに、ここでいう予備費、あるいはコンティンジェンシー予備費というのはPMBOKなどで用いられている言葉ですが、企業によっては「バッファ」「リスクバッファ」などの用語を使っているところもあります。基本的に意味は同じですが、こうした
「何が起こるかわからないうえで、
何が起こってもいいように、多少膨らむ可能性を考慮して
あらかじめ多めに予算を取っておく」
というのは間違いなく検討しておかなければなりませんし、検討したうえで予算を確保しておくのであれば「お客さま側」の財布で確保しておいて、いざという時にお客さまの予算から捻出できるようにしておきましょう。
「限定的な用途しかない」「既存システムへの改修が中心」の場合であれば、ベースとなる工数の２割弱ほどあれば問題ないでしょう。しかし「システムそのものを刷新する」「基幹システムを大幅に変える」場合、また事業全体から見れば限定的な用途しかないシステムであっても「大幅に技術要素が変更される」場合には３割から多い時には５割ほど積んでおいたほうがいいかもしれません。
経費削減の優先度が高い場合はご注意を
特にわかりにくいのは「大幅に技術要素が変更される」場合です。
お客さま側のなかでなんとなく上からのお達しによって「できるだけ安く」というニーズ優先度の高いケースがあったとします。そういった用件をＩＴ企業側に伝えると、場合によっては既存パッケージやローコード（ノーコード）開発ツールなどを紹介してくるケースがあるのですが、こうしたブツの大半はメーカーが海外企業です。
それを日本で広めたい、日本での実績を増やしたい、そうすることでコスト面での競争力を強化したい、etc.といった思惑があってＩＴ企業側も推してくるわけですが、これが非常に曲者です。
そもそも、こうした
「半自動化によってコストを抑えられる代わりに
ニッチな要望には応えられないツール群」
と日本企業のニーズは親和性が低いのは昔から言われている特徴の１つです。その証拠に、MADE IN JAPANでこうした有名なツールというのはごくごく限られていますし、有名といってもシェアはほとんどないのが実情です。
欧米を中心にこうした半自動化が可能なツール群が普及しているのは、欧米の企業では自社の独自性を主張しすぎて人材のパフォーマンスを落とさせることを嫌う背景があるからです。
とくにアメリカでは従業員の転職率は日本の４～５倍あるといわれています。
出ていく社員のことよりも、入ってくる社員に即パフォーマンスを出してもらいたいのであれば入社後にいろいろ勉強しなければわからない手間を省かなくてはなりません。そのために、どの企業もコアコンピタンスが求められる技術要素以外についてはできるだけグローバルスタンダードなものを選びます。そうすることで
社員は、転職しても新しい職場で即これまでのノウハウが活かせる
企業は、人の入れ替えがあっても業務効率（=業績）が落ちない
仕組みが構築できるわけです。そのため、こうした半自動化ツール、全自動化ツールなどの普及が促進されますし、それによって作成されたシステムにむしろ慣れているので不満がありません。
一方で日本の場合は、自社のオリジナリティを主張し、システムを導入する際には「いかにして自分にとって都合がいい形となっているか」に重きを置きます。そのため、
仕様を決める人にとっては都合がいいけど、実際に使う人たちの評価は別
グローバルスタンダード化された標準のＵＩでは味気がないと感じてしまう
等によって、自分たちのビジネスモデルを標準に合わせるのではなく、次から次へとツールでは実現できないニッチな要求を突きつけるようになります。結果、こうしたローコードツールやノーコードツールを導入すると「想定よりも費用が膨らんでしまう」「想定よりもスクラッチ（人の手による開発）をしなければならない領域が増える」等によって問題が起こるケースも増えていきます。
特に、こうしたツール群はプロジェクトマネージャーやリーダーの一部だけが中身を理解していても、プロジェクトメンバーの多くはほとんどが素人だったり、仮に経験者だったとしてもツールの中身まで理解しているわけではないため、カスタマイズやスクラッチ領域との連携となった瞬間、恐ろしく品質が低下することも珍しくありません。
こうした背景は、ＩＴ企業にシステム構築を依頼するお客さま側にもご理解いただけるよう、本来はＩＴ企業側から提案時にご説明するべきなのですが、案外ＩＴ企業側の管理職層や営業の方もそういったことはご存じないし、そのレベルの方々はやはり自社の収益や自身の功績などを中心に考えるため、こうしたネガティブな情報を提供してくれることはまずないといってもいいでしょう。
見積りの数字的な欠陥
「定常作業のタスクのコストや納期のばらつきは正規分布に従う」といわれます。
これに対して、プロジェクトのタスクのばらつきは、ベータ分布または三角分布に従うといわれ、原則として左右非対称になります。
この分布の平均は最頻値よりも大きくなります。
従って、この最頻値を積み上げた"見積りや計画を順守できる確率"は50％以下と言うことになります。実際にはこの最頻値を積み上げた見積りが守れる確率は10～15％程度といわれています。いくら契約を先に取り交わさなければならず、そのなかで期限や金額を決定しておかなければならないとはいえ、実はかなりギャンブル要素が強いんですよね。
つまり、スケジュール的／金額的予備を一切考慮しない最頻値を使った通常の見積りをしているとすれば、それは10～15％程度しか守れる見込みがない見積書を作っていることになることを覚えておきましょう。
ＩＴ企業側に見積りや計画を遵守する自信がよほどあった場合でも、70%になることや90%になることはありません。こればかりはお客さまの都合というものがあって、それにより変更を余儀なくされるケースが生じるためです。
そういう意味では、金額の高い／安いや提案内容それ自体よりも、いえそれと同じくらいには
「計画実現性の高さ」
「リスクに対する姿勢」
というものをチェックされておいたほうが賢明です。具体的には
見積り根拠となる計画に具体性が伴っている
その具体的な計画のクリティカルパスが考慮されている
変更管理プロセスが考慮されている
リスクマネジメントあるいはそのプロセスが考慮されている
変更管理にかかる予算を確保するようお客さまに明示している
等を明示しているＩＴ企業であればリスクも低くなるのではないでしょうか。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。