Amir Khella / 青木靖 訳
2010年2月17日
2004年の夏、私は最初の起業体験を変わった場所ですることになった。夏休みをMicrosoft Researchで過ごさないかという招待を受け取ったのは、私がまだ博士課程の学生の時だった。私が関心を持つ領域で研究している最高の研究者の何人かがそこにいたので、彼らがどんなことをしているのか是非見たくもあり、彼らの仕事に関わりたいとも思った。それで私は青い方の錠剤を選ぶことにした。
初日のオリエンテーションの後、自分がやることになるプロジェクトが何なのか教えてもらおうと、メンター役の人の部屋に行った。机の前に私が座ると、彼は研究論文やノートの山の間から私のことを覗き込んで、大きな笑みを浮かべながら言った。「やあ、来たね。僕らと12週間一緒にやることになるから、なんか面白くて役に立つことをするいいよ！」 彼のことを見つめながら、具体的なタスクが何なのか教えてもらえるのを待っていた。彼は続けて、「君は何百という研究者や何万という社員にアクセスできるんだから、それをうまく活用するといい。じゃあがんばって！」 それから彼はチームの他の人達に私を紹介し、この後の12週間を私が過ごすことになる部屋を教えてくれた。私が「次の大いなるもの」を生み出さんとする場所を。少なくとも私がその時に感じたのはそういうことだった。
翌朝、他のインターン達はもう研究論文をプリントアウトしたり、ソースコードを読んだり、タスクについてチームと議論したりしていた。私はといえば、どこから始めたらいいのかもわからずにいた。怖くもあったが、興奮してもいた。
既存のツールにどんなものがあるのか眺めたり、以前に書かれた論文を読んだりするところから始めた。そうしているうちにプランBを考えるようになった。もし最初の2週間で何かオリジナルなものを考えつかなかったら、既存のプロジェクトのどれかを改良することにしよう。
それからチームといくつかのアイデアについてブレーンストーミングしたが、どれにも決めることができなかった。最初の週末は会社で過ごし、「クールでエキサイティングな」アイデアを、典型的な孤独な科学者のやり方で考え出そうとした。ホワイトボードをアイデアで埋め、自分の新しい机を書き散らした紙で覆った。しかしどこへたどり着く気配もなかった。私にはどのアイデアが他より優れているか判断する基準がなかったのだ。最初の気づきが訪れたのはその時だった。自分はアイデアにばかり目を向けていて、最も貴重なリソースのことを忘れていた。人だ。私の研究テーマはプログラマの生産性だったが、私にはMicrosoftにいる何万というプログラマにアクセスすることができたのだ。
ホワイトボードに書いたことはきれいに消した。アイデアが全部なくなって自由になり、想像するかわりに見出すことに集中できるようになった。開発者たちが日々本当に苦しんでいる点は何なのか？
教訓: 素晴らしいアイデアがオフィスの壁の中で見つかることはめったにない。
次の月曜に、私はインタビュー項目を準備し、ボイスレコーダーを買い、インタビューする開発者をリストアップした。その週は毎日6時間近くを、プロジェクトや環境やチームのことについて開発者たちにインタビューして過ごした。自分でも何を探しているのか分からなかったので、彼らが話してくれることは何でも聞いた。そして彼らは私が聞きたいだけいくらでも話してくれた。前の日に手に入れた興味深いパターンやトリガーに基づいて、インタビューで聞く質問を毎日改善していった。ボイスレコーダーの録音は、聞いた内容を遡って確認するのに役立った。
その週の終わりにメンターと打ち合わせをして結果を分析した。すべてのインタビューを通して共通のパターンがあるのが明らかになった。開発プロセスの中で最も苦痛で時間がかかる部分はコードを書くことではなく、既存のコードを理解することだったのだ。Microsoftのような大きな組織では、ソースコードは何人もの開発者の手を経るものであり、コードを理解して新しい機能を追加するために、時には誰かが何年も前にした修正に立ち戻る必要があった。元々そのコードを書いた人間に接触出来ない場合、それは苦痛な作業になり得た。
教訓: 判断を差し挟まずに進んで聞くこと。
うまく痛点を見つけることが出来た。次に、それに対処するためにみんなどんなことをしているのか知る必要があった。別な質問項目のリストを作ってまた開発者にインタビューしに行くことも考えたが、もっと深い洞察を得たいと思った。この痛点に直面したとき、彼らがどうするのか知りたかった。それでMicrosoftで使われている開発ツールのVisual Studioにコードを仕込んで、ナビゲーションや編集の過程を記録出来るようにした。それから実験を計画した。ユーザは既存のプロジェクト(C#で書かれたテトリスプログラム)を与えられ、バグを修正し、機能を追加することを求められる。タスクを完了するためには、プロジェクトにある25のクラスの中のいくつかを調べ、そこにある関数や変数の役割を理解する必要があった。
確認したい仮説が２つあった。１つ目は、熟練した開発者は新人よりもプログラムの理解が早いということ(簡単な方の仮説)。２つ目は、経験深い人がコードを理解するときに共通にやることで、経験の浅い人がやらないようなことが何かあるはずだということ。それで上級の開発者5人と新人の開発者5人に協力してもらって、時間と成功率を計測し、何をしようとしているのかとか、解がどのようなものだと想像しているかといったことについて、作業しながら思っていることを口に出してもらうようにした。また、彼らがコードをいじっている間、操作がログファイルに記録されるようにした。
その週の後半にExcelマクロを書き、Visual Studio内の「活動の流れ」を収集し、開発者が見たコードの範囲や辿った経路を集計してチャートを作った。
嬉しいことに、仮説はどちらも正しいことが分かった。経験深い人は経験の浅い人よりもソースコードの理解が早く、コードを理解するときに共通の経路を辿っていたのだ。
教訓: ユーザが言うことに耳を傾けるだけでなく、彼らがしていることに目を向けること。
この時点で私は解くに値する問題を手にしており、どう解くかについてもいくつかアイデアを持っていた。しかし私は、ミーティングルームでチームとブレーンストーミングをしてもっとアイデアを出すという以上のことをしたかった。ユーザも巻き込みたいと思ったのだ。それで開発者たちをさらにインタビューする予定を組んで、私がやろうとしていることが何かということと、解決法について一緒にブレーンストーミングしたいということを伝えた。そしてその結果として、私が解こうとしている痛点を患っている張本人である彼らユーザは、とても独創的なアイデアをいくつも考え出すことになったのだ！ これは私にとって新鮮なことだった。私は良いアイデアというのは作っているチームから生まれるものであって、使っている人から出てくるものとは思っていなかったのだ。ここにあるリソースがどれほど豊かであるか、そしていかにわずかしか活用されていないかということを、再び思い知ることになった。
その週の終わりには、チームを何年かの間忙しく働かせるに足るだけのアイデアが集まっていた。私達はそれらのアイデアについて議論し、そのいくつかは非常に見込みがあり、プロトを作ってテストしてみる価値があるという結論になった。
教訓: ユーザは問題を持っているかもしれないが、彼らは解もまた持っているかもしれない。
あるブレーンストーミングセッションで、ユーザがすごく興味深い質問をした。「ソースコードをAmazonで本を眺めるみたいに見られたとしたらどうだろう？ レコメンデーション付きでさ？」 この質問をきっかけとして、私達は最初のプロトを作った。FAN(Frequently Accessed Next よく次にアクセスされるところ)という名前で、他のユーザたちが今いる場所から次に行った場所のリストを提供するソーシャルレコメンデーションパネルだ。Amazonのレコメンデーションと同じ感じで、「この変数をデバッグした人はこの関数も見ています」と教えてくれるのだ。
もう１つのプロトは記録されたログファイルから思い付いたものだった。ユーザはそれぞれのタスクで一部のクラスだけを対象として作業することが多いが、それらをすべてのクラスの長いリストの中から毎度見つけ出す必要がある。この問題に対処するため、特定のタスクで必要となるクラスを自動的にフィルタリングしてユーザに提供する、カスタマイズ可能なクラスのワーキングセットを作った。最後に、ソースコードのゲシュタルトなイメージをユーザに見せたいと思って、プロジェクトの中で一番「ホットな」部分が分かるヒートマップUMLダイアグラムを作った。
これらのプロトには本当に効果があるのかを知りたくて、私達は7人のプログラマを相手に一連の実験をし、このプロトを使った場合と使わない場合とで作業効率を計測した。結果として大きく改善されることが分かった。
教訓: 小さな変化が大きな改善に繋がりうる。
それらのプロトタイプはその後ずっと大きなプロジェクトへと成長し、何人かの研究者がフルタイムで取り組んでいる。さらにMicrosoft内で複数の製品開発チームにより活用されている。
できたものに対する私自身の貢献はごく小さなものに感じられる。問題について教えてくれたのも、その解決法について手助けしてくれたのもユーザなら、その解決法がいかに優れているか示してくれたのもユーザだ。ほとんどの貢献は彼らのものなのだ！
この実験とプロトについてもっと知りたければ、InfoVis’05で発表した論文がある。
この記事が役に立ったという人には、スティーブン・ブランクの顧客開発についての本と、エリック・リースのリーン・スタートアップについてのブログを読むことをおすすめする。
| home rss |
オリジナル: My four steps to the epiphany: Lessons learned from creating a minimally viable research product |