社内プロジェクトー販売管理システムの導入と失敗（後半）

ご覧いただきありがとうございます。

ITコンサルティング事業を展開する弊社では、中核事業（CIOアウトソーシング事業）の一つとして「IT調達支援サービス」を提供しています。

今回は、普段私たちがどのようにコンサルティング業務を進めているか、社内プロジェクトとして実施した販売管理システム導入プロジェクトの内容を紹介します。（後半）

前半の記事はこちらです。

マネージャーの参画とプロジェクトの立て直し

実行計画書の作成

プロジェクト立て直しのとっかかりとしてまず初めに作成したのが、「実行計画書」です。

実行計画書とは、プロジェクト体制図や現状のシステム構成図、課題等といったシステム導入にかかる計画を記載したものです。実行計画書の作成により、状況が可視化されるため、その時点で何を検討し決定して先に進めるのかをプロジェクトメンバー内外で把握しやすくなります。

立て直し前は「実行計画書の目次」の内、No.1、3、6、8（グレーの部分）を完了していましたが、特にNo.2導入スコープとNo.7前提事項の未実施は、前段で「ToBe」を策定できていなかったことによるもので、前工程が後工程に響いてしまったものとなります。

実行計画書（未対応部分）の着手

そもそも顧客とのスケジュールの合意は本来はプロジェクト初期に行うものですが、今回は社内プロジェクトだったこともあり、同時進行で進めている受託案件（外部にクライアントがいる通常のコンサル案件）との兼ね合いで、本プロジェクトにおける明確な着手時期は確定していませんでした。

そのため、工数に若干の余裕がでたタイミングでプロジェクトの準備を始めたことで、全体の計画が未策定のままプロジェクトが開始する形となりました。

今回の立て直しではその反省を踏まえ、全体の計画（実行計画書）に基づいて作業を進めるために初めに、No.5マスタスケジュールの策定を行いました。

策定にあたっては、まず代表の坂本とシステム導入時期の合意形成を行い、導入時期から逆算して作業スケジュールを作成しました。

システムの稼働方針としては、前提として①稼働を2段階で実行すること、②既存会計システムとの連動に大きな影響を与えないこと、の2点を条件に、基本的にトライ＆エラーの考え方で稼働後に調整を行うことにしました。

それらを踏まえ、経営層向けへのリリース（1次稼働）と現場担当者向けのリリース（2次稼働）と段階的な導入が決定しました。

次期システムへの要求要件の策定

次期システムへの要求要件は、そのまま製品評価へと繋がります。
要求要件には、大きく分けて”コスト”と”非機能要件”、”機能要件”の3つの軸があります。

要求要件（コスト）

まず1つ目の”コスト”とは、導入するシステムの①本体価格と②ライセンス料（ソフトウェアを利用する際の1人あたりの金額）、③ランニング費用（システムを維持するにあたって発生するメンテナンス料等）のことです。

①～③のいずれも予算と比較検討するものですが、その際、コストで足切りをするケースもあれば、予算との乖離度に点数をつけ、機能面の評価点との総合点で決定する場合もあります。

要求要件（非機能要件）

2つ目の”非機能要件”は、機能面以外のセキュリティやシステムの脆弱性等についての指針です。

情報処理推進機構（IPA)では下図の６つの大項目と計250個の指標を、日本情報システム・ユーザー協会（JUAS）では大項目10個と計230個の指標を定義しています。

弊社では、IPAの指標をベースに顧客の状況や要望に合わせて、どの程度まで条件を厳しくすべきか、システムの使用用途や停止した際の影響度合い等によってレベル分けをしています。

近年普及が進んでいるクラウド製品は非機能要件が確定していることが多く、ユーザー側で新たに変更できないケースもあります。非機能要件の中でも、特にレスポンス時間やシステムの安定性、情報漏洩リスクの度合いといった項目は満足度の低下に直結する要素なので、入念に確認、検討を行うことが重要です。

要求要件（機能要件）

最後の”機能要件”は、システム導入において最も重要な部分であり、システムで実現したい機能や挙動に関する要求を指します。

機能要件を策定する上では、まず各業務内容ごとに、システムで管理したい情報や見た目（一覧で情報を確認したい、ステータスはｎ段階で管理したい）について条件を洗い出します。

全ての業務工程を製品評価に反映させてしまうと、システムの調査が膨大になるため、絶対に外せない条件や重要視する部分、製品によって差が出やすい部分をメインに評価ポイントを絞っていきます。

しかし、この評価ポイントを詰める過程では、ユーザーの思い込みや認識の漏れ（「あるのが当たり前だと思っていた」等）が生まれやすく、かつ、そのような認識のずれは得てして製品選定後に気づくケースが多いことから、特別に注意を払って進める工程でもあります。

具体的な進め方としては、まずは、現場担当者へのヒアリング内容を元に現行業務の全体感を把握し、大枠で分類します。そして、その業務をシステムで行った際に、どうあってほしいのかというイメージを考えます。

例えば、案件登録業務をシステムで行う場合、「案件および顧客の名称と案件の期間を管理したい」や、「登録した案件は、後で一覧で確認でき、さらに条件で検索したい」という具合に要望を一覧に整理していきます。

整理する際は、要望のランク付け（必須機能やあると良い機能等）をしておくと、後の製品選定が行いやすくなります。

製品選定

今回のプロジェクトは社内導入ということもあり小規模だったため、整理した製品評価ポイント表に沿ってシステムを調査し、弊社の要求とのマッチ度合いを図って優先順位をつけ、代表の坂本にプレゼンを行い、製品を決定しました。

※通常の案件では、弊社が行った製品評価に加え、開発元のシステム会社にデモンストレーションを行ってもらい、経営層と実際にシステムを使うユーザ社員が製品評価をした上で製品決定を行うことが一般的です。

システムの調査の状況については、前半の記事でも紹介した通り、比較サイトから「社員規模、コンサル業界向け、価格」の条件で選定を行った結果、5製品に絞り込むことができました。

今回候補に挙がった5製品は、ノンプログラミング開発でユーザーによる構築が可能であったり、（販売管理機能のほか）経費精算機能がある等の特徴があったため、追加調査を行う前に再度坂本にヒアリングを行い、3製品に絞ってから追加調査を行い、製品評価ポイント表に沿って優先順位をつけました。

導入計画書の作成

製品選定後は、実際にシステムを導入するまでの計画を導入計画書として作成します。
導入計画書の目次は下記の通りです。（一例です）

先にご紹介した実行計画書は製品選定を行うまでの計画書であり、導入計画書は製品選定後から稼働までの計画書という位置づけです。

導入計画書作成時の主な作業としては、No,8,9の移行についての計画を立てることです。
データ方針と業務移行方針は相関関係にあるため、例えば「X日時点のデータを移行する場合はX日はシステムの利用を停止する」や、または「システムの稼働は止めず、差分データ（X日に変更、追加、削除が行われたデータ）を手作業で修正する」等、優先事項を考慮しつつ方針立てを進めました。

ToBe業務フローの作成

導入計画書の作成にあたり、No.5の想定機能概要やNo.6の業務変更点一覧を整理する上では、システムで何ができるのか実際に試しながら、新しく業務フローを作成する必要があります。

既にこの時点では要求事項を機能要件としてまとめていますが、現行業務（AsIs）の業務フローを元に、導入するシステムの仕様と突き合わせてToBe業務フローを作成します。

機能要件で検討した実現したい機能や挙動を、システムのデータ体系（入力したデータがどこに反映されるのか）を意識しながら、実際にシステム上で動かしてみて、整合性が取れているか確認しながら作成していきます。

また、業務の効率性とともにセキュリティや業務状況をイメージしながら、誰がどこまで閲覧して良いかといったアクセス権限も考慮して、業務担当者を割り振っていきます。

マニュアル作成

本プロジェクトで解決したい課題の１つは、業務の属人化でした。そのため、属人化の解消を目的として、今回はToBe業務フローと合わせて業務マニュアルを作成しました。

業務マニュアルに、使用シーンや用途別にユーザがシステムをどのように操作すべきかを具体的に記載することで、ユーザは（システム担当者を介さずとも）システムの利用方法がわかるようになります。（例えば経費精算の場合、①システム画面の”発生日”という項目に「利用した日」を入れ、②”詳細”には「訪問先＞利用区間＞片道or往復」を入力する等）

大規模プロジェクトであればベンダーからマニュアルの提供があります。
今回はマニュアルがありましたが、入力内容の指定や業務を行うタイミング等をToBe業務フローで細かく設定したため、システム画面のキャプチャをとり、Excelで業務フローと併せて、入力内容の解説を記載するという方法でアニュアルを作成しました。

また、システムの初期設定情報や管理者側での設定方法もマニュアルとして残すことで、担当者が退職してもシステムの利用に支障をきたさず、属人化の低減に繋がります。

システム利用の周知

ここまでで、導入計画書に沿ったデータ移行、マニュアルを行い、システムを動かすための準備をしました。ここからは、利用者に対しシステムの利用に向けて周知、教育を行います。

そもそも利用者にとっては、業務やシステムの変更は負荷が大きく発生するものです。そのため、利用者への周知にあたっては、業務の変更点や連絡事項だけでなく、システムが導入されることでどのようなメリットが生まれるのか（作業時間が減る、ミスが発生しにくくなる等）も併せて伝えることを意識しました。

周知、教育にあたり重要な点の一つは、「問い合わせ先（ヘルプデスク）を明確にすること」です。操作に困った場合の問い合わせ先を明確にすることで、利用者の利便性や心理的負担の軽減に貢献できるだけでなく、ヘルプデスク側として発生した課題を手元で集約できるため、詰まりやすい作業を把握しマニュアルの修正に活かすなどのアクションを取ることができます。

稼働後に発生した課題と対応

今回のプロジェクトでシステムを導入した結果、前述した「請求書に案件名が表示されない」と「出力帳票の種類が不足している」という2点の課題が稼働後に判明しました。

請求書上の案件名の非表示

まず1点目の「請求書に案件名が表示されない」という課題ですが、これはシステム導入後に初めて請求書を作成するタイミングで発覚しました。

導入したシステムには、単月の作業分ごとに請求する「都度請求書」と複数月分の作業をまとめて請求する「締め請求書」という2種類の請求書発行機能があるのですが、後者の「締め請求書」では、請求書内に案件名が表示されない仕様だったのです。（まさかと思いました）

私も現場担当者も、「請求書上の案件名の表示は当たり前にある機能だろう」と考えていたため、調査段階でも機能の有無に注意を払うことなくシステムを導入しました。

このような“当たり前”だと認識している機能は、必須要件であるにも関わらず、ヒアリングや検討する段階では発見できず、実際に業務を行う中で問題として発見されることが多いものです。そして、それらは利用ユーザにとってシステムへの不満につながります。

対応策としては、システム外でVBAツールを開発し対応することにしましたが、このような点についても十分に確認しておくことが大切です。

対応により大きな改修や業務変更は発生しませんでしたが、システムで解決したいと考えていた「業務の非効率性と煩雑性の改善」は、想定通りには達成できない結果となりました。

出力帳票の種類不足

次に「出力帳票の種類が不足している」点についてご説明します。
まず、基本的な営業フローと使用する帳票は下記の通りです。

この中で問題となったのは、発注書と完了報告書が発行できない点です。

まず、発注書が発行できない問題について、基本的に発注書はクライアントが作成し弊社が受領する流れが一般的です。とはいえ、中にはクライアントの了承の上で弊社で発注書案を作成し、クライアントにて押印＆弊社に送付するケースがあります。

この問題の発生原因は、ヒアリング対象者がずれていたことです。実際に業務を担当しているのは、今回ヒアリングを行った管理業務担当者ではなく、営業担当者（コンサルタント）の業務範囲であったため、上記のケースを認識できなかった、というものでした。

対応策としては、システム導入前に利用していたExcelツールを再び利用することにしました。

次に、完了報告書が発行できない問題についてですが、完了報告書とは、文字通りプロジェクトの進捗状況等を細かく記載してクライアントに提出するものであり、案件ごとにフォーマットが変わります。

これも、上記と同様の原因で機能の必要性をシステム導入前に認識できず、検討内容から漏れてしまいました。こちらの対応策としては、これまで通り営業担当者に都度作成してもらうこととしました。

まとめ

今回の記事では、自社で使用する販売管理システムの導入過程を説明しました。
本プロジェクトの個人的な1番の反省点は、プロジェクト全体に対する見通しが甘かったことだと考えています。

特に、自分が今行っている作業がプロジェクトに対してどのような影響を及ぼし、最終的にどのような成果へと繋がっているのかについて、見通しの甘さを実感しました。

途中からマネージャー職のコンサルタントに参画してもらい、システム稼働までの大枠のプロセスは把握することができましたが、要求定義といった目の前の作業が、システムでどう実現されるのかの完成イメージが持てず、必要となる帳票の有無や会計システムへの連携可否といった観点について、指摘をもらって初めて気づくことが多くありました。

また、マニュアルを作成する際も、システム調査を行った私自身（情報量：多）と、稼働後に初見となる利用ユーザ（情報量：少）の情報量のギャップを考慮できておらず、周知するタイミングで分かりにくい表現になっていることに気付く場面もありました。

今後は、今回の経験で学んだ各プロセスで注意すべきポイントや観点を意識して、稼働後のイメージを持ちながら作業を進め、必要要件の漏れが極力ないように意識したいと思います。

長文となりましたが、ここまでお付き合いいただきありがとうございました。
他の記事も読んでいただけると嬉しいです！