ソフトウェアアーキテクトが知るべき97のこと

通称「きのこ本」と言えばプログラマが知るべき97のことがまず話題にあがるためか、ソフトウェアアーキテクトが知るべき97のことが話題に上がることは少ないなーと思います。アーキテクトという単語が妙な先入観を抱かせるため邪魔をしているのだとは思うのですが、僕は気に入っている本です。

そもそもソフトウェアアーキテクトとはなんぞや

という定義について触れられている訳ではありませんが、前書きを読むと

ビジネスサイドの人間よりは技術に詳しく
プログラマよりはビジネスサイドの都合が分かっている

ような人のことを指すようです。スタートアップだと、そういう人がCTOに据えられていることが多いのではないでしょうか。技術的な方針／戦略を打ち出す役目を担っているという意味でも、類似していますね。

そういうわけで、「ソフトウェアアーキテクトが知るべき97のこと」には細かい実装の話よりは、ビジネスとソフトウェアに横たわる問題をいかに解決するか？という話題が多いのです。ソフトウェアアーキテクトという単語自体がなんか苦手だなーという人でも、そういう話題だと聞くと何となく興味が湧いてくれるのではないかなーと思います。

例えば「47.現実の世界にようこそ」では、

エンジニア、特に0と1の世界に住んでいるソフトウェアエンジニアは、正確さを好みます。…（中略）…すべては明快で一貫性が取れており、その正しさは外部キー制約、アトミックなトランザクション、チェックサムによって保証されています。

しかし、現実の世界はそうすっぱりとは割り切れません。発注したかと思うとすぐ後で取り消す顧客がいます。小切手は不渡りになりますし、手紙はなくなります。支払は遅れ、約束は守られません。

と、現実の世界とどう折り合いをつけるのか？　現実世界は複雑で嫌だ！と言う前に、解決手段をも現実世界で見つけよう、というエッセイが載っています。なかなか面白い話題が載っているな、と思います。

そういう設計レベルの話ばかりと思いきや「11.500行の仕様書より1行のコード」では、

仕様書は、それだけでは何の価値もありません。開発プロジェクトの最終目標は、システムを本番稼働させることです。ソフトウェア・アーキテクトは、常にこの目標を見据え、設計はそのための手段に過ぎないことを忘れてはなりません。

と戒めますし、方や「50.アーキテクトは境界とインターフェースに注意を注げ」といった設計のトピックも出てきます。

中でも一番好きなトピックは「61.データがすべて」という話で、

1歩下がって考えてみると、コンピューターとはデータの塊にアクセスし、それを操作するためのしゃれた道具にすぎません。

…（中略）…

データは、多くの問題の核となります。ビジネスドメインの問題は、データを介してコードに潜り込みます。…（中略）…アップグレードなどの運用上の問題も、データに影響がある場合にはかなり難しくなります。コードやふるまいの変更は新しいバージョンをリリースすれば済む程度の問題ですが、データ構造を変える場合には、古いバージョンを新しいバージョンに変換する大仕事が必要になるのです。

これを読むと「あるあるだよね、そうだよね」と思うのと同時に、データ構造の設計に腐心することがいかに重要で効果的なことかということを思い出すんですよね。

ブルックスの人月の神話でも「表現はプログラミングの本質である（P.95）」と述べられていますし、珠玉のプログラミングでも「データによってプログラムの構造を変えよ（P.38）」と述べられている訳です。そういうわけでデータ構造の設計は注力するに値するトピックな訳です。

と、こんな感じで、この本に名を連ねる方々は恐らく長年複雑な問題をいかに解決し、更にそれをいかに継続的に保守し続けるか、更にそれによってどのようにビジネス価値を生み出すかということに腐心してきたんだろうなーと読んでて思います。

コーディングの話よりはもう少し抽象的な話題が多いので、コーディングから離れてしまっている人でも読みやすいのが良い点かも知れません。アーキテクト向けというテーマのせいか、複雑なシステムが例として挙げられることが多いので、そういったシステムと向き合う人にも良さそうです。そんなわけで、興味の湧いた方は是非読んでみてください。