FC2ブログ

makopi23のブログ

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

自転車で東京から銚子への旅 2日目

2019/3/21(木)~3/22(金) 東京から銚子へ自転車で旅してきました。
このブログはその2日目(2019/3/22)の旅日記になります。

1日目の日記はこちら
http://makopi23.blog.fc2.com/blog-entry-307.html

2日目(2019/3/22)のスタート


千葉県成田市のネカフェで迎える朝~
朝食のパンとポテト、無料で食べ放題。
20190322_01.jpg

テント持参してたけど、完全個室でシャワールームもコインランドリーもあるネカフェは魅力やね。安いし。
花粉症なのでやっぱ野宿キツイ・・・

朝8時くらいにネカフェをチェックアウト。
20190322_02.jpg

自転車に荷物を積み込みます。
20190322_03.jpg

成田市さくらの山公園へ。
20190322_04.jpg

成田市さくらの山公園はNHKの「ドキュメント72時間」でも特集されてましたね。
再放送で見て、ぜひ行ってみたいと思ってたのでした。


成田空港の滑走路北側の小高い丘の上にある公園で、菜の花が綺麗です。
20190322_05.jpg

成田国際空港に近いので迫力ある飛行機の発着シーンを見ることができます。
20190322_06.jpg

飛行機の離陸をのんびり眺めます。
20190322_07.jpg

成田市さくらの山公園を後にし、天神峰トンネルをくぐります。
20190322_08.jpg

全長700mくらい。車道と歩道が分離されているので安全に渡れます。
20190322_09.jpg

成田市を抜け、香取市へ。
20190322_10.jpg

道の駅 くりもと 紅小町の郷で休憩~
20190322_11.jpg

田舎道をのんびりペダルを漕ぐ。
20190322_12.jpg

通りがかりに雰囲気良さそうなお寺があったので寄り道~
妙光山蓮華院 観福寺というそうな。
20190322_13.jpg

入り口の駐車場に自転車を停め、観福寺をのんびり歩きます。
20190322_14.jpg

観福寺には本堂や不動堂、毘沙門堂などがあります。お賽銭を入れて今回の旅の交通祈願をします。
20190322_15.jpg

行き当たりばったりの寄り道も旅の醍醐味なのです。

お次は下總國一之宮 香取神宮へ。自転車と共にお写真一枚~
20190322_16.jpg

関東地方を中心として全国にある香取神社の総本社だそうな。
前夜のネカフェでググって良さそうだったので来てみたのです。のんびり散策。
20190322_17.jpg

綺麗な池。神池と言うんだそうな。
20190322_18.jpg

香取神宮の総門。
20190322_19.jpg

香取神宮の楼門へ。
20190322_20.jpg

香取神宮の本殿。
20190322_21.jpg

本殿の右に宝物殿があります。
20190322_22.jpg

要石(かなめいし)。
地震を鎮めているとされる、大部分が地中に埋まった霊石だそうな。
20190322_23.jpg

香取神宮の奥宮。経津主大神の荒御魂を祀っているんだそうな。
20190322_24.jpg

香取神宮を堪能し、利根川に沿って銚子に向かいます。
20190322_25.jpg

千葉県の最東端、銚子市へ。
20190322_26.jpg

JR銚子駅前に到着~
20190322_27.jpg

犬吠埼へ。銚子半島の最東端の景勝地です。
20190322_28.jpg

犬吠埼灯台。レンガ造りの灯台で、99段のらせん階段を上ると太平洋を一望できるんだそうな。
残念ながら閉館時間を過ぎてたので登れませんでした。
20190322_29.jpg

銚子電気鉄道線の終点駅、外川駅へ。
木造平屋建の、ものすごくレトロな駅w
20190322_30.jpg

千騎ケ岩。
源義経が千騎の兵をもってたてこもったところから、この名がついたと言われているんだそうな。
20190322_31.jpg

名洗港海浜公園へ。銚子マリーナや屏風ケ浦の遊歩道などがあります。
20190322_32.jpg

イオンモール銚子へ。
一杯やりつつ、スマホのワンセグでサッカー日本代表 vs コロンビア戦をのんびり観戦~
20190322_33.jpg

この後、すぐ近くにテントを張って野宿しました。
この日は94kmほど走りました。
20190322_33_1.jpg

3日目(2019/3/23)のスタート


残念ながら、雨・・・


房総半島一周はまた次回~

感想


千葉~房総半島は平地メインなので走りやすいですね。
マスク付けつつ、いろんなところ回れて楽しかったです。

ただ花粉症なので、やっぱこの時期の野宿はツライです・・・
あと、この時期は三寒四温というだけあって、天気も崩れやすいのもな~・・・
あと、テントも寝袋も冬用じゃないので、やっぱ冬用が欲しい。寒風が貫通しまくりなので・・・
テントと寝袋、ちょと考えよう。

次の自転車旅はゴールデンウィークかな~
日本一周を目指して!

自転車で東京から銚子への旅 1日目

2019/3/21(木)~3/22(金) 東京から銚子へ自転車で旅してきました。

20190321_20.jpg

これまでの自転車旅


これまで長期休暇を何回か使って、小分けにして自転車で日本一周を目指してきました。経路はこちら。




日本一周とは別に、以下の場所へも自転車で旅をしてます。

今回の自転車旅の経緯


恒例の年度末、有給休暇消化祭り~
3/22(金)お休みとって、4連休にしてやったのでした。

絶賛花粉症なので、マスクを着けて自転車漕ぐことに。
坂道を登るとマスクで息が続かないので、極力平坦な平野の場所が希望なのです。
ということで、今回は関東平野の平地上にあり、温暖な千葉の房総半島を自転車で回ってみることにしました。
行先はほとんど決めず、行き当たりばったりな感じなのです。

ちなみに花粉症対策で↓を買ったのですが・・・

ライダーとしてはヘルメットを被れないのが致命的で、あと、ファンを回しても自転車で息が上がると超曇るので、旅のお供には諦め・・・

1日目(2019/3/21)のスタート


朝は比較的のんびり、9時くらいに出発~

まずは築地本願寺へ。デカイ・・・
20190321_01.jpg

去年、築地で3か月くらい仕事してたとき、すぐ近くにあったのでずっと気になってたのです。

駐輪場に自転車を停める。荷物いっぱい。
20190321_02.jpg

お賽銭を入れ、今回の旅の交通安全祈願をしました。のんびりお経を聞いたり。
20190321_03.jpg

隅田川に架かる永代橋を渡ると、綺麗な桜がお出迎え。
20190321_04.jpg

東京都江東区にある深川不動堂へ。
20190321_05.jpg

深川不動堂は千葉県成田市にある大本山成田山新勝寺の東京別院だそうな。
ちょうど今回のルートは成田を通るので、成田山新勝寺へも寄る予定なので、とっても偶然なのです。
20190321_06.jpg

中に入り、正座してお経をのんびり聞いたり。

深川不動堂のすぐお隣に富岡八幡宮があります。
20190321_07.jpg

寛永4年(1627年)に建立され、「江戸最大の八幡様」と呼ばれているそうな。
お賽銭を入れ、再び今回の旅路の交通安全祈願をしました。
20190321_08.jpg

荒川に架かる清砂大橋を渡る。
20190321_09.jpg

清砂大橋を渡りきると、東京都を抜けて千葉県の浦安市。
20190321_10.jpg

江戸川に架かる市川大橋を渡る。
20190321_11.jpg

船橋市と八千代市を抜け、佐倉市へ。
20190321_12.jpg

佐倉城址公園へ。国立歴史民俗博物館もあります。
20190321_13.jpg

おっきな国立歴史民俗博物館。
20190321_13_1.jpg

佐倉城址公園をのんびりサイクリング。
20190321_14.jpg

佐倉市だけに、サクラが咲いてます。
20190321_16.jpg

本丸跡。お花見してる方もいました。
20190321_15.jpg

佐倉市を抜け、成田市へ。
20190321_17.jpg

JR成田駅前。
20190321_18.jpg

JR成田駅から成田山新勝寺へ向かう参道。うなぎ料理店が目立ちます。
20190321_19.jpg

参道を抜け、成田山新勝寺の総門へ。自転車と共にお写真1枚~
20190321_20.jpg

総門を抜け、新勝寺仁王門へ。
20190321_21.jpg

成田山新勝寺と、三重塔。
20190321_22.jpg

夕日に映える成田山新勝寺。
20190321_23.jpg

成田山公園をのんびりお散歩。敷地面積165,000m²もあるそうな。
20190321_24.jpg

醫王殿へ。
20190321_25.jpg

のんびり成田の街を堪能後、近くのイオンモール成田で休憩。
すぐ近くにあるネットカフェで一晩明かしました。


この日は85kmほど走りました。
20190321_26.jpg

2日目の日記へ
 

POStudy 「1チームスクラムと大規模スクラム(LeSS)ではPO目線で何が変わるのか?」に参加しました

2019/3/6(水) POStudy 「1チームスクラムと大規模スクラム(LeSS)ではPO目線で何が変わるのか?」に参加してきました。

DoorKeeper
https://postudy.doorkeeper.jp/events/87970

Togetter
https://togetter.com/li/1325878

新しく立ち上がる大規模スクラムプロジェクトにスクラムマスターとして放り込まれそうなので、ちょうど良い機会、ということで参加することに。
先日↓の書籍が発売されたのでこちらも購入済みで、読み進めている最中なのです。



先日、LeSS Studyでも読書会が始まったので、こちらも参加してきたところです。
アジャイルサムライ横浜道場でおなじみ、たくぼんさん。


次回の読書会は3/19です。ご一緒にいかがですか~?

イントロダクション


今日のファシリテーターはodd-eの榎本さんです。
以前、スクラムマスター研修(CSM)を受けたときにお世話になりました。

冒頭、参加者にカードが配られ、榎本さん曰く、「今日一番議論したいことを1つ書いてほしい」とのこと。
ということでこんな感じで書いてみた。
20190306_01.jpg

先月、デブサミでScrum@Scaleの講演を聴講してブログ書いたり、Nexusの日本語ガイド読んだりしてたので、やっぱ違いが気になります。

書き終わったら、次は「周りの参加者さんと自己紹介を兼ね話し合ってみてください」とのこと。
ということで周りの4~5人の方と会話させていただきました。やっぱ同じこと思ってた方もいらっしゃったようで。

LeSSの概要理解


お次は、LeSSの概要を紹介した動画をプロジェクタに投影しながら、榎本さんが説明を随時挟んでくださいました。
日本語の字幕が付いたスライド、あったんですね。



以下、メモ。

「大規模」について
LeSSで大規模にスクラムをやることを推奨はしていない。
小規模で上手くいってたものが、大規模になると上手くいかなくなる。。。
大規模にスクラムをやることを目的にしてほしくない。
小さく行けるなら、そちらのほうが好ましい。
無理にスケールしないでください。

どういった状況を大規模というか?というと、2チームから。
1チームでいけるなら、極力1つのチームでやるのが好ましい。
チームが2つ以上になるなら、極力シンプルに。
極力スクラムを維持しながら、必要最低限のものを追加して、スクラムのエッセンスを極力残したものがLeSS。


プロダクトオーナー
LeSSは1人のプロダクトオーナーで、プロダクトバックログも1つ。
それに対して複数チームが仕事をしていく。スプリントの期間も全チームが一緒。
基本的には「1つのスクラムでやることを複数チームでやるにはどうすればいいのか」という観点で最低限のルールを追加している。

チーム間の調整は、チーム同士で調整していただく。
プロダクトオーナーやスクラムマスターがチーム間の調整をするわけではない。
それぞれのチームが開発していく上で、チーム間の調整は必要。それをチーム同士でやっていただく。

プロダクトオーナー視点でいうと、複数チームになると、やることが増えてくる
1つのチームなら要求の詳細化をプロダクトオーナーが出来た。
それが複数チームになると難しくなるので、要求の詳細化などをプロダクトオーナーから開発チームに移譲していく。
ビジョンはプロダクトオーナーが示す。PBIの優先順位もプロダクトオーナーが最終に決める。
開発チームが自分たち自身で顧客から要求を聞き出す、というようにプロダクトオーナーは促していく必要がある。
開発チームと、要求を持ってる人を、近づける。
開発チームと顧客とで、直接やってもらう環境づくりをプロダクトオーナーがやる。
プロダクトオーナーが自分でPBIを明確化しなくても済むようにする。


オーバーオールレトロスペクティブ
通常のスクラムにない考え方として、オーバーオールレトロスペクティブというイベントがある。
開発チームの代表者、マネージメントする人、顧客などの人たちが集まって、複数チームや組織全体の課題を考える。
複数チームで開発するとなると、全体としての課題解決の場が必要になる。それがオーバーオールレトロスペクティブ。


2種類のLeSS
LeSSは2種類ある。通常のLeSSと、LeSS Huge。
LeSS Hugeになると、8チーム以上。その場合、もうちょっと構造を追加しないと上手く全体が回っていかない。
8チームを超えたタイミングで追加の構造が作られる。
LeSS Hugeでは、エリアプロダクトバックログとエリアプロダクトオーナーという概念が追加される。
実際の開発チームから見たら、エリアプロダクトバックログが通常のバックログで、エリアプロダクトオーナーが通常のプロダクトオーナー。
プロダクトオーナーは、どのエリアにプロダクトバックログアイテムをまかせていくのかを決める。
各チームをどこのエリアに配置するのかを決める。
全体の差配、調整をプロダクトオーナーが担う。

開発チームから見たら、常に1つのプロダクトバックログ、 1人のプロダクトオーナー。


組織構造
通常、スクラムやLeSSをやるように組織は設計されていない。
LeSSは影響範囲が広くなるので、組織の影響を多く受ける。
スクラムやLeSSで定義されてない役割が組織にはいっぱいある。
企業にはそういう課題がいろいろある。
それらの課題を解決して大規模でスクラムやっていくには、推進者には障害がインパクトとして出てくる。

フィーチャーチームになるよう組織構造を変えなきゃいけない。
顧客に価値を提供できるスキルを持ってるのがフィーチャーチーム。
UI/UXチーム、サーバサイドチーム、DBチーム、とかは「コンポーネントチーム」と呼ぶ
1つのユーザー価値を提供することができるスキルセットを持ってる人がフィーチャーチーム。
組織構造を変えていくことが必要になる。


More with Less
少ないことでもっと多く。More with Less。これが基本の考え方。
何かを追加するのではなく、極力シンプルに維持していくのがコアの考え方。
QAの責任者を立てる、とかだと、「品質に責任を持つのはQAだ」という考えになってしまう。
それは開発チームから品質の責任を取り上げているのと一緒。
チームに責任を持って行ってもらう。責任をQA等、あちこちに分散させないことが大切。
チームから責任を奪うのではなく、チームが責任を果たせる状況を作っていくのがマネージャ。

原理原則がコアになる。
その上にフレームワークのルールがある。そんなに数はない。
原理原則やルールだけでカバーできない部分は、TIPSとして多く存在している。ガイドとか実験だったり。本に書いてある。
前の2冊は、クレイグとバスの実験がいっぱい書いてある。その一部が今回の本に書かれている。
必ずやったほうがいいよ、というものではない。
ルールはやりなさい、とLeSSは言ってるが、ガイドに書いてあることは助けになることがあるので使ってみるのがいいんじゃない?くらいな感じ。

LeSSでやることは極力シンプルに。
プロダクトオーナーからの視点としても、スクラムと変わらない。
極力チームに裁量を持ってもらわないとプロダクトオーナーは回らない。

PO視点での探求セッション


ここからはフィッシュボウル(Fishbowl)形式でのパネルディスカッションです。
4人がパネラーとして前の椅子に座り、ディスカッションネタを提供する人が順に1人ずつ前に出て、パネラーと議論していきます。
20190306_02.jpg

以下、出た意見のメモ。
実際はこのセッションの前に質疑応答の時間があったので、メモもそこから。



Q.
LeSS Hugeは8チームから、という話だが、「8」の意味は何か?

A.
「8」は、LeSSの中でオススメしているプロダクトバックログの粒度に関係がある。
1チームが毎スプリントで4つくらいプロダクトバックログアイテムを選択するのがお勧め。
プロダクトバックログリファインメントで3スプリント先まで詳細化する。
そうすると、1チームあたり12個くらいのバックログアイテムを明確にする必要がある。
8チームだと、合計100個くらいのバックログアイテムを明確にする必要がある。
100くらいがプロダクトオーナー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人のうち、300~400くらい変えられると一気に変わるんじゃないかな。

A4.
LeSSは8チームまでなら一気に変えていい。
8チーム以上のLeSS Hugeくらいになると、一気にやっちゃだめ。痛みを伴う。混沌としちゃう。
まず失敗を許容できる領域とサイズでやる。
ゆっくりゆっくりかな。



Q.
個人評価とチーム評価、どこかでぶつかる。どうすればいいか。

A1
特区化してるメンバに対しては、良い人に寄せてチーム評価をつけるようにしている。

A2.
多面的に評価する。
計画性があるものは、計画通りにいけてるかを重視するし、走りながら考えるものは、失敗しても行動やプロセスを評価する。
評価の考え方を分ける。

A3.
LeSSの提唱者のバスは、評価制度自体が時間の無駄、と言っている。あんな価値を生まない活動はない。
odd-eは評価制度がない。作るつもりもない。
お金のために働く、という状況をいかに作らないかが大事。
ビジョン実現のために仕事をしていく、という状況を作る。

感想


一方向の座学形式でなく、ディスカッションやワークショップの要素が多く入っているのが良いですね。
いろんな人の考えを知ることができ、いろいろ考えさせられました。

それなりの規模の企業だとプロジェクトもそれなりの規模になることが多いので、スクラムをいかにスケールさせるか、というのに悩んでる人は、実はけっこー多いんじゃないか、と思うのです。
ということで、こーゆう観点の勉強会がもっと広まっていくといいなあと思いました。

榎本さん、関さんはじめ、関係者の皆様ありがとーございました。

-->