創造開発部インフラグループの中西です。
普段はインフラエンジニアとして各メディアのインフラを管理しています。
最近はマネージャー業務に偏ってきており、試されるマネージャー2年目を迎えようとしています。
今回は、後回しにしがちな課題をいかに消化していくかについてお話出来ればと思います。
よろしくお願いします。
後回しの際によく見られる光景
- 直近のタスクとして行うほどではないので後回し。
- 緊急性が低く、かつ1人で行うと心が折れそうになるので後回し。
- 必要と言い切るほどでもないが、あれば便利なものを作りたい。しかし優先度的に後回し。
- 負債・・・！負債がぁーーー！
なるほど。これは辛い。我々は動かねばならない。
今こそ決起する時です。
具体的にはどのようなタスクなのか
現在の私達のグループで実際に普段話されている内容を一部共有したいと思います。
監視ツールを SaaS 化したので既存のものを捨てたい
- すでに監視ツール*1は存在していて、よほどのことがない限りは安定稼働しているが冗長性の観点から捨てるに捨てられない
あれば嬉しい plugin や業務ツールを作りたい
- 今の物理マシン管理ツールでも問題はないけど、使いにくい・・・
新入社員のアカウント発行を自動化したい
- 手動でやっても十分終わるけど入社人数が多い4月は辛いよね・・・
などなど、半期の目標には乗せてないけど片手間でやるにはちょっと時間掛かりすぎる。（あるいは単に面倒） だけど改善したい！どうすれば・・・！！みたいなタスク*2です。
我々は何故、後回しにするのか/なるのか
よく言われることですが、
- 動いてしまうから、使えてしまうから
- 人間が手でやればなんとかなってしまうから
ほとんどのケースがこれに該当するかと思います。
また、時間軸で考えることも可能かと思います。
短期的に問題がある場合
即改善
例：障害の種/売上毀損/業務がそもそも回らない
短期的には問題がない場合
先延ばし対象
例：古いけど動く/使いにくいけど使える
といったように短期的に問題がないケースは先延ばしされがちなものかと思います。
この他に、生み出される価値でも測ることができます。
改善すると目に見える価値が生まれる
- システムのパフォーマンス向上、開発者のデプロイがxx分早くなる など
改善しても価値が分かりにくい
- 業務上問題はないが誰も実態を知らない古代文明期に作られたシステムのリプレース(しかも元気に動いている)
余談ではありますが、負債っぽいニュアンスを出す時に忘れてはいけないことがあります。
「どんなに古いシステムであったとしても、どんなに汚いシステムであったとしても、どんなに汚いコードだったとしても、それらは間違いなく今までのリブセンスを支えてきたものであり、改善されることはあっても軽蔑されるべきものではない。お役目ご苦労さんという気持ちを我々は忘れてはいけない。」
この想いを忘れずに前へ進みたいですね。
いかにして課題を潰していくか
とは言え、このような気が重くなかなか価値が伝わりにくいタスクを1人でこなすのは精神衛生上良くないですし、任せる側にもかなりの辛みがあります。
弊社インフラグループではチーム勉強会/改善会と称して、隔週に1回業務改善会なるものを実施することに決めました。
実際の Confluence はこんな感じです。
ルールが2つあります。
- 勉強会が終わった時点で片付けたい課題がチームとして1つ終わっている状況を作る
- 1回の時間は3時間
以上2つです。
インフラグループは現在7名ですのでチームとして21時間です。 これだけの時間があれば、様々な取り組みが出来そうな感じがしてきます。
仮に1ヶ月23営業日あるとした場合7人のチームでの全体時間は、7 × 23 × 8 = 1288(時間) となります。 この勉強会は隔週開催のため1ヶ月2回と計算した場合、勉強会の時間は42時間です。 チームとして1ヶ月のうち3%~4% 程度の時間を使うこととなるため私はこの勉強会を 3% 勉強会と呼ぶことをこの記事を書いている今決めました。
気をつけるべきポイント
私達が気をつけているポイントですが、
- 事前に取り組む課題をチーム内で決めておく
- 明確なゴールを定めておく
- 当日の役割分担を決めておく
- 勉強会までに環境設定があれば行っておく
以上4つです。
事前準備がある時点で1人3時間を超えているじゃないか！というツッコミはご遠慮下さい（ぁ （現在の運用では私がザクっと決めてしまうことが多いです）
具体例の紹介
私達インフラグループでは毎月新入社員のアカウント発行を行っています。 具体的には以下のような作業となります。
- エンジニアへのLDAPアカウント発行(本番/開発)
- いくつかのサーバの .htaccess へユーザ追加
こう見ると至ってシンプルな作業で簡単な印象を受けますがこの業務の罠は「単純作業の繰り返しで辛い。」特に入社人数の多い4月ともなるとなかなかに悲惨です。
この事例は勉強会の趣旨にピッタリ当てはまった業務の1つです。
- 直近のタスクとして行うほどではないので後回し。
- 緊急性が低く、かつ1人で行うと心が折れそうになるので後回し。
まさにこの2つの項目に合致しています。
この業務を以下の方法で解決しました。
- 全て Ansible の Playbook へ落とし込む
1本道の簡単なもので終わればよかったのですが長年使ってきたものですのでそう簡単にはいきませんでした。
- 調べた結果サーバの環境が一部異なる
- 見ていくうちに想定より分岐が多くなることが分かってくる
などいくつかのイレギュラーもありましたが都度その場で話し合い、方針を決定していくことで1つずつ実装を進めました。
結果として、1回の勉強会では終わらず2回目に突入してしまったことは反省点です。が、十分にやる価値がありました。(4月に間に合いましたから...!!!）
何度か実施して見えてきた勉強会の課題とその解決
- 想定以上に課題が重たい（当初3時間で課題解決できるだろうと思っていたら6時間コースだった等（まさに上記例）
- 手を動かし続けられる人、その課題の前提知識が足りないために手が止まる人に分かれてしまう問題
- 解決するためのスキルを持ってる人と持っていない人問題
といった課題を感じることができました。 これらの課題を踏まえて以下のように改善を回しているところです。
- 3時間で終わりそうなネタに絞る（それ以上は規模が大きいと判断し、別途PJ発足の流れを作る）
- 事前準備、事前理解に時間を要するものは極力避ける（担当者を付けたほうが早いという判断から）
- 2チームに分けて、指導役をつける(プログラミングでいうところのペアプロ的なものをイメージしてください）
これによりズルズルと長引くことや手が止まって何も出来ない3時間を過ごす人を無くせるのではないかと期待しています。 副次的効果として業務の共有や認識の統一にも一役買っている印象を受けます。
ここまで実施してきた感想
まだ初めて 4~5回の会ではあるものの一定の手応えは感じています。 そもそもこの会自体が、以下のような声や思いから生まれたものでした。
「チームとしてのスキル底上げしていかなきゃね」
「この仕事実施頻度は少ないけど、いざやるとなるとげんなりするよね」
「xxxxxx（ツール名）は、いい加減なんとかしたい」
「ある程度の時間があれば直せるけど、片手間では厳しいなぁ」
などです。
そこである意味振り切った形で、業務に直結すれば業務時間中に改善勉強会できるじゃん！ と言い出したのが始まりでした。ここまで来れば後は私の判断1つでどちらに転ばせられるので 「よし、やろう」で動き始めました。
メンバーからは以下の声が上がっていました。
「全員でやるから気持ちが締まる」
「3時間で解決するという明確なゴール、イイね」
「知らないことを教えてもらえる意味でも有意義」
個人的な感想としては、「3時間で解決できると気持ちイイ！」これに尽きます。
さいごに
どの企業においても、中途半端な位置の課題はあると思います。
「今やるほどじゃないけど1年後には何とかしてたい」
「業務は問題なく回るけど、とにかく面倒くさいタスクがある」
「目標に乗せていないから手を出しづらいなぁ」
「改善しても数字は伸びないんだよなぁ」
私の少ない経験で語るのは恐縮ではありますが、こういった課題はズルズルと何年も引きずり続けるというのが実のところだと思います。
各企業、各チームの文化や方針があり課題をどう捉えるかは様々ですが、私達インフラグループはこのような戦い方をしているという記事でした。
どこかの誰かの開発/運用エンジニアの皆様へ「こういうやり方もあるんだなぁ」程度に感じて頂ければ幸いです。
ありがとうございました！
