1. プログラマが欲しい仕様書と
は
東京開発グループ
リードソフトウェアエンジニア
牧野 克俊

2. ソフトウェア工学って知ってます
か？

3. ソフトウェア工学とは
• ソフトウェアの開発・運用・保守に
ついて体系化、分析、研究する分野
• 高度で安全なソフトウェアを短期間
で設計するための研究を行う

4. • 知っていると役に立つのは
–ソフトウェア開発工程
–ソフトウェア開発方法論

5. • 知っていると役に立つのは
–ソフトウェア開発工程
–ソフトウェア開発方法論

6. ソフトウェアの開発工程

7. ソフトウェアの開発工程
• 要求分析
• 設計
• コーディング
• テスト
• 運用・保守

8. ソフトウェアの開発工程
• 要求分析
– ソフトウェアがどのような機能を持つべきか
を検討し文書化する。

9. ソフトウェアの開発工程
• 設計
– 機能がソフトウェアとしてどのように実装さ
れるべきかを検討し仕様化する。

10. ソフトウェアの開発工程
• コーディング
– 仕様に従ってプログラムを作成する。

11. ソフトウェアの開発工程
• テスト
– 作成されたプログラムが機能的な要求を満た
していることを実証する。

12. ソフトウェアの開発工程
• 運用・保守
– ソフトウェアを使用したり、新たな要求に応
じて機能を追加・変更する。

13. 一般的に必要とされるドキュメ
ント

14. 必要とされるドキュメント
• 企画書
• 要求仕様書
• 設計書
• 機能仕様書
• 詳細仕様書
• テスト仕様書
• 運用マニュアル

15. ドキュメントはなぜ必要か？

16. ドキュメントはなぜ必要か？
• 効率よく開発するため
– 情報共有するため
– 思考をトラッキングできるようにする
ため
– 質問を減らすため

17. コラム：情報共有とは
• 「教育の情報化と情報セキュリ
ティ」より
– 機密性(confidentiality)
• 認可されたものだけが情報にアクセスできること
– 完全性(integrity)
• 正確であること、及び完全であることを維持する
こと
– 可用性(availability)
• 許可されたものが必要なときに情報にアクセスす
ることが可能であること

18. コラム：情報共有とは
• 必要な人がいつでも自由に、正しい
情報を取得できるようにすること

19. ゲーム制作に最低限必要なドキュメント
は？

20. 最低限必要なドキュメント
1. 企画書
2. 機能仕様書
3. 運用マニュアル

21. 1. 企画書
• タイトル、プラットフォーム、コンセプ
ト、売り、ゲームシステム、キャラク
ターなどの説明
• １枚目からラストにかけて、流しても読
めるような企画書が望ましい
• 一番重要なのは『何かが面白い』『遊ん
でみたい』『売れそう』という３点

22. 2. 機能仕様書
• ユーザの観点からゲームがどのように動
くか記述する
• どのように実装されるかは問題にしない
• 機能を中心としており、用語の定義と
か、UI とかいったものの仕様も定める

23. 3. 運用マニュアル
• システムの構築方法
• 操作方法や注意点
• トラブル発生時の対処法

24. プログラマが欲しい仕様書はど
れ？

25. 機能仕様書です！

26. プログラマが仕様書を欲しがる理由
は？

27. ソフトウェアデザインをするた
め！

28. ソフトウェアデザインとは
• プログラムを機能単位に分割し、構
造化したり処理の流れを決める

29. コラム：良いプログラマの生態
• リファクタリングは苦にならないが、仕
様変更による作りなおしは嫌がる
• 心配性もしくは細かいことを気にする

30. どんな機能仕様書を書けばいい
か？

31. 最低限必要な項目
• シナリオ
• 対象外
• 概要
• 詳細
• 未解決の問題
• 用語解説

32. シナリオ
• ターゲットは？
• どのような状況で使うのか？
• どのように使うか？

33. 対象外
• 明らかにオーバースペックなこと
• 今のバージョンでやらないこと
• 対象外のプラットフォーム

34. 概要
• 一覧性が重要
• 全体像を把握させる
– フローチャート
– 関係性

35. 詳細
• 想定される状況を全て書く
• 何がエラーになるか全て書く
• 全てのエラーに対してどう処理する
か書く

36. 未解決の問題
• 何が未解決か残す
• これが残っているうちはプログラマ
にコードを書かせない

37. 用語解説
• 一般的な単語でもドキュメント中で
の意味を書く

38. 仕様書のアンチパターン
1. 同一レイヤの事を書いてるのに人によってフォーマットが
ばらばら
2. 一見似ているがよく見ると若干違う情報があちこちにある
3. できないこと、やらなくていいことが書かれていない
4. 単語、言い回しが統一されていない
5. 値の範囲が書かれていない、単位が統一されていない
6. 実現すべきことが書かれていないのに詳細なロジックだけ
書いてある
7. 語尾が「～したい」で終わっている
8. 変更があっても更新されない
9. プログラマに相談、確認がされていないことがある
10. わからないことがあったら直接聞いてくださいと書いてあ
る

39. 1. 同一レイヤの事を書いてるのに人に
よってフォーマットがばらばら
• 絶対に必要な項目を抽出する作業
が必要
–テンプレートを作りましょう

40. 2. 一見似ているがよく見ると若干違う情報
があちこちにある
• 仕様書の構造を見直しましょう
–共通部分を切り分ける
–機能の関係性が分かるように

41. 3. できないこと、やらなくていいことが書
かれていない
• これらはプログラムの設計に影響す
る
– どんなエラーが起こり得るか？
– その時どうするか？
– 何が必要ないか？

42. 4. 単語、言い回しが統一されていない
• 用語集は必須
– ないと絶対誤解します！
• 言い切り言葉でしめる
–例
• ☓ ザコをすべて倒すことで、ボスと戦うことがで
きます（できるようになります）
• ○ザコを全て倒すと、ボス戦に移行します

43. 5. 値の範囲が書かれていない、単位が統一
されていない
• 値には必ず取り得る範囲を決める
– 無限は実現不可能
• 精度を気にする
– [0－1000] の値を取る時、小数点何位まで比較
するか
• 数値を書く場合は常に単位を書く
– 秒なのかミリ秒なのかはっきりと

44. 6. 実現すべきことが書かれていないのに詳
細なロジックだけ書いてある
• プログラマが知りたいのは実現すべきこ
と
– ロジックはプログラマに考えさせるのが
Better

45. 7. 語尾が「～したい」で終わっている
• 仕様書には実装すべきことだけを書
く
– ボリュームの調整はスケジュールを組
む段階でする

46. 8. 変更があっても更新されない
• こまめに更新
• 相談したら即反映

47. 9. プログラマに相談、確認がされていない
ことがある
• 仕様書を書いたら絶対プログラマの
チェックを入れる
– フローがおかしくないか
– データ構造に無駄がないか
– ロジックがもっとシンプルにならないか

48. 10. わからないことがあったら直接聞いて
くださいと書いてある
• これは記述が足りないということ
• 仕様書は誰が読んでも誤解なく理解
できるように書くべき