開発責任者として、事業会社にジョインして半年の振り返り
あれこれ
- 備忘録的な書き殴りな文書です。あしからず。
- オシャンティーな技術スタックで、大きな組織でやるのも面白いと思うけど、小さな会社でレガシーなシステムやメンバーと向き合うのも悪く無いよ！ってことを伝えたいのだけど、これが楽しめる人いるかな？私は楽しいよ！
ジョインした時点の状況
- 開発体制
- 開発エンジニア（入社半年）
- インフラエンジニア（５年前後、QA兼ねる）
- 主力サービスの協力会社 0.5人月程度
- 会社の屋台骨の 主力事業のSaaSサービスがあるが、業務委託の0.5人月程度の工数の範囲でできる改修を行っていた。
- 開発エンジニアは新規機能を開発していた。
課題感
- 一度作られたシステムは、表(UI/UX)も、裏(システム)もレガシーな状況であった。
- 限られたエンジニアのリソースは、営業視点で、あったら売りやすい機能開発に費やされており、負債返却や、使い心地の改善には充てられていなかった。
- プロダクトの保護者が不在で、開発部門は、ゼロから作り直して、お客さんを移行させたい。というお気持ちで既存システムに対しての愛情がなかった。
方向性
入った直後はリニューアルする風潮だったが、開発工数やお客様の影響を鑑みるとどう考えても、リニューアルは最適な判断でな無いと思い、腹を括って既存システムと向き合うという事を決め合意を頂いた。どちらにしても、手は足りないので、内製化に向けて、人材採用を考え始めた。
前職でも、前前職でも、エンジニア採用には、苦労したので、今回も採用に関しては、長期戦を覚悟し、まずは、一緒に働いてくれる業務委託の人材を探し、その上で、求人活動を始めようと考えたが、私の日頃の行いが良いのかリファラルで、エンジニア１名、デザイナー１名を私の入社後３ヶ月で確保できた。これはには非常に助かった。プロダクト(子供)に向き合ってくれる。パパとママが現れた。不整合がたくさんある使いにくいシステムだけど、利用している沢山のお客様がいらっしゃるので、改善が回せる事にとても喜びを覚えている。
やったこと（技術編）
開発環境 一発ドン
入社直後、開発環境構築手順はこれです！と渡された秘伝の手順をそっと閉じて、docker 環境で開発できる様にした。だれでも、何時でも再現性のある環境で開発できることは、非常に大事だと思っている。
レポジトリの統合
アプリケーションは、 ２要素で構成されていた。 coreという屋台骨とその上に乗っかるビジネスロジック群。core は git で管理されておらず、リリース直後から一度も変更していない(らしい)。今後に改善において、core に手を入れる必要性が必ず出てくるので、core を 統合した。今は、core にも手を入れて改善を図っている。
GitLab => Github
今後のメンバー増えることを考えると 気持ちは、github 一択だったので変更した。好き嫌い問題だと思うが、 github のほうが個人的にテンション上がる！ もちろんGithubActionsという強力なCIを使いたいという目的もある。このタイミングで、 PullRequestを作成しコードレビューを小さくやり始めた。
composer.json composer.lock が不在
PHPと軽量フレームワークで動いているシステムなのだが、なぜか、composer.json composer.lock が無いのである。 vendor ディレクトリはあるので、もちろん composer は使っているのだけど。。。これだとパッケージの更新や追加ができないので、vendor配下やloadファイルから、必要なpackageを洗い出し、 両ファイルをサルベージした。サルベージ後、laravelでよく使われる、dd(),dump() などのデバックツールをcomposerで導入したり、Carbonを導入した。
Exceptionの可視化
インフラ的な監視はあったかが、アプリケーションが正しく動いているかが全く把握できなかった。フレームワークの Exception ハンドラー で、 Slack にExceptionを 飛ばすようにした。とりあえず、潰せるExceptionは、潰して一応、見れる範囲にはなってきたかなと思っている。ただ、TryCatch乱用なので、見えてない闇は今後の悩みどころである。
テストコード
初期の開発時に書かれたと思われるUnitTestの残骸があったかが、テストが通らない状態だった。現状との乖離が結構ありそうだったので、 修正は、諦めてゼロから（都度）書くことに決めた。Laravelのような、 外形的なテスト $this->get(route('index')) が 書けるフレームワークではないので、 Guzzleを利用しコントローラに対しての挙動をテストできるように土壌を作った。また、メールの内容の送信テストもできるよう mailpitのAPIを利用して、テストできるようになった。
# web test
$res = $this->client->post("/hoge", ['hoge' => 'hoge']);
$this->assertOK($res->status);
$this->assertSee('登録しました。', $res->content);
# mail test
$email = $this->mail->getLatestEmail();
$this->assertEquals('メールタイトル', $email->Subject);
$this->assertEquals('送信先名', $email->To[0]->Name);
$this->assertEquals('hoge@example.com', $email->To[0]->Address);
$this->assertSee('本文', $email->Text);
関連して dummy データ 、 テストデータ を流し込む用のSeederも用意した。この辺は、軽量フレームワークなのでしょうがないが、割とそれっぽく書けるようになったので、満足している。GithubActionsも使って、CIも回し始めた。
デプロイ
今までは、インフラエンジニアが ssh で サーバにログインして、秘伝の デプロイコマンドを手で叩いていたが現在は、Slack コマンドで、github Actions を キックして、デプロイを行っている。１日何回も気軽にデプロイする環境や風土を作って行きたいと思っているので、人に依存しないでデプロイできるようになったことは、大きい。次は、main branch にマージされたら、自動で deploy する予定。
sassのファイルのサルベージ
初期開発以降、何故かcssが直編集されていて、sassのbuild環境もない状態。
sassが無いと今後の改善が前に進まない状況であるので、laravelは使っていないが、laravel-vite-plugin というビルドツールを突っ込んで、build環境を作った。
現在デザイナーさんが、gitのcommit履歴を追いながら一生懸命、sassファイルのサルベージ中！
＼(^o^)／がんば！
インフラの自動化
インフラエンジニアはずっといるのでインフラ面でいうと割りと安心できる面はある。ただ、自動化は行っていない状況なので、Terraform と Ansible の自動構築文化を入れた。 ベースは私が作ったが、今は、バトンタッチした。まだ半信半疑でやってもらっているが、絶対そのうち良さがわかるはずーーー！！！！！！！
やったこと（マネジメント編）
振り返りとポストモーテム
振り返り(週１)、ポストモーテムの文化を入れた。今のところポストモーテムを一番書いているのは、私自身である。。（失敗も沢山している。）
仕事で怒ることはな必要ないと思っている。（私ももちろん人間なので心意気です）
失敗して、振り返りして、改善して行けば、よい。ただそれだけだと思っている。
なにか起こってしまったことを、自分や、メンバーが分け隔てなく、振り返り、議論すべきだと思っている。これには、素直さが物凄く大事。道半ばという感じ。ちょっとずつ。
1on1
私より後に入社した人は月１、私より前に入社した人は、オンボーディングの意味も込めて、週１でやっている。
基本は、私の思っている方向性の共有と、メンバーが思っていることを、聞いて共感したり、こうしたほうが良いんじゃん？みたいな話をしている。ちょうど、９月から会社として、新たな期が始まるので、メンバーそれぞれに、どのぐらいの間隔で実施するのが良いですか？と聞いて、メンバーに決めてもらおうと思っている。
エンジニア と 営業、CS との課題共有の場
今まで不具合やちょっとした改善提案など、対応する機会が無かったので、２週に一度、お客様から上がった声や営業メンバー視点の要望を共有してもらう場を設けた。もちろん、課題の量は沢山あって、すぐにどうこうできるってわけじゃないけど、エンジニアが共感するってのは、すごく大事だなと思った。
エンジニア評価制度
私が入るまでは、エンジニア２人ででエンジニアの昇給の仕組みが無かった。今は、私も含めて5人の世帯になったので、必然的に評価＆昇給の仕組みが必要になった。ここでちょうど、９月から新たな期が始まるタイミングで経営サイドと合意ができたので、評価制度を導入する。これは、け決してめっちゃよい制度というわけではない。最低限エンジニアがアピールできる場を作ったというイメージ。なのでまずはアピールの場に使ってほしい！ここから毎年補正して良くしていければと思っている。
やってよかったこと
昼夜問わず上記に書いたような改善をやってきた。特に、やってよかったと感じたのは、私より入社が早いエンジニアが「これだったら、メンテできるかも？！」と1mmいや、1cmぐらいは思ってもらえたことが、嬉しかった。
これは、改善を始める上での最低限の入り口でしかないが、システムに愛着を持ってほしいと思っている私に取ってはとても嬉しかった。今までテストを書いたことが無かったメンバーが、今や、当たり前の様にテストを書く。テストが無いと怖いと言う。大変おこがましいが、コードレビューで「こうしたほうが良いのでは？」と問うと共感してくれ、すごく成長されている。なにより、とにかく信用して任せてもらえるってことがとてもありがたいと思っている。これがなければ前に進めていない。
これから
これから改善を始めるスタートラインに立った？ぐらいのところ。ここから、限られたリソースの中で、いかに大事なことをやっていけるかが、より大事だと思う。
残念ながら、入社して半年、主力サービスの数字周りをまだ、見きれてないし理解しきれていない。ここが事業会社の醍醐味なので、早く数字を見れる余裕をつくり、可視化を進めて、ガンガン提案をして課題解決をしていきたい。そんでもって、チームで良いプロダクトを作って、お客様の課題解決をして、エンジニア、デザイナーをもっと採用できるよう頑張る！
Discussion
移行？