日米でエンジニアの育成戦略が正反対だと気付いた話

今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしているバンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。

採用の段階での違い

　良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。

　一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキルがある」ことは期待されないので、新入社員教育とかがあって０から教育ぐらいの勢いのカリキュラムが組まれます。どちらも体感した正直な実感としては、アメリカ式の方が圧倒的に良い気がします。というのも、「基礎がちゃんとできている」ことを企業がそもそも期待するので、きっと学生の方や中途採用の方もちゃんと勉強したり、プログラミングを練習してくるのだと思います。インタビューもコーディングインタビューとかします。

　これは「文系の人はプログラミングになるべきではない」ということが言いたいのではありません、「それ相当の知識が要求される」ことによって、採用の段階で、学んで応募者がその水準にもってくることが重要だと思います。それによって、エンジニアのレベルの平均値が相当違う感じを受けます。逆に世界の潮流では、日本式の「コンピュータサイエンス学位」のリミットを外す流れもでていると聞きますので、門戸は広い方が私も良いと思います。かつ「コンピュータサイエンス」を出てる程度の実力を求めるというのが一番いいのかなぁとか個人的には思います。

入社後の違い

　先ほど書きましたが、日本の場合は一括教育で全部教えてもらえます。新人は「知らないもの」として扱われるので簡単な仕事しかさせてもらえません。アメリカで働いていると、新人でもキャリアのある人と同じように扱われます。もちろん Junior であるので、マネージャが手厚く助けてくれたりとかはありますが、基本的には他の人と同じです。何か自分に足りない知識があったら自分で調べて身に着けます。日本の場合は、会社で使うツールなどに関しては結構手厚い手引きや参考文献とかが用意されています。

　アメリカだと、自分が知りたい知識があったら自分からその分野をよく知っている人にコンタクトをとってミーティングを設定したり、コードやドキュメントを読んだりして理解を深めます。　これは前のセクションで書いた通り、採用時点で「スキルがあること想定」か「スキルが無いこと想定」の違いなのかなぁとも思います。

設計・アーキテクチャ

　私は大手SIにいたしそれは昔の事なので今でも、すべてのチームがこうであるとは思いませんが、自分が実体験したことを書いておくと、日本の時はアーキテクチャを考えるのは一部の標準化グループとかアーキテクトと呼ばれる技術的に優れた人もしくはグループでそれ以外の人はその標準化グループが作ったフレームワークの上で、仕様書通りにコードを書きます。そうでなくても、それ以外の人はアーキテクトと呼ばれる人が作ったアーキテクチャの上で比較的簡単なコードを書くことが多いです。

　一方自分がアメリカで体験していることはゴリゴリに違います。たとえ New Grads（新卒）であっても、アーキテクチャをその人がリードします。リードすると書いているのは、他の人の「脳」を借りてその人が主体的になってアーキテクチャを考え、設計します。日本ではアーキテクチャを考えて実装する経験はアーキテクトで、それ以外の人はあまり経験が積めませんでした。ただし、現在もそうなのかは私はわかりません。今だとそうではない企業もありそうです。

　私の例でもそうですが、私は今のチームに入るまでもちろんクラウドの中身の設計とかやったことがありません。そんな人でも自分がアーキテクチャとか設計のリードになります。しかし、経験や知識が足りないので普通だとうまくいかなそうですが、実際どうなるか？というと、その人が「リード」して、必要な経験のある人やマイクロサービスのコンポーネントの知識がある人にお願いして、一緒にアーキテクチャを考えてもらったり、考えた設計をレビューしてもらったりします。だから、全員が、アーキテクチャや設計の経験をします。

標準化の考え方

　日本にいるときは標準化で細かくルールが決まっていて、それに従わないといけない感じでしたが、こちらは人にまかされています。そもそも、コンピュータサイエンスを学んでいる前提なのでそんな変なことになりません。おかしな設計や人が読みにくいコードを書いていたらレビューで指摘されます。標準化という考えというより、何か全員がやらないといけないことがあれば、たいていそれは自動化されて、自動で適用されます。

オンコール

SIerの場合は、オンコール（障害担当する週間）はありませんでした。開発したら保守する会社さんが引き継ぐので。もちろん日本でも内製の会社だと違うと思いますが、私の職場では開発者でも、障害担当をする習慣があります。インシデントが来るのが嫌だし、自分のコードのせいで障害が起こると面倒なので、保守しやすいコードを書こうという考えになりますし、障害が起きたらいろいろ考えて設計も工夫するようになります。

エンジニアの成長の度合い

　上記で紹介したような違いを整理すると上記のテーブルになるでしょう。日本時代のものと比較してもそうですが、実感の上でもこちらの開発環境の方が全然早く「エンジニアが育っている」という感じを受けます。日本にいるときは、ものすごく基本的な部分もあやしい人や、経験を積んでいる人でも独自流でソフトウェア設計の考え方からするととんでもないような設計（クラス連番、オブジェクト指向/関数型禁止、async/await 使わない、ものすごく大きなロジックにまみれた重複だらけのクラス、全部スタティック…）をしている暗黒なものも山のようにみましたが、こちらで見たことがありません。あってもレビューが通らないでしょう。

　日本のエンジニアの育成（特に私がSIで経験場合）は、優れた少数な人と、それ以外というモデルで育成が設計されており、「だれでもできるように」思想でフレームワークも作られてるし、アーキテクチャや設計などスキルが必要な場面は特定の人しか経験できませんでした。こちらだと、それが誰でも最初から経験できるのが物凄く貢献しているのか、そんなに経験無いエンジニアでもガンガンに難しいことにチャレンジして実装して、保守します。もっと言うならインターンでも結構主要な機能の開発とか任されることもあります。

　日本型の、「優秀な人だけが担当」モデルだと、設計でこけないのかもしれませんが、それ以外のエンジニアが育つことはありませんし、高度なことをするチャンスももらえませんし、なにより楽しくないと思います。他の課題としては、チャレンジングなことが出来なくなります。誰でも書けるフレームワークを目指すということは単純なことしかできなくなるので、重複も多くなり、開発スピードや品質に多くの影を落とします。

　だから、私がアメリカに来てからは、日本時代には体験できなかったような難しいこと、複雑なことにチャレンジする必要があり、正直楽しくて仕方ありません。アーキテクチャも設計も自分で決めます。だから、指示待ちなんて人は存在しません。新人をフォローする時も、めっちゃ基礎的なことはみんな勉強してくるから、そんなことを教える必要もないのでめっちゃ楽です。（そして感謝してもらえる）

まとめ

　自分的な意見としては日本も、こっち型にシフトしたほうが、会社にとってもエンジニアの成長して生産性やクオリティが上がるし、エンジニアも成長できてうれしいし、難しいことにチャレンジできて楽しいと思います。たぶんそういう会社も今は日本でもあると思うのですがそういう会社さんが増えるとよいなぁと思いながら書きました。

最近『世界一流エンジニアの思考法』という書籍を執筆しました。よかったら読んでみてね！

ついに書影公開で10/23日発売予定です。私がマイクロソフトに来てからの気づきと学んだことを全部ぶち込んだ感じですわ。ちなみにKindle とかたぶん Audible も来るらしい。良かったら読んでな！https://t.co/QLX5oJtkJQ
— 牛尾剛『世界一流エンジニアの思考法』(文藝春秋)🎸Tsuyoshi Ushio (@sandayuu) September 28, 2023