2020年11〜12月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事をよく放流しているのですが、社外向けでも需要があるかもなと思い試しに公開してみます。この記事は第2弾です。
ノウハウ・知見
スプリントレビューで共通認識を作る
ヤフーのスクラム開発実践者の経験年数ごとの学習方法の紹介
Miroを使ったふりかえりのテンプレート
A-CSM研修の概要とふりかえり
他社事例
ビズリーチのとあるスクラムチームで心掛けていたこと
大規模組織でのLeSS再導入
Uberアプリでのリアーキテクチャ失敗事例
Classiのアジャイル開発シフト
たくぼんさん(木村卓央さん)にアジャイルコーチをお願いしているとのこと。
勉強会・カンファレンス
スクラムフェス札幌 江端さん基調講演書き下ろし
AgileJapan2020で気になったもの
東京海上日動でのLeSS開発の取り組み。カンバン(Miro)の写真が所々入っていますが、使い方がとても上手。
星のリゾートの事例
アジャイル開発ってなんだったんだっけという話、川口さん
その他
スクラムガイド 2020
平鍋さんにRettyが好きなサービスと言っていただけて嬉しかった
スタートアップからグロースに移る時が、ビジョン維持も文化形成も難しい。大好きなサービスなので歩みがわかって楽しかった。 https://t.co/lh95Kl528S
— Kenji Hiranabe (@hiranabe) 2020年11月21日
プロダクトの「骨」「肉」「皮」のどれになるかで重要度を表現する
優先度「高・中・低」を「骨・肉・皮」にしただけで、「これはプロダクトの骨になるか？？」という観点でめちゃくちゃ議論が捗るようになった。
— 松岡@ログラス/DDD,アジャイル (@little_hand_s) 2020年12月11日
ノリで始めたら予想外の手応え！不思議なもんで、面白いなぁ https://t.co/mx6S38PY8a
SHIFT アジャイル白書2020年版レポート
Spotifyモデルに取り組んでいる国内事例一覧
Spotifyが2013年に発表した組織形態 "Spotifyモデル"を採用している公言する事例が増えてきたなと感じているのでまとめました。公開されている資料をベースにまとめていますが、「うちもやってるよ！」というところがあればぜひお知らせください。
まとめてみるとTribeが必要な開発規模までには至らず、Squadが自律して動くことを指して「Spotifyモデルを採用」と言っているところが多い気がします。
- アクサ生命
- dely
- for Startups,Inc
- READYFOR
- SmartNews
- Wantedly
- GMOペパボ (2020/1/4)
- MSD製薬 (2020/1/6)
- WealthPark (2021/3/13)
アクサ生命
dely
クラシルの開発
for Startups,Inc
スタートアップ情報を発信するSTARTUP DBとタレントエージェンシー支援システム（SFA/CRM）の開発。
READYFOR
クラウドファンディングサービス READYFORの開発
SmartNews
スマートニュースの開発
Wantedly
求人情報ウェブサイトWantedlyの開発
GMOペパボ (2020/1/4)
MSD製薬 (2020/1/6)
RSGT2021の講演資料でTribe / Chapter / Squad といった組織形態を紹介していました。
WealthPark (2021/3/13)
ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方
- 作者:Jonathan Rasmusson
- 発売日: 2021/04/26
- メディア: 単行本（ソフトカバー）
登壇ネタを考えるコツ
この記事はScrumFestSapporo2020 Advent Calendar 22日目の記事です。
はじめに
外部登壇を増やして行こうと考え始めた2019年の中頃、Regional Scrum Gathering Tokyo 2020(以下RSGTと表記)にプロポーザルを出してみましたが結果は落選でした。同じネタを磨いて再挑戦するのか、違うネタを考えるのか、同じネタで違うカンファレンス・勉強会に投稿してみようか・・・。そんな気持ちでスタッフ・スピーカー・スポンサーだけが参加できるRSGTの前夜祭に行ったのが2020年1月のことです。そこでスクラムフェス札幌の準備を進めていたネモトさんと知り合い、「今度札幌でカンファレンス開くのでぜひプロポーザル出してください」とお声かけいただいたことから、RSGT参加中ずっとプロポーザルのことが頭から離れなくなりました。
登壇ネタを考えるのは難しい、そう思っていた時期がありました
RSGTの最終日はみんなで議題を持ち寄って話すOST(Open Space Technology)でした。そこで私は議論ネタとして当時会社で悩んでいたスプリントレビューの雰囲気改善について提案し、多くの方からいろんな意見をいただきました。
そこでふと気がついたのです。「これまとめ直して & 自社で実践してみた内容まとめればプロポーザルになるんじゃないか?」
ということでスクラムフェス札幌にプロポーザルを出してみました。
1件出してみると「せっかくだから大阪にも何か出せないかなー。あっ、RSGTの基調講演でマネージャーの話多く出てたけどマネージャーの参加者・事例紹介少ない気がするから面白いかも」ということで、スクラムフェス大阪にも続けてプロポーザルを出してみました。
スクラムフェス三河もプロポーザルを出すことを考えましたが、「せっかくだから会社のメンバーにも出して欲しいな」と思い、プロポーザルのたたきを作るぐらいまで手伝って2件を投稿 & 採択してもらえました。
ここに挙げた以外でも採択されたやつ・採択されなかったやつ複数ありますが複数のカンファレンス・勉強会に全て違うネタでプロポーザルを出すことが継続できています。吹っ切れたのもあると思いますが、ネタを考えるときの心構えも前と少し変わったなと思うところがあります。
登壇ネタを考えるコツ
- 悩み相談して、もらえたアドバイスをまとめてみる
- 業務での1番の困りごとを出してみる
- 複数人で考える
1. 悩み相談して、もらえたアドバイスをまとめてみる
自分がスクラムフェス札幌で使ったのがこれです。最近OSTを伴う勉強会・カンファレンス増えてきましたが、その場限りの情報共有で終わることが多く、後でブログにまとめられることも少ないのが現状です。やってみてどうだったと報告があるのほとんどないでしょう。
多くの人の知見が集まっているので、これをまとめて発表する・やってみた結果を報告するのはアリかと思います。話の筋立てを考えるのも難しくないはずです。
2. 業務での1番の困りごとを出してみる
1に少し重なるところもありますが、一番時間を費やしている困りごとを発表対象にすると良いでしょう。困りごとを解決できれば業務の成果をそのまま外部発表につなげることができますし、仮に解決できなかったとしても状況を整理して公開することでいろんな解決策を募ることができるはずです。
非採択でしたが、自社だとこれが近しいかも。
3. 複数人で考える
個人では大したことないと思っていることも、他人からしたら十分ネタになる興味深い話に見えていることは少なくありません。会社の同僚、コミュニティの知人に相談してみると「XXXの話してみたら?」とアドバイスをもらえると思います。会社の同僚と行う場合、誰がプロポーザルを書くかは置いておいて、ひとまずネタを出し切ることに注力する方がうまくいくと思っています。
2019年にRettyで行った事例として、昨年のAdvent Calendarでまとめてもらったものが下記です。
おわりに
プロポーザルは「成功事例をきれいに話さないと」と思ってしまいますが、実際の講演を聞いてみるとうまくいってない例も少なくありません。自分たちの取り組んでいること・困っていることを広く問う勇気を持つことで、よりよいプロダクト開発につなげていけると思っております。
来年、1人でも多くの方がプロポーザルを出す助けになれば幸いです。
アジャイル開発を支えるテクニカル面を掘り下げてどこかで話したい
この記事はAgile Tech EXPO Advent Calendar 2020 20日目の記事であり、こんな話ができるぞという売り込みでもあります。
はじめに
2019年に「もっと外に出て発信・情報集めしないとダメだな」と認識を改め、勉強会やカンファレンスに出ることが増えました。特に2020年からは「発信を頑張っていこう」という思いの元、7件の外部登壇を行いました。
- Scrum Fest Osaka 2020でスクラム開発におけるマネジメント、目標設定・フィードバック・評価の話をしてきました #scrumosaka - tuneの日記
- 旅するAgile本箱をRettyの皆で読んだ体験から得たこと / What I learned by reading traveling agile books - Speaker Deck
- July Tech Festa 2020で組織に良い開発文化を植え付ける「Software Engineering Coach」という役割の話をしてきました - tuneの日記
- スクラムフェス札幌 2020で「もりあがるスプリントレビューをしよう」という話をしてきました #scrumsapporo - tuneの日記
- Agile Japan 2020でRettyの開発文化の変革の話をしてきました #agilejapan - tuneの日記
- YUMEMI.pm #1でGo To Eatキャンペーン立ち上げの話をしてきました - tuneの日記
- 分散アジャイルチームについて考える会でスクラム開発におけるマネジメントの話をしてきました - tuneの日記
内容を分類すると組織・文化の話が2件、マネジメントの話が2件、プロジェクトマネジメントが1件、その他アジャイル開発関連で2件です。毎度違う話ができたことは自分でもよかったと思っていますが、アジャイルの「ライトウィング」と「レフトウィング」で分けるといずれもレフトウィング(チーム環境)寄りだと言えます。会社ではマネージャーという立場とは言え、開発部門を盛り上げていく役目ですのでライトウィング(開発環境)寄りのプレゼンスも上げていきたいところです。
今年はアジャイル関連のカンファレンスに一通り出席しましたが、プロセスや心構え、文化の話が多かったように感じています。たまに見かける技術の話・記事であっても「テスト駆動開発」「モブプログラミング」「DevOps」ぐらいのざっくり粒度、またはそれらを取り入れるときの心構え的なものが多く、「マインドやフレームワークに加えて、技術の最新動向をお届けするカンファレンス」を目指すAgile Tech EXPOには期待をしています。
ということで前置きが長くなりましたが、Howをもっと細かくした発表をどこかでしたいなと思っております。
(仮題)アジャイルに進めることに向き合った結果、技術ってこうなりますよね
設計
- 当たり前だけどきちんとやる。アジャイルは設計しないなんてことはない。
- クリーンアーキテクチャとか、クラス構成とか、実装言語とか、最新技術を話す前にすることがある。
- ユースケースをきちんと拾い上げて正常系・異常系を網羅できているのかきちんと確認する。
- 関係者をきちんと呼んでやる、総務・営業・企画・CS・QAなど
- 責務が適切かとか見る。
- PRを出してから設計議論を始めない。どう実装するかを先に議論し、認識を合わせておく。
構成管理
- ブランチを切りたくない。
- 短くマージして統合し続ける。
- トランクベース開発
ライブラリ更新
- Dependabot (Renovate)を入れて楽をしましょう。
リファクタリング
- システムを作り直せば問題が解決するなんてことはほとんどない。
- リファクタリングの時間が取れないという言い訳
- 毎コミットリファクタリングする
- あなたが知っているすごいプログラマは「リファクタリングしていいですか」なんて許可とっていない
- バグ修正・機能追加の最後に「リファクタリングタスク」積んでみたら?
コードレビュー
- バグを見つけるプロセスではない。
- 「読みにくいんですけど」という率直な指摘
テスト
- 単体テストを書けばバグがでなくなるという幻想
- 多ければ良いという物ではない。失敗しないテストは書く意味がない。
- 最後に起きた障害は単体テストがあれば防げていた物ですか?
- サービス全体で落としてはならない正常形をテストし続ける。
リリース
- リリーストレインという考え方。含める機能を決めてリリース日をずらすのではなく、リリースに間に合った機能を随時出していく。
- フィーチャーフラグを仕込んでおく。本番環境で動かす機能を制御できるようにする。
監視
- 計測せよ
- 警告・エラーを0にする。
- 毎日見る、みんなで見る。
ドキュメント・引継ぎ
- ドキュメントで引き継げるという幻想
- タスクを手分けして属人化を防ぐ。
おわりに
ということでオファーお待ちしております。
分散アジャイルチームについて考える会でスクラム開発におけるマネジメントの話をしてきました
2020年12月17日に行われた分散アジャイルチームについて考える会でスクラム開発におけるマネジメントの話をしてきました。
distributed-agile-team.connpass.com
スクラムフェス大阪の話の続編であり、当時いただいた質問を元にRegional Scrum Gathering Tokyo 2021にプロポーザルを出していたお話となります。プロポーザルは残念ながら落選してしましましたが、勉強会主催者のきょんさんよりお声がけいただき、興味のある方に話を聞いてもらえる良い機会をいただくことができました。
この勉強会ですが、存在は前から知っていたものの参加するのは初めてでした。「濃いメンバーが集まる、議論が大好きな勉強会」という印象を持っており、せっかくだから答えのないもの・モヤモヤもそのまま持っていき、議論の種・酒の肴になればと思って資料を用意しました。そのおかげか勉強会のDiscordでは多くのコメント・質問・指摘をもらい、自分の過去登壇を含めても一番の熱量だったのではないかと思います。
プロポーザルの落選は残念ではありましたが、興味のある人に声をかけてもらい、話ができる機会が作れるのであれば今後も継続してプロポーザル投稿を続けていこうかと思います。
参加してくださった皆様、遅くまでお付き合いいただきありがとうございました。
参加レポート
YUMEMI.pm #1でGo To Eatキャンペーン立ち上げの話をしてきました
2020年12月10日に行われたゆめみ主催のプロジェクトマネージメント勉強会で「Go To Eatキャンペーン立ち上げ」時のプロジェクトマネジメントについて5分のLTを行ってきました。
今年の半分以上をGo To Eatキャンペーンに費やしており、締め切りありきの開発では久しぶりのプロジェクトマネジメント業を行いました。日々の業務で創意工夫したことを短くまとめて発表する機会をいただき、準備してくださったゆめみの皆様、聞いてくださった参加者の皆様に感謝しております。
「スクラムマスターは真のリーダーである」によって生じそうな誤解
はじめに
スクラムガイドが更新されました。 変更について色々と考察・議論を見かけますが、個人としては「スクラムマスターは真のリーダーである」が引っかかっています。
スクラムマスターとサーバントリーダーシップ
自分の理解ではスクラムマスターは役職では無く役割でした。プロダクトオーナーも役割、開発チームも役割であって、上下関係のない対等の3者が存在することでパワーバランスが保たれ、プロダクトに向かう一致団結する力が生まれていたのだと思っています。
「スクラムマスターとしてサーバントリーダーシップを発揮して欲しい」というこれまでの説明は納得感がありました。 自分がスクラムマスターを人にお願いする時にも「リーダーをお願いしているわけじゃ無いよ」「チームをまとめて、サポートしてあげて」と説明するようにしていました。
多くの組織にとってリーダーは肩書き・役職
- スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。
- スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクスを全員に理解してもらえるよう支援することで、その責任を果たす。
- スクラムマスターは、スクラムチームの有効性に責任を持つ。
- スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
- スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。
- スクラムマスターは、さまざまな形でスクラムチームを支援する。
元の文章にきちんとあたると「チーム・上位組織に奉仕する」とサーバントリーダーシップの流れを汲む説明が記載されているのですが、リーダーと呼称してしまうことで違う問題を引き起こしてしまう気がしてなりません。
日本の組織の多くは管理職になる前のステップに「リーダー」という肩書き・役職を置いていることが多いと思います。 リーダーが一人選ばれ、メンバーがそれに従い、プロジェクトを進めるという構造です。 リーダーは出世街道に乗っている人だったり、次の管理職候補でだったり、チームを技術的にも精神的にも支えている人です。 従来からあるリーダーの肩書きを付け替えてスクラムマスターに仕立て上げることも少なくないようです。
「スクラムマスターは真のリーダーである」という短いメッセージと、「リーダーはプロジェクトをまとめて引っ張らなければならない」という従来の発想が結びつくことで、リーダーの「導いてあげないといけない」いう誤った責任感、メンバーの「リーダーに任せて後をついていけば良い」という誤った認識を増長してしまうのではないかというのが私の懸念です。 コミットメントに責任を感じないスクラムマスターは問題ですが、とはいえ真のリーダーという言葉を引っ張り出してくることで意識してもらうのは短絡的かなと感じました。
おわりに
ガイドなのに解釈について皆が議論しているのが面白いなとブログ・Twitter・勉強会の様子を眺めていて感じました。 ガイドというよりも教典に近い位置付けをしている人が多いのだと思っています。
