業務フローを自動化するということ

Date2026/05/20 Last Modified2026/05/20

概要

業務フローとは業態によって様々あるが、今回はコンテンツ販売事業を例にしていく。
人がやっているデータ整理などの作業を自動化する……というだけなのだが、どういうところでつまずき、解決してきたかというのを備忘録としてまとめたいと思う。
具体的な内容はぼやかしつつ、1エンジニアがシステム開発に悪戦苦闘する話として読んでいただければ幸いである。

ビジネスモデルと業務フロー

そもそもコンテンツ販売とは何かというと、自社の提供するモノ・サービスがあり、それを顧客または企業に提供する仕組みである。
コンテンツをそのまま売ることもあれば、他者のコンテンツと合わせてパッケージ販売することで購買力を高めたりすることもある。そして圧倒的にこのケースの方が多い。
例えばパソコンにセキュリティソフトを同梱して販売するようなもの。パソコンを作っている会社と、セキュリティソフトを作っている会社は別だが、パソコンが売れたときに収益を分配するという形になる。

自社コンテンツで完結していれば簡単なのだが、他社とパッケージで販売し始めると、途端に業務フローが難しくなってくる。
例えば、請求のタイミング、顧客個人情報の開示範囲、サービス提供責務、各社システム依存の必要データの違い、などなど……。
もっと曖昧な話をすれば会社間の政治もある。依頼が通りやすいとか、こっちが全部飲み込まないといけないとか。とにかく、会社ごとに何もかも違うのだ。

これらの複雑さをすべて解決しているのは何か。それは「人間という超絶ハイスペックマシン」である。
なんとなく温度感を察するし、多少フォーマットが違っても全然融通を利かせられるし、何より曖昧な業務を"慣れ"でいとも簡単に行ってしまう。
そんな人間が認知負荷のオーバーフローを起こし始めて「最近ちょっと業務が多くてね……」と自動化を検討し始めるとどうなるか。

パンドラの箱が開く。

自動化の難しさ

例えば「ヤマダタロウ」という文字列を見たとき、姓と名に分けるのは簡単だと思う。
しかし、システム化しようとするとこの時点でほぼ詰みである。どこまでが姓を指すのかというのは、あくまで人間の「経験則と予測」に依存する高度なものなのに、いとも簡単に処理できてしまうから意識に上らない。
そういう空気読みはシステムで出来ない部分だから、「どうやって空気を読んでいるか」を嚙み砕くか「空気を読まなくて済むようにフローを変える」しかないのだ。

さて、他にも簡単そうで難しい定常的な業務を列挙してみよう。

ユーザーがなかなかメールに返信してくれないので、SMSを送ってみて、それでも返事がないので電話をかけて確認する。
毎月25日に請求をかけていたけれど、今月は忙しいので早めに請求件数を教えてほしいと連絡が来たので対応した。
備考の欄に氏名や電話番号、要望などを色々と書いてもらって、それを良きようにエクセルに入力する。

すでに業務自動化を経験したことがある人は、胸がつままれるような気分になっていることだと思うが、これが現実である。
どれもこれも、曖昧な条件が多くて分岐させられないし、何より自然言語の処理能力が高すぎる。人間それぞれ、一つの単語ですら違う解釈を持っているのに会話が成立するのか、驚異的に思う。
エンジニアのお仕事というのは、単にコードを書くことではなくて、「みんなが自然にやってのけることをシステムの言語で処理できるレベルに落とし込む」ことなのだ。
それができて初めて、自動化が進みだす。もはやコーディングはおまけである。（もちろん高い技術力を要するサービスならエンジニアはコーディングに偏重すべきだと思う。でも大抵求められてるのは、素晴らしいコードではなく実用に耐えうるだけのコード）

システム化(自動化)を進めるための、はじめの一歩

前提をひっくり返すような話になるが、最初に決めるべきなのは「本当にシステム化が必要なのか？」である。特に入念に検討すべきだ。
システム化をする目的は、たいてい業務負担の軽減であり、それによって外部委託している販管費が削れるとか、より別のサービスに注力できるとかの理由がある。
箱を開けてみないことには開発の予算は確定しないけれど、それでも概算で「1000万円だ」と見積もったときに将来的に回収できるのかを考えないといけない。
エンジニアとしてあるべきなのは、「完全システム化」なのか「部分システム化」になるのかという目線である。「部分システム化」になる場合は、当然業務フローのどこかにシステムが差し込まれる形になるので現場の業務フローを侵食し、マニュアルや慣れた作業を変えてもらう必要がある。その際の負担があることを、エンジニアとしてあらかじめ見積もっておかないといけない。

これが決まったら、次はシステムが果たすべき役割をはっきりさせる。
「処理が必要なデータ一覧」と「目的」さえ決まっていればよい。技術的な障壁というのは意思決定次第でなんとでもなったりするものだ。
人間関係のせいで融通が利かないこともあるけれど、一番融通が利かないのはシステム君である。まずはシステムの役割をはっきりさせないと、本当に無理になったりする。

必要な情報を集める……

ここまで進めば、エンジニアがやることは至極シンプルになった。
「必要なデータを集めて、それを役割に合わせてコードを書いてやる」だけである。
それだけなのに……。

まずは、システム化を試みている担当者から、普段使っているフォーマットを連携してもらう。
「これとこれを使って、必要なデータを作ってます！これを各社にいい感じに連携してます！」

それを見てみると、あまりにも整形されていないデータに驚く。ブレーンストーミングでもしたのかと言わんばかりのユニークなデータ形式。
けれど確かに、頭を使って継ぎ接ぎしてみると一応正しいデータは作れそうである。でもルールが完全に空気読みの要領なので、このままではコードに落とし込めない。

こうなった場合、話は次の提案へ進む。

1. 担当者が普段通りデータ整形したものをシステムへ投げてもらって、それ以降の外部連携を自動化する形で妥協する
1. 担当者にデータが流れてくる前に、その上流でシステムを嚙ませることで整形された状態で流れてくるようにする

もちろん全自動化で予算を引いているなら、なるべく手作業は排除しなくてはいけない。
そうなると、2. の案を採用してもらう形で話が進む。

次に、１つ上流のデータ処理の業務フローを見せてもらうことになる。（ここら辺から、この業務まで変えるって聞いてないんですけど！？って現場の作業者から反感を買い始めてめちゃくちゃ進行が遅れ始める）
すると、実は関係各社から自由な形式でデータを受け取っていることが判明したりする。
しかも形式が自由なだけではなくて、必要な情報が歯抜けで入ってきたりして、雲行きが怪しくなってくる。

「この会社はクラウドに個人情報載せたくないとかで、個人情報は全部抜いた状態で来るんですよね。だからうちの顧客データベースで検索して補完してるんですよ～」
なんてこった！？この会社は独自にデータベースを持っていて、そこからの検索も必要になるのか。

こんな感じで、あれもこれも何にもデータがそろわない状態が続く。

自社のDBシステムは管理画面があるけど、APIはないから自動では取れないです。あと誰が開発したのか私は知らないので確認します
こちらの会社さんとは仲良くやってるので、向こうの現場フローを変えてもらえないか交渉できますよ
この会社さんはまだ日が浅いので、なるべくこちらで特別対応して済ませてほしいです

という感じで現場の作業のやり方を把握して、どこからシステム化可能になるかを逐一判断する必要が出てくる。
難しいのは「正しい答えを持っている人は限定されている」ということ。
いち作業者に上流のフローを聞いても判然としないように、全体の業務フローを把握している人は存在しない。
なので、誰がどの業務を担当していて、誰にどんな質問をすれば全体像が見えてくるのかを把握するのもまた、エンジニアの仕事だったりする。

現場の人との確認や交渉を進めつつ……けれど締め切りがあるのでシステムの制作も同時に進めなくてはいけない。

短すぎる締め切りに、間に合わせる工夫

普段から意識していることは、「自分がボールを持っている状態」なのはコーディングのみにすることである。
というのも、開発でもっとも大きな遅延原因は「返事待ち」だから。

この自動化をメインで推進しようとしているのは自分だけであり、他の人たちはそれぞれ別の仕事がある。
その中で、何か質問していったりするとして、調整が遅れたり返事が遅れたりするのは当然のことなので、なるべく早くこちらがアクションしておかないといけない。
クライアント内で済めば良いが、場合によっては外部の承認フローを待ったりする時間もあって、全然思い通りには進まないのである。
だからこそ、「ボールを最優先で投げ返して、場合によっては催促してお願いする」などの自分にできることは絶対にやらなくてはいけない。

よくある話で、「外部の対応が遅れてしまったので締め切りを伸ばしましょう」という提案がもらえることもある。
それを得るためにも、なるべく自分のところで止まっているという状態は作り出さないようにすべきだと思っている。

私はエンジニアではないのかもしれない

エンジニアとは、工学（エンジニアリング）の専門知識やスキルを駆使して、製品の設計、開発、システムの構築などを担う「技術者」の総称です。

エンジニアを最初に志した頃は、技術に特化するのがエンジニアだと思っていたし、最近までもそう思っていた。
だから募集要項で「業務システムの改善経験」とかを問われているのを見ると、「高トラフィック処理とか、セキュリティの話に詳しいってことかな……」みたいに考えていたんだけれども、たぶん違うみたい。
おそらく現場でどういう折衝が起こるかを知っていて、それを技術者の目線で推進していけるかという経験を問われているんだろう。

ということで、きっとそういう募集要項を掲げている会社が求めているのはエンジニアじゃなくて、技術に詳しいプロダクトマネージャーなのだ。
私はそっちに近い仕事をしているような気がする。全部1人で回す必要があるから、開発ももちろんやってるけど……でも専門職っぽい開発はしていないなと思って、エンジニアを名乗るのが少し恥ずかしいような気もする。

ということで、ちょっとズレた締めに向かってしまったが、「自動化」というプロジェクトの中身がちょっとでも伝われば幸いである。