ソフトウェア開発事業者が適切な対価を遅滞なく受け取るための契約書
法務


この記事の目次
※ です・ます調は明治末期から大正期にかけて歓楽街で使い始められたもので、会話や手紙ならばともかくも、書き言葉としては下品で避けるべきであると文部科学省も指摘している。契約書や就業規則にです・ます調を使うことは考えられない。如何に親しみやすくても、それは仕事が欲しいという下心が見えてしまう。従って今回はこころみに、だ・である調で文章を作る。

1.お客様は神様にあらず。

電子カルテを中核とする病院情報管理システムの開発が失敗した責任を巡り、旭川医科大学とNTT東日本が争っていた訴訟の控訴審判決は一審判決を覆す内容だった。

札幌高等裁判所は2017年8月31日、旭川医大に約14億1500万円を支払うように命じた。2016年3月の一審判決(旭川地裁)は、ユーザ(旭川医科大学)・ベンダ(NTT東日本)の過失割合を2:8としたうえでユーザ・ベンダの両請求とも一部認容し、実質、旭川医科大学からNTT東日本へ約1800万円の支払いを命じる判決をしたが一転、高裁は旭川医大に100%の責任があるとしたのである。同医大は2017年9月14日、判決を不服として最高裁に上告した。

そして最高裁は上告不受理の決定を下し、判決は確定した。
もしNTT東が控訴していなければ、発注者の言い分ばかりが通る「お客様は神様」というソフトウェア開発の「常識(筆者に言わせれば神話)」が続いていたであろう。

ここで記事を読む読者はここまでの金額を争う企業とは思えないが、最高裁の不受理は高裁の判決、つまり発注者が度重なる要求仕様変更を繰り返し、スケジュールを限りなく伸ばし、NTT東が変更を要求された仕様について質問をしても不当に回答を遅延させた責任を重く見て発注者側に全面的に責任があるとしたものであることは参考として良いと考える。

中小零細のソフトウェア開発企業も発注者の仕様変更に悩まされ、割に合わない金額で遅れに遅れた納期で査収され、その間の適切な従業員への給与支払いにも困難を覚えることは珍しくない。

2.近年のシステム開発手法

従来「ウォーターフォール型」と言って半年なら半年と納期を定め、当初の仕様通りに開発を進めるのが主流であった。 しかし、今回の判決確定のように「当初の仕様通り」では査収されなくなってきた。

つまり発注から納品までの間に要求仕様は陳腐化し、より望ましい仕様を発注者は要求してくるのである。
例えば三か月の納期でゲームソフトを開発すると言った発注があったとする。日進月歩ならぬ「秒進分歩」と言われるほど進歩の早い分野である。三か月たつ間に当初のアイディアより斬新なゲームソフトを同業他社が開発してリリースしたら、誰も当初の予定通りの古いアイディアによる仕様のゲームソフトなど買いはしない。発注者としてはより斬新なソフトの開発を求めてくることは想像に難くない。

このように発展の早い情報処理の分野において従来のようなウォーターフォール型開発では到底「動くソフト」の速やかな開発は期待できないとして2001年(近年と言ってももう20年近い昔であるが)ユタ州に高名なソフトウェア開発者が集まって意見交換をし、考えをまとめ発表したのが「アジャイルソフトウェア開発宣言」である。

3.契約のあり方とその担保

アジャイルソフトウェア開発、スクラム、DevOps、DevSecOps、リーン開発と言った開発手法についてはいくらでも情報(情報処理技術者試験のうちでも最も初歩とされるITパスポート試験にしか合格していない弁護士の解説のみならず、名の通った雑誌や新聞社に至るまで、いい加減な解説も多いので正確な情報はipa情報処理推進機構やJIPDECなど信頼できる情報元から得るのをお勧めするが)を得られるし、ここは開発手法や技術の解説をするところではない。

問題はどのような契約書を取り交わして、どのように開発を進めれば開発事業者が十分報われる対価を遅滞なく得られるかというビジネス上の問題を解説する場所である。開発事業者のキャッシュフローを考えれば月に一度一定の金額を受領するという契約も必要であろう。

延び延びになった期日に納品して査収されて初めて金員を受け取れるというのでは、その間の資金繰りが困難となる。

さて、具体的に契約書の話に入るが、この方面の法律家が一致して指摘するのは発注者と開発事業者、場合によってはプロマネの「協力義務」を契約書に「明記する」ことである。

これにより開発事業者が誠実に職責を進めているのに、発注者が仕様変更をした場合に質問をしても不当に回答を遅延させるようなことは避けることができるし、万一発注者が誠実に迅速に協力義務を果たさなかった場合、その責任を問うことができる。最終的には法廷に訴えることもできるのであるから発注者の責に帰する納期遅延分の対価を請求することができるであろう。

次に納期も契約金額も流動的であることについて合意を取り交わしておくことである。定期的、または随時開かれるミーティングや、発注者と開発事業者が協同して行う作業、仕様変更によって当初の見積もりよりも開発事業者の従業員の実労働時間が増えた場合は納期も後ろにずれるし、受け取るべき報酬もその労力に応じて当然に増えるからである。

法律家の仕事も最初に見積もりを出して契約するのであるから、手間暇がかかって稼働が増えても容易に割増の報酬を請求するのはできないのが実態であるが、やはり時間が余計にかかり、従業員がより多くの工数を割いたとなればこれは要求して当然であるし、発注者に要求しなければ開発事業者の経営者は自分がこの分を負担しなければならない。

しかしここで問題となるのは、どれほどの時間当初の予定より超過し、単価いくらの人間が単価いくらのハード、ソフトを使用して開発したか証明して合意に至るのは現実的には容易なことではない。ストップウォッチを持って時間を測り、これをその日のうちに記録して月次に発注者に報告して対価を請求するというのはそれだけで手間である。そのためのソフトウェアを用意しなければならない。

エンジニアの時給は証明できるが、使用するハード、ソフトの時間当たり償却単価を証明するのは至難であろう。それでも双方が納得するためには契約書に使用するハード、ソフトの一覧を作成し、それぞれの取得価格や耐用年数から割り出した時間当たり使用料を記載せざるを得ない。
買うよりリースであれば月額いくらと提示しやすいくらいである。

4.クラウド利用がもたらす時間当たり単価の明瞭化

しかしここへ来て時代はクラウドとなった。
クラウド利用には様々な利点がある。しかしここはそれを列挙する場所ではない。ここでしたためるべきは「クラウドは時間当たり(一秒あたりいくら、というクラウドすら存在する)で利用料金が請求され、請求内訳も明確に示すことができる」つまり発注者に納得させることが容易である。

政府機関も「クラウドファースト」すなわちシステム開発にあたってはクラウド利用を第一選択肢とする。として、安全と認められるクラウドサービスを第三者に監査させて認定・登録し、ここで登録したクラウドを使えば安全であるから利用する。という趣旨のISMAPという制度をスタートさせた。

これは先行するアメリカのFedRAMPを大いに参考にしたと思われるが、もう「クラウドファースト」ではなく「クラウドデフォルト」の時代であることはIT関係者の衆目の一致するところである。
クラウドの利用は進展するであろう。

記事のキーワード*クリックすると関連記事が表示されます

メルマガ登録(毎週水曜配信)

SHARES LABの最新情報に加え、
経営に役立つ法制度の改正時事情報などをお送りします。