「なぜ、システム開発は必ずモメるのか？」を読んだ
2019年11月頃に読んだ。
当時残したメモと記憶を頼りに書いてみる。
目的
システム開発、とくに請負開発を行うにあたり、お客様（発注側）とどのように付き合っていけば良いのか知りたい。 なんとなく次のことが大事かなと考えている。
- 予算と納期、関係者の合意
- 各工程の進め方、成果物、完了条件
- 想定外が起きた場合の対処方法
- 要件の実現可能性の検討
- 要件の変更時の取り決め
書籍の内容
目次は次の通り。
- 要件定義
- プロジェクト計画と管理
- 設計
- プログラミング
- テスト
- 契約と仕事の完成
内容は物語形式で、IT紛争専門の弁護士である主人公を中心に話が進む。 システム開発に関わる様々なトラブルの場面で、過去にどのような裁判の判決が降ったか、トラブルを起こさないためには何が大事なのかが語られている。
読んだ感想
個別具体的には色々と注意点があるけれど「やるべきことをきちっとやろう。契約書に書かれたことが全てではないよ」ということに尽きると思った
以下、メモの中から重要そうなものをピックアップ。
要件定義
- パッケージ不適合に備えた代替案を用意する、フィットアンドギャップを実施する。
- メンバーのスキル不足があるときの評価とスキルアップ計画をユーザと共有する。
- 性能要件を条件付きで良いので早めに決める。要件を勝手に書き換えるベンダーは要注意。
- 最低限、要件と受入テストの項目を紐付ける。要件漏れを防げる。
- 要件定義が泥沼化した場合、味方になりそうな人を探し、一緒に解決する道を見つける。
- システム化の目的が抽象的な場合、方針を基に要件を考える。業務フロー図からシステム化対象範囲を決める方法、システム化の方針からシステム化対象を想像する方法の両方を使うとよい。
プロジェクト計画と管理
- ユーザ側のリスク抽出や解決はユーザ側の責任だが、そのガイドや解決策の提案はベンダー側の責任である。
- ユーザの威圧的な態度が原因であっても、メンバーのメンタル管理はベンダ側の責任である。
- その人しかできない作業に集中させる。思考の継続性を維持できるようにする。
- 引き継いだシステムをそのまま作るか、作り直すかは、定量的に比較した上で行う。フィジビリティ。
設計
- 非機能要件などの要件に不備がある場合は是正を促す必要がある。
- 設計書を著作物と認められるには創作的である必要がある。
テスト
- 受入テストのテストケースとテストデータのレビューを要件定義の直後や受入テスト前にユーザにしてもらう。抜け漏れ防止のため。
- システムの要件が固まった時点で、プロジェクト完了基準、つまり検修の条件を決めておくことが大事。
- 受入テストのテストケースが完了
- 保守用ドキュメントがある
- 保守開発とテスト用の環境がある
- 本番稼働後の体制が整っている
- 一般的にはシステムテストまではベンダ側、受入テストはユーザ側の責任。お互いの協力が必要。
- 検収書だけでは債務履行の理由にならない。
- テスト結果報告書が未提出で、それが正しく行われていることを証明できないなら不履行となる可能性がある。
- 検収後にバグが出て責任を求められたら対応計画や代替案提出などが必要。
契約と仕事の完成
- プロジェクト管理や変更管理に必要な費用は、プロジェクト全体の2〜3割程度。
- 下請けは元請けから開発規模の提示があっても自らの経験や実績に基づき独自の見積をすること。元請けはそれを妨げてはいけない。
- 契約前や受注前の作業はしない。管理作業についても契約書に記載すること。契約書に請負か準委任か記載すること。
記事作成にかかった時間：５０分
