筆者が以前の会社でテクニカルディレクターをしていた際に、非テクニカルなディレクター用にまとめたものです。
会社によって内容は異なるかと思いますので、参考程度に見ていただければと思います。
ドキュメント（共有）
- 開発仕様書
- ファイルリスト
- テスト仕様書
- 画面設計書
- デザイン
- WBS
- コーディングガイドライン
- Gitのフロー
- JS仕様書
- 開発サーバ情報
開発手法（確認）
- CSSフレームワークの使用（クライアントからの要求が無い限り使用しない）
- CSSプリプロセッサの使用
- テンプレートエンジンの使用
- タスクランナーの使用
ここで確認したいのは、その後の運用時にどのようになっているのがベストかがポイント。
よくある事例として、
クライアント側で運用を行う場合は、SassやGulpなどは触れないことが多いので、コンパイル後のファイルが編集可能な状態になっていると良い。
ファイル管理（共有）
デザインや画面設計書のファイル管理ルールを決めておく。
開発者目線としては、どのファイルが正しくて且つ最新であるかがパッと分かるようになっていると良い。
やり取り（共有）
基本的なやり取りをどこで行うのか決めておく。
また、ちょっとしたやり取りまではSlack、エビデンスを残しておきたいものはBacklog、
といったルールも予め決めておいた方が良い。
アクセス解析タグ（共有）
何を入れるかが分かっているのであれば、事前に共有しておく。
開発者目線としては、予め空のインクルードファイルを入れておく等の対応が出来る。
まとめ
事前の共有が不十分だと、開発の進行がスムーズに行かなかったり、上がってきたものに認識の齟齬があったりと、思わぬインシデントに繋がることがあります。
認識の齟齬を出来る限り無くして、リスク回避していきましょう！
今回は、着手前に確認する内容を書いてきましたが、
次回は、成果物に対して非エンジニアのディレクターさんでも確認出来る項目を書いていこうと思います。
（もしかしたら、結果的に事前に確認しておくことに入ってくる項目があるかもですが…）