ジュニアエンジニアを雇うべき理由
- 最近のビッグテック企業は主に「即戦力」のスタッフエンジニアを好む
- AIがジュニア開発者を完全に代替するという意見は多い
- しかしジュニア社員が存在する理由は、単なる労働力の提供ではなく、心理的安全な文化とイノベーションを促進することにある
ジュニア人材がチームに与える影響
- ジュニア人材はチームに、教え、コーチし、協力することを強いる
- NonakaとTakeuchiの『The Knowledge-Creating Company』では、日本企業が知識創造に集中することでイノベーションを牽引したと主張している
- イノベーティブな企業は、知識を教え、広め、共有することを優先する
- 知識の発見そのものがイノベーションである
- ジュニアは会社の知識を吸収して再処理し、明示知へと変換する
- ジュニアはチームに冗長性をもたらし、バグ修正や夜間対応などのシンプルなチームの必要を満たす
ゼネラリストは専門家よりも優れたイノベーションをもたらす
- 『Range』という本では、「ゼネラリストがしばしば革新的なアイデアを提示する」と主張している
- 専門家ではなく、自転車をいじっていたライト兄弟が最終的に飛行機を発明したことが典型例である
- NoSQLデータベースは、リレーショナルデータベースの専門家ではなく、分散システムをいじっていた人々から生まれた
- ジュニア社員はソクラテス式の対話を通じて問題を解決しようとする
- 専門家は自我や盲点のために、明白な解決策を見落とすことが多い
- ジュニアは粘り強くぶつかり、ときにはシニアが難しすぎると確信していた問題を解いてしまうこともある
- ジュニアはしばしば失敗する「ばかげた」ことを試すが、ときには専門家が長年抱いてきた前提にどれほど縛られていたかを示す
- 偉大なアイデアの一部はジュニア社員から生まれる
- ジャック・ドーシーはポッドキャスト会社のジュニア社員だったときにTwitterのアイデアを出した
- Post-itは3Mのジュニア社員だったスペンサー・シルバーとアート・フライが発明した
- Firefoxはネットスケープで働いていたブレイク・ロスのサイドプロジェクトだった
- ジュニアはシニアよりも多様な背景を持っており、それがシニアには完全に見落とされる思考様式や視点につながる
ジュニアは心理的安全を意味し、それはより多くのイノベーションを意味する
- 組織研究の文献における心理的安全という用語は、1999年のAmy Edmondsonの論文に由来する
- 中核となる引用: 「チームの心理的安全は学習行動と関連しているが、チーム効力感はそうではない」（効力感 == 認知された能力）
- コーチングが規範である環境をつくると心理的安全が高まる。チームメンバーは進んでミスを認め、エラーを報告する
- 要するに、学習文化は心理的安全を生み、心理的安全は学習を生む。学習とイノベーションは一体である
- グループ凝集性とはやや対照的である
- グループ凝集性とは、長期間一緒に働いてきた同僚同士の密接な関係を意味する
- このような凝集性は、他者の見解に反対し挑戦しようとする意志を弱めることがある（集団思考）
- それは対人関係におけるリスクテイクの不足を意味する
- 長期の同僚で構成された安定したチームは集団思考に陥り、イノベーション能力を失ってしまう
- 彼らはときに外部のアイデアや経験に対する免疫システムを形成する
- 誰か、特にジュニアをオンボーディングすることは面倒に見えるかもしれない。なぜなら同僚たちは教えたり学んだりすることを楽しんでいないからだ
- 私たちは皆、自分の知識サイロの中に住み、自分の仕事を他人に開示することを嫌がる頑固な社員に出会ったことがある
- 彼らは「学習行動」という筋肉を失ってしまう
- 「学習行動」には実験できる能力が含まれる**
- これはより多くのチームに持ってほしいものだ
- これは新しいアプローチを試し、より多くのA/Bテストを実行し、効果がないかもしれないが（ときには効果がある）プロダクトの方向性を進んで試すこととして解釈できる
- 創業者はしばしば「Fail fast」と言うが、創業者やマネージャーもまた自分自身の最大の敵になりうる。すでにすべての答えを持つ専門家だけを求め、新しい答えを見つけようとするジュニアを求めないからだ
ジュニアを雇わないと組織に起こる問題
- 前で述べた多くのテーマがここで重なり始める:
- 学びたいジュニアを採用すること
- 教えたいシニアを採用すること
- 教えられない人には、「やること」すら任せるべきではないのかもしれない
- チームは健全な大学の研究室にとてもよく似ている
- プラトン的理想のシニアはオープンマインドを持ち、挑戦されることを切望する
- 新しい道を見つけるために、自分の専門性を喜んで捨てようとする
- スポンジのように知識を吸収しようという熱意を持って入ってくるジュニアとともに、素朴な質問を通じて新しいアイデアを引き出し、土台を揺さぶる
- これこそが高い成果を出すチームに属していると感じることである
- 個人はアイデアに対して開かれており、手柄を進んで分かち合い、非難を避ける
- 継続的にShippingし、成功と学びを共有し、チームを信頼する
- これはパズルの50%にすぎない（個人的意見）
- 残りの50%には、このチームを守り、内部の混沌を一貫した物語として売り込み、投資家やステークホルダーと協力して雑然とした実験を進歩の輝かしい物語へ変える「外の世界」とのインターフェースが必要である
- 残念ながら、多くの経営幹部はこうしたリーダーシップの外見をシステム全体だと誤解し、それを機能させる教えることと学ぶことの内燃機関を無視している
GN⁺の見解
- ジュニア開発者を雇うことは、単にコードを書く人員を確保する以上の意味を持つ。それは組織文化とイノベーション能力に直結する問題である
- AI技術の進展によってジュニア開発者の役割が脅かされていると考えるかもしれないが、むしろAIと協働しながら新たな価値を生み出す機会として捉えるべきである
- ジュニア開発者を積極的に採用し育成する企業こそが、長期的により大きな競争力を持つことになる。目先の成果に執着するのではなく、組織の持続可能な成長のために投資すべきだ
- ジュニア開発者の採用が難しい状況なら、社内教育プログラムを強化したり、インターンシップ制度を活用したりするなど、さまざまな方法を模索できる
- 何よりも経営陣とリーダーがジュニア人材の価値を正しく認識し、彼らを育成し活用するための長期的なビジョンを示さなければならない
6件のコメント
全体的には同意ですが、ジュニア開発者を採用することが一つの例になる気がします。
非専門家（そのドメインをよく知らない）開発者も似たようなものではないかと思います。
思いもよらなかった視点で、いいですね。
> ジュニアは会社の知識を吸収し、再処理して明示的な知識へと変換する
この部分は特に共感できて、同僚も明示的な知識に変換しようと努力するようになる気がします。
コードレビューだけをとっても、経験のある人は直感的に避けますが、ジュニアは挑戦しようとするので、説得するために知識を整理して共有するようになる気がします。
「汝自身を知れ」 by ソクラテス
結論: 賢くて創造的で、学ぶ意欲があり、全体的に何でもできるジュニアを採用しよう
この記事をタイトルだけ見て、どんな狡猾な経営者たちも人件費のことしか考えないでしょう
Hacker Newsの意見
コードレビューを通じて、開発者はコード品質を維持し、学習できる
John Ousterhout の "A Philosophy of Software Design" の原則に従っている
ジュニア開発者には指導が必要
私たちはジュニア開発者だけを採用する会社
すべてのジェネラリストがジュニアというわけではなく、すべてのジュニアがジェネラリストというわけでもない
多くの会社はジュニア開発者を採用しない
ジュニア開発者の採用を誤ると、コードベースに悪影響を及ぼす可能性がある
ジュニア開発者を採用して育成することは、業界の健全性にとって重要
シニア開発者が去るときに備えて、ジュニア開発者を採用して育成すべき
ジュニア開発者が効果を発揮できないのではないかと恐れることが多い
ジュニア開発者を成功させるための戦略