SREcon19 Asia/Pacific 参加レポート

2週間ほど前にSREcon19 Asia/Pacific に行ってきました。何気に海外カンファレンス初参加。というわけで出張レポートです。

会社への提出レポートも兼ねているため、旅行的成分は少なめでお送りします。

カンファレンス概要

発表資料は現時点でもすでにProgramページに添付されていっている。 動画に関してもいずれ公開される予定のハズだ。

セッション内容

1st day

  • Use Interview Skills of Accident Investigators to Learn More about Incidents
    • 面接で使う質問力を用いてIncidentの原因究明に活かそうという話
    • 面接 -> Incidentという展開だけでなく、Managerの1on1にも通じる、あるいは使える話だった
    • Open Questionで相手から引き出すように心がける、などの話も盛り込まれていた
    • Templateを用意するのは面接のクオリティを担保したり、運用コストを下げるのに効果的だが、ポイントとしては Don't follow template の点もあったり工夫が見られた
  • Leading without Managing: Becoming an SRE Technical Leader
    • 結論から言うと、今回聞いた中で個人的なベストはこれ。Individual Contributorも、Tech Leadも、Engineeering Managerも皆見てほしい
    • Engineer Career Ladderの紹介もあり、その区分けが影響力によって上がっていくというのは弊社と一緒。その 影響力 をより具体的なケースで述べている
    • Task Drivenから始まり、Project Drivenになり、周りを巻き込みながら成果を大きくしていくのはしっくりくる
    • そうやって成果を出した Tech Leaderこそが 「They can change process」というのがカッコ良い
    • Be the someone in "Someone should"(= 皆が「誰かがやるべき」と思う【誰か】になる のが意味のある仕事であるというのは勇気づけられる言葉だ
  • The Bloomberg Story: Building SRE Teams in an "Immeasurable" Organisation
    • メルカリのMicroservices化にコミットしている人には見てほしい内容
    • 3年で500人以上のSRE組織にしていった話
    • メルカリと同様、Centralizedな体制で始まり、現状は半分がFeature開発チームにEmbeddedしている模様
    • 当然Centralizedな良さもあり、Infraが安定していることなどはその一要素、その通りだと思う
    • 組織拡大の過程にはInternal Transferもあったようで、これもメルカリが狙う形と同じ
    • ただしSRE mindset はとても重要だし、それもあって外部採用もできてくる
  • Retrospectives for Humans (a Crash Course)
    • ある意味日本ではそうそう聞けない「世界各国における英語の解釈の違い」について
    • 対立構造を生まない、とか断定系の表現はしない、とか言語が違っても気をつけることは一緒
    • また、SRE本にもあるPost Mortemのポイントとして「人間が頑張る」対応策はNGの話もあった
    • さらに「ヒューマンエラーは問題の根本原因にはならない」と断定しているのは素晴らしかった
    • おもしろかったのはJokeの使い方の例があったこと。この辺は日本ではないかもしれない
    • まとめると、コミュニケーションの問題は万国共通であり、この規模のカンファレンスでも取り上げられるほど大きな課題なのも万国共通なのだなぁ、ということ。
    • 特にメルカリはGlobal Tech Companyを目指す中で様々な課題に直面しているけど、きっとどこの会社でもある、あるいは乗り越えてきた課題なのだろうと思わされる内容だった
  • Releasing the World's Largest Python Site Every 7 Minutes
    • Instagramのデプロイの話
    • とても歴史的経緯が感じられる良いコンテンツだった
    • まず、おそらくInstagramモノリスリポジトリであるということ、アーキテクチャもオーソドックスなデザインであり、Djangoのアプリを本番にrsyncして、symlink切り替えてデプロイしている、ちなみに金曜日は安全のためにリリースしない、みたいな感じっぽい。それだけ聞くとInstagramもどこにでもあるwebサービスと変わらないのだなと思わされる
    • それがFacebookの後ろ盾を経て、大規模かつスピーディーに行われているというのが凄さ
    • 驚くべきことにステージング環境がなく、開発されたものは本番にcanaryリリースされて検証される。その目的がtrunk(master branch)を壊さない事。そのため、開発用のブランチでコードレビューが通ったものからcanaryリリース対象になる模様
    • モノリスのメリット/デメリットをそれぞれ考慮して対応し、かつそれができているというのが最もおもしろかったポイントだ。今メルカリはMicroservicesを選択し、自分もそれに向かって挑戦しているが、やはり答えは一つではないなとも思わされた。Miicroservices化は否定しないし、これからも推進していきたいがこれはこれで多くの学びがあった。

2nd day

  • Critical Path Analysis—Prioritizing What Matters
    • アジア版Uberとも言うべきGrabのサービスにおけるクリティカルポイントを考えた開発について
    • お金をやりとりするサービスで、お金が直接絡む機能とそうじゃない機能で重要度が違う、というのが一つのポイントだったように思う。そしてそれはメルカリもそうだな、と通じる部分を感じたのが印象的。
    • 逆に言うと、捨てるポイントを明確にするのも重要。
    • 「Developer focus to feature」というのは本当に同意で、Platform Teamもそれを目指している
    • Graceful Degradationの項目で、静的データはCaching効かせやすいみたいな話もあって、そうだよね~感が満載
  • Cross Continent Infrastructure Scaling at Instagram
    • こちらもInstagramの話。アジアのイベントなのに、データのBackup for DRに大陸をまたぐ話をヨーロッパとアメリカ大陸が舞台なのはちょっとおもしろかった
    • Cassandraの運用の話で、複数のDCにデータを持った冗長構成、でもヨーロッパでは2拠点しかないので、レイテンシを考えて東海岸も同じRegionとして扱う、とかスケールデカすぎ
    • 1日目のデプロイの話はスタートアップっぽさが残る話だったが、こっちはガチのGlobal Scaleだったのでそこそこギャップがあった。ので、登壇後の発表者を捕まえて聞いてみた話は後述
  • How to Champion SRE Investment to Different Levels of Leadership
    • What,Whyはあえて置いて、HowにFocusした内容だった
    • Individual Contributorの人に見てほしいかも
    • とてもインタラクティブな部分を重視していて、最後にセッションの内容をクイズ形式でおさらいするなどの取り組みがおもしろかった
  • Distributed Sys Teams
    • Fastlyにおけるリモートワークが超いい感じだぜ!っていう話
    • 「it's easier said than done」と途中で出てくるのだが、聞いていて「いやー、これすごいけどホントにできてるの?どうやって?問題起きてないの?」と思わざるを得なかった
    • 個人ごとのパフォーマンスのための非同期性を活かしつつ、チームワークとしての同期性(チャットよりビデオ、時には雑談だけのビデオコミュニケーションも)を意識しながらやる、っていうのは確かに大事な事だが言うより難しい
    • これを実現するために大事なことは、集合チームと一部のリモートチームみたいな構図だとうまくいかなくて、どうしても集合チームが主体になりがち。それは力関係の問題ではなく、雑談してる中でやる事が決まって、みたいな流れで物事を進んでしまうことが自然にある。それを意識的に避けないと成功しないと思う
    • Platform Team も1人だけ離れたオフィスで働いていて、上記のようなリモートから見たサプライズな動きがないように気をつけている。具体的には議論はissueを作ることから始めているので、知らなかった話というのは基本的にないハズ。issueの進捗が雑談の議論を元に進むかもしれないが、それもissueを見ていればキャッチアップ可能なハズだ。
    • あるいは、マネージャーとしてはリモート側の声はよく聞くようにしていて、先日もチーム全体の定例MTGの頻度を減らして業務効率を上げる取組をしてみたが、チームとしての一体感に対して懸念が上がってきたのがリモート側が早かったので、定例の頻度を少し戻すというのは即時に判断した。
    • いずれにしても、Fastlyの状態はすぐには実現できなくて、そのためにはまずマイノリティリモートチームを作ってワークさせないといけない。大体のケースがここで失敗して、その先に進まないっていうクエストなんじゃないかと思うので、難しいけど良い話だった

3rd day

  • Lightning Talks
    • ここは Platform Teamとして一つのハイライトであり、@dtan4 による発表を見るのがメインミッションだった
    • 10人以上のLT発表者から事前にスライドを集め、1枚15秒で自動ページ送りする形式で固定、発表者間に特に区切りのスライドはないので、ドラが鳴ることもなくどんどん進んでいくLTだった
    • そこまで自由が効かない状況で、Platform Teamがこれまでなぜ/どうやって取り組んだかをコンパクトにまとめて発表していたのがステキだった

speakerdeck.com

  • Ethics in SRE
    • これが大トリのセッション
    • これに関しては、わかったことじゃなくて「わからなかったこと」の話
    • 正直倫理という話題について、ネイティブスピーカーの人が息切れしながら話す英語を聞き取り・理解するのは俺の今の語学力では不可能だった。完敗。
    • 後述するが、はっきり言って理解できなかったセッションもあり、最後のこれもその一つ。もちろん事前に予想していたことだが、この「わからない」という学びは大きかった

その他聞いたセッション

セッション内容以外について

ダイバーシティ

会場に女性参加者の数が多いことに驚いた。各社必ずいるし、集団を成しているところもある。日本でSREやインフラのイベントをした時、一体どれだけ集まるだろうか・・ 具体的な数値で、Googleの人と話しをした時、シドニーオフィスでは100人以上のSREがいて、うち20%は女性だそうだ。結構驚きの数値だと思う。

セッションへの参加率

YAPCのAsia以外だとセッション聞かずにコード書いているだけの人とかいるようだが、フロアをウロウロしている人は少なかった気がする。ただ、そもそもの参加率として3日目とかは空席多いなとは思ったので、徐々にドロップアウトしているようには感じられた。 その辺は参加費も影響しているのかもしれないが、さすがにそれなりの額を出しているだけあって

  • そもそも会場が豪華。日本で言うなら、ビックサイトか国際フォーラム的なところ。
  • セッション切り替えのたびに各席に水が補充される
  • フロアではコーヒー飲み放題 + 軽食
  • ランチ・懇親会もしっかりしたものが提供された

あたりは流石だなと思った。電源タップの数が少ないくらいしか不満はなかった。あと、会場がクソ寒かった。

発表のうまさと話のスピード

やはり発表に慣れている人はゆっくりしたスピードで聞き取りやすかった。一方で、慣れてない訳ではないのだろうけど、かなり本気で喋る人のはさすがに聞き取れなかった。。特に技術系の話であれば、スライド内にコードが載せられて雰囲気が掴める、とかも期待できるが今回は特に技術系トークではなく、組織だったり考え方を聞くようなセッションをずっと回っていた。その系統だと抽象表現のスライドのパターンも多く、50分のセッションの開始5分で、「こりゃ無理だ」と思ったものがあったのも事実だ。 一方で、特徴的におもしろかったのは初日のInstragramの人で、おもいっきり原稿を顔の前に持っていって読んでいた。あそこまで潔い判断もできるのか、というのは驚きだった。

カンファレンス参加とレポーティング

少し上で参加費について触れたが、それ以外にもフライトチケット・ホテル等の費用があってカンファレンスに参加してきた。その費用についてはすべて会社が負担してくれた。これには素直に感謝しており、それには応える必要があると思っている。その手段としてこういうカンファレンスレポートがある訳だが、実際どういう項目を書くべきか?

個人的には、セッションのメモをひたすら取っただけのレポートは意味がないと思っている。今や大体のカンファレンスが、資料は発表者が公開するか、あるいはカンファレンスページにリンクされ確認できるし、セッション内容を録画した動画すらも公開される(今回のSREconもそう)。それだけの一次情報に容易にアクセスできる中で、第三者のメモにどれだけ意味があるか。。速報レベルで公開するか、発表者以上に資料に対して補足が述べられるくらいのアドバンテージが必要になると思う。

では何を書くか?個人的に得られた経験をそのまま書くのが良いと思う。特に現地に行ってしかできない経験をしてくるべきで、他の参加者と話す、コネクションを作る、イベントの内容ではなくその場から感じた事を伝える、などかと思う。 例えば感じたこととして前述のダイバーシティの件など、メルカリとして目指すところについて他社と乖離があるのを伝えるのは必要だと思ったので書いたし、他の日本人の方でもセッショントークをしている方がいたというのも「遠くでやってるイベント」じゃないというのを伝える意味では書き残しておくべきかと思う。

という思いは持っていたのだが、ちょうどGoogleの人と話した時にどうしてるのか聞いてみた。 基本的な考えは同じで、参加者全員で一つのGoogle Docsを共有していて、セッション内容などはセッションごとに各人が情報を書き足していく運用らしい。それも内容のメモというよりは、それを見てどう思ったかを各自が書いているようだ。

Shared Docsはなるほどな、と思いつつ基本的な考え方がマッチしていたのは個人的に嬉しかった。

Discussionした情報アレコレ

マレーシア在住のエンジニアの方々

こちらが参加者パスに「We are hiring」のシールを貼っていたおかげで話しかけてもらえた。 採用しているよ、と言ったのだが「どこのオフィス?」「東京だよ」「あー、そう、OK、ありがと」みたいな感じでかわされてしまった。多分シンガポールオフィスの企業を狙っているのかなぁという印象で、まぁ開催現場ということもあるがAsia/Pacificの中心は東京よりもシンガポールにやはりなりつつあるのかも、と少し考えたりした。

カリフォルニアのGoogle SRE

Youtube Adsをやっている人。それだけで数千人のエンジニアがいるっぽい。 GoogleのSREは、開発チームが自チームのheadcountを消費してアサインされている。 開発チームとしては、開発するためにSWE(SoftWare Engineer)を増やすか、信頼性のためにSREを雇うかを選択する形になる。
という話は以前にも聞いていて、休憩時間で話してこの辺の話題で終わってしまったのが残念。 ここでも英語力の壁に阻まれて、まだ聞いたことない部分に踏み込めなかったのが惜しかった。

Instagram の発表者

2日目のセッションの発表者。 初日のセッションがInstagramのスタートアップ的側面を強く残した内容になっていたのに対し、とてもスタートアップに所属していたエンジニアがやるのとは大きく毛色の違うスケーラビリティの話をしていたので、「スキルセット違うと思うけど、スケールに関することはやっぱりFacebookエンジニアがやるの?」と聞いてみたらそうらしい。先のGoogleの例とは違い、Instagramから見てFacebookはセントラルなインフラ部門っぽく見えてるようで、必要に応じてサポートしてもらえるようだ。Googleのように、headcount使って来てもらうというよりは、所属はお互い違うままで連携しているっぽいことを話していた。 この辺りも各企業ごとに文化や仕組みが違うので、正解は一つじゃないなぁというのを再確認できた。

まとめ

一言で述べるなら「全く知らなかった新しい発見はなく、それが良かった」となる。 もちろん各社の人と話して得られた気づきはある。一方で、セッション内容でいうと、自分たちができていること/できていないけどやりたいこと、がほとんどのように感じられた。もちろんできていないのだけれど、だからこそ今のやり方を続ける事は案外間違ってないなと確認することができた。

もう一つは英語力で、やはり聞き取れなかったセッションは悔やまれる。日常においてメンバーと英語でコミュニケーションすることも英語学習のモチベーションの一つだが、貴重なカンファレンスの機会に逃さずそれを聞きたい、というのは次回参加までの目標になった。 アジア開催は時差もほとんどなく移動も長くないし、行きやすくて良かった。SREcon自体は各Regionで行われているが、とりあえず来年のAsia/Pacificにはまた参加したいなと思えた。

チーム内Reviewを導入して、チームの自律性が高まった話

チーム内Peer Reviewを導入した話です。と言うと、チーム外Peer Reviewがあるのか?という疑問が湧くと思うので、まずその前提から。

メルカリは四半期ごとの評価タイミングでPeer Reviewを全社で実施している。

  • 各メンバーが任意の3人を指名する
  • 指名されたメンバーはValue軸に則って、Reviewを書く
  • 内容は本人及び上長に開示され、評価の参考情報として使われる

簡単に説明するとこんな感じ、割とよくある評価システムだ。まずは自分がイチ個人としてこのPeer Reviewをどのように扱っているかを説明する

打ち上げ花火、下から見るか?横から見るか?

任意3人の対象に基本的に制限はない。席が隣の人から、その気になれば社長を選択することも可能だ。 この時、Reviewで何を聞くか、ということにもなるが、自分の中では「影響力のベンチマーク」として使っている。 前職のVOYAGE GROUPでもCCFB(Creed Competency FeedBack) と呼ばれる同様の制度があった。この時は5人まで選べたので、その時に選んだ例が以下。

  1. 自部署(子会社)のリードエンジニア
  2. 自部署(子会社)のCOO
  3. 他部署(別の子会社)のリードエンジニア
  4. VOYAGE GROUPのCTO
  5. VOYAGE GROUPのCEO

これは自分からの業務範囲(=距離)が近い順にSortしている。ここで期待するのは、「どこまでの人から具体的なFeedbackが返ってくるか、逆にどこのFeedbackから曖昧になるか」の境界を見つけることだ。 具体的なFeedbackが返ってくるということは、自分が業務でその人に対して何かしらの影響を与えられていた(=仕事していた)ということだと捉えて、成果を測っている。前述メンバーとの距離を図で表しながら各人に聞いた狙いを整理するとこんな感じ。

f:id:masartz:20190606011358j:plain

  • 自部署(子会社)のリードエンジニア
    • エンジニアとしての自分のアウトプットができている
  • 自部署(子会社)のCOO
    • 自分のアウトプットが事業成果に繋がっている
  • 他部署(別の子会社)のリードエンジニア
    • グループ内の他の部署にまで自分のアウトプットが波及している
  • VOYAGE GROUPのCTO
    • グループ全体で見て、エンジニアとしての自分の成果が出せている
  • VOYAGE GROUPのCEO
    • グループ全体で見て、自分の成果が事業貢献に繋がっている

ちなみにこんな偉そうな事を聞いているが、実際は各所から具体的なFeedbackが来た!みたいな理想ケースではなくって、「自分の成果も全然まだまだだなぁー」と思わせるありがたいお返事をいただきました。

ただ、このように必ずしも良い評価だけでなく、それ以外の評価が来ることを求めて良いのが、参考情報として扱われることの最大のメリットだ。

Platformにとって顧客はDeveloper

メルカリに話を戻すと、今所属しているMicroservices Platform Teamは基盤構築のチームだ。 この時、社内のDeveloperは同僚でもあり、顧客でもある。Peer Reviewはその顧客の声を聴く貴重な機会といえる。

前述の「影響力ベンチマーク」を当てはめると例えば以下のように分類してReview相手を選ぶこともできる

  • 自分たちのPlatformをヘビーユースしてくれるDeveloper
  • 自分たちのPlatformを使いはじめたばかりのDeveloper
  • まだ自分たちのPlatformを提供しきれていないDeveloper

分類方法はこれに限らないが、いずれにしても顧客の声を大事にしてほしいと思っていて、 そのためメンバーには「Peer Reviewはチーム内のメンバーではなく、チーム外から選ぼう」と依頼してきた。 結果として、チーム外のDeveloperからありがたいFeedbackを実際いただけたので、良かったと思っている。

一方で、メンバーからは「チーム外から聞く意図はわかるし、実際のFeedbackも嬉しい。しかし、同じチームメンバーが自分の仕事をどう見ているかも知りたい」という意見もでてきた。 Platform Teamの各メンバーの良いところは、お互いをリスペクトし合ったFeedbackができることで、やはりタッグを組んで仕事をしているのでFeedbackの内容の濃さは一番だった。なので、その意見を聞きたい気持ちもよくわかる、ということで、Peer Reviewにチームメンバーを混ぜるのを許容していた時期もあった。しかし、これはもはや限られた3人枠をチーム内外で奪い合う方がもったいない。そこで「チーム内Review」を独自実装し、チーム内からのReviewはこの独自の仕組みで集める、その分本来の全社Peer Reviewはチーム外からのFeedbackを貰う、というように棲み分けするのを試してみることにした。

Release CycleとFeedback Cycleの同期

このチーム内Review、実はまだ2回しかやっていないのだけど、既に2パターンのやり方を試している

  1. 四半期単位でチーム内から任意の3人選んで、Feedbackを貰う
  2. Release単位で 同Release メンバー同士でFeedbackをし合う

1つ目はシンプルで図にすると、こんな感じ。Review相手を選ぶリクエストの矢印は簡易的にTech Lead, Bさん、Eさんの3人分のみ表現している。

f:id:hossy0108:20190605073217j:plain

チームのメンバー間でフラットにReviewする形とした。基本的には全社Peer Reviewのスキームをそのままチーム内のスコープで実現しただけだ。Engineering Manager(= masartz)が輪に入っていないのは、Managerとしてのオフィシャルな評価があるので、俺からのFeedbackはその時伝えられるからだ。

一方、2つ目のやり方の背景を少し補足するのに、先日開催した Mercari Meetup for Microservices Platform #2 でTech Leadが発表していた素晴らしい資料を先に紹介したい。

この説明にあるように、現在は6weekのリリースサイクルでProjectを回している。会社組織的には1つのPlatform Teamの中で都度ミニチーム(下記で言う、Release1,2,3それぞれ)が組成されるイメージだ。

f:id:hossy0108:20190605073239j:plain

各Release Teamには Release Leadを任命していて、そのReleaseのOwnershipとResponsibilityをTech Leadから委譲されている。Tech LeadはそれをしながらPlatform Team全体のアウトプットにコミットしている。

このミニチームを6週間単位で運営し、成果を出して解散する。次の6週間はまた別のチームが組成され、Release Leadも変わる運用だ。例えば、次はEさんとCさんのペアでチーム組成され、EさんがRelease Leadを担うチームになるかもしれない。

Peer Reviewに戻ると、各Releaseチーム内(例えばCさんとAさん)でReviewするのを基本とし、Tech LeadはRelease ReadとReviewしあう形にしている。(この図も簡易的に一部の矢印は省略している)

実際どうだったか?

チーム内の独自実装について

全社Peer Reviewは四半期末に実施され、自己評価の記入などと合わせてやや忙しくなる。そこにチーム内Reviewの記入タスクまで積んでしまうとメンバーにとって過負荷になってしまうので、ちょっとだけ時期を前倒して実施して負荷分散している。それもあってか、チーム内外それぞれのPeer Reviewを皆しっかりと書いてくれている。特にチーム内ReviewのFeedbackは受けた側の満足度がとても高いため、この取組を継続したいと言ってくれている。

四半期単位とRelease単位の実施時期について

1つ目のやり方でやると実施時期は四半期単位になる。それは全社的に見れば最短期間だが、チーム内で見ると2回分Releaseが回っている。つまり、1つ前のReleaseの時の事を思い出しながら書くことになるのでどうしても内容が薄まりがちになってしまう。また、必ず書いてもらうようにしている「もっと良くしたほうが良い点」が受け手に伝わって改善に取り組むまでにラグができてしまう。という経緯でRelease サイクルと同期している形にしてみたが、そちらの方がしっくり来ているようだ。

マネージャー視点での感想

予期していなかった成果として、俺がFeedbackしたい内容と同じことをメンバー自身が感じ、それをチーム内Reviewで伝えてくれていたりする。これが本当に嬉しい。例として、メンバーAからメンバーBへの課題をマネージャーが吸い上げる必要もなければ、マネージャーが思う事をわざわざマネージャー自身で伝えなくても代わりにメンバーAが伝えてくれる。それによって、チーム内のお互いの信頼感とリスペクトが高まっていく好循環が生まれている。チームが自律的にお互いを補完しあっているのは「チーム」という単位でのセルフマネジメントができているとも言え、マネージャーとして感謝しかない。チーム内Reviewの仕組み改善も、「2パターン目のRelease単位でやってみよう」というのはメンバーからの提案であり、正直俺は1つ目のパターンの方が良いと思いつつ試してみたら思った以上に好感触だったので、「じゃあ、2パターン目で行こう」とコロッと方針転換できたりした。

まとめ

いくつか話題があったが、まとめるとどれもFeedback Cycleの話である。

  • 個人として、前職のPeer Review 指名方法や、他チームのDeveloperのReviewを貰う狙いの件
    • 自分との距離間を元にして改善点を見つけ、それを次に活かすということ
  • マネージャーとして、メンバーにどういうReviewを受けてもらうかの試行サイクルの件
    • 受け手としての感想をメンバーから貰い、書き手をどう見つけていくかに活かすということ
  • チームとして、チーム内ReviewによってFeedbackを交換する件
    • マネージャーから見て、メンバーが自律的に改善しあうということ
    • また、それをするためにFeedbackの仕組み(チーム内Reviewの実施時期)すらも自分たちで改善するということ

ということで、とにかくトライアンドエラーで改善していって成果を出すという話でした。

メルカリの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 で話聞きたい」とつぶやけば誰かが反応するでしょうし、どうしてもであれば俺に連絡もらえれば、繋ぎますのでお気軽にどうぞ!