非開発チームにてアジャイルライクなタスク可視化をやってみた話をしてきた
DevLoveというコミュニテイ−にて、登壇をしてきました。
『社内でアジャイルと出会った新卒2年目がインフラ部隊でタスク可視化をやってみた話』
- 私の仕事のフィールドであるインフラいついて
- アジャイルいいじゃんって思うようになった社内教育について
- 自チームでカンバンを元にやってみた方法・知見について
お話しをしてきました。
インフラチームとアジャイルを結びつけてみた成果として、より色んな方の目に止まればと思って、そのあたりについて文章に書き下ろしていきます。
やってみる前の話
課題感・動機
- チーム全員がやるタスクの範囲が広い(運用、保守、構築、開発)
- 人数の増加
- 取り扱う機種の増加
この三つを理由に、今までのふんわりとした(ルール化してない)ままのチーム運営では情報共有が不十分であり、タスク消化が停滞する傾向にありました。
方法の模索と決定
アジャイル開発手法を真似てみたいと思っていましたが、当初の私はスクラムしか知らず、スクラムをそのまま使うことにはかなり抵抗がありました。
というのも、スクラムは役割・イベント(セレモニー)・目的がかなり強固なフレームワークであり、取り入れる際の学習コストと自チームで完結しない(スクラムマスターがチームメンバーと兼任するのはアンチパターン)点に大きなデメリットを感じていました。
そんな中、とある勉強会でカンバン開発手法というものに出会いました。
スクラムと比較し、
という点を気に入り、また勉強会にて非開発チームにて導入した事例を共有いただいたことで実行可能である判断ができました。
やってみたときの話
キックオフ
勉強会の1週間後にキックオフをしました。
カンバン開発手法はどのようなもので、チーム・個人・上司にそれぞれどのようなメリットがあるかを整理し話しました。
その後
- ワークフローの検討・決定
- 付箋に書き込む情報のルール化
- 朝会・振り返りの頻度の決定
と進んでいきました。
ポイントとしては、アジャイル的なノリを伝えることです。
インフラ畑に長いこといるベテランの方は、「とりあえずやってみる」、「やっていきながら改善する」といった文脈が伝わりづらく苦労しました。ルール・規則・仕様ありきの動きではない旨を伝え、いつでも改善するチャンスはあるというメッセージを添えました。
朝会と振り返り
頻度と所要時間として、朝会は週2回で各15分、振り返りは週1回15分と決めました。
朝回を毎日行わないのは、変化のスピードを考えた結果です。
開発チームと比較して変化・成果が1日で出づらい(他人マターであったり、申請が必要)ことから、毎日の朝回は過剰であると判断しました。また、変化のない朝回は停滞感を産んでしまうのではという懸念もあったためです。
振り返りの時間が15分だけというのは、可能なら避けたほうがいいと思います。実際、半年後には月1で1時間に変更しました。
週1で15分とした理由として、カンバンを模したやり方の改善は、初期段階できっとたくさんあるだろう。であれば、ジャストアイデアでも頻度が多く修正ができるように、という意図でした。
やってみた後の話
チームへの変化
資料にも書きましたが、チームメンバーへヒアリングをしたところ、
- 業務効率の良い変化
- リスクの早期発見
- ボトルネックの明確化
- 優先タスクの明確化
- メンバーが何をやっているか分かるよう になった
という変化を感じてくれたようです。
特に評判が良かったのは、「リスクの早期発見」でした。若手勢の勘違いにベテラン勢が気づく場面、ベテラン勢が失念していた最近のルール変更への説明を若手勢がする場面が見られました。
一方でデメリットとして上がった意見は、
- リモートワークに向いていない
- 人数が揃わないとき(出張や深夜メンテ明け)に決定がなされてしまう
- ボードが物理管理なので変更がしづらい
などがありました。とはいえ、全体としてはメリットが大きく継続したいという意思でした。
最後に
インフラ業界として考えると、アジャイルと相性が良くないとも理解しています。特に、納期があり仕様がきっちり策定されており、期間とお金が決まっているタイプのインフラだと尚の事です。
しかし、サービスと一体となった構築・運用・保守ができるよう、変化に富んだ環境を良しとする土壌のインフラ部隊であるなら、新たなチーム運営の方法を考えてゆくことは正しいと信じています。
その中の施策として、今回のようなアジャイル・カンバンとうキーワードから試行錯誤してみた知見が皆さんの助けになれば幸いです。