失敗しないシステム開発の発注の仕方


システム開発の成功率はたったの3割とも言われていますが、きちんと抑えるべきところを抑えておけばそれほど恐れることはありません。システム開発に成功する会社と失敗する会社にはある程度パターンがありますので、今までアクシアで見てきた顧客のパターンから、システム開発を発注する時に注意しておくべき点について書いてみたいと思います。

システム開発会社の選び方

システム開発が失敗する理由

これらは以前書いたブログですがこちらも参考になると思いますので合わせてどうぞ。

本気で取り組む覚悟を決める

いきなり精神論のようで申し訳ないですが、これが一番大事です。顧客側のやる気がないとほぼ間違いなくシステム開発は失敗します。よくあるパターンとしては上司からシステム開発を外注するように指示されて担当になった部下のやる気が全くないというパターンですね。

システム開発というのは顧客側と開発会社側で一緒にプロジェクトとして進めていく必要のある仕事です。顧客側もやるべきことをしっかりやってくれないとシステム開発のプロジェクトは進んでいきません。システム開発を担当する責任者となる人にやる気がないようであればすぐに担当者は変えるべきです。

顧客側にやる気がないことほど開発会社側として仕事を進めにくいことはありませんから、システム開発を行うと決めたのであれば、絶対にやり抜く覚悟を決めてからご発注いただければと思います。

ITの素人であることを言い訳にしない

システム開発を行うと決めた以上はITの素人であることを言い訳にしないでください。当たり前ですがシステム開発に成功している企業のほとんどはITの専門企業ではありません。

何もプログラミングをしてくれとかデータベースの設計をしてくれとか、そういう専門知識を要するようなことを顧客にやってもらうようなことは一切ありません。ただし普段からシステム開発を行っているわけではないでしょうから、見慣れない資料を読み込まなければならないこともありますし、聞いたこともないような話題を打ち合わせで行わなければならないこともあります。

その時に「私はITについては素人なのでそっちでやってくれ」みたいなことを言わないでください。普段慣れないことをやるのは辛いかもしれませんが必死でついてきてください。素人であることを言い訳にしてやるべきことから逃げないでください。

人売り企業には絶対に発注しない

この業界のざっくりと8割くらいは人売りとか人月ビジネスと呼ばれるようなことをやっている、実質派遣なのに請負契約や準委任契約のように見せかける偽装請負の企業です。私のブログでは人売り企業については色々と詳しく書いてますが、下記のブログが割りとよくまとまっています。

人売りIT派遣企業はそろそろ壊滅させてもいいと思う

スラムダンクで安西先生が「あきらめたらそこで試合終了」という名言を残されていますが、IT業界では「人売り企業に発注したらそこで試合終了」という有名な言葉があります。嘘です。私が今勝手に作りました。w

とにかく人売り企業と取引して良いことなど何もありませんので、発注先はまともなシステム開発会社を選んでください。

※ 念のため、人売り企業とは偽装請負をやっている違法な会社のことを指しており、まっとうな派遣企業様とは異なります

見積内容は正確に把握する

システム開発と名乗る会社の中には見積書に一行だけ「システム開発費用 一式」とだけ書いて出してくる会社がたくさんあります。こういうのははっきり言って論外です。後でトラブルの元になります。

「一式」だと何がどこまでその費用の中に含まれているかわかりません。そうするとどこまでが見積もりの費用内で対応できて、どこからが追加見積もりとなるのかの線引もできません。こういう見積もりを出してくる会社はおそらく人売りをやっている会社であって、請負契約の見積もりなどまともにできないためにこんな感じで適当な見積書しか作れないのだと思います。

当たり前ですが曖昧なままにしておいた方が後でシステム会社側に仕様変更を無料で押し付けることができるなどと変なことは考えないでくださいね。w

初期開発では最小の機能構成で開発する

システム開発の時に機能を大きく3つに分類するとこうなります。

  • 絶対に必要不可欠な機能
  • あった方が良さそうな機能
  • なくても困らない機能

このうち「絶対に必要不可欠な機能」は開発するのはもちろんですし、「なくても困らない機能」は開発しなくて良いでしょう。問題は「あった方が良さそうな機能」です。

よくあることですがシステム開発を行う時に顧客は色んな夢に胸を膨らませてしまいます。あんなこといいな、できたらいいな。みたいな感じで。でもシステム開発会社は残念ながらドラえもんの不思議なポッケではないんです。なんでもみんな叶えてくれるわけではありません。

システムが完成して運用が開始されると、「作ったけど使われない機能」というのが出てくることがあります。こういうのはたいてい「あった方が良さそうな機能」を作ったことによって生じます。作ってはみたものの実際には別に無くてよかったとなってしまうわけです。

逆に散々検討を重ねてシステムをオープンさせたけど「作ってないけど必要な機能」というのが出てくることもあります。これはどれだけ検討を重ねたところで発生しうることですし、別に悪いことではありません。成功しているシステムであるほど運用後の仕様変更の必要性はたくさん出てくる傾向にあります。

いずれにしても本当に必要な機能を把握するためには「実際に運用すること」が何よりも重要です。最小の構成で費用と時間を最小に抑えて、システムカットオーバーまでのサイクルを最短にすることがベストです。

あれもこれもと色々と機能を盛り込んでしまい、不要な機能をふんだんに盛り込んだ挙句、システムの運用開始が遅れてしまうようなことのないようにしましょう。

発注時期には余裕を持つ

システム開発を思い立ったら早めに開発会社に相談してください。システム開発には数ヶ月単位で開発期間を要することがほとんどです。いきなり相談してきて「今月中にシステムの利用を開始したい」とか言われても無理なんです。

無茶なスケジュールを開発会社に強要しても良いことは何一つありません。無茶なスケジュールを要求された開発会社はそれに対応するために残業や徹夜で対応することになります。そうするとどうしたって品質は低下しますし、最悪の場合はデスマーチに突入していつ納品されてくるのかもわからない状態になってしまいます。

開発期間がどれだけ必要であるかはシステムの規模等によっても変わってくるので一概には言えませんが、アクシアで開発するシステムは平均してだいたい2~6ヶ月くらいの開発期間がかかっています。発注前の検討期間も含めるとさらに長くなると思いますので、できるだけ早めに開発会社に相談してください。

開発会社に丸投げは厳禁

システム開発はプログラミングだけではありません。システムに必要となることを要件定義したり、システムの具体的な形を決めていくための設計もあります。システムが納品されてくれば検証作業も行っていく必要があります。

システム開発全体の工程の中には、要件定義や設計など、顧客と開発会社で協力して行っていかなければならない作業も少なくありません。そうした作業を開発会社側に「後はよろしく」と丸投げしてうまくいくほどシステム開発のプロジェクトは簡単ではありません。

システム開発は顧客の業務を見直したり、新しく顧客の事業を作っていくようなことも含まれていますので、どうしたって顧客側の協力も必要不可欠となります。くれぐれも発注先の会社に投げっぱなしとならないようにしてください。

担当者の窓口は一本化する

システム開発のプロジェクトを進めていく上で、ああでもない、こうでもないと何度もシステムの仕様について検討していくことになります。検討過程の中で仕様は二転三転していきますし、機能間や会社の部署間で矛盾したような仕様が出てくることも珍しくありません。

その時に最新の仕様、正しい仕様を整理するためにも、顧客側の担当窓口(責任者)は一本化した方がスムーズです。そうしないと収集がつかないようなことにもなりかねません。

最悪なのは、顧客側の各従業員に好き勝手に希望する機能の仕様を開発会社側に話をさせることです。各従業員は会社全体で最適化されるように考えるようなことはしませんから、それぞれが自分勝手な要望を出してきて全体として無駄だらけ、矛盾だらけの状態に陥ってしまいます。

情報の交通整理するために顧客側の担当者が責任者となって窓口となることは、各従業員の話を取りまとめたりする必要があるのでかなり大変です。大変なので各従業員に開発会社側と直接連絡を取るようにしてしまう担当者がたまにいるのですが、それでうまくいくようなことは絶対にないのでそういうことはやめてください。

仕様書には穴が空くほど目を通す

システムの仕様について検討を重ねていく中で、開発会社側が仕様書(設計書)を作成して顧客側と共有します。もしドキュメントを一切残さない開発会社だった場合にはやばいと思ってください。

仕様書はそれなりのボリュームになることが多いのですが、この仕様書は絶対に内容のチェックをしてください。この仕様書通りにシステムは構築されてきますし、後で「言っていた内容と違うから直してくれ」と言ったとしても、仕様書に書かれていた通りであれば仕様変更となって追加の費用が発生します。

後から騒いだところでどうにもなりません。仕様書の確認を怠った顧客側の責任となります。厳しいように思われるかもしれませんが別に厳しくもなんでもありません。仕事なんですから仕様書を確認することは当たり前のことです。

システム開発というのは、形のないものを構築していく作業なわけですから、注意しないと仕様に対する認識違いということが発生しやすいと言えます。だからこそドキュメントに取りまとめて顧客側と開発会社側で認識齟齬が発生しないようなステップが必要となります。

普段見慣れないドキュメントですし量もそれなりですし読むのは大変かもしれませんが、大変だからといってサボらずに必ず仕様書は確認するようにしてください。やるべき仕事をさぼって確認を怠ったのにそのツケを後で開発会社側に負わせようとするのは筋が通りませんよ。

システムを利用する現場の人達の理解が必要

これは実はシステム開発に限った話ではありませんが、新しいやり方を導入するときというのは、現場の人達の理解や協力が必要不可欠となります。

新しいシステムを導入する時というのは、会社によっては抵抗勢力のような人達が出てくるようなこともあります。そうした時に一部の人達が抵抗することによってシステムが正しく使われないようになってしまうと、共有されるべき情報が共有されなかったりしてシステムが形骸化してしまいかねません。

例えば新しく顧客管理システムを導入しようとした時に、各従業員が顧客の情報を正しくシステムに登録してもらわないとどんなに素晴らしいシステムを作ったところで機能しなくなってしまいます。意地でも顧客情報をシステムに入れずに、自分の手帳で管理しようとするような人がいると厄介です。(実話)

そんなことにならないように、現場の人達にシステムを利用する会社全体としてのメリットや意義を理解してもらったり、会社そのものの仕組みを変えることによってシステムを正しく利用しないと評価が上がらないようにしたりするなど、システムが有効活用されるように工夫してもらうことは顧客側のやるべきことです。

システムはあくまでもツールであり道具ですので、どんなに素晴らしいツールであったとしてもそれが有効活用されるかどうかはそれを使う側の問題となってきます。

 

以上、システム開発を発注する時に注意するべきことをまとめてみました。システム開発のプロジェクトは簡単ではありませんが、やるべきことをきちんとやっているのであればそれほど恐れるものでもありません。ぜひ本気でシステム開発のプロジェクトををやり抜く覚悟を持っていただき、プロジェクトを成功させていただければと思います。