
第26回 文書ドリブン開発 詳細設計文書編
アクセンチュア・テクノロジー・ソリューションズ
マネジャー 宮本和洋
2009/7/10
| 開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。 |
システム開発プロジェクトで作成される文書にフォーカスしての連載の第4回です。今回は詳細設計文書について考えたいと思います。特に詳細設計文書のレビュー者の視点にスコープすることで、「指摘される個所が少ない」詳細設計文書の作成ができるようになることを目指します。なお、以下の記述はあくまで筆者の私見であることをあらかじめおことわりしておきます。
■レビュー者としての特殊スキル
先日同僚と詳細設計文書のレビューというテーマについて話をしました。彼は「レビューをした際に設計の怪しい部分とそうでない部分が感覚的に識別できる」といっていました。実はわたしも不思議なことに、詳細設計文書を斜め読みしただけで、設計のバグや実装上で問題になりそうな部分が感覚的につかみ取れることがよくあります。「どうしてだろうね?」ということで話題になりましたが、結局明確な理由というものは分かりませんでした。誰に教えられたのでもなく、詳細設計文書をざっと眺めたときに、瞬時に設計の怪しい個所が天啓のように見えてくるのです。ほかのSEにも同じ話をしたところ、やはり数人が同じような特技(?)を持っているようでした。
わたし自身もこの特技がいつどうやって身に付いたものなのかはうまく説明できないのですが、どうやら自分なりにレビュー時の視点があることに気が付きました。わたしが詳細設計文書のレビューをする場合、まずわたしなりの設計の仮説を立て、それと実際に書かれている内容との整合性を検証するというスタンスでレビューに臨んでいます。また、プログラマとしての長い経験も積んできているため、詳細設計文書を読んだプログラマが誤解しやすい点に注意することもできます。それ以外にも、詳細設計者の持っていないようなシステムに関する業務的な知識や実装方式の良しあしの知識、関連する成果物に関する知識なども総動員してレビューに臨んでいます。
レビュー作業とはレビュー者の知識や仮説とレビュー対象物との照らし合わせであると考えています。レビュー者(特に上長)は過去の失敗や経験を掘り起こし、プロジェクトの状況や規約との照らし合わせをしながらレビュー作業に臨んでいます。いつも「レビューで指摘される個所が多い」と落ち込んでいるあなたも、今回の記事を読んでいただき、少し高い視点から自分の成果物を見直せるようになってもらいたいと思います。
■プログラマ視点でのレビュー
詳細設計文書を作成するに当たって誰もが一度はぶつかる壁です。特に初めて詳細設計文書を作成する若手が一番悩む部分がここかと思います。しかし実はベテランのSEであっても悩むのです。「勘と経験」によってレベル感が作られていき、気付けばさまざまなレベル感の詳細設計文書が出来上がってしまうことが多々あります。そこで、レベル感に対する明確な考え方を示したいと思います。答えはわたしの連載で何度も示しているV-モデルにあります(図1)。
![]() |
| 図1 V-モデル |
このV-モデルを見ると単体テストは詳細設計文書をインプットにして作成されることが分かると思います。もしあなたが単体テストの仕様書をプログラムコードから起こしているとしたらそれは間違いです。もしも誤りのあるプログラムコードからテスト仕様書を起こして単体テストを実行した場合、仮に動作結果が「書かれたとおりに動いた」としてもそれは「正しい結果」とはなりません。単体テスト仕様書とは本来は詳細設計文書をベースとして書かれるべきものなのです。
テスト技法を大きく分けるとブラックボックステストとホワイトボックステストに分類できますが、このホワイトボックステストのテスト仕様書を書けるようなレベル感が詳細設計文書の目指すべきレベル感だと理解してください。記述レベルが細かすぎるような気がしますが、このレベルまで落ちていない詳細設計文書を渡されたプログラマの立場になってみてください。恐らく仕様が漠然としすぎていて「あの場合は?」「この場合は?」という疑問ばかりが生じる結果になると思います。
レビュー者は自分自身がプログラマとしての視点で詳細設計文書をレビューします。そのため記述にあいまいな部分がないか、単体テスト仕様書が書けるレベルになっているかという視点でレビューをしているのです。
| 管理者視点でのレビュー | |
| » @IT自分戦略研究所 トップページへ |
システム開発プロジェクトの現場から バックナンバー
- 第1回 試行錯誤で分かったスパゲッティコード撃退法
- 第2回 セットアップ全国行脚で九州弁に大苦戦
- 第3回 未経験のデータベース構築に挑戦
- 第4回 定まらない要件、ユーザーからのむちゃな要求
- 第5回 メンバーとの仕様打ち合わせは海を越えて
- 第6回 専門用語で「カッコよく」話すのは簡単だけど
- 第7回 「できるか!」な設計書に、どう立ち向かう?
- 第8回 初めてのトラブル対応。これで直ると思ったのに!
- 第9回 この案件、ぜひ新しいテクノロジでやりましょう!
- 第10回 3プロジェクト同時にリード! どう乗り切る?
- 第11回 オフショアなんて、怖くない
- 第12回 障害対応とチューニングの危うい関係
- 第13回 最強チームで挑んだ、「40時間でデータ移行」の壁
- 第14回 運用って、あまりいいイメージはなかったけれど
- 第15回 「バッファ込み」の工数がスケジュール遅延の原因
- 第16回 大規模プロジェクトでは「同じ言葉を、同じ意味で」
- 第17回 現場デビューのお供はビジュアル多用の報告書
- 第18回 1人チームで悩む新人。「この作業って意味あるの?」
- 第19回 新人、アーキテクチャチームで「運命の出会い」
- 第20回 新人(3年目)、先輩デビューで「最悪の振る舞い」
- 第21回 新人、集合研修で「伝説」を作る
- 第22回 新人(3年目)、プロジェクトで「忍耐」を学ぶ
- 第23回 本当は楽しいドキュメント作成
- 第24回 基本設計文書の質を下げる「4つの心理バイアス」
- 第25回 文書ドリブン開発 DB設計文書編
- 第26回 文書ドリブン開発 詳細設計文書編
- 第27回 文書ドリブン開発 テスト文書編
| 【転職体験談】「もっと多くのユーザーに使って欲しい」⇒ mixiへの転職に成功! 8年間のSIer生活で得た経験とスキルを生かして転職活動。評価のポイントはどこ? |
| 【経営戦略】⇒「いつか勉強しよう」ではなく「いまこそ勉強すべき」スキル 50%のユーザー企業が「戦略を立案できるIT技術者」と仕事をしたがっている |
| 気になる「社会人大学院」という選択肢 仕事との両立は本当に可能? 独学とは何が違う? 実際の学生・卒業生6人に聞いた |
|
|
| 1日1問、模擬試験問題をメールで届けます | |
| ITスキル研修4000件、最新情報の検索できます |
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
・ケ・ュ・チマツ、クヲオ貍シ・ケ・ン・・オ。シ
- - PR -
お勧め求人情報
| ◆クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 New! |
||
| ◆気になる社会人大学院。興味はあるけど仕 事と両立可能?実際に通った6人に聞いた |
||
|
**先週の人気講座ランキング**
〜CCNA編〜
ITトレメ・今日の問題
基本情報技術者試験
エンドユーザーヘの障害対応窓口としてヘルプデスクを設置した。報告を受けた障害の根本的な原因は不明であるが、応急処置を必要としているとき、ヘルプデスクが対応する順番として、最も適切なものはどれか。<13年秋FE問57>







IE9、HTML5やCSS3、SVG対応を大幅強化へ