スプリントごとに同じアーキテクチャに関する議論を何度も繰り返したのはなぜですか? (Same Architecture Debate Every Sprint)

スプリントごとに同じアーキテクチャに関する議論を何度も繰り返したのはなぜですか?

私はイスタンブールにある急成長中のテクノロジー系スタートアップ企業で働いていました。ある昼休み、私はチームの上級開発者と公園に散歩に行きました。彼は、今後リリースされるモバイル アプリケーションの機能、追加される新しいモジュール、投資家向けのプレゼンテーションについて興奮しながら私に話してくれました。

私はそれを聞いて、次のような単純な質問をしました。「それで、アーキテクチャ図はどこにあるのですか? これらの決定をどこに文書化しますか?」

彼は笑顔で私を見つめました。計画はありませんでした。システムの「ソフトウェア アーキテクチャ ハンドブック」に目を通しましたが、簡単なメモ紙すらありませんでした。マネージャーが夜に枕に頭を置き、朝起きて新しいアイデアを思いついた様子が、その日の私たちの建築を決定づけました。顧客の一瞬のミスにより、スプリント全体がゴミ箱に捨てられました。プロジェクトは進んでいない、ただ風が吹いているだけだった。 (実際のところ、AI が人気だったため、一夜にしてそのプロジェクトに AI を統合したと後から聞いても、私は驚きませんでした。)

その日公園を歩いていると、ソフトウェア プロジェクトを沈没させるのは「悪いコード」ではないことに気づきました。プロジェクトを沈めるもの。それは建築知識の蒸発でした。私たちは決断を下しても、なぜそれを決断したか忘れてしまい、3か月後に同じ決断について再び話し合うことになります。これは私が技術リーダーとして宣戦布告した最初の戦線でした。

伝統的企業の「部族知」の頑固さ

この混乱を目の当たりにしてから、面接での私の最初の質問は「プロジェクト管理プロセスは何ですか?技術的な意思決定はどのように行っていますか?」というものでした。

数年後、私は伝統的な製造会社の研究開発部門との面接を受けました。私の目の前のマネージャーは、私がスーツを着ていなかったため、私のプロ意識を疑問視し始めました。 （ただし、私は以前その会社の重要な仕事を外部から行っていたのですが、彼はそのことを知りませんでした。）私は彼に、Jira、アジャイル プロセス、技術文書を使用しているかどうかを尋ねました。私が得た答えは、業界の厳しい現実でした。 「試してみましたが、自分たちには合わなかった。会議では誰が何をするかをノートに書いて進めています。」

たとえ採用が承認されたとしても、私はその瞬間にその内定を拒否しました。プロジェクトのアーキテクチャと運命を、誰かの会議録のかすかなインクに委ねることはできないからです。

決定戦と作戦上の混乱

その後、私は大規模な物流変革プロジェクトに携わりました。私がシステムに入ったとき、誰が何をしているのかを理解するだけで丸 1 か月かかりました。プロジェクト管理も技術的な記憶もゼロでした。

私はすぐに袖をまくり上げました。アジャイル ビジネス モデルを導入し、2 週間のスプリントを確立し、Jira を統合し、毎日のスタンドアップを導入しました。すべてがうまくいきました。しかし、民間部門には現実があります。システムに透明性と制度的記憶をもたらすと、「部族の知識」（自分たちだけが知っている秘密）から権力を得る人々は脅威を感じます。

モビングが始まりました。彼らは私からコントロールを奪おうとしました。当時、私が作成したADR（建築決定記録）のプリントアウトは見向きもされませんでした。スプリントの後、マネージャーが来て、「なぜこのデータベースをこのように変更したのかわかりません!」と言いました。彼は言い​​ました。すべてが書かれていましたが、彼らはそれを読みませんでした。私たちの文書は「意思決定文書劇場」と化していました。

そのとき私は、1 つのツール (Jira、ADR) だけを使用するだけでは十分ではないことに気づきました。そのツールを企業のターゲット (OKR) 静脈に注入する必要があります。

プロジェクトの混乱を終わらせるシステム: ADR (アーキテクチャ決定記録)現在、私はリード開発者 (6 ～ 7 人のチーム) として管理しているグローバル e コマース プラットフォーム インフラストラクチャでこのシステムを完璧に運用しています。私がプロジェクトを開始したとき、まだ混乱がありました。 GitLab では課題がオープンされていましたが、「なぜこれを行うのか?」質問に対する答えはありませんでした。

私はチームにアジャイルの精神を浸透させ、最も重要なこととして、Michael Nygard の ADR (アーキテクチャ決定記録) 原則を年次四半期 (第 1 四半期、第 2 四半期、第 3 四半期、第 4 四半期) の目標に直接マッピングしました。

では、ADR とは何ですか?また、なぜ ADR がすべてのエンジニアの命を救うのでしょうか? ADR は、アーキテクチャ上の決定内容だけでなく、それが行われた理由や受け入れられたトレードオフもコードのすぐ隣に保存される不変の記録です。

私たちは今決断を下すとき、このシンプルだが非常に効果的なテンプレートを使用してそれを記録します。

背景: 私たちはどのような問題に直面していますか? (例: バスケット クエリはデータベースを疲れさせます。)

決定: 私たちは何をしているのでしょうか? (例: Redis Cache を使用します。)

代替案 (無視): 何を排除しましたか? (例: コストを理由にデータベースのスケールアップを排除しました。)

結果/結果: 私たちは何をリスクにさらすのでしょうか? (例: データ遅延は減少しますが、キャッシュ無効化の複雑さは増加します。)

結果: 「なぜ?」という質問はもう必要ありません。私たちは尋ねません

今日のスプリント会議や経営陣のプレゼンテーションでは、「なぜこの方法をとったのか?」と尋ねる人はいません。それは言いません。なぜなら、あらゆるターゲットの下にはドアのようなADRがあるからです。

新しいソフトウェア開発者がチームに参加した場合 (オンボーディング)、私たちは彼にアーキテクチャを何日も説明しません。当社は ADR ログのみを提供します。私たちは、「私たちの歴史を読んで、私たちがどんな戦争を行ったのか、そしてなぜこれらの兵器を選んだのかを理解してください。」と言います。混乱を終わらせる秘密。重要なのは派手なコードを書くことではなく、「なぜ?」ということです。それらのコードの背後にあります。企業の遺産に対する疑問。文書化されていないアーキテクチャ上の決定はすべて、将来支払わなければならない高金利の技術的負債となります。根拠を保存して、今すぐお支払いください。

ソフトウェアアーキテクトおよび技術リーダーの皆様。あなたのプロジェクトでは、決定事項は Wiki の砂漠で失われていますか? それともコードの中心に存在しますか?

アーキテクチャ ハンドブック シリーズ

#1: スプリントごとに同じアーキテクチャに関する議論を何度も繰り返したのはなぜですか? （あなたが読んでいるこの記事）

#2: ソフトウェアアーキテクトが経験から学んだエンジニアリング原則 (次の投稿)