業務フローは、本当に「流れて」いるか？

「業務は一通り聞いたはずなのに」

既存業務のヒアリングを終えて、業務フローも描き上げました。担当者に確認してもらい、「この通りです」と言ってもらえた。ここまで来れば、要件定義の土台は固まったと感じるのが普通だと思います。

ところが、設計に入ってから、こんな質問が出てくることがあります。「この受注データは、いつ事務の担当者に渡るのですか」。誰も即答できず、あらためて現場に確認すると、「そういえば決まっていませんでした」「人によって違います」という答えが返ってきます。

業務フローの粒度や表記法については、「業務フローは、どこまで描けばいいのか――粒度という悩ましい問題」でお伝えしました。今回は、粒度とは別の角度の見落としを取り上げます。業務と業務をつなぐ部分、いわば点と点の「インターフェース」の話です。

タスクを聞くと、つなぎ目が抜け落ちる

ヒアリングは、どうしても業務のタスク単位で進みます。受注担当の方に聞き、事務処理の方に聞き、出庫の担当の方に聞く。担当ごと、作業ごとに話を聞いていく進め方です。

タスク単位で聞けば、そのタスクの中身は詳しく集まります。何を見て、何を判断して、何を作るのか。自分の作業であれば、担当者も迷わず説明できます。

一方で、タスクとタスクの間はどうでしょうか。受注担当の方に「受注した後はどうなりますか」と尋ねると、「事務の方に回ります」という答えが返ってきます。この「回ります」の中身が、実は見えていません。紙で渡すのか、データで送るのか、メールなのか。一件ずつ渡すのか、まとめて渡すのか。それを毎日、何時ごろに行っているのか。

担当者にとっては、自分の作業の外側にある部分です。聞かれなければ話に出ませんし、本人も意識していないことが少なくありません。だからこそ、タスク単位で丁寧に聞いたつもりでも、点と点のつなぎ目だけが、すっぽり抜け落ちてしまいます。

矢印一本に、頻度は描かれない

業務フロー図では、タスクとタスクの間を矢印でつなぎます。矢印があれば、つながりを押さえた気持ちになります。しかし、矢印一本で表せるのは、「ここからここへ渡る」という事実までです。

たとえば、通信販売の会社で、受注から出庫までの流れを整理したとします。受注、事務処理、出庫の三つのタスクが矢印でつながった、すっきりとした業務フローです。

ところが、頻度を確認していくと、三つのタスクはまったく違うリズムで動いていました。受注データは、お客様から注文が入るたびに発生します。つまり、一件ずつ都度発生するデータです。一方、事務処理は1日1回、まとめて行っています。出庫処理も、同じく1日1回です。

図の上では同じ矢印でも、注文の都度流れる矢印と、1日1回まとめて流れる矢印とでは、性質がまったく異なります。システムにするとき、前者は都度の処理、後者は日次のまとめ処理になり、設計も運用も別物になります。頻度は、業務フロー図を描いただけでは見えてこない情報です。

「すべてリアルタイムに」は、正しそうで危うい

頻度の話をすると、顧客からこんな要望が出てくることがあります。「どうせシステムにするなら、すべてリアルタイムで処理してほしい」。

一見、もっともな要望です。待たされないほうがよい、早いほうがよい、というのは誰もが感じる素直な期待だからです。しかし、すべてをリアルタイムにすることが、常に正解とは限りません。むしろ、処理を複雑にしてしまう場合があります。

先ほどの通信販売の会社に、「注文から30分以内であれば、お客様はキャンセルできる」というサービスがあったとします。受注した瞬間に、リアルタイムで出庫指示まで流してしまうとどうなるでしょうか。注文から15分後にキャンセルされたとき、出庫指示はすでに倉庫に出ています。出庫指示の取り消し、場合によっては梱包済みの商品の戻し、在庫数の訂正、倉庫への連絡と、後始末の処理が一気に増えます。

最初から、受注後30分は出庫指示を出さずに待つ設計であれば、この後始末の多くが不要になります。待つことで、システムは単純になります。

損益などの指標も同じです。経営層が確認するのが月次であれば、リアルタイムで集計し続ける必要はありません。見る頻度に合わせて、日次や月次で集計すれば足りる場合は少なくありません。「リアルタイム」という言葉の響きに引っ張られて、本来は不要なコストをかけてしまうことは、実務では珍しくありません。

自社の外にも、つなぎ目はある

ここまでは自社の中の話でしたが、つなぎ目は自社の外にもあります。先ほどの通信販売の会社には、一部の商品について、取引先から直接お客様へ送る直送品がありました。この場合、出荷するのは取引先で、取引先のシステムは、注文データをファイルで一括して受け取る仕組みでした。

こうなると、頻度の決め方が変わります。自社側がいくら素早く処理しても、取引先が1日1回、決まった時刻までに届いたファイルをまとめて取り込む仕組みであれば、全体の速さはその頻度で決まります。何時までに渡せば当日出荷になるのか、その締め時刻に合わせて、ファイルを作って渡すことになります。ファイルの形式、渡す手段、渡す時刻。いずれも、自社の担当者に聞いても出てこない情報で、取引先側の仕様を確認しなければ分かりません。

さらに、30分以内のキャンセルルールとも、ここで結びつきます。締め時刻のファイルには、30分を過ぎてキャンセルできなくなった受注だけを含める、という整理になります。自社の中のルールと、取引先の受け取り方が、一本の流れとして設計されるわけです。「すべてリアルタイム」という発想は、自社の中だけで考えても決まらないことが分かります。

渡した後に、データが変わるとき

つなぎ目で、もうひとつ熟慮が必要なのが、渡した後にデータが変わる場合です。住所や数量の修正、あるいは注文そのものの削除。お客様の都合で、渡した後に変更が入ることは珍しくありません。

自社の中であっても、業務プロセスが先へ進んでいるほど、話は複雑になります。たとえば、事務処理が済み、出庫指示まで出た後に、お客様から住所の修正が入ったとします。元の受注データを直しただけでは、すでに出ている出庫指示や、印刷済みの伝票には反映されません。どの段階まで戻って直すのか、すでに進んでしまった処理をどう差し替えるのか。進んだ工程の数だけ、確認しなければならない場所が増えていきます。

取引先へファイルを渡した後であれば、なおさらです。同じ注文をもう一度ファイルで送ると、取引先のシステムでは別の注文として二重に登録されるかもしれません。削除したい場合も、こちらのデータから消しただけでは、取引先には伝わりません。

そこで、修正のデータをどう渡すのか、取り消しのデータをどう渡すのか、あるいはシステムとは別に電話やメールで連絡するのか、といった取り決めが必要になります。さらに、締め時刻を過ぎた後の変更を受け付けるのか、それともここから先は変更できないと決めるのか、という業務のルールも関わってきます。

ここで、SEの発想に触れておきたいと思います。SEは、次の工程に入ったら変更は不可とする、あるいは、いったん削除して新規登録として扱うほうがよい、と考えたくなります。そのほうが、仕組みが簡単になるからです。

しかし、それが受け入れられない場合もあります。顧客が、可能な限り柔軟に対応したいというケースです。

「柔軟」は、システムがもっとも苦手とするものです。SEからすれば、そこまで対応するのは無駄なことに見えるかもしれません。ですが、その柔軟な対応こそが、顧客の最大の強みになっていることもあります。出荷の直前まで変更に応じてくれることが、他社との違いとして選ばれる理由になっている場合です。

だからこそ、メリットとデメリットを提案することはあっても、決めるのは顧客であることを、肝に銘じておく必要があります。これは、「理想通りに進まない現実――統一されているはずの用語も、業務も、実はバラバラ」でお伝えした、用語の違いを統一するのはSEの役割ではないという話と同じです。変更不可にすれば仕組みは簡単になる一方で、顧客の強みを損なうかもしれません。柔軟に対応するなら、その分、仕組みも運用も複雑になります。その両面を示したうえで、判断は顧客に委ねる。それが、要件を定義する側の役割だと考えています。

この部分は、最初の要件定義で抜けやすい一方で、運用が始まってから、例外対応として次々に表に出てきやすい部分でもあります。「正常に流れた場合」だけでなく、「渡した後に変わった場合」まで聞いておくことで、後から付け足す手間を減らすことができます。

つなぎ目を聞き出す、四つの問い

では、この見落としをどう防ぐのか。私が意識しているのは、タスクの中身を聞き終えた後に、つなぎ目だけを取り出して、あらためて聞くことです。

ひとつ目は、「何を渡しますか」です。紙なのか、データなのか、口頭なのか。渡す中身を確認します。渡す相手が社外の場合は、相手がどのような形式で受け取るのかも、あわせて聞きます。

ふたつ目は、「いつ、どのくらいの頻度で渡しますか」です。一件ずつ都度なのか、まとめて渡すのか。まとめるなら、1日何回、何時ごろなのかを聞きます。

みっつ目は、「受け取った側は、いつそれを使いますか」です。受け取ってすぐに使うのか、翌朝に使うのか。使う側のタイミングを聞くと、渡す頻度が今のままで本当に必要なのかも見えてきます。

よっつ目は、「渡した後に、修正や取り消しが起きたらどうしますか」です。住所の修正や注文の取り消しが起きたとき、相手にどう伝えるのか、いつまでなら受け付けるのかを確認します。

この問いの中で、ふとこぼれる一言にも注意しています。「午後にまとめて届くので、午前中はいつも待たされるんです」といった声は、「要求のヒアリングで漏れる本音――それこそが、要件定義の鍵」でお伝えしたとおり、聞き流さずに拾っておきます。頻度の見直しは、こうした一言から始まることが多いからです。

「要求と要件を分ける意味」でお伝えした整理でいえば、「リアルタイムにしたい」は要求です。それを「受注から30分経過したものを、出庫指示へ流す」といった形にするのが要件です。「要件の品質とは何か」の観点でも、「リアルタイム」のような曖昧な言葉のままでは、確認も検証もできません。頻度が決まって、はじめて要件になります。

まとめ

ヒアリングはタスク単位で進むため、タスクとタスクの間の受け渡しが抜け落ちやすくなります。担当者にとっては自分の作業の外側にあたる部分で、聞かれなければ話に出てこないからです。

業務フロー図の矢印は、渡るという事実は示せても、頻度までは示せません。注文の都度発生するデータと、1日1回まとめて行う処理とでは、同じ矢印でも設計がまったく変わります。

「すべてリアルタイムに」という要望は、一見もっともですが、処理を複雑にすることがあります。注文から30分以内はキャンセルできるサービスなら、待ってから出庫指示を出すほうが単純です。指標の集計も、見る頻度に合わせれば足りる場合があります。

つなぎ目は、自社の中だけにあるとは限りません。直送品のように、取引先のシステムへファイルで一括して渡す場合は、相手の受け取り方が頻度や締め時刻を決めます。そして、渡した後に修正や削除が起きたときの扱いは、自社の中であっても、業務プロセスが進んでいるほど複雑になります。変更不可や新規登録扱いにすれば仕組みは簡単になりますが、柔軟な対応が顧客の強みである場合もあります。メリットとデメリットを提案したうえで、決めるのは顧客です。

対策は、タスクの中身を聞き終えた後に、つなぎ目だけを取り出して聞くことです。何を渡すのか、いつ、どのくらいの頻度で渡すのか、受け取った側はいつ使うのか、渡した後に変わったらどうするのか。この四つを確認し、漏れ出る不満も拾っておくことで、「リアルタイムにしたい」という要求が、はじめて頻度の決まった要件になります。