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では技術顧問になっているが、技術フェローが正しい

Misocaにジョインして

はじめまして、2016年11月からMisocaにジョインした開発チームのえんだ(@enda1111)です。 趣味はゴルフですが、東京に居た頃はゴルフが全然できなかったので、主に東京観光してました。
f:id:endash:20170201170332j:plain

今回は初ブログなので、簡単な自己紹介とMisocaにジョインして思ったことを書きたいと思います。

これまでのお話

学生時代は画像処理(移動物体追跡)の研究をやっていて、その流れで新卒で入社した会社では画像処理を使った欠陥検査の開発をやっていました。
その後、スタートアップで働きたいと思い転職を考え、東京にあるスタートアップにWebエンジニアとして入社しました。
Railsを使ったWebアプリ開発やモバイルアプリを主にやっていて、DeepLearningを使った画像分類とかもやっていました。

なぜMisocaにジョインしたのか

もともと名古屋に住んでいたので、名古屋にいつかは戻りたいと思っていたところ Misocaが個別会社訪問イベントを開催してるのを知って応募しました。 選考の過程でメンバーと話す中で、サービスとか自分自身の環境を良くしていこうという気持ちをバシバシ感じ、是非一緒に働きたい!と思って入社を決めました。

Misocaにジョインして思ったこと

新しいことにチャレンジしている

○○を使ってみたい、やってみたいとなると、まず試しにやってみようとなることが多いです。 その後、良い感じなら続けていくし、良くなかった場合にはどうして良くなかったかも考えるし、すごく前向きでとても良いと思いました。

改善を続けている

新しい事にチャレンジするだけでなく、KPTをうまく回していて現状のやりにくい所がどんどん改善されています。 例えばesaのドキュメントのカテゴリー構造も私が入社してからすでに何回か改善されていて、すごく分かりやすくなりました。

Slackによるコミュニケーションが盛ん

Slackに疑問に思うことや相談したい事を書きこむと、すぐに誰かがリアクションをくれます。 オープンな場でやりとりしているので色々な人が話に参加してくれるので、色々な考え方が見れてとても勉強になります。 チャンネルによってはまったく仕事とは関係ない話しも流れてくるので、見ているだけでも面白いです。

仕事を効率よく進めている

みんな定時内に仕事を終わらせようという気持ちがすごく伝わってきます。 会議でも話しがずれていくと、「後で担当者同士で話しましょう」とか軌道修正して時間内に終わろうとしています。 私も見習っていきたいと思っています。

まとめ

Misocaはサービスや働き方を良くしていこうという人ばかりで、とてもやりがいがあり、仕事もやりやすい環境です。
興味がある方は是非一度会社見学に来てみて下さい。

www.wantedly.com

www.wantedly.com

esaの更新通知を適切なチャンネルに振り分ける

こんにちは、mzpです。

先日、Misocaオフィスでesa meetupを開催しました。当日お越しいただいた方々ありがとうございます。 会の様子は以下のような記事にまとめられています。

f:id:mzp:20170126111947j:plain

最近、esaの更新通知を1つのチャンネルに流すのではなく、適切なチャンネルに振り分けるようにしたのでその話を書きたいと思います。

これまでのMisoca

これまでesaの更新通知をSlackの単一のチャンネル(#now_esa)に流していましたが、日報のような更新頻度の高いものの通知で、更新頻度の低い文書の通知が埋もれてしまうという問題がありました。

初期: 標準のWebhook

標準のWebhookの設定を変更して「日報」カテゴリ以下の更新を #now_nippou チャンネルに通知するようにしました。

f:id:mzp:20170126154224p:plain

これにより、日報の更新通知と、それ以外の記事の更新通知が分かれるため、日報がとても読みやすくなりました。 他のメンバーにもかなり好評でした。

f:id:mzp:20170126172149p:plain

同じように、「プロジェクト/なんとか」カテゴリ以下の更新はこのチャンネル、「プロジェクト/かんとか」カテゴリ以下の更新はこのチャンネルという設定をどんどん増やしていきました。こちらもなかなか好評でした。

f:id:mzp:20170126173847p:plain

問題点

しかし通知先が増えるにつれて、以下のような問題が生じました。

  • 「他の箇所で通知してないやつ」という設定ができないので、通知が二重で届くことがある。*1
  • 通知先のチャンネルを変えるには個別にincomming webhookを作る必要があるため、大量のincomming webhookを管理しないといけない。

通知が二重で届くことについては、他のメンバーからも不満がで始めました。

f:id:mzp:20170126173035p:plain

解決策: AWS Lambda

じゃあ自分でやるか、ということでAWS lambdaでルーティングする仕組みを作りました。 名前は伝書鳩からの連想でhatoにしました。

https://github.com/mzp/hato

hatoを使うと、以下のようなことができるようになります。

  • どのパターンをどのチャンネルに通知するかを一箇所で設定できる
  • Slackのincomming webhookは1つあればよい
  • 一致するパターンがあった場合はそこで処理をやめるため、重複して通知されない

今のところ以下のような設定にしています。

module.exports = [
  // 日報は更新量が多いので専用のチャンネルに流す
  { pattern: '^日報', channel: '#now_nippou' },

  // 各プロジェクトの通知はそれぞれのチェンネルに流す
  { pattern: 'プロジェクト/2017/採用', channel: '#talk_recruit' },
  { pattern: 'プロジェクト/2016/xxx', channel: '#talk_xxx' },

  // どこにも通知してないやつは、esaチャンネルに流す
  { pattern: '', channel: '#now_esa' }
]

余談

Webhookの通知テストをしていたら、会社のチャンネルに@さんのアイコンがまざってきておもしろかったです。

f:id:mzp:20170126174158p:plain

採用

Misocaでは情報共有ツールを大事にするソフトウェアエンジニアを募集しています。

*1:厳密にはできないのではなく、「それ以外」を表現する正規表現を簡潔に書くことができない、です

2016年の大みそかを迎えて

こんにちは、マツモトサトシ (a.k.a @Dominion525) です。

今日はア・バオア・クー防衛戦…ではなく年末大みそかです。 そもそもMisoca は晦日(三十日≒月末)に由来しており、なかでも「おおつごもり」と称される大晦日は1年に一度の大事な日だったりします。 そこでいくつかの大きなトピックにについて振り返ってみようと思います。

2月:弥生グループにジョイン

2016年、一番大きかった出来事といえばもちろん上記になると思うのですが、意気込みその他については 開発ブログ1周年&弥生×Misoca - Misoca開発ブログ をご参照ください。

意気込み的なものは取り立てて大きく変わるわけではないのですが、10ヶ月ほど経って雑感を纏めてみます。

よかったこと

  • 財務面の安定
    • いままでは採用面談などでも「うちの会社は来年の今頃は無くなっているかもしれないのですが、そこは覚悟の上でよろしく願いします」って言っていたのが、少なくとも1年とかでどうにかなってしまうリスクはほぼなくなりました。その分後顧の憂いなしにより良いプロダクトを作っていくことに注力出来るようになりました。
  • 人員の増加
    • 従前よりも積極的にメンバーを採用していくことが出来るようになりました。とはいえご多分にはもれずエンジニアが足りない問題みたいなのはありますので、ぜひエントリ よろしくお願いします!
  • いろんなリソースが使える
    • たかだか10数人のMisocaからすれば弥生は大組織です。その中にはいろんな分野の専門家の方がいらっしゃるわけで、今までだと手が届かなかった様々な知見やリソースにリーチすることが出来るようになりました。

あんまりよくないこと(今後改善していきたいこと)

  • ステークホルダの増加
    • とはいっても、関係者は増えます。今まではほぼ独断でできたことが、関係各所と調整のうえで行う必要が出てきたりもします。それは組織力があるということの裏返しなので致し方ないところではあるのですが、できるだけ政治レイヤのオーバーヘッドを縮小して、スピードを維持していきたいと思ってます。
  • システム連係の改善
    • 双方の既存ユーザのベネフィットを増加させてシナジーを得る、というの肝要ではあるのですが、現状ではそこまでシームレスな連係によるバリューは提供できているとはいい難いと思っています。 ので、今後は重点的に改善していけると良いなあと言う感じです。
  • カルチャーのギャップ
    • 事前から予想はしていたとは言え、両者の暗黙的なコンテキストには 異なっている部分がそれなりにありました。大きな話題については事前に協議しているのでだいたいは一致しているんですが、わりと細かい点での齟齬がそこそこの頻度で発生しました。 現状では人的な交流やコミュニケーションを密に行うことによってだいぶ改善はしてきたかと認識しています。とは言え万全ではないので今後も継続的な活動が必要だなあと思っています。

その他、PROS/CONS いろいろあるのですが、細かい部分はオフラインのときに訊いてもらえるとわりといくらでも話します。

9月:RubyKaigi 2016 にスポンサーとして参加

今回始めてRubykaigiに正式なスポンサー(*1として支援しました。 初期のRuby会議から参加はしていたのですが、きちんと支援できたのは今回が初めてです。 単なる地方からの一参加者とだったところから、ここまで成長してこれたんだなあと思うのとわりと感無量的なところがあります。

くわしくはRubyKaigi 2016 参加レポート - Misoca開発ブログ をご参照ください。

10月:松江オフィス開設について

既報のとおり松江に開発拠点を置きました。 - Misocaが島根県松江市に進出、島根県および松江市と調印式を実施

RubyをコアテクノロジとするMisocaとしては、島根県松江市は特別な土地ではありますし、すでに@hidakatsuyaが活発に活動してくれている場所でもあります。

この度島根県松江市の支援も受けつつ、名古屋オフィスだけではなく松江オフィスも発展させていければ、と思っています。 なお、現時点は松江オフィスは物理的な場所が松江にあることを除けば何かに特化した機能をもつのではなく、拡張された開発チームとしてMisocaの開発を行っています。

松江オフィスについては、インターンSaaya HasegawaMisocaの日常-松江オフィス by Saaya Hasegawa | 株式会社Misoca が紹介してくれていますし、活動の様子は今後松江在住で松江オフィスのコアである @hidakatsuyaがいろいろ報告してくれるものと期待しています。

開発チームの現況について

以前の記事 から少し増減がありますのでご報告がてら。

増えた

  • ゆきはるさん / @snowsunny1107

    • 夏くらいからジョインしてくれました。とはいうものの下記の記事にもある通り、Misocaがスタンドファーム株式会社で受託開発とかやっていたときにもお手伝いいただいているので、こんな感じのガレージ(出典:公認会計士ナビ)時代を知る最古参メンバーだったりします。*2
    • 主にReact/Redux 周りの中心としたフロントエンドを扱うことが多いのですが、サーバサイドも頑張ってくれているオールラウンドプレイヤーです。
    • 主な過去のエントリ
  • いっしーさん / @issi_1109

  • えんださん / @enda1111

    • 11月くらいからジョインしてくれました。もともとはC++で画像解析をしてたり、硬派な感じのプログラマでした。その後東京のスタートアップにジョインして、Rails ベースで開発したり、機械学習を活用したデータ分析を行ったりしていたそうです。幅広いスキルに期待ができます。
    • ゴルフが趣味とのことなのですが、スポーツ全般に疎い*3Misocaチームではなかなか一緒にできるひとがいないので、名古屋近辺でゆるくゴルフできる人は誘ってあげてください。
    • 主な過去エントリ
      • まだないので楽しみにしてます!

卒業

これからについて

Misocaでは開発者と開発チームが最大限パフォーマンスを発揮できるように、各人が自律的によりよい環境を模索して運営が行われています。 もちろんうまくいくこともあれば期待通りの成果が得られないこともあるのですが、それらすべてを糧として次の段階に進むように頑張っています。

そんなMisocaとMisoca開発チームを一緒に作ってくれるメンバー*4をぼくたちは求めています。 くわしくは下記を参照してください。 また、エントリまでいかなくてもどんな雰囲気か覗いてみたい、という場合も随時見学を受け付けていますのでお気軽にどうぞ。開発チームのメンバと一緒にランチに行ったりできます。

www.wantedly.com

www.wantedly.com

2017年もよろしくお願い致します!

*1:いままではAdditional Sponsorでした。

*2:その後一旦4年位離れて、再度召還しました。

*3:自転車派とマラソン派とボルダリング派はいます。

*4: マーケティングとか、開発以外の人も絶賛募集しています。