こんにちは。バックエンドエンジニアのshirakawaxです。
ミラティブでは施策開発フローとしてスクラムを採用しています。 スクラム導入から数年が経ち、フローは安定してきました。その一方で「もっと良くできるはずなのに、どこから手をつければいいんだろう」という感覚がチームの中にありました。チーム内外でスクラムへの前提知識にばらつきがあり、共通の文脈を持って議論できる場を作りたい——そんな思いから、2025年2月に「スクラム勉強会」をスタートしました。
ちょうど1年が経った今、この記事では取り上げた5冊の本と、そこから生まれたチームの気づき・変化を紹介します。
なお、スクラム導入に関するテックブログもあるので、あわせてご覧ください。 tech.mirrativ.stream
勉強会の形式
- 頻度: 週1回、30〜60分
- 形式: 事前に指定された箇所まで各自で読んでおき、Confluenceに感想を書いてから集まって議論する
- 本の選び方: メンバーが読みたい本を持ち寄り、投票で次に読む本を決める
スプリントゴールで価値を駆動しよう
勉強会の最初の一冊として選んだ本です。スプリントゴールとは何か・どう設定すべきかという実践的な内容から始まり、スクラムの本質的な価値に立ち返らせてくれます。
序盤ではクネビン（Cynefin）フレームワークを通じて「ややこしい（分析すれば答えが出る）」と「複雑（まず調査・実験しないとわからない）」という領域の違いが解説されます。「自分たちが"ややこしい"ではなく"複雑"なドメインにいると自覚できた」という声が印象的でした。後半ではスクラムの2つのスタイルが紹介されます。バックログ消化に執着する「アナコンダ・スタイル」と、摩擦に柔軟に適応する「ハチドリ・スタイル」です。自分はアナコンダ寄り、ハチドリ寄りといった形でチームを当てはめながら読んだメンバーが多かったです。
「スプリントバックログの完了をゴールにすると技術的負債を作る」という記載には「PBIが全部完了になるよう頑張って仕事してた」という正直な振り返りも出ました。輪読後は「驚きや摩擦に対処しているんだなという気持ちで、前より冷静に対応できるようになった」「憶測で物事を進めようとしている自分に気づきやすくなった」という声が複数あり、仕事への向き合い方が変わったメンバーも出た一冊です。
エッセンシャルスクラム
スクラムの全体像を体系的に解説した、いわば「スクラムの辞書」とも呼ばれる定番書です。チーム全員がスクラムの概念を同じ解像度で持つために読みました。
印象に残ったのは「スクラムは組織的な病に対してレシピのようなソリューションを与えてはくれない。組織のポテンシャルを妨げている機能不全やムダを可視化してくれるだけだ」という一節で、複数のメンバーが挙げていました。
プロダクトオーナーとスクラムマスターの役割については「求められるスキルセットが高すぎる」という本音が出つつも、「POの負担を減らすために自分たちができることは積極的にやりたい」という意識につながりました。「WIP（仕掛かり中の作業）は在庫と同じ」という考え方も刺さったメンバーが多く、「作業者の手待ちではなく、作業の手待ちに注目せよ」という言葉もチームに響くフレーズとして残りました。自分たちの開発体制（バックエンド中心で個別作業の寄せ集め感が生まれやすい構造、1週間スプリントの是非）と照らし合わせながら読んだメンバーが多く、抽象概念にとどまらず実際の開発プロセスをどう変えるかを話し合う機会が多かった一冊です。
クルーシャル・カンバセーション
「重要な会話」をいかに乗り越えるかを扱った一冊です。スクラムに直接関係する本ではありませんが、開発プロセスを改善するためには結局「人と話をつける」必要があるという共通認識から選びました。
「1〜2章だけで名著の予感がすごい」という声が出るほど序盤から引き込まれる本です。対話を通じてお互いの認識を共通の「プール」に積み上げていくというモデルは「イメージしやすい」と好評でした。「日本人は争いを避けて逃げがちで、振り返ると適切に対処できた場面があまり出てこない」という自省的な声も。コードレビューがこうした重要な会話が頻発する場面だという話も上がり、「本音を探る対象は相手ではなく自分だというのが面白い」「思い込みで感情を動かしている自分に気づいた」という気づきが生まれました。
実際に対話をする際に「アドレナリンが出始めたタイミングを意識するようになった」と行動変化を感じたメンバーもいます。また、相手の誤解を先回りして防ぐ「コントラスト化」というテクニックも「予防にも使えると知って参考になった」という声がありました。最終章の「全テクニックを完璧に使いこなせなくてもOK」というまとめには「安心した」という反応があり、まず「観察する」と「安心させる」の2つを意識してみようというメンバーが多かったです。
ユーザーストーリーマッピング
「製品開発の目標は製品を作ることではない」「ストーリーを使う目的は良いストーリーを書くことではない」という書き出しが印象的な一冊です。スプリントゴールやバックログ管理と合わせて、プロダクト開発の全体像をチームで共有する手法を学ぶために選びました。
MVPを「仮定を証明または反証するために作れる・実行できる最小のもの」と定義し直す視点は新鮮でした。
「完璧なドキュメントを必死に書くことをやめ、ともにストーリーを語ることにした」という言葉には多くのメンバーが共感しました。「同じドキュメントを読んでも、人によって理解は異なる」という指摘は、エンジニア・PM・デザイナーそれぞれの解釈のずれを実感しているメンバーには特に響き、UIの早期可視化と段階的なすり合わせの重要性が改めて話題になりました。「全てのリリースを新しい知識を獲得するための実験として扱い、何を学びたいのかを忘れないようにしたい」という声もあり、リリース後に学びを積み重ねていく姿勢がチームに広がっています。
ドキュメント・コミュニケーションの全体観
良いドキュメントとは何か・どう作るかを体系的に解説した一冊です。リモートワーク環境での非同期コミュニケーションの質を上げたいという課題意識から選びました。
「不要なドキュメントを作ること自体の無駄（つくる無駄）」と「それを読まされる側の無駄（付き合わされる無駄）」という概念の紹介では、ドキュメントを書く前に目的を問う意識が共有されました。
1ページに1メッセージという原則については「卒論スライドで教授にさんざん言われた」というエピソードがあり、「油断するとやってしまう」「その癖がついている」と複数のメンバーが自覚していました。4段階の清書アプローチ（ラフな構成 → 仮テキスト・仮図表 → 清書 → 校正）は「時間がかかりそう」という率直な感想がある一方、「6割で出してフィードバックをもらうアジャイルな進め方と似ている」という見方も出ました。
まとめ
1年間・5冊の勉強会を通じて、チームにいくつかの実践的な変化が生まれました。「スプリントゴールをちゃんと設定しよう」「これはクルーシャル・カンバセーションが必要な場面だ」といった形で、本で学んだ概念が日常会話に自然と登場するようになっています。共通言語ができたことで、開発プロセスの課題を率直に話し合いやすくなりました。
個人的に最も影響を受けたのはクルーシャル・カンバセーションです。開発プロセスを改善するには、結局は人と話をつける必要があります。リモートワーク環境では距離が生まれやすいですが、この本をきっかけにコミュニケーションへの向き合い方が変わった場面がありました。
書籍を読むだけでなく、チームで感想を持ち寄って議論する場を設けたことで、「自分だけが感じていた違和感じゃなかったんだ」という共感が生まれたり、普段の業務では話しにくいプロセスの課題を安全に議論できたりするようになりました。それがこの1年で一番の収穫かもしれません。
興味を持った方はぜひ読んでみてください。
We are hiring!
ミラティブでは、一緒にサービスを作っていくエンジニアを絶賛募集中です。
今回紹介したような、チームで学び・対話しながら開発プロセスを継続的に改善していく文化があります。スクラムやアジャイルに興味がある方、リモート環境でも高い密度でチームとしてものを作ることに挑戦したい方は、ぜひご連絡ください！日本全国どこからでもフルリモート勤務が可能です。
