鯨飲馬食

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

越境し、現場を前進させるための人の巻き込み方

devlove-kansai.doorkeeper.jp

巻き込み方の勉強会に行ってきました。最初の中村さんのセッションでは、書籍 Fearless Change

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

で紹介されているパターンからいくつかピックアップして紹介があり、一番気になったのは「適切な時期(23)」でした。巻き込もうとしてる相手が、今それを受け入れられるのか、水がいっぱいであふれそうな状態じゃないかを考えて、時には引くことも大事という話でした。Fearless Changeは昨年末に見返していたのだけど、その時はこの項目は全然気になってなかったけど、年初から新しい(元居た)チームに入って仕事をしている中で感じていたこととの関係で今回は心にひっかかったんだと思う。「ガッツとパッション」についての話題で出た、折れないように、0にならないように気をつけよう、焚き火があるうちに。という言葉も印象に残りました。

speakerdeck.com

市谷さんのセッションでは最初に出た「巻き込まなくてもいいんだよ」というタイトルから、どういう話なんだろうと引き込まれて聞いていたのですが、速く遠くへ行きたいなら、まずはできるだけ速く1人でも進む、そして周回遅れだとしても、2周目3周目で誰かと出会えたならばもっと遠くへ行けるという話があり、中村さんのセッションで感じていた疑問、「適切な時期じゃなかったとき、どうしたらいいのか?」への一つの解かなと思いました。あと気になったのは「Give and Give - できることは全て引き受ける」で、これは一緒に取り組みを進めてる相棒が実際やってることだなと思いながら聞きました。Why が自分のものならできるはずとも言われていたので、僕も遠慮せず引き受けていこうと思いました。

www.slideshare.net

最後の金さんのセッションは社内コミュニティについてのお話でしたが、勉強会とかだと単発になってしまったり途中で立ち消えてしまったりするけど、継続性を重視して、いつも集まれる場所、業務が忙しくて一度離れてしまったとしてもいつでも戻って来れる場所があるということを目指すという話があり、そういう場をつくるのもよさそうだと感じました。

いろいろ心に触れるお話が聞けた勉強会で、参加してよかったです。

2017年ふりかえり

初っ端の1月に早速インフルエンザで出勤停止になるという雲行きの怪しい始まり方をした2017年でしたが、カレンダーを見返してみると新しい出会いがたくさんあった一年でした。

2月には OSS Gate大阪ワークショップ2017-02-25 - OSS Gate | Doorkeeper に参加して、新しい人がOSSへの貢献をするお手伝いを始めました。自分のプログラマーとしてのキャリアはOSSとの関わりがなければ始まらなかったし、楽しく今も続けられているのはOSSとの関わりのおかげと思っているので、新しく興味を持った人の背中を押して、一緒に歩く人を増やせたらいいなと思って活動しています。来年はモデレータにも挑戦します。

5月には モブプログラミングをやってみる - DevLOVE関西 | Doorkeeper で何度か耳にして興味を持っていたモブプログラミングを体験しました。現場ではモブプログラミングはやってないですが、新しいチームを立ち上げ、人が少しずつ増えてくる中で、個人個人がモニタの方向いて閉じこもってしまわないように気をつけて、わいわいがやがや喋りながら期待をすり合わせたり困りごとを一緒に解決したりという取り組みができたのは、この勉強会で得た学びが影響してると思います。

7月には TDDBC大阪4.0 2017年7月1日(大阪府) - こくちーずプロ(告知'sプロ) に参加しました。前の回に都合が合わずに参加できなくてその後開催がなくてずーっと待ってたので、わくわくしながら参加して、存分に楽しみました。自分の現場では開発をすすめるためにテストコードを書く文化があまりなかったところに、頑張って部分的にテストを書いて、局所的には効果は得られていたものの継続的にテストを増やしていけてなくて悩み、くじけかけていたのですが、この一日で Red, Green, Refactorとリズムよく開発することの効果をしっかりと体験できました。そしてテストは書くべきなので進めていこう、でもそれが目的ではないということを心してかかろうという気持ちになりました。その後新しいライブラリを書く機会があったのでテスト駆動でやってみて、実際に心地よいリズムで実装でき、またその後の改修でもテストの恩恵を得られています。今年は小さなチーム内の新規コードではテストがあるの当たり前という状況に出来たので、来年はチーム外にもその文化を広げます。

9月は、PyCON JP 2017 にモノタロウ侍を引き連れて参加しました。会社としてはここ数年参加していたのですが、自分が現地入りするのは今回始めてで、たくさんの人との出会いがあり、またいろいろ課題も持ち帰って来たので、得るものの多い2日間でした。PyConJPへの来年の参加は未定ですが、持ち帰った課題への対処になるかもしれないことをいくつか考えているので、来年はチャレンジします。

2017年はOSSとの関わりが再び強まった一年だった気がします。apispec の開発者に入れてもらったり、HacktoberfestクリアしてTシャツもらったりと表に見える成果も少しだけ出せました。はじめの一歩を再び踏み出せたので、OSSを使い倒して業務を素早く前にすすめる、そのためにOSSへの貢献も積極的にするという姿勢を来年も継続します。

2017年は人見知りという自分の弱点を何とかしようと社外の勉強会で頑張って人と話をするように心がけてました。たくさんの人と話ができ、刺激をもらえたのは自分にとって良かったのですが、もらってばかりだった気がするので、来年は自分から出会う人に何か提供できるようにしたいです。

【スクラムナイト#9】心理的安全性ってなに?それって美味しいの?

スクラム道関西の勉強会にたぶん初めて参加しました。

scrumdo-kansai.connpass.com

参加動機

少し前に心理的安全性をテーマとしたDevLove関西の勉強会があり、そのときは上司との関わり方を考えながら参加したのですが、今回はチームの他のメンバとの関わり方について考え直してみたいなと思い参加しました。

  • 半年前くらいに複数のチームからシニアエンジニアを引っこ抜いて集めたチームのメンバとして働いている
  • 大人なメンバが集まっているためか、相手のやり方が自分のやり方と違っていても、自分の意見を言うのを控えてしまっていることがある
  • その一方で時には、コーディングスタイルについて議論が白熱して、議論の内容知らない周りの人から見ると口論してるみたいになってることがある
  • 相談すれば早く進みそうなタスクを誰かが抱えてしまっていることがある。いろいろ聞きにくい雰囲気を出してしまっているのかも

もっとそれぞれが自分をさらけ出してお互いのことを知り合えば、それぞれの力を引き出して生産性を高める方法を考えられるようになるのではと思い、行動を振り返って少しずつ補正していってるのですが、やっていることが良いことなのか自信がなく、他の人はどういう行動をしているのか知りたいと思いつつ今回の勉強会に望みました。

森田さんのお話

最初に、心理的安全性を高めることは銀の弾丸ではないと告げられました。それで全てが解決するわけではなく、またそれを目的としてしまってはいけないという警笛と捉えました。

社員全員をChatWorkの一つの部屋に入れた話を事例として紹介されたのですが、

  • 雑なことを発信できる
  • 誰に聞いたらよいかわからないことを聞ける

のために、最初は小さなチームでやってみて、それを複数のチームに広げて、その後でえいやと全員突っ込んだという話でした。

お話を聞いていて興味深かったのは、場を広げていく間、

  • 質問出てるときに、自分で答えてしまうのではなく、知ってそうな人のところに行って答えてくれたらいいなと促す
  • あの人の発言はルール違反なんじゃないのという不満をきちんと聞いて、でもまずは受け流して何もせず、自然に問題が消えるのを見守る

といったオフラインでのフォローをしつつ、自分は表では積極的に動いているように見せずに、みんなが自発的に動いて場が回っていくよう誘導して行くのは上手いなと感じました。

ワーク

後半は立場が違う人がグループになるように分かれてワークをしました。心理的安全性がないできごとを付箋に書き出し、それぞれについて何でそういうことになるのか、どうしたら解決できるのかを話し合いました。

  • バカにされそうなのでアイデアが言えない→大丈夫と思ってもらえるように自分があえてバカなことを言ってみる
  • なかなか自分から言い出せなくて抱え込む→逆にこちらから話しかける、聞いてあげる
  • 一部では心理的安全性が上がっているが全体に広まっていかない→心理的安全性が上がったことを何かしらの形にする。MTGで発表するとか

対策として出てきた内容は自分がちょっとずつ試みていることと大きく外れてはいなかったので、少しほっとしました。ただし、人によって性質が違うので同じことをやっても良く効く場合と全く逆効果な場合があるので、様子を見ながら取り組み続けていこうと思いました。

クロージングでは、心理的安全性を高めた場を作り上げたとしてもそれによって暗黙知が増え、次に新しい人が入ってきたときには疎外感などの別の問題が出るのでゴールはないという話があり、確かにそうだなと思いました。またそれとは別の視点で、心理的安全性を高めることはそれ自体が目的ではなく、心理的安全性を高めたチームで何を一緒に成し遂げたいのかが大事だということを改めて感じたので、その意識も行動に反映していけたらなと思います。

「心理的安全性」のことに思いを馳せてみる

先日参加した勉強会の記録です。

devlove-kansai.doorkeeper.jp

予習

異動してまだ日が浅く、新しいチーム、新しい上司とまだ互いの出方を伺っている状況があり、思うことを自由に言い合える状態にしていくには何が必要かを考えたいという動機で参加しました。

参加する前に、異動前のチーム、上司との関わり方を思い出しつつ心理的安全性とは何だろうというのを自分なりに考えてみて、

  • 何かしら共通の思いや目的があることを互いに認識していること
  • それぞれが共通でない思いや目的を持つことを互いに認識していること

がベースにあり、

  • 相手は違う風に考えるだろうなということでも遠慮なく言える雰囲気
  • 異なる意見でもはなから否定するのではなくしっかりと聞いてもらえる雰囲気

が存在している場では、リスクがあることも安心して(もし失敗したとしてもリスクを取ったことを責められたりはしないという認識をもって)取り組めるというようなことかなと思いつつ勉強会に臨みました。

セッション1

speakerdeck.com

およべさんのセッションでは「チームのゴール (×1) と個人が働くモチベーション (×n)は対立するもの?」という問いかけから始まり、

  • チームについて考える場がない→知らない→不安
  • チームのことを一緒に考えながら「言える化」していく
  • 個人が考える失敗について考える。実はチームとしては失敗じゃないことが多い。
  • うまくいかないときは人ではなく仕組みを疑う
  • 時間かかる。繰り返すしかない
  • 馴れ合いではなく、戦友。必要なストレスに一緒にさらされる。
  • チーム、組織についてもっと話そう

と、時間をかけてじっくりと互いの考えを知っていくことで心理的安全性を高められるという希望をもらいました。

あと、チームと上司の関係についても、わからないから不安になる。あとで報告でなくあえて先に相談することで一緒に勧めてる感を出すとよいとか、(心の中で)上から見る、余裕を持ってどうしたらよいか考えるという話があり、まさに自分と上司との間もそうなんだろうなーと思いました。このやり方は上司に限らずチームにガッツリは入ってない周辺の関係者との間でも使えそう。

セッション2

やんさんのセッションでは、3つのチームでの生々しい話がありました。

  • 1つ目の話では、開発と企画からなるチームで、開発はサバイバルモードから抜けたという認識に対し、サバイバルモードに居る企画との間での摩擦から破壊が起き、ファシリとして入ってそもそもの目的から認識を合わせていった
  • 2つ目の話では、エースを集めてきたチームで、強制的に協働させ、手分けして早く終わることを一緒に体験したり、モブプロを2日やってみたら会話が増えていったこと
  • 3つ目の話では、国内のメンバとオフショアのメンバからなるチームで、弾丸出張でバリューストリームマッピング、One Teamという認識に持っていったがまだ完全解決せず、継続して大事にしている価値を共有したりとして良くなっていったこと

いずれも、同じ目的に向かっている認識を合わせること、一緒に仕事をすすめる上での各個人が大事にしている価値のすり合わせを、あきらめずに繰り返し繰り返し続けていくことが効くんだなという印象を受けました。

あとで、何だかんだでいいチームだということを言い忘れてたとtweetされてましたが、やんさんの熱のこもった楽しそうな話し口からそれはひしひしと伝わってきてましたよ。

後日談

DevLoveは素振りの場、現場は実践の場、ということで会社行ったら上司にいい話聞いてきたよという話をさっそくぶつけてみようと思って帰りました。 ブログ書いて自分なりにまとめてからと思っていたのに、上司と顔を合わせたときにまだまとめきれてなくて、待ちきれずに話をしてしまいまとまりのない話をしてしまいました。気のせいかもしれないけど少し上司との距離が縮んだ気がするのでまぁいっか。

TDD Boot Camp Osaka 4.0 で boot されてきた

www.kokuchpro.com

参加動機

  • 職場で若い人とペアプロでテスト駆動で開発してみたことがある
  • 短期間で機能を完成させてリリースし、有効性が見れた
  • でもその後、自分も他のメンバもペアプロテスト駆動開発を実践することがなかった

有効性が見れたのに何故継続できなかったのかは気になっていて

  • 最初の単体テストコードを書くのが難しいから他の案件でできなかった? (やれたときは、最初に作るときに単体テストを書いていた部分の機能追加だった)
  • テスト駆動開発のやりかたがよくなくてまたやろうと思わせられなかった?

という疑問は持ちつつも次の一手を打つこと無く時間が過ぎていた。 今回、テスト駆動開発がどう美味しいのか考え直したいと思いTDDBCに参加しました。

学んだこと

午前中は講演とデモがあり、午後はペアでひたすらRed、Green、Refactorのサイクルを回しました。ほとんど使ったことがなかった言語 (Ruby) で書いたので最初は手間取ったものの、徐々にペースを掴んでいって最後はもっとやりたいと思いつつも時間終了でした。

講演とデモの解説の中で irof さんから

  • 不安をテストにする
  • 不安がないところはテストを書かなくてよい
  • まずassertionを書くことでゴールが明確になる
  • 一歩一歩踏みしめたいとき以外は、こう書けばいいとわかっているなら一息で書いてしまえばよい
  • TDDのテストは開発のためのテストであり、品質を保証するためのテストはまた別
  • 開発が主役。テストが主役ではない

という話があり、動く(価値のある)きれいなコードを素早く開発するための手段としてのTDDであり、テストをたくさん書くことが目的ではないということは肝に銘じておかねばと思いました。

懇親会では原田騎郎さんから、サボるためにTDDをやるんだ、とプログラマの三大美徳の一つである怠惰に絡めた教えをいただきました。楽できるところは楽をするために頑張って、プロダクトの本質に集中して価値を届けていきたいです。

boot された?

オープニングの話で、TDD boot campに受講者として何度も参加すると boot されてないということになって主催者が叱られるという話がありました。素振りはしっかりできたので、ここで満足して終わりにするのではなく現場での実践を試みていきたいです。次回はTAなりで協力できればと思います。

講師・サポートスタッフの方々、会場提供いただいたファーストサーバさん、お菓子差し入れをいただいた皆様ありがとうございました。

(追記)後日、一緒に参加していた同僚と、職場のエンジニアに向けて学んできたことの共有をしました:

Cookpad Tech Kitchen #8 に行ってきた

cookpad.connpass.com

非同期ジョブと仲良くする / 小林 秀和さん

非同期ジョブと仲良くする // Speaker Deck

  • barbeque (https://github.com/cookpad/barbeque) の話
  • Docker ベースのジョブキューシステム
  • アプリ(マスター)とワーカーは同じDockerイメージから起動(起動時引数が違うだけ)
  • Hako (Dockerコンテナ管理ツール) を利用してる
  • キューは SQS なので、AWS におまかせ
    • cf. sidekiq + redis を増やしたら、スケールするように redis cluster の面倒見が必要
  • アプリからの実行は ActiveJob 準拠なので barbeque 特有のコード書かなくてよい
  • 開発用にローカルでの実行もできる
  • AWS SNS 契機でのジョブ実行もできる
  • アプリのデプロイはなく、ビルドした Docker イメージを上げればよい。

AWSのサービスやHakoと連携してそれらの機能をうまく活用することで、非常にシンプルな構成で、スケールする仕組みを実現できているのがよいなと感じました。

kuroko2の近況とクックパッドのバッチ周りの概況 / 大石 英介さん

kuroko2の近況とクックパッドのバッチ周りの概況 // Speaker Deck

  • kuroko2 (https://github.com/cookpad/kuroko2)の話
  • 高井さんのスカンクワークで開発され、社内導入
  • 大石さんがメンテを引き継ぐ
  • 元々OSS化の予定はなかったが、2016/10 OSS化、諸般の事情によりサイレントリリース
  • 現実的な運用を見すえた設計方針。
  • カスタムタスクによる拡張性
    • kuroko2 本体に手を入れなくてもドメインに合わせたタスクを作れる
  • バッチまわりの近況
    • 社内では OSS のkuroko2 のmaster のヘッドを使ってる
    • 700個のバッチジョブ
    • 一日あたり6000実行
    • 230 worker
    • 監視用のAPIをたたいて監視 (zabbix)
    • capistrano でデプロイ. worker は HUPシグナルでgraceful shutdown
    • ほぼすべてのジョブを1つのkuroko2アプリで管理

バッチ実行基盤なのでその上で個々のバッチが確実に実行され、それぞれの価値を生むのを継続して支えつづけることに価値があり、安定的に運用できることに価値を置いて技術選択、設計をされたという点が一番印象に残りました。自分も開発対象のそれぞれの特性によって何に重点を置くべきかはしっかり考えて行きたいと思いました。

美しいバッチの壊し方 / 青木 峰郎さん

Cookpad TechKitchen #8: Breaking BatchJobs Beautifully // Speaker Deck

  • ジョブ数が多くフローが複雑。とはいえ1000ジョブ強なので小規模もいいとこ
  • Kuroko2 でスケジュール。中身をBricolage で実行してる。
  • Bricolage
    • SQLバッチ専用フレームワーク
    • 1ジョブ = 1SQL分の強固な思想に基く → よいバッチのために必要だから
  • 運用しやすいバッチはよいバッチ
    • 落ちたときに簡単に対処できる = 障害を直しやすい = 美しく壊れる
  • 美しく壊れるバッチの3つのポイント
    • どこで壊れたかすぐわかる
    • 続きから実行できる (9割までいってたらせめて8割5分くらいから実行できる)
    • リトライで直せる (ちょこっと直してリトライ)
  • どうやったら美しく壊れる?
    • 処理をひたすら細かく分割し、小さい job を繋いで全体を構成する
      • Bricolage は 1SQLなので、もう分割できないところまで分割できてる。
    • I/O対象ごとにジョブ分割
      • 中間テーブルに書いたらそこで無条件に切る
    • ジョブ管理システムで結合
      • →今のところ Kuroko2 で繋いでる。
      • グラフで正常終了、実行中、落ちてるが見えて区別できるとよいなぁ… (Kuroko2への要望)
  • 羃等バッチの記述
    • いっこいっこがリトライ可能じゃないと意味がない
    • トランザクションなど。
    • 更新 (UPDATE) しない→あたらしいテーブルつくるか、DELETE&INSERTするか

どこで壊れたかすぐわかること、続きから実行できること、ちょこっと直してリトライで直せることというのはSQLにかぎらず一般的に大きなバッチをどう美しく(壊れた時に早く対処できるように)していくべきかの指針になると思うが、単位を1SQL文にするという明確なルールでそれを実現したというのは興味深かった。

懇親会

成田さんとヨシオリさんに、自前で作ってOSS化することに関して聞かせていただきました。最初から自分たちで作ることを考えるわけではなく、まずはその領域のありものをしっかり調査して、その結果はまるものがない場合に覚悟を決めて自分たちで作るという判断をしてること、一方で開発するときはOSS化することを前提に設計することで、業務依存な部分(OSS化しない)とそうでない基盤部分(OSS化する)をうまく分離していることなど、自分が最近悩んでいたことに対する他での取り組み方を聞けてとても参考になりました。

Agile Japan 2017 大阪サテライトに行ってきた

agilejapan-osaka.connpass.com

いろいろな方からたくさんの勇気をもらいました。参加してよかった。

Agile Japan 2017基調講演 “モダンアジャイル” / Joshua Kerievsky 氏

  • Agile Japan 2017本編のビデオが放映された。
  • 「パターン指向リファクタリング」の著者という紹介があり、読んだこと思い出しました。
  • Modern Agile
  • 古いやり方で本当にうまくいくのか?もっといい方法はないのか
    • 自転車の補助輪の例
    • 乗って漕げるようになっても、補助輪外したら怖がる。
    • バランスが重要
    • 補助輪なし、ペダル無しのバイクでバランス感覚を得ると、24hで自転車乗れるようになった。
      • 子供たちが乗って遊んでるあれの目的がそういうことだったのを知りませんでした。
  • make people awesome
    • 新幹線開発で、250km/hという very challenging な目標を設定
      • カーブがあるから→まっすぐにすればいいという発想
      • 9年でやりとげた (1955)
      • とてつもないことをやることで people を awesome に
    • いいプロダクトを作るのではなく、いいユーザーを作れ
  • Anzeneering
    • safety という単語はかっこよくないので日本語の「安全」を使った
    • 心理的安全性を前提とする
    • 安全は high performance にも繋がる
    • Fire Phone が売れなかったことに対する Jeff Bezos の言葉: “We’re working on much bigger failures right now”
    • たくさん失敗しても、成功して得るものが大きければ問題ない。
    • 素早く実験と学びを

会社の文化をアジャイルに変えたい?キミにもできるよ! / 新井 剛 氏

speakerdeck.com

  • ヴァル研究所での取り組みの紹介
  • 本気モードとのことではだしで登壇されていた
  • 問題解決ではなく共感を目的に
  • 社員向け社内見学ツアー
  • 隣に座っている取締役の話をみんなにも聞かせたい→宮本塾
  • ホーソン効果
    • 工場のあかりを明るくすると生産性あがった。一方で暗くしても生産性あがった
    • 自分たちでやってるとわかると生産性上がる
    • 内発的動機づけ
  • 会社見学ツアーをやってよかったこと
    • 良いことの後押しになる(あのすごい人がよいと言ってくれてる)
    • 広めてくれる
  • することから始める by 岡潔
  • 楽しい、好き

「楽しさ」に導かれたアジャイル開発 ~老舗メーカーでの実践~ / 久保 明氏

www.slideshare.net

  • 現場主導、コーチなし、経験なし
  • きっかけ
    • 仕事の行き詰まり
    • Project Facilitation の講演に来た平鍋さんの言葉
      • やってみてください。楽しいですから。
  • 朝会
    • 進捗確認ではなく、健康診断だと思ってる。
    • メンバーが悩んでないかな?怒ってないかな?
  • TDD
    • やることが増えた感じにしない
    • こだわらない
    • →動作確認のコードを残そう
  • 楽しみが伝搬
  • 繋がり
    • すごい人と繋がる
    • 48時間以内に連絡する。
  • 仲間の力を借りよう、そして、自分のまわりを楽しくしよう
  • 成長することは良いこと?
    • 裏にすると、成長しないことは悪いこと。辛い
    • 成長することは楽しいことだ
      • 裏にしても「成長しないことは楽しくないことだ」。乗り切れる。
  • 迷惑をかけよう
    • 無理して頑張ってると感謝できない
    • 迷惑かけて感謝しよう
      • ついうっかり迷惑かけてしまった感じで
  • 勇気
    • 高い塀の上の子供に大人のかける言葉:「大丈夫だよ」
      • 飛び降りたことあるから
      • 失敗しても大丈夫?
      • 最初、大丈夫と思って降りたわけじゃない
        • → 怖いままやってみよう