by ·0件のコメント

freeeでの闘争と謝辞

2018年7月末を最終出社日としてfreeeを卒業します。

2015年1月に入社して以来、社内外関係なくいろんな人、コミュニティ、組織にお世話になりました。

freeeには職業エンジニアとしての経験のない僕を受け入れ、特に最初の1年くらいは自分でも引くくらい成長速度が遅かったにも関わらず見放さずに育ててもらいました。

やる気以外何もないところから、よい会社に移ってよい給料がもらえる程度の1人のエンジニアを育てる環境を提供できてそれだけで死ねる

長生きして欲しいですが、こんなこと言って送り出してくれる会社他に無いと思います。言われた後トイレで10分くらい泣いてたのは内緒です。

エンジニアとして育ててもらったのはもちろんなのですが、それ以上に学びが大きかったことがあります。それは愚直に課題に向き合って価値を届けるということとそれに必要なマインド（freeeでは価値基準という）です。

僕はコードを書いたり勉強したりするだけで楽しいし、力がついていってるような錯覚に陥ってしまいます。ただ、その結果として何が解決される？本当にそれは解決されるべき大事なこと？は常に考えないと、何をするにしてもよい流れにならなかったり、求める結果を得るのに膨大な時間がかかったりでうまくいかなかったです。

手段自体楽しいと思える方が人生楽しいとは思いますが、だからこそ一層意味のあるものにしたいという願いのような意味合いでもあります。

エンジニアとしても（働く、あるいは世の中に価値を届ける）人としても大事なことを学ばせてもらったfreeeに出会えて本当によかったし、今でもfreeeが大好きです。

そんな状態でもfreeeを去るのは、自分が届けたい価値に向き合った結果です。

これまでfreeeで対峙してきたデータや自分のお金に対する考え方（捕らわれ方）、これまでとこれからのお金が表現するすべきもの、価値の表し方を考えていたときに9月から働くメルペイのビジョンに出会いました。

メルペイが実現しようとしていることはまさに自分が解決に携わりたい思う分野での大きな社会的課題の解決です。

これまで扱ってきた技術スタックとはまた異なりますが、freeeで身につけた課題に向き合う姿勢を忘れずに価値を届けます。

約3年半、本当にありがとうございました。

これは例のリストです。

ふりかえり

新しい開発組織や自分がそんなに触れたことが無い技術になるべく早くキャッチアップできるように、freeeで携わったプロジェクトを出せる範囲でふりかえります。

Web

青色申告承認申請書メール送信サービス

入社3ヶ月目くらいのとき初めて自分メインでリリースしたサービス。今はもう別のサービスが包含してるのでありません。

リリース期限がどうしてもずらせないときは他の変数で調整してなんとかやり切るしかないというのを学びました。

電子証明書連携アプリ（Windows）

対応口座拡大と品質向上

入社7ヶ月くらいのときに電子証明書ログイン対応1行のときにWindowsデスクトップアプリを引き継ぎました。

まだRubyも覚束ない中、C# + Visual Studioに初めて触り対応口座数を増やしていきました。

  • 拡張できる設計とリファクタリング（当時テストは…）
  • 防御的プログラミング（確実なこととそうでないことの切り分けと制御）
  • ログ
  • エラー通知
  • サポートチーム、セールスチームと協力しながら問題解決
  • 優先順位、割り切り
  • 目の前の技術を一歩引いてみる（技術的マイノリティプロジェクトで幸せに過ごすための5つの方法）

を身につけました。

当初他のプロジェクトやりながら半稼働、という状態が1年弱あったんですが、社内的に知見があるわけでもなかった技術を身に付けるには思い切って全投入するのが真っ当なやり方だったみたいです。

この会社でC#…みたいな迷いも大きかったですが、何人の方にもアドバイスを頂いた通りまずは自分の目の前の技術をしっかり身につければ応用も効くから頑張れという言葉を信じ頑張ってみました。

あと、技術単体で解決できないときには他のチームの協力を得てできることもあるというのは大きな学びでした。

価値は技術だけでは届きません。

このプロジェクトだったり、得た知見を他の分野にも活かすことで大きな成果に繋がりました。

アプリ + Web UX改善

デスクトップアプリの品質がよくなってきたところで、本来使うと作業が効率化できるはずのユーザーさんに存在や利便性に気づいてもらえなければ意味がありません。

  • 問い合わせ内容分析
  • KPI設定
  • ユーザーさんへのインタビュー
  • サポートチームへのDemoやFAQ共有
  • Webの導線やアプリの使い勝手の改善、リニューアル
  • 保守しやすいコード（しにくいコード）

などを通して、Web上で登録する導線から問い合わせしてくださったユーザーさんに価値が届く（トラブルシューティングを含む）までの全フロー（の中で効果がありそうな順）に対して施策を打ちました。

サポートチームとの知見共有は（もともとの仕様共有が甘ければ）目先のやり取りが減りプロダクトの改善に割ける時間が増えます。駄菓子菓子、その後は問い合わせが減ったとしても

  • サポートチームのメンバーがユーザーさんからの問い合わせに精度高く答えてくれて単にエンジニアまで届く声が減ったのか
  • 「改善」の結果ユーザーさんが離脱してしまっていないか

など目に見える現象だけで判断せず、何か数字がよくなる代わりに他にしわ寄せが及んでいないか、本当に改善したいものは改善できているか、改善そのものの数値化が難しくてもなんとか可視化できないか、その数値が妥当かどうかベンチマーク取れないかなどいくつか考える必要がありました。

プロダクトマネジメントの文脈での「解決すべき課題に向き合う」を実感する日々でした。

この本にとてもとても影響を受けました。

Inspired: 顧客の心を捉える製品の創り方

プロダクトにどういう立場で関わるにしても忘れてはいけない視点として肝に命じています。

あと、改善の過程でフロントに保守しづらいコードを結構足した自覚はあるものの、じゃあどういう設計だったら保守しやすいんだみたいな理想形が全く見えませんでした。

そこからよい設計とは？を考える、学ぶ、意識して書く時間が増えました。

パフォーマンス改善

Windowsアプリといえども、サーバーサイドは他サービスと同じくRailsのサーバーです。

C#を書きつつ、サーバーサイドで必要な修正も行なっていました。

利用してくださるユーザーさんが増えるとAPIサーバーに問題が出て段階的に対応していきました。

非同期化の過程で色々と学びがありました。

  • 時間とコストを考えて段階的に理想的なアーキテクチャに近づけていくやり方もある
  • 問題に対する打ち手を複数考える（※結論ありきの比較にしてはいけないが、自分の推しは持つこと）
  • AWS Lambdaをきっかけにインフラを含めたアーキテクチャ（特にサーバーレスアーキテクチャ）に興味を持った
  • PaaSへの抵抗（食わず嫌い？）が激減
  • OSSヘのコントリビューションのきっかけになった

自分が携わるプロジェクトに対して新しい技術をまるっと（？）導入したこともなかったので大きめの粒度で設計・導入することは考えることが多い分学ぶことはめちゃくちゃ多かったです。

電子申告アプリ（Mac）

すでにリリースしているWindowsアプリのMac版を作って明確な期日までにリリースするプロジェクトです。

Macアプリ開発の知見が社内に無い中、色々なことにチャレンジしました。

Windowsアプリ資産を活用するためにXamarin.Macを採用し、技術検証期間も取りつつチームリードとしてプロジェクトマネジメントするなどです。

  • アジャイル風プロジェクトマネジメント
  • コミュニティから力を借りること、貢献すること
  • CI/CD環境作り
  • ビルド、コンパイル入門

リリースにこぎつけただけでなく、結果的に日本マイクロソフトさんの事例掲載、大型イベント登壇、商業出版（共著）、Microsoft MVP受賞、福岡やシアトル出張などこれまでになかったくさんの機会に恵まれました。

アジャイルはこの本にだいぶ影響を受けました。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アカウントアグリゲーションエンジンのリプレース

2018年はC#を完全に離れ、この記事にある「アカウントアグリゲーションエンジンのリプレース開発」に携わっていました。

Goも利用するプロジェクトで、2週間くらいGoも書く期間はあったものの、だいたいRubyを書いて過ごしました。

かつあまり読み書きできなかったRailsのコードやRspecも昔よりは理解できるようになっていたり、改めて追い直してみると理解できたり最後の最後まで発見が多い毎日でした。

  • 昔読めなかったコードが今も読めないとは限らない
  • データ移行に必要な計画とシミュレーション
  • 防御的プログラミング（困るデータができる前に徹底的に落とす、ロールバック）
  • テストと設計のよい関係（？）
  • インフラ構築やWebアプリのデプロイフロー

この本に出会って設計良くなったかはわかりませんが、Rubyの文脈でpublicメソッドとしてクラスが持つべき責務は何か？を考えることでテストがとても書きやすくなり、テストに助けられたことも何度もありました。

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

あと、個人的にGoに興味をもち、コマンドラインを作ってみたりAPIを書いてみたりもかなり楽しかったです。

コマンドラインを作ってみることでコマンドラインを使うときもどう使って欲しいかちょっと理解が及ぶようになったり、シェルスクリプトが書きやすくなったりいろいろいいことがありました。

教訓

最後に、自分がエンジニアとして働く上で今のところ注意したいなぁと思うポイントをまとめます。

デバッグ環境できるまでが環境構築

  • とりあえず対象のサービスがローカルで実行できるようになった、で環境構築を終えたことにしない
  • コーディングとテストを含むフィードバックサイクルを効率的に回せる状態にすることに最初に一気に投資する
  • 同じ文脈でIDE、エディタの使い方は暗記する、できる（使いこなせる）ことを増やす時間はとり続ける

担当する（マイクロ）サービスは全部追え

  • エントリーポイントへのアクセスからそれが返るまで
  • コードを増やしてからデプロイが終わって稼働するまで（デプロイスクリプトや設定を含む）
  • 依存するライブラリ
  • サービスの基盤の性質
  • どう動くかわかるが意味がわからんならドメイン知識を聞くか調べる

本当に無駄なことはするな

  • 議論のための議論
  • 議論したことは残して立ち帰れる状態にする、前提を必ず書く
  • 登壇のための登壇
  • 2回くらいキー連打したり面倒に感じたことはショートカット覚えたりするために立ち止まる
  • 適度に無駄っぽいことはする、脇道にそれる

思い上がるな

  • 時間を空けて読んだコードが読みやすいと思ったとき、自分が成長してるかもしれないし、自分の知らないところで他の人がいい感じに直してくれたのかもしれない（git blameしろとかそういう話でない）
  • 読みやすいと思って書いたコードもきっとそのうち…
  • 自分が過ごしやすいなと感じたとき、その環境を作ってくれた人がいる
  • いいものは偶然発生するかもしれないけど大体は誰かが作り、そういうものであり続けるように維持してくれている