システムの調達（sd

システムの調達
システム設計
第４回
前回のポイント
ソフトウェアは




“大きい” 複雑
完璧なものはない
チームで開発
 プロジェクトマネージャ
開発手法
 複雑なソフトウェアを，間違いなく開発するた
めの手法が提案された
 ウォーターフォールモデル古典
システムの調達
前提


ソフトウェアの開発を採り上げる
 システム ⇒ ソフトウェアシステム
開発は外部のベンダ企業に依頼する
 vendor 売り手
まず

発注者
 どのようなシステムが欲しいのか
 ハードウェアは
 新規システムか既存システムの機能拡張
か
 納期は
 …
 システムの満足すべき条件をまとめる
 提案依頼書（RFP Request For Proposal）
次に

ベンダ企業（複数の場合も）
 RFPを基に，どのようなシステムを開発するか
提案する
 提案書
 開発するシステムの費用を示す
 見積書
 ここでは，提案書に含める
そして

発注者
 提案書の検討
 複数のベンダ企業から提案されている場合
も
 ベンダ企業の選定
 両者が合意すれば契約

発注者
 システムの要件
をまとめる
 提案依頼書
 比較・検討
 ベンダ企業選
定

ベンダ企業

契約
検討
 提案書
？

RFP ＝提案書でないのか？

RFPがあっても，提案書を出さない場合は？
提案依頼書の作成
提案依頼書（１）

システムの概要
 システムの仕様を具体的にまとめたもの
 何のためのシステムなのか
 システムのメリットは何か
 既存システム（があれば）との関係
 既存システムの問題点
 既存システムの変更 ⇔ 新システムを新た
に開発
提案依頼書（２）

提案依頼事項
 求める回答は…
提案依頼書（３）

調達条件
 納期
 発注形態
 保守
 著作権・機密事項
 …

費用
 開発するソフト
ウェアの”代金”
 諸経費
提案依頼を受けたベンダ企業では
まず何をするのか？
手を挙げるかどうか？

ソフトウェアの開発にはコストがかかる

トラブルが起きると大きな損害

提案依頼書の慎重な検討
システムを完成できるか？



自社の技術力
 得意分野
 ノウハウの蓄積 ⇒ コスト減
 未知の分野
 新たな人材の確保（養成） ⇒ コスト増
人手
次の受注を狙うために
 社内で不足なら，再委託
コスト増を受け入れる
…
場合も
儲かるか？

赤字でも受注を狙うことがある
判断は？


一人の社員（担当営業）では決められない
会議（役員）の会議
 会議資料の作成
 開発プロジェクト計画書（開発計画書）
 提案書・見積もりの根拠
開発プロジェクト計画書
単に“開発計画書”
開発計画書（１）

内容・書式は会社により異なる

開発する（受注する）システムの概要

（開発）プロジェクトの概要

スケジュール（スケジューリング後で補足）
開発計画書（２）
コスト
もし，これが１か月なら，プログラマの１か月分の人
 突き詰めれば人件費
件費がコストとなる（かなり単純化している）
 システムの大きさ ⇒ 必要な人手
この大きさを“1人月”という
 プログラムの作成だけに限っていうと
 プログラムの行数（A行）
 プログラマの生産性（1就業日当たりB行）
 A／B 日必要

開発計画書（３）


（２）の生産性は状況により変わる
 得意分野か未知の分野か
いろいろな要因で手間がかかる場合がある ⇒
人手がかかる ⇒ コスト増
例えば，発注者の要求にあいまいな点
実際に受注したら，そこを詰めなければならない
各工程の大きさ
投入できる人員の生産性の人数
から所要日数を求める
スケジューリング（１）

各工程の中の作業ごとに
開発の各工程の所要日数
細かく日数を求める場合も
 ウォーターフォールモデルなら
 要求分析（要件定義）
 外部設計
 内部設計
 プログラムミング
 テスト
スケジューリング（２）

ガントチャートやPERT図（アローダイアグラム）を
作る


今回の提案依頼書に応えることになったら
⇒ 受注を目指す
提案書を作成する
提案書
この段階では開発予定のシステム
なので，提案システムと呼ぶ
提案書（１）

提案システムの概要と特徴
 提案依頼書のシステムを具体化
 使用時のイメージがつかめるなど
 誰がどのように使うのか
 制約条件
 ハードウェアの条件など
 他のベンダが提案するであろうシステムとの
違い（セールスポイント）
提案書（２）

開発プロジェクトの概要
 体制
 自社の人員・協力会社の人員
 新規開発・既存システムの変更・パッケージの
利用？
 スケジュール
 発注者側との協議スケジュール
 完成するまで一切ない，ということはない
提案書（３）

契約条件など
 納期・費用（見積もり）
 納入物
 著作権に関する事項
 守秘義務も関するもの
 保証など
提案書（４）

補足納期・費用（見積もり）
 支払い方法（一括・分割）
 納期
 全システム一括納品・サブシステムごとに
納品
 支払方法に関係
提案書（５）

補足納入物・著作権に関する事項
 どのような文書（マニュアル）
 プログラム（実行形式のものだけ・ソースも含
める）は？
 こういったものの著作権はどうするか？
 発注者は再利用できることを期待？
 ベンダは別の案件でも使い回したい？
提案書（６）

補足守秘義務も関するもの
 システムのテストで，実際のデータを用いる
 このデータは発注者の営業秘密である
 取扱い方法を明記
 借用・保管・廃棄
提案書（７）

補足保証など
 納品後，不都合な点があった場合の対応
 例検収後1年は無料で対応
 技術サポート（使用方法の指導）
 例コールセンター
 例要員を配置
まとめ
まとめ（１）

ここで考えているシステムは高価なもの
 発注者システム自体だけでなく，そのシステ
ムが稼働しない・稼働が遅れることによる損害
もある
 ベンダ予想外のコスト発生などは避けたい
まとめ（２）

発注者
 システムの要件
をまとめる
 提案依頼書
 比較・検討
 ベンダ企業選
定

ベンダ企業

契約
検討
 提案書
補足

ガントチャートやPERT図は，プロジェクトの進捗
管理にも使うことができる

Download Report