1. 請負型システム開発と
プログラマの価値
Rev0.2

2. 目次
1.請負型システム開発の典型例
2.請負型システム開発の問題
3.プログラマの能力とあるべきシステム開発の姿
4.プログラマの能力の生きるビジネスモデル

3. 1-1. 請負型システム開発の典型例
請負型システム開発の例
要求掲示 発注 納品
買い手
構築 運用・保守
売り手
提案
時刻
→ 発注を受けたら、「システム」をつくり、納品する。

4. 1-2. 構築フェーズの典型例
典型例ーウォーターフォールプロセス
要求掲示 発注 納品
買い手
構築 運用・保守
売り手
提案
要件定義 受入
設計 テスト
プログラ
ミング
やりたいことが何かを確認し、どう実現するかを検討し、作っていくという「物を作
る」という意味では普通のやり方である。

5. 2-1. 「ソフトウェア」の特性
インフラ（ハードウェア）とアプリケーション（ソフトウェア）を合わせてシス
テムであるが、ソフトウェアは物質を伴う「物」ではない。
（あえて言えば、「物は」実行バイナリで、「物を作る」に相当するのは、
コンパイルし実行バイナリを生成することだと私は考える）
アプリケーション
（ソフトウェア）
インフラストラクチャ システム
（ハードウェア）
→ 「物」を伴わないので、売り手 / 買い手共に、出来上がるまで結果
が想像しづらい

6. 2-2. 要求変更とその対策
 後に行くほど結果が想像しやすくなるので、前に決
めたことを変えたくなる。
 一方で、変えると前の作業を直さないといけなくな
る（後戻り）。
要件定義 受入
設計 テスト
なるべく網羅で
きるよう先に、
先に決めようと プログラ
する。 ミング
→ 売り手は、物事が戻らないよう、多くの物事を先に決めよう
とする

7. 2-3. 要求変更の対策の弊害
 多くの物事を先に決めようとするとどうなるか？
ドキュメントや検討量 先に、先に多くのこと
が増える を決めようとする
後に戻るのが大変に
なる
→ 結果として、動作するシステムの価値は同じなのに、必要な費
用 / 時間は増え、費用に見合わない開発になってしまう。

8. 2-4. 要求変更への別の対策
 変更しにくいのがいけないのなら、変更しやすいプ
ロセスに変更すれば良いのではないか？
→ 答えは No.

9. 2-5. 要求変更とビジネス
 理由：売り手に入るお金 / 時間が増えないから
→ そもそも変更してはいけない（要求は増えないほ
うがよい）。それには、先にやることを決めるウォー
ターフォールが安全。
要求掲示 発注 納品
買い手
構築 運用・保守
売り手
提案
提案内容に対して… 価格 / 納期が確定（原則）
将来の作業に対して、「結果」を「コミット」することで対価を得ている

10. 2-6. ソフトウェアの価値
 結果として、請負型開発においてはウォーター
フォール型開発にならざるを得ない
 売り手は要求を増やしたくないので、価値は時間と
共に下がっていくのは自然の流れ
要求掲示 発注 納品
売り手
構築 運用・保守
買い手
提案 売り手は作業が少ないほうが費用がかからない
＝結果を期待できる価値は下がっていく
（結果を期待できる価値は提案時が最高）
価値
運用開始すると、陳腐化し、価値は下がっていく。
（製品としての価値は、納品時が最高）

11. 2-7. 請負型開発のプログラマの価値
 結果、請負型開発のエンジニア（プログラマ）の価
値は「いかに要求を実現できるか」つまり「いかに
要求を実現できないものがなくて済むか」で決まる
 つまり提案を満点とした「減点法」である
価値
良いエンジニア
悪いエンジニア
時刻

12. 3-1. プログラマの能力
 一方で、前述の通り、ソフトウェアは「物を作る」時
間はほとんどない
（プログラムは設計書で、完成品である実行バイナリを物と考
えた場合）
→ 本来、能力のあるプログラマなら、ソフトウェアと
いうものは時間とともにより良くしていくことが可能
のはずと私は考える。

13. 3-2. あるべきシステム開発プロセス
 より良くする→「変更」していくことを前提としたプロ
セスを選択する必要がある
ソフトウェアの価値は高めら
れるはず
価値
プログラマの価値も「減点法」から「加点法」になる

14. 4-1. ビジネスモデルの変更
 ところが、前述の通り、請負型開発ではウォーター
フォールが安定
→ プログラマの能力を活かすには、請負型開発そ
のものを変更する必要がある。

15. 4-2. プログラマの能力の生きるビジネスモデル
 プログラマが、プログラマの能力を生かした（価値
の高い）仕事をするには、変更が行えるプロセスに
する必要がある。
すなわち、将来の「結果」を見込みでコミットしない
ビジネスモデルに乗る、あるいは切り拓く必要があ
る。
 例：
 自製→人に対して対価が発生
 サービス提供→すでにあるものに対して対価が発生
 パッケージ販売→すでにあるものに対して対価が発生

16. End

17. 付録 1. ウォーターフォールが
適切な分野
 変更を可能とするのは、「物」を作る時間がほとん
どないことが前提
→ システムには「ハードウェア」という「物」がついている
場合が多い（多かった）
アプリケーション
（ソフトウェア）
システム
インフラストラクチャ
（ハードウェア）
ハードウェアがセットである必要がある箇所は必ずある（ ex: 組込）
ので、請負型システム構築でウォーターフォールという選択はなくな
りはしない。（ハードウェアありきの考え方をするとこちらになる。）

18. 付録 2. 工程分割について
 一括がダメなら、分割すれば良いのか？
→NG な場合も多い
 理由：結局、最初に決まってしまうものがある
 例１：納期が決まっている
 例２：最初に掲示した金額を越えてはいけない
当然、良いケースも存在する。
本筋からは外れるが、見積を行うのは、プロジェクト進行中のエンジ
ニアである。そのため、エンジニアの負荷が増え、本来システム作り
にかける労力が割かれてしまうというデメリットもある。