トップ ／ コラム ／ 業務をどこまで整理するか

システムを作る前に業務をどこまで整理するか｜見直す範囲の決め方

「今のやり方のままシステムにしてほしい」と言われることがあります。反対に「どうせ作るなら業務ごと見直したい」と言われることもあります。どちらも途中で止まりやすい進め方です。

前者は、今のやり方に含まれている無理がそのまま機能になります。後者は、業務の見直しが終わらないまま時間が過ぎて、システムの話に入れません。

このページでは、システムを作る前に業務のどこを整理しておくと進みやすく、どこは触らずに残したほうがよいのかを、実際の案件での線引きとあわせて整理します。費用の考え方は 業務システムの開発費用はいくらかかるのか にまとめています。

「そのまま」と「全部見直し」の間に答えがある

業務システムを作るとき、業務の整理をどこまでやるかで、進み方が大きく変わります。両端はどちらも止まります。

• そのままシステムにする：今のやり方を一つずつ画面にしていくと、例外処理の数だけ機能が増えます。使う人の手順は変わらないので抵抗は少ないのですが、作る量が膨らみます。
• 業務を全部見直してから作る：理屈は正しいのですが、見直しの範囲に終わりがありません。関係する部署が増え、決裁が増え、半年たってもシステムの話に入れないことがあります。

現実的なのは、システムの形が変わるところだけを先に整理して、残りは今のやり方を持っていく進め方です。どこがそれに当たるかは、業務の内容ではなく「誰が決められるか」で判別できます。次の章から順に見ていきます。

整理しないまま作ると、例外が機能になる

整理をまったくせずに要件を出すと、たいていこうなります。

1. 現場に「今どうやっていますか」と聞く
2. 通常の手順と一緒に、例外のときの手順も出てくる
3. 例外も漏らさないよう、画面と項目に反映する
4. 機能の数が増え、どの画面も入力欄が多くなる
5. 使う人が「前のExcelのほうが早い」と言い始める

例外を無視してよいという話ではありません。問題は、例外が「なぜ起きるか」を確かめずに機能にしてしまうことです。例外の多くは、過去に別の部署の都合や、紙の書式の制約から生まれています。元の制約がもうないなら、機能にする必要はありません。

「要件を発注側だけで抱えない」という考え方は 要件定義を発注側だけで抱えない進め方 に、失敗の型は システム開発が失敗する5つの理由 に書いています。

どこまで整理するかは「決める人がいるか」で決まる

業務の整理が止まるのは、作業量が多いからではありません。決める人がその場にいないからです。

たとえば「会員の区分を5つから3つに減らせますか」という問いは、事務局の判断では答えられないことがあります。理事会にかける話なら、答えが出るのは次の理事会です。一方「入力欄の並び順を変えてよいか」なら、担当者がその場で決められます。

そこで、整理したい項目を次の3つに分けます。これだけで、やる順番が決まります。

「会議や決裁が必要」をシステムの前提に入れてしまうと、決裁が下りるまで設計が止まります。逆に今のやり方で作っておけば、決まったあとに直す作業は、たいてい最初から作り直すより小さく済みます。

整理しておくと後が楽になる4か所

その場で決められる範囲のうち、先に手を入れておくと後の作業がはっきり楽になるのは、この4か所です。

4つ目は、整理の効果がもっとも大きいところです。ドローン操縦士協会の講習管理では、修了の判定条件が現場の経験として共有されていました。実技が10時間に届かない受講者は修了にしない、要件を満たしていない講師の指導は記録として認めない、といった条件です。

この案件で整理したのは判定条件の中身ではなく、条件がどこにも書かれていないという状態でした。条件を言葉にしたうえでシステムに判定させ、修了要件を満たしているかを一覧で表示する形にしています。人が覚えておく必要がなくなり、担当者が変わっても判定が揺れません（ドローン操縦士協会の事例）。

台帳と表記ゆれの整理は、そのままデータ移行の作業量になります。移行で詰まるところは データ移行が詰まる5つのこと に、紙とハンコで回している承認の扱いは 紙とハンコの申請業務をWebにする前に決める5つのこと にまとめています。

触らずに残したほうがよい3か所

反対に、整理の対象から外したほうがよいところもあります。ここに手を伸ばすと、終わらなくなります。

• 年に1回しか起きない例外：発生が少ないものは、システムに入れず手作業で続けたほうが安く済むことがあります。機能にするかどうかは、作る手間と、年1回の手作業を比べて決めます。
• 法令や制度で決まっている手順：記録の保存期間、報告の様式、資格の修了要件などは、こちらの都合で変えられません。整理せず、そのまま仕様にします。制度が変わったときに直す場所になるので、どこが制度由来かは残しておきます（保守・運用は誰がやるのか）。
• 組織の決め事：承認の段数、権限の分け方、部署の担当範囲。これらは業務の効率とは別の理由で決まっています。システム化を理由に変えようとすると、話が組織の議論に移ってしまいます。

整理の進め方5ステップ

整理は、机の上で完成させるものではありません。システムの設計と並べて進めるほうが早く終わります。

1. 今の手順を書き出す（1〜2週間）　部署ごとに、受付から記録までの流れを箇条書きで出します。きれいな業務フロー図は要りません。「誰が、何を見て、どこに書くか」が分かれば足ります。
2. 例外を別の紙に分ける　通常の手順と例外を混ぜて書くと、どちらが主なのか分からなくなります。例外は別にして、それぞれ「年に何回起きるか」を書き添えます。
3. 3つに仕分ける　前の章の表のとおり、その場で決められる／会議が必要／制度で決まっている、に分けます。
4. 「その場で決められる」だけ先に決める　呼び方の統一、使っていない項目の廃止、入口の一本化。ここだけ終わらせて、残りは今のやり方で進めます。
5. 画面を見ながら残りを決める　試作画面（モック）ができてから、「この入力は要らない」「この順番のほうが早い」が出てきます。紙の上では気づけないので、ここに判断を残しておきます。

5番目が肝心なところです。日本眼科医会の会員管理システムを作り直したときは、業務のヒアリングから始めて、試作画面で仕様を固めてからバックエンドの実装に入りました。業務を全部整理し終えてから作り始めたのではなく、画面を見ながら整理の残りを決めたという順番です（日本眼科医会の事例／7か月で作り直すまでの経緯）。

最初に作る範囲をどう決めるかは 新規事業のシステムを小さく早く作る方法 にも書いています。

pegのやり方

pegは、業務の整理を先に全部終わらせてくださいとはお願いしません。ヒアリングで一緒に書き出して、その場で決められるところだけ決め、残りは画面を見ながら決めていきます。

• ヒアリングは業務の言葉で伺います。　専門用語を使わず、いつもの業務の言い方のまま聞き取ります。仕様書は要りません。
• 試作画面を先に作ります。　バックエンドの実装に入る前に画面で仕様を固めます。整理の残りは、この画面を見ながら決めていただけます。
• 整理の作業は分担します。　台帳の突き合わせや表記の統一は、業務を知っている方が手を動かしたほうが速く正確です。pegは何をどう揃えるかの決め方をお渡しして、作業そのものは発注側に担っていただくことがあります。そのぶん開発の作業量が減ります。
• 整理の結果は資料に残します。　判定条件や呼び方の決めごとは、設計資料として納品物に含めます。管理者権限・プログラム・設計資料を納品することは契約に明記しています。
• 担当は常に2名以上です。　引き継ぎ資料を最新に保っているので、整理の経緯が1人の記憶に残る形にはしません。

整理をどこから手をつけるか迷っている段階なら、3つの質問でわかる簡易診断 か ヒアリングシート をお使いください。発注の条件まで整えたい場合は RFPテンプレート があります。使ってもらう段階の話は 新しい業務システムを職員に使ってもらうには にまとめています。

よくあるご質問