IT業務効率化

エンジニアのための時間管理術を新卒の運用・ヘルプデスク担当が読んで【前編】

エンジニアのための時間管理術

割り込みの害悪

割り込みは自分が思っているよりも集中を阻害している。本書では不可侵条約ということで、隣のエンジニアと条約を結び、交代制で問い合わせ窓口を引き受けることを勧めています。

私の運用・ヘルプデスク業務に置き換えてみるとどうでしょう。結構みんな当たり前の様に席まで話しかけてきたり、チャットツールでメンションを飛ばしてきます。みんな悪気はないし、緊急度をうまく伝えられない時もあるし、お願いしていることの難易度が高いか低いかなんてわからないです。

誰も悪くないかもしれないです。しかし、私の集中力は切れます。

割り込みがあると、元の作業に戻った時に、どこから始めるか確認するために時間を浪費してしまう、とあります。これはしおりを挟まずに本を置いてしまうことと同じ様なことだと感じました。本をどこまで読んだか覚えているつもりでも、思ったより割り込み作業が重たく、戻ってきた頃には忘れてしまいます。

どうやって対策をするべきか、いくつか考えてみました。

  • まずは依頼経路を集約する。弊社はBacklogという課題管理ツールを使っているので、ここに集める。メールの見落としや、個人にくるDMを少しでも減らす。
  • 緊急の時以外はDMは控える様にお願いする。
  • 1日の9時12時16時しか課題管理表を確認しないことをルール化する。
  • 過去の課題チケットを検索してから依頼してもらう様にお願いして、以来の母数を減らす。

実際にメッセージが来たとしても、しばらく放っておいてもいい内容は少なくないです。人間関係的によくないのかもしれませんが、スムーズに仕事を回していく上では、無視することも大切です。でもそのメッセージの中に、時々緊急の内容が混じっているから困ります。そんな時は本書の不可侵条約がやはり役に立つでしょう。

問い合わせしてくる人はどうしたら満足するか

運用・ヘルプデスクにはありとあらゆる依頼が毎日の様にきます。

このステータスの顧客データが欲しいんだけど、webページが真っ白だ、エクセルのマクロが動かない、アプリのボタンが反応しない、それ俺じゃないから!と思う様なこともしょっちゅうです。

やろうと決めていた仕事が一切進まないので、ついつい追い返したくなります。

そんな時本書はとても有効な答えを示してくれました。

彼らは解決することよりも、話を聞いてもらうことを大切にしているのです。

確かに私の経験からしてもそうです。うまく言った事例をいくつか思い出してみます。

  • 要件よりも企画の内容を聞くことから始め、共感する。
  • 断りたい時は、より良い改善案を示し、もっとよくしていきたいから時間をください。という話にする。(仕事量よりも時間が増える様に)

あとは必殺の枕詞です。

  • その仕事めっちゃやりたいんだけど〜
  • 僕も同じ気持ちなのですが、どうしても時間が・・・
  • 一緒に良くしていきたいので、もうちょっと待ってください。

この辺り言っておくと、なんとか回避できます。

 サイクルシステムの疑問

本書ではサイクルシステムという名前で、日々の業務を管理する術を紹介していました。

その中で自身のキャパを超える量のタスクの取り扱いについて述べています。

  • 優先順位の低い仕事を翌日に回す
  • 推定所要時間を多めに見積もる
  • 委任する
  • 上司の優先順位について相談する

などなど、しかしこれらを実践しても、私のタスクは積もっていくばかりです。

なぜ積もっていくのか考えた時に、2つ理由がありました。

  1. シンプルにチームの人数が足りていない
  2. 改善業務が業務として意識されておらず、それに時間を割けない。

1番はいいとして、今後2番の課題を解決していきたいと思っています。人のやる様なことではない手作業や、ドキュメント化されていないがために、ソーソコードの調査が必要になったりと、最悪の効率で日々の業務が回っています。しかし、ドキュメントを書くよりも次の仕事が重要視され、声の大きな人のお願いに振り回されます。

そのために、業務改善されていないことで、どのくらいの時間の損失があるか、もっと示す必要があります。

本当はもっと環境が整っていれば、〇〇時間短縮されたのに、こんなに時間がかかってしまった。

これを今後は示して、業務改善を含めた仕事をしていける様な環境整備を目指したいです。

上司のマネジメントという視点

本書ではマネジメントは一方通行ではなく、相互の関係だと述べています。

上司をマネジメントする必要があるし、上司に助けて欲しければ上司を助けることを考えなくてはいけないという思想です。

上司に指示を出したりすることではありません。例えば自身のキャリアプランを伝えて、業務との折り合いをつけてどのように貢献していくか探っていく、こう言ったことも含まれます。

私はこの辺りがまだ出来ていません。日々の業務に追われ、自身のキャリアプランとは離れた領域で働いています。まずは自分のキャリアプランを伝えて仕事を見直すことから始めようと思います。

また、上司の目標を改めて意識してみます。

  • 業務を改善し、人的コストを減らしたい。
  • 障害を減らしたい。
  • 問い合わせの母数を減らしたい。
  • 人の入れ替わりに柔軟に対応できる様、チームのナレッジを蓄積したい。

これはまだイメージです。実際に上司に聞いてみることが一番良さそうです。上司の目的意識と自分の目的意識を合わせることで、より良い連携が生まれる様にすり合わせの機会を大切にしていきたいです。

メールの捌き方を課題管理ソフトに応用する

本書ではメールの取り扱いに関して、1章分使って記載されていました。削除する前に返信しておく必要性、フィルタを上手に使って対応する方法などとても参考になるものが多くありました。

弊社は今Backlogという課題管理ソフトを利用しているので、こちらで全ての案件を請け負っています。メールに比べて利点は多くあるものの、それでもメールと同様の困りごとがあります。

それは課題の分別です。

BacklogのプロジェクトにIT問い合わせ窓口というプロジェクトがあります。さらにインフラ、ヘルプデスク、障害、ログの調査などいくつかの項目に分かれます。

しかし非エンジニアからしたら見分けがつきません。時々担当領域を超えた依頼が、誤った担当部署に登録されることがあります。また、ITに任せるべき範囲を間違えているパターンもあります。外部の会社のシステムに依存しているバグなので、社内SEにはわからないこともあります。プロジェクトに適した依頼ばかりが来るとは限らず、しかしないがしろにするわけにもいきません。これらを課題管理ソフトを用いてうまく仕分けする必要があります。

仕分けのために最近必要性を感じている項目が以下です。

  • いつまでに終わらせて欲しいのか
  • 本当にITで担当するべき内容か(無視しても大丈夫か)
  • 5分で終わるのか2時間で終わるのか1日以上かかるのか
  • その問い合わせに対応することは、ITの目標に含まれているのか

これらを意識して、課題を切り分けていくと、対応の優先順位もつけやすく、抜け漏れなく対応できると考えています。メールと同様にフィルタリングをするためのステータスを追加し、かだを切り分けていこうと思います。

後半に続きます。

ABOUT ME
hirayuki
今年で社会人3年目になります。 日々体当たりで仕事を覚えています。 テーマはIT・教育です。 少しでも技術に親しんでもらえるよう、noteで4コマ漫画も書いています。 https://note.mu/hirayuki