公式資料
「デジタルオペレーションの現状」独自調査レポート
公式資料 エンジニアの燃え尽きを防ぐ秘訣とは？
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基にしたシステム運用の”今”を解説！→ PagerDutyの資料をみる（無料）
開発プロジェクトチームにおいて「進捗をチーム全員が理解・把握できない」「リアルタイムな情報共有ができない」などの問題は、業務の非効率化を招いてしまいます。また、業務が適切に分散されず過度な負担が一点集中するなどの問題も起こりかねません。そこで、私たちPagerDutyが取り入れたのが「カンバン方式」です。
カンバン方式は「ムリ、ムダ、ムラ」のない製造を実現するための手法として、製造業の現場で用いられていました。現在では、多くの業界で使用されています。迅速かつ柔軟な対応が求められるインシデント管理でも、カンバン方式は有用です。この記事では、PagerDutyの開発プロジェクトチームが、開発方式を「スクラム方式」から「カンバン方式」に変更した理由をご紹介します。
目次
そもそも「カンバン方式」とは何か？
カンバン方式とは、トヨタ自動車が考案した生産管理方式の一つです。カンバン方式の内容は「ジャストインタイム」と「リーン生産」という、生産計画・方式に基づいています。
ジャストインタイムとは「必要なものを、必要な時に、必要なだけ供給する」という生産計画です。対してリーン生産とは、大量生産方式よりもはるかに良い品質を実現させつつ作業時間や在庫量を削減する、プロセス管理の効率を高めた生産方式を指します。この2つの原則に基づいた、タスク・インシデント管理方法が「カンバン方式」です。付箋やカードを使ってタスクを可視化し、視覚的なワークフローを作成して管理します。
また、反復的なアプローチにより、継続的な改善も可能です。カンバン方式では、作業の流れや進行状況が明確になります。可視化したタスクを誰もが共有できるため適応力が高く、予期せぬ問題に対する迅速な対応も可能です。さらに、優先度や期限などの情報の変更も簡単で、柔軟な対応ができます。
スクラム方式も、視覚的なワークフローを使用するアジャイルなプロジェクト管理の手法です。しかし、作業管理のアプローチや柔軟性がカンバン方式と異なります。スクラム方式は、スプリントと呼ばれる時間枠を使用し、構造化および定義されたプロセスに従う手法です。スクラム方式とカンバン方式を比べると、カンバン方式のほうが柔軟性・適応性ともに高くなります。
カンバン方式の具体的な利用シーン
カンバン方式が利用されているシーンとして、次の2つの具体例を紹介します。
ソフトウェア開発
カンバン方式は、ソフトウェア開発において製品のバックログ管理（在庫や未処理プログラムの管理）や、スプリント計画（プロジェクト完了に向けた必要業務を短時間の枠で区切って立てる計画）、バグ追跡に広く使用されています。ソフトウェア開発でカンバン方式を利用すると、タスクを開発段階等（バックログ、進行中など）の列に整理してワークフローを可視化できます。現段階の進行度が可視化されることで、仕掛かり作業の進行も制限でき、ワークフローの最適化が可能です。
また、ソフトウェア開発では、複数のプロジェクトが同時進行するケースも多く見られます。複数プロジェクトが同時進行すると、特定の段階で特定の社員に業務が偏ることは珍しくありません。しかし、カンバン方式を利用すればワークフローが一目瞭然になるため、過度なタスクの集中を避けられます。
さらにカンバン方式は、ワークフローをいつでも変えられるという柔軟性を持つ点もメリットの一つです。既存の作業以外に必要な作業があれば、バックログに追加し、優先順位に基づいてタスクを管理できます。したがって、カンバン方式は、技術や社会の変化への対応が求められるソフトウェア開発に最適だと言えます。
インシデント管理
ITシステムに障害を起こしている課題や、近いうちに障害を起こしそうな課題をインシデントと呼びます。「インシデント管理」とは、こうしたインシデントが起きた際に、システム・サービスを素早く復旧させるための取り組みです。
インシデント管理では、インシデントの迅速な検知と適切な対処が求められます。さらに、インシデントの深刻度に応じて、対処の優先度が変更されるケースは少なくありません。その点、リアルタイムでのワークフローの可視化や柔軟な対応が可能なカンバン方式の特性は、インシデント管理に適していると考えられます。
なお、インシデント管理では「情報共有がしにくい」「問い合わせ対応の属人化」といった課題がよく発生します。だからこそ、カンバン方式を利用することで、チーム全体がインシデント管理の状況を把握できるようになります。また、カンバン方式を使えばインシデント対応業務の分配もスムーズです。発生したインシデントへの対応から継続的な改善を目指す際にも、カンバン方式は有効だと言えます。
カンバン方式に変更を可能にしたPagerDutyの企業カルチャーとは？
かつて3Mの社長を務めたWilliam McKnight氏の言葉に「優秀な社員を雇いなさい、そして彼らの自主性を尊重しなさい」という名言があります。開発に関するPagerDutyの企業カルチャーは、まさにWilliam McKnight氏の言葉を形にしたものです。PagerDutyのチームでは、メンバー1人1人が当事者意識を持ち自己組織化されています。だからこそ、メンバーには「自分たちの未来は自らが決める」という気概があるのです。
現在、あらゆる開発プロジェクトチームが、製品開発の変動に対応し自己管理するアジャイル開発手法を取り入れています。開発プロジェクトチームは、業務管理手法にスクラム方式かカンバン方式のどちらかを利用しているでしょう。ではなぜ、PagerDutyのチームのほとんどがカンバン方式に変更したのでしょうか？
PagerDutyの多くのチームがカンバン方式に変更した理由
多くの開発プロジェクトチームがカンバン方式に変更した理由には、カンバン方式で成果を上げた同僚たちの話が影響しています。実際、周りの成功の様子を見た上でカンバン方式を試すチームも現れましたが、中には、カンバン方式を正しく理解していないチームもありました。どのような誤解があったのか、次章で解説します。
カンバン方式に対する誤解
✅能力のあるチームはいずれカンバン方式を選ぶ
スクラム方式・カンバン方式はどちらも、開発プロジェクトチームが顧客に可能な限り迅速なサービスを提供するための手法です。それぞれの方式に、優劣はありません。そのため「能力のあるチームはいずれカンバン方式を選ぶ」という考えは誤解だと言えます。
カンバン方式がどのチームにとっても優れた手法であるとは限らず、選んだ手法でうまくいったとしても、効果が永久的に続くというものでもありません。開発プロジェクトチームの課題や特性を明らかにした上で、スクラム方式とカンバン方式のどちらが適しているのかを判断しましょう。
✅カンバン方式には時間枠がない
カンバン方式では、チームにあらかじめ決められた作業量枠があります。例えば、3日以内で完了する業務量を1枠とするなどです。作業量枠を設定した上で開発プロジェクトに臨みます。カンバン方式には、スクラム方式のようなストーリーポイントやスプリントと呼ばれる時間枠はありません。しかし、カンバン方式で設定する作業量枠は、時間枠とも言えるでしょう。
✅カンバン方式には時間制限がない
カンバン方式には、スプリント（通常2～4週間の完了目標設定）という概念がありません。ただし、スクラム方式を利用する開発プロジェクトチームがスプリント速度（特定の時間枠内で完了した作業の測定値）に責任を持つように、カンバン方式を利用する開発プロジェクトチームは、サイクル時間（1チケットあたりの完了時間）に責任を持ちます。タスクの時間枠は設定されていなくてもサイクル時間には制限があるため、一概に「時間制限がない」とは言えません。なお、サイクル時間は、経験過程と発表予定日時を考慮して決められます。
✅カンバン方式は会議が少ない
カンバン方式では会議の実施が推奨されていますが、スクラム方式のようにルール化されているわけではありません。しかし実際のところ、多くの開発プロジェクトチームがプロジェクトの成功には定期的なミーティングが欠かせないと考えています。
スクラム方式とカンバン方式のどちらを利用するにしても、プロジェクトを成功に導くには、ミーティングを重ね、目標と計画に対してチーム全員が同じ意識を持つことが重要です。PagerDutyのカンバンチームは、バックログ管理ミーティングを行なう代わりに、進行中の作業が完了するとTo Doリストから新しい作業を取り出します。それに加え、振り返り・評価・スタンドアップといった会議は欠かせません。
また、バックログ管理を行なう、「バックログリファインメント」と呼ばれるミーティングも取り入れています。ただし、カンバン方式ではスプリントプランニング会議は行なわれません。プロジェクト全体を通して、カンバン方式のミーティング数が多少減ることはあるとしても、スクラム方式との大きな違いはないのです。
カンバン方式に変更する合理的な3つの理由
1️⃣ スクラム方式は柔軟性が低い
スクラム方式では、目的と時間を定めたイテレーション（完成度を高めて繰り返すサイクル）に分割して開発作業を行ないます。そのため、途中で業務量を変更するなどの柔軟性はありません。PagerDutyには「ソフトウェアに関する責任はそれを開発したチームにある」とする、DevOpsのカルチャーが根付いています。責任がある以上、途中で緊急の業務が発生することも珍しくありません。
スクラム方式ではこの緊急業務を「sprint injection（スプリントの追加)」と呼び、スプリント速度を減速させるネガティブなものとして捉えます。その点、カンバン方式では「緊急性の高い業務」としてチームが柔軟に対応できます。
2️⃣ スクラム方式はルールが多い
スクラム方式には、厳格な方法論と規則があります。そのため、ゼロから態勢を整えるような新しいチームに向いている手法です。一方で、経験値の高いチームにとってはスクラム方式のルールが妨げになり、業務速度が下がることがあります。
3️⃣ 重要なのはチームカルチャー
チームによって、業務の進め方はさまざまです。スプリントコミットメントなどの目標に対する進捗状況を定期的に確認したいチームもあれば、サイクル時間を短縮して業務効率を上げたいチームもあります。
WIP（進行中）の作業管理についても、スプリントコミットメントで行ないたいチームと、システムのチケットで管理したいチームに分かれます。さらには、業務分量をストーリーポイントで測りたいと考えるチームに対し、「3日以内で完了できる業務量」で区切った管理方法が効率的であり、ストーリーポイントにはメリットが少ないと考えるチームもあります。チームカルチャーに応じて、スクラム方式・カンバン方式のどちらが適しているかを判断しましょう。
カンバン方式の採用で注意すべきこと
現在、PagerDutyのチームは、開発プロジェクトのほぼ全てでカンバン方式を採用しています。しかし、PagerDutyの開発プロジェクトチームがカンバン方式に変更したからといって、早急にカンバン方式を採用するのはおすすめしません。方式の変更を検討する際には、スクラム方式とカンバン方式の違いについて理解しておくことが大切です。
また、開発プロジェクトの成功において、チームの継続的な学習やスムーズなコミュニケーション、状況の正確な把握や判断が必要なのは、カンバン方式でもスクラム方式でも同じです。この記事の内容を参考に、自社の開発プロジェクトチームにはスクラム方式とカンバン方式のどちらが最適なのかを検討してみてください。その際には、実際にインシデント管理やシステム開発のプロセスを変革した開発プロジェクトチームの事例を見るのがおすすめです。
大手通信会社のNTTドコモ様が、PagerDutyを通してインシデント管理のプロセスを変革させた事例があります。この事例を参考にしたい方は、ぜひこちらのページからご覧ください。その他の参考事例については、こちらから確認いただけます。
この記事が気になったら
PageDuty公式アカウントをフォロー
この記事の著者
関連ブログ記事
人気記事
検索
タグ目次
