文書ドリブン開発 詳細設計文書編 - @IT自分戦略研究所
@IT[=>]
@IT CORE[=>]
@IT情報マネジメント[=>]
@IT MONOist[=>]
@IT自分戦略研究所[=>]
JOB@IT[=>]
ITmedia[=>]
TechTarget[=>]
誠[=>]
{img:アットマーク・アイティ ITエキスパートのための成長支援メディア}[=>]
@IT総合トップ[=>]
> 自分戦略研究所[=>]
> スキル創造研究室[=>]
> 文書ドリブン開発 詳細設計文書編 自分戦略研究所[=>]
| 自分戦略研究室[=>]
| キャリア実現研究室[=>]
| スキル創造研究室[=>]
| 生活向上研究室[=>]
| 組み込みキャリア研究室[=>]
| コミュニティ活動支援室[=>]
| エンジニアライフ[=>]
| IT業界就職ラボ[=>]
| {img:スラッシュドット}[=>]
{img:はてなブックマーク}[=>]
{img:Yahoo!ブックマークに登録}[=>]
{img:印刷}[=>]
{img:システム開発プロジェクトの現場から} 第26回 文書ドリブン開発 詳細設計文書編
アクセンチュア・テクノロジー・ソリューションズ[=>]
マネジャー 宮本和洋
2009/7/10 第25回[=>]
|1 2[=>]
|次のページ[=>]
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。 システム開発プロジェクトで作成される文書にフォーカスしての連載の第4回です。今回は詳細設計文書について考えたいと思います。特に詳細設計文書のレビュー者の視点にスコープすることで、「指摘される個所が少ない」詳細設計文書の作成ができるようになることを目指します。なお、以下の記述はあくまで筆者の私見であることをあらかじめおことわりしておきます。 ■レビュー者としての特殊スキル
先日同僚と詳細設計文書のレビューというテーマについて話をしました。彼は「レビューをした際に設計の怪しい部分とそうでない部分が感覚的に識別できる」といっていました。実はわたしも不思議なことに、詳細設計文書を斜め読みしただけで、設計のバグや実装上で問題になりそうな部分が感覚的につかみ取れることがよくあります。「どうしてだろうね?」ということで話題になりましたが、結局明確な理由というものは分かりませんでした。誰に教えられたのでもなく、詳細設計文書をざっと眺めたときに、瞬時に設計の怪しい個所が天啓のように見えてくるのです。ほかのSEにも同じ話をしたところ、やはり数人が同じような特技(?)を持っているようでした。 わたし自身もこの特技がいつどうやって身に付いたものなのかはうまく説明できないのですが、どうやら自分なりにレビュー時の視点があることに気が付きました。わたしが詳細設計文書のレビューをする場合、まずわたしなりの設計の仮説を立て、それと実際に書かれている内容との整合性を検証するというスタンスでレビューに臨んでいます。また、プログラマとしての長い経験も積んできているため、詳細設計文書を読んだプログラマが誤解しやすい点に注意することもできます。それ以外にも、詳細設計者の持っていないようなシステムに関する業務的な知識や実装方式の良しあしの知識、関連する成果物に関する知識なども総動員してレビューに臨んでいます。 レビュー作業とはレビュー者の知識や仮説とレビュー対象物との照らし合わせであると考えています。レビュー者(特に上長)は過去の失敗や経験を掘り起こし、プロジェクトの状況や規約との照らし合わせをしながらレビュー作業に臨んでいます。いつも「レビューで指摘される個所が多い」と落ち込んでいるあなたも、今回の記事を読んでいただき、少し高い視点から自分の成果物を見直せるようになってもらいたいと思います。 ■プログラマ視点でのレビュー
詳細設計文書を作成するに当たって誰もが一度はぶつかる壁です。特に初めて詳細設計文書を作成する若手が一番悩む部分がここかと思います。しかし実はベテランのSEであっても悩むのです。「勘と経験」によってレベル感が作られていき、気付けばさまざまなレベル感の詳細設計文書が出来上がってしまうことが多々あります。そこで、レベル感に対する明確な考え方を示したいと思います。答えはわたしの連載で何度も示しているV-モデルにあります(図1)。 図1 V-モデル このV-モデルを見ると単体テストは詳細設計文書をインプットにして作成されることが分かると思います。もし
■Next Page
・Full Browser
ja.abc-yoga.podzone.org | Contact