退職のお知らせです。
マネーフォワードに在籍したのは 2年ちょいでしたね。
最近はこんな感じでした。歴代2位ぐらいの長さでした。
1月一杯はちょっと有給消化をしてブラブラとしつつ、次の準備をしようかと思っております。
なんとか顧問のお誘いだったりとか、一緒にご飯食べようとか、ナンカ分からないですけど、需要があればFacebookや koshikawa at ppworks.jp 宛へ、お声がけ頂けると嬉しいです。
誰
例のリスト
許可を得る前にプルリクしよう、って言ってきた。
2016年12月17日(土)、松江テルサ4階にて開催された松江Ruby会議08に参加しました。初の島根！初の松江！
キッカケは、フルタイムRubyコミッター採用までの道のり | Money Forward Engineers' Blogという記事が松江Ruby会議スタッフの目に止まり、僭越ながらゲストスピーカーにお招きいただきました。
許可を得る前にプルリクしよう、とは
プルリク = 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 せよ
— 😙 (@ppworks) 2014年5月23日
チームの意思決定プロセスの民主化
Pull Requestに流れる思想は、チームの意思決定プロセスの民主化です。
- 動くコードで提案が出来る
- 合意形成の可視化・フェア感
- コードに含めた意図を主張し、歴史に残す事が出来る
チームの意思決定のプロセスを整理してみると以下のようになります。
- あるひとの意志を案として、提案する
- 合意形成のための議論を行い、新たな案などを取り込む
- 合意形成され意思決定される
これらが、
- Pull Requestの作成して、動くコードで提案する。
- Pull Request上でのコメントのやり取り、コミットを繰り返す
- Merge
に対応するわけです。
CHANGE
何か変革を起こすときには自分が起点となることが大事です。問題提起だけで終わってしまっては、愚痴っているだけのように見えますし、もったいないですね。
- 自分が変わる
- 自分が変える
- 周りが変わる
普段の行動からリーダーシップを取る方法としては、『採用基準』にあるようなアプローチが良いと思っています。たとえ十分な情報が揃っていなくても、決断する事が大事です。決断することがリーダーシップともいえます。
また自分が変わるキッカケとしては、『人生が大きく変わる アドラー心理学入門』が参考になります。人生は自分が主人公という意識を持って、どうすれば建設的な判断が出来るかを考える事が重要です。
- 作者: 伊賀泰代
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2012/11/09
- メディア: 単行本（ソフトカバー）
- 購入: 24人 クリック: 392回
- この商品を含むブログ (63件) を見る
- 作者: 岩井俊憲
- 出版社/メーカー: かんき出版
- 発売日: 2014/12/24
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
許可を得る前にプルリクしよう
てなわけで、「許可を得る前にプルリクしよう」って何かって言うと、人生は自分が主人公という意識を持って、自分が起点となりリーダーシップを取ろう、と言い換えることが出来ます。
松本さんの話
プロダクトオーナーは、プロダクトのデザイナーでもある。デザイナーはデザインポリシーとして、モノづくりの背景である物語を語り続けるストーリーテラーであれ。
という話でした。私が考えていたリーダーシップに必要な、決断力。決断力が発揮される背景には、その人のポリシーがあるのだと気付かされました。
松田さんの話
開発のツールの話。プログラマーは自分が使う道具を自分で作ることができるし、誰の許可も求めなくていいんですよってのは本当にそうだなって思いました。
松田さんの話を聞けば聞くほど、自分はここ最近ポエムばかり吟じてばかりだし、コード書かねばなって強く思った結果、本当にプレイヤーに戻らねばと思いましたよ、ほんとまじ。
あと、お隣で「Don’t repeat your 発表っていうポリシーなんですよー」と仰ってて感銘を受けました。はー、カッコイイ。
自分の発表について
今まで自分のスタンスというものを整理するいい機会になりました。自分はナニモノなのかという問いかけを自身にしたときに、ここ最近の具体事例と一緒にスタンスを示す事が出来たのが良かったですね。
今回改めて、自分の人生にもリーダーシップを持って臨むべしと感じました。大物ゲストと並んで恐縮しか無かったんですが、当日は恐縮しすぎるのは招待してくださった方々にも失礼になるし、きっと自分にしか話せない話があると信じ、なるべく堂々と発表に挑めるよう心がけました。上手く出来ていたかどうかは怪しいですが、ベストは尽くしたと思ってます。とはいえ、勇気を出して後日配信されるであろう動画から反省点を学ばねばならないですね。（機材トラブルにより私のパートの動画配信はないそうですと思ったら、公開されてました）
きっかけを作ってくださった松田さん、並びに松江の方々に感謝です。
あわせてよみたい
Rubyエンジニアの採用戦略について話した
本日、株式会社リクルートマーケティングパートナーズ内にて開催された「Rubyビジネスセミナー Rubyの導入とエンジニア組織の作り方」にお呼ばれされ、ゲストスピーカーとして登壇してまいりました。
ZDNetへ寄稿した記事の内容を中心に、Rubyエンジニアの採用戦略についてお話しました。45分枠の登壇は初めての経験だったので事前に何度かシミュレーションしていたのですが、何故か何度やっても45分にキッチリ収まってしまい、本番でもキッチリ収まってしまいました。びっくりしたのと同時に「これぐらいのボリュームなのか、なるほど」という謎の自信がつきました。発表者ノートに「この辺で10分経過しているはず」などと書いておいたのはペースをコントロールするのに役立ちました。上手く行ったような気はしているのですが、率直な感想は聞いてみたいです。（はやくち！とか分かりづらい！とか）
なお、発表の中で話せなかったことは、以下の記事を読んで頂ければと思います。
「働く仲間を増やすために魅力的であれ」
その「エンジニア採用」が不幸を生む
ちょうどこの発表をする数日前に、『その「エンジニア採用」が不幸を生む』という本が届きました。これはいいタイミングだなと、前日に読んでから発表に臨むことが出来て良かったです。
その「エンジニア採用」が不幸を生む ?良い人材を見つけ、活躍してもらうには何が必要か？
- 作者: 正道寺雅信
- 出版社/メーカー: 技術評論社
- 発売日: 2016/12/07
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
戦略以前に、経営者の意識が「エンジニア採用」に向いていない場合は、まずこの本を読むことから始めると良いなと思います。またこの本にあるとおり、海外のイケている企業が提唱する「エンジニア採用のあり方」は、流石に日本のベンチャーではそのまま適用しても上手く行かないというのに同意です。いかに自分たちにフィットした採用戦略を考えるかが大事なのだと感じました。
（個人的には第三章はあまり同意しないというか、そういうエンジニアにあまり出会った事がないので、そうなんですかねー？という印象です。）
人に興味がある人
懇親会で、エンジニア人事に向いている人ってどんな人だろうという話をしていました。私の考えるエンジニア人事のプロは、ずばり、人に興味があるエンジニアだと思います。とても希少な人種だと思いますが、それが本質かと思います。人に興味があるからこそ、人の事に情熱を注ぎ、精を出せるのかと。
また、とあるエンジニアには、「想いや情熱が伝わってきました」という感想をもらえて嬉しかったです。
今回の私の発表を通じて、私自身に興味を持った人や同じ思いを持った人と出会えるといいなと思ってます。興味があれば、ご連絡ください。
最後になりましたが、今回このような機会をくださいましたRubyアソシエーション様に感謝致します。ありがとうございました！
