会社売却の価格算定の時によく出てくる単語「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関係のプラットフォームを作るベンチャー起業に転職することにしました。ブログは現在の所属とは切り離しておきたいので少しぼかしておきます。

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

  • お金を稼ぐためにはお金周りの業種にいた方が良いと思っていたし、お金の話は元から好きだった
  • ストックオプションをもらえるので上場したら一発当てられる
    • 当たれば億万長者ではないけど、二発目当てるために一息つけるくらいの金銭的余裕はできそう
    • 自分では出来ないちゃんとした営業ができる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/外部リンク

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

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