マーティン・ファウラーのリーダーシップスタイル：ソフトウェアチームの思考を定義した実践者

主要事実：マーティン・ファウラー

• 役職： 2000年以降ThoughtWorksのチーフサイエンティスト（1999年に参加）
• 著述した主要な書籍： 『Refactoring: Improving the Design of Existing Code』（1999年）、『Patterns of Enterprise Application Architecture』（2002年）、『Microservices』（ジェームス・ルイスとの共著、2014年）
• プラットフォーム： martinfowler.com — 彼が開拓した「bliki」（ブログ+ウィキ）形式の権威的な技術エッセイで、1990年代後期から継続的に公開
• アジャイル宣言： 17人のオリジナル署名者の一人（スノーバード、ユタ州、2001年）。エクストリームプログラミング技術実践の基盤を提供
• 影響力モデル： 純粋に獲得したもの — 職位の権限なし、自社の経営なし、数千人のチーム管理なし

マーティン・ファウラーはFAANG企業を経営したことがありません。十億ドルを調達したり、数千人の組織を管理したりしたこともありません。1999年にThoughtWorksにチーフサイエンティストとして参加し、25年以上ずっとそこに留まり、継続的に執筆、コンサルティング、出版を行っています。

ファウラー流：権限なしの影響力モデル

リーダーシップモデルの一種で、継続的な信頼性は、フィールドがすでに非公式に行っている実践に名前を付け、それらの定義を数十年にわたって継続的に出版し、実践が理論を上回ったときに公開で立場を改める者によって獲得されます。権限は階層を通じてではなく、精度を通じて複合されます。身体的作業そのものが組織図になります。

それでも、今日働いているほぼすべてのソフトウェアチームは、彼が命名、定義、または普及させた用語、パターン、および実践を使用しています。リファクタリング（動作を変えずにコード構造を改善する実践）は、ファウラーが1999年に本を書く前は、開発者が静かに行っていた事柄でした。継続的インテグレーションは、彼がそれを標準化するのを助ける前の規律ある実践でした。ドメインモデル、アクティブレコード、データマッパーは、彼が2002年に『Patterns of Enterprise Application Architecture』で記録する前のアーキテクチャパターンでした。マイクロサービスは、彼とジェームス・ルイスが2014年にmartinfowler.comで概念を定義する記事を発表するまで、ほぼ存在しない言葉でした。その記事はアーキテクチャの波を引き起こし、業界がソフトウェアを構築する方法を変えました。

ファウラーの影響力は完全に職位の権限なしで生じます。彼は誰もに何かをさせることができません。彼は、世界中の開発者に向けて、特に長い時間軸で出版された明確な思考を通じてリーダーシップを行います。

それがどのように機能するのか、そしてそれが機能しない場所を理解することは、10人のチームを率いている場合でも、500人のエンジニアリング組織を率いている場合でも価値があります。

リーダーシップスタイルの分析

55対45の割合は、ファウラーがなぜ戦略家だけでなく実践者によって研究されるのかを説明しています。彼が構築する知的インフラストラクチャは実践に根ざしており、それは動作するコードから離れて作られたフレームワークより異なる種類の耐久性を与えます。

主要なリーダーシップ特性

マーティン・ファウラーを定義した3つの決定

1. 1999年に「Refactoring」を出版

1999年の前は、コード整理は非公式で、議論不可能な実践でした。開発者はそれを行いましたが、語彙、正当化、または体系的な技術がありませんでした。「古いコードをクリーニング」しているのを見た管理職は、それがなぜ価値があるのかを理解するためのフレームワークを持っていませんでした。

「Refactoring: Improving the Design of Existing Code」がそれを変えました。ファウラーはmartinfowler.comで進化する実践を文書化し続け、25年以上の間、実践者参照として機能しています。ファウラーの本は、ケント・ベックおよび他者と共著され、実践に名前を与え、正確なメカニクスで72の特定のリファクタリング技術を文書化しました。何をするか、それをする前に何を確認するか、結果がどのように見えるべきか。それはまたリファクタリングとテストの関係を表明しました — あなたがテストを持っているコードのみ安全にリファクタリングできます。テストが動作が変わっていないことを確認させるからです。

ビジネス上の結果は、チームが技術的負債について正直な会話を持つことができるようになったことでした。「コード整理の時間が必要」ではなく — 漠然とした、オプション的に聞こえるリクエスト — 「この機能を追加する前にこれらの特定のリファクタリングを適用する必要があります。現在の構造がその機能をテストするのが高くつき、変更するのが高くつくからです。」それは具体的な主張と防衛可能な正当化です。ファウラーは開発者にそれを作成する語彙を与えました。

2018年の第2版は、モダンなJavaScriptとオブジェクト指向パターンのカタログを更新し、ファウラーが1999年のスナップショットを保存するのではなく、20年近くも現在の実践に従事していることを実証しています。

今日のオペレーターにとって、「Refactoring」からの教訓は、コード特有ではありません。それは、あなたの組織が非公式に行う実践に名前を付けることの価値についてです。すべての組織は、機能していて、名前が付けられていない、文書化されていない、または意図的に教えられていない有効な動作があります。それらに名前を付けた瞬間、あなたはそれらについて議論し、改善し、新しい人をそれにオンボードできます。これはファウラーの方法があらゆるドメインに適用されます。

2. 2001年のアジャイル宣言への共同著述

2月2001年、17人の実践者がスノーバード（ユタ州）に集まり、アジャイル宣言を作成しました。当時の支配的な重量級プロセス方法論とは異なる方法でソフトウェアを構築することを説明する4値、12原則のドキュメント。ファウラーは17人の署名者の一人でした。

マニフェストに対するファウラーの貢献は、値の声明そのものではなかった — それは集合的でした — しかし技術実践の骨組みでした。彼はエクストリームプログラミング（XP）技術を実践して教えていました：テスト駆動開発、継続的インテグレーション、ペアプログラミング、小さなリリース。これらの実践は、マニフェストの値を運用可能にするものです。「計画に従うことより変化に対応する」は価値のように聞こえます。継続的インテグレーションとテスト駆動開発は、既存の機能を壊さずに変化に対応することを安全にする技術実践です。

アジャイル宣言は21世紀のソフトウェア開発方法論で最も影響力のあるドキュメントになりました。それはまた認定、プロセス、およびコンサルティングフレームワークの業界を生成し、ファウラーはその後、その元々の意図に根本的に反対であると批評するのに数年を費やしました。

2018年に、ファウラーは「Agile Fluency」を共著し、アジャイル語彙を使用するチームとアジャイルを価値のあるものにする基盤となる技術実践を持つチームを明確に区別します。彼の立場は、明白に述べられています：継続的インテグレーションとテスト駆動開発なしのScrum は演劇です。実践は重要です。式典は二次的です。ほとんどの組織は式典を実装し、実践をスキップします。これが、彼らが宣言の著者が期待した結果を得られない理由です。

3. 2014年にジェームス・ルイスとマイクロサービスを造語

3月2014年、ファウラーとジェームス・ルイスはmartinfowler.comで「Microservices」と題した記事を出版しました。記事は、ソフトウェアアーキテクチャスタイルを説明しました — API上で通信する小さく、独立してデプロイ可能なサービス — Netflix、Amazon、ThoughtWorksのチームが共通の名前なしで構築していました。

記事は名前を正しく、トレードオフをほぼ正しく、採択曲線を劇的に間違って取得しました。その後、業界全体を掃き尽くしたアーキテクチャの波が続きました。数千の企業がモノリシックアプリケーションをマイクロサービスエコシステムとして再構築しました。その並行して出現したDockerおよびKubernetesエコシステムは、以前よりもはるかに大規模でマイクロサービスを技術的に実用的にしました。

ファウラーとルイスはパターンを正確に説明しました。しかし、何かに名前を付けることは、それをどこにでも適用する需要を作成します。包括的には適切ではない場所を含む。AmazonのWerner Vogelsは、分散サービスモデルを内側から外側に構築していました — 運用的に、スケール規模で — ファウラーがそれを概念的に定義していた間、そしてVogelsの困難で獲得した本番制約と採択の業界のコンセプト概念とそれらのギャップ制約なしで説明される、マイクロサービスの失敗の多くを説明しています。マイクロサービスは実際のオーバーヘッドを追加します。サービス間のネットワークレイテンシ、分散トレーシング複雑性、サービスディスカバリーインフラストラクチャ、および1つの代わりに独立してデプロイされた数十のシステムを実行する運用上の負担。5人の技術者のチームの場合、まだスケールする必要がない製品を出荷し、そのオーバーヘッドは利益に比べて高価です。

ファウラーはその後、彼が「マイクロサービスプレミアム」と呼ぶことについて書きました — マイクロサービスがスケールと組織規模でのみ値を使用するという観察で、大多数のチームが持っていない場合。彼は「MonolithFirst」についても書き、モノリスで開始し、実際に安定している境界を理解したときに、マイクロサービスを抽出することをチームに主張しています。それは2014年の記事によって作成されたナレーティブの重要な改正であり、2014年の記事によって作成されたナレーティブの重要な改正であり、彼が自分の高プロファイル作業を反対する場合であっても、ファウラーの進路修正の意思を反映しています。

マーティン・ファウラーがあなたの役割で何をするか

CEO の場合、リファクタリングの原則は組織プロセスに適用されます。すべての組織がプロセス負債を蓄積します：もう存在しない問題のために設計された承認ワークフロー、前のスケールで理にかなった報告構造、2年前の買収以来更新されていない決定権。ファウラーの洞察は、あなたはテストなしで安全にリファクタリングすることはできないということです — 動作が意図しないで変わったかどうかをあなたに伝えるフィードバックメカニズム。大きな組織プロセスを再設計する前に、以下を質問してください：ここの同等のテストスイートは何ですか。変更が物事を改善したかどうか、または単に変更したかどうかをあなたに伝えるフィードバックメカニズムは何ですか。

COO の場合、アジャイル宣言の技術バックボーンレッスンは直接適用可能です。ほとんどの「Agile を実行する」組織は、スプリント式典 — 2週間スプリント、毎日スタンドアップ、回顧 — 実装しましたが、これらの式典を価値のあるものにする技術実践はありません。継続的インテグレーション、自動テスト、および小さな頻繁なリリースは、2週間の増分を計画してもリスクを蓄積することなく安全にすることができるものです。エンジニアリングチームがスプリントを実行しているが、デプロイに数週間かかり、テストカバレッジが低い場合、利点なしにアジャイルのオーバーヘッドを取得しています。修正はより多くのプロセスではありません。それは、ファウラーが2001年に説明した技術実践です。

プロダクトリーダーの場合、ファウラーのMonolithFirstアドバイスは、プロダクトアーキテクチャの決定に適用する価値があります。初日からスケール用に設計する圧力 — マイクロサービスアーキテクチャを構築する前に、あなたがそれを必要とするスケールを持つ前に — 正しい前に複雑なシステムを生成します。独立してスケールする必要があるモジュールがどれであるかは、製品を構築し、それが実際にどのように使用されるかを見るまで、あなたは知りません。Marty Caganは、製品側から平行した議論をしています。あなたがユーザーから学ぶまで、あなたはどのプロセスビルドするかは知りません。これが、なぜ時期尚早なアーキテクチャ投資と時期尚早なロードマップコミットメントが同じ基礎理由で失敗するかです。ファウラーのアドバイスです。機能する最もシンプルなものを構築し、本番環境から学び、独立したスケーリングが必要な部分を理解したときに抽出します。アーキテクチャは、実際に持っているシステムを反映する必要があります。3年間に持つことを望むシステムではなく。

営業またはマーケティングの場合、ファウラー流：影響力モデル — 継続的で質の高いアウトプットで長い時間軸にわたって信頼を獲得する — このシリーズの他のエグゼクティブのアプローチより、コンテンツマーケティングとソート思考に適用可能です。彼は、継続的に出版し、それらが間違っていることが判明したときに公開で立場を更新し、エンゲージメント上のアウトリーチに優先順位を付けることによってソフトウェアで最も権威的な声の1つを構築しました。ほとんどのコンテンツマーケティングプログラムはリーチに最適化します。ファウラーは信頼に最適化しました。違いは数年の中で複合化します。彼の観客は、ヘッドラインが彼らをクリックするのではなく、前のものから彼の判断を信頼するために新しい記事を読みます。

ファウラーのプレイブックをReworkがどのように運用するか

ファウラーの影響力は、パターンを記号化 — チームが暗黙的に実行された動作を取り、それらを命名された、教えられた、参照可能なアーティファクトに変えました。それは、ほとんどの運用チームが住んでいるギャップです。その機関知識は、取引がどのように実際に閉じるか、オンボーディングがどのように実際に機能するか、またはエスカレーションがどのように実際にルートするかは、少数のシニアの頭に住んでいて、他には住んでいません。Reworkの役割は、あなたの操作のパターンカタログでいることです。パイプラインステージ、ハンドオフチェックリスト、承認フロー、および機能横断的なプレイブックは、チームの「Patterns of Enterprise Application Architecture」になります — 部族ではなく、文書化、バージョン化、参照可能。そして、ファウラーの作品のように、パターンはオープンで進化します。ステージがもう適切でないとき、あなたはそれを名前変更し、エントリを修正し、全チームが変更を見ます。それは、パターン駆動オプ — 権限なしの影響力であり、作業が実際にどのように流れるかに適用されます。

注目すべき引用と教訓を経営方針以上に

martinfowler.comから：「どんなバカでもコンピュータが理解できるコードを書くことができます。良いプログラマーは人間が理解できるコードを書きます。」Jeff Deanは、ほとんどのエンジニアが触れたスケールのシステムを構築しましたが、ファウラーのポイントはそこでも適用されます。Googleのインフラストラクチャチームの制約は、生の賢さではなく、システムを継承する必要がある人々がそれを十分に理解できるかどうか、それを安全に拡張できるかどうかです。それは、1つの文で実践者学者の原則です。コードは人間の間のコミュニケーションであり、単にマシンへの指示ではありません。大規模ソフトウェア開発の支配的な制約は、コードが機能するかどうかではありません。6か月後に変更が必要な人々がそれを変更できるまでそれを理解できるかどうかです。ファウラーの体全体の仕事は、その原則の詳細な説明です。

リファクタリングについて、本の序文から：「リファクタリングは、既存のコード本体を構造化する規則的な技術で、その内部構造を変え、その外部動作を変えない。」正確性は重要です。「その外部動作を変えない」は、リファクタリングを安全にする制約です。彼のカタログ内のすべてのリファクタリング技術は、動作を保存しながら構造を改善するために設計されています。規則的さは、リファクタリングを再執筆から区別するものです — 言葉を緩く使用するチームが失われる区別。

彼はまた、2000年の「Is Design Dead?」で、デザインと変更の関係について書きました。「多くのことは、私たちが事前設計を正当化するために使用したものは、実践では間違っていることが証明されました。」これは、構築する前にデザインするために訓練されたエンジニアにとって聞こえるより難しい声明です。ファウラーの議論は、デザインは継続的であるべきであり、正面での前のあるべきではないということです — あなたが構築によって正しいデザインが何であるかを学んで、あなたがその学習を持つ前にデザインすることは、あなたが完全に理解していない問題に最適化されたシステムを生成します。

このスタイルが壊れるところ

権限なしの影響力は遅いです。ファウラーは25年間、彼の評判を構築しています。6か月の製品サイクルで彼の方法を借りることはできません。

パターンの命名は、良い実装を保証しません。マイクロサービスは最も明確な例です。厳格なアーキテクチャの説明はカーゴカルトになりました。チーム は、それを価値のあるものにする組織の成熟さ、ツールへの投資、またはスケールなしでパターンを採用しました。ファウラーは、コンセプトを正しく命名しましたが、命名は理解より速く採択を加速させました。それは知的インフラストラクチャー構築に固有のリスクです — あなたはそれを安全に使用するコンテキストを持たない人々に強力なツールを手渡しています。

そして、実践者学者の声は、実行圧力の下で企業に翻訳されません。ファウラーの執筆は意図的で、微妙で、長いです。それはデッドラインの下で決定を作成するのではなく、反射のために設計されています。1週間でアーキテクチャを選択し、1か月で出荷する必要があるリーダーは、彼の本が必要とするフルコンテクスト分析を通じて作業する贅沢を持ちません。彼のフレームワークは、操作上の安定性を思慮深く思考する余地があるリーダーに最も有用です — それは常にあなたが実際にいる状況ではありません。

---

エンジニアリング実践とカルチャーの関連読み取りについては、Werner Vogels Leadership Style、Linus Torvalds Leadership Style、Andy Grove Leadership Styleを参照してください。