こんにちは、プロダクト開発部の郡司です。

コドモン開発部による春のブログリレーが始まってます。

春のブログリレー、爽やかですね。花粉症も過ぎ去った。とても良いです。

ただ私は、そんな春の爽やかさも吹き飛ばすような、熱いハートで燃えたぎるようなブログを届けたいなと思い執筆しました。

振り返ると2025年12月に、アドカレでこんな記事を書きました。

「やりゃ良いだけのことがやれない私へ」

自分の弱さと向き合い、強制退路断絶と10分ハックで負けループを断ち切った話です。

そして2026年5月の今、状況が変わりつつあります。

やりゃ良いと思っていたのに、私は今、ふと気づいたら「やりたい」が勝っています。

本記事ではそんな私が今チームでやりたくてやってること、そしてこれからについて話せたらと思います。

AIはチケット間の繋がりを見ているか？

ブログリレー2日目の記事にて、こちらの記事が公開されました。

友野さんとは私も同じチームで、普段から友野さんを中心にAI活用方針をチーム内で議論しながら前に進めています。

記事内では、1 Issueの中でAIと人間が意思決定を積み重ねるワークフロー「giro」が紹介されています。そして今、私たちのチームではその先を見据えて、さらに複数チケットの関係性をAIが把握できる状態にしようと取り組んでいます。

チームではこれまで、Miro上のふせんでバックログチケットを作成し、ポイント見積もりやカンバン運用を行っていました。実際に実装する段階になって初めてGitHub Issueを作成し、そのIssueをベースに設計・実装・PR作成を進めるというフローです。このフローで長らく問題なく回っていたのですが、チームにClaude Codeが定着してきた頃、ある違和感に気づきました。

Claude Codeが把握できているのは、現在取り組んでいるイテレーションの1チケットだけです。MiroにあるバックログはClaude Codeには見えない。バックログ全体の構造も、イテレーションの状況も、前後のチケット関係も、何も知らない状態です。AIにコーディングやレビューを任せる機会が増えた今、このMiroとIssueによる分断と、1Issueに閉じた範囲のコンテキスト把握は今後大きなボトルネックになるかもしれない。そう感じるようになりました。

複数チケットの関係性に着目

1つのチケットに取り組むときに、「なぜ今やるのか」「前後に何があるのか」「チケット間にどんな依存があるのか」そういった複数チケットをまたぐ関係性をコンテキストとして持たせることで、AIがより質の高い提案を出せる状態を目指しています。そのための第一歩として動いたのが、MiroとGitHub Issuesで二重管理していたバックログやカンバン、チケットをGitHub Issues + Projectsに一元化することでした。これによってClaude Codeは、現在取り組んでいるイテレーションの1チケットだけでなく、チケット同士の関係性やイテレーションの状況を把握できるようになります。

ここまでは土台を整えたに過ぎないですが、土台を作ることがゴールではありません。次に向き合うべきは、膨大なコンテキストをどうClaude Codeに渡し続けるか、そしてそのコンテキストをいかに維持した状態で開発を進めるかです。

次から次にやりたいことが出てきてワクワクしちゃいますね。

やってみたら、狙ってなかったものまで手に入った

MiroからGitHub Projectsへの移行にあたっては、移行用のskillsを作成したことでスムーズに移行できましたが、課題はあります。Miroの柔軟性は失われた部分がありますし、気軽にふせんを貼るようなコメントがしにくい、Projects上でどのIssueがどのリポジトリのIssueなのかパッと分かりにくい、デザイナー・PdMが別途持つタスクとの棲み分けをどうするかなど、改善しながら進めている最中です。

ただ、想定外の副産物がありました。

AIへのコンテキスト供給を狙っていたのに、先に人間側のフローが整ってきています。

実装フェーズに入るたびに発生していたMiroからIssueへのコピペ作業がなくなりました
バックログ総ポイント・イテレーションのDone集計が自動になりました（毎週手計算していた）
イテレーションごとのバーンダウンチャートの作成、出力が自動になりました

これらは全部、自分自身にスキルがあればやりたかったものです。工数が読めなくて、技術力に自信が持てなくて、課題に感じつつも後回しにし続けていたものです。

それが、やれちゃってます。

今、私がやれない理由は何？

AIが実装の大部分を担うようになってきた今、感じたことがあります。

これまで自分には難しいと思っていたことのかなりの部分はただの言い訳に過ぎず、やると決めていなかっただけでした。

今回の移行でも、Miroからの移行用skillsの作成やProjectsの運用方法の調査などにAIを駆使することで、やってみたらすんなり形にすることができました。さらに周辺課題においても、バーンダウン集計の自動化など、「なんとなくやれてない」状態が続いていただけで、壁だと思っていたものもどんどんぶっ壊して前に進められています。

レビューや運用の品質をどう担保するかなど、まだまだ課題は残っています。それでも、実装に踏み出すまでのコストは確実に下がりました。

技術的な壁は、思っているより低くなっています。あとはやってみるかどうかだけです。

変化していく壁

もう少し先のことも書いておきたいです。

AIが実装を担う割合が増えると、難しいタスクも簡単なタスクも完了までにかかる時間の差が縮まっていきます。ストーリーポイントは工数そのものを指すわけではないですが、これまでポイントの大小に影響していた実装コストという要素の比重が下がっていくと、何を見積もっているのかを改めて問い直す必要が出てくる可能性があると感じています。そうなったとき、ストーリーポイントの意味が変わってくるかもしれません。

さらに、タスク単位の完了時間の差が縮まっていくと、意思決定の粒度も変わってくると思っています。これまでタスクレベルで「依頼→承認」とやり取りしていたところが、より抽象度の高いエピックレベルの意思決定へと移っていく。そうなったとき、複数チケットをまたいだコンテキストの把握が、より重要な意味を持ってきます。

今やっているGitHub Projectsでのポイント自動集計やチケット管理の一元化は、きっとこれらの未来に向き合うときの土台になってくれると考えています。

そして、最近私自身も感じ始めているチームの次の壁は何か。それは、人間（組織）の意思決定の速さです。（新しく現れたというより、今まで実装コストの陰に隠れていたものがより浮き彫りになりやすくなってきただけかもしれない）

AIの力で実装速度が上がるほど、設計の合意、仕様の相談、リリース方針の部署をまたいだ調整やリリースリスクの検討といった人間同士のプロセスとのギャップが浮き彫りになってきます。これはどの組織、チームにも起きうることだと思っていて、実装自体のボトルネックが解消された先に待っている、次の共通課題だと思っています。

幸いなことに、コドモン開発部にはペアプロ文化を筆頭に、人と人とのコミュニケーションを重視する土壌が既にあります。「それなら最初から壁にならないんじゃ？」と思われるかもしれません。ただこれは、AIが実装を担うスピードに対して、コミュニケーションの量や質を保持した状態で意思決定のサイクルをどう追いつかせるか、という新しい問いです。その意味で、我々コドモンのカルチャーはむしろこの壁を越えるための武器になると思っています。

個人の壁、技術の壁、そして人間（組織）の壁。

きっと壁はなくなるのではなく、形を変えていくもの。今どこにボトルネックがあるかを常に問い続けることこそが、チームとして前に進み続けることであり、今の私の楽しみなのかもしれません。