メルカリのValueの自分なりの解釈

この前の評価の時期に整理した内容。少し遅くなってしまったが書いてみた。 評価について、特にメルカリでは360度評価的に近いPeer Reviewも実施している。その際にもValueに基づいてFeedBackするのがベースになっており、Valueについて改めて考える機会と言える。
というわけで自分なりのValueの考え方を整理してみた。

3つのValue

おさらいだけど、メルカリのValueは以下の3つ

  • Go Bold(大胆にやろう)
  • All for One(全ては成功のために)
  • Be Professional(プロフェッショナルであれ)

実はこれ以上の説明はない。各Valueについて敢えて細かく具体的な整理をしないのは経営の意図したものだ。 各人が各Valueはどういうものなのか考え・議論し、体現していくことによって会社のアウトプットに繋がる。 というわけで自分なりに考えてみるが、自分の中でのポイントは
「それぞれのValueの関連性はじゃんけんみたいなものである」
ということだ。

Go Bold or not ?

たまに聞かれる事として、「GoBoldかどうかの定義が欲しい、でないと他人にGoBoldか否かを伝えられない」とかがある。 これに対しては、各Valueはそれ単体で Yes/No という見方をするものではないと思っている。 もし各Valueの定義がありそれに沿って伝えるのであれば、例えば「あなたはGoBoldじゃない」という使い方をするということになる。しかし、それを伝えたとしてその人のためになるか?そうは思わない。是正という形でその人のアクションが狭まるだけである。 じゃんけんみたいと言ったのは、

  • Go Boldが過ぎれば Too Boldに
  • All for Oneが過ぎれば 主体性のなさに
  • Be Professionalが過ぎれば 固執した動きに

それぞれ繋がってしまう脆弱さが各Valueにはある。 Go Boldと言って無茶な事をするのは良くない。良くない事をどう計るかで言うと、「それはAll for Oneなのか?」という軸になる。大胆な行動は成功のために行うべきでそれを見過ごしてしまわないように「All for Oneを意識しましょう」と伝えられる。

「GoBoldじゃない」
と言って相手の行動を制限するのではなく、
「All for Oneを意識しましょう」
と言ってBoldさをより良く伸ばしてあげる方が相手のためになるハズである。

All for One

All for Oneを意識しすぎると、主体性がなくなったり、思考停止してしまいがちである。「(成功のために|皆のために)これを (している|しなければならない) んだ!」という考えや行動は一見立派だが、それが偏りすぎると相手への強い押し付けになったり、あるいは自身のアクションが凝り固まってしまう。 そんな時にBe Professionalを意識すると、「この仕事は本当に依頼すべきなのか?自分でもっとできることはないのか?」だったり、「自分が持っているこのタスクは実は捨てられるのではないか?」という気付きだったりが生まれると思う。

Be Professional

Be Professionalはエンジニアとしてやはり頭に入ってきやすい。だからこそ日々考えていく必要がある。 誰しもクラス設計について延々と悩んだり、テストカバレッジをひたすら上げまくる、ということをやったことがあるはず。アーキテクチャの拡張性や保守性を考えれば考える程設計に悩み、テストを増やし、というアクションに走りがちである。そしてきっと多くの人が、それでも考慮しきれない変更ケースや未知のバグにぶち当たったと思う。結局完璧なものなど作れないのは仕方なく、それを追い求めるのはToo Professionalだと思う。
そんな時に「もっとGo Boldに」と言ってもらえることで、開発はあくまで手段であること、リスクテイクの判断、そして何よりビジネスやお客様の重要性を思い出せるようになる。

ループではなく、スパイラル

こんな感じで話はGo Boldに戻ってくる。これは無限ループではなく、スパイラルである。 これらを繰り返しながら「新たな価値を生み出す世界的なマーケットプレイスを作る」というミッションに取り組んでいくのがValueの意味だと思う。

もっと明確に定義すべきではないか?の話に戻ると、そもそも多様な人材がいる中で、各人にとって基準が違うのは当たり前で、エンジニアがやる開発ひとつとってもPMから見たらBe Professionalになるかもしれないし、同じものを他のエンジニアが見た時に技術的にもっとGo Boldにできるのではと見えるかもしれない。どちらも正しいし、どちらを伝えるのもその人のためになるだろうと思っている。

上記はあくまで個人的の見解です

なんか会社に書かされていると思われそうな内容だけど、上記全て個人の見解で、本音ベースで言うなら本当に良くできてるなーと思う。 他の人も言っていたが、メルカリのValueを参考にする、というかValueを考えるとメルカリっぽくなってしまう会社は実際にあるらしいが、それも無理もないだろうと思うくらい良くできていると思う。実際俺が将来どこかの会社に行く時には、このValueと比較して会社を選ぶだろうなと思う。

まとめ

そんなValueを経営陣は本気で議論していて、変わる可能性すらあり得る。それすらもまたGo Boldだし、All for Oneで、Be Professionalに変えていくのだろう。

さて、外部に向けてこんな記事を書いてみたが、これがValueに沿ってどう捉えられるのかもまた興味深い。人によって意見は違うだろうが、その意見もまた俺のためになるものだと思う。

最後に、こんな感じでValueについて議論し合えるEngineering Managerを大募集しているので、ぜひよろしくお願いします。

mercari.workable.com

Meetupもやります!まだ参加募集中なので、ご興味のある方は是非お申込みください! connpass.com

研修中に爆睡して学んだ 1on1 で「待つ」ことの大事さ(How I learned the importance of patience in one-on-one MTGs from sleeping)

(English follows)

前置き

この記事は Engineering Manager vol.2 Advent Calendar 2018 6日目の記事です。

メルカリで Engineering Manager をしている masartzです。
今日は、先日自身が体験したことから得た、1on1の学びについて書いてみようと思います。

1on1コーチングの研修

メルカリでは、急拡大する組織に対応するため、Managerなどの中間層の教育・育成も急務となっております。Managerとしては、HR部門のサポートもあり研修プログラム等も受講する機会が与えられます。

先日 「1on1コーチング」のための時間があり、外部のプロコーチの方を相手に「コーチングを受ける側」の立場から勉強しようという機会でした。

当日、会議室に着き、挨拶と自己紹介を済ませ、いよいよ本題です。

コーチ:「最近の課題はありますか?」
masartz:「(もちろんない訳ないので、)あります」
コーチ:「例えばどんな課題ですか?」
masartz:「Aとか、Bとか、あるいはCとか、、(他にもたくさんある。。)」
コーチ:「なるほど、そうですよね。その中で敢えてこの場で話したいものはありますか?」
masartz:「うーん・・・」

ここで、とても困ってしまいました。失礼ながら赤の他人にいきなり話したい話題でもない。 俺としても日々悩みながら、周りと相談しながら進めていくべき事で、パッと答えが出るとか期待してないし、期待しちゃいけないとも思っているからです。

そんなようなニュアンスは伝え、「じゃあ、もっとたわいのないことでも、なんでも良いですが、どうですか?」と話題を振り直してもらいましたが、どうしても「この場を有意義に使えるような、何か適当な話題を探さなければ」という思いが頭から離れず、ウンウン唸るばかりでした。

実はこの日とても体調が悪く自分でも、頭回ってないなー、と思っていました。

さすがにラチがあかないので「ゴメンなさい、体調悪くて本当に頭が回らないです」と正直にお伝えしました。その後も、ストレッチをしてみましょう、とかなんとかきっかけを探そうとしてくれたのですが、最終的に「今、仕事関係なく本当に何をしても良いなら何したいですか?」と問われたので、答えました。

「正直、、寝たいです。。」

その返事は、ビックリするもので

「わかりました、じゃあ寝てみましょう!」

でした。

徹夜プロジェクトでよくやる、会議室の椅子を繋ぎ合わせた簡易ベットをその場で用意していただき、本当に寝ることになりました。その際に、「あとで起こしますね」と言っていただいたので、5分か10分仮眠したら起こしてくれるのかなと思って、試しに寝てみることにしました。

その後、起こされた時は研修時間の終了5分前でした。
90分の枠を用意していただいて、最初の30分が最初の話題探しの時間、なんとその後60分近く寝ていたそうです、、

「無理にアクションしても得られるものはない、まぁこういう時もありますよ」と全く意に介さない笑顔で場を絞めてくださったプロコーチの方には申し訳無さと共に、大きな勉強をさせていただいた感謝がありました。

この件から学んだこと

一種のコミュニケーション研修でしたが、そんな状況だったのでコミュニケーションした上でなにかを得たっていうものはぶっちゃけなにもありません(当たり前)。

しかし、この異常とも言える機会は、1on1において 相手の状況が好転するまで極限まで待つ という事の究極のベンチマークだったなと思います。 これはこれまで自分がメンバーとの1on1の場において、 その場をいかに充実させるか 、っていう事を考え、苦心していた身として完全に真逆のアプローチでした。
あそこまでのベンチマークを取る事はなかなかできません。60分寝かせて、MTGを無価値のまま終わらせる事を許容できるのが本当にすごいし、俺が外部の人間として顧客企業で研修する立場なら絶対途中で起こすだろうと思いました。

それ以降の自分の1on1スタイル

前述の通り、自分の1on1の課題はいくつもあります

  • 業務の細かい連絡や確認など、自分から話す・伝える時間が多い
    • 典型的に気をつけなければいけない事例の一つ、1on1の主役はあくまでメンバーです
  • メンバーへの効果的な話のフリができない
    • せいぜい「最近どう?」からの雑談レベルに終始してしまう
  • メンバーからの話題を引き出す力が弱い
    • 引き出そうとしても「うーん、特にないです」という返答をよくもらう

ダメなあるある典型例ではないでしょうか。
だからこそなお頑張って充実させようと思うと、より自分の話す時間が増えてという無限ループですね

なので、この件以降に決めた事としては

例え相手が寝る事だって受け入れる、もし寝て起きたらスッキリした頭で「そういえばこの前こんな事を考えて・・」とでも話を切り出してくれたら最高

と考えるようにしました。

具体的に1on1の途中でネタ切れしたら、
「じゃあこのままお互い自分の仕事でもして、なんか思いついたら話してー、なんも思いつかなければそれでも良いよ」
と言いつつ一緒に過ごす、などのアクションをするよう心がけています。

もちろんこの件をグローバルメンバー含めたチーム全員にも伝えようと思い、この記事も日英で書いています。

まとめ

1on1の方法論に限りませんが、対極的な考え方・やり方から思考の幅を広げるのは様々な場面で有用です。 それが難しいのは、対極的な考え・行動を自分自身ではなかなかできない(だからこそ対極にある)からです。 今回、プロコーチという非常に思考の幅の広い方の助けを得て、そのような事を学べたのは非常に良い機会でした。

宣伝告知

さて、メルカリではまさに様々な思考を持ったEngineering Managerを探しています。 俺のポジションも絶賛募集中であり、研修中に寝るやつより働ける!と思う方からのご応募お待ちしております。

mercari.workable.com

メルカリのこれからを担うMicroservicesのPlatform部分を作る大事な仕事です。 どうぞよろしくお願いいたします!

明日は fukuo33 さんです、どうぞお楽しみに!


Introduction

This article is the 6th edition of Engineering Manager vol.2 Advent Calendar 2018.

Hi, I'm masartz and I am an Engineering Manager at Mercari. Today, I’d to write about a great learning opportunity I had recently.

One-on-One Coaching Training

At Mercari, educating mid-level members like managers has become a high priority because our organization is growing so quickly. As part of these efforts, managers like myself are given opportunities to take training courses organized by the HR department.

The other day, I was scheduled to take part in a training session called One-on-One Coaching. From what I had heard before the session, a professional coach, who was an external contractor, would be teaching me all about coaching.

On the day itself, I entered the MTG room on time, we greeted each other, did quick self introductions and then moved to the main topic of the training.

Coach: So, what topics would you like to discuss with me? How can I help you?
masartz: Of course I thought about it before coming, and I have a few things...
Coach: For example?
masartz: Well, there is the issue A, B, and C. And actually I have more as well, but...
Coach: I see. Which of those do you want to discuss now?
masartz: Umm...

I was in trouble at this point. I realized I couldn’t really discuss any of these topics effectively with a stranger. The topics were things I was worried about and had been discussing with my colleagues to try to resolve. Even worse, they were not things I could get definitive answers about, and I shouldn’t expect to.

I told him what I was thinking and he said that it was no problem. He suggested we we just talk casually for the rest of the session.

But this idea bothered me too because I was thinking that I had to make good use of this training. I couldn’t just waste this opportunity with a professional coach. I had to come up with a good topic for us to discuss.

Honestly speaking, I was not feeling well that day. My physical condition was poor and I couldn’t really think clearly.

By this point, the conversation had basically stopped since I had take so much time to think about what to do. So I finally told him the truth as politely as I could, that I wasn’t feeling well and I couldn’t think clearly. I felt terrible and apologized.

First he recommended that I stretch or grab a coffee or something to refresh. I knew none of those things would work and I still didn’t know what to do. Finally, he asked an unexpected question.

Coach: If you could do anything right now, anything at all, what do you want to do?
Masartz: Actually, I really want to take a nap.
Coach: Got it. That’s what you should do then.

Of course I was really surprised. But he didn’t miss a beat and started building a bed for me by pushing some chairs together. It was something I hadn’t seen in a long time, not since when I first started working many years ago.

Despite some reluctance, I followed his instructions and got comfortable. He said he would wake me up later. I figured I could take a quick 10-minute nap and then we would restart the training session.

When he woke me up I saw there were only 5 minutes left in the session. I started to do the math: it was scheduled to be a 90-minute MTG, we had spent about 30 minutes introducing ourselves and trying to find a topic to discuss, so that means I had slept for almost an hour! I apologized again.

Coach: No problem at all. We can't get anything done by forcing it to happen.

He didn’t look upset at all. He just looked really sincere about his message. All I could do was say sorry once again and then I thanked him for teaching me this lesson.

What I Learned

This was supposed to be communication training, but I didn’t do any real communication since I was asleep most of the time. However, I think this strange situation was the greatest lesson I could learn about waiting for people until they are ready. How important it is to wait until the person I’m meeting with is ready to discuss something, being patient until they are feeling well enough physically and mentally to talk.

This is completely opposite from the way I had been thinking about one-on-ones. I was always asking myself how can we use this time efficiently. How can I make it exciting? How can I make it useful?

Most people don’t have the patience to wait until the right time. That’s why the coach allowing me to sleep was so surprising. He was ready to accept having a MTG with no real value to happen and not be bothered by it at all.

Before this training, if the roles had been reversed, and I was the external consultant, I would have definitely woken him up.

My One-on-One MTG Style

As I said, I have often questioned myself about how to have the perfect one-on-one meetings, and I have identified some key issues.

  • Issue: Spending too much time on topics from my agenda (announcements, reviewing old topics, etc.)
    • This is one of the most common problems. It’s easy for managers, including me to forget that one-on-ones should be led by the team member, not themselves.
  • Issue: Not being able to ask the right questions
    • When I couldn’t think of what questions to ask, I would just ask how they had been lately. I thought just having a casual chat was not a productive use of the time.
  • Issue: Not being able to figure out what topic to discuss
    • Usually, when asking the team member what topic they would like to talk about they would just say everything was OK. I felt this was not really an acceptable answer.

I’m pretty sure I’m not the only one who thought this way about one-on-one meetings. I knew it was a problem before, but my fixes always led to me talking more. I was stuck in a negative cycle. But following my session with the professional coach, my thinking about one-on-ones has changed completely.

The meetings are now totally dependent on the team member. It’s completely their time and they can use it any way they like, up to and including sleeping if they want. I can accept it without hesitation.

Of course it would be great if they think of something they want to talk about when they wake up and are thinking more clearly, but that’s not the point. When they don’t have any specific topic to discuss (and don’t need a nap), I now suggest working on our own tasks for a while in the meeting room together. And if something comes up in the course of their work, we can talk about it.

This change has come as a bit of a surprise to my team members, so I wanted to write this article to explain the background and reasons behind it. And I wanted to make sure everyone understood it clearly so I wrote it in both Japanese and English.

Conclusion

It’s useful to expand your mind by considering the opposite way of thinking. This applies to to any situation, not only one-on-one meetings. This can be difficult because we can’t think of the opposite point of view easily by ourselves. In this case I could learn a really unusual and helpful way of thinking from a professional coach who has a lot of experience in a specific area. And for that I feel very grateful and lucky.

At Mercari, we are making a lot of effort to hire a wide variety of Engineering Managers. We are even recruiting for my position) right now. If you think you can create more value than someone who just sleeps during meetings, please apply!

mercari.workable.com

This specific position has the important mission of creating the platform we need as we migrate from monolith architecture to Microservices.

fukuo33 will be writing more about this tomorrow topic. See you tomorrow!

*English edited by my amazing colleague JohnVS. Thank you very much!

Zapier を使って、SlackリアクションでTodolistを作るようにした

これまでのタスクの管理方法

最近、お仕事のRoleが若干変わり、コードを書く量が減った代わりに、「○○の件、確認お願いします」などの色んな方面の依頼や調整タスクを拾う事が増えました。
業務のメインツールは言わずもがなのSlackなので、基本的に仕事はSlackから降ってきます。
色んなチャンネルでPostされる依頼タスクを管理するには脳内メモリではオーバーフローすることもしばしばで、 手元のメモ帳にタスクリストを書いたり、依頼Post のPermalinkを拾って自分宛のDMに転送Postするなどしていました。

改善してみようと思ったきっかけ

少し前に特定のリアクションをトリガーにして動くbotを社内の方が作っていたのを見て、似たような事できると思ってZapierでやってみました。

リアクションされたコメントを自動翻訳するSlack BotをZapierで作った

またZapierについては以下のBlogが詳しいです。
社内でかなり導入されていて、今回の以外にも色々使えて便利。

tech.mercari.com

やること

Zapierで 2 step 組むだけ、以上!

って、書くと味気ないけど、ホントにこれだけで

  • New Reaction Added
  • Send Private Channel Message

のActionを設定するだけです。それぞれ以下のようなイメージです。

New Reaction Added

f:id:masartz:20180523175735p:plain

Reaction にはトリガーとなるリアクションの種類を指定する。
User での絞込もできるので、ここに自分を設定すると同じリアクション使う人がいても、それは拾わなくて済むので今回は設定する方が吉。

Send Private Channel Message

f:id:masartz:20180523181837p:plain

Channel は Post先のチャンネル名。まんま文字通りでしかない。
Message Text には Step1で拾った情報から、Message Permalink を設定する。
ちなみにこのStep2 のアクションは Private Channel である必要はなく、Public ChannelでもDMでも良いと思います。

やってみた結果

f:id:masartz:20180523175806p:plain

元の投稿にリアクションをつけます。

f:id:masartz:20180523181326p:plain

PermalinkがPostされるので、Slackの仕様で自動的に中身が展開されて一目瞭然です。 ここから流れを追いたい時には、Permalinkから元チャンネルにジャンプして確認可能です。

まとめ

1アクションでタスクリストを作れるようになりましたっ!

ex-mixi Advent Calendar 2017/12/01

なかなか珍しい ex-mixi(会社のOB/OG)によるAdvent Calendarの一発目をかます masartz です。
ミクシィは 2ホップ前の会社、現所属はメルカリになります。

どういうスタンスで書けば良いのかわかりませんが、各方面を考えてミクシィ時代から今に至るまで継続してることを述べていきたいと思います。

大規模であるが故の技術的な対策

mixiもメルカリも大規模と言って良いレベルのサービスで、そのための負荷対策はどのエンジニアにも求められるものです。 特にクラウドなインフラ環境が今ほど整っておらず、スケーリングに緻密な設計が求められたミクシィ時代に学んだ分散手法は今も活かされています。

ミクシィエンジニアなら、下記は L1分散作業 と表現すれば、その一言で伝わることでしょう。

tech.mercari.com

こういった手法はサービス初期に用いられることは少ないでしょうし、現在においてはクラウドのオートスケールでカバーできる部分もあり、それは投資フェーズにおけるメリットです。 サービスをグロースさせることに注力するのは非常に魅力的です。その後、サービスが安定し収益性を高める段階において コストパフォーマンスとの兼ね合いでこういったエンジニアリングの活用方法があります。

DB分散以外にも、SQLのクエリチューニングによる速度改善、キャッシュ機構を導入することによる負荷削減などの様々な手法も同様です。 どれも地味に感じるかもしれませんが、webサービスにおいてアプリケーションコードの計算量がボトルネックになることよりDBからのSelectやNW通信による 処理にかかる時間の方が遥かに多いです。アプリケーションコードをいたずらにリファクタしチューニングするよりも、DBへの問い合わせを1つでも減らす方がよっぽど速度改善になるケースは多いと思います。

サービスを運用し続けること

俺はミクシィにもメルカリにも、比較的規模が大きくなってから入社したため、本当の意味でのゼロイチのグロース方法は実はわかりません。 1から10でもなく、10から100くらいのステージにいつも関わっています。

その段階では既にサービスは立ち上がっていて、様々なコードを目にすることになります。先日、ブログエントリを公開したところ、 それに関してあまりにも予想外なほどにありがたいコメントをたくさんいただきました。

b.hatena.ne.jp

私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません

この部分が異常に刺さっているようですが、これはマジで本心からそう思ってます。
ミクシィ時代、後から入社してきた人に「なんでこんなコードになってるんですか」と言われるのがとにかく辛かった。 言いたい気持ちはもちろんわかりつつ、それまでの人もそのような問題は当然認識していたからです。

そのようなコードになるのはやはりサービスの成長を第一に考え、実行してきた結果だと思います。 mixiやメルカリよりキレイなコードで動いているサービスはたくさんあるでしょうが、 それらより大きな規模のサービスはなかなかないからです。

我々の仕事はサービスを提供し、価値を届けるのが目的であり、コードはあくまでその手段です。 ミクシィもメルカリもそうやって先輩エンジニアがサービスを成長させてきたのだと思います。
その上で だから、どうするか ということを考え実行していくことが、後から入ったメンバーのやることであり、 またこれから来たるべきメンバーに対してできることかなと思います。

逆説的な話ですが、後から入った人が既存のコードをdisれるのは、

  • サービスでそのコードが動くことで、価値を提供した
  • 価値を提供したことで、売り上げを出した
  • 売り上げを出したことで、サービス拡大のためメンバーを増やした

からだと思っています。つまり今の自分は目の前にある既存コードのおかげで雇用されたので、 それをdisることは自分自身の否定になってしまうので、できないという考えです。

俺自身ミクシィを出てから、前職でも今の職場でも既存コードの悪口だけは言ったことがないと思います。 サービスの規模との相関で、人や組織もスケールします。それぞれの組織の状態に適したコードがあります。 そのような振る舞い方を学んだのもミクシィという環境でした。

サービスに対する責任感

多くのお客様に使われるサービスというのは本当に刺激的です。
ミクシィ時代も、正直良い意味でも悪い意味でもたくさんの反響をいただだきました。 そのどれも貴重な体験でしたが、特に1つだけ忘れられない件は、 日本に未曾有の大災害が起こった際、友人・家族などがmixiにログインした活動履歴でお互いの安否を確認できたことをお客様から感謝されたことでした。

メルカリのおいても、日々たくさんのお問い合わせをいただきます。 どれもありがたいものですが、やはり感謝されるというのは特別です。 サービスや施策の状況に応じて様々な声がある中でも、感謝は自分達のやるべきことを再確認させられます。

とはいえ、それほどの機会が日常的に多いわけではありません。
だからこそ最も目指すべきことはお客様がなるべく非日常を意識することなく、 いつも通り使える サービスにする大前提を達成することなのは昔も今も変わりません。

といったところで宣伝

せっかくなので、それぞれの本家のアドベントカレンダーも紹介しておきます。
このex含めて3つ、どれも楽しみにしてください。

qiita.com

qiita.com

まとめ

エモい話になった初日かもしれませんが、

  • 当時やってたこと
  • 今やってる技術的なこと
  • 技術じゃない思い出や考え

などの色々をちょいちょい書いてみました。2日目以降の人で、「こんなこと書いても良いのかな」と思っていた部分の実績と後押しになれば幸いです。

2日目は KAKKA がこんな流れを大きく変える投稿をしてくれることでしょう。
その後も多種多様なコンテンツが繰り広げられ、時には穴も空く事もあるでしょう。
しかし、最終的には hirokidaichi が全て回収してくれるでしょう。

かつての同郷メンバー方々への信頼は今も変わりありません。
それぞれがどのように活躍しているか楽しみであり、離れていようともお互い刺激しあっていければと思っています。
そのような素晴らしい仲間と出会えたミクシィという場に改めて感謝しています。

WEB+DB Press vol.96 の Perl Hackers Hubに寄稿しました

gihyo.jp

この度、id:songmu さんにお話をいただいて、WEB+DB Press vol.96 の Perl Hackers Hubに「大規模広告配信でのCPANモジュール活用」と題して寄稿しました。
内容は今勤めている fluct社SSPサービスfluct の配信サーバー周りについてです。

fluctのPerlは広告配信という、いわゆるMVCフレームワークでWebサイトを作るのとは違った役割を持っていておもしろい面がありますが、
スマホのクライアントアプリを受けるAPIサーバーとかだと作りが参考になる部分もありそうですし、
広告ならではの設計もあります。案件情報を取得する部分は(Perl要素薄いですが)おもしろくてオススメ読みポイントです。

初めての執筆活動

実は、本を出すことはおろか、寄稿するというのも初体験でした。
こんな貴重な機会をいただいた id:songmu さんには大変感謝しております。

やってみて、どうだったか?

すげー大変でした!

普段とても意識していることに「言うことは3行で、簡潔に」というのがあります。
この原則は前職の上司に求められたことで、とにかく如何に短くするかを考えた上で、結論を先にまとめて言うようにしています。
これは少ない時間で本質から逸れない意思決定をするためにとても大事な事だと思ってます。

しかし、記事というものは「起承転結」と構成・流れ があり、それが基本かつ核になります。
執筆にあたっては、まずアウトラインを決めるのですが、個人的にはこれがその後の本文書くより難しかった、、
アウトラインだけで流れがわかるかどうか、がポイントなのですが校正で指摘してもらってもどうして良いかわからず。。
初っ端からかなり躓きました。

その後においても、初期のコンセプトが緩かったために 何を伝えたいのかわからない 文章になってしまったり、技術評論社の稲尾さん、監修の牧さんには執筆の過程で、多大なご迷惑をおかけしました。

結局、書けたの?

最終的には、しっかりと仕上げました。 そう言えるのは理由があって、実は来年(2017年)の頭に、fluct及びVOYAGE GROUP を辞める事にしました。

というわけで、本エントリは「退職エントリ」ではなく、「退職しそうなエントリ」です。

執筆のお話をいただいた時点で、転職先は決まっていなかったものの気持ちの中では辞める意志は固まってました。
だからこそ、今回の記事はキッチリ書こうと決めていました。

所属していれば、例えその記事の内容が不十分でもあとでblog等で補足できるかもしれません。
あるいは同僚がフォロー・サポートしてくれるかもしれません。

しかし、そこを辞める人間が書いた記事がイケてない内容だったら
外の人には、どうせ辞めるから適当に書いたんだろうと思われるかもしれないですし、
残る中の人からは、適当なこと書きやがってと恨まれるかもしれません。

そう思わせないような記事にしなければと思いながら書きました。
もちろんアーキテクチャは変わっていくと思うので、普遍的に正しい情報ではないですが、2016年末の状態は表せています。

自分としては、約2年携わって、記事を寄稿できるくらいシステムを理解したし、むしろ書ききれなかった事の方が多いです。
それはページ数が理由なだけでなく、fluctの環境の中でPerlが稼働している部分はあくまで一部であるためです。
サービスの中にいくつものドメインがあり、リポジトリと稼働する言語が複数ある、というのは前職と全然違くてやりがいのある環境でしたが、そのほぼ全てになんらか手をつけられて理解することができたのは良かったです。

また、記事の次のページで fluctの求人インタビュー広告が載っています。 このインタビューも、自分も参加する案もあったのですが断っていました。それも辞めると決めていたから。
さすがに求人しておいて、もし仮にそれに惹かれてくれた人がいて縁があった場合、「入社してみたら惹かれた人がいなかった」なんて事になったらそれはヒドいと思うのが理由です。

決して、「オススメできない環境だから求人に協力しなかった」訳ではないので、自分は違う道を選ぶけど、fluct及びVGがマッチする人はきっといるだろうし、いてほしいと思う。

話を戻すと

そんなこんなで、俺の卒業論文かつPublic公開な引き継ぎ資料であるWEB+DB Press vol.96 は16周年号として内容盛りだくさんとなっておりますので、是非ともお手に取っていただければ幸いです。

個人的にはかなり大変でしたが、とても良い経験になりました。
正直辞めるつもりで業務を整理しはじめていたので、執筆に割けるリソースがあったけど、通常の業務をこなしつつ執筆される方々は本当にすごい。
そういう時にどこまでできるかわからないけど、また機会があればぜひチャレンジさせていただきたい!

求人告知

fluct及びVGはPerlを始めとして様々な技術を使った事業開発会社です。
ことPerlに関して言うなら、客観的に見てそこまで使用割合は多くない。
おそらく今回の記事内容相当のPerl製のプロダクトはないと思いますが、全く違うアーキテクチャでおもしろいプロダクトはあります。
興味があれば、「ajito で話聞きたい」とつぶやけば誰かが反応するでしょうし、どうしてもであれば俺に連絡もらえれば、繋ぎますのでお気軽にどうぞ!

Atmoph Windowがやってきた!

f:id:masartz:20161113145412j:plain:w500
kickstarterで申し込んでいた、Atmoph Windowがようやく到着しました!
ようやくと言っても、実は3週間くらい前に届いていたのがこれまで(引っ越しがあったので、新居で && net開通してから)開封できてなかったというのもある

設置手順

とりあえずテーブルと同じ高さで立て掛ける形で配置してみた。
テーブルと併設している引き出しボックスを足場にしていて、その引き出しのポジションの関係で右の一部が宙に浮いてるけど、安定してます。
壁にひっかけるためのフックも東急ハンズで500円くらいで売ってたので買ってきました。開く穴が小さくなるし、3点固定で安定。という触れ込みだったけど、思った以上にピンが太くて、「これ穴わかるだろ、、」ということで、ひとまず使ってません。
代わりに100円ショップで買ってきた耐震用の粘着パーツで足元を強化して、これが割と良い感じです。
f:id:masartz:20161113145435j:plain:w300

セットアップ手順

使用にはWi-FI環境が必要ですが、スマホからのWi-Fi認識させるセットアップ手順もスムーズでした。
本当にスマホを上部におしつけて信号を送ると良さそう(手順の話なので買ってない人はようわからんと思いますが・・)
逆にわかりにくかったのは、MENUの操作方法^^;
スマホ側がレーダー画面になり、スワイプとかクリックとかがAtmoph側に反映されるんですが、Atmoph画面にカーソルでも出れば伝わるのですが、パッと見だとスマホ画面とAtmoph側の画面のポインタ位置がシンクロしてるのがわからなかった。。

感想

使って見ての感想は、4k画質ということで、さすがに綺麗。
おかげでさっきは珍しく自宅でターミナル開いた作業が捗りました!
f:id:masartz:20161113224404j:plain:w500

これ、写真だと伝わらないですが、静止画ではなく動画 なので(窓ですから!)
夜の時間に夜景を見ながらPC作業するのはなかなか雰囲気出て良かったです。
今後は素材が増えたり、ライブストリーミングも追加されるとの事なので非常に期待。
個人的には自分の素材をアップロードできるようになるのが楽しみ。

気になった方はこちらから どうぞ。
新型MacBookProを今から注文しても年内到着しなそうなので、うっかりAtmophをお買い求めいただくのも良いのではないでしょうか。

いくつかのファイルをまとめて tail する簡易スクリプト

やりたいこと

サービスリリース時に、先に局所的なデプロイをして様子を見る際などに使う

(実際に使っている)ユースケース

  • 広告配信サーバーが数百台あり、リリース時には手始めに1台にデプロイして動作確認というフェーズがある
    • この時、該当1台はバランサーから外している
  • 配信サーバーは、以下の3つのプロセスで成り立っている
    • 広告タグが貼られているメディアからのアクセスを受けるエンドポイント的なApache
    • 配信案件の管理し、場合によってRTBプロセスへのリクエストを行うPlackアプリケーション
    • DSPへのRTBやりとり(外部通信)を行う、RTB
    • 処理の流れとしては メディア -> Apache -> Plack -> RTB -> DSP -> RTB -> Plack -> Apache -> メディア となる
  • 先行1台での動作確認時には以下のあたりを確認したい

で、どうやるか?

簡易的なスクリプトを作ってましたが、ちょっとだけ直して外部に切り出してみました

How To Use の項目のままなのですが、clone して make すれば動きます
もうちょっと詳しく書くと、

  • 実態はperl スクリプト
  • make setup で必要なCPAN Module を $REPOS/local 配下にinstall
    • 正しくはcpanm を拾ってくる所からやるべきですが、手抜きしてリポジトリ内に同封してます
  • etc/config.yaml を 編集します
    • path : (必須)tailしたいログファイルのFull Pathを記入。アクセスログ等はローテートすると思いますが、動的な日付部分は POSIX::strftime() 形式で書けます。File::RotateLogsのやり方をパクりました
    • color : (必須)Term::ANSIColor で色付けして出力するための色指定です
    • option : (任意) File::Tail で出力する際のオプション指定
  • 編集したconfig.yaml のフォーマットが正しいか make test で確認できます
  • make run すれば、動きます。無限ループで動き続けるので、 Ctrl + C で切ってください

画面イメージ

f:id:masartz:20160923110540j:plain

まとめ

Term::ANSIColor や File::Tail など、既存のCPAN Moduleを使えてお手軽に作れました
運用上のログ監視はこんなのとは全然違うしっかりした仕組みがあるので、
あくまでリリース時の開発者作業の一助に過ぎません。そのスコープにおいてはこれで十分かと思います