カンバンによるプロジェクト管理で開発速度3倍になった話

はじめに

私は株式会社リブ・コンサルティングでSaaS事業をやっている事業部でエンジニアをしています。私たちのチームは10名以下でウォーターフォールでもなく、アジャイルでもない開発手法で開発をしていました。開発前に要件合意して進めていたので、どちらかというとウォーターフォールに近い手法で、途中（最終段階に近いところ）の変更も対応していました。その結果、なかなか開発がスタートできない、、、開発したものがビジネスサイドが考えていたものと違うと言われる、、、修正対応でさらに納期が伸びる、、、といった状況で、開発プロジェクトのQCD（品質、コスト、納期）が守るのが難しい状況でした。

そんなチームがプロジェクト管理方法をJiraを使ったカンバンに変更したところ、品質を維持しつつ開発速度が3倍になりました！！！開発速度が上がったのはプロジェクト管理方法を変更しただけでなく、チーム役割変更と権限移譲なども同時に行われたことにより実現できたと考えています。
ここではカンバンでのプロジェクト管理へ移行を私たちがどのように進めて改善したのか書きたいと思います。

やったこと

インプット

ある日、上司から「プロジェクト管理方法をカンバンにしようと思っているので、この書籍を読んで、チームで運用するためのルールを考えてみて」と言われました。おすすめされた書籍は「今すぐ実践！ カンバンによるアジャイルプロジェクトマネジメント」でした。カンバンでプロジェクト運用するベストプラクティスが書かれており、非常に参考になる内容でした。ただ、書籍の通りに導入しても、私たちのチームにはマッチしない（運用できない）と思い、あえてベストプラクティスではない方法で運用を検討しました。

運用方法のアレンジ

私たちのチームで取り入れなかった要素は以下です。

• カンバンを見ながらのデイリースタンドアップミーティング実施
  • 1つのカンバンで複数プロジェクトを管理したかったので、スタンドアップミーティングの時間だけでは確認が難しいと判断したためです。課題発見と解決は全体のプロジェクト管理を一人に情報集約（属人化）することと、他のミーティングで確認することでカバーしていました。
• WIP制限
  • これも上記と同じ理由で、複数プロジェクトを1つのカンバンで管理しているため、各メンバーが色々なプロジェクトにアサインされているため、課題発見するのが難しい（機能しない）と判断したためです。

チームへの浸透

チームでは週次で輪読会を実施しています。そこで、私がインプットした書籍を題材に輪読会を重要な章のみ（1〜3章）実施しました。これによりキーワード、前提知識がインプットされたので、アレンジした運用ルールの理解もスムーズに進められたと思います。

カンバンによるプロジェクト管理をしてよかったこと

スケジュールのわかりやすさ

1タスクを1週間で完了するボリュームになるよう作成しました。そうすることで、タスク数/開発者数で何週間後に実装完了するのかがわかります。完了の目処がわかることで実装完了後の準備（検証、社内外へのアナウンスなど）をすることができました。

早期に認識のズレと仕様変更に気づける

これはアジャイル開発のメリットですが、1週間ごとに動くものを確認できるので、開発者との認識のズレに気付くことができ、即座に修正することができました。確認している中で仕様の矛盾も発見でき、仕様を修正することができました。最終的に開発の品質が向上し、社内のビジネスサイドと顧客の満足度も上げることができたと感じています。

改善したこと

運用してみて不都合が出てきたところもあり、その点は改善しました。

エピックとタスクの管理方法を変更

エピック＞タスク＞サブタスクの粒度でチケットを管理していました。チケットのステータス（エピック＞タスク＞サブタスク）は親エピックが完了（リリース）しない限り完了しないルールにしていました。複数プロジェクトを1枚のカンバンで管理するので、プロジェクトが完了しない限り大量の完了タスクやサブタスクがカンバンに残り続けました。カンバンはカオス状態になり、フィルタ機能などを使って見えやすくしないと管理できなくなりました。なのでチケット管理を変更しました。タスク、サブタスクのチケットに関してはローカルでの検証とPRレビューが完了したら、ステータスを完了するようにしました。これにより、チケットが完了して表示されなくなるので、カンバンがスッキリして見やすくなりました。

今後、改善したいこと

まだまだJiraの機能を使いこなせていないので、今ある仕組みをJiraに移行していければと考えています。今、考えているのが「リリース管理、インシデント管理」です。リリース管理はアナログ管理（元々はRedmineで管理）になっているので、「何を、いつ」リリースしたかを管理するのが大変になりました。未来のリリース対象が何で、過去にいつ何をリリースしたか把握できるようにしたいと考えています。また、チケットの閉じ忘れもなくしたいので、ここはJiraの自動化ツールで解消する予定です。インシデント管理は他で管理（Redmineで管理）していたものをJiraに移行できればと考えています。Jiraに移行することで、修正チケットとの関係性を表現することができるのが大きなメリットだと考えています。また、振り返りしやすいようにインシデントデータを蓄積する場所として考えています。データが取り出しやすいような、管理方法を検討できればと考えています。

最後に

最後まで読んでいただき、ありがとうございました。Jiraやカンバン運用の参考になれば幸いです。
スクラムなどたくさんの開発手法はありますが、何もやるにも教科書通りにやってもうまくいかないと改めて感じました。書籍に書かれている方法は確かにきれいで完璧で上手くいくように見えますが、書籍はあくまでも参考情報でしかなく、結局は上手くいかせるのも、失敗するのも実際に運用する人にかかっています。目的からしっかり考え、まずは小さな仕組みからスタートして改善して、自分たちで正解を出していくことが大事だと思いました。