業務アプリ開発 はじまりから運用までの16ステップ~ indexはこちら
アプリというと、BtoC、つまり一般ユーザが利用するゲームやSNSなどのアプリを想像するかもしれませんが、今回は、業務系アプリを開発する場合、かつ開発を外部委託する場合を前提として説明しています。
今回は、7番目のステップ「発注・契約する」です。
7.発注・契約する
契約書はもめたときに必要なくらいのもので、個人的にはあまり重要ではないかなと思っていながらも、ご覧頂いている皆さまに対して積極的に契約書は不要とおススメできるものでもないので、やっぱり紙で交わしておくべきものかと思います。
ただ、「契約書」という文言がなくても、メールなどで「100万円OKです。注文しますので進めてください。」などというやり取りでも、契約に見なされるらしいで、最低限の証拠は残すべきですね。(細かいことは法律の専門家にお任せします)
工程別に契約する
アプリ開発会社からも要望があるかもしれないのですが、工程別に契約するという方法は検討に加えておいたほうがいいでしょう。
分かりやすいのは、要件定義工程と、それ以降の工程の契約をを分けるものです。
最初から、全体として大きな金額で契約しないというリスクヘッジの意味もある一方で、要件定義期間内にアプリ開発会社の技量を知ることができるというメリットがあります。
特に初めて発注する会社だとするならば、提案や、技術が大丈夫そうだと判断しても、絶対問題ないとは言い切れません。そこで、自社の要望を説明するとともに、それに対してどのように整理し、要件のプラスアルファの提案をしてくれるかを見る事ができる要件定義工程を一つの区切りにするのは意味ある事です。
成果物を曖昧にしない
意外に曖昧なのが、成果物(=納品物)の定義です。
商品の発注であるなら、注文した商品が注文した数量に期日内に納品されれば良いため、明確です。
しかし、これがアプリの場合、アプリが納品されるという点では明確なのですが、それだけでいいのでしょうか?
ここが専門的な所になるのですが、要件定義書、画面設計書、データベース設計書、サーバ環境設計書、契約情報一覧は、必須であると考えます。
これらの成果物は、開発する過程でまとめておくべきものであるので、紙である必要もなく、書式・形式も問わないものの、アウトプットとしてあるのが当然なものです。
繰り返しますが、書式・形式は問いません。最近は、プロジェクト管理ツールを使い、そこで仕様決定などのプロセス・結果を管理していくという手法もありますので、代替物があるならそれで良いでしょう。ただし、プロジェクト管理ツールの場合、発注先との保守契約期間中であれば、過去の情報も参照できるものの、保守契約を解除した場合にどうなるかということは予め決めておくべきです。
納品日と検収期間
前述同様、商品であれば、納品されたらその場で発注数があること、ぱっと見て破損がないことなどは確認できます。しかし、アプリはそうはいきません。ぱっと見の画面が出来上がっていたとしても、プログラムに不具合があることは多々あります。
そのため、検収期間は納品日から相応の期間を取っておく必要があります。
アプリの規模にもよりますが、1~2週間が妥当な範囲かと思います。
留意すべきは、納品日から検収期間は発注者側として検収をする予定を確保しておくことです。
ありがちなのは、忙しくて検収できないことです。
しかし、契約書上、大抵は検収期間を過ぎて連絡がない場合は検収が完了したと見なすと書かれています。そうすると、不具合があったとしてもOKを出したに等しくなるのです。
納品されたアプリをテストして確認することは発注者の責務ですのでしっかりと準備をしておいてください。
瑕疵担保責任
普段の生活で見慣れない用語ですが、瑕疵担保責任の条項は、商品でいうところの1年間の無料保証期間に相当します。
ただし、大抵の電化製品は1年間だから、アプリも1年位は保証するよね。と思い込んではなりません。個別に契約するわけですから、お互いに納得すれば保証がなくてもいいでしょうし、1ヶ月間と定めることもあるのです。知る限りでは、6ヶ月か1年としている場合が多いようです。
しかしあくまでも「瑕疵」に対する保証であり、仕様変更したい、デザインを変えたいということに効力はありません。
そのためにも、前述した検収期間の中でのチェックは怠らないようにしましょう。
着手金
システム開発において、着手金を要求されただけど、どうしたものでしょう?と、知人から相談されたことがあります。
それには、ケースバイケースでと答えます。
いかなる商売であっても、受注側としては前金で頂けるなら、ありがたいことです。
レンタルサーバでも、大抵の場合、1年分前払いならディスカウントです。流石に、アプリ開発で全額前金はないでしょうし、万が一それを要求されるなら契約しない方がいいと思います。ただし、パッケージの利用料という場合は例外です。
ケースバイケースというのは、発注先が信頼におけるかどうかにて判断して頂くという点につきます。そもそも、怪しい先には発注しないと思いますので、信頼できるという前提で考えると、可能であれば応じていいかと思います。
契約に際しては、契約書を取り交わすことは手段であって、目的ではありません。リスクヘッジをしつつ約束事をしっかりと取り決めるということが目的ですので、グレーなことを無くし明確な約束になるよう取り組んで頂ければと思います。
スマホアプリを使った業務システム構築のことなら
株式会社クラボードへお気軽にご相談ください