PSP概論

1. くまきち
長崎IT技術者会 勉強会（9/18）

2. 「汝自身を知れ」

3. 計測（見える化）大事
↓
でも測るだけでホントに大丈夫？

4. 測るだけでは改善されない
↓
自分の弱点を見つけて改善していく
それがPSP

5. PSPとは
 PSP（Personal Software Process）
 カーネギーメロン大学ソフトウェアエンジニ
アリング研究所（CMU/SEI）のワッツ・ハン
フリーさんが考案した自己改善プロセス
 個人が、自分で行う作業の管理や、またその
作業のやり方（プロセス）を改善するのを支
援する仕組み
注：「ソフトウェアプロセス」という名前がついて
いますが、根本的な考え方は、他の作業に十分に展
開可能です

6. 見積りとスケジュール
ベースラインの確立
設計品質の改善
PSPの発展段階
PSP0
• 現行プロセスの整理
• 時間、欠陥の記録
PSP1
• 規模と時間の見積もり
• テスト報告
PSP2
• 設計&コードレビュー
PSP0.1
• 規模の計測
• プロセス改善提案
PSP1.1
• スケジュールの計画
PSP2.1
• 設計テンプレート

7. ベースラインの確立
 プロセスに沿った開発、データ収集の基礎
 PSP0
 単純なプロセス構造
 時間の記録
 欠陥の記録
計画 設計 コード
コンパイ
ル
テスト 事後分析
No フェーズ 開始時刻 中断時間 終了時刻 デルタ時間 備考
No 日付 欠陥型 作り込み 除去 修正時間 参照
No フェーズ 開始時刻 中断時間 終了時刻 デルタ時間 備考
1 Code 10:00 10min 11:00 50min TEL
No 日付 欠陥型 作り込み 除去 修正時間 参照
1 09/18 20 Code Compile 10min -

8.  プロセスに沿った開発、データ収集の基礎
 PSP0.1
 規模の計測 「どこをどうやって測るか？」
 どこを測る
 どうやって測る
 コーディング標準の作成
 規模計測標準の作成
ベースラインの確立
削除
無修正
修正 追加
再利用
新規
再利用 計測の対象
ここを測る

9.  プロセスに沿った開発、データ収集の基礎
 PSP0.1
 プロセス改善提案（PIP；Process Improvement Proposal）
ベースラインの確立
「のど元過ぎれば熱さ忘れる」
「元の木阿弥」
「問題は何か？」
「次はどうするか？」
個人としてスキルアップするために、
次にどうするかを整理し、記録する。
そしてそれを実践する

10. 見積もりとスケジュール
ベースラインの確立
設計品質の改善
PSPの発展段階
PSP0
• 現行プロセスの整理
• 時間、欠陥の記録
PSP1
• 規模と時間の見積もり
• テスト報告
PSP2
• 設計&コードレビュー
PSP0.1
• 規模の計測
• プロセス改善提案
PSP1.1
• スケジュールの計画
PSP2.1
• 設計テンプレート

11. 日付 週
計画
時間
累積
時間
実績
時間
累積
時間
PV
累積
PV
タス
ク
EV
累積
EV
3/8 1 20 20
3/15 2 15 35
3/22 3 25 60
3/29 4 25 85
 見積もり手法の採用とスケジュール計画
 PSP1
 PROBEを用いた規模と時間の見積もり（後述）
 PSP1.1
 自分自身のスケジュール計画立案
見積もりとスケジュール
日付 週
計画
時間
累積
時間
実績
時間
累積
時間
PV
累積
PV
タス
ク
EV
累積
EV
3/8 1 20 20 0 0 A
3/15 2 15 35 38.5 38.5 AB
3/22 3 25 60 38.5 77.0 B
3/29 4 25 85 23.0 100.0 C
日付 週
計画
時間
累積
時間
実績
時間
累積
時間
PV
累積
PV
タス
ク
EV
累積
EV
3/8 1 20 20 20 20 0 0 A
3/15 2 15 35 15 35 38.5 38.5 AB
3/22 3 25 60 20 55 38.5 77.0 B
3/29 4 25 85 20 75 23.0 100.0 C
日付 週
計画
時間
累積
時間
実績
時間
累積
時間
PV
累積
PV
タス
ク
EV
累積
EV
3/8 1 20 20 20 20 0 0 A 0 0
3/15 2 15 35 15 35 38.5 38.5 AB 0 0
3/22 3 25 60 20 55 38.5 77.0 B 38.5 38.5
3/29 4 25 85 20 75 23.0 100.0 C 0 38.5

12. 見積りとスケジュール
ベースラインの確立
設計品質の改善
PSPの発展段階
PSP0
• 現行プロセスの整理
• 時間、欠陥の記録
PSP1
• 規模と時間の見積もり
• テスト報告
PSP2
• 設計&コードレビュー
PSP0.1
• 規模の計測
• プロセス改善提案
PSP1.1
• スケジュールの計画
PSP2.1
• 設計テンプレート

13. PSPにおける品質のポイント
 役に立つソフトウェアとは欠陥がないこと
 欠陥が混入しないソフトウェア開発はない。
だから欠陥を取り除くしくみが必要
 設計レビューとコードレビュー
 テスト
 欠陥を混入させた時点が、欠陥を除去できる
最も良いタイミング
 自分で自分が混入させた欠陥を除去するのが効率的
 自分が混入させた欠陥の原因を判断する
 自分が混入させる欠陥を予防することを学ぶ
タイミングは
この２つしかない

14. 設計品質の改善
 戦略的な設計とレビュー
 PSP2 セルフレビュー
 自分自身の欠陥経験をもとに個人用チェックリスト
をカスタマイズして使用したとき、最も効果的
 チェックリスト項目を選択するために、自分自身のデータを
使用する
 レビュー時にデータを収集し、分析する
 チェックリストを洗練させる
<POINT>
改善が定着し、同様の欠陥が発生しなくなっ
たら、リストから外す

15. プロキシベースの見積もり

16. カテゴリ 非常に小
さい
小さい 中規模 大きい 非常に大
きい
計算 2 5 11 25 50
データ 3 5 9 26 30
入出力 9 12 16 22 30
論理 8 11 16 23 35
（合計）
プロキシベース見積もり
 PROBE見積もりのステップ
1. 概念設計
 要求をもとに、必要な部品（プロキシ）を洗い出す
2. 追加部品の規模を見積もる
カテゴリ 非常に小
さい
小さい 中規模 大きい 非常に大
きい
計算 2 5 11 1 25 1 50
データ 3 2 5 9 26 30
入出力 1 9 12 16 22 30
論理 8 1 11 3 16 23 35
（合計） 9 21 48 25 50

17. プロキシベース見積もり
 PROBE見積もりのステップ
3. 再利用部品とベースプログラムの修正規模を
見積もる
 他のライブラリ等から利用する部品の規模を確認①
 将来再利用可能な部品の規模を確認②
 ベースとなるプログラムの修正行数を見積もる③
 プロキシ規模の見積もり値を求める
削除
無修正
修正③ 追加(2)
再利用①
新規
再利用②

18. プロキシベース見積もり
 PROBE見積もりのステップ
4. 追加・修正規模見積り
 蓄積されたデータをもとに、線形回帰によりプロキ
シ規模（実績）から追加・修正規模を見積もる
y = 1.2494x + 3.1938
R² = 0.9912
0
50
100
150
200
250
0 50 100 150 200
追加・修正規模（実績）
プロキシ規模見積もり

19. プロキシベース見積もり
 ポイント
 規模（ライン数）そのものではなく、プロキ
シ（代替）で見積もる
 最初からライン数では見積もれない
 プロキシはライン数と相関関係にあるものがいい。
たとえば、機能数、ファンクションポイント数、ク
ラス数など
 見積もりには必ずバイアス、偏りがあるので、
データに基づいて補正する
 データの計測、蓄積が大事！

20. TSPの紹介

21. TSPとは
 TSP（Team Software Process）とは
 PSPエンジニアで構成されるチームが、ソフ
トウェア開発作業を行うためのプロセス
 チーム構築を行うための定義されたプロセス
 チームワーキングの枠組み
 支援を提供するためのマネジメント環境
 TSPのコンセプトは「自律したチーム」
 作業計画はチームメンバが自分で作成する
 すべてのチームメンバが何らかの役割を引き受ける
 チームリーダはチームメンバ支援に徹する

22. TSPの開発戦略
ラウンチ 要求分析
インスペク
ション
事後分析
リラウンチ 外部設計
インスペク
ション
事後分析
リラウンチ 詳細設計 レビュー
インスペク
ション
コード
レビュー コンパイル 単体テスト
インスペク
ション
事後分析
リラウンチ 結合テスト
システムテ
スト
事後分析
PSPの部分

23. TSPのポイント
 チームラウンチ（立ち上げプロセス）
 役割マネージャの割り当て
 TSPコーチによるリーダ支援
 週次ミーティング
 チームメンバによるクイックな負荷平準
 PIPによるチームプロセスの改善

24. 象を食べるには？

25. よくある疑問１
 時間計測の粒度は？
 現状が把握でき、改善効果が見える単位とい
うことであれば、分単位が妥当です
 計測が面倒くさいんですけど
 作業時間計測のフリーツールなどがあります
 あとは慣れる必要があります。あくまで時間
は改善効果を確かめる指標なので、少々精度
が悪くてもよいと思います

26. よくある疑問２
 すでに開発プロセスがあるのですが…
 PSPは個人の開発プロセスがない組織にイン
ストールすることができるように、フルセッ
トで記述されています
 すでに個人の開発プロセスがあるなら、取り
入れられるところからやっていけばよいです
 概念設計にUSDMを取り入れる
 PIPにKPTを採用する
 計画立案にEVMを採用する

27. よくある疑問３
 開発言語がバラバラです
 ここがPSPのウィークポイントかも
 PSPは「データを蓄積して自分の能力を把握
する」という考え方なので、初めての経験に
ついてはちょっと苦手です
 新しいことをする場合には、事前のトライア
ルから計測を開始するとよいかもしれません

28. 最後のまとめ
 PSPとは
 個人が、自分で行う作業の管理や、またその
作業のやり方（プロセス）を改善するのを支
援する仕組み
 自分自身の（今の）実力がベース
 計測したデータがすべて
自分の実力を把握するところから
ひとつづつ始める
「象を食べるには一口ずつ食べる」

29. 参考資料
 PSPガイドブック
ソフトウェアエンジニア自己改善
（ワッツ・ハンフリー著、秋山義博監訳、JASPIC TSP
研究会訳、翔泳社）
 パーソナルソフトウェアプロセス入門
（ワッツハンフリー著、PSPネットワーク訳）