プロジェクトスタート時に README を準備して、環境を整える


こんにちは、UIデザイナーの水澤です。

以前ブログで「キックオフミーティングで大事なこと」を書きました。それに関連して、今回はプロジェクトスタート時に準備するもの、README について書きます。

チームで作り上げていくことを大切にしている Gaji-Labo では、毎回のプロジェクトでこの README を作成しています。

README とは

GitHub を利用する方はイメージがしやすいと思います。GitHub では、READMEファイルをリポジトリに追加して、そのプロジェクトが何かを他のユーザーに伝えます。

今回準備する README も同様に、そのプロジェクトの情報をまとめたドキュメントを指します。異なるのは社内メンバーのみに共有・閲覧される点です。

この README にプロジェクトに関わる情報をすべて集約して、いつでも情報を参照できるようにします。それによって、途中から参加したメンバーも情報をキャッチアップしやすいメリットがあります。

内容

README の内容は下記が挙げられます。
ここに挙げられていない情報も、プロジェクトに関わる情報であれば記載していきます。

  • プロジェクト概要
    • クライアントのサマリー
    • プロダクトの簡単な説明
    • プロジェクトの目的
  • 関係者
    • クライアント担当者
    • 社内担当者
  • コミュニケーション
    • コミュニケーションツール
      • Slackであればチャンネルなど
    • オンライン会議ツール
    • 会議体(定期的な会議のスケジュール)
  • 開発概要
    • 技術スタック
    • 使用ツール
  • ドキュメント
    • 共有データの場所
    • 社内のデータの場所
  • マイルストーン・スケジュール
  • 打ち合わせログ
    • クライアントとの MTG の議事録
    • 社内MTG の議事録

内容の説明

プロジェクト概要

クライアントのサマリーは、企業名・どのような企業かの簡単な説明、サイトURLなどです。開発対象となるプロダクトのプロダクト名・どのようなプロダクトかの説明も必要です。

プロジェクトスタートでは最初にプロジェクトの目的をしっかり確認しておき、README に書き残しておきます。開発途中に目的を見失いそうになっても README でいつでも確認できます。

関係者

クライアント担当者・社内担当者は漏れなく全員分の名前をリストアップしておきます。

名前だけでなく関係性もわかるようにその人の職種・役割も併記しておくと、後から読む人にもわかりやすくなります。

コミュニケーション

弊社はフルリモートワークのため、非同期コミュニケーションツールは欠かせません。

利用ツールは Slack が多いですが、もちろんクライアントや案件状況に応じて Slack 以外のツールも利用するので、README にまずはツール名を書きます。

もし Slack の場合、クライアントと弊社のどちらのワークスペースかという点や、利用するチャンネル名の記載も必要です。案件やチーム状況によっては役割や部署に応じて複数のチャンネルを使い分けるため、誤って違うチャンネルを利用しないようにルールを書いておきます。

Zoom などのオンライン会議ツールも必須です。ツール名と、定期的な会議がある場合はその会議体について記載しておきます。会議の種類が複数ある場合、役割や開催頻度・時間が異なることを整理して記すとわかりやすいです。

開発概要

プロジェクトで使用するプログラミング言語、フレームワーク、ライブラリ、ツール名などの開発環境や技術構成を書きます。デザインを制作するときのツール名もここに記載します。

ドキュメント

プロジェクトに関する資料はすべてここにまとめていきます。
スタート時は資料が少ないと思いますが、プロジェクトが進行するにつれて関連資料が増えるため、記載漏れが発生しないように資料が増えた段階ですぐ README に追記します。

具体的には、開発Wiki・仕様書などの開発資料や、概念モデル図・デザインデータなどのデザイン資料がここに該当します。弊社では概念モデル図は Miro、デザイン制作は Figma で行うことがほとんどです。その場合はここに Miro や Figma の URL を記載します。

Miro や Figma などのオンラインツールを利用する場合は、先ほどのコミュニケーションツールと同様にクライアント側・社内側のどちらの環境かを加えておきます。

また、資料によってはクライアントに共有するものと社内だけに共有するものがあるため、読み手が混在してしまわないようにしっかり書き分けておくことも大事です。

マイルストーン・スケジュール

弊社では、記述方法について特に定めはありません。スケジュールを引いたスプレッドシートの URL をここに貼ることもあれば、マイルストーンをここに直接書くこともあります。

打ち合わせログ

会議の議事録を指します。こちらもクライアント含めた打ち合わせのものと、社内の打ち合わせのものが混在しないように区分しておきます。タイトルには開催日時を含め、その順番に一覧化すると辿りやすいです。

おわりに

情報が分散されている状況では、情報を探しに行く手間や内容の正しさの精査などが発生してしまうため、README によってプロジェクトに関わる情報を一つに集約しておくメリットは大きいです。

もう一つのメリットは、それを自身でまとめる場合に「今の自分が何をわかっていないのか」がわかることだと思います。テンプレート化しておけば必ずそれに従って情報を確認しますから、自分の点検にもなります。

Gaji-Laboはスタートアップチームの伴走をします

「新規事業に取り組んでいるが、ビジネスから開発までのプロセスがなかなかうまく繋がらない」
「はじめて任される新規事業チームだが、プロジェクトがなんとなくうまくいっていないその理由がわからない」
「ビジョンやコンセプトを可視化してチームの共通言語にしたいが、どうしたらよいだろう」

などなど、新規事業に取り組むチームならではのお悩みごとをお持ちでしたら、まずは一度お気軽に Gaji-Labo にご相談ください。

オンラインでのヒアリングとフルリモートでのプロセス支援にも対応しています。

スタートアップ支援の相談をする!

投稿者 Mizusawa Minami

UIデザイナー。
サインデザインに携わった後、Web制作会社にてWebディレクターを経験。その後UI/UX設計に関心を持ち、事業会社や受託会社でUIデザインを担当。ユーザーにとって心地よい設計を考えていきます。Figmaが好き。