システム開発プロジェクトで発注者と受注者が築くべき関係性とは?

システム開発プロジェクトで発注者と受注者が築くべき関係性とは?

プロジェクトの失敗確率が、いまも非常に高いシステム開発。そんなシステム開発の現場で、どのように要件定義を進めていくべきか。

そして、要件定義や設計を進めていく上で、発注者とベンダが築くべき関係について。それは、発注者と受注者という上下の関係ではなく、本来の目的である「プロジェクトを成功させ、必要なシステムを開発する」ために必要なことを、すべてテーブルに上げ、議論すること。

もちろん、プロジェクト管理に必要な資料や手法についても書かれていますが、それ以上に発注者となるクライアントと、受注者となるベンダの関係性に焦点をあてて、描かれている本でした。

ありがとうございました!

本のまとめ

▼読んだ本は?

■システムを「外注」するときに読む本
■細川 義洋 (著)

▼プロジェクトの3つの失敗要因とは?

【1】納期オーバー
【2】コストオーバー
【3】当初望んだ機能が、システムに備わっていない

▼プロジェクトのはじめに行う要件定義ってなに?

■要件定義
└システムと、それを使う人の動作・業務を決める作業
└「業務要件定義」「システム要件定義」の大きく2つに分解される

■業務要件定義
└新しくシステムを導入して、どんな業務を実現したいかを決める
└例えば「アンケート作成」「結果の分析」「見込み客の抽出」など

■システム要件定義
└業務内容に基づいて、システムが保持すべき機能を決める
└例えば「アンケートを表示する機能」「回答を入力する機能」など
└「機能要件」と「非機能要件」に分解される

▼機能要件・非機能要件って?

■機能要件
└例えば「営業が特定の商品を入力すると、データベースの中の在庫情報を見て、その情報を帳票に出力する」など
└「入力値・計算方法・出力値」の3つが揃っている必要がある

■非機能要件
└システムの処理速度、容量、使い勝手、セキュリティなどを定義する

▼要件定義開始時に行うべきことは?

【1】業務フロー図を書く
└今の業務の流れ(As-Is)と、実現したい業務の流れ(To-Be)を導く
└今の業務の課題点に加え、残しておきたい業務フローも書いておく
└システムを利用するお客さんや社員が、どんな風に喜ぶかをイメージしながら描く

【2】システム化すべき範囲を明確化する
└システム化すべきところは、コンピュータの導入効果が明確に出るところに絞る

▼プロジェクト管理に必要なものは?

■WBS
└必要工数の予定と、成果物をまとめた資料

■リスク管理・課題管理
└プロジェクト成功を阻害する事象を管理するリスク管理や、タスク把握のための課題管理資料
└リスクに対しては、対応策を発動するしきい値を、予め決めておく必要あり

■変更管理
└変更が発生した場合の履歴・バージョン管理・影響度調査を行う資料

■会議計画
└プロジェクト内で必要な、会議体の開催計画を定める資料

▼発注を受けるベンダ側が取るべき姿勢は?

■プロジェクト管理は、権利ではなく義務
■例えば、追加見積もりが必要であれば、その情報を発注者に開示する必要がある
■もし開示を行わず、結果プロジェクトが失敗すれば、ベンダはプロジェクト管理義務違反、損害賠償の対象となる
■だからこそ、内部の情報を含めて、ベンダ側はできる限りリスクを開示する必要がある
■「一緒に解決策を考えてほしい」という姿勢を、ベンダ側も持っていることが大事

関連する記事