『図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書』DXにはDXのやり方がある（目標設定、使命分析）

　日本のDXは90％失敗するといわれている。その根本理由は、DXを要件定義から入るからだ、という仮説をもっている。その仮説を検証するために、要件定義をする「SE」の参考書を読んでみた。

　本書は最初に、要検定後の中核メンバーとして「情報システム部門の担当者」「ベンダー企業のSE」が現れ、「SE」は主人公で、以下の流れで要件定義をするストーリーになっている。

1）要望：個人の夢やわがままも含むもの
2）要求：要望の中で、取り組む価値のあるものを絞り要求とする
3）要件：必要なものを予算内に絞り要件とする

　本書では、これをまとめていく人をシステムエンジニア（SE）としている。しかし、本来の「SE」はシステムス（ズ）エンジニアと呼び、新商品の設計開発マネージャーを指していた。歴史的に「SE」の仕事として有名なのはボーイング社の「B29」とデュポン社の「ストッキング」だ。両方とも当時のアメリカの新商品だ。

　システムズ工学用語辞典（NEC系はシステムズと「ズ」が付く）によると、これらを要求定義工学（要求定義保証戦略、要求定義モデル枠組、要求配分シート）でまとめることになっている。

　そして本書では、要件定義に責任を持つのは、ユーザー（情報システム部門）であり、ベンダーは支援者と位置づけている。

　だとすると、人事、経理などの仕事の枠組みを、ユーザーがはっきりわかっているものは実装できるが、DXのように、未知のものは実装が難しいということになる。なぜなら、ユーザーがアウトカムに責任がもてないからだ。
　例えば、立ち食い鮨屋の仕組みDX化するときに、1）2）3）のプロセスで要求定義をすると間違いなく失敗してしまう。

　これが日本のDXが90％失敗する根本原因だ。
　では、どうしたらいいのか。

　まずは、「要求定義」ではなく、「使命分析」「目標設定」を中心に据える必要がある。その目標をユーザーもベンダーも理解し納得し共有できないことには、何をどう実装するかが明確にならないからだ。

　DXには、DXのやり方がある。

図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書