はじめに
こんにちは。株式会社PoliPoliで開発をしている高野です。
私のチームでは、限られたリソースの中で開発以外の様々なタスクにも日々対応しています。
この記事では、スタートアップの予測できない毎日をうまく乗りこなすために、独自のルールで実施しているスクラム開発での取り組みと、スタートアップとして直面する課題についてご紹介します。
スタートアップにおける課題
A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.
（スタートアップとは、極度の不確実性の中で、新しい製品やサービスを創り出すための人間の組織である。）
スタートアップでは、日々状況が変化する中で、仮説・検証を繰り返しながら、製品やサービスを成長させていきます。
その過程で、想定外の課題が発生したり、優先順位をすばやく切り替える必要が出てくることも少なくありません。
また、限られたリソースを有効に活用するため、開発業務だけでなく、顧客対応、戦略検討、組織運営など、さまざまなタスクを同時にこなしていく必要があります。
多様なタスク
以下は私の日々の開発を除いた業務の一例です。
-
契約関連
- SLAやセキュリティマニュアルなどの書類作成
- 製品導入時に、顧客企業のセキュリティ基準をクリアしているか確認
-
ユーザーインタビューと戦略検討
- 利用者の声を直接聞くユーザーインタビュー会の日程調整と実施
- フィードバックに基づく次の戦略や方針の検討
-
組織開発
- 双方向評価制度の対応
- 1on1
- オンボーディング
-
採用活動
- 外部イベントへの参加
- カジュアル面談
- JD作成
- ブログ記事作成
-
運用業務
- プロダクト運用改善
- 顧客からのお問い合わせ対応
- 部署外からの技術相談対応
-
管理業務・その他
- タスク・バックログ管理、OKR進捗管理、ミーティング準備
すべてを一人で行っているわけではありませんが、チームメンバーと連携しながら状況に応じて柔軟に対応しています。
スクラム開発の取り組みと実践事例
スクラムについては多くの方が分かりやすい記事を書いているため、詳細な説明は省略します。以下のリンクは公式の実践ガイドとスクラムの歴史についてです。
開発以外のタスクの可視化と管理
前項のとおり、私のチームでは一人一人が開発以外のタスクも多く対応しています。突発的な差し込みタスクも頻繁に発生し、外部の対応待ちでストップしてしまうケースもありました。
問題点
- 開発タスクの工数の見積もり精度にばらつきがある
- 開発以外のタスクにどれだけリソースを割いているのかが見えない
- 途中でストップしているタスクが埋もれる
- 優先順位が不明確
取り組み
- 開発以外のタスクもプロダクトバックログでまとめて管理
- 着手後に完了時期が不透明になったプロダクトバックログアイテムは確実に終えるために定期的にリマインダーを設定
効果
- 非開発タスクの可視化により、スプリントプランニングでの計画が正確になり、実施結果のずれが減少
- 外部依存のタスクもプロダクトバックログ上で確認できるようになり、未完了タスクの管理漏れが減少
- 優先順位の更新が仕組み化され、バックログで常に正確な優先順位の確認が可能になった
課題
- プロダクトバックログに含める基準が曖昧なため、認識合わせの時間が度々発生する
- スプリントプランにまでに、見積もり可能な状態のプロダクトバックログアイテムの作成が間に合わない
- スプリント期間中に発生したタスクや、途中で止まったバックログアイテムの扱いが不明確
- 急な差し込みタスクの頻度によって、スプリントごとのストーリーポイント（SP）消化実績に大きなバラつきが発生
Notionスプリント機能の導入
私のチームではこれまでタスク管理ツールに、GitHubのissuesやClickUpを使ってきましたが、事業部とのやりとりや、過去の開発時の情報が分散し、リファクタリングや引き継ぎを行う際に、過去の情報を見つけるのに時間がかかってしまっていました。そのため要件のすり合わせや設計時のメモなども、社内全般のタスク管理に利用しているNotionに集約しています。
Notionに移行後、当初はNotionのリレーション機能などを駆使してプロダクトバックログ、スプリントバックログを関連付けて管理していましたが、スプリント機能が追加されていたことを知り、新しいプロジェクトの立ち上げに伴ってスプリント機能を導入しました。
効果
- 一度スプリント機能での運用環境をつくり、テンプレート化さえすれば、新しくプロジェクトが立ち上がった場合に、すぐにスクラムに必要な環境が準備できる
- 次のスプリントは自動で作成され、未完了のスプリントバックログアイテムも自動で次のスプリントに移動するため管理コストが減少
課題
- 一つのプロダクトバックログアイテムをさらに分割してタスク化する場合、手動で紐づける必要がある
- ベロシティの測定機能がない
スクラムを実施して見えたもの
新たに発生した課題
従来の課題に対応するために独自のルールを導入しましたが、そのためスクラム開発を行う上でたくさんの判断基準が必要になるなど新たな課題も出てきました。またスクラム開発は、管理するものも多く、Notionの機能だけでは対応しきれない複雑な運用ルールであることも改めて実感しました。
小規模チーム特有の役割の曖昧さ
状況に応じたスピーディな意思決定や、固定化されたリーダーシップにとらわれない柔軟なチーム運営ができる一方、私のチームでは一人一人が複数の役割を担うため、従来の職能分業が明確になっていません。そのため、スクラムで定義されるプロダクトオーナーやスクラムマスターといった役割の境界も曖昧になりがちです。今後、メンバーごとの役割を明確にし、それぞれがその役割の達成に集中して成果を上げていくために、どんどんメンバーを増やしていく必要があります。
まとめ
スクラムの導入によって、スタートアップ特有の不確実性の中でも、チーム全体が共通のゴールに向かって迅速かつ柔軟に対応できる体制が整えられてきました。
特に、開発以外のタスクの可視化と優先順位の明確化により、リソース配分が適切になり、業務の停滞を防ぐことができました。また、Notionスプリント機能の導入により、タスク管理の効率化が図られ、プロジェクトの進行状況をチーム全体で共有しやすくなりました。
一方で、 スクラムを効果的に運用するためには、メンバー間の認識合わせや役割の明確化、独自ルールの適用など、多くの判断を伴うことが課題として残っています。
特に、小規模チーム特有の役割の曖昧さは、意思決定のスピードを上げる一方で、責任の所在が不明確になりがちです。
今後、役割を個別に最適化し、各メンバーが本来の強みを活かせる体制にすることで、チーム全体の生産性を向上させたいと考えています。
最後に
ということで、株式会社PoliPoliでは、プロダクトオーナーやさまざまな役割を担ってくれる新たな開発メンバーを募集しています！
日々大きく成長していくスタートアップ企業のダイナミズムを肌で感じませんか？
共に楽しく開発してくれる方をお待ちしています！
採用情報
国民と政治・行政が政策を共に創る社会を。政策共創プラットフォームを運営する株式会社PoliPoli（ポリポリ）の公式開発ブログです。公式サイト: polipoli.work
Discussion