意図が伝わる設計書作成の心得【第4回】
「仕様書」は，設計者とプログラマをつなぐ重要なコミュニケーション・ツールだ。それゆえ，安易な書き方をすると問題を起こす。よく議論されるのは，「仕様書の内容はどこまで詳しく書くのが適当か？」という点だろう。過剰品質を避け，効率的に書きたいところだが，きちんと意図が伝わることが大前提である。二つの実例を通して，そのキー・ポイントを紹介する。 今回から，題材を「仕様書」に移して設計書作成の心得を紹介していこう。 前回までは，ユーザーからの要望聴取を基に作成する基本設計書を題材として，設計者とユーザーとのコミュニケーションを軸に展開してきた。これに対し，今回から取り上げる「仕様書」は，基本設計書を基にシステムを実装するプログラマやSEに対して，より具体的なシステムの詳細を伝える設計書である（図1）。 このような設計書は「詳細設計書」や「プログラム仕様書」など，様々な名前で呼ばれていることと思う。ま
意図が伝わる設計書作成の心得【第3回】
効率よく，ユーザーと必要十分な打ち合わせをしたつもりでも，基本設計書に大きな“抜け”が生じることがある。システムの目玉機能ばかりに目を奪われたり，設計者が補って考えるべきところで手を抜いたりするためだ。設計書の“抜け”がどうして生まれるのか，それを防ぐにはどうすればよいかを，よく起こりがちな二つの実例を通して考えてみたい。 いざ基本設計書をレビューしてみると，システムのある部分に関する重要事項がすっぽりと抜け落ちていた――。 このような話は，システム開発の現場でしばしば耳にするのではないだろうか。図1のように，システムの構築に欠かせない重要な事項が，なぜかユーザーからも設計者からも指摘されないことがあるのだ（あるいは指摘されながらも議論が不十分なことがある）。こうした状況で基本設計書を作成しても，その通りに作るとシステムは意図通りに動かない。 問題が表面化すると，基本設計書の“抜け”に対す
Part 2 失敗しないCMS導入ワークフロー：ヒアリング、プランニング | 成功するCMS導入の必須ノウハウ
失敗しないCMS導入ワークフロー 多数の導入経験で磨かれた手順と設計書 ページではなく“コンテンツ”を管理前置きはこのくらいにして、CMS導入に関する流れを説明しよう。スリーイントでは、CMS導入において以下のようなワークフローを使用している。これはCMS導入が“システム構築”という面を持つ一方で、システム系とはまったく関係ない“コンテンツ管理という”面を持っている非常に厄介な仕事だからだ。順序だててきちんと進めなければ、成功し得ないプロジェクトだといえるだろう。 CMSが単にウェブサイトを管理するものだと考えているならば、このプロセスは必要ないのかもしれない。なぜならば、現状のウェブサイトを管理しているのはウェブマスターであり、ウェブサイトについてはほぼすべてを熟知しているからだ。システムを構築するベンダーとウェブマスターとの間で設計をして構築すればいいだろう。しかし、これによって何が構
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「うちの部下は自発的に仕事をしない」 この悩みに答える（後編）：NBonline(日経ビジネス オンライン)
