2020年9〜10月に社内で共有したアジャイル開発関連の記事
社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事をよく放流しているのですが、社外向けでも需要があるかもなと思い試しに公開してみます。有用そうだったらシリーズ化するかも。
ノウハウ・知見
リモートワークのノウハウ
Agileリーダーシップ研修の感想
コードレビューを通じたメンバー育成
リリースとはユーザー(とかステークホルダー)に使ってもらって、フィードバックをもらうことだよねという話
Silver Bullet Clubによるチーム開発の振る舞いパターン集
中村洋さんのコーチメモ。
分量も多くたまに見返すと新たな発見があるかも。
振り返りのアンチパターン
ふりかえり手法のまとめ
他社事例
atama plus
LeSSに移行したatama plusの開発体制図
atama plusはLeSS見学レポートもありました。
norihiko-saito-1219.hatenablog.com
カオナビ
自社に似ている雰囲気を感じる
SmartHR
LeSS事例、複数PdMの同期はうちも学ぶところがあるかも
勉強会・カンファレンス
ふりかえりam KPT as ART
スクラムフェス大阪の基調講演書き起こし
その他
Why communication is important in software development 🙂 pic.twitter.com/1I2v9cPMKT
— Ricardo Ferreira (@riferrei) 2020年9月18日
Re: SmartHR 社内でスクラム勉強会を開催した話
練習問題が面白そうだったので自分のブログに回答を載せてみます。
第二回：経験主義と透明性・検査・適応について
Q: 経験的プロセス制御の実現において、なぜ透明性が重要なのでしょうか？ また、透明性がある状態の具体例を教えてください。
A : 「進捗どうですか?」→「順調です、進捗80%です」→「問題が発生してスケジュール遅延しそうです」というよくあるダメな進め方をしないため。 チームの外から見て見える形で状況がわかるように保つ。
透明性がある状態の具体例とは・・・
- チーム外のメンバーがカンバンなど見える化された何かを見て、作業状況・進捗・リリース日の目安などがわかる。
- チーム外のメンバーがチームに進捗に関する質問をして、誰に聞いてもすぐに同じ答えが返ってくる。
- 開発中のものを部分的にではあるが動かして、できている状況を確認することができる。
Q : 経験的プロセス制御の実現において、なぜ検査が重要なのでしょうか？ また、検査できている状態の具体例を教えてください。
A : 定期的に検査を挟まないと、自分たちが進んでいる方向性・スピードが十分なのか判断がつかないため。
検査できている状態の具体例とは・・・
- 開発中のもの・開発が完了したものを実際に動かして、受入条件を満足しているかどうかデモで確認してもらうことができる。
Q : 経験的プロセス制御の実現において、なぜ適応が重要なのでしょうか？ また、適応できている状態の具体例を教えてください。
A : 新しく得た情報・変化した状況に追従し、計画を見直していくため。週間天気予報を毎日更新するのと同じ。
適応できている状態の具体例とは・・・
- 開発過程で受入条件の抜け・漏れが見つかったので項目が見直され、リリース日が見直された。
第三回：プロダクトオーナー / 開発チーム / スクラムマスター
Q : プロダクトオーナー / 開発チーム / スクラムマスターをそれぞれ何かに喩えてください。また、それに喩えた理由を教えてください。
A :
- プロダクトオーナー：J.Y.Park 音楽プロデューサー、ビジョン・ゴールを示し皆を導く。
- 開発チーム : NiziU メンバー、歌唱力・ダンスを磨き、ファンを魅了する音楽を提供する。
- スクラムマスター : 歌唱コーチ・振り付けコーチ、メンバーに基本を教え、訓練によって苦手を共に乗り換え、プロダクトオーナーが描くゴールへ伴走する。
Nizi ProjectのJ.Y.Park氏に学ぶことが多いなと最近感じているので(※番組は未視聴)
Q : なぜプロダクトオーナーは「一人の人間」でなければならないのでしょうか？
A : 利益が相反する事象の決定は誰かが決めるしかなく、複数人いるとその判断基準や責任がぼやけてしまう。
Q : 自己組織化チームとは一言で表すとどんなチームでしょうか？ また、なぜ自己組織化チームである必要があるのでしょうか？
A : 自分たちの管理を自分たちでできるチーム。マネージャーがマイクロマネジメントで進めるのであればマネージャーの能力を超える成果は生み出せない。 何かしら見落としや対処遅れが発生し、チームが成果を出す阻害要因になってしまう。
第四回：スプリント / スプリントプランニング
Q : スプリントの長さを固定するのはなぜでしょうか?
A : 開発にリズムを持たせるため、一定間隔で経常的にアウトプットを出していくため、うまくいかない時に比較しやすくするため。
Q : 直近の 3 スプリントをすべてバーンダウンできなかったチームの中で、スプリントを 1 週間から 2 週間に伸ばした方がいいのではないかと議論になっています。あなたがスクラムマスターなら、どのように振る舞いますか？ その理由も教えて下さい。
A : スプリントの期間を延ばすのは簡単だけど今うまく行ってないなら振り返りをして短く改善していった方がよいし、もう少し1週間で続けてみたらどうかな? 3スプリント続けて終わらなかったなら、次のスプリントは思いきってやることぐっと減らしてみたら? もし全部終わったならバックログからおかわりしたっていいんだし。
理由：スプリントを長くするのは最後の手段。立ち上げ当初は振り返りを数多くこなして改善サイクルを作った方が良い。
Q : あるチームがスプリントプランニングに丸 2 日かかってしまいました（スプリントは 1 週間）。残りの期間で計画したタスクは全て Done し、PBI は PO に受け入れられました。あなたがスクラムマスターなら、どのように振る舞いますか？ その理由も教えて下さい。
A : 開発を始めて見落としが見つかったらリスキーじゃない? 今回はラッキーだったけど、いつも全てを見通してから開発に着手できるわけじゃないからある程度のところでプランニングは打ち切って手を動かすのは大事だと思うよ。1週間の開発なら2時間ぐらいが上限じゃないかな? 少し開発してみて改めて計画を見直すならそれでもいいからさ。
理由：設計は十分に行った方が良いが、手を動かさないと何も経験できない。経験できなければ開発を進めるリスクはちっとも下がっていないことになるため。
第七回：インクリメント / 完了の定義
Q : とあるスクラムチームの PO から、スクラムマスターであるあなたに以下のような相談がきました。「1ヶ月前に完了の定義を作ったのはいいものの、リリース後に完了の定義が満たされていないことがたびたび発覚します。また、完了の定義を満たした PBI であっても、リリースするまでにいくつかの調整を私が行なっています。どうしたらよいでしょうか？」。あなたがスクラムマスターならどのように振舞いますか？ また、その理由も教えてください。
A : 完了の定義が満たせていないのは開発チームと私の責任です。リリース調整までお願いしてしまって申し訳ないです。開発チームと話し合いをして改善を検討します。 ・・・と伝えて完了の定義をチームが確実にできるレベルにまでいったん落とす。その上で少しずつ完了の定義のレベルを再度上げていくようにする。
理由：守れない崇高なルールを掲げるよりも、自分たちのレベルに見合ったルールを守り、スキルアップしていく方が良いと考えます。
Q : とあるスクラムチームはレシピ検索サービスの Android アプリを製作しています。そのアプリは同じ会社の別チームが開発する Web API に依存しています。スクラムチームは毎スプリント Android アプリをインクリメントとして作成していますが、アプリは実際に Web API に繋いでいるわけではなく、スプリント終了時点ではモック API に繋いでいます。Android アプリの開発が Web API の開発に先行しており、モック API が返すサンプルレスポンスを使用するしかないためです。そのような状況で、あなたがスクラムマスターならどのように振舞いますか？ また、その理由も教えてください。
A : Web APIを開発しているチームのところへ行き、「バックエンドと繋いでの開発・検証を回していきたいので開発を手伝わせてください。お作法にはきちんと従いますのでmm」という話をして、コードを触っても良い了解を取る。
理由：チームは価値提供に必要な上(Androidアプリ)から下(Web API)まで触れるべき。そうでないとデリバリーが他依存になってしまい、安定したデリバリーができなくなる。
「Clean Agile 基本に立ち戻れ」を読んで考えたこと
- 作者:Robert C.Martin
- 発売日: 2020/10/03
- メディア: 単行本
Clean Agileを読みました。 きちんとした書評は会社のTech Blogで公開予定のため、ここではボブおじさんの発言に対して個人的に感じたこと・考えたことを書き留めておきます。
大規模アジャイルについて
書籍の中で一貫して否定されていました😭
書籍の中で「そんな問題は存在しないと思う」とされていました、そうなのかな🤔
今の会社で大規模スクラム(LeSS : Large Scale Scrum)を推進していますが、「これは本当に必要なものなのか、疑う気持ちはわからんでも無いな」という気持ちもあります。 「すでに開発者がたくさんいるから大規模アジャイルを導入しなければならないんだ」となっているような感覚です。 自分で事業スピードと開発者数をコントロールできるのであればやりますかと言われると・・・やらないかもしれません。 チームのスケーリングの話は昨年末にCopeの話を聞いたときも考えさせられました。
ボブおじさんは小さなスクラムチームをたくさん作れば良いんだと主張していたように思えたのですが、それはそれで良いとも思えません。 またBasecampが少人数チームで2年かけてHEYを作ったという話を聞くと、「人数を増やしてリリースまで短くすることはできなかったのか」とも思ってしまいます。
「皆が一丸となり、偉大なサービスを、再現性を持って作れる」これがポストアジャイルなのかもしれません。
こちらはインドネシア･バリ島で撮影されたミナミゴンズイの稚魚の群れです。塊となって捕食者から身を守りつつも、群れ全体で回転しながら海底のエサを食べています。これなら、どんな魚も逃げてしまいそうですね。pic.twitter.com/15sWjDtC5I
— エピネシス (@epinesis) 2020年10月10日
アジャイルはソフトウェア開発のもの
スクラムガイドはソフトウェア開発のためのものという前置きを外していますが、スクラムよりも広義を指すアジャイルがソフトウェア開発だけのものというのはうーんと思います。 アジャイルHRや開発以外のスクラム導入事例も少なからずあるのでこの先もっと広まるのでは無いかなと考えています。
資格は意味が無い
自分もアジャイル開発に取り組むようになって4年半ほど経ちましたが、CSM/CSPOなどの資格試験は取らずにきてしまいました。 一線級のコーチの言葉で学べるメリットは有用だよなと思うのですが、資格試験そのものに意味がないことは同意です。
RSGTに行くとみんな資格好きだなーと思います(参加賞に取得資格を示すシールが貼れるようになっているんです)
コーチはいらない
「コーチいらない」といいながら「自分自身の振る舞いを確認するのにコーチは有用」とも言っていて書籍の中で主張がぶれています。
「コーチいらない」といいながら、後になってコーチングについて意見の異なる友人を肯定する一節が入り、どっちのスタンスなんだろうと混乱しましたが、コーチはいらないがボブおじさんの基本スタンスのようです。(補足いただいて訂正しました)
始めたばかりのコーチ(=トレーナー)はずっとは必要ないけど、定期的にアジャイルから外れていないかを確認するための壁打ち相手は必要なのではないかと思います。
アジャイルソフトウェア開発宣言は見直さない
「陳腐化するはずがないことを皆で合意して署名したのだから見直す必要がない」というのは腹落ちしました。
技術が重要
RSGTもそうですが、「フワッとした」思想を話すプロポーザルが増えているなと感じていたので、アジャイルな開発を支える技術プラクティスへの揺り戻しが来る気がしていますし、自分が外部発表をする時にもそのような割合を増やして行こうかなと思っていました。
この間1回目が開催されたAgile Tech EXPOはドンピシャですね。
関連リンク
Shape Up - Basecampによるプロダクト開発ガイド
はじめに
Basecamp社が公開しているプロダクト開発ガイド「Shape Up」の存在を知り読んでみました。 Basecamp社はプロジェクト管理SaaS Basecampの開発元で、以前は37 Signalsという社名でした。 Ruby on Railsの作者 David Heinemeier Hansson氏がCTOを務め、最近だと新機軸のメールサービス Hey を立ち上げています。
特徴
Basecamp曰く「アジャイル開発でもスクラム開発でもない」、Basecamp社で15年近く試行錯誤して改善してきたやり方だそうです。
「6週間の開発サイクル」と「2週間のクールダウン期間」を繰り返して開発を進めます。 サイクルの途中で中断・見直しはせず、期間内にリリースに至らなかった場合でも期間延長はされません。 6週間は「何か意味のあるものを最初から最後まで作り上げるのに十分な長さ」であり、「誰もが最初から期限を感じることができるほど短い」、経験から導き出した開発期間とのことです。
開発チームが着手する前に少人数のシニアグループが事前に検討を済ませておきます。 ただしこの事前検討(Shaping)は適切な抽象度までで留めるよう留意します。 「チームが何をすべきかを知っているほど具体的である」一方、「詳細を自分たちで考え出す余地がある」程度を目指します。
進め方
- Shaping
- Betting
- Building
Shaping
開発する項目を考えますが、「適切な開発スコープを切り、事前に決めすぎないようにバランスをとる」ことに留意する必要があります。
「開発前に決めすぎない」とは下記のような事例を指します。
- ワイヤフレームを描いてしまうと具体的すぎます。開発着手後にデザイナーが創造性を発揮する余地がありません。
- 言葉による説明は抽象的すぎます。開発着手後にチームが要件を満たす中でトレードオフを見つけるのに十分な情報を与える必要があります。
ガイドではプロジェクト管理ツールにカレンダーを追加しようとした例が挙げられています。 通常カレンダーには月・週・日のビュー切り替え、予定の移動などたくさんの機能が求められていますが、6週間内でリリースするには機能を絞り込む必要があります。 そこで「月表示のカレンダーにイベントをドットで表し、クリックすると詳細が見える」ところまでに機能を限定したそうです。 その際のShapingでのデザインが下記です。
これが開発完了時にはこうなりました。見比べると当初のデザインは詳細が省略されているものの必要な要素は満たしており、何がスコープの範囲外になるのかが明確になっていたことがわかるかと思います。
Shapingはインターフェース・技術的な実現性両方を考える必要があり、ジェネラリストが行うか、デザイナーが主導し他のメンバーと協力して進める必要があります。 インターフェース検討時にワイヤーフレームは具体的すぎるため、インターフェースを構成する主要なコンポーネント・関係を元に議論します。
- Places : 画面・ダイアログ・ポップアップなど、ナビゲートできるもの。
- Affordances : ボタン・入力欄などユーザーが操作できるもの。
- Connections : ユーザー遷移
Shapingのアウトプットは開発スコープを説明する「Pitch」です。 Pitchは下記から構成されます。
- 問題点 - 生のアイデア、ユースケース、またはこの作業に取り組む動機となる何か
- Appetite(食欲) - どのくらいの時間を費やしたいのか、そしてそれがどのように解決策を制約するのか
- ソリューション - すぐ理解できる形で提示されたコアな要素
- リスク
- スコープ外の項目
Pitchはステークホルダーが時間のあるときに読めるよう、課題管理システムのIssueにまとめているなどして置いておくそうです。
各Pitchに対しては以下の2種類に分ける程度の見積もりしかしません。Shape Upの用語では"Appetite(食欲)"と呼びます。
- Small Batch : 1人のデザイナーと1〜2名のプログラマーが1〜2週間で実装できるサイズ。
- Big Batch : チーム全員で6週間かかるサイズ。
Betting
次の6週間で取り組むPitchの候補は"Betting Table(賭け)"の場に持ち込まれ議論されます。 Betting Tableはクールダウン期間に行われる会議で、CEO・CTO・シニアプログラマー・プロダクトストラテジストが参加します。 全員が事前にPitchを読み込んだり、関係者と話して勉強してきているため長くかからず、1〜2時間程度で終わるそうです。
計画ではなく期待値を決める賭けの場であり、6週間後に何か意味のあるものが完成することを目指します。 失敗しても高々6週間分のリソースが失われる程度に抑えるリスクヘッジの仕組みでもあります。
チームは「 デザイナー1名・プログラマー1 or 2名・QA担当者 (サイクルの後半で統合テストを行う)」で構成されます。 6週間の間、割り込みがないように留意します。
バグが見つかった場合、下記のいずれかで対処します。
- 2週間のクールダウン期間を使う
- Betting Tableにバグ修正を持っていく
- バグ対処だけを行う日を決めてそこで対応する
Building
早期にPitchをタスク分解してしまうと全体像を見失ってしまいます。 これはタスクが割り当てられてしまうと、互いの作業の関係性に注意が向かず、判断する責任を感じなくなってしまうためです。
そこでチームは手を動かしながら適切なスコープ(単体で価値が提供できる切れ目)を見つけ、開発タスクを徐々に分解していきます。
スコープが正しいことを示すサインは下記の通りです。
- プロジェクトの全体を見渡せるような気がして、心配するような重要なことが細部に隠れていない。
- スコープが適切な言葉を与え、プロジェクトについての会話がスムーズである。
- 新しいタスクが出てきたとき、どこに配置すればいいのかがわかる
進捗は「できたこと」「できていないこと」ではなく、「わからないこと」「解決したこと」にフォーカスします。 プロジェクトを丘にたとえ、スコープごとに今現在どこにいるかを示すことで進捗を見える化します。
6週間で終わらなかった開発を継続する場合、下記の両方を満たす必要があります。
- 価値が十分に議論され重要である
- 丘を登り終え、下り途中である
リリースすると顧客から負のフィードバックをもらうこともありますが、しばらく待って注意深く観察します。 安易に対応したり、過去バージョンに戻したりせず、機能修正の対象としていた顧客の反応をきちんと見ましょう。 またフィードバックはすぐに対応せず、次の賭けとしてBetsにかけます。
HEYの開発事例
すべてShape Upのプロセスに従って進めた。1年間のシニアチームによるR&Dと1年間の製品開発、リリース前の整理に2サイクルを費やしたとのこと。
- 1年間のR&Dモード(Jason（CEO）、David（CTO）、Jonas（シニアデザイナー）の3人のチーム)
- 1年間の開発期間
- 2サイクルのクリーンアップ
感想
ポジティブな面
- スクラムが明示的に規定していないノウハウを埋めてくれそう。
- 着手前の設計・技術調査
- 事前に設計しすぎないとはどういうことかという事例。
ネガティブな面
- Basecampのような思想(少数の価値ある機能に注力し磨いていく)を前提にしていないと合わなそう。
- 運用するのが難しそう。
- 方向転換できるまでに8週間かかる。スタートアップでは長すぎ、ビジネスモデルを確立した企業では享受できるメリット(機能を絞り込んで開発し磨く)が小さいのでは?
- 原文を読むとわかるがBetting以降の章はルールでなく運用ノウハウ・コツが多い。
小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
- 作者:ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン
- 発売日: 2012/01/11
- メディア: 単行本
- 作者:ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン
- 発売日: 2014/04/01
- メディア: Kindle版
スプリントレビューのやり方・オーバーオールレトロスペクティブのやり方 - LeSS Q&A
@yohtakuさんからLeSSのプラクティスをどう実践しているかに関する質問をいただいたのでブログにも転載しておきます。
1：バザー形式のスプリントレビューのやり方
Q: 1ヶ所に集まって、みんなでワイワイやるって感じですが、オンライン&リモートの環境でどうされていますか？ オンラインでも同じように1つに集まっているのか、それとも別々にやっているのか？など。
スプリントレビューは集まって各チームの代表者がデモする形でやっており、バザー形式ではやっていません。現在はMeetで代用しています。
バザール形式にしていないのは下記の理由です。
- LeSS移行当初は仕様の不統一がプロダクトで目立ち、指摘やフィードバックを全員に聞いて欲しかった
- 質疑応答がいま一つ盛り上がらないことが多く、分散化してさらにフィードバックが減ることを嫌った
1, 2はだいぶ解消してきたので、リモートを辞めたらバザールを再度検討するかもしれませんが、今のところ変更する予定はありません。
前職もLeSSでスプリントレビューに悩んだことがありましたが、その時は
- 同じ内容を何度もデモするのが辛い
- ステークホルダーの意見を聞きたい人が多く、バザー形式にすると聞けない人が多く出た
という懸念もありました。
オンラインで開く場合、Discordで行うと、「集まっている」感じが出て良いかなと思っています。
2：オーバーオールレトロスペクティブのやり方
Q: 1と似たような感じですが、わりと参加者が多めになると思っています。 どのようにやっているのか事例やハマった点(変わっていった点など)があればお聞きしたいなと。
オーバーオールレトロスペクティブの定義は下記を参照
LeSSのルール (February 2016 (5)) - Large Scale Scrum (LeSS)
オーバーオールレトロスペクティブは各チームのレトロスペクティブの後に行われる。ここでは複数チームの共通課題や広い領域の課題を扱い、改善に向けての試みを決める。この場にはプロダクトオーナー、全スクラムマスター、チーム代表とマネージャー（いる場合）が参加する。
自分たちはチーム代表者(スクラムマスター)とマネージャーで毎週開催しています。 各チームで振り返りをしてもらった後、振り返りの概要とチーム内で解決できない課題のエスカレーションの場として設定しています。 定義を参照しても「メンバー全員でやる」とはなってないですね。
あまりハマった記憶はないですが、それなりに重たい宿題が上がってくることが多いので、対処する課題は絞って少しずつ解消していくように気をつけてはいます。
July Tech Festa 2020で組織に良い開発文化を植え付ける「Software Engineering Coach」という役割の話をしてきました
はじめに
インフラエンジニアの祭典 July Tech Festa 2020で登壇の機会をいただき話してきました。今年のテーマが「Extend Your Engineering Life」ということで、自分のキャリア観についての話となっています。ひっそりTwitterなどのプロフィールは「Software Engineering Coach」に変えていましたが、今日を機にもっと積極的に名乗って行こうと思います。
講演動画
B2：組織に良い開発文化を植え付ける「Software Engineering Coach」という役割 - JTF2020
当日Slidoでいただいたコメント
Software Engineering Coach という役割は、社内でどのくらい浸透していますか？
自称なので浸透していません。これから名乗って行きます。
マネージャーという立場とコーチという役割の利害関係がぶつかる場合がありそうだなと思いました。やはりその都度いろいろな検討をされたのでしょうか。
利害がぶつかって他に手がない場合はマネージャーに倒して考えることが多いかなと思っています。 利害関係がぶつかることは頻繁にはないのですが、頻度が多くなるなら役割を分けることは必要なのかもしれません。
Twitterでいただいた主なコメント・質問
「良いソフトウェア開発を続けていきたい」自分QAだけど共感 #JTF2020B
— かわうそ@yuira (@mld_code_yuira) 2020年7月25日
そうですよね、役割に関係なく良いソフトウェア開発やりたいですよね。難しい願いじゃないと思うんですが、やってみると難しいんですよね。
銀の弾丸らしきもの？錯覚するもの、かな。自分の周りだと...テスト自動化...かな。下手すると現場的には「QA」そのものをそう思ってたりとかしそう #JTF2020B
— かわうそ@yuira (@mld_code_yuira) 2020年7月25日
実際に効く弾丸(ただしとどめを刺すには至らず効果がいずれなくなる)と、効果がない錯覚が混じっているような気がします。テスト自動化は今まさにハイプを上り詰めようとしているところな気がします。Rettyもテスト自動化SaaSのmablを導入していますがお付き合いしていくのはそれなりに大変です。
自分の役割を抽象化した一言で表現することってけっこう難しいですよね。肩書きや形式的な役割があっても職掌外の仕事があったりして自分は何者なのだろう、何を期待されているのだろうとモヤモヤすることがある。#JTF2020 #JTF2020B
— Motohashi Tsuyoshi (@t_mozza) 2020年7月25日
役割つけた瞬間に縛られることがありますよね。なので嘘にならない一番抽象度の高い役割を名乗ることって大事なのかなと思っています。
RSGT の Target の人の講演https://t.co/yCsBTyEiy0#JTF2020 #JTF2020B
— T a i s u k e 'J e f f' I n o u e #KeepDistance (@jeffi7) 2020年7月25日
私が"Software Engineering Coach"の役割を見たのはTargetのミグズさんの講演でした。ConfengineのプロフィールもSoftware Engineering Coachになっていました。
誰かが翻訳進めているのかもしれませんが英語だけのようです。これを見たオライリーの方、私に本の翻訳任せてみませんか😁Software Engineering at Googleという書籍がある。Googleに閉じた話ではなく汎用的な知識を習得できる。英語だけかな…？日本語がないと私には厳しそう。#JTF2020 #JTF2020B
— Motohashi Tsuyoshi (@t_mozza) 2020年7月25日
50万円ですね。十分ペイするとは理解していますが、会社として行かせるとなると改まってしまいます。Certified Scrum Developerいいな。でも研修いいお値段するんだよなあ#JTF2020 #JTF2020B
— Kaori Morikawa (@monoqlock) 2020年7月25日
やり方を知っていてもできるわけではないですからね。RIZAPが流行ったのも同じ理由のような気がします。このスライド、全部禿同。#JTF2020 #JTF2020B pic.twitter.com/aH9Vv6uni8
— T a i s u k e 'J e f f' I n o u e #KeepDistance (@jeffi7) 2020年7月25日
ドキュメントに目的とかスコープを書いておくと後から見返してわかりやすくなりますよね(自戒)チームのルールの背景を知ることは大切。
— asato@頑張らないを頑張る (@at_946) 2020年7月25日
でも背景を聞く時間をとるのは申し訳ないと思ってしまうのが常。
ルールの近くに背景置いとこう！（自戒）#JTF2020 #JTF2020B
エンジニアが不要なコードを消せないはずはないので、消えてないとしたら別な理由があるんですよね。習慣がないのもよくあるのですが、「消した場合の検証をどう行ったら良いのか前例がなくわからない」というのは自分も目から鱗でした。マネージャーがリファクタリングや改善活動を指示したり、影響を及ぼさないようにするのはホント大事だと思う。習慣化して、それが評価される文化になっていくと、幸せになる人が増えるのではないかと思う。#JTF2020 #JTF2020B
— amarelo@ささみのほん5寄稿 (@amarelo_n24) 2020年7月25日
コーチングやチーミングを目的にしてしまうとちょっとした変化で満足して続かないことはありますね。そもそも解決したかった問題は紙にでも書き出しておいてたまに振り返ると良いと思います。コーチングやチーミングは話を聞くと納得するんだけど，実践しようとすると上手くいかない不思議。習慣化が苦手なのかなぁ...
— id (@ido_kara_deru) 2020年7月25日
#JTF2020 #JTF2020B B2
やっていき( ･ㅂ･)و ̑̑「Software Engineering Coach」自称しましょう#JTF2020 #JTF2020B
— もーりす のようなもの (@y_m999) 2020年7月25日
言及いただいたブログ
補足
自分の原体験を話していたときのスライド、せっかく映画の画像引用したのに触れるの忘れていました。「陽はまた昇る」は日本ビクターがVHSテープを開発したときの実話を元にした映画です。デスマーチの移動中にレンタルで見て涙が止まらなくなった思い出の映画です。
失敗して涙を流すぐらいの良い仕事、やっていきましょう。
Scrum Fest Osaka 2020でスクラム開発におけるマネジメント、目標設定・フィードバック・評価の話をしてきました #scrumosaka
はじめに
Scrum Fest Osaka 2020で登壇の機会をいただき話してきました。 Regional Scrum Gathering Tokyo 2020の2日目基調講演を聞き、「普段自分がマネジメントで意識していたことが正しかったなー」と感じていたのですが、アジャイル開発/スクラム開発の発表で具体的なマネジメントの事例を扱ったものが少ないと思いました。ならば自分がまずは発表し、他のマネージャー/マネジメントを受ける側の方々からフィードバックをもらいたいと思って資料を作っています。
当日はたくさんの方に聞いていただき、質問もいただくことができありがとうございました。
Discord(参加者限定)でいただいた質問
障害出てるのは個人に行ってしまいそう
→ 急ぎの障害対応でもチームに話を振ってどちらが担当するのか決めてもらっています。※インフラ周りの監視などは別途オンコール担当がいるので別
「不満は言うけど、決まったことは尊重する」難しそう 不満を表明するが意見の押し付けにしない(ポジションパワーを働かせない)ために工夫していること気になる いち利害関係者と言っても、マネージャーはヒエラルキー上のパワーがあるので、要望や意見の優先順位が高くなりそう。「常松さん言っているから..」とか。そのあたり、どうやっているんだろう。
→難しいのはその通りでかなり気をつけています。「いちエンジニアとしては」とか枕詞をつけるとか。言い方を変えて何度か投げかけしてみたり。 強権発動するとチームの自主性が損なわれるので部門・会社に明確な損害出るまではなるべく我慢しています。多分半年に1回やるかどうかぐらい。
リモートで観察をどうやってやったかなどあれば教えてほしいです！
→Slackチャンネルたくさん入る。Discordで雑談・モブプロしている様子を観察する。特定のメンバに発言が偏っていないかをみるとか。
評価を上げるためにタスクの取り合いにならないか？
→チームにとっての困りごとに協力・貢献できていないと評価しないのでそれは起きていない。
チームでできるようになるほど、チーム内のスタンスも技術も高いメンバーと、どちらも低いメンバーの評価差をどうするの的なのある
→評価は職務グレードごとに行うため、同じ成果であっても職務グレードで扱いは異なります。
競争を促進するシステムですか？
→あくまでチームで成果を出して欲しいというスタンスですが、スクラムでチーム開発をしているとお互いの成長が刺激になるので、競争心を引き出しているのかなと思うことはあります。
マネジメントのところの話と合わせると、現状常松さんの下に30人くらいがフラットにいる感じなのかな？ →20人くらいです
アウトプットの評価のバランスってどうしてるんだろう。 バグを減らした人と、外部発表した人の相対的で納得のある評価みたいな。
→影響度を考慮してマネージャー間で慣らしています。
他のマネージャとの評価方針についての合意ってどう進めたのでしょうか？
→会社の記録として残す評価フォーマットで足並みを揃えるようにしているので、その前段階は個人でいろいろ試しています。
チーム目標を達成した時に、チームとしては達成しているが、やっぱり個人的に貢献度が違うなって場合はどうしていますか?
→評価に至る前の1on1で「もうちょっとこういう貢献がチームにできるといいねー」という話をしています。
週の1on1はどれくらい時間をかけていますか
→1人30分です。
目標（非公開の個人目標含む）とそれに対する成果はどのように管理されているのでしょうか。社内システムがあるなど？
→社内の評価システムは内製ですが、そこに入力するまではスプレッドシートで管理しています。
スクラムにおける自分の立ち位置を変えるときに、どのように伝えましたか？
→素直に伝えています「自律できるチームを目指してください。私はチームのサポートをしますが、チームで解決できる問題は委ねます。」
全社共通のグレード表があり、各グレードによって期待しているレベルが記載されています。 そのレベルがかなり抽象的で自分自身もメンバーが理解できないという課題があります。 チーム内で表の認識を共通化して評価するのがよいでしょうか？他に何かいい方法ありますでしょうか？
→グレード表にあたる文言(=Competency Matrix)をManager/Engineering Managerで読み合わせし、より明確な言葉に置き換えなどをしていました。
個人目標を組織目標に沿ったタスクベースで書いてくる人がいて、ペアプロなどでやっているので自分が何をアピールするかがわからないと言われるのですが、どのように目標を立ててもらっていますか？
→対チームメンバ、チーム外のメンバに対してどう貢献・協力するかといった振る舞いで目標を記載しています。
1on1をするマネージャを育てることってありますか？ もし、育てるときにやってることあれば、知りたいです。
→あります。マイクロマネジメントをさけ、メンバの自律性を引き出す振る舞いができるよう、時間をかけて話をしています。
SMが1on1をしたがります。 マネージャーの私もしたいというときにどちらかが遠慮すべきでしょうか
→1on1に効果があるなら任せてみても良いのではないでしょうか。
例えば個人目標が育成・指導が目標になっていた場合ってありますか？良い・悪いの判断するときのポイントみたいな部分があれば教えていただけると参考になって助かります。
→あります。指導対象がどういう振る舞い・貢献ができるようになって欲しいかを目標として話します。
チーム内で、お互いの役職(号棒？)やそこから予想される給料みたいのはお互いがわかる状態なのでしょうか？
→個人の職務グレードは非公開です。
メンバーの目標設定は、観測可能な目標を設定しようとしていたのですが、あまりこだわる必要はないでしょうか？？納得感が得られるか悩ましいとこです。
→観測できた方が良いですが、設定することでおかしな方向にチームが進んでいかないかを気にして慎重に設定しています。
目標設定で本人の希望ややりたいことはどの程度加味していますか？
→メンバーに聞いてできるだけ加味します。が、タスクはチームで取ってもらうので、チームで「こんなスキルを伸ばしたい」といった話は積極的にするように勧めています。
Twitterでいただいたコメント
スクラム開発におけるマネジメント、目標設定、フィードバック、評価 を聞いたメモ。 #scrumosaka pic.twitter.com/SSSPg66zux
— Nakayama san (@nakayama_san) 2020年6月27日
すてきなまとめを作っていただきありがとうございました。
