【ログラス×スマートショッピング】どうアプローチすべき？開発生産性向上への取り組み前後の課題解決プラクティス
2023年3月2日、ファインディ株式会社が主催するイベント「【ログラス×スマートショッピング】どうアプローチすべき？開発生産性向上への取り組み前後の課題解決プラクティス」がオンラインにて開催されました。
ファインディでは、エンジニア組織支援クラウド「Findy Team+(チームプラス)」をリリースし、エンジニア組織づくりや生産性の可視化を通じたパフォーマンスの最大化支援に取り組んでいます。
昨今、開発生産性を定量化する指標として、GoogleのDevOps Research and Assessment（DORA）チームが提唱した“Four Keys”指標がトレンドになりつつあり、開発生産性の維持や向上をミッションに掲げ、取り組みを進める組織が増えています。
今回のイベントでは、「Findy Team+」の導入企業である株式会社ログラスのエンジニアリングマネージャー松岡さんと、株式会社スマートショッピングのCTO長島さんをお招きし、実際の開発生産性向上に関する取り組みについて、パネルディスカッション形式でお話しいただきました。
■登壇者プロフィール
長島 圭一朗さん/株式会社スマートショッピング CTO 株式会社シーエー・モバイルにて複数のECサイトの開発、複数のソーシャルゲーム・SNSプラットフォームの立ち上げおよび企画・開発責任者を歴任。その後CyberAgent America,inc.でUS向けのスマホゲーム、スマホアプリの企画/開発を担当。帰国後株式会社サイバーエージェントの新規アドテクノロジー事業立ち上げ、開発責任者を務める。2014年、株式会社スマートショッピングに参画。
松岡 幸一郎さん/株式会社ログラス Engineering Manager 2020年9月よりログラスにジョイン。DDDやスクラム、XPといったアジャイル手法を探求して発信。現在はEMとしてシステムコーチング(組織向けコーチング)を学びながら生産的な組織のスケーリングを探求中。
※本イベントのアーカイブ配信（無料）はこちら
目次
それぞれの会社における開発チーム体制とミッション
──本日はよろしくお願いいたします。まず最初に、お二方の自己紹介からお願いします。
松岡：2020年より株式会社ログラスにジョインして、初期ではドメイン駆動設計やスクラム、XPなどを用いたチームの開発プロセスの改善を行っておりました。現在は、生産性の改善など課題を解決する横串のチームのエンジニアリングマネージャーをしています。、そのなかで「Findy Team+」も使わせていただいています。本日はよろしくお願いします。
長島：株式会社スマートショッピングが創業したのが2014年11月で、その直後からずっとCTOをしています。今はCTOとして経営に携わったり、エンジニアリング組織全般を見たりしています。生産性の向上への取り組みのほか、PdMチームと共にプロダクト開発にも関わっています。よろしくお願いします。
──参加者の方々から事前にいただいた気になるポイントも合わせて、パネルディスカッションのアジェンダとして、下記の内容を用意させていただきました。
──それではさっそく、両社の「開発チームの体制ミッション」からお聞きしていきたいと思います。
松岡：現在ログラスの開発体制は、機能開発を行うチームが3つあり、そこから独立した横串で改善を行うチームがあります。背景としては、もともと技術的負債をボトムアップに解決していく文化があったのですが、チーム数が増えるにつれて課題も増えてきたので、全体最適になるようにチームを立ち上げました。今は立ち上げから5ヶ月目くらいで、私はその横串改善チームのEMをしています。
──続いて、長島さんお願いいたします。
長島：スマートショッピングでは、「日常に永遠のイノベーションを」というミッションを掲げており、エンジニアリング本部としては、技術を磨いて「日常を革新するプロダクト開発をする」ことをミッションとしています。
私たちの体制は今、大きく3つの部に分かれていて、今回「Findy Team+」を使って改善を進めたのは、図の左側にあるサービス開発部です。各ユニットにはPdMがいて、バックエンドが2人、フロントエンドが1人。多少の変動はありますが、これが基本の体制になっています。
サービス開発部には今、3つのユニットがあります。昔は機能ごとに、フロントエンドチームやバックエンドチームと分けていましたが、スクラムを導入した経緯もあって、今はこうした体制になっています。
そして、基盤統括部には、SREチームとQAチーム、コーポレートエンジニアチームがあります。加えて、私たちはハードウェアを持っているので、そのファームウェアを研究したり、改善したりするR&D部があります。
このなかの特定のチームで「Findy Team+」を活用したというよりは、全体的に関われるイネーブルメントと言われるようなメンバーを、各部署から1～2人くらい集めてきて、改革を進めたのが今回の取り組みです。
現状を定量的に把握し、より良くしていくために計測を開始
──続いて、「開発生産性を計測し始めた背景・目的」について、それぞれお伺いしたいと思います。
長島：私たちの会社では昨年の夏に経営合宿があり、そこでエンジニアに限らず、全社的に生産性を上げていこうという話があったんです。そのとき、自分たちの開発組織はちゃんとできている方だと思っていたのですが、定性的な判断しかしておらず、定量的にはまったく見れていない状況でした。
それから、Four Keysが話題になってきているなかで、定量的に測れるツールを入れて、自分たちの開発組織が他と比べたときにどうなのかを可視化したいなと。自分たちの現状をしっかりと把握して、より良くしたいという目的もあって始めました。
──こちらについて、松岡さんからもお願いします。
松岡：ほぼ同じ答えですね。どこに生産性改善の余地があるのかを、定量的に把握したり他と比べたりしたいという背景から、計測を始めました。
──「取り組み開始前のタイミングで直面した課題」については、いかがでしょうか？
松岡：改善するにあたっての定量データのなさとか、そもそも定量データとして何を追えばいいのかとか。あとは、生産性とは何なのかといった話ですね。そういう定義のところは、どうしたらいいのか迷いながらやっていました。
──実際にどの数値を追っていくか、どのようなプロセスで決めていきましたか？
松岡：プロセスというか、紆余曲折を経た結果としては、広木大地さんがQiitaで書かれた記事の考え方がすごくしっくりきたんです。その記事では、生産性を3つのレイヤーで捉えていて、レベル1が仕事量の生産性、レベル2が期待付加価値の生産性、レベル3が実現付加価値の生産性とされていました。
※出典：広木大地さんのQiita記事「開発生産性について議論する前に知っておきたいこと」
元々どれだけ価値を生み出せたのかを考えた時に、分子の部分をビジネス価値にしようとしても、弊社が提供しているのはBtoB SaaSなのでCSやセールスが絡んでくるため、開発との間が空きすぎてしまって測りづらい。とはいえ、ストーリーポイントなどを目標にしてしまうとハックの余地があり有効な測定ができない、といったジレンマがありました。
ですが、レベル1としてはまず「仕事量」の生産性でいいと考えると、割り切れたところがありました。一方で、レベル2～3となると、エンジニアとビジネスサイドとで価値が出るまでの間にラグがあって、コントロールできない部分もあります。そのため、目指しているものが得られているかについては、クォーターごとに定めているOKRで判断しようと考えています。
なので、生産性に関してはどちらかというと、よくできているかの確認よりも、課題発見が重要だという結論になりました。例えば、リードタイムに課題があるとか、成功率に課題があるとか。どこに課題があるのかを追うためのセンサーのような形でメトリクスを捉えて向き合うのがいいのかなと捉えています。
──取り組み開始前のタイミングでの課題について、長島さんはいかがでしょうか？
長島：Four Keysのデータを取ること自体は、すぐにできそうだなと思っていたのですが、それを可視化したり、過去の推移からトラッキングして、どれくらい良くなってるかを見たりしないと意味がないなと。なので、それをどうしようかなと考えていたのが、導入前にあった課題でした。
あとは、ツールを導入すれば、ロードマップの開発がすごく早くなる、と思われがちなところがあると思っています。もちろんお客様により早く価値を提供するために、最終的にはそこを目指してはいますが、あくまで改善するのはプロダクト開発のプロセスの一端です。なので、そこを説得する必要がありました。
もう1つは、現場という切り口で言うと、最初はツールの導入工数が見えないので、負荷の心配から「そんなツールを入れている場合ではなくて、ロードマップの消化をしなければ」というような、ネガティブな意見もありました。ただ、熱量の高いメンバーがいて、すごく熱意を持って現場を率いてくれたので、そこは良かったと思っています。
リードタイムやデプロイ頻度を注視し、大きく改善へ
──それでは、実際に「何を計測し、どんな取り組みを行っているか」について、お聞きしていければと思います。
松岡：Four Keysも、どの指標がどこの持ち物なのかという切り分けが大事なので、まず計測の前にそこを切り分けました。「Findy Team+」で追えるリードタイムは、完全に開発チームのものと切り分けて、横串チームやEMでは追っていません。「Findy Team+」を使うかどうかも、チームごとの課題感に合わせて選んでもらうようにしています。
横串チームでは、私ともう1人が「Findy Team+」の使い方に習熟しているので、ぐるぐると各チームのスクラムイベントなどをまわって、リードタイムに課題がありそうだという話をしていたら、使ってみますかと。「Findy Team+」の使い方をガイドして、指標を追ってもらうという形でやっていました。
全体で追っていたのは、変更失敗率や、ポストモーテムで出たネクストアクションのチケットが消化されているか。それから、弊社では技術的投資と呼んでいる、ライブラリのアップデートやリファクタリングを行う技術的負債の解消といったバックログのチケットが、ちゃんと解消できているかなどですね。
あとは、パフォーマンスであるとか、CIとかビルドの時間とか。他にもいろいろありますが、そういったところを横串チームで追っています。
──開発のリードタイムとしては、どのような数字を追っていますか？
松岡：基本的に「Findy Team+」のサイクルタイム分析のところで、リードタイムを見ています。そのなかでも、あるチームではプルリクのレビューからクローズまでにフォーカスして、とにかくそこだけ早くしようというトライをしたら、意識が変わって波及的にリードタイムが短くなりました。
その施策が落ち着いて、数字が良くなったのでしばらく見なくなっていたのですが、最近見てみたら、少しリードタイムが伸びてしまっていて。それで、改善しなければならないなと、気づくきっかけになったりもしていました。
──それでは続いて、長島さんからも取り組みについてお願いします。
長島：前段として、僕たちエンジニアリング本部では、まずできるところの最大化に注力しようと考えました。そうなったときに、デプロイ頻度を倍に、変更のリードタイムを半分にするところを目標に掲げたんですね。
当時は、それがどれくらい高い目標かわかっていなかったのですが、ファインディさん（カスタマーサクセス）のお話を聞いたところ、それくらいの数値が出ると、「Findy Team+」を使われている他社さんのなかでも上位数%に入るということでした。
「Findy Team+」導入前の昨年8月の数値と、先月の数値を比較すると、デプロイの頻度は倍になっていて、変更のリードタイムもかなり縮みました。デプロイの頻度はもう少し改善できそうですが、どうしてもリリースや作り込み期間のタイミングで前後します。なので、そこまで厳密には追っていませんが、ほぼ達成しているといえる状況になっています。
長島：取り組みの内容としては、まずは古いデータの削除から。当時は2019年くらいのプルリクが残っている状況だったので、それを削除するところからスタートしました。そして、変更のリードタイムを改善するために、プルリク作成からレビュー開始までを、24時間以内にするという努力目標を設定しました。ここは、それほど時間もかからず改善していって、48時間、36時間と、およそ12時間刻みで改善していきました。
それから、デプロイとリリースの認識が、エンジニアとPdMなど個々でずれていたので、そこの認識を統一しました。デプロイは必ずしもお客様に解放されている状況ではなく、リリースがお客様に解放されている状況なんですよね。なので、お客様に解放されていなければ、どんどんデプロイしていいというルールに変えて、開発者の精神的な負担を減らし、サイクルを早くまわせるようにしました。
もう1つは、1プルリクあたりの変更行数を200行以内に収めるという取り組みです。最初はあくまで目安としていたのですが、目安というと努力目標になってしまうので、途中からは200行以内にすることをルールとして徹底しました。これによって、昨年8月は平均で300行以上あったものが、2月には平均117行になっています。200行どころか、さらに半分近くまで落とせているので、良い傾向だと思っています。
これらのルールをすべてesaに明記して、月次と2週間に1回くらいのペースで、生産性向上を目的として立ち上げたDevOps委員会で振り返っていました。それを各チームのメンバーと話してもらい、委員会で吸い上げる、というサイクルをまわしていた形ですね。
定量以外の課題や、数値に現れるまでに感じた困難も
──両社の具体的な取り組み内容をお聞きしてきましたが、続いて「取り組みを通じての困難・課題」について深掘りしていければと思います。
松岡：「Findy Team+」を使った改善は、各チームに任せて上手くいっていました。一方で、上手くいきづらかったのは、「Four Keysをどう使うか」です。マネジメントチームが現状把握のために追いたいのか、現場の人が使いたいのか、どっちつかずになってしまっている状況があったんですね。
それについては結局、現場の人が使うものと割り切ろうという話になりました。EM陣で行っているミーティングでは、Four Keysを追いたいという意見はあまり出ておらず、現場で使うものと振り切ってからはすごくすっきりしました。
──定量的な面以外でのアプローチや、それにおける課題などもありましたか？
松岡：定量以外の課題をどうやって表出させるかは意識していて、オーバーオールレトロスペクティブなど、チーム全体での振り返りや改善を行う場は、横串チームの人がホストしてくれています。
ただ、そこで「みんな課題を出して」と言ってもなかなか出てこないので、ヒアリングしていったらいいのかとか、OSTと呼ばれる議題持ち込み式がいいのかとか、定性的な課題の拾い方はまだ試行錯誤しているところです。
最近は、意外と地道なインタビューというか、雑談から拾える面もあるなと感じていて。定量化から一周まわって、そういうことも大事だなと思っています。
──取り組みにおける困難や課題について、長島さんはいかがでしょうか？
長島：現場で一番難しかったのは、タスクのサイズを小さくする取り組みで、これが最初はなかなか普及しませんでした。取り組みを始めた当初は、肌感で今のタスクサイズの倍くらいあったんですね。そうするとコミットまで長くなるし、レビュアーも時間がかかるし、結果的にレビューも後まわしになる。負のサイクルが生まれるので、どんどん小さくしましょうと言い続けていました。
ただ、当たり前のことなんですが、やはり施策が浸透しないと数値は変わらないんですよね。9月に取り組みを始めて、最初はすぐに数値が良くなるんです。でも、10～11月くらいは、みんな施策をまわしているのに、数値は停滞してしまっている状況でした。
その後、12月くらいになって改善されてきて、このままいけば1月は良くなりそうだ、というところまで、あまり数値に現れませんでした。数値が変わらないと、「何のためにやっているんだっけ？」という話になりがちなので、そこに難しさがあったなと感じます。
でも、そのなかで救いになったのが、1on1で「Findy Team+」のデータを使い始めていたことです。メンバーも、自分のことを俯瞰的に見れたり、定量的に見れたりするようになったので、その影響が大きかった。これによって、取り組みが数値に現れてくるまで耐えられた部分はあったかなと思っています。
──12月ごろに数値に現れてきたというお話が、こちらのグラフでも見て取れます。ここで何か新たな工夫をされたのでしょうか。それとも、施策がより浸透していった結果でしょうか？
長島：施策はほとんど変えていませんでした。1つのユニットが先んじていろんなことを試してくれていて、施策に結果が出始めたんですね。なので、そのやり方を社内で横展開していき、全体的に浸透していったことが大きいと思います。
両社が取り組みを通じて得られた、効果や学びとは？
──続いて、「取り組みを通じた効果・学び」についても、それぞれお聞きしていきたいと思います。
松岡：「Findy Team+」を使ったり、横串チームで改善を進めたりしてきたなかで、生産性との向き合い方として、制約理論という考え方が個人的にしっくりくるなと思っています。
例えば、工場のラインにおいて、工程Aで1日30個作っていても、次の工程Bでは5個しか作れないと、結局そのラインで作れるのは5個になってしまう。こうした工程のボトルネックを見つけて改善すると、また制約が次のところに移るので、今度はそこに注目して改善していく、というのが制約理論です。
Four Keysは、その工場のなかで特定のプロセスに、4つのキーをセンサーとして挿しておくイメージだなと。そうすると、そこで何か改善したら効果がわかるし、何か異常があったときにも気づくことができます。
ただ、そのプロセスのなかで測っているのは4ヶ所で、当然ながら他のところもあるので、そこは定量や定性で意識しなければならない。そういう捉え方をすると、今までやってきたことが説明できて、しっくりくるなと思っています。
生産性というと、やはりFour Keysが有名なので話に挙がってきますが、それだけではダメだよな、という感覚に答えが出たというか。もちろんFour Keysも大事なのですが、そこが整理できたことが、すごく良かったと思っています。
──取り組みを通じた効果や学びについて、長島さんはいかがでしょうか？
長島：組織面としては、サービスやプロダクトをお客様にデリバリーしていく全体のプロセスのなかで、エンジニアリングが主として関わる部分は、可視化もされましたし、足かせにならなくなってきました。つまり、作るべきものの焦点が定まれば、しっかりと効率よく開発できるところまで持ってこれたと思います。
なので、本来考えるべきである、お客様にとって価値があるものをしっかり追求していこう、それをしっかり作りきろうというところに、より向き合える余裕ができたことは大きいと思っています。
人に関する面としては、自分のパフォーマンスを客観的に見られるようになったので、パフォーマンスが良くないときにはちゃんと振り返って、悪かったところを自分たちで消化できるようになったことが大きいですね。あとは、エンジニアは数値が良くなることが総じて好きだと思うので（笑）、みんなのモチベーションアップにつながるところも大きかったです。
より高い生産性を実現するための、今後のさらなる取り組み
──それでは最後に、両社の「今後の取り組みの方向性」についてお伺いできればと思います。
松岡：最近はエンジニアというより、プロダクトマネジメント領域に制約がある印象が強くなってきて、もっとチーム全体として取り組まなければならないことが増えてきたなと。なので、生産性については一旦そちらに任せながら、横串チームとしては、サービスの品質や信頼性であるとか、より細かい生産性の改善に取り組んでいきたいと考えています。
あとは、後まわしにしがちだけれど、中期的に見てやらなければいけない課題への取り組みですね。例えば、データ量をどれくらい持てるのかとか。放置してパンクしたときにはもう遅いので、そういったところにフォーカスして、どんな課題があるのかをバックログで可視化していく。それをCTOやEM、プロダクトマネージャーと取り組み始めています。
──続いて、長島さんはいかがでしょうか？
長島：より良いものをより早く届けるために、プロダクト開発全体の速度を上げたいと思っています。なので、今『Lean UX』という本がありますが、あの辺りの考え方に取り組もうとしています。
前提として、私たちはスクラムのスプリントを2週間でまわしています。やはり2週間である程度スプリントのゴールを達成できることが担保されていないと難しいと思うのですが、開発スピードが速くまわるようになってきたので、トライできるかなと思っています。
メンバーと話していくなかで、今のブランチ戦略をトランクベースに変えようと考えています。フィーチャーフラグなども導入しながらですね。先ほどデプロイとリリースの分離についてお話ししましたが、やはりデプロイはどんどんできた方が開発者体験も向上するのは間違いないと思うので、トランクベースの開発を試してみようとしています。
あと、QAのプロセスも、スプリントのなかに組み込もうと思っています。そのスプリントで作るプロダクトの1つのパーツが、ちゃんとQAまで終わっているのであれば、その後いくらパーツを合算しても、基本的には大きくバグが起きたりブレたりすることはないだろうと。そういう思想のもとに、スプリント内でQAを終わらせる取り組みも、全体でやっていこうとしています。
そういった形で、大きく分けて企画、開発、テストのところで、より高いレベルの生産性を実現するための取り組みを、引き続きやっていきたいと考えています。
──それではお時間となりましたので、本日のイベントは以上になります。松岡さん、長島さん、ありがとうございました！
※本イベントのアーカイブ配信（無料）はこちら
