目 次

業務フローは誰が作るの？

「業務フローは自社で作るんですよね？」
A社の情シスに聞かれたので、田村は「はい」と答えました。

「業務フローはベンダーに作らせるんですよね？」
別のB社の情シスに聞かれたので、田村は「はい」と答えました。

これは田村が忙しさにかまけて、テキトーに答えているわけではありません。

聞かれたタイミングが異なるからです。

現場からよく聞かれる質問ですが、「業務フロー」は自社とベンダーのどちらが作るべきなのでしょうか？

業務フローの教育効果

業務フローは作った本人の「業務理解がものすごく深まる」という側面があります。

作る過程で、業務パターンが作成者の脳内で整理されます。一つの流れとして最初から最後までを、理路整然と語れるようになります。実際に手を動かすことで、記憶としても定着し、強力な学習効果があります。

作成後は「業務のことは俺に聞け」オーラを身にまとい、その後の「キーパーソン」となります。

問題は、この業務フローを誰に作らせるか？

ここが非常に重要です。

自社で作るのか、ベンダーに作らせるのか。

これは言い換えると

どこに「キーパーソン」を作るのか？

ということです。

プロジェクトの文脈によって異なりますが、外注ケースでは「王道パターン」があると考えます。

業務フローの「As-Is」は、「自社」で作ります。

自社でしか、現状業務を正しく可視化することはできません。複数のシステム・ツール・書類を横断する流れ、現場でしか知らないイレギュラー、取引先との対応バリエーションなど、自社だからこそ書くことができます。

これらを業務フローの形式で書くことで、現状業務を上から下まで網羅的に可視化できます。この可視化をきちんと行うことで、課題が浮かび上がってきます。

その課題を解決するために、システム構想、要求整理（RFP）へとスムーズに繋がっていきます。

一方、業務フローの「To-Be」は、「ベンダー側」で作ります。

ベンダーの一番の弱点は、業務の理解不足。そこを補うため、ベンダーは業務フロー「As-Is」をインプットとして、業務フロー「To-Be」を自らアウトプットする。この過程が「業務の引き継ぎ」となるのです。

「To-Be」作成は、現行業務を把握しつつ、課題解決を検討し、新システムとのインタフェースを考えることになるので、とても難しい作業になります。だからこそ、悩みながら、苦労して手を動かすことで、業務内容がベンダー内で腹落ちします。

要件定義でベンダー側にも「キーパーソン」ができれば、その後の設計・開発フェーズにしっかりとした軸が通ることになります。

自社とベンダーの両輪で「キーパーソン」がいることが、その後のプロジェクトリスクを大幅に低減していくのです。

あえて情シス

「そうですよね。では『As-Is』はユーザー部門に作ってもらいます」

違います。

田村は「情シス」に作ってほしいのです。

そこを逃げるから、情シスは頼りにされないんです。「業務は丸投げ」のスタンスを取る限り、永久にユーザー部門から信頼は得られません。

もちろん、一人では作れないので、ユーザー部門にヒアリングは行います。でも、手を動かし、苦労しながら、多くの指摘を浴びながらでも、作るのは「情シス」であるべきです。

その過程でユーザーとの距離が縮まるし、業務も覚えるので「一石二鳥」です。その後の進捗管理や課題管理も介入しやすくなり、会議でもファシリテーションしやすくなると考えると「一石五鳥」です（笑）。

その姿はユーザー部門も見ています。必死に業務に寄ってくる姿が、信頼を呼び起こします。

「私も手伝うので情シスで作りましょう」

田村は必ずそう答えます。

最初は「しぶしぶ」ですが、たいていは最初の1枚を乗り越えると、後は要領を得てテンポよく進みます。

最初に、ほんのちょっとの覚悟を決めるだけです。

貴社の情報システム部門・IT部門は、業務フローを作っていますか？