【DXで失敗しないための開発手法】3,500万円かけたダメなサービス開発からの学び

株式会社みんなシステムズ代表の野田です。

この記事を読んでいるあなたは、発注者として自身の企業での問題点・課題点の解決・業務効率化や、サービスの提供など様々なことを理由にシステムの開発をシステム開発会社へと依頼を検討しているのではないかと思います。

今回は私の過去の大失敗してしまった実際の失敗事例をご紹介しつつ、失敗から学んだことを現在の開発の際に改善を心掛けたことによってスムーズに開発を進めていけるようになりました。

なので、過去の大失敗をしてしまった開発事例からの学びや教訓を得て、現在の開発現場でのより良い開発を行えるように改善を行なった内容などをご紹介させていただきます。

弊社で、どのようなサービス開発が行われているのかなどご興味がある方は記事を読んでいただくことで弊社でのサービス開発がどのような内容なのかもご紹介できればと思います！

3500万円のプロジェクトが大失敗！！会社は倒産の危機

この失敗事例は、創業当初の弊社で実際に起きたサービス開発での話です。

弊社の創業時は手紙サービスを開発、運用しておりまして、その時の私の開発時の失敗談をもとに現在の弊社のサービスにどのような成長に繋げていったのかをお話しさせていただきます。

これから、サービス開発を依頼を検討している企業の担当者様や代表の方など弊社の失敗から、どんなサービス開発を行なっているのかご興味がある方にどのようなサービス開発を行なっているのかをお伝え出来たらと思います。

タイトルの通り、この手紙サービスの開発、運用にかかった金額は総額3500万円。サービスが伸びず、会社は倒産の危機になりました。

この手痛い失敗が実は今のシステム開発事業を作りました。失敗を経験したからこそ、成功するシステム開発の正しいやり方を身につけました。

サービス開発での失敗をしてしまった4つの要因

主に以下の４つのことが失敗要因として、挙げられます。

• 見た目の綺麗さを優先したこと
• 普段あまり使用をしない最新の技術を使ったこと
• 社外の専門家にサーバー管理を委託してしまったこと
• リリースに全エネルギーを注いだこと

１つずつ、どういった失敗だったのかという詳細を解説します。

1.見た目の綺麗さを優先したこと

【よかった点】

デザインを実際に、女性の方に確認していただきデザイン性が高いと評価をしていただけました。

【悪かった点】

デザインへのこだわりが強くなりすぎて、実際のサービスをユーザーが使用する際の操作性が使いずらいデザインになってしまいました。
また、デザインの細かな調整などに想定していた作業時間より大幅に時間が掛かり過ぎてしまいました。

2.最新の技術を使ったこと

※フロントエンド言語：
フロントエンドとは、ウェブサイトやアプリを使う時に、私たちが直接見たり操作したりする画面の部分のことを指します。例えば、ウェブサイトで写真やテキストがどう見えるか、ボタンをクリックした時に何が起こるか、というのがフロントエンドの仕事です。

【よかった点】

サービス画面を表示するまでのスピードが早く表示できるようになりました。
また、最新技術での実装経験を積むことができました。

【悪かった点】

仕様変更が早すぎて、途中から社内のエンジニアでReactで実装できる人が限られてしまいました。
結果として、修正が増えていることにより実装ができる人が限られるため対応することに大幅な時間がかかるようになってしまいました。

※仕様とは
開発するサービスが持つ中身の構成や発揮できる性能などのことです。

3.専門家にサーバー管理を丸投げしたこと

サーバーの設定やきちんとサーバーが運用できるようにサーバーの管理や保守を専門の業者に依頼をしました。

【よかった点】

社内のエンジニアがサービスを開発するための作業に集中することが出来ました。

【悪かった点】

サービスに見合わないサーバーを運用するための費用（コスト）が高額になってしまいました（月額約10万円）。

また、サーバー上での設定を専門家に依頼してしまったことにより複雑な設定でサーバーが作られてしまい、何かサービスに問題が起きた際に修正の対応が専門の業者の方以外行えなかったので対応に時間が掛かってしまいました。

サーバー自体に不具合などが起きた時に、社内のエンジニアで対応が難しかったことも懸念点として上がりました。

4.リリースに向かって社内のメンバーで全力でプロジェクトを進めたこと

※リリースとは
お仕事の成果（主に出来上がったシステムやサービス）をお客さまに納品するのが「リリース」です。
リリースしたらお客さまが動作確認などを行い、問題がなければ完了となります。

※デモ、ベータ、正式での３つのリリースについて
デモ版：実際の実装した機能を確認する段階の実装内容を確認するためのサービスの納品のこと。
ベータ版リリース：正規版の前にバグの検証などで使ってもらうもので基本的に機能の制約はない。
但し、バグがある可能性があるのであくまでも検証版でのサービスの納品のこと。
正式リリース：実際にサービスを色々な人に実際に使ってもらう段階のサービスの納品のこと。

【よかった点】

各リリース（サービスの納品）の場面ごとでプロジェクトでのやることが明確になり、実装をする際のスケジュールが立てやすくサービス開発を進めやすいというメリットがありました。

【悪かった点】

リリース後は、実際にサービスが正常に動くかの動作確認を必ずクライアント様が実施をします。
その際に、正しくサービスが動かなかったりした際の問題箇所の修正期間を設けていなかったというミスをしました。

リリース後に実際にサービスの利用者から、サービスの操作性や使い勝手・使用感等のアドバイスをいただいたり、使いづらい部分がある時に、スピーディーに修正対応がスケジュールに含めていなかったので対応する時間がうまく取れませんでした。

私たちは、サービス開発に相当な期間とお金をかけサービス開発を行なっていました。

しかし、途中から作ったサービスを改修するのに非常に手間がかかりました。

失敗から学んだみんなシステムズの開発手法

この失敗のあと、私は2年ほど大手システム会社でエンジニアとして仕事をいただき、働いていました。
そこではアジャイル開発を中心にサービス開発が進められ、最新の技術を使いながら、いかにお客様が抱えている課題を解決するサービスを作るか、また価値のあるサービスを提供できるかという視点が徹底されていました。

自身の失敗の経験と、その会社で学んだことを活かして始めたのが、現在の弊社のシステム開発事業です。
『お客様の課題を解決するサービスを二人三脚で一緒に開発をする』を売りに4年で60以上のシステム開発を行っています。

※アジャイル開発とは
システムやソフトウェア開発におけるプロジェクト開発手法の1つで、大きな単位でシステムを区切ることなく、小単位で実装とテストを繰り返して開発を進めていく手法のことです。

自分の大失敗をもとに、もっとより良いサービス開発を行えるように試行錯誤を経て、現在の弊社の開発事業で日々お客様の課題や目標に向かってサービス開発を行なっています！

また、その失敗を元に安全にサービス開発が行えるように開発標準という社内基準も整備して、お客様が安心してサービス開発を行なっていけるような環境を日々作り上げています。