【連載 第4回】freeeカード Unlimited でのClean Architecture実践

こんにちは、金融チームでエンジニアをしているlvmingbeiです。この記事はfreeeカード Unlimited の開発の裏側について紹介する連載の第4回目になります。

この記事では、freeeカード Unlimitedの開発でClean Architectureを導入して学んだことをシェアできればと思います。

第1回~第3回の連載記事は以下のリンクでご覧ください。

Clean Architectureの概要

Clean ArchitectureはRobert C. Martinが提唱し、関心の分離、疎結合を提供するアーキテクチャパターンです。

以下の図がとても有名で、ご覧になった方が多いと思います。

f:id:lvmingbei:20210920182759j:plain

Clean Architectureは同心円上に広がるレイヤーがあり、外側が内側に依存するということをルールとしています。つまり内側のレイヤーのソフトウェアコンポーネントは、外側のレイヤーについて何も知らないということを保証します。逆にレイヤーについて方針はあるものの、種類や数について制限しておらず、右下のレイヤー間の依存の方法も一つの例として挙げられているだけです。

Clean Architectureを利用することで、以下の問題を解決します。(原文から翻訳)

  • フレームワーク独立。 アーキテクチャは、ソフトウェアやライブラリに依存しません。

  • テスト可能。 ビジネスルールは、UI、データベース、Webサーバー、またはその他の外部要素なしでテストできます。

  • UI独立。 ビジネスルールを変更せずに、UIを置き換えることができます。

  • データベース独立。 OracleまたはSQLServerを、Mongo、BigTable、CouchDBなどに交換できます。 ビジネスルールはデータベースに拘束されていません。

達成したいこと

freeeカード UnlimitedはClean Architectureの採用にあたって、以下の項目を達成することを目標にしています。

  • 変化に強い設計
    • freeeカード Unlimitedは多数外部サービスに依存しているため、外部サービスの仕様が変わっても、コアとなるビジネスロジックは影響されないように設計しなければならない。
    • プロダクトの各フェーズでは、ユーザーに提供している機能が大きく変わるので、機能追加しやすい設計をしなければならない。
  • 再利用性の高い設計
    • コードの再利用により、重複な機能排除ができ、修正漏れをなくす。
    • テストの負担軽減。
  • メンテナンスが容易になる
    • 障害が発生した場合にできるだけ早くメンテナンスを完了させる。
  • テストが容易になる
    • 決済サービスであり、お客様の財産を守るため、より一層の品質向上が必要、テストを大事にする。
    • レイヤーごとテストができるようにする。

プロジェクトの構成

freeeカード Unlimitedは上記の画像と同じ構造にしており、Enterprise Business Rules、Application Business Rules、Interface Adapters、Frameworks and Driversの4つのレイヤーに分けられています。

レイヤー名 職責 パッケージ名
Enterprise Business Rules エンティティは包括的で重要なビジネスルールを隠蔽化したオブジェクトを含むレイヤーです。最も内側に位置するように他のレイヤーの変更を受けない核心の部分です。 domain
Application Business Rules 固有のビジネスルールを含むレイヤーです。ここでは、ドメインのエンティティを利用し、アプリケーションの機能を実現するためのメイン実装になります。 usecase
Interface Adapters 入力のバリデーションや、データベースのORMや、画面の表示用データ変換などはここで記述します。 controller, repository, rpc, client
Frameworks and Drivers データベースやフレームワークなどの設定が含まれます。このレイヤーは全ての詳細が含まれておりどこからも依存されません。 database, config

パッケージの依存関係

f:id:lvmingbei:20210927141524p:plain

依存性逆転の原則

freeeカード Unlimitedは「抽象に依存せよ」の原則に従って実装しました。すべてのレイヤーは「抽象」に依存してます。

具体的には、上位レイヤーは下位レイヤーの実体に依存せずに上位レイヤーで宣言した抽象に依存するようにしています。 下位レイヤーは上位が宣言したインターフェースを依存するので上位レイヤーは下位レイヤーに依存しなくなり、つまり、上位レイヤーは下位レイヤーの知識を持たなくなります。 そうすると、上下位のレイヤー両方は「抽象」に依存するようになります。下位レイヤーを変更しても上位レイヤーがその影響を受けなくなります。髪の毛一本引っ張ると,体全体が動くようなことを避けることができます。

実装例として、以下の図をご覧ください。 ControllerはIUsecaseのインターフェースに依存して、IUsecaseの実装となるUsecaseはIRepositoryのインターフェースに依存しています。

f:id:lvmingbei:20210923150200p:plain

依存性の注入

前のセクションで記述したように、各レイヤーはインターフェースなどの抽象を依存しているので、実現するにはDI(Dependency Injection, 依存性の注入)が必須条件になります。DIにより煩雑な初期化処理を解決するためには、DIライブラリの利用することが必要です。

JavaにはSpringというDIコンテナがとても有名ですが、GoのDIライブラリは、uber digや、google wireなども多数があります。その中にgoogle wireが利用者が一番多いと思われ、freee社内はwireを導入しているので、freeeカード Unlimitedはgoogle wireを選定しました。

開発者はインターフェースと注入したい構造体を指定して、wireはgo generateを利用して、初期化処理をコードを生成します。

WireでCardControllerをインスタンス化する実装例は以下となります。

package controller

var Set = wire.NewSet(
    NewCardController,
    wire.Bind(new(ICardUsecase), new(*usecase.Card)),
    usecase.NewCard,
)

type CardController struct {
    cardUsecase ICardUsecase
}

type ICardUsecase interface {
    FindCard(ctx context.Context, ID int64) (*domain.Card, error)
}

func NewCardController(cu ICardUsecase) *Server {
    return &Server{cardUsecase: cu}
}

package usecase

type Card struct {}
func (u *Card) FindCard(ctx context.Context, id int64) (*domain.Card, error) {...}

単一責任の原則

freeeカード Unlimitedでは、Usecaseはdomainのentityごとに分かれています。Usecaseは該当するentity以外のものを操作するのを極力避けています。

したがって、Usecase職責が明確になり、機能変更の影響を特定の部分に封じ込めて、他のUsecaseに影響を与えないロバストな構造にすることが出来ます。

f:id:lvmingbei:20210924160155p:plain

インターフェース分離の原則

インターフェースの利用者にとって不要なメソッドに依存させてはいけないというルールです。 このルールに従って、Usecaseは自分に必要なインタフェースのみを知ることができるようになっています。他のUsecaseの変更の影響を最小限に抑えることが出来ます。

IRepositoryインターフェースの実装となるDBHandlerはICardRepositoryやICompanyRepositoryなど複数のRepositoryインターフェースを実装していますが、Usecase側は依存しているインターフェース以外のメソッドが利用できないです。例えば、CardUsecaseはFindCard()だけが利用できます。

f:id:lvmingbei:20210923151510p:plain

感想

freeeカード UnlimitedではClean Architectureを基本的には採用していますが、実際の状況により、一部妥協したり、変更したりすることもあります。

良かった点

テストが書きやすくなりました。MockObjectを利用して、レイヤーごとテストができるようになりました。コードの品質向上ができたと思います。

また、インターフェースに対してプログラミングすることで、実装を変えても、他のレイヤーのビジネスロジックに影響しないようになりました。

インターフェースが分離しているため、各Usecaseの責務が明確になっており、機能変更と追加する時にどこを変更すべきか、またバグが発生した時にどこをチェックすべきかが判断しやすくなります。

改善したい点

インターフェースに対してのプログラミングすることになるのですが、開発の初期段階でインターフェースを全部洗い出すのは難しく、考慮が足りないこともあります。実装しながら、インターフェースの宣言を変更したり追加したりする頻度も高いです。インターフェースの変更と伴い、依存しているレイヤーの修正も発生しています。

Google Wire使ってセットアップしているので、プロジェクトの規模が大きくなると、各package毎にProvider Setを用意する必要があり、コードの構造が分かりづらくなります。DI未経験者には、学習コストが高いかもしれません。あと、新しい実装を追加する時、また依存関係を変更する時、初期化コードを作り直すことが忘れがちです。

次回

次の連載記事は、freeeカード Unlimited の開発序盤に金融チームに配属された新卒のsekkyくんの「新卒一年目からの新規プロダクト開発」になります!


金融チームでは、一緒に「freeeカード Unlimited」を開発する仲間を募集しています。 ベンチャー企業であるfreeeの中でも更にスタートアップ色が強い金融チームで、スモールビジネスの資金繰りにイノベーションを起こしましょう! https://freeecommunity.force.com/jobs/s/detail/a4l2r000000CaUpAAK

失敗して攻め続けるために - freeeのエンジニアが障害対応で実践していること

2015年10月入社でコアエンジンチームの@kompiroと申します。普段は下記の3つの業務に従事しています。

  • お客様が自社の情報を把握するためのデータアグリゲーション機能の開発
  • マイクロサービスに切り出したデータアグリゲーション機能をEKSに移行
  • チーム横断で開発者のみんなが開発しやすい環境の構築

そんな私ですが、最近しくじり開拓者のつどいという社内イベントを開催しています。これは障害対応の一環として始めたイベントです。今日はしくじり開拓者のつどいというイベントをみなさまに紹介するとともに、背景となる障害に対する考え方と障害対応の流れを解説します!

freeeの開発文化と障害対応

freeeの開発文化
freeeの開発文化

こちら弊社の紹介スライドからの引用です。

freeeのエンジニアチームが大切にする開発文化が言語化されたものが

  • 失敗して攻めよう
  • 何でもやれる、何でもやる
  • 必殺技
  • カッとしてシュッとやる
  • 世話を焼いていくスタイル

です。この中でも「失敗して攻めよう」は私が入社した6年前から言語化されています。その本文は「学びのある失敗をして最速で成長しよう。学びのある失敗とはチームやプロダクトの成長につながる失敗。学びのある失敗をしていないのは挑戦が足りない。」です。

そのため、障害を起こしたからといって怒られたりすることはありません。しかし、お客様に迷惑をかけているので、できる限り迅速な対応が求められます。

障害発生に作成する障害報とエンジニアのうごき

障害が発生したときの流れを簡単にご説明します。まず、障害を見つけたら「障害対応するぞ」とSlackにメッセージを入れます。すると、障害報を作成するためのGoogleFormへのリンクが表示されます。

障害対応するぞ
障害対応するぞ

実際のフォームはこういう形になっています。

インシデント/障害速報フォーム
インシデント/障害速報フォーム

このフォームに必要事項を入力すると、

  • 障害報GoogleDocを作成
  • 障害報のリンクと障害対応を行っているGoogle meetのURLが書かれたアラートを飛ばす

アラートの内容はこんな感じです。

障害報アラート
障害報アラート

障害報のアラートを見たエンジニアは、障害の内容をみて必要に応じて障害対応に参加します。

一定以上の規模の障害の場合、速やかにユーザーへのアナウンスが必要です。サービスのstatus更新SNSへの発信、社内の他のエンジニアだけでなく、実際にユーザーからお問い合わせがくるカスタマーサポートチームやセールスチームへの情報共有などが必要です。しかし、障害が発生したチームは原因調査及び復旧を可及的速やかに行うことに集中すべきです。障害発生してるチームが障害対応を速やかに行えるよう、支援するチームがあります。

我々はこの障害対応支援チームのことを「鬼殺隊」と呼んでいます。鬼殺隊の由来はご存じ鬼滅の刃です。障害を鬼に見立てたのと、ちょうど鬼滅の刃のアニメ1期がTVで放映されていたころにこのチームが発足したので名づけられました。アニメ2期楽しみですね。

障害解決と障害からの学びを支援する鬼殺隊

鬼殺隊は速やかに障害に対応することを支援する、数名の有志のエンジニアチームです。曜日ごとに担当が決まっており、一定以上の規模の障害があるとその障害対応に必ず参加することになっています。障害発生しているチームの手が回っていないところを支援するように動きます。

例えば、鬼殺隊のメンバーは障害対応中下記のような活動を行います。

  • 他のチームに状況共有するために定期的に障害の状況を3行程度にまとめてアナウンスする
  • 障害報に影響ユーザー数が書かれていないなど、記載漏れがある場合は障害発生チームに伝える
  • 障害対応後に義務付けられている障害のふりかえりが実施されていない場合は障害発生チームにアナウンスする

鬼殺隊のメンバーは、役割上、普段触らないサービスの障害対応に入ることが多く、鬼殺隊活動は、他のチームでどう障害対応をしているのかを学ぶ場になっています。毎週鬼殺隊のメンバーは集まって障害対応自体をふりかえったり、今後の障害対応を改善するにはどうしたらいいかを話し合っています。しくじり開拓者のつどいはこの鬼殺隊の障害対応の改善の話し合いで生まれました。(注: 鬼殺隊は任期があるため、現在は私は鬼殺隊のメンバーではありません。)

「失敗して攻めよう」と言われても、好んで失敗したい人はいない

障害対応の流れをまとめてみました。障害対応にかかわる人は少なくない人が動くこともあり、好き好んで発生させたい人は皆無です。どうすれば障害の発生を少なくしたり、速く対応できるようになるのでしょうか?

一番良いことは障害に学び、繰り返さないことです。障害から学ぶ場があれば、

  • 最近他のチームで起きた障害とその傾向を把握できる場を設けたい。(例: マイクロサービス化が進んだため、ネットワークでのトラブルが増えている)そうすることで、自チームで同じ障害を起こさないようにレビューで指摘できる人が増えるはず。
  • 経験豊富な中途入社の方でも入社が最近の場合、freeeで過去、どんな障害が起きたのか、ご存じないはずです。どういったポイントが障害になりやすいか、学ぶ機会を設けたい。(例: freee特有のSPOFになりやすいポイントがどこか)そうすることで前職の経験を活かしてfreeeのサービスを改善することもできるはず。 障害対応に参加したメンバーにとって、障害対応自体が学ぶ場になっています。学んだ内容を言語化し、共有する場を設けたい。
  • そうすることで学びを促進して障害自体を減らしたり、同様の障害が起きた時に過去の学びを想起し、速やかに対応できる人が増えるはず。言い換えると、「世話を焼いていくスタイル」を実践できる人を増やしたい。

こういう狙いで始めたのがしくじり開拓者のつどいです。

しくじり開拓者のつどいとは?

しくじり開拓者のつどいは障害からの学びを共有する場です。ランチタイムにやることもあれば、夜にお酒を飲みながらやることもあります。(発表者もお酒を飲みながらです)参加者はラジオ感覚で気軽に聞けるよう、笑いを大事にしています。参加感を大事にするために、できればカメラONを推奨していますし、障害からの学びを深めるため、何かわからないこと、気になることがあればマイクをONにして質問したり、提案したりできます。参加者も障害から少しでも学びを深めたいので、freeeの社内にいる人であればどなたでも参加できます。専用のSlackチャンネルでにぎやかすことも推奨してますし、Meetのチャットも開放しています。障害から真摯に学ぶ場。それがしくじり開拓者のつどいです。

しくじり開拓者のつどいに至るしくじり

実はfreeeでは以前「失敗.js」と呼ばれる開発における失敗談共有のイベントがありました。このイベントは下記の構造を持っていました。

  • 失敗.jsが開催される前月に一定以上の障害を起こした人が発表することになっていた
  • 発表者と聴講者に分かれていた

障害を起こした人が発表していたことから、どうしても後悔の気持ちが前に出てきて重い雰囲気になりがちでした。また、聴講者から質問しようにも責めている雰囲気になりがちでした。「失敗.js」では誰も笑う人のいない、お通夜や裁判のような重苦しい場になっていたのです。これでは学びの場にすることができず、続けられませんでした。 とはいえ、失敗から学ぶことは大事です。何かいいものはないかと探してみると、TV番組に「しくじり先生」があるじゃないですか。障害自体を「しくじり」と表現し、TVのように笑いのある場にすればよりよい学びの場にできないか、という仮説の基、4月に私が発表者として障害からの学びを共有する「しくじり先生」を開催しました。

やってみた私の感想ですが、一方的に私が学びを共有する場になってしまいました。参加者からの質問だったり、提案だったり、学びの共有が難しく感じました。自分のMC力のなさが大きな要因の一つですが、「先生」という名前だと「先生と生徒」という構造になってしまうのだろうと気づきました。

「先生」という名前だと一方的に話す感が強かった
「先生」という名前だと一方的に話す感が強かった

より深い学びの場とするために、いわゆる「問題vs私たち」の構造にしたい。

問題vs私たち
問題vs私たち

みんなが障害という問題に向き合い、解決策についてワイワイ話す場にする。そうすることで障害をおこさないこと、及び障害が起きても最速で復旧することにフォーカスできる、強いチームを目指しています。

そうなるように改名したのが「しくじり開拓者のつどい」です。「開拓者」の由来は、新大陸上陸後の開拓から来ています。freeeでは海モチーフの名前を付けることが多く、新しいサービスを立ち上げること(市場を見つけること)を「新しい大陸を見つける」と表現したりします。我々エンジニアは新大陸を開発する開拓者、というわけです。 freeeの開発文化の一つ「失敗して攻めよう」を大事にすれば大事にするほど、freeeのエンジニアはしくじることが増えていくはずです。個人的にゆくゆくは「しくじり開拓者のつどい」ではなく、「開拓者のつどい」という名前になり、よりカジュアルに各々のしくじりを話し合い、しくじりからの学びを深める場にしていけたら、と思っています。

いつかは開拓者のつどいに
いつかは開拓者のつどいに

こういったfreeeの開発文化に興味を持っていただいた方は、よかったらカジュアル面談に話を聞きに来てください。一緒に成長していきましょう。

【連載 第3回】EMから再度エンジニアとしてプロダクト開発に挑戦して学んだこと

こんにちは、freeeの金融チームでエンジニアをしているtabachainです。この記事はfreeeカード Unlimited の開発の裏側を紹介する連載の第3回目の記事になります。

この記事では、エンジニアリングマネージャー(以下EM)からエンジニアにロールチェンジして新規プロダクト開発に当たった私の経験を元に、そこから感じたことや学んだことをシェアできればと思います。

軽くfreeeでの自分の経歴を紹介すると、

  • 2016年7月にエンジニアとして入社

  • 2018年7月にfreee申告開発チームでEMにロールチェンジ

  • 2020年12月に金融チームで再度エンジニアに戻りfreee カード Unlimitedを開発

という流れになります。

そういえば、エンジニア => EM の方向へのロールチェンジに関しては、最近

tech.asken.inc

の記事が話題になっていましたね。

本記事ではその逆の方向となるEM => エンジニア という方向のロールチェンジをした際に自分が感じた不安やその解消の流れを説明しようと思っていて、そこでの苦労や経験してみて実際どうだったかというのをできるだけ包み隠さず話せればと思います。

EMのマネジメントの定義と自分のスタイル

エンジニアになっての話に入る前に、EMと言っても人によってスタイルがあり、それによってエンジニアに戻った際に苦労を感じる点が違うと思われるのでそこの話に触れようと思います。 EMが行うマネジメントはいろいろな種類がありますが、個人的には

qiita.com

での整理である

  • ピープルマネジメント

  • テクノロジーマネジメント

  • プロジェクトマネジメント

  • プロダクトマネジメント

の4つの切り分け方が気に入っていて自分もこの分け方をして考えています。 この4つのマネジメントはEMが全部やるというよりは、PM、 EM、エンジニアが分担していることが多いかと思います。 私はEMになったとき、まず弱めの定義であるピープルマネジメントから入り、そこを中心にしつつも自分の領域を状況によって広げたり移したりしながらマネジメントを行っているようなスタイルだったと思います。 上記記事の画像を用いると以下のようなイメージです。

自分がエンジニアに戻った目的

私はEMとしてはピープルマネジメントを中心にしていくことが多かったのですが、逆にそれ以外のマネジメント部分はPMやメンバーのエンジニアに支えられているという面も多かったです。とくにテクノロジーマネジメントに関しては、EMというロールになったからといってやればすぐできるかというと全くそんなことはなく、エンジニアのときにどれだけ経験をつめたかというバックグラウンドの影響が大きい領域だと感じることが多かったです。 イメージでいうと以下のようにしたかったのですが、なかなかうまくいかずメンバーに助けらている感覚がありました。

f:id:tabachain:20210917145039p:plain
EMの時の状況

EMになってもマネジメントもしつつコードもバリバリ書いて技術力も上げていくようなスーパーマンをできれば目指したかったのですが、スイッチングコストが大きくそれができない自分がいて葛藤することもありました。

そんな状況を知ってか知らずか、当時の自分のマネージャーから「新規事業でエンジニアに戻るチャンスがあるよ」と教えてもらったのが去年の10月くらいだったかと思います。 ピープルマネジメントにほぼ全振してしまっていた自覚があったので、エンジニアに戻る心理的ハードルは自分の中では相当に高まっていて、一週間回答を先延ばしにしてもらいつつ断り方を考えていました。

ただそうしているうちにマネージャーというロールに固執している自分や、マネージャーとしてしか成果を出せないというのは思い込みなのではないかという気持ちも出てきて、現状維持バイアスから抜け出すためにもエンジニアに戻ることに次の日には決めていました。EMとしての自分が弱みとしていたテクノロジーマネジメントができるエンジニアリング経験をつむには、マネージャーという肩書きをなくしてしまったがむしろ早い、という思いもあったと思います。

エンジニアに戻っての苦労

そのような経緯でエンジニアになったのですが、ロールチェンジをした後は変化に慣れるまでに三ヶ月くらいはかかりました。外からみると早いと言われることも多いですが、自分の中では結構かかったなと思います。

特に苦しんだのは、EMの時と同じような方法で成果やチームへの貢献ができなくなる自分を、一時的に認めることだったと思います。それは同時にエンジニアになった理由や純粋にエンジニアリングを楽しむ障壁になった時期でした。 チームへの貢献やチームとして成果をあげることがEMの醍醐味であり、やりがいでもあったため、一度ロールを変えたら同じやり方では成果をあげることは難しかったです。異動後のチームにはEMがいるため、マネジメント力で成果を上げようとするとコンフリクトしてしまい自分のリソースを有効活用しているとはいえない、きびしくいうと自己満足のような状態になっていたと思います。

転機

そのような状況の中、マネージャーやメンバーとの1on1でもいい気づきをもらうことが多かったです。一番の気づきになったのは、最初にあげた、"なぜエンジニアはマネージャーになるのに不安を覚えるのか"の記事の著者でありエンジニアリングマネージャー時代からコーチングの壁うちあいてになっていたyasunishiさんの「すぐに成果を出そうとしすぎていないか」という言葉でした。

その言葉をきっかけに、マネージャーの時のスキルを使ってすぐに成果を出そうとするのでなくエンジニアとしての新たな成果の出し方を重視することができました。さらにはマネージャーになる前の自分には無かった、マネージャーを経験したからこそできるエンジニアとしての成果の出し方ができるようになったと思います。

マネージャーを経験したからこそできるようになったこと

エンジニアとしての自分に非連続的な変化を引き起こしやすくなった

freeeでは、1on1でメンバーと向き合う機会が多くあります。EMとしてメンバーの成長をサポートしていく中で、エンジニアとして伸びる人にはあり、自分にはなかった考え方や癖などに気づくことができました。エンジニアとして他者の良い点を真似していくことで、エンジニアとして続けていたときには無かったような非連続的な変化が自分の中で生まれたと思います。

「成果」の主語が広がった

EMになる前は成果は自分一人がエンジニアとして出すものを成果として捉えていました。EMとしてチームで成果を出すと考える癖がついた後は「成果」の主語が広がったと思いました。freee カード Unlimitedではモノレポやマイクロサービスの本格導入などエンジニアだけでなくQAも新しい挑戦をしないとリリースに漕ぎ着けられない環境でした。そういう中でQA工程も含めて全体最適な開発は何かを考えながら開発をしていた自分がいました。

チームの弱み、強みがわかるようになった

EMの時に他のEMから話を聞いたり、評価のすり合わせで他チームのメンバーの活躍を聞いたりしていたことで、他のチームの強みや、そもそも強いチームとはどういうことができているかという基準が言語化していないまでも無意識に自分の中にできていました。そのため、新しいチームでもチーム全体としてどこに弱みがあって、どこに強みがあるかがわかり、穴がある場所を自分がフォローする動きや、どのスキルを付ければチームに貢献し成果につなげられるかということがわかりやすかったと思います。

テクノロジーマネジメントをやり始めた

EMを経験する前は、どうしても自分より技術力や経験にまさるエンジニアの意見に対しては受け身になってしまうことがあったのですが、EMを経験してfreee カード Unlimitedの開発にエンジニアとして入った後は、(新規事業で新しいことをやりやすい状況だったからというのもありますが)マイクロサービスで作る際に他社の開発手法などを調査し、モノレポを導入する方が開発がスムーズになるのでないかと感じて結果としてチームを動かしている自分がいました。これは元の自分にはなかった動きで、EMの時に培った、将来的な開発チームの状態を想像する力とリスク管理の癖が起こした動きだったと思います。 また、EM経験前はスクラムで自分が技術系のチケットを切って開発計画に入れ込む際の優先度などの判断が難しかったため、技術系のチケットを切ること自体そこまで多くなかったのですが、現在はEMとエンジニアの両方のバックグラウンドがあることで中長期的な改善につながる技術系のチケットは率先して切り、プランニング等でチームに説明し計画に入れるようなことも増えたように思います。

最後に

エンジニア => EM => エンジニアというのを同じ会社で経験するのは、なかなか無いと思いますが、自分としては大きな気づきと学びがあり経験できて良かったと思っています。 また、この経験を元にfreee カード Unlimitedをよりよいプロダクトにしていくためにより強いエンジニアになっていこうと思っています。

次の連載記事は、freeeカード Unlimited の開発序盤にjoinした id:lvmingbei さんの「freeeカード Unlimitedでのクリーンアーキテクチャ実践」になります!


金融チームでは、一緒に「freeeカード Unlimited」を開発する仲間を募集しています。 ベンチャー企業であるfreeeの中でも更にスタートアップ色が強い金融チームで、スモールビジネスの資金繰りにイノベーションを起こしましょう! https://freeecommunity.force.com/jobs/s/detail/a4l2r000000CaUpAAK

新アプリリリース!iOSエンジニアとWebエンジニアの融合

こんにちは、DevBrandingのellyです。9月3日に配信した「freee Tech Night 〜新アプリリリース!iOSエンジニアとWebエンジニアの融合」の様子をご紹介します。

freee では iOS エンジニアと Web エンジニアは基本的に別々のプロジェクトで業務を行うことが多いのですが、今回 freeeプロジェクト管理の iOS アプリの開発にあたり、2チームが密に連携を取ってプロジェクトを進めました。 今回は iOS エンジニアのiwadさんと Web エンジニアのtomozさんをゲストに招き、チーム融合でのプロジェクトの立ち上げからリリースまでの道のり、GraphQL・SwiftUI の採用などの技術的な新しいチャレンジについて話してもらいました。

登壇者集合写真
登壇者集合写真

iwad: 写真左上 2019年11月入社。制作会社や事業会社にてモバイルアプリ開発に従事。freeeではfreee会計やfreee人事労務のiOSアプリ開発を担当。

tomoz: 写真右上 2019年11月入社。freeeプロジェクト管理のWebエンジニア。Androidアプリ開発やFlutterを用いた開発も経験。

のぶじゃす (@noblejasper): 写真右下 ラジオパーソナリティ、2017年に中途入社mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。しゃべりたがり。声が大きい。

freeeプロジェクト管理のiOSアプリ開発は当初どのように進める予定だったのですか?

tomoz:最初はある程度きっかり役割分担するという方法を考えてました。どのようなWebサービスでもモバイルアプリを作りたいというニーズがある中で、モバイルチームのリソースにももちろん限りがあって作って欲しいとお願いすればできるものではないので、CI/CDのような共通でやっていかないといけない部分はお任せするけれども、それ以外の部分は自分たちで頑張って実装しようとしていました。

モバイルチームにはすでにリリースしているアプリケーションの機能開発もありますからね。モバイルチーム側はどのように受け止めていたんですか?

iwad:プロジェクト開始前は、モバイルチームが開発するというよりは Web開発チームが主体的に開発したいというお話だったので、どちらかというとサポート役に回る感じでしたね。どういった技術スタックで作るのか、GraphQLを使ってよいかといった大枠の方針について、聞かれたら答えるといった距離感でした。

tomoz:質問があれば答えてもらう、依頼があればやってもらうっていう関係性でしたね。

実際にスタートしてどうでしたか?

tomoz:やっぱりうまくいかなかったです。何がうまくいかなかったかというと、Web開発チーム側の僕たちは「モバイルチームには守って欲しいルールみたいなものがあるだろう」と思って、どうしてもお伺いをたてるような感じになってたんですよね。一方モバイルチームも、freeeプロジェクト管理というプロダクト自体を今まで触ったことがないので判断しかねるみたいなケースがいっぱいあって、お互いに気を使う状態に陥っていました。いろんなことを決めないといけない最初のフェーズで結構足踏みしてしまいました。

それだとスピードは遅くなりますよね。そこからどうやって変化させていったんですか?

tomoz:Web開発チームのほうからiwadさんに「一緒に開発してください、朝会もモブプロも一緒に動いてください」ってお願いして、生活を共にするぐらいの感覚で開発し始めたって感じですね。

iwad さんはお願いされてどう思いました?

iwad:そのほうがやりやすいという風に思ってましたし、自分のJM(ジャーマネ:freeeにおけるマネージャー)も同じ認識を持っていました。既存プロダクトのタスクも持ちながらサポートするような形でぬるっとスタートしたので、その話があってからは抱えていたモバイルチームの定例やタスクは一旦全部置いて、完全にfreeeプロジェクト管理の開発チームにジョインするイメージで取り組みました。

朝会やモブプロ、様々なMTGにどんどん入っていくようになって、良い成果は出始めましたか?

tomoz:そうですね、決めないといけないことが多くある中で、モバイルチームだけでやってたら、Web 開発チームだけでやってたらとなると、お互いの領域に対してある程度キャッチアップコストがかかっちゃうと思うんですよね。そうするとリリースの目標とそのコストを天秤にかけて、どうしても最低限動くようなものに落ち着いてしまいがちだと思うんですよ。今回モブプロとかであーだこーだ言いながら一緒にやることによって、モバイル開発の知識とのドメイン知識をその場で共有できてキャッチアップコストがかなり削られたと思います。それぞれ単体で動いていたらできなかっただろうなというプラスアルファの上積みもたくさんできて非常に良かったです。

登壇者写真
滑舌が良いtomozさん

スキルセットが違う人たちがお互いの知識を共有しながら進められたというのはモブプロの本質ですね。ビフォーアフターで明らかに良くなったものってありますか?

tomoz:明らかにというのは難しいですが、毎週スプリントレビューみたいな形でデモをしていたんですが、融合してからは1回動くものを作っちゃおうという感じで、決めることは決めながらも作れるものはどんどん作り切って、プロジェクトチーム全体の温度感・テンションを上げていくことができたと思います。

返事待ち、確認待ちがなくガンガン進められるのは本質的ですよね。融合によってプラスアルファでできたというのはどういうものですか?

tomoz: Web開発チーム側でいうと、社内的には一般的ではないんですがfreeeプロジェクト管理でGraphQLを使っている部分があって、今回モバイルチームでも使ってみようよということでラフに導入することができました。もうひとつは、アプリケーションアーキテクチャをちゃんと設計するのって慣れない人がやるとなかなかできないことだと思うんですが、今回iwadさんに入ってもらったことで、しっかり最初からMVVMのアーキテクチャを採用して設計することができました。一画面サンプルを用意して、Webエンジニアもそれに則ったものを作ればいいということが分かったので、統制が取れた状態で同じような形で実装ができたというのは大きかったです。

モバイルチーム側はどうですか?

iwad:社内アプリの共通基盤をfreeeプロジェクト管理にも同様に導入できたのは良かったです。あと、この開発と並行して、freeeのサービス の認証関連の機能をモジュール化して他のアプリにも導入できるような取り組みを行いました。昨今freeeの社内ではfreeeプロジェクト管理と同様にモバイルアプリのニーズが高まっていて、各モバイルアプリのUIや品質に一貫性を持たせることやレギュレーションの整備が喫緊の課題になっていて、今回その機能を共通化できたのは大きな一歩だったと思います。

登壇者写真
少し緊張気味のiwadさん

freeeプロジェクト管理のモバイルアプリ開発と同時に、既存の共通化の課題を一緒に片づけたんですね、すごい!技術的なチャレンジができたのには融合したこと以外にも何か理由はありますか?

tomoz:freeeプロジェクト管理が比較的新しいプロダクトだったことと、Web エンジニアが実装したという二点です。今回SwiftUIとCombineという iOS 標準のライブラリをフルに使って実装していて、対応OSも限られている状況で、それを仮にfreee会計でやろうとすると現状サポートしているものを切らないといけないみたいな議論になっちゃうと思うんですよね。ただ、今回は新しいものを作ろうとしていて本当にターゲットに届くのであればiOS 〇〇以降に限定していいよねと判断できました。もちろん投げやりな意思決定ではなくてちゃんとした根拠をもとに意思決定をしているわけですけれども、そういう技術的なチャレンジも含めた意思決定ができる状態だったというのはあります。もうひとつはWeb エンジニアだったからこそ、SwiftUIだろうがCombineだろうが、もともと知らないのでキャッチアップコストが変わらないんですよ。だからある意味踏ん切りがついたというのもあると思います。

iwadさんはどうですか?

iwad:似てると思いますが、新規開発というところ、既存のコードベースがないという状態だったのがチャレンジングに開発できた要因かと思います。新しいものだからこそ実際に実践で使えるかという観点も重要だと思いますし。

tomoz:もちろん同じアプリでチャレンジを続けていくことも必要だと思うんですけど、たまにまっさらな環境でやりたいってこともあると思うんですよね、人は(笑)

分かる(笑)それが既存のアプリとかにも還元されていくといいですね。逆に融合してイマイチだった、大変だったことってありますか?

tomoz:正直、融合してからはないです。ただ、今回運が良くて、実はWeb開発チームの中でiOSにかなり慣れている人がいたというのもあって、スムーズに進んだ部分はあると思います。なので雑にWebエンジニアをアサインしたらなんとかなるかっていうとそんなことはないんだろうなと思います。プロジェクトの進捗が想定通りに進まない可能性もあるので、PMやBizの関係者とも共有しながら合意を作るといったように、ちゃんとケアしてコミュニケーションをとるというのは注意点として必要だと思います。

そういう意味でも、がっつり入ってもらうところが大事になってくると思います。「サンプルだけ作ったのであとはこれ見ながらやればできると思います」みたいなことではなくて、一緒にやって不明点を随時聞きながら開発するという環境を用意すれば十分やっていけると思います。

今後のリリース以降の予定や課題はありますか?

tomoz:すでに微修正レベルでは小さいアップデートをしています。基本はWeb開発チームで完結する形で修正や機能追加をしていますが、もちろんモバイルチーム側から「こういう大規模な機能追加しませんか?」みたいな提案をもらうのも全然アリだと思うんですよね。だから今回どちらにも口を出せる関係性が築けたというのが大きいと思っています。モバイルチームはfreeeのアプリを横断で見てるので、全体のUI/UXとかを理解してるのってやっぱりモバイルチームだと思うんですよ。だからそういう人から意見を聞ける環境があるのはとてもいいですし、今後とも協力しながらやっていきたいなと思っています。

iwad:Web開発チームがアプリ開発できるようになって、ちょっと修正したいなという時にモバイルチーム待ちにならずに素早く対応できるようになったのは良かったと思います。一方で技術的な仕様の変更だったりAppleのレギュレーション・規約の改訂など開発を取り巻く外部要因が影響を及ぼすようなことも結構あると思うんですけど、そこはモバイルチーム発信でハンドリングして主体性持ってやっていきたいと思っています。

関係性が築けているのは理想的ですね。今後のさらなる進化も楽しみです!

イベントの本編はここまでです。この後は「アフタートーク」でより深い技術談議が繰り広げられました。

最後に

freeeではAndroid/iOSエンジニアを絶賛募集中です。 モバイルチームでは既存の大規模なプロジェクトの改善・グロースだけではなく、多様な事業領域からモバイルアプリの開発ニーズが高まっており、様々なフェーズの開発に取り組むことができます。プロジェクトの現状課題や事業価値を総合的に判断して開発していけるような方、技術的なトレンドを追いかけるだけでなく現状と照らし合わせて最適解を見つけ改善していける方を募集していますので、気になった方はぜひこちらからエントリーください。お待ちしております!

エンジニア採用 | freee株式会社 採用情報

▶次回freee Tech Night

10/1(金)「安定した開発を続けるサイトビジットのRails活用術」というテーマでお送りします。 サイトビジット社は2021年4月にfreeeにグループジョインしました。『資格スクエア』や『NINJA SIGN by freee』を開発しており、サーバーサイドのフレームワークにRuby on Railsを採用しています。 テストカバレッジ96%・ほぼ毎日各ライブラリのupdateを実施・専業のデザイナーなしでのUI構築など、限られたエンジニアの中でどのようにして高速にかつ安全に開発を進めているのか、開発の組織や文化について話を聞いていきます。 freee-tech-night.connpass.com

▶今回のイベントのアーカイブ(録画)


www.youtube.com