「Design It! ―プログラマーのためのアーキテクティング入門」を読んだ
「Design It! ―プログラマーのためのアーキテクティング入門」を読みました。
正確には、英語版を読んだので、読んだのは "Design It!: From Programmer to Software Architect (The Pragmatic Programmers)" です。
こちらですが、端的に言って、良本でした！
アーキテクトが何者なのか、何をどんな風に考える必要があるのかについて、良くまとまっています。そしてソフトウェアアーキテクチャとは何か、という意外と答えにくい問いにも明確に答えています。
より端的に言うとソフトウェアの設計をする際の思考原則について触れている本で、デザインパターンのような本ではないです。
まず、ソフトウェアアーキテクトが何か、という点についてですが、本書では三要素に分割しています。これはこの本独自ではなく Software Architecture in Practice (SEI Series in Software Engineering) (English Edition) の引用になります。ソフトウェアアーキテクチャの設計と文書化の技術でも同様の定義を用いたので、そちらから以下に引用しました。
……ふむ、正直表現が固すぎてわからないですね。
モジュールはソフトウェアの設計時に出てくる構造で、どのように各コードを配置するか、具体例としては、クラス、パッケージ、レイヤー、データベースであれば、ストアドプロシージャやテーブルになります。
コンポーネントとコネクタは、実行時にのみ存在するもので、具体例としてはオブジェクトやコネクション、スレッドやプロセスなどが当てはまります。
そして最後の配置は、要はインフラです。具体例としては、サーバー、ロードバランサ―、そして Docker コンテナなども含まれます。
もっとザックリまとめてしまうと、モジュールはいわゆるソフトウェアの設計、配置はインフラの設計、そしてコンポーネントとコネクタはアルゴリズム、と捉えてもいいかもしれません。
これを全部含めて、「ソフトウェアアーキテクチャ」と定義しています。
そしてこれに責任を持つ、アーキテクトが何者かについて端的にまとめると、
- ソフトウェアの全体がどうなってるかに責務を持つ
- エンジニアリングの観点からの問題定義を行い、実装可能なチャンクに分割する
- 設計に際しては品質要件（非機能要件とよく呼ばれるもの）のトレードオフを把握し意志決定を行う
- ソフトウェア全体が適切に動いてることを保証する
- 技術的負債の把握やコントロールを行う
- チームメンバー全体のアーキテクトとしてのスキルを育てる（アーキテクトが多いチームが最良のチーム）
といった感じです。役職としてのアーキテクトが会社になかったとしても、この役割を担っている人は確実にいると思います。
その場合、エンジニアリングマネージャーだったり、テックリードだったりがになっているんではないかと思います。もし会社がまだ小さいのであれば、CTO が兼任しているケースも全然ありえます。
プロダクトマネージャはいわゆる機能要件、プロダクトがどのような価値をユーザーに届けるかに重点を置くのに対し、アーキテクトは品質要件（非機能要件）を軸に意思決定をすることになります。アーキテクチャの選定は品質要件（速度や拡張性、開発用意性、デプロイ用意性など）を大きく左右するためです。そして、どのようにソフトウェアが構築され、いつデリバリーされるかという点にも責任を持ちます。
ソフトウェアエンジニア、もしくはアーキテクトやマネージャーとして、常に意識しておくと良質な意思決定ができそうだなと思ったことについては、
- 制約と要件を理解し、それに応じたアーキテクチャを考える
- 良い解決策を見つけるためには問題の理解が必要だが、さらなる問題の理解のためには解決策の模索が必要で、このループを回す必要がある
- 認知負荷を下げる為の設計を行う（メンテナンス性の向上に必須で、Team Topologies など開発組織構造などの文脈でも出てくる）
- リスクドリブン設計（想定されるリスクを分析しアーキテクチャの比較検討と選択を行う）
あたりがありました。
あと、図に関する話が非常に良かったです。The C4 model で紹介されている考え方は、目を通しておく価値があります。 それについては、以下の動画に良くまとまっています。
大事なことは、
- 図を描く際は抽象化（粒度）を先に考え、表現（記号）はその次
- これは要は「誰を対象にするか」を最初に考えるということです。例えば地図を見る場合、世界地図が欲しい場合、街単位、ストリートビューなど、求めるものによって違うと思います。最初にこれを意識してから、必要な表現を考える、という話です。
- 色や形などは、既に意味が通る図をさらにわかりやすくするために使う
- つまり色や形をすべて取り除いても、意味が分かる図でないとだめ
の2つです。実際これを守って図を描いてみたんですが、格段にわかりやすくなりました。 アーキテクチャや設計などのレビューを行う外部の会社とのやり取りに使ったのですが、評判がものすごくよかったです。
特に効果的だと思ったのは、矢印には常に "(A) does something with (B)" などのように、矢印の元が主語になり、先が文章の最後に来るような説明を書く方法です。これで一発で矢印が意味しているところがわかるようになります。
そのほか、たくさんのワークショップが最終章で紹介されています。設計のフェーズにおいて、今何をするべきか変わると思いますが、それに応じて使えるワークショップがまとまっているので、軽く目を通してみるといいと思います。
この「今何をするべきか」は大事で、実際に本書では常に、
- Understand
- Explore
- Evaluate
- Make
の区分けがされていました。例えば、そもそも問題や制約を理解する必要があるのか、現状のアーキテクチャの理解を深めるのか、それとも解決策を探るのか、はたまたどのようなリスクが潜んでいるか考えるのか、最後の意思決定を行うのか、などです。
面白い点として、かなり大きなシステム開発も想定しているところがあります。どの程度事前のデザインに時間をかけるべきかの話があるのですが、一番大きいものは本当に大きく、おそらく SIer などに居ない限り目にしないような規模の話もあります。
つまり、ソフトウェア開発に携わる人であれば、だれでも楽しめる本なんじゃないかと思います！
良書でした！
