Tech Leadの心得 1 — 現場を深く知る

現場のメンバーの声に耳を傾けるべきだとよく言われる。なぜなら、実際に手を動かしているのは彼らであり、開発においてもそれは同じだからだ。

しかし、Tech Leadになるにあたっては、コードそのものを理解するだけでなく、プロジェクト全体を網羅的に把握していることがより重要になる。以下に、僕が重要だと思うポイントをいくつか挙げていく。

前言

1年前に「成為 Tech Lead 的一些感想」という記事を書いた。この1年の中で多くのことを学び、最近も「在公司中架設 Server 沒有我想像中的那麼簡單」という記事を投稿した。この記事は、僕がTech Leadとして必要だと考える要素を一度整理し、備忘録としてまとめたものだ。Tech Leadとして何をすべきか悩んでいる読者の助けにもなれば嬉しい。

專案裡使用了哪些框架、技術

フロントエンドを例に挙げると：

• フロントエンドフレームワークを使用しているか、その新しいバージョンや機能・特性は何か
• SSRに対応しているか
• APIはどのように連携されているか（GraphQL、RESTful API、それともgRPCか？）
• バックエンドで使用されているプログラミング言語やアーキテクチャについて、大まかに把握しているか

通常、Tech Leadに任命されるソフトウェアエンジニアは、任されたタスクを順調に完了でき、プロジェクトの課題解決を支援でき、チームの進捗を把握できる人物であり、少なくともコーディングの面で大きな問題はないはずだ。プロジェクトにおいてIC（Individual Contributor）として貢献してきたのであれば、この部分には大きな問題はないだろう。

なぜバックエンドの言語やアーキテクチャを理解する必要があるのかというと、フロントエンドと密接に連携するのはデザイン以外ではAPI連携だからだ。バックエンドが現在のアーキテクチャで抱えている課題を理解していれば、より適切なソリューションを一緒に議論できたり、相手の課題解決を手助けできたりするかもしれない。

專案中重要的業務邏輯有哪些

金融サービスにおいては、決済・引き落としをどのように実行するか、そのタイミングはいつか、ユーザーの本人確認をどう行うか、個人情報をどのように保存すべきかなどが重要なビジネスロジックに含まれる。フロントエンドにとってはバックエンドが処理すべき領域と思われがちだが、その背後にある仕組みを理解しておくことは、将来の要件に備えるためでもある。

大きな金額を表示する際にオーバーフローを防ぐためBigIntを使用しているか、通貨換算時に浮動小数点数の問題に十分注意しているか、端数処理はフロントエンドとバックエンドのどちらで行うか、時間の扱いに対する厳格な要件（標準時である必要があり、ユーザーが勝手に変更できないなど）があるかなど、これらは金融サービスに関わるプロジェクトにおいて極めて重要な要素だ。

ビジネスロジックを理解すると同時に、開発者にはその分野のドメイン知識が求められることが多く、金融サービスであれば留意すべき関連法規についても多少は把握しておく必要がある。

專案如何被部署

プロジェクトの開発そのものには直接関係がないように思えるかもしれないが、コードがどのようにデプロイされているかを知ることは、様々なプロセス改善を推進する上で大いに役立つ。

例えば、現在のプロジェクトでDockerを使用しているとしよう。まずプロジェクトをイメージとしてビルドし、次に社内のプライベートなDockerレジストリ（Docker Hubなど）にアップロードされ、デプロイ先のマシンがそれをpullして実行する。

ここには注目すべきポイントがたくさんある。イメージのアップロードは誰が実行しているのか、トークンはどこで設定されているのか、デプロイマシンのACLでDockerレジストリと通信できるか、トークンはどのように渡されているかなどだ。これらはフロントエンドの守備範囲を大きく超えているが、理解が深まれば深まるほど、自分が推進したいことを実現しやすくなる。例えば、新しいサーバーを立ててSSRを導入したい場合、あらかじめデプロイフローを知っていれば、スクリプトをどう書けばよいかがすぐに分かり、どこでつまずきそうかを事前に予測して対処できる。

それだけでなく、デプロイ時間を観察してプロセスを改善することもできる。例えば、イメージのビルドごとに依存パッケージを再インストールしていてデプロイが長引いている場合、共通部分を切り出してベースイメージとしてビルドしておくことでインストール時間を短縮し、全体のデプロイ時間を高速化できる。

請求發出到伺服器接收的整個流程

• ロードバランサーを経由するか
• 本番環境には何台のマシンがあり、それぞれのスペックはどうなっているか
• マシンはどのリージョンにデプロイされているか
• 静的ファイルはマシン内にあるのか、それともCDNに置かれているか
• リバースプロキシ（NginxやEnvoy）はあるか
  • 把握しておくべき特殊なrewrite/redirectルールはあるか
• サーバーはどのポートで起動しているか

了解歷史

ひどいコードを見たとき、心の声が「なんでこんな書き方してるんだ？ WHY???」と叫び出すことがある。「開き直って雑に書いた」系のコードは別として、最近は僕もその背後にある歴史を理解しようと努めている。スケジュールがあまりにもタイトだったり、ビジネス要件があまりに特殊で既存のアーキテクチャに合わなかったり、アーキテクチャの進化の過程でのトレードオフだったりすることもある。歴史的な視点に立って考えてみると、逆に感心させられることさえあるのだ。

了解各方需求

プロジェクトで衝突が起きるとき、コミュニケーション不全だけでなく、お互いが何を気にしているかを知らないことが原因であることが多い。例えば、あるプロジェクトのスケジュールが妙に厳しく設定され、開発者が納期に追われてプレッシャーを感じ、「PMが一方的に開発期間を縮めたがっているだけだ」と不満を抱くことがある。だが実際には、そのプロジェクトは新しい法規制に関わっており、法改正の施行前にリリースしなければ法律違反で罰金を科される可能性があったりするのだ。

こういった事情は、意図的に隠されているわけではなく、情報が部門全体に共有されていなかったり、途中で伝達が漏れていたりするだけの場合もある。

このとき重要だと僕が思うのは、「相手の抱える問題は、れっきとした問題である」と信じることだ。開発者の目線ではくだらない問題に見えたり、不合理に聞こえたりするかもしれない。しかし、「誰もがこのプロジェクトをより良くしたいと思っている」という前提に立てば、導き出される結果も全く違ったものになるはずだ（よほど悪意を持って嫌がらせをしている場合を除いて）。

もう一つのポイントは、疑問があれば声を上げることだ。「いくらでも質問していい、愚問でも構わない」と誰もが言ってはいるものの、ソフトウェアエンジニアの多くはプライドが高く、実際に質問して論破されたり恥をかいたりするのを恐れて、内心怒りに震えながらも黙々と機能を実装してしまいがちだ。しかし、そうした場面では、たったひとつの質問や少しの確認があるだけで危機を回避できることが多い（もしそれでもダメなら……どうすべきかは分かっているはずだ）。

總結

これらのことが重要である理由は、単にTech Leadだから知っておくべきという話にとどまらない。新しいプロジェクトや要件に直面したとき、あるいはチーム内に行き詰まりが生じたときに、既存のリソースをいかに効果的に活用して問題を解決できるかに役立つからだ。

新しい要件や改善において、開発のスピードと品質は既存アーキテクチャへの理解度に大きく左右される。例えば「画像をアップロードしてサムネイルを生成する」という新要件が出たとき、別の機能にすでに似たモジュールが存在していて既存機能を流用・改修するだけで済むにもかかわらず、Tech Leadがそれを把握していないばかりに、余計な時間とリソースを費やしてしまうことになりかねない。

チームメンバーはTech Leadと技術的な意思決定（Technical Decisions）や特定要件の実装方針について頻繁に議論することになるが、前述の事項はすべて、説得力のある見解を提示するための優れた材料となる。アーキテクチャの深層に入り込み、開発者が直面している困難を理解し、お互いの要求を明確にしてこそ、新たな要件や解決策が机上の空論にならずに済むのだ。

後記

1年前の「成為 Tech Lead 的一些感想」という記事の時点と比べて、僕自身、昇給があるかどうかをそこまで気にしなくなったことに気づいた（まあ、それでも気にはなるけれど）。それは現在の役職や働き方、仕事内容に満足しているからというのもあるし、人それぞれ自分なりのワークスタイルがあり、自分の本分を全うしてやましさがなければそれで十分だと実感したからでもある。

裏ではTwitterで愚痴を数行こぼしてしまうこともあるかもしれないが、それでもチームの生産性をできる限り高め、既存の開発プロセスやプロジェクトを改善し続けていきたいと思っている。