「なぜ、システム開発は必ずモメるのか？」を読んで

どうも、たけです。
ついさっき耳から血が出ました。裏側ですけど。
ちょうどメガネのテンプルが耳に当たる部分が出血したせいでメガネがかけられません。治らないと明日からの仕事誤タイプして詰みそー・・・
ちなみに今もメガネ外して執筆してるので誤字るかもしれません。あしからずご承知おきください。

とまぁ雑談はさておき、また本を読んだので読書感想文残そうと思います。

概要

「システム開発の現場で、よく揉める内容を実例付きで紹介してくれる」
みたいな本でした。ラノベチックで紹介してくれているので読みやすかったなと思いました。

なぜ、システム開発は必ずモメるのか？

印象に残った部分

読んでて「これ大事そう」って思ったとこはハイライト引いたのでそこを紹介しようと思います。

1. 機能要件はシステムが何をするのかを一番具体的に明らかにする部分で、ここでの漏れや誤解、理解不足は、直接ケンカの火種になるから要注意

2. 要望を出すときや、それを整理して要件にするときには、役割を超えてお互い気づくことをどんどん言い合う形でしか網羅性は担保できない

3. システムの品質を守る最後の砦は受入テストではなく、それに向けたテストケースやテストデータのレビュー(だと思う)

①②　機能要件心得

要件定義の段階で意見が衝突するのを恐れて当たり障りのないように終わらそうとすると後になって取り返しがつかなくなるみたいでした。
自分はまだ実務で要件定義に入ったことないけど、やるときには気を付けようと思いました。

③　システムの品質を守るもの

これはなるほどな、と思いました。原則、最後に行うテストが客先が実施する「受入テスト」というものなのですが、この本では、そこでのテスト実施よりもテストのためのテストケースのレビュやテストデータのレビュのほうが大事ということでした。
テストでの結果確認だけだとほぼ必ずケースや例外データとかで「漏れ」が発生します。(ユーザにとって当たり前のことでも、ベンダにとっては考慮にすら入らないものとか)
実際に今の業務でも最終試験で確認できていなかった部分でのちのちリリース後に保守対応としてやることになるものとかがあります。
なので、テストケースやテストデータがきちんと準備できていることのほうが大事なんだなと思いました。

おわりに

全体的に要件定義に関係した話しかないので(あたりまえだけど)、まだ業務で要件定義したことない自分にとってはピンと来ない部分も結構ありました。
要件定義を実際にやってみてから、もう一度読み返してみようと思います。