失敗したくない！システム導入を進める前に考えたい10項目

経済情勢やマーケットに加え、最近では労働市場の変化に合わせて、企業も変わっていく必要があります。それに合わせて素早い経営判断・運営をするためにシステムも新たに導入したり入れ替えたりする必要も出てきます。
しかしながら、新しいシステムの出現やテクノロジーの進歩のスピードは速く、何が自社にとって最適なのかを判断するのが困難になっているのも事実です。
たとえシステム導入が完了したとしても、当初の目的の一部のみの達成や予算オーバーあるいはスケジュールの遅延で終わるケースも多々あります。
今回はシステム導入の検討に際し、成功率を高めていく上で必要と思われる事項を、経営視点と現場視点の両面から厳選し概説します。
 

■経営視点で押さえるべき事項

経営視点として、プロジェクトマネジメントの視点を活用して説明します。押さえておくべき主なポイントです。
1.ビジネスとプロセス、システムの全体像の確認
自社のメインビジネスは何か、目標を達成するためのプロセスは何か、それをサポートするメインのシステムは何か、広い視野で理解します。
現在利用しているシステムの入れ替えであっても、マーケットの変化によってシステムの全体像（もしくは一部）を変える必要がないかをきちんと検証します。
2.システム導入スコープの特定
システム導入を検討する上で、「対象となるメインの部門や部署はどこか」また「プロセスとシステムの範囲」を特定し、システム導入のスコープ（範囲）の大枠を決めます。
さらに、システム導入の結果、社内外の顧客に対してどの程度の影響が出るか見極める必要があります。例えば、請求書電子化システムを導入する場合、請求書を紙で郵送していたものを電子化して送信することになるため、少なからず取引先の経理処理のフローに影響が出ます。
社内だけではなく社外への影響範囲を想定したテスト計画も必要であり、スコープを増やさなければならない可能性もあります。
3.目的の確認
「何のために導入をするのか」「どんな課題を解決するためなのか」、システム導入の目的を明確にし、関連部門間で共有します。目的が不明瞭なシステム導入を進めてしまうと、必要のない機能を追加したり、スケジュールがずれたり、関係者が勝手なことを言い始めたり、様々なトラブルに見舞われ、結局誰も使わないシステムを導入することになってしまいます。
4.オーナーシップとプロジェクト体制の確認
システム導入を進める上で、どの部門が責任とオーナーシップをもつのか明確にします。
プロジェクトは、時間や費用、労力がかかります。ゆえに誰（どこの部門）かがオーナーシップを取ってプロジェクトを推進しないと、当初の前提条件が変わったり、方向性の調整やスコープの変更・再承認が頻発することになり、結局、途中で尻すぼみする事態に陥ってしまいます。
プロジェクトを主体的に推進するオーナーシップの明確化はとても重要です。
（オーナーシップはリーダーシップよりも当事者意識が強い表現と考えてください。）
5.基本システム導入案の立案
目的、予算、スケジュール、プロジェクト体制などをシステム導入企画書の形にまとめ、マネジメントの了承を受けます。また、進捗管理やマイルストーンごとの報告手続きについてもドキュメントにしておく準備をします。
 

■現場視点で押さえるべき事項

次に実際の現場視点から押さえておくべき点を概説します。
6.現場視点から見た詳細スケジュールの立案
基本スケジュールに基づき、現場視点に立った詳細なスケジュールを立案します。
ユーザニーズと機能の確認（要件定義）
システムを使用する担当者が希望する機能、目的を達成するための機能の確認。また、現行システムがあれば機能の比較。
設計、開発と単体テスト
要件定義に合ったシステムの選定もしくは設計。システム選定でもカスタマイズや個別開発が必要の場合あり。開発着手後は要所要所でテストを実施。
総合テスト
選定したシステム、または開発したシステムの動作テスト。
本番運用までの計画
要件定義からの抜け漏れチェック、実務担当者によるテスト運用、バグなどの改修期間を想定し本番運用までの計画立案。
策定したスケジュールを進めていくうえで、以下の点が重要です。
7.本当に必要とされている機能はなにか現場の声を聴く
しっかりと実務担当者から必要となる機能についてヒアリングし、現場の声あるいはユーザー要件という形でドキュメント化します。
ありがちなのが、「社員から不満の声があるからシステムを導入する」「ミスが多いからシステム化する」など曖昧な課題から勝手にプロジェクトメンバーが推測して、独断で導入を進めてしまうことです。
導入するシステムがユーザーの求める機能をカバーしていない場合、カスタマイズや開発が必要となります。
8.ユーザー要件の優先順位付け
ただし、現場の担当者は、自分が担当しているプロセスとその前後のプロセスについては理解しているものの、全体的なプロセスの中での位置付けを理解しているわけではありません。
したがって、現場の声にもとづくユーザー要件は、プロジェクトのオーナーを中心に優先順位を付与した上で、カスタマイズや開発に回します。
この際、担当者への伝え方を間違えると、反発を買い、プロジェクトが行き詰まるという危険性があるので注意が必要です。
9.ユーザー要件をITサイドが理解できる用語への置換え作業　
システムを使用する担当者とIT担当者の間で、意思疎通ができないケースが多々あります。効率的にカスタマイズや開発を進めるうえでも、ユーザー要件をITサイドが理解できる用語に置き換え、伝えるという作業が発生します。
（IT担当者およびITサイドとは、主にシステムベンダーおよびシステム開発会社などを含みます。）
ちなみにこの作業は、理想を言えばビジネスアナリストが行いますが、日本の場合、ビジネスアナリストが介在するシステム導入は一般的ではないため、基本的には社内の情報システム担当者やSE、エンジニアが役割を担うことになります。
また、ビジネスアナリストはビジネスセンスが問われる職種です。“ビジネスセンスがないビジネスアナリスト”が担当した場合、ユーザーの期待とはかけ離れたカスタマイズや開発が行われ、時間や費用、労力の徒労という結果となります。
10.システム導入プロジェクトに専念する人材の選定
ユーザー要件の確定、開発や単体テスト、総合テストを経て本番運用に至るまでの間、日常の業務から離れ、プロジェクトに専念できる人材がアサインできるのが理想です。できないとしても、「仕事への知識が浅い」「マインドが低い」人材は避けた人選をしましょう。
よくある失敗パターンは、「エース級は忙しいがから新人に勉強のために担当させよう」です。メインの目的は少なくとも新人の勉強のためではないはずです。
また、通常業務をある程度犠牲にしてプロジェクトに参加することになるため、プロジェクト完了後は、部門としてもスムーズに現場に復帰できるような考慮や気遣いも必要です。
 

■なぜ失敗してしまうのか？

いざ導入をしても、期待した機能が実装されず、手作業が増えたというケースが多々あります。システム導入の検討の際に、上記10項目において不十分な点があれば、失敗の要因となります。
その中で、特に留意して頂きたい点をいくつか解説します。
導入して満足してしまっている
プロジェクトマネジメントに従ってシステム導入を計画し、進捗を管理、マイルストーンごとに報告を行っていても、必ずしも予定通りにいきません。特に、予算オーバーや導入スケジュールの遅延を回避するあまり、導入自体が目的となってしまうケースがあります。労力と時間がかかったプロジェクトゆえ導入して安心しまうのは気を付けましょう。
ユーザーに対する配慮がなければ、反発を買うだけ
システム導入により業務が簡素化される場合、プロジェクトにかかわる社員や対象となるプロセスの担当者は、将来に対する不安を感じます。将来の処遇に対する不安の解消や動機付けなど、担当者への配慮が大切です。
スコープの見誤り
システム導入のスコープを見誤るケースは多々あります。多少の軌道修正で対応可能の場合もありますが、スコープを特定する際、十分な考慮を払っていない場合、プロジェクトの進捗とともに、スコープが広がり、収集がつかなくなる危険性があります。
重要なのはプロジェクトリーダーが要望や情報をスコープに合わせて取捨選択することです。また、独断と思われないためにも関係者を納得させる交渉と根回し（日本ぽいですが）も必須です。
広い範囲で始めている
業務の担当者、ITの開発者、ビジネスアナリスト、プロジェクトマネージャーといった各メンバーの資質、経験や能力には個人差があります。そうした個人差を度外視して、全てのサブプロジェクトを同時に行おうとしても、どこかでほころびが発生し、失敗するリスクが高まります。失敗のリスクも考え、まずは狭い範囲からスタートし、プロジェクトに慣れてもらうとともに、成功体験を積み上げてもらうシナリオ設計が重要です。
ただし、あまりに狭い範囲のプロジェクトを続けていくと、いつシステム導入が完了するか、不明瞭になります。予算オーバーやスケジュールの遅延の要因となる危険性があり、注意が必要です。
 

■システム導入時には綿密な計画が必要

システム導入を検討する際、経営視点で大きな枠組みとなる基本的なシステム導入案を企画し、目的やスコープあるいはオーナーシップと体制を社内で共有し、マイルストーンごとにシステム導入の進捗だけでなく、目的と方向性の確認ができるようにしましょう。
また、現場視点の詳細なスケジュール案を策定し、ユーザー要件の確認、開発や単体テスト、総合テストと本番運用をカバーしていく必要があります。その際、システム導入に対するユーザーの不安の解消や動機付けといったユーザーへの配慮が不可欠です。
上記の10項目をベースに、具体的な形でシステム導入を検討してみてください。仮に失敗したとしても1回でも経験していれば、次のプロジェクトのたたき台にもなるため無駄になることはないです。