複数の業務があるとき、最初の8週間にどれを入れるか ── 「全部まとめて」と言われたときの選び方

「受注も在庫も請求も、ばらばらなんです。全部まとめて1つにしたい」。初回のお打ち合わせで、この言葉はよく出ます。まとめたいのは当然です。

ただ、私たちは最初の8週間に入れる業務を、原則1つにしています。ライトプランが「1業務フロー・10画面まで」なのはそのためで、スタンダードでも2〜3業務です。全部を同時には始めない。揉めるのは、「じゃあ、どれを先にするか」のほうです。

この記事は、その選び方です。私たちが打ち合わせの中で実際に見ている基準と、最初に選ぶと苦労しやすい業務の型を書きます。

なぜ1つに絞るのか

費用の話ではありません。画面が増えれば金額が増えるのは当然で、それは業務システムの開発費用を、自分で見積もる方法に書いたとおり、画面を数えれば分かります。

絞る理由は、業務どうしをつなぐ部分の設計に、8週間の中でいちばん時間がかかるからです。受注と在庫をつなぐなら、受注が確定した瞬間に在庫を引き当てるのか、出荷したときに減らすのか。取り消しが出たら戻すのか。こういう「つなぎ目」の判断は、片方の業務が実際に画面で動いていないと、机上では決めきれません。

1つ目を動かして、現場が使い始めて、つなぎ目の形が見えてから2つ目を足す。この順番のほうが、結果として早く済むケースが多いです。全部を一度に設計すると、W2で決めた前提がW6で崩れて、周辺ごと引き直しになります。

順番の問題です。

選ぶときに見ている4つの基準

打ち合わせで業務が複数挙がったとき、私たちはこの順で聞いています。

ひとつめは、毎日動くかどうか。いちばん重く見ています。月に数回しか発生しない業務を最初に画面にしても、使う機会が少なすぎて、現場に定着する前に忘れられます。毎日、できれば1日に何度も触る業務が先です。使う回数が多いほど、リリース後の月額での改善が効きます。

ふたつめは、何人が触るか。入力する人が1人で、見る人も1人なら、Excelのままでも当面は困りません。この判断はExcelの限界の話と重なるので、Excelでの管理は、どこまでが限界かに譲ります。人数は「役割の数」で見たほうが正確です。営業10人が同じ入力をするより、営業・事務・倉庫の3役割が1つのデータを順に触るほうが、システムにする価値は高い。役割をまたぐところで転記と伝言が発生しているからです。

3つめは、いま何を失っているか。時間なのか、ミスなのか、機会なのか。ここは会社によって違うので断定できません。ただ、失っているものが具体的に言える業務のほうが、先に入れる候補です。「毎月末に2人で3日かけて突き合わせをしている」なら時間です。「出荷の数を間違えて先方から電話が来る」ならミスです。「問い合わせに即答できなくて、見積もりの返事が翌日になる」なら機会です。社内で話が通りやすいのはミスと機会のほうだと感じています。時間の削減は、削った時間で何をするかまで言えないと、稟議で弱くなります。決裁者が何を見ているかはシステム開発の社内稟議、何を書けば通るかに書きました。

4つめは、他の業務の上流にあるか。受注、出荷、請求と流れる業務なら、上流の受注から入れます。上流のデータが画面に入っていれば、下流は「それを使う画面」を足すだけで済むからです。逆に請求から作ると、請求の元になる受注データを手で入れ直す画面が要ります。ただし、上流が社外にある場合は別です。取引先の発注システムから流れてくる、という形なら、そこは初期に触らず、社内で最初にデータが生まれる場所から始めます。

最初に選ぶと苦労しやすい業務

4つの基準で上位に来ても、型として最初に向かない業務があります。正直に書いておきます。

例外が多い業務。 「基本はこの流れですが、A社だけは違って、繁忙期はさらに別で」という業務は、例外を画面に載せきれません。載せきれない例外は、現場が紙で処理し始めて、システムと紙の二重管理になります。例外を先に減らせるか、例外込みで受け入れるかを、着手前に決める必要があります。

決裁が絡む業務。 部長承認、社長承認、金額によって承認者が変わる。こういう承認ルートは初期の範囲に含めていません。実際に運用してから「この承認は形だけだった」と分かることが多いからです。承認が本体の業務を最初に選ぶと、8週間のうち何週かが承認ルートの議論で消えます。

外部連携が前提の業務。 会計ソフトに自動で流す、基幹システムから取ってくる、取引先のシステムと繋ぐ。連携先の仕様と都合で工数が読めないので、これも初期には含めていません。連携が前提の業務は、まず連携なしで動く形があるかを考えます。CSVで出して手で取り込む、で最初の数か月は回ることが多いです。

年に数回しか動かない業務。 棚卸し、年度更新、決算の集計。頻度の基準でそのまま落ちるのですが、「いちばん大変だから」という理由で挙がりやすいので、あえて書いておきます。大変さと頻度は別です。

このうち2つ以上に当たる業務は、1つ目には選ばないほうが収まりがいいと考えています。2つ目、3つ目で入れる分には問題ありません。1つ目が動いていれば、例外も承認も「実際にどう流れているか」が見えた状態で設計できるからです。

架空の想定例で、実際に選ぶ

架空の想定例です。従業員30名の食品卸で、受注、在庫、配送の手配、月次請求の4つがExcelと紙に分かれている。「全部まとめたい」という相談だとします。

業務	頻度	触る役割	失っているもの	上流か
受注	毎日、1日40件	営業・事務	FAXの転記ミスで誤出荷	すべての上流
在庫	毎日	倉庫・事務	数が合わず月末に実棚	受注の下流
配送の手配	毎日	倉庫	特になし。1人で回っている	受注の下流
月次請求	月1回、3日間	事務・経理	突き合わせに2人で3日	末端

この場合、私たちは受注を選びます。毎日動き、2つの役割をまたぎ、失っているものがミスとして具体的で、全部の上流にあるからです。請求の「2人で3日」も痛いのですが、受注データが画面に入れば、請求は改善フェーズで「受注を集計してCSVに出す画面」を1枚足すだけで済む見込みが立ちます。

在庫は2つ目です。受注と在庫のつなぎ目（引き当てのタイミング）は、受注が画面で動いてから決めたほうが精度が上がります。配送の手配は1人で回っているので、当面Excelのままで構いません。

この想定例なら、受注の登録・一覧・詳細、取引先と商品のマスタ、出荷指示の一覧、CSV出力で7〜8画面。ライトプランの範囲です。

2つ目以降は、どこで入れるか

「全部まとめたい」の残りが消えるわけではありません。入れる場所は2つあります。

ひとつは、リリース後の月額の改善フェーズです。月20時間分の稼働が含まれているので、画面を1枚足す程度の業務なら、この枠で数か月かけて入ります。

もうひとつは、最初からスタンダードプラン（2〜3業務フロー・20画面まで）で始める形です。受注と在庫のように、つなぎ目がはっきりしていて、どちらも毎日動くなら、これが合うこともあります。ただし2業務を8週間でやるには、W1〜W2の聞き取りにかける発注側の時間が倍近くになります。

開発の途中で「やっぱり在庫も」と出てきた場合の扱いは仕様変更が追加費用になる線引きに書きました。8週間の枠は動かさず、翌フェーズに回すのが基本です。

1つに絞れない場合

「これは切り離せない」という業務の組み合わせはあります。受注と在庫が完全に同じ画面で動いていて、片方だけ先に出すと現場が二重入力になる、という形です。

その場合はスタンダードで2業務を同時に入れるか、あるいは正直に言うと、私たちではなく基幹系を扱う開発会社に相談したほうがいい場合もあります。4つも5つも同時に動かさないと業務が成立しない、という状態は、MVPで小さく始める進め方と相性がよくありません。

逆に、業務が1つしかなく、それが月に数回なら、うちに頼む段階ではありません。Excelの整理で足りることが多いです。

どれを先にするかは、初回のお打ち合わせで一緒に並べて決めています。その結果を3営業日以内に画面構成のラフとしてお出しし、ここまで費用はいただきません。8週間の中身は2ヶ月で作れるもの、作れないものに、プランの違いは料金のページにあります。