2019年1月も終わっていますが2018年に読んで心が動いた漫画の一覧を紹介します。対象は以下。
- 2018年に買った・読んだ漫画
- 2018年より前から読んでいて続刊を買った・読んだもの
- 2018年以前に完結しているが初めて読んだもの
おすすめ順に並べるとかカテゴリ順に並べるとか考えたのですが終わらなさそうなのでやめました。コメント量が多いものがおすすめです（たぶん）。
また、一記事に収まらなかったのでとりあえず20作品だけ。
続きを読むGatsbyjsがContributorにグッズを配布したりする取り組み
Static site generator の GatsbyJS が掲題の取り組みを始めたようす。
朝起きたらだいぶ前にめっちゃ小さくコントリビュートしたときの pull request にコメントが付いていた。
Gatsby community の OSS に貢献した人への感謝の気持ちとして
- Gatsby Swag Store*1 でグッズと引き換えられるクーポンをあげる
- GitHub の Gatsby organization に招待する
とのことだった。早速グッズを注文*2して org にも join してみた。
sustainable な OSS community をどのように成立させるか？という問については昨年のNode festivalで発表する程度には関心があるので、この取り組みは非常に面白いと思った一方、グッズのデザイン・製造・販売、これはもはや事業だよな〜と思っていたら2018年5月にすでに会社が設立されていたことをいまさら知る。
興味が湧いた方はぜひ Contribution をどうぞ。
ReactのContextとHooksで日本語のふりがな入力を支援するコンポーネント書いた
漢字を入力したときにふりがなを自動入力する機能をサポートするためのReact componentを書いてみました。日本語のフォームでよくあるやつです。
最近は仕事でReactをあまり書いておらず16以降のContextとか16.8のHooksとか新し目の機能のことがわかっていなかったので、その辺で遊びたかったのがモチベーションです。
Hooks と言っていますが目玉ぽい useState の話でなく useReducer, useContext がメインです。
実装
使いかたはREADMEに書いたのでさらっと流します。以下のような感じで Kana(Provider|Dispatcher|Consumer) を react-kana-provider が提供します。provider, consumer という名前からわかるとおり React Context を使っています。
import * as React from "react"; import * as ReactDOM from "react-dom"; import { KanaProvider, KanaDispatcher, KanaConsumer, KanaDispatcherProps, KanaConsumerProps } from "react-kana-provider"; const App = () => ( <KanaProvider fieldNames={["last_name"]}> <KanaDispatcher> {({ setKana }: KanaDispatcherProps) => ( <input type="text" onChange={e => setKana("last_name", e.target.value)} /> )} </KanaDispatcher> <KanaConsumer> {({ kana }: KanaConsumerProps) => ( <input type="text" value={kana.last_name} /> )} </KanaConsumer> </KanaProvider> ); ); ReactDOM.render(<App />, document.getElementById("root"));
実践: React Hooks - mizchi's blogに書かれている「useReducerとcontextを組み合わせてReduxのようにstateを管理する」というのを内部ではやっています。provider、consumerだけでなくdispatcherという名前のcomponentを提供しているのはそのためです。（実態はdispatcherもconsumerです）
漢字を入力するフィールド側（KanaDispatcher）で「漢字を入力する」イベントをdispatchし、内部のstateが更新され、ふりがなを入力するフィールド（KanaConsumer）側でそれを参照する流れです。
入力された文字列からひらがなを抽出するロジックはhistorykanaに丸投げです。
また、ふりがなフィールド側に値をどういう条件で・どのタイミングでセットするかは完全に利用者に委ねています。（ふりがなフィールドが入力済かどうかを検知したりはしない）
原形: context のみで書く
最初はuseReducerなどは使わずcontextだけでなんとかしようと、providerをラップした React.Component をがりがり書いていました。
import * as React from "react"; import historykana from "historykana"; const KanaContext = React.createContext(""); export class KanaProvider extends React.Component { constructor(props) { // 省略 } setKana(fieldName, inputtedValue) { this.setState((state, props) => { const history = inputtedValue ? [...state.history[fieldName], inputtedValue] : []; return { ...state, history: { ...state.history, [fieldName]: history }, kana: { ...state.kana, [fieldName]: historykana(history) } }; }); } render() { return ( <KanaContext.Provider value={this.state.kana}> {this.props.children({ setKana: this.setKana, kana: this.state.kana })} </KanaContext.Provider> ); } } export const KanaConsumer = ({ children }) => ( <KanaContext.Consumer>{kana => children({ kana })}</KanaContext.Consumer> );
これはこれで動くのですが遊び足りない React.Component を使わなくなっていく流れに沿ってないなーと思ったり、ライブラリ利用者側では consumer は 切り離せるのに state を更新する setKana 関数は利用する component まで props で渡していくのが不均衡だなと思ったりしました。
現状: useReducer + context で書く
現在の react-kana-provider の実装を一部省略しつつ貼ります。（上記実装との間にミッシングリンクがあり、突然 TypeScript になります）
import * as React from 'react'; import historykana from 'historykana'; function reducer(state: KanaProviderState, action: any) { switch (action.type) { case 'SET_KANA': { const { inputtedValue, fieldName } = action; const history = inputtedValue ? [...state.history[fieldName], inputtedValue] : []; return { ...state, history: { ...state.history, [fieldName]: history, }, kana: { ...state.kana, [fieldName]: historykana(history), }, }; } default: { return state; } } } const KanaContext = React.createContext<KanaProviderState>(null as any); const DispatchContext = React.createContext<React.Dispatch<any>>(null as any); export const KanaProvider: React.FunctionComponent<{ fieldNames: string[]; }> = ({ fieldNames, children }) => { const [state, dispatch] = React.useReducer( reducer, getInitialState(fieldNames), ); return ( <KanaContext.Provider value={state}> <DispatchContext.Provider value={dispatch}> {children} </DispatchContext.Provider> </KanaContext.Provider> ); }; export const KanaDispatcher: React.FunctionComponent = ({ children }) => { const dispatch = React.useContext(DispatchContext); const setKana = (fieldName: string, inputtedValue: string) => dispatch({ type: 'SET_KANA', fieldName, inputtedValue }); return typeof children === 'function' ? children({ setKana }) : null; }; export const KanaConsumer: React.FunctionComponent = ({ children }) => { const { kana } = React.useContext(KanaContext); return typeof children === 'function' ? children({ kana }) : null; };
すっきりしています。記述量はさほど変わっていないので一見これ本当にすっきりしてんのかという感じですが、state を更新する責務が reducer にまとめられたりしているため、Redux 利用者ならさらっと読み下せるようになったのではと感じます。 export している component がすべて React.FunctionComponent に置き換えられているのも良さそうです。
dispatcher を提供しているので prop drilling 問題も解消してます。
CodeSandbox
これまで使っていなかったのですがアイデアを試したいときに超絶便利ですね。自分はフロントエンドの環境構築能力がダメダメなので一瞬で立ち上げてもらえて非常に助かりました。
CodeSandbox上で「ライブラリ側」と「利用者側」のコードを同時に編集できるのも実験がしやすくて最高です。ライブラリが提供するAPIについてインタラクティブに試行錯誤したりできます。
今回は「よーしライブラリ書くぞ！」と意気込んで始めたというより、CodeSandbox上で「こんなことできるかな」といろいろ試してたらなんかできたので面白かった、公開しておくか、という流れでした。
所感
久々に触ったらいろいろ学びがあってよかったですが、逆にまだまだわからないことがいっぱいあるなと思いました。React + TypeScript にまだ身体が順応しきってなくてけっこう手が止まる。
また、npm publish したものの hooks 使っているので16.8以上じゃないと使えない、おまえ使ってもらう気あるのかという感じですが一旦は自分のためのコードということで。
余談
実はけっこう前にこういうのを書こうとしたけど完全に記憶から消えていた、というのを思い出した。以前に jquery.autokana というライブラリを使っていて、その repository の issue で「オレもいつか React で書いてみるわ！」とか宣言していた…！
（1年以上かけて伏線を回収した感がある）
わかっていないこと
このあと調べたり詳しい人に聞いたりしたい
そもそもこのやりかたでよいのか
わざわざ context とか hooks 使わなくても render props とか HOC でも書けるので、解決したい問題に対してベストなアプローチなのかわかってない
実験の仕方
CodeSandboxでごりごり書いて実装したけど、世の中で React の component ライブラリ書いている人はどうやって開発・実験・テストしているのか
hooks の polyfill
React context には create-react-context という polyfill があるが、hooksにもあるのかな？もしあれば対応する React の version を下げられる
ohbaryeが2018年に書いた記事振り返り #年間ブックマークランキング
ohbaryeが2018年に書いた記事を唐突に振り返ってみる*1。
全体的に登壇した系のイベントレポートが多い。その権化というかまとめとしての一位の記事は「読みました」って言ってくれる人が多くて嬉しかった。
技術記事の割合が少ないので今年はもう少し増やしていきたい
valid,invalidの2018年ブックマークランキングベスト32(累計1023ブックマーク)
generated by 年間ブックマークランキングジェネレーター
*1:振り返るのが遅いので一部2019年の記事が入っている
Facebookにおけるエンジニアリングマネジメント (Inside Facebook Mobile ep.5)
Inside Facebook Mobile という podcast の以下のエピソードが面白いと @hotchemi さんから教えてもらったので聞いてみた。
Inside Facebook Mobile について
この podcast のことはよくわかっていないが、上述の放送回は Facebook の London オフィスで働く Balazs 氏が彼のプロジェクトや経歴・現在の仕事について話す回だった。
50分ほどのエピソードのうち後半（28:45あたり以降）はまるまるエンジニアリングマネジメントについて語っており、印象に残る点が多かった。
メモ
ホストの2人が質問して Balazs 氏が答えていくスタイル。なので質問を見出しにして回答や語られたことを箇条書きでメモした*1。
How do the transition happen?
- もともとやりたかったこと。キャリアの早いうちにマネジメントぽいことを少しやっていた。
- 仕事で人を助けることに興味がある
- 一方コーディングも大好きなのでマネジメントの仕事をするかどうかは迷った
- 最初は半年ぐらいマネジャーをやって、その後はいちプログラマに戻ろうかと思っていたが、そうならなかった
思ったよりハマった
Facebookではマネジャーになることはプロモーションではない
- マネジャーはサポートする役割
マネジャーと技術
マネジャーになるということはコードを書くのをやめるということ？テクニカルバックグラウンドがなくてもマネジャーになれる？
- テクニカルバックグラウンドなしにマネジャーにはなれない
- Facebookのマネジャーは全員スーパーテクニカル
- ミーティングのリード、チームの方向性を決めるのはマネジャーではなくシニアエンジニアの役割
- マネジャーとして最も大事なことの一つはエンジニアのサポート
- テクニカルリーダーというより人々のサポーター
テックリードとマネジャーの違いは？
- 良い例がある、今の自分のチームにシニアエンジニアがいて、チームのことは全部彼女がやっている
- ミーティングのファシリテーション、チームのミッションづくり、ロードマップ作成、チームメンバーの技術面での成長のために1-on-1もやっている
- 私はガイダンスを行ったり、オフサイトをやったりとか…(笑)
1-on-1のスタイルは？
- 人によってぜんぜん違う
- 大事なのはhave it consistently、マネジャーが助けられるように問題を話してくれるとか、そういう信頼を築くため
- weeklyで全員とやっている
- 常にお願いしていることは、1-on-1はエンジニア（メンティー）のための時間
- 内容はキャリア開発、テクニカルな議論、現状の共有など
良いマネジャーに必要なスキルは？
- 大きな誤解の一つは、良いマネジャーであるには良いエンジニアであること、というもの
- ぜんぜん違う専門性、エンジニアキャリアの延長線上でもない
- とはいえエンジニアの専門性があることは、メンバーの話を理解したり共感するために大事
- one of the key things is empathy
- good communication skills
- エンジニアの成功で幸せを感じることができるか
- いちエンジニアとして以前はhigh achieverだった
- あれもこれもリリースできた！でも自分は何もやっていない！
- そんな状況でも思ったより喜べた、というのが印象深い
どんなトレーニングがある？
- 内部トレーニングがいっぱいある
- （Balazs氏が所属するLondonオフィスでは）マネジャーになったときはトレーニングがぜんぜんなかったんだけど、マネジャーになってから1年後にできたので受けてみたらすごく良かった
- 1年前に欲しかった〜、既に知ってることだ〜
マネジャーになるプロセス
Facebookの外からマネジャーとして入社することはある？
- マネジャーの採用計画はある
- しかしとても経験豊富な人しか採用しないし、技術にも明るくなければいけない
- マネジャーへのインタビュープロセスはエンジニアに対するものとほぼ同じ
- ホワイトボードコーディングテストもある、でも現時点でどれだけコードを書けるかというより最盛期にどれだけだったかを測る
- これはとても難しいことがある
フィードバック
- オープンなフィードバックを行うカルチャーは自分がFacebookに残る理由
- 誰もが誰もに深みのあるフィードバックを送る
- フィードバックの仕方に関するトレーニングがある
- performance feedback every half year
- マネジャーはフィードバックをそれぞれのエンジニア、カスタマー、パートナー、同僚などから集める
- マネジャーは改善すべきこと、何にフォーカスするかを考える
- ときにはオープンで厳しいフィードバックをすることもあるが、これをいかに効果的に行うか学ぶことができる
- これは4年間で最も自分を変えたことの一つ
- 今ではフィードバックを貰うのを心待ちにしている
- ときには厳しいフィードバックを自分も受けたことはあるがとても有意義だった
- フィードバックは他人を打ちのめすものではなく成長を助けるものと理解
- Facebookの良いところは、受け取ったフィードバックに基づいて何を改善するかをマネジャーと一緒に考えるところ
- マネジャーからの一方向でなく双方向で送り合うのが本当に良いカルチャー
良いマネジャーになるには？
エンジニアにとっての成長は最新の技術をおさえたり、たくさん機能を作ったり改良したりすることが挙げられる
- エンジニアリングの分野ほど急速に変化はしないけど大切なことを学ぶ
- 脳のはたらきとか社会のはたらき、抽象的な事柄
- 読書したり、最新の情報を漁ったり、コミュニケーションに関するスキルについていかに小さくても学んだり
- こうした学問は、たとえば何も話してくれないメンバーと向き合うとか、マネジャーとしてとても役に立つ
チームの目標・ロードマップ
- Facebookはとてもボトムアップな会社
- 強くて賢い人を雇ってミッションを見せる、あとは何をするかは各々に見つけさせる会社
- エンジニアが解決すべき問題を見つけてマネジャーやチームと議論する
- 皆で「最もインパクトが大きいやるべきこと」を話す
- 入社してマネジャーに自分のキャリアや強みを話したら、マネジャーからは「それじゃあ何やりたい？」
- 何をしたいかを決めると同時に、それがベストな選択であると示すことも各自の責任になっている
いま挑戦していることは？
- かつては自分の行動や自分が達成したことに対してresponsibleだった
- 今はチームの成功に対して責任を持っている
- 自分のゴールはインパクトをもたらすようなdeliverが自律的にできるチームを作ること
- チームに「○○をしろ」と言うことはできない
- 有能な人を連れてくるのもマネジャーの仕事
- （エンジニアからマネジャーになっての）マインドセットの変化は大きく、チャレンジング
- Facebookにはたくさんのスモールチームがあり、誰もが好きなことをできるので百のスタートアップの集合みたいになっている
- 他のチームがやっていることをちゃんと把握してコンフリクトしたり被ったりしないようにするのはマネジャーの仕事であり、これもまた挑戦
Further more
"Facebook Engineering Management" とかでググると他にも情報が出てくるので知りたい人は読んでみると良さそう。
「Facebookでの Engineering Manager ってどんな感じ？」という質問に対して、management は人やチームによって大きく変わるので唯一の答えはなさそうだ、という回答。
podcast で語っていたような「社内に100のスタートアップがある」とか、社内のチームによって働き方が全く違うというのに真実味がある。一方、マネジャーが何に対して責任を持つかは不変的だということも書いてある。
Glassdoor には従業員からのレビューが載っている。Pros にも Cons にもワークライフバランスが挙げられており、これもチームによって全く違いそう。
同時通訳がいるときのプレゼンで気を付けること
前回の記事で書き忘れていたのだが、RSGT2019で行ったプレゼンでは日→英の同時通訳 (interpreter) の方に付いていただいた。
通訳付きのプレゼンをするのは自分にとって初めての経験であり、予想外だったことやうまくいかなかったことがあったのでメモしておく。
準備からプレゼンまでの流れ
おそらく通訳の方・会社・イベント・言語など様々な変数で変わるのだろうが、今回は以下の流れで行った。
- 事前に資料を提出する
- 事前に資料を見ながら打ち合わせをする
- プレゼンをする
- お礼を言う
1. 事前に資料を提出する
RSGT2019ではイベントの1~2週間前には資料を提出するように案内があった。
自分の観測範囲では「テック系のイベントでそんなに早く資料準備してるやつ、おるか…??」という雰囲気なのだが、通訳者の方に事前に資料を読んでもらう工程が挟まるので締切は無論守ったほうが良い。
また、提出後の資料の大幅な訂正は止めたほうが良い。
今回ナルホドと思ったのだが、通訳者は資料を印刷して紙にメモを書き込んでいた*1。そのため提出後に修正していると直前の打ち合わせ（最悪の場合、本番）になって「あれ、手元の資料と投影資料が違う…!?」という問題が起きる。
自分も前日に訂正していたのだが、Google slidesを使っていたので打ち合わせのときにはお互い最新の状態を参照して話ができるだろうと高をくくっていた。が、ダメ…っ！「すみません、こちら修正してまして…」と頭を下げることになった。また、別の登壇者の資料はだいぶ激しく変わっていたようで、打ち合わせの際に資料を印刷し直したりしていた。
2. 事前に資料を見ながら打ち合わせをする
イベントの開始前または休憩時間を利用して通訳者との打ち合わせを行う*2。今回は20分の発表のために12分ほどの打ち合わせを行った。
まず最初に聞かれたのは「一番伝えたいことはなんですか？」という質問だった。なるほど、すごく良い質問ですね...!!
次が「話の構成・骨子を教えてください」というもの。今回の自分の発表はケーススタディだったので「1. 前提共有、2. 事例紹介、3. 得られた学び」という簡単なステップを説明した。「1のステップを5~6分で終わらせるつもりです」のように時間配分を伝えると「その情報があると大変助かります」と褒められた。今回に限って言うと、20分の発表の間に2名の通訳者が入れ替わりつつ進めるスタイルだったので、どこで区切るかが明確でよかったというのもある。
そのあとはスライドを一枚一枚めくりながら内容をあっさり説明していく。
専門用語や固有名詞がある場合は都度説明を行う。専門用語として使われる英単語が決まっている場合はそれを伝える。他にも"Kata (型)"のような日本語でそのまま輸出されているような概念はあえて訳さないでくれ、と伝える必要がある。
スライドに書いているけど触れないところ・スライドに書いていないけど話すことなども伝えていく。このへんはちゃんと練習して流れを作れていないと実りある打ち合わせにならないと思う。特にスライドに書いていないけど話すことを伝えることが通訳者にとっては大事だと仰っていた。今回の自分のスライドは文字が多めだったのだが「スライド上には絵だけ、口頭で補足する」のようなスタイルだともっと打ち合わせが大変になっていたかもしれない。
あとで調べて知った話なのだが、ジョークや笑いどころを伝えるのは文化の違いなどのために表現が難しいらしく、設ける場合は事前に伝えると良いらしい。自分のギャグを自分で説明するという大変恥ずかしい思いをしそうなのでこれは辛そう…。
余談だが、発表持ち時間とスライド枚数の相関はなんとなく通訳者の方々も感覚値として持っているようで、今回の20分でスライド70枚超えという自分の状況に対して「本当に20分で終わりますか？」というツッコミをもらった。
3. プレゼンをする
あとは打ち合わせ通りやるだけ、なのだが普段のプレゼンとは違って幾つか気をつける必要があった。打ち合わせで話した流れ・内容からなるべくはずれないようにする、ゆっくりしゃべる、一文を短くする、断定口調で言い切る等々。切りの良いところで休憩がてら水を飲んだりもした。
まぁ正直やっている最中は同時通訳のことを気にかけている余裕がほとんどなく、こんな感じ↓なのだが…。
通訳の方にゆっくり喋ってくださいって言われたのにオタク文法の早口でまくしたててしまった#RSGT2019
— 広島の粗大ゴミ (@ohbarye) January 10, 2019
通訳の方も「あまりに早口だと内容が"落ちる"ことはある」と仰っていたのでこれは実に良くないです。
ちなみに今回は質疑応答の時間は取れなかったのだが、もし英語で質問があればそれを日本語に同時通訳してもらうのだと思う。
4. お礼を言う
通訳の方を捕まえてお礼を言う。こちらにとっては休憩時間だとしても通訳者は次のプレゼンに備えていることもあるので邪魔しないよう気をつける。
気を付けることまとめ
一連の流れを踏まえて同時通訳がいるときのプレゼンで気を付けることをまとめる。一部は通訳がなくても当たり前のことだが、より重要性が増すものとして記述する。
事前準備
- 資料は早めに「完成」させ、期限通りに提出する
- 「完成」とは資料を書き上げるだけでなく発声練習を通じて表現や構成が磨き込まれた状態
- 資料は文字多めのほうが通訳者としては安心かも
- スライドとは別にスピーカーノートを用意して共有するのであれば文字少なめでも大丈夫だと思う
- 提出後は資料を修正しない
- ほんの少し（言い回しを変えるぐらい）ならまだ大丈夫だがページが増減するレベルだとやばい
- 最も伝えたいこと、話の構成をすぐに説明できるようにしておく
- 時間配分（アジェンダのn番目でm分ぐらい経過している想定）を決めておく
- プレゼン内で触れる専門用語や概念の英語表現を調べておく
- ジョークを挟むなら事前に相談する
個人的にはイベントの1週間以上前に複数回の練習を終えて練度を高めた状態の資料を提出するのが一番むずかしいな…
プレゼン
主に話し方
- 打ち合わせで話した流れ・内容からなるべくはずれないようにする
- ゆっくり喋る
- 一文を短くする
- 断定口調で言い切る
- 主語を明言する
- 可能なら良い感じに休憩を挟む
- 終わったらお礼を言う
そしてこの記事を書きつつ今更ながら自分の発表がどのように英訳されたのかがすごく気になってきたので、「通訳内容を誰かに頼んで録音しておいてもらう」というのも次の機会があればやってみたい。
同時通訳付きでいつもと違うプレッシャーはあったものの勉強になってよかった、今となっては同時通訳無しはイージーモードなはずだ!!
#RSGT2019 で『プロダクトの「負債」を「機能」と呼び直すために』というプレゼンをしました
Regional Scrum Gathering Tokyo 2019に初参加してきた。
発表した
「応募してみたらどうか」という"圧"を感じたので勢いで応募してみたら、期限ぎりぎりだったにも関わらず選んでもらえた!!
『プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー』
内容は過去にQuipper Product Team blogで書いた記事でもあるし、Rails Developer Meetupでも発表したもの。なのでそのまま再演するのはどうかなぁと思ったのだが、幸いにも聴衆があまり被っていなさそうということでほとんどアレンジせずにいくことにした。
新しいフィードバックが貰えると良いなと思っていたら本当に貰えて良かった。
また、初めて通訳つきのプレゼンをしたのだが、いったいどのように訳されていたのか、とても気になる…。
通訳の方にゆっくり喋ってくださいって言われたのにオタク文法の早口でまくしたててしまった#RSGT2019
— 広島の粗大ゴミ (@ohbarye) January 10, 2019
皆さんの発表
それぞれの発表に触れると長くなってしまうので、特に印象に残っているもの3つまで。
#RSGT2019 ちゃんとやってるのに なんかうまくいかないスクラム からの脱出 - Speaker Deck
今回いちばん得るものが大きかったというか、自分の問題意識に近いと感じたプレゼンだった。
ここめっちゃ良い / "「期待」はスクラムと相性がよくない" "スクラムは現実を見せ続ける" / “number-rsgt2019-tiyantoyatuterufalseni-nankaumakuikanaisukuramu-…” https://t.co/BuE4pToxpZ
— 広島の粗大ゴミ (@ohbarye) 2019年1月9日
自分のチームでは去年の暮れから初めてスクラムをやりはじめたのだけど、なんとなくチームや自分が背伸びしてしまうような感覚があった。ベロシティが低いときの不安とかプランニングでアイテムを積んでいくときの根拠ない自信とか。そういう気持ちの大部分は期待しすぎていたのかなーと腑に落ちたりした。
そういう期待もあってか、全体としての未着手領域を減らすとか色んなことを並行で進めるとかいうことに意識が向いていてぜんぜん一本道じゃないな、と実感できた。休み明けはこの辺の整理からちゃんとやっていく。
また、@bufferingさんはオンライン上で見知っていたのだけど一度も話せていなかったものの、RSGT2019でようやくお会いすることができて良かった!! @ama_ch さんも交えた立ち話からも高密度で得るものがあった。
ファシリテーションの難しさと楽しさ - Speaker Deck
業務でよくファシリテーションするんだけど、誰から学んだわけでも深く掘り下げたわけでもないのでとても気になっていた内容。わりと自分がファシリテーション下手ー特に喋りすぎるという点においてーだという"現実"が見えたので良かった。
そのときサーバントリーダーはどう振る舞うか - Speaker Deck
Engineering Manager Meetupでも熱くなれそうな話題。3日目にはRochelle Koppさん、Kinugawaさんと同じテーブルでディスカッション出来たのも良かった。
サーバントリーダーの話、完全に #em_meetup で盛り上がる話題だ#RSGT2019
— 広島の粗大ゴミ (@ohbarye) 2019年1月10日
聞き手としては、全く実践したことがないもしくは上司が旧来型なので苦労しているみたいな層が中心だったのかもしれない。EM Meetupの参加者層だと、実践したうえでの発見や学び・悩みといった内容でもう一歩先の議論が始まりそうな気がした。
所感
ぜんぜん関わったことないコミュニティなのでいろいろ新鮮だった。イベントのそこかしこで会話が生まれていて、そういう"場"づくりができているのが凄いと感じた。（ふつう初対面の人どうしでそんなに話さなくないか？ってぐらい）
一方、Not for meかなと思った点も無くはなく… ビジネスモデルや会社の状況が自分とかなり遠い人もけっこう多く、問題意識や悩み事が（僕が話した限りでは）噛み合わないなと思うこともあった。（クライアントからの無茶ぶりとか、ぎすぎすして心理的安全性がゼロとか、スクラムをやらせてもらうための説得とか、上司が非技術者だとかトップダウンで最悪 etc. 自分はそういう問題に当事者としての真剣味がないので議論やアドバイスになりにくい）
だがやっぱりすごい知見に溢れ、自分の課題より遙か先を歩いている人々が集まっていたのも事実で、そこからは本当に真摯に学ばせてもらった。
