受託開発で開発開始時に確認すること

受託開発で開発開始時に確認すること

Clock Icon2013.05.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

巷では受託開発についてまぁ様々な事は言われて久しいですが、紛れもなく自分は今この世界で生きていますし、多くの人が関わっていると思います。自分はプロジェクトリーダーという役割で開発に携わっていますが、プロジェクトをやる度に何かしら忘れてしまう事があるので、開発開始時又は開発開始前に必要な主な確認事項をまとめました。

確認すること

プロジェクトの基本部分

契約書/要件定義書に書かれているようなこと。設計時や問題発生時に考える時の基礎になる部分なので、プロジェクトに関わる人全てが知っていて意識するべきこと。
☆は仕様追加などの状況によってパラメータ調整する項目

目的
何故このプロジェクトが始まって何を目標としているのか
世界のはじまり。考察の基準。
エンドユーザー
お客様と本当の意味でのエンドユーザー。
誰が使って嬉しいといいのか
ステークホルダー
プロジェクトのボスは誰か
誰を納得させればいいのか
契約形態
準委任、請負
作業に対する対価なのか、出来たモノに対する対価なのか
契約期間
いつからいつまでか
☆時間
契約金額
どれだけお金が使えるのか
☆予算
何をするのか
要件定義からなのか、設計からなのか
どの機能をどこまで作るのか
☆スコープ
どの程度の品質が必要なのか
サービスや製品としてリリースするのか、プロトタイプなのか
☆品質
なかなか意識して話題に出てこないところ
納品物はなにか
ソース、設計書、テスト仕様書、導入手順書など

コミュニケーションなど

情報共有方法
情報共有ツール、メーリングリスト、電話等
大きなファイルの受け渡しをどうするか(主にメールの場合)
打ち合わせ方法
定例ミーティングをするか、Skype等でも可能か
他システムの会社
例えばアプリとAPIで開発会社が違うとか、システム連携する場合など、どんな性質の会社か調べてみたりします

請負契約時の納品物の品々について

粒度やフォーマット等、求められるものがプロジェクトの後半で発覚した場合、工数に見合わなくなる事もあります。契約時にある程度は取り決められるとは思いますが、特に初めてお付き合いするお客様の場合、なかなか納得させられる粒度/内容までは確認出来ないと思います。その中でもプロジェクトのできるだけ初期にドキュメント類、テスト仕様書類をある程度サンプルとして書いて合意を獲る事が精神安定、工数、もろもろ含めて大事です。また、ドキュメントレビューやテストケースのレビューもを行うのであればそれも加味して計画を立てられます。
テストについても、どんな観点でどのフェーズ(結合テストなど)のテストを行うのか、またどのフェーズ(総合テストなど)までのテストを行うのか、確認する必要があります。

まとめ

なんだかんだ言っても、この辺りをしっかり締めないと、ゴッドハンドなエンジニアが居てもうまくいかず、お客様も含めてプロジェクトに関わった人たちが満足する結果につながりません。
何でもそうですが、始めが肝心です。要件や仕様をできるだけ早い段階で理解し、自分たちがやりやすい形に持ってくのが自分の為にも他のメンバーの為にも、とっても大事です(ハイ)。そして制作物以外のドキュメント類やテストに関しても早い段階でステークホルダーと合意を取って進めて、無理のないプロジェクトプランでNO炎上みんなハッピーで打ち上げましょうZ!

でわでわ

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.