業務効率化のツールを導入しても残業が減らない理由
こんにちは😃
出戻りガツオ🐟です！
今日は特に「Excel VBA・マクロのツールを他の人に渡したことがある人に共感いただけるんじゃないか」と思うテーマにしました！
プログラムを書いて、本来であれば一瞬で作業が終わる想定…のはずが減らない業務、こういったケースは少なくありません。
最悪の場合、業務負担が増えているケースがあったりもします。
一体何故なのか？
複数の要因が考えられますが、私は今回、作り手であるディベロッパーと使い手であるユーザーの関係性、チームになり得ているか？に焦点を当てて、noteを書いてみようと思います！
業務効率化ツールについて
本日のnoteでは「業務効率化ツール」そのものに定義は、
Excel VBA・マクロ然り、Power Automate for desktopを中心としたRPA、人が介在する業務を示すことにします。
クラウドフローでは発生し難いためです。
Excel VBA・VBScript・PowerShell・RPA・Google Apps Script・Pythonなどなど（自分主眼で書いておりますが・・・）、自発的に勉強された作り手であるディベロッパーが、他者への貢献としてツールを提供することは、とても素晴らしいことだと私は思います。私自身そうしたツール提供を沢山してきて、バックオフィスの生産性向上にキャリアの中でしてきました。
基本的には「ワンクリックで成果物ができあがる」といったものが主体となりますが、作業をするうえで、必要な環境・設定・条件は使い手のユーザーにしっかりと伝達する必要があります。
「無条件でどこでも、自分な自由な感じで作業OKまる✨」というツールは生まれないでしょう。
そのため「仕様書」や「マニュアル」もしくは「実際に口頭で操作指導をする」といった形で、ディベロッパーからユーザーへの受け渡しがされ、実際に使うフェーズに移っていきます。
単位は小さくとも、所謂ウォーターフォールモデルで作成が進んでいます。
- コトバは業務効率化ツールバージョンとして若干変えてます
実際のシステム設計におけるウォーターフォールモデルについては下記をご参照ください。
とっても堅苦しく書いてますが様式美で書くと、こういう構造になっているんじゃないかな？って想像です。
超真面目にこの工程を徹底してやるのも一つの正解ですが、めっちゃ時間かかりますし、私たちが解決したい課題って、こんなに計画とかドキュメント詰めてやるって考えると辟易しますよね？
多分ユーザー側もウンザリザリガニ🦞🦞なっちゃうかも。
話を戻して、もーっとラフに箇条書きで書いてみます。
仕様を聞く or 自分で把握する（見ればわかるケースも正直ある
作る - 自分でテストする
仕様書やマニュアル作る、またはツールの端っこにメモ程度に残す
ユーザーがテストする
良さげなら導入🥳
こんなんじゃないかと思います。解決したい課題のスケールが所謂プロジェクトとはサイズが異なるため、このくらいのラフさでやることが私は好きです。
しかーし
最初は喜ばれるけれども後手後手が多発・・・💦
「仕事が楽になる」
このことは喜んでくださる方が沢山いらっしゃいます。
※喜ばない人もいます
実際に触ってみて、作業の速さ、正確さ、簡単さに感動を与えることも可能です。ただここからが大変なのです・・・。
ホントはもっとこうしたい
実際にツールを触ってみて、運用を始めると、「成果物の内容を変えたい」という要望はよく出ます。
ほかには「元データの形式は実はコロコロ変わる」であったり「伝えてなかったけど実はこう」といった事実がボロボロ出てきます。
私の図で言う赤枠のところ、もうこっからズレていたって事実に直面するんですね。
私の意見ですが、もうこれは「しょうがない」って諦めるしかないです。
ディベロッパーの経験則で、ヒアリングを徹底し、漏れの無いように進めるということが正論でしょうが、たぶんできません。
強い表現すると、「自分の仕事を言語化できるユーザー」って少ないです。「ディベロッパーも経験則でカンで推察できるようになる、仕組みを作る」も厳しいと思います。
結果として生まれるディベロッパーとユーザーのすれ違い
さて、ここでリカバリーが必要になりますが、これがとっても難しい。
ディベロッパーはそんなの聞いてない - 最悪作り直し
ユーザーはお願いしているのに対応してくれない - 作り手の人不親切！
亀裂が生じます。
信頼関係が出来ていないと結果として仕様があっていないツールについては導入がされなかったり、ユーザー側は仕様がどれだけカバーされているのか不明なので、同じ作業を手で結局することになります。
また亀裂は後々の作業にも影響を与えます。作るツールへの信頼感が下がり、テストの工数をモリモリに設けて、永遠にテストをする、コミュニケーションの不一致で自動化のための自動化の仕事が量産される。
人を楽にするために始めた仕事がなぜか亀裂が生まれるきっかけになる、めっちゃ大変になる、悲しい結末です。
では、どうするのか。
ここからがチームワークの課題テーマになります。
ディベロッパーとユーザーの関係性
上記では書いていませんが、「業務効率化ツールを提供する」ということは仕様の変更や、環境の変化、ユーザーからの問い合わせも自ずと課されることになります。
どうとらえるかは個々人の感性ですが、渡したユーザーとの関係は持続的な関係が生まれることになります。
ここで「ディベロッパーとユーザーの関係をひとつのチーム」としてとらえることにしましょう。
「タックマンモデル」という考え方を紹介させてください。
※引用を沢山させていただきます🙇
タックマンモデルとは？
HR BLOGをもとに紹介しますね。
タックマンモデルは1965年に提唱されたチームビルディングに役立つ考え方です。
提唱したのは心理学者のタックマンで、チームの育成のために現在でも多くの企業、組織がこの考え方を取り入れています。
タックマンモデルではチームの形成から解散までを5つの段階にわけて考えます。
それぞれの段階に応じて何が必要か、何をすべきかを的確に判断でき、チームをより効率的に育成していけます。
優秀な人材を集めたりリーダーシップの強い人材を投入するだけではチームはまとまりません。個人個人に焦点を当てて、チーム作りに何が大切かを考えることが大切です。
「チーム」というものに段階があるという考え方が、とても理解できる考え方です。
"ごくたまにしゃべる同僚"と"よく悩み相談や仕事の話をする同僚"では、関係性の濃さ、会話の頻度、話しやすさが全然違います。
そして、この部分によって、「業務効率化ツールをどうしていくか、『むきなおり』をできるか」が決まってくるんですよね。
関係性が出来ていない人との「むきなおり」
難しい課題ですね。
漏れていた仕様の整理
相手の要望の整理
納期やスケジュールの調整
対応が難しい部分に関する合意
相手との関係を見つつ、ディベロッパーであるあなたがリーダーシップをとらなければなりません。そしてとても厳しい道です。
「御用聞き」になってしまう危険性もはらみます。
しかしながら「御用聞き」「IT介護士」を脱するには、ここに勇気をもってチャレンジすることが、一つの道になります。
ちなみに！出戻りガツオは全然できてません！！！！！🐟💦
しかしながら、今期は一つ、分断を乗り越えて業務効率化を達成することができました。
チームの成長のためには
「チームの成長」というコトバを使いと暑苦しい感じもします。
ですがこの本質は、
関係者との役割分担を明確にする
リーダーを担う
スケジュールを明確に決め、徹底に寄与する
メンバーのモチベーションを見て、フォローをする
良いもの作る！良いシゴトする！
早い話、リーダーシップとっていいシゴトするんです。
イニシアティブをもって、自分が引っ張る。
「なんで自分が」とかいう損得勘定は置いておいて、進めるんです。
このサイクルを実直に回すことがチームビルディングの本質にも触れていると思います。
この難易度が、タックマンモデルでいう「混乱期」まではとても高いです。
ストレスもたまります。傷つくこともあるでしょう。
ただ関係性をしっかりと構築されたチームで仕事ができることは今後にとって素晴らしい財産です。
そしてここからディベロッパーが作ったデータを心の底から信頼し、真の業務改善につながっていきます！
感情が高まってきてしまいましたが、業務効率化推進というのは
「難易度も高いし、大変」という結論と「これほど難易度が高い課題である」ということです。
とはいえここまで難しくとらえず、単純に周りに貢献出来たら嬉しいですよね。そこからでも良し、ガチンコで全社推進するのも良し。
市民開発者の花形としてたたえられる仕事になればいいなっていう私の願いを最後に込めて締めくくりたいと思います！
最後に！！！
いつもお読みいただきありがとうございます！
ITを使って仕事を楽しくする一助になりたいと思ってますので
お読みいただいた方はぜひTwitterもフォローしてください！
Power PlatformやPythonやExcel、Google Apps Scriptなどなど雑多につぶやきます。よなよなエールが大好きです🍺
リプ、いいね👍、RT大歓迎です！
強く求めてます🐟😂🐟
業務改善フレンズ大歓迎！！切磋琢磨しましょ～♪♪
それではまた今度！ばいば〜い！