システム開発契約書(考察③)

中小企業の「システム外注」はじめに読む本 単行本 – 2018/11/18 坂東 大輔 (著)

 この本はとても有益。はじめにでシステム開発プロジェクトの成功率は52%(日経コンピューター調べ)2回に1回は失敗すると。
 システム外注をするという事は、既存の自社業務の一部をIT化する事です。そう定義し、その業務の現状(AS-IS)をヒアリングする事。そこには暗黙知と形式知がある。業務フォロー図を描いてもらって(発注者の債務)、頭の中にしかない暗黙知にヒアリングを重視。

  そして自社システムのあるべき理想像「TO-BE」を意思決定してもらう。これは発注者にしかできない作業。そしてRFP(提案依頼書)を作成。ウォーターフォール型が主流で、試行錯誤を前提としているアジャイル型。発注者もやること、決断する事が沢山。

  必ず何らかの伝達ミスや誤解が生じます。あらかじめそういう前提で何度もチェックやすり合わせを行う事が大切。「入力がゴミなら出力されてくるのもゴミ」より正確な伝達に努めよう。なるべく明文化、図評化で。後からの要件追加は混乱します。開発も戻し、時間と資金と労力がかかり追加費用となります。

 一度契約してしまうとベンダーの方が、立場として上になってしまいます。プロジェクトマネージャー(PM)との面接は必須。目が死んでゾンビ化してないか、お見合いに似ている。

 委託者がやるべき事は、法律や判例で決まっている。新システム企画書、業務フォローズ、要件定義書、RFI、RFP、進捗管理表、課題管理表、UXテスト用チェックリスト、レビュー用資料、受入テストチェックリスト、社内説明会資料、システム運用マニュアル

 RFP・・・発注者の希望する(TO-BE)を形式知としてまとめ上げた資料。新システム開発の全体像、提案してほしい内容、スケジュール、予算、契約条件など

 要件定義書・・・ベンダーと準委任契約を締結して二人三極で作り上げます。ここが失敗すると以後の工程がドミノ倒しのごとく総崩れになります。

  システムは運用保守が99% 開発に成功した後が大切。

 そして契約書。「ビジネスとは契約そのもの」お互いの行動の指針とするため、契約に基づいて様々な業務が遂行される。契約が根拠となる。契約当事者の意思を明確に表示し、責任の範囲を明確にする。

 システム開発の失敗率は50%で、その失敗の50%は要件定義。何冊か読んでいるが、やはり委託者側に原因がある場合が多い気がする。システム開発のプロと話がかみ合わないのは、知識量の差だと思う。知識差がある場合にこの本はとても有益。

#契約書作成 #リーガルチェック #契約書審査 行政書士 千葉市 #業務委託契約書 #システム開発契約書

Follow me!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

PAGE TOP