欲しいと思うものが本当に必要なものとは限らない

ソフトウェア開発の世界ではよく言及されていますね。

みなさんのプライベートではどうでしょうか。

　「ほしい！」

と思って購入した後に後悔したことは１度もありませんか？

たとえば「家」や「マンション」を購入したあとに後悔した…なんて話はよく聞きますがどうでしょう。同じようなことがソフトウェア開発の現場でもよく起きます。

もうちょっと強く言うと、コンピューターによるシステムは「作ってみて」「改良」しないと、本当に必要なものを知ることができません。

この画像は、かれこれ10年以上前からよく騒がれていたシステム開発(やサイト構築)などを皮肉にしたジョークです。そこにかかわる人たちはお客さまも含め「誰も同じ方向を向いていない」ことを指しています。

みなさんは開発側企業の立場に立ってみた場合、（それが技術者であれ、営業担当であれ）この10個ある挿絵の中で最も重要視すべきはどれかお分かりになるでしょうか？

実は、この図で本質的に重要な事は最初と最後の絵だけです。

途中、色々な人の思惑が混ざり、紆余曲折を経るわけですが、「最初に顧客が注文したとおりに作っても不正解」というところが言い得て妙です。よって「顧客がそう言ったから」を盾に自身を正当化するリーダーやプロジェクトマネージャーは、最初から確信犯的に間違える気しかないと言えるわけです。

他にも

お客さまと合意形成を図り、言質を取ることは確かに重要ですが、お客さまの意図していることが本当に顧客にとって必要なことなのかを別の立場から考えてあげることは、私たち開発側の役割でなくてはなりません。

このことは、システム開発やデザインやプロダクト開発全般に言えることで、これらに関わる人間全てが肝に銘じて置く必要がある最重要事項の一つとなります。

開発における不可知の原則

ソフトウェア開発において、

開発対象となるシステムが必要とする機能（性能・運用などの非機能）については、
そのシステムを作ってみないと正確に知ることができない

これは絶対的な法則と言っても良い、厳然たる事実です。

そもそもプロジェクト活動には「独自性」という要素がついて回りますので、過去の経験からすべてがわかるということは絶対にありえません。

この不可知の原則によって、システム開発に関わるあらゆることが反直感的に振る舞います。なぜならば、人は「知っている」と思ってしまいがちだからです。

どうしても、暗黙的に「知っていること」を前提に計画を立てるため、知っているつもりであることと現実が乖離すると全てがうまくいかなくなります。

しかし、逆に「知ることができない」事を前提にすれば、近年のソフトウェア工学で行われていることを理解することはたやすくなりますし、リスクとして検討すべきものも見えてくるようになります。

お客さまは神様ではない

以前も説明しましたようにお客さまは神様ではありません。

システム開発がうまくいかない理由によく挙げられるものに、

　「お客さまの意見をうまくヒアリングできていないからだ」

と言うのがあります。つまり「お客様はすべての正解を知っていて、私たちはそれをちゃんと聞き出してシステムを作れば、失敗することはない」ということが暗黙的な前提としてあって、そのゴールを目指すためにより良いシステム開発を目指していけばよいと言うものです。

しかし、この前提は間違っています。

お客さまは神様ではないのです（当然）。
所詮、人なのです。

人は、自分が本当に必要とする物を「作ってみないと」理解することができません。

開発プロジェクトを成功に導くには

ゴールの見えない競争に勝つことはできません。
まずは、一刻も早く「不正解」を作ることです。

正解するためには、それ以外の不正解を全て挙げてしまえば消去法でたどり着くことができます。

とは言え、時間が無限に有るわけではないですから最小のコストで不正解したほうが好ましいのは事実です。そのため、最小のコストで目標に向かっているか検証可能な（つまり動作可能な）システムを作る必要があります。これは、結果的にアジャイルやイテレーションというパラダイムが目指していることと合致します。

反復強化の大切さ

ウォータフォールの致命的欠陥と、アジャイル的な開発手法の必然性はここにあります。いえ、厳密にはウォーターフォールのような進め方であっても早期に検証することは可能です。

ビジネスの世界でも同じで、今日盛んに立ち上げられているスタートアップと呼ばれる起業形態では、MVPということが言われています。

MVPとは、Minimum Viable Productの略で、「検証可能な最小限の製品」ということです。このことからも「不可知の原則」はソフトウェア開発に限ったことではなく、もっと一般的な原則だということがわかります。

製品開発においても（たとえば一週間で作れるような規模で）最小限の機能を作成し、需要が存在するのか検証することが最重要なため、MVPというアプローチを取ります。

もしも全く需要がなければ別の仮説を立て、MVPを実装すれば良いことなので、リスクも最小限に抑えられます。うまく行けば顧客からのフィードバックを得て、イテレーション（反復強化）していくわけです。