サイボウズ松山開発部の門屋(@ryokdy)です。サイボウズ製品の開発をなんやかんややっています。今日は、プログラマが問題を解くということについてお話したいと思います。
問題を知る
開発チームには、日々、様々な要望が送られてきます。サポート部門からであったり、営業からであったり、時には社長から直接、この機能を搭載して欲しいと言われることもあります。 お客様からの声はありがたいもので、思いもよらなかった使い方や、製品の至らない点に気付かされることが多々あります。 ですが我々はたまに、「んー本当はなにがしたいのか分かりません」と答えます。「はあ？ だからこの機能が欲しいんですよ」「でもその機能で何が解決したいのか分からないんです」みたいな会話が続いた挙句、「ユーザーがそう言ってるんだから黙って作りゃあいいんだよ」みたいに怒られることもあります。
たとえば、メールにドラッグ・アンド・ドロップでファイルを添付する機能を搭載してほしいという要望があったとします。それだけ言われても、本当に相手が望んでいることは分かりません。そのお客様は毎回大量のファイルを添付する必要があって、複数のファイルを一度に添付できるようにしたいのかもしれないし、そもそもそれ以外の作業に時間がかかっているので、せめてファイルくらいは簡単に添付したいのかもしれないし、もしかしたらプレゼンのときにデモ受けがいいようにしたいのかもしれません。同じ機能を実装するにしても、それぞれやりたいことによって、実現の仕方は微妙に変わってきます。
あるときは、サポート部門から、電源断などが原因でお客様の環境でデータファイルが破損することがあり、とても困っているので、破損したときに不完全でもいいので使える状態にしてほしいという要望がありました。この要望には大変共感できたのですが、我々が本当にやるべきことは、データを不完全なかたちで修復することではなく、データが壊れている原因を突き止めて、壊れないようにするということでした。言われていることだけに気を取られていると、背景にある本質的な問題を放置してしまうことがあります。昨年リリースしたOffice 9ではデータ破損問題への取り組みを重点的に行い、破損件数を大幅に減らすことができました。
本当は何を解決したいのかということについて、開発する側がよく理解しないまま言われたものを実装していると、結局使われない機能が残ることになる、ということをわたしたちは経験的に知っています。お客様はゲームのコントローラーをリモコンみたいにしてほしいとも、携帯電話のスクリーンを指先で操作できるようにしてほしいとも言ってくれません。 逆に問題の本質を知れば、その問題の８割は解決したも同然と言われます。サイボウズでは、本当に解決したいことと、現実にできていないことの差のことを「問題」と定義しています。
なにか新しい機能を搭載しようというときは、一度その機能で解決したい問題はなにか、問いなおしてみるのがよいと思います。そのとき、「誰が、何々したい（あるいは何々できる）」というふうに言い換えてみると、実現したいことがイメージしやすくなります。さきほどのドラッグ・アンド・ドロップの例でいえば、利用者がメールを書くときに複数のファイルを一度に添付したい、あるいはもっと抽象化して、メールをもっと簡単に送れるようにしたい、でもよいでしょう。解決したい問題が分かったら、次にやることはその機能が本当に必要なのか考えてみることです。他の実現手段はないか、開発のコンセプトとずれていないか、本当に今やるべきものか、といった具合です。その製品が操作の簡便さを売りにしたものであれば、すぐに実装したほうがいいかもしれませんし、ファイルの添付をそれほど重要視していないのであれば、今は見送って別の重要度の高い要件を採用しよう、という判断ができます。実現したいことが何か分かってくると、半分くらいの機能はまあ、なくてもいいかと思えてきます。
プログラマの仕事
プログラマの仕事とは、ほとんどすべてが問題を解決することです。もう少し言えば、「プログラムと、開発プロセスに関わるあらゆる問題を解決すること」です。なにひとつ問題を解決していない人はプログラマではなく、知識労働者でもありません。もし周りに意見を言うことが自分の仕事だと思っている人がいたら、鳩かなにかだと思って無視しましょう。不幸なことに上司だった場合は、こっそり逃げ出しましょう。
プログラムに関わる問題とはたとえばこのようなものです。
- あるページのロードが恐ろしく遅い。異常にハイスペックな開発の奴のマシンでは速い。
- 削除できない誤爆データがある。
- 社長のつぶやきに自動的にいいね！を押したいという要望がある。
- Chromeでしか動かない。IEではログインすらできないがなぜかコピペしたIEハックが残っている。
また、開発プロセスに関わる問題はこのようなものが挙げられます。
- 不具合曲線が収束しないばかりかほぼ垂直になってきた。
- 納期に間に合わないときに限って歯医者に行く奴がいる。
- Unitテストがreturn trueで放置されている。
- 朝のスクラムミーティングに必ず知らないインド人がいる。
わたしたちプログラマは日々、こういった問題をひとつずつ、根気よく解決しなくてはなりません。具体的な問題を解決するための手法は扱う問題によって違うでしょうし、わたしも語るほどのノウハウはありません。ひとついえるのは、考えないとなにも解決しない、ということです。やみくもに考えても仕方ないので、考え方の参考になりそうな本を2冊紹介してみます。
珠玉のプログラミング―本質を見抜いたアルゴリズムとデータ構造(ジョン ベントリー)
あるプログラミングの問題を解くためのアルゴリズムとデータ構造を、どのようなアプローチで求めればよいかという手法について解説した本です。コードは古いですが、パズルを解くような感覚で読み進められるので、とっつきやすいと思います。この本の中では、本質的な問題をとらえて解決したアルゴリズムを、Aha! argorithmsと呼んでいます。
スタンフォード大学のポリア教授という数学者によって1945年に書かれた本です。 マイクロソフトの新人プログラマ全員に配布される本だとか。難しい本なので、要点をまとめるとこのような感じになります（ポリア先生ごめんなさい）
- 実際的な問題はいろいろな点で数学の問題とはちがっているが、解答の主な動機や手続きは本質的には同じものである。
- 未知のものはなにか、与えられているものはなにか、条件はなにかという3つの問いから出発するのが望ましい。
- 問題解決のステップとは、問題を理解し、計画をたて、計画を実行し、ふりかえってみること。
どちらの本にも共通することは、問題の本質を理解すること、与えられている条件をくまなく使って問題を解くことの重要性について述べられているということです。サイボウズではこの1年間で、パッケージ製品からクラウドサービスへドラスティックな転換をしました。そのために問題を解決するための前提条件も様変わりしました。これまでお客様の環境にインストールしてご利用いただくことを前提としていたものが、インフラを自分たちがコントロールできるようになったのです。たとえば、ファイルのダウンロード中にデータベースがロックするという問題があったとき、これまでロックの解放をこまめにしたり、アップロードできるサイズを制限するといった対処しかとれなかったものが、reproxyを使ってプロセスを即時解放するという選択肢がとれるようになりました。このように、前提条件が変わることで、最適な解決の仕方も変わってきます。つまり、その問題がどうしても解けなければ、思い切って前提条件を変えてしまえばいいということです。
最後に
12/16日に、サイボウズ松山オフィスでCode HAIKUという勉強会を開催することになりました。第一線で活躍するプログラマのみなさんが旬な話題について語ってくれます。ラボの竹迫(@takesako)さんとkintoneプログラマの鉄平(@teppeis)さんも東京から来ます！ わたしもちょっとだけなんか喋ります。 無料ですので、松山市近郊にお住まいの方はぜひご参加ください！
Code HAIKU 2012 http://atnd.org/events/33788
