fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「Developers Summit 2019」に参加しました

2019/2/14(木)～2/15(金) Developers Summit 2019に参加してきました。

公式サイト
https://event.shoeisha.jp/devsumi/20190214/

今年もなんとか仕事に都合をつけての参加です。
2日目は仕事の都合上、13:50終了のセッションまででしたが。

20190214_01.jpg

ちょと気になったセッションの聴講メモをブログに残しておこうと思います。

Scrum@Scale入門





ちょうど仕事で大規模スクラムのプロジェクトに関わってるので聴講しました。以下メモ。

権力の源泉　（P.6）
  • 農耕時代は「土地」と「労働力」を持ってる人が強かった。
  • 産業時代は「資本」と「労働力」を持ってる人が強かった。
  • 今の情報時代は「知的労働力」と「情報」を持ってる人が強い。それをどう集められるかがキー。

Power to the Edge　（P.7～P.8）
  • 昔はコマンド＆コントロールといえば「指揮命令系統」だった。
  • 「末端に判断する権限を委譲できる組織を作らないといけないよ」という意見が出てきたのが10年前。
  • 米海軍の、指揮命令しない艦長の最強組織。意図を伝えることによるリーダーシップが重要。

アジャイル時代　（P.9）
  • 顧客第一
  • 「ちいさな独立したチーム」が寄って集ってなんとかする
  • ネットワークを使って仕事する

チームの人数　（P.10）
  • 5人のコミュニケーションパスは10個。みんながみんな知っている。意思決定の速さにつながる
  • 9人だとコミュニケーションパスは36個。だいぶ辛い。

Agility をスケールさせるには？　（P.11）
  • 何をスケールさせるのか？
  • P.12は中国の住宅の例。同じ家をスケールさせた結果、誰も住まなくなった。
  • P.13はトルコの例。今度は城を並べてスケールさせた。これも破綻した。
  • 横スケールのコピペは上手くいかない。横展開は難しい。
  • コピペでチームは作れない。
  • スケールアップ、アウトしかできないのなら、それはスケーリングじゃなくて膨張してるだけ。

スケールが必要なのはなぜか？　（P.15～18）
  • P.16はチリの貧困者住宅。
  • Aravena氏が作った。TEDの彼のプレゼンが面白いのでぜひ見てほしい。
  • 貧困者住宅が完成して入居後、風景が一変した。
  • スペースが空いてる場所は、住人が自分たちで埋め始めた。
  • 住人が自分自身で作る。１階を倉庫にしたり、作業部屋にしたり。
  • そして、住んでる人同士がメンテナンスのノウハウを共有し始める。
  • 住宅を半完成の状態で住人に渡したのは、貧困者住宅なのでお金が足りなかったから。
  • スケーリングはこの例のようにしたい。
  • 「アジャイル開発標準」なんてつくってるんじゃねーぞ（笑

スケールさせる前に・・・　（P.19）
  • スケールさせる前に、上手くいってるスクラムチームを２つ育てること。
  • そうしないと、良くないチームをスケールさせようとする。
  • いいチームができてから、それをスケールせよ。

Scrum @ Scale Framework　（P.20）
  • スクラムガイドはプロダクトオーナーに冷たいので、POについてあんまり書いてないｗ
  • Scrum @ Scaleではプロダクトオーナーのサイクルがある。なぜプロダクトが必要なのか。
  • スクラムマスターサイクルもある。これってデプロイサイクルじゃないか、という話もあるが。作ってデプロイするまでのサイクルになってる。
  • この２つのサイクルがscrum@scale


スケールフリーアーキテクチャ　（P.22）
  • 幾何級数的にスケールしたいなら、「スケールフリー」なアーキテクチャが必要。
  • ジェフ・サザーランドのスクラムはいきなり十数チーム。

スケーリングの課題：官僚主義と階層　（P.23）
  • ３～７のチームが集まって、チームがチームとして動くにはどうすればいいかがscrum@scaleの課題。
  • 官僚主義を最小限にするのがscrum@scale。

デイリースクラムのスケーリング　（P.24）
  • スクラムオブスクラムを使う。
  • さらに階層化する。
  • Scrum of Scrums Master（SoSM）が必要。

スケール化デイリースクラム (SDS)　（P.25）
  • デイリースクラム終わったら、代表者で集まって共有する。それがどんどん上にあがっていく。

エグゼクティブアクションチーム　（P.26）
  • EAT（エグゼクティブアクションチーム）が一番上にいて、会社の役員レベルで構成される。
  • EATはスクラムマスターがやることをやる。チームの妨害を取り除く。
  • チームのスクラムマスターはできることが限られてるので、チームレベルで対処できない場合は上の層へエスカレーションする。
  • 3段階上くらいにEATの役員がいる。EATがその場で判断する。持ち帰りは許されない。


SAAB Technologies社の事例　（P.28）
  • 「みなさん、エースコンバットは好きですか？」 by 原田氏
  • SAAB社では戦闘機の「グリペン」を作ってる。
  • グリペンは半年に1回、ニューバージョンが出る。費用対効果が高い戦闘機。
  • いつもバラしてるのでメンテナンス性が高い。
  • デイリースクラムを4段階の階層でやってる。2000人を1.25時間で同期してる。


EATには誰が必要?　（P.29）
  • EATで、承認なしにすぐ決めれるようにする。
  • EATにはCOOとかCTOとかを入れて、財務権限がある人も入れて、人事や法務の担当者も入れる。
  • スクラムのチャンピオンとかも入れる。

プロダクトオーナーをスケールする　（P.30）
  • チームのPOに権限移譲できるようにする。
  • POもグループを作る。
    • CPO MetaScrum：　POを集めたチーフプロダクトオーナー
    • Excecutive MetaScrum：　チーフチーフプロダクトオーナー

スクラムマスターとプロダクトオーナーの スケーリングの違い　（P.32）
  • マネージャは妨害を止めるのが仕事なので、POよりはスクラムマスター寄りの役割。
  • なのでPOはマネージャである必要はない。
  • スクラムオブスクラムマスターは「みんなで寄って集ってなんとかしよう」という考え方。
  • POはちょっと違う。意思決定が勝負。
  • 上のPOの判断が絶対。相談しない。迷ったらチーフPOが決める。
  • POは「調査してから・・・」だと遅い。調査で待たせるよりは、今すぐに判断をして、間違えろ。
  • POは後回しにするな。次のイテレーションで取り返せ。すぐに間違えることでチームも自分も学ぶことができる。

組織の状況を見える化するところから　（P.35）
  • 壁に自分の組織を付箋で書く。付箋の色で課題状況を示す。
  • 紫の付箋が、全然ダメなところ。紫→赤→黄色→青の順に良くなる。
  • どのへんが赤いかがわかる。
  • 壁にずっと貼っておく。通称、恥の壁。

Scrum@Scale の利用方法は組織によって異なる　（P.36）
  • Scrum@Scaleを組織にどうやって入れるか、詰めるかはScrum@Scaleのガイドには書いてない。自分で詰めろ。
  • チームに必ずPOとスクラムマスターがいるのは狙いがある。両者くっついてるので、チームごと、ごそっと動かせる。
  • ニーズが増えたところにチームごと移動させられる。チームをゼロから立ち上げる労力に比べれば、はるかに短くて済む。
  • チームを壊さないでください。
  • POはビジネスのインタフェースとしての役割もある。
  • EATもスクラムチーム。見積もらないといけないし、デモしないといけない。


マネージャで一番大事なのは、チームの邪魔をしないこと



Scrum@Scale、日本語版のガイドも公開されています。




エンジニアの知的生産術 ビフォー・アフター



↓をクリックすると資料のPDFに飛びます。
20190214_02.jpg

自分の勉強方法や読書方法についてモヤモヤ感が否めないので、なにかキッカケを得られれば、と思って聴講しました。
以下メモ。

「エンジニアの知的生産術」の書籍を執筆　（P.2）
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
posted with amazlet at 19.02.17
西尾 泰和
技術評論社
売り上げランキング: 5,219
Amazon.co.jpで詳細を見る


学びの加速　（P.11）
  • 学ばない人よりも学ぶ人の方が上を行くが、学ぶ人と学びを加速させる人との差に比べれば微々たるもの。
  • 学びを加速させていかないといけない。それが長期的な大きな差につながる。

「理解」は「仮説」　（P.17）
  • 「理解した」という気持ちは仮設でしかない。
  • 実行して動作を見る。「手を動かす」ことによりアウトプットする。

サイクルを小さくする　（P.19）
  • 報酬のサイクル：　「動かない」→「動いた」→「楽しい」
  • 仮説検証のサイクルを小さく高速に回す。

行動によって検証する　（P.21）
  • 「知識を行動によって検証する」が学びに重要。
  • アウトプットが大事。学んでからアウトプットしよう、ではダメ。
  • LTとかも有効。
  • まず20文字くらいの付箋に書いてみよう。まず書くこと。書くと情報が消えないので、安心できる。
  • 脳を、情報を組み立てる方に投資する。

今　（P.28）
  • 魚の絵。水面下にあるものを言葉で表現してフックをかける。
  • フックをかけて水面上に釣り上げる。フックする、ハンドルする方法を手に入れることによって思考がやりやすくなる。
  • 思考の効率を言葉が底上げする。

Scrapbox　（P.31）
  • 知的生産術を支えるソフトウェアがScrapbox。情報間のつながりを表現するコストを極限まで減らし、記述しやすくしてる。
  • Wikipediaのページ間リンクは有効だけど、Wikipediaは全世界に公開されるので汎用的にしか書けない。
  • それに比べ、Scrapboxは個人で使えるので自分の好きなように書ける。
  • 書籍だとリンクや参照を書いても、すぐに飛べない。一次元のインプットにしかならない。Scrapboxはそうじゃない。
  • 西尾泰和のScrapbox


講演終了後、内容に興味が沸いたのでデブサミの書籍販売コーナーで10%割引やってるし早速購入～
20190214_03.jpg

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
posted with amazlet at 19.02.17
西尾 泰和
技術評論社
売り上げランキング: 5,219
Amazon.co.jpで詳細を見る


感想


今年のデブサミも楽しく有意義なヒトトキでした。
他のセッションも興味深いのいくつかあったので、スライド公開されたら追記するかも。

デブサミ関係者の皆様、有意義なイベント今年もありがとーございました。
また来年も仕事に都合をつけて、なんとか参加したいと思うのでした。




-->