アーキテクチャ決定のためのシンプルなフレームワーク

アーキテクチャ決定のためのシンプルなフレームワーク

ソフトウェアエンジニアは、開発を進めるためにアーキテクチャの決定をしなければならない。新しいマイクロサービスにJavaの代わりにPythonを使うことはできるだろうか？新しいフロントエンド・ライブラリを開発するときに、別のバンドルラーを使ってもいいだろうか？マネージャーや他のチームとリポジトリ構造について合意すべきか？

REST APIを設計するとき、スネークケースとキャメルケースのどちらを使うべきか？会社は、これらの決定をするための明確な枠組みを確立する必要がある。誰が関与する必要があるのか、そして、すでに行われた決定に関する情報をどこで見つけることができるのか。

このような枠組みを適切に作ることは不可欠であり、それぞれのチームがどれだけの自由と自律性を持つかを定義する。これは、ビジネスのニーズや、ある段階で築こうとしている企業文化に沿ったものでなければならない。

これは、さまざまなリーダーシップの役割のとらえ方、技術的な決定におけるマネージャーと個々の貢献者の役割、さまざまなキャリアレベルにおける権限委譲のレベルに影響を与える可能性がある。各企業は、組織の境界線、成熟度、ニーズに応じて、責任者やチームの権限を設定するだろうが、フレームワークにも非常に類似した要素が必要かもしれない。

この記事では、様々な規模の組織における私の最近の仕事経験に基づき、アーキテクチャの意思決定をするためのフレームワークが持ちうる主要な構成要素を共有したいと思う。これらの構成要素には、独自のテクノロジー・レーダー、テクノロジー・スタンダード、およびアーキテクチャ決定記録（ADR）が含まれる。

独自のテクノロジー・レーダーを構築する

Thoughtworksをご存知の方もいるかもしれないが、同社は当初、テクノロジー・レーダーを立ち上げた。Thoughtworksは、業界全体の顧客と一緒に現場で見たことを捉え、公表している。

同様に、自社が使用している、または使用する予定の様々なテクノロジー、ツール、方法論の成熟度を示す独自のレーダーを構築できる。テクノロジー・レーダーは、あなたの会社の現在と将来のテクノロジー・スタックを視覚的に表したものだ。

アセスメント、トライアル、採用、ホールドといったさまざまな段階を定義し、特定のテクノロジーがこれらの段階をどのように進むべきかのプロセスも定義しておく必要がある。

heycar Technology Radar example

heycarでは、段階を次のように使い分けている。まず、新しいテクノロジーは積極的に研究され、評価されるのだ。アセスメントの状態は通常、コンセプトの実証と、私たちの環境での技術使用の長所と短所の広範なリストで終わる。その後、その技術に関わる可能性のあるそれぞれの社内実践コミュニティやチームと、成果について話し合うのだ。論拠のリストと概念実証の実施に説得力があれば、次のステップは管理された試用期間である。トライアル期間中、そのテクノロジーは、1つのユースケースに限って実運用で開拓される。その段階が成功すれば、私たちはその技術を採用すると宣言し、どのチームにもさらなる使用への許可を与えるのだ。もし新しいテクノロジーが以前使われていたものに取って代わるのであれば、そのことを示す必要があるかもしれない。ホールド・ステータスはそのためのものだ。私たちがもはや使用することを目的とせず、代替戦略を持っているテクノロジーに対して使うのである。

テクノロジー・レーダーは、チームがテクノロジーの状況を理解し、どれを使うかについて十分な情報に基づいた決定を下すのに役立つ。常に更新していれば、社内の全員が、最新のテクノロジーの利用状況とそれらがビジネスに与える影響を把握できる。

社内テクノロジー・スタンダードの導入

2つ目の要素は、テクノロジースタンダードの導入である。テクノロジー・レーダーは、テクニック、プラットフォーム、ツール、言語、フレームワーク、そして組織全体におけるそれらの採用レベルを把握するものだ。しかし、これだけではすべてのニーズをカバーできないかもしれない。システムの異なる部分にまたがって適用されるものについて、一貫したプラクティスを確立することは役に立つ。例えば、すべてのロギングが同じフォーマットで、同じ情報が含まれるようにしたい可能性があるのだ。あるいは、REST APIを使っているのであれば、どのヘッダーを使うか、どのように名前をつけるかなど、どのように設計し、どのように使うかについて、いくつかの慣習を確立したいかもしれない。さらに、複数の似たようなテクノロジーを使っている場合、それぞれのテクノロジーをいつ使うべきかをガイドしておくと便利だ。テクノロジー・スタンダードは、社内で技術を選択し使用する際のルールを定義するものである。一貫性を確保し、新しいテクノロジーを最適でない方法で採用するリスクを減らし、組織全体の一貫性を促進する。

誰がスタンダードを担当すべきか？テクノロジー・スタンダードは、関連分野の専門家からなる部門横断的なチームによって作成され、維持されるのが理想的だ。テクノロジー・スタンダードは定期的に見直され、技術の変化に対応するために必要に応じて更新されるべきなのである。チームには、標準に従うことを奨励し、その有効性についてフィードバックを提供すべきだ。形式は異なってもよいが、おそらく詳細な説明とコード例があるだろう。例えば、RFCフォーマットフレームワークに従うようなフォーマルなものにできるし、好みやエンジニアリング文化に応じてカジュアルなものにもできる。ZalandoのRESTful APIとイベントガイドラインは、社内で共有されているテクノロジー・スタンダードの良い例だ。API標準に加え、ロギングとモニタリング、デプロイメント、QA標準を導入したい場合もあるだろう。

内部標準に基づいて、テストカバレッジのチェック、命名規則やフォーマットのチェックのためのコードリンターの統合、アーキテクチャやリポジトリ構造の検証のためのフィットネス機能などの品質ゲートを作成できる。自動化されたチェックの組み合わせや、新規参加者のオンボーディング、コードレビュー、ペアプログラミングの際に標準を使用することは、標準が使用され、価値をもたらすことを確実にするのに役立つ。これらは、標準への準拠をチェックするゲートに加えて、プラットフォームエンジニアリングの価値について議論するチャンスである。何か間違ったことをしたときに、単にそれを伝えるのではなく、デフォルトで正しいことをしやすくするのだ。

アーキテクチャ決定記録（ADR）の採用の実践

アーキテクチャの意思決定を整合させるための3つ目の要素は、ADRまたは軽量RFCを作成することだ。ADRは、アーキテクチャ上の決定とその理由を文書化する方法であり、重要な決定の履歴を記録し、チームが特定のアプローチを選択した理由を理解するのに役立つ。ADRは、アーキテクチャ上の決定をしたチームが作成すべきである。ADRには、解決すべき問題、検討した代替案、決定したこと、およびその理由などの情報を含めるべきである。それは不変の文書であり、ある決定が再検討された場合、通常は新しい文書が作成される。ADRの実践はますます一般的になってきているため、AWSやGCPなどの主要なクラウドプロバイダーは、それぞれのドキュメントにADRを追加した。

テクノロジー・レーダーと標準が技術的な決定にガイダンスと期待される境界を与えることになっているのに対して、ADRは、新しいサービスやパッケージを作成する理由、新しい技術を導入する理由、その他の主要なアーキテクチャ変更の理由など、特定の1回限りの決定について、その理由を記録し、文書化するものである。ADRは通常、一元化されたリポジトリや文書化ツールに保存され、関連するすべてのチームがアクセスできる。また、新しいチームメンバーが、全体的なアーキテクチャと重要な決定の背後にある理由を理解するのにも役立つ。

ADRレビュー・プロセスは、複数の目的，例えば決定事項のレビューと承認、知識の共有に使用できる。ADRレビューには、影響を受ける全員を参加させるのが一般的であるが、ADRレビューをより多くの人と共有することで、組織全体のアーキテクチャに対する認識が高まる。さらに、社内の技術サークルでADRを発表し、より多くのフィードバックを収集することも有効だ。過去に同じような課題を解決したエンジニアがいても、今は直接その課題に取り組んでいないことがある。

最初の2つの柱と同様に、ADRの最終決定権をカバーするプロセスや、どのような決定がADRを必要とするほど重大であるとみなされるかは、組織ごとに異なるだろう。重複を避けるために、ADRを使用して、新しい大規模なシステム変更を構築するための特定の設計の選択に合意する一方で、レーダーと標準を使用して、言語、ツール、およびプラクティスの広範な使用方法に合意できる。社内にテクノロジー・レーダーとスタンダードがあれば、もっとも重要な技術的選択と原則はすでに一致しているため、ADRに合意することは無駄のない簡単な作業となるはずだ。

結論

テクノロジーレーダー、テクノロジースタンダード、ADRを組み合わせることで、アーキテクチャを決定するための明確で一貫性のあるアプロ ーチを提供するフレームワークが形成され、新しいテクノロジーを採用するリスクを低減し、重要な決定の履歴を記録できる。アーキテクチャ決定のためのフレームワークを確立することで、チームは、テクノロジースタックをビジネス目標と整合させ、十分な情報に基づいた意思決定をするために必要な情報とガイダンスを得ることが可能だ。

チームが持つ自由度、およびテクノロジー・レーダー、テクノロジー・スタンダード、またはADRを変更するプロセスは、エンジニアリング文化を形成する。ある組織は急進的なチームの自律性を目指し、ある組織はより制限的な高い一貫性と整合を目指す。例えば、レーダーとスタンダードの変更にシニアテクニカルリーダーを関与させ、さらなる技術的な決定を導き、ADRはそれぞれのソフトウェア機能を担当するチームに任せるというアプローチが考えられる。フレームワークを選択し、自社のニーズに合わせて調整できるのだ。