こんにちは、エンジニア採用担当のnobjasです。

（nobjas）

今年1月に発表されたfreeeの子会社のfreee finance lab（プレスリリース）の開発は、正社員や業務委託さんが協力して開発を進めています。

これまでたくさんの現場を経験して、様々な現場の酸いも甘いもご存知の皆さんに、今回はランチをしながら今の仕事についてどう思っているのかを聞いてみました。この記事では、子会社での”ナマの開発の雰囲気”を伝えるべく、参加者が気軽に発言できるよう名前も顔も出さない「覆面」状態でお届けします。

今回話してもらうのは、製造業や旅行会社、金融系など大手サービスの経験がメインの業務委託エンジニア3名（A,B,Cさん）。全員がバックエンド経験者で、フロントはABテスト企画や新サービス開発を経験した方もおられます。

freee入社後は、過去にクレジットカード会社の連携強化や金融機関向けの開発、会計freeeのレポート機能のフロントエンド構成の刷新に携わり、現在はリリースにも記載されている新サービスの開発に全員が関わっています。（※A,B,Cさんの発言は、少し発言者を入れ替えるなどして、個人が特定できないように調整しています）

金融子会社の仕事の進め方

ーnobjas：よろしくお願いします。今日は個別の業務内容というよりも、業務環境について色々教えてください。

（ランチ座談会の様子）

ー早速なのですが、子会社のプロジェクトに限らず、金融系の開発ってどこが大変ですか？

C：会計チームなどの経験から言うと、金融系は提携先が多いので、提携先それぞれの仕様や要求をかためたり、つなぎ方の工夫には苦労しますね。統一フォーマットにしたり、パーツを付け替えられる設計にはしますが、それでも苦労はあります。

ー設計は誰が決めるのでしょうか？

B：金融では、個人でやっています。立場は関係なく、自主的に設計します。

ーおお、個人で。レビューとかはどうしてますか？

B：当然レビューはあります。最近は4,5人で集まってモブプロを1度やってみたりしました。「こういう設計でやろうと考えています」「コードのサンプルはこんな感じです」と説明するプロセスを入れて取り組んでみました。

ーモブプロしようとなったのは何か課題感があったのですか？

B：ソースを読むだけだと全ては分からないからですね。「都度、他の人に説明するのだったらみんなで集まって、気になるところはその都度聞いた方が早い」となりました。

C：フロント側は結構新しい技術を採用していて、ほかのメンバーがキャッチアップしきれていないような状況があったんですよ。

ーメンバー間のスキルにズレがある状況だったんですね

C：はい。なのでフロント担当が「こんな感じでやりました」と言っても、そもそも何をやっているのかがよくわかっていない状況でした。

ーモブプロはだれが発案したのですか？

A：毎週の振り返りで、属人化の課題が2週連続で出てきたので、「じゃあモブプロでしよう」という話になりました。結構社員とか業務委託とか関係なく、みんなで始めた感じですね。

あと、他のチームが「モブプロがとてもよかった」と言っているのを参考にしました。そういう言語や開発のやり方を、他のチームから吸収できるのは良いですよね。

ーfreee内の失敗例・成功例も参考になっているのですね。どういう場面で見ているのですか？

A：freee内にRubyやGoなどの言語に対するナレッジ量は断トツでたまっているので、その辺りはかなり参考にしています。QiitaとかGoogleのdocsはよく漁っています。

ー良いですね。逆に、やりづらいことやほかの現場で慣れていたらここは戸惑うなどありますか？

A：以前の職場と比べると、コード以外の仕様書が少ないです（笑）。各機能の最新仕様は、本番のコードから読み取るのが当たり前になりました。

開発ごとの要件の記録はあるので、それらを順番に読んでいきつつ全容を理解しています。

ーなるほど。それでも新サービスづくりに飛び込んできたい人が合う感じですか。

A：そうですね。でも、落ち着いてきたらドキュメントを書きたい気持ちはあります（笑）

C：私はRubyの経験は浅かったですが、必要なところはサポートしていただけるので、キャッチアップする意気があれば何とかなるものだなとは思いました。

ーコードだけを見て「きっとこうなっているのだろう」と空気を読んで書けないと結構しんどいじゃないですか。

A：そうですね。問題の当たりがつけられるぐらいの経験が無いと、原因が特定できないです。問題を丁寧に順に辿って行って、たどり着けるようなキレイな道は無いですが。デカすぎて（笑）

全員：笑

C：金融チームに入る前は「設計書通りにつくって」という感じかなと思っていました。

キャッチアップは大変ですが、入ってみると意外と自由にやらせてもらっています。慣れると「コードを読んでみればいいか」と思えてきますね。

昔の職場はコードが読めない人もいたのですが、freeeは皆さんプログラムが読めるので、「コード読んで」が通用します。

ーfreeeだとコードが読めずにエンジニアに関わる人はいないですね。

C：そこは、全体的にレベル感が高いなと思いました。

ーちなみに個々人で設計していると、後から「こっちの設計のほうがよかった」と思ったりするのでしょうか？。

B：はい、そういうこともあります。そのときはベストの選択をしたなと思うのですが、あとあと見比べてみるとどうしても粗が目立つとか。

どんな技術を使っているの？

ーfreeeは技術スタック的に新しい技術が多いと思うのですが、特徴的なことはありますか？

A：フロントはTypescriptと、”VIBES”という社内で開発されたReact共通コンポーネントライブラリを社内で初めて採用しました。

ーでは、あまりスタイルシートを書いたりはしないのですか？

A：いや、書いてますね（笑）。要件によってはVIBESが使えなかったりしますので、そこはCSSを書きます。

ーTypescriptは会計チームでも使っていないですが、どうして使うことに？

A：最初はflowtypeで進めようという話だったのですが、「flowtypeは歴史があるけど今後のプロジェクトだと相性悪そうだからTypescriptに移行しよう」という提案があって決まりました。

B：Typescriptだと利便性はもちろん、言語レベルで型情報を設定することもできるので、エディターで入力補完が効きやすいのも良かったです。

ーいいことばかりですか？

A：そうでもないです。やはり新しい言語なので、困ったときに英語のドキュメントしかないなど、トラブルシューティング系は大変です。社内でもノウハウが少ないので、自分で調べるしかありません。

ただ、全社的に新しいことに挑戦してきた会社なので、色んなtipsや困ったときに相談できる人が多いのはfreeeならではだと思います。

ーなるほど。サーバーサイドはどうですか？

B：RubyとGoどっちも使っています。一部はマイクロサービス化してGoに切り出して、本体はRubyで動いているので、そこは少し面倒です。

ーRubyとGoが共存している理由は？

B：金融サービスのネックの一つは、会計データの収集と処理です。

データ量が膨大なので、物理的な時間がめちゃくちゃかかります。それがボトルネックになるのは明らかだったので、少しでも性能がよさそうなGoでマイクロサービス化しようと。

ー絶対にGoの方が良い感じだったのですか？

B：社内のマイクロサービスを立ち上げた事例が共有されていたので、「比較してGoの方がよかった」という振り返りを見て、並列処理はGoでやろうと。あまりブラックボックスもないので、ゴリゴリにチューニングができそうなのもメリットでした。

ーさくっと新しい技術ができる環境は良いですね。

C：基本的には、新しい技術を使うことには制約がありません。プロダクトの特性に合わせて検討した結果、相性が良さそうなら新しい技術でもチャレンジしようというスタンスですね。

金融チームにはどんな人が多い？

ー今の金融チームはどんな人たちがいるチームですか？

B：結構自立していて、自分で決めることが苦ではないというか。

普通は意思決定者に聞くパターンが多いと思うのですが、金融チームでは逆です。自分たちで一度判断して、「出来上がったものを見てください」というタイプが多いです。「決めてください」と投げるのはあまり見かけません。

ーいいですね。キャラクターや人柄とかはどうですか？オタクが多いとか、ネアカ・ネクラ（根暗）が多いとか。

A：ネクラが多いですね。

B：誰を指して言ってるのかって考えてしまいますね（笑）。

ー（笑）。ではあまり雑談は多くないのですか？

C：雑談は多くはないです。結構みんな集中してがーっとやる感じです。割と静かだと思います。ビジネスメンバーと比べると静かだと思います。

A：ビジネスの人はうるさいですよね（笑）おかげでカジュアルな相談をしやすいですが。

ーなるほど。ミーティングでは結構積極的に発言はされるのですか？

C：ですね。黙るとかはないです。freeeのほかのエンジニアさんと比べると、ちょっとだけ大人しいとは思います。

ーなるほど。あとはスキル感はどうですか？

A：ここの金融子会社は、技術的なハードルは高いですね。

C：高い気がします。

B：手取り足取り教えてくださいみたいな人だと、結構厳しいとは思います。現時点でスキルフィットはなくとも、自分でキャッチアップできるという気持ちの人が合うと思います。

ー「別にやったことはないけど、調べたらできる」くらいの。

B：それくらいの気概があれば、一緒に働きたいですね。

ーちなみに正社員と業務委託で、権限の違いって無いのですか？

A：ほぼ無いですね。例えばフロントの設計だと今まではBさんしかやっていませんでした。だからチーム内にスキルを広めようという話になりました。

B：モブプロを始めてみて、スキルの偏りが課題だと思ったので、最近Aさんもが挑戦し始めていますね。

ー「正社員なら、もっと決めろよ」と思ったりしないのですか？

A：どちらかと言うと私たちは、いくらでも裁量が欲しい人種ですね（笑）。

ー自由にやらせろと（笑）。逆に正社員と業務委託の役割分担は何があるのですか？

A：一応、上流と本番まわりは正社員が多いです。他には、見積もりや提携先の金融機関との折衝は正社員の方が基本やっています。

B：社内外との調整事項は、正社員がされていますかね。

A：私も社外に出たのは一回ぐらいです。

C：私は一回もないです。

ー会計チームと金融で違いはありますか？

A：会計は、業務委託だと触ってはいけない部分が多いです。負荷も利用規模もぜんぜん違うので正社員の方に毎回依頼して開発を進めるのが当たり前ですね。

また、会計や人事労務チームには、各分野にスタープレーヤーが大勢いるので、優れたエンジニアリングの現場に入れたり、技術の積み上げに触れられるのは勉強になりますね。

一方で、金融はひとりで広範囲を見られるエンジニアが多く、全社内に類似コードがなく、真似するものもないので、その辺りの楽しさと苦しさはあると思います。

ーなるほど。新しいものをつくる楽しさと、コピペできない苦しさと。

A：そうですね。自分で決めなければいけませんし、もし間違った選択肢を選んだら後から恨まれるのは自分です。会計freeeのときは、「なんでこうしたのだ」と言えましたが、今は言われる側です（笑）。

今後やっていきたいことは？

ー「今後こうしていきたいな」ということはありますか？直近でも構いません。

A：今みたいな新しいものをどんどん立ち上げるチームはキープしていってほしいです。

ーなるほど。そう思うのはどうしてですか？

A：ゼロイチでのサービス立ち上げは追及していきたいです。あとは、もう少しビジネスとエンジニアが近くなればいいと思います。私たちもビジネス側の検討に参加したいし、ビジネスメンバーも画面の手直しが必要だと思ったら自分でやれるくらいに。

ー面白いですね。エンジニア側がビジネス側に食い込むだけではなくて、ビジネス側もエンジニアに食い込む形は理想的ですね。

C：私はずっとシステム開発をやりたくてウェブ系に移ったところがあるので、色々なサービスを触ってみたいです。

ーなるほど。これをリリースしたらまた新しいサービスに。

C：参加できるならそうしたいです。

ーいいですね。おそらくしばらくは運用することになるとは思いますが。

全員：笑

B：私もがっつりウェブサービスを開発するのはここがはじめてなので、結構いい経験になりました。次は、チーム間でのノウハウを貯めたいなとは思っています。

あとはサーバーやフロントの役割分担をうまく全員まんべんなくできるような形になると、もっと良いかなと。

ースキルアップにもなりつつ、かつサポート範囲が広いから、いざ開発をこれでやるぞと言ったときにみんなでできるのは強いですよね。

A：1人1人の負荷が減ると思います。

C：抜けたときにもフォローしやすいですし。ローテーションとか組んでもいいのかもしれませんね。

B：なので、モブプロとか、そういう取り組みも増やした方がいいのかなとは思います。

ーありがとうございました！新しいサービスのリリースを楽しみにしています！