【書評】なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術

日本実業出版社の今野様より献本御礼。

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

東京地方裁判所でIT事件担当の調停委員を努めておられる細川氏が、ご自身の経験をまとめてシステム開発のモメるポイントを整理し「人の振り見て我が振り直せ」を啓蒙する位置づけの図書になっております。

こう書いてしまうと非常に堅苦しいですが、モメるポイントをわかりやすく伝えるために「IT事例に詳しい美人弁護士に相談する」というカジュアルな設定になっています。塔子さんがその弁護士役で、厳しい指摘がコンビネーションブローのように続いており、爽快感がありました。

一部、本書の会話内容をご紹介します

彩音　「もう設計も終わる時期なのに、また要件からやり直し！そのうえ納期は全然延ばしてくれないなんて、お客さんひどくないですか？」

塔子　「何言ってんよの。要件定義工程の完了時点で本当に要件定義が固まっているプロジェクトなんて、アタシを美人だと思わない男よりも少ないわ」

いきなり飛ばしてくれるなぁと。いや、その通りですけれども！＞要件が本当に固まってるわけない

要件定義工程は委任にすればいいじゃんって言う人いるけど、委任でやるのはいいとしてもそこでやった作業が100%の要件になるかといえば、それも違うわけで。

塔子　「ベンダは、要件の追加変更要望があった時に、場合よっては追加見積りも必要って判断が必要って判断がなされてるわ」

彩音　「一応、他の機能を削ることもお願いしてるんですけど」

塔子　「現実そんなにキレイにいかないでしょ。ダメなもんはダメ。費用が必要なら必要ってちゃんと言わなきゃ」

彩音　「そんなことお客さんに言いにくいです」

塔子　「最終的に、どうすればユーザーの信頼を得られるかを考えなさい。この程度のことも出来ないんじゃ、人から金取ってITベンダやってる資格なんて無いわ」

随分とヘビーな会話をカジュアルにされてますが、これが本書の稀有な切り口で面白いところです。

提案された解決策についてもそれが出来たらなぁって思うところもありましたが、それこそが解決策を提示された時の一番の感想ということで・・・。裁判事例を引き合いに出して司法的な判断を利用しつつ責任の是非を問う切り口はとても説得力がありました。

ユーザーとベンダーの共同関係を再考する

僕の問題意識の中で、「ユーザーとベンダーがどうやって共通言語を持ちながら、システム開発を進めることが出来るのか」というのがずっとあります。本書はそれを再考するとても良い機会でした。

システムは料理をつくる工程に非常に似ています。トマトソースのパスタという完成図は大体決まってます。ただ、パスタを作る工程やトマトソースを作る工程はレシピによって千差万別で、そのレシピの妥当性を判断するには専門的な知見がどうしても必要になります。レシピ通りにモノを作らなくてはなりませんが、そのレシピの正当性を関係者で吟味できるのか。そのギャップが埋め切れずモメるケースは、皆さんもよ〜くご存知かと思います。

要件定義段階で全ての要件をFixするのは無理というコンセンサスは、僕がこの業界に入った2003年頃からありました。ただ、やり過ぎると不信感も生まれます。また「その積みって要は保険かけてるだけ。SIは保険屋であるべきなのか」と業界内部からも批判の声が上がってます。

本書でも「正当な費用を理解できない所とは商売をすべきではない」「その場しのぎで取り繕って、問題を先送りする方がよほど不誠実」とありました。何が正当な費用なのかをユーザーにご理解頂くのかが最も難しいのですが、超えないと行けない問題です。正当な費用であるとご理解頂ける努力をしないとなぁと改めて感じました。

また、管理側に近い立場のエンジニア・マネージャの方なら、受託／サービス問わず要件定義やプロジェクト管理でモメるポイントが上手くまとまっているので、振り返りに使える一冊になっています。

とても便利なチェックシート

本書はモメる事例集に閉じること無く、プロジェクトがモメるポイントのチェックリストや成果物サンプルなどを用意してくれており、現場でそーゆー問題が起きた場合はこうするも一考やで、という転ばぬ先の杖も用意してくれています。IT事件担当の調停委員という立場から逆算して解決策を提示するアプローチは、一読の価値ありです。

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術