satoryuの日記

忘れっぽいから覚えてるうちに書いておかないと。

XP 祭り2019 でLTしてきた #xpjug

LT イベントレポート XP OSS OSS Gate

前回行ってきたのが2015年だから4年ぶりにXPに行ってきた。 今回はLT参加でエントリーしてたので、LTしてきた。

この前の週に久しぶりにOSS Gateワークショップにサポーターとして参加してきた。

satoryu.hatenablog.com

2年ぶりの参加だったのだが、ビギナーの方々と話をしてみて感じるところは変わっていなかった。 彼らは「OSS開発者をすごく強大なエンジニア」と想像してしまっていることがある。 このLTで、少しでもそのイメージを払拭して、気軽にプルリクなりバグ報告なりをできるような人が出てくれたら嬉しいな、なんて思ってます。

記念

こんなにRTやファボられたのは滅多にないので記念に貼っておく。

OSS Gate東京ワークショップ でサポーターとして参加してきた #oss_gate

OSS OSS Gate イベントレポート

oss-gate.doorkeeper.jp

いつも行こうとして、なかなか家の都合と合わずにキャンセルばっかりしていたので、本当に久しぶりの参加。久しぶりに会った方々には、「本当に久しぶりですね」と言われるくらい。 今調べてみたら、この前に参加したのは2017年10月のPHPカンファレンスで実施した時以来のようだ。

いつもなら午前から始めるワークショップを今回は午後から始める短縮版としての開催だった。各回ごとに運営としては、集客のための挑戦を1つ入れていて、今回は「午後からなら参加しやすい」という仮説のもとでこうなったようだ。 自分としても午後からの方が家のことを片付けてから来れそうなので、参加しやすい気がした。 しかし、新たな問題として、今回はサポーターがビギナーより多くて余ってしまうという状況になってしまった。サポーターの申し込み状況に応じて、ビギナー枠を調整しているはずなんだけど、こういうことも起きるようだ。逆よりかはマシではあるが。

サポーターの時に気にしていること

2年ぶりだけど、サポートしてるときに気にしていることを意識しながら取り組んでみた。

  1. ビギナーは、自身が見つけた問題点の報告やコードの修正など過小評価してしまうことがある。なので、サポーターはOSSの一開発者として、その報告や修正がありがたいものかを伝える。
  2. ビギナーは、報告や修正をちゃんとしたものにしようと、色々やろうとしてしまう。なので、サポーターはその報告や修正に一旦区切りをつけて出せる単位にまとめるよう助ける。
  3. ビギナーは、報告や修正は取り入れられなければ価値が無いと思ってしまう。なので、サポーターはこれまでの経験を踏まえて、貢献の過程で学んだことを伝える。

1については、ビギナーはOSS開発者をとてもつよいエンジニアと想像してしまう傾向があるようなので、実際にはそんなことは無いという事実を伝える。簡単に言うと、良いことしかやってないので褒めまくる。

2について。 ちゃんとしたものでないと受け入れられない、とビギナーの方は考えてしまう傾向にあるようだ。 問題点の報告だけでなく、原因を添えたり、解決のための修正を送らないといけないと思って、どんどん膨らまそうとしてしまう。その結果、本来ならできたはずの問題点の報告がまとまらなくなってしまい、できずに終わりそうになってしまう。 なので、何か問題点を見つけたら、まずそれを速やかに報告できるようにまとめるようにサポートする。

3についても、2に近いかもしれない。 ビギナーは受け入れられる報告や修正でないと意味がないというように思ってしまうようだ。 受け入れられるかどうかは、正直サポーターもわからない。 でも、受け入れられなかった時に色々学べることがある。 受け入れられなかったとしても、その時になぜそれが受け入れられないのかOSS開発者が回答してくれるはずだ。 対象としている環境や設計の方針などで、問題や不具合に見えるものでもちゃんとした理由があったりする。 ちなみに、自分の経験上、出したプルリクエストなどがいきなり閉じられることは無かったし、取り込むために必要な追加の修正などコメントを貰うことの方が多い。稚拙な英語でうまく伝わらない時も「これは○○ということかな？」みたいに理解することに努めてくれる場合が多い。

ということで、どんな小さな発見でも尊いので、それを第3者が見てもわかるように書いてお伝えすればいい。 問題点を報告できそうだったら、もし見つけられれば原因も添えてあげればいい。 それはプラスαで、必須ではない。 原因までわかって可能なら修正を送ってあげればなお良いだろう。でも、これも必須ではない。 報告や修正が取り込まれなかったとしても、それを無碍に扱うOSS開発者はいない。いたとしたら、きっとそのOSSは発展しないだろう。 小さなことだとしてもフィードバックが開発にとって大切なことだから。

と、こんなことを書きつつも、今回のワークショップでちゃんとできたか心配。 最後のアンケートで、参加者全員から「大変満足」をいただけたので、とりあえず安心はしている。

次回予告

次回は10月27日（土）にLAPRAS株式会社さまにて開催です。

oss-gate.doorkeeper.jp

ミートアップは10月7日（月）に神田の英和システムマネジメントさまで開催です。

oss-gate.doorkeeper.jp

おまけ

会場は、GaiaxさんのコミュニティスペースNagatacho GRiD。

普段はコワーキングスペースとして空いていれば無料で使えるそうだ。 今回は、その一角をワークショップのために貸していただけた。 今回は2Fのフロアだったが、地下と4Fにも貸し出し可能なフロアがあるそうなので、勉強会開催を考えることがあったら候補に入れておきたい。

rakuten_web_service v1.12 をリリースしました。

OSS Ruby Rakuten Web Service rubygems

github.com

昨日に2ヶ月ぶりのリリースをしました。

これまでまったく自分が興味を持てなかったIchiba Tag APIに対応させるプルリクエストが送られてきたので、それを取り込んだものが今回のリリース内容です。

github.com

利用する場合は、

gem install rakuten_web_service -v '1.12.0'

またbundlerを利用している場合、下記の1行をGemfileに追加してください。

gem 'rakuten_web_service', '~> 1.12.0'

TDDワイワイ会に行ってきた #tddyyχ

tddyyχ イベントレポート TDD モブプログラミング

f:id:satoryu:20190908132500j:plain

今日被ってた予定が台風の影響で中止となったので、当日だったけど参加枠が空いてたのでドタ参してきた。

tddyyx.connpass.com

台風の予報が出ていたけれど無事に開催となって、特に目立った電車の運休などもなかったので15名ほどの参加者がいた。

5名ほどのチームで3チームに分かれ、各チームでcyber-dojoを使い、モブプログラミングとTDDを楽しんだ。

自分が参加したチームは、まず始めにプロジェクタがうまく接続できず、プロジェクタの準備をモブでやった。 他のレンタルのプロジェクタに取り替えてみたり*1、TV会議システムのモニタを拝借しようとしたり*2、最終的に使われてなかった天井付で使われるプロジェクターをひっくり返して使うことで解決した。

f:id:satoryu:20190908202225j:plain

普通にこのまま移すと逆さまに投影されてしまうのだが、Macのディスプレイの設定でプロジェクタへの出力を反転させることでまともに使えるようになった。 こういうのも一緒にやることで、楽しかったりする。

本題として、今回のモブチームメンバーが今までやったことない言語を選ぶことにした。 まず、みんなで経験したことある言語を書き出していったのだが、多様な経験を持つ人らが集まっていた。 問題として、FizzBuzzを挑戦した。 モブプロのススメ方は、TDDワイワイ会方式である「テストが赤くなったら交代」というもの。 自分は初めて経験した方式なのだが、前の人が赤くしたところをちゃんとわかってないと引き継げない。 なので、ナビゲーターとして参加しているときも自然とそこを意識できる仕組みなのだと思った。 また、赤くなったものを緑にするところから始めるのも、なんとなく満足感高い状態から始められる*3。 3巡ほどドライバーを回したところで、実装できた。

最後に全体で振り返りを共有して、お開きとなった。 たまに他のチームをチラ見してたけど、みんなワイワイしていたのが印象的だった。 その名が示すとおりのワイワイ会だった。

帰りがけに「モブってどういう時にやるといいんですか？」と聞かれたので、色々と答えたのだけど、モブプロ本を紹介しておけばよかった、という後悔。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

最後に、ステッカー*4を貰ったので、その場でMacbookの天板に貼った。 楽しかったので、また来よう。

f:id:satoryu:20190908202235j:plain

*1:今どきHDMIが刺さらないなんて…

*2:電源ボタンがあるであろう扉に鍵がかかっていて使えず

*3:これはお題によるかもしれない。FizzBuzzくらいに簡単だと実装が簡単なのでサクサク進められて気持ちいい。

*4:真ん中の緑色のダンベルは何を意味しているのだろうか

「服従の心理」を読んだ

読書 心理学 マネージメント

服従の心理 (河出文庫)

服従の心理 (河出文庫)

先日参加したアジャイルジャパン新横浜サテライトで視聴した基調講演の中で、この本が取り上げられていた。 どういった文脈でこの本に触れていたのかは記憶があやふやだったのだが、フラットな組織についての文脈だったと思う。

この本は、人が権威に服従する仕組みを調査する実験について、その実験方法から被験者の記録、分析について、実験を主導したミルグラム本人によって書かれたもの。ミルグラム実験がどういうものかについては、Wikipediaにも掲載されているのでそちらを読んでください。

ja.wikipedia.org

この本を読んでいて思うのは、人間が恐ろしくもたやすく権威の支持に服従してしまうということだ。 ミルグラム実験では、被害者（実際には実験する側である役者）に対して、被験者が電撃を加える。電撃の電圧を上げていくなかで、被害者が実験の中止を求めたり、体調不良を訴える。もし被験者が実験者に対して実験の中断を申し出ても、実験者は継続するように促す。 ここで被験者はどう行動するのか？

これを実験に参加していない人にアンケートを取ると、被害者が申し出た時点で被験者は実験を中止するだろう、と回答する。 特に、大学生、特に心理学を専攻している学生であるほど、より早く中止するだろうと回答している。 しかし、実験結果は、最悪のもので、被験者のほぼ全員が加えられる最大の電圧まで電撃を与え続ける。

支持の内容が非人道的だとわかっていても、責任が権威にあるとして続けてしまう。社会の中で生きるように進化してきた人間として、権威からの支持に従うことで社会の構成員として存在意義を示す傾向にあるとも言われている。

実験の種類もいくつも試されており、服従しないようにするためにはどのようにすればいいのか調査されている。 被害者と被験者との物理的な距離や、権威を持つ実験者の支持の一貫性が崩れた時や被験者を複数にするなど様々なことを試している。 それぞれの実験結果については、この本を実際に読んでみてほしい。

感想

  • 普段の社会にいたら、権威というものはいたるところに現れる。当然、仕事をしている時なんかは「上司と部下」といったものがそこら辺にある。非人道的な指示ですらあっさり服従してしまうのだから、普段の仕事でも無駄とわかっているようなことをあっさりと何も考えずにこなしてしまうのではないだろうか。
  • 上司の指示が必ずしも正しいわけではないし、それは上司が悪いと言って終わりにしてしまうわけにもいかないと個人的には思う。誤りをどこかで訂正するためには、服従に抵抗しなければならない。そのためのヒントがこの実験にあるんじゃないだろうか。
  • マネジメントは、人に働きかけて全体としてうまくやろう、というものだと思うので、人について知らないといけないだろうから心理学から学べることが多そう。

なんだかホラー映画を見ているような感覚で読んでいた気がする。

VS Code Recipes でRailsのデバッギング環境を構築してみた

Visual Studio Code Rails Ruby

Microsoft がVisual Studio Codeの設定のレシピをGitHub上に公開している。 その中に、Ruby on Railsのデバッグ環境の構築方法があったので、試しにそれに倣って作ってみた。

github.com

やってみた中で、自分なりに置き換えた部分がありました。

デバッグで使うgemをGemfileに追加

デバッグで使用するruby-debug-ide とdebase をGemfile に追加する。 理由としては2つある。

  1. それらのgemがデバッグに必須であるので、Railsアプリケーション開発に必要なものとして必要であることを明示するため。
  2. あとで作成するデバッグの設定ファイルlaunch.json 内で、rdebug-ideコマンドのパスを絶対パスとして指定する必要がある。そのパスを開発環境に依存させないようにしたいため。

2については後に出すlaunch.json を見てください。

具体的には、以下のようにGemfileに記述する。

group :development do
  # Access an interactive console on exception pages or by calling 'console' anywhere in the code.
  gem 'web-console', '>= 3.3.0'
  gem 'listen', '>= 3.0.5', '< 3.2'
  # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'
  gem 'ruby-debug-ide', require: false # <= Added
  gem 'debase', require: false # <= Added
end

gemのrequireオプションにfalseを指定している。これは、Railsが起動時にBundle.require で依存しているgemを全てrequire で読み込むのだが、アプリケーション自体には必要無いので読み込まないようにする。 このオプションを指定しなくてもデバッグはできるのだが、必要ないものはあえて読み込まないでおくほうが健全だと思う。

launch.json

デバッグ時に起動するアプリケーションやスクリプトを記述するためのlaunch.json ファイルも、vscode-recipesにサンプルが記載されている。

サンプル中に出てくる、rdebug-ideやbundlerコマンドのパスを指定するオプションpathToRDebugIDEとpathToBundler は、絶対パスで指定する必要がある。 まず、上でGemfileに依存を記述したので、bundle binstubsコマンドを使って、binディレクトリ配下にコマンドをインストールする。

bundle binstubs ruby-ide-debug bundler

launch.json内では、予め用意された変数を使ってパスなどを生成することができる。 ここで、VS Codeが開いているワークスペースの絶対パスを表すworkspaceRootを使い、先程のpathToRDebugIDEとpathToBundlerの値を指定する。

具体的には、デバッグのためにRailsサーバーを起動する設定は、以下のようになる。

       {
            "name": "Debug Rails server",
            "type": "Ruby",
            "request": "launch",
            "cwd": "${workspaceRoot}",
            "useBundler": true,
            "pathToBundler": "${workspaceRoot}/bin/bundle",
            "pathToRDebugIDE": "${workspaceRoot}/bin/rdebug-ide",
            "program": "${workspaceRoot}/bin/rails",
            "args": [
                "server",
                "-p",
                "3000"
            ]
        }

同様に他の設定についても、pathToRDebugIDEやpathToBundlerの値を置き換えていく。

一通り置き換えてみたものがこちら。

https://github.com/satoryu/ChatterBox/blob/master/.vscode/launch.json

他のレシピも良さそうなので、機会があったら試してみたい。

Agile Japan 2019サテライト 新横浜 に参加してきた。 #agilejapan #デンソー

イベントレポート アジャイル デンソー

Agile Japan 2019の企業内サテライトの1つである、デンソー（新横浜）会場に参加してきました。

Agile Japan 2019の基調講演はとても興味があったのでその動画を観れる良い機会でしたし、普段同じ建物で仕事している人たちと*1一緒にOSTしたりと、楽しい時間を過ごすことができました。

基調講演

LOVOTを開発しているGroove X株式会社代表取締役の林さんの講演を視聴しました。

  • ロボット開発はハードウェアとソフトウェアの両輪の開発
  • 新規事業

という点で、新横浜でのMaaS開発と近いものを感じていたので、非常に面白い内容でした。 気になったところをサラッと書きます。

  • 先が見通せないからこそスクラムで、なおかつ組織の体制も階層構造をやめてフラットにしている。フラットにして、複数チームが勝手に独立して動くような船頭が多い状態ではなく、そこを引っ張れるだけのプロダクトオーナーが必要そう
  • 「失敗を早くする」といっても盛大にずっこけることはできないので、リカバリや損切りを判断できるスキルが必要そう
  • 「飽きる」という感覚をポジティブに使うこと。新しいことへ挑戦するモチベーションの現れでもあるので、挑戦にもつながるが、それだけでなくそこに対応できれば離職率を下げられそう。実際に離職率が2%程度とおっしゃっていた。

個人的には、さらっと「100億溶かした」とか言っていて、それだけしてでもやりたいと思える情熱がプロダクトオーナーには必要なんだろうな、と勝手に頷いておりました。

基調講演後の感想戦

基調講演を観ている時に、各自で気になったところや感想を付箋に書き留めていたものを全員で共有し、特に気になるところについてディスカッションしました。

  • フラットな組織って？
  • 組織がフラットになると、2:8の法則の2割がなくなるってほんと？
  • うちらって「洞窟」っぽい？

みたいなことを、ときには脇道にそれたりしながらワイワイと話をしました。

ランチセッション

社内Slackで「どんなセッションをやりたいか？」を公募したところ、「焼きそばを作る」「焼きそばを食べる」という2つがエントリーしており、これが採択されました。 ということで、ハードウェア（ホットプレート）とソフトウェア（焼きそばの材料など）の調達からリリース（調理）まで自己組織的に行いました。

再演: 大企業をリファクタリングしてみる

Agile Japan 2019で登壇した弊社石田さんの再演。 いままでチラッと聞いたことがある、Joy, Inc を参考にした自分たちの秘密基地づくりやインナーソースの取り組みについて聞けたのはとても良かった。 組織と人をハードウェアとソフトウェアのアナロジーで見直すことで、得られる考え方も変わってくる。新しい改革プロジェクトって立ち上がるけど、人が集まらないというのはどこにでもあるもんなんだな、と。

石田さんの講演資料はこちら。

OST

OSTが何かについては、先日優良コンテンツが出たのでそちらをご参照ください。

takaking22.com

せっかく同じイベントに参加してるのだからもっとワイワイと話さなくちゃ！ ということで、やってみたところ、短い時間の中でカバーしきれない話題がたくさん出てきました！

f:id:satoryu:20190813200418j:plain

答えは出なくても、普段モヤモヤっとしてることを出してみて、思考を整理したり、他の人の意見を聞けたり、新しい情報を得られたりできるので、こういう時間はとてもいいですね。

ちなみに、引き続きオススメ映画（Amazon プライムで観れるもの）は募集中です。

Fun! Done! Learn!

楽しい時間は過ぎるのが早いというもので、その楽しさをFun! Done! Learn!で振り返りました。

おわりに

7月に入社して、まだ右も左も分からない感じなんですが、大企業だけどポジティブに色んなことをやっていこうとしている人たちがいる感じがしました。 しかし、良くも悪くも皆さん真面目な空気を感じてもいます。

今日みたいな楽しいことが普段からやれていけるといいな、と思った次第です。 これからも楽しむぞ！

*1:と書いておきながら自分は秋葉原にいることが多かったりするのではありますが。