2020年5月、日本では1回目の緊急事態宣言が発出されたコロナ禍の最中に1人のエンジニアの転職に注目が集まりました。今回、お話を伺ったのは、その人物、現在Launchable, Inc. Principal Engineerとしてエンジニアとしての新たなキャリアをスタートした庄司嘉織（yoshiori）氏。

25歳でプログラマとしてエンジニアのキャリアをスタートし、その後、日本有数のIT/Web企業で、プログラマ、マネジャー、さらには人事責任者と多用なポジションを経験し、今に至ります。

エンジニアに大切な資質、そして、チームとしてエンジニアが活躍するために必要な条件とは何か？――今回、yoshiori氏の20年のキャリアに深く迫り、その答えを探します。

「俺なんかじゃダメ」という卑屈な考えはなくすこと

――yoshioriさんは、各企業でのリーダーシップやコミュニティでの積極的な活動など、エンジニアとしても非常に多彩な経歴をお持ちです。改めて、ご自身のエンジニアのキャリアについて教えてもらえますか。

庄司氏（以下、「yoshiori」）：自分で言うのも何ですが、いろいろと経験していますね（笑）。そのスタートは25歳のとき、プログラミングを学ぼう、プログラミングに関わる仕事をしようと転職したのがきっかけです。今から20年前、いわゆるガラケー全盛の時代に、組み込みエンジニアとしてiアプリやそれが動く VM のエミュレータ開発をしたのが最初のエンジニアキャリアです。

その後、WebのSI、そして、今でいうデータマイニングを扱うブレインパッドに転職し、その後の2社が特に長いキャリアとなりました。1つは株式会社ドワンゴ、もう1つが（直前の）前職のクックパッド株式会社です。クックパッドには7年いました。この間、プログラマとしてスタートし、さらに新規事業開発責任者やエンジニアマネジャー、事業部長、さらには人事部長も経験しています。

そして、2020年、現職、Launchable, Inc.にPrincipal Engineer、つまり一エンジニアとしてjoinしました。

コミュニティを通じて自分も当事者であることを実感

――25歳からというと丸20年でしょうか。駆け足で聞いただけでも多岐にわたるのがわかります。その中で、まず、エンジニア個人として大事にしていること、自分にとってのエンジニアの資質というようなものがあれば教えてください。

yoshiori：エンジニア全員に当てはまるということではないかもしれませんが、自分にとって意識しているエピソードがあります。自分にとって、エンジニアの生き方の根幹とも言えるかもしれません。

それは、Seasar2の開発に関わっていた比嘉康雄（higayasuo）さんとお会いしたときに言われた一言です。Seasar2をはじめ、当時、Javaをメインにしていたプログラマは、（言語特性としても）金融など堅い業務に関わる人が多く、当時活発だったPerlコミュニティ（Shibuya.pm）など他の言語のコミュニティと比較して、Javaはまじめで、有り体に言えば、スーツの人たちの集まりという印象がありました。

自分としては、それだけじゃないという思いもあり、純粋にプログラミングを楽しむ集まりを作れないかと思った一方で、自分のようなプログラミングを始めたばかりの無名な人間がコミュニティを作ってもダメなんじゃないかと考え、比嘉さんに相談したのです。

そのとき言われたのが「俺なんかじゃダメっていうのは良くないし、何より、思いを持っている人間が作るべき」という一言でした。正直、脳天を撃ち抜かれたような衝撃でした。比嘉さんは当時、すでに開発実績もありエンジニア界隈で著名でしたが、自分のような無名の人間にも、いや、無名の人間だからこそ行動する価値があると言ってくれました。

自分から声を上げ、募集したところ、たくさんのエンジニアが集まってくれました。また、自分からjava-jaの賛同者として参加したことで、新しいつながりができ、今に至ります。ですから、コンピュータサイエンスの知識やプログラミングスキルも大事ですが、まず、自分で動くこと、当事者であることは、エンジニアの生き方として非常に重要だと考えています。

学校で経験した勉強とエンジニアの勉強は別物と考える

――java-jaでの活動をはじめ、その後のyosihoriさんのプログラミングに関するアウトプット、また、イベントの登壇など、非常にインパクトの大きいものばかりでした。ところで、そのときJavaを選んだのには何か理由があるのですか？

yoshiori：まず、あらかじめ言っておくと、自分自身はJavaじゃなきゃダメというつもりはまったくなくて、今では、RubyやPerl、Pythonなども使っています。

キャリアの最初は組み込み系だったのでいわゆる UNIX C でした。その後、iアプリ周りの担当になったときに Java を初めて触って感動しました。「配列が自分自身の長さを知っている！！」「文字列というのものが存在する！」「これがオブジェクトか……すごい！」みたいな感覚でハマっていきました。 そんな感じで Java の開発を楽しんでいたのですが、しばらくして外部のコミュニティとかに参加するようになって驚きました。当時は日本の大手Webサービスがこぞって使っていた Perl や Rails の誕生で注目が集まった Ruby に比べて Java はダサい的な空気がありました。僕は「好きなのになぁ」という気持ちや、「Java で Web とかどうなの？」とか言われると「Google も Amazon も使ってるのにな」とか複雑な気持ちになったのを覚えていますね。でも本当に僕は最初の感動もありましたし Java が好きだったので軸足をそこに置いていました。 

ですが、1つの言語にこだわるつもりはなく、さまざまな言語に触れていました。30歳を過ぎたころには、1年に1言語覚えれば、10年で10言語身に付くと考えたこともあります。最近は、10年前に比べて新しい言語に出会えていないこともあってそこまで触れていませんが（笑）。

僕の中ではプログラミング言語を学ぶとか勉強するって感覚はあまりないんですよね。新しい言語に触れるのも別に「勉強のため」とか考えているわけではなく、楽しそうだしちょっと触ってみるかという感覚ですね。たとえば新しいゲームの体験版が出ておもしろそうだったら遊んでみますよね？それと同じ感覚ですね。新しいもの、気になるものが目の間にあったら、まず触ってみる、体験してみる、自分にとってのプログラミング言語の学習とは、それと同義です。

加えて、先ほどの1年に1言語と同じように、数値化して習慣付けることが大事だという認識もありました。ですから、言語に限らず、何かを学ぶ際に、1日に何ページ以上本を読む、今であれば1日に1時間英語を勉強する、というように、自分に無理のない範囲で習慣付けすることで、結果的に学びの効果が得られると考えています。実体験に基づくので、自分にとっても進めやすいです。

どんなマネジャーにも求められるのが「情報の透明性」

――yoshioriさんにとってのエンジニア観、そして、スキルアップに向けた考え方に共通することとして「当事者」であることが非常に重要だと感じました。では、次に、エンジニアではなく、エンジニアを束ねるマネジャーについて、ご自身の体験をもとに、理想のマネジャー像、あるいは、マネジャーにとって必要なスキル・マインドを教えてください。

yoshiori：まず、マネジャーと一言で言っても、組織の大きさや目的、さらには、その人自身がどのタイミングでマネジャーになるかで、求められる役割、また、必要なスキル・マインドが異なります。

それでも2つ、自分がマネジャーになる場合に大切にしていることがあります。

1つ目は、自分で課題を発見し、正しく理解することです。あるチームのマネジャーになったときに、そのチーム内に課題があるのか、あるいは、チームとしては課題はなくても、組織全体で課題がある場合に、チームとしてどう立ち振る舞うかが必要なわけです。

具体的な例で言えば、あるプロダクトを扱う組織で、テストのスピードが遅いとなったときに、メンバーに聞くと「テストが遅い」というと思うんですよ。でも、実は掘り下げていくとみんな違うことを考えていることがある。テスト環境構築に時間がかかるのか、あるいは、実行スピードが遅いのか、それとも、他のフローとの兼ね合いで遅くなっているのか。同じ「テストが遅い」という言葉だけど、ちゃんと掘り下げてみるとみんなの感じている課題は実は違うということは良くあります。ですから、まず、その理由を可能な限り具体的に、解像度を高めていきます。

2つ目に、マネジャーとして必要なのは、より具体的になった、解像度が高まった課題について、チームメンバーに正しく共有することです。変にオブラートに包んでいうのではなく、みんながちゃんと仕事をしていたことは疑っていないが、現状としてこういう状態になっていて、それは課題だというのを伝えます。

次に、その課題の解決に対して、一方的に指示を出すだけではなく、分解し、そうなったプロセスを説明するようにします。その理由は、マネジャーから一方的に指示を出すと、実装する側（プログラマ・エンジニア）としては、受け身になって、結果、やる気が起きづらいからです。

また、どのチームのマネジャーかによっても考え方を変える必要があります。たとえば、サービス開発をするチームとバックエンドを開発するチームでは、目的も求められる役割も異なります。サービス開発であれば、よりサービスに近い側、ユーザに近い考えで開発をする必要があるので、技術だけではなくサービスへ強い思いを持てる環境づくりが必要です。一方、バックエンド開発であれば、ユーザから遠い部分、目に見えにくい部分を扱うわけなので、より技術的、データ的な考えが求められます。

マネジャーとしては、まずそのチームに配属される人の適性の判断が必要で、もっと言えば、サービスやプロダクトを提供する事業者であれば、会社として、所属するエンジニアが嫌いにならないサービス・プロダクトを持たないように心がけなければなりません。中でも、クックパッド時代は、エンジニア含め、従業員がサービスありきで開発に携わってくれたことは、マネジャーとして動きやすかったですね。

ドワンゴで経験したエンジニア経験に基づいて考えるマネジャーとしての意識

――今のお話は、非常に明快で、多くのマネジャーにとっても参考になるアドバイスです。ここまで明快に、また、芯が通った考えになったのには何か理由や背景があるのでしょうか？

yoshiori：さまざまな理由がありますが、その中でも自分にとって影響を与えてくれたのは、ドワンゴでマネジャーになったときです。このとき、初めて自分で意識してマネジャーになりました。

当時の上司である溝口浩二（coji）さんに「マネジメントをきちんと学んでくれ。エンジニアとして新しい技術を触るときまずそれについて調べて学ぶだろ？同じようにマネジメントも学んでくれ」と打診されました。そのときは正直あまり乗り気ではなかったのですが、cojiさんから「まずやってみてくれ。やってみて、それでも向いていないと思うなら降りてもらってかまわない」と、まず、経験することを強く勧められました。

その際、「ただ、新しいポジション（マネジャー）に闇雲に挑戦するのではなく、これまでのプログラマ・エンジニアで培ったエンジニアリングスキルを生かして、同様に（チームを）改善して、それで判断してみてくれ」と言われました。それで「やってみよう」という意識になりましたね。実際、マネジャーをやってみると、まさにエンジニアリングと同じで、因果関係や相関関係を分解することで、改善につながることがわかりました。

また、そのときに読書の重要性を実感できたことも大きかったですね。ご存知のように、2000年代に入ってから、国内のIT/Web企業が増えたことで、マネジャーという立場にも注目が集まり、マネジャーをテーマにした書籍が多数刊行されていきました。誤解を恐れずに言うと、これらの書籍って正解は書いていないんです。というかマネジメントに正解ってないと思うんですよね。でも不正解、やってはいけないことはあります。書籍を読んでその「マネジャーとしてやってはいけないこと」を学べたのは大きかったですね。周り見回すとやってはいけないって書いてあることやってる人も多かったですし。それを意識するだけでも、マネジャーとしてキャリアを積みやすくなりました。

ですから、とにかく自分で体験すること、さらに、エンジニアで習得した「新しいことに挑戦するときの心得」をマネジャーにも生かすことの重要性を理解できました。もちろん、良い結果も悪い結果も経験はしているのですが、どういう結果にせよ、先に進めたからこそ、質問にあるように、芯が通った考えになったのではないかと考えます。

人事部長の経験で目線が高まった――異なる職域経験がもたらす効果

――今でこそエンジニア出身のマネジャー、また、エンジニア出身の経営者は一般的になってきましたが、改めてお話を伺って、エンジニアキャリアを持っているからこその、マネジャー適正、それが世の中に認知されてきたからこそ、今の状況が生まれたように感じます。

キャリアのお話で言うと、yoshioriさんはエンジニア出身の人事部長（ジンジニア）のハシリでもあるように思います。そのときのエピソード、また、エンジニア出身の人事責任者（人事マネジャー）についてご意見いただけますか。

yoshiori：前職、クックパッド時代の話ですね。人事部長になった経緯は端的に言うとそのポジションが空いたからでした。社としてその状況になった際、世の中はちょうどHRTechというキーワードに注目が集まり、また、HRTechに関連したサービスや企業も誕生し始めたときです。この背景から「テクノロジーがわからない人間が（テクノロジー企業で）人事をやっていいのか」という声が出て、また、一方で、経営陣から自分に打診された際に、「人事もおもしろいよ」という言葉もあって、人事部長の職に就きました。

言われたとおり、人事では「人」に関わる多数の「データ」があるので、エンジニアの観点からすればそのデータを活用しないのは確かにもったいないよなという HRTech の考えも共感できました。また、先ほどのマネジャーのとき以上に、人事という日本の中でも歴史の長い職域なので、数え切れないほどの人事に関する書籍が刊行されていたので読み漁りました。中でも『NETFLIXの最強人事戦略』『ワーク・ルールズ！―君の生き方とリーダーシップを変える』『ALLIANCE　アライアンス』などは印象に残っています。

人事部長に着任してすぐのころは、正直右も左もわからなかったのですが、自分で経験して気が付いたことがありました。それは、「人事は何事もなく、日々正常に遂行されて当たり前の業務」だということですね。たとえば、従業員への毎月の給与支払い、出退勤の管理などです。つまり、正常稼働して当たり前、バグや失敗はあってはならない部門なのです。このとき、エンジニアの視点から、インフラエンジニアに近い職域だと感じました。

人事を経験して見えた「評価」の軸

――人事業務＝インフラ業務というのは、まさにエンジニアキャリアを持っているyoshioriさんならではの視点です。

yoshiori：バックオフィスを経験して初めて実感したのは自分の仕事へのフィードバックの頻度の違いですね。

エンジニアだと、たとえば新しい機能を出したら、ユーザーから「便利です」とかのフィードバックをもらえたり、いろいろなタイミングでネガポジ含めてフィードバックを受け取ったりするタイミングがあります。それがバックオフィスはあまりないんですね。へたすると自分の仕事へのフィードバックは評価のとき以外なかったりするくらいです。

しかも先ほども言ったようにバックオフィス系の仕事って基本的に正しく動いていて当たり前なんですね。それが崩れたときにネガティブなフィードバックを受けることはあるんです。でもポジティブなフィードバックを受けるのはなかなかない。「今月も給与が正しく振り込まれました。ありがとう」なんて言ってくれる人はいないですからね。

ただ、この経験があったからこそ、今、人事など、バックオフィス業務の重要性、また、それらの職域に対する評価の重要性を意識するようになっています。カッコいい言い方をすると、人事部長の経験が、自分のエンジニアのキャリアとしての目線を高くしてくれました。人事部長と他の部長の違いの一つとして自分の部署の人間だけを見れば良いのか全社の人間をみないといけないのかというのがあります。その経験のおかげて会社全体として俯瞰してみるという視点ができたと思います。

新しい人事制度設計などにも挑戦しましたが、基本的にはトライアルの位置付けから始めましたね。新制度スタート時から正式制度とすると、必ず穴を付く状況・人が出てきますから。このあたりも、エンジニア的な改善の意識とつながっているかもしれません。

その他でいえば大きい挑戦をすることは意識していました。よく CTO とお互いに「なんかでかい失敗した？」と質問していました。大きな挑戦をしないと大きな失敗はしないですし、成功率100%の挑戦はそれは挑戦ではなくただのタスクです。大きな失敗をしていないということは大きな挑戦をしていないと同義なのでお互いに意識するためにその質問をしていましたね。

エンジニアの価値を認めるなら、採用で妥協しない

――「エンジニアのキャリアとしての目線が高くなった」というのは、示唆に富む非常に貴重なお話です。続いて、その話とも関わる、エンジニアマネジャーの業務でもあり、そして、人事にも関わるエンジニア採用について教えてください。

yoshiori：採用の基準については、自分の中でブレない軸があります。それは「技術力を見る。そして、妥協しない」です。ポール・グレアムの書籍でも触れられていましたが、採用というのは、一度、基準を下げてしまうと、その基準から上に上げることはほぼ不可能で、さらに、採用した結果、チームや組織の力（の平均値）は下がったままになります。

ですから、どのような人材を採りたいか、また、採用基準はなにか、という質問を受けると必ず「その人材を採用した場合、今の私たちの組織・チームのエンジニアレベルの平均が上ると思える人」と言っています。ただ、これもまた、技術力だけがあれば良いとかの極論ではないんです。たまに「では、すごい技術力を持ったエンジニアが応募してきた場合、その人の人柄が良くない（たとえば、面接態度が悪い）場合でも採用するんですか？」と、聞く人がいます。先に言っておきますが、そんな人材は絶対に採りません。エンジニアスキルもあって、かつ、人柄、もっと言えば、自分たちと相性が合う（合いそう）という人材を選ぶわけです。順番として、まず、エンジニアとしての技術力、次に、人柄という順番ですね。

それから、人が不足している場合は、とくに何としても採用しようという気持ちにもなりますが、結構それは危ういと思っています。実際には会社に入るべき人だった人を落としてしまうよりも、入るべきでなかった人が入社してしまう方が会社へのダメージは大きいのでそこは注意していました。ですから、採用に関わる人間同士で採用のレベルを下げないストッパーの機能を意識することを心がけていました。

――ちなみに、技術力に関して、具体的な基準、言語化できるものはありますか？

yoshiori：それは非常に難しいです（笑）。それでも、あまり奇をてらった部分を見ることはなくて、たとえば、GitHubに公開されているコードやコミット数、また、イベントに登壇しているのであればその内容、もちろん、イベントに登壇していなくてもブログがあればその内容には目を通します。

そして、面接時に、可能な限りディスカッションの時間を設けます。前職では必ず面接の前に技術課題を受けてもらっていたのですが、それを元にディスカッションしていました。課題が全部正解である必要はなく、何を考えてその実装にしたのかとか、もしもサービスとして出すときにミドルウェアはどうするかとかそう言った部分まで話せれば「エンジニアとしての会話」は成立しますし、採用基準として評価できます。

――これまで、採用する側の立場でご意見をいただきました。2020年、yoshioriさんはLaunchable, Inc.へ転職されましたね。せっかくなので、採用される側（転職希望者）としての意識や意見があれば教えてください。

yoshiori：これについては、実は当初はまったく転職するつもりはなかったんです（笑）Launchable, Inc. の共同創設者川口耕介さんとお話をして、話を進めていくうちに気がついたら転職していたという。その中で、転職に至った最初の動機は川口さんのブログを読んでおもしろそうと思ったからですね。

ブログを読んで、そして、Jenkinsの生みの親の川口さんは知っていましたし、そんな川口さんがまたおもしろそうなことをやっているというのをみて、すごく興味を持ちました。砕けた言い方をすれば、新しいゲームを体験しにいく、そのような気持ちでしたね（笑）。冒頭の比嘉さんの話に戻りますが、もし、その当時、比嘉さんに会う前の自分だったら、川口さんの貴重な時間をわざわざ僕なんかのために使ってもらうのは申し訳ないと思って興味があるとメールしようとすら思わなかったでしょう。

ですから、転職する人に向けたコメントということであれば、「気になったらまず行動してみる」ことが大切です。

コロナ禍、そして、コロナ後のソフトウェア・エンジニアの役割

――転職すら考えていなかったのに、1つのブログ、気になる技術がきっかけで、4ヵ月後には転職していたというのは、まさにこれまでのyoshioriさんが体現してきた、エンジニアとしてのキャリアそのものとも言えます。

最後に、少し大きな視点で、これからの、とくにコロナ禍、そして、コロナ後のソフトウェア・エンジニアの役割について、ご自身のお考えを聞かせてください。

yoshiori：ポジティブな部分とネガティブな部分があると思っています。まず、おそらく多くのエンジニアが感じていると思いますが、ソフトウェア・エンジニアの仕事はなくなりません。少なくとも自分が生きている間は、職業として成立するでしょう。

最近ではノーコードなんていうトピックにも注目が集まっていますが、すべてをノーコードで実現できることはなく、ノーコードで実現できる・できないの判断が求められます。その判断はソフトウェア・エンジニアでないとできませんし、実現できないものを実現するのも仕事です。ですから、極論で話せば、ソフトウェア・エンジニアは、ソフトウェアがある限り、必要になります。

一方で、デジタル化・オンライン化が進むことで、ソフトウェア・エンジニアという職業に注目が集まり、これからさらに花形のしごとになる可能性があります。テレビや新聞でもそういう取り上げ方がされるかもしれません。このときに注意したいのが、うわべの流行りだけに流されないことです。先ほど話したノーコード技術を使うだけの人、あるいは、指示出しされた、仕様書通りのコードだけを書き続ける人が増えるかもしれません。

もし、そういう人たちがソフトウェア・エンジニアだと定義するのであれば、私はその人たちの仕事はなくなると思いますし、そもそも、そういった人たちはソフトウェア・エンジニアではないと考えます。私が考えるソフトウェア・エンジニアは、プログラミングができる、ソースコードが書けるだけの人ではなく、課題解決のためのアイデアを考え、それを実現できる人だからです。

たとえば将棋の駒の動かし方を知っていれば誰でも将棋のプロになれるわけではありません。駒の動かし方を知るのは大前提のひとつでしかありません。今、コードを書ければエンジニアになれているという勘違いが増えている気がしていて、その点は少し危惧しています。

――これまでの取材でも、皆、同様のお考えをお持ちでした。プログラミングスキル、ソースコードを書く技術は必要だとしても、それが、そのままソフトウェア・エンジニアであることの必要条件ではないですね。他にも何か気になる点、あるいは、未来に向けて考えていることはありますか？

yoshiori：これが本当に僕の気持ちの中でもさっきと矛盾してて難しいところなのですが、ただコードが書けるだけの人でもある程度稼げて食っていけるくらいに業界の裾野は広がっていかないと業界全体が先細りしちゃうと思うんですよね。なのでそういう人たちもいつつ、さらにもっとスキルのある人はさらに評価されて適正な対価をもらえるようになると良いなと思います。

さまざまなソフトウェア・エンジニアが、社会課題を解決して、世の中を豊かに、そして、それが結果として経済につながれば、ソフトウェア・エンジニアがきちんと稼げる社会になると信じています。

――ありがとうございました。

（聞き手：株式会社技術評論社　馮富久、撮影：中村俊哉）

yoshioriさんに3つの質問