要求開発の発展と展開、そして課題

要求開発の発展と展開、そして課題

株式会社匠 BusinessPlace
代表取締役社長萩本順三
http://www.takumi-businessplace.co.jp/

www.takumi-businessplace.co.jp

要求開発における１０の普遍的価値

2

その１：要求開発４象限

ユーザ企業・IT企業共通
・ビジネスとＩＴを繋げる考えがベースにある
・ビジネス戦略、ビジネス改革の手法に発展できる可能性

ＩＴ企業（ＩＴ企業の変革、エンジニアの意識改革に使える可能性）
・開発会社の従来の視野をユーザ業の視点まで広げる
・ビジネスの視点からエンジニアリングを再構築
戦略・要求オペレーション

ユーザ企業ビビジネスビジネス
の視点ジ戦略オペレーション
ネ
ス表（価値） What How 裏（実現）
What 表（価値）

裏（実現） How
開発会社のシ
従来の視野テ
ムシステム要求システム設計

Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved. 3

その２：コタツモデル
～要求をコタツで形成～
要求は、あるものではなく、開発するものである
業務理念を統制し、業務効率化を図るための
業務とは○○あるべきだ。
しかし現実は△△だから、それをどう改善でき
るか現場と話し合ってみよう。

オーナの論理
本当に求められている業務の姿我々のやり方がベストだと思ってい
を経営や現場と、きちんと確認たけど、見方を変えれば欠点が多
しないと、あるべき業務やシステいね。
ムの要求は導き出せない。問題の視覚化(モデル)ともう少し業務のあるべき姿を考えて
改善プロセスによる活動みよう。

コタツ
開発された要求
開発担当者の論理業務担当者の論理モデル
Copyright(C) 2012 Takumi Business Place Corporation All Rights Reserved.
動機編より抜粋 4

その３：要求のロジカルな落とし込み

オーナーや業務担当者から聞いたものをいきな
り要件に落とし込まない。

要望要求要件
オーナーやユーザーからのオーナーやユーザーからの合意された要求に対して
リクエスト要望をとりまとめ予算、スケジュール、可能
但し、それを実現して本その目的、効果、妥当性性を検討して、
当にメリットが得られるのを検証して、関係者が合実現すべき、業務、システ
か、実現可能なのか等の意したあるべき姿ムを定義したもの
裏打ちはない

要求の爆発を防止


その３：要求の構造的な階層化
要求を上位・中位・下位で関係付けて見える化
できる枠組みがある。

ビビジネスビジネス
ジ戦略オペレーション
ネ
What 表（価値）
裏（実現） How
シ
テシステム要求システム設計
ム

要求開発４象限
戦略要求業務要求 IT要求
利用代理店IDが
システム開発費
利用代理店IDが
業務負担の増大することを
維持費の削減
増大することを
軽減見込したID管理
見込したID管理
学生サービス
の重点拡充商品管理の○○を
××に改善する
標準業務モデル ○○による
の確立業務システム構築
○○視点での
安心品質の確保使いやすさ重視

新サービスビジネスモデル業務支援
の早期確立システム構築

要求分析ツリー

その４：コタツモデルの本質的価値
コタツ形成は、チームの役割だけを示すもので
はない。参加者全員が３つの視点を持つ事。

戦略的将来の価値を
視点取りに行く傾向

業務部門に戦略的視野
を身につけさせる。

IT活用のビジネスにとって業務問題現在の価値を
価値のある取りに行く傾向
視点要求・要件解決の視点
戦略部門に現場の問題
課題を理解させる。

これによって、要求（戦略・業務・ＩＴ）を広い視野で考え、取捨選択
するための基礎が形成される。

その５：コタツは、結果イメージの予測を加速
• ビジネス戦略と業務を見える化しながらIT要求を出し、開発
を進めていく手法の可能性匠メソッドビジネスアジャイルメソッド
• 企画を高速に回す可能性匠メソッド匠Method for Service

戦略的
ビ視点
ジオーナ
ネ IT活用の業務問題
ス業務担当
視点解決の視点
戦略的
視点
シ
ス
テ
ムシステム担当

IT活用のビジネスにとって業務問題
価値のある
視点解決の視点
要求・要件


その６：要求開発は仕事力向上のヒント
ビジネス戦略企画戦略／プロモーション
ビ
ジ
ネ
スＨｏｗの手探り

Ｈｏｗからの突き上げ
シ
スＨｏｗのチューニング
テ
ム
システム要求システム開発

○企画戦略段階における戦略ビジネスリスクマネジメントの向上
1.イノベーションの向上
2.実現性の早期発見

匠Think 用語より …要求開発の中で創り出された重要な言葉を通して教育を行う体系

●「戦略と実現の線上にしか価値は存在しない」
●「制御可能で制御価値の高いものから手をつける」
Ｈｏｗの手探り：企画段階から製品の価値や実現可能性を探る
Ｈｏｗからの突き上げ：企画段階から技術面からの製品価値の向上を即す
Ｈｏｗのチューニング：技術的試行錯誤を早い段階で繰り返し価値向上を図る

その７：要求開発は切れていたものを繋げる仕組み
切れていたものを、繋いで、並行でスピーディに回す。
ビジネス戦略企画戦略／プロモーションオーナ
ビ
ジ
ネ
スＨｏｗの手探り人と人業務担当
システム担当
シＨｏｗからの突き上げ
ス
テＨｏｗのチューニングオーナ企業
ム
システム要求システム開発
業務運用
子会社

IT子会社

企画・戦略部門会社と会社
営業部門
組織と組織

開発部門業務部門戦略
思考と思考目的

実現手段
実現手段


その８：コタツの究極の本質は２つの視点の導入
戦略的
視点
匠メソッドキャリア開発

匠メソッド業務改革
for Service
匠メソッド要求開発 for Product
IT活用の業務問題
匠メソッド匠Think
ビジネスにとって
価値のある

システム開発時業務改革
要求開発時スキル開発時
現場力向上

将来価値戦略を考える業務のあるべ将来の自分
の視点き姿を考える戦略を考える

現在価値現状の問題現状業務の現在身につけ
の視点解決を考え問題解決をるべきスキル
る考えるを考える


その９：目的と手段の構造を持つモデル体系がある
ビジネス戦略
ビ戦略ビュー
ジビジネス戦略
ネ
スプロジェクト戦略

サービスビュー
プロセスビュー情報ビュー
ビジネス要求
ビジネス・プロセスオブジェクト
モデル

Ｉ
Ｔアプリケーションシステム要求データ
シ・プロセスモデル
ス
テ
ムアプリケーション
フレームワーク
実装アーキテクチャ


その１０：システムに繋ぐ明確なプロセスがある

準備立案デザイン移行

立上げ現状分析改善検討業務改善

ゴールの合意
見える化見える化システム化
・
仮説設定（現状モデル）（新モデル）要件定義

プロジェクト
課題分析評価ＲＦＰ
計画作成


要求開発を適用したビジネスの課題

• なかなか要求開発からシステム開発に繋
ぐ案件が少ない。
• 大きなウォータフォール開発となりがち
。
• どこでも、なんでも使えます的。


匠Method
要求開発を発展させ
ビジネス価値の見える化に挑戦

15

Why 匠Method.
• 要求開発方法論を更に洗練化
• 契約主導：要求開発方法論と開発方法論のセット化
• 価値主導：ビジネスアジャイル要求開発
• 要求開発を幅広く活用可能とする
• 業務改革要求開発
• 要求開発による製品開発メソッド（匠Method for Product）
• 要求開発によるビジネス企画メソッド（匠Method for Service）
• ビジネス視点でＩＴを開発するための
• キャリアデベロップメント
• 価値を見える化するためのガイドライン
• 匠ビジネスエクスペリエンス
• 要求開発的思考法
• 匠Think
リスクマネジメントとイノベーションのための発想法、思考法のトレーニング


匠Think

プラクティステンプレート

匠メソッドガイド

匠プロセス要求開発プロセスキャリア開発ガイド

システム開発プロセス教育体系ガイド
ビジネスアジャイル開発プロセスサービス開発ガイド
業務改善プロセス

匠Method for Service 最新・独立

匠Method for Product 最新・独立

匠テクニカルモデリング

ビジネスエクスペリエンス

匠メソッドの構成要素

匠Think 匠メソッドやガイドに共通する基本的な思考パターンを示したもの

匠メソッド匠プロセス要求開発プロセスビジネス価値を産むための要求開発実施プロセス
（手順）要求開発の後のシステム開発についてのプロセス
システム開発プロセス
ビジネスアジャイル開発プロセ要求開発とシステム開発をアジャイル（俊敏）に実施するプロセス
ス
業務改善プロセス要求開発によって業務改善をおこなうプロセス

匠Method for Service 要求開発によるビジネス企画のためのプロセス

匠Method for Product 要求開発による製品開発プロセス

匠テクニッモデリングビジネスやシステムを抽象化によって見える化する
クユーザーの視点でビジネスやシステムをデザインする
ユーザーエクスペリエンス
（技法）
匠ガイドキャリア開発ガイド要求開発の実施に必要な人材像を示す

教育体系ガイド要求開発の実施に必要な教育体系を示す

サービス開発ガイド要求開発によるサービス開発の進め方を示す

プラクティス要求開発を成功させるためのポイントを成功事例を踏まえて説明

テンプレート匠メソッドで用いる様式集


やるべき事とは
匠Think

戦略と実現の線上にしか価値は存在しない

価値
できるだけ
前段階で！企業による分断
戦略

業務組織による分断

IT活用
職種による分断

IT実現


要求開発活用の気付き（製品開発の場合）
コタツの応用
壁を壊して、合意形成の場を形成する
トップ＆製品企画部門

戦略的
視点

技術活用のビジネスにとって
価値のある
業務問題
開発部門企画営業部門


経営・業務改革の考え方として
（将来の価値と現在の価値）

戦略的
視点将来の価値

業務問題
現在の価値
解決の視点


そもそもの原点：製品の要求とは！

ユーザ
HowからWhatの創出
何を必要としているのか何を必要としているのか
（Whatの流れ）（Whatの流れ）

Howの手探り

Howのチューニング方
向ニーズとシーズの
性
バランス（調整）

Howからの突き上げ
製品 Howからの突き上げ
ビジョン

製品コンセプト

製品アーキテクチャ
シーズからニーズを描く：情報洪水時代（情報過多）に最も必要な事！


経営・業務改革の考え方として
（価値を描いて作る）
描く力

価値

戦略

業務

機能

構造

作る力
オブジェクト指向要求開発匠メソッド
方法論Drop 1997 方法論2005 方法論2009


匠Method for Service
（企画のための要求開発）

• モデル・ビューとは、サービス企画段階において、様々なビュー
（視点）で、サービスの価値や機能および構造を見える化する
ためのフレームワーク。
• まずは見える化するためのフレームワークを確立する事が何よ
り重要
モデル・ビュー（基本）の全体像

組織ビュードメインビュープロジェクトビュー

価値モデル

業務モデル

機能モデル


匠Method for Product
（製品企画開発メソッド）

• モデル・ビューとは、製品企画段階において、
様々なビュー（視点）で、製品の価値や機能お
よび構造を見える化するための枠組みの事。
モデル・ビュー（基本）の全体像

ユーザビュープロダクトビュープロジェクトビュー

価値モデル

業務モデル

機能モデル

構造モデル


ビジネス企画への活用
匠Method for Serviceのご紹介


匠Method for Serviceの目的/活用範囲

• 匠Method for Serviceは、要求開発方法論のコンセプトを活用し、サービス（業
務・システム等）の企画段階において価値のある企画をスピーディに行うためのビ
ジネス企画のための標準的手法です。

• 匠Method for Serviceが有効な状況
– 新規ビジネス企画における有効性
• 新たなビジネスを立ち上げる際に、全体的な視野を持ち、ステークホルダの価値を形にしなが
ら、関係者感で共感していくためのプロセスが明確になる。
– 継続的ビジネス企画における有効性
• 企画を行ったが、「魅力的な内容」、「企画対象の特徴や強み」といった観点で考えた時に、
企画の進め方に何か問題があるように思えている。
• 企画自体に属人性があるために、人によって企画としての表現や質が大きく異なっている。
• プロジェクトがいつの間にか立ち上がり、価値の評価が行われずに企画が進む。
– システム企画における有効性
• 企画が手間取り、開発が遅れがちになる。
• 企画の狙いがぶれている状態で開発が進み、結果的に要求定義に後戻りすることがある。


ライセンス体系
• 匠Method for Service
– イントロダクション（無償部分）
• モデルの全体像と、それぞれのモデルの概要説明。
– ドキュメント解説編（ライセンス有償）
• 個々のモデルの詳細な説明とモデル同士の関係性。
– サンプル編（ライセンス有償）
• モデルのサンプルドキュメント。
– テーラリングガイド（ライセンス有償）
• 企画の特性に対して、カスタマイズするためのガイド。
– コンサルティングガイド編（ライセンス有償）
• 社内で匠Method for Serviceを実施するためのコタツ形成の方法
、問題意識の持ち方、それぞれのセッションでの意識の持ち方、質
問に対する答え方等、ファシリテータ― or コンサルタントのノウハ
ウを纏める。


使用法

• 匠Method for Service
– トライアル２４Ｈ
• ２４時間（振り返り含めて約６日間）
• 案件にて実践するサービスを提供

• ケース１：比較的小さな案件では、開発まで繋げる
• ケース２：大きな案件では、要求開発の準備フェーズとして活用


ドキュメント全体体系
◆ビジネスユースケース図 ◆システムユースケース図
◆SWOT分析シート ◆BSC戦略マップ
○ ○ システム

○○社
商品一覧参照する

組織在庫の確認を粉う
在庫担当

ビュー
顧
客

商品を購入する

売上集計を粉う

会計担当

◆ステークホルダリスト ◆ステークホルダ価値関連図 ◆ビジネスコンテキスト図 ◆業務モデル（AsIs,ToBe） ◆概念モデル

ドメイン
ビュー

◆要求分析ツリー ◆プロジェクトゴール記述書 ◆プロジェクト初期プラン ◆プロジェクトシート

プロジェ
クトビュー

30

ドキュメント全体体系（モデル・ビュー）

●…匠オリジナルモデル
説明
●…要求開発等により一般的なモデルを拡張
●…一般的なモデル

ドメイン(問題領域)
組織ビュープロジェクトビュー
ビュー
●ＳＷＯＴ分析シート ●ステークホルダ分析 ●プロジェクトシート
●匠ＢＳＣ戦略マップ ●ビジネスコンテキスト図ープロジェクトビジョン
ープロジェクトミッション
価値の
モデル ●要求分析ツリー
●ステークホルダ価値関連モデル ●プロジェクトゴール記述
●プロジェクト初期プラン

●業務モデル（As-Is）
業務 ●業務モデル(To-Be)
モデル ●概念モデル

●ビジネスユースケース図
機能 ●システムユースケース図
モデル


ドキュメント概要説明（１）

ドキュメント名説明書き方ポイント

◆SWOT分析シート・ビジョン、SWOT分析、戦略テーマ ○ビジョンは組織として目指したい方向性
をまとめたもの。を３～５記述します。
プロジェクトごとに記述は多少異な
るが、一度書いていれば再利用可能。
組織
ビュー
◆ 匠BSC戦略マップ・戦略を財務、顧客、内部プロセスまで ○顧客戦略以降は記号を付けて、要求分析
落とし込むためのシート。ツリーと対応を取るようにします。
ＢＳＣ戦略マップを改造して活用します。 ○詳細戦略は要求分析ツリーにて深堀しま
プロジェクトごとに記述は多少異なす。
るが、一度書いていれば再利用可能。

※匠Method for Service イントロダクション編より抜粋


ドキュメント概要説明（２）

◆ステークホルダリスト
・プロジェクト関係者からビジネス関係者まで、 ○プロジェクトが関係するビジネスのキー
主要な利害関係者を洗い出し、整理します。となる関係者、および、プロジェクトに
・業務フローのレーン、価値相関図のステーク直接的に関わる関係者を洗い出します。
ホルダに（一部）使用します。

○あくまでビジネスの全体像を掴むことが目的
・ビジネス上重要な企業および関係者についての図ですので必要以上に細かく記述しないで
◆ビジネスコンテキスト図
ステークホルダから抜粋して、ビジネスの根ください。その中で本質的に問題と思われる
幹となす主要なモノやコトの流れを捉えます。個所や改善点なども説明吹き出しで説明する
とよいでしょう。
○細かな業務フローを書く前に、書くことがポ
ドメインイントです。業務フローでは、ビジネスの大
ビュー枠を掴みきれないことがあります。

・プロジェクトテーマを成功に導くため ○これはシステムを開発したが、関係者が
◆価値関連図使ってくれないといったリスクを初期段
に重要となるステークホルダの人達が
ビジネスに参画する際のメリットを洗階から見抜くためにシミュレーションし
い出し、ビジネス価値という観点でリます。これにより、行き詰まる場合は企
スクがないか事前検証します。画的な問題があります。

◆業務モデル
○AsIsの大きな問題個所については、要求分
(AsIs、ToBe) ・現状(AsIs)は現状業務の問題個所をフローで析ツリーの問題エリアの記述と対応するで
表します。しょう。
・新(ToBe)は新業務をどのように行うか大ま ○ToBeの新業務およびシステムについては、
か要求分析ツリーのプロジェクト課題エリア
に設計したものを記述します。に対応することになるでしょう。



ドキュメント概要説明（３）

◆概念モデル・ビジネスで使われる用語の意味概念はビジネ ○用語同士の関係性、および全体-部分の関係
スを行う関係者によって解釈が異なることが汎用化-特殊化の関係を見える化するもの
あります。概念モデルにより、用語概念同士であり、データ構造のモデルを作成すると
の関係を明らかにすることで、ビジネス概念いうものではありません。
ドメインの意味を関係者で統一化を目指します。
ビュー
◆ビジネスユースケース図・ビジネス機能とそのビジネス機能を使う ○ビジネス機能はビジネスユースケースとし
○○
人（役割名）を見える化することで、て、ステークホルダはビジネスアクターと
社
主要ビジネス機能とステークホルダの関して表現します。
係を明らかにします。

◆システムユースケース図・ビジネスユースケースの機能について、 ○システムユースケースはITシステムに対
システム的にサポートされるものを、する基本要求を記述します。あくまで、
システムを使う立場から見た単位で記述


システムユースケースとして抜粋し、
記述します。します。
在
庫
在庫の確認を粉う担
当

顧
客

商品を購入する


会
計
担
当



ドキュメント概要説明（４）
◆要求分析ツリー・問題エリアには、プロジェクトで取り扱 ○要求エリアは戦略、業務、ITとできるだ
うべき本質的問題を記述します。け繋げるようにします。
・プロジェクト課題エリアは、プロジェクトで ○要求は１０～２5が適切。あまり数が
取り扱うタスクとなるテーマを記述します。多くなると本質が理解できなくなります。

◆プロジェクトゴール記述・プロジェクトとしてのゴールを約束事として ○ゴールは、３段階程度に期間を分類すると
プロジェ記述します。よいでしょう。
１．プロジェクトオーバービュー策定段階
クト２．プロジェクト企画完了段階
ビュー３．システム開発完了段階

◆プロジェクト初期プラン・プロジェクトの初期段階としてのスケジュ ○できるだけ視覚的に分かりやすく記述し
ールを記述します。ます。

◆プロジェクトシート
・プロジェクトミッション、問題・課題、 ○本プロジェクト当初から少しづつ完成させ
テーマ、ゴールなど、ここまで書いたドキュて行きます。最終的には、プロジェクト企
メントを抜粋して作成します。画書のベースとなるものです。
この段階では、あくまで概略に留めます。



要求開発準備フェーズとしての役割（例：２４Ｈでビジネス外観をHowの手探り）

ビジネス戦略戦略ビュープロジェクト戦略
◆ステークホルダリスト ◆価値関連図 ◆プロジェクト初期プラン

トライアル ◆要求分析ツリー
24Hの範囲

◆ビジネスコンテキスト図 ◆プロジェクトゴール記述 ◆プロジェクトシート

サービスビュー
プロセスビュー情報ビュー
業務・プロセスビジネス要求
◆業務モデル(AsIs、ToBe) ◆ビジネスユースケース図
◆概念モデル
◆業務システムフロー ○○
社

アプリケーション・プロセス
システム要求データモデル
◆基本要求 ◆画面イメージ
◆システムユースケース図
（TFS要求管理）（スケッチフロー）


在
庫
在庫の確認を粉担
う当

顧
客

商品を購入す
る


会
計
担
当


製品企画・開発への活用
匠Method for Productのご紹介

※匠Method for Productは、NDSと共同開発・共同所有しています。


匠Method for Productの目的/活用範囲

• 匠Method for Productは、要求開発をベースとした、製品開発における、プロダ
クトの企画・マネジメント手法として生まれました。製品や、プロダクト（製品群）の
価値を企画段階から描き、プロダクトの発展をマネジメントします。

匠Method for Productは製品開発に3ステップのイテレーションで繋げます。
（匠Method for Serviceはシンプルな企画 1st イテレーションを売りとしている）

• 匠Method for Productの特徴
– プロダクトマネジメントに幅広い視野を与えるユーザの感じる価値？
– 製品企画の価値をデザインするユーザの視点
ユーザのビジネス？
– 製品開発の方向性を見える化する
プロダクトの全体像？
プロダクトの視点
プロダクトの価値？
プロダクトの成長？

プロジェクトの視点ミッション・ゴール

ビジョン


ライセンス体系
• 匠Method for Product
– イントロダクション（無償部分）
• モデルの全体像と、それぞれのモデルの概要説明。
– ドキュメント解説編（ライセンス有償）
• 個々のモデルの詳細な説明とモデル同士の関係性。
– サンプル編（ライセンス有償）
• モデルのサンプルドキュメント。
– イテレーションガイド（ライセンス有償）
• 開発に繋げる３回のイテレーションの流れを説明。
– コンサルティングガイド編（ライセンス有償）
• 社内で匠Method for Productを実施するためのコタツ形成の方法
、問題意識の持ち方、それぞれのセッションでの意識の持ち方、質
問に対する答え方等、ファシリテータ― or コンサルタントのノウハ
ウを纏める。


匠Method for Product 全体体系（モデル・ビュー）
●…匠オリジナルモデル
説明
●…一般的なモデルを拡張
●…一般的なモデル

●ビジネスコンテキスト図 ●プロダクトビジョン ●プロジェクトシート
●ユーザコンセンサスモデル ●プロダクトコンセプト -プロジェクトビジョン
●プロダクト戦略 -プロジェクトミッション
●プロダクトロードマップ -プロジェクトプラン
●プロジェクトゴール記述
価値の ●要求分析ツリー
モデル ●想い図
●ポートフォーリオマルチビュー
●プロダクトバリューシミュレーション
-パンフレットイメージ
-プロトタイプシナリオ
-ユーザライフスタイルデザイン
●ステークホルダ分析 ●プロダクトステークホルダ分析
●ユーザビジネスモデル ●業務モデル
業務
⇒業務フロー ●組織モデル
モデル
●製品体系図
（利用目的別マップ）

機能 ●機能体系図
モデル ●問題・課題分析

構造・アーキテクチャモデル
モデル

匠Method for Product（価値・機能）主要モデル・トレーサビリティマップ

ユーザコンセンサスモデルプロダクトプロジェクト
ビジョン・コンセプトビジョン・ミッション
主要ビジョンプロジェクト
ステークホルダコンテキストプロダクトビジョン
と戦略への想い投入
の抽出強化点のコンセプトと戦略
コンセプト化のトレーサブル

主要
ステークホルダプロジェクト
の抽出への絞り込み想い図
プロジェクト
ビジネスコンテキスト図プロダクト戦略への想い投入
（ビジネス関係者）（匠BSC戦略マップ）
あたり前機能
・企業向け差別化機能戦略的機能
・ビジネスモデル廃止・強化機能
コンシューマ要求分析ツリー
向け要求・解決策要求

ステークホルダ分析機能体系図


匠Method for Product （業務・機能）主要モデル・トレーサビリティマップ
市場から見た
プロダクト価値
の評価
業務・組織

ポートフォーリオプロダクトロードマップ
マルチビュー
プロダクト
全体プラン評価
業務モデルプロジェクトシート
添付

業務・組織
開発
の評価/改革
プラン
ユーザビジネス製品体系図
モデル組織モデル
ユーザビジネス
から見た製品プロジェクトプラン
系列・機能の
評価
プロジェクト
の目標設定
製品ごとの機能体系
の評価機能体系図プロジェクトゴール記述


ドキュメント概要説明（１）
◆…匠オリジナルモデル
説明
◆…一般的なモデルを拡張
◆…一般的なモデル


◆ユーザコンセンサスモデル・ステークホルダの中で、製品を使用する ○現意識には、現在達成しているものや、
ユーザの具合的なイメージとして連想し目指している価値を表現します。
その人が、製品に対してどのような価値 ○新意識では、ユーザの新たな利用サイクルを
を感じているのか、実際の言葉で記述し連想し、そこで形成されるであろう価値を記
ます。その際に、現在の意識と、本来あ述します。
るべき意識を記述します。

ユーザ・製品を展開する上で重要な企業および関係者
○あくまでビジネスの全体像を掴むことが目的
◆ビジネスコンテキスト図
ビューの図ですので必要以上に細かく記述しないで
についてステークホルダから抜粋して、ビジ
ください。その中で本質的に問題と思われる
ネスの根幹となす主要なモノやコトの流れを
個所や改善点なども説明吹き出しで説明する
捉えます。
とよいでしょう。
○本図は、通常は、業務処理の流れを順序的に
説明するものではありませんが、シンプルな
レベルで流れを記述するとよいでしょう。

※匠Method for Ｐｒｏｄｕｃｔイントロダクション編より抜粋


ドキュメント概要説明（２）
説明
◆…一般的なモデル


◆ユーザビジネスプロセス ○コンシューマー向け製品にはビジネスプロ
・製品を使用するユーザのビジネスプロセスセスが存在しないことが多いでしょう。
について業務フローを使って表現します。ただし、コンシューマー向けであっても、
製品を使う際にフロー的なものがあれば、
それを記述します。
○ビジネス向け製品においては、お客様の製
品に関わる業務フローを見える化します。
ユーザ
◆ユーザビジネス情報モデル・ビジネス向け製品において、ビジネスを ○あくまで企画・営業・開発メンバーの業務
ビュー理解するという意味あいにおいて、情報の基礎知識としての情報モデルですので、
モデルを作成し、内部関係者で共有知と用語の関係構造を捉えるというレベルで完
します。結させてください。
詳細すぎるモデルを時間をかけて記述して
も、理解できなければ意味がありません。

◆ステークホルダ分析・顧客のほか、製品開発販売に関わるビジネ ○コンシューマー向け製品とビジネス向け
スの主要な利害関係者を洗い出し、その特製品では、ステークホルダが異なります。
性を分析します。 ○コンシューマー向け製品では、消費者を
カテゴリで区分できる場合は、区分してく
ださい。
○両ビジネス共に、製品販売に関わる関係
者を登場させます。



説明
ドキュメント概要説明（３） ◆…一般的なモデル


◆プロダクトバリュー・プロダクトの価値を描き、あらゆる観点で
シュミレーション評価・検証を行ういくつかの図で構成され
ます。

・製品の評価軸をマルチに構成できる匠BP
で発案された新たな価値評価モデルです。
座標軸をいくつも持てるので、複雑多彩な
◆ポートフォーリオプロダクト構成にも活用できます。
マルチビュー
・製品パンフレットのデザイン評価的な意識
より、その中で構成される「キャッチフレ
・製品パンフレットのイメージを作成し評価ーズ」や主要機能の見せ方について、しっ
します。かり記述し、それを持って次期リリースの
ユーザ価値を評価します。
◆パンフレットイメージ
ビュー
・主に何のためにプロトタイプ開発を行うの
・製品評価を行うためのプロトタイプを行うか、どこまで行うのか、何で評価し、プロ
プロダク際に使用します。トタイプの成果として何を期待し、今後に
トビュー活用するのかを明確にします。
◆プロトタイプ
（共通）（スケッチフロー）

・コンシューマー向け製品では、一般消費者
・製品の新たな価値を描くために、ユーザの製品を使う新たなライフスタイルを見える
の新しいライフスタイルの中で製品が如化します。
何に使われるのかイメージできるシナリオ・ビジネス向け製品については、企業の中で
を描きます。製品を使う新たな業務スタイルを見える化
◆ユーザライフスタイルします。
デザイン・これらはユーザコンセンサスモデルの新意識
を参考に考えましょう


説明
ドキュメント概要説明（４） ◆…一般的なモデル


◆プロダクト戦略・プロダクトの製品戦略を、財務の視点や ○まず製品系列の範囲を決め、その範囲内にて
重要戦略の視点、顧客の視点で整理し、戦略を定める必要があります。
内部プロセスと内部プロセス強化（育成）
に繋げていきます。
一般的なＢＳＣ戦略マップを拡張した、
匠戦略マップを使います。

◆プロダクトロードマップ ○プロダクトロードマップは、外向け（顧客向
・プロダクトにおける開発プランを3年スパン
けパートナ―向け）と、内向けで見せ方を変
程度で見える化します。ここでは、製品機能
え、内向けはより詳細が記述できる形式を使
の開発をカテゴリ分類するだけではなく、ビ
うと良いでしょう。
ジネス機会、ブランディング、営業活動など
（サンプルを参照してください）
プロダクのゴールも見える化し、全体として何がいつ
トビューまでにできているかを理解できるようにしま
す。
◆プロダクトビジョン・コンセプト
・プロダクト戦略の根幹となる、プロダクトのビ ○プロダクトのビジョンやコンセプトの要素は、
ジョンやコンセプトを明記します。プロダクトプロダクト戦略から導き出されます。あるいは
のビジョンは、その製品の根幹となる魅力を継逆に、ビジョンやコンセプトからプロダクト戦
続的に提供するための表現言葉となります。略が導き出される事もあります。
また、コンセプトは、ビジョンを実現するため ○ユーザコンセンサスモデルは、プロダクトのビ
の主要技術・キャッチ的用語で表現されます。ジョンコンセプト策定時に参考となるでしょう。

◆プロダクト
ステークホルダ分析・製品開発や企画・販売に関わる主要な利害 ○ステークホルダ分析と共通させて使用する
関係者を洗い出し、その特性を分析します。ようにしても構いません。
・先に説明した、ステークホルダ分析の中で
製品の開発・企画・販売に関わる主要関係
者の抜粋版となります。


説明
ドキュメント概要説明（５） ◆…一般的なモデル


◆業務モデル・製品における企画・開発・販売の各プロセス ○企画・開発・販売など各部門の連携がうまく
を見える化します。現状プロセスの場合は、いっていないことが多くあります。業務プロ
その問題点を明らかにします。セスの現状と新規を描くことにより、組織の
また、新規プロセスの場合は、改善効果を抜本的改革を行うために活用します。
明らかにします。

・製品企画・開発・販売における組織の全体 ○業務プロセスと同様に、現状と新規を描くよ
◆組織モデル
像を見える化します。いでしょう。

プロダク
トビュー
◆製品体系図・複数製品系列や、複数製品を持つ場合は、 ○製品体系図は、様々な表現方法がありますが、
どこまでを本プロジェクトのターゲットと利用の視点からカテゴライズされた体系図を
するかを決定し、その範囲内にある製品に記述することをお勧めします。
ついて、全体体系を見える化します。

○機能体系図における機能名の欄には、細かな
◆機能体系図・個々の機能ではなく、機能をカテゴライズ化詳細機能を入れないようにしましょう。
し、全体マップに入れていきます。その際にそもそも何をしたいのかという本質レベル
強化機能、新機能、廃止機能等の分類も行いで機能をまとめて、機能概念（大くくりの機
ます。能）を考えてみてください。あるいはあるカ
テゴリの代表的機能を、キー機能として登場
させてもよいでしょう。


説明
ドキュメント概要説明（６） ◆…一般的なモデル

◆プロジェクトビジョン・プロジェクトメンバーの想いをビジョンとして ○プロジェクトのビジョンは、想い図から参考に
／ミッション・
表します。これには、プロジェクトを実施するします。
想いが中心となりますが、プロダクトに関する ○プロジェクトミッションは、ゴール記述や、
想いが入っても構いません。要求分析ツリーを参考にします。
一方、ミッションは、ゴール記述の中で代表的
なものをミッションとします。

◆想い図
・プロジェクトに参画するメンバーのプロ ○ここで使われる想いの領域のカテゴリー
ジェクトおよび製品に対する想いを見えは重要です。これに併せて問題・課題を
る化します。このカテゴリーで分類することも行いま
す。
○想いのモデルは、ビジョン形成に役立てます。
プロジェ
クト
ビュー ◆要求分析ツリー
・問題エリアには、プロジェクトで取り扱 ○要求エリアは戦略、業務、ITとできるだ
うべき本質的問題を記述します。け繋げるようにします。
・プロジェクト課題エリアは、プロジェクトで ○要求は１０～２5が適切。あまり数が
取り扱うタスクとなるテーマを記述します。多くなると本質が理解できなくなります。

◆ゴール記述書
・プロジェクトとしてのゴールを約束事として ○ゴールは、３段階程度に期間を分類すると
記述します。よいでしょう。
１．プロジェクトオーバービュー策定段階
２．プロジェクト企画完了段階
３．システム開発完了段階



匠には誰もがなれるわけではない
匠を目指そうとするものだけに、その権利は与えられる

お問い合わせ： hagimoto@takumi-businessplace.co.jp


要求開発の発展と展開、そして課題

要求開発の発展と展開、そして課題

Recommandé

Contenu connexe

Tendances

Tendances(20)

En vedette

En vedette(20)

Similaire à 要求開発の発展と展開、そして課題

Similaire à 要求開発の発展と展開、そして課題(20)

Plus de Kent Ishizawa

Plus de Kent Ishizawa(20)

Dernier

Dernier(7)

要求開発の発展と展開、そして課題