開発ライセンスの費用負担の決定
さて、ここで注意しておくことがあります。
ソフトウェアのライセンスには、プロダクト単位のものと個人単位のものがあります。プロダクト単位のライセンスであれば、当然開発単位での購入が必要になるため、この時点で計上しておく必要があります。
これに対して、個人単位に付与されるものは扱いが難しいです。
たとえばVisual StudioやDocker Desktopについては、もしかすると既存のシステム開発で利用していてすでにライセンスを保持しているかもしれません。その場合であってもここでは2つの理由から明記しておきます。
- 新規追加メンバーはライセンスを保持していない可能性がある
- 既存システムの開発が先に終了した場合、ライセンスの延長が困難になる可能性がある
前者は分かりやすいのですが、後者はとくに注意が必要です。まずそもそも、そのライセンスはどのような目的で、どこから予算が出ているのでしょうか？
自社の経費からでているなら問題ありません。他社の請負開発の費用として、顧客に目的を開示して費用請求していた場合、転用は問題があります。仮に転用して問題ないケースでも、あとから問題になることがあります。
たとえば初期の開発が終了し、継続開発や保守・運用フェーズに入った後、利用していたライセンスが切れたときに、継続利用が困難になることがあります。そこから慌てて保守費用に上乗せ請求しても、顧客の納得が得られるとは思えません。少なくとも私であれば採算計画を乱されたことに不満を抱くでしょう。だからと言って、自社で負担する理由もありません。困りますね。
ComponentOneやSPREADはVisual Studioと比較すると保持している可能性が低くこういったトラブルはおさえられるかもしれません。しかし逆に言うとこの時点で計上しておかないと、メリットがあることは分かっているのになかなか稟議が通らないリスクがあります。やはりこの時点で、何にいくらかかるのかは、顧客に包み隠さず開示すべきでしょう。
ではすでにライセンスを保持している場合、費用の請求はどう取り扱うべきでしょうか？ これは単一のベストと言える回答ではないでしょう。顧客との関係を考慮して決定する必要があります。とはいえ、いくつかのパターンがあるので紹介しましょう。
-
初期から計上するパターン
- 費用を明確にして顧客に請求してライセンスは2重となるがそれぞれ購入する
- 費用は開発費や保守費用一式の中に含めて顧客には開示せず、ライセンス費用分はバッファーとして扱う
-
初期は計上しないパターン
- 既存ライセンスの次回更新から案分する
- 既存ライセンスが更新できなくなってから費用を請求する
1-1は無用な出費に見えるかもしれませんが、たとえば既存ライセンスが別の顧客の費用で購入したものであった場合、対象プロジェクト以外に利用してはならないという制限は十分ありえます。明確な制限がなくても、勝手に他のプロジェクトに転用することは好ましくありません。その際にはトラブルを避けるために2重で購入することは十分に考えられます。
1-2は、既存ライセンスの転用は問題ないが、表立って開示したくないというケースです。正直、あまり私の好みではありません。まず誠実とは言えません。開発費が割高に見えて、生産性が低いと評価される可能性もあります。とくに保守フェーズでは、経年とともにコストダウンの要求が現れやすいです。そうなったときに、不明瞭な費用を説明できなくて困るケースが想定されます。
2-1は、既存ライセンスの購入元と合意できれば、だれもが幸せになれるプランだと思います。既存ライセンスの購入元からも、新規開発システム側からも信頼を得られるきっかけの1つになるかもしれません。このプランを選ぶ場合、既存システム側とは開始時に契約上合意できているとさらに良いかもしれません。また新たな顧客側には、いつから費用が発生するか、事前に伝えておく必要があるでしょう。次回からでなく、初回からは？ というと、すでに支払ってしまっている費用の問題があるので、あまり現実味がないでしょう。
2-2は、既存ライセンスが社内業務の目的で購入・維持されていて、当面維持する前提になっているような場合に適用できるかもしれません。ただ、社内業務であっても経費を下げられるなら下げるべきでしょうから、2-1を選ばず2-2を選ぶ場合は、特別な場合に限定すべきでしょう。たとえば、コスト競争が厳しい入札案件などの場合です。ただし、その場合もライセンスの流用をしてコスト削減しているため、具体的なめどをもっていつから有償となる可能性があるのかは、ただしく伝える必要があります。
これらの問題は難しい問題ですが、実際には既存ライセンスの数と、必要となるライセンス数に差があるといったことが考えられるため、もう少し複雑になると思います。ただ、上記を組み合わせて解決できるものと思います。
まとめ
今回は、プロジェクト開始前の見積時に、適切な予算を獲得するためのアーキテクチャについてお伝えしました。見積時のアーキテクチャ設計で大切なことはいくつかあります。
- 大枠となるアーキテクチャの見定め
- アーキテクチャ実現要素の抽出
- コスト影響の把握
またアーキテクチャを実現するのはあくまで人です。見積時に「誰が作ることになるのか」想定してアーキテクチャを選定する必要があるでしょう。そして、これらを適切に行うため、つぎの2つが重要です。
- ビジネスの背景
- システム化の目的
開発するシステムは、ビジネス的背景にもとづくシステム化の目的を達成する必要があります。どれだけ巧妙なアーキテクチャで作られたシステムであっても、システム化の目的が達成できなくては、価値はありません。
システムを用いて、ビジネスは何を達成しようとしているのか？ そのために必要なシステムとはどのようなシステムか？ それを見極めてアーキテクチャを設計する必要があるでしょう。
今回の場合は、ビジネスの求める変化速度に、システムが対応できるアーキテクチャを実現することがシステム化の目的でした。それに対してアーキテクチャ的には、適切なドメインの分割と疎結合によって実現します。より詳細な点については、次回以降、プロジェクトが始まった後の設計・実装編でお伝えすることになるでしょう。
ということで見積編はここまでとなります。ここまでお付き合いいただきありがとうございました。また次回お会いできるのを楽しみにしています！
