大規模プロジェクトの要件定義をやったのはかなり久しぶりだったので、後学のためにその時の問題点と各問題に対してどんな対策を打ったかをメモしておきます。結構しんどかったです。
前提
- 規模感：400～500人月
- 人数：約10人
- 開発システム：4システム
問題点
- 大規模すぎて要件定義の工数が読めない
- 要件定義で誰が何をやればよいかわからない
- 要件定義中のコミュニケーションにリードタイムが多発する
- 要件定義の経験メンバーが少ない
各問題に対する原因と対応策
大規模すぎて要件定義の工数が読めない
要件定義を開始する前に、全体のマスタスケジュールを引き要件定義をいつまでに完了させるか、を決める必要がありました。ただ、規模が大きすぎるがゆえ、どれくらいまで詰めれば良いかわからず全量の把握も困難だったため、工数が読めませんでした。そのため、JUAS（日本情報システム・ユーザー協会）のソフトウェアメトリクスを参考に大体これくらいかかりそうじゃない？を提案しました。今回だと、20%くらい（80～100人月）を充てた記憶があります。正直見積りあくまで見積りであり、システム開発においてはやってみたら実は、、、、のようなことも往々にしてあるため、この数字を追い求める（多分精緻なものは出せないと思っている）よりは、進めながら完了時期を微調整していく、といった進め方の方が良いのかなと思っています。
要件定義で誰が何をやればよいかわからない
プロジェクト計画の段階で、要件定義フェーズでの成果物定義をしていましたが、これらをどういうどういう体制で作っていくのかが不明瞭でした。具体的には、何となく誰が何をやるかは決まっているものの、なぜそういうアサインでやっているか？が不明瞭でした（何の脈略もなくアサインしていたような気がします）。本来であれば、次フェーズ以降の戦略、計画（開発体制や進め方等）も加味したうえでこのあたりの体制も組むものだと考えています。そのため、開発するシステムや機能、ドメイン領域をより明確にさせ、それ毎にチームを作り次フェーズ以降も基本的にはその体制で進めていく、という方針を打ち立てました。これにり、大規模システムだけど自分の責務はこの部分、この部分なら自分に聞けば何でも答えられる、という状態を作ることで、全員が薄く広く理解しているといった中途半端な状況を作ることを回避しました。
要件定義中のコミュニケーションにリードタイムが多発する
要件定義は、企画の方から出てきた要求ドキュメントをインプット資料として要件定義ドキュメントを起こすという、ごく一般的な手法を採用しましたが、やはりどうしても、ドキュメントを書きながら「インプット資料のこの部分がわからない」ため、企画の人に確認したいといったケースが多発します。このプロジェクトでは、要件定義ドキュメントは基本的にコンフルエンスにまとめていたため（プロジェクトによってはエクセルやパワポでまとめるなどあると思います）、最初のほうはコンフルエンスのインラインコメント機能やページコメント機能を駆使して企画の方に質問を投げていました。ただ、この進め方だとメールやChatと同様にある程度のリードタイムが発生し、要件定義ドキュメントの完成までに時間がかかってしまいます。これを回避するため、日次で企画の方と対面で話をする「要件質問会」的な会議体を設け、その枠で質問をしてその場で解決する、という形をとることでほぼリアルタイム？（日次）に解決されドキュメント作成を円滑に進めることができました。
要件定義の経験メンバーが少ない
こればかりは仕方のないことだと思います。要件定義の目的は何か？どんな成果物を作る必要があるのか？といったことを啓蒙しつつ、過去プロジェクトの要件定義ドキュメントを共有し参考にしてもらったり簡単な機能のドキュメントを書いてもらったりしながら、少しずつ要件定義フェーズでの作業内容を理解してもらうということやりました。
まとめ
要件定義は、顧客からの要求に対して「実現したいご用件（要件）はこういうことであっていますか？」を擦り合わせる作業です。設計や実装のインプットにもなるため非常に重要な作業です（プロジェクトの失敗≒要件定義の失敗といった統計もあるくらいです）。場合によっては、顧客からの要求が曖昧だったりして円滑に進めるのが難しい時もあります。そうした場合でも、適切にコミュニケーションを取り要求を吸い上げ（要求定義をしっかり行い）、問題があればそれを解決するための仕組みづくりを早急に行うことで、円滑に進められるようになるのかなと思います。
以上です。