キーワードを軸とした要件定義

要件の確認フェーズにおけるキーワード

要件定義キーワード1

RFPの確認

RFP（Request For Proposal、提案依頼書）は、ユーザー要件や契約条件などがまとめられており、開発側の見積もりやスケジュール感など、プロジェクト基礎資料となります。ただ、ユーザーがシステム開発に慣れていない場合などでは、この類の資料が用意されていないプロジェクトも多く存在します。

背景（システム開発の目的）から押さえる

ユーザー企業が情報システムに精通しているにせよ、そうでないにせよ、ユーザー企業の要求を聞いて、背景を確認することで、ユーザー企業が想定している対処方法よりも、より良い提案を開発側から行うことができる場合があります。また、背景を聞くことで、ユーザー企業が気付いていないシステムの潜在リスクを察知し、別の対処について提案することも可能になります。

開発側はシステム開発のプロなので、要件確認を行う際には、"御用聞き"に徹することなく、システム開発の目的を知り、目的を達成するためにどのような手段をとるのが最良なのかを、ユーザー企業とともに考えていく必要があります。

傾聴スキル

ビジネス（ユーザー企業の業務）においては、ユーザー企業がプロです。開発プロジェクトにおいては、ビジネスのうえで重要視する内容が、何らかの形でシステムやシステム運用に反映される必要があります。システム側の立場にこだわることなく、ユーザー企業の意思をしっかり傾聴する姿勢が重要です。

重要な要件から対処する

プロジェクトでは数多くの要件が発生しますが、粘り強く確認して調整を行えば、個々の要件の優先順位が見えてきます。一説には「100個ある要件のうち、本当に重要な要件は3個程度」などと言われることもあります。逆に言えば、仮に100個の機能が完成していたとしても、ユーザー企業が重要視している数個の機能が未完成であれば、納得感は生まれません。

重要な点を押さえる、というのは、かなり厄介な作業です。そもそも、プロジェクトを開始した当初は、物事があいまいな状態です。また、ユーザー企業の現場担当者（実際にシステムを利用して日々の業務を遂行する人）が重視するポイントと、ユーザー企業の上層部が重視するポイントとの間にギャップが存在することも多いです。

対処方法としては、ユーザー企業との間で、以下に示すような各種の調整をしておくことが挙げられます。

• 要件定義の成果物である「要件定義書」に明記して、確認してもらったうえで作業する
• 「課題管理表」を用いて継続的にフォローし、大きな変更がある場合はスケジュールなどを別途調整する
• システムで対応可能な範囲を、前もって設計書やテストケースを提示して確認してもらったうえで作業する

論点整理力

ユーザー企業との打ち合わせの中で、議論が想像以上に膨らみ、収拾がつかなくなる場合があります。この際の対処方法には、以下のようなものがあります。

• 打ち合わせの議題をレジュメ化して持っていく。前もって分かっている議題であれば、開発側から提案資料を用意し、この提案に沿って推敲（すいこう）できるよう、準備を整えておく
• 議論が活発化する場合は、ホワイト・ボードを利用して論点をまとめ、軌道修正する
• マインド・マップなどの要件定義ツールを積極的に利用する

さまざまな手法や対策があるので、試行しながら自社に合った方法を採用しましょう。

要件定義キーワード2

オープン質問、クローズ質問

背景の確認時には、「どうしたらいいでしょう」などの"オープン質問"を多用する。一方、論点の整理時は、2者択一の"クローズ質問"をしてユーザー企業の要求を明確化する。このように、質問を使い分けることで、要件の漏れを防ぎ、かつ、明確化できます。

直観力

• 聞いた内容が、あいまいで、回りくどくても、本質をとらえる
• （潜在する）リスクを察知する

といったことが素早くできる能力を指します。これらの能力を備えていると、早期にプロジェクトの要点を把握できるため、プロジェクト管理のうえで非常に有用です。多くの経験を積むことで直感が働くようになる、という側面もあるため、プロジェクト管理の経験を継続的に積み重ねる必要があります。

構成力

「プロジェクトの立ち上げによって、どのような影響が生まれるか」など、システム全体を包括して考える能力を指します。システムを稼働させるためには、業務の要件以外にも、運用面やHW（ハードウエア）／NW（ネットワーク）など、さまざまな要素が絡むため、これらの組織構成を把握し、それぞれの担当者の調整を図ることなどが求められます。

提案力

これまで述べてきたスキルを駆使して捕らえたシステム開発の背景や要件をベースにして、対処方法を提案する能力を指します。「その要件では、基幹連携システムの改修も必要です。***という対処方法でどうでしょうか」、「この時期までに手配できない場合は、***のかたちで進めるやり方でどうでしょうか」など、適切な提案を行えることが求められます。

判断力

• この要件は後回しでも大丈夫
• この要件は複数社が絡むので、早めに対処
• 上長判断が必要

などの、各種の判断を行える能力を指します。プロジェクト初期は、特に多くの要件が頻出する時期なので、大まかなレベルであっても、作業内容の調査／見積もり、スケジュール手配、影響範囲の見極め、上長に確認を取ってもらう必要があるかどうかの判断など、複数の判断を同時に行うことが求められます。

調整力

プロジェクトでは、時として予想もしない進展をみせることがあります。自分が管理していない部分でプロジェクトの方針が決まることもあります。こうした場合、ユーザー企業から見た優先条件と、契約、システム、運用などの立場から見た制限条件のバランスを取りながら、適切な担当決めやスケジューリングなどの調整を行う必要があります。さらに、こうした場合でも、プロジェクト・メンバー全体の責任感／モチベーションを維持することが求められます。

このような状況が起こった場合、開発現場は、得てして厳しい状況に陥ってしまいます。しかし、できる限りユーザー企業の立場に立つことが大切です。近視眼的な視野に固執することなく、主張すべきことは主張しつつも、できるだけ気持ちよく作業できる体制を構築することが求められます。また、1人の力には限界があることを理解したうえで、関係者間で最善の対応ができるよう調整を続けることが求められます。

過小評価しない

どのような要件であれ、背景やリスクを確認しないままに過小評価することは禁物です。内容をよく理解し、確認することが必要です。