2015年に出版した
『業務効率UP+収益力UP 中小企業のシステム改革』幻冬舎 (2015/9/18) より
書籍内のコンテンツをタイトルごとに公開いたします。
コンテンツの最後に、コンサルタントのコメントを追加しておりますので、合わせてご覧ください。
P.114～
第3章 ベンダー任せにするな。改修の成否は「業務プロセス」の徹底的な洗い出しで９割決まる
システム計画策定の手順
図表８は、私たちが「業務適合性」を評価し「システム計画」を策定するときの手順になります。
以下、図に沿って手順を説明していきましょう。
（１）プロジェクトキックオフ
社内のＩＴシステムの評価と、（場合によっては）新システムへの入れ替えは、経営に直結する重大な課題です。
また、社内の業務プロセスを綿密に調査するためには、全社員の協力が必要ですが、その協力を得るためには、ＩＴシステム評価更新プロジェクトへの理解も必要になります。
そこで、社内でプロジェクトチームを組んで、一定の影響力を持つ人をプロジェクトリーダーに任命し、本気で取り組む姿勢を見せなければなりません。経営者自らがプロジェクトリーダーになるくらいの心意気があれば、きっと成功するでしょう。
プロジェクトの目的は、システム環境改善計画の策定で、そのために業務調査を行います。
業務調査には大きく分けて二つの種類があります。一つは「個人別業務調査票」で、もう一つは「帳票調査票」です。
個人別業務調査票とは、誰がどんな作業を、どれくらいの時間をかけて行っているのかを、客観的に把握するものです。１日、あるいは１週間、もしくは１カ月の間に、どの作業にどれだけの時間をかけているのかを自己申告してもらいます。ときには調査員が職場に常駐して、第三者の視点で作業の様子をチェックすることもあります。
帳票調査票とは、会社内で使われている帳票を把握するものです。業務システムが出力するものは比較的簡単に種類も数も把握することができますが、それ以外に、各部署で独自にエクセルなどで作成されている帳票も多数存在するため、もれなく集めるのには時間がかかります。
帳票の作成と確認は、人力で行うには手間のかかりすぎる単純労働です。帳票の作成とその中身のデータベース化こそ、ＩＴシステムの最も得意とする業務と言うことができるでしょう。しかし、コンピュータが登場するまで、長いこと人の手によって作られて、完成度を高められてきた帳票を、ＩＴシステムの手にゆだねるのはそれほど簡単なことではありませんでした。
そのため、次のような笑い話も流布されています。
とある企業は、ＩＴシステムを導入した結果、かえって手間が増えて業務効率が悪くなってしまったそうです。なぜなら、システムが導入される前の業務は、手書きで帳票を作成して、上司に提出してハンコをもらい、ファイリングするだけだったのですが、システム導入後は、コンピュータにデータを入力して帳票を作成し、それを出力（プリントアウト）して、上司に提出してハンコをもらい、さらにファイリングしなければならなかったからです。
このジョークのポイントがわからなかったとしたら、皆さんの会社も、システムを使って業務を非効率にしているかもしれません。
ＩＴシステムの主な仕事は、データの記録と分析と、呼び出しと繰り返しの利用です。システム上で帳票を作成したのであれば、それをそのままオンラインで上司のパソコン（クライアント端末）に送って「承認」してもらえばよいだけです。プリントアウトする必要もファイリングの必要もありません。ＩＴシステムの中のデータは、すべてきれいに保管されているのと同じことだからです。
帳票の作成業務をすべてＩＴシステム化するだけで、会社内における人の仕事はかなり減ることでしょう。新規データでない限り、繰り返して入力する必要はなくなり、簡単な操作で過去のデータを呼び出すことができます。また、所定の位置に数字を入力するだけで、計算はすべてシステムが瞬時に行ってくれますし、ミスもありません。
しかし、人間はＩＴシステムの特性や長所をあまり理解してくれません。紙で作っていた時代と同じようなレイアウトを要求したり、細かいデザインにこだわったり、出力しないと安心できないなどと言い出します。その結果、システム化の良さが損なわれて、業務効率が向上しない事態が、21世紀になった今でもどこかの企業で繰り広げられているのです。
（２）業務調査票の配布と回収
業務調査票および帳票調査票を、基本的にすべての社員に配布し、各部署にて記入してもらいます。１週間から10日程度で回収します。調査票の内容によっては、対象社員にヒアリングを行い、さらに詳しく業務内容を聞き出します。
回収した業務調査票を分類し、部署ごとに各業務の時間を集計します。定型業務にどれだけ時間がかかっているかを見ることで、ＩＴシステムの入る余地があるかないかを調査します。
同じような業務について、システムを使っている部署と使っていない部署があるので、すべてＩＴシステム化すればどれだけ時間が短縮できるかが計算できます。
（３）予備調査
現行システムのドキュメントなどを集めて、システムの概要を把握します。会社内にドキュメントがなければ、開発を担当したベンダーなどに問い合わせてみてください。
また、現状の経営課題、今後の経営方針、ＩＴシステムへの要望などを経営陣にヒアリングしてまとめます。ＩＴシステムは、ただ現場の業務効率を向上させるだけでなく、蓄積したデータの分析を通じて、経営課題や経営方針にも貢献する技術です。
このように、ＩＴを経営戦略の一部として活用するための、中長期の具体的な方針や計画を「ＩＴ戦略」と呼びます。
現代のビジネス環境において、ＩＴや情報システムの存在は、多くの業種で欠かせないものになっています。ＩＴ戦略は、経営戦略に沿って適切なＩＴ投資を行い、効果的にＩＴを活用するための指針となります。
ＩＴ戦略をしっかりと策定することで、ムダなＩＴコストを削減し、企業の競争力強化へのＩＴシステムの貢献度を効率化することができます。
逆に、経営陣がきちんとしたＩＴ戦略を意識してこなかった企業では、次のような問題が起きています。
・長期的な経営戦略に適合できないシステムを構築してしまったために、わずか２年後に、システムを新しく構築し直す必要に迫られてしまった。
・ハードウェアの保守期限が迫っていたので、ベンダーに言われるがままにハードウェアを先行して新しく導入した。しかし、システム変更時のソフトウェア設計で、当初導入したハードウェアでは必要な機能が実現できないことがわかり、ハードウェアを買い直すことになった。
・現場における個別のユーザーニーズのみを反映したシステムを構築した結果、経営戦略上あまり重要ではない部分でのＩＴ投資が大幅に膨れ上がってしまった。その結果、投資効果が上がらないものになった。
・特定製品を前提としたＩＴ戦略を立案したが、数年後、その製品が日本から撤退することになった。その結果、ＩＴ戦略策定を最初からやり直すことになってしまった。
・部門ごとに最適化したシステムを選択した結果、それぞれがばらばらの製品を導入してしまい、情報システム全体の管理が煩雑になった。また、部分最適のシステム導入によって、データが分散してしまい、業務を経営視点で一括管理することができなかった。
部分最適化の例としても、帳票を挙げることができます。従来の仕事のやり方に固執する現場は、たとえＩＴシステムの導入によってシステム内で帳票のやりとりが可能になったとしても、従来どおりに帳票を出力しての受け渡しを好みます。
しかし、特に海外製のパッケージ・ソフトウェアなどには、ムダな帳票の出力機能がついていないことが多いのです。そこで、追加料金を支払ってアドオン（機能追加）などが行われることが多いのですが、それだけで何百万円というアドオンコストがかかってしまいます。
本来的には必要でない機能のために多大なコストをかけることは、経営視点で見ればマイナスでしかありません。
現場の人間がどんなに真面目に仕事に取り組んでいても、会社全体で見たときに、何が必要で何が不要であるかという判断までできるわけではありません。経営者による大局的な視点でのＩＴ戦略がきちんと策定されていないと、どうしてもムダが多くなってしまう所以です。
ＩＴ戦略は、事業計画にも匹敵するような経営の基盤です。経営者の方がＩＴ戦略を意識することで、企業の経営は盤石なものになります。
（４）現状ヒアリング
回収した業務調査票をベースにヒアリングを行います。ヒアリングの目的は、現状の業務とシステムの利用状況を把握することです。
私たちの場合は、一部署に対して１コマ２時間くらいを想定しており、１日あたり３コマのヒアリングを行っています。ヒアリングの後には文書での議事録を作成し、ヒアリングの対象者に間違いがないかレビューをしてもらいます。
（５）問題点取りまとめ
現行システムと業務プロセスの問題点を把握して構造化し、その原因を分析します。
やり方としては、まず問題点を抽出します。各種の問題点は、基本的にはヒアリングから得るものですが、それだけでは現場が認識している課題だけになってしまいます。
そのため、可能であれば、他社との比較を行うことで、自社における非効率な業務の進め方などの課題を新たに見つけ出すことができます。
私たちの場合は、同業種や同業界の事例をもとに「他の会社ではそのようなことはしていませんよ」という第三者視点でのアドバイスも行っています。
次に、抽出した問題点を業務効率や管理水準などの視点で分類、集約し、顕在化している問題点として取りまとめます。
取りまとめた問題点は、一般的に「なぜなぜ分析」と呼ばれている手法で、本質的な原因を明らかにしていきます。
（６）中間報告会
現状の問題点分析の結果をプロジェクトメンバー間で共有し、検討します。
（７）Ｔｏ Ｂｅモデル策定
現在の業務プロセスや、業種・業態の慣習など、各種の前提条件や制約事項をもとに、最適な業務モデルとシステムの概要を検討します。この、現状で考えられる最適な業務モデルをＴｏ Ｂｅ（あるべき）モデルと呼びます。Ｔｏ Ｂｅモデルの検討は、プロジェクトメンバー全員によるワークショップ形式で行います。
この際に、経営層への報告が必要な事案が発生したときは、適時に経営層との意見調整を行います。
（８）中間報告会
Ｔｏ Ｂｅモデルの検討結果を経営陣に中間報告し、経営上の意思決定を行ってもらいます。
このとき、システムの入れ替えを実施すべきかどうかの方針も協議してもらいます。システムのリプレースを行う場合のみ、（９）以降のプロセスへと進みます。
（９）概要要件定義
業務のＴｏ Ｂｅモデルが決定したら、今度はそれに合わせた、最も効率の良い、あるべきシステムの最終形を模索します。
そして、システムの効率的な利用を前提として、業務プロセス、システム機能の概要の要件を定義します。
概要要件定義とは、ベンダーがシステム開発を行う際の助けになるように、システムが持つべき機能をまとめたものです。といっても、ユーザー企業が定義できる要件には限界がありますから、あくまでも概要になります。
この際に、大きな意味を持つのが業務プロセスの要件定義です。システムはあくまでも業務を補助するためのものですから、業務プロセスの要件がしっかりと定義されていないと、使いにくいものになってしまいます。
たとえば、システムありきで業務を考えてしまうと、どんなささいな業務でも、システムにデータを入力しておいたほうが、記録にもなるし、後々の分析にも役立つという思考になってしまいます。しかし、システムへの入力作業を不必要に増やすことは、業務を滞らせる原因になって、あまりよくありません。
年間に一度しかないような業務については、わざわざＩＴシステムに組み込むよりも、エクセルで帳票を作って、出力してハンコをもらったほうが手軽でコストパフォーマンスの高い仕組みになります。このように、システムの要件定義にあたっては、あくまでも現在の業務プロセスを主眼に、Ｔｏ Ｂｅモデルを考える必要があります。
ベンダーによっては、ユーザー企業が業務プロセスなどをまとめたものを要求定義、それを受けてベンダーがシステムの機能などの仕様をまとめたものを要件定義と言って区別することもあります。
（10）ＲＦＰ取りまとめ
ＲＦＰとはRequest For Proposalの略で、提案依頼書を意味します。
ユーザー企業が、ベンダー企業に、新しいシステムの提案を依頼するための文書なので、そのように呼ばれています。
おおまかな要件定義はユーザー企業のほうでまとめることもできるのですが、ＩＴシステムに何ができて何ができないのか、あるいは、パフォーマンスを上げるために変更したほうがよい機能や仕様などは、専門家であるベンダー企業に聞かなければわかりません。
また、ベンダー企業ごとに、できることとできないことの違いもあります。そこで、複数のベンダー企業やＳＩｅｒに対して、システム提案書と見積りを提出してもらうように作るのがＲＦＰ（提案依頼書）となります。
ＲＦＰには決まった書式などはありませんが、中身が整っていると、ＩＴに詳しい担当者のいるユーザー企業として、ベンダー企業に一目置かれることがあります。逆に、中身が支離滅裂であると、トラブルを招きかねない要注意企業と思われるかもしれません。
（11）中間報告会
ここまでの途中経過と、以降の方向性の確認を経営陣に対して行います。
（12）提案依頼（ＲＦＰ説明会）
各ベンダーおよびＳＩｅｒに対して、作成したＲＦＰの説明会を開催します。ＲＦＰを個別に送付しても、真意が伝わりにくいことが多いので、複数の競合企業を集めて説明会を行うのが通常の流れです。
参加してくれたベンダーやＳＩｅｒに対しては、正式にシステム提案書と見積書の作成を依頼します。
（13）ベンダー選定
各ベンダーからの提案内容（システム提案書、見積書など）を比較して、採用するベンダーを検討します。
（14）最終報告会
最終的に決定したベンダー、ＩＴシステム等を経営陣に報告します。
ITコンサルタントのコメント（2022年07月25日）
システム計画の大きな流れは現在も変わりません。
ただし、次の２つの変化には留意する必要があります。
1点目は、「To Beモデル」を描くことがDXでは最適な手法ではなくなったことです。
To Beモデル（あるべき姿）を策定する手法として、多く用いられる手法が「ベストプラクティスとなるモデルとの比較」ですが、ビジョンやCXを起点とするDXの「ありたい姿（Will Be モデル（※））」はこの手法では描くことができません。
※「Will Be モデル」は弊社の登録商標（商標登録 第6272163号）です。
To Beモデルを描くことが間違いではありません。実現したいゴールを明確にし、ありたい姿・あるべき姿のどちらを検討することが最適なのか、より適した手法を選択することが大切です。
2点目は、システム計画の期間が短期化したことです。
クラウドサービスが豊富な現代では、Trial and Errorを許容する前提でシステム化を早期化するケースが増えました。
従来のように「検討・構築に時間をかけてでも細部まで作り込んだ完成度の高いシステムをリリースする」のではなく、リリースして“運用しながらシステムをアジャスト”させるケースが増えました。
クラウドサービスの充実により概念検証（PoC）の優先度が上がったことや、市況の変化のスピードが上がったことが理由です。
システム計画の大きな流れが変わらなくても、今後も何らかの変化は起こり続けます。
変化を把握した上で、適したプロセスを選択することが大切です。
