WEB担ひよこ
 
開発を頼んだのはいいけど、これからの流れが全然イメージできないよ。。 
でもプロに任せておけばいいよね？

 クアリタくん
 
それだとキケンかも…！
開発をスムーズに進めるために知っておくべきことを説明するよ。

---

非エンジニアが開発を外注する前に理解しておきたいこと

外注したんだから難しいことはプロに任せておけば…というのは実はキケン！
簡単な用語や、開発のフローの基本知識を知っておくだけでもトラブルやリスクを防ぐことができます。

新たに担当者になった場合などは、開発に関する専門用語の多さに苦労するかもしれません。
要件定義や外部設計…など開発の工程に関わる用語についても一通り押さえておくようにしましょう。

作業の見積もりをする際に、かかる工数を「人月」や「人日」で表現するのも開発の特徴です。
開発にかかる費用はエンジニアの時間単価に人日数（人月数）を掛け算して出します。
例えば「このシステムの完成には6人月かかる」と言われた場合、ひとりのエンジニアが6ヶ月作業して完成するということを意味します。
あるいは、仮に6人のエンジニアで分担して同時に作業できる場合は、1カ月で完了できます。

月単位よりもっと細かく費用を出すケースでは、日単位の工数を表す「人日」が使われることもあるでしょう。
人月や人日の表現に慣れておけば、見積もりがしやすくなります。

---

開発の代表的な方法

開発を管理・進行する方法には、いくつかの種類があります。
ここでは、開発全体の流れを理解するうえで代表的な「ウォーターフォールモデル」と「アジャイルモデル」について説明します。

ウォーターフォール開発は、上流から下流に向けて開発を進めていくモデルです。
（上流とは要件定義や設計、下流はプログラミングやテストのこと。）
工程を分割して、一つ一つが完成してから次のステップに進むという王道のやり方です。
スケジュールや予算の見積もりが立てやすいのがメリットですが、逆に言えば、基本的に工程を逆戻りすることはないので、いざ変更や修正があった時には時間も費用もかかってしまうことに注意です。

アジャイル開発のアジャイルとは「素早い」という意味です。
その名の通り、スピーディな開発を実現するために考えられたモデルです。
ウォーターフォールモデルのように決められた工程に縛られるのではなく、1週間〜1ヶ月などの短期間の反復の中でシステムの実装とテストを行います。
修正や変更は細かいタイミングでやっていきますので、不具合発生時の手戻りを最小限に抑えられるのが利点です。
突然の仕様変更に柔軟に対応できるのも、アジャイルモデルの強みとなっています。
一方で、その柔軟さゆえに最初の方針をしっかり共有しておかないと開発がブレてしまうかもしれないということは注意しましょう。

計画管理が重要な大規模なプロジェクトはウォーターフォール、自由度が重要な新規事業などはアジャイル開発、などと状況に合わせて使い分けていくのが良いでしょう。

---

ウォーターフォールモデルの全工程

世界中で活用されているもっともオーソドックスな開発形式、ウォーターフォールモデルを例にとり開発のプロセスを説明していきます。

---

各工程の作業内容、チェックポイント

①RFP（提案依頼書）の作成
RFPとは開発の目的、予算、納期などが一目でわかる資料です。
この内容が不十分だと納品物の出来上がりに大きな影響が出るため、十分に練りあげるようにしましょう。

②基本契約書の締結
RFPを作成し、提案に適した開発会社が見つかれば契約書の締結を行います。
基本契約書がRFPに即した内容になっているかどうかを発注者側と開発側の双方で確認し、問題がなければサインしてください。

③要件定義
発注者側の要望や目的などを元に、誰のためのどんなものを開発するのか？を定義します。
ターゲットに対して、どのような機能で、どんなユーザー体験（UX）を提供したいのかを考えます。
機能面については、優先順位を含めて決定していきます。
ウォーターフォールモデルの場合、基本的には一度進んだ工程を逆戻りすることはしません。
あとから要件定義が覆らないように、このフェーズで認識合わせを念入りに行うようにしましょう。
その後、仕様策定として仕様書を作成し、要件定義した内容を満たしたワイヤーフレームができているかを確認します。

④外部設計
UI（ユーザーインターフェイス）＝ユーザーが見たり触ったりする画面について、システムやサービスの設計をより具体的に進めます。
どのように表示＆操作する画面にすれば最もユーザーが使いやすいのかを何度も検討しなければいけません。
その後、UI設計にもとづいてデザインを行います。
全体のレイアウトイメージを固めた後は、データベースの管理、サーバー環境、セキュリティなどについても考えていきます。
また、開発工程における詳細なスケジュール、コストについてのすり合わせもこのタイミングで実施します。

⑤内部設計
外部設計を元に、システム内部の動作やデータに関連することなどプログラミングしていくための設計を行います。

⑥実装（プログラミング）
内部設計をベースに、実際にシステムやアプリが動くようにプログラミングを行います。
また、併せて単体テストの仕様書も用意します。

⑦単体テスト
作成したプログラムに対して、きちんと動作するのかどうかエンジニアがテストを行います。

⑧結合テスト
単体テストが終了したプログラムのパーツを結合したとき、連携に問題がないかも確認します。

⑨総合テスト
開発したシステムやアプリに対して、総合的な動作を確認します。
ユーザーが実際に使うシチュエーションを想定した環境を用意して行います。
開発を担当した会社だけでテストを行うと、一律のテストになるリスクが発生しがちなので
多角的な視点でテストをするために、第三者検証を利用する場合もあります。

⑩運用テスト
総合テストが無事完了すれば、発注者に納品物を引き渡し、最終的な運用テストを行います。
発注者は、要件定義の内容がしっかりと反映されているかどうかをユーザー目線で確認するテストです。
動作だけでなく、画面レイアウトや操作感に問題がないかどうかも妥協せずチェックしましょう。

⑪リリース
運用テストでいくつかやりとりを行い、問題がなくなれば晴れてリリースです！
ついに本番環境でシステムの稼働を開始します。

⑫保守・運用
作業としては一段落ですが、リリースしたあとも、開発会社の仕事は終わりではありません。
開発したシステムやアプリの運用をサポートし、不具合があった場合は修正対応、契約によっては新規コンテンツの追加をしていきます。

---

油断は禁物！開発の外注でよく発生するトラブルとは

開発は、お金を払ってプロに行ってもらう仕事です。
そんなに簡単に失敗はしないだろうと思いたいところですが、トラブルの事例は後を絶たないのが現実といえます。
具体的には、予想以上に納期や開発費がかかってしまった、仕様と違うものができている、不具合がある、デザインが反映しきれていない…などがよくあるトラブルです。

開発者側とのコミュニケーションが不十分だったり、納期の見積もりがそもそも甘かったりすると、プロジェクトはデスマーチ化するリスクをはらみます。
発注者の思い描くシステムやアプリのイメージがアバウトな場合も危険です。

トラブル対策として、発注者側は作りたいものを明確にしておくことが大切です。
開発における最低限の知識を持ったり、外注先とのディスカッションを重ねることで明確になっていきます。
また、スケジュールは現実的に組み、必ず修正期間を最初から取っておくようにしましょう。

---

信頼できる外注先を探すことを妥協しない

発注者側に開発に関する知識が不足しているのであれば、実績がある開発会社に頼むのが安心でしょう。
実績が豊富な大手企業になると開発費用が高くなる可能性がありますが、その分サービスは充実している傾向にあります。

さらに良いのは、自社サービスの開発経験がある会社にお願いすることです。
一般論だけでなく、実際に自社で行った開発経験に基づく提案は説得力が違います。

ひとつの開発会社にこだわるのではなく、複数の開発業者に相談するのも重要です。
開発会社によって得意なジャンル、そうでないジャンルがあります。
見積もりが出てくるスピードや、プレゼンの内容などを参考にして、自分にあった開発会社を選ぶようにしましょう。

 WEB担ひよこ
 
発注側と開発側の協力が欠かせないんだね！
工程の流れや簡単な用語だけでも勉強しようっと

 クアリタくん
 
開発側がきちんと情報開示してくれて
コミュニケーションを取ってくれるところを選ぼうね！

※本記事は2020年4月時点の情報を元に作成しており、技術的な情報などは随時修正の可能性があります