ケーススタディ：ITエンジニアが業務効率化の依頼を受けた時注意すること
ITエンジニアの業務は、アイディアを形にして世の中に広めるという、いってしまえば世の中一般的に認知が取れている内容（いわゆる新規サービスや新規アプリの開発）のほか、多くは日が当たることは少ないものの絶大な効果を発揮する「業務効率化」というものもありあす。 聞きなれない人向けになりますが、業務効率化とは
- 既存の業務の作業時間を短くする
- ある人しかできない仕事をなくす（属人化をなくす）
- ミスしがちな仕事をサポートする
といった内容になります。
実際に業務効率化をITで進める際に、どうすすめればいいのか、自分の経験をもとにケースステディにしてみました。
対象読者
下記の読者を想定しています。 想定読者は、実際に仕事をうけるエンジニアです。具体的には、
- いつも仕様の抜け漏れがあって見積より多く時間がかかる
- つくったものの結局つかわれない、いまいち効果が発揮されない
といった方です。
注意事項
エンジニアにお仕事の効率化をお願いする立場の人にとっては、うるさいなーとか、めんどくさいなーとか思うかもしれません。 しかし、きちんと要件を伝えることでエンジニアはあなたの仕事を助けてくれます。 エンジニアが何を考えて、どう行動しているのか少しでもわかっていただければ幸いです。
ただし、聞くだけ聞いて何もしなかったり、非協力的なエンジニアは用無しです。 何か理屈をつけて、一緒に仕事をしないように仕向けましょう。
ケーススタディ
状況設定
あなたは、ITエンジニアです。社内の営業メンバーから次のような依頼を受けました。どのように進めたらよいでしょうか？
依頼内容
・営業現場で顧客リストとアプローチ内容、アプローチした結果を共有し、営業作業の効率化をしたい
さぁ、非常にざっくりとした相談です。このまま「はい、わかりました。それでは…」と進めていっては、うまくいかないことは火を見るよりも明らかです。 さてどのように進めていったらよいでしょうか。
基本的な質問
まずは、基本的な質問からです。 なぜ、こういった質問をするのでしょうか？それは、発注者も実は要件や本当にしたいことが煮詰まっていない場合があるからです。 基本的といっても、本質的な質問でもあります。
一つ一つみていきましょう。
今、どういう仕事をしていますか。
相手のことを知るのが１番重要ではないか、と個人的には思っています。 業務改善であれば、業務フローを把握し、かけるくらいまで聞きこみが必要ではないでしょうか。
それ本当に必要ですか？？？
今回の要件は、「営業現場で顧客リストとアプローチ内容、アプローチした結果を共有し、営業作業の効率化をしたい」というものです。 果たして、どれくらい困っているのでしょうか。また、どれくらいみんなが欲しているのでしょうか。さらにいえば、本当に情報を共有するだけで効率化がされるのでしょうか、他に方法はないのでしょうか。 色々と考えることはあります。 しっかり聞いてみましょう。 中には、上司の命令だっただけ、と言ったケースもあります。
前提を疑え
今回の仕事は、共有さえすればうまくいくという前提があります。本当にそうでしょうか？確認しましょう。 共有してもみないかもしれません、共有しても実践しないかもしれません、ターゲットとなるクライアントが違いすぎてノウハウの共有ができないかもしれません。 本当に、共有すればうまくいくのか、じっくり吟味しましょう。
なぜ既存の仕組みがうまくいっていなのですか？？？
- 本当に必要ですか？
- 前提を疑え！
に近いのですが、今の仕事方法がきちんと分析されているか確認しましょう。 共有がうまく言っていない理由は、
- システム、ないしはExcelへの入力が手入力。忙しくて入力してくれない
- フォームが煩雑（あるいは全て自由フォーム）で、入力がばらつく
といったものがあるかもしれません。
つっこんだ質問
必要なのがわかったら、もう少し突っ込んだ質問をしましょう。 実は、あまり効果がないのかもしれませんよ。
定量化：どれくらいの人がつかうの？？？どれくらいの顧客リストなの？？？
誰もが納得できることはあまりありません。 1つ1つの改善数が多ければ、分量が多ければ改善効果は高まります。反対に、改善数が少なくとも、１つ１つの効果が莫大であれば、結局は改善効果は高いといえます。
きちんと数値で把握しましょう。 たとえば、こういった内容です。
- お客さんの全数は？
- 一ヶ月のどれくらい増えるのですか？
- 似たお客さんはどれくらいいますか？
- 現状で、入力にはどれくらい時間がかかりますか
- 現状、見直すとしたらどれくらい時間がかかりますか？
- 一回（例えば、月度当り）どれくらいのデータが増えますか？
変更するものはなんですか？？？
データの数の他に変更されるものの把握も非常に重要です。
いつまでに必要なの？？？
緊急で必要なのか、半年後にあったらよいのか。相手が必要としている時期によっては、今すぐ作業を開始する必要はないかもしれません。
最終イメージのすり合わせ
どうにかこうにか、すり合わせができました。 最後に、成果物を確認しておきます。できれば、本当の成果物に近いかたちを出せるのが、お互いの考え方のズレを小さくするために理想となります。 すぐに小さなプロトタイプを作れるのもエンジニスキルの１つといえるでしょう。
難しい場合は、代替のツールで似たようなものを作ってみるのも一つの手です。 例えば、
- Excel or Googleスプレッドシート
- Web画面をスマホで表示
などです。
その他
業務改善におけるシステム化のメリットは大きく分けると
- 自動化による工数削減
- 抜け漏れをなくし属人化をなくす
といったところでしょうか。 例えば、効果が不透明だけどどうしても仕事しなければならなかった場合は、完全自動化せずに一部は人間の手を入れつつ、効果をみて改善していく、といった方法を取るのが良いと思います。
終わりに
いかがでしたか。ケーススタディといいつつも、ケースバイケースの部分が多いのが実情です。 ただ、仕事を受ける際は本当にその仕事がする価値があるのかを、実際に仕事をうけるエンジニアも考える（一緒に考えてあげる）のが必要かなーと思います。