良いプロジェクトの条件について:ウォズニアック伝を読む
『アップルを創った怪物―もうひとりの創業者、ウォズニアック自伝』を読んだ。
Apple社の伝説的なエンジニアによるモノローグ形式の自伝なのだけれども、彼が携わってきたパーソナルコンピュータという産業の立ち上がりから現代にいたるまでのさまざまなエピソードを通してプロダクトづくりの教訓を得ることができた。
それは一言でいえば人は少なく納期は短くということだ。
命がかかっているのに他人事
スティーブ・ウォズニアックという人物の功績は世界で初めて一般人むけのパーソナル・コンピューターを開発したことであると言われる。
それは具体的にはキーボードとテレビ画面に接続可能なコンピューターであるApple Ⅰやその発展型でカラー画面とサウンドとフロッピーディスクを搭載したApple Ⅱの発明なのだけれども、興味深いのは今とは当たり前になっているそれらのプロトタイプを目にしたときの人々の反応だ。
たとえば、ウォズニアックが後にApple Ⅰで実現されることにになるパーソナルコンピュータのプロトタイプを勤めていたHP社に持ち込んでプレゼンしたところ「他社のディスプレイとの接続で問題が起きた際に責任の所在がわからなくなるし、100%動くという保証がない」という理由で却下された。
また、コモドール社はジョブズから持ちかけられたApple Ⅱのライセンス販売の提案を却下し自社で「不要な要素」を切り落とした白黒でビープ音しか出ず外部媒体に従来のカセットテープを採用しためちゃくちゃダサいコンピューターを開発することになったという話も面白い。
これらからわかることは、無責任な外野ではない、その道のプロにとってもプロダクトは他人事であるということだ。
たとえそれに会社や自分の命運がかかっているとしても、大半の人々にとって顧客からのクレームや同僚からバカだと思われることのほうが切実な問題である。
また、そういう人々にとっては「二位じゃだめなんですか?」的なコスパの指摘のほうが否定しがたい真実に思えてしまい、プロトタイプを見せても見るべきものが見えないというのはありがちである。
良いプロジェクトは関係者が少ない
なので、まず良いプロジェクトにとって重要なのは人を絞り、議論や開発プロセスに他人事感が混じることを防ぐことだ。
ウォズニアックが繰り返し指摘していて、彼が去ったあとのApple社でも継承さているのが合議制の否定と開発の関係者は可能な限り少なくすべしというものである。
ウォズニアックはたびたび「真の発明は一人でしか実現できない」と主張している。
その背景にはベトナム戦争に徴兵されかけたときに抱いた「人間も国家もいい加減でありこの世に完璧な組織など存在しない」という諦念や、自信作のApple Ⅰが尊敬していたHP社の上司から却下されたこと、そして彼自身がApple社で経験したApple Ⅱの後継機であるApple Ⅲが失敗したという体験があるだろう。
スティーブ・ジョブズが90年代中盤にApple社に復帰した際にまず行ったのが製品開発の中核になるデザインチームの分離だった。
リーダーであるジョナサン・アイブが予算をめぐって主導権争いをしたりフロッピードライブの廃止やiPodのネジの規格に対する社内の批判を論駁しなくてもいいような環境を用意したのも、「ものづくりにおいて本当の意味で当事者意識をもった人間などというのはごく一部なのであって、彼らのエネルギーを議論ではなく作ることに集中させるのが経営者の仕事である」という認識に基づいている。
良いプロダクトは早く完成する
また、良いプロダクトは早く完成するものである。
創立当初のAppleという会社のスピード感を振り返ると、良いプロダクトは短期間で完成するものであるということがわかる。
本書を読んでいて面白いのがApple ⅠとApple Ⅱの開発期間が異様に短いことだ。
ウォズニアックはApple Ⅰは数時間で設計図を書き終え部品を集めたり検品するのに2〜3ヶ月かけただけと述べており、またApple Ⅱがリリースされたのはその1年後である。
それまで以下のようなランプの点滅によって計算結果を表現していたフロントパネル方式が主流だった中で、世界で初めて白黒ディスプレイに接続されたコンピューターが発明され、さらにそれがカラー画面と音声と外部記憶媒体を備えたものになるまで1年弱しかかかっていない。
開発期間が短いということは、単にそれで稼いだ時間をテストや品質向上にあてられるというだけではなく、それ自体がいかに作り手が確かな製品のイメージを持てているかということの表れであることをこのエピソードは示している。
また逆に言えば、あるサービスのローンチまでの期間を三ヶ月以上に見積もっていたり、ある企業の上場までのロードマップが5年を超えている場合、それ自体がリーダーの解像度が低かったり開発がぼんやりとした人々にリードされていることの表れである可能性が高い。
エンジニアの役割
Apple社の歴史をふりかえると、エンジニアはモノを作ることで豪快に議論を加速させることもあれば、専門用語や有無を言わさない物言いで社内を息苦しくさせ停滞させることもあることがわかる。
なので、エンジニアは言葉ではなく成果物で議論をリードすることを心がけるべきだし、リーダーは開発プロセスにプロダクトとは無関係な異論が入り込む余地をなくして手を動かすことに集中できる環境の用意する必要がある。
99.99%の人間にとってプロダクトは他人事である。
だからこそ、良いプロジェクトを良いプロジェクトたらしめるには、短い納期と最小限に限られたメンバーが必要なのである。
この記事が気に入ったらサポートをしてみませんか?