全体性／Wholenessの分かりやすい例
2025年11月1日（土）に開催されたこちらのイベントの主要トピックだった「全体性／Wholeness」について、分かりやすい例を身近に見つけたので共有です。
（参考）鉄道模型の会社によっては、先頭車両（前後）とモーター付き中間車の3両で販売してくれるところもあります。これも全体性なのかなと。
生成AIと、組織力学と
2025年10月4日（土）に開催されたXP祭り2025にて、AWS在籍時にお世話になった福井 厚さんと久々に再会した際の雑談メモです。
（参考）福井さんにどのくらいお世話になったのかは、以下で分かります。
福井さんによると、最近は複数の様々な規模・業種の企業で、生成AIを活用して要件定義→設計→実装（→デプロイ）を一気通貫で実施できるようにすることにトライされているとのこと。一方で、ある程度この施策・活動を進めていくと、組織文化の壁的なものにぶつかり、生成AIだけではスムーズに進めづらくなる傾向があるとのことでした。
以下は私の所感です。
福井さんの生成AIでのお話は、チーム単位でアジャイルを進めていくと組織文化の壁にぶつかる例と非常に似ているなと思いました。
また、DORA (DevOps Research and Assessment) 発行の『Accelerate State of DevOps Report 2024』でも、組織におけるDevOpsの普及の際にこの組織文化の壁を乗り越えることがキーであること、そして一連の変革をリードする「Transformational Leadership（変革リーダーシップ）」が必要との記載がありました。
加えて、XP祭りと同日開催のスクラム祭りの広島トラックで、『Burnoutとの「対話」』と題して発表させていただきました。ここで私は、組織力学に対して、(1) 組織全体を一つのシステムに見立ててSystems Coachingを適用すること、および (2) マネージャー層や意思決定者に寄り添い傾聴をすることが役立つことを提示しました。
結論としては、生成AIもアジャイルも組織文化の壁に対するアプローチが必要であること、そして全社的なアプローチにおいてはツールや仕組みだけではなく変革をリードする人も必要であることが言えるのかなと、個人的に思いました。
いさかいを「笑顔」に変えるTips
以前とあるクライアントにて、メンバー同士のいさかいをアジャイルコーチとして仲介した際のメモです。
1. 経緯
とあるスクラムチームにて、POおよび開発者のリーダー格（以下「Tech Lead」と呼称）からそれぞれ「個別に」、（アジャイルコーチとして）相談に乗って欲しいとの依頼がありました。
PO曰く、「Tech Leadが全然リーダーシップを発揮してくれず、チームとしての進捗が上がらない」と。
一方でTech Lead曰く、「POから自分の役割以上のことを要求されて困っている」と。
そして両者共に、「アイツが悪いのでどうにかして欲しい」と。
2. アジャイルコーチとして考えたこと
まず両者共に、相手へ期待しているものが、役割の定義と本当にあっているのかが気になりました。
加えて、自身の相手への期待を直接本人に伝えていない／伝えられていないことも分かりました。
さらに、直接本人同士で話をしようとしないことも、チームとして健全なのだろうか？と思いました。
3. アクション: 「対話」の「デザイン」
両者が直接対話する場の設定が必要と考え、両者とのミーティングを設定し、私もファシリテーターとして参加しました。
対話を始める際、私は両者に、(1) 自分自身の役割は何だと認識しているか、および (2) 相手に対して何を期待しているかを話すよう依頼しました。加えてこの際、話してもらう内容はあくまで「今私はこう理解している」という事実・データとして扱うこと、またそれゆえに何を言っても良い、不利益は生じさせないことも説明しました。
両者が自身の役割および相手への期待を話す際、私はファシリテーターとして「それが今のあなたの理解なのですね」と都度確認し、両者および私自身が話の内容に対して自身の価値観で評価や判断を下すことなく、あくまで「客観的データ」として扱うようにしました（要は感情論に発展する芽を摘むよう振る舞いました）。
4. 結果
一連の対話の結果、(1) 双方ともに相手の役割を十分に理解できていなかったこと、また (2) 相手への期待が自分の一方的な思い込みだったことを理解し合いました。その上で改めて、何を相手に期待して良いかの認識合わせを行いました。
その後、両者ともに（私もびっくりするほど）非常に仲良くなり、頻繁に直接話し合い、チームの課題をどんどん解決していってくれました。
5. ポイント
一連のアクションのポイントを整理します。
(1) まず、両者が直接対話をしていなかったため、この点にメスを入れました。アジャイルソフトウェア開発宣言にある「プロセスやツールよりも個人と対話を」、およびアジャイル宣言の背後にある原則にある「情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです」との原点に立ち返りました。
(2) 両者の「コアビリーフ」のズレを見える化した上で、両者の相手への要求の明確化を図りました。この件については、RSGT2023で発表した以下の資料をご確認いただけると早いかと思います。
(3) 各自の評価や判断を一旦保留し、情報にフォーカスするようにしました。この点は、評価や判断を行わずに相手の話に集中するというコーチングの「傾聴」のスキル、および書籍『The Fifth Discipline』（日本語版: 『学習する組織』）にある「Dialogue and Discussion」の手法を参考にしました。
まとめ
メンバー同士のいさかいは、ややもすると「どちらが悪いので改善するように」といった「解決」をしがちですが、その裏側にある真因にメスを入れることが本質的に重要だと私は思います。
またいさかいも、活用次第ではメンバーの結束を高める絶好の機会にできます。そうした発想とやり方を与えてくれるのが、アジャイルの良い点の一つだと私は思います。
「黙る不安」との闘い
アジャイルコーチとして独立するために2025年2月末に会社を立ち上げ、本稿執筆時点で2社のクライアントにコーチングを提供しています。
独立後のアジャイルコーチングにおいては、私自身の過去10数年のアジャイルコーチとしての知識・経験だけに拘ることなく、ここ数年見聞を広め準備してきた以下のスキルも活用しています。
- Scrum Allianceのアジャイルコーチングに関するMicro-credentialsを通じて習得したスキル *1
- ICF (International Coaching Federation)系列のコーチングの学校で習得したプロフェッショナルコーチングのスキル
- チームだけではなく組織全体を一つのentityと見立ててアプローチするSystems Coachingのスキル
これらのスキルを活用し、実際にアジャイルコーチとして振る舞ってみての実践的な気付きや改善点などを記録していこうと思います。
今回は特に、「黙る」スキルについて記します。
目次
これまでの反省点
アジャイルコーチとしての私の過去の活動の反省として、クライアントの役員やマネージャーから「メンバー・チーム・組織の成長よりも、早急にプロダクトをリリースすることを優先して欲しい」との要望・依頼をされることがあったこと、またその際にコーチである私がクライアントにあれこれ作業指示をしすぎてしまったことが何度かあったことがあります*2。
クライアントの知識やスキルが乏しく自律的に考え行動できない状態の場合は、コーチングよりもティーチングや作業指示を優先した方が良いことは、プロフェッショナルコーチングでも言及されています。
しかし、私自身が「クライアントをコントロールしている」全能感に飲み込まれ、過度に指図を行ってしまい、結果クライアントから「言っていることは正しいけれども厳しすぎた」というフィードバックを受けた過去は、アジャイルコーチを名乗る以上一生背負っていかなければならない十字架だと認識しています。
上記の反省を踏まえ、現在のアジャイルコーチングでは、特に以下の3つを意識しています。
- 「傾聴」に徹する
- 許可を得てから教える
- 「プレゼンス」で「語る」
1. 「傾聴」に徹する
ここでの「傾聴」は、「クライアントの話を、途中で遮ったり質問したりすることなく集中して最後まで聴き、受け止めること」を意図しています*3。積極的な質問・相槌・リフレクション（言葉を返す）・ペーシングといった「積極的傾聴」を全くしないわけではないですが、より「聴く」ことに重きを置いています。
私が「傾聴」に関して特に意識していることは、次の3つです。
(1) 話しすぎない
これは文字通り、クライアントとの会話の際に、コーチである私自身が話しすぎないということです。
コーチングにおける傾聴の効果の一つに、「クライアントが『自分の話を十分に聞いてもらえた』という体験を得られる」ことがあります。この体験はクライアントにとって、「自分自身を尊重してもらえた」という感覚となり、ひいては自分の意見を言える安心感（心理的安全性）、およびコーチへの信頼感にもつながっていきます。
経験の浅いスクラムマスターやアジャイルコーチの中には、クライアントから会話を引き出そう、議論を円滑化させようという「善意」から、自発的に様々な話をする人がいます（私自身も初めはそうでした）。しかしそのような振る舞いは、たとえ「善意」から発したものであっても、クライアントにフォーカスするのではなく、スクラムマスターまたはアジャイルコーチが会話の主導権を握る形となります。そしてこれは結果として、クライアントの発言機会を奪い、クライアントが自身の課題やゴールに向き合うことを妨げます。
私は前職での上長との1on1で、上長が会話の90%以上を占有し、私の話を途中で遮り一切耳を傾けることなく、上長自身の考えを私に一方的に押し付けられ続けるという体験をしました。この体験は、後に自身のBurnoutの主要因になりました。この体験を踏まえ私は、元上長を反面教師として、コーチである私自身が話しすぎないことを強く意識し行動しています。
(2) 自身の価値判断を一旦脇に置く
これは、クライアントの話を聞く際に、自分自身の価値判断を一旦保留し、評価や判断をすることなく、集中して聴くということです。
クライアントが話す内容には、コーチである自分自身の価値観や判断基準とは異なる／反するものが含まれることがあり得ます。しかし、都度会話を遮ってそれらを指摘すると、クライアントは萎縮してしまい、自分の考えを表明することへの「恐れ」を感じるようになります。そうした「恐れ」は会話の透明性を損ない、結果としてクライアントの自発的な課題発見・解決・成長を妨げます。
少し話は変わりますが、最近書籍『The Fifth Discipline』（日本語版タイトルは『学習する組織』）を読み進めています*4。この書籍の第11章「Team Learning」で、アメリカの理論物理学者のDavid Bohmが、チームの学習を促進するための対話（dialogue）に必要な条件の一つとして、「仮定を保留する」ことを挙げていることが記されています。これは、対話の参加者が自身の仮定を一旦保留することで、各自が対話の内容に集中できるようになり、結果対話の流れが促進される（超意訳）ことを指します。まさにこれが、「自身の価値判断を一旦脇に置く」ことで私が実現したいことそのものです。
(3) クライアントの話を全て「受け止める」
これは、上記 (2) の「自身の価値判断を一旦脇に置く」とも被る部分がありますが、評価や判断をすることなく、クライアントの話を一旦全て受け止めることです。
ここでのポイントは、あくまで「受け止める」であり、「受け容れる」ではないことです。
クライアントの話を十分に聴くことの効果と重要性をこれまで記してきましたが、これらは、コーチがクライアントの考えに賛成・賛同し受け容れることとは違います。コーチの役割は、クライアントの自発的な課題発見・解決・成長を支援する「触媒」として振る舞うことです。そのためには、クライアントの考えに賛同するのではなく、中立であり続けることが重要です。またクライアントも、自分の考えをコーチに十分に「受け止められる」ことで、コーチから質問やフィードバックを受ける心の準備ができます。
これは伝わる人が限定されることを承知で書きますが、上記はプロレスと同じことだと私は考えています。プロレスは、相手の攻撃に対してしっかり受け身を取ることで、攻撃の威力やインパクトを観客に伝えられ、結果として攻防のラリーが白熱したものになっていきます。コーチングの対話も同様で、いかにクライアントの発言を受け止めて次につなげるかが、対話を有意義にするポイントだと私は考えます。
2. 許可を得てから教える
これは、クライアントに対して何かを教えたりフィードバックを行う際は、必ず事前にクライアントの許可を得てから行うことを指します。
私は過去、クライアントに対して「良かれと思って」一方的にあれこれ教えすぎて、不快な思いをさせてしまったことがあります。また私自身、前職で上長から、頼んでもいないのに一方的なフィードバックを受け続けて心を病み、退職しかかったことがあります。そうした体験から、クライアントが望まないことを教えたりフィードバックをすることは、お互いの関係を壊すものとして徹底して避けるようにしています。
さらに、プロフェッショナルコーチングをイチから学んだことで、クライアントに対して何かを教えたりフィードバックを行う際は、必ず許可を得てから行うことが基本なのだと理解しました。
一方でプロフェッショナルコーチングでは、クライアントの知識やスキルが乏しく自律的に考え行動できない状態の場合、「どうすれば良いと思いますか？」といったコーチング的な質問は、却ってクライアントのフラストレーションを溜めてしまう悪手であるとも教えています。そのような場合、私は以下のようにアプローチするようにしています。
- クライアントに対して、「（xxxについて）知っていますか？」と質問する
- クライアントから「知らない」との回答があった場合、「私はxxxについて教えられますが、いかがですか？」と確認する
- クライアントから「教えて欲しい」との回答を得られたら、初めて教える
- この際も都度、どこまで教えて欲しいかをクライアントに都度確認しながら進める
教え魔は自己満です。クライアントの自発的な課題発見・解決・成長を実現したいのであれば、そうした自己満からの卒業が必要だと私は考えます。
3. 「プレゼンス」で「語る」
これは、特に議論の場において、私自身が主体的に話したり議論をリードするのではなく、その場に存在し続けることでクライアントを後押しすることです。
より具体的には、(1) 発言しているクライアントの目を見て話を聴く、(2) クライアントの発言内容にうなずく、(3) クライアントの発言後、議論の場にいる人全員をしっかりと見ることで、クライアントの発言・議論を後押しすることを指します。
このアプローチは、上述の傾聴の「話しすぎない」と組み合わせることで、クライアントが安心して自分の意見を言えるようになることに加え、クライアントが発言に自信を持てるようになります。
それまでアジャイルの経験がないクライアントにとっては、はじめは何事につけて不安を感じるものです。そうした不安を減らし、自発的に自信を増やす。その観点でこの「プレゼンス」で「語る」アプローチは、自分が想像していた以上にクライアントがどんどん自信を持って議論するようになってきていて、大きな効果を今まさに体感し続けているところです。
まとめ
以上「黙る」スキルについて記してきましたが、そのポイントとして私は、コーチがスポットライトを浴びることなく、クライアントにフォーカスし続けることなのだと考えています。
ちなみに先日公開されたScrum Guide Expansion Packに、"A Scrum Master doesn't seek the spotlight." との記述をみつけました。まさにこれなのだなと。
また、意識して適切に「黙る」ことが、私が思っていた以上にクライアントの成長につながるのだなと今まさに実感しています。この辺りも含めて、アジャイルコーチング・プロフェッショナルコーチングにはまだまだ学ぶことがたくさんあるなと、今後が楽しみになってきています。
さて、年明け1月開催のRegional Scrum Gathering Tokyo 2026（RSGT2026）に、『Well-beingの「スキル」 〜 Burnoutを乗り越えるためのアジャイルコーチング概論 〜』と題して、今回のような内容を含めアジャイルコーチングについて語る内容のプロポーザルを出しています。
少しでも興味を持たれた方は、同サイトにログインして、ぜひ投票してください！
*1:詳しくは以下を参照。
- アジャイルコーチの基礎を体系的に学べる公式コースを受講しました
- アジャイルコーチの実践的スキルを学べる公式コースを受講しました
- アジャイルコーチの実践スキル 1000 本ノックをクリアしました
*2:最後にやったのは2022年で、その反省からコーチングなどを本格的に学ぶようになりました。
*3:ちなみにGoogleの「AIによる概要」によると、「傾聴」の定義は以下を指します。
- 相手の話に耳を傾け、理解しようと努める姿勢全般
- クライアントの話に耳だけでなく心も傾け、共感的に理解しようと努めるコミュニケーション技術
*4:モブプログラミングの創始者の一人であるChris Lucianさんに年初にお会いした際に勧められ、購入して読んでいます。
『Scrum Guide Expansion Pack』を読んで感じた「違和感」と「チャンス」
日本時間 2025 年 6 月 12 日（水）に公開された『Scrum Guide Expansion Pack』を、一通り読み終えました。
- 公式サイト: https://scrumexpansion.org/
- コンテンツ: https://scrumexpansion.org/scrum-guide-expansion-pack/
- GitHub リポジトリ: https://github.com/ScrumGuides/ScrumGuide-ExpansionPack
一通り読み終えて、いくつかの「違和感」と「チャンス」とを感じたので、備忘録よろしく書き出してみます。
目次
1. 「違和感」
(1) アドオン的なものか？
私は「Expansion Pack」の語感から、当初アドオン的なものをイメージしました。
※アドオン的な「Expansion Pack」の例
加えて、プログラミング言語のライブラリのように、ニーズに応じて取捨選択するものなのかとも当初は思いました。
しかし、コンテンツを読み進めていくと、個別に取捨選択するものではなく、「Expansion Pack」全体を一体的に理解・導入するもののようでした。
根拠
- "This Expansion Pack is designed to support all aspects of product delivery": 全体的なアプローチを志向している模様
- "The reader is expected to read the document sequentially, at least the first time.": 「少なくとも初回は順番に読め」とある
- スクラムの各要素（三本柱・価値観・役割・成果物・イベント）と相互依存的に記載されている
一方でスクラムは、コンテキストに合わせて取捨選択・適用することは可としているので、実は「Expansion Pack」も実質取捨選択可能なのか？などとも考えたりしています。
2025/06/21 7:05 追記
改めてスクラムガイド 2020 を確認してみたところ、「End Note」に以下の記載がありました。
The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
要は、一部だけを取捨選択して使用することは、アジャイルの実装としてはアリだけれども、それはスクラムとは言わないということです。
従って「Expansion Pack」も同様に、スクラムとして適用するなら取捨選択 NG、アジャイルの実装として適用するなら取捨選択 OK と言えるのではないか？と個人的に解釈しています。
(2) 目的: なぜ今これを？
そもそもなぜ今、「Expansion Pack」を出す必要があったのか？
これについては、冒頭の「Purpose of the Scrum Guide Expansion Pack」に、「スクラムガイド 2020 をベースに、現在の状況に関する追加のガイドを提供するもの（超意訳）」との記載があります。
昨今スクラムを語る際、OODA や Cynefin は当たり前になりつつあります。加えて、ここ数年の生成 AI による世の中の変化。こうしたものを、IT 業界以外向けに抽象化「しすぎた」スクラムガイド 2020 に肉付けすることを狙った模様です。
(3) 用語が変わった
これまでスクラムガイド内で使用されていた用語に、以下のような変化があることに気付かされます。
- 補足する単語が追加されているものがある
- 例
- Developers -> Product Developers
- Definition of Done -> Definition of Output/Outcome Done
- 例
- プロダクトの受益者（customer・user）や意思決定者（decision-maker）などをひっくるめて、「Stakeholder」として集約している
- 一方でコンテンツの文脈に応じて、ここでの Stakeholder が何を指すのかを必要に応じて列挙している
- （例）"Stakeholder (including but not limited to customer)"
- 一方でコンテンツの文脈に応じて、ここでの Stakeholder が何を指すのかを必要に応じて列挙している
私は用語の理解・扱いが雑なので、今回の変化は個人的には「分かりやすくなった」と感じました。一方で人によっては、これまで使用していた用語と変わっていることで説明に一貫性を保ちづらいといった点を指摘されている方もいらっしゃるようです。
(4) 説明が詳細になった
全体的に、各用語の説明が詳細になったなと感じました。また説明の仕方が、書籍『A Scrum Book』に非常に似ているなと個人的に感じました。
また、Product Thinking や Systems Thinking などの、スクラムの理解に役立つ理論・参考情報が集約されている点も、スクラムガイドと比較して親切だなと個人的には感じました。
加えて個人的には、「Product Vision」、「Product Goal」、「Sprint Goal」、各種 DoD との関連が分かりやすく記載されているなとの印象を持ちました。
(5) ヒトではないものが出てきた
Role の一つに、「Artificial Intelligence」が追加になっていますね。
また、例えばスクラムマスターの説明に、
"The Scrum Master must be human."
といった説明が追加されていたりします。
AI 時代の到来を、この「Expansion Pack」でも否が応でも感じさせられました。
※ちなみに「Product Developer」だけ「may be human or automated」と書かれていて、ヒトでなくてもよいのだなと。
2. 「チャンス」
上述のような「違和感」の一方で、私は以下の「チャンス」も同時にあるなと感じました。
- 学び直しとアイデアの再整理
- コントリビューション
(1) 学び直しとアイデアの再整理
用語が変わったことおよび説明が詳細になったことは、上述の「違和感」の中でも触れましたが、私は特にこれらを学び直しとアイデアの再整理のチャンスだなと感じています。
私は用語の理解・扱いが雑なので、これまでもスクラムについて上手く説明できていないなと感じることが多々ありました。その点で今回の「Expansion Pack」は、上手く説明できない点を学び直す点で、個人的に非常に助かると感じています。
(2) コントリビューション
今回の「Expansion Pack」は、GitHub リポジトリが公開されており、コントリビューションの方法も明記されています。
まだ公開されたてのコンテンツ、しかも日本だけでなく世界中に注目されているコンテンツにコントリビュートできることは、人によってはワクワクするのではないでしょうか？
かく言う私もそのワクワクに刺激され、見つけた表記バグに対して、勇気を出して GitHub の discussion を立ててみました。
著者の一人の Ralph Jocham さんらとも直接やりとりさせてもらい、すぐに Issue と Pull Request を作成・対応してもらえました。素敵なエクスペリエンス！
※ちなみに、Pull Request はクローズしたものの、まだ本番リリースはされていない模様です。
まとめ
あくまで個人的な所感ですが、この「Expansion Pack」は、アジャイルマニフェストのように定期的に立ち返るもの、軌道修正の参考にするものとして利活用すれば良いものだと考えています。スクラムガイドと同様、完璧に準拠するものではなく、必要に応じて創意工夫していくための起点としていけば良いのかなと。
また、内容の改善などに関与したければ、GitHub リポジトリ経由でコントリビュートできるので、チャンスも多いかなと。
自分に合った形でこの「Expansion Pack」を利活用していくことを、読者の皆さんにはオススメしたいです。
スクフェス新潟2025で「無理」についてお話してきました
2025年5月9&10日に新潟で開催された「Scrum Fest Niigata 2025」（以下「スクフェス新潟」と表記）に初参加し、『「無理」を「コントロール」するスキル』と題して、「無理」を克服するアイデアについてお話させていただきました。
目次
1. なぜスクフェス新潟でこのテーマを話したのか？
- 私自身、昨年Burnoutして病気・入院する体験をしました。
- その反省から、メンタルヘルスの側面からアジャイル・コーチングのアイデアを整理していました。
- 今年2月頃、アイデアがある程度まとまり、どこかで発表したいなと考えていたところ、スクフェス新潟のプロポーザル募集が目に入りました。
- そこで詳しく調べてみたところ、セッショントラックに「メンタルヘルス」とありました。
- 何やら見えないものにお膳立てされている気がして、プロポーザルを提出し、採択され、登壇したという流れです。
セッショントラックの件については、スクフェス新潟の運営のJumpei Itoさんおよびかわぐちさんから、以下のように説明を受けました。
- スクフェス新潟は、Agile Testing Daysを日本に持ち込むことが当初の狙いだった。
- Agile Testing Daysには、「メンタルヘルス」というトラックがあり、スクフェス新潟もこれに倣った。
個人的には、何とも運命に導かれた感覚でした。（まさにデスティーノ）
2. スライドのポイント
- そもそも「無理」ってなんだろう？という疑問から、このスライドを作成しました。
- 以前から「無理をするな」という指摘を多くの方から受け続け、自分なりにさまざまな取り組みを続けてきましたが、それでもメンタルと体調を崩すことがありました。
- 一方で、「無理をするな」と指摘する人に「どうすれば無理をせずに済みますか？」と質問すると、ほとんどの人が「自分で考えろ」と返答してくることに、「それだと困るんだよな」とも感じていました。
- そこで、自分なりに「無理」を分解・明確化し、何をすれば良いのかをより具体化する必要があると考えました。
- ここ数年、アジャイルコーチングおよびプロフェッショナルコーチングの学習を進めて、「Burnout」*1と絡めて「無理」の整理・明確化ができると考え、まとめたのがこのスライドになります。
3. Workに対するリモート参加者の反応
今回の発表では、合計4つのWorkを実施しました。その際のリモート参加者からのDiscordでの投稿を、以下にまとめます。（みなさん、投稿ありがとうございました☺️）
(1) 自身の「無理」をした失敗談 (P6)
- 学生時代9時に起きる生活してたのに、一週間7時に起きて１時間半電車に揺られないといけなかった時くらい（あまり無理したことがないきが...
- 某スタートアップ立ち上げ期時代（不夜城時代）自分のタスクでも寝泊まりする状態だったのに、困ってる仲間の手伝いまで安請け合いしてしまって。。。もう無理。。（実質手伝いというより迷惑かけたみたいな。）
- 高熱出てたけど急がなきゃいけない・・・と頑張った結果、仕事は終わったけどインフルエンザでしばらく寝込みました
(2) 自身が考える「無理」の定義 (P13)
- 普段の生活に支障が出る（睡眠時間削るとか）行動
- 自分の能力(体力や知識)だけだと対応しきれない行動を続けること
- 限界超えてるかもと自覚がありつつも、迷惑かけちゃうなーとか相談できないなーとかになっちゃってる状態
- キョムリ！
- 不安を感じたときに無理という定義に置き換えるかも
- 理にかなってない状態とか
- できるけどやりたくないことをしているとき（気持ち的に無理をしている時）
- 実は不可能なものをやってしまうのが無理、かも？
- 悪いことが起きたら「無理」だった
- 達成を約束できない難しこと。行う事に気合が必要なこと。
- 無理の定義が無理ぃ〜
- 無理の対義語は道理
(3) 自身が考える「無理」の減らし方 (P22)
- 無理を減らすのは無理！（離れることができるのであれば、根元から断つ）
- やりたくない事はやらない！やりたくないことをやる時は仲間みんなでやる！
- 自己開示をしつつ、周りの協力を仰ぐ、難しそうなら原因となっているものから撤退する
- 余白、余裕を持つ。そして、「勇気」を持ってそれはできませんという。（もちろんしっかりとその理由も伝える）
- 自分に期待しない、他人に自分を期待させ?ない
- 無理であることを共有して助けてもらえるようにしておく…
(4) 自身の心身の回復方法 (P29)
- ちゃんと食べて、ちゃんと寝て、ダラダラ過ごす
- 休む。自分にとって安らぐと感じる手段で休む。
- 楽しみを作る
- ゆっくりお風呂入って早く寝る
- サウナで無になる
- 普段やっていることから距離を置く意味で、どこかに遊びに行く
- 散歩、ランニング、話す。歌う、ぼーっとする。海いく。
- あそぶ
- たべる
- ねる
- 吐き出す
- やりたくないことから離れる
- 美味しいものを食べる
- 寝たいときに寝る
4. フィードバック
参加者からいただいたフィードバックを、以下にまとめます。（みなさんありがとうございました☺️）
(1) 現地で直接いただいたフィードバック
- 「無理」について、ここまで明確に言語化したことがなかった
- 「無理」へのアプローチが、感覚的なものではなく、実験・仮説検証に基づく科学的なものだった
- （そもそも何をどうすれば良いかわからなかったため、）「無理」について考えるきっかけになりそう
- （コーチングのアプローチを知らないため）魔法にかけられたような感覚があった
- 近年の国内外のBurnoutの増加から、今回のテーマは追う価値があると思う。一方で、周りで追っている人は少ない。もっと追究してみてはどうか？
(2) Discordでいただいたフィードバック
- 無理を見える化する時間がなくて無理、だと重症だな
- 業務時間という側面だけを見てメンバーに「無理しなくて良いよ」って言っちゃう
- 無理とかの異変を知るには日々、その人を見れているか、話しを聞いているかは重要そう
- 無理だと思っていたものを乗り越えられちゃうと次回以降無理の定義が上がってしまうから無理とチャレンジの境目が難しい
- 無理とチャレンジの境目が難しい＞ここも無理に「気づく」スキルにつながりそう
5. 私自身の気づき
発表および参加者との対話を通じて、私自身が気付いたことです。
- 真のニーズなどの明確化の観点で、プロフェッショナルコーチングのアプローチが役に立つなと改めて感じました。
- 一方で、参加者の多くがコーチングを知らないことも分かりました。
- 「成長エリア」だと言えそう
- 「無理」やBurnoutへの対策には需要があると、小田中さん・しかのさんらから教えていただきました。
- 一方で、「無理」やBurnoutを考える上で、稼働率や勤務時間の高さがネックになっていることも、改めて分かりました。
- 改めて書籍『ゆとりの法則』を広める価値がありそう。
- 私自身も含め、「他人を変えなければいけない」と自然と考えがちだなとも感じました。
- 「自分はコントロールするが、他人はコントロールしない」
- 他人を「変える」のではなく、「変えよう」と自発的に思ってもらい、その実現方法を考えることを支援することが必要で、そこでプロフェッショナルコーチングのアプローチが役立つのかなと。
6. まとめ
発表を聞いてフィードバックをくださった皆さん、相談をしてくださった皆さん、運営の皆さん、会う人会う人が皆さん暖かく、初参加だったにも関わらず、自宅のような安心感を感じられた2日間でした。皆さん本当にありがとうございました！
ある意味こうした体験が、「無理」を減らしたりResilienceを高めることになるのかなとも思っています。
「無理」およびBurnoutについては、多くのフィードバックをいただいたので、今後も研究を続け、近々またどこかで発表させていただきたいなと思います。
*1:「長期にわたる或いは過度のストレスによって引き起こされる、感情的・肉体的・精神的な疲労状態であり、多くの場合、皮肉な気持ち・孤立感・達成感の欠如といった特徴を伴う」（出典: 『Accelerate State of DevOps Report 2024』 P.4）
*3:同上
（アジャイル実践者向け）DevOpsレポートから考える、生成AI時代の居場所の見つけ方
ここ最近の生成AI関連のニュースは、いま自分が激動の時代に生きているのだという喜びや興奮を感じさせてくれます。また、2025年4月2日に公開されたThought Work社の『Technology Radar Vol.32』のトピックの50%がAI関連のものであったことは、この（生成）AIの潮流が一過性のものではないことを示唆していると言えそうです。
一方で、上述の生成AIを使い、その高い能力・有効性・可能性などを実際に目の当たりにしてみると、「自分たちは要らないのでは？」という不安を感じることも正直増えてきたと、個人的に感じています。また、同様の不安を訴える友人・知人が増えたなとも感じています。
この生成AI時代において、私たちだからこそ出せる価値ってあるのだろうか？
2024年11月に公開されたDORA (DevOps Research and Assessment)の『Accelerate State of DevOps Report 2024』*1（以下「同レポート」と表記）を元に、この疑問について改めて調査し考察してみたところ、思いのほか出せる価値が存在していることに気付きました。
このエントリーでは、「現在の生成AI時代における、私たちだからこそ出せる価値の見つけ方」について、同レポートで言及されている3つの課題とその解決への関わり方を分析する形で考察していきたいと思います。
ちなみに上記分析は、私自身がアジャイル・DevOpsの実践者であることを前提に行なっています。読者の皆様には、ご自身の強み・好み・役割などに置き換えて読み進めていただければと思います。
目次
1. 生成AIによるデリバリーの不安定化
同レポートによると、生成AIの利用が広まった結果として、ソフトウェアのデリバリー、具体的には「Change Failure Rate（変更に障害が含まれる割合）」と「Rework Rate（障害を取り除くなどの再作業が必要になる割合）」の悪化が見られるとのことです。*2
(1) 考えられる原因
同レポートは、生成AIが一度に大量のコードを作成・更新できる結果、デリバリー1回当たりのコード変更量が増加していることに原因があるとの仮説を提示しています*3。このことは、大量のコード追加・更新があることでPull Requestが肥大化し、結果レビューにかかる時間および問題を見落とす確率が増加すると考えるとイメージしやすいのではと思います。
(2) 対策
同レポートは上記対策として、バッチサイズを小さくすること、および堅牢なテストメカニズムを構築・運用することといった、基本に立ち返る必要性に言及しています。要は、デリバリー1回当たりのコード変更量を減らし、ローカル環境およびCI/CDパイプラインでのテスト自動化を活用することでフィードバックサイクルを短くし、問題発見および対応の効率を高めると良いということです。
(3) 価値を活かせる点
上述の取り組みをリードしメンバー・チーム・組織に定着させるという観点では、短いフィードバックサイクルの有用性を説明し、必要に応じてこれを実践できるスキルが有用です。この点で私は、スクラムの透明性・検査・適応についてクライアントに説明できるアジャイルコーチのスキル、およびXPなどの反復型開発を説明し実践できるアジャイル開発者の知識・経験を活かせると考えます。
2. Burnout
同レポートでは、DevOpsを中心とした各種取り組みの評価指標として、「生産性」や「組織のパフォーマンス」といった項目に加えて、「Burnoutの減少」を挙げています*4。
ちなみにBurnoutとは「燃え尽き症候群」のことで、同レポートではこれを「長期にわたる或いは過度のストレスによって引き起こされる、感情的・肉体的・精神的な疲労状態」であり、「多くの場合、皮肉な気持ち・孤立感・達成感の欠如といった特徴を伴う」と定義しています*5。
このBurnout、Scrum Allianceのアジャイルコーチ／アジャイルコーチングのコースでも言及されており*6、海外の企業では「仕事の満足度」と併せて考慮されることの多い指標です。
(1) 考えられる原因
同レポートで挙げられているBurnoutの増加例のうち、ここでは特に以下の3例をみていきます。
- 価値ある仕事に使える時間の減少
- AI導入後の変化として、個人が価値ある仕事に使える時間が減っていることが同レポートで指摘されています。これは、「自分が役に立っていない」という不安を抱いたり、モチベーションが低下するなどの形で、Burnoutの増加に繋がり得ると考えられます。
- 組織の優先順位の不安定さ
- 組織の優先順位が頻繁に変更され不安定な状態になると、生産性の大幅な低下と共にBurnoutが増加することが、同レポートで指摘されています。
- ユーザー価値につながらない仕事の増加
- 特に開発者目線では、ユーザー価値につながらない仕事に多くの時間を使うほどBurnoutが増加する傾向があると、同レポートは指摘しています。
(2) 対策
上記のBurnoutの例に対して、同レポートが挙げている対策をみていきましょう。
- 価値ある仕事に使える時間の減少
- 個人が価値ある仕事により時間を割けるよう、組織として時間の使い方を見直すことを提言しています。
- 組織の優先順位の不安定さ
- （経営層や役員の交代などがあっても）それまでの優先順位を劇的に変えないよう、組織として優先順位を安定させることを提示しています。
- ユーザー価値につながらない仕事の増加
- 「ユーザー中心主義」、ユーザー価値につながる仕事により多くの時間を割けるようにすることを提示しています*7。要は、自分の行動が誰かの役に立っている実感が得られる状態が好ましいということです。加えて、「ユーザー中心主義」の実現の観点から、クロスファンクショナルなアプローチが有効であることも同レポートでは指摘しています。
(3) 価値を活かせる点
それぞれの例に対して、私が活かせると考える点を以下に挙げます。
- 価値ある仕事に使える時間の減少
- メンバー・チーム・組織が価値ある仕事を見つける観点で、心の底から求めているけれども自分だけでは気付きづらい欲求を見つけ、その実現のための選択肢と成長手段を考えるプロフェッショナルコーチングのスキルを活かせる余地が大いにあると考えます。
- 組織の優先順位の不安定さ
- チームを安定させることによる中長期的な効果を説明できるアジャイルコーチのスキルを、組織の優先順位を安定させることにも応用できるのではないかと考えます。
- 特にこの点をアジャイルの視点から考える際には、『When Leadership Changes, Who Pays the Price?』が非常に参考になると思います。
- ユーザー価値につながらない仕事の増加
3. 「変革型リーダー」の必要性
同レポートでは、DevOpsなどの技術的な仕組み・施策やその裏付けとしてのビジョンなどを組織に定着させ、組織変革をリードする人としての「変革型リーダー」*8の有効性について章を割いています*9。
(1) 「変革型リーダー」の定義・役割・期待される効果
同レポートでは「変革型リーダー」を、「従業員の価値観や目的意識に訴えることで従業員を鼓舞し、動機付けを行い、より高い業績を達成させ、大規模な組織変革を促進する（リーダーの）モデル」と定義しています*10。
また「変革型リーダー」の具体的なアクションとして、以下のものを挙げています。
- 権限と自律性を、チームに委譲する
- 課題解決に必要なメトリクスやビジネス情報を、チームに提供する
- 機能の提供ではなく、価値の提供を中心としたインセンティブ構造を構築する
- メンバーを鼓舞し信頼と尊敬を集めつつ、「ただ管理する」のではなく、ビジョンを示し、育て、変革を促す
さらに同レポートは、「変革型リーダー」の存在によって以下の効果が期待できると記しています。
- Burnoutの減少
- 仕事の満足度の向上
- チーム・組織のパフォーマンスの向上
- プロダクトのパフォーマンスの向上
(2) 変革型リーダー ≒ アジャイルコーチ説
私はこの「変革型リーダー」を、組織変革までをスコープに含めたアジャイルコーチの振る舞いと同じ、もしくは極めて似ている存在であると思いました。その理由を以下に挙げます。
- 鼓舞し導く存在である点
- 「触媒」である点
- ロールモデルである点
アジャイルに関する多くの書籍・論文・ブログでは、ビジョン・ルール・仕組みなどを整備して任せるだけでは、人・チーム・組織は以前の慣れたやり方（status quo）に戻りがちな傾向があることが指摘されています。このstatus quoへの引力を断ち切り、継続的改善を自発的・自律的に根付かせる点が、「変革型リーダー」の動き方であり、かつ「アジャイルコーチ」にも合致する振る舞いであると感じました。
4. まとめ: 私たちの居場所
AI、特に生成AIが登場してから、私たちの生活・行動・働き方には着実に変化が起きています。
一方で同時に、（生成）AIによる新たな課題や、注力することで大きな価値が期待できる新たな領域も発見されつづけています。
これらの課題や領域を上述のように改めて分析してみると、必ずしも（生成）AIなどの最新技術でなければ解決できないものではないこと、そして私たちのこれまでの知識・経験を活かせる部分があることに気付かされます。
新たに生じた課題やニーズのある領域に対して、その本質的課題やニーズを分析・明確化し、自身の強みを活かせるところを探す。
そして活かせるところを見つけられたら、それらを通じて課題解決や価値提供を行い、（やや大袈裟な表現ですが）広く社会・人類全体に貢献する。これこそが、「現在の生成AI時代における、私たちだからこそ出せる価値の見つけ方」だと私は考えます。
私も上記の観点から、Burnoutの減少に自身の居場所があると考え、これまでの知識・経験の整理・体系化を進めています。そして、2025年5月10日（土）のスクラムフェス新潟2025にて、『「無理」を「コントロール」するスキル 〜 Resilienceを高める実践的な観点と振る舞い方 〜』と題して、アジャイルおよびコーチングの観点からBurnoutを発見し回復するスキルについてお話しさせていただく予定です。
今回は特に、自身のアジャイル・DevOpsの実践者の視点から「居場所探し」をしてみました。
もし読者の皆様の中に、私と同様に「自分たちは要らないのでは？」という不安を抱かれている方がいらっしゃるのであれば、上述の方法でご自身の強み・好み・役割を活かせる「居場所」を探してみることをおすすめしたいです。案外自分の近くに「居場所」が見つかるかもしれません。
*1:Google CloudのDORAチームが毎年公開している、DevOpsに関する最新の研究結果をまとめたレポートです。
*2:『Accelerate State of DevOps Report 2024』 P.39
*3:2024年5月に公開された『Research: Quantifying GitHub Copilot’s impact in the enterprise with Accenture』に、GitHub Copilotを使用することでPull Requestのマージ率が15%増加したとの記載がみられます。
*4:『Accelerate State of DevOps Report 2024』 P.4
*5:同上
*6:アジャイルコーチの基礎を体系的に学べる公式コースを受講しました
*7:「ユーザー中心主義」については、Burnoutの減少だけではなく、仕事の満足度およびプロダクト品質にもプラスの影響があると、同レポートでは指摘しています。
*8:英語では「Transformational Leader(ship)」と表記します。
*9:『Accelerate State of DevOps Report 2024』 P.69-76
*10:『Accelerate State of DevOps Report 2024』 P.70
*11:アジャイルコーチの基礎を体系的に学べる公式コースを受講しました
*12:『Accelerate State of DevOps Report 2024』 P.71
*13:アジャイルコーチの基礎を体系的に学べる公式コースを受講しました
*14:同上
