nDiki : スクラム

複雑な領域に合わせたプロジェクトマネジメントをする

あるプロジェクトのプレイングマネージャーが抜けることになってから、プロジェクトがうまく進まなくなってきた。プレイングマネージャーがメインでやってしまっている間は良かったけれど、そうでなくなった今も週1回30分のミーティングのスタイルのままでスローダウンしてしまったように思える。

なので

クネビンフレームワークで言うところの「複雑な領域」のプロジェクトだから、もっと密接にチームメンバが連携して「検査と適応」をしていかないと、進まないし成果も出ないよね。

という話をした。

開発プロジェクトではないけれどスクラムがいいんじゃないかなと思っているので取り入れてみるつもり。

スクラムブートストラップ #nNote

1. [ ] スプリント期間・開始日を決める。
2. [ ] スクラムインベントをスケジュールする。
   • [ ] スプリントプランニング
   • [ ] デイリースクラム
   • [ ] スプリントレビュー
   • [ ] スプリントレトロスペクティブ
3. [ ] プロダクトバックログリファインメントをスケジュールする。
4. [ ] プロダクトバックログを作れるようにする。
   • [ ] ツールを決める(付箋・Google スプレッドシート・Trello など)。
   • [ ] 見積もり方法を決める。
5. [ ] スプリントバックログを作れるようにする。
   • [ ] ツールを決める(付箋・Trello など)。
   • [ ] ふりかえりで決めた改善案も書いておけるようにする。
6. [ ] デイリースクラムのフォーマットを決める。
7. [ ] ワーキングアグリーメントを書く場所を用意する。
8. [ ] スプリントレトロスペクティブのフォーマットを決める。
9. [ ] スプリントレトロスペクティブのツール(付箋紙・マジック)を用意する。
10. [ ] 最初のプロダクトバックログを用意する。
    • [ ] プロダクトバックログアイテムそれぞれ完成の定義を書く。
11. [ ] キックオフをする。
12. [ ] 初回プロダクトバックログリファインメント(内容の確認と見積もり)をする。
13. [ ] 初回スプリントプランニングをしてスプリントを開始する。
14. [ ] デイリースクラムを開始する。
15. [ ] 初回スプリントレビューをする。
16. [ ] ベロシティを記録する。

複雑な領域なのでスクラムがいいと思ったけれど自己組織化するほどメンバがコミットできなさそう

とある複雑な領域のプロジェクトについてスクラムがいいのではと思って準備したんだけれど、メンバがコミットできるエネルギーを考えると失敗する可能性が高いと思えてきた。

事業全体での WIP を下げた方がいいなと。

今日のさえずり: ポケベルといえばキャッツ♥アイのトシ

2018年12月03日

• 06:45 裏道のクリスマスツリー。 PowerShot G9 X Mark II https://t.co/N1NFDywBGP
• 07:00 比丘橋 PowerShot G9 X Mark II https://t.co/RZWRQMyq8s
• 09:20 ポケベルといえばキャッツ♥アイのトシ。
• 09:47 2018年12月3日 #朝の渋谷 見慣れてきた新しい渋谷。 DSC-RX0 #RX0 https://t.co/TV0x5IH6C6
• 12:30 良かったものをふりかえるのは至福のひととき。 / “買って良かったもの 2018” http://bit.ly/2SjzqBr
• 24:12 スクラムがいいんじゃないかなと思って準備したんだけれど、メンバがコミットできるエネルギーを考えるとイケてないと思えてきた。事業全体での WIP を下げた方がいい。

品質と時間のトレードオフを判断できたの自画自賛

ワークショップで「品質より時間を優先」の判断をとっさにしてゴール達成できたの、品質・時間・スコープ・予算のトレードオフを意識して意思決定するアジャイルソフトウェア開発経験の賜物だなーと思ったり。

(なお、スクラムだと期日固定で、品質可変よりもスコープ可変の方が多くの場合望ましい。今回はスコープ変更ができない課題だったので品質を下げるという選択をした。)

Developers Summit 2019 1日目 #devsumi

2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00〜10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ

• スケール
  • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
• Scrum @ Scale フレームワーク
  • スクラムだけでもスケールする。
  • スクラムマスター(SM)
    • デイリースクラム階層。チームで解決できない課題を上位のデイリースクラムに伝えて解決していく(チームのデイリースクラムの方を1日の先にやる)。トップレベルは役員によるエグゼクティブアクションチーム(EAT)。 EAT もスクラムチームなのでスクラムの全てのアクティビティをやる。
    • SM で寄ってたかって協力。
    • マネージャーの仕事。
  • プロダクトオーナー (PO)
    • チームに1 PO。PO チーフ PO。チーフチーフ PO。
    • PO は上位のオーナーが絶対。
  • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
• PO
  • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

11:05〜11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10〜12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05〜13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10〜14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた 〜spanner、GKE導入の実体験から得たこと〜

株式会社コロプラ 廣本洋一氏

• コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
• コピーベースで新しいアプリケーションを作ることによる課題があった。
• ノーメンテナンス時間というポリシーを前提とした技術選択。
• オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15〜16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末で退職済みということで、嗚呼となった。

16:20〜17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25〜18:45 【14-A-8】 「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。

個人 OKR をやってみる (4)

月曜日に立てた1週間 OKR 終了。

採点

KR のスコア(自己採点)

• A: 0.3
• B: 0.3
• C: 1.0

でトータルスコア(平均)は 0.5。でも最後の C: 1.0 のおかげで目標(O)は達成できている状態なので、KR の設定が何かイケてなかった気がする。

ふりかえり

• OKR 設定は適切だったか?
  • 目標(O) の野心度合いが低かった。
  • 主要な結果(KR) は C だけで十分だったかもしれない。(A・B はそのための行動)
• フォーカスできたか?
  • OKR を意識しなかったら、これだけ集中して取り組まなかったので良い効果だった。
  • 他の業務もあるため1週間だとサイクルが短く感じる。ただスクラムでは1週間スプリントが良いというケースが多いし、検査と適応的には1週間も悪くないか。
• トラッキングできていたか?
  • 途中、進捗を数値化できていなかった。

やること

• 次回2週間サイクルでやってみる。
• OKR スプレッドシートにデイリーの進捗度がわかるような列を追加する。

今日のさえずり: 『スクラムガイド 2020』を追従した『エッセンシャル スクラム』改訂版出ないかなー

• 19:31 『スクラムガイド 2020』を追従した『エッセンシャル スクラム』改訂版出ないかなー。
• 21:48 月見をしながら帰宅したら、リビングにススキが飾られていた。ご飯の後には月見だんご。パーフェクト。

第2回 『Hacking Growth グロースハック完全読本』を読む会 第1章 グロースチームを結成する

『Hacking Growth グロースハック完全読本』を読む会の第2回目。今日からいよいよ第1章に入る。第1章は「グロースチームを結成する」だ。

グロースチームに必要なメンバ構成、チームの規模と業務範囲

グロースチームに必要な役割として以下が挙げられている。スクラムチームと同様に機能横断型チームであることがグロースチームには求められる。

• グロースリード (マネージャー + プロダクトオーナー + データサイエンティストの役割)
• プロダクトマネージャー
• ソフトウェアエンジニア
• マーケティングスペシャリスト
• データアナリスト (常任で配属したほうがいい)
• プロダクトデザイナー

チームの規模によって1人が複数の役割を兼任したり、複数の人が1つの役割を担当したりする。

チームのマネジメントはグロースリードが行う。

グロースリードはマネジャー、プロダクトオーナー(プロダクトの最終決定権と責任を持つ役割)、データサイエンティストをあわせたような役割を担う。

本書ではプロダクトマネージャーを

一般的には、プロダクトマネジャーはプロダクトのさまざまな要素を形にする過程を監督する。

と説明している。グロースサイクルでプロダクトの新機能を実験として選定した場合に、グロースリードはメンバの中のプロダクトマネージャーを実験のオーナとして任命すると後の章である。

ここで言うプロダクトマネージャーはグロースチーム内での機能開発をマネジメントするのか、それとも別チームを率いているプロダクトマネージャーで、そちらで実験のための機能開発をマネジメントするのか。組織体系の節にあるチームだと前者なのかな。

このあたりは企業によって組織構造や役割名の定義が違うので、そういった典型的な型があるよねぐらいで読んだ方が良いだろう。

業務プロセス

詳しくは4章。

チーム内での役割分担

「専門分野に応じた業務を担う」とありメンバの専門性に頼っているイメージ。スクラムのように銃士の姿勢まではここでは求めていないようだ。銃士の姿勢であることに越したことはない。

まとめ

分析とプロダクト開発とマーケティングができる機能横断型のグロースチームを結成せよ。

• Hacking Growth グロースハック完全読本 (Kindle 版)
• Hacking Growth グロースハック完全読本 (単行本)

第6回 『Hacking Growth グロースハック完全読本』を読む会 第4章 高速で実験を繰り返す

『Hacking Growth グロースハック完全読本』を読む会の第6回目。今日は「第4章 高速で実験を繰り返す」。

いよいよ今回はグロースハックプロセスのまわし方の章である。

1〜2週間をタイムボックスとしてイテレーションするプロセスは、スクラムなどのアジャイルソフトウェア開発プロセスに通じるものがある。グロースハックでもタイムボックスは1週間が良いようである。

初期のスタートアップ企業では、週に1〜2の実験から始めて徐々に数を増やしていくのがよい。

とあり早い段階から高速な実験サイクルが期待されている。

多くの実験を行うためには多くのアイデアが必要だが、週1回のグロースミーティングはアイデア出しの場としては使ってはいけないそう。たしかに「創造的なアイデア出し」と「高速な実験サイクル」とは切り離した方がうまくいくのかもしれない。

チームメンバは「みずからの専門知識に基づいてアイデアを出すよう求められる」。ここでもメンバの専門性を重視しているように感じた。このあたりスクラムより分業感が漂っている。優先順位付けのためのアイデアのスコア付けも提案者自身だ。

実験の結果に迷った場合は従来のバージョンを維持するのが最善の道だという。時間と労力をかけた実験は、実験を続けることで良い結果が出てくるのではと思いたくなる。きちんと元に戻す判断ができるようにしておきたい。

• Hacking Growth グロースハック完全読本 (Kindle 版)
• Hacking Growth グロースハック完全読本 (単行本)

ストーリーマッピングについて調べる

プロジェクトでストーリーマッピングすることになった。

言い出しっぺではあるが、やったことが無く『エッセンシャル スクラム』で少し知った程度なので『ユーザーストーリーマッピング』も最初の方をちょっとだけ読んだ。『ユーザーストーリーマッピング』はそのうちちゃんと読みたいな。