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

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

つい2ヶ月前に、EMの座談会をお届けしましたが、今回はEL（Engineering Lead、いわゆるチームリーダーのこと）のみなさんに集まっていただきました。

▼参加してくださったELのみなさん
・志摩さん：
カンリー福利厚生チーム（Dev4）のEL
・金井さん：
カンリーホームページチーム（Dev2）のEL
・菅野さん：
カンリーカスタムシリーズチーム（Dev2）のEL

技術者として現場の第一線で開発しつつ、チームを技術的にリードしている彼らが、何を考え、どう行動しているのか。技術的な話はもちろん、チームや組織のコミュニケーションまで、現実と課題、そして理想を”正直であれ”（※1）で話していただきました。
（※1）正直であれ：カンリーの5つのバリューのひとつで、本音で思いを伝え、納得するまで対話することを示しています

わたしからの前置きはこのくらいにして...さっそく、ご覧ください！

リーダーの役割は、チームとして前に進める仕組みをつくること

菅野さん（以下、菅野）：
まずは、仕事に向き合うスタンス、ですかね。志摩さん、金井さんにもお聞きしたいのですが、言い出しっぺの僕から話します。

「とにかく終わらせること」を重視してます。そのために、代表もよく話しているエフォートレス思考（※2）をかなり意識していて。生産性向上につながる作業や取り組みに注力するようにしています。
（※2）エフォートレス思考：少ない努力で最大の成果を上げること、どのようにやるかを極める技術

志摩さん（以下、志摩）：
僕も、菅野さんに近い気がします。目指しているのは、チームが計画通りに価値を継続、提供できる状態を維持すること。そのためには常に先手を打つ必要があって、技術、コスト、スケジュールにおけるリスクを潰して、できるかぎり不確実性を最小化するようにしています。

金井さん（以下、金井）：
具体的には、どんなことをしてるんですか？

志摩：
バージョンが古いことで、次のアプリリリースができない、みたいな状態にならないように気をつけてます。バージョンのサポートが切れる前にちゃんと上げておくとか、次の大きな開発が入る前に、テストコードの実行速度が遅いといったボトルネックを取り除いておくとかですかね。たとえばテストの実行速度に関しては、プルリクエストを作るごとに2分以上かかっていたところを、13秒まで短くしました。

金井、菅野：
おぉー！ それはすごい！ どこを変えたんですか？

志摩：
以前は、すべてのユニットテストで、データベースに接続してテストをしていたのですが、全部する必要はないかも...と思って、依存の見直しを行いました。ドメインロジックやユースケースの大部分は、データベースへの永続化とは独立して検証可能であると判断し、永続化を担うインフラ層のテストだけをデータベースに接続させるようにしました。で、他のユースケース層などでは永続化部分をモックに置き換えて検証する方針に倒し、高速化を行いました。
金井さんは、どんなことを意識してるんですか？

金井：
属人化させない、逆にいうと、再現性があるものになっているかどうかはすごく大事にしてます。チームの誰かしかできないのってすごく困るので、誰もができるようにしたいなと。ただ、やりかたはちょっと悩んでいて。

他の部署から質問がきたときに、窓口になるのって僕らじゃないですか。それを自分で返しちゃうと、自分に情報が閉じてしまって、チームのメンバーは状況がわからなってしまう。この場合、すぐに情報共有することくらいしかできてないのですが、そのあたり、なにか工夫してたりしますか？

菅野：
今は一人で動いてるのでアレですが、チームでやっていたときは朝会で共有するコーナーをつくってましたね。社員同士でしか話していないことを業務委託の方に伝えたり、プロジェクトの状況を他のチームの人と話した内容を共有したり。チームの全員が同じ理解度になるよう、日々、認識合わせをしていました。

金井：
なるほど、菅野さんは定例で情報共有をしていたんですね。メンバーとの連携みたいなところでちょっと聞いてみたいのですが、志摩さんは自分でやっちゃうタイプですか？ それとも、メンバーに任せるタイプですか？

志摩：
自分が全部やらないようには気をつけてます。ただ、入社したばかりの頃は、なにかあったら自分で直してしまってました。誰かに伝えるより自分でやる方が早いし、確実に直るじゃないですか。でも、これって実は良くなくて、チームで前に進んだ方がスピードも品質も良くなるんですよね。

このことに気づいてからは、最善の意思決定がメンバー主体でできるように、みんなの意見を尊重するようにしてます。さらにその前段階として、意見が活発に出るような場をつくるということも、自分としてはけっこう意識してるかなと。あと、意見を否定しないのと、次のアクションにつなげるのも重要な気がしていて。意見を出しても、なにも行動してくれない、なにも変わらない、と思ってほしくないですから。

金井：
志摩さんのチームは、みんなから意見が出ます？ もし、意見を言うのがいつも同じ人になってしまった場合は、どうしますか？

志摩：
偏っている場合はレトロスペクティブの進め方を変えたり、1人何分とか持ち時間を決めて話してもらうようにしているかな。

菅野：
僕はちょっと違う悩みで、順調にいきすぎて課題がなかったり、話すことがない時がけっこうあって。「今週も大量のチケット消化してよかったね」で終わっちゃったり。メンバーが優秀すぎるという...。

金井：
悩みといえば悩みだけど...。

志摩：
かなり贅沢な悩みですね（笑）。

あえて属人化させることが、最善の道になることもある

菅野：
ELって、チームを良くしていくのも役割のひとつだと思うのですが、なにか取り組んでいること、工夫してることはありますか？

志摩：
Q（クオーター、四半期）ごとに全社員が実施する360°フィードバックを活用して、メンバー同士で1on1をしています。良かった点はもちろん、改善点も「正直であれ」で直接、伝えるようにしてもらっています。

その結果、連携が取りやすくなったり、意思疎通や認識にズレ、方向性の違いがあったとしても、すぐに話して軌道修正できるようになったりと、メンバー全員が主体的にコミュニケーションを取れるようになったのかなと。また、会話やディスカッションの積み重ねにより、開発生産性も上がってきているのではと感じています。

菅野：
たしかに、1on1じゃなきゃ話せないことってありますね。

志摩：
そうなんです。360°フィードバックだけだと、良かった点、改善点を書いて終わりになってしまって、改善点に対するネクストアクションにつながらないんですよね。なので、メンバー同士の1on1では、改善するためにどのようなアクションを取るべきかを一緒に考え、これでやっていこう、と合意するところまで話してもらうようにしています。さらに次のQで、改善できたのかどうかを確認することで、成長している実感も得られるようになるんじゃないかなと。

菅野：
うちのチームでも1on1をやっていた時期があるんですが、改善点がなかなか出てこなくて...。改善点、つまり課題を見つけて、解決して、評価をするというサイクルが回せているのはすごいです。

金井：
上手くいかない理由として、Dev2はホームページとカスタムシリーズでチームが分かれているので、共通の課題が見つけづらいというのが大きい気がしてます。

志摩：
あぁ、そういうことか。そもそも何をやっているのかわからない部分が多いから、改善するところも見えづらい、と。
金井さんは、どんなところを意識してるんですか？

金井：
属人化させない、という話と逆になってしまうのですが...。今は、大きなリニューアルにフルコミットしなくてはならないフェーズで、スピードが最優先なんですね。そうなるとやはり、新規機能開発は得意な人がやったほうが早いんですよね。速度を落としてまで属人化を解消する必要はないので、レビューも技術力の高い人に振るようにしています。

菅野：
これはしょうがないんじゃないですかね。会社として、いつまでにやるべきという目標をクリアするのが最優先ですから。

志摩：
ちなみに、品質面はどう担保してるんですか？

金井：
最低限コード上のユニットテストやインテグレーションテストは必須で、加えてQAフェーズも設けてます。ここは属人化の解消という意味で、メンバー全員がテストの設計〜実行までできる体制にしています。

AIも、“チームの一員”

菅野：
少し前からエンジニア部全体でAIを活用しはじめていますが、どうですか？ 僕は、今Qの目標を「自分で1行もコードを書かない」ことにしていて、ちょっとした変更もすべてAIでやってます。

志摩：
緊急対応の時も？

菅野：
ですね。緊急対応時の障害調査はAIを使っていて、エラーログをClaude Codeに貼り付けて、原因として考えられることを列挙させてます。自分でやるよりも断然早いですよ。

志摩：
なるほどね。ちょっと話を変えてしまうのですが、菅野さんがtimesチャンネルに流しているアレは？

菅野：
Coderabbitで特定のリポジトリにマージされたプルリクのレポートを吐き出させて、何が起こったのかを1週間分見れるようにしている感じです。機能があったので使ってみたんですが、権限を変更されてしまって設定が変えられなくなってしまって...勝手にずっと流れてます（笑）

金井：
それはつらい（笑）。

志摩：
ちなみに、なにか効果はありました？

菅野：
効果はそんなに...。ふだん触らないリポジトリを吐き出させて、他のチームがやっていることが見れるのはおもしろいなと。

志摩：
そこでいうと、自分たちが次につくる予定のものが、もしポンと出てきたら、横展開して工数削減とかにつなげられそうですよね。車輪の再発明しなくていいというか。情報を横断させて、一元的に見れるのがいいのかなと。

菅野：
いやぁ、まさにそれをやりたかったんです（笑）。

志摩、金井：
乗っかってきた（笑）。

菅野：
でも、まじめな話、AIはもちろん、既存のツールでも機能追加とか、新しいものがどんどん出てきてるじゃないですか。たぶん競合他社もいろいろ試してみている中で、新しいものに触らなければ負けてしまう、という怖さもあって。金井さんはどんなふうにAIを使ってるんですか？

金井：
まずはAIに聞くのが、もう習慣になってますね。で、AIがわからなければ、誰かに聞く感じ。使い方はツールごとに変えてるかな。ひとつ例を挙げると、cursorは狭い範囲をめちゃめちゃ詳しく見てくれる印象があって。障害の原因など問題を特定したいときとかは、「ここかな？」という部分の当たりをつけて、あとは細かく指示して調べてもらうようにしてます。

人間の負荷を減らして、人間にしかできないことをやる

菅野：
そろそろ終わりの時間が近づいているので、最後にみなさんのやりたいことも聞いてみたいです。

金井：
前に、3チーム横断でギルド（※3）をしたじゃないですか？ 成果物はまだ出てないけれど、めちゃくちゃよかったなと。チームを超えて情報共有ができたり、〇〇さんってこういうことを知ってるんだとか、新しい発見もあって。前回はタスク管理方法の改善でしたが、次はAIを絡めたテーマでしてみたいです。
（※3）ギルド：興味ある分野、技術に対してプロジェクトチームを作り、新しいツールを触ったり、業務に使えそうかどうかを検証したりしています

志摩：
ギルドは、サイロ化を防ぐ取り組みのひとつにもなりますよね。カンリーはマルチプロダクトを展開しているので、どうしてもサイロ化しがちだし、チームも分断されやすくなってしまう。そこを、金井さんが立ち上げてくれたギルドが解決してくれるんじゃないかと。

金井：
他のチームが使っている技術とか、なにをしてるのかが見えないのって、すごくもったいないない気がするんですよね。チーム間で共有できる場があれば、連携とかもしやすくなるのかなと思って。

志摩：
実際、チーム以外の人とペアプロをやることで、新たな気づきもあったし。できれば今後も定期的にやりたいですよね。
技術的なところだと、菅野さん、どうですか？

菅野：
プラットフォームエンジニアリングの観点で、並列QAできる環境をつくりたいなと思ってます。Devinとかcursor、Claude CodeなどAIのおかげで、開発スピードはどんどん上がってるじゃないですか。すると今度は、QAがボトルネックになってしまう。環境がひとつだけだと、本番に出せない機能が溜まっていってしまうんですね。

金井：
あー、なるほど。ステージング環境が1つしかないと2機能同時にQAできなくて、先にやってる機能が終わらないとデプロイできない状態になってしまってるというわけですね。

菅野：
なので、パラレルにQAできるように、ブランチごとにフロント、バックエンド、データベースを含む環境が自動で立ち上がるようにしたいんです。イメージとしては、プルリクを作成すると自動でプレビュー環境が立ち上がって、すぐに一通りの動作確認ができる感じ。もちろん、クオリティ、コスト、スピードのバランスを考えなくちゃいけないですが、できればやりたいなと。

志摩：
スピードと品質が担保されるなら、やる価値はあるんじゃないですかね。Dev4はそもそもQAエンジニアがいなくて、PdMにテスト設計から実行までお願いしている状態で。負担を軽減するためにも、菅野さんが作ろうとしている環境ができたら、ぜひ横展開してほしいです。

菅野：
あ、それはもちろんです。負担軽減というところで、志摩さんもなにかやろうとしていたりするんですか？

志摩：
さっき菅野さんが言っていた、AIによって開発スピードが上がるという話に関連するのですが。生成AIによってどんどん自動生成されるようになると、人間のレビュー負荷が上がるのではないかと考えていて。これをどう下げていくのかというところに興味があります。

じゃあ、どうやって負荷を下げるのかというところなんですが...。カンリー福利厚生は、ユーザーストーリーを含むプロダクト要求仕様書（PRD）をもとに開発をしています。なので、PRD通りに実装されているかどうかをAIで自動でチェックさせることで、人間のレビュー負荷を下げられるようにしたいなと。

金井：
AIはなにを使うんですか？

志摩：
Claude Codeですね。どういう観点でレビューするのかを、オプションにあるカスタムスラッシュコマンドを活用して作ろうかなと。たとえばDDD観点であれば、DDD用のチェックリストどおりにできているかどうかをひとつずつチェックして、◯×をつけていくという感じです。

さらに、.mdファイルとかに書き出してポストして、プルリクにそのまま貼り付けるコマンドも用意して、コメントにも自動で貼れるようにしていて。コマンドを叩くだけで、自動で実行できるようにしたいんですよね。

菅野：
観点別にしてる理由って、レビュー精度が下がってしまうからなんですか？

志摩さん
というよりも、プルリクの内容ごとに観点が変わるかなと思って。一応、デフォルトでは全部チェックできるようにしているんだけど、トークンを使うので、コストがかかってしまうんですよね。なので、観点別に切って、プルリクごとに最適な観点を取捨選択できるようにしつつ、全部も見れるようにしている形です。

＊　　＊　　＊　　＊　　＊　　＊　　＊　　＊　　＊

実はこのあとも、AIツールや技術について話が続くのですが、かなり長くなってしまうので、今回はここまでにさせていただければと思います。

ELのみなさんには、また座談会をしていただく予定なので、ぜひ続編をお楽しみに！