システム部門は業務を知らず、業務部門はシステムを知らず

現在オペレーションと呼ばれる業務はすべてシステム側で自動的に処理をしてくれる。AIの発達で、そんなことが実現するのはそんなに遠い未来のことではないでしょう。ただ、2018年の現時点のおいて、それを実現することはほぼ不可能です。まったくシステムを使っていない業務はほとんどないと思いますが、逆に人の手をまったく介さずに処理できる業務もほぼ存在しません。

インターネットやクラウドが当たり前になってきたことで、業務におけるシステムの活用範囲は広がっています。しかし、システム開発部門やITベンダー（以下「システム部門」）は相変わらずシステムの話しかせず、業務部門は今やっているオペレーションの話をするばかり。両者で一緒に新しいシステムとオペレーションを作っていこうという感じは見えません。

業務部門とシステム部門が一体になった業務効率化をしていくためにどうすればいいか、という部分について、今回は書いてみたいと思います。以下がアジェンダです。

———
1.業務部門の問題
　(1)属人化
　(2)マニュアルの形骸化
　(3)根幹の問題を放置する
　(4)仕事のやり方を変えることができない
2.システム部門の問題
　(1)言われたものしか作れない
　(2)業務の表層しか理解できない
3.今のやり方はベストではない
　(1)共通のゴールを設定する
　(2)まずはセオリーを重視する
4.まとめ
———

1.業務部門の問題

（1）属人化

古くて大きな企業ほど、アナログで人に依存したオペレーションが未だに根強く残っています。とある大企業の経理部では、通常のマニュアルとは別にイレギュラー対応を処理するための手順が手書きのノートで何冊も存在していて、ベテランの人が重宝され、新人は1つずつそれらの処理を覚えていくしかない状態だそうです。まるで伝統工芸の職人のように、一人前になるのに何年もかかるような世界が、まだまだ企業のバックオフィスには存在しているのです。

手書きのノートは少し極端な例かもしれませんが、多くの企業のバックオフィスには生き字引のような社員さんがいて、その人がいるから回っている部分も多いはずです。いわゆる属人化です。1つずつカスタムオーダーで仕上げなければいけない物作りでないにも関わらず、「その人にしかできない（分からない）業務」が存在することが、業務効率化に対して大きなボトルネックになっていることが非常に多くあります。

確かに、今は業務が属人化した状態でも回っているかもしれません。しかし、属人化は処理量が増えたときには簡単にパンクしますし、人が辞めたとたんにミスが多発するという非常に脆弱な仕組みなのです。

（2）マニュアルの形骸化

業務をしっかり回していく上で、手順は非常に大事です。問題は、マニュアルなどの形にしっかり落とし込まれていたとしても、時間が経つにつれてそのマニュアルが形骸化してしまうことです。

マニュアルを最初に作る際、普通はある程度の経験のある人が「たぶんこんな感じ」という想定も含めて作成していきます。その後数回はアップデートされるかもしれませんが、慣れてくるほどにいちいちマニュアルを見ながら作業をしなくなるということもあり、アップデートが止まったまま放置されるケースがほとんどです。

で、そうなると、運用自体は回っていますが、マニュアルにはない独自のアレンジやショートカットを加えたり、本当はやった方がいいけど省いてしまっている工程などが出現します。結局は「属人化」に繋がっていくのですが、マニュアルと実際の運用が異なると、その人にしか分からない領域がますます広がっていくことになります。

（3）根幹の問題を放置する

業務部門は、いつも業務に追われています。明確に期限がある定型的な業務は無数にあり、それに加えて突発的な仕事も多数発生します。よくあるのは昼間はとにかくトラブル対応や社内からの「ちょっといい？」に時間を取られて、やらなければならない定型業務に取りかかれるのは夜になってからというパターン。こうなってしまうと、とにかく目の前のことを対応するのが精一杯で、一生懸命働いているのにいつまで経っても楽にならないという負のスパイラルに陥りがちです。私はこういう働き方を「モグラ叩き」と呼んでいるのですが、ひたすら飛び出すモグラ（トラブル）を叩きまくる、というか叩くことしかしていない働き方です。経理とか総務って結構そういう人が多いのではないでしょうか。

この状態がたちが悪いのは、本人が事をした気になってしまう、ということです。いつも忙しく動き回っていますし、夜も遅くまで働いています。周囲も「あの人はよく働くよね」と思っているはずです。ただ、この状態が長く続いていると、モグラを叩くことそのものが仕事の目的になり、モグラが出現しないようにする、という発想すらなくなっていきます。仕事の仕方も受動的になりますし、常に色んなところでトラブルが発生しますので、働けど働けど、いっこうに楽にならず、という状態です。

（4）仕事のやり方を変えることができない

マニュアルは形骸化し、仕事はどんどんと属人化していきますが、その担当者が根幹の問題を解決しようとしないので、いつまで経っても仕事は減らず、現場はいつもドタバタしています。とにかく仕事に追われているので、仕事のやり方を変えたり改善しようとする余裕がありません。こういう現場にいる人には2種類いて、前述したように変えようという発想すらない人と、何とかしたい変えたいと思っているけれどその時間も動きも取れないという人です。私がコンサルティングの相談をもらうのは基本的には後者の人で「なんとかしたいが、そのリソースもノウハウもないので手伝って欲しい」というパターンです。

さて、私のコンサルの話は置いておいて、この状態でシステム部門に依頼する社内システムの要件はどうなるでしょうか。目の前の業務を処理するという手段の部分にスポットがあたり、とにかく作業を楽にするために現在は人がやっている作業をシステムに置き換える、という要件になるはずです。しかし、属人化が進んでいる現場の処理はイレギュラーだらけで、システムで処理しようとする要件がものすごく複雑で高度になります。そして、工数や開発費は膨らみ、色々な機能を削ったり、「ここは手作業でお願いします」という部分を作ったりすることで帳尻を合わせます。結果、システム対応をしたけどあんまり効率化はされなかった、もしくは「柔軟性がなくなって困る」という不満が現場でる始末。簡単に言えば「今回のシステム導入は失敗だったね」という結論になります。

2.システム部門の問題

（1）言われたものしか作れない

システム部門は基本的には受け身です。「こうすればもっと良い状態になりますよ！」という提案を自らすることはほとんどありません。基本的には、言われたものを作ることしかできません。

会計、給与計算、顧客管理などの業務系システムはデータベースの構成が複雑になりますが、業務側がそれらを扱えるようにするためにはシンプルなUIや操作性を実現する必要があります。これは結構難易度が高く、何を（what）どのように（how）の部分だけでなく、なぜ（why）そうするのかを開発する側が理解していないと実現できない、と私は思っています。

しかし、要件を出す側である業務部門が前述の通り目の前のモグラ叩きしかできない状態では本質的な課題解決ではなく、「とにかく目の前の問題を何とかして欲しい」という依頼になりがちです。そのような依頼を受けた際に「なぜそれは起こるんですか？」「そのやり方で昔からやっている理由はなんですかか？」などの質問をぶつけて掘り下げていければいいのですが、システム部門にそのような役割の人がいることはほぼありません。

システムを開発したり、新しいシステムを導入したりするのは、何らかの課題を解決するためであるのは自明ですが、作ること・導入することが目的になってしまっているので、「何のためにやるのか」は置き去りにされ、とにかく言われたものを一生懸命作ろうとしてしまうのです。

（2）業務の表層しか理解できない

組織は大きく複雑になり、役割は細分化されていきます。システム部門で業務部門の仕事をしたことがある人はほとんどいないでしょうし、逆に業務部門でシステム部門の経験がある人もいないでしょう。

何度も打ち合わせを重ね、ドキュメント化をして双方で内容を確認し、という工程を経てプロジェクトは進められるのですが、それでもお互いに表層しか理解できていません。業務部門はモグラ叩きで忙しいので、システムのことを考える余裕なんてありませんし、特に日本においてはなぜかシステム部門を下に見る傾向があって、「いいから（言われたものを）ちゃんと作っておけばいいんだよ」となりがちです。

そうなると最後の砦はシステム部門が業務を理解することなのですが、これは言うは易く行うは難しです。ヒアリングをすることで業務の流れは理解できたとしても、実際に自分で手を動かしてみないと本当の意味で業務を理解したということにはなりません。本を読んで分かったような気になっても、実際に実行に移そうとするうまくいかないことに似ています。

この境界線を越えるための工夫をしている会社もあります。freee社では、入社した社員はすべて経理部門で数ヶ月仕事をした上で営業や開発などに配属されるそうですし、オートマチック社のトライアル採用は必ずカスタマーサポート部門の業務で行うようです。いずれも自社顧客（freee社は経理部門、オートマチック社はWordPress利用者）を理解するための施策ですが、このように実際に手を動かしてやることに意味があります。逆に言えば手を動かしたものしか理解したとは言えません。

つまりは、システム部門が業務を理解するのは現実的にはかなり難しいということになります。

3.今のやり方はベストではない

(1)共通のゴールを設定する

さて、ここまでの現状分析で業務部門がシステム部門に適切な依頼を出すことは難しく、システム部門が業務を理解することも難しい、ということを書いてきました。それらを踏まえて、ここから業務部門とシステム部門が一体になって業務効率化をしていくためにどうすればいいかを考えていきたいと思います。

まず、大前提の確認ですが、ゴールは「新しいシステムを導入すること」ではありません。企業における意思決定プロセスの関係で、予算を取ってシステムを導入する、という流れになることがほとんどなので、導入することが目的のように思ってしまいがちですが、それはあくまでも手段であって、目的は「請求書発行業務を効率化する」であったり、「顧客データをきちんと管理できるようにする」であるはずです。

「業務部門は要件をころころ変えるから困る」とか「システム部門は業務側の事情も知らずに柔軟性のない仕組みを押しつける」とか、お互いにいがみ合っていても仕方がありません。自分の立場ややり方をぶつけ合うのではなく、「現状の問題をきちんと認識し、それを解決するために知恵を出し合う」という形になるように、双方ともに手を取り合って前に進めるための共通のゴール設定が必要です。

議論する際も「業務部門vsシステム部門」ではなく、「業務部門＆システム部門vs課題」という形で課題を解決するために共同戦線を張るというアプローチでなければいけません。そのために重要なのは、現状の詳細な把握と「なぜそのような仕様（やり方）になっているのか」を批判や思い込みなしで全て議論のテーブルに上げてしまうことです。

システムも業務運用も制約事項がまったくないという状況の方が少ないと思います。特にリソースや予算が少ない中でこれまでは仕方がなくこの状態になっている、という場面も多いので、「今がこうなっている」というところから一歩踏み込んで「なぜそうなっているか」をきちんと掘り下げていきましょう。

過去は変えられません。そこは事実として認識し、そこから課題を抽出し、それをどうやって解決するかという部分にフォーカスすることで、「私たちで課題を解決する」という意識になって取り組めると思います。それが双方にとっての共通のゴールになるのです。

（2）まずはセオリーを重視する

次に課題を解決する際のアプローチについてですが、まずはその分野におけるセオリーと呼ばれるやり方に沿ったものにすることをオススメします。近年はクラウドやSaaSが爆発的に広がったことにより、「システム開発側が想定している使い方（セオリー）に従って運用を組み立てる」という考え方が少しずつ広がってきましたが、まだまだ「当社は独自のやり方があるんだ！」という形で仕様を決める会社が多いように感じます。

世の中でセオリーやベストプラクティスと呼ばれるものがその形で残っているのには理由があります。端的に言えばそれが「最も効果的なやり方」だからです。先人達がトライ＆エラーを繰り返し、やっとの思いで構築してきたセオリーが自社にとってベストかどうかは分かりませんが、少なくとも現状よりはベターである可能性の方が高いはずです。SaaSを使うかどうかにかかわらず、業界内で「成功事例」や「セオリー」として共有されている方法をまずは実践してみることが、改善への近道だと私は考えています。

私がコンサルティングをする場合も、最初は自分たちは独自のやり方だと思っていても、徹底的に業務フローを見直していくと、結局はセオリーに落ち着く、というケースが非常に多いのです。つまりは最初から「独自のやり方」などではなく、既に先人達が失敗したやり方をやっていただけに過ぎず、仮説・検証がすんでいるものを単に自分たちが追体験しただけということになり、完全に時間とリソースの無駄遣いです。安易に「成功事例」に飛びつくことが必ずしもいいとは言えませんが、「セオリー」と呼ばれるものをまずはしっかりと実践してみることで多くの問題が解決することも事実です。

武道の教えなどで「守破離（しゅはり）」という言葉がありますが、独自のアプローチを試みる前にまずはセオリーを重視してみましょう。暗中模索で、手当たり次第にやってみて失敗するよりも遙かに短い時間で解決策が見つかると思います。セオリーを実践した後に、自分たちなりの改善策を付け加えればいいのです。また、セオリーをまずは実践する、という共通認識がシステム部門・業務部門双方にあれば、業務の改善はずっとやりやすくなるでしょう。

4.まとめ

組織が小さいうちに、システムや運用を見直すのはそんなに難しくありません。ただ、規模が小さいときには、間違ったアプローチで構築されたものであっても現場の力技でなんとか運用をまわすことができますし、給料に数十時間のみなし残業が含まれることが当然の状況では、現場の負担はあまりコストには跳ね返ってこないので、問題が顕在化しにくく、非効率な独自のやり方が放置されてしまいます。

そのしわ寄せが一気にくるのが、売上が増えてきたタイミング、つまり事業がうまくいきはじめたときです。色々なものがうまく回り始め、事業の注目度があがり、問合せや売上も急拡大していく中、当然に営業スタッフは増員されていくのですが、バックオフィス側の仕組みは旧態依然としたままで放置されがちです。量が少ない場合は現場の踏ん張りでなんとかなったものが、圧倒的な業務量は頑張ってどうにかなるレベルを超え、ミスが頻発するようになり、現場はどんどん疲弊していきます。

こういう企業を私はたくさん見てきました。事業が拡大するのは非常に喜ばしいことですが、それを支えるバックオフィス側が進化しないと、その業務量に押しつぶされてしまう、という悲劇が起きます。そのためにはシステム部門・業務部門双方が共通したゴールを見て、業務フローとシステムを改善していくしかありません。そのためには「昔はこうだった」「これまではなんとかなった」という幻想を捨て、セオリーに従ったやり方でゼロから全てを見直すしかないのです。

業務改善のために、システム部門vs業務部門ではなく、少しでも多くの企業でシステム部門・業務部門双方が手を取り合っていけるようになることを願っています。