テックリードのガイドライン1 — ディープダイブ

私たちはしばしば、現場の声に耳を傾けるべきだと言います。なぜなら、彼らこそが実際に物事を進めている人たちだからです。開発においても同様です。

しかし、Tech Leadになるには、コード自体を理解することだけではなく、プロジェクト全体を把握することが非常に重要です。以下に、私が非常に重要だと思う点をいくつか挙げます。

前言

1年前に「Tech Leadになるための感想」を書きました。この1年間で学んだ多くのことについて、最近「会社でサーバーを立てるのは想像以上に簡単ではない」という記事も発表しました。この文章は、Tech Leadとして必要なことを整理したメモとして考えています。これが、Tech Leadとして何をすべきか悩んでいる読者の助けになれば幸いです。

プロジェクトで使用されているフレームワークや技術

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

• フロントエンドフレームワークを使用しているか、それらの新しいバージョンや機能は何か
• SSRに対応しているか
• APIはどのように接続されているか、GraphQL、RESTful API、またはgRPCか？
• バックエンドで使用されているプログラミング言語とアーキテクチャについての基本的な理解

通常、Tech Leadに指名されるソフトウェアエンジニアは、任務を順調に完了でき、プロジェクトの問題を解決し、チームの進捗を把握できることを示しています。少なくともプログラミングに関して大きな問題はないということです。プロジェクトにおいてIC（Individual Contributor）として貢献するのであれば、この部分については特に問題ありません。

バックエンドのプログラミング言語とアーキテクチャを理解する理由は、デザインの他に、フロントエンドと密接に連携するのがAPIの接続だからです。相手の現在のアーキテクチャで発生している問題を理解することで、バックエンドとより適切な解決策を話し合うことができ、相手の問題解決を助けることができるかもしれません。

プロジェクトにおける重要なビジネスロジック

金融サービスにおいて、重要な業務ロジックには、どのように決済を行うか、タイミングはどうか、ユーザーの身元を確認する方法、個人情報をどのように保存するかなどがあります。フロントエンドにとって、これらは通常バックエンドが処理すべきことですが、背後のメカニズムを理解することは、将来の要件に備えるために重要です。

大きな金額を処理する際に、BigIntを使ってオーバーフローを避けるか、通貨変換で浮動小数点問題に十分注意しているか、小数点の繰り上げはフロントエンドで処理するのかバックエンドで処理するのか、時間処理に対して厳格な要件があるか（標準時間で、ユーザーが自由に調整できないなど）など、これらは金融サービスプロジェクトにおいて非常に重要な要素です。

ビジネスロジックを理解する際には、通常開発者もこの分野の知識を理解する必要があります。特に金融サービスでは、注意すべき法律についても少し知っておく必要があります。

プロジェクトのデプロイ方法

プロジェクトの開発自体とは直接関係ありませんが、コードがどのようにデプロイされるかを知ることは、さまざまなプロセス改善を推進する上で非常に役立ちます。

現在のプロジェクトがDockerを使用していると仮定すると、まずプロジェクトをイメージとしてパッケージし、次にそれを会社のプライベートDocker Hubにアップロードし、デプロイするマシンがそれをプルして実行します。

ここには多くの注意すべき点があります。イメージは誰がアップロードを実行するのか、トークンはどこで設定されるのか、デプロイするマシンのACLはDocker Hubにアクセスできるのか、トークンはどのように渡されるのか。これらはフロントエンドの守備範囲を大きく超えていますが、理解が深まるほど、実現したいことを推進できるようになります。たとえば、新しいマシンを導入してSSRを行いたい場合、以前からデプロイプロセスを知っていれば、スクリプトを書く方法や、どの部分で問題が発生するかを迅速に把握し、事前に対処できます。

さらに、デプロイ時間を観察してプロセスを改善することもできます。たとえば、毎回イメージ内で依存パッケージを再インストールする必要があり、デプロイ時間が長くなっている場合、共通部分を別にパッケージ化してインストール時間を短縮することで、全体のデプロイ時間を短縮できます。

リクエストがサーバーに届くまでの全プロセス

• ロードバランサーを通過するか
• 本番環境にいくつのマシンがあり、それぞれのスペックはどうか
• マシンはどの地域にデプロイされているか
• 静的ファイルはマシンに保存されているのか、それともCDNにあるのか
• リバースプロキシがあるか（nginxまたはenvoy）
  • 特殊なリライト/リダイレクトルールを理解する必要があるか
• サーバーはどのポートで開かれているか

歴史を理解する

時々、乱雑なコードを見て心の中で叫びたくなります。「なぜこんな書き方をするのか？WHY？？？」と。「私はクソコードだ」と思わざるを得ないものを除けば、最近は背後の歴史を理解することを学んでいます。時にはスケジュールが非常に厳しいから、時にはビジネス要件があまりにも奇妙で現行のアーキテクチャと合わないから、時にはアーキテクチャの進化に伴うトレードオフのためです。一度歴史の観点から考えると、時には逆に感心することもあります。

各方面のニーズを理解する

プロジェクトで衝突が発生することがありますが、それはコミュニケーションの不調に加え、多くの場合、お互いに気にしていることがわからないことが原因です。たとえば、あるプロジェクトのスケジュールが意味もなく厳しくなり、開発者たちはスケジュールのプレッシャーで大変な思いをしていますが、心の中では単にPMが一方的に開発時間を短縮したいだけだと思っています。しかし、実際にはこのプロジェクトが新しい法律制度に関連しており、新しい法律が施行される前にリリースを完了しなければならないからです。さもなければ、違法行為で罰金を科せられる可能性が高いのです。

こういったことは、必ずしも意図的に隠されているわけではなく、情報が全社に知られていなかったり、途中で伝達が忘れられたりすることがあります。

この場合、非常に重要な点は、相手の問題を問題として信じることです。開発者の目にはその問題が愚かに見えるかもしれませんし、聞こえが不合理に思えるかもしれませんが、「皆がこのプロジェクトをより良くしたいと思っている」という観点から出発すれば、得られる結果は全く異なるものになるでしょう。（本当にトラブルを起こそうとしているのでなければ）

もう一つは、問題があれば提起することです。皆が問題を多く質問することが大丈夫だと感じていますし、愚かな質問をしても問題ありませんが、多くのソフトウェアエンジニアはプライドが高く、実際に質問してしまうと逆に恥をかくことを恐れています。そのため、心の中で怒りが沸騰していても、静かに機能を完成させることが多いです。この時、一つの質問やもう少し確認することで危機を解消できることが多いのです（もしそれができなければ……、どうすればいいかはわかっているはずです）。

総括

これらの事柄が重要である理由は、単にあなたがTech Leadだから理解すべきというだけではありません。これらの事柄は、新しいプロジェクトや新しい要件、またはチーム内でのボトルネックに直面したときに、既存のリソースを効果的に活用して問題を解決するのに役立ちます。

新しい要件や改善に対する開発の速度と品質は、既存のアーキテクチャの理解に大きく依存します。たとえば、画像をアップロードしてサムネイルを生成するという新しい要件があった場合、ある機能の中にすでに類似のモジュールが存在していれば、既存の機能を修正するだけで済みます。しかし、Tech Leadがこのことを把握していなければ、結果的により多くの時間とリソースを費やすことになりかねません。

チームもTech Leadとさまざまな技術的決定や特定の要件の実装についてよく話し合います。上記に述べた事柄は、あなたが見解を述べるための良い材料です。アーキテクチャを深く理解し、開発者が直面する問題を理解し、お互いのニーズを明確にすることで、新しい要件や解決策が空想に終わることはありません。

後記

1年前の「Tech Leadになるための感想」の中で、私はすでに給与の増加にそれほどこだわらなくなっていることに気付きました（しかし、まだ気にします）。一方で、現在の役職や仕事のスタイル、内容に満足しているからです。また、誰もが自分の仕事のスタイルを持っていることを理解し、自分の役割をしっかり果たすことが最も重要だと思います。

私のプライベートなTwitterでは、時々愚痴をこぼすこともありますが、それでもチームの生産性をできるだけ向上させ、既存の開発プロセスやプロジェクトを改善し続けたいと思っています。