ScrumFestOsakaにいってきた。
早いもので2020年も半分終わってしまいました。
1月から目黒の会社に転職したんですが、いろいろあって5月からまた別の会社でスクラムマスターとして働いてます。 今まではデベロッパーと兼務してたんですが、専任になったり、まったく新しい事業ドメインだったり、リモートでチームの様子が見えなかったりで「うっ」となってるところです。
細かいセッションについてはおいおい書くかもしれないし、他の人が既にたくさん上げているので、場としてのScrumFestOsakaをふりかえりたいと思います。
運営のみなさん、スピーカー、スポンサーの皆さん、お話しした参加者の皆さん。多くの学びがある場をありがとうございました。
カンファレンスのニューノーマル
メインツールはZoomとDiscordでした。 Discordあまり使い慣れてなくて、ちゃんと楽しめるか不安でしたが、金曜日の段階でかなり慣れました。 オープニングで楽しく使い方の練習させてくれたのもよかった。
自分が関わっているコミュニティやカンファレンスもCOVID-19の影響で中止、延期、開催形式の変更など、目まぐるしく状況が変わる中、今回の開催形式やツールセットはとても参考になるものでした。
オンラインでの開催に舵を切った判断もそうですが、こうした開催形式を作り上げるには相当な苦労があったんじゃないかとおもい、運営の皆様にあらためて感謝です。
スポンサーブースがDiscord上ってどうなるの！？と運営目線で勝手に心配してましたが、完全に杞憂でした。
Zoom背景を使ったプレゼンや、各コミュニティでJamboardやMiroやRemoなどなど、コミュニティやスピーカーごとに色が出てるのも面白かったです。
プロセスやツールよりも個人との対話を
とはいえ、ただ箱だけ用意してもこんなに楽しい場が生まれるとも思えないし、本番ではいろいろトラブルもおきるわけで、「Discordの通話の調子が悪いので、こっちのチームはZoomの通話使っていいですかー？」や「こんなチャンネルあったらなー」というコメントがあった後にすぐにチャンネルが（1階の中華とかトイレとか、スライドまとめちゃんねるとか）できるなど、参加者みんなでセッションやカンファレンスを作り上げていく感じがとてもエモかったです。
かくいう私もそういうコメントを見かけたら、「許可を求めるな謝罪せよ」の精神ですぐつくってました。最後にハイタッチもできて、#廊下作ってよかった。承認欲求バク上がりです。
自己組織化ってなんだろう
RSGT2020 Day1の基調講演でCopeさんは「How many of you have seen a beautiful organization? This isn't a wonderful thing? Why are the rest of you not raising your hands? That pretty sad.」と質問してて、この時に手をあげられなかったことがずっと引っかかっていました。
会社のほかのスクラムマスターに、「自己組織化したチームってなんですか？」と問われても、明確な答えを返せませんでした。
みたこともないものを本当に作れるのか。そんな疑問を抱えながら半年過ごしてきました。
でも、今回のカンファレンスでのDiscordをみていて、「あぁ。こういうのができるのって、自己組織化したチームだよなぁ」と思ったりしました。 今なら自信を持って自己組織化を語れそうな気がします。
わたしは森を作りたい
コミュニティで得た経験はチームに還元したいですよね。美しいチームをみたので、私の関わったチームも美しいチームになって欲しい。
美しいチームといえば、明治神宮の森が人工の森なのは有名な話ですが、あの森ができたプロセスや造成の初期に考えられていたことって、チームや組織の成長プロセスにいかせるんじゃないかなというのを3-4年ずっと考えています。 上原敬二さんの著書なんかをみると、造成過程とその後どんな成長を遂げていったかの観察が詳しく書かれていてとても興味深いです。 まさにネイチャー・オブ・オーダー（←ちゃんと読んでない）。
いつかそんな話ができたらいいなぁとぼんやり思っているものの、きょんさんとかパタンランゲージ居酒屋とかみてると二の足を踏んでしまいます。まだまだ勉強が足りない。
さて録画みよーっと。
2019年を振り返る
2019年を振り返ります。
1月
会場を提供するついでに、登壇しました。これをきっかけに、
に寄稿することになりました。エンジニアの登壇を応援する会の皆さん、共著者の皆さん、おやかたさんありがとうございます。 （なお、このときに今年の目標としていたサービスづくりは頓挫してますが、ベンチプレス100kgと執筆は達成しました。）
2月
郡山さんのお誘いで、 hanahirodev.hatenablog.com に参加しました。 このあとRESTについてこの話を何度も繰り返し聞くことになります。
3月
2回目のFinalObjectに参加しました。
副業2社と合同誌の執筆でヒーヒー言ってました。 原稿のLintが1発で通って感動してました。
4月
技術書典6にいきました。合同誌のサンプルが配布されました。自分の原稿が世に出たのでちょっと感動。
5月
PyConJPのお仕事と副業のお仕事でヒーヒー言ってました。 BEAR.SundayでAPIを書く初体験をしていました。
6月
副業でたくさんお仕事したので、自分へのご褒美にCSMの研修を受けました。 Scrumとの出会いでこの先半年はScrumにお熱になります。 副業先の会社でScrumのイントロダクションをするなどもしました。
7月
Tokyo Agile Community (TACO)のイベントに初参加しました。 taco.connpass.com
8月
TACOのイベント2回目の参加です。やっとむさんからFun/Done/Learnのお話を聞いて体験しました。 「ホメホメ会」の話を聞いてすぐに自分の会社に持ち帰ってはじめました。
9月
TACOのイベント3回目の参加。LEGOでスクラムの体験をしました。これもすぐに道具を揃えてのちに会社でやりました。
PyConJP 2019のスタッフでバタバタしてました。 スポンサーブースの取材をしていました。
技術書典7で寄稿した合同誌が頒布されました。
いろいろあって退職を決めました。
A Scrum Book購入しました。（まだ読み終わってない）
10月
TACOのオーガナイザーになりました。 ユーザーストーリーマッピングのワークショップをお手伝いしました。
ぺちオブ、RESTful Web APIs読書会に参加しました。
台風の近づく中、森さんの振り返りワークショップに参加しました。
11月
Scrum Interaction 2019に参加。野中先生やJeff Sutherland氏をはじめ色々な方のお話を伺いました。 eventregist.com
オーガナイザーとしてお手伝い。
会社の人と合意形成ワークショップに参加。 scrum-jikken.connpass.com
RESTful Web APIs読書会に参加しました。
PHPカンファレンスに合わせて来日していたAdamさんの勉強会に参加。 hanahirodev.hatenablog.com
12月
PHPカンファレンスにスタッフ参加。今年もレポーターとして記事を書きました。
CSPOの研修を受けました。
ScrumBookの裏話を聞きました。
オーガナイザーとして通訳のお手伝い。 taco.connpass.com
（12月1週目は怒涛のScrum週間でした。）
RESTful Web APIs読書会に参加しました。
Agile Talks vol.1に参加しました。LeSSやSAFeの話を聞きました。Copeさんの話と対比できたのでよかったです。
JeffPatton氏にストーリーマッピングについて聞いてきました。 グラフィックレコーディング風にライブで発表されていてすごかったです。LeanCoffeeStyleをしりました。 www.meetup.com
来年から職場が目黒に変わります。仕事が変わって勉強会などに行ける頻度が減るかもしれませんが、RWABookの読書会とTACOのイベントには極力顔を出す予定です。 1月にはRSGT2020参加（仕事の都合で終日いられるわけではありませんが…）とCAL1の受講を予定してます。
皆様来年もよろしくお願いします。良いお年を。
「Adam Culp Special Talk Event "Hypermedia!"」参加記録
こちらの勉強会に参加しました。 connpass.com
会場を提供いただいた,BASE株式会社さん,スポンサーのParty Hard Incさん,Bengo4.com, Inc.さん ありがとうございます。
スピーカーの@adamculpさん, @mackstarさん, @koriymさん,@hidenorigotoさん。ありがとうございます。
@mackstarさんとは2年ぶりの再会でした。 hanahirodev.hatenablog.com
当日のタイムラインは以下から。 twitter.com
Talk #1: Doing the DDD thing across Micro-Frontends, Micro-Services and everything In-Between
@mackstarさんによるDAZN社におけるDDDとマイクロサービスの取り組みについてのお話です。
驚くことに設立から3年で世界中に開発拠点をもち,600人のエンジニアがいる巨大な組織だそう。 以下の映像とエンジニアブログが参考になりそうです。 www.youtube.com
スポーツ中継配信というドメインの特徴として,
- 大きな試合の1時間前からユーザー登録のトラフィックが集中
- 試合の時間帯だけアクセスが集中
加えて
こうした問題に対してMicro Frontend, DDD, Single-SPA, GraphQL, イベントストーミングといった手法を用いて,ドメインごとに責務の分かれたチームがエンジニアリングに取り組んでいるということが紹介されました。 とくにMicro Frontendは,（モノリスなリポジトリにするか議論はあったそうですが）コンポーネントごとにリポジトリも,デプロイメント・パイプラインも,チームも完全に分かれているとのことで興味深かったです。
Micro Frontendについては,以下の記事も参考になりそうです。 martinfowler.com
Discussion: DDD x Microservice
@mackstarさんと@hidenorigotoさんの対談です。
開発組織とビジネスサイドとの役割や関わり方についての話が盛り上がりました。 設計としての全体像はアーキテクトが責任を持つそうですが,そういう立場の人は得てして忙しすぎて手が回らなくなってしまって,チームが困ることも実際には起きているそうです。 そうした問題に対してワーキンググループを立ち上げて,解決に取り組むという活動を最近はじめたとのこと。
ProductOwnerがBacklogに責任を持つこと,チームの自治(autonomous)を重要視しているなど,AgileProcessが重要という話もありました。
Talk #2: Hypermedia!
@adamculpさんのHypermediaについてのトークです。 APIとホームページを対比しながら,Hypermediaとは何かについての再確認と,HATEOAS ,そしてHALについて紹介がありました。 また,HypermediaのリンクについてのPSR-13も紹介されました。PSRですが,言語に関係なくAPI開発者は読むべきという発言が印象的でした。
REST APIのドキュメンテーションが簡単にできるGUIのIDEの紹介もありました。 www.youtube.com
HTTPの純粋主義者(purist)からすると,RESTで苦労する開発者はRESTをちゃんと使っていないかHTTPの原則を理解していない。 という言葉は重かったです。
LT #1: Hypermedia Doc
@koriymさんのLTです。
REATにおいてHATEOAS(Hypermedia)と並んでもう一つ重要な「共通理解」を助けるためのドキュメントについてのLTです。 Application State DialogをDot言語で記述して,開発に関わる全てのひと（ProductOwnerやデザイナも含む）との共通理解を構築する方法の紹介がありました。
またダイアグラムと辞書をALPSに沿って記載する例の紹介もありました。 alps.io
A SCRUM BOOK THE SPIRIT OF THE GAMEを読んでいる
6月にCSM受けてスクラム熱が上がっているところに
が発売されたので四苦八苦しながら読んでいる
「Final Object #1」参加記録
3/27に@koriym さんのトークイベント、Final Object＃1に参加してきました。 株式会社TRASTA さんで再び開催されました。
今回はゲストスピーカーに古賀さんと林さんを迎えての開催でした。
はじめまして！Webアクセシビリティ -サーバーサイドエンジニア編- by @shiori_pk
はじめまして！Webアクセシビリティ -PHPer編- by 古賀詩織 | プロポーザル | PHPerKaigi 2019 - fortee.jp
の素振りを兼ねての登壇です。 アクセシビリティを普段から考えているか、会社としてどこまで対応するか方針があるかといった話題が印象的でした。
ショッピングサイトみたいな画像のたくさんあるサイトの場合、
— 腹周りたぷたぷ@脂肪肝 (@hanahiro_aze) 2019年3月27日
URLしか返さないAPIではスクリーンリーダー向けのalt属性などの情報を伝えられなくなる。
#FinalObject
サーバーサイドエンジニアが意識すべき点としてAPIが返す情報にアクセシビリティを意識した情報を含んでいるか、という点は「なるほど」と思いました。 また、アクセシビリティというと目の見えないひとなどを意識することが多いですが、インターネット回線が弱い地域の人に向けても考える必要があるという点は、 前回のFinalObjectでも話題になったクライアントキャッシュの利用によって解決できるという示唆がありました。
アクセシビリティを高くすることで、これまでリーチできなかった人へサービスを届けることができるようになることは、マーケティング上もプラスに働くという提案もあり、とても参考になる発表でした。
=== 2019/4/1 追記 ===
古賀さんから資料をご提供いただきましたので、追記します。
www.slideshare.net
=== 2019/4/1 追記 ===
RESTの力 by @koriym
こちらもPHPerKaigiの素振りを兼ねた発表でした。 前回の話に引き続き、「アプリケーション状態」、「キャッシュ」、「自己記述的メッセージ」についてのお話です。
アプリケーション状態
キーワード
— 腹周りたぷたぷ@脂肪肝 (@hanahiro_aze) 2019年3月27日
リソース状態：リソースの状態。サーバーサイドが持っている情報
アプリケーション状態：アプリケーションが今何を見ているか。サーバーサイドは興味がない状態。
#FinalObject
安全な遷移と安全でない遷移：アプリケーション状態からリソースへの操作
— 腹周りたぷたぷ@脂肪肝 (@hanahiro_aze) 2019年3月27日
サーバーはリソースの状態と次のアクションを情報として返す。
たとえばaタグ（安全な遷移）やformタグ（安全でない遷移）
#FinalObject
「アプリケーション状態」と「リソース状態」を「安全な遷移と安全でない遷移」と「アフォーダンス」で繋ぐという点が整理して理解できました。 前回の話の後も、この点の理解がイマイチできてなかったのですが、以下のスライドで「なるほど」と腹落ちした感じです。
キャッシュ
前回も話に上がった「E-Tagでの条件付きリクエスト」、「no-cacheとno-store」を中心にキャッシュの設計についてのお話でした。
個人的にはこのスライドがキャッシュ導入の参考になるのでありがたかったです。
自己記述的メッセージ
「メディアタイプの選択」、「schema.orgなどを命名（ボキャブラリー）に使うこと」が中心のお話でした。 htmlかjsonくらいしか使ったことがなかったので、メディアタイプの膨大さには驚きました。また、適切なメディアタイプの選定の参考になるページの紹介もありました。
情報の設計（IA）ですべきことはこういうことなんだなぁと思いました。
資料の全編は↓で公開されていますので、ご参照ください。
事業開発をしてみよう by はやしりょう
ご自身でも事業をされているはやしさんによる、エンジニア目線での事業開発のはじめ方についてのお話でした。 「要件定義ができるなら事業開発もできるはず」ということで、エンジニアリングとグロースハックの差分は考えを「コードにする」か「行動する」かの違いとのこと。
個人的には「課題を解決する前に、解決すべき課題を設定するためにモデリングをする」、「ユースケース図->ER図->実装」というプロセスを通じて気づいていないことに気づくことができるというお話が印象的でした。
Extra: REST API (Hypermedia API)開発のための7ステップ by @koriym
RESTful Web APIs9章で紹介されている設計プロセスについての解説がありました。 Todoリストを例に、
- クライアントが必要なオブジェクトを書き出して「Semantic Descriptor」を作成する。
- それぞれの参照関係を結んで「状態遷移」を書く。
- 使用されているボキャブラリーをIANAなどに登録されている標準的なものに置き換える
- 適切なメディアタイプを選定する
- 独自のボキャブラリーの説明を書く（ALPSやJSON-LD）
- 実装する
- 公開する
という手順をさらいました。
以上簡単に当日の感想とレポートでした。
