はじめに
僕はプロジェクト運営にカンバンを使っています
少人数プロジェクトはTrelloを利用していて、5人位から壁に付箋紙を貼る現物パターンにしています
このあたりはまた別の記事にまとめたいと思いますが、今回はカンバンの紹介や気をつけたい点などについてまとめてみました
（Atlassian風に言うと僕の使用しているのはカンプランというものらしい、今回記事にするために調べて知りました）
あくまでも個人とチームで試行錯誤した結果なのでこれが唯一の正解ではないし、また正解は無いと思います
別の意見がある方はぜひ色々教えて頂き、良いものを一緒に模索できたら嬉しいです
対象
プロジェクトリーダー（またはそういう立場の人）
アジャイル開発で試行錯誤している人
プロジェクトを良くしたいと思う全ての人
到達イメージ
カンバンを導入してこんな段階を経て、プロジェクトを改善しているよというイメージです
なにかの参考に、とくに向かい風のなか、カンバンを導入して改善したいと思っている人の力になれば幸いです
１．見える化
○ まずは楽しく導入
（良い傾向）
- カンバンを手作りしよう！と声をかけたら、いい感じに手伝ってくれる
（普段知らないスキルの発見にもなる、字が上手いとかセンスがあるとか
そういうのは仲間としての尊敬にも繋がり、相乗効果が期待できる）
（失敗例）
- メンバーが遠巻きにみているだけ
- 「またか」みたいな顔をしている
こんな状態のときは、メンバーはあなたのことを信頼していません
そして、あなたもメンバーを信頼していないのでは？
まずは話をちゃんと聞くところから始めたいですね
「Memoや取り組みなど」
お客様の言う通りにやるプロジェクトには向いていません、バリューを提供しましょう
納期を守るためにカンバンをと考えているならやめたほうが良いです
２．コミュニケーション
○ 朝会など、カンバンを見ながら話す習慣を
（良い傾向）
- 朝会や夕会でカンバンを見ながら全体の話ができる
- ○○さん（別のメンバー）大変そうですね・・・のような話ができる
自分のタスクが誰かの役に立っていたり、全体のどの位置なのかを
把握できるようになってきます
（失敗例）
- カンバンにタスクが一目瞭然なのに、全員にやることを発表させる（楽しいなら別）
- カンバンが更新されない、急ぎの仕事がドンドン入る
一気に意味のないもの、「カンバンという仕事」が増えただけに感じます
また、カンバンの更新が追いつかないほど急な仕事がはいるのは
スピート感ではなく、計画性がないだけかもしれません
「Memoや取り組みなど」
リーダーはコミュニケーションを学びましょう
「上手い話し方」ではなく「上手い聞き方」であり、信頼です
３．振り返りLV1
○ 運用から1ヶ月くらい or リリースなどのイベントのタイミングで振り返りを行う
（良い傾向）
- KPT（Keep/Problem/Try）やYWT（やったこと・わかったこと・次に活かせること）が活発に行える
ただし、１回目は中々勝手がつかめず活発な会になりにくいです、根気よく行きましょう
僕は２回目からが本番だと思っています（前回との比較ができるので
（失敗例）
- なんの意見もでない、もしくはお決まりの意見しかでない（コンフリクトが多かったなど）
「あなたを改善したい」と思っているかもしれません（心理的安全の欠如）
一人くらい本音を言ってくれるメンバーはいませんか？
「Memoや取り組みなど」
このあたりが一番効率が落ちる時期と思います、それでもこれを繰り返すというという態度が
みんなの安心感にも繋がり、定着するコツです
４．スループット
○ 段々と慣れてきて改善を話し合えるように
（良い傾向）
- １回目の振り返りので出てきた内容を１つでも改善しようとする
- 「ここをこんな風にできないですかね？」といった会話が聞こえる
こんな風になってきたら、ずいぶんプロジェクトの空気は良いと思います
カードや付箋に作業の見積もりを記入し、どのくらい早くなったか？や
どうすれば良くなるか？を数値化していけると思います
（失敗例）
- とにかく早くとか、スケジュールに間に合うように！といった方向にもっていってしまう
スケジュールは大事ですが、品質やプロダクトに対する理解も大事です・・・
バランスなのですが、メンバーを信じましょう、わざと遅くはしないものです
「Memoや取り組みなど」
カンバンも定着してきているはずです、ここで数値化や
さらなるカンバンの改良を行えると、ずっとチームが強くなります
５．振り返りLV2
○ 改善に対する振り返り
（良い傾向）
- イメージの話ではなく数値で話ができる（早い・遅い＞３を２にできないか？など）
- メンバー１人１人が全体に関与していると思えている
ここまで来ると色んな事をまかせられるようになっているのではないでしょうか？
勉強会を企画したり、メンバーの体調をきにしたり、たとえば誕生日を覚えて
休みを促すようなイベントを楽しくやりましょう
（失敗例）
- イベントを特に考えない
- お客さんのいいなり感
せっかく自律的なプロジェクトの芽を摘んでしまっていませんか？
自分たちで考えるがゆえに顧客からのフィードバックがほしい時期
「Memoや取り組みなど」
勉強会や1on1ミーティングなどのイベントを行いたいですね
今のチームでは「でも・だって」禁止ゲームのような話し方の取り組みをしました
６．顧客も参加
○ できればお客さんも参加してもらう、隠し事はしない
（このあたりは順不同、顧客にも理解・知識があれば初期で導入も可）
（良い傾向）
- お客さんにも朝会や夕会などに参加してもらい忌憚ない意見をもらう
- お客さんのタスクもカンバンに登録する
- 問題点が共有できる
お客さんから「部長の決済がおりません」などの意見を言ってもらえると
一気にチームとしてのテンションが上ります
お客さんも含めてチームであるという気持ちを持ちたいですし、
実は、それが提供できる価値の最大なのではないでしょうか？
（失敗例）
- セキュリティーが・・・などの理由でお客さんを参加させない
- 隠し事がある
営業的に仕方のない部分があるのかもしれませんが信頼感が欠けたプロジェクトは
早晩失敗します
「Memoや取り組みなど」
成功例として社内での布教活動が必要
新規参入メンバーにも受け入れられやすいルール化・明文化など
７．さらなるコミュニケーション（お客さんも含めた振り返り）
○ お客さんも振り返りに参加してもらうことで新たな視点・意見をもらう
（良い傾向）
- 双方合わせた問題点がみつかる
- 実はお互いにとってメリットな部分が見つかる
これが出来れば次に目指すものはもう見えているのではないかなと思います、
逆にノウハウとして共有させて下さい
（失敗例）
- ここまでくると失敗ってあるのかなぁ
もしあったら教えてください（慢心くらいかなぁ・・・
「Memoや取り組みなど」
メンバーに布教活動させることですかね（笑
簡単なルールとTips
カンバンを運用する簡単なルールやTipsを紹介します
最低限はこんな項目があれば良いとされています
（□は付箋のイメージ）
| ToDo | Doing | Done |
|---|---|---|
| □ | □ | ■ |
| □ | □ | ■ |
| ■ | □ | |
| □ |
僕はこんな感じで運用しています
| Rule | iceBox | backLog | inProgress | Review | Done | その他メモ/知見 |
|---|---|---|---|---|---|---|
| □ | □ | □ | ■ | ■ | ■ | □ |
| □ | □ | □ | ■ | □ | □ | □ |
| □ | □ | □ | □ | □ | □ | |
| □ | □ |
0.Rule
- このプロジェクト固有の情報、Gitのルールとか、サイトのURL、環境の情報など
1.iceBox
- 要件はあるがタスクとして決まっていないもの
（〜したいという要望がこれにあたる）
2.backLog
- 何をやるか分かっているが、未着手や保留のタスク
（タスクとして分解出来ている、設計が出来ているもの）
3.inProgress
- 現在作業中のタスク
- 通常は黄色、Bugは赤、要望は青のように色分けする
- なにか問題がある場合はbackLogに戻す
4.Review
- レビュー中のタスク（問題があればinProgressに戻す）
- Reviewしている担当者を分かるようにしておくと便利
5.Done
- レビューが終了したタスク
- 2Week毎くらいに区切りを入れる（===01/25===など）とあとで集計しやすい
6.その他メモ/知見
- 作業していて発見した知見など
- 定型的なものはWikiにする
以下付録的な読み物
心理的安全
カンバンに限らずプロジェクトに（良くも悪くも）変化をもたらすためには
メンバーみんなの意見が取り入れられないとうまくいきません
何を言っても許される・尊重される雰囲気があってはじめてみんなの意見が
活かせるはずです、これを心理的安全が保たれている状態と呼びます
逆に、メンバーが疑心暗鬼だったり、中心的人物が話を聞かないタイプの人だった場合
結局どんなツールや手法を導入しても意味がないでしょう？
（これは、ウォーターフォール vs アジャイルでも同じことです）
また、心理的安全とはゆるく仕事ができるという事ではなく、チームやプロダクトに対して忌憚ない意見を言っても安全である、みんなで前向きに対処が出来るという信頼感があるということだと思います
以下のような状態が期待されるとのことですが、
逆にこういった光景がないなら心理的安全もないと考えたほうがいいですね
- 率直に話すことが推奨される
- 考えが明晰になる
- 意義ある対立が後押しされる
- 失敗が緩和される
- イノベーションが促される
- 成功という目標を追求する上での障害が取り除かれる
- 責任が向上する
参考：[「効果的なチームとは何か」を知る](https://rework.withgoogle.com/jp/guides/understanding-team-
effectiveness/steps/help-teams-take-action/)
カンバンとは
カンバンカードは、1940年代後半にトヨタの産業エンジニアである大野耐一氏が発明したもので、研究でアメリカを訪れていた大野氏があるスーパーマーケットで目にした光景から着想を得たとされています
商品棚がほぼ空になっていることが視覚的に確認できたときにのみ棚を補充し、当面の顧客の需要を満たすのに十分なだけの商品をその棚に補充する方式（ジャストインタイム「JIT」デリバリー）を生産方式に組み入れられたことがトヨタの成功の秘訣の１つであると言われています
その思想・方式が海を渡り、トヨタ生産システムを「リーン製造」として知られる一連のプロセスに分解されました
（なので逆輸入ということなのですね）
テクノロジー企業が1990年代に隆盛を迎えたとき、管理コンサルタントのDavid J.Anderson氏が「カンバン方式」を提唱し、情報テクノロジーやソフトウェア開発のような、目に見えない知識作業の領域へとリーン技術がもたらされることになったとのこと
このあたりはAtlassianのカンバンの説明が分かりやすいと思います
スクラムとの比較
| スクラム | カンバン | |
|---|---|---|
| 期間 | 長さが固定された定期的スプリント (2 週間) | 継続的なフロー |
| リリース方法 | 各スプリントの終了時 | 継続的デリバリー |
| 役割 | プロダクト所有者、スクラムマスター、開発チーム | 役割不要 |
| 主要指標 | ベロシティ | リードタイム、サイクル期間、WIP |
| 変更に関する考え方 | チームはスプリント中に変更を加えない | 変更は随時発生する可能性あり |
期間
スクラムではスプリントと呼ばれる期間を２〜４週間にわけて細かく区切っていきます
これは、短納期のプロジェクトであったり、以前にも同じようなことをやったチームには
メリットがあります
逆にカンバンは短納期に向かない傾向にありますが、良いチームを作り上げる
イメージが強いと思います
役割
スクラム
プロダクトオーナー（プロダクトにおける責任者）
スクラムマスター（コーチング、ファシリテーション、チームへの奉仕的な活動）
開発チーム（実際にプロダクトを開発するメンバー）
カンバン
役割は基本的にありません
（と、なっていますが、サーバントリーダーが必要なのでは？と思います）
主要指標
スクラムではタスクごとにストーリーポイントを設定します
スプリントが終わる毎にストーリーポイントを加算し（ベロシティーと呼ぶ）指標にする
リードタイムとWIP（Work in Progress）を「いい感じ」に考えるだけです
要するにチームは、1タスク（機能でもOK）をどれだけ早く要件をチームで理解し
形にしてテストし、顧客に届けるか？を考え、そのために最適な仕事量を制限します
適しているプロジェクトのタイプ（SoRとSoE
- SoR
System of Record（簡単に言うと既にあるシステムや仕組みを作ること - SoE
Systems of Engagement (簡単に言うと今までにないシステムを作ること
実はプロジェクトを始めるときこれを考慮しないプロジェクトが多い気がします
SoRの場合ゴールや指標があるので見積もりやストーリーポイントは比較的想像しやすいと思いますが、SoEの場合、まったく指標となるものがありません
どちらが絶対的に適しているとはいえませんが、前者はスクラム、後者はカンバンに適していると思います
今までに無いシステムを作るのにストーリーポイントを出すのはなんだか嘘をついている気分になりますよね？
迷った時のコツ
必要なのは
・メンバーはサボらない
・結果的にできるだけ早く届けられるようになる
・みんなで考えたほうが結果的に良いものになる
といった信頼感かと思います
（そういうメンバーなら出来るという意味ではなく、こちらから先にそう信頼するということです）
ウォーターフォールの設計者や圧の強い自称スクラムマスターが聞いたら卒倒しそうな内容かもしれません
でもこれが、心理的安全にも繋がり結果的に良いチーム・良い仕事ができる、そんな風に考えます
なんてカッコイイことを書きましたが、単純にそんな仕事のほうが僕が楽しいと感じるだけかもしれません
さいごに
カンバンを最初に導入したときも試行錯誤で、メンバーや仲間に助けてもらいました
今回もこの記事を書くにあたって、やっぱりメンバーや仲間にレビューをお願いしました
どうもありがとう、感謝します
そして、最後まで読んでくれたあなたにも感謝です
ご意見・ご感想、特に反対意見を持つ方、議論できると嬉しいです
「参考文献やサイト」
カンバン仕事術―チームではじめる見える化と改善
正しいものを正しく作る
Atlassian Agile coarh カンバン
Atlassian Agile coarh スクラム
「効果的なチームとは何か」を知る