この記事では、
- アプリ開発の全体像
- 「設計」とはなにか
- 設計が失敗した際に起きる問題
について解説いたします。
結論から述べると、アプリ開発では「設計フェーズ」が最も重要です。
また、アプリ開発はそもそも「スモールスタート」で進めることが、開発コスト最適化やアプリ品質を高める面でも非常に有効です。
この記事を読み、設計とはどういうフェーズでどういった作業を行うのかを知り、プロジェクトが失敗するケースを押さえ、なぜスモールスタートが最適なのかを理解をしましょう。
アプリ開発の基本的な流れ
一般的に、開発費用を算出するためには、開発するアプリの内容を細かく決め、開発にかかる工数を算出し、見積もりを出します。
ここでは、アプリの内容を順番に確定させてから開発に着手していく「ウォーターフォール開発」という最も一般的な開発フローを用いてアプリ開発の流れを説明いたします。
アプリ開発の流れ：ウォーターフォール開発
アプリ開発の基本的な流れは大きく分けて以下の5つのフェーズに分かれます。
- 企画フェーズ：どんなアプリを作るか考えるフェーズ
- 設計フェーズ：開発するために、技術的な調査と選定を行うフェーズ
- 開発フェーズ：開発を行うフェーズ
- リリース：世の中にアプリを公開するフェーズ
- 保守・運用フェーズ：アプリを継続的に利用する為に必要な更新作業を行うフェーズ
※「ウォーターフォール開発で学ぶアプリ開発の流れ」記事リンク
その中で、最も成功のカギを握ると言っても過言ではないのが「設計フェーズ」です。
「設計」とはなにか
設計とは、目的に沿ったシステムを構築することです。
例えば、取引記録を正確に残したいという目的がある場合では、決済システムからの自動登録のみを受け付け、あえて手動による登録を受け付けない様にするという制限をかけることがあります。
つまり、「この機能を実現するためにはこの機能を諦める必要がある」というような、ある種二者択一を行い続けて目的達成に適したシステムを構想を詰めていく作業が「設計」です。
設計時に要件が詰まっていないと発生する問題
プロジェクト終盤で追加要件が発生する
開発が進んだタイミングで追加要件が発生すると、追加要件開発分だけの少額な追加費用だけで済む場合と、追加要件がすでに開発済みの場所にも影響し、非常に高額な追加費用になる場合があります。
追加要件が本来の設計思想に反する場合、ただの＋αの部分的な改修では済まなくなります。
初期費用の他にも以下の様な事故にも繋がることが多いとされています。
期待したほどの業務効率化につながらず運用コストが高くなる
システムは完成したが社内運用のヒアリングが足りなかった結果、期待したほどの業務効率化につながらず、むしろシステムが変更になった分運用コストが上がってしまう場合があります。
保守費用が高くなる
システムで本来対応すべきでないイレギュラーな対応を許容したため、不必要な作業をエンジニアが手動で対応しなくてはならなくなり、その分システムの保守費用が本来よりも高くなってしまう場合があります。
設計時の問題が追加改修時に顕在化する
初期リリース時には問題にはならなかったが、機能追加を行う際に既存の設計と追加要件が合わず、見た目以上に改修範囲が大きくなる。
もちろん、既存の設計思想に反する要件が発生した場合この問題は起きてしまうものですが、今後の改修方針を見定めて設計し拡張性をもたせることで、最小限に抑えることができます。
ここまで挙げた問題は設計を適切に行ったとしてもすべて防げるということではありませんが、プロジェクト成功への効果が大きいことは確実です。複雑な開発をスムーズに完遂するためには設計フェーズには十分時間をかける必要があると言えます。
設計による失敗は、商慣習と人材不足が原因
ここまで説明したように、プロジェクトの失敗の大半は設計が適切に行われなかったケースです。
ではなぜ、設計が適切に行われないのか、それは「IT業界の商習慣」や「ビジネスを技術要件に変換する難しさ」が原因とされています。
IT業界の商習慣の悪さ
開発会社に依頼する場合、
- 要件を伝える
- 開発会社が見積もりを出す
- 合意すれば契約
という流れというケースが多いです。
このとき、開発会社側は見積もりのために設計を行う必要がありますが、成約するかもわからない見積もりのための設計に多くの時間を割くことができません。
そして競合との価格競争の結果、設計をほとんど行わずに開発をスタートさせる企業が増えました。
しかし、本来設計は実際の業務フロー等を踏まえた上で行います。
似たようなシステムであっても設計書・仕様書を流用することはできず、システムごとに特注する必要があるため、まとまった人件費がかかる作業です。
こういった問題から、最近では設計に十分な時間を割くために、「要件定義」といった名称で見積もり時の設計を有料にするケースが増えてきています。
ビジネスを技術要件に変換する難しさ
ビジネスの目的に沿った設計をするには、ビジネスサイドの要望/要件を踏まえた上で技術の話を進められる力が必要です。
また、設計フェーズは開発内容を定義するだけでなく、開発内容について顧客と合意を取るフェーズでもあります。
技術的に開発/設計することができるエンジニアは少なくありません。
しかし、ビジネスや業務の観点から取捨選択を行って設計ができる・顧客と折衝できる人材は、業界に少なく市場価値が高いため、各企業取り合いになっているのが現状です。
設計の課題を最小抑えるための「スモールスタート」
ここまで解説したように、プロジェクトの要は「設計」です。そして、その「設計」はIT業界自体の課題と直結しています。
では、どのようにすれば設計を起因とする失敗を最小に抑えられるのかというと、設計に十分な時間を割くことはもちろんですが、プロジェクトの「スモールスタート」が効果的です。
最小限必要な機能だけを設計・開発・リリースし、ビジネス的な課題やアプリの価値の認識を深めながら設計〜リリースまでのフェーズを繰り返すことで、取り返しのつかない大きな失敗を避けることができます。
スモールスタートを行っていくための開発会社の選び方についてはこちらの記事で詳しく解説しています、ぜひご覧ください。
リンク：『アプリ会社の選び方｜スモールスタートの重要性』
