1~2年くらいに前に読んだDesign Itを読み直していたら、ソフトウェアアーキテクトとして果たすべき役割や責任について学び得ることがあったので、メモを残す。
お気持ちも交えつつ書くのでこれはポエム。
ソフトウェアアーキテクトはコードも書くし、プロジェクトのリードもするし、ビジネス的な視点でも思考を巡らせたりもする。
ビジネス・技術・ユーザーの3つの要素の中心に立つ存在である。
ソフトウェアアーキテクトが果たすべき責任はDesign Itでは概ね次のように定義されている。
システムの分割と責務の割当は、必ずしもマイクロサービスが意識しているわけではなくて、単にシステムのサイズ感を小さくできると良いよね、という程度のことだと思う。たぶん。
チームのスキル向上という教育的な責任もあるというのはちょっと新鮮だった。
ソフトウェアアーキテクチャは、「品質特性やその他の性質を発揮するためにソフトウェアをどのように構築するかということに対する設計判断の集まり」と定義される。
つまり、ソフトウェアアーキテクトはシステムが求める特性の理解や特性を発揮するための設計判断をする力が必要だと考えられる。
ソフトウェアの構築にはやるべきことや気をつけるべきことが沢山あるが、ソフトウェアアーキテクトが気をつけるべきことの1つは、「コストのかかる間違いを避ける」こと。
これを間違えると後で大変なことになる、という部分を察知、回避できるようにリスクコントロールを図るということだが、結構経験の差が大きく現れる部分だろうなぁと感じる。
これに関連して、ソフトウェアアーキテクトの行動指針として、「設計判断を最大限遅延させる」というのがある。
重要な設計判断（≒コストのかから間違いの発生がありえる判断）は可能な限り決定することを後ろ倒しにするということ。
人生でもそういうことあるよね、ソフトウェアアーキテクチャは人生。としみじみ思った。
どうしても今決めないと前に進めないような問題に関しては、選択肢を残して判断することが大事かなと思った。これもまた人生。
ソフトウェアアーキテクチャについての深掘りした話は、ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチを参照しても良い思う。近しいことが書かれている。ソフトウェアアーキテクチャの特性についても色々と整理されている。
続編のソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析は発展的内容だが、こちらも面白いと思う。余談だが書籍のレビューにボランティアとして参加した本でもあるので思い入れがある。
Design ItのP.214 ”プログラマーは日々アーキテクチャに関する判断を下す”に書かれていたことだが、たった1行のコードでもアーキテクチャの品質特性を左右する設計判断になり得るので、プログラマであってもソフトウェアアーキテクトと言えるよねという話。
職責が違おうが、肩書が変わろうがソフトウェアに向き合うならアーキテクトとしての振る舞いを意識することは大事だよねと改めて思った。
いつかはソフトウェアアーキテクトでと胸を張って言えるようになりたいと思った。