4.1 何をデザイン対象とするのか
4.1.1 チームデザイン軸と、プロダクトデザイン軸について
SE4BSの価値駆動開発では、匠Methodを使ってチームやデザインを行いますが、まずは匠Methodによるデザインの対象の全体から説明していきます。匠Methodのデザイン対象は、ヒト・モノ・コトとなります。
・ヒト ….企業、部門、チーム、個人
・モノ（製品） …製品
・コト（サービス) ...サービス
ヒトのデザインでは、企業、部門、チーム、個人といった組織又は個人を対象として魅力的な組織・人材創りを行うものです。
また、モノやコトについては製品やサービスを生み出すためのプロダクトデザインが対象となります。
このプロダクトとは、製品やサービスを含む概念のことです。
そしてSE4BSの価値駆動開発では、チームデザイン（ヒト）と、モノとコトを併せたプロダクトデザイン（製品・サービス）という２種類のデザインが対象となっています。
図4.1-1によりプロダクト軸とチーム軸で説明します。
ここからは、皆さんがお客様のプロダクトをお客様のプロダクトメンバーと共に開発していると仮定して説明します。お客様の製品開発で必要とされるのはプロダクトデザインであり、対象はプロダクトが扱う製品ということになります。
つまり製品の魅力を３章で説明した知情意という概念でプロダクトメンバーでデザインすることになります。プロダクトメンバーとは、「図1.7.1 イノベーティブな製品チーム」で説明したようなコタツメンバーとなります。
一方で、皆さんはお客様とは異なる企業の部門内のチームに所属していることになります。ここで必要とされるのがチームデザインであり、こちらも同じく知情意という概念でデザインします。（*注1）
しかし、実際の現場では、図4.1-1のような現場の声が数多く聞こえて来ます。
（*注１）この説明は、自社製品を作るプロダクトと自社の開発チームの関係も含んで説明しています。社外に開発チームがあるケースとの違いは、開発チームが、開発パートナー企業にあるのか、製品を所有する企業にあるのかの違いとなります。
この図のような状態は、プロダクト開発の仕事で、日々バージョンアップに追われて、なかなか技術知識の蓄積が出来なく悩んでいたり、プロダクト開発の際のスキル的な問題があり開発が進まない・非効率という現象が起こっています。
最近の日本の開発現場の多くが、このような状態に陥っているのではないでしょうか。
このような状態は、プロダクト開発における様々なノウハウが足りないことが原因となっています。日々、開発に追われ、知識をため込む余裕がなくなってしまい、いつの間にか無秩序な開発をやり続けてしまうという悪循環が発生しているのです。
この悪循環を解消するには、このチーム軸とプロダクト軸の２軸を強く意識していかなければなりません。そして、それぞれをしっかりとデザインすることで強化していくことをお勧めします。
プロダクト軸では、お客様または自社の製品orサービスの未来について目指す姿をデザインするものです。
チーム軸では、自分達のチームの未来について目指す姿をデザインするものです。
このようにチーム軸とプロダクト軸では、デザイン対象が異なるのです。
２軸をデザインしながら、チーム軸では目指す人材像、魅力的な環境への整備、技術の追求、健全な精神の持ち方などの目標や技術を積み重ねていきます。そして、たくわえた知識をプロダクト軸のプロダクト開発に活用していくことで、無秩序な開発から集合意志が形成されたプロダクトに変革していくのです。
下記の図4.1.1-2の図中の「浸透させる」という線の意味は、チームデザインの経験を持っている人たちが、製品・サービスのプロダクトデザイン時や開発段階で、チームデザインで蓄積したノウハウや考え方をプロダクト開発に活用するということです。また、プロダクト開発が寄せ集めのチームの場合は、きっと皆さんに影響を受けたお客様メンバーからプロダクト開発チームをデザインしたいという話もでてくるでしょう。その際には、皆さんがプロダクトチームのデザインのやり方を、アドバイスする立場としても活躍できるようになります。
4.1.2 チームデザインとプロダクトデザインのデザインの違い
ここでもう少しチームデザインとプロダクトデザインの違いを説明します。
図4.1.2-1をご覧ください。３章の知情意で説明しましたように、知情意のモデルでデザインする対象は、芸術でも製品でも人でも同じようにデザイン可能なのです。
全てのデザインは、生き物を誕生させるような感覚でデザインすると良いのです。
例えば、製品開発の場合、その製品の普及を通じて社会に貢献する夢を語って見える化します。また製品としての成長があり、使う楽しみを感じさせるのがやり甲斐となり、明確な製品目標が語られています。
同じように、チームについても、チームの夢、チームメンバーとチーム自体の成長、楽しくなるような魅力があり、目標を持ちます。
図4.1.2-2では、チームとプロダクトにより、どのようにデザインが異なるのか説明しています。明らかに異なることがお分かりになるでしょう。これを混同してしまうと、良い製品を作るためのデザインが、自分達の魅力的なチームをデザインしてしまったりしてしまいます。
またこの図には、私のデザイン（キャリアデザイン、人生のデザイン）と組織（企業・部門デザイン）が入っておりますが、この２つはSE4BSでは対象外となります。
表4.1.2-3は、チームデザインとプロダクトデザインの違いについて、更にもう少し詳しく説明したものとなります。
この表中の特記事項に書かれているようにプロダクトデザインという言葉がちょっと分かりづらい場合は、プロジェクトデザインという言葉を使っていただいても問題ありません。また、業務系システム開発などについてはプロダクトデザインという言葉は使いませんので、○○システムプロジェクトデザインという言葉になります。要は、プロジェクトデザインといっても、同一のシステム化対象に対してプロジェクトを通して複数のリリースを繰り返すケースの全体をプロダクトと呼んでいます。
表4.1.2-3 チームとプロダクトのデザイン内容の違い(その２)
4.1.3 デザイン対象のライフサイクルにおける知の共有と継承
ここでは、デザイン対象のライフサイクルについて図4.1.3-1で説明します。
この図のようにデザイン対象にはライフサイクル（生きてから死ぬまで）があります。
一般的にライフサイクルが長いのは企業と私です（笑）。一番短いのはプロジェクトとなります。
もし、プロジェクトだけをデザインしてしまうと、プロジェクトで共有した知は、そこで死を迎えるため消失します。しかし、プロダクト観点でデザインをすることで、個々のプロジェクトの蓄積はプロダクトの知として継承されます。この知の継承を行うために匠Methodでは、プロダクト視点にてデザインを行うのです。
また、チームにもプロジェクトの経験知は継承されます。
そして、先ほど説明したように、皆さんがチームデザインを先行してそのやり方や考え方を知として蓄積しておくことで、その知識や経験をお客様のプロダクトに活用できるのです。
このように、それぞれの対象物をそれぞれに合った観点でデザインし共有・共感をしながら、知の継承を行って行くことで、知が途切れないようにすることが重要なことなのです。
4.1.4 チームやプロダクトはいつデザインすべきか
これについては、決まりはありません。
ただ、新製品を企画する前段階に組織が出来た際にチームデザインをしておくのが最適です。
これは、新しい部門が設立される際に、部門メンバーで部門デザイン（チームデザイン）をすることと同じことです。
そしていよいよ製品企画が始まる際に、その製品のためのプロダクトデザインを行うというのが理想的ではあります。
しかしながら、SE4BSを読まれている皆さんは、既にプロダクトのチームに配置されているかもしれません。その際に、もしお客様のプロダクトのデザインができていなければ、お客様と共にプロダクトデザインを行うのも良いでしょう。その後、自分達もチームデザインすれば良いと思います。
重要なのは、一度チームデザインしたらそのモデルを常に次の年に継承しながら新たな業務活動やＩＴスキルを蓄積成長させていき、次にお客様のプロダクト開発にアサインされた際には、プロダクトデザインを提案するのです。そしてお客様のプロダクトが魅力的かつビジネス的にも成功をもたらせるように貢献することをプロフェッショナルとして目指すべきではないでしょうか。また、お客様のプロダクトを開発するチームのデザインも引き受けましょう。
4.1.5 なぜSE4BSにチームデザインがあるのか？
ここまで説明してきたように、ソフトウェアエンジニアリング(SE)という名前を持つSE4BSにソフトウェア開発の価値駆動開発プロセスとは関係しないチームデザインがあるかというと、それはSE4BSが、単にソフトウェアを開発するだけのノウハウを提供しているだけではないからです。チームとしての成長や、ひとりひとりの人としての成長を誘うための考え方やプラクティスを提供していこうとしているからなのです。
4.2 プロダクト（プロジェクト）をデザインする
4.2.1 プロジェクトデザイントライアル
さて、ここからはプロダクトデザインの説明を行いますが、先に説明しましたように、プロダクトデザインをプロジェクトデザインに言い換えて説明しています。
プロジェクトの計画を製品・サービスの成長サイクルを長期的スパンでみたプロジェクトのデザインと認識してください。
4.2.1 どんな時に使うのか
プロジェクトデザインは、テクノロジー活用が含まれるビジネスの企画時に行います。新規ビジネスだけではなく、既存ビジネスでのIT改革・改善テーマの企画時にも使われます。
4.2.2 どんな種類のプロジェクトがありますか？
ビジネス企画といっても様々なものがあります。下記には、どのような種類のプロジェクトが対象となるか説明します。
- 業務改善・改革プロジェクト…DX化、IT活用による業務改革改善
- 製品開発プロジェクト…新規製品、既存製品の改善等が対象
- サービス開発プロジェクト…新規サービス、既存サービスの改善等
4.2.3 プロジェクトデザインの目的は何でしょうか？
次のようなものが目的となります。
- プロジェクト対象のビジョン・コンセプト、ビジネス・ステークホルダーに与える価値を明確にする
- プロジェクトの価値や戦略をデザインし共有することで、そこに必要とされる業務やITに対する要求（解決すべき課題）を明確にする。
- 要求を実現するための活動を明確にする。
4.2.4 プロジェクトチームには、どんなステークホルダーが参加しますか？
下記３つに分類されます。カッコ書きは役職名を入れていますが、それぞれの視点を持つ人を入れることが重要となります。また、それぞれの担当者は、必要と思えるメンバーで構成され、メインメンバーは６名～１２名程度に厳選しましょう。それ以外の方は、必要時に集まってもらうと良いでしょう。
- 経営視点を持つ役割又は人（経営者、企画者）
- 業務視点を持つ役割又は人（ターゲットの業務の企画担当者や主要担当者）
- IT視点を持つ役割又は人（システム開発担当者）
ところで皆さん、プロジェクトデザインは初めてでしょうか？
もし、初めてであればまずは開発メンバーだけで進めてみることをお勧めします。全体的な流れを体験しておいた方が、ファシリテーションのコツがつかめるものです。あるいは、他のメンバーに初めてだけど一緒に進めてみますかという質問をして、ある程度試行錯誤しながら進めるのもよいかもしれませんね。
4.3 プロジェクトデザインを開始する
さあ、いよいよプロジェクトデザインを始めていきましょう。ここからは、各モデルの説明をしていきます。各モデルに要する時間は次を目安に考えてください。
なお、プロジェクトデザインを行うファシリテーターを決めていただきますが、ファシリテーターが初心者の方の場合、初心者の時間を参考にして無理せずに進めていきましょう。
モデル作成の基本的な順序は上記の流れとなりますが、価値分析モデルと価値デザインモデルの順序はケースバイケースとなり、下記を参考に決めてください。何れにせよ、意と情を示す両モデルはそれぞれ影響しあうものなので修正が必要となりますので、どちらが先か迷った場合は、価値分析モデルを先に行うのが良いでしょう。また、価値分析モデルと議論する中で価値デザインモデルのアイデアが浮かぶといったこともありますので、それぞれのモデルを個々に完成させなくてはならないということではなく、モデルの関係を意識しながら検討対象のモデルを変えながら、徐々にモデルを洗練させるという考え方が必要になります。
- 価値分析モデルを価値デザインモデルより先に行うケース
- プロジェクト対象に対する知見が少ない時
- 既に知見があるプロジェクトであっても新たな価値感やソリューションで新たなものを生み出したい時
- 価値デザインモデルを価値分析モデルより先に行うケース
- メンバー内でプロジェクト対象に対して明確なコンセプト等がある時
4.4 プロジェクト対象を明確にする
プロジェクトをデザインする際にまず始めることは、「誰が、何を、どんな目的で、どうする、どうなりたい」ということを決めることです。
今回のサンプル事例は、モデルをできるだけ簡易に説明したいため、早稲田大学理工学部のソフトウェア工学(2021年度)で実施されたアウトプットを使います。
このモデルは、SE4BSの価値駆動開発に沿った授業で生徒たちが作成したプロジェクトデザインの成果物（モデル）です。部分的にアレンジしている箇所はあります。しかし、ほとんど学生が2ヶ月（1.5Hの授業×7回）で進めたもので、学生でも短時間でここまで作れるという参考にしてください。
ここから紹介する学生が考えたサンプルプロジェクトは次のような内容となります。以下を参考に自分達が進めるプロジェクトを記述してみましょう。
ここからは上記内容を基にしたモデルを説明します。
4.5 ステークホルダーモデルの作成（情のモデル）
ステークホルダーモデルをデザインするには、ステークホルダーモデルを使います。ステークホルダーモデルは必ず最初に作成するモデルであり、知情意で分類すると情を表すモデルとなります。
SE4BSの情のモデルは、他人視点のモデルであるため、他人に成り代わって考えることが重要となります。ステークホルダーとは日本語で利害関係者と訳されますが、ここでは、対象ビジネスを成功させるために必要となる人たちを役割（ロール）名で書くというものです。例えば、ユーザー、顧客企業、パートナー、発注元企業、自社などです。そして、それよりも少し詳細化したものとなると自社業務部門、自社IT部門などとなります。
そのため敵対するステークホルダーは対象となりません。もし味方にすることが可能な施策、かつ、味方にすることによりプロジェクト価値が高まるのであれば、残すこともできますが、その場合は協業企業というスタンス（カッコ書きで示すと良い）で残すことになります。
サンプルプロジェクトのステークホルダーモデルを図に示します。
それでは、さっそくステークホルダーモデルの作成にチャレンジしてみましょう。
ステークホルダーモデルの作成は、次の通りですが、Step2とStep3はどちらが先でも構いません。
Step 1 ステークホルダーを発見する
Step 2 ステークホルダーの関係線を記述する
Step 3 ステークホルダーの問題意識を考える
ステークホルダーのまとめ
Step 1 ステークホルダーを発見する
このモデルは、対象ビジネスにおける主要なステークホルダーを洗い出します。「主要な」とは、この人たちがいなければビジネスが成功しないと思える人を思い浮かべて、その役割名を図のように書いていきましょう。この際にいつもよりも視野を広くすることを意識して考えてみてください。もし、この人がいないと絶対ダメという人がいて、どうでしても名前を出したい場合は、「経理部門（中田さん）」といったように書くのも特例として認めましょう。ここで言うステークホルダーは個人ではなくチーム名、部門名、企業名、あるいは「顧客」、「社員」などがステークホルダーとなります。
今回のサンプルプロジェクトで発見されたステークホルダーは下記の通りです。
ステークホルダーには、未来のステークホルダーも検討します。例えば、サービスを拡張する際に、これまで考えていなかったステークホルダーなどを考えてみたり、人事システムでは、社員だけではなく「未来の社員」のようなステークホルダーを入れるようにしましょう。そうすることで、未来達成するための試作のイメージを持ちやすくなります。例えば、人事システムで「未来の社員」を置くことで、社員の価値だけを考えるのではなく、新たな社員に入社してもらうための施策に目を向けることができるのです。
今回のサンプルプロジェクトで発見された未来のステークホルダーは、クレジットカード会社とのようですね。
また、ステークホルダーモデルに必須なステークホルダーが２つあります。
一つめは、「最終顧客を必ず入れること」です。最終顧客がいなければ、プロダクト開発をしても使う人がいないということになりますので必須なのです。これはシステムを利用する個人ユーザーかもしれませんし、ユーザー企業の営業部門や経営部門かもしれません。
二つめは、「自分達を必ず入れること」です。ここで言う自分達とは、プロジェクトの主となるメンバーのことです。
そのメンバーの方々が業務部門やIT部門からでているので、その二つの部門があればいいのでは？という疑問もあるでしょうが、プロジェクトの主要メンバーとしてのミッションんが異なるケースがあります。例えは、業務改革チームが結成され、企画・業務・開発部門からメンバーが集められ、そのチームが今回このプロジェクトを牽引していく場合は、業務開発チームというステークホルダーを入れましょう。
なぜ、他人視点の情のモデルに自分達をステークホルダーモデルに必須で入れるかというと、価値が「絵にかいた餅」にならないために、自分達に対する価値も明確に示すのです。
サンプルプロジェクトのステークホルダーに、ここで説明したステークホルダーのタイプに分類すると次のようになります。しっかりとここで説明したステークホルダーが入っていますね。
Step 2 ステークホルダーの関係線を記述する
ステークホルダーがある程度でてきたらステークホルダー間の関係を図にいれていきましょう。関係の線は直線を使ってください。また客と学生という２つのステークホルダーは、単なる関係線という意味だけでなくグループと個々の関係を示しています。これは会社と会社を構成する組織上の部門（種別）という関係にも使えます。このように「抽象的な名前ー具体的な名前」を示すものは、抽象的な名前の方に△を入れることで分かりやすくなります。これは汎化関係と言い、ステークホルダーモデルが多くなった時に非常に便利な関係線です。
サンプルプロプロジェクトでは、客には学生と教職員と学外の種別があることが分かります。
サンプルプロジェクトの関係線を引いた例は下記の通りです。
Step 3 ステークホルダーの問題意識を考える
ステークホルダーの関係線を書き終わったら、各ステークホルダーが感じている問題意識を困っていることとして表現します。これはステークホルダーに成り代わって改善すべき課題などを記述するということになります。
その際にプロダクトにあまり関係ないような問題意識ではなく、プロジェクトとして解決すべき問題を意識して、「困った問題表現」とし書いてください。そして、該当するステークホルダーに点線で繋げましょう。
はい、これでステークホルダーモデルは完成しました。後は、モデルを書き進めるうちにステークホルダーが発見されることがありますので、とりあえずの完成ということになります。
今回の学生が授業で作成したステークホルダーモデルには、図4.5-1のようにプロジェクトの簡単な説明を記述してもらいました。
ステークホルダーのまとめ
いかがでしょうか。ステークホルダーモデルは、ビジネスが成功するために、できるだけ視野を広く持って考えてください。これまで意識していなかったステークホルダーがビジネスにとって必要だという認識ができてきませんか？
ステークホルダーモデルを書くことで視野が広くなったと良く言われます。
そうなんです！
情のモデルは、意のモデルに対して視野を広くするという特徴があるのです。
ステークホルダーが出すぎてしまっても、明らかにビジネス飛躍に関係ないステークホルダーでない限り気にしないでまとめてください。次の価値分析モデルで絞り込みを行います。
4.6 価値分析モデルの作成（情のモデル）
次は、価値分析モデルについて説明を行います。価値分析モデルは知情意で分類するとステークホルダーモデルと同じ情のモデルとなります。
皆さん、プロジェクトの企画を行う際に、「このシステムの機能はどんな時に役立つのだろうか？」、「この機能は、誰にとって有効なんだろうか？」と思ったことはありませんか？
価値分析モデルの役割は、「プロダクトによってもたらされる価値の活用シーンを明らかにする」、「新たな業務は誰にとってどんな価値があるのかということをシーンで明らかにする」というものです。
サンプルプロジェクトの価値分析モデルの例を図に示します。今回のプロジェクト例では、特に集約するステークホルダーはないためにそのまま出しました。また、客には４種類のタイプがあることが分かるように客との関係をそのまま示しています。
ただし、色についてはステークホルダーモデルで識別していますので、価値分析モデルでは同色とします。なぜなら、価値記述を色で識別しなければならないために、混乱を避けたいという意図があるからです。
価値分析モデルの作成は、次の順番（Step1～Step5）で進めます。
この順序には、とても重要な意味があります。それは「ビジネス慣習からの脱却」です。なぜそうなのかという話は後回しにしますが、順番を逆（目的）から進めるようなことは絶対にしないでください。
Step 1 ステークホルダーを並べる（図の上段）
Step 2 価値記述を書く（図の中段）
Step 3 プロジェクトの目的を記述する
Step 4 価値記述とプロジェクト目的の対応付け
価値分析モデルのまとめ
Step 1 ステークホルダーを並べる（図の上段）
まずはステークホルダーモデルのステークホルダーを横に並べます。ステークホルダーモデルと同様に「自分達」と「最終顧客」は必ず入れてください。ステークホルダーの数は、５個～１２個程度が適切です。もしステークホルダーの数が多くなってしまった場合は、ステークホルダーをプロジェクトテーマの特性や規模に併せて厳選しましょう。
ステークホルダーを厳選する例としては、次の順番で進めます。
A)具体的な名前ではなくミッションが同じもの、類似するものは集約し名前をつける
具体的な名前ではなくミッションが同じもの、類似するものは集約し名前を付けましょう。
表4.6-2 ミッションが同じステークホルダーを集約し名前を付ける
B)プロジェクト特性に応じた期待毎に集約し名前を付ける
ビックプロジェクトやSDGs等をテーマとするプロジェクトでは、顧客やパートナー関連のステークホルダーが多くなりがちです。場合によってはステークホルダーモデルのステークホルダーが50以上となってしまうこともあります。そのようなケースでは、なぜ私たちはこのステークホルダーを入れたのか話し合ってみましょう。それは、そのステークホルダーに対して何らかのWinWinとなる期待をしているからだと気が付くはずです。そして、そこには何らかの役割が見えてきます。その役割毎にステークホルダーをまとめてみましょう。そして、そのまとめたグループに名前を付けるのです。
例えば、「資金提供企業」、「建築関連企業」、「共同研究パートナー」、「提携パートナー」、「サービサー」、「行政」などがそうです。
ステークホルダーを12個程度にまとめておいて価値記述を書いてみて、どしてもステークホルダーを分けたいと考えた時にはステークホルダーを少し増やしても構いませんが、ステークホルダーを増やさずに価値記述中にカッコ書きで集約前のステークホルダー名を入れる方法もありますので、図的に分かりやすい方法で行いましょう。
Step 2 価値記述を書く（図の中段）
価値記述とは対象とするプロジェクトが成功した際に、そのステークホルダーから言ってもらえる価値の言葉を魅力的な表現で表すというものです。（図参照）
更に、魅力的な表現の中に、下記の図で示すように「シチュエーションと手段と価値の言葉」をセットにすることが条件となります。
実はこれが一番難しいようです。「どんな時にというシチュエーションが思いつかない」、「手段が思いつかない」、「価値の言葉が思いつかない」などです。
しかし、頑張って「手段」と「価値の言葉」は必ず入れるように心がけてください。シチュエーションも入れると価値記述としては１００点です。
価値記述は未来に達成する価値であり、現時点で達成できる価値だけではないこともポイントとなります。1ステークホルダーに2つ程度書けたら価値記述はとりあえず完了してStep3へ進みましょう。
Step 3 プロジェクトの目的を記述する
プロジェクトで達成すべき目的を価値記述の下に書いていきます。プロジェクト目的は4個～８個程度出してください。
プロジェクト目的は、皆さんがプロジェクトに配属された時に上司から聞いたことや自分で考えた目的をまずは皆で列挙してください。また、価値記述を書いているうちに、こんな目的も必要だなと思ったものも書いてください。
プロジェクトの目的は、別名「下心」と呼んでいます（笑）。
つまり「我々はステークホルダーにこんな価値を提供するよ、しかし、我々はこんな下心を企んでいるんだ」と言っているようなものですが、あまり社内の下心をむき出しにすると魅力が半減しますので表現は考えましょう。プロジェクト目的は意志を示す言葉として「○○の向上」、「○○の削減」というような表現を使いましょう。
図のように色を分けると分かりやすいです。そして、プロジェクト目的には英記号（Ａ～Ｚ）を記しておいてください。
Step 4 価値記述とプロジェクト目的の対応付け
プロジェクト目的まで書き上げたら、価値記述を左端から、ひとつひとつを見ながら、価値記述に書いてあることに対応するプロジェクト目的を探します。そして対応するプロジェクト目的があれば、プロジェクト目的に付与された記号を価値記述に付与します。もしプロジェクト目的が見当たらない場合は、対象の価値記述のプロジェクトにとっての重要性を話し合いましょう。もし価値記述がプロジェクトに必要であると判断した場合は、プロジェクト目的を新たに追加しましょう。また、価値記述がプロジェクトのスコープに該当しないと判断した場合は、価値記述を削除するか、価値の文章を変更してプロジェクトに相応しい価値に描きなおしてください。
このような手順で、価値記述とプロジェクト目的の対応付けをしていきますが、通常はプロジェクト目的１個に対して、価値記述がN個つながる関係になります。しかしいくつかの価値記述はプロジェクト目的に対してN対Nの関係のものも出てきますが、数が少ない場合は問題ありません。このようなケースでは、価値記述の手段がいくつも入っていたり、プロジェクト目的が曖昧だったり、抽象度が高すぎたりしているという傾向があったりしますので確認し、問題があるようであれば書き直してください。
なお、対応付けられたら、プロジェクト目的の英記号を付与すると同時にプロジェクト目的と同じ色に変更しておきくと分かりやすいですね。
プロジェクト目的と価値記述がすべて対応出来る状態になれば、価値分析モデルは完成となります。
価値分析モデルのまとめ
いかがでしょうか。価値分析モデルは無事完成しましたか？
価値分析モデルは、プロジェクト目的をステークホルダーの価値記述と対応させることで、目的がどんな価値があるのか評価できるという特長があります。
皆さん、目的は、常日頃から重要だと思っていますよね。しかし目的を価値で検証したことがありますか？さらに誰の価値なのか検証したことがありますか？
おそらくないと思います。元々、目的には価値が含まれているという前提のもとに立って目的を考えていますからね。しかし、プロジェクト目的と価値を分けると分かることがあるのです。それは、目的に価値が見当たらないということや、目的の価値がすべて自社のステークホルダーにしか対応付かないことなどです。
このように目的は、日々の仕事の慣習的な考えから作られることが多いのです。
そのため価値分析モデルでは、ビジネスの主要ステークホルダーの価値を描いた後に、ひとまず価値記述とは切り離して、プロジェクト目的を考えて対応付けます。その後、ステークホルダーの価値から考えた価値記述とプロジェクト目的が対応づかないケースでプロジェクト目的を追加したものがあれば、それは皆さんが慣習的業務による弱点が見えたということになりますので、そのプロジェクト目的の実現は強く意識しなければなりません。
このような効果を狙っているために、価値分析モデルの冒頭で書いたStep1~Step4の順番を守ってほしいのです。もし目的から考えて、その価値をステークホルダー毎に価値記述を書いてしまうと、その目的に合った価値記述しか書けなくなってしまうのです。
4.7 価値デザインモデルの作成（意のモデル）
皆さんは、「このプロジェクトの成果は、どのように社会に役立つのだろうか？将来はどのように発展させていけるのだろうか？」ということをご自分で考えたことがありますか？。また、そのことをプロジェクトメンバーで話し合ったことがありますでしょうか？
プロジェクトの意志をデザインするという行為は、まさにこのことをプロジェクトメンバーで話し合い共通の言葉や絵を使って自分達のモノ・コト創りに対する意志の表明をすることなのです。
プロジェクトの意志を、プロジェクト関係者が集まりデザインするという活動は、プロジェクトで現在想定されるユーザの価値だけではなく、もう少し未来を見据えて、自分達はプロジェクトを通してどんな価値を社会に生み出していくのか皆で考えることになります。
しかし、このような機会は、あまりないように思うのですがいかがでしょうか？
どのような価値を社会に生み出すのか、最も適切な言葉を考えてビジョンやコンセプトとして言葉で表現していくうちに、プロジェクトメンバーが未来に対して共通の夢を抱くことができるようになれるのは素敵なことだと思いませんか？
プロジェクトメンバーがひたすら多忙で、仕事に対する夢とかを語る暇はないため、そんなことはやっていられないよ！と思われると思います。しかしながら、共通の夢を抱き、そのために必要なことが何かを語り合えれば、無用な衝突は避けられますし、お客さんに対しても何を優先し何をやめるべきかといったことを説明しやすくなります。すなわち、プロジェクトを進める際に選択と集中が以前より可能となるわけです。その結果、より良いビジネス開発やプロダクト開発を効率的に行えるようになるのです。
プロジェクトの意志をデザインするという活動は、これから生み出す製品やサービスに対して、プロジェクトメンバーの魂を宿らせて生きもの化するような感覚を私は抱いています。
優れた製品やサービス、そして芸術などもそうですが、何かそれを生み出した人たちの魂を感じることはありませんか？
皆さんはいかがでしょう？
これまでにそのような感覚を覚えた製品や活動などがありませんでしょうか？
３章の魅力的な製品サービスについての図で説明したように、自動車創りの哲学が意志となり、クルマのデザインやエンジニアリングの目標とし、結束力を持って製品を生み出し続けていくプロジェクトを推進させるパワーとなるのです。これがインナーブランド形成の効果なのです。
また、そのようにして創られた製品は、それら全体が魅力的な価値としてユーザーや関係者に認識されることにもつながります。
実際には、皆さんが製品やサービスを生み出すための、強い意志を形成し、より良いモノづくりを自分が描いた未来感で創り続けることで、それが消費者に伝わることになるのです。これがアウターブランド形成の効果となります。
このように、ひとりの意志ではなく、一人一人の意志を見える化し語り合いひとつに仕上げることを集合意志とよび、知・情・意による価値駆動開発において非常に重要な考え方なのです。
この集合意志形成で使用するモデルは、価値デザインモデル（意のモデル）です。ここから価値デザインモデルの詳しい説明をしていきます。
価値デザインモデルは、対象とするプロジェクトの意志を示すモデルです。例えば、下記の例のように企業デザインの場合は、企業としての意志を未来思考で描きます。
価値デザインモデルはプロジェクトターゲットが何であるかにより表現が異なります。チームデザインの場合はチームとしての意志を描きます。システム開発におけるプロジェクトデザインの場合は、ターゲットによって変わります。例えば製品、サービスなど、ある意味プロジェクトが生み出す作品に対する意志なのです。
冒頭の知・情・意で解説した、自動車プロダクトの例や伊藤若冲の絵などを思い出していただくと分かりやすいと思います。クルマ創りに対する哲学、絵描職人の哲学、これを一枚の図として表すものなのです。
今回のサンプルプロジェクトでは、学食サービスをテーマとした意志表明となります。
下記の図は、サンプルプロジェクトの価値デザインモデルです。
では、ここからサンプルプロジェクトの価値デザインモデルについて説明します。
価値デザインモデルは、記述の順番はビジョン、コンセプトは必ず先に考えた方が良いでしょう。それ以外は、自由に進めてもらって構いませんし、デザインが好きな方やポエマーには言葉やストーリーを考えてもらうのも良いですね。
Step1 ビジョンの作成
Step2 ３つのコンセプト の作成
Step3 言葉（キャッチフレーズ）の作成
Step4 意味 の作成
Step5 ストーリー の作成
Step6 デザイン（ロゴ）の作成
価値デザインモデルのまとめ
Step1 ビジョンの作成
３年～１０年後に達成したい夢（ビジョン）を語ってください。やや抽象的な表現でも構いませんが、このプロジェクトで作り出すサービスで、社会、地域社会、ユーザなどの生活などがどう変わる・変えるのかを語っているビジョンのほうが魅力を感じますので是非チャレンジしてください。このサンプルのように達成年数を記述しておくのが良いですね。
ビジョンについては、なかなかいい文章が作れない事が多いと思います。
その際には、付箋紙等により言葉の断片を参加者に書いて出してもらうと良いでしょう。
言葉の断片を上手くつなぎ合わせてビジョンを形成していくのです。
また、ビジョンで考えた言葉の断片は、ビジョンでは使えないけど、コンセプトや言葉に利用できるということがあります。
このようなことを行えるように、価値デザインモデルの要素を次のように模造紙上に張り付けていくと、意外な所に使えるというような言葉の発見があります。
図4.7-3 価値デザインモデルの要素の候補
Step2 ３つのコンセプト の作成
コンセプトは日本語に訳すると、概念・発想・構想などがありますが、ここでは構想と思ってください。ビジョンに到達するための達成しておくべき３大構想を書きます。構想は、３大目標という表現に置き換えた方が分かりやすいようであれば、そのようにメンバーに説明してください。
書き方は、次のようにタイトルと説明文を書くようにしてください。
タイトルは、狙いを一言で書くこと。説明文は、具体的にどんなことを達成するのか構想を考えます。
また、コンセプトの記述には、次の２つのルールがあります。
- コンセプトで記述した内容について実現する際に必要となる手段がいくつか想像できること
- それぞれのコンセプトから想像できる手段は、それぞれに異なっていること
２は３つのコンセプトには明確な特長を出さなければならないからです。
Step3 言葉（キャッチフレーズ）の作成
プロジェクトの対象を魅力的に表すキャッチーな言葉を考えてください。「学食を楽食に」なかなか面白いですね。
Step4 意味 の作成
プロジェクトをなぜ立ち上げたのか、プロジェクト対象をなぜ作ろうと思ったのか、その背景にあるものや、達成したい想いなどを説明します。
Step5 ストーリー の作成
明確なルールを定めていませんが、現在からビジョン達成に向けてのステップアップする道のりや、プロジェクト対象の成長ストーリー、プロジェクトのサクセスストーリーなどを考えて素敵な文章を作りましょう。
Step6 デザイン（ロゴ）の作成
プロジェクトの対象を魅力的に表すためのロゴを考えましょう。意味を持つロゴが良いですね。ロゴの叩き台として、こんなものレベルで構いません。インターネットから要素を拾ってきて合わせ技で作る人もいます。
ロゴデザインは直ぐできないからといって疎かにしないでください。著者のプロジェクトデザインの経験では、３つのコンセプトがどうしても考えられなかったチームがありましたが、ロゴデザインを作った人がいて、そのロゴデザインから３つのコンセプトが生れたことがあります。
先ほどの企業デザイン(図4.7-1)を考えている際に、匠の中にITが含まれている、ということからロゴが生れたのですが、そのロゴイメージを基にして、これまでの様々想いが集約され「オノつくりをITに変えた現代の匠」言葉が生れ、そこから様々なコンセプトが生れてきました。
このように意志を示すデザイン（ロゴ）は、とても効果的なものなのです。
なお、このデザインを広告等に活用する場合は、デザイナーに依頼するために、どのような意味を持つロゴなのかが分かるようにしましょう。
価値デザインモデルの要素説明は終わりです。
価値デザインモデルのまとめ
価値デザインモデルは、意志を表すモデルですが、意志には関係者の方向性を定めるという効果があります。それは正にストーリーを連想させるものでなければならないのです。
そのような観点で作成された価値デザインモデルは、きっと「心地よい価値観」を表現されていることでしょう。また、現在からビジョン到達に向けた立体図を構成しているはずです。
図4.7-5 価値デザインモデルは全体がストーリーを表している
このストーリーを創り上げることでチーム全体の集合意志が形成できるようになり、皆で同じビジョンに向かって突き進む原動力の源となります。
さらに、価値デザインモデルをしっかり社内外で利用することで、組織内での企画を通す際にも役立ちますし、お客さま、業界、社会にも魅力的に感じるものとなるでしょう。
4.8 要求分析ツリーの作成（知のモデル）
次は、要求分析ツリー（知のモデル）について説明を行います。
要求分析ツリーは意と情のモデルを活用しながら要求や活動を創りだしていきます。ここで要求とは何だろうと思われる方もいらっしゃると思います。
要求とは、自分達やステークホルダーの未来の価値を獲得するために、自分達組織に必要とされる課題と考えていただくと分かりやすいでしょう。自分達に向けて、取り組み課題を要求しているということなのです。
要求には「戦略要求」「業務要求」「IT要求」というタイプがあります。
- 戦略要求 ...プロダクトを成功に導く、戦略的なテーマ
- 業務要求 ...プロダクトを成功に導く、ビジネス的、業務的に取り組むテーマ
- IT要求 ...プロダクトを成功に導く、テクノロジーの活用テーマ
また活動は、要求を実現するための、具体的な活動を言葉化したものです。
サンプルプロジェクトの要求分析ツリーを示します。
さて、ここからは要求分析ツリーの作成方法になりますが、ここまではサンプルプロジェクトは、できるだけ学生チームが授業で作成したものをベースに紹介してきました。しかし、ここからは、意と情という感性的な思考で作成したモデルを知という論理思考で構成されたツリーにより如何にブラッシュアップするかについて説明したいと思います。従って学生チームで作成したモデルを変更していくような流れで進めたいと思います。
要求分析ツリーの作成は、次の順番（Step1～Step4）で進めます。
要求分析ツリーの作成順として、Step1はかならず最初に確定させます。その後Step2、Step3と進みますが、Step3の活動については、並行で進めるのもOKです。業務要求やIT要求を考えている時に、気が付いた活動や、最初からやるべきと考えている活動を入れてもらって構いません。
Step 1 戦略要求の作成
Step 2 業務要求、IT要求の作成
Step 3 活動の作成
要求分析ツリーのまとめ
Step1 戦略要求の作成
要求分析ツリーでとても重要な事は、まず戦略要求を固めるということです。
戦略要求が曖昧なものであれば、以降に作成する要求が非常に不安定なものとなってしまうからです。
戦略要求は次のようにして構成します。
1)価値デザインモデルのビジョン＆コンセプトと価値分析モデルの目的をコピーする
価値デザインモデルのビジョンとコンセプトと価値分析モデルを要求分析ツリーに、縦横を並べ替えて、図のようにコピーして並べてみましょう。ここで、注意してほしいのは、価値デザインモデルと価値分析モデルから切り取らないでください。それぞれのモデルはそれだけで価値があるので、かならず２つのモデルの作成結果は残しておいてくださいね。
2)それぞれのコンセプトと目的がつながるか検証する
次は、それぞれのコンセプトに目的をつげてみましょう。この際つながるとはどういう事かというと、要求分析ツリーは要求のツリーですので、上位要求（左側）と下位要求（右側）の関係が目的と手段の関係となります。つまり左側の目的に対して右側が手段となっているか判断してください。ここで、プロジェクト目的自体が目的という意味があるために混乱しますが、要求分析ツリーでは、すべてを要求という概念で構成しますので、プロジェクト目的という概念は忘れてください。
サンプルモデルでは、次のような結果となりました。
お見事ですね。
しっかりとつながっています。
図4.8-3 意と情のモデル要素を連結する
はい。これで戦略要求はできあがり～、となります。
しかし通常はこんな簡単に繋がりません。例えば、次のような問題が発生します。
その際には、原因を考えて、原因に合った対策を行いましょう。
さて、ここでサンプルモデルを見てみましょう。
しっかり考えてみると、要求分析ツリーの左側にあるコンセプトと右側になるプロジェクト目的の関係性に問題があるようです。本来ならば左側が目的、右側が手段であるはずです。それが逆になっています。他のコンセプトと目的も逆になっているように思えます。
図4.8-5 コンセプトとプロジェクト目的の問題
そこで、コンセプトとプロジェクト目的の改善を試みたものを次に示します。
この改善は、学生が作成したサンプルモデルの考えを崩さない必要最小限の変更に留めることにします。
いかがでしょうか？これで要求分析ツリーの構造に併せて、「左側が目的右側が手段」になったように思いませんか？
では、学生が考えたコンセプトや目的の表現が良くなかったのでしょうか？
そうではありません。意と情で示す２つの価値のモデルを論理性をもってつなげるという匠Methodのルールから見た時に始めて、三大目標となるコンセプトとそれよりも粒度の小さいプロジェクトの目的の関係性が正しくなかったということが分かるということなのです。
これは「感性的に作成したものを論理性を持って正す」ということになり、次の２つの効果があります。
- 感性的な意と情のモデルから、知の目標を作ることができる
- 知の目標を作る過程で、論理性を持って意と情のアウトプットを洗練化できる
これは、人の思考という観点でも非常に興味深いと思いませんか。
感性的な思い付きは非常に魅力的なものを発見しますが、それを論理性を持って欠陥や弱点を補うこともできるというわけです。
では、この改善により何が効果として生れるのでしょうか？
それは、戦略要求の後に検討する業務要求に現われます。
下記の図は、左は改善前で図4.8-1で示した業務要求まで含まれている要求分析ツリーです。一方、右は改善後のモデルです。
どこが異なるかというと、右の改善後のモデルの方が戦略要求から業務要求に伸びる線がシンプルに分かりやすくなっていますね。戦略要求から業務要求との接続する線は、戦略要求にあるプロジェクト目的から業務要求へは１対多となり、多対多にならないように工夫することで可能となることです。つまりは、業務要求から延びる線は１方向が望ましいということです。
なぜ、そのような構造が望ましいかというと、ミーシー（MECE)な構造、つまりは「それぞれが重複することなく、 全体として最後にでてくる活動のモレがない」構造を目指すことにつながるということと、業務要求の存在根拠となる戦略要求へ辿って、そこから価値に辿る際に、この構造にしていなければ、上位要求があっちこっちに散らばり、存在根拠が分かりづらくなるからです。下位要求を重複させてクロスさせないためにも、このような改善が必要になります。
ただし、ミーシーの「モレがない」という点は、要求と言う観点では、重要な要求がシンプルに抽出されていることを優先し、論理的にすべてを抽出するとことではありませんので注意してください。すべての要求をもれなく抽出するというのは、切りがなく要求が爆発的に増えますからね。
どうでしょうか。非常に論理的な話しになってきましたね。御免なさい。
ここについては、後で理解すれば良い事ですので、最初は読み飛ばして結構です。学生の授業の際も何を論点に話しているか分からなくなるので、改善することも行っておりません。
次の業務要求の作成に移る前に、ここまでで修正した戦略要求の並びを綺麗に整理したものを下記に示します。
戦略要求の作成中に、価値デザインモデルと価値分析モデルを変更しましたので、忘れないうちに、変更点を両モデルにフィードバックします。
まずは、価値デザインモデルの変更点は、３つのコンセプトのタイトルと説明文を変更しましたので、下記のように修正しました。これは差し替えなので簡単ですね。
次は価値分析モデルのプロジェクト目的の変更となります。
プロジェクト目的の変更に対して、プロジェクト目的に紐づく価値記述がいくつか変更となりました。
図4.8-11 価値分析モデルのプロジェクト目的と対応する価値記述を変更する
これで、意と情のモデルへのフィードバックは完了しました。
Step 2 業務要求、IT要求の作成
次は業務要求とIT要求の作成となります。業務要求は、戦略要求を実現するにはどんな業務的な要求が必要だろうかと考えます。例えば、キャッシュレス決済の強化は、決済方法の拡大と、混雑解消と考えていますね。さらに、IT要求では、「業務要求の決済方法の拡大」には、「ICカード決済システムの導入」と考えました。このように手段方向に要求をブレークダウンしていきます。
なお、業務要求とIT要求の線は多対多となっても構いません。いくつかの業務要求はIT要求で満たされる場合が多いからです。
業務要求のコロナウイルスの感染対策については、業務要求をさらに要素分解しているケースです。複雑な業務などはこのように２レイアー構成を取ることもあります。
また、業務要求からIT要求に線が引かれていないものは、ITを使わない要求と考えてください。これらは直接活動につなぐことに成ります。
ここまでは説明上、業務要求からIT要求を考えるというような話で進んでいますが、最初からIT化を頭に入れているのであれば、最初にIT要求を書き込んでおき、そのIT要求はそもそも何のために導入するのかと考えながら業務要求の言葉を作ります。そして、その業務要求は、どの戦略要求とつながるのか考えていきましょう。このようにツリーの右側から左側に進めていくやり方は「Howからの突き上げ」と匠Methodでは呼ばれています。このアプローチは、イノベーションやDX的なアプローチには欠かせません。
場合によっては戦略要求も変更されることがあります。「Howからの突き上げ」はIT部門やITに詳しい人の役割となり、これを行う際に重要な事は、他の部門の方達への「説明責任」となります。そのために、業務要求やどの戦略要求に繋げるかをしっかりと考えて説明ができなければなりません。
逆に戦略要求から業務要求、そしてIT要求と進めるやり方は、「Howの手探り」と呼び、戦略から手段方向へ手探りしながら最も価値が高い手段を発見する方法で、要求分析ツリー作成の通常の流れとなります。
DXプロジェクトを成功させるには、社会・ビジネス変革からテクノロジー活用を模索することと同時に、テクノロジー活用の方法を社会・ビジネス変革に活用するためのストーリーを考えることも重要なのです。これを、要求分析ツリーを描く際に「Howの手探り」と「Howからの突き上げ」という両方のアプローチによって議論しながら作成することをお勧めします。
Step 3 活動の作成
次は業務要求と活動の作成となります。活動について具体的に実行可能な言葉を考えて、業務要求かIT要求とつなげます。業務要求から直接活動につながっているのは、ITとは関係ない業務的な要求に対する活動となります。このように、プロジェクトの目的達成のために、IT（開発）要求以外の（業務側）活動も必要であることが可視化されることが要求分析ツリーの利点とも言えます。
要求分析ツリーのまとめ
これで要求分析ツリーがとりあえず完成しました。
要求分析ツリーは、知情意における知の代表的なモデルとなります。
意と情のモデルは、ワクワク、ドキドキと感性を刺激するような特性がありますが、知のモデルは、経営、業務、ITといったステークホルダーに対して、行うべきことの論理的な説明を可能とするモデルとなりますので、ステークホルダー（経営者、業務担当者）の心の安定をもたらすものという特性があります。別名、納得感をもたらすモデルと言っています。
このように価値駆動プロセスによって、意と情でプロダクトメンバーや関係者に感性的な刺激を与えながら、ビジネスを未来に向けて変化させ、その変化させた内容を論理思考で安定化に向かわせることができるのです。もし、意と情のモデルを作らずに、要求分析ツリーから進めるとどうなるでしょうか？その場合は、慣習的な「やりたいこと、やるべきこと」をそのまま論理的な構造に落とし込んで完成させてしまうのです。