ITプロジェクトの発注関係に潜む裏切りと罠
※ 2022年12月22日に闇のIT営業勉強会の第二回を行った。本記事はそのレポートである。
↓ 「闇のIT営業勉強会」自体の紹介はこちら
今回は、LT（Lightning Talk）形式で、3名の参加者から発表いただいた。3名のうち2名はIT系の受託開発会社の社長であり、残りの1名は受託開発会社に勤めていたITエンジニアである。
今回の発表の主な内容は、IT系受託開発会社としてプロジェクトを受託した際の体験談であり、発注者との間で起こるコミュニケーションの失敗がメインの話題となった。
今回は、IT系開発会社の内部の人間からの報告に耳を傾けることで、「発注」という行為の難しさについて考えてみたい。
報告1: 闇のブロックチェーン・プロジェクト
まずは、非常に典型的な闇プロジェクトの話題から紹介しよう。
参加者の樫野氏（仮名）から、ある受託開発会社の開発チームに属していた頃に経験した、ブロックチェーン系の闇深いプロジェクトの経験談が寄せられた。
具体的な固有名詞や金額も出てきて、非常にディティールが面白い報告であったが、本レポートでは詳細を語れないため、発表内容をかいつまんでお送りしたい。
クライアントと開発チームの情報の断絶
今回樫野氏によって報告された事例は、「開発チームが認識していた技術的課題を、営業が、クライアントである運営会社に対して意図的に報告していなかった」というものである。
クライアントの運営会社は、ブロックチェーン技術を組み込んだ新規サービスを立ち上げようとしていたが、社内には、ブロックチェーン技術に詳しい人間がいなかった。そのため、発表者の所属する受託開発に依頼が来た。
しかし、開発者チーム内では、依頼されたシステムが、プロジェクト開始前から実用に載せると破綻するシステムであることは分かっていたという。（樫野氏は、「なんでこんな仕事受けてきちゃうの〜！？」と思ったそうだ。）
そのため、開発チーム内では、プロジェクト開始の時点で、クライアントにとってちゃんと役に立つシステムを作ろうというモチベーションは失われており、まだ使われていない最新の技術を使ってみることなどに熱意が向けられていたという。（趣味プログラミングと揶揄する声もあったそうだ）
具体的には、処理スピードの問題があったという。パブリック型のブロックチェーン技術を用いた取引は、一般的なシステムに比べ、高速取引に向かない。具体的には毎秒数件程度の取引しか行えない。テスト環境では動作するものの、数万人が利用するようなサービスになると、この点が課題となる。
開発チームに所属する樫野氏は、プロジェクトの責任者である営業に報告したものの、営業はクライアント企業には報告しないことを選んだそうだ。
樫野氏が「なぜ問題を報告しないのか」「なぜリスクを過小報告するのか」と尋ねたところ、
「いやいや、今伝えたらこっちの立場が悪くなるじゃん」
「どうせこの後、お客さん都合で要件変更が起こるんだから、その時にバーターとして開発リスクを小出しに伝えるから今は言わなくて良いんだよ」
「リスクを予防するよりも、リスクを顧客判断で後回しにさせた方が、あとでリスクが発現した時に、追加で開発費用が取れるでしょ」
との回答が得られたという。
本プロジェクトは、人月で開発チームを貸し出し、月ごとに開発費用を精算する形式だったそうだ。納期については「お互いの信頼に基づいて任せる」形だったとのこと。なお、開発チームは数名で、1人あたり月額約200万円だったそうだ。これはブロックチェーン技術のエンジニア費用としての特別価格だったそうだが、チームの中にブロックチェーンの専門家は1人しかいなかったとのこと。とはいえ、クライアント企業の中にもブロックチェーン技術に詳しい人が存在しないため、バレなかったとのことだった。
なお、この受託開発会社ではクライアントとのコミュニケーションは営業とPMが統括しており、開発チームは意図的にクライアントとは直接コミュニケーションを取れないようにされていたという。
最終的には、この開発チームは内部の人間関係の悪化によりメンバーが一斉退職し、受託開発会社はクライアントから契約を切られてしまったそうだ。樫野氏もこの受託開発会社を退職したため、その後は風の噂にしか知らないという。
解説1：「発注」という行為の難しさ
このストーリーには、「発注」という行為の難しさが詰まっている。ここでは2つ指摘しておきたい。
1. 発注-受注の間の知識の格差
クライアントである運営会社は内部にブロックチェーンについての専門知識を持つ人間がいなかったから、樫野氏が所属する受託開発会社に発注することになったし、実際は開発チームの中にブロックチェーンの専門家は1人しかいなかったにもかかわらず、そのことを見抜けなかった。
知識の格差は発注という問題系における基本のジレンマの一つである。発注者は、知識がないから誰かを頼りたいのだが、知識がなければ発注先の成果物を正しく評価できない。
知識の格差の問題は、IT業界だけのものではない。例えば、医学領域であれば、「あなたの病気は今の医療技術では治療不可能で、治りたければ1000万の先進医療を受ける必要があります」と医師に宣告されれば、医学に詳しくない患者はそれが正しいかどうかを判断できないだろう。そのため、医学の領域では、医師を国家資格化し、医療サービスの価格を統一している。
しかし、ITの領域においてはこのような仕組みはない。特にブロックチェーン技術のような新興の知識領域では、ブロックチェーンの専門家かどうかを判断できる人は限られている。クライアントは成果物や人材の正しい評価ができない以上、「専門家」が言った価格をそのまま信じるしかないケースがある。
2.契約形態と責任範囲
本件で営業は「クライアントに対してリスクを過小に聞こえるように報告することで、リスクを顧客判断で後回しにさせ、あとでリスクが発現した時に追加で開発費用が取る」という戦略を取っているが、これは請負契約ではなく、準委任型の契約をしているために可能な戦略である。
ITプロジェクトはさまざまな理由で失敗することがあるが、思うような成果を出さなかった場合の責任を誰が取るのか？は非常に大事な論点である。本件では「顧客判断で失敗した場合は受託開発会社はむしろ儲かる」という構造だったために、受託開発会社の営業にとっては、リスクを過小に報告して顧客に判断を間違えさせる行動が経済合理的だった。
上述した裏切りを防ぐためには、受注-発注者間の信頼関係も重要になってくる。この点は後に議論する。
報告2: 小さな受託開発会社の営業戦略
株式会社めぐみソフトというソフトウェア開発会社の社長であるひでシス氏（@hidesys）からは、同社の案件が主にどういう経路で来ているかについて報告があった。
ひでシス氏は、大学時代にプログラミングサークル（京大マイコンクラブ）に属しており、現在もサークルの先輩・同期から請負案件が流されてくることが多くあるという。
特に「スタートアップ系の企業なのに、開発会社と勘違いされて依頼が来てしまったが、自社メンバーは本業の開発に集中したい」「本業ではないが、今後の付き合いを考えて、ワンショットでシステムを作りたい」などのケースで依頼が流れてくるとのこと。
一次請け/二次請け
請負案件では、基本的には一次請け（コーディネーター）が半分ぐらいの金額を取っていくらしい。この配分はリスクテイク的には理解でき、それほど不満はないとのこと。
一次請けの役割についても聞いた。一次請けは顧客に対して完了させる約束をするが、ニ次請けはとりあえず作成する立場である。株式会社めぐみソフトは社員数名の小さな企業であり、まだ市場からの信頼も厚くはない。一次請けの会社は、ニ次請けが納期までにタスクが完了しないリスクを、顧客の代わりに請け負っていることになる。
また、一次請けは補助金が通るようにコーディネートする作業や、顧客のニーズに合わせたシステムの仕様策定をやっているという。ひでシス氏曰く、一次請けが「ニーズと売るものをバチっと合わせる」部分を担当してくれていることに対しては、非常に感謝しているとのことだった。
なお、顧客と会う会議などでは一次請けのフリをして参加することもあるという。一次請けのフリをして名刺を作っちゃうこともあるそうだ。
決済者体験
勉強会の中で、決済者体験という論点は盛り上がった。ひでシス氏から、ITリテラシーが低い人たちにITを売るには、「決済者体験の高いアプリ」（例えば、「社長や役員は嬉しがってGOを出すけども、使用者はイラつきながら使うアプリ」）にすることは重要ではないかとの意見が出た。具体的には、決済者が見れるダッシュボードが整備されている、などが特徴である。フランチャイズ系の店舗にシステムを売る場合、意思決定者と店長が別であるケースがあり、こういう店にシステムを営業する際の苦労なども話題に出た。
解説2：請負によるリスク移動と信頼関係
すでに信頼関係がある相手に依頼することは、発注時の知識の格差の問題や責任範囲の問題を解決する上で非常に有効な手立てである。特に「同じコミュニティに属する相手」に依頼する場合、どちらかが裏切り行為を行った場合、コミュニティの他のメンバーにも悪い評判が流れることになるため、裏切りを防ぐ高い効果が期待できる。
そのため、ニ次請け先のエンジニアを探す時に「プログラミングサークルの先輩・同期」という関係は非常に有益であろう。一次請けは、発注する際に「飛ばれる」「質の低い成果物を渡される」などのリスクを抱えることになる。サークルの知り合いであるというだけで、これらのリスクはかなり削減できる。
初歩的な議論ではあるが、一次受けの会社は、システムを作ることよりも、「作るべき成果物を定めること」「リスクを取ること」によってお金を稼いでいるという点は重要だ。一次請けを挟むことで、クライアント企業はさまざまなリスクを一次請けに丸投げできており、システムに対してというより、むしろそのことに対してお金を払っていると言ってもいいかもしれない。
逆に言えば、仮にクライアント企業が自分で必要な成果物を定義できる力を持っており、プログラマーに正しく発注する能力があるならば、発注にかかる金額は半分程度に抑えられるだろう。
また、請負契約は、決められた成果物を完成させる責任を一次請けに押し付けることはできるものの、作られたシステムが将来役に立つことは保証してくれない点も気をつける必要がある。例えば以下の記事では、「一括請負の受託開発が生み出す問題」について指摘している。
ソフトウェア開発における「一括請負での受託開発」のビジネスモデルは、多くの問題を生み出してきたからです。
一括請負では、作るべき機能を最初に決める必要があります。それが要件定義です。要件定義は、開発会社にとっては大事なことですが、いざ完成しても本当に欲しかったソフトウェアと違うものができてしまうリスクがあります。それに、市場環境は常に変化し続けており、社内の人員や状況も変わっていく中で、数年先までを見通した要件定義は、実質不可能です。
しかし、一括請負で受託している開発会社は、「開発する」ことだけを価値とするため、そのソフトウェアが使えるモノでも使えないモノでも関係ありません。
（中略）
発注者は「事業の成長」を目指しているにも関わらず、受注者は「納品して開発費を受け取る」ことだけをゴールにした構造が生まれてしまいます。こうした受託開発における構造的な問題が、多くの悲劇を生み出してきました。
結局のところ、自分たちに必要なシステムが何かを判断するのは顧客自身でなければならず、その責任だけは誰にも移動できないという意識は発注者に必須であろう。
報告3: 医療/公共領域の受託開発
もう一人のIT系受託開発会社の社長である大本氏（仮名）からは、過去に経験した医療/公共系プロジェクトにおける体験について報告があった。
医療/公共系は、立ち上げのモチベは高いが、運用のモチベがない
大本氏は、病気の啓発に関するWEBサイトや、地方創生に関するITプロジェクトなど、医療系・公共系のクライアントからの案件を多く受注しているIT系受託開発会社の社長である。
大本氏によって語られたのは、ITに詳しくない発注者側が、システムの未来のことをよく考えないままに発注してくる事例であった。非常に心に残る発言が多く飛び出したのでダイジェストを箇条書きでお送りする。
特に医療系とか公共系の会社や団体は、立ち上がりに向けてのエネルギーが非常に高い
こういったプロジェクトに携わった経験がない方が多く、「これは新しいチャレンジだ！」「やってみないとわかんないからまずやってみよう！」みたいな感じでテンション高く立ち上がる
「お金も予算も人も用意したし、みんなで頑張ろう！」みたいな感じ
が、基本的にその後の2年目とか3年目のことが全然考えられていない
ECサイトの立ち上げが決まったものの、配送手続きなどのオペレーションをどうやっていくのかを発注者の誰も考えていなかった。あとから「そんな大変なんだね」と驚かれ、「でもリリース期限は決まってるから作って」みたいな返しをされる
数百万円かけてWebサイトを作ったものの、プロジェクトリーダーが家庭の事情で休んでしまった結果、数ヶ月しか運用されず、次に配属された人から「来年からは新しい予算がつかないので、ひとまずWebサイトはそのままにしておいてください」という話になった
その後、目標設定がふわっとしているため、成果を計測できないままゾンビプロジェクト化する
例えば病気啓発を目的とするWEBサイトの場合、「検診受診率をあげよう！」というような目標設定がなされるが、あまりにも目標が大きすぎて自分たちの活動と成果が紐づかず、結局「やらないよりは確実にやった方がいいよね」みたいな感じのプロジェクトになっちゃう
具体的な成果ではなく、「今年はこれだけのイベントができた」「こういう人を巻き込めた」など、やった活動が成果物になってしまう
補助金プロジェクトの場合、一次請けの主幹企業は、補助金を含めて開発費がもらえればその後の運用に関心がないことが多い
（啓発活動などは、本来はマンパワーをかける地道な活動の方が成果が高いが）ITプロジェクトは「予算が付くもの」としてわかりやすいので、早めに補助金などのお金が付きやすい
個人的に特に印象に残ったのが、他の参加者から出た「医療/公共系プロジェクトの場合、大学教授や地方の有力者など、"24時間他のタスクで頭がいっぱいの人"が飲み会の勢いで立ち上げたものに補助金がつく」という発言である。旧態依然とした組織で新しいプロジェクトを立ち上げる以上、そのプロジェクトの立ち上げを指揮できる人は組織の有力者である。しかし、彼らは「他に生業があるから」有力者なのだ。その後「プロジェクトの立ち上げ」というタスクが有力者の下の人間に渡されるが、下の人間はあくまで「プロジェクトの立ち上げ」を任されただけで、将来を任されたわけではないので、「立ち上げ」が完了した後は、転属などでいなくなってしまう。責任者を失ったプロジェクトは、誰も詳細を知るものがいないままゾンビ化する・・・。
解説3: 想像力の欠如した熱意と善意
報告1の事例とは真逆で、大本氏の報告の中にはわかりやすく誰かを騙そうとしている人物は一人も出てこない。医療系/公共系で新しいプロジェクトに関わるような人物には基本的には善意の人物が多く、関係者は「良い人ばかり」のことが多い。にもかかわらず、闇の深さは群を抜いているように思われる。「闇のIT営業勉強会」としては非常に興味を惹かれる話題だ。
この事例の中で特徴的なのは、プロジェクトの将来について責任を持っている人間が誰もいないという点である。多くの人がこのプロジェクトに献身を惜しまないし、補助金などで国からもサポートされてもいる。にもかかわらず、このプロジェクトが本当は何を目指しているのかについて、誰も意志決定する気がない。
ディスカッションの中で、「非営利の活動であることが責任の欠如を産んでいる」という指摘があった。営利企業であれば、「利益を出す」という目的がはっきりしているし、利益が出なければプロジェクトが中断される。しかし、医療/公共系のプロジェクトは目的がはっきりしないことも多い。また、彼らの多くは、自分の工数が本当に意義のあることに使われているのかどうかを管理する意識や、「自分たちがいなくなってもプロジェクトが存続するような体制作り」への意識が低く、「意味なく人月が投下されるプロジェクト」「人がいなくなればそのまま立ち消えるプロジェクト」になりがちだそうだ。
それゆえ、プロジェクトが存続するには、関わる人にとってプロジェクトが生業であることが重要である、という。特に、立ち上げを指揮した有力者にとって、そのプロジェクトが生業ではない場合、そのプロジェクトはいつの間にか最初の企画者に見放され、当初の目的を見失う。
大友氏は、これらの経験を経て、将来発生する負担やリスク、例えば将来必要になるオペレーションや思ったよりアクセスが集まらない可能性などについて、立ち上げの早い段階で強めに伝えるようになったという。
これは医療におけるインフォームド・コンセントになぞらえることができる。患者がリスクのある治療法を選択するならきちんと警告しなければならない。知識がない人間が正しく将来の意思決定ができないのは当たり前であり、意思決定に必要な知識を提供することが専門家の役割とみなされる。
とはいえ、これは大友氏の善意に依存している。発注元に将来のリスクを伝えて開発を思い留まるように仕向ける行動は、受託開発会社側にとって短期的には利益につながらない行動である点は指摘しておく必要がある。実際、発表の中でも「一次請けの主幹企業は、補助金を含めて開発費がもらえればその後の運用に関心がない」という語りがあった。開発会社側から見ると、これらの顧客は基本的には初期開発費が狙い目であって、その後の運用費などはそれほどおいしくないのだろう（プロジェクトが成功して長続きする可能性が低いのだから、うなづける話ではある）。
特に補助金プロジェクトの場合、プロジェクト初期の補助金申請時に開発の計画を立てなければならず、その計画の金額が補助対象になるため、初期段階で機能を多めに盛り込んで、大型のプロジェクトにしておくことが経済合理的になるし、立ち上げ時にテンションが高まっている発注者側もどんどん機能を追加してしまうことが多い。
ソフトウェアを作って完成させるだけでは、価値が産まれていないどころか、投資をしている分マイナスのスタートになります。それなのに、要件定義をしなければいけないのは、一括請負で受託している開発会社の都合によるものが大きいでしょう。というのも、できるだけ多くの機能が盛り込まれた要件定義になることで、高い見積もりにできるからです。発注者側は後で改修するのが大変だからと機能を盛り込んだ要件定義にしますし、その分人月がかかれば開発費が上がっていきます。
本来ならば、知識がない人間に早い段階で大きな意思決定をさせることは避けるべきである。にもかかわらず、補助金事業の多くは、ITプロジェクトに慣れてない人間に対して、最初にプロジェクト全体の計画を立てさせる構造がある。補助金が価値のないITシステムを生み出しやすい理由の一つがここにあるだろう。
補助金による開発の場合、初期段階の開発は補助金に含めることができるものの、あとからの修正や追加開発を補助金に含めることが難しい点もこれに拍車をかけている。補助金は「あとで必要になる可能性が少しでもあるなら、今のうちに作ってしまえ」という意思決定を促進してしまう。これはソフトウェア開発におけるYAGNI原則（機能は実際に必要となるまでは追加するべきではない）に明確に反している。
まとめ
あなたが「闇のIT営業」を目指すなら、以下の知見が役立つかもしれない。
顧客との間に知識の格差が存在する場合、顧客は正しい価格を判断できないため、こちらの言い値に釣り上げることができる場合がある。
準委任契約の場合、クライアントの知識不足につけ込み、「リスクを顧客判断で後回しにさせ、あとでリスクが発現した時に追加で開発費用が取る」などの手段で、開発を引き伸ばすことにより、費用を上げられるケースがある。
請負契約の場合、クライアントの知識不足につけ込み、初期段階で機能を多めに盛り込むことで、費用を上げられるケースがある。
ITに詳しくない発注者の場合、立ち上がりに向けてのエネルギーは非常に高いものの、運用フェーズではモチベーションが失われていることが多く、あとから追加で機能を開発したり費用を請求したりことの難易度が高くなりがちのため、プロジェクト初期に費用を積むことが重要になる
逆に、あなたが発注者であるなら、以下のことに気をつけると良いだろう。
発注者側にIT知識が不足していることは、プロジェクトの費用を跳ね上げ、意義のない開発費用を生み出す要因となる。発注者も最低限のIT知識を身につけるべきである。
知識の格差が埋められない場合、信頼できる相手に依頼することは有用である。
システムは作っただけで終わりではない。作った後のことを想像する力や、成果目標を設定する力が欠如していると、膨大な費用をかけて意味のないシステムを作るプロジェクトができあがる。
次回予告
第三回は、1/27(金) 19:00-21:00、ZOOM上にて開催する。
発表者は、とある大学の、ITとは程遠い学部の中で、大学主催の1年以上かかったIT活用プロジェクトの担当をしていた大学職員の方だ。「〈紙と印鑑と前例への偏重〉だらけの公的組織の実情について、末端のユーザー視点からのお話」が聞けるとのことだ。ITの素人たちの集まりの中で、ITという言葉とどう扱われているのか、現場からの声をお話いただく。
大学内でのITプロジェクトの中心に関わっていた方の経験談はなかなか聞けるものではないため、主催である私自身も、本当に楽しみにしている発表である。
参加を希望する方は、以下noteに埋め込まれた勉強会への申し込みフォームから申し込んで欲しい。
この記事が気に入ったらサポートをしてみませんか？