 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
説明の中で、(I1)や(S2)などの記号が出てきますが、これは第1回で使ったプロジェクト管理状況チェック表のNo.と対応しています。チェック表で明らかになった問題点に対応する部分は、特に注意して読んでみてください。
|
|
| 品質計画と品質基準書
|
PMBOKの品質計画プロセスでは、費用対効果分析や品質コストの算出などを行い、「品質マネジメント計画書」「品質測定基準」「チェックリスト」を主なアウトプットとしています。品質マネジメント計画書には、品質を保証・改善してゆくための組織構造や責任分担、手順、経営資源などを定義するのですが、少し概念的なのでこのままでは利用できません。実用レベルに落とすにあたり、弊社のプロジェクト管理手法PYRAMIDでは「品質基準書」を品質計画プロセスのアウトプットとしていますが、今回そのテンプレートを用意しました（図1）。このテンプレートでは、"システム全体"とか"操作性"などのテーマ単位にレスポンスやセキュリティなどの品質基準を設定します。
品質基準書を作成する上で難しいのは、抽象的な項目をいかに具体的な内容に落とすかということです。そもそも「品質＝ユーザー満足度」という前提自体があいまいな定義であり、何をもってOKとするかをうまく言い表すのが難しいのです。「更新ボタンを押したときに画面の値がデータベースに反映されること」「検索ボタンを押したときに、検索条件に合致するデータが一覧表示されること」などは非常に重要なことですが、当たり前すぎてわざわざ基準書に書き出す意味がないでしょう。実用的には、人により見解や解釈が異なるような項目、黙っているとおろそかになってしまいそうな項目について明記するという考えに立つのが良いと思います。
|
図1：品質基準書のテンプレート
（画像をクリックするとEXCELファイルをダウンロードできます。/27KB）
|
品質基準書を作成する上でもう1つ悩ましいのが、これをユーザーと共有するかどうかということです。もちろん「品質＝ユーザー満足度」という大前提からして、ユーザーと情報共有すべきなのですが、実際のビジネスでは下手にユーザーに示すことにより後で首を絞めることにならないとも限りません。そこでPYRAMIDでは基準度という項目を設け、必須事項と努力目標に分ける様式にしています。前向き品質の中で、実現できるかどうかはっきりしないものを"努力目標"とさせてもらいます。達成できなかった場合でもペナルティにならないことが、逆に前向き品質に対してチャレンジできる姿勢を生むのです。
品質はコストと無関係ではありません。品質を高めるためには、それ相応のコストがかかります。この関係はリニアではなく、エクスポーネンシャルな関係となり、あるレベル以上の品質を実現しようとすると、コストは急激にアップします。そのことをきちんとユーザーに説明すれば、間違いなく理解を示してもらえますので、できるだけユーザーと品質基準を共有するようにしてください。
|
| 品質保証とデザインレビュー
|
PMBOKの品質保証プロセスでは、「品質計画ツールと技法」「品質管理」などを使って「品質改善」をアウトプットとする、と定義されています。これも非常に概念的なので、もう少し具体化して実プロジェクトに適用する必要があります。PYRAMIDでは、実行プロセスでは"デザインレビュー"を重要な手段としています。第2回表2の「プロジェクト管理票」および第3回表3の「スケジュール表」にデザインレビューとしてDR1〜DR3という項目が書かれています。DR1は基本設計書、DR2は詳細設計書、DR3はプログラミングに対するレビューという位置づけになっています。例えばDR1は基本設計書ができたところで、プロジェクトメンバーや有識者が集まって行うレビューです。このレビュー結果は、図2のような「レビュー報告書」に記載され、レビュー実施の有無は「プロジェクト管理票」で管理されます。
システム開発プロジェクトに関わった者であれば、誰でもレビューの大切さは身に沁みています。しかし、スケジュールに追われ、ついついおろそかになってしまうものがレビューでもあります。そのためPYRAMIDではレビュー実施を必須のマイルストーンとし、「レビュー報告書」と「プロジェクト管理票」でその実施をきちんとフォローするようにしているのです（Q2）。
|
図2：レビュー報告書
（画像をクリックするとEXCELファイルをダウンロードできます。/26.5KB）
|
 レビューを3段階で行う
レビューには自分自身で行う単独レビュー、メンバーが集まって行う内部レビュー、ユーザーも交えて行うユーザーレビューがあります。確かに手間はかかるのですが、この3段階のレビューを順番に行えば、かなり品質は良くなります。できるだけ手間を惜しまずに徹底するようにしてください。
特に単独レビューはおろそかになりやすいので注意してください。文章を書く上でも「推敲」という作業があります。書いた後で見直しを行うという簡単なことなのですが、やるかやらないかでは出来栄えが大きく異なります。単独レビューが不十分なものを内部レビューに提示したら、みんなに袋叩きに合うというような厳しい姿勢を示すようにしてください。
また、ユーザーレビューも「何も言われないことが是」ではありません。ユーザーが面倒くさがったとしても、できるだけ丁寧に説明して問題点を見つけ出してください。後から不都合を指摘されるくらいなら、最初の段階で手直しした方がずっと影響が少ないのです。
|
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。
常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。
国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。
|
|
|
|
|
|
