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

一言でいうと

システムを構成する主要な要素とその関係、それらを選んだ根拠となる設計上の判断をまとめて指す言葉です。

開発元と登場年

1992年10月に、AT&Tベル研究所のDewayne E. Perryとコロラド大学のAlexander L. Wolfが論文「Foundations for the Study of Software Architecture」をACM SIGSOFT Software Engineering Notesに発表しました。同論文は、ソフトウェアアーキテクチャを要素（elements）、形（form）、根拠（rationale）の3つからなるモデルとして定義し、1990年代がソフトウェアアーキテクチャの10年になるという見通しも述べています。

2000年には、IEEEがアーキテクチャの記述方法を定めたIEEE 1471-2000を発行しました。この規格は、後にISO/IEC/IEEE 42010に引き継がれています。

何を解決するために生まれたか

PerryとWolfの論文によれば、1980年代に設計の記法が実装の言語に取り込まれ、設計と実装の区別が曖昧になりました。システムが大きくなると、個々のモジュールの設計を積み上げるだけでは、全体の性能や変更のしやすさを説明できません。

ソフトウェアアーキテクチャは、要素の選び方と組み合わせ方を設計の対象として切り出し、その根拠をシステムの制約から説明できるようにします。論文のモデルでは、根拠はシステムの制約に基づき、その制約の多くは要件から導かれると説明されています。

どこで使われているか

新しいシステムの立ち上げ、既存システムの作り直し、事業の成長にあわせた構成の見直しの場面で議論されます。マイクロサービスとモノリスのどちらを選ぶか、データをどこに持つか、同期と非同期の処理をどう分けるかといった判断が該当します。

判断の経緯を残すために、設計の決定事項とその理由を文書に記録する運用を採る組織もあります。

人材市場の実情

アーキテクチャの判断は、テックリード、ソフトウェアアーキテクト、Staff Engineerなどの役職が担います。職務経歴書に「アーキテクチャ設計」と書く候補者は多いものの、その中身は既存の構成に沿った部分的な設計から全体の刷新まで幅があります。

システム全体の判断を、要件とのつながりまで含めて説明できる人材は限られ、採用の難易度は高くなります。

混同されやすい技術との違い

採用担当の見極めポイント

• 「アーキテクチャを設計した」という経験について、何を選び、何を選ばなかったか、その理由を聞いてください。比較した選択肢を挙げられない場合、既存の構成に従った経験である可能性があります
• 設計した構成が、運用に入ったあとにどうなったかを確認してください。想定と違った点とその対応を語れる候補者は、判断の結果まで追っています
• 求人票では、現在の構成と、これから見直したい箇所を書いてください。刷新の段階なのか維持の段階なのかで、求める経験が分かれます