3. 価値駆動開発の基本

3.1 魅力的なプロダクト創りとは

ソフトウェア開発が、定型の業務の効率化から、新規のビジネスの実現や、持続可能な社会へ貢献するためのものへと、その軸を移してきているのは、前述のとおりです。　そのようなソフトウェア開発を行うためには、ソフトウェア開発の技術とその可能性を理解した開発者と、ソフトウェアを所有する人（出資をする人）が、ソフトウェアにより実現される価値、利用する人にとっての価値を理解し、共有することが必須であり、変わりゆく環境に応じて、そのソフトウェア（ソフトウェアにより実現される価値）を継続的に成長させていくことが必要です。

そのためには、見えている課題の解消という視点ではなく、未来思考で魅力ある価値を描き、そして価値から戦略につなげ、そこから業務要求やIT要求を出すことで、価値から実装までのトレーサビリティを担保し、ステークホルダー間で納得感のある開発要求とする必要があります。この章ではユーザーを含むステークホルダーの価値を描くことから要求発見するための基本的な考え方を解説します。

3.1.1 価値駆動のプロジェクトデザインとは

価値とは誰にとってのものでしょうか？　もちろんソフトウェアを利用する人、ソフトウェアによって実現されるサービスを利用する人にとって価値を感じられるということは必要です。しかしながら、持続可能で成長させていくには、そのソフトウェアやサービスを提供する人たちの価値を実現するものでなくてはいけません。

SE4BSでは、その利用者と提供者の両方の価値を描き、その要素を連結し整合性をとることによって納得性がある活動を作りだします。

3.1.2 プロジェクトデザインと「知・情・意」思考の関係性

「知・情・意」という言葉はご存知でしょうか？　哲学者カントが提唱したとされており、夏目漱石氏・松下幸之助氏・渋沢栄一氏などを始めとする錚々たる偉人がみな「知・情・意」の重要性について触れています。「知」だけに偏る仕事は無味乾燥になり、人びとの共感を得ることができず、「情」だけに走ってしまうと、あらぬ方向に逸脱する危険性があり、また「意」だけに凝り固まると、柔軟さや寛容さを欠くことになるということで、この３つの要素のバランスが大切だということです。

3.2で説明をしたプロジェクトデザインの考え方が、まさにこの「知・情・意」の考え方と符合します。

SE4BSでは、戦略や活動を具体化する前に、「価値創造」から始めます。そして、それら価値の要素を基に戦略や活動に落とし込みます。「価値創造」は、自分達視点（意）と他人視点（情）と２つの視点で描いていきます。そして、それを結合したものを戦略（知）として定義します。

結合する際に、うまく結合できない時があります。その際には、その場で内容を変更し、その変更したものを意と情のモデルにフィードバックします。

意と情は感性思考重視で描いて行きますが、知は論理思考重視で進めていきます。感性思考では、感覚的なものを文章化していきます。

いきなり論理思考で戦略を考えてしまうと現在の問題解決に終始してしまう傾向があります。そこで意と情という２つの視点で価値を描き、戦略の要素を発見するのです。

意はシーズ思考（自分達ができることを考える）に近い概念であり、情はニーズ思考（ユーザが欲することを考える）に近い概念といえます。

3.1.3 「知・情・意」思考の重要性

価値駆動のプロジェクトデザインにおいて、なぜ知情意の分類が重要なのでしょうか？ここで皆さん、魅力的な製品・サービス、組織、人材などを考えてみてください。

例えば図3.1.3-1の魅力的なクルマ（製品）には、クルマ作りの哲学（意志）を感じたりしませんか。

また、情として人を引き付けるクルマのデザインや魅力的な言葉が並べられたパンフレットに惹かれたりしませんか。

そして、知では意と情で表現しているクルマ創りの哲学（意志）やデザイン（情）を、実際に構築していくエンジニアリングプロセスや、技術や業務スキルが蓄積されていることを感じることでしょう。

製品もサービスも人も組織も同じであり、知情意という３要素を連結しながら強化している仕組みが必要なのです。

下記の図3.1.3-2に示すように、この三位一体の関係をチームや組織全体で考えて見える化し、ビジネスデザインとしての地図を作り、その後は地図を見ながら新たな家を建てたり、橋を作ったりしていくことで、価値主導のビジネスデザインを継続的に進めて行くのです。

また、この考えは普段から人が魅力的だと思う時の思考と同じです。例えば、芸術を堪能する際にも同じことなのです。

下記の図3.1.3-3は日本美術の伊藤若冲の絵を例にとって説明しています。若冲の意については、言い伝えにより理解しています。情は見事なデザイン力、知は卓越した技ということになります。

このように芸術の世界もビジネスの世界も人の捉える感性は普遍性があるものなのです。

3.1.4 「知・情・意」とモデルの関係性

SE4BSでは、プロジェクトデザインを行っていくときに形式的な図を使って見える化していきます。この図のことをモデルとよびます。

プロジェクトデザインでは、主に以下の５つのモデルを使用しますが、それらと「知・情・意」の関係を以下に示します。

意の思考では、これからプロジェクトで実現する価値をデザインするということで、「価値デザインモデル」を使用します。

情の思考では、まずはプロジェクトに関連する人たちの関係や思いを表現する「ステークホルダーモデル」と、このモデルにより特定したステークホルダーがプロジェクトによりどのような価値を得るのかということと、プロジェクトの目的の関係を表現する「価値分析モデル」を使用します。

知の思考では、「価値デザインモデル」で表現された戦略要求（ビジョン、コンセプト）と「価値分析モデル」で表現された業務／IT要求（目的、価値記述）の関係をつなげ、必要となる活動までを表現する「要求分析ツリー」と、活動の具体的なゴールを設定する「ゴール記述モデル」を使用します。

3.2 価値駆動開発プロセスの構成要素

１章で説明したように価値駆動開発プロセスの全体像は下記の通り知・情・意で構成されています。

SE4BSの価値駆動開発プロセスは、これまでのエンジニアリングとしての知識体系に加えて人が感じる「価値」「魅力」といった感性の領域に踏み込んでいます。その理由は、これからの時代はDXの言葉で代表されるように、人にとって魅力的な社会やビジネスをいざなうプロダクト製品、サービス、業務システムを生み出すことが必要とされているからです。

そこで我々は，人の根源的な心的要素として捉えられる知・情・意に基づいたソフトウェア開発・運用の考え方、チームの意識の持ち方に着目しました。
その結果、開発・運用の際にはアジャイルマインドやアジャイルプラクティスを組み入れることを推奨、開発プロセスとしては価値駆動開発プロセスを採用することになりました。

この価値駆動開発プロセスとは何かというと、ソフトウェア開発を進めていく上で、価値から始めに考えることです。これまでソフトウェア開発の上流というと要求定義でした。また超上流というと業務要求やその上のビジネス戦略まで捉えた方法がありました。しかし、このようなアプローチでは、視野が狭く自分達本位となりがちです。本当の意味での価値のあるソフトウェアは作れない可能性があります。

ソフトウェアを使う人達が感じる魅力や、ソフトウェアを導入したユーザー企業が得られる価値を真剣に考える必要があります。そこで、これをニーズデザインと呼び「情」で表し、それに対応するモデルを使っています。

また、チームが生み出す業務やソフトウェアシステムが、世の中に対してどう貢献するのかという自分達が未来に向けて創出する価値についても描き、これをシーズデザインと呼び自分達の「意」としてモデル化していきます。

価値駆動開発プロセスでは、このようにソフトウェアを使う人達が感じる魅力や、ソフトウェアを導入したユーザー企業が得られる価値を「情」として、自分達が未来に向けて何を生み出していくのかということを「意」として、チームでモデル化（見える化）します。 そうして、これらの「意」と「情」という２つの価値を結合することで、自社戦略、自社業務に対する要求、そして業務要求に必要とされるIT要求を導き出し、そこからソフトウェア構造を導き出していきます。

実際には、「意」「情」「知」それぞれが、それぞれを洗練化するため、図3.2-2に示すように、スパイラルに周ります。

知・情・意それぞれが、それぞれを洗練化するとは、図3.2-3のように、お互いがお互いに良い影響を与えるからです。
これは例えると、ステークホルダーの価値ばかりを考えていると「情に流される」という言葉もあるように、あれもこれも必要となるわけです。 そこで意によって未来の価値をproductとしてデザインしておけば、その方向にステークホルダーの価値感を引き寄せることができるのです。これが意が情に与える方向性です。しかし、意だけで突っ走ると、視野が狭く窮屈な価値しか生み出せません。
そこで他人視点の情で考えることが重要となります。これが情が意の視野を広げるという効果となります。
このようにして意と情の両社のバランスを取りながら、それを知の目標にすれば、知の世界で迷子になったりせず、周りからも角が立たないでしょう。そしてその知は、具体性を意と情に与えることで、さらに価値が洗練化されるのです。

このように文章で書くととても複雑で時間のかかる作業のように思えるでしょうがそうではありません。ビジネスを企画し、ソフトウェア構造に落とし込んで行くためのモデルをスピーディに作成できるようになっています。
しかし、現段階の価値駆動開発プロセスはまだ発展途上であります。価値駆動開発プロセスはこれから、これを読まれている皆さんの協力を基に、様々な側面で進化を遂げていくことになるでしょう。そのため現在の価値駆動開発プロセスが網羅している範囲や使用しているモデルについては、私たちが現時点の最良方法と考える例示であります。
図は価値駆動開発プロセスの全体像です。この図中の上から「ビジネスをデザインする」「ビジネス・ITをマネジメントする」「IT/システムをデザインする」「IT・ソフトウェアをデザインする」という流れがありますが、これは作業が上位から下位へ流れるウオーターフォール的な工程という概念ではありません。始まりは上位から進めていき、スピーディに下位まで進めつつも上位から下位へ、下位から上位への双方向でトレーサブルに行ったり来たりすることで、ビジネスアーキテクチャからITアーキテクチャまで一気通貫で素早く洗練し固めていくというアジャイルアプローチを取るものです。

また、登場するモデルは「ビジネス・社会視点の価値駆動」と「アーキテクチャ視点の価値駆動」という２つに大別されています。前者は感性的な思考を重視するアプローチ、後者は論理的な思考を重視するアプローチが多くなっています。

価値駆動開発プロセスでは従来の手法やモデルを取り入れた構成となっています。

手法としては匠Methodやアジャイル・スクラムで、下記のようなモデルが対象とされています。

• 匠Methodの５つのモデル（ステークホルダーモデル、価値分析モデル、価値デザインモデル、要求分析ツリー、ビジネスコンテキストフロー）
• ビジネスモデルキャンバス
• カスタマージャーニーマップ
• ユーザーストーリーマッピング
• 従来のソフトウェア工学としてのドメイン分析、ビジネスルール、パターン、設計モデルなど

なお、現時点では、ソフトウェア設計の詳細や、テスト等については触れられておらず、ビジネスやITアーキテクチャを表現する部分に集中しています。ITアーキテクチャーはビジネスアーキテクチャーと同様に、ビジネスパーソンとエンジニア人達の共通言語となるため、知識をカスケードをさせながらビジネスデザインとシステム開発を同時並行で進めていけると考えています。
ソフトウェア設計の詳細なモデルについては、最近のソフトウェア開発においては、様々なアプローチで様々な構造を持っておりますので、共通的なモデルとして取り扱うことは避けた方が良いと現時点では考えております。

3.3 価値駆動プロセスの注目すべき６つのこと

価値駆動開発プロセスの注目すべきことは６つあります。

　１）すべては価値から考えることを始める
　２）分かりやすく、ドキュメント量が少ない
　３）再現性がある
　４）トレーサブルである
　５）アジャイルに作成できる
　６）活動に携わる人々の思考法でもある

１．すべては価値から考えることを始める

価値駆動開発プロセスではすべてを価値から考えます。
これまでのシステム開発の上流工程では、業務やITの要求を出して、それを企業戦略としてどのようなメリットがあるか検討することが多かったのではないでしょうか？
全てを価値から考えるというのは、どういうことでしょうか？
図1.4-2を使ってこのことを説明します。

この図は、思考のフレームワーク（別名：思考の整理棚）という概念を示しています。思考の秩序棚は価値駆動開発プロセスとセットで習得していただきたい概念です。
ここからは、思考の整理棚という名前で説明していきます。
思考の整理棚は、図3.3-1     で示すように頭の中でイメージする棚と考えてください。（コラム参照）このタンスには、ラベルが張り付けられた引き出しが用意されており、ラベルは、上段に価値としてシーズ、ニーズ、要求として戦略要求、業務要求、IT要求）、下段に活動があります。

この思考の整理棚の引き出しは、思考をチームで整理するために用意されているものです。実際のところ、チームの思考を整理する際には、棚の引き出し毎に用意されたモデル（形式的な図）を使います。

思考の整理棚とプロセスには、それぞれ異なる役割があります。

これをカーナビを例に説明すると、価値駆動開発の「思考の整理棚」はカーナビの地図のようにどこにどんな引き出しがあるのか全体像が示されています。そして「プロセス」は、スタートからゴールに向かって、引き出しから引き出しへ進んでいく道を示しているのです。

では、ここから「全てを価値から考える」ということを説明していきますので、図中の棚のラベルを辿りながら見ていってください。
価値駆動開発プロセスでは、戦略要求・業務要求・IT要求などはあくまで手段という位置づけとなります。「戦略要求・業務要求・IT要求」は「やりたいこと、やるべきこと」であり、それらは手段なのです。

価値駆動開発を実施するファシリテーターは、プロジェクトデザインを始める際に「皆さんはやりたいこと、やるべきことをお持ちでしょう。それをいったん心に踏まえておきながら価値から考えていきましょ」なんて発言します。きっと周りはポカーンとするでしょうね。

価値から考えるとは、プロジェクトのテーマに関係するステークホルダーの価値（ニーズ）や、自分達の価値（シーズ）を考えるということです。

それぞれのステークホルダーの価値をストーリーとして描くことから始めるのです。その際には、心に踏まえていた「やりたいこと、やるべきこと」を価値の手段として入れ込むことになります。しかし、手段のまま表現するのではありません。「誰にとって、どんな時に、どんな手段で、どう嬉しい」といったストーリーとして表します。

つまり、やりたいこと、やるべきことは手段であり、価値を表す部分でしかありません。この部分がとても重要なのは確かなことではありますが、手段だけでは人は価値を実感できないものなのです。

このようにして作成した価値のストーリーによって「やりたいこと、やるべきこと」の価値を評価することもできます。実際に、価値のストーリーに手段を入れ込んで書いてみると、自分達が考えていた手段は、これまでの慣習的なものが多かったということや、あまり役立たない（価値が感じられない）ものも多かったということに気が付くことが多いでしょう。この気づきは、他人だけでなく自分自身も価値を実感できないということからくるものです。

また、価値のストーリーから考えることで、これまでの慣習に捕らわれずに未来に向けた価値のある手段を発見できるようになります。

価値をストーリーとして描いた後は、シーズ、ニーズという２つの価値の要素をルールに従って組み合わせることで、上記図の中段の戦略要求が作成できます。これはマジックのように思われるかもしれませんが、やってみると、「なんだそういうことか」と思われるでしょう。これについては「4.実践方法解説」にて詳しく説明します。

このように、価値のストーリーの構成要素から戦略要求を作り出すことで、戦略とか業務とかを難しく考えることよりも、感性で感じる魅力主体の価値から考えることができ「ワクワク・ドキドキ」しながら楽しくチームでデザインしていけますので、若い人たちも難しがらずに楽しくワークを行えるようになります。 後は、この図の矢印通りの進み方になりますが、価値と要求と活動を行ったり来たりすることで、全体的な洗練化が図れるようになります。

２．分かりやすく、ドキュメント量が少ない

価値駆動開発プロセスで作成するものは、図1.4-3で示すように、全てシンプルな数枚のモデル（形式的な図）で表します。すべてのモデルは１枚で完結するため分かりやすく、ドキュメント量も少なく、変更容易性が高いため保守がしやすいだけでなく、人の頭の中に記憶されやすいという特長があります。

３．再現性がある

価値駆動開発プロセスは再現性があります。これまでのビジネス価値を描く手法などでは、思考のための体系やプロセスが明示的に含まれておりません。そのために、もう一度他人がやったら、異なるやり方で進めることになります。
価値駆動開発プロセスでは、人の思考法の領域までモデルとして表現されているため、参加者は、価値からはじめる思考法を身に付けるようになるのです。これはプロジェクト参加者が「思考の整理棚」を頭の中で理解・共有しているからできることとなります。

思考の整理棚の引き出しに自分達の考えを当てはめていくことで価値から活動まで全体的な意識合わせが可能となります。そのために議論の空中戦のような時間ばかりかかることが少なくなります。思考の整理棚の引き出しには「価値（シーズとニーズ）」「戦略要求」「業務要求」「IT要求」「活動」があります。
チームメンバーは、この思考の整理棚が頭の中に形成されるため、他のプロジェクトに配属されても、同じ棚を使って進めることができるようになります。
この思考の整理棚（思考のフレームワーク）と、プロセスがあるために、チームの参加者全員が一定の思考法の枠組みを手に入れることができます。これが思考の整理棚のことを思考のフレームワークという所以です。このフレームワークとは、引き出しの中に入るアイデアは阻害せず、思考法としての「中身なき枠組み構造」を提供しているという意味があります。

これにより、アイデアをビジネス価値や自社戦略に繋げるための思考法という枠組みが提供されているために、一度実施した成功する方法を、次のプロジェクトで再現できる可能性が高まるのです。これが「再現性がある」という意味なのです。

この思考の再現性を実現するには、一歩踏み込んだ手法としての工夫が必要となりました。それは、双方向に行き来することが可能なプロセスに、思考の枠組み構造を提供し思考間のトレーサビリティを確保することで可能となります。

また、価値駆動開発プロセスでは、開発プロセスの中で知情意の考え方を説明するだけではありません。価値駆動開発プロセスの考え方のコアとなる原理原則について「2章　SE4BS宣言」で、詳しく説明しています。この原理原則を理解することで、多様な現場の価値駆動開発の実現の際に、その根本的な考えを外さないで、価値駆動開発プロセスを実施できるということも再現性という意味に含まれています。

４．トレーサブルである

価値駆動開発プロセスは、トレーサブルであります。トレーサブルとは追跡可能性ということです。これはプロセスとして「価値」「戦略要求」「業務要求」「IT要求」の流れで進めていきますが、それぞれのモデル要素が繋がっているのです。これは概念的に繋がっていることではありません。実際に価値のモデルの要素と戦略のモデルの要素はイコールでなければいけないのです。
例えば「価値」を表現したモデルのモデル要素から「戦略要求」が作られます。「戦略要求」は「IT要求」につながっています。このように全ての関係性が明確なため、上位の「価値」から下位の「活動」まで自由に行き来できるようになります。
この仕組みにより、例えば皆さんが『このIT要求の必要性はなんだっけ？』と思った時には、業務要求の方向にたどっていくことで分かります。「IT要求」がなぜ必要かは「業務要求」を見ることで分かるでしょう。また、「業務要求」なぜ必要かということは「戦略要求」に書かれています。さらに、「戦略要求」がなぜ必要か？、それは、「価値」をたどっていき、そこに書かれている価値のストーリを見ることで、どのような価値をもたらす戦略かが分かります。この「なぜ」が追跡できる仕組みにより様々な観点での「なぜ必要か？」が説明可能となるのです。さまざまな観点とは、「価値という感性的観点」「戦略的観点」「業務的観点」「IT活用の観点」「活動の観点」のことであり、それぞれの観点には、プロジェクトデザインを行う際の重要な観点となります。

この仕組みにより次のようなメリットが生まれます。

• チームの中に納得感やプロジェクトを遂行する自信をもたらすこと
• 価値の実現をイメージするために手段方向に具体化することで、価値の実現について確証を得ることができる

５．アジャイルに作成できる

シンプルなモデルとトレーサブルな仕組みにより、ある程度モデル作成が出来た段階から、前から後ろ（価値から実現）までモデル作成を行き来しながら同時並行で作成することができます。そのため、アジャイルな作業の進め方が可能となり、慣れてくるとワークのスピードアップが容易になります。モデルだけでは、価値の確証が取れない場合は、PoCなどのアプローチにより、価値で記述されていることを目標とし、実際に検証することもあります。

６．活動に携わる人々の思考法でもある

価値駆動開発プロセスは、思考の整理棚のおかげで日ごろの仕事を行う上での思考法としても使えます。
世の中には、なぜなぜ分析というものがありますが、価値駆動プロセスの思考法は、「なぜ」の行先を「誰の価値か？」に向けた究極かつシンプルなのものなのです。そのため、日々の仕事、日常における思考に活用すると非常に効果的な武器として使えるようになります。これも再現性でお話ししたことと同じことですね。

3.4 価値駆動開発プロセスにおけるチームとは

SE4BSにおけるか価値駆動開発プロセスでは、全てを価値からデザインしていきます。ここで言う価値とは、プロジェクトのターゲットとするビジネスあるいはSDGsなど     の社会活動のテーマの価値ということになります。
そのため、従来のソフトウェア開発のチームに加えて、戦略的視点、業務問題解決の視点を持つメンバーの参加が必要となります。このことを図3.4-1で示します。この図は匠Methodの前身である要求開発方法論(Openthology)で提唱されたプロジェクトチームの構成であり、コタツモデルというメタファで親しまれてきました。
コタツモデルと言う名前は、ビジネス成功に向けて皆でコタツに入って議論しながら見える化しましょうというものです。その際の武器として要求開発方法論がありましたが、現在では匠Methodがそれを引き継いできました。そして今SE4BSでもこの概念を引き継いでいるのです。

この図で示されていることをもう少し詳しく説明すると、以下のようになります。

• 戦略的視点                                ....トップ（役員）又はトップの考えを理解する経営企画部門
• 業務問題解決の視点               ….ターゲット業務の部門長やリーダー、主要メンバー
• 技術活用の視点       ….開発部門のリーダー、主要メンバー

この３つの視点を持つ人がチームにいることで、より良い業務開発が可能となるということを表しています。それぞれの視点では、次のような課題を考え、ワンチームでモデルを使って見える化していきます。

• 戦略的視点                 ....自社の戦略としては、どんなメリットがあるのか、どんな言葉で表現できるのか？
• 業務問題解決の視点  ….業務問題をどのように認識し、どう変えるべきか？
• 技術活用の視点 ….この技術を活用すると、どのような業務改革・改善ができ戦略的有効性としては、どんな表現ができるのか？

ここで、コタツモデルにおいて３つの分類を「○○の視点」と書いているのは次のような理由があります。

1. 部門の役職名ではありません。他えばチームにトップや企画部門がいない場合は、それに変わる視点を持つ人を入れましょう。また、トップであろうとも戦略の視点を必ずしも持っている訳ではありません。
2. コタツモデルというメタファーで表現していることは、どの立場で入っているか意識はしてもらいますが、全員が３つの視点をもってプロジェクトを進めるのが最適であり、そのような意識を持ちましょうということを表しています。ですので一人で考える際にも、この３つの視点を持ってください。

3.4.1 日本の慣習的な開発組織からの変革を促進する

価値駆動開発を日本的な開発で考えてみましょう。ここでは、業務システム開発を対象として説明していきます。
日本の典型的なSI開発においては、ITを導入する企業（ユーザ企業）とSIer（SI企業）という関係となります。このような関係の時に、SE4BSのプロジェクトはどこに存在するかというと、ITを導入する企業（ユーザ企業）に存在することになります。
なぜなら、価値駆動開発プロセスで先に示した「価値」、「戦略」、「業務」はユーザ企業側が所有するもので、ユーザ企業の責任で進めることが必要なのです。
しかし、ユーザ企業でこのようなプロジェクト構成をデザインし、価値駆動開発プロセスを遂行することが困難なことが多いのです。現在の日本ではユーザー企業の情報システム部門が弱い立場にあるからです。そこで、SIerとしての開発企業が、ユーザ企業を支えるために、この価値駆動開発プロジェクトを支援しなければなりません。そのために、技術活用の視点を持つグループにSIerの開発メンバーが参画し、技術活用の視点からの意見を出したり、業務問題解決の視点や戦略的視点からどのように技術を活用すべきか提案するという役割を担うと良いでしょう。また、このプロジェクトデザインを行う際のプロジェクト・ファシリテーター役を買って出られるように訓練してください。

SE4BSのチーム構成は、従来のユーザ企業と開発企業の関係性に次のような変革をもたらします。

• 開発プロジェクトの主体をユーザ企業側に取り戻す
• 開発企業は技術力に加えて、新たなスキルとしてプロジェクトデザインを支援する能力を持つ
• ユーザー企業の情報システム部門が強化されることで、テクノロジー主導で業務を変革できるようなる
• 発注側と受注側の壁を撤廃し、ワンチームでビジネス開発を行えるようになる

これによって、これまで日本の以下のような深刻な課題を解決し、新しい時代に向けた価値駆動の新たなビジネス開発スタイルを定着させていくことを狙っています。

• ユーザー企業側にITプロジェクトを成功させる為の責任が希薄となり、その場限りのIT要求をどんどん出すことで要求の爆発が発生しプロジェクトが巨大化する
• 受注側である開発企業は、ユーザ企業側から出る沢山の要求を作ることが目標となり、要求の根拠となる価値などを考えなくなり、そのような箱庭で開発を進めるエンジニアの力が衰えている
• 本来は、テクノロジーの有効活用がユーザー企業の業務や、戦略的優位性をもたらすはずであるが、ユーザ企業から出た要求を基にIT要件定義から進めるやり方の場合、テクノロジーを使ってビジネス価値を高めたり、業務を変革したりする作業が入らず、旧来の業務のためのIT活用に終始してしまっている。

3.4.2      イノベーティブな製品・サービス開発におけるチーム

１．６の説明では、業務システム開発について説明してきましたが、ここでは、DXという言葉に代表されるイノベーティブな製品・サービス開発や自動車や家電等の組み込み製品開発について考えてみようと思います。
旧来の製品開発では、その企業の製品の根幹となるハードウェアありきでソフトウェアが検討されてきました。しかし、最近では、ハードウェアが規格化・標準化されてきているために、先にあげた業務システム開発と類似する開発プロセスに変化しています。
とは言いましても、チーム形成を抽象的な表現で表しているコタツモデルは少々異なります。イノベーティブな製品開発におけるチームを図3.4-2-1に示します。

先に挙げたコタツモデルの違いは、「業務問題解決の視点」が「ビジネス価値創出の視点」に変わっています。これは、ここで挙げるプロジェクトのテーマは、社内業務を変えるということでなく、ユーザー企業や一般ユーザーに向けての製品やサービスを提供するということを想定しているからです。
もちろん、ユーザー企業の内部業務をサービス提供するシステムもあるでしょう。しかし、それは製品企画の観点でターゲットとなるユーザー企業の業務を分析するということになります。その際に重要となることは、「ユーザー企業のビジネス価値をテクノロジーを活かして、如何にして創出することができるか」ということを考える必要があるのです。
それでは、なぜ「製品企画の視点」と書いていないかというと、それは、顧客ビジネスの価値を高める視点に集中しないと売れる製品・サービスが作れないから、あえてこのような名前にしています。

それぞれの３つの視点では、次のような課題を考え、ワンチームでモデルを使って見える化していきます。

• 戦略的視点 …. 自社の戦略としては、どんなメリットがあるのか、どんな言葉で表現できるのか？
• ビジネス価値創出の視点 …. 製品・サービスでお客様の価値を如何にして高められるのだろうか？
• 技術活用の視点 …. この技術を活用することで、どのようにしたら製品・サービスの価値が生れるのか、
  またわが社の戦略的有効性としては、どんな表現ができるのか？