ワークスの元同期がブログでインターン先のPractice等を紹介していたのを見て
「おお」と思ったので、ボクも今の組織のPractice関係もろもろを紹介してみます。

Agile

はい、出たアジャイル 笑
ハイテク企業でPMやってるMBAが
ドヤ顔で使いそうなバズワード第一位な気がしますが、笑
ボクらの組織もアジャイル開発してます！

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。

– Wikipediaより

まず開発期間の単位ですが、
3ヶ月くらいの大きな開発期間をエポック
そのエポックを何個かに分けた一つ一つをスプリントと呼んで、開発しています。
スプリントはチームによって2〜4週間とバラツキがありますが、
大体そのくらいの粒感で行ってます。
このくらいの期間だと進捗管理が簡単で、かつ意味のある単位の開発ができます。

Team

人々については前のログでも触れてますが
今回はもう少し役割にフォーカスします。

Product Developmentという観点からは、
僕らのチームには3タイプ

• プロダクトマネージャー
• データサイエンティスト
• エンジニア

という役割があります。

チームによっては、これにプラスしてUXやOps、QA、PMOが入ります。

一つの役割に対してどのチームも1、2人なので
チームでの議論はそれぞれが全く異なる立場から発言するので、
インプットが多様でクリエイティブな解決策が生まれやすいです。

アジャイルのスクラムという観点からは
役割は二つで、

• スクラムの責任者のスクラムマスター
• プロダクトの責任者のプロダクトオーナー

があります。

ボクのチームではボクがプロダクトオーナーを、
エンジニアリングリードがスクラムマスターをしています。
これらの役割の詳細は下記プラクティスで説明します。

Practice

意外とアジャイル開発初めてだったりするので
プラクティスで「ほぅ」と思うことは結構ありました。

Stand-Up

チーム内での進捗のカジュアルな報告です。
大体10分〜30分で名前の通り立って行います。
立って行う目的は、早く終わりたくなるため。
座って進捗報告するとダラダラと
進捗と直接は関係ないことまで話してしまいがちですが、
立って行うことで「早く終わらせてぇ」
という意識を常に持つことができます。
僕らは2日に1回の頻度でしてます。
この頻度で進捗管理を行うことで
周りに聞けばわかることに何日も費やすことがなくなり
しょうもないことに詰まりにくくなります。

Scrum of Scrum

それとは別に1時間の部署全体の進捗ミーティングが
週1であります。
参加者は各チームのプロダクトオーナー、もしくはスクラムマスターで
それぞれその週の進捗をパワポのスライド1枚で報告します。
それぞれ報告時間は5分くらい。
ボクのチームはせっかくなのでボクにやらせてもらってます 笑
簡単に言うとスタンドアップの部署全体版で、
チームとして詰まってるとこがあったら
他のチームで同じ問題にハマったチームはないかとか
リソースを他のチームからもらえないかとか
そういう話をします。
このミーティングにはディレクター陣とVPも参加しています。
また二週間に一回、VP陣とCEOで同様のことを全社レベルで行っています。

Sprint Planning

リポーティング以外で「おお」と思ったのは、
各スプリントのプランニングの仕方です。

各スプリントを始める前に、
そのスプリントで何をするのか決めるのですが、
そこでPlanning Pokerというトランプのようなものを使います。
カードには1, 2, 3, 5, 8, 13, 21とフィボナッチ数が書かれていて
それが工数を表しています。
裏にはトランプのように全てのカードに同一の絵が描かれていて、
裏からはそのカードに何の数字が書いてあるのかわからないように
なっています。

バックログにあるそれぞれのユーザーストーリーに対して
ユーザーストーリーを書いた人が内容とおおまかな工程を説明して
それを聞いたメンバーがそれぞれカードを裏にしたまま出します。
みんながカードを出し終わったら、表にして数字を比べます。
みんなが出した数字が同じだったら
その数字がそのユーザーストーリーの工数になり、
違った場合は、
一番小さい数字を出した人と一番大きい数字を出した人が
それぞれその数字の理由を説明し、再度カードを出します。

まず、なぜポーカー形式で工数見積もりをやるのかというと
このやり方でやることで、声の大きい人の影響を受けにくくなり
それぞれバイアスのない状態で議論が開始でき、
数字が大きくずれた場合にちゃんと意見表明する場が与えられる
からです。
これで「ホントは自分はこう思ってるんだけど、
まぁやる人がそう言ってるんだし、いっか」がなくなります。笑

次になぜフィボナッチ数でやるのかですが、
これは工数が大きくなればなるほど、見積もりがブレるからです。
なので5の見積もりと6の見積もりに本質的な差はなく
そこに議論の時間を費やすのを防ぐため、
フィボナッチ数が使われています。

Thoughts

ということで要約すると「アジャイル」です 笑
今の部署のプラクティスでよいと思っていることはたくさんあるのですが、
前職の方がよかったと思うこともいくつかあって、
その代表がユーザーストーリーのレビューがあったことです。

今の部署ではそれがなんとなくスプリントプランニングで行われているので
ユーザーストーリーのクオリティが
プロダクトマネージャーのユーザーストーリーを書く能力に結構依存しています。
ユーザーストーリーがちゃんと書ける人を採るっていう方針みたいなので
今のところ問題は出てないのですが、笑
組織的にユーザーストーリーの質を担保する仕組みがあってもいいのかなー
と思ったりもしてます。
他の部署ではグルーミングセッションをスプリントプランニングの前にやって
ユーザーストーリーの質を担保しようとしているところもあるっぽいです。

ちなみにアジャイルはテック以外の企業でも十分成立する仕組みだと思います。
もしかしたらテック以外の企業でも使われているところは多いのかもですが
もし、ご自身の会社/チームで使われてないのであれば
試してみても面白いかもしれません。