あるプロジェクトのプレイングマネージャーが抜けることになってから、プロジェクトがうまく進まなくなってきた。プレイングマネージャーがメインでやってしまっている間は良かったけれど、そうでなくなった今も週1回30分のミーティングのスタイルのままでスローダウンしてしまったように思える。
なので
クネビンフレームワークで言うところの「複雑な領域」のプロジェクトだから、もっと密接にチームメンバが連携して「検査と適応」をしていかないと、進まないし成果も出ないよね。
という話をした。
開発プロジェクトではないけれどスクラムがいいんじゃないかなと思っているので取り入れてみるつもり。
とある複雑な領域のプロジェクトについてスクラムがいいのではと思って準備したんだけれど、メンバがコミットできるエネルギーを考えると失敗する可能性が高いと思えてきた。
事業全体での WIP を下げた方がいいなと。
2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。
朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。
以下セッションタイトルは2月13日時点の公式サイトより。
株式会社アトラクタ 原田騎郎(@haradakiro)氏
やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。
*1 どんなプロダクトバックログをいくつ用意すべきかを考えるにあたっては、基本原則がある。プロダクトごとに、プロダクトバックログをひとつ用意するというルールだ。-- エッセンシャル スクラム 6.7
GitHub 池田尚史(@ikeike443)氏
GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。
株式会社grasys 長谷川祐介氏
サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。
ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
前半永瀬氏による enPiT 事例紹介。
後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。
こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。
ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。
東工大生イジりが嫌味がないのも素敵。
株式会社コロプラ 廣本洋一氏
機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。
株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏
ECナビについて2年弱かけて AWS 移行した話。
サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。
別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。
株式会社ZOZOテクノロジーズ 塩崎健弘氏
BigQuery 移行事例についての、味わいのある発表。
今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。
高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。
KR のスコア(自己採点)
でトータルスコア(平均)は 0.5。でも最後の C: 1.0 のおかげで目標(O)は達成できている状態なので、KR の設定が何かイケてなかった気がする。
『Hacking Growth グロースハック完全読本』を読む会の第2回目。今日からいよいよ第1章に入る。第1章は「グロースチームを結成する」だ。
グロースチームに必要な役割として以下が挙げられている。スクラムチームと同様に機能横断型チームであることがグロースチームには求められる。
チームの規模によって1人が複数の役割を兼任したり、複数の人が1つの役割を担当したりする。
チームのマネジメントはグロースリードが行う。
グロースリードはマネジャー、プロダクトオーナー(プロダクトの最終決定権と責任を持つ役割)、データサイエンティストをあわせたような役割を担う。
本書ではプロダクトマネージャーを
一般的には、プロダクトマネジャーはプロダクトのさまざまな要素を形にする過程を監督する。
と説明している。グロースサイクルでプロダクトの新機能を実験として選定した場合に、グロースリードはメンバの中のプロダクトマネージャーを実験のオーナとして任命すると後の章である。
ここで言うプロダクトマネージャーはグロースチーム内での機能開発をマネジメントするのか、それとも別チームを率いているプロダクトマネージャーで、そちらで実験のための機能開発をマネジメントするのか。組織体系の節にあるチームだと前者なのかな。
このあたりは企業によって組織構造や役割名の定義が違うので、そういった典型的な型があるよねぐらいで読んだ方が良いだろう。
詳しくは4章。
「専門分野に応じた業務を担う」とありメンバの専門性に頼っているイメージ。スクラムのように銃士の姿勢まではここでは求めていないようだ。銃士の姿勢であることに越したことはない。
分析とプロダクト開発とマーケティングができる機能横断型のグロースチームを結成せよ。
『Hacking Growth グロースハック完全読本』を読む会の第6回目。今日は「第4章 高速で実験を繰り返す」。
いよいよ今回はグロースハックプロセスのまわし方の章である。
1〜2週間をタイムボックスとしてイテレーションするプロセスは、スクラムなどのアジャイルソフトウェア開発プロセスに通じるものがある。グロースハックでもタイムボックスは1週間が良いようである。
初期のスタートアップ企業では、週に1〜2の実験から始めて徐々に数を増やしていくのがよい。
とあり早い段階から高速な実験サイクルが期待されている。
多くの実験を行うためには多くのアイデアが必要だが、週1回のグロースミーティングはアイデア出しの場としては使ってはいけないそう。たしかに「創造的なアイデア出し」と「高速な実験サイクル」とは切り離した方がうまくいくのかもしれない。
チームメンバは「みずからの専門知識に基づいてアイデアを出すよう求められる」。ここでもメンバの専門性を重視しているように感じた。このあたりスクラムより分業感が漂っている。優先順位付けのためのアイデアのスコア付けも提案者自身だ。
実験の結果に迷った場合は従来のバージョンを維持するのが最善の道だという。時間と労力をかけた実験は、実験を続けることで良い結果が出てくるのではと思いたくなる。きちんと元に戻す判断ができるようにしておきたい。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。