Misocaと富山と私

3月からMisocaにjoinした @mugi_uno です。

joinしたらブログでしょ!という流れに乗って、簡単な自己紹介と所感を書いてみます。

自分について

富山県に住んでいます。

Misocaのオフィスがある名古屋とは、地理的に岐阜県を挟んで真逆に位置しています。 バスで片道4時間弱。遠いですね!

富山を出発して名古屋に着くころには体がバキバキです。体の衰えを感じます。

Toyama.rb

Toyama.rbというRubyのコミュニティを月1程度の頻度で開催しています。 派手な活動はしていませんが、かれこれ1年半ほど続けています。

f:id:mugi1:20170316183204p:plain

富山?

富山県は魚がとっても美味しく、特にブリが絶品です。お越しの際には食べてみてください。

※ブリしゃぶ f:id:mugi1:20161212190811j:plain

魚以外では、ブラックラーメンというB級グルメがあり、かなり塩気が強いため賛否両論あるようですが、私は大好きです。 f:id:mugi1:20120715123012j:plain

リモートワーク

富山と名古屋という位置関係もあり、自宅の一室を使いフルタイムでリモートワークしています。 (ずっと家に居るので、説明出来ていないご近所さんにどう見えるのかは少し心配です)

地方転職とMisoca

転職理由

前職は、いわゆる地方の中小SIerに新卒で入社し、8年ほど働いていました。

ただ、長い間「自社のWEBサービス開発にかかわってみたい!」という考えがあったことと、開発手法など技術的な面でも新しいやり方を取り入れているところに身を置きたいと思っていました。

地方転職の難しさ

最初は地元での転職活動も考えましたが、自分が望むような会社はほとんど都会にしか存在せず、ほぼ困難というのが実情でした。 また、既婚で子供がいることもあり、家族を置いて自分だけ都会に行くというのは選択肢として考えていませんでした。

リモートワークで探す

地方や家族を言い訳に諦めたくはないと思い、リモートワークを視野に会社を探し、フルタイムでのリモートワークを採用している会社として最終的に出会ったのがMisocaでした。

なぜMisoca?

採用活動が本気

まず、採用活動に多くのリソースを割いており、真剣に人を見ていることが伝わってきました。

面談の回数も多く、最終的には名古屋にあるオフィスに直接足を運び、エンジニアと1日関わるという機会もあります。

自分自身も、リモートの面談だけでお互いに理解できるのか?と考えていたので、こういった手順を踏んでいるのは安心できました。

また、代表の豊吉を含め、皆さん真摯な対応で、かつ本気であることが会話していても良くわかりました。

リモートワークへの理解と改善意識

Misocaでは、遠方のメンバーだけではなく、全メンバーが自由にリモートで働くことができます。

そのため、リモートワークという働き方は全員で共有されているものであるため、メリットもデメリットも理解されています。

常日頃からメンバー全員の改善意識も高いため、

  • 思ったことは言おう!
  • 困ったことはガンガン相談して解決していこう!
  • やってみよう!

という文化で、ここでならリモートで困ったことがあってもやっていけそうだな、と思えました。

実際にjoinしてからも、このとき感じたことは間違ってなかったです。

Misocaに入って感じたこと

速い

まずこれを一番に思いました!なによりミーティングのスピードが速い!

基本的に沈黙の時間はありません。

ミーティングというのは参加者全員の時間を並列に奪っていくため、いかに効率良く進めるかを全員が意識しており、かつ実践されています。

豊吉ブログの過去エントリでも言及されていましたが、「それは後にしましょう」というワードは、年齢や役職などは関係なく頻繁に耳にします。 実際に目の当たりにした時には「ひー!これ開発ブログで見たやつやー!!」と思いましたが、すぐに、これが人格否定ではなく効率良く進めるために全員が理解したうえで行われてるんだな、ということが解りました。

夜は帰る

「基本的に残業せずにみんな帰ります」と事前に聞いており、正直なところ心の奥底では「本当かな〜?」と思ってる部分がありました。 実際にjoinしてみると、大半のメンバーは午前10時ごろにオフィスに来て、夜の7時過ぎには帰っていきます。 (時間は人によって多少前後します。私は9時〜18時で働いています。)

残業ではなく、いかに決められた時間内で最大のパフォーマンスを出すかを皆が真剣に考えているからこそ出来ていることだと思います。

改善意識の高さ

Misocaでは複数のプロジェクトが動いており、週に一回プロジェクト単位でのふりかえりが行われます。同時に全体でのふりかえりも行われ、悩みや相談ごとはここで共有されます。内容も

  • ○○というフレームワークが使いたい
  • はじめてプルリクエスト出した!うれしい!
  • 部屋が暑い
  • 備品が足りない

と様々です。

この時に出したActionは次回のふりかえりで進み具合を確認するため、「いつかやりたいけどな〜」で腐っていくことがなく、素早い改善が繰り返されています。

みんないいひと

漠然としていますが、素直に「皆さん良い人だな〜」と思います。slackで困っている人にはすぐに救いの手が飛んできますし、実際に会話をしていても皆さん本当に人格者です。

ミーティング中に少しピリッとしても、終われば普通に笑いあって会話している姿を見ると、メリハリがしっかりしているのも良いなと思えます。

というわけで

f:id:mugi1:20170317185612j:plain

まだ日が浅く、速さについていけず戸惑っているところもありますが、良い環境に来れたと思います。

「joinしてくれて良かった!」と言ってもらえるよう頑張ります!


株式会社Misocaでは、家族が大事な地方で頑張るエンジニアを募集しています!

よいコミットメッセージ・よくないコミットメッセージ

こんにちは、mzpです。

今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。

あらすじ

開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。

ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。

ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。

f:id:mzp:20170313132724p:plain

ファイル移動を移動した事実しか書かない

これは以下のようなコミットメッセージです。

ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 ので、移動した理由を残すようにするとよいです。

  • 責務を適切に表わすファイル名に変更
  • ライブラリのバージョンアップに伴いディレクトリ変更
  • 似た内容のファイルをまとめるためにディレクトリ移動

「指摘対応」としか書かない。

これは以下のようなコミットメッセージです。冒頭にあげたコミットメッセージもこれですね。

  • レビュー対応
  • 指摘対応
  • Rubocop対応

なぜその変更をしたかが後から見たときに分かりません。 指摘があった場合はその内容を残すとよいです。(参考: 自分の言葉で書かれたコミットメッセージが好き - 準二級.jp)

  • 一行が長すぎるので修正
  • Style/IndentHash による自動修正
  • メソッドが長すぎるので修正
  • Array#map を使ってリファクタリング

「修正した」としか書かない

これは以下のようなコミットメッセージです。

  • specを修正
  • CI対応

繰り返しになりますが、なぜその修正をしたかがあとから分かりません。 CIやspecで確認していることをコミットメッセージに残すとよいです。

  • xがnilのケースを想定していなかったので修正
  • specが意図したものになっていなかったので修正
  • CIでの実施内容が間違っていたので修正

コミットメッセージに理由を書こう

Misocaではコミットメッセージに理由を書くエンジニアを募集しています。

Misocaの開発を支える名駅ランチTrelloボード

こんにちは。sunflatです。 最近FF15PS4を買ったのですが、DQ10が忙しくてあまり遊べてません。

さて、Misocaでは開発のタスクや課題を管理するために、Trelloを使っています。

trello.com

付箋感覚でカードを貼ったり移動したりできて便利なので、開発プロセスのふりかえりやブレインストーミングなどにも利用しています。

こんな便利なツールを、開発のためだけに使うのはもったいない!

ということで、Misocaオフィスが名古屋駅に引っ越した時から、オフィス周辺の昼食が食べられるお店をTrelloで管理するようになりました。

f:id:sunflat:20170224145156p:plain

「いってみたい」リストに気になるお店の情報を書いておき、そのお店に行った人は、感想や写真をコメントに書いて「いった」リストや「2回以上行った」リストに移動する、という仕組みです。

Misocaオフィスから近いお店の一覧がすぐに分かるし、新しいお店を新規開拓するモチベーションのアップにもつながるので良いですね。

というわけで今回は、Misocaオフィス(名古屋駅)周辺の、僕のお気に入りのランチスポットを紹介します。

担々麺

杏亭

http://tabelog.com/aichi/A2301/A230101/23009093/

f:id:sunflat:20170227102226j:plain

他のお店の担々麺とは違う、何か独特のスパイスの味がして、クセになる美味しさ。

それほど辛くはないので、辛いのが苦手でも大丈夫かも(ただし油っこい)。

汁有り担々麺と汁無し担々麺がある。汁無し担々麺は一見量が少なめだけど、実は結構多い。

ランチタイムはご飯無料サービス。汁が服につくとやっかいので、紙エプロンをもらったほうが良い。

カレーライス

ERICK SOUTH

https://tabelog.com/aichi/A2301/A230101/23060430/

f:id:sunflat:20170224153319j:plain

南インドカレーのお店。オフィスから近いので良く行く。

パリパリしたせんべいみたいなやつを割って、カレーとご飯に混ぜて食べるとクリスピーで美味しい。

いくつかのカレーのなかから3種類をチョイスできるセットがお気に入り。

ただし、ラムカレーはかなり辛いので注意が必要。

レジの横に置いてある口直しのスパイスは、刺激が強いので一気に口に含むと危険。

肉餃子 THE GYO

https://tabelog.com/aichi/A2301/A230101/23060136/

f:id:sunflat:20170224154837p:plain

肉餃子の専門店なのだが、ランチタイムにはカレーライスやザーサイ等が食べ放題で、しかも値段がセットで580円〜と非常にお得。

肉餃子は、汁がたっぷり入った小籠包風の皮が厚い餃子。オフィスのメンバーにはあまり好評ではないけど、個人的には悪くないと思う。

カレーライスは安心できる普通の味。むしろこっちがメイン。カレーライスをお腹いっぱい食べたくて、しかも財布がピンチの時には、この店がおすすめ。

もうやんカレー

https://tabelog.com/aichi/A2301/A230101/23059172/

色々なカレーやおかずが食べ放題のお店。

カレーは濃厚。とても美味しいのだが、食べ過ぎて行動不能になってしまうので、午後は早退する覚悟で食べに行く必要がある。

海鮮丼

めしの助

http://tabelog.com/aichi/A2301/A230101/23054149/

f:id:sunflat:20170227103133j:plain

値段がちょっと高めだけど美味しい。

でも、いつも混んでて行列ができているので、なかなか行く機会がない。

雰囲気がよく、安心できる味。お客さんを連れていく場合に良いかも。

さかなやま

https://tabelog.com/aichi/A2301/A230101/23004280/

海鮮ちらし(数量限定)が、ボリュームもあって美味しい。

入り口で札を取って入店するシステム。お目当てのメニューの札が無くなっていたら諦めよう。

魚正宗

https://tabelog.com/aichi/A2301/A230101/23031848/

漁師丼がリーズナブルで美味しい。

量も多め。おでんが無料でついてくることもあった。

明日のMisocaのランチを支えるのは君だ!

オフィスが名古屋駅に引っ越してから半年以上が経ち、最近はあまり新規のお店に行かなくなってしまったように思います。

株式会社Misocaでは、入ったことのないレストランにも果敢に入店する探究心のあるエンジニアを募集しています。

Ruby経験の浅いエンジニアだけど名古屋Ruby会議03が思いのほか楽しかった

こんにちは。いっしーです。

2/11(土)に開催された名古屋Ruby会議03に参加してきました。

f:id:issi_0x0:20170222193046p:plain

Rubyといえば、Misocaとは切っても切り離せない関係です。
名古屋Ruby会議03でもスポンサードしたり、Misocaメンバーが実行委員や発表者として参加しました。

そして、なんと今回は大須演芸場での開催。 私は11月にRubyを始めたばかりなので、楽しめるか不安な部分もありましたが、 発表内容はもちろん、演出もとても凝っていて面白かったのでレポートしたいと思います。

会場は満員御礼状態

当日は非常に寒く、朝から雪がちらついていました。そんな中、演芸場前では今回のスポンサー企業ののぼりがずらりと立っていました。弊社の正式名称は「株式会社Misoca」ですが、会場の雰囲気に合わせて漢字表記にしました。

f:id:issi_0x0:20170223104128j:plain

中に入ると左右正面に赤提灯、舞台には見台とスクリーン。これまで参加してきた技術系イベントのどれとも違う、とても風情の感じられる会場でした。

f:id:issi_0x0:20170222193251j:plain

参加者は70名程度で県内と県外で約半々。とはいえ、顔馴染みの方も多いようで、発表以外の時間もみなさん積極的に交流していらっしゃいました。

席は午前中は1階の座席のみでしたが、お昼からは2階の桟敷席も開放されました。

また、演芸場という会場柄、飲食やカジュアルなドリンク*1も嗜むことができるということで、それらと共に2階に消えていく方もちらほら。

いい意味で常識破りなイベントに期待が高まります……!

印象に残ったセッションはこれ!

Ruby/Railsはじめてチームの力をメキメキつけた!(小芝さん)

このセッションでは、RubyRails未経験メンバーのみで構成された開発チームが、1ヶ月でスループットを6倍にするまでの取り組みについて紹介がありました。 私自身がRubyRailsも初心者なので、どういった取り組みをされたのか非常に気になりました。

具体的には、以下の取り組みを行ったそうです。

  1. issueを終わらせる
  2. ペア作業習慣をつける
  3. デプロイ方法の統一
  4. 開発環境の統一
  5. ドキュメンテーション

ペア作業習慣については、先週のMisoca開発ブログでもペアプロのノウハウがいくつか紹介されましたが、 発表の中で印象に残ったのは若手同士でもペア作業を行う、というものでした。 普通に考えると 自分よりも技術に理解のある人と組むものだと思っていたので、目から鱗でした。若手は一人で作業していると煮詰まりがちなので、ナビゲータが「別の人に質問しにいこう!」ときっかけを作りやすい、という理由には納得でした。

また、次のNGワードを使わないというルールを定めたそうです。

  • 当然
  • 普通
  • 当たり前

わからない人にNGワードを言っても話が先に進まないだけでなく、質問することに対して不安が生じてしまうため、良いことは何もない、というお話で、確かにな〜、と思いました。ペア作業習慣のところで「普通に考えると」を取り消したのはそういう意図でした。

どの取り組みも具体的で、気軽に真似してみようと思えるものばかりでした。

ぺろぺろ: Github pull request bot framework(mzp)

Misocaからは@mzpが登壇しました。

内容は、GithubのPull Request通知をslackのbotに流すフレームワークについてで、Misocaでの使用方法も交えて紹介されました。発表スライドはこちらをご覧ください。

発表中、まくら(イントロのこと)が終わった段階で「足が痺れた」と足を崩し、twitter上で一斉にツッコミが入る様がいかにもIT系イベントな感じで好きでした。 また、それを見て、どこからともなく座椅子を出してくれる運営の方の気配りがすばらしかったです。

Fight with growing data on Rails(joker1007さん)

@joker1007さんのセッションではRailsとデータベースに関する知見が紹介されましたが、「お金をつぎこめばスケールできる基盤に早いうちからしておくことが大事」という言葉が印象に残りました。

プロジェクトのスケジューリングについても似たような話を聞いたことがあるので、「〇〇(リソース)をつぎ込めばスケールできる××にしておくことは大事」はテンプレート化できるのかもしれないですね。

永和システムマネジメントさんのスポンサーLT

@yucao24hoursさんのスポンサーLTが、スライドを使わず語りのみで、本物の落語のようで格好良かったです。

2017年、この演出がすごい

会場に合わせた演出がすばらしかったです。

寄席文字のめくり

寄席文字は、橘流寄席文字というもので創始者の直弟子の人が書いてくれたものだそうです。すごい…!

発表者登場時の出囃子&太鼓

出囃子は音源でしたが、太鼓は生音だそうです。どおりでセッションを重ねるごとに表現力が増していたわけです。納得。

発表が「まくら」「本題」「オチ」の構成になっている

f:id:issi_0x0:20170223182830j:plain

写真は須藤さんのセッション。

大喜利(パネルディスカッション)

f:id:issi_0x0:20170222193308j:plain

大喜利という名のパネルディスカッションは、見た目も笑点さながら。
内容は始めこそ「今回のRuby会議の感想は?」とパネルディスカッションらしいものでしたが、途中から本当に大喜利になっていて面白かったです。

お題「『すごーい』といってください。『何がすごいんですか?』と聞くので、入ったすごい機能を答えてください」

大変笑わせていただきました。

光る細かい芸の数々

他にも、

  • まくらのあとに羽織をするりと脱ぐ
  • 噺の区切り区切りで小拍子をカーーンッってする
  • 発表者が去ると、透かさず運営メンバーがめくりをめくりに現れ、次の発表者のために座布団を裏返して舞台裏にもどっていく

など、細かい芸が光っていました。

正直なところ、演芸場は敷居が高く近寄りがたいイメージがありましたが、 今回の細かな演出や周りの観客と一緒にわいわい噺を楽しむ様子を経験したことで、普段の演芸場にも足を運んでみたくなりました。

大須演芸場は一度閉鎖したものの、復活して頑張っている演芸場です。今回が初めてのIT系イベントだったそうですが、是非今後も使ってほしいとのことでした。

名古屋Ruby会議03の演出や大喜利など当日の様子が気になった方は、twitter#nagoyark03を遡ってもらえると雰囲気が伝わってくると思います。

自分が発表する機会に参考にしようと思ったTips

発表者の方々の発表方法も勉強になりました。自分が発表する機会がきたら使いたいと思います。

  • 須藤さんや三浦さんの発表から
    デモをするときは、「デモ」と書かれたスライドの他に、デモで実際に実行するコマンドと実行結果を載せたスライドを用意しておく。 こうすることで、デモが動かないときも発表を続けられ、さらに実行するコマンドを忘れた時のカンペにもなる。

  • 咳さんの発表から
    スライドの話題転換時に、あえて「少々お待ちください」と書かれたスライドを入れる。 そのスライドの右下には「羽織を脱ぐ」や「時間を確認する」など、その時々でやることを書く。 こうすることで、発表者は状況を、聴衆は情報を一息ついて整理することができる。 これは界隈では「原メソッド」と呼ばれていて、とちぎRuby会議01の原さんの講演で広く知られるようになったそうです。

まとめ

初参加のRuby会議でしたが、次回も参加したいと思えるイベントでした。 ただ、自分の知識不足も痛感したので、勉強を続けていきたいです。

私の失敗だった条件演算子(?:)とif式の話が引用されただけでなく、咳さんの講演でネタとして昇華されて報われた気持ちになりました。

Misocaではif/elseと条件演算子の使い分けに一家言あるエンジニアを募集しています。

*1:業界用語でビールのことを指します。

技術フェローが名古屋を流していたのでペアプロの手ほどきを受けたら捗った

Misoca開発チームの黒曜(@kokuyouwind)です。
先日大須演芸場で開催された名古屋Ruby会議03ではTwitterでひたすら実況していました。大喜利が思った以上に大喜利で面白かったです。

流しの技術フェローに教わったペアプロのコツ

先日、弊社技術フェローのkakutaniさん(@kakutani)からペアプログラミング(以下ペアプロ)のコツを教わり、社内でのペアプロ機運が高まっています。
今回はkakutaniさんから教わった内容のまとめと、教わったことを意識してペアプロをして感じたことなどをまとめていきたいと思います。

f:id:kokuyouwind:20170215153602j:plain

スループットをあげるためのペアプロ

最初に、大事なこととして「ペアプロは監視やOJTではない」ということを強調されました。
つまり、片方が作業しているのを他方が監視しているだけ、あるいは学ぶために見ているだけではペアプロではない、ということです。

逆にペアプロの目的として、「スループットを上げること」が重要だという話をされました。
タスクは完了させてユーザーに届いてこそ価値があるので、2人で並行して作業し仕掛りを増やすよりも、1つずつのタスクを確実に完了させてスループットを上げていくべきです。
このために、ひとまとまりのコードを書き終えてからコードレビューに進むのではなく、書かれたコードを片っ端からコードレビューしていくことで、コードレビューでのコミュニケーションコストや手戻りを減らすためのプラクティスがペアプロだ、ということです。
他にも「一緒に作業していることで継続的に引き継ぎやTipsの共有がなされる」といった話もありましたが、個人的には継続的コードレビューという考え方が面白く、ペアプロの考え方が変わった気がします。

ペアプロの持ち物

f:id:kokuyouwind:20170216111210j:plain

ペアプロの際、以下のようなものを準備しておくと良いそうです。

水や飴

ペアプロ中はしゃべりっぱなしになります。これは非常に喉が乾くので、水などの飲み物や飴を用意し、いつでも喉を潤せるようにしておきます。

紙とペン

セッション開始時のやることリストを書いたり、考えを図で書いたりできるよう、紙とペンを用意しておきます。
これはさっと書き込めればiPadやWeb上のツールなどでも良いそうです。

デカいディスプレイ

大きめのディスプレイがあると、二人で一緒に画面を見やすくなります。

その他

1台のマシンを2人で使うと、場所の交代が面倒だったりキー配列の違いで思った通りに打てなかったりします。
こういった場合にScreenheroを使うと、それぞれのマウスとキーボードを使って同じ画面を操作できるため便利です。

また、今回は実践していませんが、ペアプロした際のコードのauthorがそのペアが共同で書いたことを明確にするために、専用の名前を用意するというプラクティスも紹介されました。 有名なものではCarlhudaやtomhuda、 kakutaniさんの身近な例ではursmhbryなどがあるそうです。

ペアプロの進め方

f:id:kokuyouwind:20170216111311j:plain

ペアプロの際、主に実装する方をドライバー(Driver)、もう一方をナビゲーター(Navigator)といいます。
基本はドライバーの実装作業をナビゲーターが見ながら適宜コメントをしていくことになりますが、以下のような点に気をつけたほうがよいと勧められました。

セッションでやることをリストにする

実装作業に入る前に、今回のセッションでやることをノートなどにまとめ、ドライバーとナビゲーターで合意します。
これにより、ドライバーとナビゲーターでゴールの認識を合わせることができ、また作業漏れも防ぐことができます。

ドライバーは「やろうとしていること」を話し続ける

ドライバーが実装する際には、「どういう意図でなにをしようとしているか」を話し続けます。
これをすることで、

  • ナビゲーターにどういう意図で作業をしているのかが伝わる
  • 実装が進む前にナビゲーターからよりよい方法の提案や懸念点の提示などができる

といった効果があります。 実際にやってみると、事前に想像していた以上に喉が乾きます。 ペアプロを体験した他のメンバーからも、「冗談抜きで、水、だいじ」という感想が寄せられました。

f:id:kakutani:20170217091447p:plain

操作権を頻繁に譲り合う

ナビゲーターがアドバイスをする際、typoの修正など簡単なもの以外では、なるべくドライバーがキーボードやマウスの操作権を譲ってあげるとよい、という指摘を受けました。
これは、指示を出して何かをしてもらうよりも直接操作したほうが早いのですが、「ナビゲーター側が操作権を要求する」よりも「ドライバー側から操作を譲る」ほうが心理的な抵抗感が少なく望ましい、という内容でした。
また同様に、ナビゲーターがドライバーの作業を止める際の合言葉を決めておくと、自分から割り込むことへの心理的障壁を下げられる、という話もされました。

ペアプロしてみた感想

ここまでの内容を意識して何度かセッションをしてみたところ、「ドライバーがやろうとしていることを話し続ける」というプラクティスで早めに軌道修正ができるようになり、手戻りが減って効率よく実装が進むようになりました。
まだきちんと計測できていませんが、主観としては手戻りや詰まることが減ったことで、チームとしての出力も上がっているのではないかと思います。

リモートでのペアプログラミングも試してみましたが、こちらもScreenheroでの画面共有を使ってスムーズに行うことができました。
ただしペアプロの画面だけを映してしまうと相手の顔が見えず、コミュニケーションが少ししづらい場面がありました。

このあたりは並行してGoogle hangoutsを映したり、Pragmatic Bookshelf『Remote Pairing』を参考にしながら色々試してみたいと思います。

まとめ

ペアプロの際、今回紹介したことを意識しながらやると密度が非常にあがりました。

kakutaniさんのペアプロは、10年以上前に双人亭らい音師匠(@t_wada)から稽古をつけてもらった経験を基礎として独自研究を重ねたものだそうです。双人亭一門のkakutani流ペアプロ、オススメです。

ペアプロの他の流派の考えかたについては、結城浩さんのyukiwikiのペアプログラミングのやりかたの記事や、書籍では残念ながら現在は入手困難ですが『ペアプログラミング―エンジニアとしての指南書』を参考にすると良いそうです。

Misocaではペアプロスループットを上げたいエンジニアを募集しています!

2/22に東京で行われる「名古屋ITベンチャーNight」へ行きますので、ペアプロの話やMisocaの話や技術書典2の話(おやおや?)をしたい方はぜひお越し下さい。

及川卓也氏のプロダクトへの想いとプロダクトマネジメント

こんにちは、Kosukeです。:)

IncrementsのQiitaプロダクトマネージャー及川卓也さんがMisocaへいらっしゃったので、インタビューさせて頂きました! f:id:Kosuke7:20170203142556j:plain (左から共同創業者 松本、及川さん、代表 豊吉、Kosuke)

及川卓也氏のプロフィール

一般社団法人情報支援レスキュー隊 代表理事。東京出身。早稲田大学理工学部卒。

専門だった探査工学に必要だったことからコンピューターサイエンスを学ぶ。

卒業後は外資系コンピューター企業にて、研究開発業務に従事。米国マイクロソフトに派遣され、Windowsの開発を行う。その後もWindows関連のプロジェクトに関わっていたが、どうせWindowsの仕事をするのならと、マイクロソフト株式会社(当時)に転職。 マイクロソフトではWindowsの開発を行い、最終的には日本語版と韓国語版のWindowsの開発の統括を務める。

2006年にグーグルに転職し、9年間ほどプロダクトマネージャーとエンジニアリングマネージャーとして勤務した後、2015年11月に退職。

2011年の東日本大震災後に、災害復興支援や防災・減災にITを活用する活動を開始。Hack For JapanおよびIT×災害コミュニティの発起人。

また、個人的にスタートアップ企業や社会起業家NPOなどに技術的なアドバイスを与えている。2016年よりIncrements株式会社へ入社、プロダクトマネージャーとして従事。

wantedlyxnagoya.connpass.com

ユーザーに焦点を絞れば、他のものはみな後から付いてくる

——どういった想いを持って、過去にGoogleで関わったプロダクトや、現在のIncrementsのプロダクト作りに取り組んでますか?

ユーザー中心

Googleの時とIncrementsの時とで共通しているものもあれば、若干違うものもあります。私はGoogleのミッションである「世界中の情報を整理して、世界中の人々がアクセスできて使えるようにすること」に対する共感が非常に強く、この考え方がとても好きです。

Googleのエンジニアやプロダクトマネージャーの8〜9割はお金のことを考えなくてもいいんです。Googleが掲げる10の事実のひとつに「ユーザーに焦点を絞れば、他のものはみな後から付いてくる」というものがあり、Googleにはユーザー中心という考え方がしっかりと根付いています。

私が最後に担当していたChromeも、実際にはビジネス版があったり、色んなプロダクトに絡んでGoogleの収益になる仕組みはありました。でも、プロダクトを作っている間はお金のことは考えずに、ひたすらユーザーのことだけを考えて作ればよかったんです。

「安全・安心・快適」

ビジネスモデルとしては、ChromeAndroidのようなオープンソースのものは、風が吹けば桶屋が儲かる理論なんです。要は健全にインターネットが発展していくことによって、多くの人が安全に、安心感を持って快適にインターネット上で過ごすようになり、そうするとその内の何人かはモノを知る為に検索し、その内の何人かは広告をクリックし、そうするとGoogleにお金が入る…というように設計されています。

我々Chromeチームがやるべきことは、ユーザーに「安全・安心・快適」にインターネットを操作して頂くことでした。それだけを考えてプロダクト作りにフォーカスしていました。

検索チームも同様です。検索担当のエンジニアは広告クリック率を全く考えておらず、ひたすらオーガニック検索の質を上げることだけにフォーカスしていました。一時的に広告収入が下がるかもしれないけど、絶対にユーザーに利便性を与えて正しいことをしていれば、最終的には収益にも結びつくはずだと考えていました。

Googleはオープンなインターネットの会社であり、Webの会社です。オープンであることが民主主義を進めることになり、それによってより良い社会になり、より良い世界になると考えています。そういったところの一員になりたかったし、一員になることができて嬉しかったです。

プロジェクトの中で色んな機能を入れる入れないという話はあるんですが、全ての根本はユーザーにとって、社会にとって、より良いものを作っていくことだと考えています。

f:id:Kosuke7:20170210143308j:plain

スケールすること

他にもGoogleには面白いところがあります。

Googleはスケールすることを大事にしています。何かプロダクトを作ろうと考えた時、将来的に10億人使うかどうかで投資するかどうかを決めます。ユーザー数10万人を頑張って15万人にするのではなく、ユーザー数10万人を3ヶ月で100万人にして、1年後には1,000万人にするような計画を立てないといけないんです。スケールすることが常に問われます。

スケールするかどうかを考えた時、発想を思いっきり変えないといけないんです。10%増はちょっとした積み重ねでできますが、10倍にしよう、100倍にしようとした時には、何かのルールを変えないと絶対に達成できません。Googleでは常にそういったことを期待されていて、厳しい時もありましたが、とても楽しかったです。

Googleにいた頃、次に何をやりたいかを考えた時に、プロダクトを作る技術者を応援したいと思いました。自分の中でアイディアはありましたが、IncrementsのQiitaでできるところと被るところがありました。自分で起業するより、既に優秀なエンジニアがいるIncrementsへ合流することに決めました。

チームとして、同じようなビジョンとミッションを持っているか確認をする必要がある

——ビジョン・ミッション・目指すゴールが明確になっている中で、プロダクトマネージャーとして、良いアイディアを出す、もしくはチームから引き出す秘訣やアイディアをどうやって実現に結びつけるか、そのプロセスの中でどんな問題が生じて、どう乗り越えてきたか、教えてください。

ビジョンの絵を描く

一般的にビジョン・ミッションがしっかりしていると言いながら、実際は結構しっかりしていないことが多いです。どういう意味かというと、自分が腹落ちして分かっていても、他のメンバーは微妙に違っている場合があります。

例えば、チームのメンバーで集まり、ビジョンの絵を描いてもらうやり方があります。「5年後、このサービスがどうなっているか?」というお題で実際に絵を描いてもらうと、違うものが出てくる場合があります。それを多様性として受け入れることもあれば、認識が違っているので軌道修正していく必要がある、と気づくこともあります。

他のやり方としては、アジャイル開発プラクティスの一つである「インセプションデッキ」というものがあります。「なぜ我々はここにいるのか?」など、前段のところをしっかりと議論しておくことが大切です。このような方法で、チームとして同じようなビジョンとミッションを持っているかを確認する必要があります。

ボトムアップでできるだけ意見を吸い上げる

「こういったものを作り上げたい」といった時に、現状どういった課題があり、何を価値として出したいかを議論して、それをどういった順番で出していくか。この流れをロードマップとして作っていきます。ロードマップを四半期毎に落とし込んでいきたいのであれば、OKRというフレームワークを使い、達成したいものと達成の進捗を追っていきます。これが一連の流れとなります。

これをトップダウンで言うのは簡単ですが、チームメンバーが腹落ちしていない場合もあります。プロダクトマネージャーがいくら経験があり優秀だとしても、間違っていることとか、他のメンバーからもっと良いアイディアが出てくることがあります。トップダウンで決めるよりは、ボトムアップでできるだけ意見を吸い上げていった方がいいと考えています。

そのやり方としては色んな方法がありますが、一つは自分のアイディアを全部話すのではなくて、できるだけ他のメンバーから意見を出してもらうようにします。そうすることによって、自分が気づいていなかったことに気づかされることがあります。

f:id:Kosuke7:20170206145206j:plain

ときにはマクドナルド理論も使う

もう一つとして、逆にボーンと何かを言っちゃうという方法があります。「マクドナルド理論」というものがありますが、ランチ何にする?という話になり、みんなが「なんでもいいよ」と言った時に「マクドナルドにしよう」と提案すると、「いやいや、とんかつが食べたい」と別の意見が出てきます(笑)。

例えば、サービスが伸び悩んでる時に「もうこのサービスはやめようか」と話をすると「いやいや、ちょっと待ってくれ」となり、(もう一度成長させる為に)アイディアが出てきます。

あらゆる方法を使って、議論を活性化して、色んなアイディアを出していくことが重要です。Incrementsではさまざまなプロセスを取り入れており、その中の一つにビジネスモデル・キャンバスからサービスとユーザーの部分を取り出した「バリュー・プロポジション・デザイン」という手法が気に入ったので、使い始めています。

日本にもう一つ欠けている大事な部分はプロダクトマネージャーである

——Japan Product Manager Conferenceを開催されたり、様々なイベントに登壇されたり、積極的にプロダクトマネジメントの重要性を日本で広げようと活動されておりますが、どのような未来を描いていますか?その原動力は何でしょうか?

世界はソフトウェアでできている

Incrementsに参加した理由と似ているところがありますが、私は広義の意味での技術者がもっと日本で評価されるようになり、その人たちが力を発揮できる社会になればいいと思っています。異論があるかもしれませんが、世界はソフトウェアでできています。要は、今は色んなものが何から何までソフトウェアで動くようになっています。

しかし、日本はなぜか変な技術者のピラミッド構造があり、下位層に実装できるエンジニアがいて、中間層にSEがいて、上位層に(実装しない)コンサルタントがいる状況です。シリコンバレーはこれとは真逆な状況であり、実装できるエンジニアが最も評価されています。実装できるエンジニアと(プロダクトマネージャーのような)実装者でなくても世の中に良いものを作ろうとこだわり続ける人たちが評価されるようになってほしいです。

Google在籍時に採用をやっていて感じたことは、日本にも優秀なエンジニアが増えてきている事です。小学生や社会人のプログラミング教育も始まってきており、気運も高まっています。

日本にもう一つ欠けている大事な部分

プロダクトを作る為にはエンジニアだけでなく、デザイナーやプロダクトマネージャーが必要です。ここで本当に使われるプロダクトやサービスを作ることができます。エンジニアはエンジニアで応援しつつ、日本にもう一つ欠けている大事な部分はプロダクトマネージャーであると考えているので、ここを日本でも確立していきたいです。

他のプロダクトマネージャーと一緒にコミュニティを作り、評価システムだったり、人材育成だったり、色んな足りないものがたくさんあるので、そういったことを考えていきたいです。それが、あえて色んなところで登壇したり、記事を書いているモチベーションです。

読者へのメッセージ

——最後に、プロダクトを通して世の中を良くする為に行動している方々へ、メッセージをお願いします!

ものづくりは本当に楽しいですよね。プログラムを書いて、動くと楽しいですよね。その次に、自分が作ったものを誰かが見てすごいねと言ってくれたり、使い続けてくれると本当に嬉しいですよね。そういった想いが大切です。

喜んで使い続けてくれるものを作り続けていくことで世の中も良くなっていき、ものづくりを愛してる人も報われるので、そういったことを一緒にできると嬉しいなと思います!

インタビューを終えて

インタビューを通して及川さんの情熱が伝わってきて、私もエネルギーがみなぎってきました!及川さん、惜しみなくプロダクトへの想いやご経験をシェアして下さり、本当にありがとうございました!私もMisocaもより良い世界にしていく為に頑張ります!

f:id:Kosuke7:20170203142628j:plain

Misocaにはあなたの力が必要です

Misocaは「世の中を仕組みでシンプルに」というビジョンを持ち、「事業者間の取引を最適化する」をミッションとして、ゴールの一つとして「事業者間の商取引プラットフォーム」を創ることを目指しております。Misocaにはあなたの力が必要です。共に「事業者間の商取引プラットフォーム」を創りましょう!

2/22(水)Wantedlyオフィス@東京で「名古屋ITベンチャーNight Vol.1」やります!お待ちしております!

wantedlyxnagoya.connpass.com

www.wantedly.com

www.wantedly.com

技術フェローが「すごーい」「そうなんだー」「たのしー」しか言わなくなった件

こんにちは!
Misoca開発チームのめろたん(@renyamizuno_)です!

最近、いわゆる「トゥルーワイヤレスイヤホン」というのを買いました。
ボタンを2回押すとアシスタント機能(OK Googleとか)が立ち上がるのですが、 僕の場合は

「null」が立ち上がりました*1

はい。

たーのしー!

最近、「けものフレンズ」なるアニメが流行っていますね!

その影響をもろにうけていてMisocaちほーでも「たのしー!」とか「すごーい!」とかがすごーい流れてます。

f:id:renya-mizuno:20170209174912p:plain

その波はとどまること無く、オフィスに来ていた技術フェロー*2@kakutaniさんにまで流れていたようで、

のようにミーティング中も「すごーい!」と連呼していました。

フレンズ文法すごーい!

その流れで昼食の時に「けものフレンズヤバイね」っていう話をしていました。 Kakutaniさんいわく

  • フレンズ文法は、基本的にポジティブにフレーミングした上で発言する文法だ!
    • 〇〇が苦手なフレンズなんだね!へーきへーき!フレンズによってとくいなことちがうから!
    • 〇〇が得意なフレンズなんだね!すごーい!
  • 謙虚(Humility) 尊敬(Respect) 信頼(Trust) だ!

と語っていました!

HRTについてはTeam Geekにくわしくかいてあるよー!すごーい!

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

だって!

みんなもフレンズ文法をつかってたーのしーチームつくっていこうね!

採用

Misocaでは一緒にプロダクトをつくるフレンズを募集してます!

2/22には東京ちほーでイベントもあるからみんなきてね!

wantedlyxnagoya.connpass.com

*1:英語の発音が苦手なフレンズなので「ヌル」っていったら「メル」って検索されました

*2:mzpのtweetでは技術顧問になっているが、技術フェローが正しい