ＩＴ開発プロジェクトで契約に影響するよくある問題
プロジェクト全般での問題
プロジェクトを進めていく中で、必ずと言っていいほど発生するのは、範囲の変更や期限に間に合わないことです。
範囲が変わったり、期限が変わったりすると当然契約に影響します。
よくある原因は以下のとおりです。
- プロジェクトはフェーズが進むに従って未確定要素が見えてくるため、後のフェーズが最初の想定と違ってくる。
- ユーザ側の作業・意思決定がフェーズ全般に影響する。
- 実行中にユーザ都合の変更が頻繁に発生する。
要件定義と基本設計での問題
要件定義と基本設計で共通なのは、要件や仕様を決めるにあたって、ユーザとベンダで決めていくことです。
そして、要件・仕様の決定があいまいとなりがちなため、後から言った言わないという責任の押し付け合いの問題となることが多いです。
また、成果物を作成していく作業だけでなく、推進していくマネジメントスキルがないと問題がどんどん先送りとなってしまいます。
これらの問題は、ユーザ・ベンダーどちらの原因でも作業遅延は起こり得ます。
作業遅延、作業規模の増加は契約に影響していきますので、しっかりとマネジメントしていくことが必要です。
基本設計での問題
基本設計は、本来要件定義が決まていれば、それに従い設計を進めていくエンジニアワークのはずです。
しかし、実際には未確定要素が多いということで、ベンダーは準委任にしたがります。
要件定義の不十分により、設計の漏れや作業遅れがが発生することはよくあります。
基本設計の不備は、後フェーズへ影響を及ぼし、後から漏れが発覚し、手戻りとなります。
基本設計そのものの契約への影響に留まらず、後の契約にも影響を及ぼしてしまうことが多いです。
ソフトウェア開発・テストでの問題
ソフトウェアの著作権の問題
ソフトウェアは、作った人に著作権が帰属します。よって発注したものの著作権がベンダー側のものとなってしまいます。
普通は納品されたソフトウェアは、発注した自分がまた使っていくものです。よって、契約時に著作権は発注者に移転するようにしておく必要があります。
その点は、ソフトウェアの作るという役務のみを提供すると考えているベンダーであれば問題ないですが、ソフトウェアを再利用しようとしているベンダーであったら、すんなり受け付けてくれないこともあります。
場合によっては、著作権の問題で契約金額に影響することがあります。
ソフトウェア開発の再委託先に関する問題
ベンダーはすべてを自分たちで作成するとは限りません。
再委託先が入ることが多いです。 再委託先に関する取り決めは、予め考えておいた方がいいです。
準委任契約であれば再委託は、予め取り決めていないとできません。
請負契約の場合は、すべて元請の責任となります。
ただし、パフォーマンスが心配となる場合もあるでしょう。その場合は、セキュリティ面から再委託先をすべて開示するよう求めます。
結果的に元請がすべて責任を負うにしても、明らかにパフォーマンスの低いところがいたら、改善を求めるといったマネジメントを行います。
マルチベンダー発注時の問題
一部の機能のみを他ベンダーに発注したら、一方のベンダーの開発機能と全く繋がらないということが起き得ます。
マルチに発注していたら、発注者側が繋ぐ責任があります。
片方に幹事的に責任を持ってもらうことも契約上はできるので、契約時点で気を付けたほうがいいです。
ただし基本的には全体のマネジメントは自分でする覚悟は必要です。
仕様変更がいつのまにか発生している問題
ソフトウェア開発中に仕様の追加・変更がいつの間に発生してしまっているということが発生します。
これは、設計の漏れなどに気づいたが、プロジェクト責任者が知らぬうちに対応してしまっているということです。
あまり考えたくないですが、実際はよくある話です。
ユーザ起因もありますし、ベンダー起因もあり得ます。
開発規模などが変わると契約に影響しますし、最悪は破綻するケースもあります。
お互いのプロジェクトマネジメント責任を問われる部分です。
発注側のプロジェクトマネジメントも大きく問われる部分ですので、自分たちの体制をしっかりと計画するとのと同時に、発注先のプロジェクトマネジメントに対しても、しっかりと行うよう契約上謳っておくことも抑制策となります。
プロジェクト終了時の問題
プロジェクトが終了しているにも関わらず、問題は残ります。
まだできていないし、動かないという問題
本番移行を終え、本番フォローフェーズという工程を置いているのであれば、そのフェーズが永遠に続いているということが起き得ます。
あるいは、本番移行直線のテストが終わらないということもあります。
最悪の問題ですが、できていないと確実に言える場合は債務不履行になりますので、全面的に請負側が問題のはずです。
しかし、実際には、発注側起因の問題もあり得なくはないため、契約上マネジメントの取り決めをするのと同時に、実行上も問題が後から発生しないよう、注意が必要です。
プロジェクトは終了し、利用し始めたが不具合が発生した問題
後からわかった不具合は、契約不適合となります。
その場合は、修理を求めることができます。
しかし、準委任の場合は、あくまでも善管義務違反による対処という形で、対処を求めることなりますので、注意が必要です。
何が完成なのかは、書面にて確認できるようにしておくことが無難です。
稼働後の不具合によりビジネス上の損失が発生した問題
請負契約で依頼したものの不具合により、ビジネス上の損失が出たとしても、通常は請負範囲内での責務しか負わないよう、契約がなされることが多いです。
しかし、実施しているシステム開発の内容にもよりますので、場合によってはビジネス上のリスクも負ってもらうような契約にする場面もあるでしょう。
実際の紛争において、損害賠償を発注側が請求出来ているケースもあります。
プロジェクトの遅延により現行ＩＴの運用費用を余計に支払った問題
現行ITの刷新などにより、現行を運用しながらシステム開発を進めていることはよくあることです。
そして、現行ITは運用費用が発生しているため、当然システム開発が伸びると運用費用も継続してしまいます。
新ITシステムの開発を請け負っている立場からすると、現行ITの運用費用は無関係と思われます。
しかし、新ITのプロジェクトが遅延すると、現行運用費用が多く発生してしまいます。
これは看過できない金額となることもあります。
通常は請負範囲内での責任となりますが、仮に請負側が明らかに問題がある場合は、損害賠償請求範囲となり得ます。
発注側としては、新ITのプロジェクト費用と現行ITの延長費用をダブルで負担したくはないですが、最悪そういうケースも考えられます。
よって、契約上でも考慮できればしますし、実行中も遅延責任がどこにあるのかを常にマネジメントできるようにしておきたいです。
パッケージソフト導入プロジェクトでのよくある問題
パッケージ候補選びに支援を頼む場合に起こりうる問題
機能は良さそうだが使っていくうえで制約があったり費用が高かったりする
コストの範囲や、使い勝手について経営や現場が関与し、進めていけるように予め取り決めたいところです。
パッケージを選んでいる段階で細かい要件を進めてしまう
これは実務上発生しがちな事象ですが、後々必要であるため検討したくなってしまいますが、支援者に適切なファシリテートや進捗管理をお願いしたいところです。
パッケージ導入後を想定した業務が描けていない
発注側を含む進め方の問題ですが、導入後が描けていないままに、パッケージの機能比較のみ行うのは本末転倒となってしまいます。
よって、目的に立ち返り、やるべきこととの対比を行うよう、マネジメントします。
適当なパッケージがない
結果適当な製品がない場合がなくはないです。
パッケージ選びを頼んだのに、結果なしでは発注損となります。代替手段を提案してもらえるようにしておきたいです。
導入する直前で内部より反対にあう
いざ選んで導入しようとしたときに、反対にあってしまうと振り出しに戻ります。
進め方の問題ですが、内部関係者に途中段階で意見を収集し合意できるよう、進め方を定義します。
選んだ後から選んだ段階での不備が見つかる
通常準委任契約で選定支援を依頼します。
その活動において、製品選定したものの、後から選定のおける考慮漏れが発生することがあります。
その場合、選定での工程に瑕疵があったということなるでしょうか。
あくまでも善管注意義務違反ということになりますが、後から起きたことに対しては曖昧になりがちですので、契約時点で十分留意するよう、つまり最大の専門性を持って対処するよう謳っておきたいです。
パッケージ選定を含む要件定義時の問題
導入やカスタマイズに気を取られ、移行の負担が想定外に大きくなった
パッケージはデータが投入されて初めて使えるものとなります。
よって移行が重要であるに関わらず、移行が軽視されてしまうこともあります。
データ移行は既存ITとフォーマットが異なるため、通常困難な作業となります。
また、パッケージベンダーは既存ITまで責任を取りません。
よって何も考えないと、移行は自分でやることになります。しかし、ほとんどうまくはいきません。
移行の役割分担は留意して決めておく必要があります。
後から要件追加が次々と出てきてしまう
後から要件追加が出てくるということは、要件定義が不十分であった可能性が高いです。
発注者と受注者双方の問題であることが多いものの、受注者側に要件定義時に、最大限の専門性を発揮してもらうように謳っておきたいです。
検討を進めたら壁にぶつかり、要件定義確定が何度もループしてしまう
検討を進めると、より検討を進めないといけない部分がでてきます。要件定義としてはすべて決めないといけないのではありますが、設計にすすでいるケースもあります。
進め方に問題があり、要件定義がいつまで経っても確定できない問題となります。
進捗管理方法は事前に合意して実行すべきです。
最終的にコストで選んだら、プロジェクトの推進や保守ができなかった
選定にはコストでの評価は当然あるのですが、それだけでは後から問題が出てきます。
要求を充足していることが一番ですが、コストに加えて、発注先の推進能力にも着目して選定しましょう。
また、保守面についても、予め知っておく必要があります。
保守運用に関して、発注先は何もできず、いつのまにか自分たちがやるしかない状態になっている可能性があります。
パッケージ移行時の問題
旧ITシステムから抽出したはいいが、新ITシステム用にデータ変換できなかった
旧ITから新ITへのデータ移行については、データの範囲・抽出・加工・移行という詳細場面にて、責任が発生します。
よって、詳細に役割範囲を決めておく必要があります。
新ITシステムへデータ投入を依頼したが、想定外のコストとなってしまった
データ投入は移行するケースと過渡期にデータ投入するといった様々なケースがあります。
旧ITは大抵新ITとは異なるものですので、投入するデータは同じ件数ですらないこともあります。
件数、加工度合、投入後の確認、投入後の整合性検証等を含めると、想像以上のコストになることが多いです。
最後に移行する段階になって判明することも多いので、契約時点で決められるとよりよいです。
既設ネットワークに追加したら、既存システムに動作不具合が発生してしまった
既存ネットワークはパッケージ導入時のベンダーは我知らずの態度をとることが多いでしょう。
しかし、実際に導入したITが他のITに影響を及ぼすことはあります。
その場合に損害賠償できるケースもありますので、契約に盛り込むことも手段です。
アジャイル開発でのよくある問題
アジャイルとは
アジャイルの対義であるのは、一連の開発を行うウォーターフォールです。
アジャイルは、比較的短い一定間隔で開発・テストを繰り返し、スプリントと呼ばれるタイミングで実際リリースします。
その後の運用フェーズにおいても、スプリントを繰り返します。
初期段階ですべての仕様を決めるには要求が漠然としすぎていたり、実際にリリースしてからフィードバックを受けるほうが効果的と思わる案件について適用されます。
また、既に大規模であるITの再構築のようなものは合わず、これからスタートするプロダクト開発のほうが合っています。
通常は発注側もオーナーとしてプロジェクトに入り込んで、開発ベンダーとともにチームとして進めていきます。
状況に応じて要求の変化が激しいのも特徴です。
アジャイル開発で契約に影響する問題
後からこんなに計画が変わっていてもいいのか？とならないように
アジャイルという変化を受け入れる開発方式を採用したことを、そもそも合意しておく必要があります。
とりあえず作って、後からきれいにするというのはありなのか
アジャイルでは開発・テスト後にリリースし、その時点での要求を見たしつつ、今後のために内部の作りをきれいにするというリファクタリングが行われることがあります。
もともときれいに作ってくださいよ、と言いたいところですが、アジャイルの特性上このような段取りになることは一定規模は避けられません。
ただし、どの程度実施するかを予め決められるのであれば、決めたほうがいいです。
最初の計画から変化しているが、どう変化させるのかが決められない
スプリットと呼ばれる開発期間を繰り返していくことになりますが、すべて先まで計画が固まっているわけではありません。
しかし、次の期間を始めるにあたっては、やることが決まっていないと、待ちになってしまいます。その場合、費用をどうするかという問題となります。
この点は通常期間契約等にて契約上規定されますが、発注側は変化についていくことも大事ですし、受注者に専門家として最大限リードしてもらうことも取り決めておきたいです。
実行者が変わって開発が進まなくなってしまった
アジャイルの特性上、チーム体制を組み、開発者は伴走的に発注者に付き添って、実行していきます。
したがって、属人的な部分も出てきてしまいます。
もし、実行者がいなくなったらたちまちプロジェクトが成り立たなくなることがあります。
実際にその場面に出くわしたことはありますが、受注者は何とかしようと取り繕いますが、実態はかなりリカバリが厳しい状況となりました。
一旦交代してしまうとかなり厳しい状況となりますので、契約時点でメンバ交代に関しては十分引き継がれることを申し入れておきたいです。
変化を前提としているからといって変更しすぎは問題となる
変化に対応しやすいことを目指した契約ではあるものの、変化と変更は似ているが、少し違います。
変更は一旦取り決めたことに対する変更になります。
すなわち変更はきちんと取り決め、合意されていないといけません。
変更を発するのは発注者と思われがちですが、受注者のスキルの低さやセンスのなさからも発生します。
発注者としては善管義務を盾にするしかありませんが、変更の要因を明確にして、変更管理を行うことを、取り決めておくのと同時に、実行中もマネジメントしていきたいところです。
とりあえず動くように作っておいたということを避けるために
アジャイルだからといって、とりあえず動けばいいということをされては困ります。
その後の保守のためにはドキュメントが整備されている必要がある場合は、その旨契約しておくほうがよいでしょう。
契約・交渉・合意のマネジメント
契約・交渉・合意のスケジュールマネジメント
見積内容を確認し、契約を締結するにあたっては、提示されてからすぐにそのまま契約してしまえばいいわけではありません。
やはり、見積内容だけではなく、契約内容についてもよく確認しなければなりません。
そのため、予め契約内容を合意するまでのスケジュールを適切に押さえないといけません。
通常は、契約条件確認、法務審査、契約条件の調整、合意、承認といったプロセスを経ることになります。
従い、規模にもよりますが大きな規模になれば1ケ月くらいはすぐに経ってしまいます。
その間、的確に進んでいるかをマネジメントしていきます。
交渉のマネジメント
契約条件によっては、どちらかに有利・不利というものがあります。
よって、すんなりと合意とならないケースがあります。
交渉にあたっては、交渉項目ごとに発注者と受注者のどちらが何か調整しているかを、マネジメントし、漏れなく期限までに完成できるようにしていきます。
合意のマネジメント
最終的に内容の合意を諮ります。
合意に際しても、両者の承認を持って双方の合意となります。
よって、両者における準備期間を踏まえたうえでスケジュールを立て、合意までのマネジメント行うことになります。
まとめ
IT導入やシステム開発をこれから行うにあたっては、開発手法がウォーターフォールかアジャイルであろうが、先が見えていないことへの挑戦であることには変わりありません。
要求事項をとりまとめて、見積を取ったとしても、思ったものが出来上がらないリスクが残ります。
そして最悪は、完成してもいないのに、支出はせざるを得ないという状況です。
リスクをできるだけ抑えるために、契約は重要です。
ただし、契約書に記載されているからと言って、やはり重要なのは実行段階でどのように振舞っていたかです。
発注している側だとしても、プロジェクトマネジメント責任や意思決定責任が問われます。
発注側は発注側としての責務を果たすよう行動するとともに、証拠も残していきます。
受注側のパフォーマンスが悪ければ申し入れます。
行動をきちんと行うつもりであっても、やはり契約は重要ですので、軽視せずに対応していきたいです。
コメント