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

目次

 

これはなに

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

 

エンジニアとしての成長

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

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

最初の頃の状態

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

  • データを吸い出す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関係のプラットフォームを作るベンチャー起業に転職することにしました。ブログは現在の所属とは切り離しておきたいので少しぼかしておきます。

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

  • お金を稼ぐためにはお金周りの業種にいた方が良いと思っていたし、お金の話は元から好きだった
  • ストックオプションをもらえるので上場したら一発当てられる
    • 当たれば億万長者ではないけど、二発目当てるために一息つけるくらいの金銭的余裕はできそう
    • 自分では出来ないちゃんとした営業ができるCEOはじめとするチームメンバがいるし、ビジネスモデルも納得できるものなので、自分の努力次第で最高のシステムを作って一発当てられると信じている
  • 社員エンジニア二人目なのでバックエンド・インフラをメインに多分野を触れるようになるのを期待

ドワンゴ社のいいところ

  • 本物の裁量労働により、時間の融通がきくのはいろんなところに書かれている通りですが、最高です。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を出してマージされた段階。 そのあとの運用はまた回してみて問題が出れば修正。

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

誰かに質問をわざわざしに行くのが苦手な私が、それを克服した話

背景

私はもともと誰かに質問をするのが苦手な気質。 ランチや移動中にカジュアルな話をしていて「そういえば」くらいのノリで聞くのはできたけど、改めて「質問なんですけど・・・」みたいに人の席に行って聞くのが苦手だった。

問題点

エンジニアをやっていると分からないことはたくさん出てくる。 ドメイン知識についてや難しい技術について。

ドメイン知識についてはそもそも聞かなきゃわからないことが多い。 サーバの中をひたすらあさったり、コードを読んだりして推測することはできるけど、時間はかかる。

(自分にとって)難しい技術についても、ブログ読んだりドキュメント読んだりすればいつかは扱えるようになる。 大体の場合は通勤時間にスマホで雑にブログとか5個くらい読んで大まかな用途みたいなところを掴んで、公式ドキュメントで理念や細かいHowを読み込むと自分のものになっていく気がする。 たまにブログ情報も少なかったりドキュメントが貧弱なミドルウェアとかにぶち当り、無駄に時間をかけてしまう。

そういう時、詳しい人に「ねえねえ、10分だけちょっと最初の概要だけ教えてよ」と話を聞いて、そのあと自分で触ってみるとすっきり問題なく使えることが多い。

わかっちゃいるが聞けない

質問の仕方として「自分が何が分からないのかはっきりさせてから聞きなさい」と教育されてきたからなのかカジュアルに人に聞けない。 分からないことが分からない時には誰かに話してはいけないような気がしている。でもその時間が長く続きすぎるなら、10分だけ時間をもらったほうが良さそう。

克服しつつある

最近、あるプロダクトのSRE的な部分のリーダとして仕事をするようになった。 必然的に、誰かに技術や仕事の進め方、ドメイン知識を伝えないといけない。 私が仕事を振る時、相手に最初に短い時間をとってもらって出来るだけ方針やはまりどころを伝えようとするけども、それでも伝えきれないものが出てくる。または、ある程度進んだけど次のステップで困っているなどの相談がくる。 その時に(みんなじゃないけど)私の机のところにカジュアルに話を聞きに来てくれる人がいる。

仕事の進め方ってみんなやり方がバラバラで、Slackメンションしてから時間とってもらっていいでしょうか?みたいにちゃんとする人も、しゃべりながら近づいてきて問答無用で会話を始める人、逆に詰まっているのに話を全然持ってこない人など。 その中でピカイチの成果を出すのはやっぱり躊躇なく話を聞きに来る人。

こちらの時間は取られてしまっているのだけど、それでもその人がウンウン唸って詰まる時間が少ないので仕事はスムーズに進む。チームとしてトータルコストは低そう。 そういう風に人の仕事ぶりを見るようになって、忙しくなってきた自分がコストを低く結果を出すためには、やっぱり誰かの力をテコとして使うのがいいんだろうなと思ったりする。すべての内容を聞くのは相手の時間を使いすぎるのでいまいちだけど、一番詰まるところだけを人の力を使って解決してしまうのが良いのかなと。

終わりに

まだ克服できていない部分ももちろんある。意識して克服していきたい。 ”人に質問をする”のが苦手という断片的な部分よりも、最小コストで結果が出せているかな?という点にこだわっていきたい。 この文章を書いたのは、後から自分が見て、ちゃんと出来るようになっているかな?というのを確認したいがため。

チームがうまくまわるようにAnsibleのPlaybookでGitHubプルリクテンプレートを使いたい話

目次

背景

最近インフラを触り始めた人と一緒に働くことが多くなってきた。みんなに効率よく経験を積んでもらいつつ、インフラチームをうまく回すための施策を細々考えている。この記事はその中の一つについてのメモ。 私は「こういう内容が良いのではないか」と思って作ったものなので今後チーム内外の意見をもらって内容が書き換わる可能性は大いにある。

GitHubのテンプレート機能はどう使うか

レポジトリのルートディレクトリに PULL_REQUEST_TEMPLATE.md という名前でファイルを置くと、プルリクを作るときに自動的にその内容が書かれる。 詳しい置き方や仕様についてはググれば出てくるのでここには書かない。

テンプレートを作るにあたり気をつけたこと

  • 後からプルリクを見直したときに、何をやっているか分かるか。後から新人が入ってきたときにプルリクをトレースして学ぶことができるようにしたい。
  • 開発環境や本番環境に全て(半)自動反映になっていれば最高だが、今のところそうなっていない。 反映漏れ事故をなくしたい。
  • コードだけ書いて本番に反映せず満足してしまう人もたまに居るので、きちんとデリバリーしようという意識を持ってもらうために、それを促す記述を入れたい。
  • プルリクを出した後のネクストステップを意識するとスムーズに仕事が回るので、それを考えてもらいたい。
  • 時間は無限ではないので緊急度や重要度を意識して、やらなくて良い仕事はやらない。ネクストステップがない場合もある。
  • よく分からないことをプルリク出してもレビュアが気がつかなければプルリクが通ることがある。事故の元なので曖昧なことは表明してもらってみんなで解決したい。

テンプレート内容

# 概要
### 経緯
issueやconflenceリンクがある場合にはそれを張っても良い。

### このprの目的
課題は何か

### 変更点概要
この変更によりどう解決されるのか

# 本番/開発環境更新
### 反映タイミング
開発環境と本番環境への反映を行うタイミングを記述する。以下の選択肢から1つ選択して詳細を記述する。

* 開発環境に反映済み
  * 対象サーバを記述する
* マージ後開発環境にのみすぐ反映する
  * しばらく開発環境で動作を確認したい場合に選択。もしくは緊急度が低く、本番へは次のサーバリプレイス時に入れば良いという場合
  * 反映すべきサーバを書いておく
* マージ後すぐに本番に反映する
  * 緊急度が高い場合
  * 本番更新チケットを作成して、リリースタグを切って反映する。参考: http://hogehoge.jp
  * 反映すべきサーバを書いておく

### 動作確認手順
更新後に行う動作確認の手順を記述する。すでに開発環境で動作確認を行っている場合にはその内容を書く。
できるだけprを出した本人以外でも動作確認ができるように書く。自明な場合には記述しなくてもよいが、レビュアーはレビューをする段階で分からなかったら確認するのが望ましい。

# 関連issue/pr/外部リンク

# その他
### 今後の課題
次に解決すべき課題があれば書く。

### 実装に関する留意点
困ったことやイマイチな点など。

初めて会社でAPIを書いて学んだことメモ

これは何

普段主にインフラエンジニアとして働いている私が、会社で初めてAPIを一つ書いたので、そこで得た学びや考えたことを記録しておこうと思います。

何を学んだこと・考えたこと

仕様書を書こう

どのようなAPIなのか、目的やリクエストパラメーターやレスポンスフォーマットについて定義する。 特にAPIの場合はレスポンスフォーマットが変わるとクライアント側でパースするのに困ってしまうのではっきり定義しなければならない。 APIは使う側ありき。

レスポンスフォーマットの統一性

他のAPIとできるだけ揃えた方が良い。統一性がないと使う時に大変。 ドメイン全体でJSONのうちのMeta情報やDataオブジェクトをどのようなフォーマットにするのかというのを決めておき、各種APIはそれに従うのが良い。何も決めずに走り出すとメチャメチャになってしまうのでまず共通ルール。共通ルールはフレームワークへ落とし込んでおいて、そのフォーマットから外れなければ簡単にレスポンスを作れるようにしておく。 共通ルールをしっかり作っておくと大枠は固定されるので、後から細かいところをちょっと変えるにしても混乱が少ない。

DBで保持しているデータとAPIJSONのキー名は必ずしも合わせる必要がない

裏で使っている名前に引きずられがち。利用者にとって使いやすい名前にする。 例えばDBで公開状態をpublic_statusという名前で持っており、0,1の値を取るとする。どちらの値がpublicなのかちょっと分かりづらいと感じたとする。その場合、public_statusにこだわらなくても、APIレスポンスとしてはデータ要素が削除されているかというのが重要であるなら is_deletedという名前で返してあげるのが親切。

時間はUnixTimeで返そう

JSTUTCで帰っていると使いづらい。DBでJSTで保持していても変換してUnixTimeで返すと良い。

エラー応答についても定義しておこう

主なエラー応答やステータスは共通ルールとして定義しておこう。 各APIの仕様書においては、特殊な条件やちょっと迷いそうな場合についてエラー応答について記述しておこう。

仕様書はコードからすぐに参照できるように書いておこう

@see などで参照リンクとしておいておこう。 簡単な説明はコードにコメントしてしまった方が良いが、長くなるなら仕様書に切り出してリンクを貼っておくのを忘れずに。1セットで管理していく。

コードフォーマットはエディタに任せよう

エディタに微妙にフォーマット設定が入っていなくて細々としたPRコメントを沢山もらっしまった。 フォーマットについてはプロジェクトのREADMEにすべて明記して新しく入った人が迷わないようにする。可能であればエディタ設定ファイルなども共有しよう。 人間がやることではない。機械に任せられるのは機械に任せよう。

テストを書こう

PRコメントに長々と手動の動作確認の結果を書くのはよくない。TDDの考え方を取り入れて仕様が決まったら先にテストを書いてしまうのが良い。

コメント: とはいえ今回のケースでいうと、それなりにテスト書くのに苦労したので先に書くのは難しかったかも。Seleniumでテストを書いたのだが、他の開発者がMacだったが私だけWindowsでテストを回したので無駄に苦労した。開発環境は可能なかぎり教えてくれる人と合わせた方が良い。

同じような応答を返すWebFrontページがあるなら仕様を合わせよう

WebFrontページとソート順や件数などの仕様が異なると混乱を招く。仕様がくいちがうならその旨を理由と合わせて明記しよう。