優れたエンジニアになる方法と、その知識を伝達する方法
世界で最も見られているWebページの1つ、Yahoo!のホームページを担当しているのが、同社のプリンシパル・フロントエンド・エンジニアのNicholas C. Zakas氏。Zakas氏のブログ「NCZOnline」、8月21日付けのエントリは「What makes a great software engineer?」でした。
Zakas氏が考える優れたエンジニアとはどういう人なのでしょう? 彼のアドバイスはWebに関わるエンジニアに限らず、あらゆるエンジニアに共通するもののように思えます。
What makes a great software engineer?
長文のエントリの中から、ポイントとなりそうな部分を抜粋して紹介します。
Always do it the right way
There's an "emergency" project, or something that seems so different that it must have its own set of rules. That's bogus. Good engineers know that the right way applies to all situations and circumstances.
どんなときでも正しい方法をやり抜く
"緊急"のプロジェクトといったものがあるとして、それは緊急ゆえになにか特別なルールで動いているように思える。しかしそんなルールはインチキだ。よいエンジニアとは、どんな状況や環境でも、正しいやり方が適応できることを知っている。
Be willing to suffer
Great engineers first and foremost want to solve the problem on their own. Problem solving is a skill, a skill that great engineers take seriously.
課題を求めている
優秀なエンジニアは、自分自身で率先して問題を解決しようとする。問題を解決することはスキルであり、優秀なエンジニアはスキルについていつも真剣だ。
Never stop learning
Read blogs. Attend conferences. Go to developer meetups. Great engineers never stop learning.
学び続ける
ブログを読み、カンファレンスに参加し、勉強会に出席する。優れたエンジニアは学び続けている。
Share your knowledge
Great engineers want others to know what they know. They aren't afraid of losing their position because someone else can do the same thing. Great engineers want to see their peers succeed and grow.
知識を共有する
優れたエンジニアたちは、お互いの知識を知りたがっている。彼らは、自分の地位を失うことを恐れていない。同じ能力を持つ誰かがいることを知っているからだ。優れたエンジニアたちは、自分の仲間の成功や成長を望んでいる。
Lend a helping hand
Great engineers are team-focused and therefore are willing to do whatever it takes to help the team. Whether that be writing 1,000 lines of code or editing an image, great engineers jump at the chance to help out.
手助けをする
優れたエンジニアはチームを第一に考えており、チームを助けるためならなんでもしようと思っている。それが1000行のコードを書くことでも、画像の編集であっても助けが必要なときにはそこへ飛び込んでいく。
Take your time
Great engineers aren't born, they are made. They're made by following the advice in this post and by hard work.
焦らなくていい
優れたエンジニアとは生まれながらのものではなく、ここにあるようなアドバイスとハードワークによって、後天的に作られるものだ。
知識を伝達するための優れた方法とは
ちょうどほぼ同じタイミングで、InfoQには「Agileプロジェクトでどうやって知識を伝達する方法」という記事が掲載されていました(ちょっとタイトルが直訳っぽいですね...)。
この記事では、「知識の伝達や共有方法として、健全なコミニュケーションや指導が有効だ」ということが実験によって確かめられたと紹介されています。
記事によると、ブログ「Agile Focus」のブロガー Steve Bockman氏が、知識を伝える最適な方法を探り出すために次のような実験をしました。それは、風変わりな紙飛行機についての知識を3つの方法で伝達することでした。
- 文書化 ― 被験者に紙飛行機を作るための説明書(作り方が22ステップで記述されている)
- リバースエンジニアリング ― 被験者に完成した紙飛行機を与え、被験者はこの紙飛行機を研究した
- メンター制度 ― "チーフデザイナ"が順に紙飛行機を作るのに従って、被験者もいっしょに複製した
結果、文書化で紙飛行機を完成させた被験者は12.5%、リバースエンジニアリングでは25%、しかしメンターでは100%の被験者が紙飛行機を完成させたそうです。つまり、一緒にやってみせる、ということが大事なようです。
記事では、
知識の共有方法として最適なのはコミニュケーションやメンター制度などで一緒に作業をすることだという考えは、一般的になっている。文書も少しあれば役に立つかもしれないが、文書だけに頼った知識の伝達が生むのは限られた利益だけだ。
と結論を示すと同時に、ペアプログラミングによる知識の伝達の有効性についても伝えています。
優れたエンジニアと優れた情報伝達の手法がうまく組み合わされれば、チーム全体でよい仕事がしやすくなりそうですね。