簡単な自己紹介
渋谷のとあるプログラミングスクールを経営する会社でCTOを担当しています。
昨年、2019年3月にこの会社にジョインしてから開発から新商品企画まで幅広く担当してます。
背景
2019年3月に私が入社した時、システム開発の案件管理に色々と問題がありました。
それらの問題を各ステークホルダーにヒヤリングして問題点と解決案をまとめて社長に提案し、社長の賛同を得て開発体制の構築を進めてきました。
この度、ようやく開発体制の構築ができて順調に開発案件の管理、運用できるようになってきたので、今回、他の会社の参考になればと思ってまとめてみました。
弊社の組織体制
組織としては、CEO（社長）をトップとして、以下チームが下にある形です。
私は、CTOとして開発チームのマネージャーを担当しています。
開発体制の問題点をステークホルダーの声を聞いて整理した
問題の解決にあたって、まずは各ステークホルダーにヒヤリングしたところ、以下の声をいただきました。
CEO（社長）の声
- 開発チームは重要なのでチームとして開発効率を高めて欲しい
- プロジェクトが増えてきたので優先順位を管理しきれない。開発優先順位は各プロジェクトに任せたい
各チーム、Projectのマネージャーの声
- 開発チームの「誰に」「何を」「どのように」「どのような順番」で「どのような粒度」で依頼すれば良いのかわからない
- 開発案件を依頼するにあたって必要な前提知識が分からない
開発チームの声
- 会社全体としてどのようなProjectがどのような目的を持って動いているのか把握できない
- どのProjectが、どのくらい開発チームの力を借りたいのか分からない
- 各Projectを把握することで他のプロジェクトにも関連する案を提案したい
- 新規案件の優先順位がわかるが、保守案件の優先順位はよく分からない。開発者にお任せ状態。
- 技術的な要件（新技術に取り組む、ライブラリのバージョンをあげる）がやりたくてもできない。今の案件で一杯一杯。
- 開発チームに頼めばすぐにやってくれると思われてしまっている。何かに取り掛かっている時には難しいけど伝わらない
問題点に対するアクション
CEO（社長）の声に対して
- 開発チームは重要なのでチームとして開発効率を高めて欲しい
- アクション：⑥ カンバン方式の導入
- カンバン方式はチームとしての成果を最大化する手法なので開発効率を高めることができる
- アクション：⑨ MVV(Mision Vision Value)の導入
- チームとしての目標を設定することで、個人ではなくチームとして案件を判断できるようにする
- アクション：⑥ カンバン方式の導入
各チーム、Projectのマネージャーの声に対して
- 開発チームの「誰に」「何を」「どのように」「どのような順番」で「どのような粒度」でIT案件を依頼するのか分からない
- アクション
- ④ Issueのテンプレート機能で定型化する
- ③ 開発案件依頼用のGitHubリポジトリを作成する
- アクション
- 開発案件を依頼するにあたって必要な前提知識が分からない
- アクション： ① プロダクトオーナー制度の導入
開発チームの声に対して
- 会社全体としてどのようなProjectがどのような目的を持って動いているのか把握できない
- アクション：② インセプションデッキをプロダクトオーナーに作成してもらう
- どのProjectが、どのくらい開発チームの力を借りたいのか分からない
- アクション：⑥ カンバン方式の導入と⑤ IssueラベルによるProjectの分類
- 各Projectを把握することで他のプロジェクトにも関連する案を提案したい
- アクション：開発チームの⑧ Daily MTGの設置
- 新規案件の優先順位がわかるが、保守案件の優先順位はよく分からない。お任せ状態
- アクション：
- ⑦ GitHubのプロジェクト機能の活用と⑥ カンバン方式の導入
- 保守案件への① プロダクトオーナー制度の導入による案件の明確化
- アクション：
- 技術的な要件（新技術に取り組む、ライブラリのバージョンをあげる）がやりたくてもできない。今の案件で一杯一杯。
- アクション：技術的な案件への① プロダクトオーナー制度の導入による案件の明確化
- 開発チームに頼めばすぐにやってくれると思われてしまっている。何かに取り掛かっている時には難しいけど伝わらない
- アクション：⑦ GitHubプロジェクトボードを活用すると⑥ カンバン方式の導入による見える化
アクションまとめ
- プロダクトオーナー制度の導入
- インセプションデッキによるプロジェクト目的の明確化
- 開発案件依頼用のGitHubリポジトリ
- GitHub Issueのテンプレート機能で開発チームへの依頼を定型化する
- IssueラベルによるProjectの分類
- カンバン方式の導入
- GitHubプロジェクトボードを活用する
- 開発チームのDaily MTGの設置
- 開発チームのMVV(Mision Vision Value)導入
アクション① プロダクトオーナー制度の導入
プロダクトオーナー制度を社内に広めるにあたって、定義が必要だったので、以下、定義を定めて、各所に説明しました。
プロダクトオーナとは
-
プロジェクト/プロダクトの価値を最大化するためにどの機能、タスクに着手すべきかリストアップして、優先順位をつける役割の人 - CEO（社長）からプロジェクトを推進できる人として指名された人
プロダクトオーナの主なタスク
-
プロジェクト全体がわかる資料の作成 （必須）
- 会社全体のプロジェクトが把握できるようにGitHubプロジェクトに資料を作成する
- 基本はインセプションデッキの形式で作成する
- スケジュールの作成（期日が重要なプロジェクトの場合）
-
Issue（機能、タスク etc）の作成とテンプレート作成（必須）
- 開発チームに依頼する単位で作成する
- リリースできる単位が目安
- どの機能、タスクに着手すべきかをリストアップしてGitHubプロジェクト上で優先順位をつける
- 開発した機能を運用に乗せるために各チームとコミュニケーションする（必須）
アクション② インセプションデッキによるプロジェクト目的の明確化
- 次にプロダクトオーナーに対して、各プロジェクトの目的を明確にしていただくよう依頼しました。
- プロジェクトの目的をただ明確にするっていうことも無理があったので、インセプションデッキを活用にすることにしました。
インセプションデッキとは
- インセプションデッキとは、プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメントです。
- ThoughtWorks社のRobin Gibson氏によって考案され、その後、アジャイルサムライの著者 Jonathan Rasmusson氏 によって広まったそうです。
- インセプションデッキのフォーマットはこちらの記事(スクラムで使う「インセプションデッキ」のmarkdown形式版テンプレート)を参考にしました。
参考文献
-
スクラムで使う「インセプションデッキ」のmarkdown形式版テンプレート)
- GitHubリポジトリのREADME.mdにインセプションデッキをまとめたのでとても参考になりました。
-
振り返ればインセプションデッキがいた ~ ヌーラボにとってのインセプションデッキ ~
- 実例の紹介として活用させていただきました。
アクション③ 開発案件依頼用のGitHubリポジトリの導入
プロダクトオーナーがIssueを作成することを基本としていたので、プロダクトオーナーがIssueを登録できる場として開発案件依頼用のGitHubリポジトリを用意しました。
なぜなら、弊社のリポジトリは3つのリポジトリに開発案件が分かれており、プロダクトオーナーが、開発案件を登録する時にどのリポジトリの開発案件なのか？という判断は不可能に近かったからです。
開発者としても、複数リポジトリに渡る開発案件はどこにIssueを持てば良いのか混乱していました。
開発案件依頼用のGitHubリポジトリの導入することで、プロダクトオーナーが、Issueを登録する場所が1ヶ所で済むようになり、明確にすることができました。
案件依頼用のIssue URLを各リポジトリのプルリクエストに貼り付けることで、リポジトリをまたいで関連させることができます。
アクション④ GitHub Issueのテンプレート機能で開発チームへの依頼を定型化する
開発チームの「誰に」「何を」「どのように」「どのような順番」で「どのような粒度」でIT案件を明確にするためにGitHub Issueのテンプレート機能を使いました
GitHub Issueのテンプレート機能とは
- GitHubの機能でIssueのテンプレートを作成することができる機能
- Issueを上げるときに、選択させることができる
- この機能を利用することでどのように開発チームに依頼すれば良いのかを定型化することができる
- GitHub の Issue Template を複数設定して使い分ける の資料を参考にしてIssueテンプレートを作成ました。
参考資料
例：弊社の機能開発用のテンプレート
弊社では、当初、3つのIssueテンプレートを作成しました。
- Bug report
- バグを知らせてね
- Feature request
- ワクワクするような新機能リクエスト
- Task
- タスクの整理と内容を記す
＊Issueテンプレートの詳細については、[GitHubのIssueテンプレートを導入する方法のメモ] (https://blog.zuckey17.org/entry/2018/11/18/235914)をマルッとコピーして使わせていただきました。
Feature requestの詳細
現在では、テンプレートの追加、改良も進んで13テンプレートが弊社では存在します。
そのうちの一つFeature requestを載せておきます。
Feature requestは、新規機能依頼に利用するテンプレートです。
＊「📓 運用ルール」は、弊社独自の項目です。追加した理由は、せっかく開発したのに運用が決まっていない、エバンジェリスト不在で、機能が使われないってことが発生していたからです。現在では、この機能がリリースされたら誰が、どのように運用するか決まってますか？って、開発チームから依頼者に聞くようにしてます。
## Project
(関連するプロジェクトを選択してください。)
## 🎉 目的、完了条件
(ビジネス上の目的は？)
(IssueがClosedになるために必要な状態は？)
## 😩 現状の問題
(現状発生している問題は？)
## 🤔 問題の背景、原因
(現状の問題はなぜ発生しているのか？)
## 📓 運用ルール
(機能リリース後の運用ルール、またはエバンジェリストが存在する？)
## 💻 開発仕様
### 範囲
(どこまで開発する必要がある？)
### デザイン修正
(大幅なデザイン修正は必要？)
--
# 英語版
## 🎉 Purpose, Completion conditions
(What is the business purpose of this issue?)
(What state is required for an Issue to become Closed?)
## 😩 Current problems
(What are the current problems?)
## 🤔 Problem background, Cause, and Solution
(Why is the current problem occurring?)
## 💻 Development specifications
### Scope
### Design modification
(Is a major design modification necessary?)
アクション⑤ IssueラベルによるProjectの分類
開発案件依頼用のGitHubリポジトリの導入することで、プロダクトオーナーが、Issueを登録する場所が1ヶ所で済むようになり、明確とすることができました。
しかし、一方で、一つのリポジトリに複数のプロジェクトが同居することで、各プロダクトオーナが自分のIssueだけを把握することが難しくなりました。
開発チームとしても、どのプロジェクトで、どのくらい開発案件があるのかわからなくなりました。
そこで、ラベルによってProjectを分類できるようにしました。
GitHubのIssueラベルとは
- GitHubのラベルは、作業を編成して優先順位付けするための役に立ちます。
- ラベルは、Issueやプルリクエストに適用して、優先度、分類、あるいはその他の有益な情報を示すことができる機能です
https://help.github.com/ja/github/managing-your-work-on-github/about-labels より参照
アクション⑥ カンバン方式の導入
カンバン方式とは
歴史的な経緯だと、Lean生産方式とAgileから派生したチーム開発の枠組みのことで、以下、3つのメリットがあります。
- ボトルネックが見える化され、価値の流れ（バリューストリーム）を管理できる
- WIPを可能な限り最小に制限することで、個人の過負荷を防ぎ、プル型の助け合うチームへと導く
- サイクルタイム（リードタイム：アイデアからデリバリまでの時間）を改善することで、価値をすばやくデリバリできる
チーム開発の枠組みと、それを支えるツール・役割の用語解説 より参照
以下のようにカンバン方式によって開発案件を管理します。
参考資料
アクション⑦ GitHubプロジェクトボードを活用する
カンバン方式をGitHubプロジェクトボードではサポートしているのでそちらを活用します。
GitHubプロジェクトボードとは
- カンバン方式で、Issueを管理することができる機能です
- ステータス管理と優先順位の管理をすることができます
- Organization直下にProjectを作成することで、リポジトリ横断でIssueを関連させることができます
スッキリした構造
まとめると、以下のようにスッキリした構造になります
- 案件依頼用リポジトリ
- Issue登録
- Issueテンプレートによる開発案件依頼の定型化
- IssueラベルによるProjectの分類
- Issue登録
- GitHubプロジェクトボード
- カンバン方式
- Issueのステータス管理
- 開発優先順位の管理
- 開発状況の見える化
- カンバン方式
GitHubプロジェクトボードの作成方法
Organization > Projects
Organization > Projects > New project
Organization > Projects > New project > Create a new project
ここで、Automated Kanbanを選択します。
ここで、Linked repositoriesで、案件依頼用のリポジトリをProjectに関連づけます
GitHubプロジェクトボードとIssueを関連付ける
Issue作成 > Projects > Organization
ここでProjectsに関連させると、ProjectsにIssueが表示されます。
GitHubプロジェクトボードの優先順位とレーンについて
- カンバンにおけるレーンの設計は、開発プロセスをカンバンボードの左から右に設計すると良いと言われています
- そこで、弊社では以下のように11レーンを定義し、それぞれのレーンの責任者も決めて管理することにしました
- 開発プロセスは、会社によって異なりますが、参考としてただければ嬉しいです
レーン概要
各レーンの解説
1. Projectレーン（責任者：プロダクトオーナー）
- 会社で進行中の全てのプロジェクトを記載して整理する役割
- 各Issueの親Issueとして利用する
- そうすることで、プロジェクトに関わる全てのタスクを一元管理することができる
- プロダクトオーナーを記載して、誰が優先順位を決める責任者なのかもハッキリさせておく
- 共通の資料、スケジュールとかもあればここに記載する
- 共通の資料、スケジュールはGoogleドライブ、Docbaseを活用する
2. IceBoxレーン（責任者：プロダクトオーナー）
- プロダクトオーナーが、優先度が低と判断したIssue
- Issueとは、タスク/機能/バグのことで、ここでは粒度はあまり気にしない。
- 個人のアイディアを思い付いたら、まずはここにIssueを登録してもらう
3. Backlogレーン 仕様未確定（責任者：プロダクトオーナー）
- プロダクトオーナーが、優先度が高いと判断したIssue
- リリースできる単位でIssueを作成する
- 粒度が大きすぎるIssueは分割する
- 開発チームが開発着手できるレベルの仕様はIssueに記載されていない
4. Backlogレーン 仕様確定 But 工数未確定（責任者：開発チーム）
- 開発チームが仕様を把握して、工数見積もりができるようにする段階のIssue
- 開発チームが開発着手できるレベルの仕様はIssueに記載されている
- しかし、工数未確定
5. Backlog 仕様確定 And 工数確定（責任者：プロダクトオーナー）
- プロダクトオーナーが開発着手の最終的な優先順位を決定する段階のIssue
- 開発チームが開発着手できるレベルの仕様はIssueに記載されている
- 工数も確定している
6. Todoレーン（責任者：プロダクトオーナー）
- プロダクトオーナーが
5. Backlog 仕様確定 And 工数確定（責任者：プロダクトオーナー）のレーンで、最も優先度が高いと判断したIssue
7. Doingレーン（責任者：開発チーム）
- 開発中のIssue
- 開発チームが作業に取り掛かる時に、
Todoから移動する
8. Reviewレーン（開発チーム）
- レビュー中のIssue
- 開発チームが、コードレビューを開始したら
Doingから移動する
9. StgTest/Deployレーン（責任者：開発チーム）
開発チームが、デプロイ&ステージング環境でのテストを開始したらReviewから移動する
10. Doneレーン（責任者：開発チーム/プロダクトオーナー）
- 開発チームが、本番環境での動作確認OKだったら、
Deployから移動する - プロダクトオーナーも必要があれば期待通りの機能が本番にリリースされていることを確認する
11. DoneDoneDoneレーン（責任者：社長）
社長は、期待通りの機能が本番にリリースされていることを確認できたらDoneから移動する
アクション⑧ 開発チームのDaily MTGの設置
カンバン方式を機能させるためには、GitHub ProjectのレーンとIssueをちゃんと管理する必要があります。
毎日、開発メンバーが顔を合わせて、Issueに向き合うことで初めて、チームとしてGitHub Projectが活用されます。
Daily MTGとは
- 昨日やったこと
- 今日やること
- 困っていること
の3点についてGitHub Projectを見ながら行うことにしました。
そこでもし、開発中なのに、TODOレーンにいるIssueがあったり、開発完了しているのに、Doingレーンにいる場合、Doneレーンに移すなどの作業をすることにしました。
GitHubプロジェクトボードを見ながらIssueベースで話すので、話題に困ることがなく、手間もなくて良い感じです。オススメです。GitHubプロジェクトボードの形骸化も防ぐことができます。
また、弊社はリモートで開発するメンバーもいるので、GitHub ProjectでMTGすることでリモートの開発者もやり易くなりました。
アクション⑨ 開発チームのMVV(Mission Vision Value)導入
アクション① - ⑧で、仕組みは出来上がったものの、開発チームとして何を目指すのかわからないと、作業をこなすだけになってしまうので、開発チームとしてのMVVを設定することにしました。
MVV(Mission Vision Value)とは
- Mission Vision Valueの略
- Mission：「ワクワクドキドキするチームが成し遂げようと目指す事柄=最終目的」
- Vision：「ワクワクドキドキするチームの将来を描いた姿」
- Value：「チームの価値観」
あなたはVisionとMissionを説明できますか？ より参照
弊社、開発チームのMVV紹介
初めての組織デザイン：Vision-Mission-Valueの可視化フレームワーク で紹介されているVisionMissionValueフレームワークVer1.0 というテンプレートを使いました。
Valueは、以下、アジャイルの資料を参考にしました。
改善後の開発体制
プロジェクトの目的、開発案件の優先順位、全案件の見える化など実現することができて開発チームの作業が随分とやりやすくなりました。
最後に
今回の開発体制構築はひと段落したものの、まだまだ問題点はあって、今も、新しい試みをしてます。
- プランニングポーカー導入
- Product Owner Support制度の導入
など
プランニングポーカー導入についてはまた、記事化したいと思います。
最後までお読みいただきありがとうございました！！
＊カンバン(Kanban)方式については、チーム開発の枠組みと、それを支えるツール・役割の用語解説というスライドで歴史から解説していますのでご参照ください。
[宣伝] GAS入門の教材 - Udemy
- 2023年11月時点で、約3,000人の受講生を獲得し、UdemyBusinessにも選定されてます
- もしGASに興味があれば、以下のバナーからUdemyにて購入ご検討ください