鯨飲馬食

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

OSS Gate 大阪ワークショップ 2018-03-10 に参加しました

OSS Gate 大阪ワークショップにモデレータ(進行役)として参加してきました。ものすごく楽しめました。参加されていたビギナー、サポーター、サポートメンターの皆さん、ありがとうございました。本町オープンソースラボ(株式会社SOU)さん、会場提供ありがとうございました。

oss-gate.doorkeeper.jp

感じたこと

  • 参加した5人のビギナー全員がOSSへのフィードバックできた!すごい。
  • やってみると意外とできるじゃんと感じてもらえてたら大成功。まだ不安があるけどひとりでやってみようと実際に体験増やすも良し、またワークショップに参加して、一緒にフィードバックの仕方を学ぶもよしです。
  • 僕が最初にOSSへの貢献をしたのはもう20年近く前だけど、こんなちょっとしたことフィードバックするだけでありがたがられるんだ、役に立てるんだと感じた記憶がある。ワークショップ参加をきっかけに、OSSへの貢献を楽しむ人が増えるといいな

進行について

  • ワークショップではモデレータは毎回違う人がやるようにしていて、実際やり始めるまでは少し不安あったけど、初めてなのに不思議と落ち着いてやれた気がする。
  • ワークショップの役割の定義がうまくできていたのがやりやすかった理由の一つと感じました。ビギナーに常に寄り添ってフォローするのはサポーターにお任せして、モデレータは進め方、期待値を伝えることに集中できました。
  • サポーターがこれまでもサポーターとして参加された人ばかりだったので、今回は具体的なやり方を前でデモするのを少し省略して、作業やふりかえりにかける時間を多めに取ってみました。

伝え忘れたこと

  • 今回はサポーターが経験者ばかりだったのでサポーターへの期待値の説明を端折ってしまったのですが、ビギナーに対してどうサポートしてくれるのかをビギナー自身も知った上で進める方が認識のギャップが生じないので、説明すべきだったなと思いました。
  • 実際にサポートを受けたビギナーは感じとってくれてたかもしれないけど、サポーターは答えを教えるのではなく、寄り添って一緒に悩んだり、他者の視点で感じたり疑問に思ったことを伝えることで、ビギナーが自身で前に進むのをサポートするという動きをしてくれていたはず。
  • そうしてるのは、今日はすごい人がとなりにいたから出来たじゃなく、実際に手を動かしてフィードバックを体験したのはビギナー自身だから、自信持って明日からもできると思ってもらいたいからです。やれそうという実感を持ってもらえてたら嬉しいです。

後で書こうと思っていたこと

  • ワークショップでは伝えきれないと思ったので後でどこかに書こうかなくらいに元々思っていたのですが、せっかく頑張ったフィードバックがリジェクトされることもあるので、そのときの受け止め方について。
  • 自分もそういう時凹むことあるけど、フィードバックしたという行動や人を否定されてることはまずなくて、内容が今回は受け入れられなかっただけととらえればよいと思います。
  • 時にはリジェクトしつつも行動への感謝を伝えてくれる開発者も多く居るし、もしリジェクトされたとしてもめげずにまたやってみて欲しいです。

自分の気付き

今回モデレータをやってみて、役割によってまた違った視座でまわりが見えるという体験ができたことが大きな収穫でした。仕事では基本的に手を動かしてものを作ったり運用したりという役割で居る時間が多いのですが、たまには手を止めて一歩引いて、マネージャだったらどう考えるだろうとその役割になった気持ちで考えてみたり、ファシリテータを実際にやってみたりしてまわりを見てみると新たな気付きがあるかもしれないなと思いました。

Nature Remoで遊んでみた

スマートリモコン Nature Remo を1月末に入手して、使わないまま放置していたのを、少し前から遊びはじめました。

セットアップ

届いたので早速 iPhone アプリを使ってセットアップしようとしたのですが、WiFiルーターを選択したあと、「Remoをタッチ!」の画面から進まない問題が出ました。

nature.global

の通りにやっても進まないので、サポートに問い合わせて何度かやりとりをした結果、WiFi パスワードを16進64桁にしてたのが制限事項に引っかかっているらしいとわかったのですが、パスワード変えると他の端末それぞれの設定をしなおして回らないといけないので面倒だなと思ってしばらく放置していました。

その後腰が重いまま日が過ぎていたのですが、奥さんが新しいタブレットを買ったのでセットアップしてーと言われて、端末増えたら余計に面倒になってくるのでついでにやってしまえと思いパスワード変更したら、Remo の設定も無事に成功するようになりました。

Amazon Echo連携

Echo Dot を持っているので連携させようとスキルを検索すると2つ出てきて、最初スマートホームスキルを有効にしたのですが、

av.watch.impress.co.jp

にあるようにテレビは電源オンオフしかできないとわかり、次にカスタムスキルを使って連携させました。カスタムスキルの方でも最初、電源のオンオフはできるのに、チャンネル変えたりができないので何でかなーと思ったところで

nature.global

を見つけて、「以下の通りボタンを設定していただく必要がございます(名称は、自由に登録していただいて構いません。追加で登録されているものがあっても問題ありません)」のところの画像の通りの「アイコン」でリモコンボタンを登録していたところ、それっぽく動くようになりました。

APIを使って存在しないボタンを登録

家のテレビはSONYのものなのですが、電源をトグルじゃなく切り替えたいなと思いました。手元のリモコンにはトグルの電源ボタンしかないものの、以下の記事を見つけて、0x2e, 0x2f を送信できればいけそうなので試してみようと思いました。

d.hatena.ne.jp

Nature Remo は API での制御が可能とのことなので仕様書を眺めていると、Cloud API のほうの /1/appliances/{appliance}/signals に POST すると登録できそうです。 /1/appliances を GET して得られた id を使って /1/appliances/{appliances}/signals を GET すると登録したボタンは一覧できたのですが、そのエンドポイントに POST する際の message に何を設定すればいいのかでまた少し悩みました。結局、 Local API の /messages を GET すると受信した信号のデータは取れるのがわかったので、それをそのまま登録してみて、うまく動くのを確認しました。次はこのデータをいじってリモコンで出せない信号を出すにはどうするかを考えました。

SONYの赤外線リモコンの信号のフォーマットは 赤外線学習リモコンの信号定義データの合成/ソニーフォーマット編 — 赤外線学習リモコンの信号データ合成 1.1 ドキュメント で解説されていて、 T = 600us の整数倍の配列でデータが表現されていると理解したので、 Local API で取得した電源トグルボタンのデータの配列の各要素を 600 の倍数に丸めてやって、説明通りの形式(実際にはリーダー+データ+トレーラーが何度か繰り返されている)のを確認し、またそれを Cloud API で登録して iPhone のアプリから期待通りに操作できるのを確認しました。あとはそれを 0x2e, 0x2f を表現するデータに書き換えて登録し、トグルじゃなく何度叩いても電源オン、何度叩いても電源オフが実現できました。

信号データを生成する

手でデータを作るのは飽きてきたので、ユーティリティを作りつつ、手元にあるPanasonicのレコーダーのリモコンのデータも生成できるようにしました。 Local APIで信号送信して効くか見ながらやっていたのですが、 Local API の /messages への POST では 1024 バイトを超えるデータを送信すると 400 エラーになっていて、エラー処理してなかったのでしばらくそれを知らずにうまく動かんなーと悩んでました*1。エラー処理は後ほど足しておきます。*2

github.com

感想

バイナリデータから意味を読み解くのは楽しい。

*1:切り分けのため curl で送信したらエラーになってるのに気づいた

*2:curl で 1024 バイトを超えるデータを送信すると Expect: 100-continue が付くけど、それを Remo が処理できずに 400 エラーを返しているようでした。python の requests を使ったときにはそれは踏んでなかったので、うまく動作してなかったのはたまたま別の問題が起きていたのかも

つくりたいものを好きなようにつくっていっしょうけんめいに売る

子供が小さいときに何度も絵本を読み聞かせ、会社の箱ティッシュカバーはずっとワルモノと、とってもとっても大好きなアランジアロンゾの創業者、さいとうきぬよ氏の講演があると電車の吊り広告で見たからには、行かずには居られず、半休とって OSAKA創業フェア2018(第8回創業グリップDay!) | 大阪信用保証協会 に行ってきました。

早めに着いたので真ん中の前の方に座ることができましたが、開始直前に次々と椅子が運び込まれ、会場の隅っこまでいっぱいの人の中で講演が始まりました。人前でしゃべるのは苦手だけどということから始まり、さいとうさんの、静かだけど熱のこもった言葉たちがじわーっと伝わってきました。

  • すごい強い想いは実現すると信じる
    • 言ったら、ひたすら行動
  • やろうと言ったらすぐにやる
    • 次から、明日から、は絶対やらない。実現しない
  • 意見違ったら、やりたい思いが強い方を
  • お互い絶対に「できない」と言わない。口に出さない。
  • たいていのことはギリギリセーフでできる
    • くりかえすと、できる
  • 絶対に好きな人とだけ仕事する
    • × あんまり好きじゃないけど仕事だし
    • ○ この人なら騙されてもいい
  • 楽しい、会社をつくってよかった。
  • 休みの日に遊ぶのも、次の日に仕事行くのも、楽しいのがいい

ひとことひとことが、心に突き刺さって、たくさんの勇気をもらいました!

OSS Gate 社内限定版を開催してみた

OSS開発に参加していない人が参加する人に変わる「入り口」を提供する取り組み、OSS Gateを終業後の時間を使って MonotaRO の社員限定で開催しました。

準備

OSSの開発をやったことがない人をメインターゲットとするので、不慣れな操作で社内情報を漏洩する心配がないようにと、OSSを動かす環境を構築するときにソフトウェア導入申請(社用PC利用時のルール)が障害にならないように、

  • PCは会社のものは使わず、持ち込み申請して承認もらった上で私物を持ち込んで使う
  • 社内ネットワークには接続せず、来客用のWiFiを利用する
  • 会議室のモニタには接続させてもらう
  • オープンな場所 (GitHub issue) への書き込みで機密情報を書かないよう、参加者に念押しする!

という形式で社内の会議室を使って開催することで上司の承諾を取り付けました。前からもくもく会を同様の形式で社内で開催していた(最近途切れてしまい過去形なのが悲しい…)ので、上司からは「これまでと変わらんのでしょ?」と二つ返事でOKしてもらえたのですんなりと開催の運びとなりました。

モデレータとしての準備は、資料はすでに用意されているものをそのまま使うのですることはなく、時間割はmasayuki14さんがスプーキーズで開催した時の記事 をベースにできたので、あとは YouTube の動画 を繰り返しひたすら見てました。

前半戦(2018/01/15)

ビギナー2人、サポーター2人とモデレーター私の構成で、OSSを動かして、ふりかえりをしてフィードバックポイントを探すところまでをやりました。

  • サポーターは大丈夫だよとしか言わないと説明したが、大丈夫という機会が前半戦ではほとんどなかった。
  • サポーターからビギナーに、いい問いかけが出て、ビギナーが自分で考えて進むサポートができていた。
  • メモを取りながらすすめるのは役に立ったというビギナーからの声が聞けた。

後半戦(2018/01/31)

ビギナー1人、サポーター3人(新規1人)とモデレーター兼サポーター私の構成で、前回のおさらいとやり方の説明をした上で、フィードバックの内容を整理していきました。

  • ビギナーが1人で、途中まで進んでいる状態だったので、急遽モブってみることに。
  • フィードバックポイントがまだぼんやりしていたので、そこを深掘りして、ポイントを整理するところからはじめた。
  • 質問と答えが噛み合ってなかったところで、ビギナーの人が思っていたことと別の解釈がされる可能性(省略してしまってたこと)に気づけた。
  • 実は2つのことを言おうとしてた気づき。2つIssue立てれるよとなって、ひとまず片方に注目してすすめることに。
  • 日本語で開発者視点でわかる文書にまとめ直すところまで到達したところで時間になったので打ち止め。
  • アンケートをリポジトリをフォークしてプルリクエストで出すというのが、一番難易度高いのではというツッコミ。

最後のツッコミについては、ワークショップ中では枠組み的なところはおいておいてフィードバックするコンテンツを作ることに集中、アンケートではコンテンツは容易なものとしつつ標準的なフィードバックの枠組み(プルリクエスト)の経験ができるようになっていて、進め方がよく練られているなあと感じました。

次やること

小さくはじめる、継続的に開催するを目標としていて、小さくはじめるの方はできたので、次は継続的に開催するの方。まずは2回目の開催を計画します。

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

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で発表するとか

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

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