ドキュメントレビューに役立つ40のチェックポイント：企業システム戦略の基礎知識（14）（3/3 ページ）

[青島 弘幸，＠IT]

設計書のチェックリスト

　設計書の内容は技術的になるので、ある程度ITに対する知識がないと難しいが、できれば設計レビューにも参加することを勧めする。

　早い段階で、以下のチェック項目を確認しておくことで、設計者の勘違いなどを早期に是正できる。これらが運用試験などの後工程で発覚し、後戻りや繰り返しを重ねるよりは、コストや期間を抑制できる。

（1）仕様書の要求事項との追跡性が確保されているか
　仕様書の要求事項が、確実に設計に反映されていることを追跡しやすいように記述されていること。例えば、仕様書の記載項目のページ番号や章・節と、設計事項との対応リストなど。

（2）設計手法やフレームワークは、明確か
　使用している設計手法やフレームワークが示され、その選択理由が明確であること。

（3）アーキテクチャが論理的に説明できるか
　アーキテクチャについて、なぜ、それが最善の方式であるのか明確かつ、論理的に説明できること。技術的な説明内容の理解や評価が重要ではなく、しっかりとした説明がなされるかどうかが重要だ。「なぜ、を5回繰り返し」徹底的に根拠を突っ込みたい。

（4）複数選択肢を検討のうえ、妥当な決定を行っているか
　技術などを選択するに当たり、代替案を2つ以上比較検討していること。その結果として、提案が妥当であること。

（5）設計上持ち込まれた制約事項などを確認したか
　設計上持ち込んだ、制約事項などの確認。例えば、最大処理件数やデータ容量など。設計者が、勝手に持ち込んだ制約事項が、運用保守時の足かせになることがある。なぜ、その制約事項を持ち込んだのか、根拠をしっかりと確認しておく必要がある。

（6）データ項目のけた数、属性、識別キーなどを確認したか
　データ項目のけた数、属性、識別キーなどの確認。特に識別キーのけた数が1けたでも違っていると後から大変なことになる。

（7）障害対策やバックアップ機能を確認したか
　障害対策やバックアップ機能の確認。想定している障害や回復時間が要求に合致していなかったり、いざというときに役に立たないようでは意味がない。

（8）エンドユーザーにとっての使い勝手への配慮があるか
　ユーザービリティやアクセシビリティ、ユニバーサルデザインを考慮していること。

---

　ところで、実際のレビューでよくあるのが、ドキュメントの記述内容に対する説明と質疑応答で時間切れになって、肝心の問題発見までいかないケースだ。また、その場で解決の議論を始めてしまい時間切れとなってすべての問題を洗い出すことができないというケースもある。

　レビューを行うときには、必ず事前にドキュメントを一読しておくこと、問題発見を第一とし解決策は別途検討会を開催するのがミソだ。

　次回は、企業システム戦略の遂行に潜む、4つのリスクについて解説する。

著者紹介

▼著者名　青島 弘幸（あおしま ひろゆき）

「企業システム戦略家」（企業システム戦略研究会代表）

日本システムアナリスト協会正会員、経済産業省認定　高度情報処理技術者（システムアナリスト、プロジェクトマネージャ、システム監査技術者）

大手製造業のシステム部門にて、20年以上、生産管理システムを中心に多数のシステム開発・保守を手掛けるとともに、システム開発標準策定、ファンクションポイント法による見積もり基準の策定、汎用ソフトウェア部品の開発など「最小の投資で最大の効果を得、会社を強くする」システム戦略の研究・実践に一貫して取り組んでいる。趣味は、乗馬、空手道、速読。

「システム構築駆け込み寺」を運営している。

メールアドレス：[e-mail]