Now Loading...

最近やってるストーリードリブンの進捗管理

こんなはずではなかった・・・というプロジェクトマネジメントからの脱却

こんにちは。月刊(?)Pick Paeriaの山口です。最近バタバタしているので、そのバタバタっぷりをそのまま記事にしたいと思います。

突然ですが、スクラムというプロジェクトマネジメント手法があります。ざっくり説明すると

  • チームでこなせる工数(ポイント)を決める
  • できる限り、リリースまでに必要な体験のストーリーを立てる
  • 1−2週間などの単位をスプリントと呼び、スプリント単位でストーリーを消化していく
  • スプリントでこなせるポイントはチームで決めておき、その分だけタスク予定をたてる
  • タスクは誰がとってもいい
  • 開発に関しては手を動かさないスクラムマスターを設置し、横槍からチームを守る
  • 最終的にプロダクトのジャッジをするのはプロダクトオーナー。スクラムマスターと時には喧嘩もする
  • スプリントの終わりには振り返りを行い、次回のスプリントに生かす

みたいな回し方です。 (認識誤っていたらツッコミ大歓迎です!)

大規模開発で回すにはいいのですが、小規模でやっているとスクラムの方に手間がかかってしまって本末転倒・・・そこで、スクラムからおいしいところだけ奪ってくることにしました。いわゆるストーリー管理です。

最近、社内では自社の新規サービスの開発をしています。実際、事業開発しながらものも作っていく必要があります。そこで進捗管理をどこまで頑張るかと思った時に、ポイントもタスクも正直各職種に委任するからとりあえずこのストーリーだけは今週頑張ろう、というやり方で進めていてそれなりによく回っているのでご紹介したいと思います。

大事なのは計画、予定、実績でまわす

モザイクだらけなのはご容赦ください。おおよそ2日に1回この表をベースに30分−60分程度で状況確認と課題のシューティングをしています。

おおよそのストーリーはプロダクトオーナーの僕が立てるのですが、それに対して何をその週に倒すべきかという小ストーリーは、基本的に各職種のメンバーが立てます。メンバーが立てます、と言っても本件、僕を入れて3人+α(うちが苦手な部分を巻き込んで適宜アドバイスをいただいている皆様)という規模です。

計画は最初の最初に立てたもの、予定は直近の状況を見て立てるもの(3wの金曜に4wの予定をたてる)、実績は実際どうだったかを書くものです。つまり、毎週予定はアップデートされていき、計画と予定との差分を認識してくことになります。これは次回の予定の精度を高めるのに役立ちます。

また、メンバー全員がプロダクト開発以外も含めた横の動きが見えるようにし、「プロダクトだけを見た都合ではなく」毎週優先順位の入れ替えができる形、自走しやすい情報量を担保しています。また、適宜計画と実績を修正し、「あれ、自分が思ってたよりできてた、できてなかった」と振り返りやすくもなり、なあなあで進むのも防げます。

さも当たり前のように書いていますが、実際は0−2wの時にやっていたことのほとんどはビジョンの共有と戦略戦術に対するメンバーの腹落ち口説きでした。プロジェクトオーナーがトップダウンであれこれ指示するほど、うちのような規模の組織では余裕がありません(というか、社長が1日社内にいられることのほうが稀)。となると、各人が自走できる必要があり、将来に何があるから今これをやるのだ、ここに行き着きたいならこの優先度はきっとこうあるべきだ、という認識、腹落ちができていないと進められません。(逆に言えば、この辺りがうまくいかないと、ずっとプロジェクトオーナーがボトルネックになるプロジェクトが生まれてしまいます・・・。)

こうなると、タスクを細かく出せることよりもストーリーの修正、入れ替えの方が重要になり、「これが叶えられるもので任せる!」という、ある意味丸投げ的な依頼になるのですが、目的が握れているので大きくずれたものが出来上がることはほぼありません。

もちろん、受託開発であれば作るもの自体にもコミットしているためここまでの振り方はほぼありませんが、自社サービスのようにある程度自由のきくものであれば、メンバーに判断する場数をたくさん踏んでもらいやすくもなり、それをまた受託開発時の判断の確度へも生かしやすくなっていくループが生まれて、とちょっとした育成タスクにもなっているように思えます。

結局は、自分がやっていることは事業の中でどの部分なのかを知ること

今開発してるものは誰がどう使って、それはどのタイミングでリリースされるからどんな機能が必要なのか?ストーリーベースで開発を動かしていると、自然にそういう発想になります。

ユーザーストーリーというと大げさですが、例えば営業が使うシステムを営業フローや実際に動く営業規模が明確じゃないのに作り込んでも意味ないよね、であったり、ユーザがやってきて最初にやりたいことに対してこの機能を使うまでにはいくらか成長期間がないとつらいよね、であったり、フラットに考えてしまうと「これは普通作るでしょ」といったものでも冷静に優先度を判断できます。

大規模運用サービスだとこうもいかない部分もたくさん出てくると思いますが、これ誰に対して何のために作ってるんだっけ?というのも十分プチUX戦略として有効だと思うので、よかったら試してみてください。できないところを巻き込む時に自分のストーリーを人にうまく語れなかったらまだ詰めが足りないよね、など振り返れるため、伸びしろとしてもおすすめです。

今やっていることは何に繋がってるんだろう?が明確にわからないなと思ったら、ぜひ身近な同僚か上長にぜひ聞いてみてくださいね!

株式会社パエリア
〒150-0043
東京都渋谷区道玄坂1-15-3
プリメーラ道玄坂 328号室
our service