ワークフロー移行の様式一覧。その行数は業務の数ではない

長く使ってきたワークフローシステムを止めることが決まり、移行の準備として現行システムから様式の一覧を書き出します。CSVを開くと、行数が数百行ありました。ただ、その行数をそのまま移行対象の数として扱ってよいとは限りません。同じ名前の様式が何行も並んでいることが、珍しくないからです。

これを全部作り直すのか。

一覧を開いた最初の感想は、だいたいここに落ち着きます。そして数百という数字は、そのままベンダーへの見積もり依頼に載っていく。構築の工数もテストの期間も、この数から逆算されることが多いからです。行数と実際に作る数のあいだにどれくらい差があるのかは、早い段階で見当をつけておきたいところです。

一覧そのものは現行システムから出せる前提です。様式が増えていった理由を5つに分けて整理するので、数を減らす話に入る前の仕分けのたたき台になれば十分です。

様式一覧の行数と業務の数が一致しないのはなぜ？

一致しない理由は、様式という単位が業務ではなくシステムの都合で切られているからです。ひとつの業務が複数の様式に分かれていることも、逆にひとつの様式が複数の業務を兼ねていることもあります。

申請様式とは、申請の入力項目と承認経路、出力する帳票をひとまとまりにして登録した単位のことです。入力項目が同じでも経路が違えば、システム上は別の様式として登録することになる場合があります。

例えば、様式一覧に「備品購入申請」という名前が7行並んでいます。営業部用、製造部用、大阪支社用、100万円以上用。名前の末尾だけが違って、中身の入力項目はほとんど同じ。

業務としては1つです。備品を買うために上長の承認をもらう、それだけ。

7行に分かれたのは、経路を様式ごとにしか持てない作りだったからかもしれません。あるいは部署ごとに担当者が別々に作ったのかもしれない。理由は一覧を見ただけでは分かりませんが、7という数字が業務の複雑さを表しているわけではないことは言えます。

移行で減らせる様式と減らせない様式の5分類

減らせる可能性があるのは、経路が違うだけ・帳票が違うだけ・項目が一部違うだけ、の3つです。業務そのものが違うものと、使われていないものは、減らすというより別の扱いになります。

分類の名前だけでは、手元の一覧をどこに振り分けるか決められません。1行ずつ見るときに、何を根拠にするかを書きます。

業務が違うかどうかは、名前ではなく入力項目の集合で見ます。「購買申請」と「備品購入申請」が並んでいたとき、名前からは別物にも同じものにも見える。片方にしか存在しない入力項目があるかどうかを比べると、判断がつきやすくなります。項目が完全に一致していれば、業務が違うのではなく名前が違うだけです。

帳票だけ違うものは、提出先で分かれています。社内で保管するだけのもの、取引先に渡すもの、官公庁に出すもの。中身は同じでも様式の欄外や体裁が指定されているので、別の様式として作られていることがあります。ここを1本に統合すると、帳票を1つ改定したときの影響が全部署に及びます。統合しやすい代わりに、改定の手続きは重くなる。

項目が一部違うものは、追加項目の性格で分かれます。増えている項目が部署固有の管理コードや連番であれば、表示条件で切り替えられます。一方、その項目があることで承認の判断そのものが変わるなら、業務が違うほうに寄せて考えたほうが安全です。

「使われていない」の見分け方も、思ったほど単純ではありません。直近1年の申請件数がゼロでも、年に一度しか出ない様式なら翌月に使われます。決算期、株主総会、保険の更新。件数だけを見て切ると、必要な様式が消えます。

件数を出すときは、少なくとも2期分。それでもゼロなら、所管部署に一度確認する。ここは省略できないところです。

経路をまとめると経路を触れる人が変わる

備品購入申請の7行は、経路だけ違うところにあたります。金額と部署を条件にできる製品であれば、1本の様式に条件分岐を持たせる形に置き換えられます。

ただし、置き換えられることと、置き換えてよいことは別です。

経路を1本にまとめると、経路の設定を変えられる人が変わります。これまで部署ごとの様式を部署の管理者が触っていたのなら、統合後は中央で一括管理することになる。設定で吸収できるのは経路そのもので、運用の主体が動くことのほうは設定では戻せません。統合の判断が情シスの中だけで閉じないのは、そのためです。

減らせる3つのうち、帳票違いと項目違いは設定の話で終わります。経路違いだけが、設定の外側に影響を残す。同じ「吸収できる」でも重さが違います。

経路を中央に集めた後に何が起きるかは、承認経路のメンテが終わらない理由にも書きました。

行数の内訳がどう出るかは会社によりますが、偏りの方向は見当がつきます。業務そのものが違う様式の数は、会社の規模が変わってもそれほど増えません。買う、雇う、出す、直す。業務の種類は組織の大きさに比例しないからです。一方、経路の都合で分かれた様式は、部署の数と決裁の段数が増えるほど増えていきます。一覧の行数が多いほど、名前の末尾違いが占める割合は上がりやすい。

なぜ様式を減らす作業は移行の前に終わらないのか？

終わらない理由は、廃止と統合を決められるのが情シスではないからです。判断できるのは所管部署で、その部署は移行プロジェクトの担当ではありません。

移行の解説記事を読むと、たいてい「不要な様式を整理してから移行する」と書かれています。正しいと思います。ただ、この整理が計画どおりに終わることは多くありません。

備品購入申請の7行のうち、大阪支社用を廃止してよいかどうか。判断できるのは大阪支社で申請を出している人と、その様式を作った所管部署です。情シスは一覧を出せますが、業務上まだ必要かどうかは知りません。

そして所管部署には、日常業務の合間に7行の様式を見比べて「これは統合してよい」と判断する時間を作ってもらうことになります。

数百行あれば、確認先の部署も数十になります。

ここで起きるのは、遅れというより停滞です。全部の返事が揃うまで次に進めないので、待っている間の進捗がゼロになる。プロジェクトの中でいちばん動いていないように見える時期が、移行の初期に来ます。

だから、整理を先にやるか後にやるかという二択ではなく、どこまでを整理してから次に進むかを先に決めておく。全部を仕分けきってから動き出す設計にすると、止まります。

どこで区切るかを決めること自体が移行の設計だという点は、新システムへの切り替えは「一斉リリース」か「段階リリース」どちらが良いのかでも触れました。

数えるタイミングと見積もりのタイミング

現行システムから一覧を出す作業と、ベンダーに見積もりを依頼する作業は、ふつう近い時期に来ます。一覧が出た時点で「数百あります」と伝え、そこから構築の工数と金額が出てくる。

問題は、仕分けが終わるのがそのあとだということです。

仕分けの結果として実際に作る様式が減っても、見積もりの前提はすでに固まっています。契約の形によっては、減った分が金額に反映されないこともある。

もう一つ、減った分がそのまま工数に効くとも限りません。7本を1本の条件分岐にまとめると様式の数は7分の1になりますが、分岐ごとの動作確認は残ります。帳票を3レイアウト出し分けるなら、そのレイアウトも3つ作ることになる。数だけが減って、確かめる箇所は減らない領域があります。

だから、共有しておきたい幅は2つあります。一覧の行数と実際に作る様式数の幅と、様式数と工数が比例しない部分。「一覧の行数は数百ですが、経路違いと帳票違いが含まれているので、実際に構築する数は精査中です」と伝えたうえで、精査後に数が変わったときの扱いを見積もりの条件に入れてもらう。

ベンダーへの聞き方については、ワークフローシステムを選ぶ前に押さえておきたいポイント。比較表の○が揃ってしまう4つの領域にも書きました。

棚卸しで誰に何を聞くか

仕分けに必要な情報は、聞く相手によって分かれます。自分で調べられることと、聞かないと分からないことを混ぜると、待ちが増えます。

現行システムから出すこと

• 様式の一覧と、それぞれの直近2期分の申請件数
• 様式ごとの入力項目の一覧（項目の集合を突き合わせるために使います）
• 様式ごとの経路の設定
• 様式を最後に更新した日付と、更新した人

所管部署に聞くこと

• 年に一度しか使わない様式がどれか
• 名前が似ている様式のうち、実際に使い分けているものはどれか
• 様式を分けている理由が、経路の都合か業務の都合か
• 統合した場合に、経路の設定を誰が管理することになるか

最後の1つは、答えを見てから統合の可否を決める項目です。中央で管理してよいという返事が返ってくるなら統合できますし、部署で管理し続けたいという返事なら、統合できる作りであっても分けたまま移すほうが運用に載ります。

ベンダーに聞くこと

• 見積もりは様式の数で数えるのか、経路の分岐数や帳票のレイアウト数で数えるのか
• 経路の条件に使える項目は何か（金額・部署・役職・入力値のどこまでか）
• 1つの様式から複数の帳票レイアウトを出し分けられるか
• 入力項目の表示・非表示を条件で切り替えられるか
• 廃止した様式の過去データを、参照だけできる形で残せるか

最後の項目は聞き漏らされやすいところです。廃止すると決めた様式にも、過去の決裁記録は残っています。参照先の選び方は3つあって、旧システムを参照専用で残すか、PDFで一括出力するか、新システムに参照用としてインポートするか。保存が必要な年数と参照する頻度で分かれます。新システムに作らない様式の記録をどこに置くかは、廃止を決めるのと同時に決めておきたいところです。

まとめ

移行の見積もりに載る数字は、現行システムから出した一覧の行数です。その行数は、業務の数ではありません。経路の都合、帳票の都合、項目の都合で分かれた結果が、そのまま行数になっています。

だから最初にやるのは、減らすことではなく分けることだと思っています。5つの理由に振り分けると、そのうち3つは設定で吸収できる。1つは廃止の候補になり、残った1つだけが本当に作り直す対象になります。

ただし、3つが同じ重さではありません。帳票違いと項目違いは設定の話で終わりますが、経路違いだけは、統合したあとに経路を管理する人が変わります。ここだけは所管部署の返事を見てから決めたほうが、後で戻さずに済みます。

減らす判断そのものは、情シスの一存では決まりません。決められるのは所管部署で、そこには合意形成の時間がかかります。全部の返事を待ってから動き出す設計にすると、移行の初期で止まります。

以前は、移行の前に様式を整理しきるのが正しい進め方だと考えていました。考えが変わったのは、整理の途中で止まったまま数か月が過ぎたプロジェクトを見てからです。整理をやめたほうがよいという意味ではなく、整理の完了を次の工程の条件にしないほうがよい、という順番の話でした。

私は相談を受ける営業の立場で、数百行の一覧を自分の手で最後まで仕分けた当事者ではありません。1つの様式から何を出し分けられるかは製品の仕様として説明できる範囲ですが、個々の会社の備品購入申請を7本のまま残すか1本にまとめるかは、決められる場所にいない。経路の管理を中央に寄せるか部署に残すかも、話を聞いていてその場で線が引けないことがあります。

よくある質問

現行システムから様式の一覧を出せない場合はどうすればよいですか？

古いシステムでは、様式の一覧や申請件数をエクスポートできないことがあります。その場合は、管理画面の表示を1画面ずつ書き出すか、所管部署から現行の申請様式を集める形になります。件数が取れないときは、過去の申請データの保存先から年度ごとの件数を数える方法もあります。どちらも時間がかかるので、移行を検討し始めた段階で出せるかどうかを確認しておくと、後の見積もりが立てやすくなります。

経路を1本に統合すると、部署側は何ができなくなりますか？

統合前に部署の管理者が自分で変えられていた設定が、中央への依頼に変わります。承認者の追加、順番の入れ替え、代理承認の設定。どこまでを部署に残せるかは製品によって違うので、経路の一部だけを部署の権限で編集できる作りかどうかを確認しておくと判断しやすくなります。すべてを中央で持つ形になると、異動のたびの修正依頼が情シスに集まります。

移行を機に様式を作り直すのと、そのまま移すのとではどちらが早いですか？

構築の作業だけを見れば、そのまま移すほうが早く終わります。ただ、そのまま移すと現行の分かれ方も一緒に持ち込むことになるので、移行後の経路メンテナンスの手間は変わりません。どちらが早いかは、移行の期限と、移行後に誰が保守するかで判断が分かれます。期限が近い場合は、まず移して運用開始後に統合する進め方も選べます。

一覧の行数を前にして、どこから開くかを決めるときの手がかりになれば幸いです。