上流工程における品質目標の考え方と、プロジェクトが失敗する４つの要因を聞いてきた

10月24日
この１冊でよくわかる｢ソフトウェアテスト、設計書作成、プロジェクト管理｣教科書セミナー
を聞いてきた！！その内容をメモメモ

---

■「テスト設計」の観点から見た品質向上とプロセス改善の戦略
・体系的に学んだ人のあるひと５人くらい
　→属人的
・はじめに
　バルデスについて
　　バリューとテストの造語
　自己紹介

・こんな悩みはないですか？
　　テストのヌケ・モレ
　→限られた時間の中で→根性主義ではだめ
　→基本の型がだいじ：それを我流にしてしまうとだめ
　
・5分・１０分で品質上がる
　→どういう発想で

・基本の型：クオリティゲートについて
　上流工程から下流工程まで考える
　　→成功：ＱＣＤすべて→品質管理
　　　移行判定基準・品質基準：かんがえるのむずかしい
　　　時間がない

・Ｖ字モデル
　　クオリティゲート：何が出来ていればＯＫかという考え方
　　静的テスト：レビューも
　　動的テスト：動くものがある普通のテスト
　　考え方の基本が一緒

・上流工程でテストの発想を持っているかどうかが大事
　　品質を作りこむ基本の型
　　仕様ヌケの発見→手戻りの幅が広いほど、コストがかかる
　　テストの発想ばらばら→そろえていく

・Ｖ字モデルとアジャイル
　・アンケート：アジャイルは？すくない
　・ウォーターフォールとアジャイル：本質は同じ
　　　設計する→実装する→テストする
　　タイムスパンの違い
　　成功のポイント：要求定義の段階からテストを考えている

・上流工程にかけるコスト
　　不具合が発見されたときにかかる実装コスト
　　　　１：１０：４０：６０：１００
　　→基本設計で見つけられる修正：へらすことができる
　　　　→５分の手間を省いて、３日かかってしまう
　　基本の型：ロスが少ない

・品質低下
　　ほおっておくと、本来あるべきものから外れる
　　なにができればＯＫなのか
　　　　→品質は劣化していく：下げ止まりをする
　　開発；動くものを作ってから→品質保証；はずれている

・品質管理のポイント
　　品質低下を防ぐ＝品質目標からの乖離を防ぐ
　　・仕様書を全て実装すればＯＫ？
　　　　→お目にかかったことない。３０％
　　　→未来永劫でてこない：１００％の仕様書：コスト

・仕様書が不完全でも、テストは完全でないといけない
　　→書かれていないことを読み解く
　　　リバースエンジニアリングが基本：これができないといけないはずだ
　　　　　→トレーニングで身につく
　品質：自分で作れる

・上流工程における品質目標の考え方
　要求分析
　　仕様書＆取説がないけど、テストできる能力
　フィリップクロスビー
　　品質は要求を満たすことである→ペア概念
　　要求：望んでいること
　ワインバーグ
　　誰かの要求を満たすこと
　ＴＱＭ：日本人が得意でない部分
　　→この発想重要
　プロとして、どんな走り込みをしていますか？

・狩野モデル
　　当たり前品質、魅力的品質
　　　基本要求：品質と要求がペア概念　むずかしい
　　　変動要求：評価が上がったり、下がったりすること
　　　潜在要求：魅力的品質

・異常形の部分：あっちゃいけない
　リスクベイスドテスト

・皆さんにとって優先順位が高いところ
　　→メンバの癖
　：取り消しキー
　　あけたら止まる
　　ボディの異常加熱
　→機能仕様書のレビューをする前に行う
　　Never Must Want　に分解

・動かしてみないと分からない部分はある

・ＩＳＯ９１２６　品質特性
　ソフトウェアがいい
　　３つ　３つに分解
　　　外部特性
　　　　　機能性
　　　　　信頼性
　　　　　使用性
　　　内部品質：エンジニア
　　　　　メンテナンス
　　　　　別環境
　　　　　さくさく動く

　機能性のＮｅｖｅｒ，Ｍｕｓｔ，Ｗａｎｔ
　信頼性のＮｅｖｅｒ，Ｍｕｓｔ，Ｗａｎｔ
　使用性のＮｅｖｅｒ，Ｍｕｓｔ，Ｗａｎｔ
　　　　　：
　　　　　：
　　　とわけて考える
→日本のエンジニアは機能性のＮｅｖｅｒ，Ｍｕｓｔ，Ｗａｎｔしか考えない
　→テストの観点つくっていく

・テスト観点：テストを行う上での「切り口」のようなもの

・品質管理は教育に始まり教育に終わる

---

■設計書作成の標準化のススメ

・オブジェクトブラウザー　for Oracle
　他のＤＢにも対応

・設計書を標準化する２つのポイント
　・理想の設計書はない

・なぜ設計書はばらばらに
　　目的：ドキュメント体系（横軸）
　　読み手の特性：詳細度（縦軸）
　　他のドキュメントの存在（除いたもの）
　→案件ごとに変わる：パターン化することは出来る
　※ポイント１：案件のパターンを整理し、パターンごとに標準化する

・ツール
　　標準化
　　　「オブジェクトブラウザ　デザイナー」：フレームワーク、テンプレート
　※ポイント２：設計には設計専用ツールを使う

・機能紹介：デモを使って「オブジェクトブラウザ　デザイナー」などの紹介

---

■この一冊でよくわかるプロジェクト管理の教科書

・「オブジェクトブラウザ　シリーズ」とは
　設計、開発、プロジェクト管理などソフトウェア開発全般の合理化、
　生産成向上を実現するツール群

・プロジェクト管理　ＰＭＢＯＫ
　プロセスをマネジメントする考えを広めた
　　　９つの知識エリア：ＱＣＤがゴール　ＱＣＤだけではむずかしい
　　→いま１０個

　ＰＭＢＯＫの体系
　　１０の知識エリア

・ピラミッドという体系にした→思ったプロジェクト管理できない
　　統合システムにしないと、管理力は上がらない→ＯＢＰＭ

　プロジェクト管理のＥＲＰ
　脱Ｅｘｃｅｌ
　　　Ｅｘｃｅｌ：見える化できない、
　　　　　　　　　俺流の蔓延→標準のテンプレート
　組織で標準を持たない限り、プロジェクト管理力はＵＰしない

・プロジェクトが失敗する４つの要因
　　（１）そもそも無理な計画
　　　　　スケジュール、コスト、スコープ、リスク
　　（２）ユーザー側の甘い体質
　　（３）体制が不十分
　　（４）コミュニケーション不足

・（１）そもそも無理な計画
　受注しちゃいけない；未然に防ぐ
　　→見積もり提出時にリスクチェックミーティングを行う
　　　チェックリストを用意：形骸化しない工夫
　　　営業が甘くなる中で、辞退すること；リスクに対して真剣に考える

　プロジェクトスタート時にレビュー会
　　インセプションデッキで目的供給
　　情報共有
　　　→ガントチャート上にマイルストン

　インセプションデッキ
　　アジャイル開発のプロジェクトスタート
　　みんなで作る→プロジェクト憲章と違う

・（２）ユーザー側の甘い体質
　最初が肝心。キックオフセットを用意・活用する
　自分たちが分かっているがお客さんが分かっていない→お客さんに理解
　日程の確保
　ステアリングコミッティー
　キックオフセットで何を決める
　　体制：意思決定する人、ステアリングコミッティー
　　目的と概要
　　スケジュール
　　要件定義
　　コミュニケーションの方法

・（３）体制が不十分
　気合でＧｏは失敗する。リリース計画をきちんと立てる
　　　リソースヒストグラム
　スキル管理をこつこつ行う
　　　スキル照会、

・（４）コミュニケーション不足
　・最初にツールとルールを決める（めーるはやめる）

・組織の成熟度を高める
　ＣＭＭＩ
　実績・計画・標準・分析
　　計画までやらないと管理しているとはいえない