失敗しない「システム構築」

システムを構築する際に注意すべき点

重要な基幹システムの構築。
企業にとっては、今後の戦略/成長をかけた一大事業になります。

ただ、なかなかうまくいかないのがシステムの構築であるのも事実。

失敗事例から学び、成功するシステム構築を目指しましょう。

システム開発、主な失敗事例は・・・
  1. 想定した効率化や省力化にならなかった。
  2. 最初の見積からどんどん膨らみ、予算を大幅にオーバーしてしまった。
  3. 納品されたが、トラブル続きで正常に稼働しない。
  4. 操作が煩雑で、使いにくいシステムが出来上がってしまった

など、失敗のパターンは多くありますが、原因はほとんどが共通したところにあります。
それぞれの原因ごとに、対処方法などをご紹介しますので、参考にしてください。

想定した効率化や省力化にならなかった。

システム構築する際は、現状をしっかりと把握し、数値などで目標を設定することが大切です。つまり、成果を目に見える形で予測しておくことです。

例えば、
-現在3時間かかっている伝票処理を、1時間で終わらせたい。
-2名体制の問合わせ業務を1名体制でできるようにしたい。
など、それぞれの業務に要している「時間」「人数」を測定し、具体的な数値に落とし込みます。

要件定義の段階で、この現実の数値と、自社がめざす目標値をシステム開発会社と共有し、どのようにして実現するのか、果たして実現可能な数値なのか、を検討することから始めます。

システムを入れれば自然と、効率化や省力化になる-という感覚で導入すると、他に余計や作業が増えて結果的に作業時間は変らなかった。という結果にもなりかねません。

ただ、システム化の目的は「効率化」や「省力化」だけではありません。

  • 業務の人的ミスを減らし、正確に行う。
  • 取引先に利便性のあるサービスを新たに提供する。
  • 競合他社との競争を優位にするために、新しい業務を組み込む

など、企業によっていろいろな目的があるはずです。

こうした目的を明確にするとともに、是非、システム開発会社と共有し、お互いにコミットしてからプロジェクトを進めるようにしましょう。

最初の見積からどんどん膨らみ、予算を大幅にオーバーしてしまった。

最初の検討段階で見積をした後で、打合せを進めるうちに、必要な機能が増えて結果、見積額が大幅にアップしてしまうことがあります。

  • できれば、この帳票も自動化できないか。
  • やはり、今より管理項目は増やした方が良い。

など、話が具体的になればなるほど、改善したい内容や付加したい機能などが増えてきます。

それ自体は、悪いことではないと思います。
かえって、当初通りに、とんとんと話が進んでしまう方が、議論が深くなっていなかったり、あまり現場を知らずに机上だけで打合せが進んでしまっている危険性を持っています。

ただ、機能の追加は費用に関連してきます。それは依頼者側にとって予算を調達しなければならないことや、スケジュールを再調整しなければならないことになり、大きな負担になります。

ここでできることは、新たに提案された見積をベースに、すべての要件を一度に開発しようとせずに、プロジェクトを2次開発、3次開発のように分割して開発できないかを検討します。

こうすることで、優先順位を明確にすることができます。つまり、骨格(必ず必要な部分)を先に開発し、枝葉(サブ機能など)になる部分はその後に回すようにし、開発フェーズごとのスケジュールや予算を再検討します。

また、1次開発が終わった時点で必ず、それ以降のフェーズについて、機能や費用の見直しを行います。

-あったら良いと思った業務も、実際に稼働してみると必要がなかった
-今となったら、他の方法の方が効果的かも知れない

など、検討する余裕も生まれてきます。

プロジェクトを必要以上に大きくしないことは、依頼者側/開発者側にとっても大切なことです。
こうした検討をしたうえで、お互いに合意するようにしましょう。

納品されたが、トラブル続きで正常に稼働しない。

無理なスケジュール(工期)だったり、開発者側の技術不足やテスト不足、テスト想定が誤っていることにより起きる問題の一つです。

全体のスケジュールの中で、充分なテスト期間を確保することが重要ですが、多くの場合、当初の工程のムリよりは、システム設計や製造の工程遅れのしわ寄せがテスト工程にひびいてきたことが原因になります。

プロジェクトを開始したら、WBS(Work Breakdown Structure)などを使って、作業の進捗を共有するとともに、スケジュールの見直しも適宜おこなうようにしましょう。
何らかの理由があり、リリース工程を動かせない場合は、早い段階で機能を絞り込むなどの調整が必要です。

また、テストのシナリオとして「運用マニュアル」を流用してもらうのも、効果的です。
こうすることで、単体(機能ごと)には動作していても、全体の流れで利用すると不都合が発生するリスクを回避することができます。

中小企業の場合、システム導入時に並行稼働(旧システムと新システムの両方を使用する、または従来の手作業とシステムの両方を運用する)時期を取ることは、人的な部分や作業負担から、なかなか行えないのが現実です。
システムリリース後も、開発業者に問合わせ窓口や、何かあった場合の対応体制などをしっかりとお願いしておきましょう。

操作が煩雑で、使いにくいシステムが出来上がってしまった。

利用者側にとって、操作性はとても重要な要素のひとつになります。

設計段階では、開発者が、仕様書-画面レイアウト(画面のイメージ図)や画面項目仕様書(入力や表示項目などの型や長さなどを記載した表など)で説明をしながら、合意をとっていく方式が多く使われていました。

ただ、いくら資料ベースで説明をされても、なかなかリアルなイメージがわかない、頭に入ってこない-のが現実です。

最近では、デモ/モックアップなどの言い方をしますが、設計段階でサンプル画面を作成し、紙芝居のように全体の流れや画面の表示内容を模擬的に作成し、説明することも多くなりました。

実際に近い画面で検討することで、より実際に動かした感触を設計段階から共有することができます。

依頼段階から、こうしたレビューをお願いすることを前提に、見積や工程を検討してもらうのも良い方法です。

モックアップをレビューする際に、依頼者側が確認する点として

「操作性」(ボタンを押したり、画面遷移したりの動作がムダに多くないか、ボタンの配置は適切か)
「画面の見やすさ・理解しやすさ」(全体の色の統一や、言葉の統一、必須などが一目で解るか)
「ガイダンスは親切か」(確認、注意、エラーなどの警告文は解りやすくなっているか)

などがあります。

関連コンテンツ

[clink url=”http://blog.tact-info.co.jp/blog/archives/product/%E5%9F%BA%E6%9C%AC%E8%A8%AD%E8%A8%88%EF%BC%88%E5%A4%96%E9%83%A8%E8%A8%AD%E8%A8%88%EF%BC%89%E3%81%A8%E3%81%AF”]
The following two tabs change content below.

田邉弘美(たなべひろみ)

メーカーのプログラマーを経て27歳で独立起業。数々多くの企業のシステム構築を手掛けてきました。得意な分野は基幹システムや営業支援、顧客管理など社内業務のシステム構築。プロジェクトでは、主にお客様の要望整理や業務改善などのコンサル部分を担当。私の無理難題も難なくこなす頼もしいスタッフ(技術者)に囲まれ、奮闘の毎日を送っています。

最新記事 by 田邉弘美(たなべひろみ) (全て見る)