こんにちは、freee受発注の開発をしている21新卒のmicciです。 freeeの新卒は4,5月に新卒研修を行うので、今年の6月でチーム配属からちょうど1年が経ちました。節目としてはちょうどいいので、この1年を振り返っていきたいと思います。

2021年6月

まず配属されてからしばらくはfreee受発注のコードに慣れる意味で、既存機能の改善系タスクをやっていきました。改善系タスクとはいえ文言修正などの細々としたものではなく、既存機能の挙動が変わったり、freee会計の方も変更が必要だったりするものをやっていきました。メンターと1on1で話してたときの目標としては、6月中に3つリリースすることでした。結果としては6月中にリリースできたのは2つで、3つ目は7月に入ってからのリリースとなりました。

この頃はとりあえずPR出して、そこからひたすらコメント貰って修正を繰り返してました。3つの機能を実装した3つのPRのコメント数の合計が239個で、命名の話から構造の話まで事細かにコメントを貰っていました。

「プログラマーのテストは、振る舞いの変化に敏感であり、構造の変化に鈍感でなければいけない。」という話は特に印象に残ってて、テスト書くときに「テストしたい対象の振る舞いはなんだっけ？」と考えるようになりました。

2021年7月〜8月

当時のfreee受発注にはサービス内のお知らせを変更したり、サービスのフィーチャーフラグを切り替えるための管理用の機能が無かったため、次はその骨組みを作る事になりました。ここでは、デプロイ先としてのインフラや、アプリケーションコードと分離するためのミドルウェアの設定をしました。インフラやミドルウェアをしっかり触ることがそれまであまり無かったので、ひたすら調べながらやってた記憶があります。触り始めのときは呪文のようにしか見えなかったterraformも少しずつどこの値がどこに渡るのか理解出来るようになりました。当時はterraformのリファレンスとひたすらにらめっこしてました。

作業中に検証用の環境にアクセスできなくなってしまったこともありました。当時は検証作業が行われていなかったので何事もありませんでしたが、さすがに背筋が凍りました。

2021年9月〜10月

管理用の機能が一段落した頃に納品・検収機能の開発に取り組み始めました。それまでより一回り大きい規模の開発で、QAを入れることになりました。しかしながら当初の予定からずれることが頻発してしまい、何度もQAのスケジュールをずらすことになってしまいました。実際に自分で開発期間の見積から機能の実装をしていったことで、どこの見積が間違っていたのか、どう実装していけばより速くQAに入ることが出来たのか振り返ることが出来たので、非常に良い経験になったと思っています。

この開発の過程で、freeeのデザインシステムvibesに新しいコンポーネントを追加していきました。自分でデザインシステムを育てていく感覚は新鮮で楽しく、その後も積極的にコンポーネントの追加や既存のコンポーネントの拡張などしていきました。

また、納品・検収機能の仕様について社内のセキュリティチーム（PSIRT）に相談しに行った際に、セキュリティ的に懸念のある仕様になっていることが判明しました。現行の仕様のままでリリースするには、セキュリティを担保するための開発に多くの時間がかかってしまうことが分かったので、セキュリティチームとの相談により一部の仕様を変更することによってあまり追加で時間をかけず、安全な納品・検収機能としてリリースすることが出来ました。

納品・検収機能はこれまでやったことない規模のリリースで、時間はかかったものの最終的には納得したものがリリースできました。

freee受発注の納品・検収機能の画面。納品ファイルというタイトルと、URLをアップロードするための入力欄、アップロードボタン、ファイルアップロードボタンがあり、その下に既に納品されているURLやファイルが表示されている。 — 納品・検収機能のスクリーンショット

2021年11月〜2022年2月

何とか納品・検収機能をリリースした後、今度は依頼のCSVインポート機能を作ることになりました。 freee受発注には、取引先のCSVインポート機能が既に存在していたので、そちらを参考にして開発しました。

普段はUXの方が作ったデザインを参考にして画面の実装をしていくんですが、既存機能を参考に出来るので今回はデザイン無しで実装していくことになりました。モックを作って適宜UXの方にレビューを貰うという形式で進めていきました。当時はUXリソースがボトルネックになりがちだったので、そこの解消をすることが目的でした。

依頼のCSVインポート機能では、取引先のCSVインポート機能より親切なエラー表示に変更することになったので、取引先のCSVインポート機能の方も同時に改修していきました。また、今回の開発の過程でvibesに新しいコンポーネントを追加したりと、既存機能の複製に留まらない形で成果が出せたので満足しています。

2022年3月〜6月編

それまでのfreee受発注の開発では1人のエンジニアが1機能担当して、リリースまでの開発を全てその人がやる方式を採用していたんですが、チームが拡大していくことを考えるとそろそろ無理があるだろうことは、それまでの振り返りで分かっていました。そこでチーム全体で開発プロセスを一旦見直すことになりました。次の開発プロセスの候補としてスクラムが挙がったので、スクラムを採用するとチームの課題は解決できそうなのか、スクラムを始めるにあたって決めないといけないことは何か等を調べていきました。

元々チームとして上手く開発を進めていくための手法には興味があったので、スクラムについて調べたり社内の先輩スクラムマスターに話を聞いたりしながら、freee受発注チームでスクラムを始めるために決めなくてはならないことの叩きを作っていきました。具体的には、なぜスクラムを導入するのか、スクラムの各ロールは誰が担当するのか、スクラムイベントはいつ開催するのか等について、このチームに合わせた叩きを作りました。理想的にはここで他のアジャイルな開発手法と比較したり出来ると良かったんですが、そのまま「スクラム行くぞー」と進んでいってしまいました。

この頃は、スクラムマスターのイメージがチームがスクラム運営する上でのプロセスに対して決定権を持つ人だったので、結構1人で動いてしまうことが多かったのは反省点です。チームで話し合いつつ意思決定をサポートする役回りが出来るともっと良かったかなと思います。現在も先輩スクラムマスターやアジャイルコーチの助けを借りつつ、なんとかやっています。チームのプロセス改善も継続的に出来ており、とりあえずスクラムが始まっている状況にはなっているんじゃないかなという印象です。最近はスクラムマスターとしての成長と開発者としての成長を両立させるためには、どうするのがいいのか悩んでいます。

おわりに

改めて1年振り返ってみると本当に色んなことをやらせてもらえたな、という印象があります。割合としては機能開発がやっぱり多いですが、インフラもやったし、vibesも触るし、スクラムマスターもやるし、書いてはないですが、ライブラリのアップデートやサポート対応もたくさんしました。やったことないことをやってみるのは、単純なことですがやっぱり成長に効いているような実感があるので、次の1年間でも積極的にやったことないことにチャレンジしていきたいです。