業務改善に、終着点はあるか
みなさん、システムツールを利用した業務改善に取り組んでいらっしゃいますでしょうか。おそらくこの記事を読まれる方は、自分の仕事の改善であれ、会社全体の改善であれ、その規模にかかわらず業務改善の取り組みについて興味を持たれている方々でしょう。
ぼくはサイボウズ社のノーコードのクラウドサービス「kintone」を利用してお客様の業務の改善提案を行ったり、伴走支援や研修をすることを生業にしています。
きょうは、業務改善に終着点があるかという論点について、自分なりにまとめて決着をつけたいと思っています。
終着点がない業務改善
本格的な議論に入る前に、業務改善に終着点がなかったらどうなるか考えてみましょう。
業務を改善する。その目的は「企業の売上の向上」であることは間違いないでしょう。「生産性の向上」と言い換えてもよい。
であるならば、１つの業務を改善して、生産性が上がる。つぎに２つめ、３つめ。１，２，３を統合。市場の需要や法律などの企業を取り巻く状況が変わる。また改善する・・・。
企業が利益を追求して社員に還元する活動を続けていくならば、市場と戦うためにこの活動が無限につづきます。
無限に続くものを目標にすることはできませんので、細かい目標を立てたりします。そうしても、目標が達成されるたび新しい目標が生まれ、システムは無秩序に増え、漫然と改善が繰り返されて同じ課題にぶつかり続けます。
つらいのは、改善を行う担当者です。改善する使命を組織から与えられた者は、誰からも褒められず、省みられず、延々と階段を上ることになります。
ぼくは終着点があるとかんがえている
ぼくは、業務改善という活動には終着点がある、と考えています。「終着点」という言葉があいまいだと思われるかもしれませんね。その場合は「目標」と言い換えてもいいかもしれません。
業務改善には終着点があります。
それは、業務を改善するための業務を作り上げたときです。
業務を改善するための業務を作ることが、業務改善という活動の目標です。
これは一見するとレトリックに聞こえるかもしれません。けれども、かなり示唆に富んだ推察だと思っています。なぜなら、多くの企業で業務プロセスの改善それ自体が目的になっており、業務プロセスを改善するプロセスに目が行く企業が少ないからです。
改善の担当者は「改善する社内の仕組み」を維持する管理者です。そして業務の改善はそれをしたいと思う人と、改善できる人とが原動力となって、一緒に達成されます。
業務を改善するための業務とはなにか
では、なにがこれにあたるのか考えてみたいと思います。
kintoneを利用した開発。「案件管理の仕組みを作りました」といったこと。
これは業務の改善です。では何が業務を改善するための業務にあたるのでしょうか。
kintoneの開発技術の研修。「問い合わせやFAQ」の仕組み。問題管理。変更管理。開発環境と本番環境の分離と整理。業務課題のヒアリングシート。定例会。
これらは業務を改善するための仕組みであり、業務を改善するための業務です。
直接的に業務上の課題を解決するのが「業務改善」であり、業務改善する上の課題を収集、管理、分析して解決に寄与するのが「業務改善するための業務」となる。
システムの開発
昨今ではローコード開発技術の高まりから、内製化を目指す動きが活発です。内製化はとても良いことだと思います。なぜなら、企業のシステムとは企業の生産構造を表現したものになるからです。
システムが業務と一体化していて、内製するものであったころ、システム化の計画は企業の自分事、自分の課題でした。外注するようになると、提案や企画まで外の企業に求めるようになり、自社の業務プロセスをシステム化するための考え方が失われてしまいました。
その代わりに、外注先のシステム開発企業の関心事として、システムを作るためのシステムへ姿を変えました。あたらしい開発技術はシステムを作るために必要なものですが、その収集や学習の方法、システム設計上の表現手法。テスト、プロジェクトの健全な管理、顧客との正確なコミュニケーションなどはシステムを作るためのシステムです。
そういったわけで、システム開発企業はシステム自体だけではなく、自分の生産構造を守るためにシステムを作るためのシステムを備えることになりました。
内製化により企業の手に戻ってきたシステム化を、いま推進して業務改善をしようとするとき、このシステムを作るためのシステムという構造を逆にシステム開発会社から輸入することができます。
たとえば、ローコードツールで開発したアプリのテストはどのようにおこなうのか。設計はどのタイミングで行うのか。といったことです。
業務プロセス改善の平衡状態
課題の収集＞企画立案＞開発＞運用＞課題の収集…
このサイクルが回りだすと、植物が枝葉を広げるようにシステムが生産構造の中に浸透していき、利用が拡大します。
利用拡大すると、実業務のほうの生産性が上がり、改善が提供されます。改善手法を提供できる作業者の生産性を需要が超えてきますので、無限に改善が行われるわけではなく、システムチームや担当者の数や能力の制限を受けながら伸びていきます。
では特定分野での改善が無限に続くのかというとそうでもなく、システムは利用するテクノロジーにより制限を受けますから、テクノロジーとビジネスの間で妥協点に至ります。なんでも自動化するわけではなく、人の作業を残したりしますね。
そうやってシステムによる業務の改善は良い平衡状態になります。
目先の課題の解決ではなく、課題解決のサイクルの構築と強化が企業の実体の生産性へシステム側から提供できるものと言えると思います。そしてそれには「実際に業務を改善できる」能力ももちろん必要です。
このサイクル、業務を改善する業務が生きている間は、今すぐでなくともいつか、生産性は改善される。でもこのサイクルが確立されずシステムだけが存在する場合、変化に追従できなくなるときが来ます。
⇔技術の提供度（右に行くほど強いシステム）
⇕業務の改善具合（上の方が改善が進んでいる）
点線の部分がビジネスの規模
まとめ
業務改善には終着点があるかというテーマで、自分の考えをアウトプットしてみました。これはぼくが日ごろから考えている内容です。
関係者の方々にシステムの開発に楽しんで積極的に関わってもらいたいといつも考えています。そんなとき、具体的な「システム」以外で、何を付加価値として提供できるのか。
システムを開発するシステムがぼくが提供できるものの一つだ。と考えています。
この記事は以上です。お読みいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか？