[アジャイルジャパン2025]あなたのアジャイルがうまくいかない10の理由～"Reboot"のための処方箋～

あなたの アジャイルが うまくいかない 10の理由 〜“Reboot”のための処方箋〜 森實 繁樹 1

ただし、それはアジャイルを具体的に体 現する流派の一つ、「スクラム」の考え をどのような場合にも同じように適用す るべきと見なしているわけではない。局 面によって、スクラムの適用の仕方を変 えるところが現れてくる。 -市谷聡啓（『作る、試す、正す。』ISBN：978-4-8025-1329-6） 2

森實 繁樹 株式会社レッドジャーニー Swise株式会社 外部顧問 Pluslab株式会社 外部顧問 国立筑波大学 非常勤講師 （所属ユニット） 侍塊s プロジェクトマネージャ保護者会 ITかあちゃんず （所属（運営）コミュニティ） 日本XPユーザグループ BIT VALLEY –INSIDE保険xアジャイルコミュニティ 人材業界ビジネスアジャイルコミュニティ Agile Tour Yokohama 3

あなたのアジャイルが うまくいかない10の理由 4

本日の前提 SIerで15年以上、事業会社で4年以上の経験から、 マネジメントの基本は、 ①中日程 ②体制図 ③課題管理表 にあると考えます。 5

其の壱 プロジェクトマネジメントがスクラ ムのイベントに盛り込まれていない 計画駆動型のプロジェクト→プロジェクト憲章およびプロジェクト計画から始まる プロジェクト計画＝プロジェクトをうまくいかせるための戦略を描いたもの 世の中のだいたいのスクラム（アジャイル型）プロジェクト プロジェクト計画を飛ばして…スプリントイベント（セレモニー）を実行している そのデイリースタンドアップにプロジェクトをうまくいかせるための戦略は反映されていますか？ 6

本当はさらにステアリングコ ミッティや必要に応じたアプリ 横断連絡会、運用要件確認 会などなど足していくのかど こかに埋め込んでいくべき 7

其の弐 既存のガバナンスを満たすような アジャイルの設計になっていない 自社のソフトウェア開発標準やISMSなどに沿わせた開発方法およびガバナンス設計は、 計画駆動型プロジェクトにアラインするようにできている →これはこれで過去の失敗に学んだガードレールでありゲートの役割を果たしている →ここでやりたかったことは、必要なプロセスが踏まれ、堅牢なシステムを世に出すこと 一方、だいたいのスクラム（アジャイル型）プロジェクトは、プロセスよりも価値となりがち… 成すべきプロセスを組み込みながら既存ガバナンスを突破できる形を目指していますか？ 8

どんな開発であれ、やるべき ことは原則同じ。どうして PMBOKで標準的にあらわさ れているアクティビティに対す る実行をしないでよいのか 9

其の参 チームメンバー全員が、ロールという帽子 をかぶりわけるべきことがわかっていない スクラムマスターが開発者と兼務しているときなどは、 「スクラムマスターの帽子と開発者の帽子を被り分けましょう」 といったりします。 しかし、チームメンバー全員でプロジェクトを推進するのに、 ユーザーの体験を考えるのはUXデザイナーだけなのか、競合他社を分析するのはPOだけな のか… 開発者だろうがUXデザイナーはおろかユーザーの帽子を被ってみていますか？ 10

其の肆 権限・役割の委譲の単位は、 小さくていいことがわかっていない 権限・役割の委譲というと何を思い浮かべるでしょうか？ 一番身近なところで言うと、スクラムマスターが当初仕切っていたファシリテーション業をチーム メンバーに役割を委譲していくというのがあると思います。 「ファシリテーション業」という塊、大きくないですか？？ もっと小さく、「今日の司会」「今日のタイムキーパー」「今日の議事メモ係」… 小さく小さく権限・役割を委譲していくことで、受け取る側の心理的ハードルも下がります。 11

其の伍 ふりかえりはマイナスをゼロやプラ スにもっていくことだけではない ふりかえりをやると、どうしても問題（Problem）が多く出て、 TryもProblemからの小さなカイゼンを出さないといけない雰囲気がありませんか？ それならKeepを出す意味が何もなくなってしまいます。 Problemも小さな改善の種かもしれませんが、Keepというのは成功体験の言語化です。 言語化された成功体験は再現性を生み出し、更によい成功を生むエナジーなのです。 12

其の陸 チームで決めるということと責任者 を置かないことは同じではない 計画駆動型のプロジェクトの場合、リーダーやマネージャーといったいわゆる責任者をたてます。 これは、責任を持って遂行に当たるために、割り当てられた権限の裏返しでもあります。 では、責任を持って遂行に当たるために、スクラム（アジャイル型）プロジェクトには、チームに 権限があるといえるのでしょうか。 これは権限を分解する必要があり、例えばRACIで考えると、「実行責任者」、「説明責任 者」、「相談先」、「報告先」があります。 この場合、チームに与えられているのは実行責任であり、説明責任は誰かが担うのが組織 で活動するチームなのではないでしょうか？説明責任は一箇所で担うべきです。 13

其の漆 専門職にも越境するマインドが必要 であることがわかっていない 専門職とは、専門性を持ち且つ協調して働ける人であり、専門性しか持たない偏った人 ではありません。 例えば、みなさんの周りでもPOが忙しいというのをよく見たり聞いたりしませんか？ それはみなさんのせいかもしれません。 相談とは提案です。「どうしたらいいですか？」ではなく、「こうするのはどうでしょう？」です。 つまり、POの意思決定をしてもらう相談（提案）を行うには、自分の領域を超えて、POの 興味関心を知らないと相談（提案）は通りません。事実に基づく妄想力が必要なのです。 あなたはどれくらいPOの考えていることをわかろうと（越境）していますか？ 14

其の捌 プロダクトのマネジメントにラインの マネジメントを持ち込んではいけない プロダクトにおけるマネジメントは、小さなスクラムチームを想像する場合、POがプロダク トマネジメントの中心にいます。 しかし、例えば職能ごとに、エンジニアやデザイナーには自部署自組織があり、そこにおけるラ インの課長や部長といった役職も存在します。 プロダクトの観点で会話をするとき、ラインマネージャーの課長の意見は所詮1メンバーの発言 にすぎません。プロダクトのマネジメントの会話に職能の役職による上下を持ち込むのはナンセ ンスです。しかし、周りの人が相手の役職を慮って意思決定が歪むことは往々にしてあること です。 ラインのマネジメントをするとき、意図的にプロダクトから離れておこなっていますか？ 15

其の玖 POは本当に CEO​ （ミニCEO）なわけではない POはミニCEOであるとかよく言われます。 端的に言います。POはCEOでもミニCEOでもありません。 POは、ただの雇われ店長です。 プロダクトへの愛情をもつことは、自分のためであり、ユーザーのためであり、社会のためです。 しかし、雇われ店長に一番求められるのは、今月の稼ぎであり、安定した経営です。 みんな本当はわかっているので、そんな雇われ店長業の中でも、ちょっとだけでいいのでプロダ クトに愛情を持ってもらえることを祈っています。それがPOの最善でありビジネスです。 16

其の拾 生産性の高さとビジネスの成功は 比例しない アウトプット→アウトカム→インパクトという流れについてよく聞くと思います。 しかし、一般的な成果評価の期間で区切ると、アウトカムに至るところまでが計測できず、必 然的にアウトプットでの評価をせざるを得ません。つまり、結果指標ではなく、行動指標による 評価です。 結果指標を導くために行う行動指標を先行指標としてターゲットにするのは正しいです。し かし、行動指標を高めることが結果指標を押し上げることにつながるかは別の話です。 生産性を高めればビジネスの求める結果指標に近づくとは限りません。ビジネスの求める結 果指標をいかに早期に先行指標におけるかが、行動に変化をもたらしビジネスの成功の 確度をたかめるのです。 17

まとめ 18

まずは中日程を引きましょう あなたの アジャイルを Reboot するために… 守破離の守は自分たちが大事にすべ き本質から生まれます 教科書からは生まれません 右ができるようになったら、品質確保 計画やリリース計画などを落とし込む 破や離を目指しましょう ◦ 3ヶ月～半年先のロードマップを今すぐ描きましょう ◦ 中日程はいつどこで見直すのか ◦ プロダクトバックログリファインメントで見直しましょう 次に体制図を描きましょう ◦ 体制図はステークホルダーの関係図です ◦ 同じ高さには同じレイヤーの握るべき人がいます ◦ 線が繋がっているところ以外に必要な会議体が見えてきます ◦ 勝てる戦略を勝てる実行計画にするために箱（イベント）を調整しましょう ◦ スプリントの営みそのものを再設計しましょう 課題管理は開始期限で管理しましょう ◦ 開始期限を管理し、タスクの一つとして実行することで、想定外は減ります ◦ また、短期のリスクは事前に課題管理でサキヨミ対応しましょう ◦ スプリントプランニングで課題と短期リスクをタスク管理しましょう ◦ あわせて、長期のリスク管理も今まで通りしましょう ◦ リスクの判断は組織的に行うべきで、スプリントレビューでフィードバックをもらいましょう 19

おまけ 20

チームを良くしようと思ったら より個人をみないといけない チーム力を高めるということは、すなわち個々が十分に実力を発揮できる環境を整え、 その上でチームの総合力とするためのバランスをとる事が必要です。 チーム力を高めるためには、まず個人と向き合い、個人の特性や強みを認め、それ を最大限引き出せる、あるいは伸ばせるための策を講じていく必要があります。 チームから始まる成長はありません。 個人にいかに向き合うかです。 21

『ゼロからはじめる チームプロジェクトマネジメント』 2026/1/8 インプレスさんより発売します！ チームのみんなで一度読んでみてください！ 22