ABEJA のアジャイル開発チームでスクラムマスターをしている小川です。
今日はスクラムなどに代表されるアジャイルなチームに欠かせない「自己管理（自己組織化）」についてご紹介をさせていただきます！
また、失敗例という形で「自己管理型チームから遠ざかる危険シグナル」についてもご紹介をさせていただき、最後に自己管理型チームを実現するための（私の経験をベースに独断と偏見による）代表的なコツも挙げさせていただきます！
アジャイルなチーム作りをされている方の参考になれば幸いです。
（この記事では上下関係に対して否定的な表現を使っていますが、あくまでアジャイルなチームにおいては望ましくないという意図であることをご承知おきください。）
目次 アジャイル/スクラムのチーム作りで欠かせないキーワードとして自己管理（自己組織化）というものがあります。 これは従来型の上位下達なチームとは大きく異なる点で、アジャイル/スクラムの経験のない方は違和感ややりづらさを感じるところかもしれません。 従来型組織構成は「上位者」と「下位者」という上下関係の序列で構成されます。
一方、アジャイルのチームでは上下関係のないフラットな組織を目指します。
「自分は経験やスキルが少ないから…」なんて考えずにどんどん意見を言っていいのです！判断や意思決定をチームで行うためにも、メンバーそれぞれの目線/観点の意見が非常に重要です。
逆に従来型組織で経験が長かった人は、考え方やマインドセットの切り替えが必要です。
正直なところ私も社会人として多くの時間を「上司と部下」や「先輩と後輩」、「PM とメンバー」、「委託元と委託先」のような、ある意味でわかりやすい上下関係的な中で業務していたので、最初にスクラムチームに入った当初は、指示命令系統（もちろん、そんなものはスクラムにはないのです！）を意識して自分の意見を控えたり、後輩や新入社員から手痛い指摘を受けてプライドが傷ついたり、とかとか…、していたような記憶もありますw
なぜ自己管理型チームの実現にはフラットな関係が欠かせないのか？
アジャイル開発では、開発成果物をジャストインタイムにリリースして、ユーザなどの反応を収集し、柔軟に取り入れ、次の開発に活かしていく、そんなフィードバックサイクルを継続的に回し続ける必要があります。
また、チームの活動に問題があれば、自分達でそれに気づいて自分達で速やかに修正をしていくこともアジャイルチームには求められます。
「上位者に聞かないと/指示をもらわないと、次のアクションが打てない」では、チームのアジリティは発揮できないのです。
スクラムの場合は、開発者はデイリースクラム（いわゆる朝会）でスプリントゴール達成に向けて、今の状況を自分達で見定めて、必要なら自分達で変更プランを考えて、自分達で変更後のアクションプランを実行する（透明性、検査、適応）ということを毎日行います。
ちなみに、デイリースクラムは開発者のものです。スクラムマスターやプロダクトオーナーがコントロールしているような状況は自己管理型チーム形成を阻害しますので気をつけましょう。
メンバーとチームの主体性が大事です。（これは突き詰めていくとABEJA のバリューであるテクノプレナーシップにも通じるように思います。）
こんな感じで、柔軟に速やかに高頻度にチームの活動を変化させていくことが求められるのに、都度わざわざ決定権者に問い合わせていたらアジャイルはうまく回りません。
もしかすると、決定権者が常に状況を広く捉えて、未来を的確に予測して、聞かれるまでもなく間違いもなく判断できるのであれば回るかもしれません（ごく稀にそういうスゴすぎる人もいますよね...）。ですが、病気やケガで急きょお休みすることもあるでしょうし、いつかはチームから離れる日も来るでしょう...。仮にスゴすぎる人を中心に大成功しているチームがあるとしても、特定の誰かに依存している状況は継続性に難があるかもしれませんね。
フラットなチームの失敗例
ここから失敗例のご紹介ですが...反面教師的に捉えていただければと思います！
誰かに依存している
まず大前提として、権限/決定権が適切にメンバーに移譲/分散されている必要はありますが、一見フラットに見えても、多くのシーンで決定を左右する（依存する）人がいるような状態は良くないです。
エンジニアであれば経験とスキルが高い人がいて、その人の意見にみんなが従ってしまっているだけの状態というのは良くある話です。（スーパースターやゴリラ（Gorilla in the Room）と呼ばれる問題です）
また、「設計はリーダーの承認が必須である」とか、「レビューはシニアエンジニアが担当する」といったような状態が続いているのも良くないですね。
知識と経験が豊富なエンジニアのレビューが必要である状況があることも理解しますが、アジャイルなチームではペア/モブレビューなどでシニアの観点やノウハウをチームに伝搬する努力もするべきだと思います。
プロダクトオーナーと開発者に序列がある
受託開発でお客様側にプロダクトオーナーがいるようなケースでは、プロダクトオーナーと開発者が受発注者の関係になることもあります。このような状況でも、お客様側にもフラットなチーム運営に理解してもらう必要があります。
一方、開発者がプロダクトオーナーに対して意見を言ってはいるけど、実はプロダクトオーナーが決めた仕様だけを実装する開発になっていて、仕様の抜けや不明点が見つかるとプロダクトオーナーを質問攻めしてしまっている…、さらに悪いことに、仕様の抜け漏れなく全て出揃うまで開発者がプランニングをしない...、というのも健全な状態ではないですよね。
これの行き着く先は「プロダクトオーナーがPBI の受け入れ条件を、あらゆる可能性を網羅した内容で書き込む」という状態です。 このような状態だと、開発者はSBI プランニング（詳細設計）や実装時に、ユーザー価値向上に資するアイデアを考えることをやめてしまい、やはり自己管理型チームから遠ざかります…。 （しかも、PBI プランニングはユーザー価値の検討より、仕様の抜け漏れ発見に重きが置かれるでしょう）
フラットなチームを作るコツ
次に、チームをフラットな体制にして自己管理型チームにしていくためのTips をご紹介します！
1. イベントのファシリテーションをスクラムマスターが占有しない
チームで進行役を回すことでメンバーの主体性を醸成することを狙います。
チームメンバー全員がその時々でリーダーシップを発揮し合い、スクラムマスターのファシリテーションに限らず、決まった人が常にリーダー的に動いているような状況は避けましょう。
2. スーパースターがいる場合は発言を控えてもらう
前述の失敗例にある「誰かに依存している状態」である場合、依存先の人は相談されたり、聞かれたら答えるようにしてもらいましょう。言いたいこともグッと堪えて我慢！
3. （状況に応じて）開発者からの質問にプロダクトオーナーやスクラムマスターは全てを答えずに、開発者の考えも聞くようにする
プロダクトオーナーやスクラムマスターとの答え合わせをするようなマインドがチームに根付かないようにしましょう。
プロダクトオーナーからスクラムマスターも同様です。
4. プロダクトオーナーは自らの判断でバックログを変更管理できるようにする
これはチーム外との上下関係に焦点を当てたトピックになります。
実例としてたまに聞くのが「受託開発で発注元にプロダクトオーナーがいるが、実は若手の担当者で社内的には裁量権がなく、上司に聞かないと開発の優先度が決定できないようだ…」という状況です。
ステークホルダーに許可をもらわないとバックログを変更できないという状況はやはりチームのアジリティを損ないますので、プロダクトオーナーに最終決定権があることを、チーム内外、ステークホルダーも含めて認めてもらうのは必須です。
5. 開発者の専任/属人体制をなくす
属人化はチーム継続性の観点でも悪です。
また、「自分の範囲はここからここまで！」という誤った責任感がチームに蔓延してしまい、部分最適思考によって、チームとしての改善ができなくなり、やはり自己管理型チームから遠のきます。
全員参加が必要なスクラムイベントに参加していないメンバーがいるとしたら、それももしかすると本人が誤った線引きしている危険信号かもしれません！
スクラムマスターとしては観察も必要ですが、まずは全員が参加できるよう、参加を阻害している要因排除を行いましょう。
6. 役割と責務による線引きを必要以上にせずに、コラボレーションを大切にする
（これも専任/属人体制に近い話ですが、あえて分けてみました） スクラムガイド2020 でチームの範囲が変更（開発チームではなく、開発者とプロダクトオーナーとスクラムマスターで１チームに変更）された背景にも通じるところかと思いますが、価値実現に向けた努力はチーム全員で協力すべきです。
「PBI を作るのはPOの仕事だ（だから、プロダクトバックログの更新ができてないのはPO の怠慢だ！）」、「実装は開発者の仕事だ（だから、PBI が終わらなかったことの責任は開発者にある！）」という他責な意識が持たれないようにチーム運営をしていく必要もあるかと思います。
不要な責任分界点は排除してチーム（内外）でコラボレーションを密に行えるようスクラムマスターは働きかける必要もあると思います。
また、もしチーム内のコミュニケーションになんらかのルールや慣例（例: 所定のフォーマットで質問や依頼するとか、相談のタイミング/時間が限られているとか）があるようでしたら、なくしてみることもお勧めします。
7. ペアプロ/モブプロを推奨しましょう！
一緒に手を動かすことで、良好な関係の構築につながります。 また、ペアプロ/モブプロはスキルトランスファーにもなったり、複数の目を通すことでレビューにもなりますし、エンジニア同士で作業効率化の情報交換ができたり（「なるほど、そういうやり方もあったのか！」という発見も結構多いですよね！）、状況を把握する機会にもなったりと良いことづくめです。
また、アジャイルチームの立ち上げ初期フェーズでは特に活用いただきたいと思っています。 早い段階でコミュニケーションを取りながら開発を進める成功体験を得てもらい、対話を重視することや全体最適思考を早期に醸成させたいです。（エモい表現をするなら「一体感の醸成」ですね！） 後からこの辺のマインドを変えるのは結構骨が折れるはずです…
アジャイルに慣れていない方的には稼働効率が気になるところ（２人が別の作業すれば２倍のアウトプットになるはず...、話しながらで集中できないのでは...、などの懸念）かと思いますが、心配せずに活用してみていただきたいです。
ペアプロの誤解とメリットについて完結にまとめてくれている記事があったので貼っておきます！
8. 役職や経験に関係なく、お互いにお互いの強みでリードし合い、気づいた点をフィードバックしあえる関係性を構築する
雑談、1on1、ペア/モブプロ、レトロスペクティブなどを活用しましょう。
とにかく対話が大切です。
9. スクラムマスターは開発者を兼任しない
どちらの傾向が出やすいかは人によりますが、スクラムマスター傾向の強い人は開発者の中で声が大きくなりがちです。（開発者傾向が強い人だと、チームの成熟度が低い場合はスクラム自体が機能しなくなりそう…）
（これは私自身の経験でもありますが....、）自分では開発者とスクラムマスターの役割を状況に応じて使い分けているつもりでも（例えば、スクラムマスターとしてチーム活動を支援/牽引しているつもりでも）、チームにはそれが伝わりづらく（もしくは甘えてしまい）、開発者内で開発者リーダーのような役割だとみなされてしまい、開発者の中に序列ができる可能性があります。（発言のたびに「いまからスクラムマスターとして話します！」と丁寧に言う手もあるかもしれませんが、会話の流れの中では必ずしも毎回言えなかったり、そもそもいちいち枕詞をつけるのは言う方も聞く方も煩わしいですよねw）
また、スクラムマスターはアジャイルのノウハウや経験を多く有していたりもするので、例えば、他の開発者が気づいていないような「スプリントが失敗するであろう状況」を察知しやすいです。
そのようなときには、メンバーに気付きを与えて自分達で失敗回避させる（ときにはあえて失敗させる）のが望ましいのですが、開発者も兼任していると「開発者としての確約の精神」から、回避策のプラン出しと実行まで一気通貫でリードしきってしまい、他の開発者の主体性を発揮する機会を奪ってしまうかもしれません…。
（似たような話題でプロダクトオーナーの開発者兼任というものもありますが、自己管理とはまた別の問題も抱えてしまいますのでやめるべきだと思います。それに、プロダクトオーナーは兼任できるほど暇ではないはずです...。）
兼任していいことはあまりないので、やめた方が良さそうです。
10. 尊敬/リスペクト を大切にする
フラットなチーム運営で重要なのは尊敬です！
フラットで対等な立場だからこそお互いにリスペクトの気持ちを持つことが非常に大切です。 （スクラムの５つの価値基準「集中、確約、公開、勇気、尊敬」にも入っていますね。）
これは少々余談ですが、自己管理型チームにするべくスクラムマスターはあえて手を出さない、というのは有名な話ですが、逆にチームにきちんと介入すべき状況もあります。 それは、「５つの価値基準に反する言動があったとき」です。 これはあまり知られていない気もしますが、私も初めて聞いたときに大変感銘を受けまして、今でも肝に銘じております...。
We Are Hiring!
ABEJAは、テクノロジーの社会実装に取り組んでいます。 技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方はもちろん、アジャイルの開発体制の中で幅広い技術を活用・習得したい方も、下記採用ページからエントリーください！ （新卒の方のエントリーもお待ちしております）
