はじめに
新規のお客様からOdoo導入に関するご相談をいただく際に、同じような説明を繰り返しているところがありましたので、こちらにまとめておきます。この投稿はこの先継続して編集していくつもりです。
以下、Q&A形式にて。
Odoo導入費用の見積をもらえますか？
まず、一般的な費用例の目安を知りたい、という場合にはこちらをご覧ください。
弊社のOdoo導入系サービス、Odoo運用系サービスと、それぞれの予算目安を掲載しています。
目安ではなく実際に自社で導入の際にいくらくらいになるかを知りたい、ということであれば、
通常パイロット導入サービスの中で導入費用の見積を行っています。
もしパイロット導入サービス前にどうしてもということであれば、ご要望詳細をいただけましたらそれに応じて概算金額を提示さしあげます。
ですが、私たちのOdoo導入サービスは、アジャイル的な導入手法にもとづきタイムアンドマテリアル方式で実際にかかった時間で課金する方針で提供しますので、提示さしあげる金額はあくまで拘束力をもたない概算となります。（既に要件定義が済んでおり、その内容が妥当だと見受けられる場合を除き、スコープを固定した請負契約でのサービス提供はいたしません。）
Odooの導入では、Odooの標準機能や既存のソリューションをうまく組み合わせ、そことのギャップにつき落とし所を見つけていくといった作業（要件定義）が必要です。この作業の中では「Odooだとこういうことであれば実現できるが、それだと問題があるか？」といった質問をコタエルからお客様に多数投げかけます。この作業を通じて、当初お客様が要求していたものと全く別の解に落ち着くこともよくあります。（パイロット導入サービスの中で見積もるようにしているのはそのためです。）
なぜアジャイル的な導入手法を採用しているのですか？
プロダクトの特性上、また経験上、Odooの導入にはウォーターフォール的なアプローチに対しアジャイル的なアプローチの方が適していると考えるためです。
Odooは要領さえわかっていれば、Odooコミュニティ協会（OCA）管理下のモジュールの活用含めスピーディな実装ができる場面が多々あります。そのためコタエルでは要件定義の一環でお試し的な実装を施しています。実際に操作できるたたき台がある状態からの要件定義と、そうでないものでは、効率や精度に大きな差が出ます。
ウォーターフォール的なアプローチは事前にスコープ・予算・スケジュールを固めるため、お客様側の社内承認の手続き上こちらのアプローチが要求されることもよくあります。ですが、経験上この手法では「コミュニケーションが一方的になりがち」です。お客様は要求を伝え、サービス事業者は成果物を納入するのですが、後から振り返ると「なぜそのような要求があったのか」、「なぜそのような実装となったのか」についての理解がお互いに欠落している状況が散見されます。（過去、他のサービス事業社で導入したOdoo環境の保守を引き継いだ際、例外なくこの状況になっていました。）
このため、コタエルではウォーターフォール的なアプローチそのものを否定するわけではないものの、Odoo導入に際してはアジャイル的なアプローチが適しているというスタンスをとっています。
アドオン機能の開発はできますか？
できます。Odooの機能開発に関しては私たちは高度な知見とノウハウを持っています。
ですが基本姿勢として、できる限りアドオン機能開発は避け、Odoo標準機能（または品質が担保されたOCA機能）に業務を合わせていただくようにしています。個別のカスタマイズを行うとシステムの保守性が落ち、将来のアップグレードの際にかかるコストも高くなってしまうためです。（そうなってしまっている例をいくつも見ています。）
このため、お客様のアドオン開発の要求の根拠が不明であったり、妥当でない可能性があると思われる場合は、私たちが納得するまでしつこく質問させていただきます。そうでないと、結果としてお客様に不利益が生じるためです。
アドオン機能開発した場合の著作権の帰属はどうなりますか？
プログラム等の成果物の著作権はコタエルが保持し、お客様には恒久的に成果物の使用/改変/配布を許諾する条件でサービス提供しています。（ソースコードはいつでもお客様にお渡しします。）
こちらのアレンジは、OSSの有効活用および成果物の二次利用を担保することでお客様に提供する価値を最大化するためのものです。
こちらに反しお客様にて著作権を保持するアレンジをとります場合、サービス料金を調整（通常の単価の2倍等）させていただきます。
オープンソースモジュールの利用に際しての注意点はありますか？
コタエルが活用するオープンソースのOdooモジュール（多くはOCAモジュール）のライセンスは、現状概ね8割以上がAGPLv3、残りがLGPLv3です。
特にAGPLv3のモジュールについては、次の点をご認識ください。
- ユーザが当該モジュールのソースコードにアクセスできる状態にする必要がある
- 当該モジュールに依存するモジュールには同じライセンス（AGPLv3）を適用しなければならない
それぞれのライセンスの詳細については下記のページをご参照ください。
自社または他の事業者で開発した機能の保守をしてもらえますか？
コード品質がコタエルの管理基準（原則OCAのものと同等）に適合している前提で可能です。
現状、OCAでの活動に参加していないOdooサービス事業者の作成したコードは保守性に難があることが多く、大幅な構成組み換えやコードの書き直しが必要になることがよくあります。この場合は別途料金がかかりますこと、お含みおきください。
業務提携（コタエルが開発パートナーとなる）は可能ですか？
実質難しいとお考えください。
コタエルでは原則、
- ユーザ企業と直接契約
- 準委任契約のみ（請負契約は原則不可）
- カスタマイズを行う場合の著作権はコタエルで保持
の前提でのみサービス提供しています。
営業、コンサルティング、開発等明確な役割分担をする体制は当社のアジャイル的なアプローチは相性がよくなく、当社のサービスやOdooの良さが発揮しにくいと考えるためです。
上記ふまえた上で、それでも提携することでユーザにより大きな価値が提供できるようになる枠組みが考えられる場合は、ぜひご提案ください。
IT導入補助金は利用できますか？
場合によります。
- コタエルのIT導入支援事業者としての登録が済んでいること
- コタエルのOdooサービスがITツールとして登録されていること
- お客様が補助金申請の条件をみたすこと
- IT導入補助金の事業スケジュールとお客様のOdoo導入スケジュールが合致すること
等の条件をクリアする必要があります。
IT導入補助金ウェブサイトの情報をご確認の上、気になる方はお問い合わせください。
なお、コタエルは補助金申請に関し、「ご利用いただくお客様が主体的に手続き等理解すべき（お客様でIT導入補助金のウェブサイトに掲載されている資料を読んで流れを理解いただくべき）」というスタンスでいます。
コタエルの経験の範囲内でできるアドバイスはさしあげますが、手続き面で手厚くサポートさしあげることはできませんので、予めご理解ください。
Photo by Aubrey Odom-Mabey on Unsplash
コタエルのOdoo導入サービスをご検討の際に確認いただきたいこと