前回の記事では、DXやAI導入がうまくいかない背景として、システムを導入する前に「業務のバグ」を直す必要があることを見てきました。どれほど高機能なシステムを導入しても、業務そのものがスパゲッティ化（複雑化）していれば、期待した効果は得られません。これは特定のシステムや技術が悪いという話ではなく、土台となる業務の構造が整理されていないことが原因です。

多くの企業では、課題が見つかると「新しいシステムを入れれば解決するのではないか」「⁠AIを使えば効率化できるのではないか」と考えがちです。しかし実際には、その前提となる業務の流れや役割分担、判断基準が曖昧なままでは、どんな技術を投入しても効果は限定的になります。テクノロジーは魔法の杖ではなく、あくまで設計された業務を支える手段にすぎません。

実際の現場では、「⁠仕様が曖昧なまま開発が始まる」「⁠業務の前提が途中で変わる」「⁠部署ごとに言っていることが違う」といった状況に、違和感やストレスを覚えたことのあるエンジニアも多いのではないでしょうか。議事録や仕様書を何度読み返しても、全体像が見えないまま実装に入らざるを得ない。そんな経験を積み重ねてきた人も少なくないはずです。その違和感は、業務が構造として破綻していることに気づいている証拠でもあります。業務がきちんと設計されていない状態では、システムにしわ寄せが来る。そのことを、エンジニアの皆さんは現場で何度も体感してきたと思います。

では、こうした業務を構造として整理する視点は、どこから生まれるのでしょうか。業務部門の担当者は、日々の仕事を「慣れ」や「経験」で回しています。その結果、個々の作業は回っていても、業務全体を構造として見直す機会はほとんどありません。問題が起きてもその場しのぎで対応され、根本的な設計には手がつかないままになりがちです。

実は、ここにエンジニアの思考が活きる余地があります。業務設計の主役はあくまで業務側ですが、エンジニアが日常的に行っている「複雑な対象を分解し、構造化し、抽象化する」思考は、業務を整理する場面でもそのまま応用できるのです。

1. エンジニアの「構造化能力」は最強の武器

「点」で見る業務側と「線と面」で見るエンジニア側

業務側では、業務を「タスク（点⁠）⁠」の集合として捉えがちです。「⁠この作業を終えたら次へ進む」「⁠この書類を作ったら完了」といった手順の話が中心で、その前後で何がインプットされ、何がアウトプットされているのかまで深く意識されることは多くありません。その結果、作業単位では説明できても、業務全体の流れを説明できる人はほとんどいない、という状態が生まれます。

このような状態では、業務改善を行おうとしても、どうしても局所的な話になりがちです。特定の作業を効率化したり、システムで置き換えたりしても、その前後の工程との関係が整理されていないため、全体としてはかえって分かりにくくなることもあります。

一方、エンジニアはシステムを設計する際、必ずデータの流れという「線」を意識します。どこから入力され、どこで加工され、どこへ渡されるのか。さらに、それらが集まったときにシステム全体として整合が取れているかという「面」まで視野に入れます。部分最適で動く処理を積み重ねても、全体としての成果は最適化されにくいことを、多くのエンジニアは経験的に知っています。

業務を点でしか見ていない状態では、改善を積み重ねても全体は良くなりません。むしろ、部分的な改善が別の場所の負荷を増やし、かえって複雑さが増すこともあります。一方、線と面で捉え直すことで、ムダや矛盾、重複、抜け漏れが自然と浮かび上がってきます。この視座の違いこそが、エンジニアの思考が業務設計に活かせる大きな理由です。

※ ここで述べていることは優劣の話ではなく、業務を見る際の「視点の違い」です。両者がこの違いを理解し合うことが、協働した業務設計の出発点になります。

「モジュール化」と「責任分界点」の思考

業務がスパゲッティ化する大きな原因の1つは、誰が何に責任を持つのかが曖昧なまま運用されていることです。特定の人に業務が集中し、「⁠その人に聞かないと分からない」「⁠その人が休むと止まる」といった状態が生まれます。システムで言えば、1つの巨大な神クラス（God Class）が、あらゆる処理を抱え込んでいる状態とよく似ています。

こうした状況は、担当者の頑張りによって一時的に支えられていることが多く、問題が見えにくくなりがちです。しかし、その人が異動したり退職したりした途端、業務が回らなくなる。このリスクは、どの組織にも潜んでいます。

エンジニアはこうした状況を避けるために、「⁠関心の分離」や「モジュール化」を行います。責務を明確にし、変更の影響範囲を限定することで、システム全体の保守性や拡張性を高めていきます。この考え方は、業務設計にもそのまま適用できます。

業務を機能ごとに切り分け、どこまでが誰の責任なのかを明確にする。必要以上に密結合になっている部分をほぐし、疎結合な状態を作る。この整理が進むだけで、属人化や引き継ぎの問題は大きく改善されます。業務が「人」ではなく「構造」にひもづくようになるからです。こうした設計感覚は、エンジニアが日常的に使っている思考法であり、業務設計の場面でも有効に働きます。

2. 実は同じ方向を向いているドメイン駆動設計と業務設計

前章で述べた構造化の思考と強く共鳴するフレームワークが、ドメイン駆動設計（DDD）です。ここからは、少しだけ設計の話に寄り道します。DDDは高度で難解な設計技法として語られることもありますが、その中心にあるのは「業務をどう理解し、どう分解し、どう整理するか」という姿勢です。業務設計とDDDはまったく同じものではありませんが、向いている方向は驚くほどよく似ています。コード設計の話に見えますが、その土台にあるのは業務理解そのものです。

DDDが重視するのは、技術的に正しい設計よりも、業務の実態を正しくとらえることです。業務を理解しないまま作られたシステムは、使いにくく、例外処理が増え、やがて複雑化していきます。これは、エンジニアであれば誰もが一度は経験していることでしょう。

共通言語を作る 〜 ユビキタス言語の威力 〜

業務の現場では、同じ言葉が部署ごとに微妙に違う意味で使われていることが少なくありません。たとえば「顧客」という言葉1つ取っても、営業では見込み客や過去の取引先を含めて指す一方、経理では請求先として登録された相手だけを指す、といった違いがあります。このズレは、普段の会話ではあまり問題にならなくても、システム化の段階で一気に表面化します。

こうした状態のままシステムを作れば、どこかで必ず不整合が生まれます。仕様書の行間を埋めるために、エンジニアが暗黙の判断を積み重ねることになり、結果としてバグや手戻り、想定外の運用が増えていきます。トラブルが起きたときに「仕様通りです」「⁠いや、業務ではこうです」という不毛なやり取りが発生するのも、この構造が原因です。

DDDにおけるユビキタス言語とは、業務上の言葉の意味を定義し、関係者全員が同じ前提で会話できるようにするための考え方です。これはシステム設計を円滑にするためだけでなく、業務そのものを整理し、共通理解を作るうえでも欠かせない取り組みです。業務側とエンジニアが同じ言葉で話せるようになることで、議論の質そのものが変わっていきます。

組織の壁を越える 〜 境界づけられたコンテキスト 〜

前回触れたコンウェイの法則が示す通り、組織の構造は業務やシステムにそのまま反映されます。部門ごとに最適化された業務は、それぞれの内部ではうまく回っているように見えても、全体として見ると分断され、複雑さを増していきます。部門間の調整が増え、「⁠例外対応」や「特別ルール」が積み重なっていくのも、この延長線上にあります。

この複雑さを整理するための考え方が、境界づけられたコンテキストです。どこまでが販売の文脈で、どこからが請求の文脈なのか。どの範囲で用語やルールを共有し、どこから先は別の前提で動くのか。境界線を引くことで、複雑性を閉じ込め、変更の影響範囲を限定できます。

ここまで見てきたように、DDDで語られるユビキタス言語やコンテキストの考え方は、単なる設計技法ではありません。業務をどう分け、どこに線を引き、どの単位で責任を持つのかという、業務設計そのものに深く関わる視点です。

DDDの知見を業務設計の場でどう活かすか

では、こうしたDDDの考え方を踏まえたとき、エンジニアは業務設計の場で何を意識すればよいのでしょうか。ここからは、視点を一段引き上げて考えてみましょう。ここで重要なのは、エンジニアが業務設計の主役になることではありません。あくまで主役は業務側であり、エンジニアはその議論を前に進めるための触媒として関わることが求められます。

たとえば、業務の議論が個別の作業や例外対応の話に終始しているときに、「⁠その前後では何がインプットされ、何がアウトプットされていますか」「⁠この判断は、どの範囲で共通のルールとして扱うべきでしょうか」と問いを投げる。あるいは、「⁠ここまでは同じ文脈で考えられそうですが、ここから先は別の前提で分けた方がよさそうですね」と境界を示す。こうした関わり方は、DDDで培われた思考を、そのまま業務設計に持ち込んだものです。

エンジニアが業務設計に関わる価値は、答えを出すことではなく、構造を浮かび上がらせることにあります。業務側が日々の経験として持っている知識を言葉と構造に変換し、全員が共有できる形に整える。そのプロセスにエンジニアが参加することで、業務要件が構造化され、明確になっていきます。

このように考えると、DDDは「エンジニアのための設計手法」であると同時に、「⁠業務設計の議論に参加するための思考の型」でもあります。次は、この視点を踏まえたうえで、エンジニアがどのように業務設計に関わり、自身の役割を広げていけるのかを、さらに具体的に見ていきます。

3.「実装者」から「アーキテクト」へ

コードを書く前の「上流工程」にこそ価値がある

AIによるコーディング支援が急速に進化する中で、エンジニアの価値は「どう実装するか」だけでは測れなくなってきました。生成AIによって、経験の浅いエンジニアでも一定の実装ができるようになるでしょう。しかし、「⁠何を作るべきか」「⁠どこに手を入れるべきか」という判断は、やはりAIには代替できません。

現場によって状況はさまざまですが、エンジニアが仕様書や要件定義書を起点に開発を進めるケースは少なくありません。その中には、業務の背景や本来解決したい課題まで十分に共有されないまま実装に入らざるを得ない場面もあります。その結果、「⁠要件通りには作ったが、実際の業務では使いづらい」「⁠後から前提の見直しが必要になる」といった手戻りが発生することもあります。

ここで重要になるのが、コードを書く前の段階、つまり業務そのものを見直す視点です。これは本記事で最も伝えたいポイントの1つでもあります。言われた通りの仕様を実装するのではなく、その仕様が生まれた業務プロセスを分解し、整理し、再設計できないかを考える。これは、実装前に行う業務のリファクタリングとも言えます。業務が整理されていなければ、どれだけきれいなコードを書いても、成果にはつながりません。

業務設計を実践するためには、会議や調整も多くなり、必ずしもスマートには進みません。利害関係が絡み、抽象的な議論が続くこともあります。しかし、構造を描き、境界を引き、複雑さを制御するという点では、やっていることはアーキテクチャ設計と本質的に同じです。対象がコードか業務かの違いでしかありません。エンジニアが培ってきた思考は、ここでも十分に活かすことができます。

『業務設計の教科書』を共通言語にする

ただ、多くの場合、業務側にいきなり「DDDをやりましょう」「⁠業務を構造化しましょう」と伝えても、すぐに理解してもらえるとは限りません。エンジニアの思考法と、業務側の日常言語との間には、少なからずギャップがあります。そのギャップを埋めるためには、両者が立ち返れる共通の土台が必要です。

拙著『業務設計の教科書』は、DXやAI導入に取り組む前に、「⁠そもそも仕事はどのような構造を持っているのか」「⁠業務をどう分け、どうつなげばよいのか」を、業務の言葉で整理した一冊です。INPUT・DO・OUTPUTで業務をとらえる考え方や、業務の地図を使った全体把握、属人化を防ぐための業務の分け方など、システム導入の上流工程で必要になる視点を体系的にまとめています。

本書を通して業務部門と情報システム部門、あるいはエンジニアと非エンジニアが、「⁠どこが問題なのか」「⁠何を整理すべきか」を構造で共有できるようになる。その状態を作るための補助線として活用していただきたいと考えています。

まとめ

業務設計は、エンジニアにとって未知の領域ではありません。本記事で見てきたように、これまで培ってきた構造化思考や抽象化のスキルの延長線上にあります。業務に踏み込むことは、専門外に手を出すことではなく、自分の得意領域を広げることでもあります。

DXやAI導入に注目が集まる中で、テクノロジーやシステムが重要であることは言うまでもありません。そのうえで、それらを最終的な成果につなげるためには、土台となる業務の構造が整理されていることが欠かせません。だからこそ今、「⁠それを支える業務の形」が改めて問われています。業務側が主役となって業務を設計し、エンジニアが同じ認識を持ってその議論に参加する。そんな関係性が築けたとき、システム開発は単なる実装作業ではなく、事業を前に進めるための設計行為へと変わっていきます。

『業務設計の教科書』は、そのための考え方や視点を、手を動かしながら学べるようにまとめた一冊です。システム開発や導入の上流工程に関わるエンジニアや情報システム部門の方にとっても、「⁠業務を見る目」を整えるための補助線として役立つはずです。この記事をきっかけに、業務設計に少しでも興味を持っていただけたら幸いです。