Christie Wilson (著)Jez Humble , Eric Brewer (原文)
オライリー・ジャパン (2024/4/26)

これは良書。

少し専門的すぎるかと思っていたけど、今の自分にベストマッチなとても分かりやすい入門書でした。

継続的デリバリーは以下の2つの状態を維持すること。

• いつでも安全にソフトウエアの変更を提供することが出来る。
• ボタンを1つ押すぐらい簡単に、そのソフトウエアをデリバリーできる。

そのために、人間が間違えそうなことや障害になりそうなことはすべて一連のパイプラインとして自動化する。

そして、その自動化がどうすればどういう効果が得られるかは前回『LeanとDevOpsの科学』でみたように実証された有効な指標が確立されている。

重要と感じたのは、

• できること（間違えそうなこと、繰り返し処理すること）は自動化する。
• テストをシグナルとして扱い、維持する。
• すべてをコードとして扱う。

このあたり。

これは組織のマネジメントやBIMを実装していくうえでも大きな示唆を与えてくれる。

仕組み化は「人が間違えやすい場所から人を遠ざける」

これらの考え方は、ソフトウェア開発の現場に限った話ではない。
むしろ印象的だったのは、継続的デリバリーが一貫して人間の不完全さを前提に設計されている という点だ。

「できることを自動化する」というのは、人を減らすためでも能力を疑うためでもない。
人が間違えやすい場所から人を遠ざける ための設計だといえる。

属人的な判断や、毎回思い出しながら行う手順は、経験を積んでも不安定さを内包し続ける。
それらを仕組みに預けることで、人は本来向き合うべき判断に集中できるようになる。

これは組織における業務を組み立てるうえでも、高度で複雑な情報を扱うBIMを誰でも使えるようにする上でも重要な視点だと思う。

人間の不完全さを前提として、組織を組み立て、BIMを取り扱えるようにする。これを徹底することで快適な環境が実現され、それぞれの業務を本来の価値創造に向けられるようになる。

テストは「合否」ではなく「状態を知らせるもの」

本書でも再三強調されているように「テストをシグナルとして扱う」という考え方も重要。

継続的デリバリーを開発環境に組み込んでいく中で、機能を実装するコードと並行もしくは先行して、その部分のテストをかなりのリソースを使って作成する、というのが新鮮だった。

• いつでも安全にソフトウエアの変更を提供することが出来る。
• ボタンを1つ押すぐらい簡単に、そのソフトウエアをデリバリーできる。

この2つを実現するために、それなりのコストを負担するわけだが、これが将来のトラブルの芽を未然にキャッチし大きな損失を回避することを可能にするし、「何か不具合が紛れ込んでしまうかもしれない」という恐怖を大きく緩和してくれる。

ここで、テストは何かを「通す／落とす」ための儀式ではない。
システムの状態が、これまでと同じように正常に機能しているか、変わり始めているか を知らせるためのものであり、シグナルとしての機能を阻害するノイズを嫌う。

テストを「書く」ことよりも、テストが信号として機能し続けているか を保つことが重要になる。

これも組織の仕組み化やBIMの導入において重要な視点になる。

本筋から外れたり、不具合の芽が発生していないかをキャッチするシステムが組み込まれていれば、日々の業務、特に心理面での負担はかなり低減されるだろう。

「すべてをコードとして扱う」という態度

継続的デリバリーにおける「コードとして扱う」という言葉は、単にプログラムを書くことを意味していない。

手順、判断基準、設定、前提条件。これまで人の頭の中や経験に依存してきたものを、再現可能な形に落とす という姿勢だ。

これは、先に上げた自動化やシグナルをキャッチするシステムに同期させていくことが前提となる。

いくら、手順や基準を作成しても、それが守られなければ意味がないし、多くは期待通りには機能しない。それらと並行して、それらが守られている状態を維持するシステムを構築し、あらゆる業務をこのシステムで扱えるものとして定義しシステムに載せていく。これが「すべてをコードとして扱う」ことの意味だろう。

BIMテンプレートはデータに対する思想の固定化である

この考え方は、BIMのテンプレート設計と強く重なる。

レイヤ構成、命名規則、さまざまな設定とそれらの関係性。
これらは単なる「初期設定」ではなく、毎回考えなくていいようにするための意思決定の集積 だ。

自由度を奪うためではなく、迷いや事故を減らし、安全に設計を進めるための土台。
テンプレートは、データに対する思想を構造として埋め込む行為だと言える。

なんとなくは感じていたけれども、ソフトウエア開発の領域は、データに対する思想をどう構造として埋め込むかを徹底してきた。当然BIMを取り扱うアプリケーションの思想にはソフトウエア開発領域の蓄積が活かされていることだろう。

BIMを扱う以上は、このあたりの過去の、もしくは現在進行系の知見を理解し活用することは必須なのではないか。それによって得られるものはかなり大きいのではないか。そんなことを最近強く感じている。

個人の頑張りに依存しないという選択

こうして見ていくと、継続的デリバリーが目指しているのは、優秀な個人に支えられたシステムではない。

誰が関わっても、変更が怖くならず、壊れにくい状態を保てること。
能力や気合ではなく、構造で品質を担保する という選択だ。

これはソフトウェアに限らず、組織やBIMの運用を考えるうえでも、多くの示唆を与えてくれるように思う。

ここから核心として

ここまで述べてきた継続的デリバリーに関する議論は、一般的にはソフトウェア開発の効率化や品質向上の文脈で語られる。しかし、ここから先で扱いたいのは、そのような実務的・技術的な射程ではない。むしろ私が関心を持っているのは、継続的デリバリーという思想が暗黙のうちに前提としている、人間観やシステム観、そして世界との関係の捉え方そのものである。

それは、環境問題や資本主義的生活様式といった、より大きく、かつ容易に答えの出ない問題系と接続したときにこそ、はっきりとした輪郭を持ちはじめる。

資本主義的生活様式と不可視化された関係性

環境問題への対応が困難である理由は、単に技術が不足しているからでも、人々の意識が十分に高まっていないからでもない。より根本的には、私たちの生活そのものが、すでに資本主義的な世界との関係の持ち方を唯一の前提として組み立てられているという点にある。

資本主義は、世界との関係を商品化という媒介に集約することで、極めて高い安定性と再現性を獲得してきた。エネルギー、食料、住環境、労働、時間──それらはすべて、貨幣を通じて取得・管理可能なものとして整理される。この構造は、利便性と引き換えに、私たちの生活を一見すると自由で選択肢に満ちたものに見せてきた。

しかし同時に、資本主義は、「世界との関係の持ち方が本来は複数あり得る」という事実そのものを不可視化してきた。選択肢は増えているように見えるが、それらはすべて「買うか、買わないか」「効率的か、非効率か」といった、同一の判断形式の内部に回収されている。ここで問題となるのは選択肢の数ではない。選択の形式が一種類に固定されていること、その固定が当たり前として受け入れられていることにある。

この意味で、資本主義が実現しているのは、すべてが商品化される、実は極めて窮屈で不自由な世界であると言うこともできる。世界との関係が一つの型に収束していくこと、それ自体が問題の核心である。

仕組み化の意味を反転させる

この状況に対して、より良い行動を促す仕組みや、合理的な選択を後押しする制度を設計することは、一見すると有効に見える。しかしそれらは多くの場合、同じ判断形式を前提としたまま、その内部での最適化を進めるにとどまる。

ここで必要なのは、仕組み化そのものの意味を反転させることだ。私がここで考えている仕組み化の反転とは、ある振る舞いを正解として固定化し、それを効率よく再生産するための構造をつくることではない。むしろ、振る舞いが特定の型に固定化しつつあることを検知し、世界との関係の取り方が再び多様化しうる状態へと開いていく構造を、あらかじめ内包することである。

それは、より良い答えを提示するための仕組みではなく、答えが一つに収束していくこと自体を不安定化させるための設計である。振る舞いが固定され続けることに対して、システムが静かに違和感を蓄積し、別の可能性へとずれる契機を内側から生み出す。そのような構造を考えたい。

人間の不完全さを前提とする思想

この文脈で改めて継続的デリバリーを見直すと、そこには一貫した人間観が見えてくる。人は必ず間違える。人は容易に流される。長期的な正しさよりも、短期的な容易さを選びがちである。継続的デリバリーは、こうした人間の不完全さを克服しようとはしない。教育や規範によって矯正することもしない。

それでも破綻しないために、観測・フィードバック・再調整といった手続きを、システムの中核に据える。重要なのは、正しい行動を取らせることではなく、誤った方向に進んでいることに気づき、戻れる状態を常に残しておくことである。

この態度は、環境問題に対してもそのまま適用できる。人々が容易に資本主義的生活様式に流されてしまうことを、失敗や罪として扱わない。その前提に立ったうえで、それでも別の振る舞いに戻れる経路が消滅しないよう、構造そのものを設計する。この視点は、従来の意識改革論や行動変容論とは異なる地点に立っている。

依存という構造から見た対比

ここで鍵となるのが「依存」という概念である。依存は否定すべきものではない。人間も社会も、必ず何かに依存して成立している。問題は、依存が存在するかどうかではなく、どこに、どのようなかたちで固定されているかにある。

資本主義的システムは、依存の対象を貨幣や市場といった外部に固定し、その解除コストを極端に高くすることで安定する。依存していること自体は不可視化され、別の世界との関係の持ち方は非現実的なものとして排除されていく。依存は不可逆的な構造として組み込まれている。

一方で、継続的デリバリー的なシステムが生みだす依存は性質が異なる。それは特定の正解や形への依存ではなく、観測し、フィードバックを受け取り、再調整を行うという機能への依存である。ここでは依存そのものが可視化され、入れ替え可能であり、常に更新の対象となる。

熊谷晋一郎は、自立とは何者にも依存していない状態ではなく、「依存先を増やすことで、一つ一つの依存先への依存度が極小となり、あたかも何者にも依存していないかのような幻想を持てている状況」であると述べている。この視点から見ると、資本主義における固定化された依存の形式は、人々から自立の機会を奪うものだと言えるだろう。同時にそれは、環境の中に本来存在しているはずの分散的な依存可能性を不可視化している。

資本主義が「依存を固定することで安定するシステム」だとすれば、継続的デリバリーは「依存を動かし続けることで更新可能性を保つシステム」だと言える。この差異は、単なる技術論ではなく、世界との関係の結び方そのものに関わる構造的な違いである。
（さらに、ソフトウェアの領域では、常に変更は生じることを前提としたシステムへと進化し続けている。それについては、次の読書記録で考えたい。）

動態再起論との接続

ここで、動態再起論との接続が見えてくる。動態再起論とは、環境の中にもともと存在していた「依存度を下げた、あるいは分散的な依存を可能とする振る舞いが生じうるアフォーダンス」を、再び読み取るための思考と実践の技術体系である。

むしろ重要なのは、世界との関係がある一点に固定されてしまったときに、その固定を検知し、わずかにずらし、再び動かすための思考と実践の技術であるという点にある。ここで言う「再起」とは、元に戻ることではない。状況の変化や失敗を織り込みながら、異なる関係性を取り結び直すことを意味している。

この視点に立つと、環境問題への処方箋の一つは、商品化の流れの中で人々が手放してしまった技術や知恵を、再び手元に取り戻すことだと考えられる。それは懐古的な復元ではない。大規模な転換を一気に実現することでもない。むしろ、今の環境条件の中で、自分たちが再び引き受けられることを一つずつ取り戻していくという、極めて地味で、しかし確実な実践の積み重ねである。

動態再起論が目指しているのは、別の理想社会の設計図ではない。世界との関係が固定されてしまったことに気づき、その固定を緩め、再び動かすための思考の回路を増やしていくことである。その意味で、継続的デリバリーが示しているのは、完成や到達ではなく、再起し続けるための条件なのだと言える。

思索を続けるための芽として

思索を続けるための芽として

ここまでの議論は、環境問題に対する解答を与えるものではない。具体的な行動指針を提示するものでもない。むしろこれは、どのような姿勢でこの問題と向き合い続けるのか、その思考の筋道を自分自身のために確認するための思索である。

世界との関係が一つの型に固定されていくとき、その固定を感知し、わずかにずらし、再び動かす。そのための構造や思考を、試行錯誤しながら組み替え続けること。継続的デリバリーが示しているのは、完成された理想像ではなく、壊れながらも更新し続けるための構えである。

その構えを、環境問題や生活の構造、そして思考の枠組みへとどう接続できるか。ここから先は、その問いを抱え続けること自体が、ひとつの実践なのだと思っている。

次は『ソフトウエアアーキテクチャの基礎』を読もうと思っている。初めの数ページをめくっただけだが、そこではすべてがトレードオフの中で設計されているという視点が強く示されていた。更新し続けられるシステムはいかにして可能か。その問いに対する次のヒントは、どうやらそのあたりに埋め込まれていそうだ。