IT業界10年で、いちばん楽しかったのは事業会社のIT部門にいたときです。
ただ、感謝されたから楽しかったわけではありません。
むしろお礼を言われた記憶がないんですよね。
それでも楽しかった理由を書いていきます。
情シスやIT企画への転職を考えている人
社内で業務改善やRPAをやっている人
改善の効果をどう数字にするか悩んでいる人
業務改善の一例：倉庫の検品業務
事業会社のIT企画部に常駐していたときの話です。
この部署では、基幹システムの要件定義や、海外向けの販売管理システムの導入なども担当していました。
業務改善もRPA化も、対象になる業務はいくつもあります。
なので以下はあくまでそのうちの一つとして読んでください。
分かりやすい例なので、これを使って書いていきます。
まず、業務の流れ
当時の検品業務は、こんな流れで回っていました。
- メーカーが商品を倉庫へ発送する
- メーカーから本社へ、検品依頼書がエクセルでメール送付される
- 本社で内容をチェックして、受付の連絡を返す
- 検品依頼書を、倉庫が見る場所に配置する
- 全体の進捗一覧に、新規の依頼を追加する
- 検品結果を記入するためのエクセルを作成する
- 倉庫の担当者が検品して、結果を記入する
このうち4番から6番が、本社の担当者がひたすら手でやっている作業でした。
エクセルを開いて、中身を見て、別のエクセルに転記して、また別のエクセルを作る。
商品が動いている裏で、人がずっとエクセルを触り続けている状態です。
しかも季節によって物量が変わるので、忙しい時期はここが完全に詰まります。
自動化したのは、この真ん中の3つ
やることは単純です。
届いたエクセルから必要な情報を取って、配置して、一覧に足して、記入用のエクセルを出す。
これをフェーズ1とフェーズ2に分けて進めました。
- フェーズ1（2週間程度） 依頼書の配置と、進捗一覧への追加
- フェーズ2（3週間程度） 検品結果を記入するエクセルの作成
作るもの自体は、正直それほど難しくありません。
エクセルを読んで、別のエクセルを出す。
RPAの中では、かなり素直な部類の処理です。
自動化の前に、業務のほうを変えた
ここが一番大事なところです。
調べてみると、検品依頼書のフォーマットがメーカーごとにバラバラでした。
項目の位置も名前も違います。
この状態では、そもそも自動化できません。
だから、フォーマットの統一を提案した
やったのは、共通フォーマットを決めて各メーカーに合わせてもらうことです。
社内の調達部門と一緒に、順番に切り替えてもらう調整をしました。
全部を一斉に切り替えるのは無理なので、切り替えが終わったメーカーから順にRPAに乗せる進め方にしています。
正直、ここが一番しんどかった
RPAを作るのは、実はそんなに時間がかかりません。
大変なのは、揃っていないものを揃えることのほうです。
社外の相手に「フォーマットを変えてください」とお願いするわけですから。
相手には相手の事情があるので、一方的に押し付けることはできません。
なので、なぜ変えてほしいのかと、変わったあとに何が良くなるのかをセットで説明しました。
「受付の連絡が今より早く返せるようになります」
そう言えると、話が進みやすくなります。
ただ、面白いのはここからで、フォーマットが揃った時点でRPAが無くても業務は軽くなっているんですよね。
自動化するために業務を整理したら、整理そのものに価値があった。
この感覚が、今もずっと残っています。
全部を自動化しようとはしなかった
もう一つ決めたことがあります。
対象は新規の依頼だけにして、修正が入った分は手作業のままにしました。
修正分は全体の5%ほどです。
残り5%に時間をかけない
修正のパターンまでRPAでカバーしようとすると、難易度が一気に上がります。
条件分岐が増えて、作るのにも直すのにも時間がかかるようになります。
100点を狙うと、たぶん完成しません。
95%を自動化できれば十分ですし、残り5%に時間をかけるくらいなら、次の業務に手をつけたほうが効果は大きいです。
このあたりの割り切りは、この案件で身につきました。
ちなみに、同じ流れの中にメーカーへの請求書作成という業務もありました。
こちらは難易度が高かったので、いったん別扱いにしています。
やる順番を決めるのも仕事のうちだと思っています。
ちなみに、この5%を手作業で残すことは最初に関係者へ伝えています。
後から「これはできません」と言うと、だいたい揉めます。
やらない範囲を先に決めて、先に言う。
これだけで、あとがかなり楽になりました。
効果は「パートの時給×時間」で出した
効果の計算は、難しいことは一切していません。
削減できた作業時間 × パートタイマーの時給
これだけです。
年間にすると、約500万円になりました。
数字にするのは、自分のためではない
効果を数字にしておく意味は、褒めてもらうためではありません。
次の投資を通すためです。
「これだけ減りました」と言える実績があると、次の改善の話がとても進めやすくなります。
逆に、効果を測っていない改善は、やった本人しか価値を知らないまま終わります。
これは開発費の判断でも同じでした。
たとえば開発に数百万かかるとして、何か月で回収できるのかを試算します。
その数字があると、上長も判断できますし、やらないという結論も出せます。
やる理由よりも、やらない理由を出せるほうが信頼される気がしています。
ただ、お礼を言われたことはなかった
効果は大きかったと思っています。
ただ、正直に書くと感謝された記憶はありません。
言われていたのは「いつできるんですか？」
むしろ、急かされることのほうが多かったです。
依頼はどんどん増えていくのに、そこはあまり気にされません。
当時のIT企画部のリーダーや先輩は、その様子を見て少し苛立っていました。
「これだけやってもらってるのに、その言い方はないやろ」という感じです。
私はその横で、まあそういうものかと思っていました。
依頼している側からすると、目の前の業務を早く楽にしたいだけなんですよね。
悪気があるわけではないと思います。
ただ、こちらの作業量が見えていないので、際限なく増えていきます。
今振り返ると、仕方なかったとも思う
ただ、今になって思うことがあります。
私自身が、仕事を押し込まれやすい雰囲気を出していたんですよね。
頼まれると断らないし、やってしまいます。
そういう人のところに依頼が集まるのは、当たり前です。
相手からすれば、頼めば出てくる窓口ができたようなものだと思います。
ちなみにこの癖は、10年経った今も直っていません。
そこは今回の転職でもいちばん不安に思っているところです。
断れないままだと、どこに行っても同じことが起きます。
結局それで残業が増えて、前職では体調を崩しました。
それでも、いちばん楽しかった
楽しかった理由は、感謝ではありませんでした。
業務が実際に変わるところを、自分の目で見られたからです。
倉庫の人が何をやっているかが分かります。
どこで手が止まっているかも分かります。
そして自分が作ったものが、来週から普通に使われています。
このスピード感が、たぶん自分には合っていました。
半年後にリリースされるものより、来週から効くもののほうが面白いです。
作って納めて終わり、では味わえない
開発の現場に3年いて、この違いがはっきり分かりました。
システムを作って納めたあと、それが業務をどう変えたかまでは、たいてい見えません。
どちらが偉いという話ではないです。
ただ、私の場合は「その後」まで見えないと物足りないだけなんですよね。
今回コンサル寄りの仕事を選んだのも、結局ここが理由でした。
まとめ：感謝はされなくても、変化は残る
情シスやIT企画は、正直かなり感謝されにくいポジションです。
うまくいって当たり前、遅いと言われる。
これは情シスを経験した人ならだいたい共感してもらえると思います。
ただ、業務が変わった事実だけは残ります。
そして数字にしておけば、それは自分の実績としても残ります。
実際この検品業務の話は、5年近く経った今でも面接で使えています。
お礼を言われなくても、やったことは消えません。
そう思えるようになったのは、この仕事のおかげかもしれません。
もし今、社内で改善をやっていて報われていないと感じている方がいたら、効果だけは数字にして残しておいてください。
感謝はされなくても、その数字はあとから必ず効いてきます。
