要件定義 - ProgramingLake

とりまく環境
・要件定義を明らかにするプロセスを得意とするSEが不足している。
・プロトタイプに頼るあまり、行き当たりばったりの開発が横行し、結果的に設計書が書けるSEが減ってしまった。

要件定義フェーズにおける注意点
・大方針としてゼロベースで検討するのか？それとも現行のシステムを参考にして進めるのか
・手戻り、納期遅延の根源は要件定義。
・読む人が判断に迷わないものを作成するべきで定量的な表現がベターで、
　次の工程の担当者に何をすべきかを伝える目的がある。
・当フェーズで曖昧さを解消するのは骨が折れる。ただ、これを怠ると後工程に皺寄せがいくだけ。
・見積もり時、コミュニケーションオーバーヘッドがあるので、開発要員を増やしてもスピードは倍にならない。むしろ低下することを考えなければならない。
・アリバイレビューではなく、ユーザーを巻き込んだ実質的なレビューが必要。
・プロトタイプで行きましょう = 「今、丁寧に要求を洗い出すのはやめましょう」という意味では無いことを確認すべき。
・この言葉に「仕様の決定を先送りにしましょう」という意味合いが含まれているのであれば一度立ち止まるべき。
・1:1, 1:n, n:1, n:nを考える
・見積もり時は変動要素をよく考える必要がある。
・要求事項というのは発散しがち、それぞれが問題、解決に貢献する要求なのかを判断する必要がある。
・業務理解が大事な理由。それは仕様漏れの芽を潰せる。また、例外業務があるかというのがわかる。
・ヒアリング時は無理に整然としたフローを作ろうとするな。業務は実際は複雑であるため。
・美しくない業務の流れがあれば改善する必要が出てくる場合もある。

・机上で仕様を詰めていても、実画面が動く姿を見て違和感を感じるというケースは多い。
・プロトタイプに頼りすぎると、システムエンジニアの行動が計画的でなくなる。

発注元のユーザに対して
・丸投げ的な発想はシステムにおいては通用しない。同じ業態であっても、会社が違えば考え方が違う。
　最もパッケージ製品に馴染むと言われている給与システムや会計システムでも曖昧さを解消しないと失敗すると言われている。
　協業して進めていかなければ必ず失敗する。　

ヒアリング
・ユーザーは抱えているニーズを自ら列挙することはできない(忘れや漏れが必ず生じる)
・これは当たり前だろうと思っていることを語ることができない。
・あなたと異なる意見を言う差は他にいませんか？という観点も大事
・ヒアリングの難しさ、聞いたことが情報が得られるが、聞いていないことは分からない。
・「何か問題がありますか？」が一番 NG。漏れだらけになる。
・あなたの意見は部署全体で見て標準的ですか？例外的ですか？
・この人だったらどう答えると思いますか？それにはどういう思惑があるからだと思いますか？
・ドキュメント調査が必要。現場で使われているマニュアルやちょっとしたメモも大事。あとは開発ドキュメント。

一般法則
・遅れは遅れを呼ぶ。一度遅延したプロジェクトはもう一度遅延する。(プロジェクトマネジメントの一般法則)
・挽回するシナリオよりも現状維持か、それより悪くなるというシナリオを想定しておいた方がよい。それが現実的。
・正しくないものを急いで作っても仕方がない。
・なぜ遅延するのか？それは正しくないものを作ってしまうから。
・例えば冗長な作業、ヒューマンエラーを削減するべき。担当者の注意力で解決するというのは一番やってはダメ。個人の成長を待たずに遂行できるのが理想。
・FIT & GAP をして総括的に一致するので進めていたが、ミクロな視点で見ると不一致があるというケースがある。
・ミクロな視点に傾きすぎると、システム構築本来の目的を見失ったり、優先度が定まらなくなる。

開発側の社内の課題
・報告用の対応等に時間が費やされるのは無駄。実質的には何も解決されていないままである為。

発散した要求事項の絞り込み
・要件定義で最も恐れるべきなのは仕様の漏れであるグレーゾーンのものまで切り捨てると必要なものまで捨ててしまうリスク。
・意見、指摘、愚痴は多ければ多いほどいい。そこからは取り組むべき重要なテーマが見えてくる。
・例えば冗長な作業、ヒューマンエラーを削減するべき。担当者の注意力で解決するというのは一番やってはダメ。個人の成長を待たずに遂行できるのが理想。
・トヨタのなぜなぜ分析を5回すると、自然に問題の核心に迫っていき、本質的な問題が発見される。最終的には数個程度の根っこに当たる問題に収束するのが普通である。
・ボトルネックを探そう。ボトルネック=投資効果が高い観点である。
・機能というキーワードだけだと色々な解釈ができるため、なるべく要件定義では使わない方がベター。具体的な例で補う必要がある。
・解決したい問題と実装すべき機能のマッピングが必要
・必要であろう機能の洗い出しが完了しても、まだその機能を実装する価値があるかどうかの判断はできていない状態である。