ベンチャー情報システム部門は何に時間を使っているのか？
こんにちは、株式会社うるる 取締役の長屋です。
妻と子と猫と暮らしています。
猫と暮らし始めて早4年、こんなにも楽しく、そして飼いやすいとは驚きです。猫は自分勝手な所がいいですね。人間も自分勝手なのでお互い様だな〜と思いながら暮らしています。引き続きゴロゴロ言わせます。
当社の情報システム部門は、1人情シスとして発足した2015年から始まり、3年前には3名チーム、足もと5名チームへと段階的に組織化が進みました。
「そんなに人数が増えてやることあるのか？」
「ベンチャーで5名とかやりすぎじゃないのか？」
など、色々なご意見はあろうかと思いますが、そんな弊社の情報システムチームが「一体何に時間を使っているのか？」を本日は赤裸々にご紹介してみたいと思います。
情シスの仕事内容は、情シス以外の人には伝わりにくいですし、コスト部門なのであまり人数をかけたくないと思う人が多いのも事実です。
今回は、時間という共通の単位を利用することで、少しでも部門内外の相互理解に役立てれば嬉しいです。
作業毎の時間計測を開始した経緯
うるる情報システム部門のマネージャーKさんが入社されてから半年ほどたったある日、定例にて「業務棚卸の目的で時間の計測を行っていく」ことが発表されました。
Kさんの信条は見える化
・仕事をする上で見える化は必須。何をしたのか？ 説明できなくては、仕事と言えない
・上司や会社に説明する上でも、見える化は非常に便利
・作業記録や記録をまとめた手順は同僚を助けるし、属人化も防いでくれる
Kさんは「役員説得用にも使えて便利なんです（笑」と冗談交じりに発表していましたが、業務が見える化されれば改善に繋がり、ひいては企業成長に繋がるので、主張には全面的に賛成でした。
一方で、チームメンバーにとって「時間計測」という新たな手間が増えるのはネガティブではないか？ 「当人たちは面倒だと感じ、不平不満が出るかもしれない。納得性づくりが難しいと思いますよー」と意見したのを覚えています。
しなしながら、そんな私の懸念をよそに、上司力が高いKさんは上手く進めていくのです。自ら体を張って計測を率先することから始めることで。
設定した時間計測の目的
・業務量の多さを定量化する
・改善施策の効果測定を行う
時間計測と分析の方法
・記録には、時間の計測サービスを利用する (TimeCrowd)
・集計はCSVで行い、Google Spreadsheet 上で分析する
上司力の高いKさんらしい進め方
1. まず上司自らが時間を計測して、結果をシェアする
2. 賛同してくれる仲間を作るべく、まず1名だけが試験的に計測
3. 見える化されたデータを携えて、チーム全体で計測を開始する
いかにして時間計測を日常化したか
結果的に、時間計測はいつの間にか当たり前になります。
今では「年貢」と呼びながら、ふざけながら提出される日常です。毎週のようにログが積み上がり、チームのヘルスチェックが行われています。
実績、仮説、分析
運用開始から1年強、見える化が進んだ結果、時間の使い方に変化はあったのでしょうか？
結論から言えば「時間の使い方に大きな変化は無し」です。
上記グラフは、過去1年程度の業務従事比率ですが、パット見て増加傾向も減少傾向も認められません。グラフの形から分からないのであれば、相関は無さそうですが、仮説を元にもう少し分析を進めてみることにします。
仮説：社内対応が増えたら、タスク活動が減るのでは？
「社内対応 = 問い合わせなどの、社内スタッフ向けの対応」という定義です。情シスは日々問い合わせを受け対応していますので、「問い合わせが増え過ぎたらタスク消化に影響が出そう！」という仮説はまっさきに思い浮かびます。
相関関数での計算結果は、「非常に弱い負の相関 (-0.37)」を示していましたので、「現時点では相関が無い」と考えるのが妥当です。
とはいえ、負の相関側にあるのは事実なので、「社内対応（問い合わせ等）を効率化すると、タスクに割ける時間が増える可能性がありそう」と我々は捉えました。
仮説：障害対応がタスク活動に悪い影響？
「障害対応 = インシデント発生を受け、一次対応と復旧対応（再発防止を含まない）」です。障害が発生すると一時的に多くの時間が取られますので、他の業務活動に影響が出るのでは？と考えるのは自然なことでした。
計算結果は、「弱い負の相関 (-0.45)」を示しており、0.5 を越えると相関があると言われているので、相関までもう少しという所でしょうか。
「障害がそれなりに業務を圧迫していたんだねー」と会話をしています。
分析：どの業務従事比率の低下を目指すべきか？
日常的にスタッフの動きを見ながら感じている課題と、データは一致していましたので、我々は素直に以下2つに狙いを定めました。
社内対応
一定の割合を占め続け、会社規模の拡大とともに積み上がり続ける
規模拡大とともに、情シス増員を続けるのは辛すぎる
入退社対応
一定の割合を占めるとともに、繁忙期（4月向け対応の3月）が存在する
繰り返し作業が多いから、改善施策が立てやすいのでは？
「この答えデータ必要だったの？当たり前じゃない？」
と言われそうな結論ですね。皆さん日常的に感じてらっしゃるはず…
一方で、「データがあるということは判断が簡単になる」と理解していますので、決着のさせ方に我々は満足しています。あらためて「決断するより、判断材料（データ）を集めるほうが大変だ」というのが我々の感覚です。
改善に向けて
分析結果はごく当たり前のものでしたが、弊社ではもう1つ加味しなければならない背景がありました。それは、事業拡大に伴う従業員数の増加です。
過去3年間の従業員（パートタイマー、派遣社員を含む）推移は下記の状況で、過去3年間で 130名 >> 301名 に大きく増加しています。これは、年平均成長率 132 % の増加ペースです。
従業員数のハイペースな増加は、入退社が続くことが意味しますし、問い合わせ対応のどんどん肥大化していくことに懸念を感じます。
「どんどん人が増える、情シスもどんどん増える...。そんな未来は面白くない」と、Kさんと私はよく会話しています。
不用意に利益を圧迫することのない筋肉質で強い情シス、そんな「あるべき姿」が改善の方向性の中心になっていたのは、とても自然なことでした。
具体的な対策
分析結果を加味しながら、我々が実行中の施策を２つご紹介させていただきます。「もっと良い方法あるよ！」「過去試したけど...」などあれば、色々と教えてください。
社内対応（問い合わせ対応）の効率化
社内対応の主たる部分は「社内からの問い合わせ対応」です。
答えだけお伝えして解決するものもあれば、追加の対応が必要なものもあります。
例）
・Wi-Fiに繋がらない = Wi-Fi を Off >> On して様子を見てください
・PCの時刻が大幅に狂った = リモートログインして、調査させてください
マネージャーKさんが考えたのは、単純な問い合わせに対して「セルフ解決手段を提供していく」ということでした。
弊社では Slack 上に Bot 型の FAQ ツールを導入することで、解決を試みています。
進展中でまだ成果は見えませんが、明るい未来を目指して施策に取り組んでいます。導入詳細や結果は、折を見てまたご紹介させていただこうと思います。
入退社対応の効率化
入退社対応の中で、Kさんと私が着目したのは「入社対応」です。
手作業で、エンドポイントとSaaSアカウントの準備おこなっていましたが、その大部分は繰り返し作業です。「楽をするのは良いことだ」の精神全開でココを改善しようと決まりました。
サーバーの世界では、昨今 IaC (Infrastructure as Code) が流行しています。
かなり自動化が進み開発スピードが爆上がりしているのがシステム開発業界ですが、同じ波はエンドポイントやSaaSアカウントの管理にも来ています。この波に乗って、プロビジョニングを用いて自動化していきます。
具体的な対策は大きく2つです。
・Intune や Jamf を利用した、エンドポイントの自動キッティング
・IDaaS を利用した、SaaS アカウントの自動プロビジョニング
足もとはまだ構築中なので実戦投入はこれからですが、構築段階ですでに明るい未来をひしひしと感じています。魔法の様な世界がそこにあり、めちゃくちゃ設定が楽できそうです。成果がとてもとても楽しみです
まとめ
まだ具体的な成果は見えていないのが実情ですが、我々の学びは以下２つです。
・作業時間の計測は、当たり前にすれば、さほど辛いものではない
・作業毎の時間が見えれば、課題も見え、対策も立てられる
特に「作業時間の計測は、普通に当たり前にできる」は、私にとって目からウロコでした。Kさんすごいな〜。
これもある種のデータドリブン。
「時間的に余裕ができ、本当にやるべきことに集中できる未来」を目指して、チームは記録を続けてくれることでしょう！
この記事が気に入ったらサポートをしてみませんか？