シェア
はてブ
2024年6月28日、ファインディ株式会社が主催するイベント「開発生産性Conference 2024」が開催されました。本記事では、株式会社カケハシでエンジニアリングマネージャーを務める笹尾 納勇仁さんによるセッション「プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの」の内容をお届けします。
「Musubi AI在庫管理」のプロダクト開発チームにおいて、各メンバーが役割をまたいで協業しつつも、個人のスペシャリティを活かしながら、プロダクト検証サイクルを効率化する目的と、その達成のためにチャレンジしたこと、その成果についてお話いただきました。
■プロフィール
笹尾 納勇仁（ささお なおひと）
株式会社カケハシ エンジニアリングマネージャー
「沢山の埋もれた力を最大限に発揮できるようになれば、多くの人がもっと楽に成果を上げられる。」「チームが自律的に行動し無意識に成長できれば、最高のプロダクトやサービスを生み出せる。」の実現を常に目指すEM。スタートアップのVPoEとして組織システム構築の再現性を上げたのちに、これまでの経験を大きな社会貢献に繋げるためにカケハシに参画。EMになる以前はエンジニア兼マネージャーとして大手自動車会社のテレマティクス分野におけるWebアプリケーション開発や、開発・運用フレームワークの開発、アプリケーション配信プラットフォームの開発などに携わる。
医薬品の在庫管理システム「Musubi AI在庫管理」を開発
笹尾：こんにちは、笹尾です。僕は多くの人がもっと楽に成果を上げられる方法を探しながら、最高のプロダクトやサービスを生み出せる環境を目指して組織づくりをしています。自己紹介が苦手なので、まずは僕の好きな言葉を紹介させてください。「ボールは丸くて、試合は90分」。ドイツのサッカーの生みの親と言われる人物の言葉です。
限られた時間の中で、ありとあらゆる手を尽くして、ゴールを決めて勝つ。そんなふうに、あらゆる手を尽くして自律的に行動し、無意識に成長でき、最高のプロダクトやサービスを生み出せるチームをつくりたい。さらには、たくさんの埋もれた才能が最大限に発揮され、多くの人がもっと楽に成果を上げられる、そんな世界を目指しています。
僕が所属する株式会社カケハシでは、「日本の医療体験を、しなやかに」というミッションを掲げています。そして、「高潔・価値貢献・カタチにする・無知の知・変幻自在・情報対称性」という6つのバリューを掲げ、それらをメンバーが自ら体現するチームを目指しています。
その中で、僕は「Musubi AI在庫管理」という、調剤薬局で取り扱う医薬品の在庫を管理するプロダクトを開発しています。本日は、その開発チームの中で各メンバーが役割をまたいで協業しつつも、個人のスペシャリティを生かしながら、プロダクト検証サイクルを効率化する目的と、その達成のためにチャレンジしたこと、その成果についてお話させていただきます。
なお、本発表の内容には、制約理論というマネジメント理論をもちいて解説する場面があります。できる限り丁寧に説明しますが、詳細を知りたい方は、『ザ・ゴール』という書籍を参照いただければと思います。ちなみに、僕は難しい本が苦手なので漫画版しか読んでいません。
そして、本日の発表内容は、私が入社してから約1年半にわたるチームの変化と併せてお話します。いつ何が変化したかについて、ところどころ時系列を示しながらお話したいと考えています。本発表の大まかな内容はこちらです。
事業における生産性、開発組織における生産性とは何か？
笹尾：さて、本題です。事業における生産性とは何でしょうか？ すぐに答えられる方、少し悩む方もいるかもしれません。では、事業を行う会社のゴールとは何でしょうか？ 先ほど紹介した書籍を読んだ方はわかるかもしれませんが、利益を出すことが会社における共通のゴールです。
先ほど紹介した制約理論でも、生産性について定義されています。生産性とは、会社のゴールに向かって会社を近づける行為そのもの。会社のゴールに少しでも会社を近づける行為は生産的で、反対にゴールから遠ざける行為は全て非生産的である、と書かれています。
笹尾：行為は人によるものです。だから、僕なりに考えついた、事業における生産性が高い状態とは、従業員1人当たりの利益を最大化させている状態でした。では、開発組織における生産性とは何でしょうか？
まず、開発生産性の計測に適さないものから挙げていきたいと思います。ベロシティは、アジャイル開発でよく使用される作業の指標で、事前に見積もった数値がどれぐらい消化できたかを計測して、自分たちのトレンドを知ることができるものです。つまり、特定の期間に完了できる作業の量を、チームが推定しやすくなるんですね。
見積もりというのは、相対的な尺度です。何らかの効率が上がったりすると見積もり自体が変化するので、生の数字にはほとんど意味がありません。ベロシティが上がっているときに、開発生産性が上がっているという保証はどこにもないんです。
では、成果物の量で測るのはどうでしょうか？ 実は、開発における成果物が利益を生むとは限りません。我々が開発しているようなSaaSの場合、機能開発を行ったからといって必ず売れるわけでもないんですね。
売れたとしても利益が出るかわからないし、持続性や拡大の確証もない。実際に利益が出て成長中のプロダクトですら、単一の機能開発における利益を測定することは困難だと思います。成果物には、運用コストや保守コストがかかるものもたくさんあります。だから、つくればつくるほど利益が出る、なんてことは絶対にありません。
さて、開発組織における生産性に戻ります。会社のゴールとなる利益に会社を近づけられているかわからないまま、生産性を判断して良いのでしょうか？ 利益に紐づかない生産性があって良いのでしょうか？ 改めて、事業から考えてみます。事業の生産性を上げるには、ビジネスのサイクル全体で利益を最大化する必要があります。
制約理論では、3つの指標で考えます。「スループット」とは、販売してつくり出すお金の割合、入ってくるお金のことです。「在庫」とは、販売しようとするものを購入するために投資したすべてのお金のこと。現在のプロセスの中に留まっているお金とも言えます。
「業務費用」とは、在庫をスループットに変えるためのすべてのお金のことで、スループットを実現するために支払うお金です。慣れないと少しわかりづらいですが、大事なのはすべてお金で考えるということです。
笹尾：効率ではなく、会社のゴールとなる利益を追求する。そのためには、生産能力を需要に合わせるのではなく、需要にフローを合わせる必要があります。フローを改善するには、ボトルネックを解消する必要があり、ボトルネックは仕掛品の多い部分で判断が可能です。制約理論には、ほとんどの場合で効率を求めるとゴールを達成できないと書かれています。効率を考えなければ、むしろ現場でやることはもっとたくさんあるはずです。
『ザ・ゴール』では、フローをハイキングの隊列で表現しています。ハイキングでは先頭から最後尾まで、メンバー全員が見通せる距離を保ったまま、予定通りに目的地に着く必要があります。もし隊列がバラバラになって、動ける人が先にどんどん進んでしまったら、安全なハイキングとは言えませんよね。最後尾の人が、予定の時間までに目的地に着けない可能性もあります。
だから、制約理論では「ドラムバッファロープ」で進むことが推奨されています。隊列の中で一番遅いメンバーのペースに合わせる「ドラム」、予定や計画に適度な余裕を持つ「バッファ」、そしてメンバーが離れ離れになってしまうことを防ぐ「ロープ」です。
それを実際の生産に当てはめると、「ドラム」はボトルネックに合わせてプロセスをつくること、「バッファ」は適度に余裕を持ったリードタイムを持つこと、そして「ロープ」は早すぎる仕掛りを防ぐことにつながります。効率を考えないので、常に全員が忙しい状態を求めることもなく、負荷を分散しながら、ボトルネックを解消していくことが大切になります。
見積もり漏れからの大幅な遅延発覚、問題解決への対処
笹尾：説明が一段落したので、ここから開発の話に戻ります。先ほどの「利益に紐づかない生産性があって良いのか」という問いについて、会社のゴールに少しでも会社を近づける行為は生産的となるので、良いと考えて進むことにします。つまり、開発組織の中でも、常に全員が忙しい状態を求めず、負荷を分散しながら、ボトルネックを解消していくことを目指します。
ここで僕が入社した2023年2月頃の、「Musubi AI在庫管理」の状況について整理しましょう。スモールビジネスセグメントでは一定の導入が進んでおり、ミドルビジネスセグメントでも導入を開始。エンタープライズセグメントの要望も取り入れ始めている段階でした。
お客様のビジネス規模は、システムに大きな影響を与えます。実際に、現場には大量の機能追加の要望が上がっていました。そうしたなか、システムでは既存の設計では解決が難しい問題が見つかるなど、技術的負債が顕在化したり、既存概念や既存機能との矛盾が生まれ、それらに対処する中でプロダクトの複雑性が上がっていくなど、弊害も生まれてきます。これらは悪いことばかりではありませんが、開発メンバーの負担は確実に増えていきます。
実際にその頃、メンバーとの1on1の中で、「最近は以前ほど開発が進んでいない気がします」といった言葉を複数名から聞いたのを覚えています。そんな状況でも、市場の引き合いに何とか応えようと、機能追加などの要望をこなすためにチームは拡大。チームが成長する過程で、バックエンドチームとフロントエンドチームが分離するなど、スキルやロールによる分業化も進み始めていました。
笹尾：ところが、4月末に問題が発生します。見積もりの漏れが発覚し、6月末に計画した機能のリリースが、早くても9月末になってしまうことがわかったんです。フロントエンドの実装が間に合わず、リリースの制約になっていて、他の工程に比べて5ヶ月程度の開きがあることがわかってきました。この遅れが原因で、他の機能リリースも大きくずれ込むことが確実な状況でした。
ソフトウェア開発では、仕掛品が目に見えることはほとんどありませんが、フロントエンドチームの前には未完成の仕掛りが大量にある状態でした。仕掛りが大量に溜まってしまう部分というのは、先ほど言ったボトルネックで、すぐに解消する必要があります。
そこで、僕はプロダクトマネージャーに「フロントエンドチームが取り掛かっていること以外、機能開発に関わるすべての作業を止めてほしい」とお願いしました。フローを優先して進めたいということです。
もちろん最初は反対されました。ただ、今後の機能開発のための質問や確認をフロントエンドチームにお願いすれば、それに時間を取られて、さらに遅れることになります。フロントエンドチームが今頑張っているものがリリースされないと、結局は次のリリースに取り掛かることもできない。それを丁寧に説明し、フロントエンドの開発に全力を注ぐことになりました。
PdMもデザイナーもバックエンドチームも、フロントエンドチームが抱える課題を優先的に解決します。それだけでは手が空いてしまいますが、PdMとデザイナーは新たな機能仕様をまとめるのではなく、お客様の要求を精査するなどディスカバリーに専念。バックエンドチームは、大規模なリファクタリングなどを実施してもらいました。また、この問題解決に伴う作業時間を確保するため、同時にスクラムイベントなども停止しています。
価値を明確にしながら、ユーザーストーリーを小さく分割
笹尾：でも、フロントエンド以外の開発を止めて、フローを改善していても、ゴールには近づけていない状態です。ここで理想のチームについて考えてみます。僕が考える理想のチームは、個々の能力に関係なく、高い価値を生み出す集団です。ただ個人の能力を合わせていくだけでは、コミュニケーションなどのロスがあるので、全体の合計より低いパフォーマンスしか出せません。そこを超える何かが必要です。
そもそも利益というゴールの実現は、とても難しい。だからこそ、本質的な価値を優先して開発する必要があります。では、開発成果物がどうなれば、本質的な価値と言えるのか。見える形にできるでしょうか。そこで、開発への直接的な要求となるユーザーストーリーの改善を行うことにしました。
誰が、どんな理由で、どんな価値を、どんな状態で享受できるかをタイトルに記載して、そのユーザーストーリーを完了したときに、記載されたユーザーがどんな体験をするかまで明確にします。ユーザーのセグメントも細かく分類し、より具体的に記載することで価値を感じる人が明確になります。
そうやって記載してみると、今まで1つのユーザーストーリーに、いろいろな要素が詰め込まれていたことがわかりました。それを解消するために、ユーザーストーリーの価値を小さく分割していきます。
ただストーリーを分割すると言っても、価値を明確にしながら分割するのは簡単ではないため、分割の基準をガイドとして記して進めました。これにあたり、一緒に進めてくれたプロダクトマネージャーからは、「本当にこんなに細かく分ける必要があるんですか？」と言われましたが、「結果が出るまで無理のない範囲で続けてほしい」とお願いしながら進めていきました。
笹尾：そのような活動を通して、例えば「在庫調整において出庫処理と同様の形式で入庫処理を実施することができる」といった、目的や機能の理解が難しいユーザーストーリーが並んだ状態から、「適格請求書発行のための設定実施者は、設定済みの登録番号を取引先管理の法人間融通のデフォルト設定欄で確認することができる」といった、価値や機能が想像しやすい記載に変化していきました。
ここまで変化すると、お客様に対するインパクト、利用回数や運用の容易さなど、さまざまな価値を比較し、優先度やコストから判断して開発対象を絞ることができます。つまり、必要のないユーザーストーリーを探して、やらないと決めることができるんですね。プロダクトマネージャーにも、「スコープ調整で細かく捨てられる」とメリットを感じてもらえて、その後は率先してこうした活動を進めてもらえるようになりました。
笹尾：改めて時系列で見てみると、ユーザーストーリーの改善はこのタイミングです。ユーザーストーリーの改善で削ったスコープは、ボトルネックに対する負荷の軽減にも貢献します。
実は、この活動はフロントエンド以外の機能開発を停止する決断をしたおかげで、促進されている側面もありました。プロダクトマネージャーの手が空きやすくなったため、この活動自体を丁寧に進めることができたんですね。これこそが、常に全員が忙しい状態を求めず、負荷を分散しながら、ボトルネックを解消していくこと、そのものだった事例ではないでしょうか。
笹尾：こうして進める裏側で、フロントエンドのメンバーを倍の人数まで増やすことができ、8月末には新規に参画したメンバーが一緒に開発できる状態になっていました。人数的にも、フロントエンド開発のボトルネックが解消する兆しが見えてきたわけです。
ただ、フロントエンドの開発を押し進めているなかでの増員は、大きな賭けなんですよね。今フロントエンドの開発をしている人の手を止めてしまう可能性があるので、ジョインしたメンバーには、あえて「機能開発をしないで」とお願いして切り抜けていました。
不確実性を下げるために必要な、チームの理想の状態とは？
笹尾：では、この流れでゴールに近づけるのでしょうか？ いや、無理ですよね。なぜなら、需要に合わせたフローになっているとは、まだ言いがたい状態だからです。とはいえ、開発成果物がどうなれば生産性が高いと言えるのでしょうか？
冒頭でお話しした通り、ただ闇雲に開発成果物を増やすことは、決して良いことではありません。むしろ、保守コストや運用コストが増大して、利益を阻害する可能性すらあります。そこで、利益に対する不確実性を下げることが大事なのではないかと考えました。
利益を上げるために不確実性を排除し、確実に利益が出せるように繋げていく。利益が損なわれる不確実性も排除して、利益が失われないようにする。その両方が開発の役割だと、僕は考えています。その状態を視覚的に表すと、このような形になります。
タスク消化に対して、不確実性の高い部分を優先的に検証して、確実にゴールに近づけていく。では、その不確実性を下げるチームに必要な状態とは、どんな状態でしょうか？
笹尾：それは、ケイパビリティとアジリティが高い状態で、さらに仮説検証サイクルが高回転に回せる状態です。まず、理想のケイパビリティの高さの前提を説明します。
チーム内のメンバー間で、メンバーそれぞれのスキルの幅と深さ、ドメイン知識のエリアと深さ、才能として扱える個人特性、これらを理解し発見して活用したうえで、さらに共有し活性化できること。そして、チーム間ではチームを個人と同様に1人格として扱い、チーム内と同様のことができていることが理想です。
特に個人やチームの特性において、できないことをなくそうとするのは、やめたほうがいいと考えています。最低限のスキルセットを定義し、できないことを埋めていくのは、確かに義務教育などでは必要な考え方です。でも、みんな選ばれて同じ会社にいるのに、入社オンボーディング以外でそれは必要でしょうか。僕はあまり必要ないと思っています。
さらに、万能な人が優秀だという空気感が生まれる場合もあります。できないことは当然のようになくしたうえで、より能力を向上させた優等生のような存在を求める。産業の世界で、多能工と言われる価値観もそうです。でも、短期間でみんながスペシャリストでジェネラリストになるというのは、無理があります。
そもそも、実際に個々の能力をよく見てみると、スキルセットの広さも能力も高さも、個人差が大きいです。さらに、観察して感じたのは、スキルセットの足りない部分の深さは誰にもわからないということです。それがマリアナ海溝並みの深さなら、エベレストを全部壊して海に沈めても陸地にはなりません。
笹尾：会社のゴールに近づくのに、そんな行為は要らないはずです。できることに目を向けて、個人やチームの能力の高い部分をどんどん利用していくべきです。小さい頃、砂場で山をつくろうとして、崩れた砂で周囲が積み上がっていった経験はありませんか？ それと同じように、得意な経験を積むほど、周辺領域もどんどん広がっていきます。それによって、さらに能力が高まる可能性もあります。
なにより、組織には多様性が必要だと言われて長い時間が経ちました。まんべんない能力に期待するよりも、最高の能力を使いこなすことが大事です。個性あるメンバーやチームが理想とするビジョンを語りながら、より良くしようと活動し続ければ、自ずと妥協は消え、目指す価値も上がっていきます。気づけば新しい価値を生み出し、今まで見えていなかった未来が見えるようになります。それが、僕が必要だと考えるケイパビリティの形です。
笹尾：次に、理想のアジリティの高さの前提を説明します。状況に合わせた計画変更が容易にできること。不確実性が高い状況でより確実性の高いものを優先したり、不確実性を排除するために計画に柔軟性が持てること。そして、状況に合わせて最適なプロセスを選べることです。
不要なものを捨てることができる状態も必要です。例えば、柔軟なスケジュールを確保するために、ユーザーストーリーだけではなく、開発要望となるエピックのサイズをレゴブロックのように入れ替え可能にします。
さらに、エピックのリードタイムに適度な余裕を持たせつつ、小さな期間に設定することで、事業のスケジュールや市場の需要の変化に対応しながら、エピックの不確実性を減らし、有効なユーザーストーリーを優先する状態を作り出すことができます。
それだけでなく、コアとなる価値を分割してリリースすることで、スケジュールに余裕を持たせ、不確実性の排除と価値提供に対して柔軟性を確保することができます。ユーザーストーリーを進めるには背景理解が都度必要になりますが、エピックのサイズを小さくすると理解も簡単になります。
笹尾：これを制約理論で表現するとセットアップタイム、実際の作業をプロセスタイムと言います。そして、仕掛品のリードタイムで最も長い時間を取っていると言われるのは、他の部品を待っているウェイトタイムと、次のプロセスを待っているキュータイムです。この2つを排除するために、ユーザーストーリーもエピックも小さくしたほうが良いと僕は考えています。
続いて、不確実性排除の要となる、理想の仮説検証サイクルの高回転化の前提を説明します。原則すべてのアウトプットを小さな仮説検証サイクルと捉えた状態で、計測と学習により次の適応ができていることが大切だと考えています。
この画はMobiusloopと言って、まず価値を定義してやることを明確にして絞り込み、価値を提供し、計測と学習をして、次の仮説に生かすことが表されています。このループを可能な限り小さなパラメーターで、検証可能な状態で高回転に回していくことが、僕にとって理想の仮説検証だと思っています。
笹尾：そもそも、単純に仮説検証と言っても、事業フェーズや計画ごと、それぞれの仮説検証に多重構造があります。顧客側面以外にも、技術面や運用面でも仮説検証が必要なことは多々あります。さらに、仮説検証はその時間軸にも多重構造があります。日々の開発の中での小さなトライと振り返りがあって、スクラムだとデイリースクラムとスプリントがあります。
価値の発見から検証までの時間に、仮説検証をしている時間ループがたくさんあって、グルグルと入れ子構造になっているんです。これは、まるでロマネスコですね。全体と部分が似ていて、拡大すると区別がつかないものを自己相違性やフラクタル性と言いますが、「この小さな突起が」と指をさしたとして、どの突起のことかわからないんですよ。
これが開発や仮説検証における、物事のわかりにくさの一因だと僕は考えています。だからこそ、パラメータを小さく少なく明確にする。ノイズを減らし、アウトカムの定義から学びや計測まで、認識齟齬を減らしていく必要があります。
マトリックス型の組織、ストリームアラインドなチームへ
笹尾：では、どうやったら不確実性を下げられるチームの状態をつくれるでしょうか。理想だけなら誰でも語ることができます。しかし、チームは生き物で、毎日活動しています。
早くフローを改善してゴールに近づけたいですよね。そもそも分業化したままで、フローを改善できるのか。考えてみると、やっぱり難しいと思います。同じリズムで適度に距離を詰めて進む必要があります。要件によって変わるボトルネックにリズムが合うように、スクラムのプランニング、デイリースクラム、レトロスペクティブで毎日、毎週リズムを合わせる必要があります。
ユーザーストーリーやエピックを小さく明確にしつつ、計画に適度な余裕を持たせ、状況の変化に合わせてタスクやスケジュールを組み替えられるようにして、バッファをつくる。全員の進捗に合わせてバックログの上位から一緒に進めるために、エンジニア、プロダクトマネージャー、デザイナーが同じ命綱で繋がって進むような状態をつくり出す。
それには、チームの構造を変える必要がありました。このようなマトリックス型の組織をつくりたいなと。ただ、それには課題もあり、フローを優先してストリームアラインドなチームをつくるには、個々のメンバーのオーナーシップをもっと強くする必要があります。特にバックエンドチームのようにメンバーが多いところでは、そういった傾向が強くなります。
笹尾：開発チーム全体が、古参のメンバーに頼る状況を減らす必要があります。これはエンジニアだけでなく、周囲も頼っている状態を減らしていかなければなりません。そこで、フロントエンド以外の機能開発停止の裏側で進めている、大規模リファクタリングが有効になります。
一番の目的は間違いなく技術負債の解消ですが、難しいチャレンジだからこそ、あえて最古参のメンバー以外にリファクタリングをお願いしました。これにより、古参のメンバーに頼る部分が徐々に減っていきました。機能開発を継続していたら、関係性がそのまま固着してしまい、あまりこういった変化を起こせなかった可能性が高いです。
これも常に全員が忙しい状態を求めず、負荷を分散していくことで、次のボトルネック解消に繋がっていると考えられます。時系列で見てみると、時期が重なっているのがわかりますね。紆余曲折、各チームの立ち上げを丁寧に行ったので、チーム全体が変化するのには5ヶ月かかりました。
笹尾：「Musubi AI在庫管理」の機能開発チームは、原則ストリームアラインドなチームに変化することができました。僕たちは、小さな縦のチームをレーンと呼んでいます。先ほど紆余曲折とお話しましたが、その間に一度やめたスクラムイベントの中で、振り返りを復活させたり、スプリント期間を2週間から1週間にしたりといった施策も同時に実施していました。
そして、すべてのレーンが立ち上がって1ヶ月後、会議全体の見直しと同時に、スクラムイベントを再定義したうえで、スプリントレビューも開始しました。チーム内の全レーン全員が集まって、毎週1時間のスプリントレビューをします。そこには、CSのメンバーも参加してくれています。そう、マトリックス型の開発チームを超えて、プロダクト関係者のリズムを合わせる準備がだんだん整ってきたんです。
スプリントレビューは、仮説検証の大切な検査の一部です。だからこそ、導入は僕自身、かなり緊張しながら進めていました。デプロイ可否判定会にしないこと、進捗管理や報告の場にしないこと、それから開発メンバーの頑張ったアピールの場にしないこと。それらに配慮しながら、参加体験型に感じられ、盛り上げながら成熟させられるイベントにしようと考えていました。
しかも、レーン数が多い中、限られた時間で何を検査するかをきちんと決めないと、上手くいきません。だから、各レーンが必ずスプリントゴールを立てられるようになってから、スプリントレビューを開始し、明確にスプリントゴールで不確実性を下げることを目指すようにしました。
スプリントゴールに対して、プロダクトマネージャー、デザイナー、エンジニアだけでなく、CSのメンバーも同じ方向を向いて、リズムを合わせて一緒に進めているかを確認します。すると、開発チームとCSが近づき、双方が知らなかったことに気づける機会が生まれてきました。
実際にCSのメンバーからは、「お客様要望の機能がどうつくられていくのか見えて嬉しいです」といったコメントをもらっています。さらに、スプリントレビューの中で、お客様がどのように利用していて、どのような要望があったのかといった背景をどんどん教えてもらえるようにもなっています。
さて、話を開発生産性に戻して、不確実性を下げることが生産性が高いと言えるのか。これは実際に進めていく中で、必要なアウトプットが予測しやすくなり、仮説検証の質も高まりそうなことがわかってきました。
そして、これらの取り組みを通して、技術的負債の解消などをプロダクトマネージャーだけでなく、CSのメンバーとも協調しながら進めるチャレンジもしています。少しずつですが、オープンに会話する機会を増やしながら、ボトルネックになり得る要因について、双方の理解のもと行動できるようになりつつあります。
サイクルタイムや機能リリースの数値から見るチームの変化
笹尾：とはいえ、状態だけを語っても確証がありません。では、数値としてどういう変化をしているのか。僕たちのチームは今期、高回転な仮説検証とアジリティの高さを計測するチャレンジを始めました。「Findy Team+」のサイクルタイム分析を利用して、エンジニアの日々の数値を確認しつつ、ディスカバリー単位のリードタイムを計測できるように、エピックの開始から完了までを計測する計画を立てています。
これらは理想のチームに近づけば近づくほど、短くなると考えています。実際に「Findy Team+」のサイクルタイムを見てみましょう。こちらはチーム全体の今月のサイクルタイムで、メンバーが最初のコミットをしてから、次回の本番デプロイに乗るリリースブランチにマージされるまでの平均時間です。土日を抜いた数値なので、大型連休がなければ約3日以内でマージされていることになります。
笹尾：続いて、チーム全体の去年4月からのデータを見てみましょう。混乱のあった4～5月の数値が少し高く、その後フローを優先してフロントエンド以外の機能開発を止めた6～7月は、大きく改善しています。
その後、チーム全体の開発が始まると、数値は大きく悪化。年末年始を挟んだ1月を境に改善傾向になり、一旦37.2時間まで下がっています。直近は悪化していますが、長期連休があると数値が大きくなりやすいため、5月はゴールデンウィークが影響している可能性があります。
6月に関しては、機能開発ではないレーンが大型のライブラリアップデートをしてくれていて、機能開発に影響を与えないタイミングでマージするために調整しており、それが大きく数値に出ていることが考えられます。
笹尾：僕たちは、理想のチームの状態を大切にしていて、こうした数値に一喜一憂しないようにしています。数値を追いかけながら原因を分析し、施策が狙い通りであれば問題ないと判断しつつ、次の改善を考えています。
では、去年9月に立ち上げた機能開発レーンの数値を見てみましょう。最初の60時間程度から、年末年始に70時間余りを記録したのち、ゴールデンウィークに少し悪化したものの、今月は21.1時間にまで短くなっています。
笹尾：2番目に立ち上げた機能開発レーンの数値も見てみましょう。年末年始に若干の悪化、ゴールデンウィークに大幅な悪化が見られたものの、今月は26.9時間と、あと少しで24時間以内のマージができそうな状態になっています。
笹尾：では、ディスカバリーのリードタイムについてはどうでしょうか。実はこちらの数値は取り始めたばかりで、残念ながらお見せできる数値がありませんでした。ただ、エピックの単位と同じような数字がないかということで、機能リリースのリリースノートの数を調べてグラフにしてみました。
去年の混乱期直前の3月は、なんと0件。そして、フローを改善した6月に5件を記録して、7月にまた0件。その後は安定期に入り、直近では増大しています。これらの数値を分析すると、サイクルタイムが短くなりつつ、アウトプットも増えていることがわかります。これは僕の想像になりますが、制約理論における在庫が減って、スループットに貢献できる状態に近づいているのではないでしょうか。
笹尾：これらの成果は、本当にすべてチームのみんなのおかげで成り立っています。エンジニアやプロダクトマネージャー、デザイナー、そして毎週協力してくれるCSのメンバー、みんなの継続的な努力のおかげで、こうした結果が出ています。この場でお礼を言いたいところですが、まだまだ僕たちには課題が残っていて、次に向けて一緒に進んでもらいたいと思っています。
以前からあった技術負債は解消するのが難しく、高い複雑性や結合度に対して、まだ上手く対処できていません。このままではアウトプットに比例して、インシデント発生確率が高い状態になってしまいます。解決するために、機能削除に繋がるような行為も必要になるかもしれません。これらの不確実性を、僕たちチーム全員で解決する必要があります。
だからこそ、これからも開発チームだけではなく、プロダクトチーム一丸となって、リズムを合わせて進んでいきたい。ボールは丸くて、試合は90分。限られた時間の中で、ありとあらゆる手を尽くして、チーム全員でゴールを決めて勝つ。僕たちのチームはもちろん、今日ここで聞いてくださっている皆さんのチームでも。
ご清聴ありがとうございました。
