生産性を高め、効率も上がったがために、余計に仕事が増えて忙しくなることもあります。今回は、具体的に「本社・管理系業務」と「開発・設計系業務」の2つを例に、業務改善のヒントをお伝えします。
生産性を高め、効率化したら余計に忙しく？
直接部門、間接部門に関わらず、経営者からは「生産性を高めろ！」「もっと効率的に仕事をしろ！」と言われるのは、昔も今も変わりません。言われ続ける現場の身としては、「これ以上、どう効率化しろと言うのか？」と喉元まで出かかった声をグッと堪えることもあるでしょう。
現在はIT化も進み、業務そのものは情報システムの恩恵にあやかって、システム的には効率化は進んでいます。その一方で、システムで解決できない仕事はむしろ増えてきています。「人間が頭を使い・考え・判断し・行動する」部分は、決してシステムではできないことです。
業務改善は、ミス・トラブルなどの後追い的な仕事をなくすことで、コストを下げる・品質を高める・納期を短縮することを実現していくものです。結果として、仕事の上でも、気持ちの上でもゆとりもでき、できた時間を使ってより付加価値の高い仕事を行う、このような理想論は誰しも描きます。業務改善のモチベーションの1つにもなります。
しかし、「1つ山を越えると次の山がすぐ待っている」状態に陥ることも、過去に改善で失敗をしてきた人は学習してしまっています。効率化を進めた分、余計な仕事が割り当てられて、結局はトータルの仕事量は何も変わらず、時間に追われるというケースです。
景気の低迷などにより、どこの会社も現場は時間短縮を強いられるものの、仕事そのものが減るわけではありません。もっと時間が欲しいと嘆きつつ、取り組んだ業務改善で生まれたゆとりの時間……、さぁこれまでできていなかった付加価値を生み出す仕事も着手できるぞと思いきや、余計な仕事を突っ込まれるわけです。結論から言えば、あなたが部門トップや経営者でない限り、これを現場側で防ぐ術はありません。ただし、これまで14回に渡る本連載を読まれて実践をされていれば、「どうすればできるようになるか？」と考える習慣や部門間の連携もできあがっているはずです。したがって、山を越えたときの次の山の高さは高くとも、より容易に超えられるようになっています。
さて、本題に戻します。最初は本社・管理系業務で考えてみましょう。
本社・管理系業務の場合
本社や管理系、いわゆるスタッフ部門の業務は製造現場のようなライン業務とは異なり、大きく分けると“ルーチン業務”と“ルーチン業務以外”に大別できます。
"ルーチン業務以外"は、さらに「企画業務」と「管理業務」に分けることができます。これらの業務は、本社・管理系業務の中でも特に中枢業務として位置づけられます（図）。
図本社・管理系業務
「企画業務」には、戦略立案、経営計画策定などの経営企画業務、アライアンス・提携に関わる調整交渉業務のような全社に影響を及ぼす比較的規模の大きな業務から、事業単位ごとの商品戦略、販売戦略などを練る事業企画、商品企画の業務もあります。
「管理業務」には、専門的知識とスキルにより財務的な計画や運用、全社の人事制度設計、情報戦略立案と運用、重要な法務に関する業務が該当します。
"ルーチン業務"は日常的にそれほど大きな変化がなく、かつ繰り返し発生する比較的単純な定型業務のことを言います。高度なプロフェッショナル性は求められず、作業・処理的な要素が強くなります。また、"ルーチン業務"は先の企画業務や管理業務の中にも存在し、人事部門であれば福利厚生や給与計算業務が、経理部門であれば月々の請求書発行業務などは毎月、同時期に同じ業務を行います。また、どの部門にも共通して、資料収集や庶務的な業務があります。
以上を踏まえ、本社・管理系業務の業務改善の対象は、ルーチン業務が大部分を占めます。ルーチン業務を効率化する際には、一般的に次の視点で考えます。
ルーチン業務の効率化
ルーチン業務の効率化の視点は下記の6つが基本です。
- （1）やめる
- （2）簡素化
- （3）システム化
- （4）集中化
- （5）標準化
- （6）移管
1つずつ、順番に見ていきましょう。
（1）やめる
業務がなくなれば、業務改善の対象の存在がなくなるので、改善をする必要はありません。大事なことは、「なぜ、この業務が必要なのか？」と問い、考えることです。
特に付加価値を生むこともなく、何となく昔からやっていたものの、誰も利用しない社内的なサービス、無意味で複雑な決裁承認や稟議プロセスなどが意外と身近に見つかるものです。
あとは、「やめる勇気と決断だけ」になります。このように書くと、それができれば苦労しないよ！と思われることでしょう。詳しくは後述します。
（2）簡素化
業務をやめることはできないが、簡単にするということです。
手間や工程が減ることでミスやトラブルも減らすことができます。社内で用いている報告書の書式への工夫や、社内回覧を全員に回すのではなく1部だけ誰でも閲覧できるようにすることで無駄が省けます。また、簡素化することで通常はスピードも向上します。
（3）システム化
システムや装置に置き換えられる業務は置き換えます。イントラネットの活用、データや情報の共有を積極的に進めることを検討します。
こう書くと、いかにも教科書的であり、企業実態としては既に一般的な業務に関わるシステム化はほぼ、できあがっています。
ここで考えたいことは、「システムに置き換えられないと思い込んでいる人間系の業務」のシステム化です。現状業務の可視化を最初に行っているので、業務プロセスのどこからどこまでをシステムに置き換えられるか、おおよその見当も付けられるだけの技量は身についているはずです。
（4）集中化
共通点が高い業務、似たような処理のルーチン業務は1ヵ所1部門に集約します。
各事業部で管理や庶務の業務はほとんど変わりませんが、分散して行われているケースが多く見られます。1ヵ所に集約することで、規模の経済性が働き、かつ業務品質も向上します。
大手の企業では関連会社などに対するシェアードサービスの形態で見られます。
（5）標準化
同じ部門で同じ業務を行っているにも関わらず、個々人で仕事のやり方が異なる、いわゆる属人的な状況になっている場合、無駄が非常に多くなります。
表には見えなくとも、周りの人や前後の工程の人が属人的業務を行う人の特性を把握しているので、かろうじて成り立っていますが、業務引き継ぎに苦労をし、部下もなかなか育ちにくい弊害もあります。
属人的になっている業務やルーチン業務は、業務自身を標準化します。もちろん、全ての業務が標準化することで属人化が解消するわけではありません。
具体的には業務マニュアルや指針を作成し、標準業務フローも作成し、その業務で用いられる帳票やデータの書式も統一し、情報システムとも整合させます。標準化を進めることで効率が上がり、最終的にはオペレーション品質も向上します。
一般的に属人的な業務が多いと、システム化と標準化は難しくなります。理由は2つあります。1つは職人・職能的な業務を行う人です。この場合、標準化よりも技能や技術の継承に注力を注ぐべきでしょう。もう1つは、逆説的になりますが、属人を許す・許してきた周囲の環境です。業務標準を作らなかった、人によりバラバラであることを周囲も許してきたなどです。したがって、属人的業務の比率が高い場合は、まずは目に見えないノウハウや知識を暗黙知から形式知にするところから着手します。
第5回の図1のように、業務プロセスを細かくバラすことができないと、属人的な「人によるちょっとした違い」は絶対に可視化できません。
（6）移管
重要度の低い業務、特別高い専門性やスキルを必要としない業務をすべて自社内でまかなおうとすると、人件費率が上がりコスト体質になります。したがって、中枢のコア業務だけを残し、ノンコア業務を外部にアウトソーシングする、正社員でないスタッフに業務を移管するなどします。移管された業務を従来は担当として行っていた人は、より付加価値を生む仕事に職種変換をする、もしくは配置転換を視野に入れます。
教科書的な説明はここまでにして、次により具体的なお話をします。
やめる勇気と決断
職種変換や配置転換できない人がゼロではないので、こういう人をどうしますか？いわば、業務を移管することによって、その人の仕事が会社の中からなくなってしまうのです。「君は明日から仕事はないから」と言われているようなもので、当然ながら業務移管には頑なに反発することは目に見えています。
業務改善で現場が無関心とは異なり、会社は効率化を大義名分にして、大掛かりなリストラ策を行うことがあります。最初はやんわりと子会社への出向、転籍から開始し、最初は社内や関連会社に自分の居場所は確保できたものの、業務を（1）やめる、（6）移管となると、"無関心"から一転して"反発"という行動特性が生まれるので、これらを予測して解決策を準備しておかないと、単純に「やめればいい」「外に出せばいい」という議論にはならなくなります。
開発・設計系業務の場合
開発や設計業務にルーチン業務は少ないと言われていますが、はたしてそうでしょうか？
通常、開発部門における新製品開発プロセスは、製品コンセプトを考え、設計するためにシミュレーションや実験を繰り返し、試作品を作り上げ、生産ラインに乗せます。反面、既存製品のサポートや特注品の対応などによる図面の修正、社内的な打ち合せや手続き業務も少なくありません。
比較的、開発・設計部門、研究開発部門は自由な発想でクリエイティブな製品を生み出すという思想が多く存在することもあり、ある種、聖域のように業務改善や効率化の対象にはなりにくかったのが事実です。
しかし、昨今のように製品のライフサイクルが短くなり、製品機能はますます多様化・複雑化し、開発期間は短縮されてくる中で各社、様々な取り組みを行っています。開発・設計部門の業務棚卸をまずは手掛けてみることで、手続き業務が浮き彫りになります。
（1）部門を分ける
新製品開発と既存製品のフォローを行う部門を分けて、新製品の投入を早めます。
既存製品のフォロー部門はルーチン業務に近くなり、新製品開発部門は研究や開発に専念します。
（2）標準化推進
納期がかかり、かつ高価な特殊部品を使わず、標準的な部品を用いて設計を行います。そのためには、設計段階において、電子部品や部品を組み合わせたユニット部品、ソフトウェアであればドライバなどの標準的なライブラリ、系列的に揃えられた筐体部品などが必要です。設計部門は設計段階からこれらを用いることで、開発期間を短縮することができます。そのためには、部品などの調達を行う購買部門、標準化を推進する部門、これらのデータベースを管理する情報システム部門との連携が全社的に必要となります。標準化を進めることで部品やそれまでの企業資産の再利用性が高まり、購買部門としても一括調達が行え、コストが下がるメリットも生まれます。
（3）仕事のやり方を変える
販売活動は営業部門、市場・競合調査はマーケティング部門と、一般に開発部門までに設計のインプット情報が到達するまでは、多くの部門を通り、かつ長い時間がかかります。場合によっては、途中で情報が歪んでしまうこともあります。
可能な限り、開発部門も顧客に足を運び、かつ市場動向などを把握しておくことで、設計に有用な情報を得ることができます。
このように、一見業務改善や効率化ができないと思われていた業務も、視点を変えることで改善できる領域はたくさんあります。
次回は「仕事のやり方を変える」をテーマにお話します。
