演題：価値のデザインからはじめるビジネス企画（前編解説）

Copyright (C) 2014 Takumi Business Place Corporation All Rights Reserved （無断複製/転載を禁じます）.

匠Methodで目指す「ビジネスエンジニアリング」

前編

株式会社匠 BusinessPlace

代表取締役社長萩本順三


アジェンダ

• 匠Method概論（前編）

• 匠Method モデル理解のポイント

• 匠Method 演習

• 変革すべきこれまでのスキル

時間１３時～１６時３時間

2

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

3

匠Method概論


4

【解説】


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

これからエンジニアリングは「描いて創る」事

5

価値

戦略

業務

ＩＴ機能

ＩＴ構造

描く力

作る力オブジェクト指向方法論Drop 1997

要求開発方法論2005～2008

匠メソッド方法論2009


6

【解説】この図は私がソフトウエア開発を行う中で開発手法の必要性に目覚め、独自の方法論を作成してきた道のりです。最初は開発方法論（オブジェクト指向方法論Drop 1997）を作成しました。この時、システム要求は業務要求からもたらされるのに、システム要求を最上位する方法論でしたので後ろめたい気持ちが残りました。豆蔵時代にBDA(ビジネスドリブンアーキテクチャ)という言葉と共にビジネス改善を含んだ方法論を作成しました。後に要求開発方法論ver0.6として業界オープンとなったものです。その後、要求開発方法論は要求開発アライアンスのメンバーの皆さんと共に、戦略モデルの強化を図り洗練され、それを基に「要求開発(日経BP)」という書籍になりました。これが要求開発方法論ver1.0です。その後、私は豆蔵を辞め、新しい会社「匠BusinessPlace」を立ち上げ、その中で要求開発方法論の更なる洗練化を行い匠Methodという方法論の体系を創り上げました。その際に、ビジネス戦略の上位に価値を置いたのです。そして、価値＝＞戦略＝＞業務＝＞IT活用という流れで同時並行的に進めていくメソッドを考え出しました。そのメソッドが、匠Method for Serviceと匠Method for Peoductです。


キャリア開発ガイド

サービス開発ガイド

教育体系ガイド

要求開発プロセス

システム開発プロセス

ビジネスアジャイル開発プロセス

業務改善プロセス

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

匠Think(要求開発シンキング)

ガイド

匠プロセス

匠メソッド

モデリング

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

匠テクニカル

匠Method for Service

匠Method for Product

…ビジネス企画メソッド

…製品企画メソッド

強化

7


8

【解説】図は、要求開発から発展した匠Method の全体体系です。現在では、これらの体系を匠Method for Serviceと匠Method for Peoductに凝縮させるようにしています。

匠Method for Serviceと匠Method for Peoductは匠Methodが凝縮された２つの方法論であり、匠Method for Service はビジネス企画方法論、匠Method for Peoduct は製品企画方法論と名付けています。

なぜ、要求開発を洗練させたメソッド群が凝縮された方法論に○○企画と名付けたか？それは、新規ビジネスや製品を作る際のプロジェクトが良い結果を生み出すか否かは最初の段階（つまり企画段階）にあると、要求開発を実践すればするほど痛感したからです。

また、匠Thinkは、方法論を習得するのは時間がかかるという弱点を補うために「言葉」で理解してもらうための言葉集となっています。


技術革新に伴うシステム開発の変化

9

ビジネス企画・運用現状

将来

システム開発

要件定義設計開発テスト

ビジネス企画

ユーザ企業開発企業

ビジネス企画業務設計 IT活用検証運用

ユーザ企業

システム開発開発企業

IT活用設計設計開発テスト検証

プロト提案

ビジネス企画

ビジネス企画業務設計 IT活用検証運用

ユーザ企業

システム開発

開発企業

IT活用設計設計開発テスト検証

クラウド技術

超高速開発技術プロト提案

開発企業の貢献下流（システム開発）から上流（ビジネス）へシフト


10

【解説】現状では「ビジネス企画はユーザ企業」、「開発は開発企業」で行う事が多いですね。本来ならばビジネス企画と開発が近い所で回す必要があるのですが、この２つが切れているというのが日本企業の問題です。これにより負のSierのビジネス慣習（ユーザ企業からシステム要求が出るのを待っている）が蔓延ってしまいました。匠Methodはそのような慣習を断ち切るために必要とされる方法論なのです。

本来ならば図中の将来にあるように、ビジネス企画の中で新しい業務モデルをデザインする中、IT活用の姿を明確に持つべきです。匠Thinkでは、この事を「結果イメージの予測」と呼び、その手段として「Howの手さぐり」を行う必要性を問うています。つまりはIT開発が近い所で回る事でビジネス企画の結果が見えるためにもITチームの存在が必要となります。またイノベーションの事を「Howからの突き上げ」と匠Thinkでは表現します。このイノベーションにもITチームがいることで貢献できるのです。

最近ではクラウド等新しい技術が生まれ、すぐ試せるIT環境が普通に提供されるようになっています。そのような時代だからこそ、ビジネス企画とIT活用（開発）を同時並行的に進められる方法論が必要となるのです。


新時代の企画開発プロセスとマネジメント

要求開発段階システム開発段階

分ける（作業の見える化）

要求開発段階システム開発段階

繋げる（プロセス）

並行で走らせる（チームセル）・Howの手探り・Howからの突き上げ

11


12

【解説】この図は、新しい時代のプロセスとマネジメントの姿を現しています。これまでのプロセスは開発プロセスが中心とされていました。そこで、要求開発というプロセスなどによりビジネスのプロセスを表す必要があります。開発プロセスは徐々に発展はしていますが、まだまだビジネスの標準的なプロセスは未発展と言っていいでしょう。ここまでが図中の「分ける」です。

次に重要となるのは、プロセスのフェーズで活用するモデル（or 活動成果）のインプットとアウトプットを「繋げる」事が重要となります。この段階で、巨大なウォータフォールモデルとなり時代遅れのプロセスとなってしまいました。

近代的なプロセスは、「並行で走らせる」方法を持つプロセスです。言ってみれば、流れ作業からセル型のチームで行うプロセスです。

匠Method for ServiceやProductは、セル型チームで並行で走らせる事でスピード感をもたらしており、様々なプロジェクトで評価をいただいています。

このようにプロセスの概念はまだまだ進歩します。これから非常に重要となる概念なのです。


組織ビュードメイン(問題領域)

ビュープロジェクトビュー

価値のモデル

ＳＷＯＴ分析シート匠ＢＳＣ戦略マップビジネスモデル図

ステークホルダモデルビジネスコンテキストフロー

プロジェクトシートープロジェクトビジョンープロジェクトミッション

要求分析ツリーゴール記述初期プラン

業務モデル

業務モデル概念モデル

機能モデル

ビジネスユースケース図システムユースケース図ストーリーボード

ビジネス企画モデル全体像（匠Method for Service）

価値関連モデル価値分析モデル

価値デザインモデル

• 具体的な図の名称を入れたモデル・ビューフレームワークを以下に表します。

13


14

【解説】図は、匠Method for Serviceの全体像です。モデル（図）を、組織ビュー、ドメインビュー、プロジェクトビューに分類され、さらに、価値モデル、業務モデル、機能モデルというレイアに分類されます。組織ビューとは自社またはお客様企業を見える化するためのビューです。ドメインビューは、ターゲットビジネスを見える化するやめのビューです。プロジェクトビューは、プロジェクトに絞り込むためのビューです。匠Method for Serviceの非常に特徴的なものは価値モデルのレイアとプロジェクトビューの存在と言えます。価値モデルは匠メソッドオリジナルな表記を使います。また、価値モデルにより価値をデザインするだけに留まらず、ビジネス戦略やプロジェクト戦略に繋げ、業務モデルやITモデルで検証を図ります。このことが、これからのビジネスに相応しい価値を生み出し合意形成を得ながら素早く検証するといった、独創的かつ唯一無二となる現代的なメソッド体系を生み出しています。


ビジネス企画モデル全体像（匠Method for Service）

◆SWOT分析シート ◆匠BSC戦略マップ

◆ステークホルダモデル ◆価値関連モデル

◆プロジェクトシート

◆業務モデル

組織ビュー

ドメインビュー

プロジェクトビュー

◆ゴール記述書 ◆初期プラン◆要求分析ツリー

◆ビジネスユースケース図

◆システムユースケース図◆ビジネスコンテキストフロー ◆概念モデル

◆価値分析モデル ◆価値デザインモデル

◆ビジネスモデル図

◆ストーリーボード

15


16

【解説】匠Method for Serviceで使われる図のイメージです。このように匠Method for Serviceは使う図を数枚に制限することでシンプルなパッケージ化を図りました。


ビジネス企画メソッドの洗練化目標

• 価値からデザインする事

– 価値＝＞戦略＝＞業務＝＞IT活用

• スピーディ最短距離で目標達成

– ビジネスマインド志向

– 少ないモデル・少ないアウトプット

• 用途に合わせてカスタマイズ可能

– ゼロベースビジネスに対応

– 小さい企画にも対応

– 企業戦略にも対応（中期計画等）

– システム開発なくとも対応

– 複数企業の改革にも対応

– 個人の課題にも対応

17


18

【解説】匠Method for Serviceはビジネス企画メソッドです。このメソッドを開発した時の目標として、下記を目指しました。

・価値からデザインする事価値＝＞戦略＝＞業務＝＞IT活用….これにより、価値や戦略から業務やIT活用の必要性を把握し絞り込めるようにする

・スピーディ最短距離で目標達成ビジネスマインド志向….できるだけ短時間で関係者を集めて行う事。少ないモデル・少ないアウトプット….少ない情報量により、ドキュメント過多に陥らない事

・用途に合わせてカスタマイズ可能…下記のような案件で使えるようにカスタマイズできるようにしました

ゼロベースビジネスに対応小さい企画にも対応企業戦略にも対応（中期計画等）システム開発なくとも対応複数企業の改革にも対応個人の課題にも対応


モデルトレーサビリティー

19

価値分析モデル価値デザインモデル

戦略要求業務要求 IT要求解決策

要求分析ツリービジネスコンテキストフロー

ゴール記述書ユースケース（ビジネス・システム）

ビジョン

コンセプト

価値

目的

ステークホルダ

機構、構想

プロジェクト戦略上位層

価値の仕組み

業務変更ポイント

業務要求

解決策＝＞アクション

業務、IT要求業務、システムユースケース

業務要求


20

【解説】匠Method for Serviceのモデル（図）は、次に作成するモデルとの関係性を重視しています。この図はその一例です。モデルの中のモデル要素が、次のモデルのモデル要素と意味関係に関係性を持たせているので、対応関係が取れるようになります。実際には、モデル要素に記号や色を使って関係性を定義します。このやり方で、１年以上かかる規模のビジネス企画からIT活用のための要求までのトレーサビリティ（追跡可能）が保証できる事を検証できました。できるだけ必要最低限のモデルで「価値＝＞戦略＝＞業務＝＞IT活用」を追跡可能とし、それによって必要な業務要求やIT要求を絞り込む事ができるようにする。これが、匠Method for Serviceの目標なのです。


戦略ベースプロジェクト（上位モデル・トレーサビリティ）

戦略要求業務要求 IT要求財務ビジョンレベル

コンセプトレベル

目的レベル

詳細レベル

戦術レベル戦術レベル

価値デザインモデル価値分析モデル

ビジョンを転記

コンセプトを転記

目的を転記

業務的な手段を転記

IT的な手段を転記

コンセプトは３つの重要な達成すべき事が表現される！


22

【解説】この図は、上位に位置する２つのモデル「価値分析モデル」と「価値デザインモデル」が、下位のモデル「要求分析ツリー」にどのように繋がる可能性があるかを示しています。このページは、「戦略ベースプロジェクト」の例です。このパターンのプロジェクトでは、絶対的なアイデアがあるわけではなく競業他社に勝つために業務改革を行うなどといったプロジェクトに多いケースです。この場合、価値デザインモデルで検討されたコンセプトは、戦略要求の３つの重大要素として定義されるケースが多くなります。なぜなら、このプロジェクトで重要となる３つの戦略テーマを３つのコンセプトとして価値デザインモデルで検討するようにお願いしているからです。


コンセプトベースプロジェクト（上位モデル・トレーサビリティ）

戦略要求業務要求 IT要求財務ビジョンレベル

コンセプトレベル

目的レベル

詳細レベル

戦術レベル戦術レベル

価値デザインモデル価値分析モデル



目的を転記

業務的な手段を転記

IT的な手段を転記

コンセプトは製品等の最も特長的かつ強み・強化点である部分が表現される


24

【解説】この図は、前のページの「戦略ベースプロジェクト」に対する「コンセプトベースプロジェクト」です。これは、絶対的なアイデアが明確にあるケースです。たとえば、製品企画の中では、他の製品と比較して非常に特徴的で価値のあるコンセプトを３つ上げるようにします。また、業務改革でも明確な勝ちパターンがある場合、それを３つ表します。この場合、戦略要求の下位や業務要求の部分として現れます。なぜなら、そのような光り輝く価値を持つアイデアは、プロジェクトでなすべき戦略の全体からすると、一部分である事が多いからです。ただ、一部分とは言えども非常に重要な注目すべき要求分析ツリーの枝となります。


ソフト開発へのトレーサビリティ

25

ビジネスユースケース図○ビジネス機能モデル

システムケース図○システム機能モデル

ストーリーボード○リアルモデル

要求分析ツリー○戦略のツリー化

ビジネスコンテキスト図○ビジネス外観のフロー化

ビジネス概念モデルビジネス概念語彙の整理

データモデル・オブジェクトモデルシステム情報の整理

■ユースケースドリブン

■アーキテクチャセントリック


26

【解説】この図は、要求分析ツリーからIT活用イメージへ流れる方向と、システム構造に繋げる方向と２つの方向がある事を説明しています。この流れを持っているために、開発会社の手法の超上流メソッドとして匠Method for Serviceが定義できるのです。開発手法と匠Method for Serviceを繋げるだけではなく、匠Method for Serviceを上流に置く事で、既存の開発手法を洗練化する事もできるようになります。なぜなら、要求の絞り込みができたり、IT活用の検証を頂上流で行えたりするために、開発手法がコンパクトな体系で纏められる可能性が高くなるからです。


製品アーキテクチャ

製品コンセプト

製品ビジョン

方向性

何を必要としているのか（Whatの流れ）


Howからの突き上げHowからの突き上げ

HowからWhatの創出

ユーザ

ニーズとシーズのバランス（調整）

Howの手探り

Howのチューニング

匠Method 価値のデザインの原点

シーズからニーズを描く：情報洪水時代（情報過多）に最も必要な事！

27


28

【解説】この図は、匠Methodの考え方の原点にあるものです。シーズからニーズを描く（プロモーション・ブランディング）事。つまり、自分（チーム・組織）が強いと思っている事を、顧客が欲しいと思うような流れを作る事。これは逆の視点で考えると、顧客が欲しいと思うようなものを作るためには自分は何を強くすればよいのか考える事です。この中でシーズの強みを明らかにし、ニーズを見ながら洗練化し、シーズをニーズに転換させるテクニックを持つ事ができれば、この情報過多の時代に迷う事がなくなります。

現代社会では、自分を見失っている企業や個人が多いのではないでしょうか？

このような考えは、己やチームの力を強くします。


匠Methodモデルへマップ

製品アーキテクチャ

製品コンセプト

製品ビジョン

方向性


Howからの突き上げ

HowからWhatの創出

ユーザ

ニーズとシーズのバランス（調整）

Howの手探り

Howのチューニング

シーズからニーズをプロモーション・ブランド化：情報洪水時代（情報過多）に最も必要な事！

ビジョン

◆価値デザインモデル

◆価値分析モデル

価値

目的

ユーザ価値を描き目的につなげる

◆ユーザコンセンサスモデル新意識と現意識

◆要求分析ツリー

戦略要求業務要求

IT要求

ストーリーやコンテキストでシーズからニーズへ転換イメージの確立


30

【解説】匠Method for Service やProductのモデルは、シーズからニーズを描くというこの図の各所の役割を受け持っているのです。たとえば、価値分析モデルの中で扱う「価値（嬉しい言葉）」の表現は、シーズがニーズに転換される所です。なぜならステークホルダの嬉しい言葉は、あくまで自分の考えを通して、ステークホルダの価値を描きます。そのため自分の意識が洗練化されていないとステークホルダの嬉しい言葉も洗練化できません。自分の思考を洗練化しながらステークホルダの嬉しい言葉を考えていくので自然と自分の意識改革につながっていくという経験を実際のプロジェクト実践で私は毎回実感します。また、価値分析モデルの「目的」は、どちらかというとシーズの方向性を表します。この２つの調和を取るのが価値分析モデルです。一方価値デザインモデルは、モデル要素の殆どがシーズ側（自分たちの考えの骨格）にあります。しかし、ストーリーだけは、ニーズを意識します。要求分析ツリーは、シーズ側とニーズ側を描いた後に、その調和の中から導き出す要求となります。


今回の３つのモデルで目的と手段をつなぐ

価値

戦略

業務

システム活用

システム実現

価値分析モデル

嬉しい言葉の価値部分

嬉しい言葉の仕組み部分

■要求分析ツリー

目的を戦略要求へ

嬉しい言葉の仕組みの部分を業務IT要求へ

目的

目的/手段

手段/目的

手段

目的/手段

ストーリーが優先度

ビジョンとコンセプトを戦略要求の橋兄！

■価値デザインモデル


32

【解説】この図は、価値分析モデルと要求分析ツリー２つを例に、「価値-戦略-業務-IT活用」の繋ぎを説明しています。この図で示すように、「価値-戦略-業務-IT活用」は目的と手段の連鎖と考える事ができます。これを繋げてスピーディに行き来する事こそメソッドの目標なのです。このことを匠Think（要求開発活動の中で生み出した言葉集）では、「戦略と実現の線上にしか価値は存在しない」と言っています。つまりは、戦略と、戦略の実現（業務モデル、IT活用）、の繋ぎの中で最も価値が高いものを選べという事です。その事を匠Thinkでは、「制御可能で制御価値が高いものから選べ」と言っています。ここでの制御とは、「変える（開発、業務改革・業務改善）」などの事です。


ビジネス企画の成功のポイント

33

価値創造

企業戦略

業務プロセス

ＩＴ活用

Project戦略

お客様を含む利害関係者が何を持って価値とするかを描き、プロジェクトの目的と繋げる（価値分析モデル）

企業戦略の視点でプロジェクト戦略を洗練化する。

プロジェクト戦略を「戦略要求」、戦術を「業務要求」、「ＩＴ要求」として行動計画に落とし込む。（要求分析ツリー）

業務のあるべき姿を全体プロセスとして描き、あるべき姿がもたらす価値（嬉しい事）を定義する。（ビジネスコンテキストフロー）

上記の業務プロセスの中でＩＴ活用シーンを明確化し、ＩＴ活用によりどのような価値（嬉しい事）が生まれるのか定義する。（ユースケース図、ストーリボード）

Howの手さぐり

Howからの突き上げ（イノベーション）


34

【解説】この図は、匠Method for Serviceのモデルがターゲットとしている領域の詳細です。この中で「プロジェクト戦略」というのが非常に重要となります。プロジェクトを成功させるための戦略は、時間勝負・絞り込みといった観点が入り、すべて行うのではなく、今行うべき事を選別してからプロジェクト計画を立てるという事です。もちろん、その際に「制御価値」つまりは、価値の検証を行うための「Howの手さぐり」を行ってからこれを決定します。

現在のプロジェクトでは、制御可能（今実現すべき量か、実現できる量か？）、制御価値（価値を検証する）とか考えずに、いきなりWBS化(プランを立てる）してしまうプロジェクトも多いのではないでしょうか？

これはPDCAという良質に見える言葉の落とし穴と考えています。

PDCAのPは制御可能で制御価値のあるものをプランすべきであり、そのためには、PDCAのPの前にビジネス企画というPDCAをスピーディに回す必要があるのです。


図１匠Method for Product(製品の現在から未来へ進むための立体モデル定義）

プロダクトビジョン

プロダクトコンセプト

現在

未来

ある時点での製品（群）または製品コンセプトを、現意識と新意識を切り替え仮想ユーザで評価

プロジェクトシート（v01）シート（v02）シート（v03）

ゴール記述（v01）ゴール記述（v02）ゴール記述（v03）

成長

ポートフォーリオマルチビューステークホルダモデルプロダクト戦略マップ ◆価値デザインモデル



◆ユーザコンセンサスモデル

◆プロダクトロードマップ

価値デザインモデルの「ストーリ」との整合性を検証する

◆プロジェクト・シート ◆ゴール記述

◆要求分析ツリー

プロダクト要求の関係性と優先度

◆

◆◆

◆価値分析モデル

◆プロジェクト価値関連図


36

【解説】この図は、匠Method for Serviceと匠Method for Productが未来に向けてどのような部分の役割を受け持っているのか示したものです。この図のように、将来のビジョンに向けて、そこまでの道のりをプロダクトのロードマップと考え、ロードマップのある地点のスナップショットをモデル（図）で表していると言って良いのではないかと考えています。

つまりは、両メソッドはプロジェクトの道のりを立体的な地図として表す事で、道に迷わず、道が変化した場合は、指さししながら組織・チームで強い意志を持って歩んでいける仕組みを作りだす事を目指しているのです。


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

[email protected]

www.takumi-businessplace.co.jp

37

演題：価値のデザインからはじめるビジネス企画（前編解説）

Business

Transcript of 演題：価値のデザインからはじめるビジネス企画（前編解説）