カスタマーレビュー
おすすめ度：

---

プロジェクトの見えるかは何のために？　　（2008-01-18）
ITプロジェクトの「見える化」は何のためにやるかで、そのやり方も違うかもしれません。
この冊子での報告を参考に、自社の目的、自部門の目的、個々の社員の目的を明確にして、見える化を進めるとよいと思われます。

見える化の費用が、改善による費用削減を上回らないように、なるべく費用がかからない方法がよいと思われます。

---

「要件定義」と「システム設計」工程の「見える化」　　（2007-08-06）
　昨年でた「下流工程編」は、
　システム開発のライフサイクルの下流部分にあたる「システムテスト」「運用テスト」に
　焦点をあてた「見える化」でしたが、
　今年の「上流工程編」は、「要件定義」と「システム設計」工程の「見える化」です。


　下流工程編が、システム開発のシステムテスト工程以降を
　　医療の現場をアナロジーにして、
　　健康状態・病気の診断、対症療法で説明したのに対して、

　上流工程編は、
　　飛行機のフライトにおける目標値設定と飛行計画に例えています。


　内容的には、

　プロジェクトにおける「定性的見える化アプローチ」を、
　　まず「自己評価シート」に基づくセルフチェックと、
　　アセッサーによる「ヒアリングシート」におるアセスメントの実施で把握。

次に、
　　「定量的見える化アプローチ」
　　測定尺度・・・ＣＭＭＩの「測定プロセス」の指標そのものになるか、と思いますが、
　　この指標項目を見ているだけで、しばし考えさせられます。

　「曖昧性と不確実性のマネジメント」は、
　　　ズバリ、リスク管理。
　そのリスクも踏まえた上での「見切り」をどうするか。
　　「良い見切り」と「悪い見切り」を考えます。

　具体例として、
　　失敗工学・・・にならって、失敗プロジェクト事例が５８も載っています。
　　これだけでも、一読の価値あり、と思います。