システム開発の成功に欠かせない分析はどのように行うべきか【2024年最新版】

システム開発のポイントは、開発の「目的」を明確化して、現在抱えている問題点の解決を図ることにあります。
成功するシステム開発プロジェクトは、例外なくこの視点がぶれずにしっかりと確立されています。

例えば、「既存顧客の顧客満足度を高める」ため（目的）、「現在営業マンごとに管理を任せてしまっている顧客データ」（問題点）を「ITシステムで全社的に一元管理する」（解決）というプロジェクトは、目的と問題点の解決が明確化されています。

もちろんこうした視点は、思いつきで出てくるものではありません。
システム開発を成功に導くぶれのない視点を確立するために必要なのが「分析」です。
この分析はIT系のコンサルティング会社に依頼することなどが必要なケースもありますが、ポイントさえ押さえておけば、基本的な部分は自社で行うことができます。

最終的に外部にアウトソーシングするにしても、自社で問題点を大まかに分析したあとに、それを精緻化する段階でコンサルティング会社に調査を依頼するほうが、課題を社内でしっかり共有することができるので望ましいと言えます。

この記事では、現在自社が抱えている業務上の問題点を浮き彫りにし、それをITシステムの新規構築や、システムのバージョンアップ図ることでどのように解決するかを明確化するための「分析」手法についてお伝えします。

システム開発を行う場合の「分析」には、大きく分けて既存の業務システムの分析と、現在稼働しているITシステムの分析とがあります。

いずれにしても、いきなりヒアリングや現状分析を始めるのではなく、下記のような網羅的な方法論が重要になってきます。
すべての項目の分析が完了しないままに開発プロジェクトをスタートすると、あとで矛盾が出てきてプロジェクトが頓挫してしまうことにもなりかねません。

以下、順に見ていきましょう。

システム開発の「目的」とは、開発投資を行うことになった課題について一文でズバッと答えたものです。
これに対して目標とは、目的を達成するために設ける具体的な「目印」です。
目的と目標を混同してしまうと、往々にしてプロジェクトは失敗に至ります。

これから問題を解決していこうとする分野で、まだ社内にITシステムが存在しない場合（先程の例で言えば、既存顧客の満足度を高めるためのシステム）には、業務システムの分析から入ることが必要になります。
この場合には、関係者のヒアリングなどを実施する「要求定義」が必須になります。

既存のITシステムにおいて当初の目的を果たせていないなどの課題がある場合、システムを使った業務フローを整理し、なぜその業務フローが当初の「目的」に結びつかないのかという問題点を抽出します。

システムの内容とは、ITシステムによって実現する機能になります。

新規システムでどんな機能を実現するかについては、発注者サイドの「要求定義」をヒアリングで明確化し、システムの機能に落とし込む「要件定義」が必要になります。

既存システムで実現されている機能について、現場の不満や改良リクエストなどを拾い上げます。

システム構築は、目的に対して、ある意味でゴールのないプロジェクトだと言えます。
「顧客満足度向上」という目的には、次々と新しい課題が出てきますので、それを機能的にすべて実現することは不可能です。
したがって、最優先とされるシステム開発の対象を優先的に抽出して開発対象に線を引くことが必要となります。

新規システムで開発の対象範囲を分析するには、最終的にその機能を実装するかどうかは別にして、将来的に考えられる必要機能をすべてリストアップすることが重要です。
そして、そのなかで今回のプロジェクトに必須の機能を割り出します。
こうした作業を抜きに対象範囲を決定してしまうと、開発が具体的に進展することによって担当者のプランが進化し、次々と追加要求が出てきてプロジェクトの再定義が必要になってきます。

新規システム開発時に対象範囲を立案した際に、優先順位を下げて実際には実装しなかった機能を検討します。
システム開発の当初の目的が達成できない原因として、既存システムの構築範囲を決定したときには重要視されていなかったことが、実は目的達成のために必須であったという場合もあります。
例えば顧客管理システムで「見込み客を半自動化して育てていくマーケティングオートメーションツール」の部分は時期尚早として開発対象範囲から外していたものの、その後急速にリードナーチャリングの必要性がクローズアップされてきた、などはよくある話です。

システムの実施期間は、「プログラマの人数」×「稼働時間」というシンプルな計算式で決まります。
つまり、開発に割く技術者の人数を増やせば稼働時間（納期）は短くなりますし、小規模の開発会社で人数を増やせない場合には、納期は長めになる傾向にあります。

新規システムの開発詳細が要件定義を経て設計段階まで完了すると、新規システム構築に適切な開発期間が出てきます。
このときの開発期間は、どれくらいの開発人員を割り当てるかによって決まってきます。
したがって開発期間が長いと感じる場合には、開発要員の割り当てを増やしてもらいましょう。

既存システムの改良は、一般的に新規システムよりも短納期で完成します。
しかし、分野によってはその開発会社の実施期間が世間の相場よりも長いという場合もあります。
既存システムの改良については、外注先の第一候補は最初にシステムを導入してくれた会社になります。
しかし想定している開発期間がこちらのイメージよりもかなり長い場合には、別の会社も候補として検討することが必要です。

実施体制とは、発注側のどの部署がシステム構築に関わるかということを指します。

新規システム構築においては、現場で業務を推進している部署のほかに、情報システム部門、トップマネジメント層などの関与が必要になる場合もあります。
これは、システム構築の目的が単なる業務の効率化だけにとどまらず、全社的なBPR（ビジネス・プロセス・リエンジニアリング）の実現などの場合があるからです。

既存システムの改良の場合には、まず現状分析が必要になりますので、主体は現場で実際にシステムを使っているユーザーになります。
しかし、分析が進むにつれて、改善に必要なのは全社的な対応である、という結論が出る場合もあります。
その場合には、情報システム部門やトップマネジメント層の関与が必要になります。

システム開発の実施方法には、大きく分けて伝統的な「ウォーターフォール型開発」と、小さな成果物を次々とリリースしていく「アジャイル型開発」とがあります。
新規システムにはウォーターフォール型が向いているとか、既存システムにはアジャイル型開発が向いているなどの傾向性はありません。下記のような判断軸で、案件ごとに分析することが必要です。

現在稼働中の汎用機システムをオープンシステムにそのまま移行したいとか、凝った仕組みは要らないからとにかく本店と支店の営業データを共有したいなど、どのようなシステムを組みたいかが明確になっている場合に適しています。

ゲーム開発でユーザーの反応を見ながら次々バージョンアップを繰り返すなど、市場の反応を見ながら最適な戦略でアップデートしたいという場合にはアジャイル型開発が適しています。

上記の判断を行うにあたっては、こちらの記事もぜひご参照ください。

実施費用分析は、平たく言うと見積もりの妥当性となります。
見積金額の妥当性は、実現する機能によって変わってきますので、RFP（提案依頼書）を配布するなどの同一条件下で相見積もりを取得して分析することが最も確実です。
同一条件でないのに、金額だけを比較することには意味がありません。

アプリケーション分だけでなく、インフラや保守などの非機能要件についての分析を見落とさないようにします。

改良部分にどれくらい費用がかかるかですので、範囲的には新規システムよりも見積もり比較がしやすいと言えます。
ただし、同じ部分の改良案であっても、改良方法、内容には違いがありますのでその違いを考慮して比較分析しないと意味がありません。
例えば、A社は見込み客の半自動育成にマーケティングオートメーションツールのパッケージを導入する案を出しており、B社はオリジナルでマーケティングオートメーションツールの構築を提案しているという場合、金額的にはB社の提案が高くなる傾向にありますが、内容的には自社の問題解決に直結している（A社提案よりも優れている）というケースも考えられるので、単純に金額だけで判断しないように注意しましょう。

ここまで、新規システムと既存システムの双方について、分析のポイントとなる視点について解説してきました。
視点の持ち方に多少の違いがあるものの、5W2Hに沿って分析を加えれば、自社の抱える業務フローや既存システムの問題点は明らかになってきます。

ここで、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

既存の比較的大きなシステムで、稼働してからかなりの期間が経っているというケースなどでは、システムの問題点を分析することが困難なこともあります。
次に、そうした中規模以上の既存システムを分析するポイントについてお伝えします。

ITシステムにはさまざまな目的のソリューションがありますが、ビジネスの現場で稼働しているシステムを大別すると「データ処理型システム」と「状態管理型システム」に分類できます。

「データ処理型システム」は顧客データベースなど、データを入力し、加工・編集し、アウトプットすることなどをメインの業務とします。
それに対して、「状態管理型システム」は受発注システムなど、注文⇒在庫確認⇒発送のようにビジネスプロセスを滞りなく管理することをメインの業務とします。

「データ処理型システム」の場合は入出力部分の情報とデータとの関係が整理できれば、システムの全体像を整理することができます。
入出力部分とは普段ユーザーが使っている画面や帳票、外部システムとのインタフェースになります。

「状態管理型システム」は受発注に限らず、あらゆる業務フローの管理を支援しますので、業務の開始ポイントと何を持って業務の区切りをつけるかの終点部分がはっきりすれば全体像を整理することができます。
この始点と終点部分に関しても、普段ユーザーが使っている入力画面や状態の管理画面、終点部分の画面などのインタフェースに着目することで流れが見えてきます。

数年間稼働しているような既存システムの分析で問題となるのは、有益なドキュメントが存在しないという点です。
システム納品時のマニュアルはあっても、最低限の使い方しか記載されておらず、実際にどのように業務フローを構築しているのかは、設計図を見なければ解読できないというケースがほとんどです。

そうした場合には、実際にユーザーが行っている業務フローに沿って、システム画面のハードコピーを取り、状態の遷移を把握することが有効です。
どのようなアクションを起こしたときに、どのように画面が遷移するのかを整理しておきましょう。

ハードコピーを活用したインタフェースの遷移図を見ながら、その遷移図にオペレーションをしている人が感じている課題点や問題点を書き込んでいきます。

さらにその問題点がシステムのどういった動作によって引き起こされているのか、より望ましいオペレーションをするときに何が制約条件となっているのかなどについて、データベース構成図やER図などの納品時の技術資料をもとに推測をつけます。

システム的な問題点がこうした社内の調査で浮かび上がってくれば、その時点でRFPを作成して、複数の業者に声をかけ始めることができます。
また、データベース構成図やER図などを使って問題点を探り出すという作業が困難であれば、遷移図に課題点や問題点を書き込んだ段階で、システム開発会社やコンサルティング会社に相談を始めるということでもかまいません。

現状の課題点や問題点が整理できたら、そうした点をどのように解決したいのかについてまとめておきます。
「データ処理型システム」であれば、データの活用方法を改善することによって、何を実現したいのかを明確化します。
例えば、顧客データベースの「データ抽出に課題あり」とした場合、見込み度合いによってデータ抽出をもっと段階的にきめ細かく行えるようにし、少しでも見込みがあるお客に迅速にアプローチできるようにしたい、というような改善の方向性をはっきりさせます。

また「状態管理型システム」の受発注システムであれば、外部業者に配送を依頼するとき、現場でシステムを使った確認作業ができず、いつも電話で確認を入れているという作業が課題だったとします。
この場合、発注確認業務がすべてシステム内部で解決できるようにするというのが、解決の方向性となりますので、それを明記したドキュメントを作っておきます。

ここまでの準備がしてあれば、中規模以上のシステムであってもRFPを作成して、システム開発業者からの提案を募ることが可能です。

以上「分析」という作業をキーワードとして、システム開発成功のためのポイントを整理してきました。
「分析」と聞くと尻込みしてしまう担当者の方もいらっしゃるかもしれませんが、新規にせよ、既存システムの改良にせよ、システム開発を成功させるには「目的」を明確化して現状の問題点、課題点の解決を図るというスタンスが大切です。
それには、適切な「分析」作業が不可欠なのです。

もっとも、この「分析」作業のすべてを発注者側で完全に行ってから業者に声をかけなくてはいけないわけではありません。
システム開発会社のなかには、こうした分析を得意とする会社もたくさんありますし、分析そのものを専門に手がけるコンサルティング会社もあります。
アイミツにお声をかけていただければ、貴社の課題点を適切に分析するところから手がけて、最終的にシステム構築を成功に導いてくれる会社を複数ご紹介できます。

分析に強いシステム構築会社、コンサルティング会社をお探しの場合には、ぜひ「アイミツ」をご活用ください。