こんにちは！
PRIME ORDERの内藤です。
IT、とりわけシステム開発業界というのは、他の業界と比べて発注側と請負業者（ITベンダー）間のトラブルが多い業界です。
わたしたち自身が発注側のみなさんとトラブルになったことはありませんが、それでもこの問題にはとても詳しいです。
なぜなら、「現在のITベンダーとうまく行かず頓挫中の（あるいは頓挫した）プロジェクト」の引き継ぎをご相談いただくケースが非常に多いからです。そうしたご相談の中でわたしたちは、どのような経緯でITベンダーとトラブルになったのかを具体的に聞き取りし、その傾向について分析を重ねてきました。
この記事を読んでいただいている方の多くが、これからシステム開発をITベンダーに発注しようとしている、あるいは既に発注しているプロジェクト担当者・責任者だと思います。
みなさんに向けて、システム開発ではどうしてそんなにトラブルに発展しやすいのか、実際に発生した具体例を引用しながら解説します。
発注者のみなさんがITベンダーとトラブルになるのは、大きく分けて以下の３つのケースです。
１：予定の納期になってもシステムが完成しなかった
２：完成したシステムがバグだらけで使い物にならない
３：運用に必須の機能が実装されていない
およそ上記３つのいずれか、あるいは悪いときにはこれらが複合的に発生します。
いずれの場合も、発注者の皆さんは「約束と違う」「期待通りじゃない」と裏切られた気持ちになると思います。悪質なITベンダーに騙された、という感想を赤裸々に語られる発注者の方を何度も見てきました。
たしかにITベンダー側に問題があることは多いです。
人材不足が深刻な業種ですから、経験の足りないエンジニア、いわゆるジュニアエンジニアに開発を担当させるITベンダーも少なくありません。やっているふりをして全然仕事をしていないITベンダーも、残念ながら存在します。
しかし今回は、そうした「ハズレ」を引いた、という話以外で生まれるトラブルのからくりを解説します。
約束とはなにか
「約束と違う」「期待通りじゃない」。この、”約束”や”期待”というものは一体どういうものでしょう。
システム開発プロジェクトというのは、発注者のみなさんの頭や心の中にある「こうあるべき」「こうであってほしい」という、ITシステムに求める大小様々な想いが出発地点です。その思いをITベンダーが汲み取ってシステム開発が動き出します。
みなさんの頭や心の中にある想い、という表現から分かる通り、そのままでは曖昧すぎますよね。ですから、多くの場合それらの想いを発注者側で資料にし、そこから要件定義書（システムが満たすべき機能を整理した文書）という形で言語化を行います。
この要件定義書の内容を実現することをITベンダーが”約束”して、みなさんはシステムの完成を”期待”して待ちます。
つまり、発注者とITベンダーとの間で交わされる”約束”とは”要件定義書”のことになります。・・・一般的には。
要件定義書のないプロジェクト
興味深いのは、”要件定義書が存在しないプロジェクト”も実のところたくさんある、ということです。つまり、発注者側が提示した資料や説明に対して、ITベンダーが見積書だけ作成し、それを元に開発が始まるというケースです。
この場合の約束とは、”見積書”ということになります。ですから「提示した資料や説明」の内容が「ITベンダーが作成した見積書」に、齟齬なく網羅されているかチェックするのは発注者のみなさんの責任です。ところが、見積書の多くは文字数の少ない簡素な内容の割に技術ワードが散りばめられていて、一体何のことを言っているのか、各機能がどこまでを想定しているのか、わかりづらいことがほとんどです。
大抵はここで、ある程度の質疑はするものの、最終的にはITベンダー側の窓口担当者（営業もしくはプロジェクトマネージャー）の人柄、もしくは企業ブランドを信用して、発注が取り交わされます。
「運用に必須の機能が実装されない」というトラブルの入口が、ここにあります。そもそも見積書に必須機能の記載そのものが欠落している、というケースもあります。ですがそれより多いのは、記載はされているが”想定がだいぶ甘い”あるいは”見当違い”、というケースです。出来上がったものを見た発注者が、「そもそもこの仕様では業務で使えない」と伝えると、ITベンダーからは「見積書で想定した仕様はそこまでのものではない」という返答。
”見積書で想定した仕様”は、見積書に明確に書かれていません。つまり、ITベンダーの頭の中という、みなさんからすると圧倒的に不利な保管庫にあります。
元々みなさんの頭の中にあったシステムにかける想い。それが明確な言語にされることなく、ITベンダー側の頭の中の想定でシステムが組み上がって行くのです。
両者の頭の中身が一緒という奇跡が起きなければ、ゴールが大きくズレてトラブルになるのは当然です。
”要件定義書”は銀の弾丸か
だから、要件定義書が必要なんだ、よし作ってもらおう。
そう思うかもしれませんが、ちょっと待ってください。残念ながら、要件定義書にも落とし穴があります。たしかに要件定義書は、前述の見積書に比べたら詳細に書かれています。内容も、みなさんが理解・把握しやすい内容になっていると思います（そのように作成するのが要件定義書ですので）。
要件定義書をITベンダー側に作成してもらった場合、一見格好いいのだけどなんだか難解なものが上がってくることがあります。AWSアーキテクチャ全体図や運用監視体制、ジョブスケジュールなど。なんのことかわからないけど、何やら必要らしい。そんな内容にたくさんのページが割かれている場合は要注意です。ITベンダーには、格調高い要件定義書を作成するプロがいます。しかしその作業の実態はほとんど別プロジェクトからのコピペです。みなさんの事業や業務の固有事情からシステム要件を書き出す部分が要件定義書のメインですが、よくよくみるとメインたるそのページには、前述の見積書と大差ない、簡素で想定が分かりづらい内容。そのような要件定義書を約束に開発を進めるのは、見積書で約束しているのと変わりません。
みなさんが理解・把握しやすい内容でなければ要件定義書ではありませんので、その点は注意です。
しかし、です。
完璧な要件定義書がある前提での落とし穴が、本当にお話したいことです。
要件定義書を作成した時点ではどうしても書ききれなかった、隠れた要件、気づけなかった問題点というものは、必ずあります。
ITシステムというものは大変複雑なものなので、実際に開発をする前にすべての問題点を洗い出すことは困難です。
たとえば、要件定義書に
「A1-1-1 ◯◯と◆◆という条件に該当するデータを抽出する」
という記述があったとします。ところが、実際にエンジニアが実装してみたら、演算処理が重すぎて応答に５分以上かかる、あるいはタイムアウトしてエラー終了してしまうことがわかった、などということはよくあることです。つまり、実装を開始した後になって新たな要件や問題点が浮かび上がってきた、ということです。
「A-100-1-1 要件A1-1-1で素早く検索できるよう、◯◯と◆◆という条件に該当するデータが登録されたら、その時点で検索のインデックスにできるマークを記録する」
ITベンダーのエンジニアからそんな要件の追加（つまり追加費用、納期の延期）が告げられます。
ITベンダーと交わした約束は”要件定義書”です。発注側はこう言います。
「A1-1-1 ◯◯と◆◆という条件に該当するデータを抽出する」
と書いてあるのだから、ITベンダーはそれを満たすものを開発する義務がある、と。
ITベンダーは言います。
「A1-1-1の前提となるデータ量について要件定義書に記載はない。実際のデータ量は我々の想定を超えていたので、これはシンプルに物理的な限界を超えている。この課題をクリアするには、要件の追加定義が必要だ」、と。
こういうつばぜり合いが始まると、時間と費用が無駄にかかり、かつ発注側とITベンダー側の関係が険悪なものに変わっていきます。
要件定義書に”非機能要件”として各データ量の想定を書くこともあります。しかし、実装してみてはじめて”書くべきだった”と気づいたことを、実装前に書くことはできないんですよね。今回はデータ量というテクニカルな側面でお話しましたが、そうでないケースもあります。
たとえば、「α版（仮組み）のシステムを現場のユーザーに触らせてみたら、△△という項目を入力する場所がないですよ、という指摘がありました」というようなケースです。現場のユーザーは忙しいので、開発前に文字だらけの要件定義書をくまなくチェックしてくれることはほとんどありません。でも、実際に出来てきたシステムのチェックは、それこそ親の仇を探すように行ってくれます。
あなたは猫なで声でITベンダーにお願いをする羽目になります。「なんとか、当初予算、期間内で対応してくれませんか」、と。
「わかりました、対応します」、最初のうちはITベンダーも融通を利かせてくれることも多いです。でも、プロジェクト後半になってくると、ITベンダー側の態度も変わってきます。遅れずに不具合のないシステムを完成させる”義務”に集中していて、あなたの相談を聞いている余裕がないからです。加えて、このころはスケジュールの遅れや不具合の多さなどについて、あなたからの”お叱り”が増えていて、ITベンダー側との空気が冷えていることも多いのでなおさらです。
プロジェクト終盤、現場のユーザーチェックでの指摘事項、追加要望などがリストに積み上がってきた時期に、発注側とITベンダーの思惑・立場に大きなギャップができます。
要件定義書には書けなかった調整や追加を実現したい発注側と、あくまで要件定義書に書かれた内容だけに執着するITベンダー。
この先に待つのは、「運用に必須の機能が実装されていない」というトラブルです。
発注側としては、背に腹は代えられない状況。追加の費用とスケジュールを工面せざるを得ません。もし、そういう隠れた要件が他にもたくさんあったら？みなさんにとっては大変不都合な事実をお伝えしますが、そうした隠れた要件は、たくさんあるというのが通例です。
ITベンダーの忠誠心
もちろん、プロジェクト終盤の時期になっても常に寛大？忠誠心が高い？ITベンダーもいます。あなたから、要件定義書にも見積書にも記載のない機能の相談を受けて、ITベンダー側の窓口となる担当者がこう言います。
「それは絶対にやらないといけないことですよね。わかりました、やっておきます！！」
こういうITベンダー担当者、好きになっちゃいますよね。要件定義書という頭の硬い形ではなく、まごころというのでしょうか、忠誠心という形であなたとの間のあいまいな約束を果たそうとしてくれます。
そうか、ITベンダーとの間に交わす約束というのは、担当者のまごころのことか。
これはとても惜しいんですが、実はそれだけでは完全ではありません。担当者だけでは、足りないんです。その後の展開を見ていきましょう。
その彼（あるいは彼女）は、その日の夕方、オフィスで開発中のエンジニアの手を止めさせて、会議室に集めてこう言います。
「クライアントが困っているので、追加でこの機能の実装をやることになった。この件で追加スケジュールはもらえないので、各自残業や休出などで工夫して業務にあたるように。」
こんなことが１度だけならどうってことはありません。でも、忠誠心の高いその人は、１度ならず２度３度と、あなたの無理を聞いてくれます。まるでそのことが自身のストロングポイントだと言わんばかりに。
そんなことが繰り返される日々。実際に開発をしているエンジニア側の気持ちを想像してみて下さい。「こういうレイアウトにしたほうがユーザーは使いやすいかもしれないから提案してみよう！」というポジティブな気持ちは萎れ、「形だけ仕上げて早く帰りたい」というネガティブな気持ちに支配されます。そうしたやらされ感というのは、確実に生産性に影を落とすのです。
もちろん、発注側には悪気はありません。まさかそんな影響が出るなんて、と思いますよね。でも、この先に待つのは次のトラブルです。
「完成したシステムがバグだらけで使い物にならない」
あるいは、エンジニアの深夜残業、休出の常態化により、エンジニアのダウン、辞職による欠員（今のエンジニアはより良い会社に簡単に転職できます）で開発チームが崩壊するという話もよく聞きます。ITベンダーとしては、開発を続けないといけないので、手近なところで調達できてかつ、赤字にならない単価のジュニアエンジニアを調達して開発を再開します。が、通常それは開発ではなく破壊（ジュニアエンジニアの多くは、すでに完成していた機能に、意図せずたくさんの致命的な不具合を仕込んでいきます）の日々なのです。
つまり、
「予定の納期になってもシステムが完成しなかった」
というトラブルにつながります。ひどい場合には、
「永遠にシステムが完成しない＝デスマーチ」
となることも。
窓口となる担当者だけと話をしていると、とても上手く行ってるように思えるため、問題が進行していることに気づけません。そのため、このパターンはとても怖いケースです。わたしたちが聞き取りをしている中でも、このパターンでのトラブルはかなりの数だと感じます。
窓口担当者がまごころを持つ、というのは決して悪いことではないです。問題は、そのまごころを開発チームと共有できていなかったことにあります。
まとめ
結局、ITベンダーとどのような約束を交わすべきでしょうか。
内容の薄い見積書での約束は危険。
要件定義書での約束は、隠れた要件や問題、状況の変化に対応できない上、プロジェクト終盤で発注側と受注側の心が離れていき、約束の解釈を巡って対立が始まります。
ITベンダー側の窓口担当者の忠誠心に頼る方法は、ITベンダー側の開発チームを破壊し、ひいてはプロジェクトを破滅に追い込みます。
ではどうするべきか。これには明確な回答を記したいと思います。
ITベンダー側の窓口担当者だけでなく、開発チームを含めた全メンバーに、まごころを持ってもらうこと、です。全メンバーがやらされ感の下で作業をするのではなく、あなたの想いに共鳴し、自分ごととして能動的に動く。そうすれば、発注側と受注側でトラブルに発展することはありません。
それはそうだろうけど、そんなのはITベンダー側の事情であって発注側はどうしようもないんじゃ？
そう思うかもしれません。
でも、鍵を握っているのは発注側なんです。
ITベンダーと、次の約束を交わしてみて下さい。
「このプロジェクトにかけるわたしたちの想いを理解・共感し、全員が能動的に動く開発チームを提供すること」
そのまんまですね。
そんなのじゃ、ITベンダー側はどうとでも言える、口約束の域をでない危ういものと感じるかもしれません。
しかし、システム開発業界には、
「クライアントの、プロジェクトにかける想いを深く理解して共感し、チームメンバー全員が自分ごととして熱意を持って能動的に動く開発手法」
があるんです。その名前は、アジャイル開発、です。つまり先程の、ITベンダーと交わしたいたった一つの約束とは、”純然たるアジャイル開発チームを提供すること”、と同意になるんです。
いったいアジャイル開発とはどんなものなのか。
そちらは別の記事にて解説をさせていただきますが、今すぐ知りたい、という場合にはぜひお問合せフォームからご連絡をください。詳しくご説明をさせていただきます。
この国のITシステム開発プロジェクトの失敗が、少しでも減ること。
あなたのプロジェクトが無事成功裏に完了すること。
そのことを願って、この記事の結びとさせていただきます。