![[ARK-Web SandBox]](image/sandbox.gif "[ARK-Web SandBox]")
- バックアップ一覧
- ソース を表示
- 要求仕様化手法のWikiエントリー記述への応用 は削除されています。
- 1 (2006-07-20 (木) 13:38:02)
- 2 (2006-07-20 (木) 16:43:45)
- 3 (2006-07-21 (金) 14:47:29)
- 4 (2006-07-21 (金) 16:35:36)
- 5 (2006-07-21 (金) 18:23:34)
目次 †
このドキュメントは？ †
要求を仕様に分割して整理する要求仕様化手法の練習がてら、Wiki(またはブログ)に週一回単位でエントリーを投入することを一つの要求とみなして（実際会社から自分に投げられた要求には変わりありません）これを仕様として具体化してゆくことで、要求の実現性を高め、要求仕様化のスキルアップもはかる為に記載したドキュメントです。
自身の習熟もさることながら、要求仕様化手法の周知も目的に兼ねています。
要求とは？仕様とは？ †
後の混乱を避けるためにも、要求と仕様の定義、そしてその違いを明確にしておきます。
- 要求
- 依頼者が作業者に対して、作って欲しいこと、達成して欲しいことをあらわしたもの。何(What)を望んでいるのかを明示する。モレ、重複を防ぐために要求には必ず時間的、空間的、機能的な範囲をもたせる。また、範囲そのものがブレることを防ぐために必ず理由も定義する。
例）
要求：３ヶ月間で月次売り上げ1.2倍増を達成する
理由：３ヶ月後に四半期の決算発表があり、株主に対して業績向上をアピールする必要があるため - 仕様
- 要求を実現するために抽出される具体的な機能、行動、措置。要求をいかに(How)実現するかを明示する。仕様は要求の範囲を出ないこと、そして要求の範囲の隙間をモレなく埋めるものである必要がある。また、仕様は検証可能性を持つ。これは仕様とは作ること、達成することに関する関係者が記載内容に関してSpecify（特定）できるように表現されるものであり、特定できるとは検証可能であるということで担保されるため。
要求の定義 †
今回の直接指示された要求、理由は下記の通りです。
| 要求 | Wiki（またはブログ）に週１ペースでエントリーを書く |
| 理由 | Wiki（またはブログ）に記事を書くことは、営業上も非常にコストパフォーマンスの高いActionであり、また、自分達のやれるコト、興味を持っているコトを示すことで、これに共感してくれる顧客と仕事ができる可能性が高まるため |
しかし、この要求が外界との間に持つ境界線がこのままではまだ曖昧であり、また、この要求が含む範囲自体がまだまだ大きいため、仕様抽出時に仕様が拡散してモレてしまう可能性が高いです。そこで、この要求の外界との境界線の特定と分割、階層化を実行します。
要求の境界線の特定 †
要求とそれを取り巻く境界、外界とのやりとりを明示するためにコンテキスト図（概要図）を使って表現し、要求の「内」と「外」を明確にします。
&ref(): File not found: "要求仕様化要求範囲.jpg" at page "要求仕様化手法のWikiエントリー記述への応用";
こうすることで、今回の要求にはWikiそのものの設置、Wikiデザインの適応・カスタマイズは含まれず、また、この要求の出力が別の要求（効果測定）の入力になることもわかります。要求（効果測定）で得た閲覧者、潜在顧客等からのフィードバックは要求（Wikiを書く）にフィードバックされる様子も明示されます。要求に課せられた範囲が視覚的に明確になることで、下記に続く要求の階層化や仕様の抽出時にぶれやモレを防ぐことに寄与します。
要求の分割と階層化 †
要求の分割と階層化を実施するためには紙上に要求全体を示す領域を表現し、それを分割する形で一段階層を降りた要求を表現する方法があります。
今回の要求を分割してみます。
厳密には紙上に拘る必要はなく（実際上記でもPPTで表現した後、画像化しています）、Excelなどのテーブル形式を利用した表現でも問題ありませんが、最初にざっと分解する際には手書きで紙上で作業するのが分割作業そのものに注力できますし、視覚的にも要求の範囲の間隔をつかみやすいのでオススメです。
分割、階層化したといっても要求に変わりはありませんので、各要求には理由が記述できます。実際には分割、階層化する中で理由を書くことが困難になっていくのが一般的です。が、理由を安易に省略するようにすると、安易に階層化するようになっていき、要求の範囲のぶれ、重複、抜けを発生させてしまうので、理由は必ず記述するように心がけます（ただし、どうしても無理なケースにおいては空欄にしておきます）。理由を各要求に対して書くためにはテーブル形式の方が都合がよいので、テーブル形式にまとめなおします。
| 要求 | WIKI001 | Wiki（またはブログ）に週１ペースでエントリーを書く | |
| 理由 | Wiki（またはブログ)に記事を書くことは、営業上も非常にコストパフォーマンスの高いActionであり、また、自分達のやれるコト、興味を持っているコトを示すことで、これに共感してくれる顧客と仕事ができる可能性が高まるため | ||
| 要求 | WIKI001.1 | Wikiに書くテーマを見つける | |
| 理由 | あらゆるエントリはテーマを伝えるために存在するため。また、テーマを決めない状態では調査、記述にもゴールが見えず時間が必要以上にかかってしまうため。 | ||
| 要求 | WIKI001.2 | 調査、エントリー記述の時間を１週間の中に定期的に確保する | |
| 理由 | 定期的なエントリーの提供を行うためには、定期的な調査、記述の時間が必要であり、その時間は明示的にとらなければ日々の業務にとって変わられてしまうから | ||
| 要求 | WIKI001.3 | エントリーの段落分け、構成を考える | |
| 理由 | 段落に分割することで、段落単位の記述が可能になり、まとまった時間の確保ができなくても記述が可能になる可能性が高まるから。また、構成を考えてエントリ全体の流れをまず把握することで、不必要な情報収集を避けられ、調査、執筆時間の見積りも行いやすくなるから。 | ||
| 要求 | WIKI001.4 | テーマに関する調査、自分なりの検証を行う | |
| 理由 | 自分は社のWiki/ブログでは技術的な動向を伝えたり、取得した知見、検証結果を提示することによって自社の技術力、関心度、アンテナの高さをアピールすることで営業に寄与することに求められているという理解から、技術動向、興味のある技術周りの件に関する学習、検証が求められていると判断されるから | ||
| 要求 | WIKI001.5 | 文章を書く | |
| 理由 | |||
| 要求 | WIKI001.6 | 必要な図、表を用意する | |
| 理由 | |||
| 要求 | WIKI001.7 | 書いたエントリーをアナウンスする | |
| 理由 | 自社Wiki（ブログ）に記載するエントリーは自己の研鑽、社内での知見の共有だけではなく、潜在顧客へのアピールも兼ねているため、適切なアナウンスが必要 | ||
「文章を書く」、「必要な図、表を用意する」に関しては理由が書けませんでした・・・降参です。これらは要求に配置するのではなく、最上位の要求「Wiki（またはブログ）に週１ペースでエントリーを書く」に対する仕様と捉えるべきだったかもしれません。
要求から仕様を導く †
各要求から仕様（今回のケースでは措置の方が適当かもしれません）を抽出します。
階層化した要求から各々の理由をふまえながら抽出することで、各仕様（措置）が要求の範囲を逸脱したり、逆にモレる可能性を減らします。
WIKI001.1 Wikiに書くテーマを見つける †
- 理由
- あらゆるエントリはテーマを伝えるために存在するため。また、テーマを決めない状態では調査、記述にもゴールが見えず時間が必要以上にかかってしまうため。
| 仕様No | 仕様(措置) |
| WIKI001.1-1 | 自分が興味を持っていることを紙上に抜き出してリストする |
| WIKI001.1-2 | 自分が携わりたいと思っている仕事の内容、およびその仕事にかかわるキーワードを抜き出してリストする |
| WIKI001.1-3 | 業務の必要から調査した内容をテキストファイル上にメモし、ログにしておく |
| WIKI001.1-4 | ふと気づいたアイデアなどもテキストファイル上にメモし、ログにしておく |
| WIKI001.1-5 | 社内に流れるメール（弊社には企画ディレクターの中野がその日にネットで気になった記事やエントリーを流すNewsRoundupという社内メールマガジン（？）があります）から気になった記事や内容をメモし、ログにしておく |
| WIKI001.1-6 | リスト、メモ、ログを分類、整理して１行で表現されたテーマを抽出する |
WIKI001.2 調査、エントリー記述の時間を１週間の中に定期的に確保する †
- 理由
- 定期的なエントリーの提供を行うためには、定期的な調査、記述の時間が必要であり、その時間は明示的にとらなければ日々の業務にとって変わられてしまうから
| 仕様No | 仕様(措置) |
| WIKI001.2-1 | エントリーを記述するために必要な作業を分解する（このWikiエントリーを書く作業がこれを満たす） |
| WIKI001.2-2 | 次週に記述するテーマに関して調査する時間を金曜日に次週のスケジュール上に確保する |
| WIKI001.2-3 | 次週に記述するテーマに関してエントリーを記述する時間を金曜日に次週のスケジュール上に確保する |
| WIKI001.2-4 | 社内のスケジュールソフト上に確保したスケジュールを明示する |
WIKI001.3 エントリーの段落分け、構成を考える †
- 理由
- 段落に分割することで、段落単位の記述が可能になり、まとまった時間の確保ができなくても記述が可能になる可能性が高まるから。また、構成を考えてエントリ全体の流れをまず把握することで、不必要な情報収集を避けられ、調査、執筆時間の見積りも行いやすくなるから。
| 仕様No | 仕様(措置) |
| WIKI001.3-1 | テーマを分解して階層化する |
| WIKI001.3-2 | テーマに対するまとめを記載する |
| WIKI001.3-3 | Wiki上に階層化したテーマを段落で表現する |
| WIKI001.3-4 | 各段落での主題を一行で表現する。必要な調査、図、表があればそれも記載する |
| WIKI001.3-5 | まとめを最後に配置する |
WIKI001.4 テーマに関する調査、自分なりの検証を行う †
- 理由
- 自分は社のWiki/ブログでは技術的な動向を伝えたり、取得した知見、検証結果を提示することによって自社の技術力、関心度、アンテナの高さをアピールすることで営業に寄与することに求められているという理解から、技術動向、興味のある技術周りの件に関する学習、検証が求められていると判断されるから
| 仕様No | 仕様(措置) |
WIKI001.5 文章を書く †
- 理由
| 仕様No | 仕様(措置) |
| WIKI001.5-1 | 語調を決定して、統一する |
| WIKI001.5-2 | 文章内で利用する用語の正式な記述を調べ統一する。（あれば）用語説明のページにその用語がエントリー内で最初に出てきた箇所からリンクを張る |
| WIKI001.5-3 | 各段落内を埋めていく形で実際に文章を書く |
WIKI001.6 必要な図、表を用意する †
- 理由
| 仕様No | 仕様(措置) |
WIKI001.7 書いたエントリーをアナウンスする †
- 理由
- 自社Wiki（ブログ）に記載するエントリーは自己の研鑽、社内での知見の共有だけではなく、潜在顧客へのアピールも兼ねているため、適切なアナウンスが必要
| 仕様No | 仕様(措置) |
| WIKI001.7-1 | (Wikiの場合、つまりここの場合)blikiフッタをつけてトップページから参照できるようにする |
| WIKI001.7-2 | (ブログの場合)社内MLに記載した旨をアナウンスして、社内の公開審査にかける |
まとめ †
