動かないコンピューター ― 情報システムに見る失敗の研究 単行本 – 2002/12/6 日経コンピュータ (編集)
動かないコンピューターが発生した11のパターン
1. ソフトの不具合を修正できず
2. 開発を請け負った企業の業務知識が不足
3. 導入計画に無理があり、システムの仕様が不完全
4. 出来上がったシステムを確認する検収作業が不十分
5. 開発を請け負った企業の指導が足りず、顧客がシステムを運用できず
6. 顧客企業にシステム専任要員がいない
7. 利用したパッケージ・ソフトが業務に合わない
8. 顧客企業と開発を請け負った企業の役割分担が曖昧、契約も不明確
9. システムを運用するための基本的な準備が不足
10. 顧客の社内及び開発を請け負った企業との人間関係のこじれ
11. 開発を請け負った企業の担当者が交代あるいは退職
業務のやり方をどうシステム化するのかをハッキリさせないと、「何をしたいのか」を曖昧にしたままシステムを開発しても失敗に終わる。どんなシステムを作るのかを決める要件定義。この最初の作業が一番大切。開発の失敗の半分は最初の要件定義。
設計開発。システム会社の社員は、委託者の会社の業務、すなわち仕事の進め方について知らない。大まかな流れを図に書いて、かつ現場の要望も吸い上げないと使い勝手の悪いシステムが出来てしまう。
テスト。各プログラムを合わせて、ちゃんと動くか？所定のテストを時間をかけて全て行わないとリスクが大きい。発見できない不具合もある。そこは保守運用でカバーされる。保守とは業務の変化に合わせてシステムを修正していく面もあります。
運用。 実際に運用する現場の担当者に操作方法を教える。システム障害に備えた対策。ソフトに不具合は付き物です。
システムの成功率は約50％で、失敗の50％は要件定義である。委託者と受託者のコミュニケーションがなにより大事。委託者には「協力義務」受託者には「プロジェクトマネージメント義務」があり協業作業そのものです。委託者の多数の業務部門にまたがるシステム開発に、各業務部門の意思が統一されてなければマズいです。委託者側の意思疎通、委託者と受託者の意思疎通、受託者側の意思疎通（元請けと下請け）
現場は協力的か？こちらは仕事の進め方、やり方（商慣習）があるから、掻きまわされたくない。という感じで非協力的になる場合もあります。現場の暗黙知を含めないと使い勝手の悪い使えないシステムが出来てしまう。「要望」を吸い上げて「要件」として定義して慣れれば使いやすいシステムを作れば成功である。明文化されてない要望を察知して適切なシステムに落とし込む技量（仕様書の行間を読む）なかなか委託者が本気にならないと受託者も本気にならないのでは・・・
担当者の突然の異動、退職は開発にダメージを与える恐れがあります。この本にはいろいろな失敗例が載っています。最近の事例は、以下
日経コンピュータ「動かないコンピュータ」 | 日経クロステック（xTECH） (nikkei.com)
こういった現実を知らなければ、おそらく自分の常識を優先してしまうのでしょう。支払う側なのになんでこんなに動かなくてはならないの？ 受託者側の義務として、委託者にわかりやすく説明して要件定義など開発を主導する義務があれど、委託者側が非協力的だと成功しないでしょう。更に知識量の差から意思疎通が停滞し、人間関係が悪化。開発の失敗につながる。それで委託者は損害賠償を考えて弁護士に相談。損害の立証の為システム開発の失敗事例を研究。「あっ無理だ。」と裁判を諦める。この本は20年前に発行された事例なので、もう現在はこのような事例はないかと思いたいです。
#契約書作成 #リーガルチェック #契約書審査 行政書士 千葉市 #業務委託契約書 #システム開発契約書
Follow me!
