導入 見出しへのリンク

自分は具体的で短期的な問題を解くのは得意な方だと思っている。目の前に課題があれば、それを分解して、ネクストアクションを決めて、実行する。この繰り返しで仕事を前に進めてきた。

でも最近、それだけでは足りないと感じることが増えた。たとえばo11yを導入したいという話が出たとき、「そもそも何の問題を解決するために導入するのか」が決まっていないことが多い。流行りの技術だから、みんなやっているから、という理由で有償のサービスを導入しようとしていないか。本当にそれが必要なのか。こういう疑問は常にある。

o11yに限らず、手段が先に来て、問題設定が曖昧なまま進んでしまうケースはよくある。本当に大事な問題というのは実は少なくて、しかも抽象的で、そもそも「これが問題だ」と気づくこと自体が難しい。改善に数ヶ月〜数年かかるような大きな問題ほど、目の前の具体的なタスクに追われていると見えなくなる。

そんなときに「ネガティブ・ケイパビリティ」という概念を知った。答えの出ない事態に耐える能力のことだ。自分に足りないのはこれだと思った。

この記事では、ネガティブ・ケイパビリティと制約、そして意思決定の関係について考えたことを書く。

ネガティブ・ケイパビリティとは 見出しへのリンク

ネガティブ・ケイパビリティとは、「どうにも答えの出ない、どうにも対処しようのない事態に耐える能力」のことだ。もともとは詩人のキーツが使った言葉で、不確実さの中に留まり続ける力を指している。

ただし、ネガティブ・ケイパビリティは諦めることを意味していない。いまは変えられないとしても、その不確実な状態に努力して耐え、希望を見いだしていく態度だ。

対になるのがポジティブ・ケイパビリティ、つまり問題を分析して解決する能力だ。エンジニアとして日常的に鍛えているのはこちらの方だと思う。バグを見つけて直す、パフォーマンスを改善する、設計を整理する。こうした問題解決のスキルはもちろん大事だが、問題解決が強調されすぎると、問題設定の時点で問題を平易化してしまう傾向がある。複雑さを削ぎ落として、自分が解ける形に変えてしまう。

shibayu36さんは、拙速に解決策を見出すのではなく、宙吊りの状態に耐えることで深い理解に行き着くと書いている。マネージャーの文脈でも、hotchemiさんが新しく入ったマネージャーが成果を出そうとして芯を外してしまう例を挙げている。問題を正しく見極める前に動いてしまうことの危うさだ。

問題設定の重要性 見出しへのリンク

本当に大事な問題というのは実は少ない。そして、そういう問題はたいてい抽象的で、そもそも問題だと認識されていない。elephant in the roomという表現があるが、自分の経験では、見て見ぬふりをしているというよりは、そこに象がいること自体にみんな気づいていないことの方が多い。

導入で触れたo11yの話もそうだ。「o11yを導入したい」という声が上がったとき、それは本当に今解くべき問題なのか。流行りの技術だから導入したいのか、それとも本当に困っていることがあるのか。Howが先に来て、Whyが曖昧なまま進んでしまう。そーだいさんが「Howだけ考えると複雑さを導入して仕事が増える」と書いているが、まさにこの話だ。作業が増えることで仕事をした気になるが、本質的な問題は解決されていない。

だからこそ、何を問題にするかという選択が最も重要になる。改善に数ヶ月〜数年かかるような大きな問題であれば、問題設定を間違えたときのコストは大きい。ここで拙速に「これが問題だ」と決めつけず、わからない状態に耐えて観察し続ける。ネガティブ・ケイパビリティが必要なのはまさにこのフェーズだと思う。

制約を見つける 見出しへのリンク

そもそも、何が「本当の問題」なのか。これを見極めるのは思ったより難しい。

ポッドキャスト「Today I Learned -シリコンバレーの現場から-」で『ザ・ゴール』が紹介されていた。物理学者でビジネスコンサルタントのエリヤフ・ゴールドラットが1984年に書いた小説仕立てのビジネス書で、制約理論(Theory of Constraints、TOC)を扱っている。工場の生産性は、いちばん遅い工程 — ボトルネック — によって決まる、というのが核の主張だ。ボトルネック以外をいくら最適化しても、全体のスループットは上がらない。むしろ、ボトルネックの前に在庫が積み上がるだけで、状況は悪化することすらある。

ソフトウェアの仕事でも同じことが起きる。問題に見えているものを片っ端から解決していくと、忙しく働いているのに全体は前に進まない、ということがある。本当の制約はどこか別の場所にあって、そこを見つけないうちに動き出すと、局所最適の集合が積み上がるだけだ。

だから、まず「本当の問題はどこにあるのか」を見つける必要がある。これを別の角度から補強する議論が、弁護士ドットコムの「制約を読まないエンジニアへ」という記事にあった。

ここでいう「制約」は、TOCのボトルネック(全体を律速する箇所)とは少し違う意味で、設計上の制約 — 何を可能にし、何を禁じるかの選択 — を指している。たとえば、型システムは「何でも入れられる変数」を禁じることでバグを減らす。RDBの正規化は冗長な表現を制約することで一貫性を保つ。UNIXの「ひとつのことをうまくやる」は責務を制限することで組み合わせ可能性を生む。自由度を増やすことが常に良いわけではなく、あえて制約を置くことで価値が生まれる、という考え方だ。

弁護士ドットコムの記事は、メルカリのマイクロサービス基盤刷新の振り返り記事をきっかけに、この「設計上の制約」の意味を論じている。中心になるのは、RESTというアーキテクチャスタイルを定義した博士論文で知られるRoy Fieldingの議論だ。Fieldingは2000年の論文で、アーキテクチャスタイルとは「制約を協調的にまとめたもの」だと定義し、優れた設計者はバズワードではなく「解こうとしている特定の問題のニーズに合ったスタイル」を選ぶべきだと書いている。

弁護士ドットコムの記事はこのFieldingの議論を引きながら、こう書く。

制約は自由の敵ではありません。制約は価値の源泉です。

そして、REST、マイクロサービス、いまはAIエージェントと、形だけが流通して、なぜその制約が置かれたのかという思想は読まれない、という構造を指摘する。「Design by Buzzword」と呼ばれる現象だ。

この「Design by Buzzword」と、自分が導入で書いた「o11yを導入したい」の話は、同じ構造だと思う。Howの形が先に流通して、Whyにある制約の思想は問われない。本当に解くべき問題 — ボトルネック — がどこにあるかを見極める前に、流行りの解決策に飛びつく。結果として、ボトルネックでないところを最適化したり、思想を読まずに形だけ真似てしまう。

『ザ・ゴール』と「制約を読まないエンジニアへ」は、それぞれ違う文脈で書かれた話だ。前者は工場の生産管理、後者はソフトウェア設計。でも二つとも、「本当の問題を見つけることが先、解決策はその後」という同じ姿勢を伝えていると思う。

そして、本当の問題は、わからない状態で観察し続けることでしか見えてこない。「これが問題だ」と決めつけて動くと、ボトルネックでないところを最適化することになる。

ここがネガティブ・ケイパビリティのいちばんの使いどころだと思っている。耐えて、本当の問題を見つける。見つけてから動く。

見えたら決める — 主語は自分にする 見出しへのリンク

問題が見えたら、自分の意見として決める。耐えるフェーズから決めるフェーズに切り替える。

ここで大事なのは、自分の意見として述べることだ。チームのコンセンサスを待ってから決めるのではなく、自分の中で「これが問題だ」と結論を出す。アラインメントを取りに行くのは、その後の話だ。

順序が逆になると、つまりアラインメントを取ってから決めようとすると、「組織として」「チームとして」という曖昧な主語に戻ってしまう。誰も決めていないものに対して合意は取れない。だから先に自分が決める。

qsonaさんの記事に出てくる「組織は話さないですよ」という言葉が端的にこれを表している。ある施策について疑問があるから推進者と議論したいと言ったところ、「組織として進めている」と返ってきた。でも組織は話さない。意見を持っているのは個人であり、その個人と直接議論すべきだ。

konifarさんも「主語を個人にする」と書いている。「法務側の要請で」「経営陣の意向で」といった集団を主語にした表現が出てきたら注意が必要で、意見を言うのはいつでも個人だ。主語が集団になると、個々人ではコントロールしにくいものだと勘違いしてしまう。

そーだいさんは「組織は意思決定しない。意思決定するのはいつだって組織の中にいる人だ」と書いている。DRIが決めないなら、自分が材料を集めて意思決定をする。その振る舞いが仕事を前に進ませる。

自分はインフラ側の仕事をしているので、問題が放置されると最終的に自分のところに来る。誰かが決めるだろうと待っていると、自分が困る。だからこそ、自分から問題を定義して、自分の意見として決めていくしかないと思っている。

問題のAlignmentを取る 見出しへのリンク

自分の意見として決めたら、次はチームとアラインメントを取りに行く。自分の中で結論が出ているからこそ、議論の出発点を提供できる。

「Alignment > Autonomy」という記事の中で、自律性(autonomy)よりもアラインメント(alignment)が大事だと語られている。自律的に動けることは良いことだが、方向が揃っていなければその自律性は無駄になる。ロケットが太陽に向かって飛んでいるとき、1度のズレが120万マイルの誤差になるという例えが出てくる。アラインメントのズレは複利で効いてくる。

これは問題設定においても同じだと思う。自分が「これが本当の問題だ」と見えたとしても、チームがその認識を共有していなければ、改善は進まない。数ヶ月〜数年かかるような大きな問題であればなおさらだ。

「自分で決める」と「アラインメントを取る」は矛盾しない。むしろ、まず自分の意見を持つことがアラインメントの出発点になる。「組織として」「チームとして」という曖昧な主語ではなく、「自分はこれが問題だと思う」と言うからこそ、そこから具体的な議論が始まる。

決めた意見は、アラインメントを取る過程で更新されてもいい。自分の見立てが甘かったとわかれば直せばいい。重要なのは、出発点を自分で用意することだ。

Liz Fong-Jonesの「Code less, engineer more」でも、チームの有限なエネルギーを本当に価値を生む場所に集中させるべきだと書かれている。何を問題にするかを揃えることは、何にエネルギーを使うかを揃えることでもある。

おわりに 見出しへのリンク

短期的で具体的な問題を解くことはこれからも続けていく。それはエンジニアとしての基本的な力で、自分の得意なところでもある。

でも、それだけでは見えない問題がある。抽象的で、言語化しにくくて、そもそも問題だと気づかれていないような問題。そこに向き合うにはネガティブ・ケイパビリティが必要だ。

ただし、耐えるだけでも足りない。見えたら自分の意見として決める。そのうえでチームとアラインメントを取りに行く。

耐える力と決める力。この二つをセットで使えるようになることが、自分のこれからの課題だと思っている。

Reference 見出しへのリンク

ネガティブ・ケイパビリティ:

意思決定・問題設定:

Alignment:

制約: