コードレビューの最優先やペアプログラミングの実施など、かつての開発現場では“正解”とされた鉄則が、AIの爆発的進化によって一夜にして覆る時代が訪れている。どれほど優れた手法であっても、一つの正解にすがり続ける組織は「もはやこれまで」と言っても過言ではないだろう。

しかし現実は、慣習や反対勢力の壁に阻まれて停滞を余儀なくされる組織が絶えない。激変の波を乗り越え、「変化不全」な組織から脱するためにはどうすればいいのか？

『野蛮なアジャイル』（翔泳社）の著者であり、サイボウズ初のスクラムマスターとして組織改革をリードした実績を持つ天野祐介さんに、変化を率いるための実践ノウハウを聞いた。

アバロスプラス株式会社 代表取締役／変容実践家
天野祐介さん（@ama_ch）

2009年、サイボウズ株式会社へ入社。エンジニアとして『kintone』の開発に携わった後、サイボウズ初の専任スクラムマスターに就任し、チーム、そして組織全体へのアジャイル推進を牽引。21年に仙台へ移住。「スクラムフェス仙台」の立ち上げなど、地域コミュニティの活動にも取り組んだ。25年サイボウズを退職、2026年アバロスプラス株式会社を設立

変化を拒む開発組織に潜む落とし穴

ーー天野さんは長年スクラムマスターやアジャイルコーチとして、組織の変革を支援してきましたよね。近年のソフトウエア開発の現場は、どのような変化に見舞われていますか？

もはや、開発現場で「同じやり方を続けていればいい」ということは一つもなくなったと言えますね。具体的なプラクティスであればあるほど反証が見つかる時代なので。

例えば、私がエンジニアとしてばりばりコードを書いていた2010年代は、「開発のスループットを上げるために、自分の実装作業よりレビューを優先しよう」という方針が王道でした。ですが今では「人間のレビューは遅いからAIに任せよう」と言われていますよね。アジャイル開発でよく行われるペアプログラミングも、一人の人間が複数のAIエージェントを稼働させた方が効率的になりました。

このように、この間までのスタンダードが陳腐化するサイクルが早くなっている印象です。

ーー「変わらなければ」ということ自体は、きっと多くの開発組織が分かっていることだと思うんです。ですが、それでも変われない組織があるのはなぜでしょう？

変わることのインセンティブを示せていないからですね。

ノルマをこなすだけ、顧客や株主に求められたら対応するだけ……といったスタンスの組織で重視されるのは「締め切りまでに作業を終わらせること」です。仕事のやり方を変えるには大きなエネルギーが必要なので、変化に対して消極的になるのは当然でしょう。

ですが本来、「変化」は成長に欠かせない要素です。学習して、試行錯誤して、変わることで成果を出した結果、売上が上がってまた新しい挑戦ができるというのが健全な成長のサイクルですから。

これだけ変化が早い時代ですし、受け身のスタンスに留まる組織が生き残るのは難しいと言えそうです。

ーー組織を変えるには、やはり経営層やマネジャーがトップダウンで方針を示すのが効果的なのでしょうか。

それが、一概にはそうとも言えないんですよ。

確かに、トップダウンの変革は最初はスムーズに進みます。権限を持つ人が号令をかければメンバーは一斉に動きますからね。ですが、それが現場の意思で進んでいるのか、単に「上から言われたから」なのかは謎のまま。全員が心から共感して取り組んでいるとは限りません。

その結果、推進者がいなくなったり、障壁が現れたりすると勢いが失われやすいんです。

反対派は「そのまま」でOK？ 変革を前に進める3ステップ

ーーでは、現場のメンバーが主体的に変革に取り組めるようにするには、何から始めればいいですか？

今回は三つのステップで説明しますね。

【1】変える対象は、まずは「自分」から

リーダーやマネジャーは上からミッションを託されるポジションです。ですが、与えられたミッションを深く咀嚼しないまま、ただ下に伝えても、なかなか上手くはいきません。

そこで、まずは自分自身の考えを変えることから始めましょう。ミッションの目的は何なのか、変わることでどんなインセンティブがあるのかを深く理解し、情熱をもって語れる状態をつくるんです。

私が以前在籍していたサイボウズでは、「説明責任」に加えて「質問責任」という言葉がよく使われていました。与えられた指示に疑問があれば、とことん質問して自分自身が腹落ちするまで理解を深める。基本的なことですが、変革はそこからがスタートです。

ーー自分自身の納得感を周囲のメンバーにも広げていくにはどうすればいいのでしょう？

最初から難しい課題に取り組む必要はありません。まずは、すでに課題が顕在化している領域や、改善による効果が大きい領域から着手すると、早期に成果が出るのでスムーズなスタートが切れるはずです。

すでに信頼関係があり、取り組みに共感してもらいやすいメンバーを少しずつ仲間に加えていくのも一つの方法ですね。

ーーとはいえ、変化に反対する人が出てくるのは避けられませんよね。そうした人には、どのように向き合えばいいのでしょうか？

私自身、反対意見の人と向き合う苦労は嫌というほど味わってきました。ここで重要なのが、二つ目のステップです。

【2】反対派は説得しなくてOK

自分と異なる考えを持つ人から説得されると「絶対に納得してやるものか」とかえって反発したくなることってありますよね。仕事に関しても同じで、相手を論破したり、打ち負かそうとしたりすると、ますます警戒されて反対の姿勢を強めてしまいます。

だからこそ、正面から説得しようとするのは避けた方がいいんです。

ーーでも、納得してもらわないことには物事が前に進まないのでは……？

反対派のまま参加してもらえばいいんですよ。

『Fearless Change』（丸善出版）という本に、「懐疑派代表」というパターンが出てきます。これは、反対する人の考え方を変えようとするのではなく、むしろ「反対意見を持つ専門家」としてそのまま活動に巻き込む方法です。

ーー反対意見を持つ専門家、ですか。

この方法を知った当時、私も「そんなやり方があるのか」と衝撃を受けました。

例えば、「あなたはこの分野に関して的確なフィードバックをくださるので、活動を進める上での問題点を見つけるために協力してほしいんです」とお願いするわけです。

合気道という武道は、相手の攻撃を自分の技に利用するアプローチをとりますよね。それと同じです。

ーー反対する人に協力を求めても、議論のテーブルについてもらうことが大変では？

私自身、チームにスクラムを導入しようとした際は反対するメンバーと何度も対話を重ねました。

その時は、「スクラムを導入したい」という自分の主張はいったん抑え、まず相手の話を聞くことに徹しました。すると、意見が異なるのは目の前にある短期的な手段の部分だけで、「ユーザーに価値を届けたい」という長期的な理想は共通していることが分かったんです。

この経験から、意見が対立したときは、双方の考えが一致するところまで目標を遠くに置いてみるというアプローチを学びました。

ーー長期的なビジョンから逆算して議論していく、ということですね。

同じ会社で働いている以上、企業の理念や10年後に目指す姿といった大きな方向性はある程度共有できているはずですよね。そこから徐々に時間軸を短くしていけば、1年後の事業目標くらいまでは意見を一致させられるかもしれません。

しかし、その目標を達成するために何を優先すべきかとなると、やはり意見が分かれます。機能開発を進めるべきだと考える人もいれば、販売施策に注力すべきだと考える人もいる。私のように、社内の開発プロセスを変えるべきだと考える人もいるでしょう。

そこからは、無理に説得せずに懐疑派代表として、一致している目標に向かう上での障害物を指摘してもらう……といった流れです。

ーー「懐疑派代表」のメンバーにも、他のメンバーと一緒にミーティングに参加してもらうんですか？

はい。意見が対立するような話こそ、チーム全体など複数人がいるオープンな場で話し合うといいですよ。

一対一でのやり取りは伝言ゲームになりますし、時間がかかって非効率です。それよりも、各メンバーが持っている情報や、それぞれの立場から見えていることを一つのテーブルに出し合う方がスムーズです。

チームで議論すれば意見の背景にある事情も理解できるので、納得感のある結論にたどり着きやすくなりますしね。

ーーその「納得感のある結論」というのがまた難しくて……。全員が納得する結論って、なかなか出ないですよね？

そうですね。ですが私は、スクラムの導入を通して物事を多数決や合議制で決めてはいけないということを学びました。

ーーえっ、むしろ合議制こそ定石では？

そう思いますよね。これが三つ目のステップです。

【3】「決める責任」はオーナーが持つ

スクラムの場合、プロダクトオーナー、スクラムマスター、開発者という役割を持ったメンバーが5〜10人程度のチームを組むことが一般的です。それぞれに果たすべき責任がありますが、中でもプロダクトの方針に関わる意思決定と、結果に対する責任を担うのがプロダクトオーナーです。

もちろん、メンバーの意見を聞くことは重要です。ただし、最終的に決める責任はプロダクトオーナー自身にあります。 これまで多くのスクラムチームを支援してきましたが、プロダクトオーナーであっても、こうした意思決定に慣れている人は決して多くないのが実情です。

ーー良かれと思って全員納得できる状態を目指している人も多そうです。

その通りです。「いい兄貴分」のような立場で、メンバー全員の声を集めていくリーダーは少なくありません。

ですが、最終的な意思決定の責任者を明確にしないまま多数決で方針を決めたり、全員が納得するまで話し合おうとしたりすると、意思決定の一貫性が失われてしまいます。

変化を生み続ける条件は「良いコーチであること」

ーー冒頭で「スタンダードが陳腐化するサイクルが早くなっている」とおっしゃっていましたが、これからの開発組織は「変わり続けること」が必要ということですよね。それがまた大変そうで……。

変化を継続させるためには、エンジニアから自発的に生まれたコミュニティをつくることが大切だと考えています。というのも、学習は強制できないからです。

健全なコミュニティにはモチベーションの高い中心メンバーがいて、勉強会などの活動を主催していることが多いんです。その情熱や好奇心に引き寄せられるように他のメンバーも集まり、活動が継続していく。それがコミュニティの醍醐味で、組織が変わっていくために欠かせないコアになります。

ーーそうした自発的な活動を継続させるには、マネジャーはどのような役割を果たすべきなのでしょうか？

従来のマネジメントには、目標を達成するための知識や経験が不足している部下を教え導く、という考え方があります。ですが今のソフトウエア開発の現場には、優秀な若手が数多くいますよね。そうした人たちに対して「能力が足りないから教えてあげよう」という発想で接するには限界があると思うんです。

むしろ重要なのは、本人が意欲を持ち、能力を最大限に発揮できる環境をつくること。そのため、近年はコーチングの重要性が高まっているのでしょう。

相手の内面にある意思やモチベーションに耳を傾け、それを引き出すことがコーチングの極意。Googleが優れたマネジャーの特徴をまとめた『Project Oxygen』という調査の中では、最も重要な条件として「良いコーチであること」が挙げられているほどです。

ーー組織を変えたいと思いながらも、周囲の反発や失敗への不安からなかなか一歩を踏み出せないエンジニアもいそうです。

組織を変えるというのは、基本的に逆境から始まる仕事ですからね。変化に対する抵抗がないことはまずありませんから、間違いなく苦労します。

ただ、それが不幸な仕事なのかというと、必ずしもそうでない。私も過去を振り返ると、激しく衝突したものの、結果的に良い関係を築き、今では笑い合えるようになった同僚がいます。結果的には得るものばかりでした。

つらい経験というのは、どこまでいってもつらいでしょう。ただ、苦労した経験は必ず何らかの学びや糧になると思うんです。仮に成果が出なかったとしても、経験や成長は残ります。

つまり、どう転んでも「成果」か「成長」のどちらかは手に入る。そう考えると、組織変革には大きな価値があると思いませんか？ 大きな変化に立ち向かおうとしている人には、ぜひ軽率に、たくさん失敗してほしいですね。

書籍情報

『野蛮なアジャイル ［サイボウズ発！］組織の常識を覆した反骨のスクラム実践記』（翔泳社）

今でこそアジャイルな開発文化で知られるサイボウズですが、その道のりは決して平坦なものではありませんでした。

本書は、同社史上初のスクラムマスターとしてアジャイル開発を社内に根づかせた著者による、泥臭い組織変革のドキュメントです。単なる成功談や理論の解説書ではありません。経験者ゼロで始めたスクラムによる大混乱、正しいやり方に固執するあまり起きた周囲との衝突、幾度となく壁にぶつかり迷走する苦悩など、人と組織が変わる裏側で起きていた真実が赤裸々に描かれています。

一人の「野蛮なエンジニア」の挑戦が、一つの開発チームから組織全体、さらには他部門へと広がっていく過程は、読む者の胸を熱くさせます。サイボウズで実際に起きた生々しい変革を追体験しながら、現状を打破し、自らの手でチームや組織を変えていきたいと願うすべての人の「野蛮な心」に火をつける1冊です。

＞＞詳しくはこちら

取材・文／秋元 祐香里（編集部）