技術リーダーとしてのレベルアップ (Japanese Edition)

章8 技術的課題への対応

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

本書ではこれまで、技術リーダーシップにおける人的側面を重点的に扱ってきた。それには十分な理由がある。信頼、方向性の統一、そしてコラボレーションこそがチームを効果的にする要素だからだ。

しかしテックリードとして、チームが日々取り組む技術基盤にも影響力が及ぶ。アーキテクチャ、デプロイ、テスト、インシデント対応、技術的負債——これらもリーダーシップの課題だ。システムをどう構築し進化させるかは、デリバリースピード、製品品質、チームの士気に直接影響する。

この章では、そうした重要な技術的課題について述べる。

まずアーキテクチャから始める。ゼロから構築する場合も既存システムを進化させる場合も、設計と改善作業を通じてチームを導く方法だ。次に、統合、デプロイ、テストを含む現代的なソフトウェアデリバリーの仕組みに深く入り、それらをよりスムーズで信頼性の高いものにする方法を掘り下げる。最後に、技術的負債の管理、インシデント対応、ドキュメント化の方法とタイミングの決定といった、一般的でありながら見過ごされがちな課題に取り組む。

本書の前半で強力なチーム構築に役立ったなら、この章ではそのチームが強力なシステムを構築できる体制をセットする手助けとなるだろう。

アーキテクチャ戦略と実装

アーキテクチャ上の決定は、チームが構築し、 が拡張し、維持するあらゆるものに影響を与える。技術リーダーとして、現在のアーキテクチャの姿を積極的に導き、時間の経過とともにどのように成長・進化させるかを示す必要がある。

このセクションでは、ゼロから全く新しいアーキテクチャを定義することから、既存のアーキテクチャを改善・進化させることまで、両極端をカバーする。

また、明確な図解を通じてアーキテクチャの可視性と実行可能性を高める方法、機能横断要件を定義・管理する方法、革新と安定性のトレードオフをどう扱うかについても学ぶ。

ゼロからシステムアーキテクチャを定義する

ほとんどのエンジニアは既存システムで働くが、 グリーンフィールドプロジェクトや新製品、内部ツールなど、アーキテクチャを一から定義できる瞬間もある。これは初日から意図的にシステムを形作り、正しい軌道に乗せる稀な機会だ。

コードを書く前に、チームで一歩引いて根本的な問いに答えよう。まず問題から始める：何を解決するのか、なぜそれが重要なのか？この議論にはプロダクトやビジネスのパートナーも参加させるべきだ。早い段階で明確化することで、正しいものを設計していることを保証できる。また、明確に定義された問題解決に集中するため、過剰設計を防ぐ助けにもなる。

問題が明確になったら、技術的・組織的・ビジネス関連の制約を検証する。使用するプログラミング言語、採用するクラウドプロバイダー、内部プラットフォーム基準の遵守可否などの決定事項が含まれる。トレードオフを可視化せよ。スピードを最適化しているなら、後回しにする要素を正直に示し、後日再検討する計画を立てること。

こうしたコンテキストを踏まえ、高レベルの技術的構想を形作り始める。成長過程におけるシステムの姿に関する初期仮説だ。精密である必要はない。主要構成要素とそのやり取りの大まかなスケッチがあれば、チームを一致させ議論を促すのに十分だ。以下のような質問が指針となる：

• 必要な中核的な構成要素やサービスは何か？

• それらの構成要素はどのようにコミュニケーション・統合すべきか？ ...