システム開発を外注した際、システムの品質が悪かったり、

計画通りに進まず納品が遅れるなど、プロジェクトが上手くいかなかった経験はありませんか？

発注側の企業でも、開発の流れを理解し事前準備をすることで、プロジェクトの進行をスムーズにし、失敗のリスクを最小限にしながら成功に導くことができます。

本来、システム開発を発注する会社と委託を請け開発する会社は、双方に協力し合いお互いプロジェクトの成功に向けて伴走するパートナーというべき関係です。

そこで、発注会社の目線で、失敗しないシステム開発委託の方法と、認識齟齬が発生させないプロジェクト進行のチェック方法についてご紹介します。

システム開発プロジェクトで起きる4つの失敗パターン

まずは、開発プロジェクトのよくある失敗パターンとその原因をご紹介します。

失敗するプロジェクトは、プロジェクトを開始する前に明確なゴールが設定されていなかったり、開発委託先に全てを丸投げしていることが原因となっているケースが見受けられます。

失敗パターン①：目的や目標が達成されない

開発を依頼する発注会社では「こんなアプリがあればユーザーが便利かも！」など、非常に抽象的な目標でシステムの開発を依頼してしまうケースがあります。

明確なゴールがないまま開発を依頼してしまうと、気づけばアプリやWebサービスの完成が目的となり、リリースした後に「ユーザーに使われない」システムになってしまうことが多々あります。

特にシステム開発の依頼経験がない会社の場合「こんなアプリが作りたい！」と、リリースされている他社のアプリ事例をもとに依頼の相談をしてしまいがちです。

自社のお客様を高い解像度で分析し、言語化した上で「どんなユーザーのどんな課題をどのぐらい解決したい」かを数値ベースで相談しましょう。

ユーザー（自社のお客様）の課題を解決する手段は、開発会社と一緒に検討し、プロトタイピングとユーザー評価をセットに要件定義していくことが重要です。

失敗パターン②：完成後に追加したい重要な機能が発生してしまう

完成したアプリやWebサービスをリリースし、ユーザーに使ってもらうと、新たな課題やニーズが見つかり、リリース後に追加したい重要な機能が発生することがあります。

これは発注会社の方で十分なユーザー理解ができていないことが原因で、開発会社にはなかなかキャッチアップできない部分です。

解決策としてはユーザーの課題やニーズを深く理解し、言語化して開発会社に伝えるとともに、ゴールに至るソリューション（機能）を複数提案してもらいましょう。

失敗パターン③：機能のユーザビリティ（使い勝手）が悪い

システムの各機能のユーザビリティについて、発注会社側はシステムが実際に動くまで動作を確認することができません。

そのため、完成したシステムを触ってみると「思っていたのと違うな」や「説明されないと使い方がわからない」などの問題が発生することがあります。

開発をスタートさせ、アプリやWebサービスのデザインが仕上がってくると、システムのイメージができるようになっていきます。

しかし、デザインの良し悪しだけで機能を評価してしまうと、後々システムが完成してから問題が発覚し手戻りおよび開発スケジュールが遅延してしまうケースもあります。

システムのユーザビリティはデザイン（色入れ）とは切り離して考えるべきで

「ユーザーは迷うことなく使えそうか？」

「機能の目的は満たせているか？」などは、

システムが構築される前段階で発注した会社でも評価していくことが重要です。

また、発注会社の担当者による評価だけでなく、ターゲットとなる実際の将来のユーザー（ペルソナ）からの評価をおこなうことで、担当者でも気付けなかった視点で課題やニーズが発覚することがあります。

システム完成までに評価する手段としては、AbodeXDなどプロトタイピングツールを使い、実際の操作感を完成前から確認する方法があります。

システムの実装前に問題点を把握することで、無駄な工程を省き、スケジュール遅延を発生させないことが可能です。

失敗パターン④：運用後にトラブルが発生したものの放置されてしまう

システムの完成時に開発会社側で十分なテストを実施し、いざアプリやWebサービスをリリースしても大きな問題が発生することがあります。

まずは、システムに不具合はつきもので、あらゆるシステムには必ず不具合があるということを前提として理解しましょう。

また、不具合の改修を折り込み、迅速に問題の解決を図るために、完成（納品）して終わりではなく、かならず開発した会社とのメンテナンス契約を結びましょう。

開発発注前に保守費用を予算として組み込んでおくことをおすすめします。

システム開発工程モデル

システム開発の失敗パターンをご紹介したところで、次は一般的なシステム開発の流れについて説明します。

開発モデルにはウォーターフォールモデル開発とアジャイルモデル開発という大きく二つのパターンがあり、どちらかに分類されます。

それぞれメリットとデメリットがありますが、開発モデルを理解しておくことで開発を依頼する時にどのように開発が進んでいくのかがイメージできると思います。

ウォーターフォールモデル開発とは

ウォーターフォールモデル開発は、

「要件定義」
「基本設計」
「詳細設計」
「システム実装」
「テスト」
「リリース」

といった開発工程の一つ一つを手戻りをせず、順番に完了させて進めていくシステム開発モデルです。

国内のシステム開発会社のほとんどで採用している開発モデルで、古くからある実績のある手法です。

ウォーターフォールモデル開発では、設計以降の工程で仕様変更をしないよう入念な要件定義をしなければなりません。

要件定義どおりにプロジェクトを進めれば、開発途中のリソースなどの管理もしやすいため、スケジュールの遅れも生じにくくなります。

したがって、適切な予定を組んで人員を割り当て計画通りにスケジュールを進めたいプロジェクトに向いています。

ウォーターフォールモデル開発のメリット

ウォーターフォールモデル開発は、上流工程（要件定義）から確実に開発工程を進めていく手法です。

そのため、要件定義を終えた段階で、開発規模の見積もりと開発スケジュールの全容を詳細に把握することができます。

開発規模とスケジュールが明確になるため進捗管理がしやすく、工程ごとにタスクが決まっているため進捗管理を適切に行っていれば、スケジュールに遅延なくシステムの完成に至ることができます。

ウォーターフォールモデル開発のデメリット

手戻りが発生すると工数が増えるウォーターフォールモデル開発では前工程に後戻りをせずに開発を進めるのが前提です。

しかし、綿密に立てられた計画でも、工程の手戻りが発生する可能性はゼロではありません。

最大のデメリットは開発に柔軟性がないという点で、要件定義後に仕様変更しない前提のため、工程の手戻りが発生すると全体的な計画に遅れが生じてしまうという性質を抱えています。

これは、開発がスタートしてからは仕様変更を行わない前提として計画されるため、途中でユーザーの意見を取り入れることが困難になります。

アジャイル開発とは

アジャイル開発は、システムの開発にかかる工程を細分化し、短いサイクルで進行していくシステム開発手法の1つです。

上記で説明したウォーターフォールモデルでのシステム開発は、最初に全体の要件定義をまとめてから企画、設計、実装、テストを経てリリースします。

開発初期からすべての機能要件をすべて洗い出して開発するのではなく、機能レベルの小さな単位で作業を進め、企画からリリースまでの工程を短いスパンで繰り返すため、柔軟な要件定義の変更が実現できます。

アジャイル開発のメリット

アジャイル開発は、設計段階で大まかな要件だけを決めてシステム開発を進めていくため、臨機応変で柔軟な対応と開発スピードの早さが大きなメリットです。

リリースを適宜実施するため、不具合があった場合も機能開発と優先度を比較しながら素早くに修正していきます。

プロジェクトの途中で多少の方針転換があっても、一部分だけの修正や機能の追加に対応しやすいのも特徴です。

アジャイル開発のデメリット

柔軟な開発ができるというメリットがある一方で、細かくテストやリリースなどを繰り返すため、作業工程自体は増加します。

要件が途中で変わってしまう可能性のある、エンドユーザーに向けたアプリやWebサービスなどではアジャイルモデルの開発工程がマッチします。

しかし、社内システムなど要件が最初から明確に決まっており、リリース後にもシステムのアップデートをあまりおこなう必要がないようなシステムの場合は、ウォーターフォールモデルの開発が適切になります。

成功するシステム開発の流れ

ウォーターフォールモデル開発とアジャイルモデルの開発をご紹介しましたが、当社ではこの二つの開発モデルをハイブリッドにご提案しています。

それぞれの開発モデルにはメリット・デメリットが存在しますが、基本的にはクライアントに柔軟かつ可能な限り低予算でスタートしていただくため、開発初期は機能を絞ったウォーターフォールモデル開発とし、ローンチ後にアジャイル開発に移行する方法で開発を進めています。

その上で、それぞれの工程で重要なポイントを列挙します。

ゴールを明確に定義する

まずは、システムの完成はゴールではなく、ユーザーの課題解決がゴールであることをクライアントと十分にすり合わせ、ソリューションを提案しています。

初期のクライアントの希望がたとえば「スマホアプリの開発」であっても、ゼロベースで技術的なソリューションを検討しますので、クライアント通りの技術アプローチにならないこともあります。

機能を絞り本質的なソリューションを企画する

ユーザーの課題解決をゴールに設定しても、すでにリリースされているアプリやWebサービスを参考に要件を定義してしまうと、多くの機能を実装したくなります。

本質的に必要な機能以外を実装してしまうと、開発予算が多額となり開発期間が長くなってしまうため、機能に優先度を設定し、実装する機能を十分に絞って、本当に必要な機能から実装とリリースをおこないます。

プロトタイピングでユーザー評価を入念に行う

ユーザーの課題解決をゴールとするため、クライアントの担当者や開発者の視点ではなく、最終的にシステムを利用するエンドユーザーからの評価を正解と定義する必要があります。

可能な限り手戻りを減らし、小規模での開発予算の実現するため、プロトタイプによるユーザー評価を初期段階で入念におこないます。

ユーザーの声を集計・分析することで、解像度の高い課題やニーズをキャッチアップするとともに、適切なソリューション（機能）を仕様に反映していきます。

事前に効果測定を設計する

適切なソリューションを実装しても、初期段階からゴールに到達することは非常に難易度が高いため、リリース後に細かくチューニングすることで効果を最大化することを前提としています。

チューニングのために必要な分析アプローチとして、システムの効果測定はリリース前に設計することが重要です。

システムのローンチと同時に、アクセス（ユーザーアクション）解析ツールをシステムに実装しておき、リリース後のユーザーの操作を数値化し、ロジカルに改善提案を行なっています。

継続的なPDCAを前提とする

システムローンチ後には、システムの効果の最大化を図るため、分析したデータを元にシステムをアップデートします。

本質的に必要な機能に絞ったものに対してユーザビリティの最適化を図るとともに、新たに見つかったユーザーのニーズを満たすための追加機能を提案しながら、プロジェクトのゴールを目指します。

おわりに

システム開発は会社経営にとって大きな投資の一つです。

せっかく開発したシステムが無駄にならないよう、明確なゴール設定と計画をもってシステムが完成するように開発を委託する発注会社側も事前の知識を得ておくことが重要になります。

クランチタイマーでは、クライアントから依頼をいただくスマホアプリ開発やWebサービス開発実績の他にも、自社向けのアプリや社内システムの開発もおこなっているので、開発を依頼するクライアントサイドの視点を持った開発工程をご提案することが可能です。

初期のプランニングでお悩みをお持ちの場合は、是非クランチタイマーへご相談ください。

システム開発について無料で相談する