フィーチャー開発からホールプロダクト開発への挑戦

飯田：株式会社ログラスでVPoEを務める飯田と申します。前職では執行役員をしていましたが、2020年にログラスにソフトウェアエンジニアとして入社しました。ログラスは2019年創業のスタートアップであり、初期フェーズから参画して事業と組織の成長を間近で見てきました。

本日はログラスのミッションや事業、開発組織の変遷についてお話ししたあと、FASTに挑戦して得られた学びをご紹介します。

ログラスは「良い景気を作ろう。」をミッションに、経営企画向けのプロダクトを開発しています。ユーザーの業務は多岐にわたり、中でも「守り」の経営管理に時間とコストがかかっています。これを効率化し、DX推進や新規事業といった「攻め」の業務につなげていこうとしています。

今後の展望として、私たちは単なる業務効率化にとどまらず、さらなる経営の高度化に向けて取り組んでまいります。具体的には、経営管理領域を起点としたマルチプロダクト展開および生成AIによる分析・意思決定の高度化の実現を目指しています。現状では5つあるプロダクト・サービスを、2027年に20以上へ拡大し、それに伴い従業員数も増やしていきたいと考えています。

ちなみに、ログラスは開発生産性カンファレンスに初回開催から参加しており、今回で3回目の登壇となります。昨年は、CTOを務める伊藤（登壇当時はVPoE）が登壇しました。

▼フィーチャー開発から ホールプロダクト開発へ ～顧客価値へ向き合い続ける挑戦 ～
https://speakerdeck.com/itohiro73/dev-productivity-con-2024

登壇の内容についてもご紹介させてください。

はじめに、開発生産性を「仕事の生産性」「期待付加価値の生産性」「実現付加価値の生産性」という3段階で考えた時に、 プロダクトの価値を高めていくために「期待付加価値の生産性」が重要だという話をしていました。

開発組織の変遷にも触れ、創業当初のワンチーム体制から、メンバーの増加に伴いチームが分割され、最終的に機能領域ごとのチームが存在するようになったとお話ししました。

ホールプロダクト開発に向かう上で、プロダクト全体での価値を捉えにくくなってしまうという課題がありました。そこで我々は、 課題解決のためにOrg Topologiesを参考にしました。これは組織の状況を16個のアーキタイプで類型化するものです。



右側にある図の横軸はチームのケイパビリティで、右へ行くほどクロスファンクショナルなチームになっていきます。縦軸はチームの扱っているスコープで、上に行くほどプロダクト全体のことを扱えるようになります。

昨年の登壇では、図の右上を目指すための施策として、アジャイルのスケーリングフレームワークであるFASTの導入に取り組むと伝えていました。

ログラスが選んだ自律的スケーリングフレームワーク「FAST」とは

飯田：取り組み結果をご紹介する前に、前提についてもお話しします。

ログラスのプロダクト組織が向き合う課題は「ドメインの複雑さ × 横断的体験の整合性」です。経営管理領域は複雑な業務であり、組織全体でその価値を捉えるのには難しいところがあります。

「パフォーマンス問題への継続的な対処」も課題の一つです。経営管理においては、多様なデータを複数の軸で集計・分析するユースケースがあり、会社の規模が大きくなるにつれて扱うデータ量も増加していきます。

様々な複雑性がある中で、1人の担当者が全体を認識して開発を進めることは難しく「認知負荷とチーム間連携のトレードオフ」という課題もありました。認知負荷にうまく対処するため、機能領域別チームで開発を進めていたのですが、機能Aの拡張に機能Bの変更も必要なケースがあり、チーム間の連携コストが発生してしまっていました。

機能領域に閉じた最適化からプロダクト全体での最適化に向かえるように「デリバリー・ディスカバリー双方に組織全体でコミットする」「組織全体での機動性を高めていく」ことを目指し、FASTを導入することにしました。



FASTは、Quinton Quartel氏が提唱したスケーリングフレームワークです。上図の右側にあるように「活動アイテム＝取り組むこと」をベースに、流動的にチームを組成していく考え方です。他のスケーリングフレームワークと比較して対極的な考え方をしているため、難易度が高いと思われるかもしれません。取り組んで実際に感じたのは、 ルールが少なく自由度が高い分、個々の開発者の自律性が強く要求される手法だという点です。

スケーリングフレームワークには、FAST以外にもさまざまなものがあり、国内で導入事例があるものを選択するのも可能でした。しかし、ログラスは自律性を大事にしてきた組織文化があるため、 柔軟性が高くスタートアップの機動性にもフィットしそうなFASTを選びました。



他のフレームワークと同じように、FASTにも「価値」「原則」「柱」が設定されています。



FASTについて、もう少しご説明します。

図の左がスクラム時代の構造です。1つのコードベースがあり、その上に3つの機能領域があり、3つのチームがそれぞれのバックログを持ってスクラムを回していました。

FASTでは、1つのコードベースの上に全体で1つの組織（コレクティブ）があり、その中に流動的なチーミングの枠（スロット）があります。ビッグピクチャー（バックログのようなもの）から各チームが何に取り組んでいくかを自律的に選んで組成していく構造になっています。

FAST自体は不確実性が非常に高く、導入の意思決定時にはまた別の困難がありました。詳細は2025年1月8日開催のRSGTにて発表しておりますので、ぜひそちらも見ていただければと思います。

▼エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢
https://speakerdeck.com/yoshikiiida/rsgt2025

FAST導入の1年間で得られた5つの学び

飯田：ここから、FASTを導入して学んだ5つのことをお話しします。



1つ目の「流動性の解釈の深まり（内部・外部）」は、FASTが流動的なチーミングをしていくことをどのように捉えたのかという話です。

導入当初は各スロットの出入りが多く、流動性が高い時期がありました。それにより自律的に動いていくマインドが生まれて良かったものの、後から入ってきた人に各スロットの説明をする必要があり、コミュニケーションコストが上がるという指摘もありました。

ただ、この点についてはFASTの考案者が言っている通り、時間経過とともに人の出入りは落ち着いていきました。 流動性を特徴としているものの、必ずしも流動しなくてはいけないわけではないのだと学びました。

外部の流動性についてもお話しします。FASTを導入した当初は、創業事業である経営管理だけでなく新規事業においても組織全体でフレキシブルに動いていけるだろうと考えていました。

しかし、実際に運用してみると、FASTの原則があったとしても外部との自由な出入りが必ずしも良い結果につながるとは限らないのだと気がつきました。内部で知見をためていく、出力を高めていくという点においては、 スクラムと同じように組織全体としての安定性が重要です。

次に「品質との向き合い方」についてお話しします。チームの枠を流動的にすると、スクラムよりも小さいチーム単位を構成できるのではないかと考えました。最小単位としてペアプロのようなものをたくさん作ったとして、一見すると並列数を上げられたように感じます。しかし実際には、戦力が分散してしまいました。

例えば、機能Aを開発する際に知見のある人が集まってチームを組成できれば、品質をどんどん高めていけるでしょう。しかし、有識者が分散してしまい、品質に課題が出てしまうシーンがありました。

スクラムの固定的な枠があってメンバーの出入りによってチームの持っているケイパビリティの増減がわかりやすいというのは、安定性の向上という点で理にかなっているのだなと改めて思いました。FASTにおいても、 各スロットで十分なメンバーが揃っているかどうかは重要な視点です。

参考情報として、アジャイルコーチから教えていただいたKen Schwaber氏の書籍『The Enterprise and Scrum』をご紹介します。この書籍では、企業のプロダクトの中心にあるようなデータや処理の機能など、コア領域の変更は難しいとされています。新機能開発に伴いコアの変更が必要になる場合は、コア開発者がいなければ新機能を開発できないと。つまり、 新規開発できる数はコア開発者の人数に制約されると書かれています。これは、当時の我々が置かれている状況からも感じていたことでした。

次にお話しするのは「自律性の解釈の深まり」です。FASTは自律性を大事にする考え方を持っており、導入後は組織内に「自律性を守らなければいけないのでは？」という過度な空気感がありました。

「自律性が大事だから、優先順位の決定はエンジニアに任せた方がいい？」
「入社して間もないけれど、自律的に動かなければいけない？」
「影響範囲が大きいけれど、自分たちで意思決定しないといけない？」

といった声が聞こえるようになったのです。この点に関して、FASTを導入している＝自律的に動かないといけない、という考えは違うのではないかと思っていて。スクラムにも自己組織化というコンセプトがあり、FASTと同様に自律性が求められます。ただ、振り返ってみると、FASTという複数チームを混ぜ合わせた大きな組織で、自律性を発揮する難易度が上がっていたのではないかと思います。ログラスでも、混乱や戸惑いが生まれた時期がありました。

ただ、結果としては、自律性に関する解釈が深まりました。どんなやり方を取るにしても、プロダクト全体でどこに向かうのか、何を優先的に取り組んでいくのか考える必要があります。その際に、みんなで考えてみんなで議論する合議のような形にすると歪んでしまうため、“誰か”が意思決定しなくてはいけません。誰かが意思決定することが自律性を損なうことにつながるわけではない、という学びがありました。

「サイロとの継続的な戦い」についてもお話しします。機能領域ごとにチームがあった時は、各チームでカルチャーが育っていました。すると、チーム間でのコラボレーションの際に、文化の違いがコミュニケーションコストという形で顕在化していました。

FASTの導入で、そういったサイロは崩れました。ただ、各スロットで走っていくものが増えていくにつれて、その中で新たなやり方や文化が形成され始めました。

ここでの学びは、やり方に問わず、環境次第でサイロの力学は働いてしまうということです。チーム間での協働の視点を常に持ちながら、個々の仕事を進める視点が非常に重要だと感じました。

最後にお話しするのは「守破離の捉え方」です。



FASTにおける守破離の「守」について考えてみると、太字の部分は普段の活動でも意識できている気がします。しかし、他の要素も含めると、これらを全て頭に入れて動くのは、難しいと思います。

実際のところ、現状ではFASTの「守」が完全にできているとは言えません。スクラムよりもルールが少ないものの、価値や原則などの考え方に関する要素が多く、馴染むには時間が必要です。

一方で、スクラムの原則である「透明性、検査、適応」については、多くのメンバーに馴染んでいます。過去の取り組みを通して、ログラスにはスクラムが定着しており、まだアンラーニングしきれていない部分があったのでしょう。ただ、無理にアンラーニングしていくことが最適解かどうかは改めて考えたいなと思っています。

また、FASTの「守」を超えて「破」に入っている部分もあります。マーケットプレイスにて、その時々の状況を見て流動的にチーミングをすることが前提ですが、先々を見通すためにスロットの配置の予測を立てる取り組みもしています。これは流動性とは逆行する取り組みであるため「守」ではないのかなと。



FASTをベースにしつつも、ログラスなりの現時点の最善を模索しています。上図のように、スクラム（安定的なチーム組成）、FAST（流動的なチーム組成）が両極端にあるとして、今は少しスクラムよりに戻ってきている状況です。

生産性指標では測れない組織学習と文化形成の価値

飯田：その上で開発生産性にどう向き合うのか。前提として、我々のプロダクトは大規模なモノリスがベースになっており、スクラムかFASTかに限らず、全体の開発生産性を精緻に計測するのは難しいと思っています。とはいえ、Findy Team+による可視化や品質ダッシュボード、コードベースの増加量推移など、いろんな観点から分析はしています。



参考までに、上図はコード量とリリースごとのコード変更量の推移を分析したものです。左はプロダクトコードの増え方を表していて、線形的に増加していっています。

右側はリリース単位の変更行数とAuthor数、1人当たりの変更行数を可視化したものです。ここは人の増加に伴って純増し、リリースの単位やコード変更量、プロダクトコードの規模感は増加しています。1人当たりの変更量は維持できているため、コードベースが大きくなっても変更容易性を維持できていると分析しています。

一方で、新機能や改善のリリースについて、直近はダウントレンドがありました。開発規模の拡大に伴いリードタイムが増加し、ソースコードやデータ量が増していくことで非機能的な開発の比率も上がり、加えてFAST移行によるダウンタイムも影響していたのだと予測しています。こうした複合的な要因が絡み合うため、単一指標で生産性を測ることはしていません。

また、開発生産性を語る上でAI活用は間違いなく今後のゲームチェンジャーだと考えていて、全方位的に高い実行強度で取り組んでいます。例えば、Claude Codeだけでどれだけ開発速度が向上するかを確認するといった取り組みをしたこともあります。

▼「Claude Code Week」既存事業で1週間AI縛りで開発したことで見えたゲームチェンジと開発フローの再構築の必要性
https://zenn.dev/loglass/articles/b286b1e8f0947b

このような取り組みをしつつ、 各種メトリクスはあくまでメトリクスとして扱い、変数となるレバーを見定めながら、施策を実行してモニタリングすることが重要だと考えて取り組んでいます。

FASTとの関連性についてもお話しします。先ほどお話ししたFASTの学びを開発生産性の3段階と結びつけると、このように振り分けられると思います。



「仕事量の生産性」でいうと、流動的なチーミングをしていくことによって、課題の優先順位が高いものに対して適切にチーミングができれば、フロー効率を高められます。開発が長期化するものについては、配置をあらかじめプランニングすることで、フロー効率を高められるのではないかと。

「期待付加価値の生産性」については、機能領域をまたいだチーム組成により、全体の価値を考慮できる体制を構築できると思います。
チームごとの枠を取っ払ったことで、プロダクトマネジメントの意思決定において全体俯瞰の意識が強化された部分もあったと感じています。

ただ「仕事量の生産性」に関わるようなものはアクションしやすいものの、「期待付加価値の生産性」に関する改善は非常に難易度が高いのも事実です。現状ではそういったところに取り組みやすい動きができつつあるのですが、まだまだ道半ばの状態です。

「お客様の意思決定がより良くなったか？　課題を発見しやすくなったか？　業務を効率化できたのか？」など、期待付加価値の観点は複数あり、恒常的なモニタリングができる状態までには至っていません。

一方で、FAST導入によって得られたものとして、定性的なメリットもあると思っています。FAST自体も練度をどんどん向上している部分はあると思いますし、結果として現場のアジャイルに向き合う本質的な試行錯誤を促進できました。改めてプロダクトの全体を見て開発をしていく重要性や、そこに向き合うマインドセットを構築できたのは、非常に良いポイントだったと思います。

最初は「FASTはわからない」という声も多かったのですが、得られた学びを自ら外部に発信してくれるメンバーも出てきました。

▼FASTと向き合うことで見えた、大規模アジャイルの難しさと楽しさ
https://speakerdeck.com/wooootack/fast-taught-me-large-scale-agile-hardships-and-fun

ここから、VPoE視点でのお話しもさせてください。

改めて生産性とは何かを考えると「生産性＝単位〇〇あたりの生産量や価値」と言えると思います。計測することで得られるものは、ある期間における過去～現在のやり方に関する情報だけであり、いわゆる健康診断のようなものだと考えていて。

過去の診断結果と比べて、改善されたかどうかを判断することはできるものの、健康診断を見て「アスリートを目指しましょう。そのためにはこういった取り組みが必要です」とはなりませんよね。

つまり、 開発生産性の計測から導き出せるアクションは短期的なものに過ぎず、生産性を改善するだけでは長期的な価値を見落とすリスクがあるのではないかと考えています。

FASTの評価でいうと、短期的には組織のやり方を大きく変えたことで一時的に生産性が下がりましたが、現在は回復してきている状況です。一方で、今まではスクラムでなんとなく回してしまっていた部分があり、それを見つめ直す機会にもなりました。

組織全体でプロダクトの価値を捉えることの難しさ、チームを超えてコラボレーションすることの大事さ、自分たちで改善していくことの重要性を体感できて、組織としての学習が進んだ1年でした。この学びの価値は、生産性だけでは測ることができないと思います。

振り返ると、長期目線のスタンスを取ることが非常に重要だったのだなと感じています。生産性で測れるような短期の合理性も大事ですが「短期では合理的ではないように見える取り組み」も重要なのではないかと。

短期でスループットを上げるためだけであれば、FASTという選択でなくても良かったでしょう。しかし、全体の価値にどう向き合うかという視点を含めて、その過程で育まれる文化やアイデンティティといった、より抽象的な開発組織としての強みを維持できるかどうかに焦点をあてました。

取り組みを継続させるために長期的な視点とスタンスを持ち、その意義を説明し続けることが、VPoEの責務なのだと思います。

次の1年は、AI時代の新しいスタンダードに向かう

飯田：まとめます。

私たちは、FASTというフレームワークを用いて、機能領域のフィーチャーチームからホールプロダクトに向き合うためのスケーリングに取り組んできました。

スケーリングの過程において、流動性や自律性に関する解釈と、品質を上げるためのチーム構成の要素についての理解が深まりました。サイロの力学やFASTの守破離をどのように捉えていくかについても学びがあったと思います。

開発生産性という観点では「仕事量の生産性」や「期待付加価値の生産性」の解像度が上がったものの、取り組みや運用の軸足はまだまだこれからの部分があります。次の1年では、AI時代の新しいスタンダードへのチャレンジに取り組みたいと思っています。

FASTを取り入れたことで、長期的な価値となる学びを得られましたし、長期視点での投資はVPoEのスタンスが重要だとわかりました。

ご清聴いただきありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です