言われたまま作るのではなく、仕組みから頭をひねって考える　弥生のテックリードが語る、やりがいとおもしろさ　

エンジニアとしての経験年数は人によってまちまち

山川和也氏（以下、山川）：チャットでもご質問いただき、本当にありがとうございます。さっそく、1個目を拾います。「何年くらいエンジニアとして経験してから、テックリードになりましたか？」というご質問をいただいています。

弥生に入る前からという人もいるかもしれませんが、みなさんはどうですか？峯岸さんはどうだろう？

峯岸純也氏（以下、峯岸）：弥生に入る前は、技術リーダーのような役職がない会社を転々としてきたので、ちょっと微妙ではありますが。ただ、リーダーのような肩書きの職は以前の会社でもあって、そういったポジションに就いたのは、だいたい私は10年目ぐらいだったんじゃないかなと思います。

山川：ありがとうございます。他のみなさんはどうだろう。では、古藤さんはどうですか？

古藤衣里子氏（以下、古藤）：私も前職からです。テックリードという技術のリーダーではなかったのですが、リーダーをやり始めたのはたぶん5年目でした。SESでお客さん先に出ていて、それが3人ぐらいのチームだったので、そこからリーダーとして他の人のレビューをしていました。環境的にリーダーになるのが私だった、という感じですね。

山川：ある程度経験して、「よっしゃ、じゃあこの現場に行ってこい」みたいな感じで（笑）。

古藤：そんな感じです（笑）。

山川：私も前職で経験しました。奥村さんはどうですか？

奥村和彦氏（以下、奥村）：僕もずっとエンジニアをやっています。小さなプロジェクトが多かったので、年功序列的なところや経験値もありますが、結果的にけっこう若い時からリーダーのようなことをやらされていた感じですね。実際にテックリードに任命されたのは弥生へ入ってからですが、それに近いことはやっていたのであまり違いは意識せずにやれています。

山川：エンジニアを経験する中で後輩が入ってきて、その後輩の技術的なフォローをいろいろと積み重ねていった、ということですかね。

奥村：そうですね。

山川：三富さんもずっと頷いていますね。

三富学氏（以下、三富）：僕は弥生で2社目ですが、前職では入社後5年ぐらいで気づいたら、大きなチームの中のサブリーダーみたいになっていました。その後、その会社を辞めてフリーランスでやっていたのですが、その時はさすがにリーダーはやらずにいました。そして、弥生に入って3年ぐらいでテックリードですかね。「何年経験したから」というよりは、みなさんと一緒で気がついたらこの立ち位置にいた、そんな感じですね。

山川：ありがとうございます。そういったかたちで、エンジニアとしての経験年数は3年や5年などけっこうさまざまでしょう。弥生は中途入社も多いので、峯岸さん、古藤さん、奥村さんのようにいきなりテックリードということもあり、まちまちという感じですよね。

テックリードに向いている人の特徴

山川：ずっと手を動かしてゴリゴリとアウトプットするパスもあれば、チームをリードしていくパスもあります。今日、みなさんにはリードする役回りで来てもらいましたが、自分はこういうことに気をつけている、テックリードをする上でこういう人が向いている、テックリードにはこんな特徴がある、などを紹介してもらえますか？

古藤さんは何が思い浮かびますか？

古藤：モバイルチームには技術に強い人が多いんですよ。自分でセミナーに行ったり、いろいろやったりする人が多くて、私が技術でリードしているわけではないんですね。どのような人が向いているかと言われたら、自分で調べられる人ですね。

テックリードは課題ができたらとりあえず突き進んでいく役割です。割り込まれたり、問題が起きたらとりあえず呼ばれたりするので、とりあえずその問題に突っ込んでいける人が向いていると思っています。

山川：ありがとうございます。古藤さんが言ってくれたように、テックリードにはさまざまな特徴がある人がいます。一言で「テックリード」と言葉にしてもそれぞれ得意分野も違うので、ぜんぜんそれでいいと思います。あと1人ぐらい聞いてみようかな。じゃあ、峯岸さんいきましょうか。

峯岸：いろいろなメンバーの相談に乗ったり、案件を聞いたり、レビューしたり、そういった役回りがどうしても増えてくると思うので、私は広く浅く柔軟にやれる人が向いていると思っています。

先ほどの前半パートで、テックリードはエンジニアをまとめるというお話が山川さんからありましたが、円の中にはそのエンジニアも入っていて、時には自分が手を動かす場面もあるので、1つのことに集中したいというより、広く浅く、時には深くも入れるような柔軟さがないとなかなか向いているとは言えないと、個人的には思います。

山川：リーディングしていく、みんなをまとめて前に進める、そういう特徴が大事だよねということですかね。

峯岸：はい。

難題をどう実現するか？　頭をひねるのがテックリードの仕事のおもしろさ

山川：では、他にも事前に質問をけっこうもらっているので、それも織り交ぜながらお話ししていきたいと思います。

前半では、テックリードはこんなことをやっていますとか、ふだん意識してることとか、どのような人が向いているかなどのお話をしました。

次は、テックリードとしてやりがいを感じていることや、テックリードはこれがおもしろいということを、みなさんに紹介してもらえればと思います。では、三富さんはどうですか？　なんでいつも振ったら笑うんですか（笑）。

三富：いつも答えにくい質問が来るなと思って（笑）。真面目な回答をすると、自分でいろいろな仕組みを考えられるところですかね。あまり良くないですが、エンジニアをやっていると、言われたように作ることがわりと多いんです。テックリードの立ち位置になると、どういう仕組みで作るのか、どういうつながりでやっていくのかから考えなければいけないので、それが難しくもあり、やりがいでもあるという感じですかね。

あとは、何回もレビューの話をしますが、レビューしていると本当に文章力がつきますよ。メチャクチャつくと思います。人のものを指摘するので、自分も文章をまともに書かなければいけません。今だったら国語の先生になれる感じです。

山川：ありがとうございます。すごく共感できるところがありました。これはテックリードに限らないと思うのですが、自ら手を動かした量はけっこう大事だと思います。コーディングもそうだし、レビューもそうだし、それを文章に書くということもそうだし、そういうことを繰り返していくことが大事。

おもしろいといえばおもしろいですよね。新しい機能を作らなきゃいけない、新しいアプリを作らなきゃいけないなど、難題が来た時に頭をひねってこれをどう実現しようかと考えることがおもしろみの1つですね。ありがとうございます。奥村さんはどうですか？

奥村：テックリードだからというわけではありませんが、決定権や裁量権をある程度与えられているので、「こうしたい」ということがいろいろと通りやすいです。

それに関係があるかどうかはわかりませんが、業務知識をみんなに覚えてもらいたいとPMに話した時に、「勉強会をしたら？」と言われて、じゃあやってみようとなったんです。週2回勉強会やるから来てねと言ったら、テックリードが言っているから行かなきゃと来てくれていて、一応今も継続してできています。

みんな忙しいし、面倒くさいと思っている人もたぶんいると思いますが……ちょっと偉そうな感じになってしまいましたが、決めたことに対して責任がありながらも、周りに指示ができるということですね。

山川：自分がこのチームで、こういった取り組みをやりたいと考えたら、まず「やろうぜ」と言って、最初のきっかけを与えてあげる。最初は確かにそう（面倒だと）思う人もいると思いますが、やっていくうちに少しでも共感してくれるとうれしいなと思って、テックリードのみんなはそういう取り組みをやってくれていると思っています。ありがとうございます。

メンバーから「自分の提案のほうが技術的にいい」と言われたらどうするか

山川：チャットでもすごくよくわかる質問をいただきました。「メンバークラスのエンジニアから技術的に自分の提案のほうがいいと言われた時はどのように返答していますか？」

ここもぜひ聞いてみたいと思っています。峯岸さんはどうですか？

峯岸：専門知識が深い人は本当に深いので、聞いた上で技術の提案がすばらしければ、どんどんやっていこうと後押しする方向に行くように私は意識しています。

山川：メンバーから提案があった時、峯岸さんは「いいね」とか「やっちゃいなよ」とけっこう後押ししてあげるタイプだと思っています。「こう考えている」という意見は極力大事にしてあげたいというのが峯岸さんの考え方なんですね。

峯岸：そうですね。

山川：すごくわかります。古藤さんはどうですか？

古藤：モバイルチームはアジャイル的な進め方をしているので、合意してから動くことが多いです。後々のタイミングでひっくり返したり、自分の提案のほうがいいということはあまりありません。合議して進めているので、そのタイミングで出てきた提案はチームで話して、「いいね」となったらそのとおりに進みます。

山川：すごく良いチームですよね。「よし、これでいこう」とみんなで最初に方針を決めて、それに納得して前を向いてくれるというのは、すごく良いことだと思っています。

今の質問に近しい弥生ならではのことで、起こしたくないけど起きてしまうケース。要求や要件を決めて、「これでいくよね」と言って、エンジニアもがんばって作ったけど、後半になって、「実は、これはこうしたほうがいいんじゃね？」とか「こうしたい」と言われてしまう時はあるじゃないですか。

プロダクトのことを考えれば、確かに「そうしたほうがいいよね」ということもあるし、「これでいく」と、作ってくれたエンジニアにどう伝えようか、という時もあると思いますが、そういったユースケースで意識していることや、工夫していることがあったらぜひ聞いてみたいと思います。どうですか？

三富：難しいですね。何回か経験がありますが、僕はまずみんなに謝りますね。こちらのほうが良くなると言われました、と。今までやってきた作業は無に帰しますが、がんばろうと。最後は雰囲気で乗り越えますが、苦しいは苦しいですよね。

山川：そうですよね。苦しいは苦しいですよね。その瞬間はすごくわかります。

当然、私にもその経験はあります。私も三富さんに近くて、まず「作ってくれたのにごめん」と言います。そこはけっこう大事だと思っています。でも、そのプロジェクトや要件で一番達成したいことは何かという点を伝えたり、「やりたいことを実現するために、こういうロジックで必要だから、なんとかがんばってやっていかない？」などと伝えたりしているかな。スケジュールの話もあるので全部が全部そういうパターンではいかない時もあるとは思いますが。

（次回へつづく）