読者です 読者をやめる 読者になる 読者になる

新人の開発研修を見て思ったこと

今日は、会社で今年わたしのいる開発チームに入った新人の研修発表会があった。研修といってもすでに配属は決まっているので、いわゆるOJTというやつだ。うちの会社はクラウドサービスを作って提供していて、新人は学習をかねて製品のコードに手を入れて、好きな機能を追加してみたり、改良してみたりする。ただし研修の成果物が実際にリリースされるわけではない。今年チームに入った新人はふたりだったのだが、そのふたりの発表内容が対称的で、興味深かった。

ひとりめの新人が追加した機能は、ユーザーからの要望はまずないといっていいものだった。だが機能としては面白く、あると確かに便利かもねと思わせる内容だった。それに対して、もうひとりの新人が実装したのは、ユーザーからこんな機能もないのかといわれてもおかしくないような、想定する利用シーンがわかりやすいものだった。どちらのアプローチが優れているということではない。いわゆるプロダクトアウトか、マーケットインかというやつだ。ないニーズを作り出すか、すでにあるニーズを取り入れるか。方法はどちらでもよいが、開発は最終的にユーザーに選ばれる製品をつくらなくてはいけない。そういう意味では、ふたりとも結果的に失敗していた(製品のコードを触るのがOJTの目的なのでそこまでハードルをあげるのは可愛そうだと思っているけど)。

一度リリースした製品にしろサービスにしろ、普通は顧客からのフィードバックを得て改善したり、機能を追加していったりするものだ。ここで作り手は、「顧客が解決したい問題がなにか」ということを見極めなくてはいけない。画像が多すぎるから減らして欲しいという要望をそのまま聞いてはいけない。顧客は本当は画面をもっと速く表示してほしいのかもしれない。やるべきことは画像をやめて文字にすることではなく、画像をキャッシュさせることかもしれないし、データベースのチューニングかもしれない。データが壊れたときに直せるようにしてほしいと顧客にいわれたら、それはデータが壊れないようにしてほしいということだ。顧客は本当はどうしたいかをいわず、あえて遠回しなソリューションを提示しようとする。彼らはやさしいから、我々にできそうなことをいってくれる。この機能さえあれば、自分の問題が解決するのだと信じている。でもそれはたいてい、本質的な問題の解決にはならない。作り手は、顧客がなにをいっているのか、心の耳を傾けなくてはいけない。渡ろうとしている橋の手前に「このはしわたるべからず」と書いてあったとしたら、これみよがしに橋の真ん中を渡ってみせてはいけない。親切な忠告に従わなかったせいで橋が壊れておぼれ死ぬこともある。本当に顧客のやりたいことが理解できるまで、なにもするべきではない。

一方で、顧客は自分がやりたいことさえもわかっていない場合がある。顧客はリモコンみたいなコントローラーを振り回してゲームがやりたいとはいわないし、携帯電話をスタイラスなんかじゃなくて指先で操作できるようにしてほしいともいってくれない。WiiやiPhoneみたいな製品は、お客様の声みたいなところからは生まれないものだ。そういうものを作るのはすでにあるものを改良するよりもずっと難しい。闇の中にある問題を解決するようなものだからだ。そういうものを作りたかったら、まだ表面化していないニーズについて仮説をたてて、誰に、どんな価値を提供できれば成功かというコンセプトを作る必要がある。ここで重要なのは、仮説が正しいか正しくないか検証できるまで、コンセプトをぶらさないということだ。リモコンやタッチインターフェイスやいいねボタンといった機能が絶対ではない。コンセプトが絶対だということを忘れてはいけない。

優秀な新人のふたりはすぐに、技術を魔法のように駆使して製品を作ってくれるようになると思う。魔法は人を幸せにもするし不幸にもする。魔法使いを引退した身で恐縮ではあるけど、正しい目的で正しい魔法が使えるように、これから学んでもらえればうれしい。