低カロリーにスクラムマスターを始める方法

こんにちは、freeeで人事労務freeeを開発している id:gn-spawn です。 『シン・エヴァンゲリオン劇場版𝄇』面白かったですね。 パンフレットには制作スタッフのインタビューが記載されていて、感動した作品を作っている側の仕事術が読めるのはとても貴重で奮い立たせられました。

それはそうと最近スクラムマスターになったので、プロセスの改善を行った話を書いていきます。

スクラムマスターを引き継ぎという形で始めた

freeeでは多くのチームがアジャイル開発のプロセスを使ってプロダクトの開発を行っています。 私の所属するチームも1週間でスプリントを区切ったアジャイル開発を採用しています。 他の会社や組織では専任のスクラムマスターがいる場合もありますが、弊チームではスクラムマスターはエンジニアと兼任で行っています。

私のチームでは以下のような流れで開発を進めています。

小さいリリースと検証・改善を繰り返す
小さいリリースと検証・改善を繰り返す

スクラムを実施するにあたってチームでやっていることは以下のとおりです。

  • 毎朝のデイリーミーティング
  • スプリントレビュー
  • レトロスペクティブ
  • プランニング

なぜスクラムマスターになったのか

マネージャーとの1on1の中で

  • スクラムマスターのマネージャーが非常に忙しそうなので、自分が一部でも引き継げる部分はないか
  • プロセスの改善が好きなのでそういった領域で引き継ぎたい

という話をしていると、「スクラムマスターをやってみないか」と提案されました。 今までもスクラムでの開発経験はあるものの、自分でオーナーシップを持って運用したことはありませんでした。 色々な人とコミュニケーションを取るのが好き、少しでもマネージャーから委譲できればというモチベーションで挑戦してみました。

引き継ぐにあたってやったこと

まずはデイリーミーティングのファシリテーションから引き継ぎました。 前述のモチベーションから徐々に引き継いでいく方法を取りました。私がスクラムのオーナーに慣れていないというのも理由の一つです。

やり方を知らなかった私は、前スクラムマスターのやり方をそのまま行いました。

実際に感じた問題

全ての引き継ぎを行ったところ、思ったよりも時間が取られることが分かりました。 エンジニアとスクラムマスターが兼任なので、準備に時間が取られて思うように実装の時間が取られたりしてしまいました。

これは単に私が不慣れな部分があるのですが、実装の時間が取れないのはチームメンバーへの負担も増えますし、リリースしたい機能の開発も遅れてしまいます。

特に時間がかかっているのは

  • バックログの整理
  • バーンダウンの更新

の2点です。「スクラムマスター」のロールをやる以上はチームメンバーが迷わないように完璧な準備が必要だと思いこんでいました。

他チームを見て改善していく

まず問題の改善を行う場合に、スパッと「ここが今のやり方だとマズいよね」と分かれば一番なのですが知識や経験が無いとなかなか難しい部分です。 そこで先ずは他のチームのスクラムイベントを見学してみることにしました。

今は感染症対策もあり、ほとんどのエンジニアチームがオンラインでミーティングをしているので気軽に見に行けるのは助かりました。 その中から自分たちのチームにフィットするやり方を見つけて、取り入れていくことで改善しています。

実施したアクション

他チームのスクラムイベントを見学して、以下のことを実施しました。

  • バックログを整理しない
    • プランニングで整理もメンバーと一緒に行う
  • 準備の委譲
    • メンバーのスプリントごとに出した成果を自分で書いてもらう
    • バーンダウンもとりあえず準備してツッコミがあればその場で直す

スクラムマスターとしてちゃんと準備をしなくては。と思っていたせいで準備に時間がかかっていました。 しかし、メンバーを信頼して完璧に準備をすることをやめてみました。 その結果、精神的負担が減って漫然とした多忙さを感じることがなくなり、プロセスの改善にフォーカスできるようになりました。

得られた結果

スクラムイベントの最後に、感想や改善案を書けるアンケートを置いています。レトロスペクティブでそういうのはやれば良いのでは?とも思いましたが、 レトロスペクティブでは開発に関することにフォーカスを当てています。 私へのアンケートとして匿名も可能な形で書いてもらうことで、フィードバックを受けやすい形にしています。

プロセスの改善にフォーカスできるようになったおかげで、チームとしてより良いやり方を試行錯誤ながら追求しています。

まとめ

スクラムマスターに挑戦して一番のメリットは、プロジェクトの全体像を意識してオーナーシップを持てるようになったことです。 ユーザーに素早く価値を届けるにはどうしたら良いか?というのは、「頑張ってコードを書く」という単純なものではないと思っています。 職種に関わらず、プロダクトに関わる人全員を巻き込んで進めていくのはエンジニアだけで進めたときに見えないものが見えるので非常に面白いです。

会計フリー Public API史上初の新バージョン移行を完遂しました

こんにちは、freeeのPublic APIチームでエンジニアをしているまっつーです

花粉症ですごい鼻水が出るので少しくらい体重落ちてるんじゃないかと期待してます

去年の6月15日、会計freeeのPublic APIは新バージョンを公開しました

developer.freee.co.jp

この新バージョンでは約30個の破壊的変更を含んでいます

そして去年の12月、会計freeeのPublic APIは半年間の並行運用期間を経て、新バージョンへの完全移行を達成しました

この記事では後方互換性を保ち、既存ユーザーに影響を与えないことと、APIの負債を解消しより使いやすいAPIへと進化させることを両立するために、どのように工夫して進めたのかをお伝えしたいと思います

破壊的変更とは

Public APIはそれを使って開発や業務を行っている方がいるため、変更する時には後方互換性を担保しすべての利用者の動作に影響がないように行わなければなりません

しかし、会計freeeの機能拡充による変化や、過去に作った仕様が今現在では最適なものとは言えなくなくってしまったなどの理由から、後方互換性を担保しない変更を行わざるを得ない場合があります

freeeの場合はPublic APIを利用してアプリを作成しfreeeアプリストアに公開している開発者もいるので、後方互換性がない (今まで通りのリクエストを送信しても返ってくるレスポンスが異なる)ということは公開しているアプリが突然動かなくなるという事態につながります

この後方互換性を担保しない変更を破壊的変更と呼び、破壊的変更を実現するためにPublic APIでは並行運用期間を設けるという方法が取られることが多いです

また、上で述べたようにPublic APIはそれを使ってアプリを公開している開発者もいるので、新バージョンの公開には外部との連絡、連携が必須です

開発者には並行運用期間中に、利用しているAPIのバージョン移行をしてもらう必要があります

外部とのコミュニーケーションについては同じAPIチームでディベロッパーリレーションを担当しているニックさんが記事を書いてくれているので、ぜひそちらも読んでみてください

https://developers.freee.co.jp/entry/how-to-make-a-communication-plan

新バージョン移行への流れ

2020年1月頃: 変更点のスコープ整理とversioningの方法の検討

新バージョン公開の半年前からプロジェクトはスタートしました

目標を設定する

まず、今回の新バージョン公開で実現したいこと (目標)を決めました

以下の2点です

  • Public API Releaseからここまでのフィードバックおよび利用しにくい個所の改善(レスポンスの構造が他と異なる、freeeの権限がうまく効いていないAPIの改修など)を行い、開発者が速く安く手戻りなく作れるおよび使いやすいAPIになっている

  • インパクトを受けないアプリは改修アクションを行わなくても新しいバージョンに移行ができる(特定の日をもって自動切り替え)

スコープを整理する

次に新バージョンに盛り込みたい破壊的変更リストの整理を行いました

それまでユーザーからフィードバックをもらっていたものをメインに、具体的にどのエンドポイントのどこをどう直すかという点を確定していきました

新バージョンの表現方法、指定方法を決める

新バージョンを公開するにあたって

  • バージョニングポリシーをどうするか
  • バージョン指定方法をどうするか

という問題がありました

前提として、それまで会計freeeのPublic APIはバージョンいくつとはリファレンス上で明記しておらず、pathは api/1/{リソース名} となっていて「バージョン1 っぽいけどどこにも書いていない」という状態でした

バージョニングポリシーをどうするか

  • 案1 incrementalに増やしていき、次の新バージョンをv2とする

    • 現在 api/1 というpathになっているので旧バージョンをv1、新バージョンをv2、今後リリースされるものはv3とincrementalに増やしていく案
    • TwitterのAPIはこの手法をとっている
    • 良い点: 直感的にわかりやすい
    • 悪い点: バージョンの指定方法についての部分でも触れるが、バージョン指定方法をpath以外にした時、pathは /1 だけどバージョンはv2という状況がおこる。一方バージョン指定方法をpathで指定する (新バージョンのpathを /api/2 とする)と全てのAPIが新バージョン移行対象となり、既存で動いている全アプリでエンドポイント移行が必要になり、目標の2つ目が達成できなくなる
  • 案2 日付で表現

    • 新バージョンのリリース日をバージョン名とする案
    • StripeのAPIはこの手法を取っている
    • 良い点: pathが api/1 の状態を維持したまま新しいバージョンのリリースが出来る
    • 悪い点: 良い点と表裏一体だが、バージョン指定方法をpath以外にした場合、api/1 というpathのまま今後バージョンを上げていくことになる

バージョン指定方法をどうするか

  • 案1 pathで表現

    • 現在 api/1 となっている1の部分を新しいバージョン名に変える案
    • 良い点: ユーザーからするとどのバージョンのAPIを使っているかわかりやすい
    • 悪い点: 新バージョンで変更が加わるAPIを使っていないユーザーにも影響がある。内部的にも仕様変更がない部分は別々のパスからくるリクエストを同じコードで処理するなど複雑さが増す
  • 案2 アプリ管理画面から指定

    • freeeのAPIはアプリを作成してアクセストークンを取るので、アプリ管理画面で利用するAPIのバージョンを切り替える案
    • 良い点: 画面から決めることが出来るので設定が容易
    • 悪い点: UIが必要なので他の案より工数が多くかかる
  • 案3 ヘッダーで指定

    • 新バージョンを識別するX-Api-Version のようなカスタムヘッダーを用意して、ヘッダーがある時は新バージョン、ない時は旧バージョンの動きをする案
    • 良い点: 実装は比較的容易
    • 悪い点: バージョンの指定に多少の技術的なスキルが必要。freeeのAPI利用ユーザーにはエンジニアでは無い会計士さんのような方もいるのでこの点は意識して議論しました

結論 目標を考慮して、インパクトを受けないアプリは改修アクションを行わなくても新しいバージョンに移行ができるために、バージョニングポリシーについては案2の日付でのバージョン表現、バージョン指定方法は案3のヘッダー指定にし、リリース後様子を見てアプリ管理画面での指定の実装も検討するという結論になりました

(リリース後、既存アプリケーション開発者による移行状況から、headerでの指定による手段で移行要件が満たせていることがわかり、今回はにアプリ管理画面でバージョン指定ができるようにする実装は見送りました)

2020年3月頃: 新バージョンリリースに向けたリリースプランニング

実現方法が明確になったので、2月あたりからリリースに向けたプランニングを行いました

とりあえず大まかにどれくらいかかりそうかという見積もりを行い、PMやビジネス側のメンバーとも話し合ってリリース日を2020年6月15日に決定しました

この時点で新バージョンが Version: 2020-06-15 に決定しました

現在公開されている会計freeeのPublic APIのリファレンスにも大きくバージョン名が記載されています

会計freeePublic APIリファレンスのスクリーンショット。一番上に会計APIリファレンス Version: 2020-06-15と記載されている

2020年4月頃: バージョン切り替えの仕組み、新旧両バージョンでrequest validationを行うための実装

バージョン切り替えの仕組みの実装

4月頃から実装を開始しました

まずポイントになったのが「ソースコード上どこで新旧どちらのバージョンを指定してリクエストしてきたかを判別するか」です

前提として、会計freeeはRuby on Railsを利用しています 話し合った結果、もともと会計freeeに導入されていたrequest_storeというgemを利用することにしました

https://github.com/steveklabnik/request_store

簡単に説明すると、request_storeを使うことでrequestごとにglobalな変数を設定することができます

新バージョンを利用する際には X-Api-Version: 2020-06-15 をつけてもらう仕様としたので

requestが送信されるたびに、request_storeで

  • headerがあれば新バージョン

  • headerがなければ旧バージョン

であることを表す値を version という変数に代入します

これを各controllerやserializerなどで参照することで、新旧どちらのバージョンの挙動にするかを判定できるようにしました

新旧両バージョンでrequest validationを行うための実装

会計freeeのPublic APIではcommitteeというgemを利用してrequest validationを行っています

https://github.com/interagent/committee

このgemはOpenAPI Specificationに準拠したschemaを読み込ませることで、schemaにあわせたvalidationを行ってくれるものです

committeeは以下のようなやり方でschemaをしていた上でRackに入れて使用します

use Committee::Middleware::RequestValidation, schema_path: 'docs/schema.json', coerce_date_times: true

ただ複数のスキーマを読み込めるような仕様にはなっていないのでそのままでは新旧両バージョンでvalidationを行うことができませんでした

チーム内で相談した結果、RequestValidation層を2層挟み、またスキーマバージョンを判定する変数を渡せるようにしました

それぞれの層で上で書いたversionという変数を参照し、自らの対象バージョンでなければそのまま下位のRack層にrequestを流す方法を取りました

use Committee::Middleware::RequestValidation, schema_path: 'docs/old_schema.json', pubilc_api_version: 'v1'
use Committee::Middleware::RequestValidation, schema_path: 'docs/old_schema.json', pubilc_api_version: 'v2020-06-15'

このようにしてどちらのバージョンでもrequest validationを行えるようにしました

2020年5, 6月頃: 実際の破壊的変更対応を実装

バージョンを判定することができるようになったので、あとは 1月に決めたスコープの破壊的変更をガシガシと実装していきました

ただものによっては仕様が複雑でスッと実現できないものも多くありました

APIチームはエンジニア5人ほどで会計、人事労務の全エンドポイントを担当しているので全てのAPIを完全に把握するのは正直不可能です

そもそもこれは会計ソフトとして正しいんだっけ?みたいな部分はドメインロジックを担当しているチームに相談しながら実装を進めていきました

2020年6月15日: 新バージョンリリース!!!!!

バージョン名に日付が入っているので遅れると相当カッコわるいぞというプレッシャーがありましたがなんとか間に合わせることができました

並行運用期間

6月から12月までの並行運用期間は大きな出来事はありませんでしたが以下のことには気をつけていました

  • 細かな修正があったときに忘れずにAPIリファレンス含め、新旧両バージョン変更を加えること

あたりまえなんですが地味に見落としが多く、僕自身もプルリクエストのレビュー時に何度も指摘し、された覚えがあります

たった2つのバージョンを並行運用していても意識から漏れてしまうことがあったので、複数バージョンサポートとなった場合なにかしらの仕組みで自動で反映されないと厳しそうだなと感じました

また、この期間エンジニアはあまりやることはなかったですがビジネス側のメンバーはいろいろと働きかけてくれていました

  • 移行対象のエンドポイントのrequest数を確認して移行状況のチェック
  • freeeのdeveloper community参加者への全体連絡
  • freeeアプリストアに公開されているアプリのうち、移行対象のエンドポイントをつかっているアプリのオーナーに対して別で連絡

12月に無事旧バージョンのサポート廃止ができたのは間違いなくビジネス側のメンバーのおかげです

APIの新バージョンはエンジニア、ビジネス全員が一丸となって取り組まないと実現できないんだなと身をもって感じました

以上のことを乗り越えて、会計freeeのPubilc APIは現在新バージョンで稼働しています

興味のあるかたはぜひdeveloper siteから確認してAPI callしてみてください

freee Developers Community | freee Developers Community

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

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

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

developers.freee.co.jp

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

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

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

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

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

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

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

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

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

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

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

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

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

Remo上でのモブプロ風景
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コール数の推移

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

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

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

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

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

最後に

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