メンバーのプログラミング力を測り、伸ばす
晴れて採用が進み、メンバーになっていただけたら、次にやることは現時点のプログラミング力を定期的に測り、伸ばしていくことです。
プログラミング力の測り方
メンバーのプログラミング力を測る決まったやり方はなく、他人のプログラミング力を測ることは非常に難しいので、私も四苦八苦しながら実力を測っています。私のやり方を強いて言うならば、常に2つの事柄を中心に見ています。一つは理解力と設計力に関連するもので、解こうとしている問題（設計・実装）とそれを解くために採用している解法の両方がうまく説明できるかです。もう一つはアウトプットのスピードです。
問題の理解をまず聞くのは、問題を理解しないままに解き始める人が非常に多いからです。まず手を動かさないと不安になってしまうのですね。問題を理解するために手を動かしているのであればいいのですが、浅い理解のまま解き始める人が多いのです。そして、アウトプットの最後の方で、自分が作るべき仕様が思っていた仕様と違ったり、自分のやり方では実現できないことが分かったりします。問題をよく理解していれば、簡単な方式で求める仕様が満たせたり、美しい解法・設計を取ることができたりする可能性が高まります。プログラミング力が高い人は、何かを作る前に達成すべきものは何かを理解しようと努めるものです。
そして、次に聞くのは、どのように解こうとしているか、です。もしあなたのプログラミング力が十分に高く、かつ問題をきちんと理解すれば、どのように解けば良いかがあなた自身にはある程度見えていると思います。そこで、メンバーがやろうとしている方法と、自分ならこうするだろう方法との比較を行います。ここで、自分のやり方が正しいわけではないことに注意しなければなりません。メンバーの方が問題を考えている時間が長いため、問題についてよく理解している確率が高いからです。そのため、自分がその問題をちゃんと考えたのでなければ、メンバーの方が正しいこともあります。あくまで、自分のやり方の差異を理解し、違う場合はなぜその方法でやろうと思ったのかを聞くようにします。
問題には本質的な難しさのレベルがあり、解法もその難しさによって異なります。メンバーが取ろうとしている方法が、自分が思うよりも難しいやり方であれば、自分の問題に対する理解がおかしいか、メンバーが良い解法を思いついていないかのどちらかでしょう。もしより簡単な方法でやろうとしているならば、何か思い込みや想定の抜けがないかを確認します。このようにして、問題を正しく理解しているかと、その解法が正しいかを尋ねます。もし、自分の思いついたやり方よりも良い方法をとっているならば、それはメンバーのプログラミング力が高い証拠でしょうから、メンバーを褒めてあげてください。
もう一つ見ているのは、主にアウトプットまでのスピードです。アウトプットは、設計だったりコードだったりとさまざまですが、人に一旦見せられる程度までできたものを指します。やはり能力が高い人ほど、アウトプットのスピードが速いです。 そして、速いほど質も高いこと多いです。こちらの比較はわりと簡単で、問題の難しさから想定されるアウトプットスピードを比べればいいので、わりと測りやすいでしょう。ただし最初に述べた様に、難しさを推定することは簡単ではないので、問題の理解をメンバーに問い、その結果今やろうとしていることの難しさを理解しようとしてください。
プログラミング力の伸ばし方
メンバーのレベルが低いうちは、日常業務を行っているだけでも多少プログラミング能力を伸ばすことができます。何事も慣れていくものです。が、最終的にはそうもいきません。
連載の第1回で、プログラミング力は知識と応用力からなると述べました。知識の部分は自学自習もしやすいですが、応用力は実際に経験したことがものをいいます。そこで、本人が普段やっている業務より少し難しかったり分野が隣接したりする業務を、サポート付きで与えてみる必要があります。
具体的には、普段バックエンドで実装業務ばかりやっているメンバーにはシステム設計の仕事を任せてみたり、フロントエンドばかりやっているメンバーにはAPIの定義から考えてもらったり、設計もできるメンバーにはより難しい社内の改革に結びつくようなシステムの提案を……などと、本人の活躍の幅が広がる業務にあえて挑戦してもらいます。もちろんキャパオーバーでうまくいかない可能性もありますから、最終的に尻拭いを自分でするという覚悟の上で、当人の力量ギリギリと思われる、頑張ればなんとかできそうという仕事にトライしてもらう必要があるのです。
このようなことをせず、エース級の社員に難しい仕事を任せれば、そうでないメンバーがやるよりその仕事は確実に早く終わります。しかし、それでは下のメンバーが育っていきませんし、エース級社員が抜けたときにできる人がいないようでは困ります。エース級社員のサポートが望める間に、他のメンバーを育てる方が圧倒的に効率が良いでしょう。
特に、システムの機能設計は、システムは何度も作るわけではないために仕事としての総数は多くないかもしれません。しかし、一度通してやってみなければいつまでもできるようにはなりませんし、通してやったことがあるという実績も解除できません。一度こなしたことがあるという実績はかなり意味があるもので、それだけで次の仕事を任せやすくなります。多少仕事が遅くなり、質が落ちたとしても、今後設計ができる人を増やすためにはやらせる価値があるものと思います。
ここで重要なのは、サポートを必ずつけることです。サポートなしでは独りよがりの設計になり、うまくいきません。設計レビューを何度もはさみ、より良い方法を適宜ディスカッションするようにします。メンバーがやったことは（できなくて当然なのですから）なるべく否定せず、要件に合致するか確認し、最適な方法はないかを常に一緒に探るようにしましょう。ペアプログラミングのように、ペアシステムデザインのような形に持っていければ最高でしょう。
最後に
この連載では、プログラミング力とはなにか、どのようにしてプログラミング力をつけるか、どのようにして他人のプログラミング力を見極めるかについてお話ししました。各論を話し始めるともっとたくさん書けることもあるのですが、広い視点を捉えるようにしたつもりです。
みなさまがプログラミング力をつけ、より良いソフトウェアエンジニアライフを送っていただける、そしてその結果として日本のソフトウェアエンジニアリングの実力が向上することを願ってやみません。
なお、私は半分趣味で他人のモックコーディング面接をやっております。興味のある方は@mayahjpまでDMください。
