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

著者：吉田啓二
発売元：日本実業出版社

目次

１　要件定義（「言った・言わない」と「やる・やらない」）
２　プロジェクト計画と管理（線表だけが、管理じゃない！）
３　設計（ベンダとユーザが協力すべし）
４　プログラミング（動けばいいってもんじゃない）
５　テスト（テストの対象、わかってる？）
６　契約と仕事の完成（約束したのは何だっけ？）

感想

これ、タイトルは「●●が△△だから□□」ってタイトルな、そんな本な気がしましたが

いろいろ読んだ、要件定義な本の中で一番良かったかも。

「こうすればいいことありますよ」という書き方ではなくて「こうだから、ダメなんだよ～お前は～」と上司から怒られるような書き方となっているので、骨身にしみます。

あぁ・・・ごめんなさい

と、素直に思えてしまいます。

まぁ、失敗こそが最大の教科書といいますからね。

そんなわけでして、この本はものすごい良い教科書だったりしますわ。

たとえば、要件定義した後に、多くのユーザーさんは「アレもしたい。これもしたい」って騒ぎ出すのですけれど、そういう場合はどうすればいいのかがちゃんと書かれている。

それは

◎要件変更要望があった際には、そのメリット・デメリットをユーザに説明し、一緒に賛否を検討する
◎追加要望の場合には必ず費用を見積もる
◎見積りの際には、要件変更の賛否検討や要件変更の管理工数を予測して、プロジェクト管理費に含んでおく

のだとな。

で、こういう話をすると、機能の話に落ちるのですけれど、機能の話はベンダーとユーザーの間の思いの差が大きかったりするわけですよ。

なので何やるのか？何の機能なのか？を明らかにして、お客さんと握らないとヤバイ。

そして、それは機能要件以外、非機能要件でも発生するので、注意ということですわな。

で、要件定義をやり慣れているSierや、Web開発のベンダーと、事業会社の方々は違うわけですよ。

事業会社の情シスの人たちだって、年がら年中、要件定義をしているわけではない。

要件定義のスキルに関しては、ユーザー側が大きく劣る。

そりゃ、業務用権ではユーザー側のほうが知見は多いけれどね。

で、そんな要件定義に関してはユーザーを導くことが求められるわけですよ。

ユーザーにおまかせではなくな。

で、それを本書では

◎ベンダはユーザの決めること、調べることを積極的にガイドする
◎要件定義は、役割を超えてチームで徹底的に議論する
◎要件定義チームには出来る限り多くの利害関係者を入れる

事が重要だと、書いておりますわ。

あと、最初から1つのツールにこだわるな、とも書いてあるね。

これ、ものすごく重要。

あと、重要そうなこととして

システム開発の要件すべてが、要件定義工程の完了時点までに決まることは稀有です。決まらない要件は未決定事項とし、解決担当者や期限等を定めて継続的に管理することが大切です。

と書いてありますわ。

まぁ、期限と担当者が重要ですがね。

これが漏れちゃダメ、と。

で、お客さんのやりたいことって山ほどあるんですけれど、それをきっちり全部、最初の開発で実装できるわけがない。

順を追って実装していくのですけれど、この考え方をていぎしたものあるのね。

MSCoW分析っていうのね。

何かというと

一つ一つの要件をMust（必須）、Should（できればやる）、Cold（あれば尚良い）、Won't（将来的にはやりたい）に分類する

のだとな。

いままでなんとなく思っていた＆やっていたことを定義してくれたのが嬉しい。

あと、機能の有り無しは目につくけれど、その機能があっても実行還流するまでの性能に関してはあまり定義していなかったりするので、注意ねっていう話も良かったわ。

あと

「塔子のチェックリスト」

っていうのが良い。

開発プロセスをレビューするためのチェックリストが使えるよ。

これをなぞるだけでも、クォリティはものすごく上がるよ。

あと、参考文献がいろいろ紹介されているのも良い。

成功する要求仕様 失敗する要求仕様

アメリカ国防総省直伝 プロジェクト・マネジメント実戦教練ブック

ソフトウエアの要求「発明」学

要求仕様定義ガイドライン(UVCプロジェクト報告書2007)

非機能要求仕様定義ガイドライン(UVCプロジェクトII)

を読みたくなりましたわ。

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