はじめよう!要件定義

目的

要件定義の打ち合わせに同席した。機能の一覧が並んでいる。正しいのかどうか、こちらには判断できない。

専門知識が足りないのではなく、何を見れば判断できるかを知らない。本書を読む目的は、その読み方を持つことにある。

論点1 機能の一覧は、使う場面が無いと判断できない

「検索機能」「承認機能」と並んでいても、過不足は分からない。

「営業が、案件を探す」「課長が、申請を承認する」と誰が何をするかの形で並べると、抜けている役割が見える。営業はここなら判断できる。

いちこ

開発の資料に口を出していいんでしょうか。

シュン

使う人の話だからね。むしろ営業しか知らないことが多いんだ。遠慮するほうが危ないよ。

論点2 決めていないことを書かないと、決めたつもりで進む

決まったことだけを並べると、合意できた風に見える。

「未決: 既存システムとの連携範囲」と書いておけば、残っている穴が見える。未決事項の管理は プロジェクトマネジメントの基本が全部わかる本 が詳しい。

論点3 変更を禁じるのではなく、変え方を合意する

全部を最初に決めて動かさない方針だと、変更のたびに「追加費用か仕様内か」で揉める。

• 動かさない部分を決める
• 動く部分は、変え方のルールを決める

営業の立場では、この合意を商談段階で作っておけるかが効く。

いちこ

変更は無いほうがいいと思っていました。

シュン

無いほうが楽だけどね。実際には必ず出るから、出たときの手順を先に決めるほうが現実的なんだ。

この本の限界と、次に読む本

業務システムが前提で、手を動かす人向けに書かれている。営業は読み方として使う部分を取ることになる。並べ方と優先順位なら ユーザーストーリーマッピング、発注側の責任範囲なら なぜ、システム開発は必ずモメるのか? が隣に並ぶ。