最終更新日：
オーナーシップは、大規模な組織で判断、品質、相談先を明確にするために必要であり、主体性や当事者意識を支える概念でもある。しかし、それが「領域を健全に保つ責任」ではなく「排他的に決める権利」として運用されると、責任回避、縄張り化、目的置換を生む。共有資産や境界上の問題は担当表からこぼれ、つなぎの仕事は気づいた人や断りにくい人の善意に依存しやすくなる。
本稿は、その副作用を避けるために、オーナーシップをスチュワードシップとして設計し直すことを提案する。スチュワードシップとは、領域を囲い込むことではなく、領域の健全性を保ち、他者が安全に関与できる条件を整え、境界で起きた問題を組織学習につなげる責任である。必要なのは、越境する個人を英雄にすることではない。共有資産への時間と予算、低リスク変更の入口、高リスク変更の合意経路、見えない仕事の評価、利用者が関われる統治の仕組みを用意することである。
よい組織は、誰の仕事でもない仕事を、誰かの勇気だけに預けない。越境する責任を、正当性、評価、手続き、権限、保護を備えた仕事として制度化する。そのときオーナーシップは、所有権からスチュワードシップへ変わる。
大きな組織では、仕事を分けることから設計が始まる。プロダクト、サービス、機能、コンポーネント、職能、地域、顧客セグメント。どの軸で切るにせよ、分業は欠かせない。全員が常に全体を見ようとすれば、理解し、判断し、調整すべきことが増えすぎて、意思決定は遅くなり、責任の所在も曖昧になる。だからこそ組織は、担当範囲を定め、責任者を置き、各領域の判断を速くしようとする。
しかし、ここに最初の難しさがある。責任範囲を明確にするほど、範囲と範囲のあいだもまた明確になる。組織設計の古典的な議論では、専門化によって分化した組織は、同時に統合の仕組みを必要とすると説明されてきた。Lawrence and Lorsch (1967) は、環境の違いに応じて部門が分化する一方で、成果を出すには統合が必要になることを示した。Galbraith (1974) も、不確実性が高い仕事では、組織が処理すべき情報量が増え、横断的な調整能力が重要になると論じている。
ソフトウェア開発組織でも同じことが起こる。チームをサービス単位に分ける。基盤チームを置く。コンポーネントごとにオーナーを決める。こうした分割は、多くの場合、正しい判断である。ところが、障害対応、技術的負債、共通ライブラリ、ドキュメント、監視、データ移行、ユーザー体験、セキュリティ、運用改善は、きれいに一つの領域へ収まらない。複数のチームにまたがり、誰もが少しずつ関係しているのに、誰か一人の明示的な責任ではない仕事が残る。
本稿では、この種の仕事を「隙間仕事」と呼ぶ。隙間仕事とは、重要であるにもかかわらず、既存の担当表、バックログ、評価制度、意思決定プロセスのどこにも十分に置かれていない仕事である。単なる雑用ではない。分業された組織が失いやすい全体性を補い、境界をまたぐ問題を処理可能にするための仕事である。
たとえば、ある機能の変更が別チームの運用負荷を増やしていることに気づく。誰も保守していないドキュメントが、オンボーディングの障害になっていると分かる。共通基盤の小さな不整合が、複数チームの開発速度を落としている。こうした問題を見つけて手を伸ばす人は、組織にとって貴重である。Conway (1968) が指摘したように、システムの構造はそれを作る組織のコミュニケーション構造を反映しやすいため、境界上の問題はソフトウェアの問題としても表面化する。
それでも、隙間仕事に気づき、取り組み、誰かを助ける行為が常に歓迎されるとは限らない。外からの支援は、受け手にとっては助けではなく、介入、批判、あるいは責任範囲への侵入に見えることがある。「なぜあなたがそれをやるのか」「それはうちの領域ではないのか」「その変更の責任は誰が持つのか」という問いは、単なる感情的反発ではない。境界を引いて仕事を進める組織では、当然に生じる問いである。
したがって、本稿の論点は「善意の人が報われない」という話ではない。より重要なのは、善意に依存しないと隙間仕事が処理されない組織設計そのものである。オーナーシップは、大規模な仕事を統治可能にするために必要である。現場の人が自分たちの仕事として引き受け、責任ある判断をするためにも欠かせない。しかし、オーナーシップを主体性ではなく領域の所有権としてだけ運用すると、境界の内側は守られても、境界のあいだに落ちた仕事は扱いにくくなる。
本稿は、オーナーシップを否定しない。むしろ、オーナーシップが必要だからこそ、その副作用を見る。そして、領域を囲い込むためのオーナーシップではなく、領域を世話し、必要なときには他者と接続する責任としてのスチュワードシップ1へ、どのように運用を変えられるかを考える。
オーナーシップは、しばしば組織の冷たさや縄張り意識と結びつけて語られる。しかし、本来のオーナーシップは悪ではない。むしろ大規模な組織では、複雑な仕事を統治可能にするための基本的な仕組みである。誰が判断するのか、誰が品質を見ているのか、どこへ相談すればよいのかが分からなければ、仕事は前に進まない。
全員が常に全体を見ようとする組織は、一見すると協調的に見える。だが、実際には理解・判断にかかる負担と調整コストがすぐに限界を迎える。すべての会議に全員が出る。すべての変更を全員が理解する。すべての意思決定に全員が合意する。これは、小さな集団では美徳になりえても、規模が大きくなるほど現実的ではなくなる。だから組織は、役割を分け、担当範囲を定め、権限を委譲する。
組織設計の古典的な論点は、分化と統合の両立である。分化とは、専門性や環境の違いに応じて、組織を異なる単位へ分けることである。統合とは、その分かれた単位を、全体の成果へ向けてつなぎ直すことである。Lawrence and Lorsch (1967) は、環境の違いに応じた分化と、それを束ねる統合の必要性を論じた。オーナーシップは、この分化を実務上扱える形にするための技術だと言える。
ソフトウェア開発組織では、この必要性は特に分かりやすい。決済、検索、認証、データ基盤、モバイルアプリ、社内ツール、セキュリティ、運用など、対象ごとに知識もリスクも異なる。あるチームが自分たちのサービスを深く理解し、日々の変更に責任を持つからこそ、判断は速くなる。共通基盤やプラットフォームを担うチームが存在するからこそ、各プロダクトチームはすべてを自前で抱えずに済む。Team Topologies は、チーム間の相互作用を設計対象として扱い、各チームが理解し判断できる複雑さの範囲を設計することの重要性を示している（Skelton and Pais, 2019）。
また、オーナーシップは人の態度にも働きかける。自分たちの仕事として引き受ける態度があるからこそ、現場に近い判断は生まれ、品質や継続的改善への責任感も育つ。担当範囲があることは、単に「ここからここまでしかやらない」と線を引くためではない。日々の変化を見ている人が、利用者や運用の実態に即して判断し、必要な改善を続けるための足場でもある。
不確実性が高い仕事では、階層的な命令や事前計画だけでは足りない。状況が変わるたびに、現場に近い場所で情報を処理し、判断し、調整する必要がある。Galbraith (1974) は、不確実性が高まるほど組織が処理すべき情報量が増えると論じた。オーナーシップは、その情報処理を一か所に集中させないための仕組みでもある。責任ある単位へ判断を寄せることで、組織は複雑さを扱いやすくする。
ただし、本稿が注目したいのは、まさにこの点である。境界を引くことは、同時に境界をまたぐ問題を生む。サービスの責任者を決めれば、そのサービスの内側は扱いやすくなる。しかし、複数サービスにまたがる障害、共通ライブラリの保守、データ定義の不一致、ユーザー体験の分断、監視やアラートの標準化は、一つの境界の内側だけでは閉じない。
境界は問題を消すのではない。問題を扱いやすい単位へ分ける。その結果、境界の内側の問題は見えやすくなり、境界の外側や境界そのものにある問題は見えにくくなる。Conway (1968) が示したように、システムの構造は組織のコミュニケーション構造を反映しやすい。組織の境界が硬くなれば、その硬さはソフトウェアの接続面にも現れやすい。
したがって、オーナーシップ設計で問うべきことは「誰が持つのか」だけではない。「誰が境界を見ているのか」「共有資産を誰が世話するのか」「複数領域にまたがる例外をどこで扱うのか」も同時に問わなければならない。境界内の責任と、境界をまたぐ責任は、片方だけでは足りない。
オーナーシップは、問題を解くために境界を引く技術である。しかし、その境界が組織の思考停止を生むなら、技術は制度疲労を起こす。必要なのは、オーナーシップを捨てることではない。オーナーシップが生む境界を前提にしながら、その境界をまたぐ仕事を設計することである。
オーナーシップは必要である。しかし、必要な仕組みほど、運用を誤ると強い副作用を持つ。ここでは、オーナーシップが「領域をよくする責任」ではなく「領域を所有する権利」として扱われたときに起こる逆機能を、責任回避、縄張り化、目的置換の三つに分けて考える。
第一の逆機能は、責任回避である。責任範囲を明確にするほど、「それはうちの責任ではない」と言うための論理も明確になる。担当表、コンポーネントオーナー制、RACI2 のような整理は、曖昧さを減らすために用いられる。だが、曖昧さの中にある仕事まで自然に処理してくれるわけではない。むしろ、担当範囲の外に置かれた問題は、より正式に「範囲外」として扱われることがある。
たとえば、ある障害の根本原因がアプリケーション、基盤、運用手順、監視設計の複合にあるとする。各チームは、自分たちの範囲に閉じた改善なら実行できる。しかし、境界をまたぐ再発防止策は、誰のバックログにも載らない。結果として、個別の修正は進むが、同じ種類の問題を減らす全体の取り組みは残り続ける。責任が弱すぎる場合だけでなく、責任が局所化されすぎる場合にも、組織は問題を処理できなくなる。
第二の逆機能は、縄張り化である。オーナーシップは、主体性や愛着を支える一方で、運用次第では心理的所有感を強めすぎることがある。Pierce, Kostova, and Dirks (2001) は、組織における心理的所有感が、人の態度や行動に影響することを論じている。自分たちのプロダクト、自分たちのサービス、自分たちのコードであるという感覚は、品質への愛着や長期的な責任を支える。その意味で、心理的所有感は組織にとって有益である。
しかし同じ感覚は、外部からの関与を脅威として受け取らせることもある。「ここは自分たちの領域だ」「外から触られたくない」「事情を知らない人に口を出されたくない」という反応は、単なる頑固さではない。自分たちが責任を負っている領域を守ろうとする自然な反応でもある。Brown, Lawrence, and Robinson (2005) は、組織内の縄張り化が、領域を守る行動として現れることを論じている。
このとき、外部からの支援や指摘は、改善提案ではなく、介入、批判、支配として受け取られうる。越境支援を設計する際は、権限の有無だけでなく、事前調整、関係性、評価や信頼への影響も確認したい。Carlile (2004) は、境界を越える知識の扱いには、単なる情報の移転だけでなく、翻訳や変換が必要になることを論じている。したがって、越境的な助言では、内容の正しさに加え、誰が、どの場で、どの合意を経て入るのかが重要になる。
第三の逆機能は、目的置換である。オーナーシップは本来、顧客価値、システム健全性、組織の学習を支えるための手段である。ところが制度が硬直すると、「オーナーを尊重すること」「担当範囲を守ること」「正しい承認経路を通すこと」自体が目的になる。Merton (1940) が官僚制の逆機能として示したように、手続きは本来の目的から離れ、手続きそのものを守る方向へ人の行動を導くことがある。
目的置換が起こると、組織は奇妙な判断をする。顧客影響がある問題でも、担当チームの優先順位に入っていなければ待つ。複数チームに関わる品質問題でも、誰かが正式なオーナーになるまで放置する。すぐに直せるドキュメントの誤りでも、所管部署の確認を待つうちに古くなる。こうして、境界を守ることが、境界を作った目的を上回ってしまう。
この三つの逆機能は、互いに独立しているわけではない。責任回避は、縄張り化によって正当化される。縄張り化は、目的置換によって制度的に守られる。目的置換は、責任範囲の明確さによって見えにくくなる。問題は、オーナーシップが足りないことだけではない。オーナーシップが所有権として強くなりすぎることでもある。
だからこそ、組織はオーナーシップを「触らせない権利」としてではなく、「健全に扱えるようにする責任」として設計し直す必要がある。領域を守ることは重要である。しかし、領域を守ることだけでは、境界に落ちた問題は救えない。
では、その隙間仕事は具体的にどのような仕事なのか。隙間仕事は、単なる雑用ではない。誰かが親切で引き受けている細々した仕事、という理解だけでは、その重要性を見誤る。隙間仕事とは、分業された組織が失いやすい全体性を補う調整作業である。境界の内側だけを見ていては処理できない問題を、組織が扱える形に変える仕事である。
第一に、共有資産の世話がある。共通ライブラリ、ドキュメント、開発環境、テスト基盤、監視、データ品質、アーキテクチャ方針。これらは多くの人が便益を得る一方で、保守の責任が特定のチームに明確に置かれていないことがある。便利なものほど、動いている間は存在を意識されない。壊れたとき、古くなったとき、新しい人が使えなかったときに、初めて問題として現れる。
共有資産は、厳密な意味で公共財そのものではない。だが、多くの人が便益を得る一方で、維持コストを誰が負うのかが曖昧になりやすい点で、公共財に似た集合行為問題を生む。Olson (1965) は、集団が共通利益を持っていても、各人が自発的にそのためのコストを負うとは限らないことを論じた。組織内の共有資産でも、類似した構造が起こる。全員がドキュメントの整備を望むが、今日の評価に直結しなければ、誰も時間を確保しない。
第二に、境界上の問題がある。チーム間インターフェースの不整合、仕様理解のずれ、依存関係の放置、障害時の責任境界、ユースケースを横断するユーザー体験の分断。これらは、一つのチームだけを見ると小さな問題に見える。しかし、利用者や運用者から見ると、全体として大きな摩擦になる。Carlile (2004) は、境界を越える知識の移転には、単なる情報共有だけでなく、翻訳や変換が必要になることを論じている。境界上の仕事は、まさにこの翻訳と変換を担う。
第三に、例外処理がある。通常の担当範囲では扱いにくい問題、緊急度は高いが恒常的な担当がない問題、組織変更や人員変更、技術移行期に発生する問題である。平時の組織図は、平時の仕事を処理するために作られている。だが、移行期には、古い責任範囲と新しい責任範囲のあいだに空白が生まれる。そこで起こる仕事は、必要であるにもかかわらず、正式な居場所を持たない。
第四に、つなぎの仕事がある。人をつなぐ。文脈を補う。誤解を減らす。意思決定を前に進める。放置されている論点を見える化する。Reilly (n.d.) は、こうしたつなぎの仕事を "glue work" と呼び、組織に不可欠でありながら評価されにくい仕事として説明している。本稿では、訳語を固定しすぎず「つなぎの仕事」と呼ぶ。成果物だけを見ると残りにくいが、これがなければ成果物が生まれない種類の仕事である。
隙間仕事が厄介なのは、必要性が事後的にしか見えない点にある。ドキュメントが整っているとき、それを整えた人の貢献は見えにくい。監視が適切に設計されているとき、障害の発見が速かった理由は目立たない。チーム間の誤解が事前に解消されているとき、回避された衝突は記録されない。問題が起こらないことを成果として評価するのは、組織にとって難しい。
さらに、隙間仕事は組織市民行動として扱われやすい。組織市民行動とは、正式な職務範囲を超えて組織に貢献する行動である。Van Dyne and LePine (1998) は、支援や発言のような職務外行動が組織に貢献しうることを示した。一方で、Bergeron et al. (2013)、Bolino et al. (2015)、Deery et al. (2017) は、こうした行動が評価や疲弊の面でコストを持つことも示している。これらの研究はソフトウェア開発組織の隙間仕事を直接扱うものではないが、正式職務外の支援や発言にコストが生じうるという点で、本稿の議論を支える。よい行動だからといって、無限に個人へ期待してよいわけではない。
したがって、隙間仕事を「気づいた人がやること」にしてはいけない。共有資産には、明示的な予算、時間、担当ローテーション、意思決定ルール、エスカレーション経路が必要である。Ostrom (1990) は、共有資源を持続的に管理するには、利用者自身によるルール形成や監視、段階的な制裁、紛争解決の仕組みが重要であることを示した。自然資源の議論をソフトウェア開発組織へ直接移すことはできないが、利用者がルール形成に関わること、紛争解決経路を持つこと、運用状況を見えるようにすることは、組織内の共有資産にも類推的に参照できる。ただし、それは共同体の自発性だけに頼るという意味ではない。仕事として扱うための制度が要る。
隙間仕事の正体は、善意の余白ではない。組織が複雑さを分割した結果として残る、統合の仕事である。これを見えないままにすると、組織は一部の人の気配りに依存する。見える仕事に変えれば、初めて予算を付け、優先順位を付け、評価し、引き継ぐことができる。
隙間仕事を見つけて助けることは、組織にとって有益である。だが、受け手にとっても常に有益に見えるとは限らない。ここを誤ると、越境的な支援は、善意であるほどこじれる。助ける側は「組織全体のため」と思っていても、助けられる側は「自分たちの仕事に勝手に入ってきた」と感じることがある。
第一に、支援は能力への批判として受け取られうる。外部の人が問題を見つけ、「直しましょうか」と言う。その言葉は、助ける側にとっては自然な申し出である。しかし受け手には、「あなたたちではできないから私がやります」と聞こえることがある。特に、担当チームがすでに問題を認識していて、他の優先事項との兼ね合いで後回しにしている場合、外からの支援は事情を知らない指摘に見えやすい。
第二に、自律性への侵害として受け取られうる。チームには、チームなりの優先順位、進め方、歴史、制約がある。外から見える最適解が、内側から見ても最適とは限らない。たとえば、ある改善が技術的には正しくても、今は採用できない理由があるかもしれない。運用体制、顧客との約束、過去の事故、未公開の移行計画が関係しているかもしれない。越境者がその文脈を知らないまま手を出すと、支援は相手の自律性を乱す行為になる。
第三に、評価上の脅威になりうる。外部の人が問題を発見すると、その問題は担当者の不備として見えることがある。本人が責められていなくても、周囲からはそう受け取られるかもしれない。日本の職場を含む具体の組織で考えるなら、明示的な責任追及がなくても、「あのチームは見落としていた」という受け止めが評価や信頼に影響しないかを、制度と文化に照らして点検する必要がある。内閣府男女共同参画局（2021）の調査が示すように、職場には役割や能力をめぐる思い込みも残っている。もちろん、この調査はチーム間支援の評価影響を直接測ったものではない。ここで重要なのは、支援が相手の能力や役割への判断として読まれうる場面では、助ける側がその影響を軽く見れば相手が防御的になりやすい、という点である。
第四に、境界違反になりうる。オーナーの許可なくコード、設定、運用手順、顧客データ、セキュリティ設定に触ることは、技術的にも組織的にも危険である。本番影響、セキュリティ、個人情報、データ移行、契約上の責任が関係する領域では、善意の変更が事故になる可能性がある。越境行為は、善意であることによって免責されない。
この問題は、心理的安全性とも関係する。心理的安全性とは、対人関係上のリスクを取っても罰せられたり恥をかかされたりしないと感じられる状態である。Edmondson (1999) は、チームにおける心理的安全性が学習行動に関係することを示した。越境的な支援が機能するには、助ける側だけでなく、助けられる側も安全でなければならない。指摘されても評価や信頼が不当に傷つかない。支援を受けても評価が下がらない。断っても関係が悪くならない。そうした条件が必要である。
したがって、支援は「相手の不備」ではなく「境界上に発生した構造的リスク」として提示する方がよい。「このチームが見落としている」ではなく、「この変更は二つの領域にまたがっていて、今の担当表では扱いにくそうです」と言う。「直しておきます」ではなく、「影響範囲を一緒に確認し、必要ならこちらでプルリクエストを出せます」と言う。問題の置き方が変わるだけで、相手が受け取る意味は大きく変わる。
Schein (2013) の Humble Inquiry は、この場面で役に立つ。Humble Inquiry は、相手を診断して答えを与えるのではなく、問いを通じて相手の文脈を学ぶ態度を重視する考え方である。越境者は「正解を持ってきた人」ではなく、「処理可能な選択肢を増やす人」として入るべきである。最初の言葉は、提案よりも確認でよい。「この挙動は、いま意図された状態でしょうか」「この変更は、どのチームが一番文脈を持っていますか」「手伝えるとしたら、どの形が負担になりませんか」と問う。
境界を越える支援には、正当性と手続きが必要である。正しいことを言うだけでは足りない。誰の責任で、どの範囲を、どの合意のもとで扱うのかを明確にする必要がある。Carlile (2004) が示すように、境界をまたぐ知識は、単に伝達すればよいものではない。互いの文脈を翻訳し、場合によっては仕事の進め方そのものを変換しなければならない。
助けが迷惑になるのは、人が善意を嫌うからではない。支援が、相手の専門性、自律性、評価、責任範囲を脅かす形で届くからである。だから、越境支援を個人の勇気や人柄に任せてはいけない。助ける側も、助けられる側も、安心して扱える作法が必要である。
5章までで見てきた問題は、オーナーシップが不要だという話ではない。むしろ、責任の所在を曖昧にしたままでは、隙間仕事は放置され、共有資産は劣化し、善意の支援は介入として受け止められやすくなる。必要なのは、オーナーシップを「排他的に決める権利」から「領域を健全に保つ責任」へ意味づけ直すことである。
本稿では、この責任をスチュワードシップと呼ぶ。スチュワードシップとは、ある領域を排他的に所有する権利ではなく、その領域の健全性を保ち、境界上の問題を扱い、他者が安全に関与できる条件を整え、そこから組織が学習できるようにする責任である。
この言葉は、経営学の stewardship theory とも響き合う。stewardship theory は、経営者を自己利益のために監視される代理人としてだけではなく、組織目的に向けて行動しうる受託者として捉える議論である（Donaldson and Davis, 1991; Davis, Schoorman, and Donaldson, 1997）。Hernandez (2012) は、スチュワードシップを心理的・関係的な志向として捉え、自己利益を超えて長期的な集団の利益に向かう側面を整理している。ただし、本稿で扱うスチュワードシップは、経営者論をそのままソフトウェア開発組織へ移植するものではない。領域を任された人やチームが、所有者として囲い込むのではなく、健全性、参加、学習に責任を持つという実務上の考え方として用いる。
第一に、スチュワードシップは、境界上の問題を扱う責任である。隙間仕事は、担当表の外に突然現れるのではない。多くの場合、複数のチーム、システム、評価指標、時間軸の境界で生まれる。Carlile (2004) が示すように、境界をまたぐ知識は、単に渡せばよいものではなく、相手の文脈へ翻訳し、必要に応じて互いの前提を変換する必要がある。したがって、スチュワードは「ここは自分たちの範囲ではない」と線を引くだけでは足りない。境界で起きている不具合を見つけ、関係者が扱える形に言語化し、次に誰が何を決めるべきかを明らかにする責任を持つ。
第二に、スチュワードシップは、領域の健全性を保つ責任である。心理的所有感は、責任感や継続的な改善を支える一方で、領域を「自分たちのもの」と感じすぎると、外部からの関与を脅威として受け止めやすくなる（Pierce, Kostova, and Dirks, 2001）。組織内の縄張り化も、資源や情報を守る行動として現れることがある（Brown, Lawrence, and Robinson, 2005）。そのため、健全性を保つとは、単に壊さないことではない。利用者が困っていないか、保守が滞っていないか、変更の入口が閉じていないか、領域が組織全体の目的に合っているかを継続的に見ることである。
第三に、スチュワードシップは、安全な参加条件を設計する責任である。支援が批判や侵入に見えるのは、支援者の態度だけの問題ではない。どこまで外部の人が触ってよいのか、どこから相談が必要なのか、誰がレビューするのかが曖昧であれば、善意の行動もリスクになる。スチュワードは門番ではない。低リスクな改善は入りやすくし、高リスクな変更には合意、レビュー、ロールバック計画を求める。つまり、参加を拒むのではなく、参加が壊れにくい条件を作る。
第四に、スチュワードシップは、見えない仕事を組織の仕事として扱う責任である。つなぎの仕事、調整、オンボーディング、ドキュメント整備、再発防止、共有ライブラリの保守は、成果物だけを見る評価では見落とされやすい。Reilly (n.d.) が "glue work" と呼ぶ仕事は組織を動かすが、個人のキャリア上は不利に働くことがある。Bergeron et al. (2013) や Bolino et al. (2015) も、組織市民行動には疲弊や評価上のコストが伴いうることを示している。さらに Babcock et al. (2017) は、昇進につながりにくい仕事を女性が引き受けたり依頼されたりしやすいことを示している。日本の職場環境については、内閣府男女共同参画局 (2021) の調査が参考になる。同調査の職場領域の一項目では、「受付、接客・応対（お茶だしなど）は女性の仕事だ」という主張に「そう思う」または「どちらかといえばそう思う」と答えた割合が、別添資料の男女別スコアで男性25.1％、女性20.1％と示されている。この調査結果は実態の調査ではなく意識の調査であり、かつ一つの設問例であるため読み方に注意を要するが、依然として、見えない仕事を任される人の属性に偏りがないか確認する価値があることを示唆する。ソフトウェア開発の現場に置き換えれば、調整、議事録、非公式な相談対応のような仕事が、職位が低い人、断りにくい立場の人、または性別やその他の属性による役割期待を向けられやすい人に偏っていないかどうか、組織の実態として検証されるべきである。スチュワードシップを掲げるなら、これらを「気が利く人の善意」ではなく、時間、評価、分担、引き継ぎの対象にしなければならない。
ここでは、ケア倫理も重要な補助線になる。ケア倫理とは、人が互いに依存し合う現実を前提に、必要に気づき、責任を引き受け、適切な能力をもって応答する実践を重視する倫理である。Tronto (1993) は、ケアを私的な美徳へ閉じ込めず、注意、責任、能力、応答という観点から政治的・社会的に捉え直した。さらに Tronto (2013) は、ケアを共同責任として扱う視点を強めている。本稿の文脈で言えば、スチュワードシップは、面倒見のよい個人を称える言葉ではない。必要な世話が誰に偏り、誰に見えず、どの制度から外れているのかを組織として扱うための言葉である。
第五に、スチュワードシップは、組織設計を学習・更新する責任である。境界問題が繰り返し起きるなら、それは個人の注意不足ではなく、責任範囲、権限、評価、チーム間相互作用の設計に問題があるというシグナルかもしれない。Ostrom (1990) が共有資源の持続的な管理に、利用者が関与できるルール、監視、紛争解決、段階的な制裁などを見いだしたことは、組織内の共有資産を考えるうえでも示唆を持つ。もちろん、自然資源とソフトウェア資産を同一視するのではない。利用者、メンテナー、費用負担、変更ルール、優先順位の決め方を曖昧にしたままでは、共有資産は善意に依存する、という統治上の類似に注目するのである。
この定義に立つと、オーナーに求められる仕事は変わる。オーナーは、自分の領域を守るだけでなく、領域が健全に使われ、必要な人が安全に関与でき、そこで起きた問題が次の学習につながるようにする人である。支援者に求められる仕事も変わる。正しいことを言うだけでなく、相手の文脈を学び、責任の所在を尊重し、参加条件に沿って関わる必要がある。
所有権としてのオーナーシップは、「ここは誰のものか」を問う。スチュワードシップとしてのオーナーシップは、「ここを誰が健全に保ち、誰が安全に関われるようにし、何を組織として学ぶのか」を問う。次章では、この定義を理念で終わらせず、組織の運用能力として実装するための段階を整理する。
では、スチュワードシップを個人の態度ではなく、組織の運用能力としてどう実装するか。スチュワードシップは、言葉として掲げただけでは定着しない。領域の健全性、境界上の問題、安全な参加条件、見えない仕事、組織学習という責任を、日々の運用に落とす必要がある。ここでは、Capability Maturity Model Integration3 のような成熟度モデルに着想を得て、スチュワードシップを自己診断するための段階として整理する。
このモデルは、認証や序列化のためのものではない。どのチームが優れているかを競うためでもない。自分たちがどこで詰まっているのかを見つけ、次に改善すべき制度を考えるための補助線である。
全体像は、次のように整理できる。
| レベル | 状態 | 実装されていること | 次に問うこと |
|---|---|---|---|
| 1 | 属人的善意 | 気づいた人、断りにくい人、面倒見のよい人が隙間仕事を引き受ける | 誰が、どの見えない仕事を、どれだけ引き受けているか |
| 2 | 名札づけ | オーナーや担当チームが決まり、相談先が見える | オーナーは何を決め、他者はどこまで支援できるか |
| 3 | 可視化 | 隙間仕事がバックログ、ふりかえり、評価面談、ロードマップに載る | 記録、時間、評価、引き継ぎの対象になっているか |
| 4 | 参加設計 | 低リスク変更と高リスク変更、相談経路、レビュー責任、裁定方法が明確になる | 誰が安全に関与でき、どこで合意すればよいか |
| 5 | 学習するスチュワードシップ | 共有資産ガバナンス、評価制度、権限、チーム間相互作用を見直す | どの境界、責任、評価、権限を更新すべきか |
レベル1は、属人的善意の段階である。隙間仕事は存在しているが、正式な仕事としては認識されていない。共有ライブラリの小さな修正、ドキュメントの更新、チーム間の調整、オンボーディングの手助け、障害後の再発防止が、気づいた人の善意に任される。仕事は進むこともあるが、誰がどれだけ支えているのかは見えない。評価されにくく、引き継がれにくく、特定の人に偏りやすい。
この段階で最初に行うことは、名簿を作ることではなく、見えない仕事の棚卸しである。「最近うまくいった仕事のうち、担当表やバックログに載っていなかったものは何か」「その仕事は誰が引き受けたのか」「同じ人が何度も引き受けていないか」を確認する。答えが曖昧であれば、組織はまだ善意に依存している。
レベル2は、名札づけの段階である。誰の仕事かわからないものに、いったんオーナーを割り当てる。これは重要な進歩である。放置されていた仕事に相談先ができ、意思決定の責任も見えやすくなる。ただし、この段階ではオーナーシップが所有権として運用されやすい。「担当は決まったのだから、その人が全部見るべきだ」「外部の人は勝手に触るべきではない」という理解に寄ると、隙間仕事は別の形で詰まる。
この段階では、オーナーの名前だけでなく、責任の中身を短く定義する。何を決める人なのか。何を守る人なのか。どの変更なら外部から支援できるのか。オーナーが忙しいとき、誰が相談を受けるのか。名札は必要だが、名札だけではスチュワードシップにはならない。
レベル3は、可視化の段階である。隙間仕事を、バックログ、ふりかえり、インシデントレビュー、技術負債管理、評価面談、ロードマップの対象にする。バックログとは、これから取り組む作業や課題を優先順位付きで管理する一覧である。ここに載らない仕事は、組織上は存在しないものとして扱われやすい。
実装としては、共有資産の保守に明示的な作業項目を置く。横断課題に担当期間を設ける。再発防止を完了条件に含める。ドキュメント、監視、データ品質、開発環境の改善を成果物として扱う。ふりかえりでは、見えない仕事を誰が引き受けたかを確認する。評価面談では、つなぎの仕事が単なる人柄ではなく成果として扱われているかを見る。ロードマップには、共有資産の更新や負債返済を、機能開発と並ぶ投資として載せる。
可視化の段階で見るべき問いは、「この仕事はどこに記録されているか」「優先順位は誰が決めるか」「完了したときに誰の成果として評価されるか」である。記録はあっても評価がないなら、可視化はまだ半分である。評価はあっても時間がないなら、制度は現場に負債を押しつけている。
レベル4は、参加設計の段階である。オーナーだけが領域を抱え込むのではなく、他者が安全に関与できる条件を決める。ここでは、組織によっては、境界をまたぐ仕事の受け皿になる役割や場を制度として置くことが有効である。たとえば、アーキテクト、Staff Engineer4、イネーブリングチーム5、プラットフォームチーム、Site Reliability Engineering6、Technical Program Manager7、横断レビュアー、ギルド、Community of Practice8 である。名称は組織によって異なり、根拠の性質も同じではない。重要なのは、これらを一律の万能役割として置くことではなく、どの種類の境界問題を、どの権限と責任で扱うのかを明らかにすることである。
Team Topologies は、ストリームアラインドチーム、プラットフォームチーム、イネーブリングチーム、コンプリケイテッドサブシステムチームといったチーム類型を示し、チーム間相互作用を設計する考え方を提示している（Skelton and Pais, 2019）。この枠組みは、プラットフォームチームが内部プロダクトを提供する場面や、イネーブリングチームが他チームの学習を支援する場面を考えるうえで使いやすい。Staff Engineer は、複数チームにまたがる技術方針や複雑な問題解決を担う技術リーダーシップの例として位置づけられる。Community of Practice は、職能や関心を共有する人々が実践知を交換し、横断的に学ぶ場として位置づけられる。
一方、Site Reliability Engineering は、一般的な境界横断役割というより、信頼性運用や toil 削減をエンジニアリングとして扱う実践の例である（Beyer et al., 2016; Rau, 2016）。Technical Program Manager については、Reilly (n.d.) がプロジェクトマネージャーと並べて、つなぎの仕事を高いインパクトで担う役割の例として挙げている。ただし、その具体的な職務範囲は組織によって異なる。ここで重要なのは、組織図の名前を真似ることではない。チームが互いにどう関わるのか、どこで協働し、どこをサービスとして提供し、どこで学習を支援し、どこで運用責任や依存関係を制度として扱うのかを明示することである。
実装としては、低リスク変更と高リスク変更を分ける。誤字修正、リンク切れ、テスト追加、開発環境の説明改善は、外部の人がプルリクエストを出しやすくする。一方、本番設定、認可、課金、顧客データ、セキュリティ、データ移行、障害対応手順は、事前相談、レビュー責任、影響範囲の確認、ロールバック計画を必要とする。相談経路、レビュー担当、判断する会議体、意見が割れたときの裁定方法も決める。
この段階では、オーナーは門番ではなく、参加条件の設計者になる。支援者も、正しいことを言う人ではなく、相手の文脈を学び、選択肢を増やす人として振る舞う。スチュワードシップは、ここで初めて「世話する人がいる」状態から、「世話に参加できる状態」へ進む。次章で扱う越境支援の作法は、このレベル4を日々の行動へ落としたものである。
レベル5は、学習するスチュワードシップの段階である。組織は、隙間仕事の発生を個別の例外として扱わない。どこで隙間が繰り返し生まれているのかを見て、共有資産ガバナンス、評価制度、権限、チーム間の相互作用を見直す。隙間仕事は、誰かが埋めるべき穴であると同時に、組織設計を更新するためのシグナルでもある。
実装としては、共有資産ごとに利用者、メンテナー、意思決定権、費用負担、変更ルール、紛争解決の場を明らかにする。つなぎの仕事を昇進要件、職務定義、表彰、目標設定に入れる。境界横断の責任を、特定の個人の例外的な献身ではなく、ローテーション、兼務比率、専任役割、チーム間契約として扱う。チーム間相互作用が変わったなら、チーム境界そのものを見直す。
この段階では、「この問題を次に起こさないために、どの境界を変えるべきか」「一時的なオーナーで足りるのか、恒久的な責任範囲を作るべきか」「共有資産の利用者自身がルール変更に関われているか」を問う。スチュワードシップが成熟した組織は、越境する人を英雄にしない。越境が必要になった理由を学び、次からはより自然に処理できる形へ制度を直していく。
この五段階は、直線的に一度だけ進むものではない。あるプロダクトではレベル4に近くても、別の共有資産ではレベル1のままということはある。新しい事業、新しい技術、新しい組織変更があれば、成熟していた領域にも再び隙間が生まれる。したがって、重要なのは自分たちに点数を付けることではない。どの種類の仕事が、どの段階で止まっているのかを見ることである。
隙間仕事に名札をつけることは、確かに第一歩である。しかし、スチュワードシップが確立されるのは、その名札が所有権の印ではなく、世話と参加の入口として機能したときである。組織が自己診断すべきなのは、「誰がオーナーか」だけではない。「そのオーナーは、誰が安全に関われるようにしているか」「その仕事は評価され、時間を与えられ、次の学習へつながっているか」である。
越境行為には段階がある。問題を発見する。助言する。支援を申し出る。変更する。意思決定に関与する。これらをすべて「助ける」と呼んでしまうと、リスクの違いが見えなくなる。発見を共有するだけなら低リスクでも、本番設定を変更するなら高リスクである。越境支援を安全にするには、この段階を分けて扱う必要がある。
最初の段階は、発見である。越境者は、気づいた問題をすぐに解決策として提示するのではなく、まず問題として言語化する。ここで大切なのは、担当者の欠陥ではなく、境界上のリスクとして表現することである。「この実装はおかしい」ではなく、「この仕様は二つのチームの前提がずれているように見えます」と言う。「監視が足りない」ではなく、「障害時にどちらのチームが先に検知するのかが曖昧に見えます」と言う。
次の段階は、影響範囲を示すことである。どのユーザーに影響するのか。どのサービスやチームが関係するのか。今すぐ扱うべき問題なのか、後でよい問題なのか。越境支援では、正しさよりも処理可能性が重要になる。相手が動ける粒度まで問題を小さくし、必要な関係者を特定し、選択肢を並べる。これだけでも、組織にとっては大きな価値がある。
そのうえで、オーナーに共有する。発見した人が、ただちにオーナーになるわけではない。オーナーは、その領域の文脈、リスク、優先順位を持っている。越境者は、オーナーの許可を形式的に得るだけでなく、合意を作る必要がある。「こちらで直します」ではなく、「どの進め方ならよいでしょうか」と聞く。相手の自律性を残すことが、支援を介入にしないための最低条件である。
提案は、単一の正解ではなく選択肢として出すとよい。現チームで修正する。支援者がプルリクエストを出し、オーナーがレビューする。設計判断記録（Architecture Decision Record; ADR）9 だけ先に作る。一時的な横断課題として、期間や範囲を限定した担当者を置く。高リスクであれば、定例会議や意思決定の場へ持ち込む。選択肢を並べることで、支援者は支配者ではなく、処理能力を増やす人として振る舞える。
Humble Inquiry の考え方もここで効く。Schein (2013) が示すように、問いは相手の文脈を学ぶための手段である。越境者は、相手の領域に入る前に、相手が何を見ているのかを学ぶ必要がある。「なぜまだやっていないのですか」ではなく、「これを後回しにしている制約はありますか」と聞く。「この設計に問題があります」ではなく、「この設計で守りたい前提は何ですか」と聞く。問い方は、相手の専門性を尊重する実務である。
低リスク変更と高リスク変更も分けなければならない。誤字修正、リンク切れの修正、テストの小さな追加、開発環境の説明改善は、比較的低リスクである。もちろんレビューは必要だが、越境者がプルリクエストを出しやすい領域にできる。一方、本番設定、認可、課金、顧客データ、セキュリティ、データ移行、障害対応手順は高リスクである。ここでは、支援の意思があっても、オーナーの明確な合意、レビュー、ロールバック計画、影響範囲の確認が必要になる。
Team Topologies の相互作用モードも、越境行為を整理する助けになる。collaboration は、複数チームが一緒に問題を解く関わり方である。X-as-a-Service は、あるチームが他チームへサービスとして能力を提供する関わり方である。facilitating は、相手チームが学習し自走できるよう支援する関わり方である（Skelton and Pais, 2019）。どのモードで関わるのかを明示すれば、「どこまで入ってよいのか」が曖昧になりにくい。
越境行為を安全にするには、個人の作法だけでなく、組織のプロトコルも要る。どの種類の変更なら外部の人が直接プルリクエストを出してよいのか。どの変更は事前相談が必要なのか。誰がレビューするのか。緊急時はどの経路で合意するのか。意見が割れたら誰が裁定するのか。問題を見つけた人は、発見者として評価されるのか、それとも余計な仕事を増やした人として扱われるのか。これらを事前に決めておくことで、越境は例外ではなく仕事になる。
心理的安全性も、このプロトコルの一部である。Edmondson (1999) の議論を踏まえるなら、学習する組織には、問題を見つけて声を上げても罰せられない環境が必要である。ただし、声を上げる人だけが安全であればよいわけではない。声を向けられる側も安全でなければならない。指摘を受けても評価が壊れない。支援を断っても関係が壊れない。合意形成に時間を使っても、遅いと言われない。そうした制度があって初めて、越境支援は持続可能になる。
善意は重要である。しかし、善意だけでは足りない。善意は、相手の文脈を学び、リスクを分け、合意を作り、責任の所在を明らかにすることで、初めて組織の力になる。越境行為を安全にするとは、勇敢な個人を増やすことではない。越境しても関係、評価、責任が壊れない進め方を、組織の標準にすることである。
ここまで見てきたように、大規模組織にオーナーシップは必要である。誰が判断するのか、誰が品質に責任を持つのか、どこへ相談すればよいのかが曖昧なままでは、複雑な仕事は前に進まない。責任範囲を定めることは、組織を動かすための基本的な技術である。
しかし、オーナーシップを所有権化した運用に寄せすぎると、別の問題が生まれる。責任範囲が明確になるほど、範囲外の仕事を拒否する理由も明確になる。心理的所有感は、品質への愛着や長期的な関与を支える一方で、外部からの関与を脅威として受け取らせることがある。Pierce, Kostova, and Dirks (2001) は、組織における心理的所有感が人の態度や行動に影響することを論じている。また、Brown, Lawrence, and Robinson (2005) が論じる組織内の縄張り化は、領域を守る行動が協働を妨げる可能性を示している。
このとき起こるのは、単なる人間関係の摩擦ではない。責任回避、縄張り化、目的置換である。責任を明確にしたはずの制度が、「それはうちの責任ではない」と言うための根拠になる。品質を守るためのオーナーシップが、外からの学習や改善提案を拒む理由になる。顧客価値やシステム健全性のために作った境界が、境界を守ること自体を目的にしてしまう。Merton (1940) が官僚制の逆機能として示したように、制度は本来の目的から離れ、手続きそのものを守る方向へ硬直することがある。
だからこそ、隙間仕事を見つけ、越境して助ける人は重要である。ただし、その重要さを個人の美徳として消費してはいけない。越境的な支援を「気が利く人」「面倒見のよい人」「空気を読める人」に任せるだけでは、組織は同じ失敗を繰り返す。この種の職務外貢献は成果に貢献しうる一方で、評価されにくい負担や疲弊にもつながる。Bergeron et al. (2013)、Bolino et al. (2015)、Deery et al. (2017) の組織市民行動研究は、ソフトウェア開発組織のつなぎの仕事を直接扱うものではないが、よい市民であり続けることにコストがあるという点を示している。
組織がすべきことは、越境的な責任を正当化し、評価し、安全に実行できる制度を作ることである。共有資産には予算と時間を割り当てる。横断課題をバックログに載せる。共通基盤、運用、アーキテクチャ、ドキュメント、再発防止、データ品質を「誰かが気づいたらやること」ではなく、組織として扱う仕事にする。Team Topologies が示すプラットフォームチームやイネーブリングチームのように、チーム間の相互作用そのものを設計対象にすることも、その一つである（Skelton and Pais, 2019）。
ただし、制度化には副作用がある。越境的な責任を正当化するために会議体、承認経路、優先順位付けの仕組みを増やすほど、今度はその意思決定機関がボトルネックになる。共通基盤を守るための委員会が、現場の小さな改善まで止めてしまう。リスクを管理するための手続きが、リスクを発見した人の行動を遅らせる。これは、制度そのものが悪いという話ではない。Merton (1940) が述べたように、制度は目的を支える道具であるはずなのに、手続きへの同調を目的にしてしまうことがある。
この副作用に抗うには、制度を中央集権的な許可装置にしないことである。Adler and Borys (1996) は、官僚制を、現場を縛る強制的なものと、現場の仕事を助ける支援的なものに分けて論じている。この区別は、越境責任の制度設計を考えるうえでも有用な補助線になる。よい制度は、すべての判断を上位会議へ集めるのではなく、判断基準、相談先、ログ、例外処理、取り消し方を明らかにし、できるだけ問題に近い人が動けるようにする。Ostrom (1990) が共有資源の統治原則で、影響を受ける人々がルール変更に参加できることを重視した点も、直接の証拠ではなく類推として、この方向を支えている。複雑な問題では、最初から正解を選ぶより、小さく試して学ぶほうが有効な場合がある。Snowden and Boone (2007) の Cynefin フレームワークも、複雑な状況では安全に失敗できる実験を通じて状況を理解する必要を示している。
同時に、越境行為には作法が必要である。発見した人が、ただちにオーナーになるわけではない。相手の領域に入る前に、問題を境界上のリスクとして言語化し、影響範囲を示し、オーナーと合意を作る必要がある。Schein (2013) の Humble Inquiry は、相手を診断するのではなく、問いを通じて相手の文脈を学ぶ態度を示している。越境者は「正解を持ってきた人」ではなく、処理可能な選択肢を増やす人として振る舞うべきである。
越境行為を安全にするとは、越境者に勇気を求めることではない。越境しても、関係、評価、責任が壊れない制度を作ることである。誰が相談を受けるのか。どの変更はオーナーの承認を必要とするのか。どの範囲なら支援者がプルリクエストを出せるのか。高リスク変更はどの会議体で扱うのか。問題を見つけた人は、発見者として評価されるのか、それとも余計な仕事を増やした人として扱われるのか。こうした問いに、組織は事前に答えておく必要がある。同時に、低リスクで可逆的な変更は、会議体を通さず実行できる範囲を明確にする必要がある。高リスクの変更は慎重に扱うべきだが、すべてを高リスクとして扱えば、制度は安全装置ではなく停止装置になる。
結論は単純である。オーナーシップは、複雑な組織を統治可能にするために必要であり、主体性や当事者意識を支える。しかし、それが所有権化すると、責任回避、縄張り化、目的置換を生む。組織に必要なのは、領域を守るだけのオーナーシップではない。領域を世話し、境界に落ちた問題を見つけ、必要な人をつなぎ、他者が安全に関与できるようにするスチュワードシップである。
よい組織は、越境する責任を個人の善意に任せない。越境を例外扱いにせず、正当性、評価、手続き、権限、保護を備えた仕事として制度化する。誰の仕事でもない仕事を、誰かの勇気だけに預けない。その設計こそが、オーナーシップを所有権からスチュワードシップへ変えるための実践である。
アクセス日は、特に断りのない限り2026年6月17日である。キャッシュ上で取得日を個別に管理した項目は、各項目にアクセス日を明記する。ウェブ記事の公開日・更新日は、公開ページで確認できる範囲を記す。公開ページで日付を確認できない場合でも、書籍・講演・関連ページなどの書誌情報から年を確認できるものは、その年を記す。