システム設計の合意形成の話

先日こんな問いについて議論になりました。

未来予測を含むような難しい状況で、システム設計やアーキテクチャを進めるための、良い方法論はあるか？

その場ではうまく自分の考えを整理できなかったので、ここで振り返って自分の頭の中を整理してみます。

先に結論を書いておくと、良い方法論は持っていません。これが正直なところです。

自分一人で全部決めてよいならそんなに難しくはありません。でも現実にはステークホルダーがいて、意見が割れます。その合意形成について、再現性のある良い方法を自分はまだ持っていません。

それでも何も考えずにやっているわけではありません。大まかには2つのプロセスで考えていそうです。

1. 事業的な合意

1つ目は、事業的な合意を取るためのプロジェクトマネジメント的なアプローチです。

何を実現したいのか。なぜそれを実現したいのか。期待は何か。どういう方法でやりたいのか。そもそもエンジニアリングが必要なのか。いつやるのが事業的にインパクトがあるのか。

こうした問いを立て、目指したいゴールから逆算します。そうすることで、開発のスコープや仕様、捨てられないところといった意思決定の基本軸が整理されていきます。

このあたりは昔読んだ「プロセスデザインアプローチ」という本の考え方が比較的しっくり来るので、それに従うことが多いです。

2. エンジニアとの合意

2つ目は、エンジニアとの合意です。そのためには設計とそのトレードオフを整理します。 未来予測を含む以上正解はありません。だからこそ、選択肢を並べ、それぞれが何をトレードオフにしているのかを整理したうえで、自分の考えを述べます。このとき、ADR や 設計ドキュメント を書くこともありますし、口頭で済ませることもあります。

ドキュメントを書くというのは、考え方を論理立てて体系的に整理することです。価値があるのは間違いありません。自分の思考も整理されますし、後から判断の経緯も辿れます。一方でそれなりにエネルギーは要ります。特に最終的な意思決定に差が出ない場合は、コストとも捉えられます。正直なところ書くことを億劫に感じることも多いですが、書かない、あるいはうまく書けずに議論に失敗した経験も多くあるため、基本的に書いて損はないと思っています。

それでもきれいには決まらない

ではトレードオフを整理すれば簡単に決まるのかというと、そうでもありません。

たとえば選択肢A・B・Cを用意して、「〜という理由でAが良い」と自分が言ったあとに、別のメンバーから「Bでよくない？」とか「自分はD（選択肢にない別案）だと思う」と返ってくることは普通にあることです。

もちろん相手の考えのほうが良いと思えば、BでもDでも取ります。結局はどのトレードオフを受け入れるかという話ですし、議論することで自分の視点では見えなかったことが見つかるからです。

ただ、判断には未来予測の要素に加えて、個人の経験に紐づいた感覚値も含まれます。これはネガティブな意味ではなく、「考え方は大なり小なり違うよね」くらいの意味です。だから正解がない以上、素直には決まりません。意見が合わないことはどうしても起きます。

結局、何をしているか

では結局どうするかというと、めちゃくちゃ考えます。徹底的に調べます。

今は Deep Research のようなものもあって調査のコストが下がったので、納得がいくまで調べます。関係者にヒアリングや質問ができるなら聞きます。そして割と四六時中そのことを考えています。というより、トレードオフを整理しないと……という状況になっている時点で、電車の中でも、帰り道でも、寝る前でも、もう考えてしまっています。

そのうえで、双方の懸念と、それぞれが描いている未来や絵姿をテーブルに並べます。相手がBを推す懸念はどこにあるのか。自分がAを推す懸念はどこにあるのか。両立する手段はないのか。それを考えます。

それでも両立しないなら、最後どっちに転ぶかはその時々です。自分が折れることもあれば、相手が折れることもあります。その場の雰囲気で決まる部分もあると思っています（雰囲気というとやや誤解を生みそうですが、きれいに言語化されていない暗黙的な合意というニュアンスです）。

つまり、再現性はありません。だから、冒頭で書いたとおり「良い方法論を持っていません」に戻ってきます。

それでも心がけたいこと

うまくできているとは言えません。でも、こうありたいと心がけていることはあります。

それは相手を尊重するスタンスをなるべく取りたい、ということです。

これはオーナーシップの問題だと思っています。チームである以上、コードベースや事業は共有資産として、みんなでオーナーシップを持つべきです。それでも「自分が意思決定をしているか」もしくは「自分が納得できる意思決定が下されているか」は、オーナーシップの感じ方に効いてきます。

だから、相手がオーナーシップを持てる選択をできるだけ尊重したいです。そう心がけています。

コードレビューを受ける際に少し楽になった考え方

PostgreSQL 18のリリースノートから個人的に気になったもの

2025年9月25日 に発表されたPostgreSQL18のリリースノートから、個人的に気になった内容を挙げていきます。
本記事の内容は、筆者がリリースノートを読んだ所感をまとめたものであり、すべてを検証したわけではありません。誤りが含まれている可能性もありますので、ご了承ください。

CKADを取得しました

先日、CKAD（Certified Kubernetes Application Developer）を取得しました。 受験レポートは調べればたくさん出てきますが、意外と最近（2025年）に近いものが見当たらないので、2025年6月時点でのレポートを残しておきます。

Gitを活用したブランチ戦略のメモ

クラウドネイティブで実現する　マイクロサービス開発・運用 実践ガイドという本を読んでいて、ブランチ戦略の説明が非常にわかりやすかったのでメモ。

読んでいた書籍

Lua（とOpenResty）に入門した

きっかけ

最近、小学生を中心にプログラミングを教える機会があり、その中でRoblox Studioによるゲーム開発に取り組んでいる子がいました。
Roblox Studio はLua言語でゲームを作成するため、質問に答える際などにLuaがある程度扱えないと困るということで触ってみました。

僕は新しい言語を学ぶ際によくポーカーの役判定ロジックを作成するので、今回もそうしています。
Luaを用いてAPIを作成する方法を調べたところ、OpenResty というフレームワークでできそうだったため、OpenRestyを利用しています。

「AIと資本主義」というNRIの特集が面白かった

以下の特集記事が面白かったので、自分なりに雑に咀嚼しておきます。 www.nri.com

記事の全文は以下のPDFです。

https://www.nri.com/content/900034006.pdf