#業務設計者論｜名前のない職能に輪郭を与える

はじめに：業務をする人ではなく、設計する人

私はこれまで、製造業の現場で設計や管理、DX推進、情報システムといった様々な立場を経験してきました。
その中で、いつも拭いきれない違和感がありました。
それは、「業務を設計する」という役割が、組織の中でどうにも曖昧なままになっているという事実です。

たとえば、高価なシステムを導入したはずなのに、気づけば現場は元の使い慣れたExcelで裏作業をしている。
あるいは、会議で運用ルールを決めたはずなのに、誰もその通りに動かない。
こうした現象に出会ったとき、私たちはつい「現場のリテラシーが低いからだ」とか「システムの使い勝手が悪いからだ」と、誰かのせいにしたくなります。

けれど、本当は誰も悪くありません。
システム（論理）と現場（感情）の間にある断絶を埋める役割が、すっぽりと抜け落ちているだけなのです。

業務設計者とは、業務そのものをする人ではなく、設計する人です。
現場の業務とITのしくみの間に立ち、業務フローや情報連携を再構築する存在です。

業務設計者の役割とは

業務設計者は、現場とITの翻訳者です。
現場の「こうしたい」という曖昧な言葉を、システムが理解できる条件に変換する。
逆に、システムの冷たい仕様や制約を、現場が納得して動ける運用ルールに翻訳して伝える。

その過程で、属人化して見えなくなっていた業務の流れを整理し、再現性のあるしくみへと組み直していきます。
たとえば、現場の声を拾い上げながら、ノーコードツールを活用して業務フローを可視化し、システムと接続していく。
あるいは、部署間で途切れていた情報のリレーを設計し直し、小さな改善が組織全体に定着するように支援する。

こうした取り組みは、単なるツールの導入やマニュアル作成ではありません。
人とシステムが無理なく共生するための、しくみの設計そのものなのです。

なぜこの職能が見えにくいのか

これほど重要な役割であるにもかかわらず、業務設計者の仕事は組織の中で正当に評価されにくいという現実があります。
それは、成果物が目に見えにくいからです。

プログラミングのように明確なコードが納品されるわけでも、営業のように売上数字が出るわけでもありません。
私たちの成果は、「なぜか仕事がスムーズに回っている」「現場の納得感がある」「運用が止まらない」といった、静かな状態（質）としてしか現れないのです。

また、既存の組織図や職種分類では、この役割の居場所がありません。
「業務に詳しい担当者」か、それとも「ITに強い技術者」か。
どちらかの箱に無理やり振り分けられてしまう結果、業務設計という独自の職能が埋もれ、評価の網の目からこぼれ落ちてしまっているのが現状です。

言語化することで、職能は立ち上がる

だからこそ、私は「業務設計者」という職能を言語化し、形を与えることに取り組み始めました。
それは、私自身の立ち位置を確かめるためでもあり、同じように組織の狭間で孤独に翻訳を続けている方々が、自分の仕事に誇りと名前を持てるようにするためでもあります。

職能は、言語化されて初めて社会的に認知され、評価の対象となり、次の世代へと育成されていきます。
この発信は、そのためのささやかな第一歩です。

次回予告：業務設計者がDX定着に果たす役割

次回は、「業務設計者は、DXの定着にどう貢献できるのか？」というテーマでお届けします。
業務とITの間に立つ翻訳者としての視点から、DXがただのツール導入で終わってしまう理由と、その推進の本質に迫っていきます。

さらに深く「しくみのスキマ」を覗き込みたい方へ

この、名前のない職能や、組織の構造的なズレについて、より解像度を上げて思考したい方へ。以下の記事を案内します。
システムと現場の板挟みに悩み、自分の役割の正体を知りたい方へ
板挟みの正体は「能力」ではなく「構造」にある─上司の数字と現場の感情を翻訳するコスト

ITでも現場でもない「境界」に立つことの哲学と、その必然性に触れたい方へ
スキマから見える業務のかたち＃1 ｜なぜ業務設計者は“境界”に立つ必然があるのか

言葉は通じているはずなのに、なぜか現場の仕事がズレていく構造を解き明かしたい方へ
なぜ話は通じているのに、仕事はズレていくのか─ マネジメントやDXが空回りする本当の理由