はじめに
さまざまなロールを転々としてきましたが、10年以上ソフトウェア開発の世界にいます。さまざまなプロジェクトでさまざまなアーキテクトと仕事をしてきましたが、関わったすべてのプロジェクトで、システムを設計したのは一人でした。
1. 新卒で最初に開発したシステム
アーキテクトが設計したものは、メッセージキュー、共有メモリ、マルチスレッド、子プロセスを駆使した複雑なシステムでした。当時、巨大なシステム構成図を作った際に「UNIXプログラミングの遊園地」とジョークを言ったことを覚えています。構成が複雑なためバグが多発したもののマルチスレッドはprintfデバッグできなかったため、GNUデバッガでメモリを追いかけ苦労しながらデバッグしていました。シンプルな目的のシステムだったため、当時から「こんなに複雑なアーキテクチャは必要なのか? ただ自分が使いたい技術を使っているだけではないか?」という疑問を抱いたことを記憶しています。
2. 前職でのマイクロサービス化プロジェクト
アーキテクトが設計したのはモダンなマイクロサービスアーキテクチャでしたが、設計方針を知らされていなかったプロジェクト外のエンジニアにサービスを開放した際、開発方法が変更されることについて大混乱に陥りました。彼が残した豊富な設計文章は前提知識が乏しい人にはむずかしいドキュメントでした。さらに、マイクロサービスの詳細についてSREやビジネス部門に説明していなかったため、マイクロサービス起因の障害について納得させることはむずかしかったです。
----
もちろん、彼らアーキテクトを責めたいわけではなく、彼らがいなかったらシステムもプログラマーとしての私も存在しなかったと思っています。
つまるところ、システムの土台を作ったのは彼らなのです。
ただ、もう少しだけ分かりやすいドキュメントや、周囲への理解と説得が欲しかったのも確かです。
アーキテクチャの民主化、『Design It!』
というわけで今回本書『Design It!』を読む前は「現代的なソフトウェアアーキテクティングの入門書!」と帯文にあったため、最新のアーキテクチャの理論が羅列されているものと想像していましたが、実際はかなりニュアンスの異なる書物でした。もちろんアーキテクチャの理論についても触れられていますが、平鍋健児氏の日本語版序文に「アーキテクトとプログラマーという構造ではなく、アーキテクチャを民主化したのだ」と見事に要約されているように本書のメインテーマはアーキテクチャの民主化だと感じました。著者はアーキテクチャを設計することだけではなく、チームのアーキテクチャを育てることをアーキテクトの重大な責務として挙げています。
ソフトウェアアーキテクトは、プログラミング以外にも、たくさんの責任がある。(中略)そして何より、チームのアーキテクチャを育てる。アーキテクトで満たされたチームこそが最善だと理解しているからだ
- 作者:Michael Keeling
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/11/25
- メディア: 単行本（ソフトカバー）
本書に出てくるびっくりするほどのヒューマンスキル
たとえば、ステークホルダーに共感して共感マップを作成する、ステークホルダーに要求をインタビューする、評価ワークショップをする、「積極的傾聴」スキルの重要性をアーキテクトが語るコラム......さらに本書で登場する架空のプロジェクトでは設計の毎ステップでアーキテクトが一人で意思決定するのではなく、必ずチームやステークホルダーのワークショップで意思決定するほどの徹底ぶりです。私は読んでいてアーキテクトではなくUXデザイナーやスクラムマスターの本ではないかと思ったほどです。アーキテクチャやシステムの理論もたくさん出てきますが、本書の独自性は間違いなくアーキテクトの世界にヒューマンスキルと民主主義を持ち込んだことだと感じます。
個人的には方向性は歓迎
冒頭に書いた通り、今までアーキテクチャが一人で設計するシステムにしか関わったことがなく一人で設計することのデメリットを数々体験してきたため、アーキテクトの意思決定が見える化されること、よりステークホルダーやメンバーと協調して設計すること、分かりやすいドキュメントを残すこと、チームメンバーをアーキテクトとして教育するなどのアーキテクチャの民主化という本書の方向性は良い流れではないかと思います。
またアジャイル宣言の背後にある原則の一つに「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」という原則がありますが、まさにこれをプロセスとして具現化されているので今後サンプルの一つとしてアジャイルコーチの立場からも説明しやすくなるなと感じました。
アーキテクチャ民主化の光と影
とはいえ、アーキテクチャの世界を専制君主制から急激に民主化することが果たして本当に良いことなのかということの自分の答えはまだ出ていません。まずは、アーキテクトの責務に「チームメンバーの教育」を含めると単純にアーキテクトの負荷が増大するのではないかと単純に思います。そして本書ではメンバー全員でアーキテクチャをスケッチし批評し合う『アーキテクチャデザインスタジオ』という手法が紹介されていますが、そこで私は『デザインスタジオ』という言葉から昨今急激に進んでいる(ように見える)デザインの民主化を思い起こさせました。結局デザインは民主化できたのでしょうか? たしかに一部はされたかもしれませんが、自分たちが手軽にデザインできるという思い込み、表面的なデザイン手法の濫用、専門家への軽視、そして反動的な専門家への崇拝の復活といった悪影響も多いように感じます。
民主化は素晴らしい一方、何かを拡げるということは本質を薄めたり無くしたりする危険性と常に隣り合わせです。
ステークホルダーの要求をマッピングし品質特性とアーキテクチャデザインパターンを組み合わせれば、誰でも設計できるようになるのでしょうか。
様々な開発者やアーキテクトによる本書の批評が読みたいと思います。
おわりに
今回は『Design It!』を代わりに読んできました。
色々書きましたが、とりわけアジャイル開発に興味ある方はぜひ一読していただきたい良書です!
本文でも書きましたが、様々な開発者による本書への批評をぜひ読んでみたいと思いました。
賛否両論あるかと思いますが、何はともあれRead It!
最後までお読みいただき、ありがとうございました!
