※このストーリーは、noteで発信した記事を転載しています。

こんにちは！ カンリーでエンジニア採用を担当している宮本です。

今回は、VPoE長谷川とエンジニアリングマネージャー（以下、EM）の須藤に、「組織」と「人」というテーマで、ディスカッションしていただきました。

エンジニア組織のビジョンや行動指針を作ったことで、どんな変化があったのか。組織として、エンジニアにどんな環境を提供したいのか。組織開発と採用活動をリードする2人が今、何を考えていて、これから何をしようとしているのかを、語っていただきました。

VPoE　長谷川 稜

大学卒業後、システム開発会社にてサービスの開発に従事。主にインフラ設計、サーバーサイドの設計を担当し経験を積む。その後、アプリ広告 ASPの会社の立ち上げに関わったのち、独立。フリーランスエンジニアとして3年間活動。カンリーの創業初期にCTOとして成長し続けるチーム作りを目指す。

▼参考記事：カンリーのCTO譲りました！自分よりも優秀な人を採用していく組織カルチャーとは

EM・カンリーエンジニア部 部長　須藤 聡之

独立系SIer企業にて、受託開発、自社プロダクト開発などの多種多様なプロジェクトに従事。開発リーダーやプロジェクトマネージャーとしてマネジメントの経験を積む。カンリーに入社後は「カンリーホームページ」のプロダクト立ち上げをリードする傍らで、エンジニア採用やエンジニア組織づくりなどの業務も兼任。現在はEMとして「カンリー店舗集客」の開発をメインとしつつ、組織開発にも携わる。

▼参画記事：満足度の高い1on1を受けるコツ

行動指針を作ったら、理想の組織が見えてきた

宮本：
すごく抽象的な質問になってしまうのですが、採用では何を重視しているのでしょうか？

長谷川さん（以下、長谷川）：
大前提として、バリューフィットがあります。その上で、エンジニア組織というところだと、いい意味で楽をしようとすると言いますか、最小限のリソースで高い生産性を出そうとしている人がいいなと。

須藤さん（以下、須藤）：
いわゆる効率化ですよね。カンリーのバリューでいうと、「圧倒的当事者意識」の「生産性」という軸でフィットする気がします。

長谷川：
そのとおりですね。逆に、手段が目的になっている人だとフィットしないと思います。お客さまへの価値提供を目的としている中で、「この言語をやりたい」「このアーキテクチャをやりたい」という理想やこだわりが強すぎると、上手くいかないのかなと。適材適所を考えられないと、むずかしいですね。

須藤：
そういえば、こういう話ができるようになったのって、ほんと最近のことですよね。これまではエンジニア採用におけるカルチャーマッチって、あまり言語化できていなかった気がしていて。エンジニア部の行動指針が決まって言語化された感じがあります。

さきほど長谷川さんがおっしゃった「いい意味で楽をしようとする」というのは、「当たり前の水準を高め続ける」というビジョンに近い気がしました。

宮本：
せっかくなので、行動指針についてもっとお聞きしたいなと。どのように行動指針を体現しようとしているのか、具体的に教えていただけると嬉しいです。

長谷川：
理想があったとしても、プロジェクトが忙しいと短期的な解決策にフォーカスしてしまうことって、よくあると思うんですね。そんなときでも「時間を言い訳にせず、根本解決に挑もう」「目的を見失わず、価値ある解決策を追求しよう」という行動指針によって、理想に向かって考えよう、がんばろうという共通認識が持ちやすくなったと感じています。

もちろん、考えた上で実行しなかったり、折衷案を取ることもありますが、理想のカタチをしっかり話し合って、どの選択肢がベストなのかをディスカッションできるのは、すごくいいことだなと。

須藤：
体現というところだと、わたしはすでに全部やってますけどね（笑）。という冗談はさておき、チーム開発をする上で、「人を責めずに、仕組みを改善しよう」は、かなり大事にしています。具体的にいうと、課題が発生した時に「誰が悪い」と犯人探しをするのではなく、仕組みを改善して、みんなでチームを良くしていこうとしています。

たとえば、エラーが発生してシステムがダウンしてしまったときに、バグを埋め込んでしまった人を個人攻撃しても、なんの解決にも繋がらないですよね。まずは、お客さまの理想から入って、ユーザー体験を元に戻す。そのあとで、再発防止のためにチームとして何ができるかを考える。このケースであれば、いろいろな検知の仕組みを作ったり、コードレビューの方法を変えてみたりもできますよね。

長谷川：
そのとおりだと思います。よく言われることですが、再発防止策の一環として「ダブルチェックを強化しましょう」というのはアンチパターンですよね。2人とか3人でチェックしていけばいいという話ではなく、ダブルチェックをしなくてもいいようにするとか、仕組みそのものを見直していく必要があるのかなと。

須藤：
そうですね。さっきのコードレビューの話でいうと、時間がなくてチェックしきれなかった結果バグが生まれてしまったのであれば、AIでコードレビューができるツールや静的の解析チェックを入れたり、CI/CDを導入したり。あくまでも、技術的な解決や仕組みの改善をしていくべきなんですよね。「失敗した人が、もっとがんばればよかった」という話にしてしまうと、組織が成長していかないのかなと思ってます。

​​もうひとつ、「実践から学び、知識を知恵に変えよう」のところでも、やりたいことがたくさんあって。今、強く思っていることとしては、みんなにチャンスがある状態にしたいんですよね。できる人がすべてを解決してしまうのではなく、みんなが成長できるような役割や環境を提供していけたらいいなと。

長谷川：
小出さんのお話にあった「Goのコンポーネントを立ち上げた」というのも、こうした環境づくりの一環だった気がしますよね。さらに将来的には、チーム間で人を異動できるようにしたいなと思ってます。今は5つのプロジェクトチームがあって、それぞれ関わるステークホルダーやメンバー、使っている技術も違います。これを利用してジョブローテーションをすれば、新しい人との関わりや技術を通して刺激を得られるんじゃないかなと考えていまして。

須藤：
そうすると「知識を共有して、組織の成長を促そう」という行動指針につながりますね。サイロ化を良しとしないというか。

長谷川：
そうですね。ジョブローテーションを半強制的にする、いわば、人の異動を前提にすれば、サイロ化は構造上、ほとんど起こらなくなりますよね。これを実現するためにも、ドキュメンテーションやシステムの標準化、全体のアーキテクチャが統一されているなど、誰もがすぐにキャッチアップできる状態を作っていきたいなと思っています。事業モデルとして、今後、新しいプロダクトがどんどん立ち上がっていくという観点からも、こうした環境づくりがより重要になってくる気がしています。

須藤：
そうなったときに、マネージャーは何をすべきか。マネージャーの責務は、事業の成果にコミットすることで、そのためにはチームの成果を最大化させることが必要だと思っているんですね。では、チームの成果を最大化させるにはどうしたらいいのか。ひとつの手段として、アロケーション（割り当て）しやすくすることですべての人がチャンスを得られたり、キャリアとしても継続的に成長できる環境を提供できるのではないかと考えています。要は、みんなで成長して、事業を伸ばしていきたい、ということですね。

プロダクトエンジニアを生み出す組織を作る

宮本：
エンジニアの成長やキャリアというお話が出ましたが、目指してほしいエンジニア像はありますか？

須藤：
今って、得意な領域で開発を続けた結果、フロントエンドとかバックエンドとか、ラベルがついてしまっているじゃないですか。、そうではなく、エンジニアはプロダクトを伸ばす人であってほしいなと思っているんですね。この意味で、最近ちょっとずつ聞くようになった、プロダクトエンジニアをたくさん生み出したい、育てていきたいなと。

宮本：
プロダクトエンジニアは、ポジションなんですかね？ あまり聞きなれないのですが...。

須藤：
ポジションというよりは、志向性や能力を表している感じです。「開発の中心にプロダクトの価値追求をおいているエンジニア」として定義されていて、プロダクトを用いた課題解決やDXを進める上で、お客さまのお客さまや社会的な課題解決をして世の中をより良くしていくことがミッションになってくるのかなと。

能力的なところでいうと、テクノロジーだけでなく、プロダクト目線であるUXデザインや、ビジネスサイドが中心になりがちなドメインについても、エンジニアがオーナーシップを持っている状態ですね。これが、カンリーが目指すエンジニア像になります。

もう一度、採用基準の話に戻ると、長谷川さんが冒頭でおっしゃったバリューフィットや技術がベースにあった上で、プロダクトエンジニアとしての志向性、少なくともポテンシャルを持てるようになるといいなと思っています。

もちろん、フロントエンド、バックエンドといった技術領域で役割分担して成功している会社もあって、この場合、エンジニアは専門家集団であるべきです。一方、カンリーのエンジニア組織としては、ビジネスサイドと協力していいものを作ってお客さまに届けることを目指したいんですね。そうなるとやはり、プロダクトエンジニアとしての志向が必要になってくる、というわけです。

長谷川：
ここは今まさに、取り組みを始めているところですよね。ただ、これまでは、プロダクトに興味を持ったり、ビジネスサイドと会話できる機会を作れていなかった。そこで今後は、EMクラス以上で仕組みづくりをしていかなくてはならないなと思ってます。

須藤：
やってみなきゃできないのに、メンバーにその機会を作ってあげられていないということですよね。ドメインを学習するには、もしかすると組織構造を考え直す必要も出てくるかもしれませんね。これまでも検討する機会はあったものの、エンジニア部だけでやろうとすると、どうしても限界が出てきてしまう。そろそろ、事業全体から見たときに「これでいいんだっけ？」を、考え始めるフェーズにきている気がします。

長谷川：
会社としてテックカンパニーを目指していく中で、見直す気運にはなってきているんですけどね。

須藤：
そうですね。このあたりはエンジニア組織にとってというだけでなく、事業部全体で最適な方法は何かを模索し続けていきたいですね。

エンジニア一人ひとりのWillを実現できる場でありたい

宮本：
組織づくりにおいては採用活動も重要になってくるかなと思うのですが、どんなスタンスで選考や面接に臨んでいますか？

長谷川：
転職を通じて本人のキャリアをよりよくできるかどうか、その環境をカンリーが提供できるかどうか、を特に意識して見るようにしています。

須藤：
相互理解の場であるという点は、選考に関わるEM、CTO、VPoE、全員が意識してますよね。あくまでもわたしの場合ですが、本人が実現したいキャリアがカンリーで提供できないのであれば、「お互いに良くないね」という共通認識を持てるように話を進めることもあります。

長谷川：
めちゃくちゃスキルマッチしていても、本人のWill（やりたいこと）が合っていなければ、仮に入社していただいたとしても、短期離職に繋がってしまいますからね。

須藤：
こういったことが起こらないよう、キャリアパスやビジョン、行動指針を作っているわけですよね。

宮本：
そういえば、メンバーとして入社したあとのキャリアパスには、どのようなものがあるのですか？

須藤：
マネジメントの方向にキャリアを伸ばした場合は、EM、VPoEというステップになります。もうひとつ、技術、いわば専門性を追求したい場合はテックリード、CTOという形になります。

ただ、現状、テックリードはプログラミングだけをするのではなく技術選定や技術負債のコントロールなども任せているので、広義ではマネジメント（テックのマネジメント）になってしまうんですね。となると、専門性に特化したポジションがないので、定義も合わせて作っていきたいなと考えています。ちなみにテックリード、CTOを目指す場合でも、事業への興味が必要なくなるわけではありません。カンリーでいうとCIOの萩野さんのような動き方で、専門性を使って事業に貢献していくイメージです。

技術にも同じことが言えるんですよね。フロントエンドのスキルが高いとか、たくさんの言語を扱えることはあまり重要ではなくて。そのスキルを使って何をしてきたのか、どのように事業やプロダクトに貢献してきたのかが大事なのかなと。

長谷川：
おっしゃるとおりですね。プログラミングが徐々にAIやAIエージェントで代替されていく中で、人にしかできないことをやるべきだし、追求していってほしいですよね。

▼EM、テックリードを募集しています！ カジュアル面談をご希望の方も、ぜひお気軽にご連絡いただければと思います！