業務を理解したあと、何を決めるのか

なぜこれを記録するか

業務向けのSaaSをつくるなら、顧客の業務を深く理解する必要があります。

誰が、いつ、何を見て判断するのか。標準的な流れは何か。どこに例外があり、顧客ごとに何が違うのか。ヒアリングを行い、業務フローを書き、要件やケースを整理する。知らないままつくるより、知ってからつくるほうがよい。それは間違いありません。

調査を重ねると、やがて精密な地図ができます。

• 現在の業務フロー
• 登場人物と責任
• 顧客ごとの差分
• 判断の条件
• 例外と手戻り
• 利用している帳票やシステム

それでも、プロダクトの仕様やつくる順番がうまく決まらないことがあります。資料には現実が正しく書かれている。要件にもそれぞれ根拠がある。しかし、出来上がるものを一つのプロダクトとして見ると、どこへ向かっているのか分かりません。

地図が間違っていたとは限りません。行き先を決めていなかった可能性があります。

地図からは、行き先が決まらない

三つの顧客について調べ、次のことが分かったとします。

• 顧客Aには、業務a、b、cがある
• 顧客Bには、業務a、d、eがある
• 顧客Cには、業務b、c、fがある

ここまで調べれば、業務の分布は見えるようになります。しかし、まだ次の問いが残っています。

• aからfまですべてをプロダクトに含めるのか
• aとbを共通の業務として扱えるのか
• cはプロダクトではなく運用で支えるのか
• dを先につくることが、次の顧客にもつながるのか
• eとfは例外なのか、まだ見えていない別の幹なのか
• 今回は誰のどの業務を、最後まで成立させるのか

これらは、業務調査の不足によって残っている問いではありません。すべてを詳しく調べても、観察した事実だけから答えは一つに決まりません。

必要なのは追加の事実だけではなく、どの顧客と業務を中心に置き、プロダクトとして何を共通の形にするかという選択です。

記録001では、要件のリストではなく、未知の要望を位置づけられる業務のモデルを持つことについて書きました。ただし、モデルができても、それをどのプロダクトにするかはまだ決まっていません。モデルは現実を捉えるための構造であり、プロダクトの行き先そのものではないからです。

プロダクトは、現在の業務の写しではない

現在の業務を正確に再現することが、最も正しいプロダクトとは限りません。

ある業務が、次のように行われているとします。

担当者が内容を確認する
表計算ソフトへ入力する
別のシステムへ転記する
責任者が判断する
結果をメールで送る

この流れをそのまま画面と機能へ置き換えれば、現行業務に適合したシステムはつくれます。しかし、表計算ソフトへの入力や別システムへの転記は、以前の道具に制約があったために生まれた手順かもしれません。確認と判断も、本当は同じ人が同時に行えるかもしれません。

現在の業務には、守るべきドメインの規則と、過去の制約から生まれた迂回路が混ざっています。両方を区別せずに再現すると、プロダクトは業務を改善するのではなく、迂回路まで固定します。

プロダクトを考えるときには、少なくとも三つの選択があります。

1. 残す — 人が担う意味のある判断や、業務上必要な統制を残す
2. 置き換える — 転記や照合など、同じ結果をより小さい負担で得られるようにする
3. なくす — 新しい仕組みでは不要になる手順そのものを消す

どれを選ぶかは、現在の業務を観察しただけでは決まりません。何を守り、何を変えたいのかという意思が必要になります。

すべて正しいのに、全体が正しくならない

地図だけを見て開発すると、観察された業務が一つずつ要件になります。

顧客が実際に行っている。業務上必要だと説明されている。商談でも求められた。だから、その要件を実装する。それぞれの判断は合理的です。

しかし、合理的な部分を足せば、一貫した全体になるとは限りません。

業務aの前半に対応した機能、業務dの例外に対応した設定、業務fの結果だけを出す画面が、同じリリースへ入ることがあります。各機能には根拠があっても、特定の利用者が一つの目的を最後まで達成できるとは限りません。

この状態では、優先順位も「どの要望が重要か」という比較になります。本来その前にあるはずの、「どの業務をどのような状態へ変えるか」が決まっていないためです。

正しい地図から間違った場所へ進むのは、地図の読み方を間違えたからとは限りません。目的地を置かず、地図に書かれた道を順番に進んだからでも起こります。

業務理解のあとに決めること

業務理解とプロダクト要求の間には、プロダクト上の選択があります。

記録002では、事業戦略をプロダクト上の選択へ変換する過程について書きました。業務理解は、この変換に必要な材料です。材料を揃えたあと、少なくとも次のことを決めます。

どの変化をつくるか

現在の業務を記述するだけでなく、プロダクトを使ったあとに何が変わるかを置きます。

• 作業時間を短くするのか
• 判断の質を揃えるのか
• 属人化している知識を共有可能にするのか
• 業務そのものを不要にするのか
• これまで実行できなかった業務を可能にするのか

同じ業務を対象にしても、目指す変化が違えば、必要なプロダクトも変わります。

どこまで責任を引き受けるか

プロダクトは、対象業務のすべてを最初から担う必要はありません。

情報を記録して見えるようにする。判断に必要な材料を提示する。決まった規則の処理を自動化する。通常のケースを処理し、例外だけを人へ戻す。一つの限定された範囲を自律的に処理する。

これらは単純な成熟度の階段ではありません。誤りの影響が大きい業務では、人の承認を残すほうがよいことがあります。頻度が低く、人が短時間で処理できるなら、自動化しないことも合理的です。

問うべきなのは「どこまで高度にするか」ではなく、このプロダクトは、今この業務のどこまでに責任を持つのかです。

どの順番で近づくか

最終的な姿が同じでも、そこへ至る順番は複数あります。

最初に人が業務を完遂できる場所を一つにまとめ、その後に定型処理を自動化する。先に判断結果を記録できるようにし、十分な事例が集まってから判断支援を加える。対象顧客を狭くして一連の業務を成立させ、あとから例外を広げる。

順番は納期の分割ではありません。各段階で価値を届け、何かを学び、次の選択肢を増やすための設計です。

何を地図に残したままにするか

調べて見つけた業務を、すべてプロダクトへ入れる必要はありません。

重要だが今は扱わない。特定顧客の運用として残す。外部システムへ任せる。将来の判断材料として記録だけ残す。業務として存在することを認めたうえで、プロダクトには含めない選択があります。

地図から消すことと、目的地に選ばないことは別です。理解したものを捨てるのではなく、理解したうえで境界の外へ置きます。

小さくつくる場所を間違えない

MVPだから機能を小さく切る、という説明を聞くことがあります。小さく始めることには意味があります。しかし、画面や処理の途中で切れば、小さなプロダクトになるわけではありません。

一連の業務が、入力、処理、確認、完了で構成されているとします。入力と処理だけをつくり、確認から先へ進めないなら、利用者は価値を受け取れません。

一方、入力と処理をプロダクトで行い、確認は人へ安全に戻し、業務を完了できるなら、プロダクトの自動化範囲は狭くても一連の価値は成立します。その利用から学び、次に確認を支援または自動化できます。

重要なのは、機能の数ではなく、切った先に成立するフォールバックがあるかです。

小さくするなら、価値の流れを途中で切るのではなく、プロダクトが引き受ける責任の範囲を小さくする。

どこまでをプロダクトが担い、どこからを人や既存運用へ戻すか。その境界によって生じる負担や失敗時の影響は、初期のプロダクトを決める重要な材料になります。

詳しくなるほど、選べなくなる

業務理解が深くなると、見える例外も増えます。

「この顧客では別の承認がある」「この条件では処理が逆になる」「年に一度だけ違う帳票を使う」。知ることが増えるたびに、必要に見える要件も増えます。

判断基準がなければ、理解の深さがそのまま仕様の大きさになります。

業務理解
例外の発見
要件の追加
さらに詳しい調査
さらに多くの例外

これは、調査の質が低いために起きる失敗ではありません。むしろ、誠実に調べるほど入りやすい循環です。

業務を深く知ることは、選択肢を増やします。プロダクト戦略は、その選択肢を減らします。片方だけでは、現実から外れるか、何も選べなくなるかのどちらかです。

AIが地図を広げる

AIによって、情報を整理するコストは下がりつつあります。

インタビューの要約、業務フローの下書き、顧客ごとの差分、要件の分類、類似ケースの探索、仕様書のたたき台。入力となる情報の質や文脈には依存しますが、人が最初からすべてを処理するより速く進められる場面は増えています。

AIは選択肢を出すことも、優先順位を提案することもできます。したがって、「AIは整理し、人間だけが判断する」と単純に分けることもできません。

それでも、提案された選択を自分たちのプロダクトとして引き受ける仕事は残ります。

• どの事実を重く見るか
• どの顧客を中心に置くか
• どの不確実性を先に検証するか
• どの例外を扱わないか
• 失敗したときの影響を誰が負うか
• どの方向へ進むことを組織として約束するか

AIが百のケースを整理すれば、百のケースがプロダクトになるわけではありません。地図が短時間で広がるほど、どこへ行かないかを決める負担は大きくなります。

業務分析の速度が十倍になっても、プロダクト上の選択がなければ、十倍の速度で「多くを知っているが、何をつくるかは決まっていない状態」へ到達するだけです。

AI時代に価値がなくなるのは、業務理解ではありません。情報を集めて整理したことだけを、意思決定の代わりにすることです。

地図で止まっていないかを確かめる

業務を理解したことが、そのままプロダクトを決めたことになっていないかを見るための三つの問いがあります。

1. 変化テスト — 現在の業務ではなく、プロダクトによって何が変わるかを説明できるか。
2. 境界テスト — 理解しているがプロダクトでは扱わない業務を挙げ、その理由を説明できるか。
3. 到達テスト — 次のリリースで、誰がどの業務をどこまで完了できるようになるか。

一つめに答えられなければ、現在地を記述したところで止まっています。二つめに答えられなければ、地図にあるものをすべて目的地にしています。三つめに答えられなければ、進んではいても、どこへ到達するのかが決まっていません。

まとめ

• 業務を正確に理解することは必要だが、それだけでつくるべきプロダクトは決まらない
• 業務モデルは現実を捉える地図であり、プロダクトの行き先そのものではない
• 現在の業務には、守るべき規則と過去の制約から生まれた迂回路が混ざっている
• 業務理解のあとには、つくる変化、責任範囲、近づく順番、扱わないものを選ぶ仕事がある
• MVPでは価値の流れを途中で切るのではなく、プロダクトが引き受ける責任の範囲を小さくする
• AIが地図を広げるほど、どこへ行き、どこへ行かないかを決める価値が上がる

業務を追うことは、目的地を決めるために欠かせません。しかし、地図のすべての道を通る必要はありません。

どの道を選び、どの道を残し、どこまでをプロダクトの責任にするのか。業務を知ったあとに、プロダクトづくりが始まります。