先の記事では見積もりの見方をご紹介しましたが、記事の最後に書いた通り、システム開発では『見積もり以上に大事な点』というのが多々あります。
むしろ、『プロジェクトを開始する前のすり合わせ』こそが、成否を分けるといっても過言ではありません。
今回の記事では、実際に開発を進める前、それも発注の前に確認しておくべき点をご紹介します。
請負契約or準委任契約？
システム開発を発注する際、『請負契約』と『準委任契約』があるのですが、そもそもこの２つの違いについてご存知でしょうか。
『請負契約』は、依頼した成果物を納品することで、業務を完遂したとみなす契約です。
受注側は『成果物の完成』に対して責任を負います。
例え予定より大幅に工数がかかったとしても、成果物を納品しない限り契約の完遂とはみなされません。
逆に数時間で開発が終わってしまったとしても、成果物さえ納品できれば指定の報酬を支払う形となります。もしそこから『追加でこれもお願いします』と依頼した場合は、別途発注を行う形になるのです。
一方『準委任契約』は、労働時間に対して成果を支払う契約です。
こちらの場合、『成果物の完成』に対して受注者は責任を負いません。
なので、例え成果物が出来上がらなかったとしても、発注者は報酬を支払う必要があります。
※ちなみに、なぜ『準』が付いているかというと、『委任契約』は法律に関わる士業関係の仕事にのみ用いることができる単語だからです。
受注側が優位に思えるかもしれませんが、『準委任契約』の場合は、時間が許す限り製品の改善や、追加の指示等を出すことが可能です。
柔軟な対応を求めることができるので、仕様を決めきるのが難しい開発等では『準委任契約』を用いたほうが無難でしょう。
成果物に何を定義するか？（請負契約のみ）
先程述べた通り、請負契約では『成果物の納品』を持って全ての契約が完遂されるため、『成果物』の定義を厳密に決めておく必要があります。
例えば『アプリの開発』を発注した際、アプリはスマホアプリでしょうか、WEBアプリでしょうか？
iOS、androidどちらに対応するのでしょうか、各OSのバージョンはどこまで対応しますか？
実際アプリが完成した後、『App Store』や『Google Play』への登録は『成果物』に含まれているでしょうか？
こういった『成果物の定義』は、細かく決めて置かなければ事故の元です。
『当然やってくれるものと思っていた』と言っても、相手はそう思っていないかもしれません。
事故をなくすためにも、この点はしっかりとすり合わせを行いましょう。
なお、先程述べた通り『準委任契約』には成果物という定義がありません。
なのでどのような作業を行うかは、発注者であるあなたが手綱を握る必要があります。
システム開発の担当者は誰になるのか？開発メンバーの体制
前回の記事でも少し触れましたが、営業の担当者がそのままプロジェクトマネージャーになることはほとんどありません。
小規模な開発会社ならば同じ人物が行うこともありますが、中規模以上の会社ならば別の担当者がつくケースがほとんどです。
（理由は、求められるスキルが違いすぎるからです。もし営業もPMも十分にこなせる人材がいたならば、その人はスーパーマンです）
なので、実際に開発がスタートした場合、どのような人が担当者になるのか、しっかりと確認しましょう。
（担当者の見極め方については、いずれ別記事で詳しく解説します！）
メンバーは社員か？パートナー？外部委託？
また、リーダーだけではなく、メンバーについても確認が必要です。
……現在、IT関連事業は大幅な人手不足です。
2022年のデータでは12.09倍の求人倍率という驚愕の数字が出ています。
何が言いたいかと言えば、発注側は『当然、開発メンバーは正社員』だと思っているかもしれませんが、
実際には『開発メンバーはほとんどが別会社からの派遣』『フリーランスに委託』『オフショア開発』更には『外部の会社に委託していた』ということもありえるのです。
最もまずいのは『知らないうちに外部に委託していた』ケースです。
この場合、『システムの目的が全く伝わっていなかった』『質問してもなかなか回答が帰ってこない』『不具合の解決が異常に遅い』といった悲劇がよく起こります。
もちろん、開発メンバーが正社員じゃなかったからといって、プロジェクトが失敗すると決まったわけではありませんが、長期的な開発でメンバーがコロコロ変わってしまったり、納期がずれた途端に人手が足らなくなる、といった事態も起こりえます。
営業担当者・プロジェクトマネージャーだけでなく、開発メンバーについてもしっかりと確認を取りましょう。
使用する言語は？ミドルウェアやパッケージは何を使うか？何で動くのか？
この質問は、非エンジニアの方には「聞いてもわからない」質問かもしれませんが、だからこそ聞く価値のある質問です。
特に『相見積もりを取ったら違う仕様で提案された』場合に効果を発揮します。
例えば使用する言語についてですが、
『なぜその言語を使うのか、他社で提案された言語に比べてどういった利点があるのか』と質問してみましょう。
この質問に対して『わかりやすく利点を説明してくれた』ならば、その会社はあなたのやりたいことを正確に理解し、その上で適切な提案を行ってくれているのでしょう。
一方で、答えをはぐらかすようならば、その言語にしか自信がないのかもしれません。
もちろん、営業担当者に聞いても即答できるほど詳しくないかもしれませんが、持ち帰ってもらった後にどのようなレスポンスが来るのかで、その会社の対応力を測る事ができます。
この質問は、ミドルウェア・パッケージ・動作環境等でも可能です。
なお、『ミドルウェア・パッケージ』、特にオープンソースのものを使う場合には、『それらにバグ・不具合が見つかった場合』の対応についても確認しておきましょう。
オープンソースのものを使った場合は、制作コストを安く抑えることができますが、バグ・不具合は利用者それぞれで解決を行う必要があります。
そこをカバーしてもらえるのか、カバーするだけの知識・技術はあるのか、といった点も確認しておく必要があります。
使用するサーバー(orクラウド)はどこか？
これも先方の対応力を測ることができる質問ですが、『単純に重要度が高い質問』でもあります。
利用する側としてはあまり気にしない箇所かもしれませんが、サーバはそこで動くシステムのパフォーマンスを左右する、重要な要素です。
したがってシステム開発を発注する前に、以下の点を確認してみてください。
- サーバはどこを利用するのか。（クラウドか、物理サーバか、レンタルサーバか）
- おおよそどのぐらいの同接に耐えられるのか
- セキュリティ、バックアップはどうなっているか
- 契約は受注側が行うのか、発注側が行うのか（多くの場合受注側企業が直接契約しますが、WEBサイト等では発注側が行うこともあります）
- サーバをランクアップ、ランクダウンさせることはできるか。その場合どういった影響があるか
- 将来的にサーバが追いつかないほど利用者が増えた場合、拡張することはできるか。その場合のコストはどのぐらいか。
サーバー・ミドルウェア等の利用料金
また、重要な点としてサーバやミドルウェア等、『システム会社以外に支払う料金』についても説明してもらいましょう。
特にこれらのものは『利用状況によって自動でスケール・プラン変更が行われる』ものもあります。
「気づいたらすごい料金の請求書が届いていた」という事態にならないよう、各プランの詳細、範囲についてもしっかりと把握しておきましょう。
更に、発注側がそれらサービスの契約を直接行う場合、各サービスの連絡が、発注側企業に届く形となります。
【メンテナンスのお知らせ】【利用契約の更新】【仕様変更のお知らせ】等、届くメールを無視したばっかりに、
『いつの間にかサービスが止まっていた』という事態も起こりえます。
使うサービスの概要・対応等について、システム会社に任せるのではなく、しっかりと把握しておいてください。
『瑕疵担保責任』と保守契約の費用・内容
システムは完成したら終わりではなく、動き出してからが本番です。
基本、リリース前にテストを行いますが、……残念ながらリリース後に見つかるバグ・不具合も少なくありません。
そのような不具合は、『瑕疵担保責任』によって改善を求めることができます。
『瑕疵担保責任』は開発されたシステムに欠陥や不具合があった場合、開発者がその問題を修正する義務を負う責任です。
また、その義務を負う期間のことを『瑕疵担保期間』といいます。
この『瑕疵担保期間』は無限にあるわけではありません。
……法律では「不具合を知った日から１年間」に通知をすれば、対応する義務が生じることになっていますが、これは受注側からすれば結構辛い条件になってしまうので、多くの場合は契約書で別途『瑕疵担保期間』について取り決めが設けられています。（納品後１年間という取り決めが多いです）
リリース後に揉めないためにも、この箇所はしっかり合意を行いましょう。
（なお準委任契約には、成果物の概念がないため瑕疵担保責任もありません）
また、システムに瑕疵がなくとも、サーバ・OS・ブラウザ等の仕様変更により、エラーを起こすことがあります。更に、使い方を誤った場合・使い方がわからない場合等、開発側の手を借りなければいけないケースもあるでしょう。
そういったときの対応を行ってもらうため、多くの場合、システム開発を依頼した会社に、そのまま保守を行ってもらいます。
ただし、保守契約を結んでいるからと言って、無尽蔵になんでも依頼できるわけではありません。
『正常な動作だけは保証します』といった契約から『ちょっとした改良・使い方の指南も行います』といった契約までそれぞれです。
どのような保守契約を結ぶのか、その対応範囲と毎月の費用について、しっかりと取り決めを結びましょう。
デザインはどうするのか？誰が担当するのか？
そして『事前の打ち合わせを忘れがちな要素』『後から揉めがちな要素』がデザインです。
『デザインはそこまでこだわらない』という方針だとしても、
単純にUIのデザインは使い勝手と直結します。
特に外部の人へ提供するようなシステムの場合は、顧客の印象や売上に影響を及ぼす部分です。
「まったく力を入れない」ことはおすすめできません。
かといって『開発段階でデザインの修正を依頼する』ことも、非常に危険です。
例えあなたがデザインセンスの持ち主だったとしても、『頭で思い描いたデザインを伝える』のは、非常に難易度の高いやり取りになります。
「ボタンの色を変えたら良くなる…と思ったが、実際に見るとちょっと微妙だ」といった事態はよくあることで、この後『ひたすら修正を繰り返す』という『お互いストレスの溜まる時間』が流れたりします。
しかも、そういった時間を延々とかけて出来上がったデザインが、『本来の狙いから逸脱したデザイン』になってしまうことも少なくありません。
そのぐらい、デザインとは難易度の高い工程だからです。
ではどうすればいいかと言えば、一番は『デザイナーを雇う』ことです。
良いデザイナーとは『格好いいデザインを作る人』ではなく、『製品の目的に沿ったデザイン』を行ってくれる人です。
そのためには、どのタイミングでどういったやり取りを行えば良いのか、デザイナーは全てを知っています。
もしデザイナーを雇う予算・規模でないのならば、最低以下の点を事前に確認しておきましょう。
- デザインを最初に確認できるのはいつか
- 誰がデザインを担当するのか、打ち合わせはいつどのように行うのか
- 修正を依頼できる回数・期間
- 使うテンプレート・UIキット
ちなみに『何度でも修正対応しますよ！』と言う会社の場合は、逆に警戒したほうが良いでしょう。
デザインの重要性・大変さを知らないのかもしれません。デザインの経験がある人ほど、いい印象は抱かないと思います。
お互いに気持ちよく仕事をするためにも、デザインのことはしっかりと事前に話し合ってください。
例え信頼できる会社であっても、確認は大切
以上、システム開発を行う前に確認しておきたい点を取り上げましたが、
これらの確認事項は、旧知の会社・信頼できると思った会社であっても、ぜひ行ってください。
多くのトラブルは『認識の違い』『すれ違い』から起こります。
あなたがこれらの点を確認することで、将来生じるかもしれないあらゆるトラブルを防止することができますし、システム会社にも『これが重要なプロジェクトであること』を印象付けることができます。
また受注側からしても、『このプロジェクトは決しておざなりにできない』と襟を正す機会になるでしょうし、
『細かい点を発注者に知ってもらえている。説明を行っている』状態で開発に入ることができるので、その後の動きやすさ、コミュニケーションの取りやすさが段違いになります。
もちろん、これらの質問に対して十全に応えられる会社ばかりではありません。むしろ、弱みとする部分が浮き彫りになるかもしれません。
しかしシステム会社はあなたの敵ではなく、これから共にシステムを作る仲間です。
なので、「この会社はどういった部分が弱いのか」「その弱い部分を補うために、どのようなアクションを取ることができるのか」といった点を知るためにも、発注前に相手のことを知る必要があるのです。
システム開発は簡単な仕事ではありませんが、発注側にできることはお金を支払うことだけではありません。
『適切な発注先を選ぶ』『発注先のことをよく知る』ならば、プロジェクト成功の確度を大きく上げることができます。
だからこそ、発注する前のコミュニケーションにはしっかりと時間を割くように致しましょう。
お問合せ＆各種リンク
- お問合せ：GoogleForm
- ホームページ：https://libproc.com
- 運営会社：TodoONada株式会社
- Twitter：https://twitter.com/Todoonada_corp
- Instagram：https://www.instagram.com/todoonada_corp/
- Youtube：https://www.youtube.com/@todoonada_corp/
- Tiktok：https://www.tiktok.com/@todoonada_corp
presented by
