サンクコストの呪縛
本を読んでていて “サンクコスト（埋没費用）” の話があって、「あ〜。なんか覚えがあるな〜」と思いながら読んでいたので、思い出したことを書いておく。似たような状況にあるなら他山の石にでもしてください。
サンクコスト（埋没費用）とは
以下はウィキペディアからの引用。
埋没費用（まいぼつひよう、英: sunk cost 〈サンクコスト〉）とは、事業や行為に投下した資金・労力のうち、事業や行為の撤退・縮小・中止をしても戻って来ない資金や労力のこと[1]。
ウィキペディア：埋没費用 より引用
簡単に言えば「もったいない…」というやつ。それまでに投じた資金や労力に成果が見合っていなくても、回収しようもしくは回収できるのではないかと考えてしまう心理現象。
ただ単に「もったいない…」と思うだけならまだ良いんだろうけど、サンクコストというのはその後の判断にも影響する。”このまま続けたら赤字になる” というのがわかりつつも更に進み続ける。いわゆる “デスマーチ” というやつですね！
あるシステム開発のプロジェクトでのこと
僕が途中から参画したシステム開発のプロジェクトでのこと。
かなり業務仕様が複雑で、過去に似たような業務に関わった経験があったことと、同じ部署の人がマネジメントとリーダーをやっていたのもあって、ヘルプで入った。
プロジェクトの事前情報
事前に聞いた話では以下のような感じだった。詳細は書けないので概要。
- 要件は確定済み
- 開発に向けて設計書を作成中
- 外部データを処理するサーバは顧客側で開発
- 現行システムがあるのでUI、機能は8割近く踏襲
- 納期は短い
- 費用は十分にある
納期が短いという部分以外はなかなか良好に見えた。見えたんだけどね…
プロジェクトに参加してからわかったこと
要件が確定していると聞いていたが、プロジェクトに参加して設計の打ち合わせや、サーバチームとのインタフェースを調整する会議に出てわかったのは、確定していると聞いていた要件というのは、顧客の要望…書き直すと願望は確定しているということだった。
それも雑な感じの要件。「こういうのあったら良いなぁ」「こういう風にできるんでしょ」みたいのが羅列しているだけのもの。（おいおい、こっちはドラ●もんじゃねーんだよ！）とかいう心の声が出てしまいそうだった。
あれ？そうすると、みんなはそんな状態でどうやって設計を進めているんだろ？
と思うでしょ。僕も思います。どうしていたかというと、みんな前提を置いて設計を進めていた。
クライアントを開発する側は「画面のレイアウトと必要な情報を定義すれば、サーバ側から画面に合わせたデータが送信されてくる」とか言ってた。
サーバを開発する側は「サーバ開発の人員は限られているので、ある程度はクライアント側で処理して貰います」とか言ってた。
そこには埋められない深い溝があった…
まあ、でも現行システムがあるならある程度はソース解析して設計できるし、納期は短いとはいえ費用は十分確保できているから、少しぐらいの無茶振りは吸収できるよね。とか思ってたんだけど、現行システムのソースコードは提供されていないの。
「え？それでどうやって現行とUIや機能を合わせるの？」って聞いたら、40ページぐらいのマニュアルと動く現行システムを渡された。画面数だけで100以上あるのに40ページのマニュアルと実際に動かせるアプリしか情報ないの！？
システム開発に詳しいければ、MVCで書くと以下のような役割のはずだった。
- M：外部データ（既に存在する外部業者のサーバ）
- V：クライアントの担当範囲
- C：サーバの担当範囲
でも実際はこんな感じ。
- M：サーバの担当範囲
- V：クライアントの担当範囲
- C：該当なし(o^-･)b
そんな状態なのにみんなガンガン設計を進めているんだよね。言い分を聞く限りは「要件定義書にこのように記載されているので、こういう風に解釈しました」と、要件定義が曖昧なのでみんな自分に都合の良いように好き勝手に解釈してしまっていた。
と、後から思い出して書けば数行なんだけど、これだけの情報を各自から地道にヒアリングしながら集めて整理するのに３、４ヶ月はかかった。だってパッと見はどれもこれもそれなりにできているんだもん。パッと見はね…
これに更に追い討ちをかけたのは、設計から参加していた技術者の大半がほとんど技術をもっていなかったこと。一部にはしっかり技術がある人もいたけど、納期が短いにも関わらず新人や、開発言語の経験がなかったり、他の人と連携しながら開発を進めるプロジェクトの経験がない人が半分以上を占めていた。
納期短いんだからそんなの(ヾﾉ･∀･`)ﾑﾘﾑﾘ
プロジェクトを一度止めることを提案
そんな状態だっていうのに気づいたら、どう考えてもこのまま進んでも何も良いことはないのはわかっていた。
見た目にはそれなりに動くようなものは多分できるけど、できたは良いけど中身はスカスカで、そのあとは不具合の改修に奔走することは目に見えていた。
そんな状態ならとりあえずプロジェクトを一度止めて、要件定義や設計をやり直すことを提案するよね。
というかしたよ！まずは内部に。
結果何を言われたかというと、「そんなこと今言われても困るよ！」ということだけ。それまでに費やした金額でいえば、およそ２億円くらいで、その時点でプロジェクトに関わっている人員は100人ぐらいだった。
僕の提案では、一度プロジェクトを止めて、しっかり技術があって設計ができる人を残して人員整理をし、設計の一部と各チームの役割分担を見直すべきだということを話した。
確かにいきなりこんなこと言われても困るよね。とは思ったけど、僕より10年も20年も経験が違う人達に対して伝えたので、その時点でいきなりプロジェクトを止める決断はしなくても、その後なにかしらの手は打ってくれるのではないかと思っていた。
結果から言えば、僕が伝えたことは “聞かなかったこと” になったみたい。ここに関係しているのが、サンクコストなんだと思う。
それなりの費用と人員を費やして、要件定義や設計といった工程も合意をとって進んできていて、そこに僕が投げた石は「これまで費やした8割近くをやり直すべき」という提案であって、今確保している人員100名の内、80名ぐらいをカットするような話だから、まあ受け入れられないよねというのは今なら理解できる。
顛末はどうなったのか？
人員面では、僕が提案した３ヶ月後ぐらいに開発が終わり、テストフェーズに入り、人員が一気に30名ぐらいに減り、その後は緩やかに減っていく計画だったが、開発が終わってからテストフェーズに入れず…というのもサーバと繋げるとシステムが動かず、一度人員減らしたにも関わらず再度人員を集めて改修するということが２、３度発生していた。
費用面では、僕が提案をした時点で２億近く費やしていて、計画では最終的に４.５億円くらいかかる見込みだった。結果としては、費用負担がバラバラ担っていたので僕の試算にはなるが、およそ10億円以上はかかっていた。加えて、トータルで2億円近い赤字になっていたと思う。ちなみに僕の予想では、1億ぐらいの赤字は覚悟するべきだと言っていたが、それすら甘い考えだった。
スケジュール面では、僕が提案した半年後が納期だったのだが、確かそこから更に２年半ほど時間がかかっていたと思う。
つまり、僕が思っていたのよりも更に上振れしたひどい状態で着地している。
わかっちゃいるけど辞められない
今現在の状態、そして未来に向けての予測に、過去に費やしたリソースがどれだけだったか？なんていうのはなにも関係は無い。
結局のところは「相当な費用と人員を投じているんだから、それなりの成果に つ・な・が・る でしょ？」という楽観的な見通し…というよりは信じたいと思う気持ちが判断を鈍らせている。
プロジェクトが終わった後に、関係者を集めて “ふりかえり”（反省会のようなもの）を必ずやる。僕はプロジェクトが終わるより前にとりあえず自分が救える範囲を救って退散したからそれには呼ばれていない（呼ばれても行かない）が、そこで話し合われた内容は議事録で確認できる。
なにが書いてあったと思う？
「要件が曖昧だったのが問題だった。一度プロジェクトを止めて要件定義や設計をやり直すという勇気を持つことも大事。」
みたいなことが書いてあって愕然とした。言った！それ2年半前に同じこと言った！と思うが、まあ予想通りだった。
なんでかというと、何百というプロジェクトがあって、同じように失敗したプロジェクトも多くあり、それらの議事録を参照することもできるんだけど、大体失敗したプロジェクトのふりかえりは同じようなことが書いてあるし、僕が提案した時にいた人達もそんなことは知っていたはずなの。
人は過去から学習しない…というのではなく、それまでにどれだけリソースを費やしたかによって、当事者には「わかっていても辞められない」とか「過去にそういうこともあったけど僕たちは大丈夫」とかいう思いが生まれてしまうんだよね。
ここに書いた話で言えば、僕が想定していた一番最悪の状況の更に上をいった着地をしているので、結果に対しては僕も楽観的な見通ししかできていないということになる。
いやー、論理的な判断って難しいねー(｡･ω･)ﾉﾞ