※この記事は、これまで業務効率化に携わる中で感じたことや、これから市民開発支援に携わるにあたって考えていることを整理した備忘録です。
はじめに
DXを推進するために、新しいツールを導入する。
Microsoft 365、Power Platform、RPA、生成AIなど、業務を効率化するためのツールはどんどん増えています。
会社としても、
- ツールを導入する
- 研修を実施する
- マニュアルを用意する
- 動画を公開する
- テンプレートを用意する
など、社員が利用できる環境を整えていることも多いと思います。
それでも、
「思ったほど使われない」
ということがあります。
なぜなんだろう？
今回は、これまで業務効率化に取り組む中で感じてきたことも含めて、DXがなかなか進まない理由について自分なりに考えてみました。
1. ツールを導入しただけではDXは進まない
会社からすると、
「使える環境を用意しました」
「研修動画もあります」
「マニュアルもあります」
「テンプレートもあります」
となっていても、実際に使う社員側からすると、
「何から始めればいいの？」
「自分の仕事のどこに使えるの？」
「どの動画を見ればいいの？」
「調べる時間がない……」
「今のやり方でも、とりあえず仕事は終わるし……」
となることがあります。
つまり、
ツールを使える環境 ≠ ツールを使える組織
なのではないでしょうか。
ツールがそこにあるだけで、社員が自然に使い始めるわけではありません。
そこには、
- 学習コスト：新しい操作や考え方を覚える必要がある
- 検索コスト：自分が必要としている情報を探す必要がある
- 心理的ハードル：「難しそう」「壊したらどうしよう」という不安がある
といった壁があります。
特に通常業務を抱えながら、
「業務改善のために、まず新しいツールを勉強してください」
と言われても、なかなか時間を確保できない人もいると思います。
DXを進めるには、ツールを導入するだけではなく、こうした**「使い始めるまでのハードル」そのものを下げる仕組み**が必要なのではないかと考えています。
2. DX以前に、業務そのものがブラックボックス化している
もう一つ、大きな問題だと感じているのが業務の属人化です。
職場でこんな言葉を聞くことがあります。
「その業務は○○さんしか分かりません」
○○さんが休む。
↓
業務が止まる。
○○さんが異動する。
↓
誰も詳しい手順が分からない。
○○さんが退職する。
↓
「このExcelマクロ、誰が作ったの？」
となる。
マニュアルがあったとしても更新されていなかったり、実際の細かい判断基準は担当者の頭の中にしかなかったりすることもあります。
これでは、どれだけ新しいツールを導入しても、その土台となる業務自体がブラックボックスのままです。
DXを考える前に、
「この業務は誰が、何を、どのように行っているのか」
を組織として把握できる状態にすることも重要だと思います。
3. 市民開発が「新しい属人化」を生む可能性
ここで、少し怖いと思っていることがあります。
Power Platformなどによる市民開発が進むと、現場の担当者自身が業務を改善できるようになります。
これはとても大きなメリットです。
一方で、
個人が作ったアプリやフローが、その人にしか分からない状態になる可能性もあります。
例えば、
「このPower Automate、誰が作ったの？」
「○○さんです」
「○○さん、もう異動してるよ……」
「エラーになっているんですけど、誰も中身が分かりません」
ということが起きたらどうでしょうか。
Excelマクロで起きていた属人化が、Power AutomateやPower Appsに置き換わっただけになってしまいます。
つまり、
DXのために作った仕組みそのものが、新しいブラックボックスになる可能性がある。
市民開発によって「作れる人」を増やすことは大切です。
でも、作れる人を増やすだけでは、組織としてのDXには十分ではないのかもしれません。
4. 業務効率化すると、仕事が増える？
もう一つ、私自身が業務効率化に取り組む中で感じてきたことがあります。
それは、
「業務を効率化しても、その分また仕事が増える」
ということです。
もちろん、業務効率化によって生まれた時間を、別の仕事に活用すること自体が悪いわけではありません。
例えば、今まで4時間かかっていた定型業務を自動化して、30分で終わるようになったとします。
そこで生まれた3時間30分を、企画や分析、改善活動など、より付加価値の高い仕事に使えるのであれば、むしろ業務効率化の大きな成果だと思います。
私が疑問に感じているのは、
「効率化によって生まれた時間を有効活用すること」と、「空いた分だけ新しい業務を追加すること」は同じなのだろうか？
ということです。
効率化した本人からすると、
仕事を改善するために勉強する
↓
自動化の仕組みを作る
↓
テストする
↓
エラーが起きれば直す
↓
周囲から別の改善も頼まれる
↓
さらに新しい業務も追加される
という状態になる可能性があります。
これが続けば、
「効率化できる人ほど、仕事が増える」
という状況にもなりかねません。
「お宅らが、仕事を増やしてるんだよ」
以前働いていた職場では、業務効率化を進める一方で、上位組織から新しい依頼や対応事項が次々と増えていくことがありました。
そんな中、当時の部長が、こんな趣旨のことを言ってくれたことがあります。
「いくらこっちが業務を効率化しても、お宅らが仕事を増やしてるんだよ」
この言葉が、今でもとても印象に残っています。
この言葉は、「効率化して空いた時間には何もするべきではない」という意味ではありません。
現場が工夫して10時間分の業務を削減しても、その一方で新しい業務が15時間分追加されれば、組織全体で見れば業務量は減るどころか増えています。
業務効率化というと、つい
「この作業を何時間削減できたか」
という個々の成果に目が向きがちです。
でも、本当に見るべきなのは、
「その時間を何に使えるようになったのか」
そして、
「組織全体として、本当に業務が効率化されているのか」
なのではないでしょうか。
定型業務を自動化して生まれた時間を、より付加価値の高い仕事に使う。
これは業務効率化の理想的な形の一つだと思います。
一方で、効率化によって生まれた時間を、また別の定型業務で埋め続けてしまえば、現場にとってDXは、
「より価値の高い仕事をするためのもの」
ではなく、
「より多くの仕事をこなすためのもの」
になってしまいます。
そうなれば、
「頑張って効率化しても、結局また仕事が増える」
と感じる人が出てきても不思議ではありません。
DXを継続していくためには、単に「何時間削減できたか」だけではなく、
効率化によって生まれた時間をどう使うのかまで含めて考えること
が必要なのではないかと思います。
5. 改善する人が「やってよかった」と思える仕組みも必要
DXや市民開発を進めるのであれば、
「業務を改善してください」
と社員に求めるだけではなく、
改善した人が「やってよかった」と思える仕組み
も必要なのではないでしょうか。
例えば、
- 削減できた時間をどう扱うのか
- 改善活動そのものをどう評価するのか
- 市民開発に取り組む時間を業務として確保できるのか
- 作ったアプリやフローの保守を誰が担うのか
- 他部署でも使える仕組みを作った人の貢献をどう評価するのか
といったことです。
特に市民開発では、
通常業務 ＋ Power Platformの学習 ＋ 開発 ＋ 保守
となってしまう可能性があります。
さらに詳しくなれば、
「○○さん、Power Automate詳しいよね？ これも作ってくれない？」
と頼まれることも増えるかもしれません。
それなのに、評価も役割も変わらない。
これでは、市民開発を続けるモチベーションを維持するのは難しいと思います。
ツールだけではなく、
評価・業務配分・役割・運用まで含めて考える。
ここまで含めて、市民開発の仕組みを設計する必要があるのではないでしょうか。
6. 「人に依存するDX」から「組織に残るDX」へ
そしてもう一つ重要なのが、
できる人を増やすだけではなく、その人が持っている知識や仕組みを組織に残すこと
だと考えています。
例えば、
個人が便利なフローを作る
↓
その人だけが使う
で終わるのではなく、
個人が便利なフローを作る
↓
構築方法や変更箇所を整理する
↓
組織内で共有する
↓
他の人が再利用する
↓
自分の業務に合わせてさらに改善する
↓
改善したものを、また組織に戻す
という循環を作る。
そうすることで、
「あの人がいないと分からない」
から、
「組織として分かる・組織として使える」
へ変えていけるのではないでしょうか。
これは単なるPower Platformの使い方の共有ではなく、属人化を防ぐためのナレッジマネジメントにもつながると思っています。
7. DXとは、ツールを導入することではない
新しいツールを導入しても、使い方が分からなければ使われない。
一部の詳しい人だけが使えるようになっても、その人がいなくなれば止まってしまう。
業務を効率化しても、その分だけ仕事を増やしてしまえば、現場にとって「効率化した」という実感は得にくい。
さらに、市民開発によって一人ひとりがアプリやフローを作れるようになったとしても、それが個人の中だけに残れば、今度は
「市民開発による新しい属人化」
が生まれる可能性があります。
だからこそ、
個人が持っている知識や仕組みを、どう組織の資産に変えていくか。
そして、
改善した人が「やってよかった」と思える環境をどう作るか。
ここまで考える必要があるのではないでしょうか。
DXを進めるうえでは、ツールを導入すること以上に、
人が使えること
改善する人が評価されること
知識や仕組みが組織に残ること
そして、
次の人がそれを活用できること
が重要なのではないかと考えています。
では、どうすれば「組織に残る」のか？
ここまで書いてきましたが、
「じゃあ、具体的にどうやって知識を残して、再利用できるようにするの？」
という話になります。
その方法の一つとして、私が現在考えているのが、
「ゼロから作らない。TTPSで育てるPower Platform市民開発」
という考え方です。
すでにある良い仕組みを参考にする。
自分の業務に合わせて進化させる。
そして、その知識をまた次の人へ渡す。
個人の業務改善で終わらせず、組織のナレッジとして循環させる。
まだ構想段階ですが、これから市民開発支援に携わる中で、実際にどこまで実現できるのか試してみたいと思っています。