back to top

エクストリームチーミング というのを提唱する

Cover Image for エクストリームチーミング というのを提唱する
Me
Me

自身に問うてください。
スクラムを使った開発で、「最速で開発できている」と実感できたことはありますか？

私は、ないです。

いきなり反発から始めちゃいましたが、スクラムの凄さは私が説明するまでもなく、世に認められたもので、現状でこれより良いものを探すのは難しいと思います。
ただ、私にはキャリアのスタートからずっと「なんでもっと開発本位に開発できないんだろう」という思いがありました。

自分が思ったことをまず形にして、それを動かしながらみんなで会話していけば絶対に今よりも高速に開発できるはずだと。

AIの進化によって、ようやくそれが誰しも現実的に捉えることのできる話になってきました。

以下の エクストリームチーミング という構想は、私が長年あたためていた考えをClaudeと対話しながらコンセプトとしてまとめたものです。

おそらくこれを実行できる組織はまずありません。
例外的に、創業したてのスタートアップは可能というか、人員の少なさからそうならざるを得ないということはあるかもしれません。

随分前に「他者と働く」の著者である宇多川先生の講演を聴講した際に、「ティール組織とは組織の進化ではなく、組織が退化する前の最初の状態で、組織が大きくなるにつれ徐々に組織はティールからレッドへ向かって退化していく」というようなことをおっしゃられていました。
それに近いと思います。

最初のティールの状態からいかに退化させないか、あるいは退化した組織がもう一度進化してティールに近づくためにはどうしたら良いのか、そんな問いかけが背骨にあって出来上がったコンセプトになります。

エクストリームチーミング：職能を超えた協働による価値探求

人間らしい協働への回帰

私たちは本来、「困っている人を助ける」「お互いの得意を活かして支え合う」という行動を自然に行う生き物だった。
狩猟や共同生活の時代には、誰かが獲物を仕留め、誰かが火を起こし、誰かが子を守った。そこには、役割の違いはあっても分断はなかった。

しかし文明が進み、生産性を高めるために分業が発達すると、私たちは「職能」という枠で自分たちを区切るようになった。
それは確かに効率を生み、技術を発展させた一方で、共感と相互理解に基づいた協働の感覚を少しずつ失っていった。

エクストリームチーミングは、この流れに対する静かな反抗である。
それは、職能によって人間を分けるのではなく、その人間の得意な振る舞いをチームのために行使するという、より自然な働き方への回帰だ。

つまり、

  • 「専門性を越えて協働する」ことは非効率ではなく、
  • 「人間として自然な状態に戻る」ことこそが、
  • 持続的なチームと価値創造を生み出す根源的な力になる。

この思想を、現代のプロダクト開発に落とし込んだ実践が エクストリームチーミング である。

背景

私は、バックエンドエンジニアとしてのキャリアの中で、複数のプロジェクト・チームに参画。それぞれのプロダクト開発において、共通するプロセスの問題を観察してきた。

観察された問題

1. 人間の稼働率優先による並列化の弊害

多くのプロジェクトで見られた共通の問題は、人間の稼働を優先するあまり、タスクが並列で動いてしまい、結果的に一人しかいないところ（POやQAへのコンタクト）でボトルネックが生じるということだった。

また、ボトルネックが生じる原因として、 重要な判断をするための意見を持ったSales/CSがチームの外にいるためコミュニケーションに時間を要する ことと、お互いの会議などで コミュニケーションのタイミングが合わないことによる無駄な遅延 がよく発生していた。

具体的には：

  • エンジニアを遊ばせないために次々とタスクをアサインする
  • これはチーム全体の暗黙の了解として存在していた
  • 特定の誰かが推進しているわけではなく、チーム全体の雰囲気として形成されていた

2. 認識されているが解決されない問題

  • POやQAがボトルネックになっていることは、チームメンバーやマネジメント層も認識していた
  • しかし、それをクイックに改善する動きを取れる現場はなかった
  • 手が空いているメンバーは、また別のタスクを取りに行っていた

3. 「手を止めることへの罪悪感」という文化的背景

この「言い出しにくい雰囲気」の根底には、自分が手を止めることへの罪悪感が大きく存在していた。

  • 日本では「働く時間に手が動いていない＝サボる」という意識が根強い
  • この意識がボトルネックの指摘や改善提案を妨げていたと思われる

4. 改善提案に対する現状維持バイアス

「タスクは必ずシリアルに流した方がいい」という主張を行ったこともあったが：

  • 強い反論はないものの、「今の状況を変えなくてもいい」という空気が支配的だった
  • 業務委託という立場では強く出ることが難しかった
  • 周りのメンバーも同様の「言い出しにくい意識」に囚われていた
  • PO/PM自身も並列化を促すやり方を推奨していた

5. ボトルネック側の対応

ボトルネックになっているPOやQA側も：

  • 自分たちの生産性を上げることで対応しようとしていた
  • 人員を増やすという方向で解決を図っていた
  • タスクの流れ方そのものを変えるという発想には至っていなかった

6. 職能間の分断による問題

従来の職能ごとに分かれた働き方では：

  • 「仕様検討している段階で『このデザインだと作れなくないですか？』」という後工程での手戻りが頻繁に発生
  • POとデザイナー・営業・他ステークホルダーとの調整に大きな時間を消費
  • 情報の非対称性により、各工程で「次に何が起きるか」を予測できない
  • 会議を重ねないと次の工程の人が何をすべきか分からない

7. 本質的な問題：価値探求からの逃避

これらの問題の根底にあるのは：

個人の稼働率重視は、顧客にとっての価値を探求するという本質的な活動から目を背ける理由を作ってしまっている

その結果：

  • 「作るための開発」になってしまっている
  • 成果の検証ができていない
  • アウトプットは重視されるが、アウトカムが見えていない

解決策：エクストリームチーミング

コンセプト

エクストリームチーミングは、エクストリームプログラミング（XP）のプラクティスを、開発だけでなくチーム全体のワークフロー、さらには営業・CSを含めた顧客接点からリリース後の検証まで拡張したアプローチである。

基本原則

1. タスクのシリアル化

  • バックログから必ず優先度の高いものを一つずつ流す
  • 基本的にペアプロやモブプロで全員が稼働している状態を保つ
  • WIP（Work In Progress）を強く制限する

2. 職能を超えた全員参加

すべてのタスクを職能を超えて全員で対応する

具体的には：

  • 仕様決め〜QAまで、基本全員がいるところで作業する
  • 理想的には、ずっとZoomを繋ぐような形で、同じタスクに全員で意見を出し合って進める
  • 各工程で職能に応じてリードが変わる
    • 要件定義の段階：POが主導し、他メンバーからフィードバックを受ける
    • 開発段階：エンジニアが主導
    • QAフェーズ：QA担当が主導しテスト項目を決めていくが、テスト自体は職能に関係なく全員でやっていく

また、POだけでなくSalesやCSも初期段階から参加する。

  • Salesは顧客との商談・契約プロセスで得た一次情報を提供し、顧客の課題のリアルを共有する
  • CSは利用後の課題やリテンション率に関する知見を提供し、「継続的な価値提供」の観点をチームに持ち込む
    これにより、プロダクトが「顧客価値を最大化する判断」を現場感をもって下せるようになる。

3. 企画〜リリース後まで全員で取り組む

  • 自分が今まで与えられていた職能だけをこなすことを是としない
  • 企画〜リリース後のヒアリングまでも全員で取り組む
  • 次の機能を作る上で、必ず得た学びがフィードバックされる

実践プロセス

全体フロー

  1. やりたいことを言語化する

    • 全員で要件を議論
    • この段階から全職能が参加
    • POだけでなくSales・CSも参加し、顧客の声や市場の反応を共有する
      • 「売れる理由」「売れない理由」
      • 「継続率が高い顧客の特徴」
      • 「導入後によく出る質問」
        などの生の情報をもとに、仮説を立てていく

  2. すごい雑に一回作る（プロトタイピング）

    • AIをドライバー、他メンバー全員をナビゲータとしたモブプロで行う
    • デザイナーは横で意見は出すが、デザインカンプは作らない
    • テストは書かない
    • プロダクトによっては全部がモック（BEは考えない）でもいい
    • 全員が意見できる状態で作る
    • 「プロトタイプで検証した」ことを仕様決定のゲートウェイとして強制する

    このステップの意義：

    • 一旦作ることで構造が明らかになり デザインにかけるコストを大幅に削減できる
    • ナレッジが全員に共有される
    • 作るコストは小さいため、捨てることへの心理的抵抗が少ない
    • 開発ではなく全員の作業として責任を持たせる

  3. みんなで動かしながら意見を出す

    • プロトタイプを実際に触りながら議論
    • 技術的制約や実現可能性も、この段階で明らかになる

  4. 最終的な成果物のためのデザインと仕様を決定する

    • プロトタイプでの検証を踏まえて仕様を確定
    • この時点で手戻りのリスクは大幅に減少している

  5. 開発する

    • QAリーダーは横で見ながらQAの準備を行う
    • 全員が「この先に何が起きるか」を予測して進めることができる
    • プログラマは開発に着手する段階で、何を開発すべきか会議をしなくても知っている
    • AIをフル活用し最速で実装する

  6. QAする

    • 開発メンバーはここでQA項目をユニットテストとして実装していく
    • QA専任者がリードするが、全員が参加
    • 手数がある分、早く終わる

  7. デプロイ

    • 一つずつリリースする
    • 2週に一度のリスクを抱えたビッグバンリリースではなく、日次の細かなデプロイを行う
    • チームの練度が上がるとこのサイクルスピードはどんどん早くなっていく

  8. メトリクスの検討（適宜）

    • リリース後のヒアリングや効果測定も全員で行う
    • 素早く現場に適応することを優先

職能ごとの貢献の仕方

各メンバーは、あくまで元々の職能を持つ人がリードしつつ、自分の強みを活かして全体に貢献する。

例：QAフェーズでの開発者の貢献

QAをそのままやるのではなく、QAを開発と捉えて：

  • QAを改善するようなツールを作る
  • ドキュメントを取りまとめる
  • テストそのものを自動化する
  • これらをリリースごとに少しずつ積み上げていく

例：Sales/CSフェーズでの他職能の貢献

  • Salesは顧客との商談・提案活動から得た情報をチームに共有する
  • CSは利用状況や課題をモニタリングし、改善点を全員にフィードバックする
  • エンジニアやデザイナーは、それをもとに改善アイデアを出し、素早く試す
  • QAは顧客からのフィードバックを再現性のあるテストケースに落とし込む

この連携により、「開発と現場が分断されている」という構造的な問題が解消され、プロダクトが顧客と共に進化していく。

AIの活用

昨今のAIの浸透により、プログラマが開発に要する時間は劇的に短くなった。

これにより：

  • 「十分な検討を終えてから開発する」のではなく
  • 「一旦雑に開発して動くものを作ってから、まるっきり作り変えるぐらいで仕様検討を完成させる」方が早い
  • プロトタイピング段階でAIをドライバーとして活用し、全員がナビゲートする形が可能になった

期待される効果

1. 情報の非対称性の解消

  • 全員が全ての工程に関わることで、「この先に何が起きるか」を予測して進めることができる
  • プログラマは開発に着手する段階で何を開発すべきか、会議をしなくても知っている

2. 手戻りの削減

  • 開発に入る前に様々な議論がなされるため、後になっての手戻りが起きにくい
  • 手戻りが発生した際も、どのような議論で決まったかを共有しているため修正が早く終わる

3. スピードの向上

  • QAでも手数がある分早く終わる
  • プロトタイピングにより、仕様検討の段階での手戻りが減る
  • リリース頻度を上げることで、トータルのスループットとフィードバックサイクルが速くなる

4. 学習速度の向上

  • チーム全体で知識を共有しながら進めるので学習のスピードが速い
  • 次の機能を作る上で、必ず得た学びがフィードバックされる

5. 仕事の充実感

  • 自分たちが作ってデプロイし続けているという実感
  • リリースしたものとその先が繋がっている実感
  • 構想したものが実現される（されない）ことをに全員がボールを持っている

6. 相互理解と共感

最終的に実現したい理想のチームの状態：

全員が全員の辛さや素晴らしいところを分かり合い、顧客と同じ方向を向いている。

特にSalesやCSの現場感と、開発チームの技術的知見が融合することで、真の意味での「顧客価値に向き合うチーム」が実現する。

実践に向けた課題

1. 文化的な抵抗

  • 「手を止めることへの罪悪感」という根深い意識
  • 「今のやり方を変えなくてもいい」という現状維持バイアス

2. 職能へのこだわり

  • 多くの人は、今まで自分がやってきたことだけをやりたいと思っている
  • 特に、QAを進んでやりたい人は少ない
  • 各メンバーが自分の専門外の領域にも関与することへの心理的ハードル

3. 実践のアプローチ

段階的な導入：

  1. 現状のヒアリング

    • 全員が何を問題として感じているのか
    • 最初に手をつけるべきはどこかを観察

  2. 問題意識の共有

    • 本当に全く問題を感じていないのであれば変えなくてもいい
    • 効率性よりも仕事の充実感、サービスの品質を上げるという側面から必要性を訴える

  3. 小さく試す

    • 過去に「たまたま条件が揃った」ときにうまくいった経験がある
    • それを再現可能な仕組みとして定着させる

まとめ

エクストリームチーミングは、単なる効率化手法ではない。
それは、人間が本来持っていた「支え合い」「共に作る」感覚を、現代のチーム開発に取り戻すための実践である。

  • 個人の稼働率重視から、顧客価値の探求への転換
  • 「作るための開発」から、「学習と検証のサイクル」への転換
  • 職能の壁を超えた相互理解と共感に基づくチームづくり

AIの進化により、技術的な実装コストが劇的に下がった今、私たちは「何を作るか」「どう検証するか」により多くの時間を使えるようになった。
エクストリームチーミングは、この変化を活かし、チーム全員が顧客価値の探求に集中できる働き方を提案する。

お読みいただきありがとうございました。

どんだけ偉そうに語るんだよって感じですが、これやりきれれば最強の開発プロセスだと思うんだよな〜。

これを実行可能にするには、各職能がそれぞれのミーティングとかに縛られまくるようでは絶対にダメです。
つまりこれは

  • 組織に理解があること
  • これをやり切る胆力をもったメンバーが主導すること

を前提としています。

こんなハードコアなコンセプトを受け入れられる会社なんてあるのか、という笑

けど僕自身はいつかどこかでこれを実践できることを夢見ています。
読んでいただいて、ぜひフィードバックがあればいただけると嬉しいです。

yamashitashinichirou at gmail.com

(冒頭の写真は息子氏曰く「スライムのキャンプ」だそうです。かわいいね)

追記:

組織の形態を変えずに、現実的な方法論としてアジャイルを適応させるためのフレームワークがスクラム。
だが、実際にはこれで適応できない組織がほとんどなので、「なんちゃってスクラム」になってしまう。
(Be AgileのはずがDo Agileになっているし、そもそもDoすらできていないチームが多い)

アジャイルになるためには組織を根本から変える必要がある、AIによってそのタイミングが訪れたんだということを言いたいのがエクストリームチーミング。

という立て付けの違い。

追々記:
ちょっとメモ的に。説明が足りていないかなと思うので補足。

AIを全体的に組み込むことで、これまで時間のかかっていった作業が大幅に短縮されるであろうという前提がある。
これまでは、それぞれの工程に時間がかかるので、職能によってプロセスをざっくり切っていた。
が、それはもう必要ないのでみんな同期でやることでコミュニケーションコストを無くしてしまおうというのがこのプロセスの重要なポイント。

もう少し具体的に言うと、何かが決まって作り始めたら、今まで3日かかってたものが3時間で終わるようになってきたから、その時間だけ部外者は離席して他のMTGに出るみたいな運用の方が効率いいよねっていう。

デザインとかに関してもその場でAIを使いながらモックでも動くものを見ながらみんなで議論した方が早いよねっていう感じ。
(一人の頭で考えるよりみんなで議論した方が観点が増えて良い。今ままでは議論の俎上に上げる具体例が出るまで時間がかかっていたけど、AIによって初動はほぼゼロコストになった)

エンジニアもコーディングそのものに頭を使うリソースがかなり少なくなったわけで、「どう動くか」「顧客にどういう価値が伝わるのか」を考えることにパワーを割いた方がいい。そのための協働。