要件定義がうまく進まない。
要件定義が期限内に終わらない。
もっと楽に要件定義をやりたい。
要件定義を進めていくと、様々な問題が出てきて思うように進まない事態に悩まされます。
ですが、要件定義を始める前に、準備するだけで結果が大きく変わるコツが実はあります！
ここでは、要件定義を進める上で知っておきたいコツを紹介します。
すでに要件定義に着手中であっても、要件定義の準備ができていたか確認できますので、是非チェックしてみてください。少しでも参考になれば幸いです。
要件定義とは
※要件定義とは何か理解されいる方は読み飛ばしてください。
要件定義とは、プロジェクトの企画構想で立案したプロジェクト計画書に沿って進めるシステム開発の上流工程で、そのプロジェクトの目的を達成するための業務要求を実現するために、システム化の機能要件の抽出と実現可能な要件仕様を決定する作業です。
文章にすると分かり難いため、こちらで要件定義を進める3つのステップについて、図を用いてわかりやすく解説しています。
システム開発のスケジュールが遅れる原因の50％以上が要件定義の不備に起因すると言われています。
3つのステップとは何か、要件定義の進め方、要件定義の失敗事例、失敗しないための7つのポイントを詳しく説明していますので、要件定義に不安のある方はぜひお読みください。
要件定義は準備次第で結果が変わる
要件定義はプロジェクトの最初で行うフェーズですので、お客様との信頼関係もまだ出来ていない時期です。
それどころか、自分の方（システムを構築する側）の体制もメンバーを寄せ集めた知らないもの同士で、各々が様子見の状態というのが本当のところかと思います。
そんな状況の中であっても、プロジェクトを計画通りに進めるため、お客様と共に要件定義を完遂しなければなりません。
しかしながら、「お客様の業務が忙しくて時間が取れない」「要件が決まらない」「課題が解消されない」「要件定義書の作成が遅い」「要件定義書の出来栄えが人によってバラバラ」などの問題が出てきて要件定義が思うように進まない事態になります。
ですが、これらの問題は主に体制や成果物に関する準備不足から発生している可能性が高く、しっかりと準備することで解消することができます。
そこで、体制や成果物を中心に、要件定義を進める上で知っておきたいコツを紹介します。
体制に関するコツ
体制を共有して役割と責任を明確にする
要件定義を開始するにあたって、業務担当（お客様）とシステム担当（システム開発会社）それぞれで体制を組む必要がありますが、各担当者の職務と役割、責任範囲を明確にすることが重要です。
そのためには、要件定義の体制を体制図にしてステークホルダーで共有します。
体制図によって、指揮命令系統と役割、そしてエスカレーションのルートを明確にし、課題解決や報告を円滑に行うことができます。
体制図の書き方とポイントをこちらで解説しています。よろしければ参照ください。
最初からベストメンバーで体制は作られないことを知る
ベストなメンバーで体制を組むことができれば良いのでしょうが、そんなことはまず無いですし、メンバー構成が悪いと嘆いても要件定義は進みません。
プロジェクトがスタートした時点では、プロジェクトメンバーが何をしていいか不明確な状況にあるため、まずはプロジェクトの概要、特に目的や目標を共有して全員が同じ方向に目線を合わせる必要があります。
各メンバーの役割と責任を説明し、具体的な指示を行って行動に移してもらうことから始まります。何を目指しているプロジェクトかを明確にすることで、メンバー各自がやるべきことを考えることができます。
各自の役割と責任がメンバー全員に周知され、それぞれのメンバーの強み・弱みが理解できれば、お互い助け合うことができるチームを醸成できるようになります。
最終的にはメンバー各自がリーダーシップを発揮して、メンバー同士が協力して活動するチームを目指しましょう。
実際に業務を行っている業務キーマンを体制に組み入れる
部長や課長など、実際の業務を知らない役職者だけでメンバー構成せず、実際に業務を行っている担当者（以降、業務キーマンと記述します）を組み入れることが重要です。
ですが、業務キーマンは普段の業務が忙しいため、プロジェクトに時間を割くことできません。そのため、次のコツが必要になります。
業務キーマンの活動時間を作る
どうしても業務キーマンは業務を優先しがちで、要件定義の時間が取れずに予定通り進まないケースがあります。
プロジェクトの対象範囲が広く、複数の業務部門と調整が必要になる業務プロセスの場合は、その調整作業に時間がかかるため、後回しにされる可能性も高くなります。
ですが、業務キーマンが業務を優先することは当たり前の行動です。問題なのは、業務優先にせざるを得ない状態でプロジェクトに参画させていることです。
この場合、業務キーマンの負担を減らすことが先で、プロジェクトに専念できる環境を作る必要があります。
そのためには、プロジェクトマネージャー自らがプロジェクトオーナーや責任者と話し合い、業務キーマンをプロジェクト専任にする、業務の負担を減らしてもらう等、対策を講じてもらうように要請しなければなりません。
また、業務キーマンが安心して活動できるように、業務を離れてプロジェクト専任になることを社内に周知してもらうこと、プロジェクトであっても正当に人事評価されること、プロジェクト解散後に元の職場に復帰できること、などの配慮も合わせてお願いしましょう。
要件が決まらない時はステアリングコミッティを開催する
要件定義を進めていくと課題が出てきます。複数の業務をまたがる課題は、より上位層（経営層レベル）に相談して決める必要があります。
ただ、上位層の方は忙しく、随時相談する時間を取ってもらえない場合が多いため、あらかじめ定期的に相談できる会議を設けることが重要です。
特にプロジェクト全体に関わるような緊急課題については、臨時でも開催できるようにプロジェクト計画段階で合意しておきましょう。
ステアリングコミッティの会議はこちらで説明しています。よろしければ参照ください。
情報システム部門をメンバーに入れる
もし、お客様の社内に情報システム部門があるにもかかわらず、情報システム担当者がアサインされていない場合は参画を要請しましょう。
対象業務に精通した情報システム担当者がメンバーに加わることで、現行システムを運用している立場や業務に関する知見からアドバイスをいただけます。
業務キーマンでは見えない社内外のシステムとデータ連携していることもあるため、ステークホルダーから情報システム部門を漏らさないように注意しましょう。
成果物に関するコツ
作成する成果物を決める
プロジェクトの特性や規模によって、必要となる成果物や書く内容の粒度が変わってきます。
成果物はプロジェクト活動の対価でもあるため、要件定義を開始する前に、何を作成するのか、記載内容の基準や粒度はどうするのかを定義してお客様と合意しましょう。
成果物の作成者を決める
要件定義で作成する成果物を決めたら、それぞれ誰が作成するのかを決めましょう。
要件定義はお客様主体とはいえ、ドキュメント作成を請け負うことが多いと思います。その場合、作成者はシステム開発会社のメンバーとし、レビュー担当者をお客様（業務部門）に決めてもらいましょう。
成果物の承認者を決める
要件定義で作成する成果物の完了を合意するために、成果物の内容を承認する人が誰かを明確にする必要があります。
対象範囲が広い場合は、業務部門ごとに承認者が必要になると思いますが、漏れずに選出することが重要です。
また、承認時は成果物の内容を説明する時間も必要なことから、レビュー日程のスケジュールもあらかじめ決めておきましょう。
成果物の出来栄えを統一する
特にお客様にドキュメントを作成いただく場合、様々な業務部門の方がおり、スキルの違いから作成されるドキュメントに個人差が生まれます。
作成されたドキュメントにバラツキが出ないように、事前に下記の対策を検討しましょう。
- ドキュメントのフォーマットを決める
- 書き方のサンプルを提示する
- 書き方の説明会を実施する
- 初回は関係者でレビューを実施する
プロジェクトに合った要件定義のやり方を見つけよう
要件定義のやり方のコツは、まだまだ他にもあると思います。もし新たなコツを見つけたら、今後のプロジェクト活動のために社内で共有しましょう。
プロジェクトは生き物だと思います。どれひとつ同じものは無く、それぞれやり方は異なるはずです。つまり、要件定義のやり方に正解はありません。
今回紹介した要件定義のコツを参考に、自分が参画するプロジェクトに合ったやり方を見つけ出してほしいと思います。
もし要件定義に少しでも不安がある方は、要件定義の記事をまとめていますので、こちらもあわせてお読みください。要件定義が計画通りに完了することを願っています。
