最近、twitterで10倍エンジニアについて話題になり、何が良いエンジニアなのかについて大きな議論が始まりました。 10倍速エンジニアは会議を嫌う」「10倍速エンジニアは遅刻する」「10倍速エンジニアのラップトップの背景はたいてい黒」など、本当にくだらないことが述べられています。 一般的に、十分に頭が良ければ、ろくでなしでもいいと思っている人がいるようです。
Wixでは、ろくでなしは門外不出とするようにしています。 10倍速エンジニアとは、単に他の人の10倍速く作れる人ではなく、さらに、一緒に働く誰に対してもポジティブな影響を与え、チーム全体を10倍良くすることができる人たちだと信じています。 それは、問題を解決でき、IDE、デバッガー、サービス、フレームワークなど、自由に使えるツールの使い方に精通している、優れたコーダーであることを意味します。 この記事では、私たちウィックスエンジニアリングが考える、まともなエンジニアを10倍のエンジニアにするためのポイントを説明します。 一言で言えば、自分が何をすべきかを常に把握し、誰かの指示を待つような状況に陥ることはほとんどない、ということです。 何でも自分でできるという意味ではなく、自分自身やチームの他の人のブロックを解除する方法を知っていて、技術的負債を最小限に抑えることができるという意味です。 例えば、何らかの問題でブロックされた場合、仲間から支援を受けるにせよ、自力で解決するにせよ、解決策を見つけることができます。 独立系エンジニアは、アイデアから生産まで、プロジェクトの全フェーズを担当する能力を持っています。 7094>
プランニング
経験の浅いエンジニアが最も苦労しているのは、大きな仕事を小さなステップに分解することでしょう。 これは、何かにどれくらい時間がかかるか見積もることができるようになるためだけでなく、高品質のソフトウェアを構築するための重要な部分でもあります。 正しい計画を立てることで、開発者はできるだけ早く製品の初期バージョンをリリースし、より早くフィードバックを得ることができるようになります。 正しいプランニングとは、システムの設計を早期に行い、海に飛び込む前に何をするのかの良いイメージを持つことです。 正しく計画を立てるということは、開発中に設計が壊れるような大きなサプライズがないということです。 優れたエンジニアは、タスクを分解し、設計とリリースのフェーズを定義し、その計画を示す設計文書と見積もりを提供できるはずです。
Humility
これは難しいことです。 どんなに強いエンジニアでも、謙虚さに関しては成長する場所が何度もあります。 それは、自分自身の解決策に惚れ込まないということです。 他の人の解決策に耳を傾け、受け入れることができること。 仲間のことを一番に考え、間違いと思われることを見つけたら、その理由を理解しようとすること。 物事をオープンにし、議論すること。 人々に自分なりの解決策を提案させること。 自分のアイデアを共有し、自分の手柄にしようと気にしないこと。 あなたのアイデアであることを皆が知ることよりも、皆がそのアイデアに納得し、チームの努力の賜物であると感じることの方が重要です。 正直であれ。 自分の手柄にしましょう。 自分が間違っていたと言うことや、誰かが正しいと認めることを決して恐れてはいけません。 7094>
Reuse
些細なことに聞こえるかもしれませんが、ほとんどの人は、進歩するための最善の方法は、以前の仕事の上に構築することであることを理解していません。 経験の浅いエンジニアは常に、早く進むための最善の方法は、すでに存在するものをすべて無視して、もう一度やり直すことだと考える悪い癖があります。 優秀なエンジニアは、常に既存のソリューションを徹底的に調べ、学び、尋ね、理解します。 たとえ既存のソリューションに不足があったとしても、それを置き換えることを決める前に、どうすれば改善できるかを検討しようとする。 7094>
インフラストラクチャー マインドセット
上述したように、以前の仕事を再利用することは、人々に大きな影響を与えることがあります。 つまり、エンジニアは常に再利用可能なものを作る機会がないかどうか、目を光らせていなければならないのです。 そのような機会があっても、最も簡単なのはそれを無視することです。 再利用可能なものを作ることは、再利用不可能なものを作るよりも常に「作り手」の負担が大きくなるため、多くの近視眼的な人々は、自分や他のチームが将来的に享受できる利益を無視してしまうのです。 優れた開発者は、再利用可能なものを作成する機会を特定し、それらを最善の方法で再利用可能にする方法を知り、そのための努力を惜しみません。
ドメインをマスターする
優れたソリューションを考え出す唯一の方法は、取り組んでいる製品を徹底的に理解することです。 優れたエンジニアは、開発する製品を深く理解しているだけではありません。 彼らはまた、すべてのユースケースを理解し、製品の動機を理解し、製品マネージャと容易に有意義な会話をし、決定に異議を唱え、代替案を提供することができます。 何が重要な機能で何が重要でないかを把握し、それに応じた優先順位の付け方を知っていて、必要に応じて回避策を提案することができるのです。
好奇心
優れた開発者は、自分の領域の境界をはるかに超える健全な好奇心を持っていなければなりません。 これは、基礎となる技術が実際にどのように動作するかを学ぶことに特に当てはまりますが、他のチームが取り組んでいる製品、そのアーキテクチャ、およびそれらが完全なシステムとしてどのように接続するかを理解することも同様に重要です。
No boundaries
悪いソリューションや悪いアーキテクチャの原因は、人々が自分の枠の外側にあるものを変えることを恐れていることに根ざしていることをよく見かけます。 クライアント開発者は、たとえサーバーで解決した方が良い場合でも、クライアントで物事を解決しようとする傾向があります。 アプリケーション開発者は、解決策がプラットフォームやインフラにあるにもかかわらず、ローカルで問題を解決しようとする傾向があります。 その理由は簡単です。 自分の手の届かない世界をブラックボックスとして扱い、自分の知っている悪魔を相手にする方が簡単だからです。 しかし、優れたエンジニアは、自分たちが一つの大きなシステムの一部であり、そのシステムのどの部分も本当は自分の手の届かないところにあるのだということを知らなければならない。 アーキテクチャの変更について別のチームと議論することは、健全かつ有益であり、あなたの視点を増やすことになるかもしれません。 あなたが必要とする変更に貢献することを申し出ることは、チーム間の信頼を築くのに最適である。 新しいドメインに触れることは、自分にとって有益な経験である。 最も重要なことは、自分の境界線がより柔軟になることは、自分の影響力が大きくなることを意味することです。
責任/所有権
すぐにはわからないが、あるプロジェクトが遅れたり失敗したりした根本原因を探ってみると、所有権と責任に行き着くことが非常に多いのである。 人は常に周囲のせいにしがちです。 「他のチームが完成するのを待つ必要があった」「システムの問題が発生したが、誰も助けてくれなかった」「定義が遅すぎた」など。 優秀なエンジニアは、それらがほとんど言い訳であることを知っています。 あなたがタスクのオーナーであり、それを実現する責任があなたにあるとき、あなたの考え方は、遭遇するすべての問題は、あなたが解決しなければならないものであるというものでなければなりません。 もし、他のチームから邪魔をされたら、そのチームと話をしましょう。 他の人に責任を「丸投げ」するのではなく、その問題についてペアを組むことを申し出てください。 もし、まだ定義が得られていないのであれば、定義がどうなるのか、ある程度想定しておきましょう。 ただ座って待つより、ある程度進めてから調整する方が良い。 何か大きな問題があって遅れている場合、いつ旗を揚げるべきか、また、その問題を回避する方法を知っておくことで、少なくとも別の面で前進することができるようになります。 自分の問題を解決するために他の誰かが責任を負うような状況には決して陥らないでください。 コミュニケーションができるということは、人類が今のような存在になることを可能にした唯一最大のものであり、明らかに、ソフトウェア エンジニアリングを含む人生のあらゆる側面において、同じように重要なことなのです。 優れたエンジニアは、自分の考えや意見を雄弁に語ることができなければなりません。 また、同僚と知的で尊敬に満ちた議論をすることができなければなりません。 コミュニケーションは話すことだけでなく、聞くことも重要です。 チームの全員が自分の考えを同じように表現できるわけではありません。優れたエンジニアは忍耐強く、適切な質問をして他の人が何を考えているかを理解し、彼らの意見を聞き入れる手助けをしなければなりません。 さらに重要なのは、会話だけではありません。開発者の生活は、文書、プレゼンテーション、ドキュメント、コードコメント、コミットメッセージなど、さまざまな形式のコミュニケーションで満たされています。 文書、プレゼンテーション、ドキュメント、コード コメント、コミット メッセージなどです。
チームワーク
これは、経験豊富なエンジニアでさえ頻繁に失敗し、それが起こっていることにさえ気づいていない場所の 1 つです。 複雑すぎる、私に任せてくれ」と言ったすべての時間を考えてみてください。 この仕事は一人でやるものだ、人を増やしても簡単にはいかない」と言ったことを思い返してください。 誰かを助ける時間がなくてフォローアップしなかったこと、誰かのコードをレビューも求めずに修正／リファクタリングしたこと、チームに相談せずに大きな変更を行ったことを思い返してみてください。 例は山ほどあります。 そして、経験豊富なエンジニアにとってさえ、その瞬間は正しいことのように思えるということです。 しかし、これは戦術的な思考であり、短期的にしか利益を得ることができません。 もし私たちが偉大なことを成し遂げたいのであれば、チームとして協力できることを確認する必要があります。 チームワークがコミュニケーションの直後にあるのは、偶然ではありません。 これは生物学の基本です。 優れたエンジニアは、仲間と協力し、相談し、学び、助け合い、ペアを組み、尊敬するだけでなく、指導し、問題を指摘し、チーム内で起きていることすべてに興味を持ち、そこから学び、自分に直接関係のないことでも積極的に役に立とうとします。 7094>
Keep it simple
ソリューションの複雑さは、チームが前進し適応するためのサイレントキラーの1つになり得ます。 それは高血圧のようなものです。 素人目には、すべてがうまくいっており、すべてが期待どおりに動いているように見えますが、実は、心の奥底では、主要な機能に直接影響しないものが、ゆっくりとあなたを殺しているのです。 優れたエンジニアは、たとえコード行数が増えたとしても、実用的な解決策と読みやすいコードを作成します。 すべての言語機能を使ったり、冗長な抽象化レベルを作ったり、誰も理解できない、デバッグできない関数を1行で書いたりして、自分がいかに「賢い」かを示すのはやめましょう。 また、すでに複雑なものを取り上げて単純化することを決して恐れてはいけません。
優先順位付け
私たちはすべてを行うことはできません。 すべての問題を解決することはできません。 すべての議論に勝つことはできない。 私たちはすべてを完璧にすることはできません。 私たちには限られた時間と限られた資源があり、それらを賢く使わなければなりません。 つまり、どうしてもやらなければならないこと、先延ばしにしてもいいこと、無視してもいいことを見分ける能力が必要なのです。 開発者は、毎日何十回となくこのような判断をしています。 バグを調査するかどうか考えるとき、リファクタリングを行うかどうか考えるとき、ユースケースやエッジケースの処理を考えるとき、計画したタスクから回り道をすることを考えるとき、さらには自分の意見で誰かを説得するために時間を費やすときなどです。 優秀なエンジニアは、本当に重要なことについては、修正、調査、研究、主張などに執拗に取り組むことを知っています。 また、重要なことでも緊急でない場合は、メモを取り、後で出直すことも知っています。
タイムマネジメント
前述したように、私たちの存在の悲しい真実は、私たちが時間に縛られていることである。 私たちが開発する製品は最終的に稼動させる必要があり、私たちには達成すべき締切や見積もり、目標があります。 優れた開発者は、自分のタスクにかかる時間を予測する直感を養うだけでなく、タスクをさらに小さなパーツに分解して順序付ける方法について、巧みになる必要があります。 また、割り込みやコンテキストの切り替えを賢く管理する必要があります。 このような時間の見積もりに関する直感は、前述の優先順位の付け方と不可分な関係にあります。 例えば、「短い時間なら、それほど重要でなくてもやる価値がある。
結論
前述したように、上記のすべてに精通したエンジニアは、仲間に影響を与え、鼓舞することにより、チームを 10 倍良くすることができると信じています。 優れたエンジニアは、影響と刺激を与えること、これが日々の仕事の一部であることを常に忘れてはなりません。 つまり、自分の仕事をするだけでなく、他の人の仕事を手伝う時間も見つけなければならないのです。 これは様々な形で行われます。チームのメンバーを指導する、メンバーを教育するためのリソースを作成する、すべてがきちんと文書化されていることを確認する、常にオープンに説明し人と組むなど、その他にもたくさんあります。 良い指導者、教育者になるということは、チームメンバーの成長を助けるだけでなく、自分が行うすべてのことに対する理解を深め、物事の明確さ、システムの複雑さ、改善できる点などについて新しい視点を与えてくれます。
これらは、個人の影響だけでなく、他の全員に影響を与えるという点でも、10xエンジニアの素質があると言えます。 自分の影響力をより大きくするために何ができるかを常に自問し、成長の余地は常にあるのです」
。