こんにちは、豆蔵で要求開発を担当している上山（うえやま）です。
第1回～第2回では、「要求開発」および「要求開発方法論」の概要についてご説明をしてきました。 いよいよ今回からは、家具販売会社の仮想プロジェクトを題材に、具体的な要求開発の進め方についてとりあげます。
今回と次回の２回は、プロジェクトメーキングを行う準備フェーズになります。その後、業務分析を行う立案フェーズ、あるべき業務の設計を行うデザインフェーズ、要求開発からシステム開発への橋渡しを行うシフトフェーズへと順を追って話しを進めていきます。
システム開発を前提とした『要求開発』
（前回の連載から、少し間が空いてしまったので復習しておきます。）
「要求開発」は、中長期的なＩＴ戦略など大上段に構えたものから、ある程度スコープが明確になっているシステム再構築のようなケースまで様々な用途に使用できます。どの様な目的で「要求開発」を行うかにより、プロセスや成果物をテーラリングする必要があります。
今回は、システム開発の前段階で行う「要求開発」です。ここでは、システム化の本来の目的や、業務との整合性を確保した正しい要求を獲得して、システム開発に必要な情報を定義することが主眼となります。
仮想プロジェクト：ReDA家具
ReDA家具販売株式会社（資本金5億円、年間売上高430億円、従業員数1015名）は、製造会社５社、資材会社３社を含む大手家具メーカーReDAグループの中核に位置する販売会社です。ショールームを基軸に、丁寧な接客で顧客ニーズに応じた家具のトータルコーディネイトを提案する企業としてビジネスを展開してきました。
しかし、金融危機以降の個人消費の減退、少子高齢化、低価格を売りにした輸入家具販売やインターネットを通じた通信販売の台頭により、ここ数年は収益の悪化が続き厳しい経営を余儀なくされています。そこで、ショールームを基軸とした現在の販売スタイルを変えていかなければ、生き残れない厳しい状況となってきています。
来年、導入してから既に１５年になる販売管理システムのハードウェア保守が切れます。これを機に、ビジネス改善とあわせ新システム構築を検討することになりました。
情報システム室の木村室長は、社長より販売システムの再構築についての計画を次回役員会に提出するようにとの指示を受けました。 木村室長は、先日コンピュータ雑誌で読んだ「要求開発」という手法を使用してみることにしました。
（→『日経コンピュータ』2009年7月8日号 120頁に「要求開発」記事が掲載されました）
STEP1. チーム作り
先ず要求開発プロジェクトのチーム作りから始めます。
要求開発では、システム開発プロジェクトにおける主要なステークホルダーとして、ビジネス戦略を決定するビジネスオーナー（経営層）、実際のビジネスを遂行する業務担当者、情報システム担当者の三者をあげています。
要求開発プロジェクトでは、経営・業務・情報システムのそれぞれの視座が必要となるので、これら３つの立場からバランスよくチームを編成していきます。チームは、図1のようにプロジェクトとの関わりの深さに応じて「コア・チーム」「プロジェクト・チーム」「外郭メンバー」とします。
- コア・チーム：要求開発プロジェクトの推進役。3～10名程度。
- プロジェクト・チーム：プロジェクト関係者。
- 外郭メンバー：ヒアリングなどのプロジェクトへの協力を要請されている人
STEP2. プロジェクト情報の整理
要求開発プロジェクトを開始するにあたり、プロジェクトの基本情報（目的・背景・期間・制約事項）と、プロジェクトに関係するステークホルダーを整理します。要求開発に限ったことではありませんが、プロジェクトの発足時点で明らかになっている前提条件を可視化し、プロジェクト関係者で共有しておくことはプロジェクト成功の重要ファクターです。
ReDA家具販売株式会社の販売管理システム再構築プロジェクトの基本情報を整理したものを図2に示します。
- 名称：プロジェクトの名称を記述します。
- 目的：プロジェクトの初期段階で明らかになっている目的を記述します。
- 背景：プロジェクトが発足するに至った問題点などの背景を記述します。
- 期間：プロジェクトの期間（from～to）を記述します。
ここには、システム開発プロジェクトの全体に加え要求開発の期間についても記述するようにしましょう。 - 前提条件：プロジェクトの前提条件が存在する場合に記述します。
- 制約事項：リースや保守の期間満了日など納期順守に関わる項目や予算の条件など、プロジェクトの制約事項を記述します。
- スコープ：プロジェクトの対象となるスコープについて記述します。
- 組織：要求開発プロジェクトの体制を記述します。
次に、「プロジェクト定義書」のスコープに従い、プロジェクト及びその結果に対して影響を受ける可能性のある人を「ステークホルダーリスト」を用いて整理します。
システム開発プロジェクトでは、導入時点や最終的なテスト段階になってから、システムに物言いがつくことがあります。この様なケースでは、事前に関係するステークホルダーに十分な説明が行われていないことが多いようです。
プロジェクトを成功させるには、ステークホルダーを正しく認識し、適切なタイミングで合意を取り、一定の納得感を与えながら進めることが重要です。
「ステークホルダーリスト」のテンプレートは、要求開発アライアンスのホームページからダウンロードできますので、これを用いてプロジェクトの早い段階でステークホルダーの分析をしておきましょう。
ReDA家具販売株式会社のステークホルダーリストを図3に示します。
- ステークホルダー名：プロジェクトに関係するステークホルダーを、基本的に役割で記述し ます。
- 説明：ステークホルダーの主な責務、関心ごとなど、ステークホルダーにつ いての説明を記述します。
- 重要度：プロジェクトにおける重要度を設定します。
高 3 － 2 － 1 低 の3段階で表現することを推奨しています。 - 人数：ステークホルダーごとの人数を記述します。
- 具体例：ステークホルダーの代表者を記述します。
- 想定される影響：ステークホルダーごとに想定される影響を記述します。
- レビューポイント：ステークホルダーごとに、レビュー対象が異なるので レビューポイントを記述しておきます。
これでプロジェクトの概要が把握できます。
「プロジェクト定義書」や「ステークホルダーリスト」は、要求開発以外のプロジェクトでも活用できます。ReDA家具の成果物を参考に、皆さんのプロジェクトで作成してみてください。
次回は、要求開発のオリジナルツールである「要求分析ツリー」を使用した業務の課題や要求の分析方法について解説します。
お知らせ
- 日経コンピュータ（2009年7月8日号）に「要求獲得プロセスの効率化」として要求開発についての原稿が掲載されました。120頁です。
メソドロジック山岸さん、ウルシステムズ河野さんと筆者の共著です。
- EM ZERO VOL.4 「要求開発特集号」が発行されました。
「実用段階に入った要求開発」として筆者の原稿も掲載されています。
