![5. 値の範囲が書かれていない、単位が統一
されていない
? 値には必ず取り得る範囲を決める
– 無限は実現不可能
? 精度を気にする
– [0－1000] の値を取る時、小数点何位まで比較
するか
? 数値を書く場合は常に単位を書く
– 秒なのかミリ秒なのかはっきりと](https://image.slidesharecdn.com/random-111108024555-phpapp01/85/-43-320.jpg)
プログラマが欲しい仕様书とは
- 1. プログラマが欲しい仕様書と は 東京開発グループ リードソフトウェアエンジニア 牧野 克俊
- 2. ソフトウェア工学って知ってます か？
- 3. ソフトウェア工学とは ? ソフトウェアの開発?運用?保守に ついて体系化、分析、研究する分野 ? 高度で安全なソフトウェアを短期間 で設計するための研究を行う
- 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. わからないことがあったら直接聞いて くださいと書いてある ? これは記述が足りないということ ? 仕様書は誰が読んでも誤解なく理解 できるように書くべき