効果が見えないシステム開発から脱出する13のチェックリスト

2017/03/17


うまくいかないシステム開発には共通点があります。
依頼者（顧客企業）とシステム開発会社との共同作業が噛み合わないというものです。
システム開発会社が抱える問題をここに詳しく記載しました。
本ページでは依頼者が留意すべき「事前にクリアにすべきポイント」を13個にまとめます。

1. 今、具体的に「何」に困っているのかがはっきりしているか（業務システムの場合）

「データが共有できなくて困っている」や「業務が煩雑化している」ではなくて、具体的にどのように支障が出て、誰が困っているのかを洗い出すことが必要です。誰のために何を解決したいのかが、具体的に浮かび上がらないと、ピントがずれてしまいます。

2. システムに期待することは何かがはっきりしているか（業務システムの場合）

「スピード化」、「大量処理」なのか「人手の省力化」なのか、あるいは「複数のスタッフ間のサービスレベルの均質化」のなのか、または「リアルタイムな情報把握」なのか、何を期待するのかをはっきりさせることです。ここが曖昧だと、関係者によっては期待するものがバラバラになってしまいます。

3. 誰のためのシステムなのかはっきりしているか（業務システムの場合）

「顧客サービスの利便性を高めるため」なのか、「現場部門が効率良く作業するため」か、あるいは「経営の武器にするため」なのかで、誰にとっての利便性を優先させるのが異なってきます。裏返すと、誰かの負担が増えたり、誰かの仕事のやり方を変える必要があるため、大義名分をはっきりさせておくことが必要です。

4.システムを導入した結果、どのように「なっていたい」のか

「解決して欲しい」ということでなく、導入後のイメージを持ち、そしてそれを共有することが重要です。
また「どんなシステムが欲しい」ではなく、システムが新しくなった結果、組織や現場が「どういう状態」になっていれば満足するのかを先にイメージしたほうが、何を作るのかといった課題設定がやりやすくなります。

5. システムの理想目標と、最低限クリアしなければならない目標について

システムの理想目標を明確化することはもちろん、最低限クリアしなければならない目標も併せて設定する必要があります。「予算とスケジュール」と折り合いを付けるために必要だからです。現実的な目標をどこにおくのかは、システム開発担当者（担当セクションもしくはシステム会社）と共に定義することになります。

6. 社内のシステム管理者、担当者のスキルやポジション

システム開発を外部に発注する場合、システム会社の窓口になる社内の担当者が必要になります。業務に精通し、社内的な権限がある方が進めやすいため、マネジメント職が適しています。 ただ多忙な場合が多いため、別の担当者をおくこともあります。いずれの場合も、担当者とシステム会社とが情報交換を行ううえで、そのスキルやポジションは重要なポイントです。

7. 誰がそのシステムを使うのか

システム完成後、それを実際に使用する人は誰で、その使用頻度はどれくらいかを明確にする必要があります。コンピュータシステムに詳しいか否か、インターネット系のシステムに慣れているかどうかなどによって、設計時点から対応させる必要が出てくるからです。この部分を明確にしないと、後で設計変更が出る可能性があり、スケジュールの遅れにつながります。

8. 第三者アクセスの範囲はどこまでか

開発対象となるシステムに、第3者（取引先、代理店、会員など）からのアクセスがあるかどうかです。
システムの利用者をどこまで広げるかでシステムに必要となる条件が変わってきます。まず利用者に応じて適切なセキュリティのレベルを検討する必要があります。また相手先毎に、アクセスできる情報の範囲や加工の仕方を検討する必要も出てきます。

9. 他のシステムとの連携があるかどうか。ある場合はその内容について

まず社内システムとの連携の有無についてです。経理との連携、在庫・商品など基幹データベースとの連携が考えられます。連携がある場合は、必要とされる条件について関係部門から情報を集めておく必要があります。次に社外システムとの連携がある場合は、相手先のやり方に合さないといけないときと、自社のシステムに相手が合わせてくれる場合とがあり、工数への影響が大きいため、なるべく詳しい情報を事前に把握する必要があります。

10. 既存システムをリニューアルする場合、既存システム仕様を全て伝えることができるか

よくありがちなのは、システム開発担当者に対して「基本要件については既存システムを参考にして欲しい」という依頼方法です。既存システムを作った会社とリニューアルする会社が別の場合、ほぼ間違いなく問題が発生します。それでも既存システムの仕様書が存在する場合には問題も解決しやすいのですが、多くの場合、仕様書は無いか、あっても不十分なものです。システムは「業務」があってこそのシステムですので、既存システムが「何故そのように作られているのか？」という理由を知ることなく理解することは不可能です。シシテム開発担当者に、背景を含めて詳細に伝えることができるかどうかがポイントになります。
（逆に機能のひとつひとつを「業務」とマッチングさせる作業を行うことができれば、必ずしも既存システムの「仕様」を明確にする必要はありません）

11. 参考にしたいWebサイトがある場合、ビジネス要件を全て伝えることができるか

第10項でも触れましたが、これと同じ理屈で、システム開発担当者に対して「このサイトを参考にして欲しいので、あとはよろしく」という伝え方では、ほぼ間違いなく問題が発生します。
戦略は往々にして目に見えないため、表面上の機能を参考にするだけでは、本来の意図を踏み外す可能性がおおいにあるからです。

12. システム会社の担当者との相性はよいかどうか

システム開発を外部に発注する場合、担当者との相性はとても重要です。一般にシステム開発は数ヶ月に渡るため、担当者との付き合いは長くなります。長い打ち合わせの合い間で雑談ひとつも交わせなかったり、自分の意見を押しつけようとする相手と何回も会うのは苦痛です。結局おっくうになって適当になってしまっては困ります。また依頼する側は、その間、関係者との調整や、システム環境の手配、運用保守の体制など、頭を使うことがたくさんありますから、話しの通じない人と何時間も話をしていたらストレスが溜まります。それでは良いシステムは生まれません。波調が合う相手と仕事をするにこしたことはないのです。

13. 技術知識がなくても明確なビジネス目的があるか

システム開発を外部に発注する場合、専門的な技術知識がなくても、明確な目的が決まってさえすれば、ゴールへの道筋を考える際に、システム会社から有力なアドバイスや力を受けることができます。逆に言うと、ここがブレていると、出来上がるシステムもピントがずれてしまいます。

この記事を書いた人について

谷尾 薫
谷尾 薫
オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。

関連記事