ソフトウェアアーキテクト

この領域について

中核となる能力

• 01システムの分割

  事業が実際にどう変化するかを反映した境界を見つけ、典型的な変更が4つの構成要素にまたがるのではなく1つの中に収まるようにすること。ドメインの関心ではなく技術レイヤーに沿って引かれた境界は、あらゆる機能追加が協調リリースを必要とするシステムの典型的な原因です。

• 02統合と契約

  構成要素がどう通信するかを決め — 同期か非同期か、スキーマを共有するか端で変換するか — 依存に足る安定した契約を定義すること。バージョニング、非推奨化、後方互換性は設計の一部であり、最初の利用側が壊れてから考えることではありません。

• 03非機能要件

  漠然とした期待を、可用性、レイテンシ、スループット、耐久性、復旧、データの所在、監査可能性についての明示された目標に変え、それに向けて設計すること。誰も数値化していない要件は、意図して満たすことができず、偶然にしか満たされません。

• 04技術選定

  実際に効いてくる要件 — 運用負荷、採用しやすさ、ライセンス、離脱コスト、組織との相性を含む — に照らして候補を評価すること。問うべきは抽象的にどれが最良かではなく、制約とそれを運用する人々にどれが適合するかです。

• 05トレードオフの分析

  各選択肢が何をもたらすかだけでなく、何を要するかを明示し、どの性質を犠牲にしているかを明確にすること。欠点がないものとして提示されるアーキテクチャは、分析されていないか、説明ではなく売り込みが行われています。

• 06移行戦略

  現状から目指す姿への道筋を、各段階でシステムが動いたままになる増分として計画し、共存、突き合わせ、切り戻しを設計に含めること。難所は目標設計であることはまずなく、ほぼ常に順序です。

• 07決定の記録

  何を決めたか、どの代替案を却下したか、何を前提としたか、どうなれば見直すべきかを書き残すこと。その価値は数年後、ある制約が今も有効なのか、いつのまにか失効したのかを誰かが判断しなければならないときに現れます。

• 08障害と脅威の分析

  依存が停止するのではなく劣化したときに何が起きるか、リトライがどこで負荷を増幅するか、部分的な障害が利用者にどう見えるか、そして信頼境界とデータの流れがシステムをどう攻撃にさらすかを考えること。

• 09コストの見積り

  ある設計が想定される量と想定外の量でいくらかかるかを理解すること。技術的には健全で経済的には持続不可能なアーキテクチャはよくあり、その発見はたいてい請求書とともに訪れます。

• 10指示によらない影響力

  受け入れを強制されていない判断に沿ってチームに作ってもらうこと。この能力が、上に挙げた他のすべてが何かを生むかどうかを決めます。そして強い技術的経歴を持つ候補者に最も欠けていることの多い能力でもあります。

よくあるご質問

よくあるご質問

ソフトウェアアーキテクトとテックリードの違いは何ですか

影響範囲と時間軸です。テックリードは1つのチームの技術的な仕事について数週間から数か月の責任を負い、コードの近くに留まり、誤った判断はたいてい1スプリントで修正できます。アーキテクトは複数のシステムとチームにまたがり数年の視点で働き、誤った判断は誰かが気づく前に、その上に作られたすべてに波及します。両者は補完的です。アーキテクチャはチーム間の制約を定め、技術的リーダーシップはその内側で良い判断を下します。

ソフトウェアアーキテクトはコードを書くべきですか

量として必ずしも必要ではありませんが、現実についての自分のモデルを正確に保てるだけの、稼働システムとの接触は必要です。その接触は、通常の機能開発ではなく、試作、レビュー、障害対応への参加、テレメトリを読むことからでも得られます。そうした接触のないアーキテクトは、説明された姿のシステムに向けて設計を始めます。それが、ほとんどすべての象牙の塔批判の背後にあるしくみです。

小規模な組織に専任のアーキテクトは必要ですか

独立した職位としては、必要でないことが多いでしょう。単一プロダクトと数チームであれば、アーキテクチャ上の判断は、経験あるエンジニアと技術的リーダーが担えるだけの数に収まります。必要になるのは、判断がチームの境界をまたぎ始めたとき、複数のシステムが相互運用しなければならなくなったとき、あるいは約束によって非機能上の性質が譲れないものになったときです。またぐべき構造がまだ存在しないうちにアーキテクトを置くと、問題を探しに行く統制が生まれがちです。

アーキテクチャ決定記録は実際に何をもたらしますか

根拠を保存します。根拠はコードより速く失われます。記録は、何を決めたか、どの代替案を却下したか、何を前提としたか、どうなれば方針転換が正当化されるかを述べます。その価値は後になって、ある制約が今も成り立つかを誰かが判断しなければならないときに現れます。却下した選択肢も前提も書かず、結果だけを記した記録はその価値をほとんど持たず、多くのチームがこの実践を官僚的だと結論づける原因になっています。

良いアーキテクチャと高くつくアーキテクチャはどう見分けますか

その複雑さが、実在する要件に答えているかどうかで見分けます。良いアーキテクチャは想定される変更を安くし、どの変更に対しては最適化していないかを明言します。高くつくアーキテクチャは、誰も求めていない変更のための柔軟性を先に作り込み、その代金をその後に届けるすべての機能で徴収します。実務的な確認方法は、構造の各部分がどの具体的な圧力を吸収するために存在するのかを、アーキテクトが言えるかどうかです。

アーキテクチャは個人ではなく集団が所有できますか

できますし、多くの組織ではそのほうがうまくいきます。上級エンジニアの集団が構造上の判断をともに下し、判断を閉じる明確な方法と決定の記録を備えていれば、個人が方向を発するよりも納得の得られる判断が生まれます。集団が容易にできないのは、一貫性への責任を負う人がいないまま、年単位で整合を保つことです。したがって一般的な形は、共同の意思決定と、記録の管理者を1人定めることの組み合わせです。

ソフトウェアアーキテクトは既存の開発チームとどのように働きますか

御社のアーキテクチャ実務の代わりではなく、その担い手の1人として働きます。開発体制の拡張という形態では、アーキテクチャ上の権限、技術的方向づけ、エンジニアリング基準、ロードマップ、プロダクトの所有は御社に残ります。構造に関する判断を下し承認するのは御社の担当者であり、作業を指示するのも御社のチームです。Talent.ID側の役割は雇用に関する部分に限られます。雇用関係そのもの、給与支払い、従業員福利厚生、そしてタレント管理です。アーキテクチャ上の意思決定がこれに伴って移転することはありません。