satoryuの日記

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

「闇に魅入られた科学者たち」を読んだ。

闇に魅入られた科学者たち―人体実験は何を生んだのか

闇に魅入られた科学者たち―人体実験は何を生んだのか

たまたま図書館で見かけたのだけど、科学倫理の話として面白かった。

副題にあるように、犠牲者を出す人体実験を行ってしまった5人の科学者について書かれている。 時代背景などは異なるが、好奇心や国家への忠誠心、理想が生み出されている。 人体実験を行った科学者本人それぞれは、それぞれが従った正義を否定することはないようだ。 本文中にも書いてあるのだが、謝罪することはそれまでの自身が行ったことを否定することになり、それは自身が気づきあげてきた理論を否定することになるからなのだろう。 あくまでも科学や国家、人類のために、ということを裏付けとして行ったことで、それは誤りではないということなのだろう。 確かに、彼らが行ったのはエセ科学というものではなく、それぞれの領域の発展に貢献する結果も出してはいる。

科学者といえどもただの人であり、置かれた状況によっては、間違った行為と思いつつも誤ったことに手を出してしまうのかもしれない。 それは「服従の心理」に書かれていることがそのままなのだろう。

satoryu.hatenablog.com

この本の最後に池内了氏が言うように、科学者の暴走を止めるために、行き過ぎた科学者に対して一般市民が声を出して批判することは大切なのだろう。 そのために、科学について知っておく必要があるのだな。 と思った。

エクストリームプログラミングを読んだ。

エクストリームプログラミング

エクストリームプログラミング

先日参加したXP祭り2019までの予習として読んでいたのだけど、当日までに読み終えることができなかったが、ちまちまと読み進めてやっと読了。

この本を読む前までは、エクストリームプログラミングについては名前しか知らなかった。 本を開くまでは、プラクティスについて記述された本だと思っていた。

10年以上前に学生の時に、ペアプログラミングを同期とやったことはあった。 チーム開発というわけではなく、スポットで一緒に知識を出し合ってコードを書いてみたかっただけで、どちらかと言えばモブプロっぽい目的だったと思う。 就職してから初めてチーム開発をするようになった。 テスト駆動とかCIとか言葉しかしらなかったものを真面目に学び始めたのもその頃から。ということを、本を読みながら色々と思い出した。 先日のXP祭り2019での基調講演で、「どこにでもXPのかけらがある」といった話をしていたが、なんとなくそれが納得いった気がする。

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

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

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

satoryu.hatenablog.com

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

記念

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

OSS Gate東京ワークショップ でサポーターとして参加してきた #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 をリリースしました。

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χ

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

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

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

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

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

感想

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

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