pblog

pplog.net を作っている @ppworks こと越川直人(Koshikawa Naoto)のブログ。文体は日によって違う。esa LLCで働いてます(\\( ⁰⊖⁰)/)

許可を得る前にプルリクしよう、って言ってきた。

2016年12月17日(土)、松江テルサ4階にて開催された松江Ruby会議08に参加しました。初の島根!初の松江!

f:id:naoto5959:20161217125444j:plain

キッカケは、フルタイムRubyコミッター採用までの道のり | Money Forward Engineers' Blogという記事が松江Ruby会議スタッフの目に止まり、僭越ながらゲストスピーカーにお招きいただきました。

許可を得る前にプルリクしよう、とは

About pull requests - User Documentation

プルリク = GitHubのPull Requestという機能です。GitHubはGitのRepositoryをホスティングするサービスで、Pull Requestを使うことで、そのRepositoryの本筋の歴史に対してある時点で分岐した歴史を統合する提案が出来ます。

『許可を求めるな謝罪せよ(Don’t ask for permission, beg for forgiveness)』の初出

「許可を求めるな謝罪せよ」という有名な言葉があって、これは、"Don’t ask for permission, beg for forgiveness"の誤訳らしいんですが、それをもじったツイートをしたことが有り、今回はその心を問うという形で発表させて頂きました。

チームの意思決定プロセスの民主化

Pull Requestに流れる思想は、チームの意思決定プロセスの民主化です。

ポエム/GitとGithubについて(by taea) - ppworks.esa.io

  • 動くコードで提案が出来る
  • 合意形成の可視化・フェア感
  • コードに含めた意図を主張し、歴史に残す事が出来る

チームの意思決定のプロセスを整理してみると以下のようになります。

  1. あるひとの意志を案として、提案する
  2. 合意形成のための議論を行い、新たな案などを取り込む
  3. 合意形成され意思決定される

これらが、

  1. Pull Requestの作成して、動くコードで提案する。
  2. Pull Request上でのコメントのやり取り、コミットを繰り返す
  3. Merge

に対応するわけです。

image.png (895.3 kB)

CHANGE

何か変革を起こすときには自分が起点となることが大事です。問題提起だけで終わってしまっては、愚痴っているだけのように見えますし、もったいないですね。

  • 自分が変わる
  • 自分が変える
  • 周りが変わる

普段の行動からリーダーシップを取る方法としては、『採用基準』にあるようなアプローチが良いと思っています。たとえ十分な情報が揃っていなくても、決断する事が大事です。決断することがリーダーシップともいえます。

また自分が変わるキッカケとしては、『人生が大きく変わる アドラー心理学入門』が参考になります。人生は自分が主人公という意識を持って、どうすれば建設的な判断が出来るかを考える事が重要です。

採用基準

採用基準

人生が大きく変わる アドラー心理学入門

人生が大きく変わる アドラー心理学入門

許可を得る前にプルリクしよう

てなわけで、「許可を得る前にプルリクしよう」って何かって言うと、人生は自分が主人公という意識を持って、自分が起点となりリーダーシップを取ろう、と言い換えることが出来ます。

松本さんの話

プロダクトオーナーは、プロダクトのデザイナーでもある。デザイナーはデザインポリシーとして、モノづくりの背景である物語を語り続けるストーリーテラーであれ。

という話でした。私が考えていたリーダーシップに必要な、決断力。決断力が発揮される背景には、その人のポリシーがあるのだと気付かされました。

松田さんの話

開発のツールの話。プログラマーは自分が使う道具を自分で作ることができるし、誰の許可も求めなくていいんですよってのは本当にそうだなって思いました。

松田さんの話を聞けば聞くほど、自分はここ最近ポエムばかり吟じてばかりだし、コード書かねばなって強く思った結果、本当にプレイヤーに戻らねばと思いましたよ、ほんとまじ。

あと、お隣で「Don’t repeat your 発表っていうポリシーなんですよー」と仰ってて感銘を受けました。はー、カッコイイ。

自分の発表について

今まで自分のスタンスというものを整理するいい機会になりました。自分はナニモノなのかという問いかけを自身にしたときに、ここ最近の具体事例と一緒にスタンスを示す事が出来たのが良かったですね。

今回改めて、自分の人生にもリーダーシップを持って臨むべしと感じました。大物ゲストと並んで恐縮しか無かったんですが、当日は恐縮しすぎるのは招待してくださった方々にも失礼になるし、きっと自分にしか話せない話があると信じ、なるべく堂々と発表に挑めるよう心がけました。上手く出来ていたかどうかは怪しいですが、ベストは尽くしたと思ってます。とはいえ、勇気を出して後日配信されるであろう動画から反省点を学ばねばならないですね。機材トラブルにより私のパートの動画配信はないそうですと思ったら、公開されてました

www.youtube.com

きっかけを作ってくださった松田さん、並びに松江の方々に感謝です。

あわせてよみたい

ppworks.hatenablog.jp

ppworks.hatenablog.jp

Rubyエンジニアの採用戦略について話した

本日、株式会社リクルートマーケティングパートナーズ内にて開催された「Rubyビジネスセミナー Rubyの導入とエンジニア組織の作り方」にお呼ばれされ、ゲストスピーカーとして登壇してまいりました。

ZDNetへ寄稿した記事の内容を中心に、Rubyエンジニアの採用戦略についてお話しました。45分枠の登壇は初めての経験だったので事前に何度かシミュレーションしていたのですが、何故か何度やっても45分にキッチリ収まってしまい、本番でもキッチリ収まってしまいました。びっくりしたのと同時に「これぐらいのボリュームなのか、なるほど」という謎の自信がつきました。発表者ノートに「この辺で10分経過しているはず」などと書いておいたのはペースをコントロールするのに役立ちました。上手く行ったような気はしているのですが、率直な感想は聞いてみたいです。(はやくち!とか分かりづらい!とか)

なお、発表の中で話せなかったことは、以下の記事を読んで頂ければと思います。

「働く仲間を増やすために魅力的であれ」

その「エンジニア採用」が不幸を生む

ちょうどこの発表をする数日前に、『その「エンジニア採用」が不幸を生む』という本が届きました。これはいいタイミングだなと、前日に読んでから発表に臨むことが出来て良かったです。

戦略以前に、経営者の意識が「エンジニア採用」に向いていない場合は、まずこの本を読むことから始めると良いなと思います。またこの本にあるとおり、海外のイケている企業が提唱する「エンジニア採用のあり方」は、流石に日本のベンチャーではそのまま適用しても上手く行かないというのに同意です。いかに自分たちにフィットした採用戦略を考えるかが大事なのだと感じました。

(個人的には第三章はあまり同意しないというか、そういうエンジニアにあまり出会った事がないので、そうなんですかねー?という印象です。)

人に興味がある人

懇親会で、エンジニア人事に向いている人ってどんな人だろうという話をしていました。私の考えるエンジニア人事のプロは、ずばり、人に興味があるエンジニアだと思います。とても希少な人種だと思いますが、それが本質かと思います。人に興味があるからこそ、人の事に情熱を注ぎ、精を出せるのかと。

また、とあるエンジニアには、「想いや情熱が伝わってきました」という感想をもらえて嬉しかったです。

今回の私の発表を通じて、私自身に興味を持った人や同じ思いを持った人と出会えるといいなと思ってます。興味があれば、ご連絡ください。

最後になりましたが、今回このような機会をくださいましたRubyアソシエーション様に感謝致します。ありがとうございました!

ホネーマワード紀行

久々に人前で発表をしました。「エンジニア×個の力をForward」というテーマのMoneyForward Meetupです。来月は45分枠の発表が2つもあるので、ちょうどよい肩慣らしになりました。

ホネーマワード紀行

前のお二人の発表タイトルに「奇行」と「寄稿」が入っていて、これは繋げねば!という謎のプレッシャーにより急遽タイトルに「紀行」を付けたのですが、奇しくも「マネーフォワード」に至るまでの私の人生の旅路がまとまった発表を上手いこと表した感じになり、結果的に良かったです。

2011年に某社でRailsを触り始めたのがRubyコミュニティへ関わるキッカケの一つとなったと言えます。その会社の合宿でFacebook APIを使ったRailsアプリを作り、herokuにdeployしたことで、当時の上司と繋がりのあった相澤さんからHeroku JP Meetup #3 : ATNDへ招待されたのが外へ出るキッカケとなりました。

Meetupの数日前に見たツイートをキッカケに、we love herokuをリリースすることになります。その際、使ったTwitter Bootstrapのtipsを書いた記事が軽くバズったりしました。

そこからアウトプットの癖が付き始めた気がします。

キッカケは、割とそこら辺に転がっていて、それを「チャンス」だと捉えられるかどうかが大事だと思いました。『仕事はたのしいかね?』で言うと、以下のあたりです。

  • もし宇宙が信じられないような素晴らしいアイデアをくれるとして、きみはそれにふさわしいかね?
  • きみはたぶん何十もの素晴らしいアイデアに、目の前を通り過ぎさせて来てしまっていると思うよ。
  • 僕たちはね、失敗するのを怖がりすぎて、それが宇宙からの贈り物だってことに気づこうとしないんだ。

仕事は楽しいかね?

仕事は楽しいかね?

振り返ってみると、一歩を踏み出す勇気が大事だったんだと思いました。外に出ることで視野が広まりました。

色々と試して来たので多くの失敗もしました。しかし学びが多かったです。例えば、起業は側から見たら単なる失敗にしか見えないと思いますが、あの経営経験は確実に今に活きてます。ブレない芯を言語化出来たのもその時の経験からです。

MF時代のppworksについて

パネルディスカッションでの質問の一つに、「MF時代のppworksについて」という質問がありました。ちょうど良いタイミングで、同日に公開された記事があるので、それを紹介します。私が取り組んできたことを体系立てて整理してみたら、それは戦略として繋がっていた事に気付かされました。

もはや月並みとなった表現で表すと、Connecting the Dotsってやつですね。組織の中で裁量を持って働くことで視座が高まりました。

「働く仲間を増やすために魅力的であれ」

せっかくメディアへ寄稿するということで、結城先生の書籍にお世話になりつつ、いつもよりも丁寧に文章を練ってみました。

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 推敲編 (ちくま学芸文庫)

数学文章作法 推敲編 (ちくま学芸文庫)

この記事を元にした発表を2016年12月15日に行います。興味のある方はぜひお越し下さい。

Rubyビジネスセミナー Rubyの導入とエンジニア組織の作り方 - Rubyアソシエーション | Doorkeeper

冒頭で触れた45分枠の発表のうちの一つです。