ざっくりと雑記としてIT業界に勤めている人ならお馴染みのipaさんが公開している要件定義工程の進め方についてざーっと読んだので私の考えや経験も交えながら内容を簡単にまとめてみた。
IT業界の経験が浅い人やユーザ部門側である程度知っておくべきな人、でも全部を読むのはキツイという人向けです。
以下から出典元にアクセス可能です。
独立行政法人IPA 情報処理推進機構
ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ
要件定義の全体像
まずは要件定義の全体像とプロジェクトにおける位置づけを整理。ざっとこんな感じ。
「企画」➡「要件定義」➡「システム設計・基本設計」と進み、企画や構想でまとまったものを定義し、開発工程に繋げていく超絶重要な工程。
要件定義終了時に、設計から移行・運用準備までのコストを見積り、ブレが±10%以内になるようにあらゆる不明点を洗い出し、ステークホルダと定義していく！一言でいえばこれこそが要件定義工程の核であると言ってよい。
要件定義の進め方
要件定義は「立上げ」➡「計画」➡「監視・コントロール」➡「終結」の順に進む。以下から順にそれぞれのプロセスで必要となるタスクや観点について整理していく。
立上げ
構想・企画
企画フェーズで検討した要求事項（やりたいこと）一覧をもとに、何について議論していくのかを決める。ずばり要件定義のスコープを定義すること。
ステークホルダの特定
プロジェクトを取り巻くステークホルダを見定める。プロジェクトの関係者、それぞれの立場、役割を整理。そしてざっとこんな疑問を投げかけてみよう。
関係する周辺システムのベンダーはいる？既存システム・現行業務を理解している人はいる？ちゃんと関与してもらうように調整してある？お客さんの誰がキーマン？声がでかい人誰？あとから決定事項をひっくり返してきそうな人いる？その人にはどう対処していく？偉い人にはどのような頻度、どのような粒度で報告する？誰と合意形成していく？誰が決定権ある？
この問いと共にプロジェクトに関わるステークホルダーを明らかにしていくこと。
計画
プロジェクト計画
要件定義工程の前後のプロセスを確認し、要件定義の進め方、必要な成果物、記載レベルを定義する。
作成した成果物はステークホルダのうちの誰と合意し、誰の承認を得るものかを明確にする。
スケジュール
過去実績、推定値に安全係数を乗せた形でスケジュールを作成。
レビュー、部門間調整、承認にかかる期間を織り込むことを忘れずに！
成果物の作成にかかった時間と同じくらいレビュー・承認にも時間がかかるという感覚をもっておくのが無難であり、だいたいレビュー・承認の時間が十分に取れずに遅延が発生したり、スケジュールに間に合わせるために品質が低下したりと悪循環を招くリスクが非常に高い！！
成果物個別に修正工数を見積もるのは難しいため、要件定義後半にまとまって修正のみを実施する期間を設けることがコツ。
スケジュール作成におけるポイント①
タスクの長さとクリティカルパスを意識した計画を立てること。
スケジュール作成におけるポイント②
要件定義の工期と工数は全体工期・工数または開発工期・工数から目安をはじく。
費用見積
生産量（システム数や機能・画面数）×生産性（各成果物の作成にかかるコスト）×補正（人による差異）で求める。
体制
タックマンモデルを意識（成立➡動乱➡安定➡遂行➡遂行➡解散）
体制が良ければプロジェクトは大概うまくいく！不安定な時期があっても”そういうもん”と割り切ることが乗り越えられるポイント！
品質計画
“見た目の品質が高いこと“と”要求に対する漏れがないこと”
この２つを観点にして品質を点検をしていくと良い。ただし、前提として最初にどのような状態になったら要件定義が完了するかを計画し合意しておくことが肝！！
コミュニケーション計画
誰と（ステークホルダー）何で（打合せ？メール？）どのような内容をどの頻度で報告するかを決める。
合意形成の積み重ねが要件定義において何よりも重要！
レビュー１つとっても、成果物を最後にまとめて合意しようとしない。
「叩き台」のつもりで作成し完成度60%程度で見せて、方向性の確認をしていくことが重要。よく失敗するケースとして、「100点です、レビューお願いします」というスタンスでいくとレビューでボコボコにされ、レビュー時間も想定を超え、指摘対応で工数が取られ、遅延を招くことである。
「まだまだ未完成ですけど、いったん見てください。」このスタンスはあらゆる仕事の進め方でも通じる方法であるが、要件定義も例外ではない。
リスク
２つのリスクを認識する。
１）プロジェクトリスク（開発チームの観点）
品質低下、コスト超過、納期遅延などのプロジェクト失敗の原因になりうる要素
２）プロダクトリスク（ユーザ視点）
取引先や得意先への支払漏れ、個人情報漏洩などの重大障害となる機能不備を招く要素
調達
要件定義はあくまでユーザ（顧客）が主体であることを忘れてはいけない。ベンダーはそのことをしっかりと顧客に認識させる。
再構築案件の場合、現行仕様の理解不足が頻繁に起こりえる。
そのため、要件定義の前に現行仕様を調査し分析する行程を設ける。
プロジェクト計画の作成
このプロジェクトにおけるルール決めを行う。
どういう状態になったら要件定義は終了（クリア）とするのか、完了判定とするのか。
自分たちのルールブックを決める。そうでなければ、誰も判断ができなくなる。
監視・コントロール
要件・スコープ
一番重要といってもよい。
多くの要求から最も価値のあるものをいかに選択して制約の範囲内に収めるがが重要。
要件定義のいまどの段階かを意識して運営することが重要。どの段階かで進むべき方向性は変わってくる。
「工程の最後になって要件が増えています。このままでは開発期間に収まりません」と報告するのはNG。工程の途中途中で規模を測り、要件定義の進行度合いを測れるようにする。
要件定義前半で十分に意見を拾い上げ、後半で意見をまとめていく。
スケジュールコントロール
この工程はタスクの多くが調査、分析、解決策の立案、ステークホルダとの調整、組織的なオーソライズとなり、進捗管理が難しい。作業ベースのタスクに落ちづらい性質がある。
そのため細かいチェックポイントを設けて、進捗遅れを早期に発見、対処するを繰り返す。
各担当者から実施しているタスクの完了目途をヒアリングし、完了するために必要な条件や情報が何かを確認しながら工程を前に進めていく。
そして、顧客も含めた関係者を絞った実質討議ができる場を設けることで、スケジュールの状態を肌感で捉えられるようにする。
品質
成果物が抜け漏れなく作成されているか？正しいプロセスで実施されているか？
この観点でチェックしていく。
コミュニケーション
レビューのたびに新しい意見が出るなんてことがないようにしなければいけない（収束段階で）
そのために、こまめな合意形成が大原則。
成果物や議事録から意見が発散する原因を探る。
適任者がアサインされていない場合、声が大きい人がいる場合は個別に対処する必要がある。
リスク
特にユーザ側のリスクが顕在化して遅延になることが多い。
ステコミでしっかり事前共有し、プロジェクトオーナーからトップダウンで意思決定をしてもらうように取り計らう。
終結
要求評価
決まらない要件を明確にする、つまり、どのビジネス要求がシステム化要求に落とせていないか
決まらない要件には以下で対処する
１）システム化しないことによる業務影響の確認
➡システム化せずスコープアウト
２）決まらないことへの後続工程への影響の確認
➡後続に影響がでる場合は後続工程の工期も延ばす
完了判断
未決事項の整理。
投資額が不明な場合や納得できない場合は、議論のために延伸することも重要。
未決事項があるなら相応の対策（ステークホルダとの合意やリスク対策の追加・実施）を行う。
未決事項を次工程に申し送りにする基準（スコープに影響しない、業務フローには影響しない、解決する日が決まっているなど）をプロジェクトのルールとして決めておく。
IPA要件定義の進め方
ここまで要件定義の進め方、進めるうえでのポイントなどを超絶簡単にまとめてきました。
理想は、ipaのサイトからダウンロードして読むことをオススメしますが、分量も多いため今回の簡単なまとめが何かの参考になればうれしい限りです。
コメント