鯨飲馬食

いろいろつまみ食いで勉強したことのメモ書き

RSGT2019に参加した

f:id:yoichi22:20190115013153j:plain

2019/01/09〜11に開催された Regional Scrum Gathering Tokyo に初参加しました。最高に楽しかったので感じたことを書きます。

巻き込む力

3日間を通して、参加者全員を巻き込んでみんなで作り上げていくという雰囲気と仕組みの存在を感じました。

  • しょっぱなのキーノートの一部にワークショップ成分が盛り込まれていた。
  • お弁当もらってふらふらしていると洋さんが輪に入りますかと言ってくれて futabooo さんと話せた。
  • セッションの合間に部屋の外に出るとFun/Done/Learnのボードがありその前に黄色い人(viva_tweet_xさん)が居て、勢いで声をかけた。
  • だんだん遠慮がなくなってきて、ネットワーキングできょんさん、あまのさんを捕まえて質問した。
  • 講演会場の外でもセッションが開かれていて、ふらっと立ち寄って聞くことができた。
  • OSTでは場に集まった人の課題や疑問を持ち寄って話が進んでいき、自分も発言できた。

みんながわいわいがやがやしてて熱気が溢れていて、人見知りで知らない人と喋るの苦手な私でも最初の一歩を超えてしまえばいろんな人とお話をして貴重な機会を活用できました。参加する前に #RSGT2019 の歩き方 - うさぎ組 を何度も読んでたのもよかったと思います。

深く問い続けることの大切さ

何をやるか、どうやるか、の両方について深く問い続けることについて、

  • Gabrielle Benefieldさんのセッションで、正しい問題を見つけるために仮説検証を繰り返すという話があったり
  • きょんさんのセッションで、超個体の美しさを目指して試行錯誤を繰り返した先に何かを見つけたという話があったり
  • クリスさんのセッションで、やり方を変えたら計測してきちんとふりかえるという話があったり
  • OSTで話をしてるとき、横から有野さんの鋭いコメントが入って、自分への問いを止めてしまいそうになってしまっていた自分に気づいたり

と、深く問い続けること、しっかり考えることの大切さを改めて気付くことができました。

そしておよべさんと楽天の新卒研修メンバーのセッションで、何をやるか、どうやるかの両面の試行錯誤をしていい形に短期間で到達したという話を聞いてすごく刺激を受けました。自分のところで早いサイクルを回していくのにどうしたらいいかしっかり考えていきたいと思います。

この熱が冷めないように

刺激を受けて終わりじゃなく、もらったヒントを種に現場で何かを実践して、来年はその結果を持って参加できたらいいなと思いました。素晴らしい場を提供して下さったオーガナイザー、参加者の皆さんありがとうございます!

手を動かす会をたくさんして学んだこと

2018年は、手を動かす会に参加したり、開催したりをたくさんしてたのでふりかえります。

OSS Gateワークショップ社内版

oss-gate.github.io

OSS Gateワークショップは、それまでOSS開発に参加したことのなかった人をターゲットとして、おすすめのやり方に沿って進めることで、数時間のワークショップでOSS開発への参加を実際に体験できる会です。オープンに参加者を募集してのワークショップが大阪でも定期的に開催されていて、何度か参加してとてもよい体験ができたので、社内の仲間たちにもぜひ体験してもらいたいと思い、社内で参加者を募って開催しました。

  • 1回目: 2018-01-15, 2018-01-31
  • 2回目: 2018-05-28, 2018-05-29
  • 3回目: 2018-10-01

メンバーを変えつつ3回やりました。 やっていてものすごく嬉しかったのは2回目にビギナーとして参加してくれた2人が、その次の3回目でサポーターとして参加してくれたこと。

ビギナーとして参加した人もそれを受けて「私も、次のビギナーの方に自信をもって貰えるようにサポートしたいなと思いました。」と書いてくれていて、よい体験をして、次の人にバトンを渡していくというのができているのがすごい。

tech-blog.monotaro.com

TDD Boot Camp 社内版

TDD Boot Camp 社内版もやりました。簡単な課題をペアで解き、テスト駆動開発を体験するワークショップです。 サポーターとして参加して、手を動かしているところを眺めてたのですが、それぞれのペアの動きを見て学びがありました。

こちらも2回目が年末に開かれていて、継続的な取り組みになりそうです。

GDCR2018

前から参加したいなーと思ってた Global Day of Coderetreat に参加することができました。こちらはライフゲームペアプロで作っては捨て、作っては捨てをひたすら繰り返す一日がかりのワークショップです。へとへとになりましたが楽しくて仕方がなかった!

tech-blog.monotaro.com

システム運用訓練

おしごとの話になりますが、運用しているシステムの障害対応をスムーズに行うための訓練を何度かやりました。年末最終週にもやってました。 障害が起きたという想定で、実際に手を動かしてもらいながら、どういうところに気を付けて進めるかということを伝えました。手順の属人性を下げることができ、業務時間外の障害対応を持ち回りでやっていることに対しても安心感を上げることができました。

このことの直接の影響かどうかはわからないですが、開発者向けのツールを作ったときなど、それまでは「こんなの作りましたー」と共有するくらいだったのが、ハンズオンをして実際に使うところまでフォローする取り組みを、チームメンバーが自発的にやってくれたりと、チーム内で気軽に手を動かす会が行われるようになっています。

車輪を再発明する会

年末のおしごと最終日に少し時間があったので、リストの長さを求める関数を実装するという課題をもくもく解く会をしました。 普段使っている標準の len() 関数と自分で実装したものを比較してもらい、何が違うのか考えてもらいました。いろいろ発見して楽しんでもらえたようです。

qiita.com

学んだこと

手を動かす会を開催したり、参加者として手を動かしたりという体験をたくさんしました。

よく参加するDevLove関西勉強会では申込みの際に自分の課題を書く欄があります。私がいつも書いてるのは「ソフトウェア開発の楽しさをまわりに伝える、拡げる」です。この「楽しさを伝える」のは言葉で伝えていくのも大事ですが、実際に手を動かして体験してもらうことで伝えていくという手もあるということを実感した一年でした。来年もソフトウェア開発の楽しさをまわりに伝え、拡げていこう。

2018年のDevLove関西と私

年も末なのでいろいろふりかえっていますが、その中でDevLove関西で今年たくさんお世話になったことを思い出したので書きます。

2018年はDevLove関西の勉強会は14回参加してました。

途中、勉強会行き過ぎで消化不良になっているかもしれないと感じて参加を控えようと上司との1on1で話してた記憶がありますが、結局開催27回中の14回なので過半数参加してましたね。

カイゼン・ジャーニー著者のお二人との出会い

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

DevLove関西がきっかけで出会ったカイゼン・ジャーニー著者のお二人からは相当な影響を受けました。市谷さんの話を聞き、カイゼン・ジャーニーを読み、新井さんの話を聞き、ジョイ・インクを読みと、話を聞いて刺激を受ける→それをきっかけで知った本を読む→現場でまわりを巻き込み前進するためのヒントを探す、考える→現場で実際にやってみる→本を読み返しつつ悩む…といったところで、東京出張のついでにエウレカさんで開催されたイベントにもお邪魔させていただいて、新井さんや、あとたまたま参加してた元同僚に相談してまたヒントをもらって現場に持ち帰ってやってみるといったことをしてました。

eure.connpass.com

カイゼン・ジャーニー自体も非常に身近に感じられる内容の本ですが、著者のお二人も身近に感じることができ、たくさん勇気とヒントをもらいました!

聞くだけじゃない参加

DevLove関西は素振りの場なので、その場で質問したり、話を聞いた後に参加された他の人と話をしたり、感じたことをTwitterやブログに書いたりして、学んだ内容を自分の中で消化し血肉とするための行動を心がけています。そういったことに加えて今年は新たに、登壇1回(2018-08-27)、企画1回(2018-12-17)、会場提供2回(2018-08-25, 2018-10-22)をしました。いずれも自分の学びにプラスに働いたので来年もやりたいと思ってます。

今年もDevLove関西にとてもお世話になりました。忘年会でいろいろ忘れてしまう前に、yohhatu さんや、参加された方々に感謝です!

f:id:yoichi22:20181224005752p:plain

Team Geek を読み直した

先日 DevLove の勉強会「あなたが読んだ本は、きっと俺も読みたい。」に参加した*1

devlove.doorkeeper.jp

そこで紹介されていた本の中の一つに Team Geek があり、最近チームづくりに興味持っていろいろ取り組んでいるので、改めて読み直してみようと思った。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

本は発売当時に一度読んでその後は本棚に眠っていた。2013年当時は前職でやや大きめのチームを見てて、自分が技術的な詳細を知らないことをやってるサブチームも見てたので、チームづくりでいろいろ悩んでいたのだろう。そのころから現在までのいろんなことを思い返しながら読み直して、興味深い内容をたくさん見つけることができた。

読み返して印象に残った言葉たち:

  • 1.7.4 「影響を受けやすくなれば、それだけ影響を与えやすくなる。弱いところを見せれば、それだけ強い人だと思われる。」
  • 3.2.1 「伝統的なマネージャーはどうやって仕事を完了させるかを考える。リーダーは何ができるかを考える……(どうやって仕事を完了させるかはチームに考えてもらう)」
  • 3.5.2 「エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決をするのを手伝ってほしいからだ。そのためには、彼に質問をすればいい。」
  • 5.4.1 (許可を求めるより寛容を求める方が簡単)「勝てる見込みのある重要な争いを選択しよう。勝てない争いで資本を使い果たしても意味がない。」
  • 6.2.6 「コードを書く側の都合ではなく、ユーザーに集中しよう。コードを書くのが大変になったとしても、愚痴を言わずにやるべきだ。」

心にしっかり留めて行動に活かしていく!

*1:Zoomでリモート参加できるようにしてくれていて、遠隔地からも参加できるのでありがたい

アウトカムを得てから深掘りするやり方

i2keyさんのブログ記事(「再発防止策はチェックリストによる目視確認」から考えるアウトカムフォーカス)を読んだ。

i2key.hateblo.jp

実利をリードタイム最短で取っていき、その後で効率化していくという話を示した図を見て、t_wadaさんのTDDの資料に出てくる黄金の回転の図

との共通点に気付いた。手段にこだわらずにとにかく動く(効果が測れる)ところまで持って行き、最適化する次のステップは価値が見えたそのあとでというあたりが。ポイントは1ステップ目をまず素早くやってしまうというところだと思うが、最適化の原則としてぎりぎりまで最適化するなということに関連して、動くものを手に入れてしっかりと対象の理解を深め、その後で最適化することでより最適な形に持っていけるという2ステップ目の成果へのメリットもあるなと思った。

実際の現場では、「動いて価値が出たんだからいいじゃん、そのままにしといて別のことやろうよ」という圧がかかってきて、2ステップ目に進めないことがありがち。1ステップ目においては動機が客観的に見てもはっきりしているのに対して、2ステップ目はそれを何故やらなければならないのか、現場の人が自信を持って説明でき、その価値を周りが認めてくれないことには切り崩されてしまうから。

自動化されたフローによる障害防止の再現性や、きれいなコードによるメンテナンスの継続性といった、もう一段上の価値を根拠として、2ステップ目をきちんと進めていける、あるいは1ステップ目を素早くやってみた結果それ以上やる価値はないからやめとこうと自律的に判断していけると良いなと思う。

まず成果を出すというゴールから始めるやり方では、こないだ会社ブログで書いた、新しい人をチームに迎え入れるときに、まずチームの一員としてアウトプットしている状態という成果を体験してもらってから、次のステップで基礎力を高めるという流れにした話とかも、類似点がありそうだ。

tech-blog.monotaro.com

OSS開発を楽しく続けてきた話を喋ってきた

DevLove関西の勉強会で、OSSへの貢献というアウトプットを継続してきた話を喋ってきました。

devlove-kansai.doorkeeper.jp

タイトルは「OSS開発を細長く続けてきた話」改め「OSS開発を楽しく続けてきた話」。

speakerdeck.com

前半では、プログラムを書けなかった中で、見よう見まねで FreeBSD ports への貢献を始めたこと、興味をもった対象について、自分に出来ることで貢献しながら学び、徐々にできることを増やしていったことを話しました。後半は仕事の中でOSS開発で学んだことをアウトプットして、業務時間でOSS開発もさせてもらえるようになった話、OSS Gateでまわりの人をOSS開発に誘っている話をしました。

緊張でろれつ回ってなかったし時間いっぱいまで使ってしまったしでさっさと降壇しようとしてたら呼び止められて、ありがたいことに質問をいくつも投げかけてもらえました。

  • コミッターになった話のあとにコード書けるようになった話があったけど、プログラミングできない状態でコミッターになれたの?
    • 本当にそうでした。Makefile書くと言っても変数の定義をいくつかするくらいなので、できちゃいました。貢献をするようになってから、ビルドエラーになったときにC言語コンパイルエラーの読み方とか学んでいったという順番でした。
    • 最初見よう見まねでできちゃって、成果をみんなに使ってもらえて嬉しい!という経験ができたのはラッキーだったと思いますが、先にアウトプットしちゃって、後追いで学んでいくというやり方もありかなと。
  • OSS Gateワークショップは何人くらい集まるの?
    • OSSの開発をしたことがない人と、経験者が同じ人数、例えば3人対3人とか5人対5人とかで参加して、ペアで作業をします。
    • 経験者と言っても、ビギナーに寄り添って一緒に考えるので、ビギナーとして参加した人が次はサポーターとして参加したり。
  • OSS開発をしていて一番嬉しかったことは?
    • うーん何だろう。
    • Emacsというエディタを気に入ってずっと使っていますが、それを開発したリチャード・ストールマンにパッチを受け入れてもらったときはめっちゃ嬉しかった。ほんの小さなパッチですが。
  • どれくらいの時間をOSS開発に使ってる?
    • 学生のころは、研究そっちのけでやっていたこともあった。学業が本職なので本当はよくない。
    • 仕事でやるようになって本業としてやるようになって本当に良かった。遊んでるわけじゃないのでお給料もらえるし。
    • その場では仕事の中での割合を答えるのを忘れていたけど、特に区別して時間をとってないので、必要に応じてというのが答え。製品開発や障害調査のクリティカルパスに乗っているならずっとOSSデバッグをしてる日もあるし、全くやってない時期もある。
    • 仕事では回避して過ごしたけど面白いなと思うOSSの不具合については、おすそ分けしてもらう感じでプライベートで解決しちゃうことも時々あります。趣味なので仕事の持ち帰りではない(気が向かなくなったらやらなくてもいい)という気持ちでやってます。

後藤さんのお話

後藤さんからは、コミュニティイベントの開催や登壇というアウトプットのお話がありました。

継続的に同じイベントに参加して周りと喋ることで、次までに自分がアップデートされていかないとコミュニケーションのネタがなくなるという形で、自分を駆り立てているという話があり、参考にして自分もやってみようと思いました。ネタ作りを意識することで日々のインプット、アウトプットが促進される。「来月どう変わっていられたら素敵か?」という問いかけもよいなと思いました!

ダイアログ

4人くらいのチームに分かれて、私のまわりでは勉強会についての話をしました。テーマをかっちり決めずに集まって、付箋にそれぞれの話したいことを書きそれぞれが書いたことを出してそれについてみんなで議論する形式は、やってみたことないので今度やってみようかな。

別のチームでは、Qiitaやブログの下書きが溜まってる話が出てたという話があったようです。自分向けメモ書きとして自分に役立てばいいやと公開してしまうようには心がけているものの、それでも供養しないといけないものがちょっとずつ溜まってしまってる…。もっと気軽に書いていこう。

越境しようとしている者達の話

devlove-kansai.doorkeeper.jp

これは聞かねばという話が並んでいたので申し込んでいたら、中村さんから「御社で会場提供できませんか」と声をかけていただき、弊社オフィスで開催。周りの人も連れて行って一緒に刺激受けてこようと、数人誘って参加しました。

"越境”の正体とはなにか? / 中村さん

  • 越境とは
  • 前提、制約を気にせず、あらゆる活動をすること
  • 目的に忠誠を誓う

私が見つけた境界線 / 橋詰さん

  • ここが境界線かも、「この先に何かありそう」と感じた
    • 既視感
    • ちょっと難しい
    • 経験者少ない
    • ちょっと面白い
  • それまでは、「技」(正しい技術、正しい開発)、「体」(正しい業務)
    • 境界線の向こうに「心」(定着化、現場へのケア)
    • あまりやっている人居ない
    • けど、既に境界の向こうにも何人か居る
      • 何か共通点がある人
      • 壁打ちさせてもらう
  • 人を相手にすることの難しさ
    • 15人くらいのチームでも難しい
    • そのあと何千人に広げないと
  • 進むには
    • 自分が折れない
    • 正しいことをする
    • 周りの意見を聞く
    • あわてない
      • 刺激と反応の間にスペースを取る
    • 前に進んでいることを確認しながら進む

私の「越境」航海図 / 神ノ倉さん

  • 若い頃、技術力が全て、組織ワーク?何それ?だった
  • 障害が起きている顧客の顧客のところに飛び込む
    • 駆けつけて全力で取り組めた
    • 会社の枠を越えた一体感が得られた
    • その後よい関係を築けた
    • 飛び込んだことについては一切怒られなかった
  • チームの話
    • どうありたいのか(to-be)をあげる、共有する
    • 日々の業務から学習できる仕組みを作る
    • タスクボード
      • 自分のDoingがたくさん
      • タスクの関係見えない
      • 人依存でタスク握ってる
    • タスクボードの改善
      • 案件ごとのレーン
      • Doingの数を制限
      • イデア試して改善の繰り返し
  • カイゼンジャーニー社内読書会
    • Zoomで複数拠点繋いで実施
    • やったあとそれぞれの気づきを共有
      • 学びの活け〆
    • 今日の発表した事も、社内の宣伝に使う→広げる
  • Trust, but Verify
    • 信頼する
    • フォローちゃんとしますよと表明

怖くない越境 - 小心者でも越境マンになれた理由 - (改) / 福本さん

  • エンジニアは修正理由全部覚えなきゃいけないと思ってた。
  • 別チームのお手伝いで GitHub, Git, アジャイルと出会う
    • 修正理由覚えなくていいんだ!
    • メインのチームにも導入したい
  • 「現状を疑う」は大切
  • 狭い範囲から、少しずつ広める
  • 新人研修やっていたら、突然の総務。
    • 2年くらい居た
    • 無邪気に五歳児の空気で問いかけ
    • 「なんでそうしてるんですか?」
  • つらいのを何とかしたい + きっかけをくれる人の存在
    • きっかけをひろう
  • やらない理由
    • 失敗したら…
    • 思考の停止
    • やってもやらなくても給料変わらないし
      • 会社の中だけ見てること自体リスク
  • 現状維持バイアス、損失回避性
    • そういうものだから、しょうがない
    • そういうこともあるよね
    • 状況がそうさせてるだけ
  • 人生は短い
  • おもむろに Evernote に価値観を書き出す
    • 自分に問いを投げる
    • 人に聞いてもらうのもおすすめ
  • 誰にでもできる、今からできる
    • きっかけを拾う
    • 時には見切りをつける

ダイアログ

みんなが出したいろんな境界からいくつかピックアップして、それを乗り越えるにはどうしたらいいかをみんなで考えました。

感想

私は話を聞くのに夢中になりすぎて会場係のことすっかり忘れてしまっていたので、他の人連れて行って正解でした。刺激たくさんもらいました!