【05】複雑よりもシンプルな方がいい

　私に言わせれば、電子レンジには「1 分加熱」というボタンが 1 つあれば十分です。コーヒー用の水を沸かすときには、そのボタンを 3 回押します。クラッカーにのせるチーズを溶かすときには、ボタンを 1 回押します。小麦粉のトルティーヤを温めるときには、「1 分加熱」ボタンを 1 回押してから 15 秒後にドアを開けます。

　このワンボタン電子レンジが、商品企画委員会をパスしたことはあるのでしょうか？　おそらくないでしょうね。今の電子レンジの（決して使われることのない）機能を見れば、委員会がシンプルなものより複雑なものを好んでいることがわかります。もちろん、彼らはその「複雑さ」を「機能豊富」という言い回しで隠したのでしょう。しかし、いたずらに複雑な製品を作ることを目標にして作り始める人などいません。複雑さは知らず知らずのうちについてくるのです。

　1 枚の冷凍ピザを温めたいとしましょう。メーカーの取扱説明書によると、まず「メニュー」ボタンを押さなくてはなりません。すると今度は「スピード調理」と「再加熱」というオプションが現れました。（うーん、おそらく「再加熱」でしょうね。お腹がすいているので、スピードの早い方がよいのですが）

　「再加熱」を選ぶと、今度は「飲み物」、「パスタ」、「ピザ」、「料理皿」、「ソース」、「スープ」というオプションが現れました。さて、どれでしょう？（ピザの上にはソースがのっているのですが、ここでは「ピザ」を選ぶことにします）。すると今度は「惣菜 / 生もの」か「冷凍」です。（実際にはどちらでもありません。これは宅配ピザの残り物なのです。おそらく「惣菜 / 生もの」を選ぶのでしょう。）すると今度は「1 枚」、「2 枚」、「3 枚」、「4 枚」ですって？　この質問があとどれくらい続くのか、私には見当もつきません。そこで私は「キャンセル」を押して、「1 分加熱」ボタンを押すことにします。

　この話はソフトウェア開発とどんな関係があるのでしょうか？　私に言わせれば、ワンボタン機能があるのは Amazon だけです。つまり「1-Click 購入」です。確かに初回は住所とクレジットカード番号を入力する必要がありますが、以後はマウスを 1 回クリックするだけで衝動買いできるのです。

　一般的に、ソフトウェアは複雑な問題を解決してくれるものです。ここで問題になるのは、本来の複雑さをどれくらいエンドユーザーに強いるかです。あなたのソフトウェアは複雑さの増幅器になっていませんか？　一般的に、すばらしいソフトウェアというのは複雑さを吸収してくれるものです。問題をユーザーに伝えるのではなく、ユーザーの身代りとなって問題の矢面に立つのです。

　ソフトウェアプロジェクト・マネジャーとして、あなたは複雑さを吸収しようとしていますか？　それとも、複雑さの増幅器になっていますか？　最高のプロジェクト・マネジャーは、あらゆるところ（プログラマ、エンドユーザー、マネジメント）に存在する複雑さを吸収します。決してそれを増幅することはありません。エンドユーザーは一見して矛盾のある要求をするものです。プロジェクト・マネジャーの仕事は、そうした矛盾のある要求の整理を手伝うことです。やみくもに要求を開発者に伝えることが仕事なのではありません。開発者は難解な技術的理由を挙げて、要求を満たせないことを説明するものです。プロジェクト・マネジャーの仕事は、その複雑さを言い換えて（吸収して）、エンドユーザーに別の選択肢を選ばせるのに役立つ情報を提供することです。

　あなたのアプリケーションはどれくらい簡単に使えますか？　アプリケーションに新しい機能を追加するのはどれくらい簡単ですか？　新しい機能を要求するのはどれくらい簡単ですか？　バグレポートはどうですか？　新しいバージョンの展開はどうですか？　不具合のあるバージョンを元に戻すのはどうですか？

　知らず知らずのうちにシンプルになるわけではありません。自分たちで積極的に育てていく必要があります。よく注意していないと、ものごとは複雑になるものなのです。