「なぜ、システム開発は必ずモメるのか？」感想①
「なぜ、システム開発は必ずモメるのか？」の要件定義～プロジェクト計画編まで読んだので、その感想を書いていきます。
概要
本の内容としては、現実に発生した判例を元にどのようにトラブルを回避していけばよいかを描いている。
ITの本らしく各工程ごとに解説をしてくれており、会話形式で展開されていくため、エンジニアには内容が入ってきやすい。
要件定義
全体を通して言われていることは、昨今の潮流である「要件定義はユーザの責任」だけではないということが語られている。
例えば、他システムからインターフェイスされるデータの形式が想定と全然違うために取り込めないという事例の場合である。
開発経験が少ないユーザに要件定義時点で他システムへのヒアリングしたりすることを自発的にすることはないだろう。
なぜならそもそもそんなことをしなければならないという意識がユーザ側にはないためである。
ベンダはそういったリスクを考慮してユーザに対してそうした動きを促す必要があり、それもプロジェクト管理責任であるというのが、裁判所の判例としてある。
専門家のベンダがきちんとガイドする必要があるということである。
逆にユーザ側も要件定義書が本来のシステム化の方針（業務のどこがどのように変わるのか）や目的（システム化によるメリット）を達成できるのかを当事者意識を持って検証しなければならない。
ユーザもベンダも双方がひざをき合わせて、腹を割ってとことん本気でシステム化について、議論しないとよいシステムは出来ないことが語られている。
プロジェクト計画
まず、リスク管理がプロジェクト管理の要であるといっている。
システム化におけるリスクとして、ユーザ側の人事異動による担当者変更も挙げられている。
そこでの引継ぎはもちろんユーザ側のリスクであるが、そういったリスクが発生した場合にどのように対応するのかを考えておく必要がある。
まとめ
この本に書いてあることはソフトウェア工学やPMBOKで語られていることであり、理想論であるが、理想論を知らないとそこから現実に何を引き算して適用すればよいかわからない。
そういった視点でもこの本の有用性は高いと思う。
