Successfully reported this slideshow.

プログラマが欲しい仕様書とは

310

Share

1 of 48
1 of 48

プログラマが欲しい仕様書とは

310

Share

Download to read offline

  1. 1. プログラマが欲しい仕様書と は 東京開発グループ リードソフトウェアエンジニア 牧野 克俊
  2. 2. ソフトウェア工学って知ってます か?
  3. 3. ソフトウェア工学とは • ソフトウェアの開発・運用・保守に ついて体系化、分析、研究する分野 • 高度で安全なソフトウェアを短期間 で設計するための研究を行う
  4. 4. • 知っていると役に立つのは –ソフトウェア開発工程 –ソフトウェア開発方法論
  5. 5. • 知っていると役に立つのは –ソフトウェア開発工程 –ソフトウェア開発方法論
  6. 6. ソフトウェアの開発工程
  7. 7. ソフトウェアの開発工程 • 要求分析 • 設計 • コーディング • テスト • 運用・保守
  8. 8. ソフトウェアの開発工程 • 要求分析 – ソフトウェアがどのような機能を持つべきか を検討し文書化する。
  9. 9. ソフトウェアの開発工程 • 設計 – 機能がソフトウェアとしてどのように実装さ れるべきかを検討し仕様化する。
  10. 10. ソフトウェアの開発工程 • コーディング – 仕様に従ってプログラムを作成する。
  11. 11. ソフトウェアの開発工程 • テスト – 作成されたプログラムが機能的な要求を満た していることを実証する。
  12. 12. ソフトウェアの開発工程 • 運用・保守 – ソフトウェアを使用したり、新たな要求に応 じて機能を追加・変更する。
  13. 13. 一般的に必要とされるドキュメ ント
  14. 14. 必要とされるドキュメント • 企画書 • 要求仕様書 • 設計書 • 機能仕様書 • 詳細仕様書 • テスト仕様書 • 運用マニュアル
  15. 15. ドキュメントはなぜ必要か?
  16. 16. ドキュメントはなぜ必要か? • 効率よく開発するため – 情報共有するため – 思考をトラッキングできるようにする ため – 質問を減らすため
  17. 17. コラム:情報共有とは • 「教育の情報化と情報セキュリ ティ」より – 機密性(confidentiality) • 認可されたものだけが情報にアクセスできること – 完全性(integrity) • 正確であること、及び完全であることを維持する こと – 可用性(availability) • 許可されたものが必要なときに情報にアクセスす ることが可能であること
  18. 18. コラム:情報共有とは • 必要な人がいつでも自由に、正しい 情報を取得できるようにすること
  19. 19. ゲーム制作に最低限必要なドキュメント は?
  20. 20. 最低限必要なドキュメント 1. 企画書 2. 機能仕様書 3. 運用マニュアル
  21. 21. 1. 企画書 • タイトル、プラットフォーム、コンセプ ト、売り、ゲームシステム、キャラク ターなどの説明 • 1枚目からラストにかけて、流しても読 めるような企画書が望ましい • 一番重要なのは『何かが面白い』『遊ん でみたい』『売れそう』という3点
  22. 22. 2. 機能仕様書 • ユーザの観点からゲームがどのように動 くか記述する • どのように実装されるかは問題にしない • 機能を中心としており、用語の定義と か、UI とかいったものの仕様も定める
  23. 23. 3. 運用マニュアル • システムの構築方法 • 操作方法や注意点 • トラブル発生時の対処法
  24. 24. プログラマが欲しい仕様書はど れ?
  25. 25. 機能仕様書です!
  26. 26. プログラマが仕様書を欲しがる理由 は?
  27. 27. ソフトウェアデザインをするた め!
  28. 28. ソフトウェアデザインとは • プログラムを機能単位に分割し、構 造化したり処理の流れを決める
  29. 29. コラム:良いプログラマの生態 • リファクタリングは苦にならないが、仕 様変更による作りなおしは嫌がる • 心配性もしくは細かいことを気にする
  30. 30. どんな機能仕様書を書けばいい か?
  31. 31. 最低限必要な項目 • シナリオ • 対象外 • 概要 • 詳細 • 未解決の問題 • 用語解説
  32. 32. シナリオ • ターゲットは? • どのような状況で使うのか? • どのように使うか?
  33. 33. 対象外 • 明らかにオーバースペックなこと • 今のバージョンでやらないこと • 対象外のプラットフォーム
  34. 34. 概要 • 一覧性が重要 • 全体像を把握させる – フローチャート – 関係性
  35. 35. 詳細 • 想定される状況を全て書く • 何がエラーになるか全て書く • 全てのエラーに対してどう処理する か書く
  36. 36. 未解決の問題 • 何が未解決か残す • これが残っているうちはプログラマ にコードを書かせない
  37. 37. 用語解説 • 一般的な単語でもドキュメント中で の意味を書く
  38. 38. 仕様書のアンチパターン 1. 同一レイヤの事を書いてるのに人によってフォーマットが ばらばら 2. 一見似ているがよく見ると若干違う情報があちこちにある 3. できないこと、やらなくていいことが書かれていない 4. 単語、言い回しが統一されていない 5. 値の範囲が書かれていない、単位が統一されていない 6. 実現すべきことが書かれていないのに詳細なロジックだけ 書いてある 7. 語尾が「~したい」で終わっている 8. 変更があっても更新されない 9. プログラマに相談、確認がされていないことがある 10. わからないことがあったら直接聞いてくださいと書いてあ る
  39. 39. 1. 同一レイヤの事を書いてるのに人に よってフォーマットがばらばら • 絶対に必要な項目を抽出する作業 が必要 –テンプレートを作りましょう
  40. 40. 2. 一見似ているがよく見ると若干違う情報 があちこちにある • 仕様書の構造を見直しましょう –共通部分を切り分ける –機能の関係性が分かるように
  41. 41. 3. できないこと、やらなくていいことが書 かれていない • これらはプログラムの設計に影響す る – どんなエラーが起こり得るか? – その時どうするか? – 何が必要ないか?
  42. 42. 4. 単語、言い回しが統一されていない • 用語集は必須 – ないと絶対誤解します! • 言い切り言葉でしめる –例 • ☓ ザコをすべて倒すことで、ボスと戦うことがで きます(できるようになります) • ○ザコを全て倒すと、ボス戦に移行します
  43. 43. 5. 値の範囲が書かれていない、単位が統一 されていない • 値には必ず取り得る範囲を決める – 無限は実現不可能 • 精度を気にする – [0-1000] の値を取る時、小数点何位まで比較 するか • 数値を書く場合は常に単位を書く – 秒なのかミリ秒なのかはっきりと
  44. 44. 6. 実現すべきことが書かれていないのに詳 細なロジックだけ書いてある • プログラマが知りたいのは実現すべきこ と – ロジックはプログラマに考えさせるのが Better
  45. 45. 7. 語尾が「~したい」で終わっている • 仕様書には実装すべきことだけを書 く – ボリュームの調整はスケジュールを組 む段階でする
  46. 46. 8. 変更があっても更新されない • こまめに更新 • 相談したら即反映
  47. 47. 9. プログラマに相談、確認がされていない ことがある • 仕様書を書いたら絶対プログラマの チェックを入れる – フローがおかしくないか – データ構造に無駄がないか – ロジックがもっとシンプルにならないか
  48. 48. 10. わからないことがあったら直接聞いて くださいと書いてある • これは記述が足りないということ • 仕様書は誰が読んでも誤解なく理解 できるように書くべき
  1. 1. プログラマが欲しい仕様書と は 東京開発グループ リードソフトウェアエンジニア 牧野 克俊
  2. 2. ソフトウェア工学って知ってます か?
  3. 3. ソフトウェア工学とは • ソフトウェアの開発・運用・保守に ついて体系化、分析、研究する分野 • 高度で安全なソフトウェアを短期間 で設計するための研究を行う
  4. 4. • 知っていると役に立つのは –ソフトウェア開発工程 –ソフトウェア開発方法論
  5. 5. • 知っていると役に立つのは –ソフトウェア開発工程 –ソフトウェア開発方法論
  6. 6. ソフトウェアの開発工程
  7. 7. ソフトウェアの開発工程 • 要求分析 • 設計 • コーディング • テスト • 運用・保守
  8. 8. ソフトウェアの開発工程 • 要求分析 – ソフトウェアがどのような機能を持つべきか を検討し文書化する。
  9. 9. ソフトウェアの開発工程 • 設計 – 機能がソフトウェアとしてどのように実装さ れるべきかを検討し仕様化する。
  10. 10. ソフトウェアの開発工程 • コーディング – 仕様に従ってプログラムを作成する。
  11. 11. ソフトウェアの開発工程 • テスト – 作成されたプログラムが機能的な要求を満た していることを実証する。
  12. 12. ソフトウェアの開発工程 • 運用・保守 – ソフトウェアを使用したり、新たな要求に応 じて機能を追加・変更する。
  13. 13. 一般的に必要とされるドキュメ ント
  14. 14. 必要とされるドキュメント • 企画書 • 要求仕様書 • 設計書 • 機能仕様書 • 詳細仕様書 • テスト仕様書 • 運用マニュアル
  15. 15. ドキュメントはなぜ必要か?
  16. 16. ドキュメントはなぜ必要か? • 効率よく開発するため – 情報共有するため – 思考をトラッキングできるようにする ため – 質問を減らすため
  17. 17. コラム:情報共有とは • 「教育の情報化と情報セキュリ ティ」より – 機密性(confidentiality) • 認可されたものだけが情報にアクセスできること – 完全性(integrity) • 正確であること、及び完全であることを維持する こと – 可用性(availability) • 許可されたものが必要なときに情報にアクセスす ることが可能であること
  18. 18. コラム:情報共有とは • 必要な人がいつでも自由に、正しい 情報を取得できるようにすること
  19. 19. ゲーム制作に最低限必要なドキュメント は?
  20. 20. 最低限必要なドキュメント 1. 企画書 2. 機能仕様書 3. 運用マニュアル
  21. 21. 1. 企画書 • タイトル、プラットフォーム、コンセプ ト、売り、ゲームシステム、キャラク ターなどの説明 • 1枚目からラストにかけて、流しても読 めるような企画書が望ましい • 一番重要なのは『何かが面白い』『遊ん でみたい』『売れそう』という3点
  22. 22. 2. 機能仕様書 • ユーザの観点からゲームがどのように動 くか記述する • どのように実装されるかは問題にしない • 機能を中心としており、用語の定義と か、UI とかいったものの仕様も定める
  23. 23. 3. 運用マニュアル • システムの構築方法 • 操作方法や注意点 • トラブル発生時の対処法
  24. 24. プログラマが欲しい仕様書はど れ?
  25. 25. 機能仕様書です!
  26. 26. プログラマが仕様書を欲しがる理由 は?
  27. 27. ソフトウェアデザインをするた め!
  28. 28. ソフトウェアデザインとは • プログラムを機能単位に分割し、構 造化したり処理の流れを決める
  29. 29. コラム:良いプログラマの生態 • リファクタリングは苦にならないが、仕 様変更による作りなおしは嫌がる • 心配性もしくは細かいことを気にする
  30. 30. どんな機能仕様書を書けばいい か?
  31. 31. 最低限必要な項目 • シナリオ • 対象外 • 概要 • 詳細 • 未解決の問題 • 用語解説
  32. 32. シナリオ • ターゲットは? • どのような状況で使うのか? • どのように使うか?
  33. 33. 対象外 • 明らかにオーバースペックなこと • 今のバージョンでやらないこと • 対象外のプラットフォーム
  34. 34. 概要 • 一覧性が重要 • 全体像を把握させる – フローチャート – 関係性
  35. 35. 詳細 • 想定される状況を全て書く • 何がエラーになるか全て書く • 全てのエラーに対してどう処理する か書く
  36. 36. 未解決の問題 • 何が未解決か残す • これが残っているうちはプログラマ にコードを書かせない
  37. 37. 用語解説 • 一般的な単語でもドキュメント中で の意味を書く
  38. 38. 仕様書のアンチパターン 1. 同一レイヤの事を書いてるのに人によってフォーマットが ばらばら 2. 一見似ているがよく見ると若干違う情報があちこちにある 3. できないこと、やらなくていいことが書かれていない 4. 単語、言い回しが統一されていない 5. 値の範囲が書かれていない、単位が統一されていない 6. 実現すべきことが書かれていないのに詳細なロジックだけ 書いてある 7. 語尾が「~したい」で終わっている 8. 変更があっても更新されない 9. プログラマに相談、確認がされていないことがある 10. わからないことがあったら直接聞いてくださいと書いてあ る
  39. 39. 1. 同一レイヤの事を書いてるのに人に よってフォーマットがばらばら • 絶対に必要な項目を抽出する作業 が必要 –テンプレートを作りましょう
  40. 40. 2. 一見似ているがよく見ると若干違う情報 があちこちにある • 仕様書の構造を見直しましょう –共通部分を切り分ける –機能の関係性が分かるように
  41. 41. 3. できないこと、やらなくていいことが書 かれていない • これらはプログラムの設計に影響す る – どんなエラーが起こり得るか? – その時どうするか? – 何が必要ないか?
  42. 42. 4. 単語、言い回しが統一されていない • 用語集は必須 – ないと絶対誤解します! • 言い切り言葉でしめる –例 • ☓ ザコをすべて倒すことで、ボスと戦うことがで きます(できるようになります) • ○ザコを全て倒すと、ボス戦に移行します
  43. 43. 5. 値の範囲が書かれていない、単位が統一 されていない • 値には必ず取り得る範囲を決める – 無限は実現不可能 • 精度を気にする – [0-1000] の値を取る時、小数点何位まで比較 するか • 数値を書く場合は常に単位を書く – 秒なのかミリ秒なのかはっきりと
  44. 44. 6. 実現すべきことが書かれていないのに詳 細なロジックだけ書いてある • プログラマが知りたいのは実現すべきこ と – ロジックはプログラマに考えさせるのが Better
  45. 45. 7. 語尾が「~したい」で終わっている • 仕様書には実装すべきことだけを書 く – ボリュームの調整はスケジュールを組 む段階でする
  46. 46. 8. 変更があっても更新されない • こまめに更新 • 相談したら即反映
  47. 47. 9. プログラマに相談、確認がされていない ことがある • 仕様書を書いたら絶対プログラマの チェックを入れる – フローがおかしくないか – データ構造に無駄がないか – ロジックがもっとシンプルにならないか
  48. 48. 10. わからないことがあったら直接聞いて くださいと書いてある • これは記述が足りないということ • 仕様書は誰が読んでも誤解なく理解 できるように書くべき

More Related Content

Slideshows for you

Related Books

Free with a 30 day trial from Scribd

See all

×