とにかく手を動かすこと

若い日本のエンジニアと話していると，「今の職場ではなかなか自分が作りたいものを作らせてもらえない」「せっかくエンジニアになったのに，仕様書通りにプログラムを書くばかりでクリエイティビティを発揮するチャンスがない」などの声を聞くことが多い。

職場にもよるとは思うが，特にITゼネコンを頂点にした産業構造を持ちウォーターフォール型で開発を進める「IT産業」では，そんな思いをしている人もたくさんいると思う。

そんな人たちに私が勧めているのは，とにかく何としてでも自分の時間を見つけて，手を動かして自分の作りたいものを作りはじめることである。作りはじめて見えてくるものもたくさんあるし，上司を説得するにしろ，仲間を集めてベンチャー企業を起こすにしろ，投資家からの資金提供をしてもらうにしろ，何か動いているものがあるのとないのでは説得力に雲泥の差がある。

まずは時間をひねり出す

「こんなものを作りたい」という思いが十分に強ければ，夜中でも週末でも時間はひねり出せるものだ。もし「平日は仕事でずっとプログラムばかり書いているから週末にまでプログラムを書きたくない」と感じるのであれば，そもそもソフトウェアエンジニアという職が向いていないのかもしれない。

本連載第1回で書いたように，ほかの人から見れば「苦しくて大変なこと」も，本当に好きであれば「楽しくてしかたがない」ことに変わる。逆に，週末までプログラミングなんて書きたくないと思っている人に「なんとか時間をひねり出せ」と言っても無理である。

私は高校生のときからプログラムを毎日のように書いてきたが，学生時代は期末試験の直前になると，必ずと言ってよいほど「ものすごく書いてみたいプログラム」の案が浮かんできて困る，という経験をしてきた。「勉強しなければいけない」と思えば思うほど，プログラムのほうに頭がいってしまって能率が落ち，勉強に身が入らなくなるのだ。

そこで，「今日は夜の9時までは思いきり勉強。そこから11時までプログラミング」というようにメリハリのある時間の使い方をしてこの問題を克服したのだが，そんな時間の使い方に思わぬメリットがあることを発見した。「試験前の忙しいときほど逆にプログラミングの生産効率が上がる」のである。「今日は2時間しかプログラムを書くことができない」などのプレッシャーを自分に与えることにより，集中力が増して生産効率が上がるのだ。

普段の仕事がどんなに忙しくても，「どうしても作りたいもの」があれば「時間をひねり出す」ことは可能なはずである。もしそれが不可能と感じるのであれば，たぶんそれほど真剣に作りたいとは感じていない証拠だと思ったほうがよい。

作りながら考える

私が常に心がけていることは，「作りながら考える」ことである。もちろん，ものすごくあいまいなアイデアしかない場合には無理だが，わずかでも自分の中でイメージが具体化してきたらまずはプロトタイプ作りをする。

たとえプロトタイプといえども，ユーザとのやりとりの流れだとかアルゴリズムなどを一つ一つ決めなければ前に進めないので，それがアイデアをよりシャープなものに鍛え上げていく。実際に作ってみる，そして自分自身で使ってみる，実際のユーザに試してもらう，という過程を経ない限りけっして見えてこないものがあるので，そういう発見やひらめきを，プロジェクトのできるだけ早い段階で取り入れる。

つい先週も，その前の週に思いついたアイデアを試してみたくて，日曜日を使って作ってみることにした。ちょうど，neu.Calcという新しい商品の開発とneu.Notesのアップデート版の開発が一段落したところだったので，意識をリフレッシュする意味でも，自分自身のモチベーションを上げるためにも何か「新鮮なもの」に着手したかったのだ。

思いついたアイデアは「指で描いた文字を3次元の画像に変換する」というもので，そのアイデアだけで商品になるかどうかははっきりとはしていなかった。しかし，思いついたアルゴリズムを試してみたかったこともあるし，作りながら「どう商品化をするべきか」を考えてみることにした。

半日かかってアプリケーションの大まかな骨組みが完成し，午後になってようやく本命の3D変換のアルゴリズムの開発に着手した。しかし思いついていたアルゴリズムに致命的な欠陥があることがわかったので，昼寝をして頭を冷やす（私は「頭のガベージコレクション」と呼んでいるが，20分程度の短い昼寝はとても効果的だ）。

アルゴリズムが完成し，当初予定していた「アプリケーションとしてそこそこ使える」ところまで到達したのは午後の5時過ぎ。簡単なサンプルを作って動作確認をしたうえで，neu.Pen LLCの共同経営者である相棒Peteに「プロトタイプを作ったんだけど，試してみてくれない？」と送りつけた。

次の日の朝にはPeteからのフィードバックがきており，そこから商品化へ向けたアイデアの交換をメールで何回か行い，商品の位置付け，開発プランなどを練り上げるプロセスが始まった。

捨てること，作りなおすことを怖がらない

このようなプロトタイプを作るときに大切なことは，書いたコードを捨てること，作りなおすことを嫌がらないことである。

人間誰でも自分が作ったものにはそれなりの愛着がわく。特に，苦労して作ったもの，時間をかけて作ったものを捨てることは難しい。その気持ちが強くなればなるほど客観的な判断ができなくなり，ユーザにとって価値のあるもの，ビジネスにとってプラスになるものを見い出すうえで公平な判断が難しくなる。せっかく作ったプロトタイプが「足かせ」になってしまっては本末転倒である。

その意味でも，プロトタイプはできるだけすばやく作ることが大切だし，最初から「このコードは捨てても惜しくない」と心に決めて取りかかることが重要である。だからと言って，けっしてでたらめなコードを書けばよいわけではなく，プロトタイプとはいえども，インタフェースの設計はキチンとし，手を抜いたところにはきちんとコメントで説明を書いておく。

このプロセスは，新しい食材を手に入れた料理人がまずはそれを使って料理を一，二品作ってみるプロセスに似ている。その料理をそのままお客に出すわけでもないし，そもそもその食材を採用するかすら決めていない。しかし，常にそうやって新しいものに挑戦し，腕を磨き続けているからこそ，常に一流のシェフとしてお客を喜ばせ続けることができるのである。ソフトウェアエンジニアもまったく同じだ。

自分の成長に結び付ける

こんな風にプロトタイプの必要性を訴えても，多くのエンジニアはなかなか手を動かしてくれない。「商品化に結び付かないかもしれないプロジェクトに時間をかけたくない」「せっかく前のプロジェクトが一段落したところだから少しゆっくりしたい」など理由はさまざまだ。

私から見れば「ソフトウェア開発で最もおもしろい部分」である新商品の企画に自ら関わることができる大チャンスなのだが，そこが理解できていないエンジニアが多いようだ。

特に，まだ企画が固まっていない段階でプロジェクトに関わることは，エンジニアとしての幅を広げる意味でもとても有意義だし，仕様書に従ってこつこつと書くプログラムと，仕様書もない段階で1～2日で一気に作り上げるプロトタイプでは，マラソンとスプリント（短距離走）以上の違いがある。

特に大きなプロジェクトになると，開発者1人の生産性が1日あたり数行～数十行まで落ち込むことがあるが，プロトタイプの場合は1日で数千行を書くことが普通だ（先に挙げたプロトタイプは2,200行）。

常日頃からプロトタイプを通じてスプリント型のプログラミングで自分を鍛えておくと，重要なプロジェクトを担当したときに，一気にスタートダッシュをかけてリスクを低減することなども可能になる。

形にして説得する

ちなみに，いつも一緒に仕事をしているPeteは，今回のように何の相談もなくいきなりプロトタイプを送りつける私の開発スタイルに慣れている。アイデアがあまり練れていない段階でミーティングをしても，結局は「細かなことは持ち帰って検討する」ということに落ち着くのが常なことはお互いにわかっているからだ。

それよりも，まずはプロトタイプという目に見える形にしてから，それを叩き台としてより具体的なアイデアを出し合う。その段階ではメールでのやりとりで十分だ。逆に，アイデアがある程度煮詰まってきたり，袋小路にさしかかったときにこそミーティングをして，そこで次のステップにどう進むか（もしくは進まないか）という重要な決断を下す。

注目すべき点は，この「プロトタイプという叩き台を作って企画を煮詰めていく」というアプローチは，エンジニアにしかできないということだ。ソフトウェアのことがまったくわからない人から企画を丸投げされて閉口した経験は多くの人が持っていると思うが，そんな無駄なことを避けるためにも，企画の段階からリーダーシップを発揮するためにも，エンジニアはプロトタイプを作るべきだと私は考えている。

アイデアは誰でも出せる。それを実際に形にできるのはエンジニアだけである。シリコンバレーの投資家が，エンジニアが起業した会社に投資したがるのもこれが理由である。ビバ，エンジニア！