プログラマーの種類、いろいろあると思う。

  1. ハッカー
    プログラミングが楽しくて、コードさえ書ければあとは何でもいいという人。
  2. OSS プログラマー
    1 と似てるけど、 OSS が楽しくてコードを書いてる人。カンファレンスで登壇したり、技術ブログを熱心に書いたりする。
  3. プロダクト指向プログラマー
    開発だけでなく事業の方向性にも口を出したい人。社長が死んだらいつだって代替ができる、というような気概の人。
  4. サラリーマンプログラマー
    プログラミングは仕事のためと割り切っていて、余暇には一切コードを書かない人。

1 〜 4 のどれか一つに綺麗に分類できるというものではなく、 1 かつ 3 とか、 3 かつ 4 とか、複数にまたがる人もいる。

職業プログラマーになりたての頃、サラリーマンプログラマーしかいない環境で働いて早くそこを抜け出したいと思っていた。プログラマーは会社の最下層で、プロジェクトマネージャーや営業が偉かった。プログラマーの人たちは仕事のために仕方なくプログラミングしてた。

それが嫌で余暇でもコード書くような人たちがいる職場に移ったけど、そこではハッカーや OSS プログラマーがよいプログラマーの代表とされていた(と思う)。自分もそういうのを目指し OSS カンファレンスに登壇したり技術的に中身のあるブログ記事を書いたりしたいと思ったけど、なかなかよいコードは書けないし、結婚して所帯を持つと町内会の草むしりや廃品回収、町内の運動会のテント設営、審判にかり出され、またあるときは子どもの幼稚園に夫婦そろって呼び出されて「お前らは夫婦そろって人間の屑以下だ、心を入れ替えるか幼稚園を辞めるかどっちか選べ」と説教されるなど多忙を極め、勉強会で話したりブログ記事を書いたりということが難しくなった。

一時期は自分は凡人プログラマーなんだろうなぁ、かつて忌み嫌っていたサラリーマンプログラマーと同じなのかなぁ、と将来を悲観していた。この頃は技術的な伸びしろがなくなって学ぶことに対する意欲が失せてしまっていた。

ただ、仕事で失敗プロジェクトを担当してつらい目に遭うことが多く、チームで仕事することだとか、失敗からどう学ぶかとか、その手のことに関してはそこそこ知見が貯まっていった。どうすればチーム開発はうまくいくのか、どういう風に情報を共有すればいいのかなどなど。業務改善のためにちょっとしたスクリプト書いたり、ぶっ壊れて動かなくなってる hubot スクリプトを直したり、 CI のセットアップを頑張ったりと、エンジニアチーム全体の生産性を上げるような落ち穂拾い業務みたいなタスクも好きだった。

いまは自分はチーム開発プログラマーなんだろうなぁと思う。ハッカー気質は皆無じゃないけどそこそこ、 OSS へのコントリビュートも気が向いたときに、プロダクトのことを気にする気持ちもある。どれも中途半端で単独では生産性高くないけどチームで仕事をするときに効能を発揮するタイプ。こんな風に自分が適している役割が分かると仕事がやりやすくなるし、目指すべき方向性のようなものが明確になって将来のことを考える上でも役に立つ。

ベンチャー企業で働く場合は自分のマインドやスキルセットが会社のステージにフィットすることも大事だと思う。もともとはベンチャー企業でも成功して上場しているような会社だとデプロイ時にハンコリレーなどがあってやるべきことをやるべきときにババッとやるのが難しい。そういうのは自分には向いてない。一方で起業したばかりの小さなスタートアップも、自分のような最初から綺麗なコードを書こうとするプログラマーはきっとフィットしない。起業したばかりのスタートアップでは自分たちの事業が社会から求められるかどうか不透明なので、そんな状態でテストがどうだとか CI がどうだとかチーム体制がどうだとかを言うようなプログラマーは必要ない。汚くてもクソコードでもテストコードなんて存在しなくてもいいからとにかく金を生み出すコードを素早く書ける人が向いている。

その意味でいまいる会社は創業当初の価値仮説の検証は済んでいて、これからいかに事業を伸ばしていくかというステージに入っているので、ちゃんとテストを書いたり、 CI を導入して継続的インテグレーションに努めたり、デプロイをいい感じにしたり、情報共有ツールを導入したり、開発チームの組織体制を云々したりといった部分で価値を発揮しやすい。

一握りの本当に優秀なソフトウェアエンジニアってのは受託会社だろうが事業会社だろうがベンチャーだろうが大企業だろうがどこにいたって価値を発揮できるのかもしれない。しかし自分のようなすべてにおいて中途半端なプログラマーは、自分に何ができるのかを理解し自分を必要とする規模とステージの会社を見つけてそこの門を叩くのがよいと思う。もちろん、事業に共感できるとか、チームメンバーとの相性も大事だけど、事業に共感できてもチームのメンバーがいい人ばかりでも、会社の規模やステージが自分を必要としなければ価値を発揮することは難しい。

ECS 化していたブログをさくら VPS に戻した。理由としてはお金が高かった。普段、 S3 と Route 53 に払ってる金額の 20 倍くらいの金額になって少ない小遣いでは払えないと思ったので VPS に戻した。ただ AWS で運用して勉強になった点もあった。

まず ECS での運用について知見が得られたのがよかった。 deploy するためには docker builddocker push が必要で、最初はちょっとした修正のためこれやるのは大げさだと思ったが、慣れればそんなでもなかった。ただイメージのビルドをどこでやるかは考えといた方がよさげ。自宅だと高速な光回線があるからよいけど、実家やどこか旅行に行ったときに image をビルドして ECR にプッシュするのはつらい。 GitHub に git push する度に CircleCI でビルドされるような体制を構築する必要があると思った。

CloudFront をウェブアプリケーションの前段に挟む、というのもやってみたけどこれもよかった。 Rails なら Asset Precompile によって静的なファイルへのリクエストはウェブアプリケーションまで届かないようにするのを良くやると思うけど、 Lokka は Sass や CoffeeScript を動的にコンパイルしてクライアントに返すので、 CSS や JS などへのリクエストにも puma のプロセスが消費されてエコではなかった。 VPS 運用時には Nginx を前段に入れて、画像やコンパイル済みの JS / CSS ファイルへのリクエストは puma にプロキシせず直接返していたが、 ECS 化したときに Nginx を挟まなくなったので CloudFront を入れて画像や JS / CSS へのリクエストをキャッシュするようにしてみた。

cloudfront-ecs-image.png

すると puma の負荷が低下し、 New Relic の Appdex が 0.95 前後だったのが 0.99 になった。 ECS で利用していた EC2 コンテナは t2.micro でしょぼいのでサーバーのスペックアップで改善されたわけではない。ということで VPS に戻すときにも Nginx の proxy_cache を使って Sass や CoffeeScript から動的にコンパイルされる CSS / JS をキャッシュするようにしてみた。さすがに CDN のような配信の最適化は実現できないが、以前よりかはかなりましになるはず。

なおセッションを有効にした Rack アプリで Sass や CoffeeScript を動的にコンパイルすると Set-Cookie ヘッダーがセットされてしまう。 Nginx の proxy_cacheSet-Cookie ヘッダーがセットされてるとキャッシュをしないので、

proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;

などとしてやる必要がある。

今後仕事でも ECS 化を行う予定があるので得られた知見を有効活用していきたい。

castro-and-overcast.png

Podcast を聞くのには Marco Arment の Overcast を使ってたんだけど、最近「 Internet Connection を確認しろ」みたいなメッセージが出てエピソードの一覧を取得できないことが何度かあってストレスに感じたので Castro に変えてみた。 Overcast は独自のサーバーサイドアプリケーションがあってそこと通信してるので、 overcast.fm の調子が悪くなると新しいエピソードをダウンロードできなくなる。 Castro や Apple の Podcast アプリだと iTunes から直接ダウンロードしてるので iTunes のサーバーがダウンしない限りエピソード一覧を取得できないということは起こらない。

エピソードの再生クオリティに関してはやはり Overcast の方がすばらしい。無音部分のカットや賢い倍速再生はやはり Overcast ならではだと思う。 Castro で再生してみて無音部分は結構気になることに気がついた。

一方でエピソード一覧の UI などは Castro が優れていると思った。以前聞いたエピソードを聞き返したいとき、 Castro は年月でエピソードがグルーピングされるので心理的に探しやすい。

castro

Overcast の方は雑然とエピソードが羅列されているだけなので探しづらい。

overcast

プレイリスト

castro

Castro はプレイリスト機能が前面に出ていて、基本的にリストに聞きたいエピソードを登録して聞くというスタイルになる。次に聞くエピソード、過去に聞いたエピソードのヒストリー機能もあるので、昨日聞いたあれをもう一度聞きたいというときにも便利。 Overcast にもプレイリストはあるが存在に気がつきづらい。次々に新着のエピソードを聞いていくという使い方には向いてるが、過去のエピソードを掘り出して聞くときには Castro の方が優れている。

再生中画面

再生中の画面に関しては Overcast の方が良い。カバーアートをスワイプするとショーノートとチャプター一覧を行き来できるのも便利。

overcast overcast

Castro はショーノートと再生位置の切り替えは▽のトグル式で、しかも再生位置確認画面は SoundCloud のように波形表示される。

castro castro

正直こんなのは必要ない。僕は興味のない話題はスキップするので Overcast で聞いているときはショーノートを見ながら再生位置スライダーを動かしてスキップしたりするが、 Castro ではショーノートを表示している状態では再生位置スライダーが表示されないので 30 秒早送りボタンを連打するしかない。

結論

再生中の画面の UI には問題があるが、全体的なルックアンドフィールは Castro の方が優れていると感じた。配色を含めたデザインは Castro の方が使いたいと思わせられる。ちゃんとデザイナーによってデザインされている感じ。 Overcast の方はエンジニアが片手間でデザインした感がぬぐえない。

Overcast に不満がある人、過去エピソードをよく聞く人は Castro を試してみるといいと思う。

docker-and-ecs.png

ブログを Docker 化して AWS ECS で運用するようにした。

なぜ Docker 化したか

  • 仕事で Docker を使う機会が増え知見がたまってきた
  • 仕事では Production 投入はできていないので個人ブログで Production 投入して知見を得ておきたかった

どうやったか

ローカルセットアップ編

  • Dockerfile & docker-compose.yml を作成した
    • Alpine Linux を使ってなるべくイメージを小さくする
  • Gem::LoadError 問題
    • Lokka の Gemfile には動的な読み込みを行っている部分があるため、 Dockerfile で単純に COPY するだけでは Gem::LoadError になってしまう。
      • Lokka のプラグインは Gem 化されておらずリポジトリ内に含める形式
      • プラグイン側で必要な gem はプラグイン内に Gemfile を配置して宣言する形式
      • Lokka 本体の Gemfile には Dir["public/plugin/lokka-*/Gemfile"].each {|path| eval(open(path) {|f| f.read }) } のようなコードがあって強引に eval で内容を取り込んでいる
    • 対策
      • Gemfile.docker を用意する
      • Gemfile.docker を生成するためのシェルスクリプトを用意して実行する
      • Dockerfile の COPY は以下のようにする
      • COPY Gemfile.docker /app/Gemfile
  • 他、 MySQL のコンテナを追加して手元でアプリが起動するところまでは確認済み

Production セットアップ編

  • ECR にリポジトリを作成し image を push (公式のチュートリアル通りにやればできる)
  • ECS にサービスやターゲットグループ、タスクの作成なども指示通りに行う
    • 土台となる EC2 インスタンスは手動で作るのではなく、 ECS の画面でポチポチやると勝手に作られる
    • 詳細コンテナ設定でエントリポイントを入力する欄に、 Dockerfile と同じように文字列で書いていたらコンテナが起動せずハマった
      • カンマ区切りで書かないといけないらしい
      • puma を起動したかったら bundle exec puma ではなく、 bundle,exec,puma というように書かないといけない スクリーンショット 2017-08-19 10.50.09.png
  • 諸々設定を済ませたらロードバランサー( ALB )を EC2 のパネルで作成してターゲットに Docker コンテナが動いている EC2 インスタンスを指定する
    • ECS の用語やサービス構成に慣れるのに時間がかかるが、歯を食いしばってがんばるしかない
  • DB に関しては RDS を使うことにした
    • 稼働中の VPS サーバーで mysqldump -ufoo -p db_name | mysql -ubar -p db_name -h foo.bar.ap-northeast-1.rds.amazonaws.com みたいな感じで雑に流し込んで移行する
  • ECS は VPC でしか使えないので、 VPC に慣れてない人は VPC に慣れるところから頑張るしかない
  • セキュリティグループの設定なども必要になるので頑張って下さい
  • Nginx を利用しないので SSL の復号を ALB で行う必要がある
    • ACM で無料で証明書を発行できるのを知らず、 Let's Encrypt の証明書を取り込んで使う
  • ここまでで一旦公開

運用して気づいた問題点

  • サイトが 503 や 504 になる
    • Docker コンテナがすぐ死ぬ
    • ALB から切り離されることしばしば
    • VPS 時代は Nginx に静的ファイルの配信をまかせていたが、 Nginx を挟まなくなったので puma が担当することになりアプリの負荷が高まったのではと推察
      • CloudFront を挟んでいい感じにキャッシュしてもらい、静的ファイルの配信は CloudFront にまかせることに

CloudFront 導入編

  • ALB で使っているのとは別に SSL 証明書を取得する必要がある
    • CloudFront <-> ALB 間の通信を HTTPS で行うため
    • Route53 で ALB に割り当てている A レコードをサブドメイン付きの別のものに変更
    • ALB 用にはワイルドカード証明書を使う(無料で証明書取得できる ACM 最高)
    • Let's Encrypt の証明書を使うのはやめ、ルートドメインの証明書も ACM で取得して CloudFront に設定
  • 動的コンテンツ( HTML など)はキャッシュしないようにしないといけない
    スクリーンショット 2017-08-19 11.32.04.png
    • 当初、設定がうまくいっておらず、以下のような問題が発生
      • POST, PUT, DELETE できない
      • Cookie が origin に転送されずセッションが維持できない
      • クエリストリングが無視されてしまい、ページ検索などができない

所感

  • 体感的にサイトの読み込みがチョッパヤになった
  • CloudFront 導入したが、まだ 503 にはなる
    • そもそもインスタンスを良いやつに変えないとダメなのかもしれない
    • タスク数を増やしてクラスタリングするなどいろいろ試してみる
      • クラスタリングするためには Cookie セッションではなく Redis や Memcached などをセッションストレージに使う必要が出てくる…
  • Deploy だるい問題
    • cap deploy しなくなり、イメージをビルドして push する感じになる
      • Alpine Linux でもそこそこイメージサイズはでかくなるので貧弱な回線では docker push にめっちゃ時間かかる
    • ECS 側でもサービスを更新するなどの作業が発生
      • Blue / Green Deployment できるがポチポチ作業が発生するのがだるい
      • Rails を運用する場合は migration なども発生するのでうまいことやる必要あり
    • git commit しなくても作りかけのコードの状態で docker-compose build してしまいがちになり、リポジトリのコードと動いてるコンテナイメージの間に差分が発生してしまいそう
      • ちゃんと CircleCI などを導入してイメージのビルドとプッシュは CI サービスでやる、というような運用にしないと破綻しそう
  • 手順書問題
    • こんな風にブログを書いて雑な手順書を作成するようではいけない。 Terraform 化しないと破滅する。
  • Lokka は CMS for Cloud です
    • git push heroku master するだけで使えることが売りの Lokka を AWS のガチな構成で運用するという皮肉
  • お金高い
    • 毎月 3000 円くらいかかる感じになりそう。 VPS は年払いで 16000 円くらいなのでだいぶ高い。払えなくなったら VPS に戻しそう。

謝辞

r7kamura さんの amakan Docker 化の一連の記事と Classmethod 社の ECS 関連の記事には大変お世話になりました。

角島

GW 前半の 4/29, 4/30 で山口県に行った。子どもが SL やまぐち号に乗りたがっていたのと、自分が下関の唐戸市場と角島に行ってみたかったから。旅行計画はこんな感じ。

予定表

家庭内 Kibela にエントリーを書いて嫁さんと共有しながら計画を練った。ただ嫁さんはめんどくさがって前日まで見てなかった。自分は電話が嫌いなので SL やまぐち号のチケット予約の電話を嫁さんにしてもらった。

予定では朝 7 時に家を出ることになっていたけどうだうだしてしまって結局は 9 時半頃家を出た。昼前に関門海峡に差し掛かり、関門橋を見渡すことができる PA で写真撮影して本線に戻り下関 IC で降りたところで嫁さんがシートベルトをしておらず後席シートベルト不装着で長州の官憲につかまえられた。関門橋のところの PA まではシートベルト着けていたとのことなのであれはトラップだと思う。ゴールド免許復帰の夢は潰えた。

DSC_2722 DSC_2720

下関市役所の駐車場に 11 時半頃到着し、歩いて唐戸市場へと向かった。下関の印象は門司と似ていた。昭和の雰囲気を色濃く残す寂れた商店街の感じは、あぁ、門司と下関は双子の都市なんだなぁという思いを抱かせた。

DSC_2726 DSC_2730

唐戸市場は昼時ですさまじい混み具合だった。ようやく食べ物を調達しても座って食べられる場所を探すのが大変。人混みの中で押し合いへし合い状態で買った海鮮丼は大したことなくて、唐戸市場はアクティビティとして来てみるのはよいけどわざわざ食事を目当てに来るほどではないなと思った。

DSC_2739 DSC_2741

テラスから関門海峡を通るタンカーや船を眺められるのはよかった。タンカー、普段は港に停泊してるやつか沖合を航行してるやつしか見ないと思うけど、間近で見るタンカーは結構速いスピードで動いてるという知見が得られた。

DSC_2743 IMG_2957

唐戸市場を出たあとは商店街にある自家焙煎のコーヒー屋でサイフォンでいれたコーヒーを飲んだ。

DSC_2769 IMG_2956

その後角島を目指して日本海側を移動した。海沿いの景色は福岡の糸島と同じような風景だったけど、とてつもなく長いビーチがあって気持ちよかった。角島には 4 時頃着いた。運良く空いたところに停められたけどすごく人が多くて車を停める場所を見つけるのが大変だと思った。この日は曇り気味の天気でガスも多く、角島大橋の景色ははっきりは見えなかった。橋を渡って角島の方まで行ってみたけど観光名所となっている灯台のあたり(映画の舞台になったらしい)は駐車場代が福岡の天神よりも高くバカらしくて車を停めはせずぐるっと回って戻ってきた。角島大橋近くの店でコーヒーを飲んで休憩したあと、併設の萩焼の店で嫁さんがいくつか器を買った。

角島 DSC_2790 DSC_2785 IMG_2960

6 時頃から今度は宿泊先の山口湯田温泉に向かった。途中、秋吉台を見ていきたいと思っていたけど道に迷った&日が暮れてしまい、結局秋吉台を見ることはできなかった。 8 時頃ホテルに到着し、繁華街に出かけて食事をした。結構迷ってふらっと入った店は悪くはなかったけど会計がすこぶる高く卒倒した。宿に戻ると 11 時半を過ぎており、併設の温泉の利用を断られた。予約していた部屋がツインではなくダブルの部屋だったことを嫁さんにとがめられ床で寝た。

翌朝、朝食が無料で付いていたので食べに行ったところ、無料なのに地元のおばちゃんたちが作る煮物などがどれもおいしくびっくりした。チェーンのビジネスホテルで家庭の朝食みたいなやつが食べられて良かった。

食事を終えてチェックアウトし、コインパーキングを探して車を停め、メインの目的の SL やまぐち号に搭乗すべく湯田温泉駅へとタクシーで移動した。湯田温泉駅はつつじが満開だった。

DSC_2804

SL やまぐち号は非常に混雑していた。また車両は古くてすすけていた。 SL は子ども時代に家の近所を走っていた ASO ボーイの試乗運転にしか乗ったことがなく、長距離を乗るのは初めてだった。 SL 特有の動き始めたときに車輪が滑ってずるっとなる感じが印象的だった。

DSC_2811 DSC_2838 DSC_2848

やまぐち号の目的地は島根県の津和野で、車窓からの風景は山また山、時々田園地帯という感じだった。石州瓦の赤い屋根瓦の家々が印象に残った。日本海側で降雪量が多いことも関係あるのか、切り妻屋根の家が多いなと思った。

DSC_2837 DSC_2935

津和野は昔ながらの雰囲気を残す街だった。小京都と言われているようだが、中山道の宿場町の馬籠宿に似ていると思った。小さな街なことと帰りの SL までの時間が限られているのでレンタカーを借りるほどでもなかったので駅前でレンタサイクルをかりて街を回った。昼飯を食べなければならなかったが着いた時刻が 14 時前でどこの飲食店も軒並みラストオーダーを過ぎており、昼食を食べる店を探すのに難儀した。森鴎外の出身地とのことなので鴎外の生家に行ってみたかったが、三時間弱の滞在時間では時間が足りず、菓子屋で名物の源氏巻を食べ、閉店しようとしていたところを何とか滑り込んで割子そばとうずめ飯を食べ、酒蔵を二軒回って日本酒を買った(2本買ったうち1本は列車から降りるときに嫁さんが落として割った)ところでタイムオーバーとなった。

Untitled Untitled DSC_2914 割子そば うずめ飯 DSC_2909

山口の湯田温泉駅に戻るとどっと疲れが出て、これから福岡まで運転して帰るのかと思うと暗澹たる気持ちになったので帰る前に足湯に浸かって帰った。街中に綺麗な足湯スポットがあって 200 円で入れて、足湯に浸かりながらコーヒーなどを飲むこともできる。

IMG_2979 DSC_2938

いろいろ盛りすぎて一泊二日で行くには時間が足りなかった。特に津和野にはもう一度行ってみたいと思った。

SL Yamaguchi Tour

LDR が再び終了するとのこと。

【重要】Live Dwango Reader/LDR Pocketサービス終了のお知らせ : LDR / LDRポケット 開発日誌

RSS 、確かに昔に比べたら使わなくなった。ソーシャルメディアが情報の流入口になってる。

そもそも自分自身も周りの人もブログの更新頻度が落ちてる。いまも精力的にブログ書いてる人はとても珍しいと思う。長々とブログに書かなくても 140 字のツイッターに 2, 3 投稿すれば満足できるのかもしれない。むかしはメインのコンテンツがブログだったのに対していまはソーシャルメディアになってるので、コンテンツの発信と受信がそのソーシャルメディア内で完結してしまう。ツイッターやフェースブックを RSS リーダー経由で読む人はまずいない。というかフィードが提供されていない。

加えて、情報収集も分野ごとにハブとなる人がいて、その人経由で仕入れるのが効率的になった。前は話題になったブログがあったらみんなでそのブログのフィードを購読してたような感覚あるけど( LDR ではフィードの購読者数が表示されてた)、いまは目利き的な人がいてその人のソーシャルネットワーク(はてブ、ツイッター、ヘェースブック)経由で情報を仕入れる感じ。 Twitter Card とかオープングラフプロトコルとか出て来たのも大きい1。 RSS リーダーではなくソーシャルメディアが情報が集まる場になってる。

とはいえ一部の目利きの人たちは RSS リーダーとフィードの仕組みなくして効率的に情報収集することはできないので今後も利用者がゼロになることはないと思う。そういう情報収集マニアな目利きの人たちに対して課金しないと RSS リーダーは収益化できないだろう。だとしたら目利きから情報収集している我々は目利きの人たちに対して投げ銭的なことができれば良いんだけど。


  1. ヘッダー画像とサマリーが展開されることでわざわざリンク先を見に行かずにある程度のコンテンツを推測できる。ますますソーシャルメディアから出て行かなくなる 

Kaizen Platform

Qiita:Team エントリのレベルが高い

CEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテントリのようだった。ブックマークできるもんならしたいという感じ。お金を儲ける仕組みってこうやって作り出されていくんだなぁと思いながら眺めてた。技術顧問の伊藤直也さんが残していった名エントリも結構あった。 Kaizen エンジニア行動指針とか。

SRE (インフラチーム)のレベルが高い

インフラが盤石だった。 SRE は二人しかいなかったがとても仕事が速く、困ったことがあって Slack のインフラ相談チャンネルで相談したらたいてい 3 分くらいで問題が解決してた。

yosudo さんは問題解決能力が高すぎていまは SRE ながら VP of GA (総務部門のドン)やってるし、 glidenote さんは SRE 業務をこなしつつも R&D して新しめの技術をどうやってビジネスにフィットさせていくかを追求したりしてる。

SaaS や IaaS をフル投入したモダンな開発体制

SaaS や IaaS を使うのはかっこいいからとかエンジニアが楽しいからではなく、その方が最終的にかかるお金が少なくて済むし、事業の圧倒的な成長に対応(スケール)できるから。詳しくは yosudo さんのスライドをご覧ください。

Mackerel meetup #7 スタートアップとSaaS // Speaker Deck

コードのクオリティが高い

Kaizen Platform も 5 年目に入っているのでプロダクトのコードがレガシー化しているところがあるのは否めないけど、レガシーと言っても本当に悲惨なレガシーコードとは比較するべくもなかった。ユニットテストはちゃんと書いてあるし1、インフラは AWS だし平均的な水準が高い。メインのシステムは Ruby と Rails で構築されていたけど、一部の機能を Go lang でマイクロサービス化したり、ログ集約サーバーは Node.js で構築されていたり、場所によっては C で書いて高速化してあるところもあり、特定の技術に依存するのではなく目的、状況に応じて柔軟に使う技術を選定していくところがこれまでにない感じだった。エンジニアが Ruby しかわからないから Ruby をずっと使いますというような消極的な技術選定ではなかった。

プロダクトマネージャーがいる

プロダクトマネージャー( PM )がいる会社で初めて働いた。データ取りとかは PM 自身ががんがん SQL 書いて取るし Domo や Redash などの BI ツールを PM 自身が使いこなしているので「○●のデータを本日 11 時までに大至急抽出してください!!!、!(現在 10 時)」みたいなことを割り込みで依頼されるということはなかった。プロダクトマネージャーは技術、ビジネス、市場、顧客のすべてに精通していてリーダーシップがあり、ミニ CEO のような人たちだと思った。

Kaizen Platform における BigQuery 活用事例 #bq_sushi tokyo #2

QA チームがいる

PM のほかに QA チームの人がいて、 QA 観点で動作検証したり仕様に指摘をしてくれてめっちゃありがたかった。しかも QA チームの皆さんが優秀。エンジニアが自分で作って自分で動作検証するのではどうしても先入観が入ってしまって検証が不十分になると思う。むかし働いていたブラック企業では午後 10 時まで開発したあと午前 4 時まで自分で作ったやつを動作検証してエクセルエビデンススクショ職人業もこなしてたけどあれは本当に不毛だった。エンジニアが作ることに集中できる環境はすばらしい。

社長が近い

社長室などはなく、 CEO も普通にフリーアドレス席に座って仕事しているので CEO がすごく身近な存在で話しやすかった。会社にいる人たちも CEO に対して従順というよりは、その道のプロの人たちが集まっていて、若い CEO を助けるために一肌脱いでる感じがあった。雇われているというより雇われてやってる感じ。 CEO のことを親しみを込めて「スドケン」と呼び捨てにするし、むやみやたらに上下関係を作って序列通りにひれ伏すのはださいという雰囲気があった。

セールスが強い

こんなに強力なセールスがいる会社で働いたのは初めてだった。砂漠でこたつを売ってくる男の異名を持つ人がいたり。元リクルートの人たちを中心とした精強なセールスチームがいて、大企業からどんどん契約をとってきてた。自分はこれまで中小零細企業とか上場企業でも個人向けサービスをやってる会社でしか働いたことなかったので、こんなに大人っぽいカッチョイイセールスの人たちがいる会社で働いたのは初めてだった。

社員の趣味がエクストリーム

雪山スキーとかサーキット走行とかフルマラソンとか雨が降らない限り毎週末キャンプしてるとか鎌倉に住んで毎朝サーフィンしてから仕事とか、社員の趣味がエクストリームだった。アウトドアでなくても仏像なぞり描きと御朱印集め、囲碁、観葉植物、美食、マイル乞食、不動産運用、マンション管理組合理事など、趣味が中途半端な人がいなかった。

性善説とアンチマイクロマネジメント

社員は悪いことをしないという前提で会社が動いているように思った。承認システムみたいのがあるにはあったけど、新しい SaaS を使いたいときには CTO に相談すればよかった。マイクロマネジメントを嫌う風潮もあり、休みをいつ取るかなどは自由だった。細かいマネジメントをする方が無駄にコストがかかるし、そもそもマイクロマネジメントが嫌いで大企業を辞めてきた人たちで構成される組織だった。

求められる水準が高い

マイクロマネジメントされない一方で、求められる水準は非常に高い。四半期ごとの目標設定と評価面談では、目標として設定したことをこなすだけではマイナス評価となる。目標を達成するのは当然で、求められていること以上の成果を出すことができたかが評価軸だった。

採用フローで期待されていることを説明される

自分が受けた頃は採用にとても時間をかけていて、これこれこういうことを期待しています、ということを丁寧に説明された。 2 回くらい現場の人と面接して最後に重役と面接して「お、キミいいネ、採用!」という感じではなかった。むしろ最初に CTO と話して次に CEO に口説かれ、あとから将来同僚となるエンジニアやプロダクトマネージャーと話すという感じだった。採用フローでポジションや求められる役割について説明があり、入ってから「俺はマネージャーだったのに平で雇いやがって」というような期待のミスマッチが起こりにくかった2

情報が閉じられていない

会社の売り上げ、状況は公開されていた。毎週金曜朝から行われる All Hands で数字の共有があり、目標に届いていないなどのアナウンスがあった。また隔月で行われる全社合宿(合宿だけど日帰り)でも会社と事業の現状について説明が行われ、社員全員で今後の方向性についてディスカッションを行う文化があった。

仕事をしていく上で、会社の経営状況について知らされていることは重要だと思う。かつて働いていたブラック企業は顧客が自分たちにいくらお金を払ってくれているかを教えなかった(教えたら自分たちが搾取していることが従業員にばれるため)。お客さんがいくら払ってくれているかを従業員が知らないと払ってくれている金額に応じた仕事をすることは難しいと思う。


厳しいなと思うところもあるけど、意欲がある人には機会が与えられる職場だと思う。総じてパワーのある会社だった。

なんでこんなことを書くのかというと、実は Kaizen Platform を先月で退職していた。すべて自分の能力不足が原因で、決してペパボを辞めたときのような積極的な退職ではなかった。前回の退職は前進だったけれども今回の退職はまさに撤退という言葉がふさわしい。なので退職日に合わせて記事を書くことができなかった。

Kaizen では入社早々に障害を起こしてしまったり、アサインされたプロジェクトを頓挫させてしまったりで在籍期間中に大したバリューを出すことができなかった。

ただ Kaizen Platform で働いた 1 年 11 ヶ月は自分にとって非常に貴重な時間だったと思う。リモートワークのおかげでこれまでにない生活をすることができた。家族が忙しいときに家事をしたり子どもの幼稚園の送り迎えをしたり。普通のお父さんではできないようなことができた。

なにより通勤がないのが素晴らしかった。通勤は実際に移動してる時間は 30 分でも家を出る前の身支度が必要だったり、なんだかんだで朝晩に 1 時間ずつ時間を取られてしまう。家族がいる人の場合はこれが自分だけでなく家族の負担にもなる。通勤に取られる 2 時間があれば洗濯や炊事ができる。この 2 時間が生活にゆとりをもたらしてくれていたと思う。

ダイエットにも成功した。糖質制限をして減量したけど、普通に朝から出社して働いていたら食事の準備に時間をかけられず、摂取しやすい炭水化物中心の食事を続けていまもデブのままだったのではないかと思う。

半日休む必要はないんだけど、昼間数時間だけ自分のことに時間を割きたい、用事が終わったらまた仕事しよう、というようなことができたのがとても良かった。病院通いがとても捗った。

こういうの、ワークライフバランスと言ってしまえばありきたりな感じがするけど、ちゃんとワークライフバランスを保つのは尊いことだと思う。

反面、リモートワークにはつらい面もあった。何をやればいいかが明確ではない状態でのリモートワークはとても難しい。チームメンバーの意識が統一されていない状況にもフィットしない。何をやるべきかを自分で明確にできる人遠隔でもリーダーシップを発揮できる人でないとリモートワークはこなせないと思った。自分にはその両方が欠如していた。誰からも管理されない状況で自分でやるべきことを明確にし仕事をしていくのは自分で自分を律することのできる人でないと難しい。サボろうとしているわけではないのに時間だけが経過していくのは非常にもどかしかった。小さい頃から親や学校の先生に「次はこれをやりなさい」、「あれをやってはダメ、これをやってはダメ」と指示監督されてきた人間が突如として管理されない状態で働くのはきつい。管理されて働いているときは管理者に対して不満を持ちつつも、管理されないと全く何もできない自分の不甲斐なさが露わになるばかりだった。

全体として、自分に足りない部分がわかった 1 年 11 ヶ月だった。上に挙げた、リモートワークをうまくやっていくための資質(何をやるべきかを自分で明確にできる、リーダーシップがある)は、オフィスでより良い仕事をしていく上でも必要なものだと思う。また自分のやりたいことに貪欲であるべきことを学んだ。エンジニアだけでなく、セールスやカスタマーサクセスなど違う職種の人と話をしていて感じたことだった。やりたいことがあるのに黙ってもじもじしててもやりたいことは回ってこない。やりたければ相応の準備をした上でやりたいと手をあげないとやらせてもらえない。空気を読まず、遠慮をしないことが良い仕事をしていくために必要だと感じた。

Kaizen でのリモートワーク失敗経験をどう今後の人生に生かすか。以下のツイートを繰り返し眺めながら悔い改めていきたいと思う。


  1. むしろテストコード多すぎて CI が遅くなるのが問題だったけど CircleCI に重課金してテストを並列実行して凌いでた。 

  2. ただしたまに逆のパターンが起こってた