読者です 読者をやめる 読者になる 読者になる

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 発表っていうポリシーなんですよー」と仰ってて感銘を受けました。はー、カッコイイ。

自分の発表について

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

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

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

あわせてよみたい

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分枠の発表のうちの一つです。

『取締役の心得』という本を読んだら『論語』を読み出してた。

取締役の心得

取締役の心得

最近、取締役という立場について興味を持っている。経営者とは違う、経営陣の取締役という立場についてだ。そもそも、取締役ってのは、どんな役割なんだろうだとか。執行役員って、取締役と何が違うんだろうだとか。

以前、とある会社の取締役をやった経験や、自分で立ち上げた会社の代表取締役をやった経験もあるんだけど、会社の規模感によって全然違う立場だし、偉そうなことを言うつもりはない。

子曰わく、其の位に在らざれば、其の政を謀らず。

この本を読んで、あらためて自分の経験なんて大したことないと思った部分も多かったが、ほんの少しだけ自分の行動の源泉に触れた気がした。名ばかりの経験であっても、意外とあの経験は今活きていたのだ。

取締役のように振る舞えば、取締役である。しかし任命されない限り、そうは言ってもやっぱり取締役ではない。そりゃそう。

特に印象に残った言葉

  • 一般人では対処できない専門的な事柄を専門科に依頼する契約
  • 子育ての世界では「子は親が言っていることではなく、親がしていることをする」という。同様に社員は経営陣が言っていることではなく、経営陣がしていることをする。
  • 取締役の仕事の大半は、担当している業務分野やビジネススキームに絡むことよりも、現実的には人(特に部下)の心に関することである。
  • 名目上の取締役でも、取締役の義務と責任を追う
  • ピーターの法則(組織の全階層は、やがて無能な人間で埋め尽くされる)
  • 権力を持つ立場になった人こそ、逆に自分に厳しいことを言ってくれる女房役を、意識的に傍におくべき
  • 取締役は、社長と意見対立しても論破してはいけない
  • あらゆる投資の中で、自己投資が最も確実で大きなリターンが得られる
  • 古典や歴史書は教養ではなく、人間の原理原則を知る為に読む

古典や歴史書を人間の行動原理を知る為に読んでみよう、という事で『論語』に関する本を読み始めた。どちらも齋藤孝さんの本。

まんがでわかる 論語 (Business Comic Series)

まんがでわかる 論語 (Business Comic Series)

取締役というのは、「 一般人では対処できない専門的な事柄を専門科に依頼する契約」を会社と交わしているわけだけども、「取締役の仕事の大半は、担当している業務分野やビジネススキームに絡むことよりも、現実的には人(特に部下)の心に関することである。」ということから、「人間の行動原理を知る」ことが大事であるということが一番刺さった。

このよう行動が出来る取締役のいる組織は、組織として上手く回ると思った。「社員は経営陣が言っていることではなく、経営陣がしていることをする」ということから、組織の取締役の行動がその組織なのだ。

取締役の行動を見ることで、その組織で働きたいかどうかを決めるのは理にかなっていそうだ。

esaカテゴリで検索したり統合したり投稿したりするときのTips

やあだね、esa使っているかい?

カテゴリあんじゃん、あれさ、増えてくるとわけわかんなくね?えっとどの辺にあったっけみたいなアレ。 後逆にどこのカテゴリに投稿しよう、、、みたいな気持ちになるアレ。

便利な検索

検索窓におもむろにin:って入力しようぜ。

f:id:naoto5959:20160621093214p:plain

こんな感じで候補が出るので、カテゴリ名を部分一致で検索できる。

例えば、「吉成」が含まれるカテゴリを検索したい場合、検索窓に「in:吉成」と入力すると

f:id:naoto5959:20160621094542p:plain

ほら便利!でも「吉成」が散らばっていることも分かったね。

ちらばったカテゴリを整理だ

  • イベント/吉成

は階層構造的にこれでいいかなと思うけど

  • ポエム/吉成
  • 吉成/ポエム

これはどっちかに寄せたいな。

吉成/ポエム -> ポエム/吉成

に出来るとヨサソウ。んではやってみよう。吉成/ポエムを開いて、カテゴリ名の横の鉛筆をクリック。

f:id:naoto5959:20160621094310p:plain

フォームに変わるので、ポエム/吉成に変更してUpdateする。

f:id:naoto5959:20160621094500p:plain

すると、2つカテゴリがマージされるのです(( ⁰⊖⁰)/)

f:id:naoto5959:20160621094644p:plain

便利っすねー

カテゴリに投稿する

ついでにポエみが高まってきたのでポエム書いておこう。 てなわけで、ポエムカテゴリに移動。

f:id:naoto5959:20160621094850p:plain

右上の[Create new post here]をくりっくだ。

すると、そのカテゴリに設定されたテンプレートがいい感じに反映されて記事投稿フォームが表示される。

f:id:naoto5959:20160621094948p:plain

便利っすね〜、つーかなんでテンプレート適用されてんだよって感じなんですが、templates/ポエム/ナンカタイトル

f:id:naoto5959:20160621095026p:plain

こんな感じでカテゴリ切ったテンプレートを用意してあるとそれがよしなに適用されるんですよね。

まとめ

esa並びに情報は生き物なので定期的にメンテナンスが必要だし、もっというとカテゴリは整理整頓が必要だなと思うのでesaトロールオジサンが組織に最低1人居ると良いと思うんだよね。

(( ⁰⊖⁰)/)ーな

pplogがキッカケで形になった本があるらしい #わかばちゃんと学ぶwebサイト制作の基本

pplogがキッカケ?

まじかよッて感じでずっと楽しみにしていた本がやっと届いた!

ので読みました。読みながらの感想はツイッターに書いてたのでその辺を適当に貼っておく。

まとめ

Webデザインという単語は、知っていて何となくカッコイイし興味を持っている人が、Webサイト制作〜運用までの一連の流れを知る取っ掛かりとしては、すごく良くまとまっていると思った。

Webサイトを作る目的をマーケティング視点で考えてからサイトを作り始める流れもちゃんと押さえつつ、最後には運用時のマーケティングにも触れててヨカッタ。

もしかしたら、子供とかにお父さん(やお母さん)はこういう仕事しているんだっていう説明をザックリする時とかにも良いかもしれない。

たぶん、インターネットの事業会社でもクリエイター以外の人がザックリとインターネットのシステムがどうやって動いているのかなどを知る意味でもスゴくいいなと思った。つまりウチの会社とかでもオススメできる内容かなと思ったのと、湊川さんがこの本を引っさげて新人研修の導入とかしに行くとかいう未来も見えた。ヨサソウ。

随所に割と大事なことがサラッと書いてあって、例えばノンデザイナーズ・デザインブックに書いてあるようなこと。割と頭の中でこうやって整理して理解するわな、みたいなことを綺麗にとめてて、ポイント高い。図解が多いのも、そういう理解するときにこうやるよなーという図が最初から書いてある。だからサラッとしてるのにスッと大事なことが入ってくる。

pplogってのは、

自分の思いを好きなように書ける場所が欲しい。 引用元: 俺たちのゆるふわインターネット「pplog」 をリリースしました(してました) - 納豆には卵を入れる派です。

という想いで作った なので、そこで何か思考が整理されたり、何かを始めるキッカケになったり人生の何かが変わるってのはは自分自身でも本当によくある。自分の作ったそういう場所で同じ想いを感じてくれたことがただ純粋に嬉しい。pplogでポエム書いたおかげでナニカを始めようと思った、みたいなことがただただ嬉しい。ありがとう。

Rubyちゃんが登場してたので、Railsちゃんを見てみたいな。「わかばちゃんと学ぶRuby on Rails」だな。

わかばちゃんと学ぶ Webサイト制作の基本

わかばちゃんと学ぶ Webサイト制作の基本

trelloのboardにwebhookを登録する

雑なWebhook Docsの先にあるAPI referenceも、そっすね、という感想しか湧かないドキュメントで、まあ読めば分かるだけどさって感じ。

てなわけで、どう考えても忘れるので、Webhook登録するだけの作業をまとめておく。

ちなみに、この作業では、https://github.com/jeremytregunna/ruby-trello を使う。

gemをinstall

cd ~
mkdir setup_trello_integration && cd setup_trello_integration
bundle init
echo "gem 'ruby-trello'
gem 'launchy'" >> Gemfile
bundle

下準備

bundle exec irb
require 'trello'
Trello.open_public_key_url # API key が表示される以下で渡すkeyはコレ
Trello.open_authorization_url key: 'yourpublickey'
exit

Trello.open_public_key_urlで表示される画面はこんな。ここのKEYを使うので覚えておこう。

f:id:naoto5959:20160402003946p:plain

Trello.open_authorization_url key: 'yourpublickey'で表示される画面はこんな。OAuthのアレ。よろしければ、Allowを。

f:id:naoto5959:20160402003958p:plain

TOKENが表示されるので、こやつを後で使う。

f:id:naoto5959:20160402004008p:plain

webhookを作る

環境変数に、先ほど最初に取得したKEYと最後に取得したTOKENを指定。

echo "export TRELLO_DEVELOPER_PUBLIC_KEY=************************\nexport TRELLO_MEMBER_TOKEN=*********************************************" > .envrc
direnv allow
bundle exec irb
require 'trello'

Trello.configure do |config|
  config.developer_public_key = ENV['TRELLO_DEVELOPER_PUBLIC_KEY']
  config.member_token = ENV['TRELLO_MEMBER_TOKEN']
end

board_id = Trello::Board.find('****').id # TrelloのURLの`/b/:board_shortlink/*`の:board_shortlinkの部分でboardを探す

callback_url = 'http://example.com' # 普段はPOSTで来るが、Webhook登録時はHEADに200を返すようにしておくこと。
webhook = Trello::Webhook.create(callback_url: callback_url, id_model: board_id)
webhook.id # 設定変更したい場合などに使うのでメモっておく

コメントに書いたとおり、受け側のwebhookは初回だけHEADリクエストに200を返す必要がある。なんなの。

わからん

webhookのid忘れたらどうなっちゃうわけ?