マーティ・ケイガン推薦書籍の日本語版を探してみた。 #pmconfjp
プロダクトマネージャーカンファレンス2019の基調講演は、あのInspiredの原著者マーティ・ケイガンでした。 マネジメントやプロダクトのデザインとかそういう話ではなく、意外とチームや人の話で、とても共感できる部分があったり、とても考えさせられました。
基調講演中、氏が推薦図書を紹介してくれました。
#pmconfjp pic.twitter.com/zGW4bMQxNf
— 文 (@wifecooky) November 12, 2019
で、さらっと中身を知りたいと思ったので、日本語版の書籍を探してみました。 一部は翻訳されていませんでしたが、原著はAmazonで購入可能のようです*1。
- 作者: レイ・ダリオ,斎藤聖美
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2019/03/21
- メディア: 単行本
- この商品を含むブログを見る
リーダーは最後に食べなさい! チームワークが上手な会社はここが違う (日経ビジネス人文庫)
- 作者: サイモン・シネック,栗木さつき
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2018/04/28
- メディア: 文庫
- この商品を含むブログを見る
- 作者: ラズロ・ボック,鬼澤忍,矢羽野薫
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2015/07/31
- メディア: 単行本
- この商品を含むブログ (10件) を見る
- 作者: L・デビッド・マルケ,花塚恵
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2014/05/30
- メディア: 単行本
- この商品を含むブログ (6件) を見る
THE CULTURE CODE ―カルチャーコード― 最強チームをつくる方法
- 作者: ダニエル・コイル,楠木建,桜田直美
- 出版社/メーカー: かんき出版
- 発売日: 2018/12/03
- メディア: 単行本
- この商品を含むブログを見る
上のスライドとは別で、Amazon、Apple、Googleのファウンダー達をコーチングした故ビル・キャンベル氏に関する本の日本語訳も近々出版されるようです。
ということで、当面読みたい本には困らなそう*2。
「闇に魅入られた科学者たち」を読んだ。
- 作者: NHK「フランケンシュタインの誘惑」制作班
- 出版社/メーカー: NHK出版
- 発売日: 2018/03/08
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
たまたま図書館で見かけたのだけど、科学倫理の話として面白かった。
副題にあるように、犠牲者を出す人体実験を行ってしまった5人の科学者について書かれている。 時代背景などは異なるが、好奇心や国家への忠誠心、理想が生み出されている。 人体実験を行った科学者本人それぞれは、それぞれが従った正義を否定することはないようだ。 本文中にも書いてあるのだが、謝罪することはそれまでの自身が行ったことを否定することになり、それは自身が気づきあげてきた理論を否定することになるからなのだろう。 あくまでも科学や国家、人類のために、ということを裏付けとして行ったことで、それは誤りではないということなのだろう。 確かに、彼らが行ったのはエセ科学というものではなく、それぞれの領域の発展に貢献する結果も出してはいる。
科学者といえどもただの人であり、置かれた状況によっては、間違った行為と思いつつも誤ったことに手を出してしまうのかもしれない。 それは「服従の心理」に書かれていることがそのままなのだろう。
この本の最後に池内了氏が言うように、科学者の暴走を止めるために、行き過ぎた科学者に対して一般市民が声を出して批判することは大切なのだろう。 そのために、科学について知っておく必要があるのだな。 と思った。
エクストリームプログラミングを読んだ。
- 作者: ケントベック,シンシアアンドレス,Kent Beck,Cynthia Andres,角征典
- 出版社/メーカー: オーム社
- 発売日: 2015/06/26
- メディア: 単行本
- この商品を含むブログ (6件) を見る
先日参加したXP祭り2019までの予習として読んでいたのだけど、当日までに読み終えることができなかったが、ちまちまと読み進めてやっと読了。
この本を読む前までは、エクストリームプログラミングについては名前しか知らなかった。 本を開くまでは、プラクティスについて記述された本だと思っていた。
10年以上前に学生の時に、ペアプログラミングを同期とやったことはあった。 チーム開発というわけではなく、スポットで一緒に知識を出し合ってコードを書いてみたかっただけで、どちらかと言えばモブプロっぽい目的だったと思う。 就職してから初めてチーム開発をするようになった。 テスト駆動とかCIとか言葉しかしらなかったものを真面目に学び始めたのもその頃から。ということを、本を読みながら色々と思い出した。 先日のXP祭り2019での基調講演で、「どこにでもXPのかけらがある」といった話をしていたが、なんとなくそれが納得いった気がする。
XP 祭り2019 でLTしてきた #xpjug
前回行ってきたのが2015年だから4年ぶりにXPに行ってきた。 今回はLT参加でエントリーしてたので、LTしてきた。
この前の週に久しぶりにOSS Gateワークショップにサポーターとして参加してきた。
2年ぶりの参加だったのだが、ビギナーの方々と話をしてみて感じるところは変わっていなかった。 彼らは「OSS開発者をすごく強大なエンジニア」と想像してしまっていることがある。 このLTで、少しでもそのイメージを払拭して、気軽にプルリクなりバグ報告なりをできるような人が出てくれたら嬉しいな、なんて思ってます。
記念
こんなにRTやファボられたのは滅多にないので記念に貼っておく。
先程使用したLT資料です。
— さとりゅう 🌸 たつや学院 (@sato_ryu) September 21, 2019
今日は良い床だったので、良い滑りができましたね。 #xpjug https://t.co/CudjDvyLJY
OSS Gate東京ワークショップ でサポーターとして参加してきた #oss_gate
いつも行こうとして、なかなか家の都合と合わずにキャンセルばっかりしていたので、本当に久しぶりの参加。久しぶりに会った方々には、「本当に久しぶりですね」と言われるくらい。 今調べてみたら、この前に参加したのは2017年10月のPHPカンファレンスで実施した時以来のようだ。
いつもなら午前から始めるワークショップを今回は午後から始める短縮版としての開催だった。各回ごとに運営としては、集客のための挑戦を1つ入れていて、今回は「午後からなら参加しやすい」という仮説のもとでこうなったようだ。 自分としても午後からの方が家のことを片付けてから来れそうなので、参加しやすい気がした。 しかし、新たな問題として、今回はサポーターがビギナーより多くて余ってしまうという状況になってしまった。サポーターの申し込み状況に応じて、ビギナー枠を調整しているはずなんだけど、こういうことも起きるようだ。逆よりかはマシではあるが。
サポーターの時に気にしていること
2年ぶりだけど、サポートしてるときに気にしていることを意識しながら取り組んでみた。
- ビギナーは、自身が見つけた問題点の報告やコードの修正など過小評価してしまうことがある。なので、サポーターはOSSの一開発者として、その報告や修正がありがたいものかを伝える。
- ビギナーは、報告や修正をちゃんとしたものにしようと、色々やろうとしてしまう。なので、サポーターはその報告や修正に一旦区切りをつけて出せる単位にまとめるよう助ける。
- ビギナーは、報告や修正は取り入れられなければ価値が無いと思ってしまう。なので、サポーターはこれまでの経験を踏まえて、貢献の過程で学んだことを伝える。
1については、ビギナーはOSS開発者をとてもつよいエンジニアと想像してしまう傾向があるようなので、実際にはそんなことは無いという事実を伝える。簡単に言うと、良いことしかやってないので褒めまくる。
2について。 ちゃんとしたものでないと受け入れられない、とビギナーの方は考えてしまう傾向にあるようだ。 問題点の報告だけでなく、原因を添えたり、解決のための修正を送らないといけないと思って、どんどん膨らまそうとしてしまう。その結果、本来ならできたはずの問題点の報告がまとまらなくなってしまい、できずに終わりそうになってしまう。 なので、何か問題点を見つけたら、まずそれを速やかに報告できるようにまとめるようにサポートする。
3についても、2に近いかもしれない。 ビギナーは受け入れられる報告や修正でないと意味がないというように思ってしまうようだ。 受け入れられるかどうかは、正直サポーターもわからない。 でも、受け入れられなかった時に色々学べることがある。 受け入れられなかったとしても、その時になぜそれが受け入れられないのかOSS開発者が回答してくれるはずだ。 対象としている環境や設計の方針などで、問題や不具合に見えるものでもちゃんとした理由があったりする。 ちなみに、自分の経験上、出したプルリクエストなどがいきなり閉じられることは無かったし、取り込むために必要な追加の修正などコメントを貰うことの方が多い。稚拙な英語でうまく伝わらない時も「これは○○ということかな？」みたいに理解することに努めてくれる場合が多い。
ということで、どんな小さな発見でも尊いので、それを第3者が見てもわかるように書いてお伝えすればいい。 問題点を報告できそうだったら、もし見つけられれば原因も添えてあげればいい。 それはプラスαで、必須ではない。 原因までわかって可能なら修正を送ってあげればなお良いだろう。でも、これも必須ではない。 報告や修正が取り込まれなかったとしても、それを無碍に扱うOSS開発者はいない。いたとしたら、きっとそのOSSは発展しないだろう。 小さなことだとしてもフィードバックが開発にとって大切なことだから。
と、こんなことを書きつつも、今回のワークショップでちゃんとできたか心配。 最後のアンケートで、参加者全員から「大変満足」をいただけたので、とりあえず安心はしている。
次回予告
次回は10月27日（土）にLAPRAS株式会社さまにて開催です。
ミートアップは10月7日（月）に神田の英和システムマネジメントさまで開催です。
おまけ
会場は、GaiaxさんのコミュニティスペースNagatacho GRiD。
#oss_gate 会場は開場しています。 pic.twitter.com/iHnwwKDarq
— さとりゅう 🌸 たつや学院 (@sato_ryu) September 14, 2019
普段はコワーキングスペースとして空いていれば無料で使えるそうだ。 今回は、その一角をワークショップのために貸していただけた。 今回は2Fのフロアだったが、地下と4Fにも貸し出し可能なフロアがあるそうなので、勉強会開催を考えることがあったら候補に入れておきたい。
rakuten_web_service v1.12 をリリースしました。
TDDワイワイ会に行ってきた #tddyyχ
今日被ってた予定が台風の影響で中止となったので、当日だったけど参加枠が空いてたのでドタ参してきた。
台風の予報が出ていたけれど無事に開催となって、特に目立った電車の運休などもなかったので15名ほどの参加者がいた。
5名ほどのチームで3チームに分かれ、各チームでcyber-dojoを使い、モブプログラミングとTDDを楽しんだ。
自分が参加したチームは、まず始めにプロジェクタがうまく接続できず、プロジェクタの準備をモブでやった。 他のレンタルのプロジェクタに取り替えてみたり*1、TV会議システムのモニタを拝借しようとしたり*2、最終的に使われてなかった天井付で使われるプロジェクターをひっくり返して使うことで解決した。
普通にこのまま移すと逆さまに投影されてしまうのだが、Macのディスプレイの設定でプロジェクタへの出力を反転させることでまともに使えるようになった。 こういうのも一緒にやることで、楽しかったりする。
本題として、今回のモブチームメンバーが今までやったことない言語を選ぶことにした。 まず、みんなで経験したことある言語を書き出していったのだが、多様な経験を持つ人らが集まっていた。 問題として、FizzBuzzを挑戦した。 モブプロのススメ方は、TDDワイワイ会方式である「テストが赤くなったら交代」というもの。 自分は初めて経験した方式なのだが、前の人が赤くしたところをちゃんとわかってないと引き継げない。 なので、ナビゲーターとして参加しているときも自然とそこを意識できる仕組みなのだと思った。 また、赤くなったものを緑にするところから始めるのも、なんとなく満足感高い状態から始められる*3。 3巡ほどドライバーを回したところで、実装できた。
最後に全体で振り返りを共有して、お開きとなった。 たまに他のチームをチラ見してたけど、みんなワイワイしていたのが印象的だった。 その名が示すとおりのワイワイ会だった。
帰りがけに「モブってどういう時にやるといいんですか？」と聞かれたので、色々と答えたのだけど、モブプロ本を紹介しておけばよかった、という後悔。
モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める
- 作者: マーク・パール,及部敬雄（解説）,長尾高弘
- 出版社/メーカー: 日経BP
- 発売日: 2019/02/23
- メディア: 単行本
- この商品を含むブログを見る
最後に、ステッカー*4を貰ったので、その場でMacbookの天板に貼った。 楽しかったので、また来よう。
