Monday.comによるプロジェクトマネジメント

基本ツール利用図

---

ツールの選定基準・指標

① UI / UX：限りなくシンプルであること
②連携性：monday.comをベースに連携が可能であること
③拡張性：どのプロジェクトにも対応しうる拡張性があること

マネジメントレイヤーとの対応

ピープルマネジメント：コミュニケーションツール（Slack）
プロジェクトマネジメント：スケジュール管理ツール（monday）
プロダクトマネジメント：バージョン・ソース管理ツール（git, GitHub）
タスクマネジメント：タスクマネジメントツール（monday）

タスクの構造化について

1. タスクの洗い出し・分解
2. タスクの順序（優先順位）を設定する
3. 親子構造で構造化する
4. スケジューリングと担当アサインを行う

親子構造で分解したタスクはmondayで管理する。

プロジェクト進行における4つのマネジメントレイヤー

1. ピープルマネジメント
2. プロジェクトマネジメント
3. プロダクトマネジメント
4. タスクマネジメント

当初、レイヤーとして一方向性（1次元的）のマネジメントを思考していたが、図式化すると2次元的,3次元的な考え方もできるのではないかと考察。

マネジメントそのものを次元拡張し、多角的に検討することで簡潔で単純化した管理が実現するのではないかと考える。
レイヤーのような1次元的なマネジメントであれば、タスクマネジメントの比重がかなり大きくなりピープルマネジメントやプロジェクトマネジメントの重要性や必要性が失われると考える（本来は重要で必要であるのにも関わらず。）

次元を拡張しそれぞれのマネジメントを連結させていくことで、実際の運用の際にはやるべきこと・重要視するべきことが明確になり、同時に全てのレイヤーを監視・フィードバックすることができるのではないか。

次元を上げていくことに対するデメリットとしては、マネジメント構造自体を頻繁に見直し全てのレイヤーを同時に改善していく必要があること。さらにそれには膨大な時間的コストがかかること。

これに対する反論としては、チーム単位でマネジメント構造が最適化されやすい。
構造が限りなく完璧に近くなるにつれ指数関数的にマネジメントコストも落ちていくだけでなく開発効率の向上にもつながる。

実際にどのように次元を拡張していくかは今後検討するべき。
また次元拡張した際の構造について自己理解を怠らないこと。

一次元的マネジメント

4つのマネジメント要素を点としてとらえ、その連続によって進行していく構造
最大2方向

二次元的マネジメント

4つのマネジメント要素を線型化し、それぞれ要素末端が連携して相互作用が生まれる構造
最大8方向

三次元的マネジメント（検討中）

4つのマネジメント要素の一つ一つを平面化し、それぞれの面の表と裏が対応するように作用する構造
（最大？）

検討中要素：

• 予測工数と実工数の入力を行うか？
• 英語対応どうする...?

実装予定機能：

• Slackとの連携（毎日夕方にプロジェクト進捗の通知など）
• Github連携
• 色分けによる可視性向上

---

monday構造

ボード一覧：

• プロジェクト管理
• 機能マスタ
• タスク管理
• バグリスト

ドキュメント一覧：

• 設計書・仕様書
• リンク集

ボード・ドキュメント概要

プロジェクト管理（未定）

プロジェクト全体の進捗を追うためのボード。
ダッシュボードにするかも。

機能マスタ

ビュー

• メイン
• スケジュール（ガントチャート）
• カテゴリ別（カテゴリによるグルーピング）

カラム

• 機能名 [メインカラム]
• カテゴリ [状況]
• 概要 [テキスト]
• タスク [接続 - タスク管理]
• 進捗 [ ミラー - タスク - ステータス]
• バグ [接続 - バグリスト]
• 進捗 [ ミラー - バグリスト - ステータス]

タスク管理

最小単位で分解したタスクを全て登録・管理するボード

操作ユーザー：PM・エンジニア・テスター

ビュー

• メイン
• スケジュール（ガントチャート）
• タスク分類別 （タスク分類によるグルーピング）
• かんばん

カラム

• タスク [メインカラム]
• 担当 [ユーザー]
• ステータス [状況] [未着手 / 進行中 / レビュー / 完了]
• タスク分類 [状況] [設計 / 開発 / テスト]
• スケジュール [タイムライン]
• 機能 [接続 - 機能マスタ]

バグリスト

ビュー

• メイン
• スケジュール（ガントチャート）
• 優先度別

カラム

• 担当 [ユーザー]
• 優先度 [priority]
• ステータス [状況]
• スケジュール [タイムライン]
• 機能 [接続 - 機能マスタ]
• 概要 [テキスト]

設計書・仕様書

ドライブやNotionへのリンクや捕捉事項。
使用技術の記載やローカル開発環境構築の手法などを記載。

資料・リンク集

先方から共有された資料の共有、使用ライブラリの参照URLなどを記載。

複数フェーズに分かれる中規模 ~ 大規模プロジェクトの場合、機能マスタの一階層上に "プロジェクト管理"ボードを作成。

以下カラムで管理：

• フェーズ [メインカラム]
• ステータス [状況]
• 機能 [接続 - 機能マスタ]
• 実装進捗 [ミラー - 機能マスタ - 状況]
• タスク進捗 [ミラー - 機能マスタ - タスク進捗]
• バグ進捗 [ミラー - 機能マスタ - バグ進捗]

このボード上にダッシュボードやガントチャートを置き、可視性を向上するのもあり
（無料プランだとほぼできないんだな... orz

mondayの構築フロー

1. 全ボード複製
2. 設計書や仕様書添付
3. WBS（タスク洗い出し・分解・構造化）
4. フェーズ登録
5. 機能マスタ登録
6. タスク登録

機能マスタボードへGitHub接続
自動化整理（Github, Slack）

実際に登録してみたが、WBSについてはスプレッドシートなどで先に作成しておく方が良い。
作りながら考えるは時間的コストが大きい。
取り急ぎメモ。