システム開発や新規事業立ち上げなどにおいて、必要不可欠となる要件定義フェーズ。
前職時代も含め5年以上要件定義に携わってきて、要件定義フェーズの延長や炎上、様々なプロジェクト中で学んだ「落とし穴」とその「対処法」について書いていこうと思います。
目次
①要件を理解・意見できるメンバーがいない
現場のプロジェクトメンバーがプロジェクトの内容を把握しておらず、要件を出す立場のメンバーが要件を把握していない・決められない状況が発生することがあります。
よくある原因の一つとして考えられることが、役員レベルで実現したい目標達成や課題解決に向けて必要なパートナーとなるベンダー選定まで行い、通常業務で忙しい現場レベルの人に突然新しいプロジェクトとして渡されている、というような状況です。
このような状況でプロジェクトが始まると、なにも決められない無駄な会議を開催してしまったり、ふわっとした状態の要件が積み上げられ、結局何も決まらないまま時間が過ぎていってしまいます。
もちろん会社としての目標や課題解決は必要不可欠なことではありますが、プロジェクトを進めていくうえでどのようにすれば上記のような問題を回避できるのでしょうか？
対処法：要件の源にミーティングに参加してもらう
プロジェクトが発足してからしばらくの間は、実際にその要件の源となる企画者本人にミーティングに参加してもらいましょう。
本人がスケジュール的に参加が難しければ、議事録などの資料を連携し、密にコミュニケーションを取って一つひとつ要件をつぶしていきましょう。こうすることによって、後々のどんでん返しも避けることができます。
②終盤にかけて新たな要件が浮き彫りになる
プロジェクトがスタートして、様々な要件を決めていく中でとても重要なこと・今まで積み上げてきた要件の根底を揺るがすような要件が出てきてしまったプロジェクトを経験したことがあります。
例えば、想定していた業務フローと現状の業務フローがかけ離れていて、システム化が困難になってしまったり、取得可能だと想定していたデータが実はどこにも保管されていなかったり。
このような事態が発生することによって、積み上げてきた要件定義が白紙に戻ってしまうという事態も起こりかねません。
それでは、どのようにすれば上記のような状況を避けることができるのでしょうか？
対処法：想定される事項を用いての要件の決定を行わない
ステークホルダーから要件を引き出すために、たたき台として仮の案を想定で作成することは要件定義において必要なアクションです。しかし、その想定の裏を取らずにそのまま要件を決定してしまうと、その想定が覆ったときに要件定義のやり直しをする必要が出てきてしまいます。
要件の確定を行う前に前提条件の中に想定が含まれていないことを十分に確認することが必要です。
③要件が確定したつもりでも設計の十分なインプットにならない
いざ要件定義フェーズが完了し、要件定義で作成を予定していたアウトプットもクライアントOKをもらい、いざ設計フェーズに差し掛かって設計メンバーにアウトプットを共有してみたはいいが、設計メンバーから大量の問い合わせが寄せられ、要件定義メンバーには回答できない内容だったり、設計するために必要な情報が足りていなかったりする状況がありました。
すでに設計フェーズが進行しているなかで、要件定義フェーズで決めるべきだったことが浮き彫りになると、最悪の場合設計フェーズを中断して要件定義のやり直しが必要となってしまう場合あります。そんな最悪の事態に陥らないためにはどうしたらよいでしょうか？
対処法：QAチームからレビューをもらう
要件定義が終盤に差し掛かったら、QAチームにレビューしてもらいましょう。
前提としてチームがレビュー観点やチェックリストを作成していることは条件となりますが、要件定義のアウトプットは、しかるべきレビュワーによって要件の詳細化の度合いや、決定事項の過不足の確認を行ってもらう必要があります。
QAチームが設けられていない場合は後続フェーズの担当者にレビューをしてもらいましょう。要件のフィージビリティも併せて実際の設計メンバーにレビューしてもらうことができれば、要件の詳細化の度合いと併せて、要件の実現性も確認することが可能です。
上記3点は私が過去5年にわたって要件定義を経験する中でよくみられた落とし穴です。これらを気を付けて行うだけでも、プロジェクト延長や炎上のリスクは下がると考えられます。
