プロジェクト管理

システム開発において「効果的なドキュメントレビューができない。」という悩みを持つプロジェクトマネージャ、品質管理者やエンジニアは少なくない。そこにはドキュメントレビューに対する勘違いや誤解などがある。ダメ！レビューに良くみられる５つの勘違いとその解決策を紹介！

システムとの関わりを持つ組織を切り離して考えることはできない。目的やビジョンの策定に始まり、要件定義や要求仕様の作成、運用試験、実用展開とあらゆる段階において、組織的なリスクが存在する。ＩＴのあるべき姿に組織を導く能力を、ＩＴガバナンスという。

近年は、ＩＴの高度化・複雑化によりシステム構築における技術的リスクが高くなっている。かつての汎用機だけの世界に比べると、パソコンやＵＮＩＸが混在し、それらがネットワークでつながれている。また、搭載されるソフトウェアも、さまざまなベンダのものが混在している。

正しく認識するのも、誤認するのも全ては「人」。コンピュータに誤認させているのも、やはり「人」が誤認し、誤認にもとづいて指示をしているからにほかならない。システム構築が、極めて労働集約的な作業である以上、「人」は、大きなリスク要因である。

システム構築は、認識に始まり認識に終わる。いろんな段階で、認識を誤る、勘違いするというリスクがある。目的を誤認する。要件を誤認する。要求事項を誤認する。伝える相手を誤認する。聞く相手を誤認する。進捗状況を誤認する。問題の本質を誤認する。

ドキュメントレビューにおける設計書のチェックポイントを紹介する。設計書の内容は技術的になるので、ある程度ＩＴに対する知識がないと難しいが、できれば設計レビューにも参加することを勧めする。早い段階で設計者の漏れや勘違いを是正でき、手戻りによるコストや期間を抑制できる

ソフトウェアの原価は、ほとんどが人工費であるので、生産量と生産性の合意が基本となる。ここでは、ファンクションポイント法による見積もりを前提に、チェックポイントを紹介する。

ドキュメントレビューでの仕様書の基本的なチェック項目を紹介するので参考にされたい。さらに、記載内容については前述の「質の高い仕様書の基準」や「分かりやすい表現」も合わせてチェックしていただきたい。

◆参加者は、役者・監督・スポンサ　稽古に参加するのは、役者だけでなく、監督やスポンサもいる。つまり、システムを利用する業務担当者だけでなく、職制の長や経営層なども参加して、それぞれの立場からチェックするのが理想だ。役者である、担当者は、画面...

ウォークスルーで入出力情報を具体的にイメージするために、使用する画面や帳票のスケッチは、できるだけ具体性のあるものが良い。単に枠だけの画面や帳票のスケッチではなく、実際に近いデータも表示する。