More than 5 years have passed since last update.

freee EngineersAdvent Calendar 2016

超サイヤ人と界王拳とスタートアップと私。

Last updated at 2016-12-19Posted at 2016-12-14

まえがき

~~おはようございます。~~
freee ではそばを打つスキマ時間でプログラミングをやっている @inage782 こと smb です。
インフラゾンビなので英語での肩書は Site Reliability Engineer となっています。

この記事は freee Engineers Advent Calendar の14日目の記事になります。ゆるふわです。
モダンでテックでヒャッハーな記事が読みたい方はfreee の誇るインフラゾンビさんの記事を読みましょう。執筆時点で今年度の個人的ベスト・オブアドベントカレンダーです。

趣旨

今回は職業プログラマ経験のなかった自分が、いかにして超サイヤ人だらけの freee というテックなスタートアップでキャッチアップをしたかってことを回り道しながらつらつら書いていきたいと思います。

前置き

ドラゴンボール（原作準拠）に例える上での定義とか（飛ばしてOK）

戦闘力

エンジニア力
問題解決力

freee 社内だと腕力ともいいます。

用例

「腕力で解決」

サイヤ人

Wild And Tough.
- 修羅場が大好き
- 戦闘力を高めることに貪欲
- モチベーションが落ちない

用例

「いやあの人サイヤ人だから」

界王拳と超化

戦闘力を上げる手段。

界王拳とか超化とか書かれてもさっぱりわからないと思うので、なんぞやというのを簡単な表にしておきます。

	界王拳	超化
必要なもの	カフェイン/残業	-
戦闘力の上昇率	2~20倍	50~100倍
特徴	人間性が死ぬし体を壊す	眠くなるからご飯食べない
	祝祭休日に有給は体調不良で消化	祝祭休日問わずレビューとPRが飛んでくる上に個人プロジェクト作ってる

※ freee エンジニアに聞いた「超サイヤ人なエンジニアの特徴」より 2016/11調査

問題解決のための集中方法が根本から違うか、稼働時間で補おうとしているかの違いですね。
自分には後者しか使えません。

こういう話をします

無理をしすぎないアウトプットの高速化
サイヤ人に学ぶこと/サイヤ人じゃ無くても出来ること
freee の求人/採用

趣旨の通り難しいことは書かない方針です。もちろん記事の内容の一部は自分への戒めも入ってます。

本題

無理をしすぎないアウトプットの高速化

界王拳を使用して一時的にアウトプットを向上させても、それは長く続きません。
使えば使うほど疲弊するし、無理をすると本当に心と身体を壊してしまいます。
それらをいちど壊してしまうと復帰には数カ月から何年もの長い期間がかかります。
特にいちど落ちたモチベーションはなかなか戻りません。

そして明日をも知れぬスタートアップ及び殆どの会社ではその期間あなたを支え続けることはまず出来ません。

事業よりも心身の健康のほうが、個人にとっては重要です。

また、中長期的にみると健康であるほうが成長の機会も多く、安定して結果を出すことが出来ます。
界王拳はなるべく使わないように生きていきましょう。

これ以降は界王拳を使わずに安定して結果を出すために取り組むべきことを書いていきます。

課題を定める

目の前の問題を解決するときに課題を設定することはとても重要です。
問題を解決するには、その問題がなぜ発生するのかを正しく見極めなければなりません。
freeeを支えるマジ価値開発の極意でも書かれているように、問題を観察することで課題を設定することが出来ます。

そして課題は短期的に達成可能なものであることも重要です。

自分のようなサイヤ人ではないエンジニアは、一つの課題に対し長期に渡って高いモチベーションを維持し続けることが出来ません。
つらいからです。
長大な課題を設定してもそれをやりきることは困難を極めます。

問題を解決するには

課題を定める
課題の解き方を考える
答え合わせをする

といったステップが必要ですが、そもそも自分もこの文章を書いていてちゃんとキャッチアップの記事になるのか不安なので、問題を観察して課題を設定してみたいと思います。

問題を観察する

キャッチアップの何が辛いかというと、そのサービスが属するドメイン知識やサービスの設計思想を学ぶことです。
サービスの規模が小さい頃ならまだしも、freee のようなプロダクトに新機能を追加するとなったら大変です。PLBS勘定科目に複式簿記で仕訳だなんだとの会計知識に加えて、それをコードに落とし込んだ複数のアーキテクチャが共存する巨大なプロダクトが存在します。

ここをいじれば他にどんな影響が起きるのかわからない。そんなことは往々にしてあります。

現実にある問題の複雑さは、たった一人の地球人の手には負えません。
大きな課題を独力で解決しようとするのは、達成感は大きいけれど効率が悪く辛いものです。
そして今回はこの記事を通して、なるべく無理をしないエンジニアとしてのキャッチアップについて伝えたいと考えています。記事の内容も無理をしません。
サービスが属するドメイン知識やサービスの設計思想を学ぶことについて普遍的な記事を書くのが難しそうなので**「ここをいじれば他にどんな影響が起きるのかわからない」**といったプログラミングの部分について書いていきたいと思います。

課題の解き方を考える

かめはめ波より元気玉

いまは情報共有の進んだ世の中、問題を解決するための情報収集についてはnyanchuの記事などが参考になりますが、**「何事も先達はあらまほしきことなり」**ということで自分も急遽この記事の方向性は正しいのか、「オラに元気を分けてくれ！」ってことでプログラミングをするときの心構えを帰宅前にオフィスに残っていたエンジニア全員に聞いてみました。

freee エンジニアに聞いたプログラミングをするときの心構え
インタープリタかコンパイラの気持ちになって書く。言語仕様の気持ちよりそっちが楽。
自分が読みやすいコード。
動かす。
オブジェクト指向を意識する。
必要なことだけをプログラミングする。ミニマムに実装する。
楽しむこと。
たくさん試すこと。
なんでその言語を作りたかったかを調べ読む。言語設計者の立場から考える。言語の思想や作製の動機を知り、使い方の方向性を知る。
穏やかな心を持ち取り組む。
サンドイッチを食べて元気になること。
みんなが読みやすいように。
死ぬ気でやる。
なるべく書かない。
未来への自分へ手紙を書くつもり。
どんなことでも自分が楽しいと思えるところを見つける。同じような試行の中でもチャレンジして常に楽しむ。
所属組織のコンテキストに合わせた可読性。　コードも生まれる親を選べない。
レビュアーの選定。ドメイン知識が共有できていて、実装する機能に合わせたレビュアーを選ぶ。一晩寝かせる。自分の中をリセットして他人として読む。
クソみたいなコードは書かない。まず動くものを作る。パフォーマンスを気にする。コードの役割を気にかける。抽象化と役割付。
理想のインターフェースから考えて、ビジネスロジックを実装する。最近意識しているのはメソッドを細かくする。
問題を細かくくだいてコードに落とす。
なんかあったら反射的に書くだけ。クソコードを見かけたら（コードに）死ねという。
そもそも何のために存在するか意識する。誰の何を良くするのか。その機能を作ることに寄って良くなるユーザの問題を考える。とにかくちっちゃく作る。関心の分離とか。

※ freee エンジニアに聞いた「プログラミングをするときの心構え」より 2016/12/12 調査

解決するレイヤーを特定しない雑な質問にも関わらず真摯に回答してくれてみんなありがとう。

それぞれ個性ある回答を頂きましたが大体以下のように分類できそうです。

意図が正しく共有されるように読みやすく書く
対象となる問題を細分化して取り組む
試行回数を増やす
モチベーションを保つ
なるべく書かない

この分類を課題として設定し、自分なりの解法を書いていけば良い感じにまとまるんじゃないでしょうか。

それはさておき楽をしたい。

目の前の問題に取り掛かる前に、導入コストの低い下駄は履けるだけ履いて生産性を上げましょう。
舞空術が駄目なら筋斗雲を使えばよいし、自分で瞬間移動が出来なければ誰かに運んで貰えば良いんです。
自分に無いものは借りて来ればいいし、すでにあるものは使いまわしましょう

いくつかは重複していますが、課題に対してこうした方が楽だよ。というのを箇条書きしておきます。
Github-flow を使ってて手厚いレビューにステージング環境があり統合テスト環境がありQAもUXもいてChatOpsで自動テストも全部入りという環境が空気のように存在する freee ですが、世の中はそんなに甘くないので、個人でできそうな範囲で環境を整えましょう。

意図が正しく共有されるように読みやすく書く

まずは自分が読みやすいようにディスプレイを増やすか解像度を上げよう。
- 環境によっては一番難易度が高いかも。
高機能なエディタを使おう。
- 使用前の準備が少ないエディタがおすすめです。Atom とか。
言語に合わせた lint を入れよう。
- 自動的に整形される方が書く方も読む方も気が楽です。
コード外でやりたいことを周囲に共有しよう。
- freee では DesignDoc という小さな仕様書を社内全体で共有し、自由に意見を求めたりします。

対象となる問題を細分化して取り組む

タスク管理サービスを使おう。
- 文字に落とし込むことで整理もできます。重要。
- trello とかお手軽。
- 有料なら JIRA で個人プロジェクトとして管理するのも良いです。
  - とはいえこんな記事もあるけど。

試行回数を増やす

出来る限りバージョン管理しよう
- 試行するために失敗できる環境を作ろう。
- せめて自分だけでも git 使おう。
自分なりの回答を用意する
- 自分なりのテストを書こうってことです。
  - 期待する回答を書くだけで、その回答がそもそもあっているかの確認もできます。
- 最低限チェックリストを用意しよう。例えばChibineko。
よくやる作業は自動化する
- 意識の低い自動化おすすめ。
- 可能なら自分だけでもCIを回そう。

モチベーションを保つ

タスク管理サービスを使おう。区切り大事。
- 手戻りが最小限になるようにしよう。
  - 手戻りほど心を萎えさせることはそうそう無い。
界王拳を使わない

なるべく書かない

すでにあるものを流用できないか考えよう
- ライブラリを使う
- 外部サービスを使用する
- lint を使う
  - ruby だと rubocop とかね。
よくやる作業は自動化する
- 意識的にマインドセットとして行っているならともかく同じことはやめよう。

といったことをやればいくらか楽になるのではと思います。
ちなみに環境整備で個人的に最もおすすめなのは「ピープルウェア」と「人月の神話」をマネージャに読んでもらうことです。

答え合わせをする

と、ここまで書いておいてなんですが、こういった安定的かつ高速にアウトプットする方法というのはみんな考えているわけで、ソフトウェア開発方法論とかシステム開発方法論(SDM)と呼ばれています。すでにあるものは使いまわしましょう。

意図が正しく共有されるように読みやすく書く
対象となる問題を細分化して取り組む
試行回数を増やす
モチベーションを保つ
なるべく書かない

そうですね、上記の条件を満たすならもちろんオブジェクト指向とアジャイルソフトウェア開発手法ですね。

サイヤ人に学ぶこと/サイヤ人じゃ無くても出来ること

アンケート結果から freee のエンジニアはそれぞれのSDMを自分の中に落とし込んで消化し、開発に活かしていることがわかりました。
インタープリタやコンパイラの気持ちになったり反射的にコードを書くといったことはなかなか真似できませんが、自分なりにどうすれば5つの課題を満たすことが出来るのかを意識することで、効率的にキャッチアップ出来るのではないでしょうか。自分はしました。