はじめに
業務自動化を始めるにあたっての進め方やポイントを自身の振り返りを兼ねて記述します。
当記事は自動化プロジェクトにおいてのフローと各フロー段階での観点にフォーカスしており、特定の自動化技術(VBA、RPAなど)にフォーカスをあてているわけではありません。
ターゲット選定(検討)
・昨今のDX風潮「自動化すべし」から入らない
・自動化の入口は「めんどくさい」から始める
「めんどくさい」が入口になる理由としては、めんどくさい業務はだいたい定型化されており繰り返し単純作業の場合が多いため
繰り返し単純作業は自動化しやすく開発工数が嵩張らない、効果が分かりやすいという点で自動化するに適している。
また業務の自動化というと一連の業務の１～１０すべてを自動化を検討しがちだがハードルは低めに１～４を自動化、５～１０は引き続き手動など半自動化も検討してみる
ターゲット選定(決定)
・費用対効果を意識
・作業時間削減のみに着目しない。「品質」も併せて判断。
前段でも挙げた「自動化すべし」が目的となり、自動化が効率化への手段でなく目的になってくことが多い。
意識していても、自動化を進めていくうちに「稼働」に焦点があたりいつの間にか自動化が手段から目的へとすり替わってたりするので要注意
ターゲット選定において削減工数のみに注目してはならないことに注意
工数に現れづらい以下の利点がある。
- 品質向上
自動化は「工数削減」がピックアップされがちだが、品質向上効果も大事な要素。
人が行う作業の揺れがなくなりで毎回同じ精度でoutputができることは大きな利点となる。
単純に開発工数と削減作業工数を比較し「あんまり効果ないからやーらない。」ではなく、品質的側面も検討したうえで検討したい。
特に現めんどくさい業務の品質が悪いために後続作業や修正作業に多大な工数が発生しているようであれば開発工数が作業工数削減にさして貢献できないとしても「品質」のため自動化はあり。
開発フェーズ～自動化は実務・運用担当との二人三脚で～
・自己満実装はやめろ
・実務を常に意識して過剰なくらい認識合わせを
いざ稼働フェーズに入った際にあるあるなのが「思ってたのと違う」「これじゃだめだ」など運用側で発生するいまさらな文句。
「そんなこといまさら言うなよ」「やり直しってマ？」
気持ちはわかるが、それを実装前に引き出せなかった自身の責任。
(特に実務・運用側はシステム的知見に疎いことが多く、開発側が求める業務ロジックをうまく提示できなかったりする)
※ただ散々認識合わせをしても稼働フェーズで根本問題なとんでも爆弾が落ちてきたりはある...。
結局最初のころだけちょっと稼働した後、実務・運用側で「つかえねー」となり、いつの間にやら手動に戻ってるなんてことはあるある。
上記を防ぐためにもプロジェクトには実務・運用担当に参加してもらいしつこいほど認識合わせをするのがいい。
開発フェーズ～常に進捗や状態を見える化～
・WBSを立てる
・すべてさらけ出し共有
前項で書いたように失敗の原因はだいたいが「認識齟齬」
これは私が失敗した自動化のすべてに共通している。
最初はあってたはずの認識が徐々にずれていく。
「それ伝えました」
「いや、聞いてない」
原因は伝達不足や共有不足、または確かに伝えた事実が残っているがslackのスレッドでコメント程度に大事なことをさらりと伝えてしまっていたり。
認識齟齬を防止するためにも常にオープンにすること。
WBS(Work Breakdown Structure) を作り、同じファイル内に仕様書なども追加していき、常に実務・運用担当と共有されている状態を作る。
→WBSとは
また進捗確認も上記のWBSと照らし合わせながら定期的に開催し、「今週は～したときに～されるまでの機能を作成しました。～したときは～のヘッダー順で～.csvとして出力されます。来週は～を実装する予定です」など細々と認識をすり合わせながら進めること。
「すごい時間かかるじゃん、無駄じゃん」
あとから防げたはずの爆弾が降ってきて修正や再認識合わせの工数のがはるかに嵩張るのでここは面倒くさいがちょうどいいくらいで丁寧に進める。
稼働フェーズ
・自身が実務担当となる
・マニュアル/手順書は手厚く
実務担当になるというのは実務担当へジョブチェンという意味ではなく、自分が実務担当のつもりで自動化を組むこと
実際に自動化するまえの実務と自動化後の1回目は自身と実務担当で一緒にやるくらいがいい。
実際にやってみると、
「ヒアリングではそんなこといってなかったやん...」
みたいなことが必ず１つ２つ出てくる。
実務担当のことは信用はするが信頼するなの姿勢
他人を信じず一人で全部やれということではなくて、必ず裏付けを取ること。
自動化にあたっては自身もやってみるが最大の裏付けになります。
引き渡す際には手厚い手順書は必ず作りましょう。
そこまで書かなくても...くらいがちょうどいいです。
× 「マクロを実行した後、[結果]シートにて正しい値となっていることを確認」
〇 「[設定]シートの「処理開始」ボタンを押下し、「処理が完了しました」のダイアログが出るまで待機、ダイアログが表示されたら「OK」を押下しダイアログを閉じた後、[結果]シートの比較チェック項目にてAとBのセル結果が同一であることを確認する」
自動化された業務は、派遣さんやアルバイト、はたまた新人などに渡されたり、ITリテラシーがあまりない人が行うことも充分に考えられます。(というより多いと思う)
「これくらいならわかるやろ」
が無用な事故を起こす可能性があるので手順書の充実は絶対です
遠足は家に帰るまでが遠足
自動化は手順書を作り終わるまでが自動化です
保守フェーズ
・仕様書/手順書は常に無駄なく美しく
・アップデート履歴を残す
なにかしら業務上の変更などで要件が変わり修正などが発生することは必ずあります。
その前提で仕様書・手順書を作りこんでおくべき。
それを直すのは自身ではなく、後任者である可能性もあります。というより後任者が直す前提で作りこんでおくのがいいです。
実際問題そこまで至らないことが多いです。事実私もまだ...(自戒)
ただ後々何してるかわからない、変になるのが怖くて触れないなど後々に負債になることは目に見えています。(作りが複雑なものほど特に)
なかなかそこまで目が向きませんがしたほうがいいのは間違いなく、、、必ずしましょう(再自戒)
評価
・予測値との乖離原因をなぜなぜ
稼働したら気持ち的に開放された感、終わった感ありますが評価を必ず実施。
特に検討時に予測した効果と実績との差について分析
なぜ乖離があるのか
開発工数の予想効果のどちらの見通しが甘かったのか
予想効果が盛りすぎてたか、思ったより実効果がなかったか
実効果がなかった理由は？
正しい評価をして振り返ることで次の自動化の費用対効果を考える際の確度が高まります。
複数回サイクルを回していると検討段階での確度がだいぶ高まります(体感)
だんだんと最初の自動化してたころには思い浮かばなかった「この自動化には実オペレーションの中にこんな爆弾ないよね？」みたいなまだみぬ爆弾へのあたりがつくようになります。
最後に
今回は以下を読ませていただき「自分はできているだろうか」と振り返りながらこうしたほうがいい。こうあるべき。を記載させていただきました。
https://qiita.com/youzhen0x38/items/3d1d043f794b707cf031
私も稼働時に
「そんなのきいてないよ...ひどいよ...」
みたいなことがしばしばあります。
なので実体験からくる反省として記載内容がどなたかの助けになればと思います。
また私も助けられたいので「こうしたほうがええやん」があれば容赦なくコメントいただけますと幸いです。
最後に、
実際に業務の中に自動化の仕組みがマージされ、無事稼働したときの達成感や嬉しさたるや「よく頑張ったね。機嫌よく動いてくれてなにより」みたいな我が子を育て、就職を見届けた親のような達成感があり、業務の中で子育てを経験したい方は自動化オススメです。(私は独身ですが)