セカイノカタチ

世界のカタチを探求するブログ。関数型言語に興味があり、HaskellやScalaを勉強中。最近はカメラの話題も多め

システムの発注者は自分に必要なシステムを自分で知らない

f:id:qtamaki:20160623093751g:plain

システム開発系のエントリーでちょいちょい言及していますが、自分が欲しいと思うものが、本当に必要だったものとは限らないと言う話です。

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

上に張った画像は、ネットでよく流れている、システム開発(やサイト構築)などを皮肉ったジョークですが、この図で本質的に重要な事は、最初と最後の絵だけです。

途中、色々な人の思惑が混ざり、紆余曲折を経るわけですが、「最初に顧客が注文したとおりに作っても不正解」というところが最高にクールです。

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

システム開発における不可知の原則

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

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

呼び名がないと面倒なので、ここでは「システム開発における不可知の原則」と呼びます。

この不可知の原則によって、システム開発に関わるあらゆることが、反直感的に振る舞います。

何故ならば、人は自分のことを自分で知っていると思ってしまいがちだからです。

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

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

自分向けのツールを作る

2000年代初頭、自分が初めて作ったWebサービスは、OneLineChatを言う名前で、一行ずつコメントを残していくだけの小さな掲示板アプリでした。

自分向けに自分が使いたいアプリを作るというのは、とても勉強になります。

初めて自分用にアプリを書いてみて、愕然としました。

「こうしたら楽しいだろうな」と思って作ったツールが、全く使い物にならなかったのです。

出来上がったツールの使いにくいところ、当初想定していなかった使い方などを改善していくことで、ようやく「その方向性のツール」として実用に耐えるようになります。

この経験は、僕のシステム開発に対する取り組み方に大きく影響を与えました。

それまでは、システム開発がうまくいかないのは、「お客様の意見をうまくヒアリングできていないからだ」と思っていました。

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

しかし、その前提が間違っていました。

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

その後、15年以上システム開発の仕事を続けていますが、未だこの原理を破るような事例にあったことがありません*1

システム開発プロジェクトを成功に導くには

ゴールの見えない競争に勝つことはできません。

まずは、一刻も早く「不正解」を作ることです。

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

とは言え、時間が無限に有るわけではないですから、最小のコストで不正解したほうが好ましいのは事実です。

そのため、最小のコストで目標に向かっているか検証可能な(つまり動作可能な)システムを作る必要があります。

これは、結果的にアジャイルというパラダイムが目指していることと合致します。

プロダクトにおけるMVPとインクリメンタルの大切さ

ここ数日、ウォーターフォール開発の是非についてのエントリーを続けてきましたが、ウォータフォールの致命的欠陥と、アジャイル的な開発手法の必然性は、ここにあります。

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

MVPとは、Minimum Viable Productの略で(Most Variable Personではないです)、「検証可能な最小限の製品」ということです。

「不可知の原則」は、システム開発に限ったことではなく、もっと一般的な原則だということです。

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

もし、全く需要がなければ、別の仮説を立て、MVPを実装すれば良いことなので、リスクも最小限に抑えられます。

うまく行けば、顧客からのフィードバックを得て、インクリメンタルに強化していくわけです。

ソクラテスは偉大だった

現代のソフトウェア開発(とスターアップ)を支えているのは「不可知の原則」です。

人々は、自分が無知であることを知ることによってこそ、先に進むことができるのです。

古代ギリシアの偉大な哲学者ソクラテスの言った「無知の知」そのものですね。

昔の人は偉かった。

*1:数少ない例外がスティーブ・ジョブズです。彼は自分が、そして世界が必要としているプロダクトのビジョンを目の前に存在するがごとくありありと想像できたそうです。世界でも稀有な存在だったのだと思います

*2:ここでも「正解するために不正解する」という逆説が出てきます。本当に直感に逆らいます。ソフトウェア開発のセオリーをオールドタイプのお偉いさんに説明するのは不可能だと思います