人が、企業が、業界が、進化する「要求開発」セミナー開催（２）

2010年11月2日東京銀座で、株式会社ニッポンダイナミックシステムズの主催による「人が、企業が、業界が、進化する『要求開発』セミナー」が開催されました。そのレポートの後編をお送りします。

より価値のある要求を目指す要求開発実践のご紹介

株式会社ニッポンダイナミックシステムズ ビジネスアーキテクト 大泉 美香 氏

ニッポンダイナミックシステムズの大泉氏は、同社が携わった要求開発の実践例を紹介しました。対象はIBMiを使ったアパレル業のシステムで、業務改善のために要件ヒアリングから協力してほしいという案件でした。ヒアリング期間は2ヵ月で成果物はシステム提案書。提案が通ればシステム開発にもつながるという、期待と不安が入り交じる内容です。大泉氏は要件ヒアリングを要求開発の方法論を使って実施しました。

要求開発の実践例を紹介する大泉氏。業務改善のため要件ヒアリングからプロジェクトに参画

要求ヒアリングの流れ

要求ヒアリングは次のような流れで行います。

---

1．プランニング

プロジェクトの計画、コアチームの編成

2．キックオフ

プロジェクトの目的、進め方などの意識合わせ

3．要求ヒアリング

課題・要求のヒアリング、要求の整理

4．中間報告

ヒアリング結果の報告、改善点の意識合わせ

5．業務ヒアリング

原稿業務、改善後の業務に関するヒアリング

6．新業務設計

機能の導出、プロトタイプの作成

7．報告書提出

提案書作成、概算見積もり

---

要求開発ではこれらを、

---

• 準備フェーズ：プロジェクトの全体把握（戦略・要求の可視化、ゴールの策定）
• 立案フェーズ：業務の分析（業務外観の把握と可視化）
• デザインフェーズ：新業務の設計（設計・検証・機能導出）
• シフトフェーズ：システム開発への移行

---

という4フェーズでとらえます。

要求開発の実際

要求開発ではまず経営層を含めたコアメンバーを選定します。そこで活用するのがコタツモデルです。経営、業務、ITの各担当者が膝をつき合わせて議論できる状況を作り出します。キックオフや中間報告などのタイミングでコアメンバーに集まってもらい、認識あわせを実施します。今回のプロジェクトでは社長をプロジェクトに巻き込めたのが大きな成果だそうです。社長にプロジェクトの状況を知っていただいたことから、社長の意向を意識することができたほか、合意も取りやすくなりました。

要求のヒアリングができたら、課題と要求を要求分析ツリーで構造化します。課題、要求、解決策が目的と手段の連鎖でつながっていくことを確認しながら作業を進めます。要求分析ツリーを使うことで、要求の全体構造をとらえることができたそうです。要求のレベル感を合わせることができたほか、重点課題、改善ポイントを絞ることができたそうです。

要求の構造化ができたら、次に方向性を確認します。たくさんの改善ポイントの中から注力する部分を選びます。可視化されたモデルをベースに議論したことから、その場で関係者に確認しながらモデルをメンテナンスすることができたそうです。

課題と要求を要求分析ツリーで構造化

要求開発の効果

大泉氏によると、要求開発には次のような効果がありました。

---

・改善の論点がずれなかった

コタツモデルを最初に確立したことで、認識合わせがスムーズだった。また要求の構造化をすることで改善ポイントが明確になった。

・マイルストーンが明確になった

プランニングの時点でゴールまでの道筋を描くことで、いつ何をすべきか明確になった。中間地点で改善の方向性を定めたことで、作業のポイントが絞れた。

---

今回の成果は大泉氏をはじめとするチームの大きな自信につながっているはずです。大泉氏は「要求開発に少しでも興味がありましたら、どうぞ我々にご連絡ください」と述べてセッションを終えました。

要求開発の全体像と進め方

株式会社匠Business Place 代表取締役 萩本 順三氏

株式会社ニッポンダイナミックシステムズ ビジネスアーキテクト 中村 仁氏、向中野 彰久氏

要求開発の全体像

要求開発は全体としてどのような体系になっていて、実際の現場ではどのように進んでいくのでしょうか。要求開発を実践するビジネスアーキテクトの中村氏が解説しました。

中村氏によると要求開発の実例は日常にたくさんあるそうです。例えば、子供が新しいおもちゃを欲しがっている場合、本当に子供の要求に応えようとすると、「それがどんなおもちゃなのか」「何がしたいのか」「それに価値はあるのか」など、様々なことを考える必要があります。もしかしたら「本当はお出かけに行きたい」のかもしれません。こうした抽象的な要望から具体的な要求を作り出すプロセスが要求開発です。

具体的には、描く力と作る力、そして結果イメージの予測が求められます。そのために必要なツールがHowの手探りとコタツモデルです。Howの手探りとは目的と手段をロジカルに結びつけることです。そしてコタツモデルとは経営的な視点とIT活用の視点と業務運用の視点をバランス良く取り入れることです。

要求開発の4つのフェーズ

要求開発は4つのフェーズから成り立ちます。

---

・準備フェーズ：戦略モデルの策定

プロジェクトイメージを確立し、ゴールを策定させるための手探りをする

・立案フェーズ：業務モデルの立案

業務の見える化を計り、プロジェクトゴールを洗練させる

・デザインフェーズ：新規業務モデルの設計

新しい業務モデルをモデリングする

・シフトフェーズ：要求モデルの策定

ビジネスからシステムへの橋渡しをする

---

準備フェーズ

続いてビジネスアーキテクトの向中野氏がこれらのプロセスの詳細を説明しました。まず準備フェーズです。この段階ではまずプロジェクト組織の編成を行います。コアチームはコタツモデルにより、戦略的な視点を持つ人、IT活用の視点を持つ人、業務運用の視点を持つ人で編成します。そしてこれらのメンバーが膝をつき合わせてプロジェクトの目的と範囲を設定します。そしてその結果をプロジェクトシートとして書き起こします。プロジェクトシートには次のような項目を記入し、プロジェクト全体を捉えます。

---

・プロジェクト名称：匠プロジェクト

・プロジェクトミッション：

1．要求開発をビジネスとして立ち上げる

2．要求開発を社内で普及させ、有効活用する

3．要求開発で社内を活性化する

・背景：

1．経済状況の変化に伴い、受注案件が減少している

2．IT企業としての武器を持ち、差別化を図る

3．社内教育の柱を探している、社内をもっと活性化したい

・期間：2009～2011年の3年間で成果を実感できるようにする

・前提条件：新規マーケットだけでなく、既存マーケットも活性化させる

・制約事項：既存ビジネスへの影響を抑えつつ、新しいビジネスとして立ち上げる

・スコープ：全社員対象、社内外の活動全般

・コタツ組織：

1）オーナー：社長

2）コアチーム：荒井、開発部門長

3）選抜メンバー（メジャーリーガー）

---

プロジェクトシートで決まった目的と範囲に沿ってステークホルダー分析を行います。分析はビジネスコンテキスト図で行い、業務に関わる利害関係者をアクターとして関連づけていきます。対象業務とアクター間の情報やものの流れを記述します。

ビジネスコンテキスト図でモデリング

ビジネスコンテキスト図ができあがったら、ステークホルダーリストを作成します。リストには、重要度、人数、具体例、想定される影響（メリット、デメリット）を想定して記述します。

ステークホルダーリストで重要度を決定

ここまで整理した上で、具体的な課題・要求の分析を行います。この分析には要求分析ツリーを使用します。課題と解決策の間を要求でつないでいきます。課題、要求、解決策、と進むに従って経営から現場に視点が移っていきます。

要求分析ツリーで課題と解決策をロジカルにつなぐ。そして関係者全員で見る

こうしてできあがった要求分析ツリーを関係者が見ることで、対象プロジェクトの要求の全体構造をロジカルに把握することができます。要求分析ツリーを見ながらプロジェクトのゴールを設定します。プロジェクトゴール記述書に、以下の項目を記述します。

---

• 何をすることで
• 何が
• いつまでに
• どうなっている
• 評価尺度
• 目標値

---

準備フェーズの仕上げに、プロジェクトゴール記述書を作成

立案フェーズ

準備フェーズが終わったら立案フェーズに進みます。立案フェーズでは現状ビジネスを「サービス」「プロセス」「情報」の視点で見える化します。サービス構造の視点で見える化する際に、ビジネスユースケース図でモデリングを行います。モデル中のアクターに対して「○○（目的語）を××（動詞）する」という形で振る舞いを記述することがポイントです。さらに、プロセスの視点でビジネスフロー（業務フロー）、情報の視点で概念モデルも作成します。こうすることでサービス構造、プロセス構造、情報構造が可視化されます。

ビジネスユースケース図でモデリング

「○○（目的語）を××（動詞）する」という形で記述するのがポイント

情報構造も可視化

デザインフェーズ

続いてデザインフェーズです。このフェーズでは、あるべき業務の設計と検証を行います。あるべき業務は立案フェーズで見える化した現状の業務と準備フェーズで作成した「要求分析ツリー」から導き出されます。準備フェーズで作成した「プロジェクトゴール記述書」にある施策や課題に関連箇所を特定し、それらを解決するあるべき業務モデルを作成します。

ここで作成するモデルはステークホルダーの覚悟を取り付けるためのものです。もしこの時点で覚悟が取り付けられない場合は、その理由を明らかにし、どういう条件なら覚悟ができるかを明確にします。

あるべき業務に対して合意が得られたら、モデルのシミュレーションを行って検証します。本当にそのモデルで目標を達成できるか、期待する効果が得られるかを確認します。

本当にそのモデルで目標を達成できるか、期待する効果が得られるかを確認

シフトフェーズ

最後がシフトフェーズです。ここではシステム化範囲の導出とシステム要件の文書化を行います。シフトフェーズで大事なのが、ビジネスとシステムの橋渡しです。ビジネス戦略、ビジネスオペレーション、システム要求、システム設計を、WhatとHowの連鎖でつなぎ、実行に移していきます。これまでフェーズでは出てこなかった非機能要件（品質やビジネスルール、制約など）も定義し、システム構想書を作成します。

システム要件の文書化に当たっては、業務要件、機能要件、非機能要件をまとめます。業務要件は立案フェーズ、デザインフェーズでできた成果物を元に、非機能要件はシフトフェーズの成果物を元に作成します。

要求開発の真価とは

要求開発の真価は、「技」「人」「心」をバランス良く扱うところにあります。エンジニアには言語やモデリングのような技が求められます。しかしそれだけで開発はできません。エンジニアが開発するのは人が扱うシステムですから、コミュニケーションやマネジメント、ファシリテーション、そしてコタツモデルのような、人としてのスキルも必要です。この2つだけでもまだ足りません。この2つの要素は本人のやる気や気づきといった心のスキルがあってはじめて生きてきます。

技、人、心の3つの要素がそれぞれ刺激し合ってエンジニアの成長を促していくのが要求開発の真価と言えるでしょう。これまで3回の要求開発セミナーに参加して、NDSのエンジニアの人としての厚みが増していることに気づきました。要求開発という武器を身につけ、エンジニアとして社会に貢献できているという実感が表情にも表われてくるのでしょう。要求開発を通じて魅力的なエンジニアが一人でも増えてくることを期待して今回のレポートを終えたいと思います。

要求開発は「技」「人」「心」の成長を大切にします

情熱あふれる要求開発セミナー運営スタッフの皆さん