私は現在、会社でアーキテクト[*1]という職位についています。実際のところは、自分の半分くらいの時間でチームのテックリードを務めつつ、半分くらいの時間でアーキテクトをしているという時間配分です。アーキテクトというのは、勤務先ではテックリードの上位に置かれているようなイメージで、テックリードがチーム単位での技術的なリードを司る職位だとすると、アーキテクトはチームの上位概念である事業領域単位での技術的なリードを司る職位、ということになります。
アーキテクトの主な仕事は、基本的にはテックリードと変わらず技術的な意思決定です。さまざまなトレードオフを掻い潜りながら、その時点での最適な結論を出すのがお仕事といったところでしょうか。ただ、アーキテクトの場合、どちらかというと未来やビジョンを持った技術的な意思決定が問われる場面が多そうに見えています。チームを率いるテックリードの場合、そのチームでの決め事を事業領域の方針に従って決めればよいです。一方で、アーキテクトの場合は、そもそもその方針を決める側というわけです。見ている方向や時間軸に大きな差があります。
何かを決める場合、何かしらの軸があると「意思決定」という行為の負荷が下がります。私が本書を手に取った理由も、こうした軸を作るにあたって何か参考になることがあるのではないかと考えたためです。
どんな本か
アーキテクトの意思決定を支援するための話が書かれています。最初にどのような判断軸を持って日々の開発業務にあたると良いかが「質問」と「原則」によって示され、その後具体的にアーキテクトが知っておくべき技術的な話が続きます。そうした技術的な話の中でも、例示として「質問」と「原則」を適用し、技術的なトレードオフから何をどう選び取り、物事を決めていけばよいかが示されるという構成になっています。
本書で示される「質問」と「原則」の一覧は、下記のようになっています。
5つの質問
- 市場投入に最適なタイミングはいつか？
- チームのスキルレベルはどの程度か？
- システムパフォーマンスの感度はどれくらいか？
- システムを書き直せるのはいつか？
- 難しい問題はどこにあるか？
7つの原則
- ユーザージャーニーからすべてを導く
- イテレーティブなスライス戦略を用いる
- 各イテレーションでは、最小の労力で最大の価値を加え、より多くのユーザーをサポートする
- 決定を下し、リスクを負う
- 変更が難しいものは、深く設計、ゆっくりと実装する
- 困難な問題に早期に並行して取り組むことで、エビデンスに学びながら未知の要素を排除する
- ソフトウェアアーキテクチャの凝集性と柔軟性のトレードオフを理解する
本書をおすすめする人
アーキテクトという直接的な職種がある会社はそう多くはないと思いますが、まずはアーキテクトにはおすすめできるはずです。リード職種を束ねる立場になると、判断や意思決定がメインの仕事になってきます。その際の指針の拠り所になる一冊だと思います。また、システムアーキテクチャの基本的な座学のための一冊としてもよいと思っており、自身の知識の再整理におすすめできるはずです。
将来的にもう少し上位職になりたいと望むテックリードもまた、おすすめできると思います。多くの職場では結局のところ、上位職種の実務をすでにこなしていると判断されるか、こなせるというポテンシャルを感じられた場合に、昇進し上位職種に就けることが多いはずです。つまり、自分より少し上位の職種が何を考えるべきか、日常的に何をやってるかを知り、その視点から業務に臨むとよいのではないでしょうか。
印象に残った箇所
本書を読んで印象に残った箇所と、私が読んでいて考えた内容を書評の代わりとして載せておきます。
アーキテクト特有のリーダーシップ
本書は要するに、アーキテクトがリーダーシップをこなすために必要な知識を授けるという体裁になっています。アーキテクトが正しくリーダーシップを発揮するためには、リスクを最小限に抑え不確実性を管理する力が求められることになります。また、アーキテクトは自身のビジョンを示し、人々にそれを伝え続け、ビジョンに人を巻き込む力が求められます。
なぜここまでアーキテクトのリーダーシップや意思決定力ないしは判断力が強調されるかというと、筆者の見立てによれば、多くのアーキテクトに足りないのは、知識ではなく判断力だという確信があるからです。アーキテクトの仕事というとついつい知識面が強調されがちではあるのですが、プロジェクトやプロダクトの設計がうまくいかなくなる理由は知識不足にあるのではなく、将来の不確実性を管理するという目標に向かって正しく判断できないからだと言います。
ところで、不確実性を管理するという言葉を読んだとき、マネジメントとやることが被っているのではないかと思いました。実際、『エンジニアリング組織論への招待』という本では、不確実性と向き合うことが強調されていたように思います。この書籍の中では、不確実性は下記の3つがあると整理されていたのを思い出します。
- 方法不確実性: どうやって作るのかという不確実性
- 目的不確実性: 何を作るのかという不確実性
- 通信不確実性: コミュニケーション上発生する不確実性
アーキテクトもエンジニアリングマネージャーも、一旦は方法不確実性と向き合っていることが多いと思います。EMは加えて、通信不確実性にも向き合っているかもしれません。なので、対象が被っているのではないかと思ったというわけです。
しかし考えてみれば当たり前の話ですが、アーキテクトとEMとではアプローチの仕方に差があります。アーキテクトの場合は技術選定や設計の面から方法的不確実性に対処することになります。EMの場合は、たとえばスケジュールマネジメントや組織開発、人材開発の観点から方法的不確実性にアプローチするはずです。究極的な目的は両者ともに、将来の不確実性の管理という意味において未来を見ることではあるものの、アプローチの仕方が異なっているのだと理解しました。
意思決定に使えるアプローチ
リーダーシップの発揮において、意思決定は欠かすことのできない要素でしょう。一方で、よい意思決定には判断の軸が必要ではないかと私は考えています。実際本書では、下記の「質問」と「原則」を通じて、よりよい意思決定をサポートするようになっています。また、本書で紹介されるさまざまなケーススタディの最後には、これらの要素を適用する例も示されています。
ところで書籍の内容とは関係ないものの、もう一つおもしろいと思っているのが、こちらの記事で紹介されている「松竹梅」によるアプローチです。この手法のメリットは、上記の判断軸が「網羅性」や「見落とし」に効くという意味において良い意思決定になるのに対し、よりベターなシナリオを導き出せるという点にあると考えています。
こうした意思決定を支えるアプローチは、試せるものは一通り試しておきたいなと思いました。今後もどんどん意思決定を求められるタイミングが増えそうなので、引き出しを持っておきたいものです。
委譲の問題
リーダーシップを発揮するとして、どこまで現場の意思決定に介入すべきかは難しい問題になります。本書の推奨は、
- 基本的にあまり重要でない問題はどんどん個々のチームや現場に委譲した方が良い。
- 自分にしか決められないものというか、決定後不可逆になりそうなものは、自身で決めた方が良い。
です。これはことあるごとに意識したいなと思いました。チームが成長し、次のアーキテクトが生まれるという意味でもこれは重要かもしれません。
決定後不可逆になりそうなものというとなかなか例が難しいでしょうが（おまけに本書にも具体は載っていない）、たとえばデータベース設計などがそれに当たるでしょうか。テーブル定義は一度作るとなかなか変更の難しいものの代表例であるように思っていて、失敗すると非常に影響が大きく、技術的負債になる確率も高いです。この辺りは、全体を俯瞰しながら設計できるような経験豊富なアーキテクトが先回りしておくべきかもしれません。
それ以外は、基本的に現場に任せ、アーキテクトは指針を示す程度にとどめておいた方がよいとのことでした。というのも、これは経済学者のハイエクが「The Use of Knowledge in Scoiety」という文書で書いていたらしいのですが、現場の人々の方がよりよいコンテキストを持っていることが多く、よりよいコンテキストから下される判断の方が、よりよい意思決定となる可能性が高いからとのことです。Design Docを書く際などについつい詳細まで埋めがちで、抜け漏れがあると反省していたといえば反省していたのですが、その必要はないと悟りました。
品質の分類
最近仕事でも少し考えさせられることがあったのですが、本書で行われる品質の分類は役に立ちそうだと思いました。
品質は大きく分けて3つになるようです。ひとつは既知の既知（本書ではおそらく、「既知のエラー」として説明）、既知の未知、未知の未知です。参考記事。
- 既知の既知: リスクの存在を知っており情報も十分で対策を立てやすいもの。
- 既知の未知: リスクの存在は知っているが、詳細や具体的な影響が不明なもの。ただし、存在を認識しているので対策を立てやすい。
- 未知の未知: そもそもリスクとしての存在を知らず、予測を立てられないもの。
品質向上においては、未知の未知を既知の未知に変えていく作業（大きくはテスト）が必要になります。既知の未知も未知の未知も両方テストで拾えます。筆者はテストを「探索」と「開拓」の二つの検査行為と考えているようです。未知の未知に立ち向かうためには、「開拓」のテストの実施が必要になります。たとえばカオステストや生成AIの活用などが例としてあげられていました。
私が最近TLで見かけて少し気になっていたのは、いわゆる「探索的テスト」と呼ばれる手法です。軽く見た限りでは、これはどうやら未知の未知への対抗策なように見えていて、今年のどこかでどういった手法かを学んでみたいなと思っていました。最近書籍も出たようで、書籍の冒頭にまさに、最近考えていた話が載っていたので興味を持っています。
卓越性を示す
「卓越性を示す」というのは要するに高い基準を示し続けることだと思いました。たとえばコードのクオリティやインシデント対応後のポストモーテムでの再発防止に際して、日常業務に追われているとついつい妥協をしてしまいがちなのですが、さらに一歩深く追究できるようであればそれを促すということです。
これを示すためには、本書でも語られるようにチームへの問いかけが重要になります。コーチングや問いかけの技法、ファシリテーションなどはEM専属のスキルに見えがちなところはありますが、アーキテクトにも必要になってくるというわけです。アーキテクトは技術職ではあるものの、技術の理想を組織に浸透させるという役割を担う以上、やはり周りの人の思考を深める手助けをするような能力も求められることになる、と本書では語られます。
卓越性に関する節（p.260〜p.262）で出てくる「重過失」という概念も、物事の判断基準の参考になりそうだと思いました。重過失とは下記を指します:
- わずかな注意をしさえすれば簡単に結果を予測できたにも関わらず、怠慢により注意を怠った過失
- または、法的義務や他者への結果を無謀に無視した、意識的で自発的な作為または無作為
前者は概ね同意するものの、「怠慢だったかどうか」は外から判断が難しい点に注意が必要だとは思いました。怠慢だったから注意を怠るのではなく、純粋に気が回っていなかった可能性は往々にしてあると思うからです。
後者は要するに、会社や他者にどのような結果を与えるかをある程度予見できていたはずなのに、意図的に何かをしたりしなかったりすることでしょうか。たとえば、ある作業をすばやく完結させることのみに着目し、ものすごく大きなEC2インスタンスを立ててそのリソースを潤沢に使って処理を済ませた、みたいな行為がありえるでしょうか。たしかに作業はすばやく済むかもしれませんが、それをすると月の利用料金が膨大になる可能性があります。
こうした重過失については、1on1を組んでちゃんと何が問題だったかを伝え、一緒に解決策を練るべきだとのことです。その際、人を責めるのではなく問題が問題であると指摘するようにするのが重要です。
まとめ
ソフトウェアアーキテクトの意思決定を支えるよい一冊だなと思いました。大半のミスは、知識不足ではなく判断力不足であるという箴言は、今後も心に留めながら日々の業務に取り組みたいと思います。ソフトウェアアーキテクトに関連する類書は、洋を問わず知識偏重な傾向にあるように思っており、この点を指摘する文章や本は今までになかったように思います。目覚めさせられる読書体験でした。
アーキテクトに関する本だとたとえば、下記あたりでしょうか。昔読みましたが、意思決定に関する話はなかったかもなと思います。
こちらの書籍は、どちらかというと考案した設計をどう伝えるかをメインにしていた記憶があります。
これらの書籍は本書とは相補し合う関係にあると思います。あわせて改めて読み返しておきたくなりました。
一方で、用語や単語に対する定義づけが甘いと思われる箇所が多々あり、それが一般的によく言われる定義の文脈で使用しているのか、筆者独自の定義で使用しているのかわかりにくい箇所があったと思います。たとえば「既知の未知」は、調べてみるとプロジェクトマネジメントでよく使われる用語のようですが、であればそれに依拠していることをどこかで示して欲しかったかもしれません。他にも、「不確実性」という単語は確かに出てくるのですが、一般的な意味なのかテクニカルタームなのかわかりにくいと感じました。その辺りは、この記事を書くタイミングで少し深ぼる必要があったように思います。翻訳に対する指摘ではなく、原著の構成に対する指摘であることを書き留めておきます。
