IT企業では受託開発という仕事の受け方があり、今回の記事では受託開発企業での開発の流れについてご紹介します。
すべての企業で同じ方法の開発手法を用いているわけではありませんが、共通している部分も多いので参考にしてください。
しう特に転職ドラフトは人気サイトやから、他の人には内緒やで！
記事の信頼性： 受託開発企業で働いていた経験のある現役エンジニアの「しう」が受託開発の流れについて紹介しています。
受託開発 開発に入るまでの流れ【依頼側も意識すること】
エンジニアが受託開発を始めるまでの流れについてご紹介します。
案件を依頼する側としても抑えておいた方がいいポイントになるので参考にしてください。次の順番で紹介をしていきます。
- 提案依頼
- 見積もり作成・内容確認
- 予算のすり合わせ・契約
提案依頼
1つ目の受託開発の開発に入るまでの流れは「提案依頼」です！
依頼が来る場合は次のようなパターンがあります。
- 自社のホームページに新規開発依頼が来る
- お客さんの紹介で他の会社からの新規開発依頼が来る
- 受注サイトで開発の募集があり、応募をして受注をする
- コンペで提案をして採用後となり、新規案件を受注する
- 自社の営業がアプローチをして、新規案件を受注する
特に信頼のされる仕事の仕方を続けた場合、お客様の紹介で仕事の依頼が来るようになります。
筆者の「しう」の会社もお客様の紹介で今ではCMに出るような会社との取引をさせてもらっています。
システム開発会社に提案依頼をおこなう場合、お客様はあらかじめ「RFP（Request for Proposal：提案依頼書）を作成します。
開発規模の小さい場合はRFPを作成せずに依頼することもありますが、大規模なSIerやベンダー企業に仕事を依頼する場合は作成を忘れないようにしましょう。
見積もり作成・内容確認
2つ目の受託開発の開発に入るまでの流れは「見積もり作成・内容確認」です！
受託開発の案件を受注した後は、どのくらい費用がかかるのかの見積もり作成と開発内容の確認をしていきます。
（見積もりを案件の受注をする前に提示していく場合の方が多いです）
IT業界では費用の計算をする場合に人月単位という計算方法を利用する場合がほとんどです。
エンジニアによって単価が違いますが、1人月50万円の場合10人で1か月開発をしたら500万円かかる計算になります。
工数と1人当たりの費用で計算をしていきます。
予算のすり合わせ・契約
3つ目の受託開発の開発に入るまでの流れは「予算のすり合わせ・契約」です！
見積もりで提示された金額が予算を超えてしまっている場合もあります。
その場合には、開発をしない機能をどこにするのか、予算を増やして開発に取り掛かれるようにするのかを検討して、お互いに合意ができれば契約を結び開発をおこなっていきます。
最初の見積もり段階では金額の目安を表示して、実際に契約をした後により具体的な金額がわかって支払金額が確定する場合もあります。
最初の見積もり金額が多めに提示されて実際に金額が見積もり金額をかなり超えることはあまりありませんが、気をつけておくようにしましょう。
受託開発 開発に入ってからの流れ【開発側が意識すること】
受託開発での開発に入ってからの流れについて説明していきます。
調査をした結果と1年以上の受託開発企業での勤務経験を元に次の順番でご紹介します。
- 要件定義
- 外部設計（概要設計・基本設計）
- 内部設計（詳細設計）
- 実装（コーディング）
- テスト（単体テスト・結合テスト）
- リリース・納品
要件定義
受託開発での開発に入ってからの流れの1番目は「要件定義」です。
要件定義ではユーザーが出したシステム化の要望(要件)を整理して、どのような機能が開発するシステムに必要なのかを検討します。
お客様からヒアリング調査をして、どのようなシステムが必要か考える工程になります。
お客様の希望する機能を追加しすぎて使いにくいシステムができてしまったり、無理なスケジュールで炎上案件になってしまうことになります。
この工程で作成をする要件定義書は次の外部設計以降で利用することになります。
そのため、大きなミスがあると出戻りが発生して納期に間に合わなくなるので気を付けましょう。
外部設計（概要設計・基本設計）
受託開発での開発に入ってからの流れの2番目は「外部設計（概要設計・基本設計）」です。
外部設計（概要設計・基本設計）では要件定義の内容を元に操作画面や操作方法などのインターフェース、データベースの構造やどのようなデータを受け渡すかなどを決めていきます。
案件によっては、次の内部設計（詳細設計）で書くような具体的な処理の流れや画面の各項目の定義を書くこともあります。（特に大企業の案件の場合、細かく設計書を書くことが多いです）
お客様から案件を受注している場合、外部設計書に自分で書いた内容に関してなぜこのような機能が必要か・なぜこのようなデータの受け渡しがいるのかなど説明できることが大切です。
曖昧さをなくして、自分で調べてわからないことはそのままにせずリーダーやチームのメンバーに確認するようにしましょう。
内部設計（詳細設計）
受託開発での開発に入ってからの流れの3番目は「内部設計（詳細設計）」です。
内部設計（詳細設計）では「機能分割」「物理データ設計」「入出力の詳細設計」の３つのフェーズに分けて考えるのが一般的です。
機能分割では各機能の役割を分けて、各機能の説明を記載していきます。
例えば、カート機能の場合次のように分割できます。
- カートへの商品の追加
- カート一覧の表示
- カートの商品の注文
- 注文完了後のカートの商品の削除
物理データ設計では、データベースのテーブル設計やシステム内部でのデータ処理の設計をおこないます。
実際の開発現場ではテーブル設計はテーブル設計の担当チームがいて、その人達の作成したテーブルを利用してデータの流れを考える場合もあります。
入出力の詳細設計では、どのようなデータをインプット・アウトプットするのかを記載していきます。
具体的なデータ項目の桁数や入力情報を入れた時の画面の繊維やエラー時の処理が該当しています。
実装（コーディング）
受託開発での開発に入ってからの流れの4番目は「実装（コーディング）」です。
実装では内部設計（詳細設計）で記載された内容に従って、実際にコードの記載をしていきます。
大規模開発の場合、内部設計（詳細設計）で細かくコードの書き方まで記載している場合もあります。
一方で、規模がそこまで大きくない場合は、内部設計（詳細設計）ではおおまかな処理の流れが書いていて、実際のプログラミングでの実現方法は作業者に任されることになります。
個人的にはコーディングをする時に処理の方法も考える方が楽しいですね。
実装（コーディング）では、より保守・改修がしやすいようなコードを書く必要があります。
どのような書き方が保守・改修がしやすいかについては次の書籍を読むことがオススメです。
テスト（単体テスト・結合テスト）
受託開発での開発に入ってからの流れの5番目は「テスト（単体テスト・結合テスト）」です。
実装でコードを書いた後には、実際に想定通りの動きをするか確かめる必要があります。
そのためにテスト（単体テスト・結合テスト）を実施します。
単体テスト・結合テスト以外にも総合テストや受け入れテストなどもありますが、エンジニアとして働き始めた場合は単体テスト・結合テストの2つを抑えておけばいいでしょう。
リリース・納品
受託開発での開発に入ってからの流れの6番目は「リリース・納品」です。
テストを実施してエラーがなければリリース・納品をおこないます。
この時にエラーが起きる可能性もあるためかなり緊張します。もし、リリースした後に不備が見つかった場合は急いで前のバージョンに戻す必要があります。
そのための手順書も前もって作成する必要があるのですが、エラーは起こらないだろうと中途半端な手順書を作成していると被害が大きくなるため不備がない手順書を作成する必要があります。
受託開発のメリット・デメリット
受託開発のメリット・デメリットについては下記の記事で紹介しています。
両方の視点で見ることでより客観的に判断がしやすくなります。
まとめ
いかがでしたか？今回は、受託開発の流れについて次の3つの点についてご紹介しました。
- 受託開発 開発に入るまでの流れ【依頼側も意識すること】
- 受託開発 開発に入ってからの流れ【開発側が意識すること】
- 受託開発のメリット・デメリット
受託開発企業では請負契約となるため納品まで不備なくおこなう必要がありますが、その経験から得られるものも多いです。
特に初めて受託開発企業で働く人は今回紹介した開発の流れを参考にして取り組んでくださいね。
※補足
今回は受託開発の流れについて解説をしましたが、開発の規模によっては内部設計（詳細設計）で実施する内容を外部設計（概要設計・基本設計）で実施することがあるなど、案件での開発・設計書の作成方法に合わせる必要がある点に注意が必要です。
☟あわせて読みたい 「しう」のオススメブログ
コメント