【1年振り返り】第2子誕生。育休、時短。そして課長という名のEMへ。

これは何

こんにちは。鈴木です。このブログでは「やも」というハンドルネームでやってます。株式会社M&Aクラウドのエンジニアリングチームのマネージャーとして、開発チームと会社のアウトプットの価値最大化を日々考えるお仕事をやっています。

この記事はM&Aクラウドの2022年のアドベンドカレンダーの2022/12/2の記事です。今回のお題は「今年の振り返り・来年の抱負」。久保田(@kubotak_public)さんが「会社のことを知ってもらうためには、会社に所属している人が1年何を考えていたか発信するといいのでは」という趣旨で旗振りをしてくれています。

私にも記事を書く白羽の矢が立ちまして、こうして筆を執っています。 私が普段記事を書く場所は、会社に関わるものは会社のテックブログ、学びに関するものは個人noteなのですが、今回は個人に強く紐づくお題なので、数年ぶりに個人ブログを引っ張り出してきて書こうと思いました。

振り返りと抱負を分けて2部構成で書いていきたいと思います。

※サムネイルに大きな意味はありません。canvaで画像を探していたら最高の画像があったので使いました。個人ブログなので良いかなと。

振り返り

プライベートの話

まず大きなニュースは7月に第2子が生まれたこと。正直今年はここが「1年の始まり」としても差し支えないくらい、前半の記憶があまりありません。前半は確か、だんだん妻のお腹が大きくなってくるので、それに合わせて家事を頑張ったり、ホルモンバランスの関係でメンタルを崩しがちな妻を支えるべく平常心を保とうとしたり、そういうことばかりしていた気がします。

出産予定日1ヶ月前の6月。前駆陣痛が多くて、お医者さんには「いつ産まれてもおかしくない」と切迫早産の可能性を指摘されました。結果的には予定月に産まれまして、本陣痛が来てから数時間で出産まで進み、めちゃめちゃ安産でした。出産する部屋に妻が行ってから15分くらいで産まれたそうで、私は立ち会えなかったのでした。病院から「そろそろ生まれるので病院まで急いできてください」と電話を受けたのですが、実はその電話の時には産まれていたようです。そんなことも知らず、私は全速力で病院に向かったのでした。家に帰り、ヘルプで来てくれていた私の母と、上の子に「産まれたよ!」と報告したのですが、上の子(3歳)は絵本を読むのに夢中で話を聞いてくれませんでした。

そんなこんなで、子供も二人になったので、家庭は想像通り大変なことになりました。3歳と0歳の小さなお子様がいる家庭です。
以前は部屋が汚れてきたら、私か妻かどちらかが「そろそろ片付けるか〜」という気持ちで週に2回くらいは綺麗にしていたものでした。この前ふと気がついたら、掃除機とかはたまにしているものの、部屋には物が溢れかえり、リビングを歩くには足元注意が必要な状態でした。11月頭ごろにその状態にハッと気がついて、片付けをしたものでした(またすぐ足元注意状態です)。

上の子は3歳になり、下の子が生まれたのを期にしっかり”赤ちゃん返り”しました。「ぐにゃぐにゃしちゃう〜〜」と言いながらわざと立てないフリしたり、「ゲホゲホしちゃう〜〜」と言いながらご飯をわざと喉に詰まらせたフリなどをしてます。この子なりに親の関心が分散したことに対して気をひこうと頑張っているのだなと感じています。そんな子に対して、私は「甘えたかったらちゃんと甘えたいですって言えばいいんだよ」とか「シャキッと座ったらゲホゲホしないよ」などと厳しめの事を言っているのでした。すまんな。強く生きてくれ。

ちゃんと家にいて家事もやって育児もやってという生活なので、上の子もある程度懐いてくれていますし、下の子の育児も第一子に比べたら(単体で見れば)楽々です。子育ても経験値が大事です。
最近のいい話をちょっとだけ惚気ておきます。

  • 上の子エピソード
    • 寝る前は 1. タッチ 2. ハグ 3. ほっぺにキス、のルーチンを続けてくれてます。たまにやってくれないので、追いかけ回して無理やりやります。大体の日は、追いかけっこも楽しいアクティビティの一つです。
    • 布団の中で見たい夢の話をしてくれます。日によってはチョコソースをかけたパンケーキでフルーツ乗せを、別の日はコーンに乗ったアイスクリームに桃型のチョコレートを乗せて緑色のソーダソースをかけて食べる、などと言っています。パパにも分けてくれるそうです。優しいですね。いろんな刺激に慣れてしまった大人にとって、それがまさに「ドリーム」だという思考は初心を思い出させてくれますね。
  • 下の子エピソード
    • みんなのご飯の時に決まって泣きます。膝に乗せると、色々見えて嬉しいのかニコニコです。基本は膝の上にいればニコニコなので癒されます。
    • 抱っこ紐に入れて散歩すると、楽しそうにキョロキョロあたりを見渡しています。私もお腹に子供がいると暖かいので散歩が捗ります。

産まれて1ヶ月は育休。そのあとは2ヶ月は6時間時短、そのあと当面の間7時間時短、という形でこんな感じで生活してます。

仕事の話

さてそんな出産前後の忙しい時期ですが、仕事の方も忙しくなりました。こんな状況であるにもかかわらず、7月から課長になりました。エンジニアリング課の課長なのでいわゆるエンジニアリングマネージャー(以下EM)です。期待されるのは嬉しいですが、正直なところ、無茶だと思いました。

5月ごろからEMになるべく準備をするため、社外のベテランEMの方にお話を聞いて記事を書いたり、EMになった後は仕事を記事化(例えばこちら)して脳内整理しつつやってきました。 私としては初めてのマネージャー業なので、あらゆる仕事が一気に溢れてきました。
メンバーが優秀なので、多くの仕事は座組みだけ作って、あとはウォッチしながら多少の軌道修正、くらいでなんとか回った気がします。メンバーのみんなには、負荷をかけてしまったことがあったので、感謝と共に申し訳ない気持ちがあります。

それぞれの仕事のざっくりとした個人的評価はこんな感じです。

  • 目標設定と座組み: 主に目標設定を通したチーム体制と座組みがまあまあうまくハマって、「資金調達クラウドリリース」という大きなPJが大きな問題なく収まりました。おかげさまで顧客の登録も増え、成功とみなしてよさそうです。誰がどういうスタンスでどの配置に居るべきか、という設計が最も大事だという学びがありました。一方で大きなPJがある場合には、それ以外の目標設定においた仕事は進みにくいので、それは次回に改善の余地がありそうでした。
  • 1on1: 今まで先輩と後輩という枠の中で1on1をしていた相手はいましたが、上司と部下という関係になり、距離感をどれくらいとったらいいのか、何が確定情報で未確定情報で今伝えていいものはなんだろうか、とかすごく気にすることが多くなったと感じています。また、自身の技術力が落ちていると感じている中で、技術を使った仕事の進め方や技術力アップについてメンバーを支援する、という難しさがありました。一方で、普段からメンバーの仕事を見ていると「すごいな」とか「成長しているな」と感じていることが多くて、それを元に1on1で「こういうこともやったよね」とか「こういうところ成長じゃない?」とか話して感謝されることもありました。
  • 制度設計:
    • 「全員インフルエンサー支援制度」を作りました。大規模カンファレンスへの登壇であれば交通費、宿泊費、振替休日が取れるよ、という制度です。社の既存ルールの上で最大限何ができるか、というのを関係者にヒアリングしながら、脳を絞って作りました。正直、小規模カンファレンスへの登壇が減ってしまうのではないか、逆インセンティブになってしまうのではないかなど心配は尽きないですが、やってみないと分からないのでしばらく運用です。
    • 「2hルール」を作りました。タスクにするとオーバーヘッドやコミュニケーションコストが高い技術的な作業について、エンジニアが各自のプロフェッショナリズムを持って、少なくとも週に2時間は自由にやってOKというルールです。保守タスク20%ルールがあったりするので、追加でチームが動きやすくするための仕組みという立て付けです。ちょっとしたリファクタ、テストの追加、いらないインスタンスの削除、などなど走り始めたばかりですが(この時間枠組みだけでなく、チームへのメッセージという視点も含めて)ある程度はうまくいきそうな気がしています。
  • 広報: データエンジニアの職種については特に採用に苦労しており、「会えてすらいない」状態でした。とりあえず「弊社のデータ周りの話を発信してバズったら興味を持ってもらえる人も出てくるのではないか」という目論見で記事を書きましたtwitterでそれなりにバズってくれて(tweetは13000 imp, 130 fav、記事は1000PVくらい)、社内外からご好評いただきました。広報記事としてだけでなく、ある程度社内の関係者の目線合わせにもなって良かったと思います。ちなみにデータエンジニアの方は、無事に別の経路で採用が決まり、データプロジェクトは波に乗り始めています。
  • 採用: エンジニア採用難の昨今にあって、採用媒体経由での採用はあまりうまくいっていなかったので、チーム一丸でtwitterや勉強会の知り合いなどのうち、特に弊社にマッチしそうな人に声をかけさせて頂きました。実際に私が声掛けをしてカジュアル面談につながっているポジティブな事例をお手本として出せたので、他のメンバーも動きやすくなったと理解しています。全然知らない人にスカウトもらうより、やっぱり知り合いとか、カンファレンス登壇しててセッション見てた人とに話をもらう方が嬉しいよなあと、私としても思ったりしました。目標としていた合計3名の方に内定承諾して頂けたので、成功と言って差し支えないと思っています。

正直なところ、この半年は業務時間の20分の1くらいしかコードを書いていません。かなり詳細技術ついての技術力は落ちてきたように感じています。ここの折り合いをつけることについては考えることはあるものの、EMとして仕事を始めた半年で、全てをカバーすることはできないのだろうと思っております。EMの仕事を胸を張ってやるのは時短7時間では足りず、技術詳細の方も詰めるならもっともっと時間は必要ですが、私の手持ちカードの中である程度は割り切ってやっていかないといけないのだろうなと考えているところです。

抱負

プライベート

第2子のKPI, KGIとして以下のものを意識。

  • KPI1: 母乳に追加して、生後5ヶ月時点の1日あたりの平均ミルクの量460mlをベースラインとし、生後6ヶ月までは上昇すること。その後はこれに加えて離乳職を追加し食すること。
  • KPI2: 1日あたりのうんちの回数。最低でも1回は確保すること。0.25を切った場合には速やかに医師の診断を受けること。
  • KGI: 体重。標準体重50パーセンタイルを維持すること。

KPI1とKPI2を達成することでKGIは達成する見込み。

(実のところ、長女・次女ともに「大きくな〜れ」しか考えてません。何も書くことがないので適当なことを書きました。引き続き楽しく暮らしたいです。)

仕事

SDGsを意識して、個人と会社の成長の継続的発展を目標とします。
こちらは本当です。自分だけでなく、チームメンバーが継続的に楽しく、かつ、成果を出す仕事することを重視します。

終わりに

怒涛の1年でした。
関係者各位にはこれからもご迷惑をおかけして生きていくかと思いますが、今後ともよろしくお願いします。

技術選定と会社のフェーズの関係について会社技術ブログで書きました(Elasticsearch 編)

この記事を書きました。

tech.macloud.jp

以前 qiita に別の切り口で同様の記事を書きました。

qiita.com

元のqiitaの記事は移行直後に「技術選定失敗したなぁ」という気持ちで書きましたが、 改めて落ちついて考えてみると、その当時の選択としてはベストだったのではないか?と思い直し、その視点でリライトしてみました。

会社売却の価格算定の時によく出てくる単語「EBITDA」とはなんだ?ってのを調べてみた

これはなに

M&A領域で最近エンジニアとして働いているのですが、社内の会議とかに聞き耳を立てていると、会社の売却価格の文脈で「EBITDA」という単語がよく出現します。よく分からないこの略語はなんなのか?というのを素人なりに調べてみた記録です。

言葉の定義と理解

EBITDA は Earnings before interest, tax, depreciation and amortization の頭文字をとったやつ。。 単語に日本語訳つけるとこんな感じ。Earnings(利益) before interest(金利), tax(税金), depreciation(有形固定資産の減価償却) and amortization(無形固定資産の減価償却)。言葉の定義からすると、金利とか税金、減価償却費とか引いていない利益。

そもそもよく使われるなんとか利益の主なやつは以下のざっくり理解。損益計算書の上から現れる順。

  • 売上総利益 => 売り上げから売上原価(商品全体の仕入れ値というよりも、実際に売れた商品の仕入れ値)引いたやつ
  • 営業利益 => 売上総利益から販管費(人件費とか、オフィス代とか)引いたやつ
  • 経常利益 => 営業利益から利息とか(経常的に入るけど企業商売で儲けたものじゃないやつ)引いたやつ
  • 税引き前純利益 => 経常利益から不動産売買収入(経常”ではない”たまにしか発生しないやつ)とかを引いたもの
  • 純利益 => 税金引いた後の最後の利益

減価償却費はどこに入るのか? という話ですが、ググった感じだと以下のような説明でした

減価償却費は損益計算書のどこにある?売上原価に含まれる減価償却費とは? | ストーリーとアートでみがく会計力

減価償却費の中でも、商品の製造に関わるものは売上原価に含まれます。たとえば、商品を作っている工場や機械の減価償却費です。 一方、本社ビルや店舗の建物、その中の設備の減価償却費は、販売費及び一般管理費に含まれます。

とのことなので、営業利益を計算した時にはもう入ってしまってます。 EBITDA は「金利とか税金、減価償却費とか引いていない利益」なので、営業利益に対して減価償却費を足し合わせたものになりそうです。

なぜEBITDAが使われる?

会社の営業マンに聞いたところ、以下のような話

PLに書かれている営業利益や経常利益は、書面上の数字で、実際に会社に出入りしたお金の数字とは異なるんですよね。
減価償却は、費用として計上されますが、実際にお金が減ったわけではない。
「じゃあ、実際に今年、会社から出たり入ったりしたお金はいくらで、現金をどれだけ生み出せたの?」というのを見せるのがキャッシュフロー。
M&Aでは、買い手は、買収対象企業の「キャッシュを生む能力」を見るため、キャッシュフローがvaluationで見られるのです。

会社を買いたい売りたいという時には、「実際どれくらい今後儲かるの?特にキャッシュで。」というのが大切なので、減価償却の分を抜くのが一般的みたいです。

後、ネットでいろいろ調べていると以下のような意見もありました(メモだけ残っていたので出典なし。見つけたら書きます)。

  • 減価償却費とか税金、利息などは国やによりルールが違うので、それを勘定に入れないキャッシュ利益を簡易的に見積もる方法。国際的企業が売り手企業が本業でCFをどれくらい生み出すか、という視点で見たいMA領域でよく使われる。

じゃあ売却時にどれくらいの価格でってのはどう関わってくる?

”「1秒!」で財務諸表を読む方法[実践編] ” という本曰く、要約すると以下のような感じでした

  • 買収時のEBITDA倍率は5倍は不況時または安く買いたい、7-8倍はちょっと高め、10倍は割高で二の足を踏む企業が多い

というわけで、生み出すキャッシュフローをベースに、お値段を決めるのがよくあるようでした。この倍数は「マルチプル」と呼ばれるものらしいです。

相場観って教科書通りなん?

しかし、ここまでだとそこまで納得感はなく、やっている商売によってキャッシュを長く生み出すかどうかは変わってくるはずなので、マルチプルが高くなったり低くなったりするのでは?という疑問がありました。 最近「ゴディバ」の日本事業が買収されたという話がありました。そこでマルチプルの話。(15x というのはマルチプルで15倍、つまりEBITDAの15倍の値段がついた、という理解)

弊社内でメディアの売却の話などをよく聞くが、新興メディアだと5倍もあれば良い方と聞きます。一般的には3倍程度。安定性が低いと2倍とか。 どっかの買い手企業はメディアはマルチプル7倍以下じゃないと買わないよという話を漏れ聞きました。なるほど。

その対比で見えてくるのは

  • 老舗ブランドの場合には継続性が高い(ずっとキャッシュを生み出してくれる)と見なされるので、マルチプル高くなり
  • 新興メディアは継続性に疑問。マルチプルは低くなる

ということのよう。

IPOするときの相場とM&Aするときの相場って違うって聞くけど?

これも弊社内で仲介やっている人がslackに書いていたのを引用します

IPOをする際は市場で値段がいくらつくかを考えるので、実際に類似会社が市場でついている値段を参考にします(=マルチプル法)。DCFは事業計画ありきの価値評価、つまり会社を運営する人にとっての価値ともみなせるので、参考として使う分にはいいと思いますが、DCFの評価をロジックとしてIPO価格を決めるというのは聞いたことがないです。
M&AというイグジットをするならDCFで評価をするのが妥当。

なるほど? EBITDAをベースにしたマルチプル法はわかりやすいけども、M&A実務の実態としてはDCF法のほうもちゃんと理解をして相場観提示が必要そうでした。まだよく学んでないのでこちらも近い機会に学んでいきたいと思います。

ベンチャーに転職して三ヶ月たったけど

目次

 

これはなに

前の記事 転職しました - ふわっとしたやつ に書いた通り、三ヶ月ほど前にベンチャー企業に転職しました。 入ってみて期待通りだったのかとか、良いところと悪いところはどこなのか、というのを忘れないうちに記録しておきたいと思います。

 

エンジニアとしての成長

元々専門のインフラに加えて、主にバックエンドと多少はフロントエンドも書けるようになりたいという希望で入りました。

結果として、これは予定通りか、割と良いペースで習得していけている気がしています。

最初の頃の状態

バックエンドは最初の仕事はサイト内検索を作るというものでしたが、めっちゃ時間かかりました

  • データを吸い出すAPIを作るのに3日ほど(PRコメントついたのを対応するのを含めてもっとかも?)
  • データをインポートするAPI作るのに1-2日
  • aws cloudsearchの理解周りに1日
  • 検索窓つけるHTML/CSSマークアップに1日
  • さらにSP対応に1日程度

トータル1週間以上かかりました。全然書いてあるコードが理解できないし、全く終わらないので土日も家で唸りながらコードの読み書きをしていました。

主に時間がかかったのは設計の理解で、DDDやレイヤードアーキテクチャの触りも知らなかったのでかなり理解に時間がかかりました。今でも詳しくは分からないところが多いですが、今のシステムのフレームに乗っている限りは大体どのレイヤやクラスに書くべきかというのが分かるようになりました。

最初は”コントローラにロジックを書くな”という定説があるのは聞きかじったことはありましたが、じゃあどこに処理を書けば良いのさ?という感じでした。

細かいPHPの書き方においても、例えばPHPで配列に要素を突っ込んでいく arr= []; arr[] = $item;  みたいな便利な表現も知らず、array_push やarray_mergeをこねくり回して数時間苦労したりなんてレベルでした。

最近の状態

直近2週間くらいはは以下のようなタスクを進めていて、まあ1-2営業日くらいでできると御の字だねというくらいの粒度のタスクが予定通り終わるようになってきた気がするので、速度の向上を感じます。

  • 管理ツールでの各種条件でフィルターしてのメール一括送信(0.5〜1営業日 * 3つのタスクくらい)
  • ユーザーの退会(垢BAN)、退会ユーザ一覧と復元(削除実装で1.5〜2営業日, 復元で1くらい)
  • (マッチングプラットフォームなので)打診の前の自分の情報確認ページの作成(1〜1.5営業日くらい)
  • 管理ツールからのメンテナンスを入れる機能(コードリーディングをしてOSSにコミットできないかの検討 0.8, 無理そうだなと思って独自実装に切り替えてから0.7くらい)

もうちょっと速度はあげられるかなと思いつつ、以下のような課題があるので、上がった分の速度は学習時間に回して高度な仕事もできるようにしてくのが良いかなと考えています。 あとはPRコメントが炎上(めっちゃ大量に指摘が入ること)が減ったのでストレスは劇的に減りました。

 

課題

Laravelを使ってるのですが、フレームワーク側のコードを読もうとするとつっかえるのが頻繁にあります。

例えば、Eloquentまわりの、Collectionあたりに生えている関数がPHPStormでは補完してくれないのになぜか使えるという謎が解明するのに苦労してます。多分_call()とかマジックメソッドあたりがミソなんだろうと思っているのですが、理解しなくても書けなくは無いので多少おざなりになってます。

他にもキャッシュのどれを使うかという設定がENVでできるのですが、それに対応するインスタンス生成がどういう風にフレームワークで分岐しているのかというのがいまいちわからず。Factoryデザインパターン周りのネーミングがついているっぽいのでそれをちゃんと理解して読み込めば分かる気はするが、やはり業務優先でこれまでおざなりに。 デザインパターンの学習については開発チーム内で読書会をやっており "Java言語で学ぶデザインパターン入門" これをみんなで読んでいます。週に1章進めていますが、もうちょっと先回りしてやっていくといいのかもしれないと思いつつあります。   

所感

転職前は自分のサイトをまあまあの速度で作れるようになることを希望していたのですが、それはそろそろ出来るレベルになってきたのかなというかんじで、インフラしか出来ない!つらい!みたいな状態からは脱することが出来ました。

 

ビジネスサイドの知識

所属企業はM&Aプラットフォーム関係なので、会社売却や事業譲渡のフローは、本を数冊読んだり、会社で聞きかじったりしてなんとなくは分かってきました。軽い機能追加の仕様決めをする上ではそこまで困らないくらいです。

とはいえ、企業価値算定は業種などでどう変わるの?などの実務的な知識、そもそもの会計知識の不足でBSを読んでもあまりピンと来ないなど課題は盛りだくさんです。株価の目安になるPERやPBRについても何度定義を調べても、いざ自分で説明できるレベルかというと微妙。

 

実生活に良いフィードバックもありました。

例えば時価総額がどれくらいだとこれくらいのフェーズなんじゃない?という雰囲気がなんとなくわかってきたこととか。どこの会社がこういうビジネスでこういう調達をしたとか、これから上場する、とかいうニュースが楽しくなってきた。

多分後から見ると間違っている気がしますが今の所の雑なイメージでいうと

時価総額

  • 10億: ビジネスが軌道に乗り始めたフェーズ。調達額数千万~1億をする前後

  • 30億: ベンチャーとしては軌道に乗って、バイアウトするなりIPOを狙うなりなんらかのエクジットが見えてきているイメージ。大きめに数億調達して攻めに出るフェーズのところが多そう

  • 100億前後: 上場前後。そのまま上場せずユニコーン(未上場1000億)を目指すところもあるが、上場準備に入り始めている。

  • 1000億:やべえ一流企業

 

こんなふわっとした知識です!

そもそも株って何? 会社は時価総額(株価)をなんであげたいの? 調達ってどうやってお金集めているの? みたいなのが理解できるようになったのは大きな収穫かなと思います。

 

働き方など

決まった時間に出勤しなければいけないのは最悪かと思っていましたが、朝起きて生活リズムを整えてというのは考えることが減るので案外悪くないです。(とはいえこれからエンジニア採用していくのである程度フレックスが必須かなと思いつつ)

前職では自由すぎたので、11時になってそろそろ家を出ないといけない、と思いつつ別にすぐに行かなくてもいいので毎日判断が必要でしたが。今は起きる時間も家を出る時間も決まっているので判断をするのが減ったことはよかったです。

しかし通勤は悪。ラッシュではないものの多少混んでる時間なので電車が辛い時があります。やはり家は職場に近い方が良いです。

 

残業は周りは結構(1〜2時間くらい)している人が多いですが私は30分くらいでちゃんと帰ります。強い心を持って家で健康的な夕飯を食べて睡眠を8時間半とるのだ。

残業時間について周りに文句を言われたりせず、みんな楽しく好きなだけ働いているのでそれは良いかなと思います。とはいえ取締役の上司連中が無限に働いているのにひきづられて、そこまで残業したくない人がなあなあで残っていたりすることもあります。それはちょっと違うかなと思うので徐々に改善方向に向かうように促していけるといいかなと思います。

 

コメント

結論から言うと転職をすると言う判断は正しかったと思います。

スキルも付いてきているし、将来への希望もあります。

「私もベンチャーで働きたい」という方がいれば参考になれば幸いです。弊社では事業が割と成長してエンジニアをそろそろ増やしていくフェーズになってきたので、もし興味がある方がいればお話ししましょう。

転職しました

これは何

いわゆる退職エントリです。 転職活動とその意図について記録しておきたいと思います。

はじめに

株式会社ドワンゴを7月末で退職します。2014年に新卒として入社して5年目になり4年ちょっと働いたところでした。 ニコニコ静画・漫画のインフラリーダとしてアクセスが順調に増えていくシステムに対して、なんとか安定運用することだけをずっと考え続けました。会社全体の効率化のために他部署に借り出されたりしたけど軸足はずっと静画でした。 最初はくそ使い捨てスクリプトくらいしか書けないレベルだったけど、信じてインフラ権限を与えて成長させてくれたチームには感謝の気持ちでいっぱいです。

なぜ転職?

主な理由は以下のもの

新しいことにチャレンジするタイミングだと思った

  • 転職するなら30までにしたいと思っていた。私にとって社会人5年目のタイミングなので、経験と学習能力のバランスがよく取れている時期
  • インフラとしてずっとやっていくとやれることが頭打ちになる気がした
  • 最近はSRE的な動きをするようになって多少はバックエンドのコードを触るようになったけども、もっと多分野触って一人でちゃんとしたサービス作れるようになるまで成長したい、という思いがあった

一発当てたい

  • 昔からぼんやりと、お金を稼ぎたいという意識がずっとあった
  • 最近結婚したので将来お金がないことで困りたくないという意識が強まった。窮困することを心配するというより、やりたいことや住みたいところが出てきた時にコツコツ貯金してできる数百万〜千万のお金では自由になれないと感じた

ネガティブな理由は?


当然大なり小なりあります。よくある疑問について書いておきます。

  • 給料上がらなかったの?
    • 以前からお給料が上がらなくなったら会社から成長が止まったとみなされていると考えて、転職しようと考えていました
    • 幸い、2年目入ったあたりからコンスタントに上がってくれたので強い不満はそこまでありませんでした。強いて言えば、リーダという一応の肩書きがついた直後にあまり上がらなかったのでそれが転職活動のトリガーにはなりました。とはいえ、冷静に考えればリーダとして実績を出していけばまた問題なく上がるだろうとは思っていたので燻りながらもクリティカルではなかったです。他にいいところがなければ残留方向
  • 人間関係とか?
    • 良好でした
    • 強いて言えば、技術や仕事の進め方・改善提案がめちゃめちゃうまかった先輩や同僚が何人か抜けたことがありショックではありました。これも比較的自分が自ら学べるタイプではあるのでクリティカルではありませんでした(けど、転職というものがよりリアルに感じられたのは事実)

転職先について


というわけで、知人に誘われてM&A関係のプラットフォームを作るベンチャー起業に転職することにしました。ブログは現在の所属とは切り離しておきたいので少しぼかしておきます。

選んだ主な理由は以下のとおり

  • お金を稼ぐためにはお金周りの業種にいた方が良いと思っていたし、お金の話は元から好きだった
  • 社員エンジニア二人目なのでバックエンド・インフラをメインに多分野を触れるようになるのを期待

ドワンゴ社のいいところ

  • 本物の裁量労働により、時間の融通がきくのはいろんなところに書かれている通りですが、最高です。16時に朝会で、本当にその時間にギリギリ出社する人もいました
  • 自発的な勉強会がたまに組織される
    • 自発的に動けて技術が好きな人にとっては良い会社だったと思います
  • 祭りが定期的に発生していた
    • 超会議とか公式の祭りもありますし、闇LT大会などの他の会社ではなさそうな奇抜で面白い人の祭りが沢山ありました
  • やりたいと言って、自分で仕事を取りに行けばやりたいことをやらせてもらえます
    • 良くも悪くも言い出しっぺの法則
    • どこでも一緒だとは思うけど意思表現が苦手な人には辛いことも多かったように見えました(これはいいところではないか。まあ表裏一体なのでしょうがない)

転職活動についていろいろ

いろいろ転職サイトやエージェントを使いました。時系列で並べておく。何かの参考になれば。

2年目終わり頃くらい

怪しげなヘッドハンターからメールが届き始める。 話を聞いて近い同業他社を紹介されるが1人前になる前にどこに移動しても同じだろうなと思って一回だけ話を聞きに行ったが後はスルー。

4年目始めくらい

技術ブログを適当に書いて wantedly に登録したらそれなりにオファーが沢山来た。 数社知っている会社を中心に話をききにいきました。印象的なのは以下のところ。

  • リクルートライフスタイル: 問題解決できる人しかとらない、というのが印象的。「あんまり活躍できない人がいたらどう扱うの?」と質問したら「しっかりお金渡す早期退職制度があるからそういう人はいなくなる。」(私がそう受け取ったという解釈です)と言われたのですごい会社だなと興味を持った
  • アトラシアン: 場所が横浜の馬車道にあって西海岸の雰囲気。昼前に会社訪問に行ったらメンバーと一緒にランチをすることになって、メンバの印象がすごく良かったので1〜2ヶ月くらいずっと本気で考えて転職しようか悩んでいた。ただ、まだバックエンド開発をほとんど触っていなかったのでサポートエンジニアになってそのスキルが取れないのはキャリアとしてまずいと思って見送り。
  • マネーフォワード: お金の会社はお給料良いのだなあ(雑)と思った。話が合いそうな人が多そうな会社だなとは思ったが、現場メンバとは実際には顔合わせしなかったのでそこまで本気で考えれなかった気がする。

4年目終わり頃

市場価値を知りたくなって転職ドラフトに登録して本気でレジュメを書いた。 現職より100万くらい高いオファーを出してくれた会社が複数あったので、エンジニアは転職すると給料が上がるというのを実感する。 あとバックエンドコードが書けるインフラエンジニア(SRE)が需要が高いことを肌で感じた

印象に残った会社

  • コネヒト: ママリという子育て世代向けSNSを運営している会社。インフラエンジニアの方とじっくり面談して、なんだか感覚的なところだけどすごく働きやすそうな気がした。やることが現職とあまり変わらなさそうというのとお給料的にも多少上がるくらいなのでリスクをとったり関係を断絶させてまで行くのは躊躇して断念
  • マネーフォワード: ここでもありがたくもオファーをいただきました。結構スキル的に雰囲気的にマッチしていたみたい
  • ヘルスデータプラットフォーム: 面談通してものすごく高く評価してくれました。手当を入れるとその当時の給与から150万以上も上がることになりクラクラした。健保会員向けアプリの開発会社で、肝心の事業内容にそこまで興味が持てなかったのが残念なところ。「専門家同士でお互い背中を守りあって開発していきましょう」とおっしゃっていたのが印象的でした

5年目始め

他の業界や職種も視野に入れて将来を考えたいと思ってエージェントに相談するべく登録してみた。 しかし同時期、退職した同僚を交えた飲み会でちょうどエンジニア募集をしているという話に。 「バックエンドでもなんでも長い目で見て経験させてくれるならありだね」という私の希望にマッチしそうだったのでオフィスに遊びに行くことに。お金の話と人を見て、これならいけるかもと思って転職を決意。

あとがき

ドワンゴ社には本当にお世話になりました。どこでも働けるスキルを得たいと思って新卒で入った会社だったけど、大正解でした。部署配属も「勉強できるところに入れてください」と面談で言って構築運用部というインフラ部署に入れてもらったのも良かったです。

次の会社でうまく働けるか分からないけど、無理をしすぎることなく淡々とやっていけば道は開けるはず、と信じてやっていきます。

インフラ手順書テンプレートを作った話

これは何

インフラ的な手順作業書の書き方についてまとめたい。 このページのテンプレートをコピーして書き始めると、手順書がスムーズにかけることを目標としています。 ここに書いてあるものはコンフルエンスを前提として書いています。

インフラ作業をやるときには原則的に手順書を書いてチームメンバーにレビューしてもらいましょう。 予定していない作業をぶっつけ本番でやると、大幅に時間がかかったり事故がおこったりすることが多々あります。

手順を残しておけばどういう進捗状態になっているかすぐ分かりますし、これから近い作業をする人が参考にすることができます。 まったく手順資料がなかったとすると、すべての作業をゼロから考えなくてはならず、大きなコストがかかってしまいます。手順を作ること自体がコストではありますが、長期で見てコストが低くなると考えて資料化するべきだと考えています。

=============以下手順テンプレート=====================

タイトルは、実施日時が決まっている手順は年月日を書いておきましょう。例えば単に「メンテナンス手順」と書いてあると後から見た時にいつのかわからなくなりますが、「20180206 全体メンテナンス手順 MySQL Master昇格」 などと書いてあると大体タイトルだけ見て参考にできるか判断することが出来ます。

目次

目次はつけましょう。目次を見てよくわからない(階層がガタガタしているとか、節のタイトルが意味不明とか)の場合にはたいてい読みづらい資料になっています。

作業目的&作業概要(方針)

この作業書にかかれている作業の目的と概要を書きましょう。 目的を達成する手段は(場合によっては)沢山あるので、目的をはっきりさせて手順方針を決めた時点でチームレビューを受けたほうが手戻りが少なくて良いです。 目的と方針は表裏一体なので対で書くと良いのではと考えています。

作業目的

目的です。

作業概要

この手順の概要について数行程度で書きましょう。細かい手順だけがあると、それをすべて読まないと全体をつかむことが出来ません。

期限&スケジュール感

厳密な期限がある場合にはそれを根拠と共に書いておきましょう。チケットなどあれば貼っておくとよいです。  特に強い根拠がなくても期限の目安や目標時期だけ書いておいてもいいと思います。仕事を振った人が「このタスクはどれくらいかかるかな? いつ終わるのかな?」というのが把握できるようにする目的です。 ある程度タスクが洗い出されている場合には、いつごろにどのタスクをやるというロードマップを書いておくとよいです。厳密でなくてもよいので工数見積もりが書いてあるといいかもしれません(理由は同上)。

関連リンク

チケットや全体を通した参考資料を貼っておきましょう。前提知識やこれまでやられた似た作業手順を貼っておくのも良いと思います。 手順の個別項目に関連する資料はその場に貼っておいたほうが便利です。

手順に関わる調査資料などを子ページに置いていきましょう(コンフルエンスなど階層化できる場合)。子ページへのリンクが自動で表示されない設定になっている場合には子ページを表示するとしておいたほうが階層がすぐ分かって便利です。子ページのマクロは孫ページまで表示するように設定することもできます。

検討事項

検討内容によって手順が変わるような先に考えておくべき重要な検討事項について書いておきましょう。なければ不要です。 検討が終わったらそれをタスクに落とし込むか、「その他」項目や子ページにまとめるなどしましょう。

検討事項1

ほげ

検討事項2

ふが

事前準備

当日でなくてもできる作業については事前にやってしまいましょう。やった結果もまとめておきましょう。 特に他部署依頼など時間がかかりがちなものは先に潰しておきましょう。作業ボトルネックは何か? それを潰すには何をすればいいんだろう?という視点で考えるといい気がします。

事前準備1

ほげ

事前準備2

ふが

同期的作業タイムスケジュール

他チームと同期的にやらなくてはいけないとかメンテナンスの時間が決まっているなど、当日のタイムスケジュールを決める必要がある手順については書いておきましょう。非同期でできるものは事前作業としてやってしまいましょう。 同期的作業が特になければ、事前作業、事後作業ともに一つの項目にまとめてしまって良い。

実際にかかるだろうなという時間に追加してバッファや万が一の切り戻しの時間も考慮して決めましょう。

| 時間 | 作業内容概要&リンク | 担当者 | |:-----------|------------:|:------------:| |xx:xx ~ | 詳しい作業内容が長くなる場合には作業詳細に書いてリンクを貼っておきましょう。 | やること: @担当者 役割分担できそうなら相談して依頼しましょう。 | 長時間に渡る作業の場合には休憩時間なども考慮に入れましょう。人は休まないとミスをします。

依存関係があるサービスには連絡しておきましょう。その話をしたリンクもはっておきましょう。当日に連携が必要な場合にはその連絡内容もあらかじめ作っておくとテンパらなくてよいです。

同期的作業詳細

上のタイムスケジュールに書ききれなかった詳細な内容について書きましょう。上のタイムスケジュールにリンクを張りましょう。リンクは目次のものをコピーすると楽です。

設定更新がある場合には、その設定を確認できるコマンドなども一緒に書いておきましょう。可能であれば設定の一部だけでなく全部をカバーする確認方法を検討しておきましょう。

中作業1

作業は問題があった時に巻き戻せるように進めましょう。可能な限り一気にすべてを破壊的に進めるのではなく、徐々に次の状態に移行していきましょう。

少作業1

チェックボックスで細かく書いておいたほうがよい 終わったらチェックをつける

少作業2

好みではあるが、少作業にもタイトルをつけたほうが目次を見て流れがつかみやすい

中作業2

ふが

後処理

当日にやらなくてもよい手順についてまとめておきましょう。 忘れがちなのでリマインダやgaroon予定など入れておくとよいかもしれません。

その他

参考となる小話や調査について書く。分量が多いときには子ページに切り出しましょう。

非効率な仕事の進め方とルール化について(オートフォーマット編)

背景

最近ちょっとだけバックエンド開発の仕事をやらせてもらっている。 当然その分野の先輩がいるわけで、その人たちの書いたコードを修正したり追加したりするのが多い。

IntelliJを使ってPHPを書いているのだけども、オートフォーマットをしてPRを出すと細々とコメントがつくことが何度かあった。 私はREADMEに書いてあるルールに従ってIntelliJのオートフォーマッタを設定して修正しているだけなんだが、ここはこうした方が良いとか、最近の運用ではこうなっている、とか細々としたコメントが大量につく。 「クラス定義の後ろの "{" の前は改行しよう」とか「いや、ここは今はもうそのルールは古い」とか。そんなくらいの話。

問題点

おかしいな?と思ってヒアリングすると幾つかの問題がチームにあることがわかった。

  • READMEの記述が古い
    • 古いコードに引きずられてルールが作られていて、すでに誰も見ていない。新しく入った人だけがそれを見て振り回される。
  • 昔のコードをフォーマットするかしないかで意見が統一されていない
    • 自動フォーマッタを入れている人は修正を出すが、そうでない人も多い。ボーイスカウトルールとは(来た時より出る時には綺麗にしましょう)
  • 温かみのあるコミット分割
    • ある人は新規で追加した部分はフォーマッタかけるが、ファイル全体に修正がPRに出るといやなので、git add -pなどを用いて自分の変更箇所だけコミットするなどしていた。温かみ運用。毎回手動でやっているのか・・・

修正

私の提案

  • 形がい化したルールを削除(READMEに書いてあることは正しいものとする)
  • PRで議論をして満足するな。議論して決まったことは同じことを繰り返さずREADMEに明記すること。書いていないルールはそのPRを通す通さないには関係してはならない。直したければ別PRとして修正すること。
  • オートフォーマッタ設定の方法もかく。会社でライセンス買っていて大体みんなIntelliJ使っているのでその設定方法の明記。vim使っている人は従ってもらい同等のものを入れてもらう
  • 古いファイルもまずオートフォーマットしてそのコミットを分ける。必要に応じてPRも分ける。実作業と分けた方が良い(緩やかなルール)

できなかったこと

  • editorconfig などでルールの自動読み込み
    • すでにあるエディタ設定が優先だったし、PSRなど包括的なルールで設定できなさそうだった。これは知見が足りないだけかもしれない。

終わりに

上の提案はあくまで提案で、そのような内容をREADMEにかくPRを出してマージされた段階。 そのあとの運用はまた回してみて問題が出れば修正。

とにかく「繰り返しの無駄な議論」「細かすぎる指摘によるマージブロック」「温かみのある手作業」 こういうのをなくしていかなければならない。