運用保守チームで2018年5月からスクラムをやっていたが、12月でスクラムを終わりにしてカンバンに切り替えた話。
スクラム実施状況
以前の記事
運用保守チームでスクラムをやってみた話 - takusamarのブログ
このような感じでやっていたが、どうも上手く回せなかった。
問題点
運用保守という業務の特性上、どうしても緊急の割り込みが発生する。だいたい当日中か翌日までに対応しなければならない。
スプリントの途中で割り込みが入るのが当たり前になってしまい、スプリント計画を作る意味がない。
急ぎの作業はPOを通していたら間に合わず、顧客から開発チームに直接依頼がくる。
10年以上前の設計思想で作られた既存システムから新システムへの過渡期のため、使用している技術要素が多すぎる。
POが全ての作業内容を把握しきれず、開発チームへ丸投げになってしまう。
特定の担当者や特定の端末でしか実施できない作業があり、チーム全員で一気に作業することは難しい。
開発案件は他部署・他ベンダーと連携するため、各関係者と調整しながら進める形になる。
調整待ちのまま何週間も待たされることが多い。
1週間スプリント毎にリリース可能な成果物を作るのが難しい。
担当者2〜3名で（他の案件と掛け持ちしながら）数ヶ月かけて仕上げる、という開発形態になってしまう。
プロジェクト管理ツール（JIRA）を使いこなせない。
JIRAを見ながらミーティングしているとメンバが自分のPCばかりを見てしまう。同じ部屋にいるのに会話が少ない。
タスクが可視化できるので管理している気になるが、見た目だけきれいになっている感。
顧客がJIRAを見れないので報告用にRedmineも使っていて、二重管理が面倒くさい。
考察
スクラムが悪いわけではなく、現場の業務内容と合っていなかったのだと思う。 「スクラムをやってみたい」というノリで始めて失敗する典型例。
いったん「スクラム」を離れて、自分たちが何をしたいのか、どういう仕事の仕方をするのが一番良いのか、を改めて検討。 その結果、
各タスクがどういう状況かチーム・顧客と情報共有したい。
プロジェクト管理に工数をかけたくない。
チームメンバ同士の会話を増やしたい。
という点を満たしたい。それならカンバンが良さそうだよね、という結論に至った。
僕たちのカンバン
作業場所（顧客とチームメンバが入室可能）の壁に模造紙*1を貼る。
模造紙にステータス毎の欄を作る。
（空白）：顧客の要望や将来案など、ネタは出ているがまだ作業可能になってない。（Not Ready）
未着手：顧客から作業依頼が来たもの。これからやるべき作業。
着手中：担当者が作業中のもの。
確認中：顧客や他部署・他ベンダの確認中・問合せ中。
受入待ち：作業完了。顧客への月次報告待ち。
完了：作業完了。顧客への月次報告が済んだもの。
タスクを付箋紙に書く。
タスクは誰でも追加できる。POだけでなく開発チームや顧客も書いて良い。
業務毎に付箋紙の色を変える。
タスクの概要、納期（明確な場合）を書く。
作業状況に合わせて付箋紙を動かしていく。
ルールはこれだけ。なるべくシンプルに、アナログ重視でやってみた。
カンバンの効果
カンバンをやり始めて半月だが、仕事が進めやすくなったように感じている。
カンバンを前にしたデイリーミーティングで、今まで少なかったメンバ同士の会話が増えてきた。
壁に貼ってあるので、顧客にも状況が見えやすくなった。
タスクのステータス更新し忘れが減った（ような気がする）
ただ、カンバンではリアルタイムな状況を見ることはできるが、記録が残らない。 そのため、カンバンのタスクをRedmineのチケットとしても記入することにしている。 ここだけは二重管理をなってしまうが、致し方ない。 カンバンのステータス分類をRedmineと合わせたので、まだ転記しやすくなっているはず。
今後の課題
属人化の対策
担当者同士で少しずつ仕事を教え合ってもらいたい。会話が増えてくればそういう動きにも繋がると思う。
相対見積もり
スクラムで相対見積もりをやっていたので、カンバンでも相対見積もりは続けたい。 どのように書くか、どのように集計・計測するかは悩み中。
請負契約の取り扱い
準委任契約の作業は顧客と情報共有した方が仕事が上手くいくが、請負契約の場合はどこまで見せるかが難しい。
