読書メモ。2025年55冊目。
『Loglass Scaling Book2025』を読んでの感想となります。（2025/7/14記載）
本の概要
スケーリングアプローチとしてログラスが取り組む「FAST」に関する記事をまとめた技術同人誌
引用：
🎁 #開発生産性con_findy ノベルティ紹介①🎁
— Loglass Product Team (@LoglassPrdTeam) 2025年7月3日
スケーリングアプローチとしてログラスが取り組む「FAST」に関する記事をまとめた技術同人誌「Loglass Scaling Book2025」📙
本イベントに向けて用意した記事も複数載っています✍️
数量限定なのでぜひ早めにブースでGETしてください🙌 pic.twitter.com/8vQTDiU01j
動機
- ログラスさんにはいつも大きな刺激と学びを頂いており、FASTについても以前から興味を持っていました。
-
特に以前の勉強会でFASTに触れたとき消化しきれず、いつかちゃんと知りたいという気持ちを持ち続けていました。
- 今回、開発生産性カンファレンスでこの書籍をいただけたのは、本当に嬉しかったです。
感想
自分がFASTについて認知したのはログラスさんの勉強会がはじめてでした。
当時、私自身は２つのスクラムチームで１つのPBIに対応するプロダクト開発に携わっていて、チーム間の連携に課題を覚え、どうしたやり方が良いのだろうかと悩んでいた時でした。
ログラスさんの勉強会で紹介されていたFASTに魅力を感じつつも、自分一人では実現するには遠く、一緒に学べる仲間を探していたことを覚えています。
結局、FASTについては興味関心を持ったレベルで終わってしまいましたが、いつかちゃんと知りたいと思っていたため、今回の本はとても嬉しかったです。
改めて、今回の書籍を通じて、FASTを実現するにあたっては単にフレームワークを導入するだけではなく、プロダクト開発に関係する全員で前のめりで取り組む必要があることを理解しました。
前のめりで取り組めるからこそ、固定化されたプロセスより流動的なプロセスが効果を発揮するようなイメージをしました。
また、流動的＝不安定になりそうなイメージもありますが、そこに機動力をもたらすのが、プロダクト目線であったり、Update Normalのようなマインドなのかなと想像しました。
特に、流動性を支える自律MAXという言葉が印象的で、だからこそログラスさんのアウトプットはいつも刺激的なんだとも納得しました。
FASTガイドも改めて読みたいと思います。
忘れたくないメモ
私が本書を通じて得た理解や気づきを、自分のためにも書き留めたメモです。
特に印象に残ったポイントを振り返ります。
自分たちで考えることに本気で取り組む
フレームワークで定められた方法を実施する場合は説明が容易です。ただ、 決められた形に則ることは、チームの本質的な課題を考える機会を奪っていると感じます。一方FASTでは、実施方法を自分たちで考える必要があり、その過程でチームが本質的な「Why」を考える機会となっています。難しさはありますが、このように活動を自分たちで考えることに本気で取り組むことで、チームの本質的な課題を考える機会となり、チームの成長につながります。
フレームワークを前提とすることで、かえって思考の幅を狭めてしまうことがあると改めて実感しました。
また、そのうえで、本気で考えることに求められる意思の強さを想像しました。
ひとりひとりが能動的に動ける環境でなければ実現が難しそう、と思いつつ、それがUpdate Normalであると思うと腑に落ちました。
目的意識
流動性の中で自分の軸を持つためには、作業ではなく目的を追うべきという話として理解しました。「自分が所属するこのコレクティブ( ログラスではプロダクトのドメインからとって『経営管理コレクティブ 」という固有名詞で呼ばれている)をどうしていきたいか？それについて自分に何ができるか？」 という観点で考えるようにしたら、流動性が高くても理解しやすくなったかなと感じました
スクラムでもそうしたい、と思いつつスプリント内ではチケットの消化が主軸となり本質を捉えづらくなるのは、固定化が障壁となっているのか。
プロダクトチームをどうしたいか、そのために何ができるか、改めて意識していきたい。
パフォーマンス対応
具体として今取り組みたいところ。将来起きうるであろうパフォーマンス問題を、お客様のご利用環境で顕在化する前に対処すべく、横断チームの特性を活かし先手を打つことにしました。
改めてPlatformチームのように、機能開発チームとは切り出した対応がよさそうとイメージできました。
鼓舞タイム
鼓舞タイム。やりたいです。FASTを始めた当初は「FASTミーティング」のアジェンダの1つに「鼓舞タイム」と呼ばれる、メンバーを鼓舞するための時間があるのですが、個人的には「方針を揃えていく」場として捉える方が、その本質を表していると考えています。
鼓舞＝後押しすること、と考えると、皆でチームの行き先が見えているからこそできることとも思いました。
そうした意味で、方針を揃えていく場のイメージができました。
鼓舞タイム取り入れたいです。鼓舞したいし、鼓舞されたい。
プロダクトマネジメントは開発に関わる全員で取り組むべき
とても好きな考え方でした。プロダクトマネジメントは「プロダクトマネージャー」という名前がついているからPdMだけがやるのではなく、開発に関わる全員で取り組むべきだと考えています。
