SaaSは増えたのに仕事は楽にならない? “SaaS飽和時代”に求められる業務設計の考え方

3月18日に開催された「TECH+セミナー SaaS連携 2026 Mar. SaaS飽和時代の“統合による生産性向上” ツール導入のその先、連携を成果に変えるには?」に同氏が登壇。業務設計の必要性と、その具体的な進め方について説明した。

なぜSaaS導入は失敗するのか？原因は「業務設計不足」

SaaSの活用は急速に普及しており、1つの企業が活用するSaaSの数も数十個は当たり前となった。まさに“SaaS飽和時代”とも呼べる状況だ。しかし武内氏は、「これほどSaaSが増え続ける中で、業務は本当に楽になったのか」と問い掛ける。複数ベンダーのSaaSを併用すればその連携も難しくなり、業務がかえって複雑になりかねない。データがどこから来たのか、他部署が何をしているかも分からないなど、業務の全体像が見えなくなることもある。

同氏はその理由を、業務設計をせずにSaaSを選んでいるためだと指摘する。マーケティングや営業活動をどう設計するのかを考えず、何が目的であるのかを曖昧にしたままSaaSを導入しても業務は楽にならない。何を基準にSaaSを選ぶのかが整理されていなければ、部門ごとに最適なものを選んでしまい連携ができなくなったり、結局のところ運用の手間が増えたりする。業務プロセスが整理されていなければ、いくら高性能のSaaSを導入しても何も解決しない。そのため武内氏は、SaaSの選定の前に業務設計を行い、業務プロセスを整理し再構築しておくことを強く推奨するのだ。

業務設計はどう進める？「3つの視点」で整理する方法

業務設計の第一歩は、業務を観察して整理することだ。ここで武内氏が提案するのは、マクロ視点の“鳥の目”とミクロ視点の“虫の目”、それにフローの視点の“魚の目”の3つの目で多角的に業務を見ることである。

まず鳥の目で部門を横断して全体を俯瞰し、虫の目で現場の業務を掘り下げる。そして再び鳥の目で全体を見て、最後に魚の目で全体の流れを把握する。重要なのは、虫の目の後に再び鳥の目で見ることだ。AIやSaaSは個別の処理の自動化には強いが、それが全体と整合しているとは限らない。そのため虫の目で個別業務を見た後に、全体との刷り合わせを鳥の目で確認するのだ。この視点の切り替えを繰り返すことで業務全体のつながりを明確にすることができる。

鳥の目で見るときは、自部門だけでなくその前後の部門の処理がどうなっていて、どうつながっているのかを把握することが重要だ。このときPCではなくホワイトボードで、付箋と太めのペンを使い、関係者が集まって可視化しながら整理するのがよいと同氏は話す。太めのペンを使うのは、細かいことが書き込みにくくなり、より全体を見やすくするためだ。

虫の目で現場を見るというのは、全体の中の自分の業務を言語化することだ。自分は何をしているのかを、他人に説明するように言葉にする。まず自分で整理してから他者と刷り合わせれば、刷り合わせできていないことや定義が曖昧なところが浮き彫りになる。最後に魚の目で見るときは、全員が同じ流れを見て同じイメージを描けるようにすることが重要だ。

業務はどう言語化する？『業務定義シート』の作り方

業務を整理するというと、フロー図をイメージするかもしれないが、武内氏はその前にまず業務を言語化すべきだと話す。フロー図は、認識のズレがあってもなんとなくよさそうなものができてしまうため、しっかりと言語化しておく必要があるのだ。

そこで必要になるのが「業務定義シート」だ。A4用紙1枚に、担当者や対象範囲、目的、インプット（必要な情報）、DO（処理内容）、そしてアウトプット（完了とみなす状態、および成果物）を書き入れる。

• 

  業務定義シート

ポイントはアウトプットと目的を区別することで、これはその業務が何を目的として行われているかを明確に定義するためだという。例えば請求書発行業務なら請求書が成果物であり、その目的は入金によってキャッシュフローを回すことだ。こうすることで、成果物がその目的を果たしているのかどうかを再確認することができる。

業務定義シートは完璧にしようとせず、「簡単につくるだけでよい」と同氏はアドバイスする。まずリーダーがたたき台を簡単につくり、それをベースにディスカッションするのもよい方法だ。

「リーダーがつくってきたものに対してさまざまな意見が出ることがあります。逆に言えば、リーダーから見えていないところの動きが分かる。それが業務の再設計の出発点になるため、この時点でズレがあっても問題ありません」（武内氏）

「業務の全体像はどう整理する？『業務の地図』の作り方

業務の流れを見るのにフロー図は便利だが、つくるのは難しい。そこで武内氏は「業務の地図」をつくることを薦めている。これは業務定義シートで言語化したものを工程に分解し、より簡略化したものだ。構造を把握して認識を合わせるのが目的のため、フロー図のような細部の正確さがなくても、全体の流れを俯瞰できればよい。そのため、これも「簡単に作成できるものでよい」と同氏は話す。すぐつくれるものであれば、すぐに直すこともできるためだ。

• 

  業務の地図

業務の地図はマトリックス形式で、例えば入社対応業務なら、内定通知を人事が行うところからスタートし、雇用契約書と労務データベースへの登録を労務が、名刺作成を総務が担当するというように、工程ごとにどんな順でどの部門が何をしているかを記入する。これにより、業務の受け渡しのタイミングや内容が明確であるか、待ち・戻りが考慮されているか、誰が何を確認するのかが見えてくる。とくに、完了条件を誰がいつ確認するかは曖昧になっていることも多いため、ここで確認することがポイントだ。また、前工程のアウトプットがそのまま次工程のインプットになり、処理後にアウトプットされるという流れも確認しておきたい。アウトプットが不十分であるため再度作業するというような無駄を防ぐためである。

SaaSはどう選ぶべきか？失敗しない3ステップ

ここまでできたら、次はシステムの選定だ。武内氏は、3つのステップでシステムを選定する方法を紹介した。

ステップ1は業務要件、つまり何のために何が必要であるかを整理することだ。業務の言語化を行った業務定義シートに基づいて議論し、必要な機能を洗い出す。もちろんコストとの兼ね合いもあるが、業務に不可欠なものは何かを判断し、マストとウォントを洗い出していく。

ステップ2は、影響範囲を整理することだ。新たなシステムを導入したときに、その業務にかかわる部署はどこか、そのデータをどこで使うのかといったことを、業務の地図で全体を把握しながら検討する。重要なのは前後の工程のつながりを意識することだと同氏は言う。前工程から受け取るデータの内容や形式はどうなるのか、後工程に渡す出力データや帳票はどんな形式であるべきかを把握しておけば、どのような機能を持つSaaSが適切であるかが分かるためである。

ステップ3は評価軸を決めてSaaSを比較することだ。比較する際にはコストも重要だが、それ以外に拡張性や操作性など複数の評価項目を並べて検討することが必要になる。そのために有効なのが意思決定マトリックスだ。それぞれの評価項目がどれだけ重要であるかという重みを設定し、重みと評価点数を掛け合わせて各SaaSのスコアを出す。そうすれば数字で比較することができる。ただし、何のためにシステムを変えるのか、何を解決すべきだったのかという優先すべき課題が明確になっていなければ、このマトリックスで意思決定することはできない。だからこそ業務設計が必要になるのだ。

最後に同氏は、業務設計をする際には業務を多角的な視点で捉えること、関係者で業務を刷り合わせること、そして何度も改善し続けることが重要だと話した。

「完璧な設計図を最初からつくる必要はありません。アジャイルの考え方で、まずバージョンワンとしてSaaSを選んで導入し、想定と違うところは直してどんどんブラッシュアップしていけばよいのです。ぜひホワイトボードの前でディスカッションするところから始めてみてください」（武内氏）