ITの世界には「銀の弾丸は存在しない」という合言葉がある。これはどうやら狼やドラキュラを退治するときの道具が「銀の弾」らしく、古典的な名著であり、未だに参照され続けている『人月の神話』という本に収められている論文から来ているらしい。なぜ、「銀の弾丸は存在しない」と言われるのかというと、ある諸問題に関して一気に片付けられるような、そういう解決策は無い。少なくともそれらの問題に関しては泥臭く、忍耐を持って接しないといけないという話だ。川を綺麗にするためには根気よく缶を拾ったりしなければいけないのと似たようなものだろう。
元のドラキュラの話を知らないので、Wikipediaで聞きかじりに語るのだが、そもそも「銀の弾丸」といったところで、その「銀の弾丸」を使う存在というものがいる。ドラキュラの場合、それが「ヘルシング教授」である。ヘルシングといえば平野耕太の漫画を思い出すが、どうやら原作のドラキュラでは、この教授がドラキュラを退治したらしい。でもって、ドラキュラ・ハンターのことをヘルシングと呼ぶらしい。
この記述を読みながら、「ああ、なるほど、ヘルシング教授というのは銀の弾丸なのか」なんていうことを考えたりしていた。
プログラマーが好きな話題として、「生産性のあるプログラマーは」というのがある。生産性のあるプログラマーは10倍とか100倍とか言われるが、自分が平凡なプログラマーであるが故に、この手の話題は好きにはなれない。あともう一つ好きになれないのは、それがプログラマー単体の問題に終始してしまって、環境とか、あるいは関係性なるものを考えるのを捨ててしまっているからだ。はっきり言ってしまうと、あるプログラマーが如何に早くコードを書くか、というのは問題ではないんだと思う。大・中規模の会社だと、こんな理想的なことは言ってはられないけど、でも少なくとも理想としては「単体のプログラマ」の話を云々するよりも、全体のプログラマの作業を底上げする方法のほうが、たぶん大切なんだと思う。
なぜ環境の問題や、人間関係の問題を言うのか。というのも、プログラムというのは、繊細な作業であると思っているくらいでちょうどいい作業だからだと思っているから。優秀なプログラマが優秀なプログラミングを行うさいには、例えば自分が作業に入り始めたら邪魔が入ってこないとか、自分が大切にしている価値観が配慮されないまま物事の進め方を決定されるとか、あるいは、周りがそもそも「良いプログラミングをしていこう」みたいなことを考えていないとか、そういうことによって作業効率が落ちてしまったりする。もちろん、プロフェッショナルなんだからどんな環境でも一定の力を……って言うのは正論かもしれないけど、でもそういうので作業効率が変わってしまうのは仕方ないことだと思う。
現実をシビアに考えてみる。そのシビアさというのは、自分のところにはドラキュラを退治してくれるヘルシング教授はやってこないだろう、という過酷な認識から始めるべきだと思う。いや、貴方がお金を持っていたり、あるいは知名度が半端ないとかであるならば、それを期待してもいいだろう。しかし、そうでないならば、優秀なエンジニアがやってきて、全ての問題を解決してくれるということは、それこそ宝くじを拾うようなものだ、と考えるくらいで僕はちょうどいいと思っている。事実、良く言われるように、優秀なエンジニアというのは、既に何処かの企業に拾われているだろうからだ。
こんなエラそうなことを書いている自分は、はっきりいってポンコツであることは疑いようがない。とはいえ、ポンコツがポンコツとしてうじうじしていても仕方はない。だからポンコツはポンコツなりに、どう自分のポンコツと上手く付き合っていくかを考えないといけないだろう。
例えば、自分のポンコツ事例だと下のような感じだ。
- 仕様書を読み違える
- デプロイの手順を間違える
- ついつい一つの作業をやりすぎてしまう
で、このポンコツを直すためにはどうすればいいのか。
- 仕様書を読み違える -> チケットを切って作業を行う、あるいはテストを書いて理解している仕様を明確にする
- デプロイの手順を間違える -> chefやansibleなどのコードに書き下せるツールで手順をスクリプトまかせにする
- ついつい一つの作業をやりすぎる -> HipchatにGitHubのコミットを流して、作業を共有する
という風に、基本的にはこのラインで考えている。
たぶん、人としてあんまり評判は良くない毛沢東という人が書いた『矛盾論』という本には面白いことが書いてある。「問題は、大問題と小問題に別れる。私たちは個別に現れる小問題を退治することに懸命になるが、小問題は大問題が生み出しているものであり、大問題を解決しないことには、個別の小問題というものがいつまでも生まれ続けるだろう」という内容だ。
僕が思うに、最終的な目標として、平凡な僕たちが、些細なことに患われずに、如何にしてユーザーに価値を提供するために、価値を届ける手段として、どのように機能を開発するのか、という問題だ。そのときに個別に出てくる問題というのは、きっと小問題だ。例えばプロジェクトが炎上するとか。そのときに、大問題に対して意識しておかないと、いつまでたっても「なんでこんな同じ事をしているんだろう」ということになってしまうし、実際それに悩んだことがあった。で、余裕が無かったりすると、このあたりに対して「まあまあ」といったような感じになってしまう。そうすると、次第にその状況に対して鈍感になっていく。しかし、このITという世界は面白いもので、そういう「これって問題だよね」ということに対して、どんどん解決法が提供されたりする。
最近は、企業のスタートアップの話をたまにチェックしたりするのだけれど、結局のところ「優秀なエンジニアを集めるのが、成功において重要なものである」という身の蓋もないことが書いてある。事実、著名なプログラマの人も「優秀なエンジニアを集めることが大切」みたいなことを言っている。これは恐らく事実だ。僕も、もしスタートアップが資金力に溢れていたり、あるいはプログラマの人を惹きつけるようなビジョン、スターエンジニアがいるなら、それでもOKだと思う。しかし、多くの場合はそうではない。僕は自分の参加しているスタートアップが目指すところは最高にクールだし、それに同意するけれども、しかし、それでは上手く人は惹きつけられるものではないし、自分の感受性自体が非常に特殊であることも理解している。
とするならば、やるべきことというのは、「優秀なエンジニアを採用する」ではダメで、「平凡なエンジニアでも、優秀なエンジニアと同等の力を発揮できるような環境を整えていく」ことであり、そういうことが出来るようにしていくことだと思う。
とはいえ、そういうことを考えられるということが、優秀なエンジニアの条件かもしれないが、それは主旨が外れるので別のお話。しかし、優秀なエンジニアであるなら1から10まで出来ることを、平凡なエンジニアたちが1つずつ持ち寄って改善していって、5つの改善が出来れば、そっちのほうがいいとは思う。
追記 (2013-11-24 16:30:00)
どうやら「手持ちの戦力でどうしようか？」みたいな話を期待されていた方もいらっしゃったらしくて、確かに誤解を招きやすいタイトルであったなあと。それは自分が「そもそもエンジニアを採用するってどういうことだろう」ということを考えていたので、その話に偏ってしまっていたのかもしれません。
手持ちのメンバーで戦う、という話については「他人の技術に興味や関心を持つということ - Line 1: Error: Invalid Blog('by Esehara' )」に書いたつもりなので、それを参照していただければと思います。