何が卓越した開発者を作るのか
(steady-study.super.site)インフコン 2023で発表した ジュニアフロントエンドエンジニアの成果および能力向上のための実践ガイド の第1部に当たる文章です。以前にGeekNewsにも投稿した
フロントエンドエンジニア キャリアロードマップ: ジュニアのための3つの専門性トラック の精神的な続編とも言えるかもしれません。
卓越したエンジニアとはどんな人か?
Li Paul Luoは2015年の論文 <What Makes a Great Software Engineer?> で、卓越したエンジニアを形作る5つの必須要件を提案した。研究方法は次の通りだった。
- 開発者に必要な教育、能力、行動などに関する数多くの既存研究を分析
- Microsoftでレベル2以上、つまりある程度能力が認められた開発者59人に深層インタビューを実施。開発者が持つべき個人的特性（性格、知識、行動など）の候補54個を導出
- Microsoftの開発者約2,000人を対象にアンケート調査を実施。（特性に対する詳しい説明の後）「もし熟練した開発者がこの特性を持っていないなら、あなたはその人を卓越した開発者だと評価するか？」
- アンケート調査結果の分析および回答者への追跡インタビュー
- アンケート分析および追跡インタビューの結果をもとに、開発者の主な協業相手（アーティスト、コンテンツ企画者、データサイエンティスト、デザイナー、電気工学者など）40人に追加インタビュー
著者が提案した5つの必須要件について、順序と解釈を少し変えつつ、自分の考えを加えて整理してみた。
1. 優れたコードを書く (Be a competent coder)
「有能なコーダー」よりも「優れたコード」のほうが目標にしやすい。
コーディング力はジュニアにとって最も重要な能力だ。しかし一定のレベルを超えると、ほかの能力を伸ばす努力のほうが効率的になる。この「一定のレベル」は人によっても、組織によっても異なる。
私はジュニアのコーディング力を見極める基準を、「1) コード品質について自分なりの一貫した観点を持ち、2) 顧客の要求事項を満たすコードを、3) 速いスピードで、4) 少ないバグで、5) 読みやすく書くこと」だと考えている。
2. 根拠に基づく意思決定を練習する (Practice informed decision-making)
意思決定力を育てるには、意思決定の結果よりもプロセスを改善することに集中するほうが有利だ。結果は自分の意思とは関係なく決まることがあるからだ。
そして根拠に基づくとは、データに基づきつつも、データを偏見で解釈したり、性急に結論を出したりしないことを意味する。特に新しい情報を得たなら、気が進まなくても合理化せず、既存の判断を見直すほうがよい。
特にデバッグのとき、自分ではなくライブラリやブラウザが問題だと思うと、たいていは間違っている。たとえ本当にブラウザの問題だったとしても、それに似たあらゆる問題をブラウザのせいにしてしまうと、実は自分のミスで起きた致命的な問題まで見逃してしまうかもしれないので注意が必要だ。
偏見や性急さを避ける一つの方法は、さまざまな外部の視点をオープンな姿勢で受け入れることだ。少し立ち止まり、友人、同僚、顧客、競合、上司など多様な人がその事案をどう解釈するかを見ると、自分の偏見は維持しにくくなる。
もちろん、人はストレスを受けると理性的に行動しにくい。組織も同じだ。だから賢い組織は意図的にスケジュールやリソースに 余裕 を持たせ、賢い個人は 瞑想 などを通じてストレス管理の方法を身につける。
根拠に基づく意思決定を日頃から練習するには、よい根拠をたくさん持っている必要がある。多様で質の高い情報が自分の周囲を流れていくような仕組みを作っておくとよい。ニュースレターを購読し、コミュニティに所属し、勉強会に参加する、といった形で。
3. 同僚の効果的な意思決定を助ける (Enable others to make decisions efficiently)
卓越した開発者は、情報と経験を共有して同僚を成長させ、チームの生産性を高め、その結果として組織がより良い意思決定をできるよう支援する。
ではジュニアはどうすればよいか。ジュニアは今すぐ成果を出すことよりも、質問を通じて成長することが、同僚を助け、組織を助けることになる。過小評価・拒絶・迷惑をかけることへの恐れ を乗り越え、高コンテキストな質問をしよう。普通は信頼を築いてこそこのような 脆弱性 を見せられると考えがちだが、実際の研究では逆だ。互いに弱みを見せ、勇気を持ってリスクを取るとき、信頼の土台は素早く形成される。
脆弱性にも、うまく見せる方法がある。コンテキストを十分に含めることだ。ジュニアはたいてい、Aという問題があってBを試し、その中でCがうまくいかないとCだけを質問する。こうすると、たいていは非常に枝葉末節な答えしか得られず、その答えを得ても問題解決がうまくいかない。逆にAをきちんと設定すると、Bが自動的に導かれてCが不要になることをよく見てきた。
質問を奨励するには、脆弱性と透明性に大きな価値を置く組織文化を整える必要がある。このとき、組織内のデフォルト値を何にするかがかなり重要だ。デフォルト値は人の認知と行動に非常に大きな影響を与えるからだ。
この点では、隠すためにはアクションが必要な Public by Default のツール（Slack、Notion）は、共有するためにはアクションが必要な Private by Default のツール（Email、Google Docs）よりもよい。「いつでも話しかけてよいが、このときだけは避けてほしい (Do Not Disturb)」のほうが、「この時間なら自由に来て話しかけてよい (Open Hours)」よりもよい。
4. 作業の現在価値を最大化する (Maximize current value of your work)
卓越した開発者には、システム思考（後で問題になりそうな部分や、要求事項がどう変わるかを予測して長期的観点から実装すること）と、まず動くこと（分析で立ち止まらず、不確実性が怖くてもまず飛び込んで実行し、フィードバックを得ること）の両方が求められる。
特にスタートアップでは後者のほうが有利だが、極端に偏ると不利になる。素早い実行に注力しつつ、少しの努力で大きな利益をもたらす行動を習慣にしておくとよい。ミクロな例としては、値が1つしかなくてもハードコードせず変数に切り出しておくことや、値が今は2つしかなくても、それが1つのコンポーネントを超える種類のオプションなら Boolean 値の代わりに Mode を使うことがある。マクロな例としては、自分がどの仮説を検証するために実行しているのかを考え、どのデータで検証するかを考えてから実行する習慣がある。
結局のところ、自分の意思でシステム思考とまず動くことの間を柔軟に行き来できるとき、作業価値は最大化される。
5. 効果的に継続して学習する (Continuously learn)
効果的に学ぶ方法を学ぶことが、あらゆる成長の出発点だ。早く始めるほどよく、複利の利益をもたらす行為でもある。
学習とは結局、自分の知識を広げて人生を変えるためのものだ。しかし古い知識が今も有効だという保証はないので、常に新しい情報で更新する努力が必要だ。
しかし、情報が多ければ無条件によいわけではない。精製されていないビッグデータのように、ある種の情報はあるとかえって邪魔になる。したがって、不正確だったり自分の問題と無関係だったりする「ノイズ」ではなく、「シグナル」の比率を高める必要がある。自分の専門ドメインではない場所で既存知識との接点を作ってくれる洞察、あるいは自分が特定の条件下では間違っていた可能性を示す証拠などが、よいシグナルの例だと考えている。
効果的な学習は、「どうすれば自分は毎日少しずつ、より効果的に成長できるか？」という問いに要約できる。その答えは、1) 今すぐ現実の中で自分に必要なものを見つけ、2) 関連する理論的根拠を必要な分だけ学び、3) 学んだらすぐ使ってセルフフィードバックを受ける、これを繰り返すことだ。
では、今すぐ現実の中で自分に必要なものはどう知ればよいのか。日記を書いて日常で自分が直面する問題を見つけることもできるし、ここ1週間で多くの時間を使った活動をもっと上手くやるために努力してみることもできる。たとえば就職活動中の人なら勉強会をよくするだろうから、勉強会を効果的に進める方法を研究すると役立つ。頻繁に行うことであるほど学習機会も多く、改善したときの生活の質の向上幅も大きい。
どう活用するか - ジュニアとシニアの観点
ジュニアは、これらの目標を一つひとつ、とりわけ「優れたコードを書くこと」と「効果的に継続して学習すること」に描かれた知識や行動に自分がどれほど合致しているかをチェックしてみるとよい。そして不足している能力を集中して伸ばす。
そしてシニアであれば、これらを採用評価と成果評価に使える。応募者がこの能力を十分に持っているかを、どんなシグナルで見極めるかを考えてみる。ジュニアの能力を高めるためにリードするときにも、同じように活用できるだろう。
そしてこれらの能力は、「優れたコードを書くこと」だけを特定ドメインの専門性に置き換えれば、どの職種を評価する場合でもよい基準になる。だから実際に XL8 では、PMでも、デザイナーでも、開発者でも、人を採用し、オンボーディングし、フィードバックするときに、できる限りこれらを基準に能力評価をしており、かなり大きな効果が出ている。
活用時の注意点
この5つの能力はすべて相互補完的だ。すべてが絡み合っているので、1つだけをうまく伸ばすための目標にするのはあまり効果的でないかもしれない。逆に言えば、1つだけが得意でも、ほかのものをよりうまくできるようになるのが楽になることはある。
そしてこの研究は、ほかの研究と同じく絶対的真理ではない。もちろん限界があり、論文著者の解釈と私の解釈を経ていることも考慮する必要がある。
また、論文のタイトルが「何が卓越した開発者を作るのか？」だったため、5つの能力を備えれば卓越した開発者になれる、つまり十分条件だと考えることもあるかもしれない。しかし実際に研究されたのは、「これがなければ卓越した開発者とは言えない」、つまり必要条件だ。したがって、これらをよい目標や志向点、あるいは通過点とするのはよいが、最終目的地とみなす必要はない。
どう活用するか - フロントエンド開発者の観点
この5つの能力をフロントエンド開発の文脈で活用するために、次のような問いを投げかけることができる。
- フロントエンドドメインにおける優れたコードとは何か? どうすればよりよいコードを書けるか?
- フロントエンドドメインでもっとよい意思決定をするには、どのような根拠をどう集めればよいか?
- フロントエンドドメインで同僚の効果的な意思決定を助けるとは、どういう意味か?
- フロントエンドドメインで自分の作業の現在価値をどう測るか? どう最大化するか?
- フロントエンドドメインの知識を継続して、効果的に学習するにはどうすればよいか?
こうした問いにどう答えるかを考える中で生まれたのが フロントエンドエンジニア キャリアロードマップ だ。フロントエンド開発者に組織が期待する役割を、Web/製品/運用に特化したトラックに分け、トラックごとの主な特徴と長所・短所を説明したものだ。(インフコン発表ではこの内容は完全に省かれたが、別の記事でさらに補強して解説する予定です。)
このロードマップもまた、ジュニアとシニアの文脈で活用できる。
たとえばフロントエンドのジュニアは、事前調査または面接質問でその会社の状態を把握したうえで、「自分が行きたいこの組織では、こういう専門性が求められているのだな。この専門性を自分がしっかり伸ばし、うまく示せれば採用される可能性が高くなるな」といった形で求職時に活用できるだろうし、
シニアであれば、「うちの組織にはこういう専門性を持つ人が不足している状態だ。ならばこの人がこの専門性を伸ばせるよう助けよう。そしてこの専門性を持つ人をうまく見極めて採用してみよう」といった形で、メンバーを成長させたり採用したりするときに活用できる。
もちろん、上の論文と同じく3つのトラックが相互補完的であり、絶対的真理でもなく、最終目的地でもないことは念頭に置く必要がある。
卓越したシニア開発者になる
フロントエンドエンジニア キャリアロードマップ では、卓越したシニア開発者になる方法についての私の考えにも簡単に触れた。
- 基本に忠実で、5つの必須能力の育成を継続する人がよいシニアになる。
- ときには同僚の模範的な行動1つが、明示的なリーダーの数多くの言葉よりも大きな影響を与える。リーダー役ではないときにもリーダーシップを示す人には、結局リーダー役が与えられる。
- どんな状況でも、どんな小さな仕事を任されても大きなインパクトを生み出す人が、その後さらに大きな仕事を任される。
1件のコメント
Notionからそのまま移したら、後ろの「フロントエンドエンジニア キャリアロードマップ」リンクがNotionのリンクになっていました。うぅ https://steady-study.super.site/frontend-engineer-career-roadmap これです。