リモートワーク下で立ち上がった開発チームがモブプロを通してうまく開発できるようになった話

こんにちは。freeeの中部支社でエンジニアをしている maru です。

私たち中部支社の開発チームは去年7月の立ち上げ以来、『中部から日本中で使われるプロダクトを作りたい』と考えて開発を行ってきました。 そのためにもfreeeの東京・大阪の開発チームと自然体で連携できるよう、様々な工夫をしています。

developers.freee.co.jp

今回はその中でうまくいったプラクティスの一つとして、チーム横断でモブプロをした話をご紹介します。

きっかけ：支社の立ち上げでこれまで接点のなかったチームに参加

弊社では昨年2月からリモートワークが始まり、HangoutやRemo上でのコミュニケーションもすっかり日常となりました。 このリモートワーク下においてもチームの異動や、新チームの立ち上げが盛んに行われています。

中部支社の開発チーム（通称 みそかつ）もその一つでした。

去年7月に立ち上げたチームでこれまで一緒に働いたことのない関西支社のたこやきチームに合流することになりました。 担当する開発も、プロジェクト管理freeeという初めて触るプロダクトになりました。

しかし１ヶ月ほどして、異なる文化を持ったチームから来たことによる「壁」にぶつかるようになります。 コードにどんな意図があるのかや、その背景がわからないまま開発していることに課題を感じ始めていました。

具体的に感じた課題感は次のようなものがありました。

1. どこにコアとなるロジックがあるか把握するのが大変で、生産性が落ちてしまっていました。（具体的には既存の実装を調べる時に、実質機能していないロジックを精査していたこともありました。）

2. 背景知識やプロダクトの設計思想を知らないため、設計方針の議論で手戻りが発生することが増えていました。

3. PRのコメントで議論をしていても、コメントを書く人と読む人の事前知識に差があると、うまく伝わらなかったり表現が冗長になってしまいます。その結果なかなか議論が進まないこともありました。

有志チームの開発で「モブプロ」を体験した

チーム合流から3ヶ月ほどたったところで、これらの問題を打破するヒントを得られました。 チーム横断で有志メンバーが集まって、技術的な負債や課題を解決する期間（551スプリントと呼んでいます）で、シニアエンジニアの方の呼びかけでモブプロを行ったのです。

web会議ツールのRemoとVS CodeのLive Share機能を使って、4人ほどで集まってコードを書きながら設計方針を決めました。

Remo上でのモブプロ風景

この時、次のようなことを心がけて行いました。

• コードの方針を決める時には普段から課題に感じていることを口に出しながら、その解決策をなるべく コードで示す ようにします。

• ドライバを順に交代しながら行い、全員が実際に書いて方針を実現していくようにしました。

その結果シニアエンジニアの思考や意図を書きながら学んでいくことができました。これまでチーム毎にばらつきのあった細部の実装の指針についても、様々な面での優劣を議論し認識を合わせることができました。

普段の開発でもモブプロをするようになった

有志の開発以降は普段の開発でもモブプロを取り入れるようになりました。 よく行うのは開発初期の設計や実装方針を決める段階で、テックリードや開発をリードするエンジニアがアイディアを提案しながら実装方針を形にしています。

また馴染みのない機能拡張の開発を行う時には、既存の実装をよく知る人にモブプロに入ってもらうようにしました。 結果として既存実装の疑問点や当時の意思決定の背景を理解した上で、コードの変更ができるようになりました。

具体的には課題に感じていたことについて、次のような変化が起きました。

1. ロジックの配置ルールを知ることで、コアロジックの書かれている場所をスムーズに把握できるようになりました。またそれだけでなく、既存実装の抱える課題点や技術的負債について全員が共通認識を持つことで、普段の開発計画の見積もりが立てやすくなったり、リファクタリングの計画を盛り込むことができるようになりました。

2. チームで大切にしている考えや方針、思想を理解できるようになりました。例えばロジックを可能な限りサーバーサイドに寄せる方針であったり、プロダクトのコア機能がどこにあり、ユーザーストーリーや価値をどのモジュールが実現しているのか、などです。

3. モブプロを通して建設的な議論の成功体験を積むことができたおかげで、臆せず意見を言い、より突っ込んだ議論をしても大丈夫という安心感を持つことができました。

今後の展望

これまでの9ヶ月ほどで関西支社との連携も機能し、支社の距離を超えて一体感のあるチームで開発を回すことができるようになりました。 その理由には今回お話したモブプロ以外にも、日々のコミュニケーションや細やかなドキュメントでの情報共有など様々な工夫があります。

今後はこれまで蓄積してきたノウハウを元に、東京のチームとも連携の機会を増やし、freeeのコアに近い領域においてもより大きな貢献をしていけるようがんばっていきます。

仕様変更コミュニケーションの進め方

こんにちは！freeeのニックです。スプラトゥーン3の開発が発表されて、ワクワクが抑えられない今日この頃です。

今回は、2020年12月に実施されたAPIの大幅な仕様変更について、どのように開発者コミュニケーションを進めていったかについてお話しします。

freeeのPublic APIについて

freeeのPublic APIは、仕様や使い方をドキュメントとして公開し、誰でも好きな時にAPIを利用した開発ができるようにしています。

自分はPublic APIの利用促進を進める「ディベロッパーリレーション」というロールを担当していて、APIの情報発信や開発者の皆様とのリレーション構築を中心に業務を行っています。

Breaking Change (破壊的変更) とは

「Breaking Change」という言葉をご存知でしょうか。

APIなど、外部連携サービスのバージョンアップを行う場合、互換性を保ちながら進めるのが通常のやり方です。「後方互換性」と呼ばれています。

一方で、サービスの継続性や品質担保のために、止むを得ず互換性を犠牲にしてでもバージョンアップを行うべき場合があります。後方互換性を担保せずにバージョンアップを行うことを「Breaking Chagne」と呼びます。日本語では「破壊的変更」と呼ばれたりします。

仕様変更をする理由はケースバイケースですが、今回は

• 開発者からのフィードバック、仕様面のちぐはぐさの解消
• 開発者が安心に、手戻りなく開発に取り組むための改善

など、開発者の皆様が安心して開発に取り組めるよう、実施することになりました。

Breaking Change の詳細については、まっつーの投稿でより詳しい説明が行われているため、ぜひご覧ください。

APIの大幅な仕様変更とコミュニケーションプランの作成

仕様変更に先立って、関係者の皆様に支障が出ないよう、前もってコミュニケーションプランを作成しました。

コミュニケーションプランは、おおむね以下の手順で進めています。

最初に、仕様変更の内容確認。どんな理由で、どのように仕様が変わるかを把握します。

変更点が把握できたら、仕様変更のインパクトを見積もります。影響を受けるサードパーティはどの程度存在するか、特に影響が大きい変更はどこか、などを、ログをもとに算出します。

仕様変更の内容によって、規模感は上下します。微小な変更の場合は小規模なプランで済ませますが、今回は影響範囲が大きいと判断し、プランも大掛かりなものとなりました。

次に、大まかなスケジュールを作成します。プロジェクトのマイルストーンをおおよそ設定。いつまでに何を行うのかを設定します。スケジュールをもとに、本格的なコミュニケーションプランの作成を行いました。

今回の仕様変更では、事前に半年間の切り替え期間を設定。開発者の皆様に前もって新バージョンを提供し、余裕を持った改修に取り組んでいただけるよう配慮しました。

社内外への告知プランを作成する

コミュニケーションプランをもとに、社内外のステークホルダーに説明を行い、情報発信する準備を進めました。意識したことは「広く、大きく伝えて巻き込む」こと。APIはインフラの一部なので、皆さんに理解してもらい、協力してもらうことが大事です。

一方で、APIの技術情報は、営業担当者やマーケティング担当者の皆様には理解が難しい側面があります。そういった方々に、できるだけわかりやすく説明を行い、協力してもらいたい内容をまとめて力を貸していただきました。

実際の情報拡散ルートをまとめると、以下のような形になります。

大事なのは、「情報が必要な方に届け切ること」です。リリースノートを公開するだけでは、情報は届きません。社内関係者の皆様にご協力いただき、各方面に連絡をしてもらいました。個別カスタマイズを行っているクライアントへは、社内の営業担当部門から。アドバイザーの先にいらっしゃっるAPI利用ユーザー様へは、アドバイザー担当部門を含め、誰に対して連絡を行うか整理しました。

下記は、仕様変更に影響があるAPIコール数の推移です。皆様に協力いただいたおかげで、プラン通り切り替えが進んで行きました。

完全なコミュニケーションは難しい

全体的には計画通りに進めることができたのですが、反省するべき点も多くありました。個人的には、リリースノートの記述に分かりづらい表現があったところが反省点です。

必要な情報を、できるだけ簡易に、分かりやすく伝えることはとても大事です。いつになっても「完璧」になることはない、考え続けるべきテーマです。

技術面からの記事もご覧ください。

APIの仕様変更については、Engineerのまっつーが、同テーマで記事を書いています。読み比べていただくと、ビジネス側・Engineer側の両サイドから、どのようにプロジェクトを進めていったかがわかるため、合わせてご一度ください。

最後に

最後に、宣伝をさせてください。freeeでは、APIを利用する開発者の皆様に「freee Developers Community」、「freee Open Guild」という情報提供の場を提供しています。ぜひご登録ください。そして、APIの活用について一緒に情報交換をしていきましょう！

組織変更用のアプリ開発から広がる夢と、Salesforceパッケージ開発のデメリットの話

こんにちは。freeeでDevBrandingチームに参加していたり、採用管理システムを作っている@noblejasperです。

今回組織変更をする社内アプリを開発して夢が広がってワクワクしている話と、Salesforceパッケージ開発して気づいた課題の話をさせて下さい。

本日から1週間 freee Developers Blog Week 開催

本日からfreee Developers Blog Weekと題してたくさんの記事をお届けさせていただきます。多くの方にfreeeの開発者の事を知っていただき、なにかのお役に立てればとても嬉しいです。freee Developers Blog Weekにかける想いや詳しい説明は下記の記事に詳しく書いてあるのでも気になる方はこちらもどうぞ。

developers.freee.co.jp

freee Developers Blog Weekのようなイベントを不定期ではありますが継続的に開催し、freeeの開発の事をアウトプットしていく機会を作っていこうと思っています。

明日からの記事はきっと私の記事よりも読み応えがあって面白いはずなので、是非読んでいただけたらとても嬉しいです。

”組織変更”のためのSalesforceアプリ開発

今回私が取り組んだ開発は社内で定期的に行われる「組織変更」をスムーズに行える機能開発の話です。「組織変更」と言われてもピンとこない方も多いと思います。私も着手以前はそもそも誰がどんな作業をするのか知りませんでした。

freeeでは、3ヶ月に1度組織内の配属やチームの粒度、名称の変更などを行います。（3ヶ月の中で適宜行われることもあります。） 従業員にとって最適な配属や、事業の成長や変化に合わせて組織を最適化させていく作業です。

freeeの今までの社内フローとしては下記のような手順で進められていました。

1. 各組織のオーナーが組織の構成を決める
2. 各組織間をまたぐ異動者の配属をあわせて決める
3. 1つのスプレッドシートに記入する
4. 労務チームなど確認者がおかしな点がないかどうかチェックする
5. 社内共有用の組織図や名簿を作成する
6. 各種反映が必要なシステムに転記する

人数もチーム数も小規模だった時には、この運用で充分でした。専用のシステムを使う必要はなかったと私も思います。

会社規模拡大により、組織変更が重労働に・・・・

会社の成長と共に人数が増えチーム数も増えた現在では、組織変更の作業に多くの課題が発生していました。

• 毎回組織図や名簿を作るのに膨大な時間がかかる
• 組織図、名簿作成ともにミスが発生しやすく修正が発生する
• 各種システムへの転記もミスが発生しやすい
• 上の作業にそれぞれ時間がかかるため、各種システムへの反映が遅くなる

社外製のSaasツールなどを活用してみたり、スプレッドシートで効率化が出来ないかなど、試行錯誤を行っていましたが、なかなかうまくいきませんでした。

今回私が開発したツールで組織変更を実施する所まで進められました。どのように開発したのか、今後の展望と合わせて紹介させてください。

単体アプリケーションとして開発してみる

私はSalesforceエンジニアとして社内システム開発を行っています。今回もSalesforce上で開発を行いました。

今回私は組織変更を行うアプリケーションに「組織変更クリエイター」という名前を付けました。「組織変更クリエイター」はパッケージ開発モデルという開発手法で、Salesforce上で動作する単体のアプリケーションとして開発しました。パッケージ開発についてはSalesforce自体のヘルプに詳しく説明されていますので、興味がある方はそちらをご覧ください。

パッケージ開発を選択したのにはいくつか理由がありますが、主な理由としては開発したアプリケーション自体のSingle Source Of Truth (SSOT)を本番環境ではなくGitHubにしたかった為です。SSOTに関しての考え方はtalendのこちらの記事が詳しいので気になった方はご参照下さい。

本番環境のSalesforce上で開発を行ってしまう（詳細は省きますが、変更セットを用いた開発フローの事を指しています）と、SSOTがVCSではなく本番環境になってしまいます。Gitのmainブランチではなく本番環境が正になってしまいます。Salesforceの構造上仕方のない事ではあるのですが、最近ではSalesforce社から「Salesforce Developer Experience（SFDX）」という開発手法が提案されており、回避出来る方法が存在します。厳密な説明ではないですがそれがパッケージ開発です。

本番環境の全てをパッケージ化する手段も存在します。しかし多くの独自機能や設定が含まれている本番環境をパッケージ化するのは容易ではありません。とても時間がかかります。開発に携わるメンバーのキャッチアップも必要です。将来的には本番環境もパッケージ化に近い形で管理したいと考えています。しかし現時点ではまだ出来ていない状況です。パッケージ化されていない現在も日々開発は行われているため、本番環境は常に肥大化しています。

そのため本番環境に存在する既存機能と疎結合に出来る新規開発だけでもパッケージ化した形で開発したいと考えました。そのためには本番環境で直接開発を行うのではなく単体で開発を行い、パッケージングされたアプリケーションを本番環境にインストールするという手段を今回は採用しました。

これによって、開発したアプリケーションに含まれる全てがコードで管理され、SSOTをGitHubにすることができます。さらにCI/CDの恩恵を受けることが容易になり開発速度や品質も上げやすくなります。Webエンジニアである私にとっては馴染みのある環境で開発が出来るのでとても快適です。

しかしやってみて分かった大変な所やデメリットもあります。

パッケージ開発の課題/デメリット

今回新機能をパッケージ開発した事でデメリットや手間がかかる所も見えてきました。

現状分かっている課題、デメリットは以下です。

• Salesforce Administrator 担当者との協業がしづらい
• 手戻りでの修正がとても大変
• 本番環境との共存が大変

弊社独自な部分もありますが、本番環境のSFDX化（パッケージ化）が出来ていない組織だと発生しうる課題、デメリットだと感じています。簡単に内容を補足します。

Salesforce Administrator 担当者との協業がしづらい

Salesforce Administrator 担当者（以下Admin）は開発経験者ではないことがあります。そういった場合にシェルからコマンドを実行したり、GitHubの操作をするのは導入障壁が高い事があります。新たにキャッチアップしてもらうようには出来るかもしれませんが本来の業務に加え（大体Adminの方は多くのタスクを抱えている）、更に作業を増やす事になってしまいます。

Adminの方に依頼出来ない分、本番環境上で開発する方法に比べて開発者の手順や作業が多くなってしまいます。Adminの方にどれぐらい作業をお願いしているのかはチームによってまちまちだとは思いますが、いつも分業している作業を分業できなくなるのは思いの外大変だったりします。普段Adminの方が把握されている部分の知見が足りないため、不具合やミスも出やすくなってしまいます。

この課題の解決策としては、開発環境をAdminの方にも簡単に作成でき開発を行ってもらう方法を模索しています。自動デプロイなどの環境を整備し、GitHubを直接触らずに開発出来る環境を作りたいと思っています。

手戻りでの修正がとても大変

どんな開発でもそうなのですが手戻りでの修正が特に大変です。本番環境上で開発する場合に比べてパッケージ開発独自の手順がいくつも増えるためです。

具体的には、

• 開発環境の作成、コードの適用、サンプルデータの適用
• 開発後のパッケージング、公開作業
• パッケージのアップデートのテスト
• パッケージのインストールに関連する依存関係の確認と対応

などが必要になります。1つ1つの詳細な説明は割愛しますが、パッケージ開発特有の処理や手順などが存在します。

この課題の解決策としては、開発環境の作成からパッケージング、公開作業部分はCI/CDで自動化していきたいと考えています。アップデートのテストや依存関係の確認と対応に関してはまだ何も思いついていませんが、今後向き合っていく必要が出てくると認識しています。

本番環境との共存が大変

上のほうで疎結合と書きましたが、疎結合でも結合はしています。少しだけでもつながっている部分があります。パッケージ化したアプリケーションの導入では、Sandbox環境と呼ばれる「本番環境をコピーした開発環境」にインストールし、結合部分の動作確認やテストを行います。

情けない話ですが、私はとりあえず手を動かすのが好きで、事前に設計をしっかり作るのが苦手です。そのためSandboxでのテスト時に設計の不備から多くの手戻りが発生しました。前述の通り、手戻りには手間がかかります。自分の計画性のなさをとても悔いました。

この課題の解決策としては、アプリケーション開発時には結合部分の設計は丁寧に事前にやらなければいけなかったと反省しています。今後はチームのメンバーにも助けてもらって、不備が出づらいレベルまで設計してから取り組もうと考えています。

とはいえパッケージ開発は面白いので、チャレンジする価値あり！

まだまだ課題は山積みですが、パッケージ開発は面白いです。今回複数の機能が必要で、実際の業務に直接必要なパッケージ開発を行ってみましたが、アプリケーション自体の開発はとてもスムーズで快適でした。是非Salesforce開発者の方はチャレンジしてみてほしいと思います。そして知見を私にこっそり教えてくださいｗ

面白かったポイントはこんな感じです

• たくさんのノイズがある本番環境で作業しなくていい
• GitHubベースで開発出来るのは開放感がある
• CI/CDの恩恵に夢を感じれる
• 既存環境の状況に囚われづらい

組織変更クリエイターは4月デビュー

パッケージ開発の話が長くなりましたが、「組織変更クリエイター」の話に戻ります。組織変更クリエイターは簡単に説明すると、以下のようなアプリケーションです。

• 現組織からデータをコピーしてくる
• 次の組織変更後の配属やチームを作成、編集出来る
• 作成中の組織の名簿や組織図を表示、エクスポート出来る
• 現組織に対して組織を反映出来る

組織変更中はこんな画面で操作します。チームと従業員を1画面内で設定できます。

4月にある組織変更に向けて今まさに各オーナーが組織をポチポチ変更してくれています。今回初の利用なので戸惑いも伺えますが問題なく（多少の問題はありつつも）使っていただけているようです。

組織変更から繋がるバックオフィス業務の夢

組織変更クリエイターを開発しながらニヤニヤと妄想していた夢があります。それは高速統合型組織情報です。名前はダサいですが、今回の組織変更クリエイターが軌道に乗ることで広がる構想です。

組織変更クリエイターによって組織変更当日に従業員と組織の最新データがシステムに反映される事で、多くの社内システムに革新が作れます。

• 会計freeeと連携することで申請、承認などのワークフローの元になる組織情報
• 人事労務freeeと連携することで勤怠承認などの元になる組織情報
• 社内の評価システムの元になる評価者の設定
• 社内アカウント管理用データベースの設定

これらの情報や設定が常に正しい情報で即時反映される世界。何か作業をする時に「あれ？この情報古くない？」と確認する必要のない世界。夢が広がります。

まだまだ予測しきれていませんが、組織と従業員に紐づくマスターデータが一元管理され即時反映される事で得られるメリットは計り知れないと考えています。

高効率で、高精度なfreeeのバックオフィスを構築することでfreeeに関わる全ての人達が大きなインパクトや成果を出せるようになるはず。この構想の続きをまたBlogで報告させて頂けるように開発していきます。

そんなバックオフィスを作りたい人も、そんなバックオフィスがある会社で働きたい人も大募集中です

jobs.freee.co.jp

freeeのCREチームとは

はじめに

　freee CREチームのKishimotoです。

　2014年に入社以来開発チームに所属していて、現在はCREチームで仕事しています。

　入社当初は、お問い合わせの調査、修正からデプロイ作業などを担当していました。

　その中で、お問い合わせ対応の効率化を考えるようになり、当時のマネージャーとテクニカルサポートチームを作り、その後、CREチームへ改名しました。

　今回はそんな自分から見た、freeeにおけるCREを軸に書いていこうと思います。

---

freeeのCRE

　CREという職種はGoogleが発表した専門職を参考にさせていただきました。

Google Cloud Platform Japan 公式ブログ: Google の新しい専門職 : CRE が必要な理由

　Customer Reliability Engineering（カスタマー リライアビリティ エンジニアリング）の頭文字を取った略で、シーアールイーと読みます。

　顧客信頼性エンジニアリングとも呼ばれています。

　freeeでは、前身のテクニカルサポートチームを改名してCREチームを作りました。

　当初は3名でスタートしましたが、現在では10名ほどのチームに成長しています。

　改名の理由は、仕事内容とチーム名の不一致を感じ、「もっとしっくり来て、よりかっこいい名前ほしいよね」と、チーム内で話題になったのがきっかけだったと思います。端的に言うと「テクニカルサポート」にプラスして、エンジニアリングの要素を含んだ名称にしたかった。他社の職種も参考にしながら案を出し合い、その中で「CRE」という名称にかっこよさとしっくりさを感じて採用となりました。

　Googleの専門職とは異なる部分もありますが、個人的に以下2点に共感しました。

• アプリケーションのデザインやコード、運用などに内在する信頼性
• お客様の不安が軽減されている

freeeのCREはどんなことをしている？

freeeのサービスに関わるお問い合わせを

エンジニアリングスキルの活用によって

解決へ導く

　ということをしています。

　その過程で、開発エンジニアチーム、QA、PM、UXや、サポート、セールスなど、多くのメンバーと議論しながら、より早い解決方法を一緒に考え、優先順位を決めて対応しています。

freeeのサービスとは？

　freeeは「スモールビジネスを、世界の主役に。」 　というミッションのもと、スモールビジネスの業務を効率化するサービスを提供しています。

corp.freee.co.jp

　CREではその中でも利用者の多い会計freeeと人事労務freeeを中心に対応しています。

お問い合わせとは？

　「使い方がわからない」

　「不具合が発生する」

　「欲しい機能がない」

　など、freeeのサービスを使う中で

　「どうしたらいいのか分からない」

　という状況に遭遇した方々から、サポート窓口へお問い合わせをいただきます。

エンジニアリングスキルとは？

　Webアプリケーションを開発、運用するスキルで以下のようなものが挙げられます。

1. コードを書いて意図したプログラムを作れる
2. コードの管理、調査、修正のフローが分かる
3. セキュリティやリスクを考慮したコードが書ける
4. 開発言語や連携している外部サービスの使い方が分かる
5. 運用後の課題発見や分析をして、次にやることを考えられる

解決へ導くとは？

　お問い合わせはサポートチームが一次対応します。

　そこで解決に至らない場合、CREチームへ渡ってきます。

• 分かりにくい仕様のお問い合わせやログ確認などの調査と回答
• CREチームで対応できる軽微な不具合のコード修正やデータ修正
• 深い部分の修正などは仕様を熟知した担当の開発チームへエスカレーション

　お問い合わせの回答を早くすることも大事ですが、一方で、お問い合わせが発生しない仕組みを作ることも大事だと思っています。

　そのため、お問い合わせが発生しない仕組み作りも他チームと協働で進めています。

• よくあるお問い合わせの発生原因を修正して元を断つ
• ヘルプページなどを活用して自己解決できる仕組みを作る

　よくあるお問い合わせについてはサポート窓口の手前で解決できるものもあります。

• チャットボットによるAIを活用した回答の調整や実装
• お問い合わせフォーム上で解決へ導くサジェスト機能の実装

　といった機能の改善や開発の試行錯誤も行っています。 　

こんな思いを持つ人に向いています

• 新規開発よりも運用面でエンジニアリングスキルを活用したい
• エンジニア以外とのコミュニケーションも積極的にやっていきたい

　採用チームと一緒に採用活動をする中で、CREはまだ経験者が少ない印象です。

　とはいえ、CREに共感する課題意識を持つエンジニアは多くいると思っています。

おわりに

　今回はfreeeのCREについて僕の視点から軽くご紹介させていただきました。

　4月からはCREチームにも新たな仲間のJOINが決まり、さらに成長していきます。

　まだ認知度の高くない職種ですが、将来のキャリアビジョンやプランなどを考える際に、選択肢のひとつとして「CREというポジションもあるのね」と覚えていただけたら幸いです。

　今週はfreee Developers Blog Weekで、他のチームからの投稿もあります。

　そちらもぜひご覧ください。

　また、freeeでは引き続き一緒に働く仲間を募集しています。

　採用情報で気になる職種がありましたら、ぜひご応募ください！

jobs.freee.co.jp