最近，チームを自己組織化させるためにどうするかみたいなことをよく話したり考えたりするのだけれど，チームの自己組織化を考えるうえで，特に組織の「境界」をどこに引くかはとても重要なんじゃないかなあと思うので，今の考えをまとめておく．
基本的にはどのような組織にも当てはまる話ではあるが，主にソフトウェアシステム開発の現場での経験が元になっていることをご理解いただきたい．
自己組織化とは何か
いろんな定義があると思うのだけど，自分は Scrum Alliance の認定スクラムマスター研修にて日本人唯一 *1 の認定スクラムトレーナーである江端一将さんが仰っていた定義がわかりやすいと思う．
1. チームのゴールが明確であること
2. チームの仕事や裁量の境界が明確であること
3. チームメンバーが，自分たちのやるべきことを自分たちで 0.1 秒以内に決定できること
また，最近同僚と話していた中で出た言葉で分かりやすかったのは 「チームが勝手に最適化されること」 という言葉だった．
ソフトウェアエンジニア的に「最適化」という言葉がわかりやすくて，何らかの「最適化」がなされるためには，そもそも最適化されるべき指標が明確でないと最適化のしようがない (上記の江端さんによる定義の1つめ) . 例えば，アクティブユーザーの拡大を目的とするべきなのか，売上の拡大を目指すべきなのかの認識がチーム内でずれていれば最適化は絶対にできない．その組織は間違いなく自己組織化されていない．
そして，組織がどのようなシステムを用いてその指標を弾き出すのかも明確でなければいけない (江端さんの定義の2つめ)．例えばチームの携わるプロダクトが弾き出す売上を最大化するために，ソフトウェアシステム自体の改良だけが裁量の範囲なのか，営業アプローチの見直しまで入るのかでアプローチは変わるだろうし，その裁量の範囲が曖昧であればチームが自らアクションを自ら決めることは出来ない．
境界を設定することでチームはどうなるのか
で，チームの境界を明確にすることは自己組織化を促す上で大きな役割を果たすと考えているのだけど，それは以下のようなメカニズムからだと思う．
1. チームの境界が明確になることで，チームの仕事や裁量の境界が明確になる
2. チームの境界が明確になることで，チームの目指すべきゴールや注力するべき指標が明確になる
3. チームの境界が明確になることで，チームのゴールに向けたメンバーの自発的かつ自由なアイディアやアプローチを促進しやすくなる
境界は引くだけではダメで，引いた後に，その境界の内側でチームメンバーが如何に活発に活動してくれるかが重要になることには疑問はないだろう．その意味では，境界の内側でのファシリテーションや心理的安全性の確保が大事なのは言うまでもない．
逆に境界が存在しないなかで活発な活動を促してしまうと，それが正しい方向を向かなかったり，不適切なアプローチを取ってしまって，結果としてチームとしてのまとまりが欠如したり，チーム全体での最適化から大きく離れてしまうだろう．
境界の引き方を間違える例
境界は何でもかんでも引けばいいというわけではなくて，上手く狙いを持って境界を引かないと逆効果になりうる，というのが最近の自分の課題意識．
これまで自分の周りで見たり，自分がやらかしてきた「境界の引き方の失敗」の例を挙げると以下のようなものがある．
境界を引かない
単に「境界を引くことを知らない」というよりは，「みんなで一体となって仕事をしよう！」というメンタルモデルに引っ張られすぎて，組織デザインを怠ったりするケース．
組織の最適化するべき KPI も明確でないからコミットメントも弱くなるし，全員が目指す成果が存在しないので達成感も生まれず，チームビルディングをしようにも無理矢理な方法しか取れなくなってしまう．無理矢理なチームビルディングは持続可能でないし，どこか悲しい．
境界を引きすぎてしまう
逆に組織デザインについて勉強したばかりで，とにかくサブチームみたいなものを引いてしまう例．
スクラムでは，開発チームの人数について「小回りが効く程度に小さく，1スプリントに意義ある仕事を完成できる程度には大きく」ということで3人から9人とスクラムガイドにて規定されている．特に「3人未満だと充分なインタラクションが生じず生産性が出ない」と書かれている．組織を小さくすることを覚えてすぐのとき，チームと言いながら1人で何らかの仕事を任せているだけだったり，2人でチームを名乗らなければいけなかったりしているケースはよく見られるし，自分もやったことがある．
また，「小さすぎるチーム」ではなかったとしても，分けなくてもよい粒度で境界を引いてしまうことで，組織にムダが生じることはよくあるのではないだろうか．
境界を作って自己組織化を促すことの大きなメリットのひとつは，知識移転が容易になることだ．境界を定めてサブチームを作ってしまうと，知識移転が滞ったり，サブチームそれぞれが知識の体系化を別々に行ったり，問題解決をそれぞれが取り組んでしまうという無駄が生じてしまう．
(これを対策するのがマトリクス組織なんだろうけど，なかなかうまくいかないよねぇ…)
引いてはいけない境界を引いてしまう
目指すべき目標をベースに境界を引いて自己組織化を促すべきなのに，職域で境界を引いてしまうケースはよくあるのではないだろうか．給与体系とか採用といった人事的な都合は必要なのだけれど，仕事をする上ではその境界というか区別をそのまま持ってくるのはアンチパターンだと思っている．
たとえば，グループウェアのような SaaS システムの販売をする営業組織と開発組織の間に境界を強めに引いてしまうと，営業が見込み顧客から吸い上げた要望を開発組織に伝えてプロダクトの機能に反映するまでのリードタイムや正確さが失われてしまう．これは一種の知識移転の阻害だ．
知識移転が阻害されてしまうだけならまだ良いが，それぞれのサブ組織の間での目標や推奨される行動が矛盾してしまったり，そもそも目標を基準に境界を引いていないが故に組織全体の目標にサブ組織の目標が寄与しないというケースも生じがちだ．
一度引いた境界を見直さない
目標ベースで境界を引いて，ある程度の期間は成功したとしても，時間の経過とともにそのサブチームが掲げていた境界が最適なものでなくなることもある．
例えば，それまで中価格帯の品揃えを展開していた店舗チェーンが，新たに低価格帯の店舗を展開するとなると，組織内に境界を引いてサブ組織を形成するだろう．
当初は，低価格帯の店舗チェーンが想定した顧客セグメントに充分に受け入れられることを実証することがミッションになるし，何よりも組織やシステムを立ち上げることがファースト・ミッションになる．なぜなら，そのサブ組織のミッションを成し遂げることが組織全体の成長にも貢献するからだ．
しかし，その低価格帯の店舗チェーンのマーケティングやシステムが軌道に乗ると，ただシステムやオペレーションを洗練することではなく，収益性や知名度を上げることに最適化した組織へと変更する必要がある．システムやオペレーションの完成度を上げるだけでは，組織全体の成長にはそれまでほど大きく貢献できないからだ．
どう境界を引くか
ここまで境界を引くときの失敗パターンばかりを挙げてきたが，正直，どのように引けば正解になるかはよくわからない．正確に言えば，正解は文化や文脈といった様々な前提に左右されるし，失敗パターンの最後に触れたように，時間の経過とともに正解が変わってくることもあるから，正しい選択が出来ているのかどうか，境界を引くための正しいアプローチをとれているか，常に自問自答するべきなんだろうなぁと思っている．
以下，自分のこれまでの経験の中で有用だと感じているアプローチをいくつか書いておく．
組織に名前をつける
kawasima さんが チーム力向上のためのエトセトラ - Qiita にて書いているけど，チームとかサブシステムに名前をつけるのは非常に重要だと思う．アイデンティティを醸成することも出来るし，チームメンバーが勝手に境界を意識してくれるようになる．
ポイントは，名前をしっかり考えること．例えば，雑誌制作を行っている会社が新たに雑誌に掲載する広告の募集・原稿管理を行うシステムを開発するときに「広告システムチーム」と名付けても悪くはないのだけれども，アイデンティティや愛着は生まれないだろう．このような命名アンチパターンを，個人的には「飼い犬に犬と名付けるパターン」と呼んでいる．"ポチ" でも "モカ" でも "大五郎" でもなんでも良いけど，家族の一員として認めたい愛犬なのだったら愛せる名前をつけたいですよね．
物理的に近くで仕事をする
エクストリーム・プログラミング (XP) における Colocation のこと．個人的には，チームメンバーも含めて本格的にリモートワークと向き合ったことがないのだけれど，同じオフィスに居るとしても雑談ができる近さは本当に大事だと思う．
境界を意識させる上でも近くにいることは大事だし，自己組織化を促してスムーズな知識移転を実現したとしたら，その知識移転の大半は形式建てられたミーティングではなく，日々の雑談から生まれるものなんだと信じている．
会議体の出席者を調整する
境界外の人が参加するべき会議と，参加するべきではない会議を明確にするべきだ，ということ．
失敗しがちなのが振り返り会で，境界を意識せずに振り返り会を行うことで共感を産んだり課題感を共有して対策を考えることが難しくなったり，上司を含む重要なステークホルダーを同席させてしまうことで心理的安全が損なわれてしまうケースが多い．
また，スクラムでもスプリントプランニングにステークホルダーを参加させないとか，スプリントプランニングの中でも前半はプロダクトオーナー同席で取り組むプロダクトバックログを決めて，後半はプロダクトオーナー不在でスプリントバックログの書き出しを行う，とか工夫したりする．
結論
最近，ソフトウェア開発の文脈の外に出て経営学の観点から 組織デザイン (日経文庫) *2 という本を読んでみたりしたのだけど，車の製造やサプライチェーンの構築と比べると，ソフトウェア開発はプロダクトもプロセスも作って壊すというサイクルも圧倒的に早く回せるし，クラウド時代がやってきたことで物理的資源の制約も格段にゆるくなっているため，チームビルディングとかモチベーションを優先できるという意味で組織デザインの自由度が高いなぁ，と感じた．
しかし，自分もまだ全然理論的な側面で学びきっていない自負もあるので，「こういうことを学んで違う観点から考えると面白いよ」みたいなものを教えてもらえたら嬉しい．
