私たちパクテラ・コンサルティング・ジャパン（以下：パクテラ）は世界基準のナレッジを有し、デジタル領域に強みを持つグローバルカンパニーです。

大規模のプロジェクトを進めていく上で、従業員のボトムアップが常に求められている現状から、社内研修制度の一環としてITのスペシャリストによるセッション「PETS」を開催しました。

本投稿ではその第１回目の内容をレポートさせていただきます。是非、ご一読ください。

PETSとは？

PETSとはPactera Engineer Training Session のそれぞれの頭文字を取ったITのエキスパートを養成するためのパクテラ・ジャパン独自の社内研修です。毎回、外部講師を招待し、日本のDX化を促進させる上での専門性や思考力をセッションを通じて身に付けてまいります。

講師

川島　義隆　

株式会社ウルフチーフ　代表取締役
大手SIerで20年間、多数のWebアプリケーション開発プロジェクトのアーキテクチャ設計を担当、また社員教育、技術者採用、研修講師などを努め、2018年10月アーキテクチャ設計専業の株式会社ウルフチーフを創業する。その他、技術コミュニティを中心に登壇多数。

テーマ：要件定義

システム、ソフトウェア開発において最初の工程である「要件定義」を川島さんからレクチャーしていただきました。顧客から要求を明確にし、システムに実装すべき機能を整理する上でのポイントをレポートしていきます。

要件定義の必要性

顧客、ユーザーが満足するシステム、ソフトウェアを開発するのは容易なことではありません。昨今の開発時間短縮傾向を受け、各フェーズの時間制約は厳しくなる中で、要件定義を早く済ませ、設計や製造の時間を確保し、細部のカバーは下流工程ですることが現状となっております。

しかし、要件定義に時間をかけることで、ユーザーの要求を捉え、プロジェクトのベクトルを的確に定めることができ、開発の作業効率の向上を図ることができます。

つまり、最初の工程である要件定義がプロジェクトの成否のカギを握っているといっても過言ではないのです。

認識の齟齬

プロジェクトを正しいベクトルで、効率的に進めていくためには顧客の本当に必要としているものを明確にすることが必要であると同時に、困難な点でもあります。その要因として挙げられるのは開発側とユーザー・顧客側との認識の齟齬が生じることです。
顧客が説明した要件（晴れの日に、木が2本ある道路を車が走行する）に対し開発側の認識が徐々にずれてしまい、実際に得られたサポートは微弱なものとなります。さらに顧客自身が、本当に必要なもの（月夜に、木が2本ある道路をトラックが走行する）を分かってないため、要件定義の時点で開発成果が見込めなくなってしまうのです。

顧客が本当に必要なものを説明できてないということは、必要なものが分かっていないということです。そのため、説明をただ鵜呑みにするのではなく、コミュニケーションを通じて顧客事情を網羅的に把握し、相互の認識をすり合わせることが要件定義における最重要事項なのです。

要件定義における3つのポイント

顧客が本当に必要なものを知るためのポイントを整理しました。
本当の問題を見つける、エッジケースを探す、抽象化をする、この3点が要件定義には欠かせない要素となります。
ここからは、それぞれのポイントがどのようなものなのかを探っていきます。

①本当の問題を見つける

顧客の課題を抽出し、最適なソリューションを提供することが開発側の役割ですが、一心不乱に大量の仕事をこなしてバリューを創出することはナンセンスです。
取り組むべき問題が明確になっていないまま良い解を見つけようとするのはアンチパターンであり、時間も工数もかかるため、アウトプットの質も効率も落ちてしまいます。

そのため顧客のインサイトを知るためには、開発側がイシューベースで要件定義に携わり、問題の本質を見極めることが必要です。
問題の解像度を上げ、問いを明らかにすることで目的意識を統一させ、問題（インサイト）を明確にした後、その問いに対して最適な解（ソリューション）を磨きこむのです。

問題１

それでは、「本当の問題を見つける」ことを意識しながら以下の問題に取り掛かりましょう！

問題：混雑するエレベーター
・73階のビルのオフィスは、いつもエレベーターが混雑している
・このビルの入居企業は大体が平日9：00~17：00である
・大体が金融系企業である
・エレベーターの混雑具合に不満の声が広がっている
オフィスビルのオーナーはこの状況に対してどのような行動をとったでしょうか？

２～3分考えてみましょう！

正解は…

エレベーターホールに鏡を置いた

イシューベースで考えてみると、問題は待ち時間が長いことではなく「利用者が待ち時間にフラストレーションが溜めていること」なのです。なので、待ち時間をいかに短くするのではなく、待ち時間に対する不満をどのように緩和するかということが問われているのです。エレベーターの機能をアップデートするなど、技術面で待ち時間を短くすることはできますが、同業の企業が集まるオフィスビルでは、劇的な変化が見込めるとは限りませんよね。

情報を一元的に捉えず、問題を明確にすることで、簡易な方法でユーザーの要求を満たすことができるという良い事例でした。

②エッジケースを探す

問題の本質を見極めるには、顧客からの複数の要求を分類し、曖昧さを無くしていかなければなりません。エッジケースを探す癖を身に付けることで、要求のグルーピングを行い、開発するシステムがどこまでの要求に応えるべきかという機能の範囲を要求の境界線をもって明確化します。

また、エッジケースを探す際には要求のグルーピングと同時に、要求の中に存在する曖昧な要素の見直しやエラーケースの考慮もしなければなりません。

問題２

引き続き、要求の分類や曖昧さの解消を心がけた上で以下の問題に取り掛かりましょう！

問題：ECサイトにおける送料無料サービス
「5000円以上の注文で送料が無料になるシステムを作ってほしい」
顧客から要求されたのはこの一言である。
追加で確認しておくことはあるか？

こちらも2～3分考えてみましょう。

考えられましたでしょうか？確認事項をブラッシュアップできましたら、スクロールして自身の回答と照らし合わせてみてください。

追加で確認しておくこと（例）

・税金は含まれているのか
・5000円に含まれるのは紙の本だけでなく電子書籍も含まれるか
・国際配送もサービスの適用範囲であるか
・配送の優先順位はあるか

顧客からの要求は一見シンプルに見えますが、エッジケースを探してみると曖昧な要素が多く、機能の範囲が明確化されていません。価格の内訳や配送手段に関するそれぞれの定義をより深掘り、それぞれに境界線を設けることで、曖昧だった顧客の要求をクリアにしていきます。

③抽象化

要求のグルーピングを行い、要件を明確にするためにはその判断基準となる抽象概念を見出さなければなりません。
ここで必要な要素は視座を変えることです。視座とは事実を捉える抽象度の高さで、この高さは比較的、役職に比例していますが、視座が高いから良質な概念を見出せているということではなく、顧客からの要求に対して適切な判断基準を設けられているかが重要なカギとなります。

つまり、視座を変えながら抽象度の高低を探り、最適な判断基準を設定し、要求を抽象化するのです。

終わりに

以上が今回のPETSのレポートでした。いかがでしたか？システム、ソフトウェア開発における要件定義は、顧客の本当のインサイトを明確にする重要な工程であることが再認識できました。
パクテラでは引き続き、日本のDX化を促進させる活動の一環として社内研修の内容をご報告させていただきます。ぜひ、今後ともよろしくお願いいたします。