1. 本ドキュメントは筆者の個人的な
趣味です。所属する団体、組織、
企業とは一切関係がありません。
特に、所属する企業とは本当に
一切関係がありません。

2. 2013年11月30日
Web系企業における
アナリストとかコンサルタントとか
データサイエンティストとか
呼ばれる人のための：
ウォーターフォール開発モデル
再評価の試み

3. 役割分担
た
ぶ
ん
こ
ん
な
感
じ
だ
と
思
う
。
元
請
け
下
請
け
孫
請
け
開発工程
要件定義
概要設計
詳細設計
開発
プログラミング
テスト
運用・保守
大規模なソフトウェア開発で一般的に使われている
ウォーターフォール

4. ウォーターフォールは、批判がとても多いのだ。
• 元請が得してて、下請が損してる気がする。
• 『要件定義』とか、結局なにやってるのかよくわからない。
• 実際そうそう計画通りには作れない。
• 元請けだと肝心の『開発』ができないし、
下請けだとそもそもの『要件定義』に関われない。
ウォーターフォールの悪い点
やりたいことができない

5. でも、Web系の会社なら
自社でサービス持ってる
から……

6. 役割分担
開発工程
社
内
に
各
分
野
の
い
ろ
ん
な
担
当
者
が
い
る
。
サービス
イン
発見した課題の
解決策発見
僕の考える理想の
Web系企業の開発モデル

7. ウォーターフォールの課題を克服。
• 元請が得してて、下請が損してる気がする。
→ 元請とか下請とかない。
• 『要件定義』とか、結局なにやってるのかよくわからない。
→ 課題の発見と解決という、明確な目標ができる。
• 実際そうそう計画通りには作れない。
→ 課題はあることが前提で、試行錯誤を繰り返して良くしていけばいい。
• 元請けだと肝心の『開発』ができないし、
下請けだとそもそもの『要件定義』に関われない。
→ 元請とか下請とかない。
僕の考える理想の
Web系企業の開発モデルの良い点

8. しかし、現実は
きびしかった。

9. 役割分担
開発工程
営業
契約を取る
コンサル
契約書作成
実在
しない人
サービス
イン
課題を
ごまかす
運用・保守
サービスの
課題発見
発見した課題の
解決策発見
契約更新
契約更新
確認
発見した解決策を基に
開発
この辺のことやりたいけど、無理理。
下⼿手に⼿手出すと徹夜連続になって
契約か運⽤用・保守で事故る。
僕の考える現実の
Web系企業の開発モデル

10. 課題の解決とかしようとすると
営業か、コンサル
どっちかが過労で死ぬ。
僕の考える現実の
Web系企業の開発モデルの悪い点

11. やっぱ
ウォーターフォールを
再評価しよう

12. 開発工程
役割分担
事
務
『
』
運
⽤用
・
保
守
『
と
』
開
発
営
業
運
用
・
保
守
は
分
多
析
め
に
雇
開
う
。 発
契約書
作成
契約
取る
サービス
イン
運用・保守
課題発見
解決策発見
開発・テスト
僕の考えた
ウォーターフォール

13. これならギリ回せる気がする。
僕の考えた前ページの
ウォーターフォールの良い点

14. 以上です。
本ドキュメントは筆者の個人的な趣味です。
所属する団体、組織、企業とは一切関係がありません。
特に、所属する企業とは本当に一切関係がありません。