「開発改善カンバン」を導入

なぜ「開発改善カンバン」を導入したのか？

開発チームでは、現在(2025/09/01)下記のような課題があります。

1. 目の前の開発に忙殺される
   日々の機能開発に追われ、本当に重要なリファクタリングや開発環境の改善が、常に後回しになっていました。

2. 技術的負債が雪だるま式に増える
   目の前のタスクをこなすことに必死で、「いつかやるべき」と先送りされた技術的負債は、着実に膨れ上がっていきました。

3. チームが疲弊し、開発が停滞する
   開発速度は目に見えて低下し、些細な変更でもバグが頻発。チームのモチベーションが蝕まれていく。

この状況を改善すべく、今回プロダクトとチームが持続的に成長できる環境を築くために、導入したのが 「開発改善カンバン」 です。

「開発改善カンバン」とは何か？

一言で言えば、これはプロダクトの機能開発とは別に、開発の質を向上させるためのタスク（＝開発改善タスク）だけを管理する専用のカンバンです。

ビジネスサイドが常に進捗を把握する必要がある機能開発とは異なり、ここにはエンジニアの裁量で進められる改善タスクが集約されます。

対象となるタスク例

• リファクタリング: 複雑化したコードの可読性・保守性を向上させる。
• ライブラリ／フレームワークのアップグレード: セキュリティリスクの低減と、新機能の恩恵を受ける。ここにざっくり書いて壁打ちや方向性の確認をしたりするのにも使おうかなと思っています。
• テストの拡充や改善: コードの品質を担保し、デグレを防止する。
• CI/CD・開発環境の整備: デプロイ時間の短縮や、開発体験を向上させる。
• プロダクトとして「こうあるべき」という技術的な方向性の実現: アーキテクチャの改善や、将来を見据えた設計の見直し。

これらのタスクは、直接的な事業価値にすぐ結びつくわけではないため、優先度が低く見積もられがちです。しかし、これらを放置することが、将来の開発速度を致命的に低下させる「技術的負債」となるのです。

このカンバンは、そうした 「重要だが緊急ではない」タスクを可視化し、計画的に推進するためのものです。

運用フロー：アイデアの種から知見の資産化まで

私たちは、タスクのライフサイクルを以下の6つのレーンで管理しています。このフローの裏側にある「思想」こそが、この仕組みの核心です。

1. Backlog（候補 / 要議論）

すべての改善は、誰かの「こうすればもっと良くなるのに」という小さな気づきから始まります。このレーンは、そのアイデアの種を気軽に置くための場所です。

重要なのは、ここでのIssue作成のハードルを極限まで下げること。GitHubのDraft Issue機能を活用しています。

ポイント：Draft Issueで心理的ハードルを下げる

• 「こんなことを起票していいのだろうか？」という躊躇は不要。
• 課題感や背景がわかる程度のメモ書きでOK。
• これにより、どんな小さなアイデアも埋もれることなく、チームの目に触れる機会が生まれます。

2. Ready（着手準備OK）

Backlogで挙がったアイデアの中から、議論を経て「やろう」と合意されたタスクがここに移動します。

このタイミングで、Draft Issueは正式なIssueに昇格します。

ポイント：Issue昇格時にタスクの解像度を上げる

• 目的、完了条件、具体的な進め方を明文化します。
• これにより、担当者以外が見てもタスクの全容を理解でき、誰でも着手できる状態になります。
• このプロセス自体が、タスクに対するチーム全体の共通認識を形成する重要なステップです。

3. In Progress（作業中）

担当者がアサインされ、実際に開発が進んでいる状態です。

4. Review（レビュー / 確認中）

コードレビューや動作確認など、第三者による客観的なチェックを受ける段階です。

5. Done（完了）

全ての作業と確認が完了したタスクです。しかし、私たちのフローはここで終わりません。

6. Knowledge（知見化済み）※オプション

このレーンは、改善活動から得られた学びを形式知化し、チームの資産に変えるためのものです。

ポイント：学びを次に活かす文化を醸成する

• 完了したタスクの中から、特に学びが多かったものについてドキュメントを作成します。
• 「なぜこのライブラリを選んだのか」「このリファクタリングでどんな問題が解決されたのか」といった知見を共有することで、同じ課題に直面した他のメンバーを助け、チーム全体の技術レベルを引き上げます。

仕組みを動かす「場」作り。開発改善ミーティングの導入

カンバンフローを作ったとしても、それだけではただの「置物」になってしまう危険性があります。アイデアがBacklogに溜まる一方、誰も拾い上げない。そんな状況を防ぎ、カンバンを活用するために、「開発改善ミーティング」 という「場」を設けました。

これは、隔週30分、カンバンに挙がったアイデアやタスクについて、エンジニアが主体となって議論するための定例ミーティングです。

しかし、ただの定例ではありません。ここにも 「心理的ハードルを下げ、自律性を尊重する」 という思想で運用しようと思っています。

アジェンダは「話したい人」が決める

このミーティングには、厳格なアジェンダはありません。話したいことがある人がいれば開催し、いなければスキップします。その意思表示を促すために、Slackでこんなリマインダーを流しています。

/remind #team-dev "@engineer @...
🚨14時から開発改善MTGじゃい！🚨
もし12時までに誰もスタンプ押さなかったら、華麗にスキップします✌️
「俺が語るぜ！」って人は🙆‍♂️をポチってアピール頼む！" every other Wednesday at 2pm starting September 10

遊び心のあるリマインダーのポイントは、「参加の強制」ではなく 「発表の機会」 を提供している点です。「誰かがスタンプを押さなければ開催されない」というルールが、当事者意識を生み出します。

参加も時間も、あくまで柔軟に

ミーティングの運営方針も、エンジニアの負担にならないよう、徹底的にシンプルにしています。

• 発表する人がいなければスキップ
• 話が終われば時間前でも終了
• 超えそうな場合はその場で相談
• 決まったことは GitHub Projects の Issue に記録
• 参加は任意

重要なのは、議論をすること自体が目的化しないことです。壁打ち的に意見交換し、方向性が決まればすぐに解散。そして、議論の結果は必ずIssueにフィードバックし、次のアクションに繋げる。このサイクルが、カンバンを単なるToDoリストではなく、改善活動として機能させるのです。

このミーティングは、まさに「まずは試しに」の精神で始めました。プロセス自体も、チームで改善を続けています。

なぜ「削除」より「アーカイブ」を推奨するのか

私たちのカンバンにはもう一つ重要なルールがあります。それは 「タスクの削除は原則行わず、アーカイブを基本とする」 ことです。

• アーカイブ: 完了、あるいは見送られたタスク。ボード上からは消えるが、検索すればいつでも参照可能。
• 削除: 完全に履歴から消える。誤作成など、ノイズでしかない場合に限定して使用。

なぜなら、見送られた議論や失敗した試みさえも、未来のチームにとっては貴重な学びの記録だからです。
「過去に同じ議論がなかったか？」
「なぜこの方法は採用されなかったのか？」
こうした問いに答えられる履歴は、チームが同じ轍を踏むことを防ぎ、より賢明な意思決定を下すための羅針盤となります。

「開発改善カンバン」がチームにもたらす3つのゴール

この仕組みを運用することで、私たちは以下の3つのゴールを目指しています。

1. エンジニアが開発に集中できる環境をつくる
   ビジネスサイドとの調整が少ない改善タスクを切り分けることで、エンジニアは深い集中状態（ゾーン）に入りやすくなり、生産性が最大化されます。

2. 技術的負債を計画的に解消し、プロダクトの持続可能性を高める
   「いつかやる」をなくし、改善タスクを日常のフローに組み込むことで、プロダクトは健全な状態を維持し、変化に強いしなやかな構造を保ち続けることができます。

3. チーム全体のレベルアップと成長の機会を創出する
   日々の機能開発だけでは得られない、アーキテクチャの改善や新しい技術の導入といった挑戦的なタスクは、エンジニアにとって絶好の成長機会です。このカンバンは、その機会を意図的に創出し、チーム全体の技術力を底上げする機会となります。

文化を育むためのプラットフォーム

「開発改善カンバン」は、単なるツールやルールではありません。それは、「自分たちの働く環境は、自分たちで良くしていく」というオーナーシップを育み、継続的な改善を是とする文化を醸成するためのプラットフォームです。

カンバンという「仕組み」と、開発改善ミーティングという「場」。この両輪を回すことで、改善のサイクルは力強く回り始めます。

もしあなたのチームが、かつての私たちと同じように技術的負債や開発環境の課題に悩んでいるなら、ぜひこのカンバンの導入を検討してみてください。

完璧なルールで始める必要はありません。まずはBacklogレーンを作り、チームが感じている課題感をDraft Issueで書き出すところから始めてみてはいかがでしょうか。

README

# 開発改善カンバン

このプロジェクトは、プロダクト開発をより良く進めるための **開発改善タスク専用カンバン** です。  
リファクタリングや環境整備など、ビズサイドが逐一チェックしなくても良いタスクをここで管理します。  
ただし、プロダクトや利用者に影響を与える可能性があるアップグレードや変更については、必ずビズサイドに共有してください。

---

## 対象となるタスク例
- リファクタリング  
- ライブラリ／フレームワークのアップグレード  
- テストの拡充や改善  
- CI/CD・開発環境の整備  
- プロダクトとして「こうあるべき」という技術的な方向性の実現  

---

## 運用ルール
- ビズサイドに逐一共有しなくても良い開発改善タスクを登録  
    - ディスクリプションは他のエンジニアが見ても分かるように、できれば丁寧に記載していただけると🙏
  - あとから参加した人が状況を把握できるように、背景や目的も簡単に残しておくとベター  
- プロダクトやビジネスへ影響が及ぶ可能性がある場合は必ず共有  
- タスク完了後は、再発防止や継続改善のために知見を必要に応じてドキュメント化  

- **Issue 化のタイミング**  
  - Backlog（候補 / 要議論）に置く段階では **Draft Issue** として作成  
    - アイデアや議論の種を気軽に残せる  
    - 課題感・背景が分かる程度の記載でOK  
  - Ready（着手準備OK）に移すタイミングで **正式な Issue** に昇格  
    - 目的、完了条件、進め方がある程度整理されている状態  
    - これ以降は誰が見ても作業に入れるレベルで明文化する  


---

### 🗂 アーカイブ（原則はこちらを使う）
- 完了したタスク  
- 見送ったけど議論の記録を残しておきたいタスク  
- 将来参考になるかもしれないタスク  

**特徴**  
- ボードからは非表示になるが、履歴として残る  
- 検索すれば後から参照できる  
- 必要に応じて復元も可能  

### 🗑 削除（例外的に使う）
- 完全に誤作成したタスク  
- 重複して作られたタスク  
- 明らかにプロジェクトに関係ないタスク  

**特徴**  
- 完全に消える（履歴も残らない）  
- 後から参照・復元はできない  
- 誤作成やノイズを取り除くときだけ使う  

👉 基本は **アーカイブ** を使い、削除は「存在自体が不要」なケースに限ること。  
これにより、履歴や学びを後から参照できるようにします。  

---

## ゴール
- エンジニアが開発に集中できる環境をつくる  
- 技術的負債を計画的に解消し、継続的に改善できるプロダクトにする  
- 成長の機会として積極的に改善タスクに挑戦し、チーム全体のレベルアップにつなげる

余談

Github Projectを使ったことがなかったけど、勢いでGithub Projectにたたき台として作った。操作していると意外とない機能がありnotionに移行したほうが良いのか考え中。

複数選択からの一括処理でできることが少なく、一括アサインが使えないのがつらい。。。