社内勉強会資料として作成した資料です。Web制作者を対象として、システム開発における上流工程とは何か、なぜそれが必要なのかを説明した内容です。

1. P R E S E N T A T I O N :
フロントエンドエンジニア 堀 祐磨 (ほりでー)
Web制作者のための
上流工程の簡単な説明

2. 2
自己紹介
堀 祐磨 (ほりでー)
1988年生まれ。多摩美術大学を中退後、
デザイナーとしてグラフィックデザイン･Web
デザイン･UIデザインを経験。
2015年、株式会社LIGにフロントエンドエ
ンジニアとして入社。

3. 3
上流工程とは

4. 4
2つの側面

5. 5
側面1
システム開発の
スタート地点

6. 6
Vモデル・
V字型アプローチ

7. 7
よく見る
教科書的な図

8. 8
要求分析
要件定義
基本設計
詳細設計
実装
単体テスト
結合テスト
システムテスト
プロジェクト評価
上流工程･上流設計
よく見る教科書的なVモデルの図
仕様が決まる
テスト

9. 要求分析
要件定義
基本設計
詳細設計
実装
9
そもそも何をしたいの?
プロジェクトの目的って何?
プロジェクトが解決する問題って何?
課題抽出とそれを解決する仮説の作成
こんなものがあったらさぞかし儲かる!
というシステム企画の立案

10. 要求分析
要件定義
基本設計
詳細設計
実装
10
どんな業務フローを作ればいい?
ソフトウェアはその業務フローのどこを担うの?
(運用要件)
ソフトウェアに必要な機能は?
例外が発生したら?
(機能要件)
ソフトウェアに必要な性能や信頼性は?
(非機能要件)
外部のソフトウェアとの連携や入出力は?
ソフトウェアが扱うデータの内容は?
将来的な拡張性は?
このあとのスケジュールは?
要求を具体化するためのあらゆる側面を
「要件」として決める

11. 要求分析
要件定義
基本設計
詳細設計
実装
11
どんなハードウェア構成にする?
どんな言語やフレームワークにする?
データベースの設計はどうする?
おおまかなクラス設計はどうする?
(アーキテクチャ設計)
外部システムとの入出力に使う
物理規格･プロトコル･データ形式はどうする?
(入出力設計)
ユーザインタフェースはどうする?
(画面設計･UI設計･情報設計)
要件を実現するの技術的な基盤や
方針を設計する

12. 要求分析
要件定義
基本設計
詳細設計
実装
12
具体的にどんなクラスやサブルーチンが必要?
各テーブルの具体的なスキーマは?
各サブルーチンの具体的なロジック･入出力･
発生しうる例外の種類はどういった仕様になる?
ユーザーインタフェースの具体的な意匠は
どんなものになる?
画面内のコンテンツはどういった処理を通じて
表示される?
ドキュメントやマニュアルの章立ては?
実装レベルでの詳細な仕様を固めていく

13. 要求分析
要件定義
基本設計
詳細設計
実装
13
これまでの設計したことを実際に作る

14. 要求分析
要件定義
基本設計
詳細設計
実装これまでの設計したことを実際に作る
実装レベルでの詳細な仕様を固めていく
要件を実現するための技術的な
基盤や方針を設計する
要求を具体化するための
あらゆる側面を「要件」として定める
システム企画の立案

15. 実装
単体テスト
結合テスト
システムテスト
プロジェクト評価
詳細設計での仕様通りかサブルーチンを検証する
複数のパーツを結合し、
基本設計レベルの仕様を満たすか検証する
システムを実際に動作させ、
要件が実際に満たされていることを検証する
企画通りのシステムが実際に完成したか検証する
企画の意図通りの効果が実際にあったか検証する
今後の運用改善を検討する

16. 16
要求分析
要件定義
基本設計
詳細設計
実装
単体テスト
結合テスト
システムテスト
プロジェクト評価

17. 17
要求分析
デザイン
コーディング
単体テスト
結合テスト
ブラウザ検証
プロジェクト評価省略
省略
省略
小規模なWeb制作の規模感だとこんな感じ
対応ブラウザ
WF 省略

18. 18
なぜこんなことをするのか

19. 19
なぜこんなことをするのか
上流工程の重要性
「目的(why)」なしに「何が必要か
(what)」を考えるのは不可能
「何が必要か(what)」が決まっていない
状態で「どうやって(how)」を考えるのも
不可能
「目的」「何が必要か」「どうやって」が
ない状態では、的外れなものしか作れない
要求分析
要件定義
基本設計
詳細設計
実装
Why
What
How
How
Do

20. 20
側面2
リスク管理の要

21. 21
要求分析
要件定義
基本設計
詳細設計
実装
単体テスト
結合テスト
システムテスト
プロジェクト評価
上流工程･上流設計
スケジュール･予算･方針･
機能･性能･責任範囲のほと
んどがここで決まる!

22. 22
側面2・リスク管理の要
要求・要件がはっきりしないことによるリスク
実装のやり直しが何度も発生する
想定を越えた機能や品質を求めら
れる
作業スコープが際限なく広がる
実装を開始してからアーキテクチャ
の変更が必要なことに気付く
実は全く的外れなものを作ってい
たことに運用開始してから気付く
サビ残･赤字･デスマの原因に

23. Thank you!
http://media-massage.net/
デザインとWeb開発とその他諸々。