(所要時間 : 約3〜4分)
先日のエントリでリモートワーク主体に切り替えることついて書きました。4月は取り組みを更に加速させ、21営業日中の10日をリモート日としました。47%なのでほぼ半分のリモート率です。
変化が急過ぎるかなと思いましたが、やってみると全然問題なく仕事はまわってます。むしろまだリモート率上げられるなという感じなので近々逆転させる予定。思ったより速くリモート主体に移行できそうです。
(Thanks! the photo on flickr by Citrix Online / CC BY-NC-ND 2.0)
特別な準備もなくリモート主体に転換できてる訳ですが、要(かなめ)になってるのはチケット管理(タスク管理)を徹底してることにあると感じてます。チケット管理しっかりできてるな〜という実感がある会社は、すぐにでもリモートメインに切り替えれるんじゃないでしょうか。
今回は、急なリモート主体への切り替えに耐えれている、弊社のチケット管理について少し書いてみようと思います。主に、マネジメント側の不安についてです。
弊社のチケット管理
チケット管理、タスク管理、TODO管理、バグ管理….色々と呼び方はありますが、やらなくちゃいけないことを管理するシステムは、自分が雇われエンジニアだった時から結構触ってきました。
- Bugzilla
- Excel
- 影舞
- Google Spread Sheet
- Redmine
- Backlog
- Trac
- Trello
- JIRA
- GitHub Issue
懐かしいものもちらほらありますね。弊社のチケット管理の歴史はシンプルで、
| 時期 | ツール | 適用範囲 |
|---|---|---|
| 2006年〜2010年 | Trac | 社内案件 |
| 2010年〜 | Redmine | 社内案件 |
| 2011年〜 | Backlog | 社外パートナーが絡む案件 |
って感じです。10年以上前からチケット管理をやってますので、結構早い頃から社内タスクの見える化ができてたのではないかなと。
今でもまだ運用の仕方に洗練の余地がありますが、チケット管理の徹底が、リモートワークあるあるの「誰が何をやってるか分からない」というマネジメント側の不安を解消しているなと感じてます。
マネジメント側と言っても弊社の規模だと社長である僕だけですが(笑)、まぁ不安は皆無と言って良いです。信頼関係もありますが、チケットに情報が集約されてることが不安の解消に寄与しているのは間違いありません。
(Thanks! the photo on flickr by Pete Tschudy / CC BY-NC-ND 2.0)
全ての仕事はチケットに紐付く
弊社内でのチケット管理ルールは、
- 業務時間中の作業が常にチケットに紐付いていること
- チケットに記録をできるだけ細かく残すこと
の2点。一日の終わりに「◯◯さん、今日は何をして、その状況はどんな感じ？」と尋ねた時に、◯◯番のチケットです。というやりとりだけで基本済むようになってます。チケットに紐付かない仕事はありません。(社外の方とやりとりするBacklogはここまで…ではありません)
実際、弊社では一日の終わりに slack で日報投稿するようにしてますが、だいたいこんな感じになります。
f#XXXXXと書いてる番号がチケット番号。自動的に対応するURLを投稿するhubotが稼働してますので、チケット詳細がワンクリックですぐ見れるようになってます。
slackで一日単位のタスクの動きが把握できるほか、プロジェクト全体のフィードを見てれば、
(モザイクでほとんど何書いてるか分かりませんが…笑)
誰がどのタスクを終えたのか、日中でもどんどん情報が集まってくるようになっています。ってチケット管理に慣れてる方なら当たり前だと思いますので、どちらかというとチケットの種類や中身のほうに特徴があるかもです。
チケットに時系列の記録を細かく残す
弊社がTrelloやカンバン方式をメインにしない理由でもあるんですが、時間軸の記録を結構大事にしてます。時系列に、何した、あれした、どうなった…と結構細かくチケットに書くんですね。
ちょっと極端な例ですが、一例をあげるとこんな感じ。「KUSANAGI for さくらVPSへの移行」というWordPress環境の引越し作業のタスクです。
だいぶ長いですね。印刷するとA4で10ページぐらいになります。
Redmineをご存じの方は見慣れた画面ですが、最上部の黄色いところがタスクの内容、その後に時系列コメントが並びます。移行作業で、サーバで何をしたのか、設定ファイルをどう変えたのか、パフォーマンスはどうなったか等など、ガンガン書いていきます。
会社によっては「もっとチケットを分割すべきだ」となりますが、このタスクについては最小粒度です。「公開鍵を置く」「NGiNXを設定する」「KUSANAGIのプロビジョンを設定する」「MariaDBの設定をする」「DBにdumpをimportする」てな感じまで分割するのかって話なので、そこまでは必要なかろうと。
ま、そのへんは臨機応変に僕がチケット分けて〜と言ったり僕が分けちゃう場合もあります。あと、設定情報等は別途wikiに転記して整理するとか、gitのコミットが連動しているとか、＋αな連携もさせてます。
他には、こんなチケットもありますね。「◎◎様に提案する為の Dropbox Business Advanced についての調査」という題目。これはちょっと短め。
商流をどうするか、販社はどこを使うか、パートナー制度の調査情報などガンガン書きます。これは僕が担当したタスク。コメントは5,6個ですかね。
この種の情報は、ひょっとしたらSFA(営業支援)やCRM(顧客管理)の範疇かも知れません。が、弊社では、何らかのタスクであって時系列つまり事の経過が重要なものは全部 Redmine や Backlog に集約してます。情報は一つのシステムに集約されてる方が良いですから。
ここまで書くのはちょっと…という方もいます。正直面倒かも知れません。でも、会社の生産性って突き詰めると、情報共有のスピードや共通認識の形成スピードなので、生産性を求める僕的には譲れないところなんですよね。そうじゃないと残業ゼロを促進できません。
だから、なるべく多くの情報を非同期的に共有できるよう、チケット管理システムを使ってガンガン書くことを是としています。あ、別にチケットの更新頻度が査定に関係する…みたいなことはしてないです。
一見面倒に見えるんですけど、社内で「共有」とか「報告」の名の下に開かれる会議や書類作成の無駄に比べたら楽なもんです。エンジニア的には、コマンドやその標準出力、設定ファイルの一部をコピペして見解を書く、とか、gitのリポジトリのコミットログが連動しててそれだけで済む場合もありますから。
(Thanks! the photo on flickr by kiwamuk / CC CC-BY 2.0)
チケットに記録が集約されることのメリット
既に前述してるものもありますが、
- 報告のための会議や書類作成に要する無駄な時間を無くせる
- 過去を遡れるので、有事の時の思い起こしコストが最小化できる
- 誰が何をやっていてどこまで進捗しているか具体的に分かるので管理側は安心できる
あたりでしょうか。
チケットに書く記録の粒度は人にもよりますし、一挙手一投足を捉えられる訳ではない(それはそもそも必要ない)ので、情報共有具合が常に100%って訳じゃないです。体感でせいぜい90%ぐらいでしょうか。
だから不足分は必要に応じて顔を合わせた会話で補います。その場合でも、関係者がチケットを事前確認して現状共有した状態で会議を始めますから、濃密かつ所要時間を最小化した会議運営ができる訳ですね。
記録を残す負荷が余りに高いと組織の生産性が落ちますが、適度に記録を残す癖は組織の生産性を確実に上げます。無駄を無くせるという意味で。
(Thanks! the photo on flickr by Citrix Online / CC BY-NC-ND 2.0)
という訳で、チケット管理のついて書いてみました。冒頭の話に戻りますが、誰が何をやっていて今どういう状況なのかが分かるから、リモート主体にいきなり切り替えても何も困らなかったのでしょうね。
もちろん、弊社の場合は人数が極めて少ないってのも理由の一つです。でも、人数が少ないからと言って、誰が何をしてるか分からない、何をしたら良いのか分からない、という不安が無くなる訳ではありません。なので、人数や会社の規模はリモートワークを採用できない理由にはならないだろうなと今は思います。
チケット管理の徹底が、労使双方にとって不安の解消に寄与するのは間違いないです。リモート主体にするかどうかは別にして。何をすべきかチケットで把握でき、何をしているかがチケットで分かるからですね。チケット管理は奥が深いのでまた書いてみたいと思います。