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

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

  • Login to see the comments

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

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

×