Specification creation

1. 今すぐ実践! 仕様書を充実させよう！
Let's Try！Enriched Specification creation!!

2. 仕様書と設計書の違い
Difference between specifications
and design documents

3. 仕様書とは
「何がしたいのか？」
「何を作るのか？」
について書かれたもの。
完成イメージ（結果）が書かれています
The specification is written about
"What do you want to do?" And
“What do you want to make?”
The completed image (result) is written

4. 設計書とは
「どうやって作るのか？」
について書かれたもの。
完成するまでの制作過程が書かれています。
The design document is
written about how to make it.
The production process until completion is
written.

5. わかりにくい仕様書の特徴
Obscure specifications

6. プレゼン用のパワポで作った資料
（企画書）しかない
There is only material (plan) made with
power point for presentation
こんな事がやりたい！など戦略的な狙いは伝わりますが、
どんなWebサービスやアプリを作りたいのか？具体的なイメージがわきません。
プレゼン用の資料はあくまで企画書なので、仕様書とは違います。
What kind of web services and
applications do you want to
create? I don't know the specific
image.
The presentation material is just a
plan, so it is different from the
specification.

7. 図やビジュアルがない
No image or visual
ミーティングで完成イメージを話したり、メール、チャットなどのテキストベースで説
明しても、図やビジュアルがないと伝わらないこともあります。
図やビジュアルを用意して解説すれば相手にはっきりとイメージを伝えることができま
す。
言葉の壁を乗り越えるためにも視覚的に訴えることが大切です。
Speaking of completed images
at meetings, text-based
explanations such as email and
chat, may not be communicated
without diagrams and visuals.

8. 完成イメージが違う
The completed image is different

9. 内容が大雑把すぎる
The contents are too rough
仕様書の段階で、不確定要素が残った状態で、あいまいなまま開発が進むと、明確にし
なかったことで認識の食い違いが発生します。
最初の段階で可能な限り要件を詰めることが大切です。
開発においてコミュニケーションコストと品質低下のリスクを削減するためには、最初
の段階から可能な限り要件を詰めておくことが大切です。
If development progresses
vaguely, there will be
discrepancies in recognition due
to lack of clarity.
It is important to fill in the
requirements as much as
possible from the first stage

11. わかりやすい仕様書の特徴
Easy-to-understand specifications

12. イメージが入っている
Contains an image
あらかじめ仕様書内にイメージ画像を挿入しておくと、サービスの目
指すべき方向性とビジュアル面のイメージ共有ができます。
完成イメージに近い画像を挿入しておけば、完成像が共有しやすくな
ります。
Share an image by inserting an
image into the specification.
Inserting an image close to the
completed image makes it easier
to share the completed image

13. 画面遷移図が具体的でわかりやすい
Screen transition diagram is concrete
and easy to understand
画面遷移図はリリース後のユーザーの行動・導線を把握するうえで重要な役割
を担っています。事前にユーザーの行動パターンや遷移するパターンをしっか
りと考えておけば、想定外のトラブルを起こりにくくすることができます。
The screen transition diagram plays an
important role in understanding the
user's behavior and lead after the release.
Unexpected trouble can be prevented.

14. シーケンス図が用意されている
Sequence diagram is prepared
シーケンス図は、システムの設計を視覚的に把握するために用いられるものです。
時間軸に沿ってクラス・オブジェクト間のやりとりを表現することができます。
ユーザーがどんなアクションをして、どんな動きをするのか、一連の流れを把握し
ておくことは非常に重要です。
The sequence diagram is used
to visually grasp the design of
the system.
It is very important to
understand the flow of what the
user is doing and how it moves.

15. 細かい部分の説明書きがある
There is a detailed explanation
文字制限数、ダイアログメッセージ、入力チェックなどユーザーに
表示する文言など、細かな部分まで仕様書に落とし込むことが大切
です。開発中のコミュニケーションコストの削減にもつながるので
、随時、確定している要素は仕様書に落とし込みましょう。
It is important to include in the
specification the details such as
the number of characters, dialog
messages, wording displayed to
the user, such as input check.

16. 開発方法をより良くする為に、
自分たちで考え、実験し、検証し、
改善していきましょう。
Think and experiment by yourself to
improve the development method.
Let's examine and improve.