カンバンボードで業務を可視化・整理しよう - 組織に合ったカンバンの設計・運用をヴァル研究所の実践に学ぶ

Agile Journeyをご覧の皆さん、こんにちは。ヴァル研究所の熊野壮真 / 小泉翔太です。
私たちの勤務する株式会社ヴァル研究所は、日本で最初に発売された経路検索サービス「駅すぱあと」を中心に、公共交通に関連するさまざまなプロダクトを展開しています。最近では MaaS （Mobility as a Service)）といった、未来の移動のあり方を変えていくような取り組みにもチャレンジしています。

これらプロダクト開発の現場にはアジャイルの考え方が浸透しており、各チームでは現場ごとに合わせたさまざまな形のアジャイルの実践が見られます。その実践手法は多様ですが、各チーム、共通して力を入れているのが「カンバン」による仕事の可視化の取り組みです。こと「カンバン」に関しては開発部門のみならず、バックオフィス部門でも積極的に活用しており、その活用場面の多さ、バリエーションの豊かさは当社の特色と言えます。

本稿では、「mixway team」というWeb API開発グループ内のチームで開発を担当している熊野と総務業務を担っている小泉がそれぞれの経験を持ち寄り、「カンバン」の運用や解消してきた課題、自分チームへの最適化の過程、そしてコロナ禍以降のリモートワークへの対応などをお伝えします。仕事の可視化や「カンバン」運用に悩まれている読者の方が、そっと一歩を踏み出すお手伝いができれば嬉しいです。

なお本稿における「カンバン」は、日本の製造業をヒントに発展した開発プラクティスとしての「カンバン」のうち、特にツールとしての「カンバンボード」を念頭に置いています。以下括弧書きを外し、「カンバン」と表現しますが、そのような意味と捉えてください。 「カンバン」や “Kanban”、”Kanban board” で検索すると、多くの先人の知恵を見つけることができます。ぜひ参照してください。

カンバンで解決したかったこと

そもそも、私たちがアジャイルについて学び始めたのは2012年ごろです。有志数名が社内横断組織を作り、草の根活動的な発信を行なっていました。元々ボトムアップを好む文化的土壌があったこともあり、アジャイルな考え方や、スクラムといったプラクティスを取り入れるチームが2〜3現れるまで、そう時間はかかりませんでした。

その中でも当時R&Dを行なっていたチームが採用したカンバンの取り組みが社内で評判となり、「うちもうちも」と取り入れる現場が増えていったのです。結果、カンバンを含む業務の可視化を目的としたなんらかのボードは、最も多い時期で100近くまで増加しました。当社の社員数は160人強なので、その豊富さが分かると思います。

【総務チーム】「業務が不可視」「メンバーのスキルが偏在」が課題

こうしてカンバンが増えていった背景には、それぞれのチームに「カンバンを用いて解決したい課題」があったことは言うまでもありません。総務チームの業務範囲は人事・総務全般で、採用・研修・労務・人事制度運用から購買や自社ビルの管理まで、多岐にわたります。しかし当時は、社員3名と派遣スタッフ1名の少数体制で、メンバーそれぞれが自身の専門業務を持っており、担当業務が明確に分かれていました。そのため、各人がどのような仕事をしているのか、進捗がどうなっているのかが見えにくくなっており、必然的にメンバー間のスキルにも偏りが生じていたのです。このころの総務チームは「個の集合」にすぎず「チーム」としての仕事ができていなかったのです。これが総務チームの抱えていた課題でした。

【Web API開発チーム】関係者が多く業務のプライオリティ整理が困難

一方のWeb API開発チームでは、ステークホルダーの多さに起因する課題がありました。Web APIサービスは成長途上であり、お客様から多くの要望をいただきます。また自社プロダクトにも使われているため、社内から生じるニーズも存在します。さらには社内の他チームが開発するプログラムをラップするミドルウェア的な性格も備えているため、さまざまな開発チームとの調整も欠かせません。

このように多くのステークホルダーが関わり開発しているプロダクトであり、それだけに制約も多く、チームが「やりたい事」と制約が常に渦巻いている状態です。そんな中で開発チームが息切れせず、一定のスループットで成果を出し続けるためには、仕事の可視化や整理が必要でした。まずはスクラムのフレームワークを導入しましたが、スクラムの取り組みの中で、ミクロな日々の仕事を可視化し整理するツールとしてカンバンは非常によくフィットしたのです。

カンバンをチームに導入＆定着施策を講じよう！

【総務チーム】定着の秘訣はカンバンに触れるきっかけ作り

これら課題解決を目指し、総務チームがカンバンを導入したのは2015年のことです。社内の推進に乗る形でカンバンを導入しましたが、導入当初は付箋を動かすことを忘れてしまったり、カンバンにないタスクをやっていたりと、カンバンが「当たり前」になっていなかったのが実情でした。

そんな私たちがなぜカンバンを当たり前にできたか。今振り返ると「イベント」と「振り返り」の2つの取り組みによって、習慣化のきっかけができたことがポイントだったように思います。

• イベント：カンバンを見る / 使うきっかけづくり
  • 毎日の朝会と、週次の計画会議のことです。最初は決まったタイミングに、チーム全員でカンバンを見る・使うことで、徐々にカンバンを使うことを習慣化していきました。
• 振り返り：カンバンを改善する / 考えるきっかけづくり
  • 当時は毎週KPTを実施しており、その中でカンバンの改善についても自然と振り返りが行われていました。使いにくいところ、モヤモヤするところなどが共有されてるので、すぐに改善サイクルを回せます。当時のチームリーダーがカンバンを含むいくつかのプラクティスを導入しましたが、メンバーの意見を適切に汲み取ってくれ、振り返りの翌日にはカンバンの形態が大きく変わっていることもありました。こうして生まれた改善サイクルを回す中で自チームに合った運用へ、少しずつアジャストしていったと思います。常に運用を見直すのはなかなかに大変でしたが、習慣化するための大きな要因だったと思います。

以上の取り組みが、総務チームのカンバン習慣化に好影響を与えましたが、もう1つポイントを挙げるとすれば、それは「完璧を求めすぎない」でしょう。特に総務チームは割り込みタスクが多いですから、「何か1つでも手落ちがあったらダメ」という考え方になると、運用が息苦しくなってしまいます。チームのカルチャーにもよると思いますが、カンバン運用に気軽に取り組めるスタンスがあったことも奏功したと思います。

また、総務チームにはエンジニア経験者がおり、何かツールやプラクティスを導入し仕事を改善することに前向きだったことも、カンバン導入の後押しとなりました。

【Web API開発チーム】「書かない・動かさない」問題への対策は「声かけ」と「情報集約」

Web API開発チームの場合、カンバンを導入したのはちょうどコロナ禍に入る時期の現チーム立ち上がりのタイミングでした。当社でもフルリモート体制に移行し、特に開発者がオフィスに来ることはは皆無になりました。筆者がそれまでに所属していたチームでは、ホワイトボードに線をひき、その上で付箋を動かすリアルなカンバンを活用しており、物理的なカンバン運用に愛着を持っていたのですが、リモートワーク下でこれが使えず、オンライン上でのカンバン運用に適したツール探しから着手せねばならなかったのです。

紆余曲折ありましたが、採用したのは定番であるヌーラボ社のBacklogのボード機能です。付箋（Backlog上では「課題」と表現されます）を列から列へドラッグできる、物理カンバンに近いUIが決め手になりました。「ステータスさえ把握できればインターフェースは物理カンバンと違ってもいいのでは」という意見も出ましたが、筆者は物理カンバンに近いUIにこだわりたかったのです。なぜなら、カンバン上で「付箋を左から取って右に進めていく」ような操作感や「問題を抱えると複数の付箋が一箇所に滞留する」という目に見えるカンバン特有のフィードバックは、チームの状況を表すメタファーとしてとても有用だと考えているからです。

かくして始めたオンラインカンバン運用ですが、最大の課題は「書かない・動かさない」問題です。物理的なカンバンであれば、そこへ行き付箋を書くなり動かすなりすれば、実際のステータスとカンバンを簡単に同期できます。対して（Backlogに限らず）多くのオンラインのツールでは、付箋を書き始めるまでに、サービスにアクセスする、ログインする、見たいプロジェクトへ遷移しカンバン画面を開く.…….という、いくつかのステップを踏まねばなりません。これが心理的な障壁となり、誰かの仕事が進んだり詰まったりしても、カンバンに反映されないという日が続きました。タスクの状況の見通しをよくするというカンバンの目的から考えると、これはよくない状況です。チームの振り返りでも議題に上がり、幾度も改善の方策を議論しました。

この課題を解消するべく、チームが取った方法は2つです。 1つは単純な声かけです。朝会や計画会議、そのほかのミーティングの場面で「カンバンは最新の状態になってますか？」や「今の会話でステータスが変わったのでカンバンを動かしましょう」という声かけを互いにするようにしました。少々人力に頼った方法ですが、習慣化には効果的です。

もう1つは必要な情報を全てカンバンに集めたということです。私のチームではスクラムを活用して開発をしています。当初、スクラムで重要な情報となるProduct Backlogは別のツールで管理していたのですが、この機にカンバンへ統合しました。カンバンのカード1枚をPBIやSBIに対応させ、そこにユーザースーリーや完了の定義、開発の状況やステークホルダーからのフィードバックなど、開発に必要な全ての情報を集約することにしたのです。これによってプロダクトの状況とチームの状況、カンバン上でのステータスが完全に一致するようになりました。また仕事をこなすには常にカンバンを参照するというサイクルが回るようになり、カードの記入や移動も活発化します。

カンバンに全ての情報を集約する場合、情報量が多くなり物理的な付箋には記載しきれません。一方、オンラインツールであれば1枚の付箋にテキストや画像をたくさん載せられるという強みが発揮が発揮されます。

カンバンをチームに最適化させよう！いまの運用の形と、いまに至る変遷

【総務チーム】3つの機能を落とし込んだカンバンの現在

総務チームがカンバン運用で大切にしていることは、全ての仕事を見える化すること、そしてそれをチームで共有することです。こうしたマインドで運用していく中で、かつて縦割り組織的な課題を抱えていた総務チームが、タスクの可視化・スキルの共有がされるようになってきたのです。そして、カンバン自体も運用の中でその形を変えてきました。総務チームのカンバンは2020年4月のリモートワーク移行と同時に、物理カンバンからアトラシアン社のTrelloへ移行しています。今のカンバンは以下の項目から成り立っています。

かなり横に長いリストの連なりになっているので画像は3分割していますが、これらリストが1つのボードに収まっており、大きくは「曜日ごとイベント整理・共有」「その日のタスクのステータス管理」「中長期的なタスク管理」の3種の機能を持っています。それぞれのリストは以下のような定義、役割で運用しています。

• 曜日ごとイベント整理・共有ゾーン
  • 曜日別タスク（月〜金）：1週間分の各曜日のタスクやMTG、締切など
• その日の業務のステータス管理ゾーン
  • 今日のMTG：打ち合わせの時間を把握するため、ToDoとは別リスト
  • 今日のToDo：当日のタスク
  • Doing：今、取り組んでいること
  • Waiting：仕掛かっているタスク。ボールが相手にある状態のタスクや、資料を作って一旦寝かせたい時などに置く場所
  • Done：今日終わったタスクを置く
• 中長期的な業務管理ゾーン
  • 労務対応一覧：労務関連のタスクは1つのイベント（入退社、住所変更、産休育休など）に対し、タスクが複数あって長期間にわたるため、ToDoとは別リストで管理
  • 来週以降やること：思い付いた先々のタスクを忘れないように置いておく場所

上記リストのうち「Waiting」は、総務らしいリストといえそうです。総務チームはその業務特性（確認・連絡待ち、押印待ち、承認待ちなどが多い）から、待機せねばならないタスクも多いです。こうした行き場所を見失いがちなタスクを「Waiting」に蓄積することで、チーム内で共有化され抜け漏れ防止につながります。

カード（物理カンバンでいうところの付箋）に記載する情報も、以下のサンプルのようにある程度フォーマット化しています。

カードにはそのタスクの担当者のアイコンを付けます。ラベルはどの業務（例：新卒採用、社員研修、労務、庶務）かを分けるのに使用しています。また、必要に応じてチェックリストを使います。Trelloの有料機能になってしまいますが、チェックリストの各項目に期限や担当者を振れるので便利です。

【総務チーム】定期MTGの時間を利用し、カンバンを更新

これらのリスト、カードは定期的にメンテナンスし常に最新の状態へと更新しています。総務チームでは、以下の2つのタイミングで更新を行っています。

• 計画会議（毎週金曜夕方）
  • 「曜日別タスク」へタスクやMTGを書き出します。書き出す際の粒度は特に気にせず、とりあえず書き出します。粒度が大きすぎるタスクについては、カードを分けたり、カードのチェックリストを用いたりして細分化し管理しやすくしています。
  • 「来週以降やること」で着手時期が来たものは「曜日別タスク」に移します。
• 朝会（毎朝）
  • 「曜日別タスク」から「今日のToDo」へタスクを移動させておきます。
  • 前日の「Done」を一通り読み上げながらアーカイブしていきます。必要に応じて説明を入れます。
  • 「今日のToDo・MTG」「Doing」「Waiting」の確認をしつつ、困っている点などはその場で共有します。

なお、前述のとおり総務チームは割り込みタスクが多く発生するため、いつでもタスクは追加してOKですし、タスクのステータスが変わった際はリスト移動も随時行ってOKとなっています。

【総務チーム】カンバン変遷。カンバンからなくなったもの

現状のカンバンの設計、運用は上記の通りですが、もちろんカンバンを導入してすぐにこの形に落ち着いたわけではなく、さまざまなトライアル&エラーを繰り返してきました。総務チームの初期のカンバンは……

こうした状態でした。こちらは、いわば最初期のβバージョン。その後、運用していくなかで以下のような状態にアップデートされました。

上記のリスト設計はいくつかのバージョンを合成したものですが、現在のものに比べるとリストの数が少なくシンプルです。しかし、シンプルではあるものの、チームメンバーの状況や業務管理が直感的に把握しにくいという課題があり、より自分たちの業務に最適化するべく、以下の設計を見直したのです。

• ToDoing・Waiting・Done運用

  • 割り込みや、複数の作業を並行して行うことが多かったので、あえて「やること・今やっていること」の区別をつけず「ToDoing」にまとめ、他者のボールになっている業務は「Waiting」、終了したものは「Done」という形を取ってみたのですが、「今現在何に手をつけているか」がわかりにくくなり、廃止しました。代わりに、上記の通り週単位での業務整理と「今日のToDo」を設置し、「今やっていること」を（Doing）に移動することで、明示的になるように改良しています。

• 業務を重要度・緊急度のマトリクスで配置

  • 総務チームには多様な業務があり、カンバンが付箋であふれかえってしまうことが常でした。そのため、縦軸を重要度、横軸を緊急度としてタスクを配置する運用や、「やること」と「やりたいこと」を分けて配置する運用を試しました。しかし総務チームには「やらなければならない仕事」が多く、こうしたマトリクスが機能しないことが多かったため、リスト内でのマトリクス整理は廃止しました。
• みんなでやろう・誰かお願いゾーン
  • 読んで字の如くですが、こちらはカンバンの運用が定着し、メンバーの状況が可視化されたことで、朝会の時などにメンバー同士が自然と助け合う文化ができたため、あえてそういう表記をしなくなりました。

見直したのはリストの設計だけではありません。最適化を目指す中で、運用上の取り組みも見直しを重ねてきました。たとえば、詳細な見積もりです。カンバン開始当初はチームが1週間でこなせるタスク量を明らかにし、優先順位を付けてタスクを回そうとプランニングポーカーで見積もりを付けていました。しかし、総務チームの仕事は前述の通り「やらなければならない仕事」が多く、また、見積もりを詳細化するのに時間がかかりすぎてしまうことから、現在では「なんとなくのキャパシティを把握できる」程度の見積もりに止めています。

このように設計、運用の両面で「やってみて、検証する」を繰り返し、徐々にチームにフィットする形を模索していくのが大事だと考えています。

【Web API開発チーム】スクラムに適したカンバン運用

続いては、Web API開発チームのカンバンです。先述の通り、筆者のチームはスクラムにそって開発をしているため、カンバンにもその考え方が色濃く反映されています。カンバン導入当初はBacklogのボード機能に元から準備されている「未対応」「処理中」「処理済み」「完了」というリスト構成でしたが、カイゼンを重ねていく中で、以下のようにかなり細分化されてきました。

それぞれのリストは以下のような役割、定義で運用されています。

• 未対応
  • 詳細なPBIにはできていないが忘れたくない思いつきを溜めておく場所。スクラムにおけるPBの下位の方の未整理な部分と同じように扱う
  • 「いつかは作りたい機能」や「やっておきたいカイゼン」のようなものが該当。
  • スクラムチームに所属する全てのメンバーがここに起票できる
• toDo整理済み
  • 詳細化され順位付けが済んだPBIを溜めておく場所。スクラムにおけるPBの上位数スプリント分と同一視できる
  • ここはPOの責任で追加や並び替えを行う
• 処理中
  • 現スプリント内で取り組むことをコミットメントしたカードが置かれる。一般的なカンバンの「toDo」と「Doing」が合わさったようなイメージ
  • ここには多くても3枚程度のカードしか置かれない
• in review
  • 実装が完了し、コードレビューやPOによるレビューを待っているカードを置く場所
• pending
  • 仕掛かったものの、なんらかの要因でステータスを進めることができなくなったカードが置く 例えば他社と共同で進める取り組みで、ビジネス整理を待っているため進められないカードなどが該当
• waiting for release
  • 開発やレビューを完了し、リリース日を待っているカードが置かれる
• 処理済み
  • 現スプリントにおいて、カードに関連する全ての作業が完了したカードが置かれる場所
• 完了
  • カードに関連する全ての作業が完了し、チームでそれをリリースできたことを祝ったものが置かれる

【APIチーム】情報集約のためのカード記入フォーマットと起票ルール

先に必要な情報はカンバンに集約する、とお伝えしたとおり、カードにはさまざまな情報を記載します。以下のサンプルをご覧下さい。

サンプルではかなり簡単な記載にとどめていますが、カードにはなぜそのカードに取り組むべきかを説明するユーザーストーリーや、何が為されれば完了とできるかを約束したコミットメント、マイルストーンごとの記録などそのPBIに関連するあらゆる情報を記載しています。また、取り組む中で、詰まったり困ったりした出来事なども後から見返せるようメモします。コードについてまとめたドキュメントや調査メモなど、再度参照される可能性の高いものは別のドキュメントツールにまとめた後に、そのURLをカードに記載しています。

カードを切る粒度もよく議論に上がります。ざっくりと切るチームもあれば、全ての作業に対して細かく切るチームもあると思います。筆者のチームでは議論の上で「半日（約3時間）を越える見込みの作業はカードを切る」というルールを定めました。突発的な業務であっても、それがプロダクトの成長に寄与するのであれば将来も参照できるようカード化しトラッキング可能な状態にしておくべき、という考えからです。対して、本当に細々とした作業や、チーム全体へ可視化するほどでもない作業もあります。こっそりやってお披露目したい作業もあるかもしれません（小さいけど素敵なスクリプトを作って、同僚を驚かせた経験はありますよね？）。「半日以上の作業はカード化」ルールは、こうした人間的なバッファーを吸収する緩衝材としてうまく機能しています。

物理カンバンをいかにしてオンラインに移行するか。いま向き合う課題

総務チーム、Web API開発チームともに、それぞれのやり方でカンバン運用に向き合っていますが、もちろんまだそれぞれに課題を抱えています。とくに、物理からオンラインに移行したことによる課題は両チーム共通しています。

総務チームの場合、物理的カンバンの美点を

• いつでもどこでもカンバンを確認できる
• タスクの修正や説明書きが容易で、カードに資料の添付もできる
• カードの中にチェックリストを作成するなど、付箋を拡張して使うことができる

と捉えています。一方のオンラインカンバンには、以下のような課題を感じています。

• 面積が無限になってしまったため、リストやカードが乱立して長期間放置されるタスクが出てきている
• ホワイトボードを囲んで業務について話すときにあった「チームのワイワイ感」が弱くなる
• 画面上に常に表示しておけなかったり、全体を一覧できないため、見落としや、タスクのステータス変更忘れの頻度が上がる

もちろん、これら課題感に対してはいくつかの対策を講じています、たとえば、

• 計画会議で時間に余裕がある時、全体を見回し長期間放置されるカードを点検
• 出社を週2回輪番制から、メンバーの合意を得て週3回全員出社*1へ変更。在宅のメリットを享受しつつ、カンバンを囲んだコミュニケーション活発化という、対面でのメリットも生かすように工夫

Web API開発チームが感じるオンラインカンバンの課題は「手触り感」不足です。オンライン上のカンバンをどれほど使いこなしても、物理的なカンバンの手触り感、つまり物理運用がもたらす、ふとした情報を得ることはできていません。例えばタスクを書いた付箋がヨレヨレになっていれば、そのタスクは着手されずに放置されているか、何らかの理由で停滞してしまっているという情報が得られます。なんとなくカンバン全体を眺め、新しい付箋を見かければ「POが何か新しいことをやろうとしているな」と感じることもできます。忘れていた付箋が目に入り「この案件はどうなったかな？」と思い出すこともあるでしょう。こうした情報はオンライン上のカンバンではなかなか得られません。

また物理的なカンバンでは、誰かが（主に筆者ですが）ホワイトボードに落書きをしたり、かわいいマグネットを貼ることがありました。こうした遊び心がきっかけになり雑談の輪が生まれチームの良い空気作りに一役買うこともあります。良い空気感はDX（開発者体験）にも影響します。物理的なカンバン特有の「楽しさ」も再現されたオンラインカンバンの実現が、いま向き合う課題です。

共有とコミットメントが、取り組みを成功させる

両チームのこれまでの取り組みを振り返ってみると、「カンバン」を組織の中で機能させるために必要だったのは、ルールやシステムに頼ることではなく、導入初期に心がけていた、「カンバンを活用しよう、カードを書こう！」というリアルな声掛け、そしてチームがまずは手を動かしてみる、というある種アナログなアプローチが鍵となっていました。実際に手を動かすことで自分たちにフィットする運用が積極的に模索され、細かい改善が得られたのです。結果、チームに浸透するまでの期間が短縮され、その後のスムーズなオペレーションに繋がったのだと思います。

こうした声掛けなどの取り組みを個々の自主性に委ねてしまうと、いつの間にか雲散霧消してしまう可能性もあったでしょう。私たちが（カンバンに限らず）新しいアジャイルな取り組みにモチベーションを保てたのは、社内で立ち上げた「アジャイル推進委員会」の存在が影響していたと思います。委員会はアジャイルにまつわる情報交換や、困った時の拠り所です。委員会で情報や好事例を得た者がチームに持ち帰りキーマンやハブとなって旗を振ったからこそ、周囲を巻き込みチームでの運用が軌道に乗ったのです。

ここまで述べたように私たちのカンバンはカイゼンを重ね、スタート地点からはかなり遠い場所まで歩みを進められました。過程や方法は多々あれど、チームの個々人が情熱と当事者感をもってカンバンに向き合うこと、そしてそういった意識を持てる空気づくりがなによりも大事です。 長く続いてきた組織ほど新しいやり方を導入する最初のハードルが高いかもしれませんが、ぜひ本稿を読まれた皆さんがハブとなり、自分たちのチームにふさわしいカンバン、そして「アジャイル」を実践していただけたら幸いです。

関連記事

編集：はてな編集部

*1:私は育児事情で週1回の出社にさせてもらっています。ありがたいです。

小泉翔太（こいずみ・しょうた）

2011年に新卒でヴァル研究所に入社。1年間Web系のプロダクト開発チームにエンジニアとして従事し、2012年より現職（総務チーム）。
新卒採用・経験者採用・研修企画 / 運営をメインに、労務、人事制度策定・運用、経営理念策定プロジェクトなど、人事・総務の様々な業務に携わっている。

熊野壮真（くまの・そうま） @kumatira

2018年に新卒でヴァル研究所へ入社。WebAPIプロダクトの開発・DevRelに従事。2019年よりMaaS開発に携わった後、経路検索サービス「mixway」のプロダクトオーナーに着任。Certified Scrum Product Owner