【システム開発】委託先選びの重要性！700万円を失った悲しい失敗例を用いて解説
今回も前回に引き続き、これをするとシステム開発は失敗するという点について投稿します。
前回は開発依頼先の選定〜要件定義工程を中心に解説しましたが、今回は、要件定義以降の工程を中心に解説します。
目次
このテーマは2回に分けて投稿します。第1回目は開発依頼先の選定〜要件定義工程を中心に、第2回目となる今回は要件定義以降の工程を中心に説明します。
→第1回目はこちら【システム開発で失敗する原因はこれ！システム開発で、NGな発注者の思考・行動10選！Part1】
※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。
それでは、前回に引き続きシステム開発を失敗に導く、NGな考え方・行動とそれがなぜNGなのかを説明します。
⑪業務の常識はいちいち説明する必要はない
この業界のシステムを作ろうと言うのだから、いちいち業界の常識を説明する必要はないよね。時間の無駄だし。開発するITベンダーがしっかり勉強してくれればいいだけのこと。
→ ×
発注者の思いとしては正しいかもしれません。ITベンダーも開発する業界のことを勉強しておくという事もその通りです。
しかし、注意しなければならないことは、ITベンダーは本当にその業界のシステムの開発経験や、知識は豊富なのか？正しい知識を持っているのか？また、自分が思っている業界の常識は、間違いなく業界の常識なのか？それは、自社の独自ルールではないのか？という点です。
例えば、「ITベンダーは経理システムは精通している」としても、「あなたの業界独自、あるいは自社独自の経理処理を理解している」とは限りません。説明の時間を惜しんで後から後悔するよりは、はじめに認識が同じであることを確認しておく方が安心です。
⑫打ち合わせの内容を記録しない
システム開発って、こんなにも何度もヒアリングやらなにやら、打ち合わせをするんだ。面倒だし、メモなんて取らなくていいよね。あっちが議事録を作ってくれればそれでいいや。
→ ×
「議事録を作るのは開発側の仕事」というのは、いいでしょう。但し、そのことは予めルール化しておいてください。これは何気に重要です。議事録も一つの成果物であり、開発が始まる際に誰が議事録を作成し、どのようにその内容を確認し、承認するのかは決定しておく必要があります。
あなたが、説明した内容を相手が正しく理解できているか。
あなたが、要望した機能を相手が漏れなく把握できているのか。
自分が話したことは絶対忘れないという人はなかなかいないはずです。少なくとも、要点は記録しておき、議事録を確認する際にそこが漏れなく正しく記載されていることは確認しましょう。
⑬質問は手空きの際に対応、本業を優先する
システム開発の打ち合わせだけでも思ったより多くて時間を取られているというのに、打ち合わせの日程の間も、質問が次々と飛んでくる。本業優先にしないといけないから、質問の答えは手が空いた時に答えることにしますよ。
→ ×
現場の方の判断としては、致し方ないところかと思います。本来なら、開発側の質問に対しては速やかに回答できるような体制を整えることが必要なのです。ただ、現場の人を開発担当選任者にできないのがリアルなところでしょうから、その場合は、質問には優先度を付けてもらい、この質問の回答がなければ設計や開発がストップしてしまうという点は速やかに答えるようにしてください。
⑭社内調整はベンダーに任せる
またITベンダーから質問が来たよ。他の部署とデータ連携をどうするかって言う話。忙しいし、それは隣の部署の話しだから、そっちと適当に調整しておいてって言ったんだ。
→ ×
もし、ITベンダーが御社の業務改革を含めたコンサルティングを行っているのなら、話しは変わってきますが、基本的に社内調整はITベンダーの仕事ではありません。何か判断が必要な時、ITベンダーが決定する権限はありませんし、部署の間に挟まれて、仕事が進まない状況に追い込まれることが発生します。
例えば、新システムからは、このデータの責任はどちらの部署にあり、どこが責任をもって入力をするのか、ということはITベンダーは提案できたとしても、決定できません。社内調整はITベンダーへ任せないでください。
⑮いまはアジャイル開発を選ぶべきだ
ITベンダーから、「いまはアジャイル開発ですよ」と勧められているんだよね。ベンダーいわく、「ウォーターフォール開発なんかで開発したら動く画面が見られるのは遅いし、ユーザニーズが変わっても仕様変更には、時間もお金もかかるし、融通が利きませんよ。アジャイル開発なら、直ぐに動く画面も見られて仕様変更にも柔軟に対応できるので、そうしましょう」と言われてる。確かに、それは便利だからアジャイル開発で行こうと決めたのだよね。
→ △
確かにアジャイル開発は短期間で動く画面を見ることができ、仕様変更への対応も早いです。しかし、この手法は向いているシステムと向いていないシステムがあります。ざっくり言うなら、ウォーターフォール開発の手法はカッチリ仕様を決めて、着実に開発を進める。アジャイル開発は大雑把に仕様を決めて動かしてみながら決めていくという相反する違いがあります。
あなたが開発しようとしているシステムが大規模で複雑なシステムであればウォーターフォールが適しています。開発対象のシステムにおける相性がどうなのかを見極めたうえで判断してください。
⑯受け入れテストはよく分からないから適当にしておく
システムの開発も終わりに差し掛かっているようで、受入テストをしてくれと言われているんだよ。テストのやり方なんかよくわからないから、とりあえず適当にやっておけばいいよね。
→ ×
受入テストは要望通りにシステムが動くかどうかを確認する重要なテストです。要件定義書どおりに正しく動作するか、漏れなくチェックしなければなりません。このテストが終了したら、次は本番稼働が待っています。本番稼働の段階で不具合が発生すると業務に支障をきたしてしまいます。受入テストの段階で正しく業務が回るのかをしっかりとテストしてください。
⑰要件定義の会議で話したことは機能に盛り込まれるのは当り前
要件定義の会議の時に、この機能はこんな動作をしてほしいと話しをしたのに、いざ出来上がってみたら、その機能が盛り込まれてないのだよ。これは追加で作ってもらわないといけないし、当然追加料金なんか必要ないよね？
→ ×
要件定義などの場で話題に出たからと言って、「それは開発対象になる」と考えてはいけません。要件定義では、多くの人がたくさんの希望を出しています。そこから、優先順位をつけ、開発対象が決まります。そこには、予算の都合もあることでしょう。
単に、あの時話したから、だけで開発対象になっているとは限りません。要件定義の成果物である、要件定義書に盛り込まれているか確認しておく必要があります。
⑱不具合があったら後から直してもらうのは当然のこと
開発したシステムを業務で使い始めたら、必要な項目がなくて業務に支障をきたしているんだよ。この項目がないと、これを使う部署が動けないんだから不具合として、直してもらうのは当然のこと。
→ △
その項目が必要であることが要件定義書に明記されているならば、直してもらうのは当然です。しかし、その項目が必要であることがどこにも定義されていないのなら、定義を漏らしてしまった発注者側の責任ですので、「直して当然」とはなりません。
業務上必要な機能はもとより、情報や更新のタイミングなどを抜け漏れなく、要件定義で定義できているか確認しましょう。
⑲開発が終わるまで進捗状況は気にしない
今回のシステムは開発に半年くらいかかるようだけど、後はITベンダーに任せて、ゆっくり待っていればいいよね。開発の状況なんて気にしなくても作ってくれるよね？
→ ×
開発の進捗状況は定期的に報告を受けてください。もし、そうしないと最悪本番直前になって、「リリースが間に合いません」という報告が突然舞い込むかもしれません。これは実際にあります。
あなたの会社内でも思い当たることはありませんか？悪い報告をしたくない人。ギリギリになってから、きますよね？これは社内だけの話しではないのです。
⑳分からないことはITベンダーにお任せ
サーバーのスペックがどうとか、開発言語がどうだとか言われるのだけど、分からないことはお任せしてしまっていいよね。問題が起こったら、後から責任を取ってもらえばいいんだから。
→ ×
ITベンダーに「これでいいですね?」と言われ了承し、要件定義書や設計書などに記載してあり、その書類をあなたが承認したのなら、問題が発生したからと言って責任を取れというのは難しい話です。
しかし、もし要件定義書などで、「ログイン時、同時刻に100人のアクセスが集中した場合でも3秒以内にログイン完了の応答が返ること」と定義しており、「これを満たすためのサーバを導入する」となっているならば、選定したベンダーの責任を問う事ができます。技術的に判断が難しい決定事項は、判断するための材料、つまり複数案とそれぞれのメリット・デメリットを開発側に提示してもらい、自身で判断してください。
まとめ
今回は、システム開発を失敗に導くいけない考え方や行動について、要件定義以降の工程を中心に、追加で解説させて頂きました。
前投稿と本投稿にあるNG行動をしないために、適切な開発パートナーの選び方や見積書・契約書の見方など、過去の投稿で詳しく解説していますので、ぜひ過去の投稿もご覧ください。
→システム開発パートナー（発注先）の選び方 Part1【候補を探す】
→システム開発パートナー（発注先）の選び方 Part2【選定する】
→【システム開発】！こんな見積書はNG！見積書はここを見よう
→システム開発の契約書はここに注意！
これまで解説したNG行動に、思い当たることがあるあなた。注意してくださいね！
