AI時代だからこそ考える、僕らが本当につくりたいスクラムチーム / A Scrum Team we really want to create in this AI era

by TAKAKING22

Embed

Start on current slide

Slide 1

Slide 1 text

AI時代だからこそ考える、僕らが本当につくりたいスクラムチーム及部敬雄 (@TAKAKING22) 2025/10/04 スクラム祭り2025 福岡トラック

Slide 2

Slide 2 text

世はまさにAI時代

Slide 3

Slide 3 text

「またAIの話かよ・・・」って思ってませんか？

Slide 4

Slide 4 text

2022年11月、ChatGPTリリース Photo by BoliviaInteligente on Unsplash

Slide 5

Slide 5 text

当時は新たな技術の登場にわくわくしていた

Slide 6

Slide 6 text

それから3年が経ち、目に入ってくるのはAIに関する話題ばかり

Slide 7

Slide 7 text

AI疲れ

Slide 8

Slide 8 text

第四次産業革命、真っ只中第一次産業革命（18ʙ19世紀）：蒸気機関第二次産業革命（19世紀後半ʙ20世紀初頭）：電力、大量生産第三次産業革命（20世紀後半）：コンピュータ、自動化第四次産業革命（21世紀ʙ現在）：AI、IoT、ロボット

Slide 9

Slide 9 text

技術革新を背景に生産方式や社会構造が  急速かつ大規模に変化する歴史的転換のこと産業革命

Slide 10

Slide 10 text

AI疲れの正体ほとんどの人にとって今起きている変化は過去最大級今目の前で起きている・起きようとしている変化量が大きすぎて認知の許容量を超えてオーバーフローしている状態生存本能から現状維持バイアスがかかり、変化を受け入れようとしない

Slide 11

Slide 11 text

https://www.youtube.com/watch?v=nHIlMlpDWzg "The Agilists’Emerging Superpower and Our Planetary Challenge”/ Lyssa Adkins：RSGT2023 Keynote

Slide 12

Slide 12 text

目の前の変化を乗り越えたら次の変化が来る

Slide 13

Slide 13 text

あれ？アジャイルソフトウェア開発宣言スクラムガイド2020

Slide 14

Slide 14 text

私たちは知っているアジャイル開発やスクラムの普及期、変化を受け入れない現状維持バイアスと戦って変化を起こそうとしてきた ex. 今仕事ができてるんだから変える必要ないのでは？ ex. そんなよくわからない新しいやり方は採用できないアジャイル開発やスクラム自体、変化に適応することが主な目的

Slide 15

Slide 15 text

アジャイル開発の実戦経験を積み、コミュニティで研鑽を続けてきた私たちが今こそAI時代という変化に適応するとき Photo by Thao LEE on Unsplash

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

AI時代だからこそ考える、僕らが本当につくりたいスクラムチーム及部敬雄 (@TAKAKING22) 2025/10/04 スクラム祭り2025 福岡トラック

Slide 18

Slide 18 text

AI時だからこそ考える、僕らが本当につくりたいスクラムチーム生成AIの登場により、ソフトウェア開発はかつてないスピードで変化しています。コーディングやドキュメント作成、資料作成といった“作業”は加速度的に効率化が進み、 Vibe CodingやAgentic Codingのように、開発の役割や働き方そのものを揺さぶる変化も生まれています。では、こうした変化の中で、私たちのマネジメントや開発プロセスは変わらないままでいられるでしょうか。もし変わらないとしたら――その時、ボトルネックになるのは“人やプロセス”かもしれません。スクラムは、チーム全体が一つの“全体性”として動くことを支えるフレームワークです。しかし普及が進むにつれ、その本質は形骸化しがちです。生成AIと共に働く時代だからこそ、チーム・組織・プロダクトの全体を見渡し、「全体で創る力」がますます問われているのではないでしょうか。このセッションは、私が答えを提示する場ではありません。正解が見えない中でも、未来の開発のあり方を妄想し、語り合いながら、「僕らが本当に作りたいスクラムチーム」を一緒に描くための対話の場です。参加者の皆さんと共に、AI時代のスクラムチームの可能性を探求します。

Slide 19

Slide 19 text

お話のターゲット AIによる変化は感じているものの、具体的に自分たちの仕事への影響について考える時間を持てていない方

Slide 20

Slide 20 text

Learning Outcome AIがソフトウェア開発に与える具体的な影響を理解できるすでに起きている変化とこの先起こりうる変化の可能性を知ることができる AI時代のアジャイル開発やチームのあり方を考えるきっかけを得られる正解ではなく、自分たちの答えを描くための視点を持ち帰られる

Slide 21

Slide 21 text

TAKAKING22 及部敬雄制御不能なアジャイルモンスター株式会社ホロラボ執行役員 Silver Bullet Club所属 AGILE-MONSTER.COM アジャイルコーチ

Slide 22

Slide 22 text

アジェンダ AIとソフトウェア開発スクラムはこのままでよいのか AI時代だからこそ本当につくりたいスクラムチーム

Slide 23

Slide 23 text

アジェンダ AIとソフトウェア開発スクラムはこのままでよいのか AI時代だからこそ本当につくりたいスクラムチーム

Slide 24

Slide 24 text

元年 "*

Slide 25

Slide 25 text

⇒2025年4月時点で1,500万人以上 AI時代のアジャイル開発（XP祭り2024版）

Slide 26

Slide 26 text

2025年2月から3月くらいの調査期間のレポート

Slide 27

Slide 27 text

AI活用はコード生成とリサーチがメイン https://2025.stateofai.dev/en-US/

Slide 28

Slide 28 text

AIによって生成されたコードの割合は平均28% https://2025.stateofai.dev/en-US/

Slide 29

Slide 29 text

よく使われるモデルはChatGPT、IDEはCursor https://2025.stateofai.dev/en-US/

Slide 30

Slide 30 text

AIエージェント

Slide 31

Slide 31 text

Vibe Coding 2025年にAIエージェントが進化し、Vibe Codingが登場したことで、ソフトウェア開発の変化のスピードが一気に加速した Claude Codeから定額制が導入されたことも大きい AIエージェントの自走力が上がり、並列開発も可能に「コードを書く」から「問いを立て、設計する」へ

Slide 32

Slide 32 text

“In one year, AI will be writing 100% of code.” - Dario Amodei -

Slide 33

Slide 33 text

AIとソフトウェア開発の現在（2025/10） Claude CodeやCodex、Gemini CLIなど強力なツールが  登場し、ソフトウェア開発における生成AI活用が加速している開発の作業支援からAIエージェントへ Vibe Coding、そしてAgentic Coding 「AIと委託」か「AIと伴走か」

Slide 34

Slide 34 text

AIとソフトウェア開発の現在（2025/10）作業効率は確実に上がっているが、ソフトウェア開発全体の  スループットが劇的に変化しているようには感じない Outputの量とスピードが増えたことで、ソフトウェア開発に  おける問題がより健在化しやすくなったレビュー、品質、人材育成、コミュニケーション・・・ OutputをOutcomeにつなげる部分が追いついていない

Slide 35

Slide 35 text

再び開発プロセスやチームがボトルネックに

Slide 36

Slide 36 text

Open AI社が唱える5つのステージ Stage 1：Chatbots, AI with conversational language Stage 2：Reasoners, human-level problem solving Stage 3：Agents, systems that can take actions Stage 4：Innovators, AI that can aid in invention Stage 5：Organizations, AI the can do the work of organization

Slide 37

Slide 37 text

変化は止まらない AIの進化はまだ過程の段階現時点でプロセスやチームがAIの性能を引き出せていないだけで、  そこを支援するAI技術の登場や、人・チームの適応によって、  革命的な変化が急に訪れることも好むか好まざるかに関わらず、変化のベクトル自体は誰も止められない

Slide 38

Slide 38 text

アジェンダ AIとソフトウェア開発スクラムはこのままでよいのか AI時代だからこそ本当につくりたいスクラムチーム

Slide 39

Slide 39 text

スライド7枚で「スクラム」

Slide 40

Slide 40 text

スクラムの構成要素スクラムチーム開発者プロダクトオーナースクラムマスター作成物プロダクトバックログスプリントバックログインクリメントイベントスプリントスプリントプランニングデイリースクラムスプリントレビュースプリントレトロスペクティブ 1

Slide 41

Slide 41 text

スクラムマスタープロダクトオーナー開発者教える支援するつくる価値を最大化する教える支援する 2

Slide 42

Slide 42 text

スクラムマスタープロダクトオーナー開発者教える支援するつくる価値を最大化する教える支援するスクラムチーム 3

Slide 43

Slide 43 text

Day1（水） Day2（木） Day3(金） Day4（月） Day5(火） 9:00 10:00 スプリントプランニング 11:00 12:00 13:00 デイリースクラム 14:00 15:00 スプリントレビュー 16:00 バックログ  リファインメント 17:00 スプリント  レトロスペクティブスプリント 4

Slide 44

Slide 44 text

スクラムのイベントと作成物の関係 1. プロダクトバックログを用意する 2. スプリントバックログを用意する（スプリントプランニング） 3. スプリントを実施する 4. チームの状況を毎日検査をする（デイリースクラム） 5. 成果＝インクリメントを見せる（スプリントレビュー） 6. 開発の様子をふりかえる（スプリントレトロスペクティブ） 5

Slide 45

Slide 45 text

何度も繰り返すスプリントを何度も繰り返すチームで学習してうまくなっていく 6

Slide 46

Slide 46 text

スクラムのまとめプロダクトの機能を欲しい順番に並べ変えてその順番につくること  で成果を最大化する（価値を基準）短い時間に区切って繰り返す（タイムボックス）仕事の状況や問題を関係者間で常に共有する（透明性）定期的に仕事の進捗やプロダクトの方向性や仕事の進め方に  問題がないかを確認する（検査）もっとうまくやる方法を常に追い求めてやり方を変えていく（適応） 7

Slide 47

Slide 47 text

よくある現実スクラム（私見）チームの人数は4ʙ7人スプリントの期間は1ʙ週間プロダクトオーナー、スクラムマスター、開発者（プロダクトオーナーはいるけどスクラムイベントくらいしか話してない）（会社の役割は変わらないからエンジニアの誰かがスクラムマスター兼任になる）チームで仕事が完結する機能横断型なチームを構成したい（デザイナーやテストエンジニアもチームに入ってほしいけどチーム横断になりがち）タスクは個人アサイン型でカンバンで管理（スウォーミングはわかるけど生産性悪そうだし現実的ではない）

Slide 48

Slide 48 text

この2年間で、あなたのチームの開発プロセスや構造は  どれくらい変わりましたか？

Slide 49

Slide 49 text

よくある現実スクラムの最近（私見）開発者が生成AIツールを使って仕事をするのが普通になってきたロールの役割や仕事の進め方は以前と変わっていない生成AIツールを使って作業は効率的はなったけど、チームの OutputやOutcomeが大きく変わった感じはしない

Slide 50

Slide 50 text

どれだけ車が速くなったとしても、ドライバーや道路環境が変わらなければスループットは変わらない

Slide 51

Slide 51 text

「開発プロセス」や「チーム」も変化の対象 Photo by Gift Habeshaw on Unsplash

Slide 52

Slide 52 text

Scrum Guide Expansion Pack https://scrumexpansion.org/ja/scrum-guide-expansion-pack/2025.6/

Slide 53

Slide 53 text

https://www.servantworks.co.jp/resources/created/scrum_overview/

Slide 54

Slide 54 text

Scrum Guide Expansion Pack 2025年6月11日に公開（日本語訳も公開されている）スクラムガイド共同著者ジェフ・サザーランド氏が著者の一人公式ガイドではなく非公式のパタンライブラリスクラムガイドを補完する目的で、特に生成AIによって  もたらされる変化への適応を考慮されて書かれている役割の再定義と拡張、コミットメントの再定義、理論の強化 GitHub上で公開され、誰でもフィードバックすることができ、  四半期ごとに更新される予定

Slide 55

Slide 55 text

スクラムはこのままでよいのかこの2年間で開発プロセスやチームがあまり変わっていないとしたらそこがボトルネックになっているかもしれない AIによってソフトウェア開発にもたらされる変化に合わせて、  開発プロセスやチームも適応していかなければならないスクラムも更新されていくが、それ以上のスピードで  自分たちの開発プロセスもチームも更新していく必要がある

Slide 56

Slide 56 text

明確に区別する制約を理解しその中でできることを模索すること、そして成果を出しながら周囲の信頼を獲得し、制約自体の除去にも取り組んでいくこと「できることを一生懸命やっている」という自己正当化を行い、制約に飲まれて妥協したやり方でただこなしていることこの2つは明確に区別しなければならない

Slide 57

Slide 57 text

変化の過程？それとも妥協？チームの人数は4ʙ7人スプリントの期間は1ʙ週間プロダクトオーナー、スクラムマスター、開発者（プロダクトオーナーはいるけどスクラムイベントくらいしか話してない）（会社の役割は変わらないからエンジニアの誰かがスクラムマスター兼任になる）チームで仕事が完結する機能横断型なチームを構成したい（デザイナーやテストエンジニアもチームに入ってほしいけどチーム横断になりがち）タスクは個人アサイン型でカンバンで管理（スウォーミングはわかるけど生産性悪そうだし現実的ではない）

Slide 58

Slide 58 text

これから起こり得る２極化 AIの進化を吸収してチームで生産性を上げて価値を向上していくチームいままでとあまり変わらないチーム

Slide 59

Slide 59 text

アジェンダ AIとソフトウェア開発スクラムはこのままでよいのか AI時代だからこそ本当につくりたいスクラムチーム

Slide 60

Slide 60 text

AI時代だからこそ本当につくりたいスクラムチーム柔軟で滑らかな開発サイクル複数の小さなチームとロールの再定義学習する組織化

Slide 61

Slide 61 text

柔軟で滑らかな開発サイクル

Slide 62

Slide 62 text

生成AIによる開発サイクルへの影響 .PO 5VF 8FE 5IV 'SJ ίϛϡχέʔγϣϯ ։ൃ “スプリントは1ヶ月以内の決まった長さ” via スクラムガイド2020 コミュニケーションをするタイミングをつくる ex. スプリントプランニング、デイリースクラム、スプリントレビュー… それ以外のスプリント期間で開発を進める

Slide 63

Slide 63 text

生成AIによる開発サイクルへの影響 .PO 5VF 8FE 5IV 'SJ ίϛϡχέʔγϣϯ ։ൃ AIによって開発が効率化され、同じ仕事量をこなすまでの時間がかからなくなるすると何が起きるのか

Slide 64

Slide 64 text

生成AIによる開発サイクルへの影響 .PO 5VF 8FE 5IV 'SJ ίϛϡχέʔγϣϯ ։ൃ サイクルを変えないままだと、同期間に対応するPBIが増える相対的に扱う情報量は増え、コミュニケーションコストも増大する  （プロダクトバックログづくり、仕様の確認、レビュー、受け入れ・・・）バッチサイズが大きくなってしまいフィードバックループの効果が半減する

Slide 65

Slide 65 text

生成AIによる開発サイクルへの影響 .PO 5VF 8FE 5IV 'SJ ίϛϡχέʔγϣϯ ։ൃ だから開発サイクルを短くする 1週間スプリントから1日スプリントへ

Slide 66

Slide 66 text

滑らかに変化をできるようにする

Slide 67

Slide 67 text

フラクタル構造スプリント期間はフラクタル構造をとってもよいプロダクトとチームの全体性を2つの期間から検査・適応するダブルループ 1日スプリント 1日スプリント 1日スプリント 1日スプリント 1日スプリント 1週間スプリント

Slide 68

Slide 68 text

やがてカンバンへ突き詰まっていくとスプリントというタイムボックス自体が  不要になる可能性もあるカンバンでフローを制御する

Slide 69

Slide 69 text

カンバンガイドカンバンとは、あるシステムを通じて価値の流れ（フロー）を最適化するための戦略である以下の3つのプラクティスが連携して機能するワークフローを定義し可視化するワークフローの項目を主体的に監視するフローを改善する https://kanbanguides.org/ja/

Slide 70

Slide 70 text

人間がボトルネックになる！？扱わなければいけない情報量が増える同期間に対応するPBIの量コミュニケーション（プロダクトバックログづくり、仕様確認、レビュー・・・）それらをマネジメントするケイパビリティがなければ、  開発の効率があがっても開発サイクル全体の効率はあがらないプロダクトマネジメントプロジェクトマネジメントピープルマネジメント

Slide 71

Slide 71 text

マネジメント個人チーム・組織会社ポートフォリオマネジメント財務コーポレートガバナンス・・・プロジェクトマネジメントプロダクトマネジメントピープルマネジメント・・・ナレッジマネジメント学習マネジメント・・・

Slide 72

Slide 72 text

マネジメントにおける重要な要素成果を上げるために意思決定を行う／ピーター・F・ドラッカー意思決定の5つのステップ 1. 問題を知る 2. 必要条件を明確にする 3. 何が正しいかを知る 4. 行動に変える 5. フィードバックを行う情報を持っているか情報にアクセスできるか情報を選択できるか

Slide 73

Slide 73 text

生成AIとのやりとりも意思決定の繰り返し・・・どの問題を解くのかどんなプロンプトを入力するかどんなフィードバックをするかレスポンスを受け入れるかどこまで繰り返すか結果を検証し問題ないと判断するレスポンスは適切か否か欲しい情報は充足したか受け入れたうえで次に何をするのか結果を受け入れるか

Slide 74

Slide 74 text

どうやってケイパビリティをつくるか AIの性能を引き出すことができる開発サイクル開発サイクルをまわすために必要なチームのかたち機能するチームになるために必要な学習の仕組み

Slide 75

Slide 75 text

複数の小さなチームとロールの再定義 Photo by Omotayo Kofoworola on Unsplash

Slide 76

Slide 76 text

スクラムにおけるチーム小規模で自己組織化されたクロスファンクショナルチームチームメンバーがお互いに補完するさまざまな知識やスキルを持っているさまざまな変化に対応し、チームで多様な問題を解決できるようにする

Slide 77

Slide 77 text

人間＋生成AIのチームへ人間のみのチーム人間+生成AIのチーム生成AI 生成AIは多様なドメイン知識、プログラミングスキル、設計スキルをもっている知識の総量は人間よりもはるかに大きい（今後ますます大きくなっていく）もちろん人間にしかできない領域も存在する

Slide 78

Slide 78 text

より小さなチーム、より多くのチームへ 6人 X 2チーム（1ʙ3人＋生成AI） X 5チーム AI AI AI AI AI 人間＋生成AIのチームであれば、少ない人数でも経験やスキルを補完できるようになる 10人以下（スクラムガイド2020）がよいとされていたチームサイズがより小さくなる小さなチームが増えるので、これまでよりも多くのチームでコラボレーションをしながら  開発を進めるシーンが増える

Slide 79

Slide 79 text

ロールの再定義開発者はAIによってより全体性をもって仕事に取り組み、  意思決定に関わる機会が増える Outputの量とスピードが上がることでプロダクトオーナーがボトルネックになりやすくなるので、開発者もプロダクトの意思決定に直接関わり、一部を代替する考える人とつくる人の距離が近づき、やがて同一化なる開発者からアーキテクトへ

Slide 80

Slide 80 text

ロールの再定義小さなチームになることでチーム内のコミュニケーションコストは減るが、チーム横断のコミュニケーションコストは増えるスクラムマスターは大きなチームの支援にスクラムマスターはチームと個人が自己組織化を支援するスクラムマスターからチームコーチへ

Slide 81

Slide 81 text

大きなチームと小さなチームチームコーチチームサポート小さなチーム小さなチーム小さなチーム小さなチーム大きなチーム

Slide 82

Slide 82 text

学習する組織化

Slide 83

Slide 83 text

学習の重要度が増す複雑で変化が激しい状況では学習の重要度も増す AIの使い方新しい開発プロセス新たなロール個人学習に依存することはできなくなるため、  学習する組織になるための仕組みを積極的に導入する

Slide 84

Slide 84 text

全体としての意思決定の総数を増やす小さなチームがそれぞれ自己組織的に運営することを目指す全体としての意思決定の機会が増え、  意思決定の打席に立つ人と回数が組織全体に増える経験を積み、経験から学習をする

Slide 85

Slide 85 text

ペアワーク／モブワーク小さなチームではペアワークを推奨するドライバー⇒AI、ナビゲーター⇒人間×2 AIによってOutputの量とスピードが増えるため、  属人化を防ぐ意味でも常に4つの目を使う必要があるチームを超えた知識移転や学習の機会として、  モブワークを活用する

Slide 86

Slide 86 text

Team Open Space Technology チームというコンテキストがそろった状態でのOST 個人、相互作用、プロセス、ツール、完成の定義に関して  検査と適応を行うことを目的とする神回が常に起こることを目指し、知的コンバットの練習を  繰り返す

Slide 87

Slide 87 text

AI時代だからこそ本当につくりたいスクラムチーム柔軟で滑らかな開発サイクル複数の小さなチームとロールの再定義学習する組織化

Slide 88

Slide 88 text

AIによって生まれた新しい課題ではない OutputをOutcomeにつなぐ考える人とつくる人をどうやって近づけるか人とチームをどう育てるか課題に向き合わなければいけない必要性が増した AIによって課題に向き合う必要性が増した

Slide 89

Slide 89 text

スクラムの全体性スクラムフレームワークは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてを備えたものがスクラムであり、その他の技法・方法論・プラクティスの入れ物として機能するものである。スクラムガイド2020

Slide 90

Slide 90 text

変化に向き合う覚悟を持つ結果としてスクラムではなくなるかもしれないがそれでいいロールも開発サイクルもチームのかたちも変数にする複雑な問題を単純化するのではなく、複雑なまま取り扱う確実に失敗しない挑戦はない

Slide 91

Slide 91 text

今取り組んでいることを事例としてお話します（予定） https://confengine.com/conferences/regional-scrum-gathering-tokyo-2026/proposal/24521/ai

Slide 92

Slide 92 text

どちらが真実なのか AIはゲームチェンジャーエンジニアの仕事はなくなるアジャイルは死んだ開発生産性は劇的に変わる AIはそれほど使えないエンジニアの仕事は残るアジャイルは死なない開発生産性は変わらない

Slide 93

Slide 93 text

A. どっちでもいい

Slide 94

Slide 94 text

まさにやっかいな問題（Wicked Problem） 1. 解決策が真偽でなく善悪である 2. 解決策の試行錯誤ができない 3. 解決策が問題の味方に縛られる 4. 問題だとイイ切れない 5. 解決に終わりがない 6. 問題が唯一無二 7. 多様な問題が絡み合う 8. 明確な問題定義ができない 9. 終わりを決めるルールがない 10.即効性のある解決策がない

Slide 95

Slide 95 text

安易な二元論にとらわれない AIという大きな変化に「うっ」ときていることを認知する不確実な状況下でどちらの未来が来るのか予測する必要はない決定を遅延し、選択肢を広く持ち続けるどちらの未来が来ても成功できる能力を身につける思考と試行を繰り返し、経験からよりよいやり方を模索する

Slide 96

Slide 96 text

私たちは変化への立ち向かい方を知っているアジャイルソフトウェア開発宣言スクラムガイド2020

Slide 97

Slide 97 text

アジャイル開発誕生の背景アジャイル開発（アジャイルソフトウェア開発宣言）は、  当時世界各地で変化に挑戦し学びを体系化していた人たちが  集まり、その集合知を言語化したもの 2001年スノーバードアジャイル  開発知見知見知見

Slide 98

Slide 98 text

1970年代　ウォーターフォール・モデル誕生 2001年　　アジャイルソフトウェア開発宣言

Slide 99

Slide 99 text

1970年代　ウォーターフォール・モデル誕生 2001年　　アジャイルソフトウェア開発宣言 2030年　　？？？ 2025年私たちの現在の試行錯誤が、ソフトウェア開発の未来をつくる

Slide 100

Slide 100 text

未来へバトンをつなぐ今度は私たちがコミュニティに知見を持ち寄り、  AI時代の変化に適応するなにかを生み出すとき更新なのか新規なのかはどちらでもよいが日本発だと嬉しいコミュニティ？？？知見知見知見

Slide 101

Slide 101 text

AI時代に突入し、ここからさらに変化が早くなり、開発プロセスやチームにボトルネックが移っていきます。そんな時代だからこそ、アジャイル開発やスクラムを通して、変化に適応できるよいチームを増やしていくことの社会的意義が増していきます。そして、その取り組みの中で今のあたりまえを疑い、常によいやり方を模索し、コミュニティを通して皆さんと知見を共有しあっていくことで、未来のソフトウェア開発にバトンを送りたい。

Slide 102

Slide 102 text

@TAKAKING22 及部敬雄 https://agile-monster.com/ 一緒に取り組んでいきましょう！現役のアジャイル開発実践者によるアジャイルコーチお仕事のご相談も雑談もぜひお気軽にお声がけ下さい！