読者です 読者をやめる 読者になる 読者になる

ジンジニアニッキ!

とあるITベンチャーで、人事だけど開発環境もってた人のニッキ

業務改善のために取り組んだことと沼からの脱出方法について

たまにはジンジニアっぽいことを書いてみようかなと。

2016年の4月に現職に入社したのですが、入社して一番びっくりしたことは、足元の業務が思いっきりカオスだったことでした。

カオスな状況

  • Googleドライブの管理がエリアスではなくすべて個人で権限がついており、入社しても必要なデータがすぐに見れない
    • というか、部署や業務として必要なデータがフォルダにまとめられておらず、個人で管理されている
    • 同じ名前のファイルが複数あり、どれが最新なのかも不明
  • そもそも使われていない、あるいは存在すら忘れられているメーリングリストがある
  • 現在進行形で使われているメーリングリストに、(過去の経緯から)現在は不要な人が入っている
  • 必要な書類がデータで管理されておらず、紙で保管
    • その紙も、コピーのコピーのコピー、という状態のままで管理されており、印刷が歪んでいたり変な斑点が入っている状態のものを利用せざるを得ない
  • マニュアルやドキュメントが存在せず、何が正しい業務フローなのか不明
    • ついでに言うと、ミーティングの議事録も存在していなかったので「言った/言ってない」「聞いていなかった」などなどの状況も発生
  • 人事管理システムの運用がうまくなされておらず、システムに入っているデータが本当に正しいのかどうかが分からない
    • そして、データのエビデンスを参照しようとしても、元データが保存されているはずのGoogleドライブが前述の通りなので、探すに探せない
  • いろんな書類やらフローやらがアナログのままになっている

ということで、ひとつのファイルを探すだけで丸一日かかるとか、手戻りがあるとか、逐一車輪の再発明をしたりとか、過去の経緯を記憶の彼方から引っ張り出してもらったりとか、そういうことをやらざるを得なかったのでした。


なんでそんなことになっていたのか

これは急激に変化した/成長した会社によくあることだと思うのですが、一般論として。


人事やバックオフィスの業務って、社員数が少なく、ビジネスもまだ大きくないうちは手作業でできちゃうんですよね。
システムを導入するよりはエクセルで管理したほうが、費用面でも工数面でもコストが低いです。
特にバックオフィスは「コスト部門」なので、システム導入にあたってはハードルがある場合も多いかと思います。
小さい会社だと一人で業務を担当していることも多いですし。


そうやって担当者の個人に紐づく形でやってきた業務が、社員数が一気に増えると全部崩壊しちゃいます。
少ない人数のうちは一人ひとりの顔と名前とそれぞれのステイタスが一致していたし、目視でデータを確認しても30-50人分くらいのものであればすぐに目を通せてミスもすぐに発見できたことでしょう。
ところが、人数が増えてくるとバックオフィスの人員を補充したり、システムを導入したりというのが始まります。


会社が急激に変化しているので、そこについていけない人や変化後の会社の状況に合わなかった人は辞めていったりします。
これまでのアナログなやり方では限界がきてしまい、方法を変えていかなければいけません。
そして、秘伝のたれをずーーーーっと温めていた人事担当者が辞めたとき、そしてたれの製造法が正しく伝授されなかったとき、カオスが起きます。


…という一般論なことがまさしく弊社でも起きていたんですね。
長年ずっと担当していた人事の人が退職し、それだけで済んでいたらよかったのですが、その後、短期間の間に担当者が次々と変わっていき、それぞれのやりかたで業務がスクラップビルドされ、短期間なのでそのスクラップビルドも不完全なままで次の人に引き継がれ、その引き継ぎもきちんとされていたわけではなく…。


ということが積み重なって、前述のカオスになっていたようでした。


やったことは、とにかく小さいことの積み重ね

ここまでカオスな状況だと、より成果を上げていくために頭を使うような業務に時間を割くことはできません。
なので、まずは少しでも今のルーティンワークにかかる時間を削減し、頭を使って仕事をする時間を確保するということを考えました。
なんせ、業務に圧迫されて息ができないような状況ですし、それでも新しいタスク(例えば、新しい採用や新しい入社者の対応)があるのでさらに息をするスペースがなくなっていきます。
根本的にフローを見直したり、フローの概念から考え直すことも必要なのだとは認識していましたが、そんな概念的なことを言ってられるような余裕がなかったので…。


具体的にやったこととしては、以下の感じ。

  • 同じチームの人にGoogleDriveの基本的な使い方、機能、概念をレクチャーする
    • ちなみに、PCのデスクトップ上に存在している状態のファイルとクラウド上にあるファイルとの違い(自分以外の人に共有できているかとか、会社PC以外でもファイルを編集するためにはどこに保存しなければいけないのかとかそういうこと)あたりから説明しました
    • 自分としては衝撃でしたが、世の中のバックオフィスの人ってこのくらいのITリテラシーなんだなということと、そりゃ、人事もプログラミングやろうぜ!で乗ってくる人少ない少ないなと思いました
    • その後はきちんと活用できているので、最初に丁寧に教える/使い方を知ることが肝心という学びにもなりました
  • 会議の議事録を残す
    • 最初はSlackにPostしていましたが、ドキュメントのシステムを導入したタイミングでシステムに移管しました
  • 手元のフォーマットを改善する
    • 入力を少なくするようにプルダウンにしたり、部署名などわりと変更があるものについてはマスターデータ化したりなど
  • 権限が大丈夫な範囲内で、社内システムの管理者権限をもらう
    • ワークフローなど、システムに載せることができそうなものは載せていく
  • ルーティンワークや作業について引き継いだ(あるいは説明を受けた)際には自分だけのメモにせず、マニュアルを作成する
    • 最初なGoogle Documentでやってたけど、いろいろ編集とかやりにくかったのでドキュメントのシステムを入れました
  • メーリングリストを整理できる範囲で整理する
    • あまりに膨大すぎて全部は無理だったけど、いらないメーリングリストを20個以上なくしました
  • ドキュメントのシステムを導入したタイミングで、手元のルーティンワークをマニュアルにし、業務を可視化(できる範囲で)
    • いろいろ検討してみた結果、今のところKibelaというやつを使ってみています
  • 元ファイルを見つけ出す
    • これが一番時間かかった…
  • 今すぐには改善できないことや実はあまり意味のなさそうな改善案については「これをやらない」あるいは「もっと後に先送りする」ということを決める
    • 何かをやるだけではなく、やらないことを決めるということもとても大事だと思いました

少しでも前進するための工夫と「沼」について

上記のことは一気にできたわけではなくて、半年くらい(かな?)をかけて徐々にやったことです。
当然のことですが、こういった業務改善だけが仕事というわけにはいきませんでした。なんせ、バックオフィスの人数が余っているような組織ではないので…。


日々のその他のタスクがある中で少しでも前進するために工夫していたことは、
①シリアスにしすぎないこと
②タスクの粒度を小さくすること
③進捗を可視化すること

でした。

シリアスにしすぎないこと

テキストにしてみて改めて思ったのですが、結構ひどい状況ですよね…。
それを「ひどい」「やってられない」「嫌だ」と表現することはできますし、事実として自分自身としてもそう思っていたのですが、ネガティブな言葉を遣いすぎたりすると他責になりがちなのと、より気がめいっていくばかりであまり良い方向に働かないなと思ったのでした。
なので、あのひどい状況のことを総称して「沼」と呼ぶことにして、それを少しずつ改善する/したことを「沼を退治する」とか「沼が浄化された」とか、思ったよりタスクが小さかった/大きかったことを「沼じゃなくて水たまりだった!」とか「水たまりかと思ったら底なし沼だった!」とか、そんな感じのちょっとふざけた言葉で表現していました。

小手先のことかもしれないですし、そういった表現をすること自体が根本解決になるわけではないのですが、なんとなく気持ちが軽くなり、ちょっと楽しげな雰囲気になったように思います。

タスクの粒度を小さくすること

「業務改善をする」といったような大きなテーマを設定した際にやりがちなのが、「そもそも業務改善とは」といったような大きな概念や目標を設定しにいったり、そのためのロードマップやマイルストーンをかっちりひいたり、そういった目標設定やロードマップに時間をかけて実際の改善に取り組むのは壮大な絵が描けてから…といったことかなと思います。

広く「業務改善」というプロジェクトことに取り組む場合、目標設定やロードマップも大事です。プロジェクトなので。

ただ今回の場合は「プロジェクト」という感じよりは「あまりにも苦しすぎて息ができず、このままでは酸欠で死んでしまうので、まずは今よりも息ができるような状況を作り出したい」ということがメインであって、大きな絵を描くのであればそれば息ができるようになってからと思っていました。

なので、大きな絵のタスクを設定するのではなく、大きなタスクは今すぐできるようなタスクにできるだけ小さくして、それを一つ一つなくしていくことを考えました。
こうすることによって、業務の合間のちょっと余裕ができた時間にすこしずつタスクに取り組めるようにもなりました。

進捗を可視化すること

実際に取り組んだことって一つ一つは些細なことなので、今取り組んでいる泥沼がどのくらい改善されたのか分からず、そして少しも前進していないように見えてしまって「この小さな改善に意味はあるのか」とかそういうことを感じてしまうんですよね。

なので、①上記で細分化したタスクはポストイットに書き出す ②それを沼ゾーンに貼る ③タスクをこなしたら、浄化されたゾーンに移動する ということをやっていました。
アナログのカンバンですね。
また、可視化することによって自分以外の人ともチームで改善に取り組むことができるようになりました。

タスクの振り返りについては特に期限を設定して見直しをしていた訳ではないのですが、3ヵ月に1回くらい見直していました。
自分の場合は、その他の業務量との兼ね合いでそのくらいのスパンが最適だったなと思います。

見直しをすると、「あら、意外と前進してるじゃない!」とリアルに見えて、なんだかうれしくなったりできました。

ということで、半年くらい運用したものがこちら。詳しいタスクの内容はお見せできないのですが…。
f:id:mameco0417:20170117131145j:plain


沼のタスクは似たような感じのテーマやらタスクをグルーピング化したりなどしてました。
少し大きめのテーマ的なタスクもあります。

前よりは息ができるようになったので、今後はもう少し粒度の大きなタスクも取り組めるようになりそうな気がしています。
(また、チームでタスクの洗い出しからやることになると思います。)

やってみてよかったこと

とにかく、気持ちがすっきりします。
また、自分は(人事という職種ではあるのですが)システムを触るとかそういう作業が好きなので、目の前の沼にムカつきながらも実はちょっと楽しくやっている部分もありました。

今回書いた事例は、わりと極端な例だとは思うのですが、バックオフィスとかルーティンワークの現場って、実はどこも似たりよったりな状況なのかなと思ったりするので、何か参考になることとかあればと思います。