この記事は「コドモンAdvent Calendar 2025」15日目の記事です🎄
—
こんにちは、プロダクト開発部 請求関連チームでエンジニアリングマネージャーをしています、さかうえです。
コドモンにジョインしてから早くも2年が経とうとしています。エクストリームプログラミング（XP）をベースにしたアジャイル開発にもだいぶ慣れてきました。
毎日のペアプログラミングやチームイベントの中で議論が交わされるのは当たり前という環境で、「みんなでプロダクトやサービスをつくっている」という実感を味わいながら、プロダクトの価値を高めるべく日々奮闘しています。
しかし、そんな充実した時間の中で、「過去の記憶」がフラッシュバックすることがありました。
「アジャイルとしてどうあるべき？」という議論をしていると、昔、言われた「それはアジャイルじゃない」という言葉が脳裏をよぎり、何も考えられなくなってしまうのです。
当時は「アジャイルの正解」に縛られるあまり、本当の意味での対話を通じて自分たちの答えを出すことを放棄してしまっていたのかもしれません…。
今はそんなことも無くなり、かつての悩みに対する自分なりの答えを出すことができたので、ここで供養させていただきたいと思います。
「つらい」アジャイルにさせていたものは何か
少し、コドモン入社前の話をします。
当時の案件では、XPではなくスクラム開発を採用していました。
背景を簡単にまとめると、スクラムマスター（以下、SM）を除く開発メンバーはアジャイル初心者で、しかも役職者であるSMの発言は「とにかく絶対！」という雰囲気がありました（私だけだったかも）。
例えば、チームでやりづらさについて話し合っていても「"守破離"なんだから、まずはアジャイルのルール通りに」と言われ、つらさを抱えながら運用を続けることもありました。
そんな状況だったので、「このままこじれるくらいなら従おう」と受け身の思考に逃げがちになってしまい、SMが言う「アジャイル」の目的や "Why" を問うことを放棄してしまっていた気がします。
さらに、レトロスペクティブ（ふり返り）なんかは、毎回SMが提案する新しいフレームワークをこなすだけの時間になってしまい、一通り終わった後の「最後に何かある？」から、やっと本当にチームの課題が出てきて議論が始まるということも多々ありました。
SMが忙しく、開発メンバーと話すのはデイリーなどのイベントのときくらいだったことも理由にあるかも知れません。でも、ファシリが言う通りに議論して一旦終わらせよう、という気持ちで参加していたのも事実です。
今思えば、お互いの「信頼の欠如」と「他者の正解を探すコミュニケーション」が、思考停止させる状況を生んでいたのではないかと思います。
アジャイルとの向き合い方への気付き
コドモンでは自律的・主体的なアジャイルチームを目指しています。
私も最初は手探りでしたが、本を読んだり、チームでインセプションデッキをやったり、毎週のレトロを重ねる中で、入社して半年経つころには「コドモンでのアジャイル開発」の輪郭を少し掴み始めてきました。
その後、「アジャイルなチームを目指すチーム情報交換会」という社内勉強会に参加するようになり、ちょうどワークショップが開催されたころにはチームを超えて意見交換するようになっていました。
そんな中で得た「アジャイル開発」の一つの答えが、「『私たちはいまアジャイルか？』を追求し続けること」でした。その判断基準もみんなで議論して決めたものです。太鼓判は押してもらいましたが、正解を当てに行ったわけではありません。
「自分たちにとってのアジャイル」を定義していいんだ、という衝撃を受けたことを覚えています。
このあたりで視界が開けました。（成仏への道も開けました）
コドモンでアジャイル開発に向き合う中で変わったこと
1. 「許可」の前に行動してから「謝罪」を選ぶ
- 過去：何をやるにも「上の人」の許可が必要で、都度「これで合ってますか？」を聞く必要がある
現在：「許可より謝罪（Ask for forgiveness, not permission）」という言葉に出会った
- これに関連する言葉をいろんな人からことあるごとに言われて最近やっと腑に落ちてきました。「大体合ってるから脊髄で喋ってみなよ」、「許可を求めたら相手の責任になるし、そもそも自分の軸で考えてないのが良くない」など。
- それまで過去をさかのぼったり「正解」を探すのに時間を使っていましたが、最近は足りない情報を埋めるために誰かに聞きに行くことはあるものの、自分がこれでOKと判断したら突っ込んでみるようにしています。
たまに見切り発車していることもありますが怪我はしていません。
※ XPの原則の一つ「ベイビーステップ」も、後押しをしている気がします。チームで「1イテレーション試してみる」を選択できるようになったことは、失敗は「怖いもの」ではなく「データを得る機会」に変わったことの裏付けではないかと考えています。
2. レトロスペクティブは「自分たちがカイゼンする場」
- 過去：与えられるフレームワークを「こなす」時間になっていて、課題が後から出てくる
現在：ゲストファシリテーターと共に「議題は自分たちで決める」スタイル
- フレームワークはファシリテーター（しかも他チームのメンバー）が選ぶのですが、きちんとチームが課題を見出して議論できる仕組みになっています。具体的な流れは下記のとおりです。
① フレームワークに従って今イテレーションの気になりポイントを付箋に書く
② 全ての付箋をグルーピングし、トピックに名前を付ける（KJ法）
③ メンバーがトピックに投票し、その日話す議題をチームで決めて議論する
④ アクションプランを決める - チーム一人ひとりが「自分たちが働きやすくなるための作戦会議」としてレトロに参加しており、ファシリテーターは議論を円滑に進めるための補助、という立ち位置になっていることを、メンバーとして参加しても、ファシリとして参加しても、強く感じています。
- フレームワークはファシリテーター（しかも他チームのメンバー）が選ぶのですが、きちんとチームが課題を見出して議論できる仕組みになっています。具体的な流れは下記のとおりです。
3. お互いの凸凹をリスペクトし、最大限に活かす
- 過去：すごい人たちのすごいところを基準に考えて、エンジニアとしての自信を持てなかった
現在：自分の弱みは誰かの強み、自分の強みは誰かの弱み。自分も「一人」のエンジニア
- 「技術的な質問」は特に自分の無知をさらすようでこわい側面があると思います。それが、ここにはお互いの強みを活かすカルチャーがある！と思いながらペアプロをやっていると、自分が質問することもあれば、相手の迷いを自分の一言が解決することもあり、お互い様なんだと実感します。
- 当初は「自分はチームの役に立っているだろうか」と不安になることも多かったですが、360度フィードバックやレトロなどで感謝の言葉をいただいたり、逆にのびしろポイントを教えてもらうことで自分もチームを支える一員だと自信を持てるようになりました。
そして、もっと「なんでも言える」チームを目指して
こうした変化を経て、必要なのは「教科書通りの正しさ」ではなく、「ユーザーへの価値提供」と「チームの健全さ」を考え続けることだ と腹落ちして考えられるようになりました。
そして今、私たちのチームはさらに Step Forward しようとしています。
チーム人数が増え、少し発言しにくくなった空気を変えるためか、最近PdMやデザイナーが率先して「ふざけて」くれるようになりました。
毎朝の雑談スレで盛り上げてくれたり、あえて初歩的な質問を投げかけたり。一見遊んでいるようで、これが「心理的なハードル」を下げ、本質的な議論を引き出す高度な戦略なのではないかと感じています。（違ったら恥ずかしい）
いい雰囲気なので私も一緒に乗っかりたいのですが、たぶんうまくいってない気がします。私もノリたい。みんなが困らない範囲でフランクな雰囲気にしたい。。
でも、かつて「正しさ」でガチガチに萎縮していた頃に比べれば、チームの「こうありたい」を素直に考えられるようになっている今は間違いなく前に進んでいるはずです。
おわりに
以上！アジャイルの「あるべき」そのものは重要ではないことに気付き、チームが健全に機能していることを追求できるようになった現在の自分から過去の自分へのメッセージでした。
もし今、過去の私のように「アジャイルとは何か」で悩んでいる方がいたら、それは手法のせいではなくチーム自体の問題かも知れません。
お付き合いいただきありがとうございました！
引き続きメンバーと健全なチームを目指して議論を重ねながら、よりよいプロダクトを届けるために邁進していきます！
