開発に“生産性指標”を持ち込み起こった変化　Four Keysを可視化して分析することで得られたメリット

生産性の指標を持ち込んだことによって得られたメリット

大仲能史氏（以下、大仲）：そして最後に、改善を後押しする力ですね。

我々はもともと2週間イテレーションで開発していたという話をしました。イテレーションをやっていると、すごく改善しやすいんですね。

「1イテレーションだけ試しましょう」という合言葉があります。イテレーションのふりかえりで、次のふりかえりの時にKeepするかどうかを判断できるので、「まず、お試しで入れてみましょう。悪かったらやめるし、良かったらそのままKeepしましょう。なので、試させてください」というのがすごく言いやすい。イテレーション開発をしていると、変化を許容しやすい文化が生まれます。

我々がもともと持っていた価値観を、当時はてなに所属していた「id:Songmu」が言っていました。「業務や開発フローは、『変えることは無条件に正しい』くらいに思っていていいと思っています」「素早く変えて、もし仮に駄目だったら素早く戻せばいい」と。この精神でふだんからやっていました。

ここに、生産性の指標というものが持ち込まれたことによって変化が訪れています。これは、課題をすごく共有しやすくなるということですね。今どんな問題があるのかを定量的に表現することができます。

「ほかのチームはレビュー速度が平均で6時間ぐらいだけど、我々は24時間以上かかっているよ」とか、「ここにムラがあるよね。人ごとに差がある」とか。あと、リリースするまでの速度だったり、生産性指標としてよく知られているFour keys、リードタイムだったりが遅いことが如実にわかったりします。

「これが問題である」と、課題の大きさを数字で伝えることができることによって、共有しやすくなります。

そして、変更の後の結果を共有できるというのも、生産性指標を取り始めて変わったことでした。「実際にやってみたらこう変化したよね」というのが数字で、グラフでわかるのは、すごくおもしろいですね。数字で表現されるので、ゲーミフィケーション的になって、「じゃあ、もうちょっと上げてみよう」みたいなモチベーションが生まれたりもします。

個々人で変化の受け止め方の差がある。「自分は良くなったと思っていない、むしろ悪くなった」と思っている人がいても、数字をもって黙らせることができるので、データドリブンで話す。ギャップを埋める材料があり、共通言語が提供されるという状況が生まれています。

まとめ

ということで、まとめに入ります。イテレーティブな開発には、改善を後押しする非常にいい効果があるので、イテレーティブに開発をして改善していきましょう。ここで、生産性の指標を取得していると改善が非常に加速します。改善の導入障壁が下がるんですね。

改善の必要性を伝えられたり数値で表せられるので、より改善に参加しやすくなる。チェンジマネジメントでいう動機付けの部分を乗り越えるのがすごく楽になるので、改善を入れる数が増えます。データに基づいた具体的な会話になるので、結果をお互いに共有できます。

私からは以上です。では、内田さん、お返しします。

アジャイル開発に取り組む企業の利用が増えている「Findy Team+」

内田博咲也氏（以下、内田）：ありがとうございました。本当に、いろいろな改善をされていく中で、生産性指標も取得して、さらに加速しているというお話だったかと思っています。あらためて、ありがとうございます。

最後にファインディからぜひご案内させてください。

実際に、はてなさんの開発生産性はこんなかたちで見えます。まず、折れ線グラフがリードタイムですね。メチャクチャ下がり、安定しているのが見えるかなと思います。先ほどタスクについてのお話がいろいろあったと思いますが、そこのリードタイムが下がっているのが一目でご覧いただけると思います。

実際にTeam+が、お話にあったFour Keysの可視化やボトルネックの発見にご活用いただけるものになっていて、直近だと、それこそウォーターフォールからアジャイルに変えた時の効果を説明していく文脈でご利用いただいたり。

あとは、外注から内製に切り替えるタイミングで、「本当に内製に切り替えて開発スピードは上がったんだっけ？」や、「開発のボリュームは増えたんだっけ？」というところの効果説明など、それをさらに推し進めていく文脈でご利用いただくことも増えてきました。今たくさんの企業にご利用いただいていて、アジャイル開発に取り組む企業さまのご利用がすごく増えてきています。

なので、ウォーターフォールからアジャイル開発に切り替えていくタイミングで、その効果説明の文脈においても、少しでも興味をお持ちいただきましたらブースでお待ちしています。

では、本日の発表は以上になります。ご清聴いただきましてありがとうございました。

（会場拍手）

2、3人組のユニットをどのくらいの期間固定するか？

司会者：大仲さま、内田さま、ありがとうございました。ここからは、Ask the speakerに移ります。質問がある方は、挙手をお願いいたします。

ただいまマイクをお持ちいたします。よろしくお願いいたします。

質問者1：お話をありがとうございました。TDCソフトのイケダと申します。WIP制限に関する対策のところで、2、3人組のユニットを作るという案があったと思います。私もこれを実際にやったことがありまして、非常に効果があるなと思っているのですが、そのユニットをどのぐらいの期間固定するか、いつも悩んでいます。

ある程度の期間、2、3人で作ったユニットを継続して、1個タスクが終わっても、その次のタスクもそのユニットでやる、とやるのか、ある程度タスクごとにユニットをシャッフルというか、メンバーをシャッフルするほうがいいのか、けっこう悩むんですが、そこに関して知見などがありましたら教えていただきたいと思います。

大仲：完全に完成されているチームだと、本当にタスクごとにバラバラにすることも可能かもしれません。我々の場合は、新卒教育、OJTとしてユニットを組んで、そのペアの人から教わるみたいなことをやろうとしていて、「1年間で3、4人師匠ができるとちょうどいいよね」みたいなことを考えていました。

なので、3ヶ月から4ヶ月ぐらいでユニットを切り替える。その頃には、大きな開発方針というか、メインタスクも変わっていくよねというところで、3ヶ月ぐらいの大きなタスクを1つと考えて進めることが多かったです。

質問者1：はい、ありがとうございました。

司会者：ありがとうございました。

カイゼンへの適用に取り組んでいること

司会者：そのほか、いかがでしょうか？　ご質問はどうでしょう？　

話者1：「Miro」のほうにいっぱい来ているんですよね。よいしょ、よいしょ、よいしょ、よいしょ。

お名前を書いてくださっている、これにしてみましょうか。「お話にあったのは、物的生産性のように見受けられましたが、アジャイルがより重きを置いている付加価値生産性の指標化（CVRなど）、カイゼンへの適用にはなにか取り組まれていますか？」。

大仲：そうですね。デュアルトラックアジャイルとして、ディスカバリーのトラックとデリバリーのトラックというものがよく言われると思います。

我々は、デリバリーがお粗末だと、どれだけいい企画があってもリリースするまでに時間がかかるよね、と考えているので、まずはきちんと自分たちの車のメンテをして、いつでもトップスピードを出せるようにしておくというのを、開発チームの目標としては持っています。

企画も含めた実際のプロダクトチームとしては、デリバリーも含めてユーザーに価値を提供できているのかを追っていきたいのですが、開発チームとしてはまずデリバリー速度を高めておく、というのを目標にやっていました。

内田：ありがとうございます。実際にFindy Team+でも、CTO、VPoE、マネージャーの方とお話しすると、やはりいわゆる付加価値であったり、事業KPIの部分とひもづけた開発組織の可視化向上みたいなところをやっていきたいというお声はすごくあります。そこはぜひ今後も取り組んでいきたいテーマとなっています。ご質問をいただきまして、ありがとうございます。

司会者：ありがとうございました。

ベロシティとストーリーポイントの両方を見ている

司会者：会場は質問いかがですか？

大仲：（「Four Keysが流行っていますが、それ以外で御社で取られているメトリクスなどありますか？」というMiro上の質問に対して）Four keys以外で取っているメトリクス？

開発の生産性に強く相関があるのはFour keysであると信じているので、これに従っています。チーム運営上、別のメトリックも取れていると便利だなというのは、トークでもお伝えしたとおりです。

そうだな……これは私が個人的にやっていることなんですけど。コメントの往復が増えてくると、「そろそろリアルに電話して、同期的に話したら？」みたいなことをサジェストするとうまくいくというのがあるので、コメントが増えてきたら即アラートになるとか。

あと、プルリクを出してからマージまで時間がかかっているものがある時に、リードタイムアラートということで、Findy Team+からアラートがSlackに飛んでくるようになっているので、「このタスクは、きちんと進んでいますか？」というのを監督しやすい、モニタリングができている状況が作れているかなと思います。

内田：併せて、お聞きしたいんですけれども。たぶん、アジャイルを始めた時、最初に取る指標としては、ストーリーポイントやベロシティが多いのかなと思っています。

そういう中で、ベロシティを見ていますという状態と、一方で、Four keysが流行っているみたいなお話があるじゃないですか。ここの切り分けだったり、概念としてどういうふうに整理していくみたいなお話がもしあればおうかがいしたいと思うのですが、このあたりはいかがですか？

大仲：回答としては、「両方見ています」になります。スプリント、イテレーションごとの消化ポイント数みたいなベロシティを測るのは、我々の現在の健康度のバロメーターとしてもう確立されているので、これは知見を大いに活かさせてもらっています。

Four keysがどれぐらい直接的に影響しているかは、すべてが高いと生産性の高い企業であるとわかっていますが、ここが高いとどうなるかというのは、まだ解明されているわけではありません。

（スライドを示して）左下の、この「デプロイを測っていく中でどんなことに気づけたか」というのもあります。デプロイ頻度を上げていく上で、どんどん問題にぶち当たって、改善し続けると、ベロシティも実際上がっているので、動きの速いチームに変わっていっているのが見えてくる。

というところから、デプロイ頻度に相関があるというのはわかってきていますが、ベロシティやストーリーポイントも同時に使っていますね。

内田：急な質問だったにもかかわらず（笑）、ありがとうございます。

話者1：ほどよい時間になりましたが、会場からもよろしいですかね。

司会者：お時間となりましたので、ご講演を終了とさせていただきます。大仲さま、内田さま、ありがとうございました。