要約
Unity Learnでチーム開発におけるプロジェクト管理とチームワークについてのチュートリアル1が説明されていたので，
個人的にメモした．
概要
効果的なプロジェクト管理とチームワークに関すること：
- チームメイト，クライアント，その他の関係者との明確なコミュニケーション．
- 完成品を期日までに仕上げる．
- 完成品とは，プロジェクトに設けられた要求を満たし，目標を達成しているもののこと．
プロジェクトのフェーズを確認
-
Pre-production:
プラン，プロトタイプ，パイプラインの設定，初期デザインなど，
本格的なプロジェクトを始める前に行われる作業． -
Production:
最終的な2D,3Dモデルの制作，オーディオ，ライティング，ユーザー体験などを含む，
アセットの制作． -
Post-production:
品質保証(QA)，編集，テスト，バグ修正，最終的な磨きを含む，
完成品が完成したと言われる後に行う作業． -
Operations:
販売，収益化，アップデート，継続的なメンテナンスなど，
プロジェクトがリリースされた後も継続して行われる作業．
プロジェクト計画の概要
ドキュメント化とトラッキング
ドキュメントデザイン：
- プロジェクトの目的，対象，目標を明確化．
- プロジェクト計画を作ることによって，必要なプロジェクトのステップを明確化．
- 成果を作り期日を達成するために，マイルストーンを一貫してトラッキング．
- チームで作業するとき役割を割り当て，各々のタスクを定義し，優先順位をつける．
- 各々が役割と責任を果たし，フォローしていることを確認する．
タイムマネジメント
プロジェクト管理するとき：
- 設計と開発プロセスの各フェーズにおけるスコープタイム
- 日々プロジェクトプランを見直し，プロジェクトマネージャーに簡潔に日々の状況を報告する（スタンドアップ）．
- いかなる予期せぬ遅延のためのコンティンジェンシープランニングを使う．
- 必要に応じて，プロジェクト計画におけるタスクや成果を再優先順位付けや更新を行う．
- チームに適したプロジェクト計画や管理ツールを明確化する．
- 選んだツールを一貫して使う．
コミュニケーション
プロジェクトにおいて他者とコミュニケーションをするとき：
- 自分の進捗やチームメンバーや外部の協力者の仕事に影響を与える問題を明確にする．
- 相手の時間を尊重する．自分もね．
- 仕事を批評するとき，相手の気持ちに配慮する．
- フィードバックを役に立つ，具体的，リスペクトものにすることに焦点を当てよう．
- 活発的に聞いて，フィードバックをくれた人と関わることによって自分に対するフィードバックを受け入れる．
- それらのフィードバックをどのように対処できるかを正直に反映しよう．
リスペクトとプロ意識
他者とプロジェクトを共同するとき：
- 時間厳守．
- 共同者，同僚，クライアントへの迅速な返信
- 他者の意見や貢献を聞く．
- 積極的に共同作業を行う．
設計書とプロジェクト計画書
プロジェクトを始める前に設計書に含まれること：
- ゲームデザインドキュメント(GDDs)
- 対象ユーザー
- プロジェクト規約
- 技術仕様
設計書
青写真に含まれること：
- ハイレベルな概要；例えば，ゲームデザインドキュメントにおけるプロジェクト全体のヴィジョン
- プロジェクトにおける特定のパイプラインに対する要求と標準
- 特定の機能に対する詳細な仕様書
よりハイレベルな設計書に必要なこと：
- プロジェクトに対する目標と目的
- 想定されるユーザー
- プロジェクトの主な特徴
- 最終的な配信形式
プロジェクト規約
たいてい含まれること：
- プロジェクトに対する理由
- プロジェクトの目的と制約
- 主要なステークホルダーは誰？（一番関係あるの誰？ってこと）
- リスク把握
- プロジェクトのメリット
- 予算の一般概要
追加ドキュメント
-
Technical documentation:
プロジェクトの技術部分のアーキテクチャと機能の指定 -
Meeting notes:
チーム開発のとき，チーム全体が取り組んでいること，依存関係，進捗状況，阻害要因などを記録 -
Proposal or pitch document:
提案が必要なときや，投資者にプロジェクトの資金を出してもらうときに，
正式な提案書やピッチドキュメント（簡易プレゼンテーション）が推奨される．
プロジェクトの管理と進捗管理
プロジェクトを成功させるためのガイドラインに含まれること：
- 必要なプロジェクトのステップを明確にする．
- チーム開発のとき，プロジェクトの具体的な役割と責任を明確にし，割り当てる．
- 具体的な成果や期日を伴うタイムラインを作成する．
- スコープクリープや過度な野心的な計画設計，厳しい時間制約など，
プロジェクト管理における共通の問題や課題を明確にする． - プロジェクトを完成させる期日を決定する．
- プロジェクト全体を構成する小さなピース毎に期日を設定する．
- プロジェクトの各フェーズ毎に合理的な時間枠を作る．
- チーム開発のとき，リスト上の各タスクの責任者を指定する．
クライアントに向けたプロジェクトの作成
クライアントのためのプロジェクトを作成するときの考慮事項：
- プロジェクトの役割を明確にする
- クライアントとグループの間の連絡係となる人や，
プロジェクトのそれぞれの要素に対する主なステークホルダーを明確にする． - クライアントの期待を理解し，明確にする．
- クライアントとの明確なコミュニケーションをサポートするための計画
- クライアントとコミュニケーションをするための方法や
クライアントとプロジェクトをレビューするためのオンラインコラボレーションツールを明確にする．
プロジェクト管理をサポートするツールの特定をしてみよう！
僕のGitHubを貼っておきます．
(個人でゲーム開発しているんですが，チームの意向でpiravteにしてます．すみません．)
配信のための準備
品質保証テスト
Test scripts
QAテストスクリプトは，テスターによる観察を記録する一連のステップのこと．
これは，正式なテストを開始する前に作成され，
プロジェクトの要件やユースケースを参照して製品を評価するために使用される．
また，ユーザー体験に関するチームの仮定をテストするために使用されることもある．
Bug report tracking
バグの追跡と解決は，配信に向けて製品を磨くために不可欠な要素．
GitHubはおすすめだけど，多くはスプレッドシートを使っている（らしい）．
典型的なバグレポートに含まれること：
-
Title / bried summary:
バグの説明的なタイトル -
Identified frequency:
どのくらいの頻度で発生する？ -
毎回？ほとんど？ランダム？たまに？
-
Reproduction steps:
バグを再現するための具体的なステップ．
これは，開発者が追加情報なしでバグを再現できるほど詳細であるべき． -
Detailed description:
バグとユーザー体験に関する影響のより詳細な要約． -
Any other observations:
バグの原因に関する考察や関連する詳細を含める -
例：エラーは一貫して起こらないが，日中よりも夜間のほうがより頻発する．
プロジェクトをリリース
プロジェクトがテスト，修正，検証されたらリリースです！
理想は，最初に特定した日にプロジェクトを公開できたらいいですね．
たとえ決めた通りにならなくても，調整することで，合理的な範囲内にできるはず．
オペレーション活動とレトロスペクティブ（振り返り）
オペレーション活動
プロジェクトサイクルの最終フェーズは，通常，リリース後にその稼働を維持するために行われる作業．
この作業は，継続的な販売，収益化，アップデート，継続的なメンテナンスが含まれる．
プロジェクトレトロスペクティブ
振り返りの方法として，以下の3つの欄からなる表を作るのが，シンプルな方法：
- やったほうがよかったこと
- やめたほうがよかったこと
- 続けること
最後に
プロジェクト管理の基本をまとめた．
これらは，いかなるプロジェクトにも当てはまる．
次のプロジェクトを始める際には，これらの推奨事項を参考にして，計画通りに進め，期日までに完成させよう！
-
[Unity Learn Tutorial - Introduction to project management and teamwork] (https://learn.unity.com/tutorial/introduction-to-project-management-and-teamwork?labelRequired=true&pathwayId=5f7e17e1edbc2a5ec21a20af&missionId=5f71fe63edbc2a00200e9de0#) ↩