ソフトウェア開発に関わるすべての人へ。プロジェクトの混迷を止める鍵は、意外にもシンプルな問いの中にあります。

ソフトウェア開発プロジェクトがうまくいかない理由を尋ねると、現場からはたいてい同じような言葉が返ってきます。

「仕様変更が多すぎて」「要件の認識がズレていて」「テスト直前に『やっぱり違う』と言われて」——。

これらの原因を辿ると、多くの場合、同じ根っこにたどり着きます。

「そのソフトウェアで何を実現したいのか」が、最初から明確になっていなかった、あるいは関係者で共有されていなかった、ということです。

顧客から示されたRFPや要件書には「機能の一覧」は書かれていても、「なぜその機能が必要か」「それで誰が何をどう感じるはずか」は書かれていない。書かれていたとしても「生産性向上」や「コスト削減」のような括られた表現で具体的になっていないことが多い。

その不完全な情報を出発点にプロジェクトを走らせた結果、終盤になって「私が欲しかったのはこれじゃない」という言葉を聞くことになる。

この構造を「受身なソフトウェア開発」と呼んでいます。

そして、受身なままでは関係者が全員不幸になるのが必至です。

厳しい言葉ですが、実務経験のある方ならうなずける表現ではないでしょうか。

品質について問われると、多くのエンジニアは「要件・仕様通りに動くこと」「バグがないこと」と答えます。

品質管理の権威フィリップ・クロスビーの言葉を借りれば「品質は要求への適合である」。これはこれで正しい。

ただし、ここには隠れた前提があります。**「その要求自体が正しい」**という前提です。

要求が間違っていれば、どれだけバグのないソフトウェアを作っても、ユーザーには価値が届きません。

ジェラルド・ワインバーグはこう言っています。「品質とは誰かにとっての価値である」。

ユーザーが喜んで対価を払う体験や満足度——それが品質の本質だ、と。

この2つの定義は矛盾しているのではなく、車の両輪です。

「要求への適合」と「ユーザーへの価値提供」の両方を実現して初めて、ソフトウェアは"良いもの"になる。

それを“品質が良いソフトウェア”と呼ぶのです。

図1.に示すノートPCの利用者評価データが、この問題を鮮明に示しています。

機能的な充実度（スペックや機能数）が高い製品ほど、情緒的な満足度（「使っていて気持ちいい」「これ好き」という感覚）が低い傾向があるというのです。

図1.機能的価値と情緒的価値（ノートパソコン）

http://japanbrand.jp/ranking/nandemo/35.html

直感に反するようですが、考えてみれば当然かもしれません。

機能が多いほど、どこに何があるかわからなくなる。

事前設定するパラメーターが増えて利用が難しくなる。

自分が使わない機能のために費用を払わされている感覚が生まれる。

実際、スマートフォンに入っているアプリのうち、毎日使っているもの／使ったことすらないものはそれぞれいくつですか。

いつも利用しているアプリの中に存在する機能のうち、いつも使うのは／使わないのはどれですか。

それにいくら支払っていますか。

以上の理由でソフトウェア品質を「機能的価値」だけで語るのには限界があります。

ソフトウェアに対するユーザーの評価を実際に決定づけているのは、実際に使ったときの感情や体験——すなわち**「情緒的価値」**の側です。

これらの「価値」をもう少し詳細に見てみましょう。

マーケティング理論家デイヴィッド・アーカーが提唱した価値の3階層に照らすと、こうなります。

　　•機能的価値：機能・性能・スペックがもたらす直接的な価値

　　•情緒的価値：使うことで得られる心理的満足感・感情的体験

　　•自己実現価値：その製品・サービスを通じて自分らしさを表現できる感覚

図2.　価値の3階層

そしてこの3つの価値は連動しています。

機能的価値が情緒的価値を生み、情緒的価値が自己実現価値へとつながる。

逆から言えば、自己実現価値や情緒的価値を先に設計し、それを実現する機能的価値を導くという順序で考えることが、本来は正しいはずです。

ソフトウェア品質モデリングが提案するのは、まさにこの「逆から考える」アプローチです。

従来の開発は「要件→設計→実装→テスト」という流れで、出発点は顧客から渡された要件書です。

しかし品質モデリングは、ビジョン・ミッション・ポリシーという組織の意図から出発し、次のような問いを先に立てます。

「誰に、どのような局面で、どのような価値が提供されることを目指すのか？」

この問いへの答えを、さまざまなモデル（価値連鎖モデル、現状分析モデルなど）を使って構造化します。

そうして初めて「だからこの機能が必要なのだ」という根拠のある要件が導かれるのです。

図3.　ソフトウェア品質モデリングの全体像（例）

図4.To-be価値連鎖モデル（例）

この構造が明確になると、開発現場に大きな変化が起きます。

たとえば、プロジェクト途中で顧客から「この機能を追加してほしい」と言われたとき、目的・ゴールが明確になっていれば「それは開発目的に寄与しますか？」と問い返すことができます。

必要であれば代替手段を提案し、関係のない機能であれば次期開発へ回す判断も容易になる。

モノづくりに強みを持つエンジニアが、より適切な解決手段を提案できるチャンスも生まれます。

これは顧客への反論ではなく、目的を共有しているからこそできる建設的な対話です。

さまざまなモノが溢れ、VUCAと呼ばれる変化の激しい時代、「良いモノを作れば売れる」という前提はとうに崩れています。

似たようなソフトウェアが溢れる市場で選ばれるためには、これまでにない体験や価値を提供するものでなければなりません。

さらに生成AIの登場が開発の生産性を大きく変えつつあります。

ただし、現状のままでは「そこそこのバグのないソフトウェアをより速く作る」ための変革にしかならない可能性もある。

誰も気づいていない新しい価値を見出し、それを実感する主体はAIではなく、あくまでも人間です。

だからこそ、何のために作るのかという問いを人間が持ち続けることが、今後ますます重要になっていきます。

品質モデリングという言葉は少し難しそうに聞こえるかもしれませんが、核心はシンプルです。

「このソフトウェアを使った人は、何を感じて、何を達成できるのか？」

この問いに、開発チームと顧客が一緒に答えられる状態を作ることが、受身な開発から抜け出す第一歩です。

要件書を受け取る前に、あるいは受け取ったその日に、この問いを立ててみる。

それだけで、プロジェクトの進み方が変わり始めるかもしれません。