【社内SE・DX担当・部署改善担当 必読】業務フローの「見える化」で、社内に絶対的な居場所をつくる方法
あなたは今、職場で「成果」を出せていると言えますか？
DXを推進しろと言われた。業務改善をやれと言われた。社内SEとして配属された。でも何から手をつけていいかわからない。そもそも自分に何ができるのか、自分が何をすべきなのかが見えない。
私はそういう状況を経験した。
社内SEとして3年間、外資系メーカーの日本法人でひたすら現場に向き合った。そして気づいたら、スイス本社のCIOに成果を認められ、27歳で日本の情報システム部門の部門長になっていた。引き抜きのオファーまでもらった。
特別なスキルがあったわけではない。英語が堪能だったわけでもない。やったことは、ほぼ一つだけだ。
業務フローを「見える化」することを、ひたすら続けた。
これだけで、工場の現場技術者が私に電話をかけてくるようになった。「次工程ってなんだっけ？」という質問が、全社員の質問箱状態に変わった。プロジェクトが立ち上がり、改善が進み、信頼が積み上がった。
この記事では、私がやってきた業務フローの「見える化」を、4つのパートに分けて書く。若手の社内SE、DX担当、または「自分の部署をもっと良くしたい」と思っているすべてのビジネスパーソンに向けた、明日から試せる再現性の高いメソッドだ。
難しいことは何もない。ただ、やっている人があまりにも少ない。
第1章 なぜ業務改善は「テクニックゼロ」でできるのか
業務改善と聞くと、多くの人がこう思う。「難しそう」「特別な知識がいるんじゃないか」「自分には無理だ」と。
でも実際に現場に入ってみると、拍子抜けするくらいシンプルな事実に気づく。
ほとんどの職場では、誰も業務の全体像を把握していない。
これは皮肉でも批判でもなく、純粋な事実だ。工場でも、営業部門でも、人事部門でも、経理でも、状況はだいたい同じだ。業務というのは「後付け」で増えていくものだから、誰も意図して全体を整理したことがない。
最初に1本の業務フローがあった。それに2本目が加わり、3本目が生まれ、どこかのタイミングで「あの業務と似てるよね」という理由で一つにまとめられたり、逆に例外処理が増えて枝分かれしたりしていく。結果として、現場の人間がスパゲッティと呼ぶような、複雑に絡み合った状態ができあがる。
このスパゲッティを「解く」作業に、特別なスキルはいらない。必要なのは、時間と根気と「正確に記録しようとする姿勢」だけだ。
私が社内SE時代に実感したのは、若手だからこそできることがあるということだった。
作業単価が高くないから、時間を使える。社内のしがらみが少ないから、どの部門にも聞きに行ける。「教えてください」と素直に言える立場が、実はものすごい武器になる。業務改善で成果を出せない人の多くは、テクニックが足りないのではなく、そもそも現場に入ろうとしていない。
だから、まず現場に行くこと。それだけが出発点だ。
第2章 業務フローの「見える化」3ステップ
ステップ1 業務を「解いて」、本当の本数を数える
まず工場を例に話す。部署改善を目指す人は、自分の部署に置き換えて読んでほしい。
工場長や部門長に「今、この部門には業務が何本ありますか？」と聞く。たいていの場合、「90本くらいかな」という答えが返ってくる。これが出発点だ。
次に、その業務の資料を一式もらって持ち帰り、1本1本を丁寧に解いていく。
解くというのは、「絡まりを解きほぐす」という意味だ。
業務というのは、追加されるたびに既存のフローにくっついていく。「この工程とあの工程、なんとなく似てるから一緒にしておこう」という判断が積み重なっていくと、本来は別々の業務なのに一つとしてカウントされている状態が生まれる。これを解いていくと、90本だと思っていたものが100本になる。
私の経験では、平均的に言われた本数の2〜3%は増える。最大で100本以上増えたケースもあった。極端に聞こえるかもしれないが、それくらい「業務の実態」と「把握されている業務の数」にはギャップがある。
増えた本数を持って、工場長に報告する。「90本と言っていた業務を丁寧に解いたら、実は100本ありました」という事実を、数字として伝えるだけでいい。
これが第一ステップだ。「見える化」の最初の成果物として、相手に渡せる。
この報告を受けた工場長や部門長は、たいていこう反応する。「そんなにあったの？じゃあ無駄もあるよね」と。ここから次の仕事が自然に生まれてくる。
一点補足しておく。業務フローの本数が極端に少なかった場合は、疑ってかかったほうがいい。
私が人事部門に入ったとき、担当者から「業務は3本だけです。入社登録、退職削除、情報変更の3つ」と言われたことがある。本当だと思って観察を続けたら、入社登録ひとつとっても、面接調整、書類確認、上長への通知、社内システムへの登録、ハローワーク連携など、10本以上の業務フローが見えてきた。人は思っている以上に、多くの業務をこなしている。「少なすぎる」と感じたら、それは見えていないだけだと考えたほうがいい。
ステップ2 共通化してスリム化する
「では、もう少し詳しく解析させてください」と持ち帰り、今度は100本に解いた業務を整理し直す。
ここでやることは一つ。共通している部分を見つけて、まとめ直す。
ただし、元の90本に戻すのが目的ではない。後付けで追加されてきた業務を正しくまとめ直すと、本来くっつけられるはずの業務が浮かび上がってくる。「この業務とあの業務は、実は同じプロセスを経ているよね」という発見が、随所に出てくる。
これを整理していくと、100本が80本になる。場合によっては50本まで減る。
それと並行してやることがもう一つある。「今実際に使われている業務かどうか」を白黒はっきりさせること。
現場にリサーチをかけて、今も動いているものと、事実上使われなくなっているものを仕分けする。使われていないものは捨てる。使われているものだけ残す。
こうして整理すると、90本だったものが70本になる。この「70本になりました」という報告ができた時点で、見える化のパート2が完成する。
「こんなにスリム化できたんだ」「業務がすっきり見えるようになった」という反応が返ってくる。これだけで、相手の中に「信頼」の種が植わる。
ステップ3 業務に「濃淡」をつける
見える化の最後のステップは、業務の頻度に基づいてステータスを振ることだ。
私がよく使う分類はこうだ。
レベル５：毎日やる業務
レベル４：週に数回やる業務
レベル３：週に1回やる業務
レベル２：月に1回やる業務
レベル１：年に1〜2回やる業務
この濃淡をつけた業務フロー一覧を、部門長に見せる。すると、今まで見えなかったものが一気に見えてくる。
「この業務、年に1回しかやらないのに、手順が複雑すぎる。マニュアル化したほうがいいな」とか、「このレベル5の業務、人が3人もついてるのはおかしいよね」とか、「ここ、デジタル化したら相当ラクになるんじゃないか」という声が、自然に出てくる。
それがプロジェクトの種だ。
さらに凝って作りたいなら、各業務にかかる工数やコストを載せると、重要度マップとして完成する。どこに人が集中しているか、どこが改善余地の大きいボトルネックかが一目でわかる業務フローマップができあがる。
ここまで来ると、工場長や部門長から具体的なフィードバックがもらえる。
そのフィードバックをメモして、自分の上司に「こういう活動をして、現場からこういう反応をもらいました。うちでプロジェクトとして動かしてみませんか」と提案しに行く。
これが、質の高い企画書・提案書の材料が揃った瞬間だ。
特別なスキルは何もいらない。ごちゃごちゃに絡まったスパゲッティを解いて、同じところをくっつけてスリム化して、濃淡を見せてあげる。すべて既存の事実だけで完成する。これが業務フローの見える化3ステップだ。
第3章 「社内で一番、業務がわかる人間」になったとき、何が起きるか
この3ステップを一つの部門でやり遂げると、次の部門で繰り返したくなる。コールセンターでやる。営業部門でやる。工場のあのラインでやる。繰り返していくと、ある時点で気づく。
自分が、社内で一番業務を知っている人間になっている。
私がそのポジションに達したとき、ある日一本の電話がかかってきた。
工場の加工ラインで長年働いている技術者からだった。
「今、新しい品目を作ってるんだけど、次工程ってなんだっけ？」
という質問だった。
驚いた。現場を誰よりも知っているはずの職人さんが、私に聞いてくる。
理由を聞いたら、こう言われた。
「現場の僕たちは、自分の担当ラインのことはよく知ってる。でもそれは点の知識だ。あなたはそれを線でつないでいる。だから聞きやすい」
業務の全体像を知っているということは、部署を超えた「つなぎ役」になれるということだ。この役割は、組織の中で思った以上に希少だ。
そこから先は加速した。業務改善の相談だけでなく、「この作業がめんどうで」「この手順、どうにかならない？」という日常の困りごとが集まってくるようになった。VBAのマクロで解決できるのか、それとも大規模な対応が必要なのか。自分の裁量で考えて提案できる案件が増えていった。
一年間、これを愚直にやり続けると何が起きるか。
社内での信頼度が劇的に変わる。「あの人に聞けばわかる」という存在になる。仮にプロジェクトが一つも立ち上がらなかったとしても、「社内で一番業務がわかる人間」というポジションは必ず残る。これは誰にも奪えない資産だ。
同じことをお客さん相手にやると、「またあなたにお願いしたい」というリピートに変わる。私はERPコンサルとして現在も、この「業務を解く」アプローチを使い続けている。SAPやSalesforceの導入案件でも、まずやることは変わらない。お客さんの業務フローを1本1本解いて、現状を正確に把握することだ。システムはその後でいい。業務を知らずに入れたシステムは、いずれまたブラックボックスになる。
そして失敗したとしても、得られる副産物はでかい。種をまき続けた結果、プロジェクトが一つも芽を出さなかったとしても、業務を徹底的に調べた記録と、現場との関係性は残る。どんな結果になっても、マイナスは絶対にない。
第4章 「まずツールを作ろう」という考え方の、ひとつの落とし穴
AIが仕事を変えると言われている。自動化、効率化、内製ツール開発。新しいキーワードが次々と生まれ、「DXと言えばシステム構築」という空気が強い。
私もAIを使う。毎日使う。業務の生産性は確かに上がっている。
だから言えることがある。ツールは「業務の後」でいい。
社内SEやDX担当、あるいは「自分の部署を改善したい」と思っている人が、最初にシステムやツールを作ろうとする場面を何度も見てきた。気持ちはわかる。作ることが楽しいし、成果物が目に見えるし、「自分がやった」という実感が持てる。
でも、業務フローが整理されていない状態でツールを作ると、何が起きるか。
ブラックボックスが増える。
業務が複雑に絡み合っているスパゲッティの上に、新しいスパゲッティを重ねることになる。最初は便利に見えても、半年後、一年後に「このツール、なんのためにあるの？」という状態になりやすい。内製ツールの多くがこの運命をたどる。
業務を改善する立場にある人間が、まずやるべきことは「紐解く」ことだ。絡まっているものを解いて、実態を把握して、何が必要で何が不要かを整理する。その上で初めて、どんなツールが必要かという議論が始まる。
外部から調達するツールなのか、既存のSaaSで対応できるのか、それとも小さな内製ツールで十分なのか。業務の実態を知っていれば、その判断が格段に正確になる。逆に知らなければ、ツールを入れるたびに「なんか使いにくい」という不満が積み上がっていく。
AI時代だからこそ、「業務を知っている人間」の価値は上がっていく。ツールを使いこなせる人は増える。でも、業務の全体像を把握して、何を変えるべきかを判断できる人間は、それほど増えない。
だから今、業務を解く力を身につけておくことが、長期的に効いてくる。
おわりに 一年間で、景色は変わる
ここまで書いてきたことを、一言でまとめるとこうだ。
業務フローを解いて、見える化することを、一年間やり続けなさい。
技術は関係ない。経験年数も関係ない。英語力も、資格も、出身大学も関係ない。
現場に行って、話を聞いて、業務を1本1本解いて、正確に記録する。それを報告する。フィードバックをもらう。次の部門でまた繰り返す。
これだけで、一年後には「社内で一番業務がわかる人間」になれる。プロジェクトの提案ができるようになる。現場の人間が自然と相談しに来るようになる。上司から信頼される。お客さんからリピートされる。
私が27歳で部門長になれたのは、特別な才能があったからではない。誰よりも現場に入って、誰よりも業務を解き続けたからだ。
一年間、騙されたと思ってやってみてほしい。
やってマイナスになることは、本当に何もない。
