システムを”作らせる”（ユーザ企業側）目線で書かれた，
システム開発系PJ成功指南所．
かなり割愛して読んだが，後書きにあった最後の一文が痺れた．
"本当は「作らせる人」も、「作る人」もいない。いるのは「プロジェクトを成功させ、会社を良くしたい」ともがく人々だけだ"
ベンダーだろうがユーザだろうが，この信念を持てるかどうか．ベンダーであれば要求の洗い出しや整理などユーザ主体の活動であっても「ユーザの責任範囲なんで」と他人事で見ないこと．ユーザであればシステムのことはわからない（わかるつもりもない）とベンダーに丸投げしないこと．
すなわち，他責にならないことが大事．
相手に多少踏み込み過ぎ？と思われるくらいが丁度いいかもしれない．だって「プロジェクトを成功させ会社をよくする」ためにもがいているんだから．
・PJには100％確実なものは何もない
・ユーザは業務のプロであって要求定義のプロではない．ユーザからシステムへの要求や制約を引き出させるのもエンジニアの仕事
・プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
他人への説得論法
why → How → What
私たちは世界をかえる〜→その手段は〜→だから◯◯を作った。
一般人はどうしてもwhatから考える。だからストーリーがつまらない。
こんなソリューションを使う(what)→ベンダーに作ってもらおう(how )
工場を◯◯にしたい→◯◯が必要だ→こんなシステムが必要だ
プロジェクトは曖昧さ100%から曖昧さ0％の着地に向かって進む、不確実性が減り具体的になる
→★確実な情報を持ってこい！は傲慢。曖昧さを減らすために対話して意思決定を積み重ねる。
要件定義の難しさ
・検討漏れの発生
・要件を詰め込みすぎる→ビジネスライクに必要性を判断
総論賛成各論反対
良いプロジェクトのゴール
以後の工程で使える価値尺度がはいっている
(現状維持>新規性)
地に足がついている
わかりやすい
whyがこめられている
プロジェクトは初めての活動
→こうすればよかったは必ず出る
→完璧を目指す姿勢そのものが間違っている。
要求定義
→システムを作らせる人のwant
要件定義
→システムを作る人が、システムに必要とされる性能や機能を明確にする作業
設計
→要件を実現するための技術的な方法を決める作業
要求定義作成の難しさ
・網羅的な洗い出しができない
・予算オーバーになるって
・立場によって要求が異なる
★著者の会社の要求定義の定義
"要求定義とは利害関係者の意見をまとめて、実現すること・実現しないことを揺るぐなく定めること"
★ユーザは業務のプロであって要求定義のプロではない
→引き出す、ナビゲートするのもエンジニアの仕事
★全て洗い出す→優先順位をつけてやるやらないを線引きするところまでの客と握る
→スコープ(やる・やらないの線引き )を明確にして、あとになって「これも必要」と言わせない。やらないと分かっていても端折ったり捻じ曲げたりしない。
★網羅的に検討したんだぞという訴求
★恣意的ではなく合理的に選択したんだぞという訴求
コミュニケーション計画
★プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題
ファンクショナルマトリクス
縦軸に大きな流れやmeceな構成要素
横軸には各行を一段落として分解したもの
セキュリティの例: 対策領域×IDDRR
