レビューではヒントだけを与えて「ここ」とは言わない　テックリードが具体的なアドバイスを“そこそこ”にしておく理由　

新規サービス開発チーム・テックリードの自己紹介

山川和也氏（以下、山川）：これから座談会を始めます。まず、登壇者のみなさんにテックリードとして、各チームでふだんどのような業務をしているかを織り交ぜながら、自己紹介してもらえればと思います。奥村さんからお願いしていいですか？

奥村和彦氏（以下、奥村）：私は奥村和彦といいます。新規サービスの開発チームでテックリードをやっています。

簡単に経歴の話をします。これまで、ハードウェアの電気回路設計やプログラマー、SIerにてWebアプリを請負で開発、前職ではプリセールスエンジニアをしていました。そこでは、製品のデモ、最新技術のキャッチアップやアウトプットなどをやっていました。いろいろな立場のエンジニアを経験してきて、2021年の10月にこのチームのテックリードとして弥生に入社したので、テックリード歴がそのまま弥生での社歴となっています。弥生で5社目です。

チームの中では、要件定義や基本設計の役割を担っています。プロダクト開発のいわゆる上流の部分を主に担当していて、最近は他の関連サービスの人たちとも話したり、連携したりしています。弥生の企画部の人やマーケティングの人、あとはカスタマーサポートの人とも話し合って、いろいろな要件を決めたり調整をしたりするのが主な役割です。その内容をチームのメンバーに伝えて、上がってきた設計やコードのレビューもしています。

ちなみに、うちのチームはちょっとメンバーが多いので、実は僕も含めてテックリードは4人います。それぞれが、アーキテクチャをリードしたり、最新技術の導入をリードしたり、品質やテスト視点で開発チームをリードしたり、メンバーの実装作業を直接リードしたりと、専門分野を分けて活動しています。今日はよろしくお願いします。

山川：よろしくお願いします。奥村さんが言っていたように、各チームに1人しかテックリードがいないかというと、ぜんぜんそんなことはありません。また、テックリードといってもいろいろなタイプがいると思っています。この後、みなさんからそういった話もお聞きできればと思っています。

「YAYOI SMART CONNECT」テックリードの自己紹介

山川：では、続いて三富さん、お願いします。

三富学氏（以下、三富）：外部とつなぐ「YAYOI SMART CONNECT」というサービスのテックリードをやっています、三富と申します。

テックリードとしてふだん何をやっているかは、先ほど奥村さんがお話したこととだいたい一緒です。今はちょうどプロジェクトが大変な作業中なので、主にエンジニアのみんなが出してくれた成果物をレビューして、指摘して、返ってきて、というのを繰り返しやっています。

閑散期はあまりないのですが、ちょっと暇な時にはエンジニアのみんなが「何かないの？」「タスクはないの？」と口を開けた雛鳥のように待っているので、タスクを生み出すという作業を一生懸命しています。

プロジェクトをリリースした後はリリース作業もします。だいたい夜間のリリースになるので翌日はお休みになるのですが、その間に不具合が発覚して、僕のいない中で「お祭り」が行われていることもあります。すると、日中対応してくれている他のテクニカルリードから怒られる、ということが僕の主な仕事になっています。だいたい口だけで生きているテックリードなので（笑）。そんな感じです。

山川：そんなことはないですよ（笑）。

三富：よろしくお願いします。

山川：よろしくお願いします。三富さんがリリースに立ち合った次の日、何もなければ「おぉ～」と社内では盛り上がっています。いろいろ愛されているテックリードだと思います。

モバイルチーム・テックリードの自己紹介

山川：では、続いて古藤さん、お願いします。

古藤衣里子氏（以下、古藤）：モバイルチームでテックリードをやっています、古藤と申します。私は2021年の5月から弥生に参画していて、そこからテックリードをやっているので、テックリード歴は2年目になります。

connpassの自己紹介では「Misocaアプリ、弥生電子署名アプリをメインに担当しています。他のアプリの担当やPMの座を虎視眈々と狙っています」とconnpassに書いた目論見どおり、他のアプリにも手を伸ばし始めている状態です。「Misocaアプリ」には他のテックリードがいるので、そちらにお任せしている状況になっています。

モバイルアプリを5種類ぐらい出しているので、今はそれら全部に薄く広く関わっています。アプリによっては自分で実装しますし、他のアプリでは要件定義をやっています。ほかには、外注先や関係者との連携もやっていて、アプリによって工程はバラバラなので、一応、全工程をやったことがあります。

今は基本的に、他のチームとAPIの調整をしたり、作業をやってもらうために要件定義をしたり、他のチームに作業をお願いするために時間の調整をしたりしています。最近も三富さんとやり取りをしたところです。「弥生電子署名アプリ」について公式のnote記事があるので、よかったらご覧ください。今日はよろしくお願いします。

山川：よろしくお願いします。モバイルチームもいろいろなプロジェクトに関わることが多いので、そういった調整もやりつつ、アプリによっては実装もバリバリやったりと、本当にマルチに活躍されていると思っています。今日はよろしくお願いします。

インフラチーム・テックリードの自己紹介

山川：続いて峯岸さん、お願いします。

峯岸純也氏（以下、峯岸）：インフラチームでテックリードをしています、峯岸と申します。よろしくお願いします。

私の自己紹介ですが、2020年1月に弥生に転職しました。弥生が4社目で、弥生に来る前はJavaやC#のアプリケーション開発をやっていました。弥生ではインフラチームにアサインされていますが、インフラの実務経験ゼロの状態で入社して、試用期間が明けた途端にテックリードだと言われて、すごくびっくりした記憶があります。そういう前例はないと思っているので、本日の座談会では「未経験でもインフラをやれるんだよ」と、インフラに興味を持ってもらえるような話ができたらと思っています。

インフラチームなので、主にサーバーの管理をしています。仮想のサーバーやオンプレミスのサーバーを含めると、弥生にはだいたい1,000台ぐらいのマシンがあるのですが、最近はそれを徐々に棚卸しして減らす活動をやっています。インフラチーム内では今年から謎の「大臣職」というものが始まって、私は「断捨離大臣」に任命されました。

その後、AWS周辺の全体的なセキュリティ周りをやるようになって、そこでは「防衛大臣」に任命されました。最近はオンプレミスにあるサーバーを少しずつAWSの環境に持っていきましょうという活動を始め、そこで「移行大臣」という3つ目の大臣職に任命されました。

インフラチームにはこのように多岐にわたる仕事がいっぱいありますので、インフラに少しでも興味がある人がいたら、ぜひ弥生に来ていただけたらと思っています。本日はよろしくお願いします。

山川：よろしくお願いします。3大臣兼務とは本当にすごいですね。このように、今日はいろいろなタイプ、いろいろな業務をやっているテックリードが集まっています。これからさまざまなお話ができればと思っています。よろしくお願いします。

エンジニア時代に培われたレビュー観点

山川：事前にアンケートをいただいているので、その内容を織り交ぜながら、この後いろいろとトークできればと思っています。

みなさんがふだんやっている業務の中でけっこう共通して多かったのが、レビューや他部署調整だったと思います。レビュー観点はどうやって培ったのか、どういう観点でレビューを大事にしているのか。先ほど、レビューが多いと言っていた三富さん、そのあたりはどうですか？

三富：レビュー観点をどうやって培ったかというと……。エンジニア時代とてもとても厳しいレビューを散々受けました。すごいですよ。弥生にはレビュー記録表がありますが、100個ぐらい受けて今に至っています。そうやって鍛えられました。その結果、「こう言われた。じゃあ、俺も見る時はそこを見よう」という感じで培われたかな。あと、僕は根がツッコミなので、基本的にドキュメントを見てどこかツッコんでやろうと思って絶対にレビューしています。

山川：「何かしらあるはずだろう」みたいな（笑）。

三富：俺の目はごまかせまいと思いながらレビューしていますね。だから、観点は別に養っていない（笑）。

山川：そうですよね。過去にこういう失敗があったとか、エンジニアなら誰しもあると思います。そういう「やっちまったな」という経験を二度としないために蓄積しておくことも、大事なレビュー観点ですよね。ありがとうございます。奥村さんはどうですか？

奥村：三富さんに言われてしまいましたが、僕も失敗して怒られて成長してきました。反省を活かすというのがもちろんありますね。先ほども言ったように、最近は要件や業務知識をメインでやっているので、そのあたりを意識しています。コードを見ているというより、「僕だったらこう書く」ぐらいの感じでザーッと見て、「ん？」となったところがあったら指摘しています。

あと、最近は「テストコードでこういうテストをしています」と（コメントを）書いてくれるので、そこを見てちょっと違うと思ったことを指摘していますね。そんな感じです。

山川：やはり経験している分だけ、それを無駄にしないことが大事というところは、すごく共感できます。ありがとうございます。レビューはテストの一環でもあるし、レビューを通してエンジニアとコミュニケーションを取っていくというかたちにもなると思います。

具体的なアドバイスはそこそこにしておくことを意識している

山川：レビューに限らず、チームでメンバーとコミュニケーションを取る時に、気をつけていることを聞いてみたいと思います。

このあたり、古藤さんはどうですか？

古藤：コミュニケーションを取る時、事前に議事録を用意しておいたり、必要そうな情報のリンクをまとめて資料を提供しておいたりしています。私はしゃべっているとよくわからなくなってしまうので、このミーティングのゴールはここです、と先に提示した上で話していくことを意識していますね。

山川：段取りを大事に、みたいな感じですかね。

古藤：そうですね。

山川：空中戦だけだと、「あれ？　ここはどうだったっけ？」となりがちだから、そのあたりを注意して日々取り組んでいるんですね。

古藤：そうですね。

山川：ありがとうございます。峯岸さんはどうですか？

峯岸：自分は「もうちょっとこうしたほうがいいんじゃない？」「ああしたほうがいいんじゃない？」と技術面の話をついついしてしまうと思っていて。具体的なアドバイスも必要だと思うのですが、それをあまりやり過ぎてしまうと今度はメンバーが考えなくなってしまう事態になるので、それは怖いと思っています。なので、具体的なアドバイスはそこそこにしておいて、メンバーに考えてもらえるようなアドバイスの仕方をより意識しないとダメだと最近は思い始めています。

コミュニケーションでギャップを生まないようにツールを使用している

山川：周りのテックリードも頷いていましたが、共感できることやこのへん難しいよねと思うことなどがあれば。どうですか？

三富：レビュー指摘はその最たるものだと思っていて、「こう直してください」と書いてしまうと、そのとおりに直してしまうんですよね。そして、他を見なくなってしまう。ヒントだけを与えて「ここ」とは言わない。そういうことを僕も意識していますね。

山川：三富さんの場合、そういったヒントに対してメンバーのみんなからどのような質問を受けますか？

三富：「このレビュー指摘、わからないんですけど」って（笑）。

山川：ヒントは難しいですよね。レビューする対象の成果物を作ってくれたメンバーが、そのタスクに対してどのような段階にいるのか。バッチリできるぜという段階なのか、初めてトライしますという段階なのか。状況に応じていろいろなアプローチがあると思います。

コミュニケーション面では、奥村さんはどうですか？

奥村：先ほど、古藤さんも言っていましたが、話をしているだけだと……ということもあるので、僕もいろいろ準備します。うちのチームでは、実際の画面を見ながら話をしますし、「Figma」を使いながら絵で「こう」と話すこともあります。最近は「Miro」を入れました。何か話をしていて「やべっ」となったらMiroを開いて、「こうだよね」と適当に図を描きます。「こんなイメージで僕は思っています」と最近は共有しています。

山川：新しいプロダクトのUI/UXを考える時は、先ほど言っていたFigmaのようなUXのためのツールを使います。コミュニケーションを取る時も、どういったものを一緒に見ながらであれば誤解を与えないか、ギャップが生まれないかと注意しているということですね。ありがとうございます。

（次回へつづく）