2019/3/21(木)～3/22(金) 東京から銚子へ自転車で旅してきました。
このブログはその2日目（2019/3/22）の旅日記になります。
1日目の日記はこちら
http://makopi23.blog.fc2.com/blog-entry-307.html 2日目（2019/3/22）のスタート 千葉県成田市のネカフェで迎える朝～
朝食のパンとポテト、無料で食べ放題。
テント持参してたけど、完全個室でシャワールームもコインランドリーもあるネカフェは魅力やね。安いし。
花粉症なのでやっぱ野宿キツイ・・・
朝8時くらいにネカフェをチェックアウト。
自転車に荷物を積み込みます。
成田市さくらの山公園へ。
成田市さくらの山公園はNHKの
「ドキュメント72時間」 でも特集されてましたね。
再放送で見て、ぜひ行ってみたいと思ってたのでした。
成田空港の滑走路北側の小高い丘の上にある公園で、菜の花が綺麗です。
成田国際空港に近いので迫力ある飛行機の発着シーンを見ることができます。
飛行機の離陸をのんびり眺めます。
成田市さくらの山公園を後にし、天神峰トンネルをくぐります。
全長700mくらい。車道と歩道が分離されているので安全に渡れます。
成田市を抜け、香取市へ。
道の駅 くりもと 紅小町の郷で休憩～
田舎道をのんびりペダルを漕ぐ。
通りがかりに雰囲気良さそうなお寺があったので寄り道～
妙光山蓮華院 観福寺というそうな。
入り口の駐車場に自転車を停め、観福寺をのんびり歩きます。
観福寺には本堂や不動堂、毘沙門堂などがあります。お賽銭を入れて今回の旅の交通祈願をします。
行き当たりばったりの寄り道も旅の醍醐味なのです。
お次は下總國一之宮 香取神宮へ。自転車と共にお写真一枚～
関東地方を中心として全国にある香取神社の総本社だそうな。
前夜のネカフェでググって良さそうだったので来てみたのです。のんびり散策。
綺麗な池。神池と言うんだそうな。
香取神宮の総門。
香取神宮の楼門へ。
香取神宮の本殿。
本殿の右に宝物殿があります。
要石（かなめいし）。
地震を鎮めているとされる、大部分が地中に埋まった霊石だそうな。
香取神宮の奥宮。経津主大神の荒御魂を祀っているんだそうな。
香取神宮を堪能し、利根川に沿って銚子に向かいます。
千葉県の最東端、銚子市へ。
JR銚子駅前に到着～
犬吠埼へ。銚子半島の最東端の景勝地です。
犬吠埼灯台。レンガ造りの灯台で、99段のらせん階段を上ると太平洋を一望できるんだそうな。
残念ながら閉館時間を過ぎてたので登れませんでした。
銚子電気鉄道線の終点駅、外川駅へ。
木造平屋建の、ものすごくレトロな駅ｗ
千騎ケ岩。
源義経が千騎の兵をもってたてこもったところから、この名がついたと言われているんだそうな。
名洗港海浜公園へ。銚子マリーナや屏風ケ浦の遊歩道などがあります。
イオンモール銚子へ。
一杯やりつつ、スマホのワンセグでサッカー日本代表 vs コロンビア戦をのんびり観戦～
この後、すぐ近くにテントを張って野宿しました。
この日は94kmほど走りました。
3日目（2019/3/23）のスタート 残念ながら、雨・・・
房総半島一周はまた次回～
感想 千葉～房総半島は平地メインなので走りやすいですね。
マスク付けつつ、いろんなところ回れて楽しかったです。
ただ花粉症なので、やっぱこの時期の野宿はツライです・・・
あと、この時期は三寒四温というだけあって、天気も崩れやすいのもな～・・・
あと、テントも寝袋も冬用じゃないので、やっぱ冬用が欲しい。寒風が貫通しまくりなので・・・
テントと寝袋、ちょと考えよう。
次の自転車旅はゴールデンウィークかな～
日本一周を目指して！
2019/3/6(水) POStudy 「１チームスクラムと大規模スクラム（LeSS）ではPO目線で何が変わるのか？」に参加してきました。
DoorKeeper
https://postudy.doorkeeper.jp/events/87970 Togetter
https://togetter.com/li/1325878 新しく立ち上がる大規模スクラムプロジェクトにスクラムマスターとして放り込まれそうなので、ちょうど良い機会、ということで参加することに。
先日↓の書籍が発売されたのでこちらも購入済みで、読み進めている最中なのです。
先日、
LeSS Study でも読書会が始まったので、こちらも参加してきたところです。
アジャイルサムライ横浜道場でおなじみ、たくぼんさん。
次回の読書会は3/19 です。ご一緒にいかがですか～？
イントロダクション 今日のファシリテーターはodd-eの榎本さんです。
以前、スクラムマスター研修（CSM）を受けたときにお世話になりました。
冒頭、参加者にカードが配られ、榎本さん曰く、「今日一番議論したいことを１つ書いてほしい」とのこと。
ということでこんな感じで書いてみた。
先月、
デブサミでScrum@Scaleの講演を聴講してブログ書いたり 、Nexusの
日本語ガイド 読んだりしてたので、やっぱ違いが気になります。
書き終わったら、次は「周りの参加者さんと自己紹介を兼ね話し合ってみてください」とのこと。
ということで周りの４～５人の方と会話させていただきました。やっぱ同じこと思ってた方もいらっしゃったようで。
LeSSの概要理解 お次は、LeSSの概要を紹介した動画をプロジェクタに投影しながら、榎本さんが説明を随時挟んでくださいました。
日本語の字幕が付いたスライド、あったんですね。
VIDEO 以下、メモ。
「大規模」について LeSSで大規模にスクラムをやることを推奨はしていない。
小規模で上手くいってたものが、大規模になると上手くいかなくなる。。。
大規模にスクラムをやることを目的にしてほしくない。
小さく行けるなら、そちらのほうが好ましい。
無理にスケールしないでください。
どういった状況を大規模というか？というと、2チームから。
1チームでいけるなら、極力１つのチームでやるのが好ましい。
チームが2つ以上になるなら、極力シンプルに。
極力スクラムを維持しながら、必要最低限のものを追加して、スクラムのエッセンスを極力残したものがLeSS。
プロダクトオーナー LeSSは1人のプロダクトオーナーで、プロダクトバックログも１つ。
それに対して複数チームが仕事をしていく。スプリントの期間も全チームが一緒。
基本的には「１つのスクラムでやることを複数チームでやるにはどうすればいいのか」という観点で最低限のルールを追加している。
チーム間の調整は、チーム同士で調整していただく。
プロダクトオーナーやスクラムマスターがチーム間の調整をするわけではない。
それぞれのチームが開発していく上で、チーム間の調整は必要。それをチーム同士でやっていただく。
プロダクトオーナー視点でいうと、複数チームになると、やることが増えてくる
１つのチームなら要求の詳細化をプロダクトオーナーが出来た。
それが複数チームになると難しくなるので、要求の詳細化などをプロダクトオーナーから開発チームに移譲していく。
ビジョンはプロダクトオーナーが示す。PBIの優先順位もプロダクトオーナーが最終に決める。
開発チームが自分たち自身で顧客から要求を聞き出す、というようにプロダクトオーナーは促していく必要がある。
開発チームと、要求を持ってる人を、近づける。
開発チームと顧客とで、直接やってもらう環境づくりをプロダクトオーナーがやる。
プロダクトオーナーが自分でPBIを明確化しなくても済むようにする。
オーバーオールレトロスペクティブ 通常のスクラムにない考え方として、オーバーオールレトロスペクティブというイベントがある。
開発チームの代表者、マネージメントする人、顧客などの人たちが集まって、複数チームや組織全体の課題を考える。
複数チームで開発するとなると、全体としての課題解決の場が必要になる。それがオーバーオールレトロスペクティブ。
2種類のLeSS LeSSは2種類ある。通常のLeSSと、LeSS Huge。
LeSS Hugeになると、8チーム以上。その場合、もうちょっと構造を追加しないと上手く全体が回っていかない。
８チームを超えたタイミングで追加の構造が作られる。
LeSS Hugeでは、エリアプロダクトバックログとエリアプロダクトオーナーという概念が追加される。
実際の開発チームから見たら、エリアプロダクトバックログが通常のバックログで、エリアプロダクトオーナーが通常のプロダクトオーナー。
プロダクトオーナーは、どのエリアにプロダクトバックログアイテムをまかせていくのかを決める。
各チームをどこのエリアに配置するのかを決める。
全体の差配、調整をプロダクトオーナーが担う。
開発チームから見たら、常に１つのプロダクトバックログ、 1人のプロダクトオーナー。
組織構造 通常、スクラムやLeSSをやるように組織は設計されていない。
LeSSは影響範囲が広くなるので、組織の影響を多く受ける。
スクラムやLeSSで定義されてない役割が組織にはいっぱいある。
企業にはそういう課題がいろいろある。
それらの課題を解決して大規模でスクラムやっていくには、推進者には障害がインパクトとして出てくる。
フィーチャーチームになるよう組織構造を変えなきゃいけない。
顧客に価値を提供できるスキルを持ってるのがフィーチャーチーム。
UI/UXチーム、サーバサイドチーム、DBチーム、とかは「コンポーネントチーム」と呼ぶ
１つのユーザー価値を提供することができるスキルセットを持ってる人がフィーチャーチーム。
組織構造を変えていくことが必要になる。
More with Less 少ないことでもっと多く。More with Less。これが基本の考え方。
何かを追加するのではなく、極力シンプルに維持していくのがコアの考え方。
QAの責任者を立てる、とかだと、「品質に責任を持つのはQAだ」という考えになってしまう。
それは開発チームから品質の責任を取り上げているのと一緒。
チームに責任を持って行ってもらう。責任をQA等、あちこちに分散させないことが大切。
チームから責任を奪うのではなく、チームが責任を果たせる状況を作っていくのがマネージャ。
原理原則がコアになる。
その上にフレームワークのルールがある。そんなに数はない。
原理原則やルールだけでカバーできない部分は、TIPSとして多く存在している。ガイドとか実験だったり。本に書いてある。
前の2冊は、クレイグとバスの実験がいっぱい書いてある。その一部が今回の本に書かれている。
必ずやったほうがいいよ、というものではない。
ルールはやりなさい、とLeSSは言ってるが、ガイドに書いてあることは助けになることがあるので使ってみるのがいいんじゃない？くらいな感じ。
LeSSでやることは極力シンプルに。
プロダクトオーナーからの視点としても、スクラムと変わらない。
極力チームに裁量を持ってもらわないとプロダクトオーナーは回らない。
PO視点での探求セッション ここからは
フィッシュボウル（Fishbowl）形式 でのパネルディスカッションです。
4人がパネラーとして前の椅子に座り、ディスカッションネタを提供する人が順に1人ずつ前に出て、パネラーと議論していきます。
以下、出た意見のメモ。
実際はこのセッションの前に質疑応答の時間があったので、メモもそこから。
Q. LeSS Hugeは８チームから、という話だが、「８」の意味は何か？
A. 「8」は、LeSSの中でオススメしているプロダクトバックログの粒度に関係がある。
1チームが毎スプリントで４つくらいプロダクトバックログアイテムを選択するのがお勧め。
プロダクトバックログリファインメントで3スプリント先まで詳細化する。
そうすると、1チームあたり１２個くらいのバックログアイテムを明確にする必要がある。
8チームだと、合計１００個くらいのバックログアイテムを明確にする必要がある。
１００くらいがプロダクトオーナー1人が理解して優先順位を決めれる限界だろう、という考えに基づいている。
8チーム以上になると1人のプロダクトオーナーで対処できないので、エリアプロダクトオーナーがプロダクトオーナーの役割を担っていく。
そうしないと把握しきれなくなる。
プロダクトオーナー視点で注意しないといけないのは、細かくやりすぎるとすぐ把握できなくなる、という点。
ある程度まとめてやっていく、という考えが必要。
Q. なぜ責任は分散させてはいけないのか
A. LeSSで重要視しているのが、顧客やプロダクトの全体感。
常に動くソフトウェアを作るということ。
責任を分散させると、全体感や責任を持つという点がチームから離れていく。
自分の責任じゃないよね、という部分最適が始まる。
助け合いが生まれない。組織として良くしていこう、という思想と真逆にいってしまう。
Q. リリース後のフィードバックからPBIを作るのが難しい。
A. マーケットから新しい学びを得たら、スプリントレビューとかPBRとかでプロダクトオーナーから開発チームにシェアしていく。
そこからどうしていけばいいかは開発チームに主体的に動いてもらいたい。
大きな変化をさせる必要が出てきたら、開発チームに伝えて、プロダクトバックログに入れる。
その時は、ポンッと大きい要求を入れる。プロダクトバックログアイテムの分割など、細部はチームにやってもらう。
プロダクトオーナーは方向性とかビジョンとかを持ち続けるのが重要な責務。
Q. 異なるチーム間で、プロダクトオーナーからのインプット情報は、どの程度共有するべきか
A1. 朝会やバックログリファインメントを部屋でやってると、「あの人たち、何をやってるんだろうね・・・」となる。
A2. 週次のレビュー会は全員でやる。その場でプロダクトオーナーが決定する。
A3. LeSSのフレームワークとして、共有する場としてはスプリントレビューがある。参加者は全員。
大きい部屋で各チームがブースを持つ。バザールと呼ばれる形式でやる。
スプリントレビューでは、いろんなチームが開発したものがブースで公開されるので、ステークホルダーはそれらを見て回る。
スプリントプランニングとかプロダクトバックログリファインメントとかは、LeSSだと2部構成でやる。
1部は全員参加。
スプリントプランニングの第一部は、一番上のバックログアイテムから順に、どのチームやる？と決めていく
プロダクトバックログリファインメントも、どのチームがやるのが良さそうか、を考えて、そのチームにリファインメントをやってもらう。
Q. ソースコード、チーム間のをどのタイミングでシェアしてる？
プロダクトバックログリファインメントをやろうとすると、そのソースに知識がないとできない。
違うチームが作ったものを学習していかないといけない。
意識的にやらないと、自分のに集中してしまう。
A1. 他人のソースをいじるの難しいなので、チームで完結するようにしてた。
A2. LeSSは「コードの共同所有」という概念を提唱している。
基本的にはどのソースも、誰でも変更を加えられる。その考え方をオススメしている。
このソースはこのチームにしか触れない、だと、そのチームに変更依頼しないといけなくなる。
誰でも変更してOKとなると、コンフリクトおきるじゃん？となる。でも、コンフリクトは極力起こそう、という考え方に立つ。
変更を1週間分貯めてマージ、じゃなくて、1時間に何回も同じコードベースに対してマージしていく。
それだとコンフリクトの差分が小さくてすむ。
どこが誰とコンフリクトしたかが分かる。コンフリクトすることが互いに話すきっかけとなる。
コードで対話していきましょう。
極力コンフリクトが頻繁に送る環境を作るようにする。
Q. LeSSのプロダクトオーナーに向いてる人は？
A1. 完璧主義は向かないかな？
A2. 任せる人。
A3. 意思決定をちゃんとする人。
A4. やるやらないを明確にする人。
A5. 開発で細かいところは知りたがるけど、それでも任せる人。
開発よりも、市場とかお金をもらう人に意識が向いてる人。
Q. 短いサイクルでたくさんの意思決定を求められる。なにかよい工夫あるか？
A1. 決定するには事前の情報収集が大事。市場を分析して未来を予測する。
A2. あとで検証できるように根拠を明らかにしておく。
A3. スクラムマスターが意思決定をしてしまって、そこに結論を誘導するようにした。
A4. 失敗していいんだ、というのを後押しする。
Q. 成功するプロダクトと成功しないプロダクト、どこが違うんだろう？
A1. 成功するプロダクトは、ビジョンが最初から最後まで変わらない。
A2. はっきりと意思決定すること。ビジョンを持ってることが意思決定の速さや成功につながる。
Q. プロダクトオーナーで難しいのが、どうやってスポンサーを納得させるか。
開発チームやスクラムマスターに、こーゆうことやってほしいな、というのがあれば教えてほしい。
A1. ステークホルダーを納得させるのに、場を設けるとか日程調整とかの時間をプロダクトオーナーは持っていかれがちなので、それらの調整はスクラムマスターにやってもらうようにした。
A2. 投資家にお金を出してもらうには、「動くもの」と「将来性」を見せることが大事。
結局、動く状態をいかに作り続けていくか。動くように継続するのがポイントかな。
Q. スクラムを理解してない人から、「ミーティングばっかりやってるよね」とか、「残業しないでいつも早く帰るよね」とか嫌味を言われる。
A1. スクラムの啓蒙は外にもやってほしい。
A2. 完成前にプロダクトを提供していくのが大事。製品を細かくリリースしていく。
それにはバックログアイテムの分割が重要。
フィーチャーチームの単位で体制を組め、とLeSSはルールとして言ってる。
バックログアイテムをフィーチャーチームができるように分割してないとダメ。
フィーチャー単位でのバックログ分解をしていく重要性を開発チームにもプロダクトオーナーにも理解してもらわないといけない。
ユーザーが読んでもわかるようなバックログアイテムになってるのが重要。
開発者しかわからないバックログアイテムはフィーチャー単位でなくコンポーネント単位になってる可能性がある。
Q. LeSSをやったとしても、本質的には組織を変えないといけない。年月がかかる。
そこが上手くできなかった。どうやればいいか。
A1. 上の人に共感を得る。
A2. 組織を変えるにはトップダウンとボトムアップの両方が必要。
組織構造をいじれるマネジメントと、現場と、両面から変えていく。
スクラムの価値を説明して体感してもらうことが、スクラム知らない現場をボトムアップで変えていくのには大事。
A3. 2000人をいきなりには変えられない。
まず10人からやって、徐々に根回しを経営層にしたりしていく。
まずちっちゃく初めて、10人単位にして、次に100人単位にして、徐々に進めていく。
大企業でいきなりやるのは難しいので、小さい組織を特区化して、そこで試す。
徐々に人数が増えていくと、見え方が変わる。
2000人のうち、３００～４００くらい変えられると一気に変わるんじゃないかな。
A4. LeSSは8チームまでなら一気に変えていい。
8チーム以上のLeSS Hugeくらいになると、一気にやっちゃだめ。痛みを伴う。混沌としちゃう。
まず失敗を許容できる領域とサイズでやる。
ゆっくりゆっくりかな。
Q. 個人評価とチーム評価、どこかでぶつかる。どうすればいいか。
A1 特区化してるメンバに対しては、良い人に寄せてチーム評価をつけるようにしている。
A2. 多面的に評価する。
計画性があるものは、計画通りにいけてるかを重視するし、走りながら考えるものは、失敗しても行動やプロセスを評価する。
評価の考え方を分ける。
A3. LeSSの提唱者のバスは、評価制度自体が時間の無駄、と言っている。あんな価値を生まない活動はない。
odd-eは評価制度がない。作るつもりもない。
お金のために働く、という状況をいかに作らないかが大事。
ビジョン実現のために仕事をしていく、という状況を作る。
感想 一方向の座学形式でなく、ディスカッションやワークショップの要素が多く入っているのが良いですね。
いろんな人の考えを知ることができ、いろいろ考えさせられました。
それなりの規模の企業だとプロジェクトもそれなりの規模になることが多いので、スクラムをいかにスケールさせるか、というのに悩んでる人は、実はけっこー多いんじゃないか、と思うのです。
ということで、こーゆう観点の勉強会がもっと広まっていくといいなあと思いました。
榎本さん、関さんはじめ、関係者の皆様ありがとーございました。
