賢く責任を全うできるチームを作るため、担当分野を変えてマルチエンジニアを育てる

良いエンジニアとは？

　エンジニアチームをマネジメントするに当たり、まず「良いエンジニアとはどんな人物か」について考えてみました。そして、良いエンジニアとは「賢さ」と「責任」を備えている人物だと考え至りました。

　「賢さ」が意味するのは、無駄がなく、シンプルで、最速かつきちんと目的を達成する力です。例えば、あるプロダクトの担当者から「ユーザーにアンケートを取りたいんだ」という依頼が来たとしましょう。それをあるエンジニアが「任せて！」と言い、3日でアンケートシステムを構築しました。「たった3日ですごい！」と感動した担当者は、しばらくすると「アンケート結果をグラフ化したい」と依頼してきました。その仕組みも迅速に実装してあげると、今度は「アンケートデータをCSV形式で出力したい」。そのエンジニアには、次々と舞い込む依頼に応え続けました。

　一見するとスキルが高く優秀なエンジニアのようですが、果たしてそうでしょうか。「それ、Googleフォームで出来るよ」の一言で解決する場合もあるからです。エンジニアの仕事は、課題を解決すること。技術や作ることはあくまで手段であり、手段を目的化してはいけません。無限数に存在する手段の中から、最適な一筋を見つけ出すことこそがエンジニアリングなのです。

　また、非エンジニアの方は、システムを「一度作ってしまえば24時間365日動き続けてくれる便利なもの」と思いがちですが、むしろ生き物に近いでしょう。子犬を飼い始めたら、飼い主は「責任」を持って育てなければなりませんが、システムにもそれがあてはまると思うのです。

　エンジニア自身も、生み出し続けることの責任を深く理解できていないことが大いにあると思います。上述のように動くものを作っていると、「何となく仕事をした感じ」になるからです。しかし、子犬を飼い始めたつもりでも、いつしか大きく成長し、雨が降っても、自分が風邪を引いても、毎日散歩に連れていき、餌をあげ続けなければいけない。そこまでちゃんと理解して「子犬を飼う」決断が必要です。無責任なシステムを作ることは、子供が「このワンちゃん飼いたい！」と言うのと同じだと思いましょう。

　ただ、ここで言っているエンジニアにおける「責任」とは決心の話ではありません。「影響範囲を把握する能力を身に付けること」です。どのようなクラスを作ればよいか、アーキテクチャは何がいいのか、どんなライブラリを使うのか、もしくはここはひとまずコピペで済ませるか。今作っているものが後でどのような影響を及ぼすかを想像できるようになれば、こうした判断が適切に下せるようになります。エンジニアにとって責任とは、スキルを上げることと直結するのです。