こんにちは、マネーフォワード 福岡開発拠点のStart up Studio部で新規プロダクトを開発しているバックエンドエンジニアのダンと申します。

今回の記事は私たちのチームでマイクロサービスアーキテクチャにあるAPI Gatewayの課題を解決できるソリューションを検討の経緯、そして辿り着けた優れたGraphQL Federationについて紹介させていただきます。

1. 課題
2. GraphQL Federationの前の世界
3. GraphQLの誕生
4. GraphQL Federation登場 – “One endpoint to rule them all”

1. 課題

まずは、マイクロサービスアーキテクチャによく出会うパターンの例を説明します。

製品をレビューするシステムを構築するプロジェクトで、フロントエンドとバックエンド二つのコンポーネントがある。
バックエンド側はドメインによる三つのサービスに分けて、それぞれのサービスは以下の情報を管理する:

• Users Service: ユーザー情報を管理するサービス
• Products Service: 製品情報を管理するサービス
• Reviews Service: 製品に対するレビューを管理するサービス

数カ月ぶりにおはようこんにちはこんばんは。
マネーをフォワードする会社で技術広報してるluccafortです。
皆さん元気ですか？
私は応援するマンチェスター・シティがチャンピオンズリーグの優勝を逃してしまいやる気の全てが虚無に消え去ってしまいました。
でもコパ・アメリカでアルゼンチンがグループ首位になったのでこれを糧に日々をなんとか過ごしています。
選手ではアグエロが好きです。

今年の3月から技術広報を本格始動してはや3ヶ月、怒涛の時間を過ごしたので技術広報立ち上げ期の壮絶ハードな活動を書いておこうと思います。
めちゃくちゃ頑張ったので 全力でシェアしてください！！！

エンジニアが技術広報としていろいろ貢献したり、失敗したことも会社の資産だと考えたので今回エンジニアブログに投稿させてもらいました。
技術的な内容ではないのですが、プロダクト開発でも技術広報でも根底となる思考プロセスやカイゼンの手法は同じなので広義の意味でエンジニアリングで技術広報をしていると捉えてもらえればと思います。

いきなりですが宣伝させてください！

GoCon 2021 Springでスポンサーをされていたカミナシさんと合同でイベントを開催します。
弊社マネーフォワードからは2名のエンジニアが登壇予定となっています。

岩村からは確定申告が技術的負債を如何にして返済して、フルリニューアルを成し遂げたのか？
木吉からは経費精算の自動化をさらなる推進を実現するためにGoでマイクロサービス開発をおこなった話をそれぞれ登壇していただく予定になっています。

6月30日(水曜) 19時開催予定となっています、まだ定員に空きがありますので是非ご参加ください。
「現場の声にとことん応える！ペーパーレス最前線のプロダクト開発」

閑話休題。

こんにちは。松本と申します。

2020年8月から2021年5月までの約10ヶ月間、クラウド横断本部のわり算グループという技術的負債を解消するチームでエンジニアとしてインターンをしていました。

メインタスクとして社内向け管理画面のリプレイスを担当しつつ、他にも実際にユーザーに使われているサービスの一部機能を改修したり、共通基盤のコードを数千行消してリファクタリングするなど本当に多くのことを経験させてもらいました。

(共通基盤のコードを数千行消した PR)

今回は振り返りの意味も兼ねて、インターンで得た学びを書き残しておこうと思います。

• 具体的な技術の話をすると収まりきらないので、今回は省略します。
• 記事にする関係上、詳細を割愛・簡略化している部分もあります。

要求の裏にある「やりたいこと」を常に意識する

こんにちは！
マネーフォワード クラウド経費 というサービスでサーバサイドエンジニアをやっている 福岡拠点 (九州・沖縄支社) の野田 (@quanon_jp) と申します。
最近は 狩猟 に勤しむ日々で、ハンターランクは 333 を超えました 💪

先日、クラウド経費で大規模な事業者 (ユーザ) 様の環境で実用に耐えないほどのパフォーマンスの劣化が発生しました。
そのときに行ったパフォーマンス改善についてお話します。

例

モデル構造と問題点

ユーザ (User) モデルとプロジェクト (Project) モデルがあり、1 人のユーザに対して複数のプロジェクトを割り当てることができます。
その割り当てをプロジェクト割り当て (ProjectAssignment) モデルで表現します。

こんにちは。
マネーフォワード CTOの中出（なかで）です。

CTOの私が、普段「なにを感じて、どんなことを考えているか」について、四半期に一回社内へ共有している内容を一部編集し、エンジニアブログに公開したいと思います。

前回はこちら：マネーフォワードCTOが考えていること（2021年3月）

目次

• 技術的負債からの脱却
• リードエンジニアへの期待値
• 採用へのコミット

技術的負債からの脱却

多くの企業が抱えているであろう技術的負債を、例外でなくマネーフォワードも抱えています。技術的負債からの脱却は、マネーフォワードの多くのエンジニアにとっての悲願です。先日9周年を迎えたマネーフォワードは、2016年12月頃からその負債を解消するプロジェクトをスタートし、実に歴史の半分をかけて負債からの脱却を図っています。
過去の判断はマネーフォワードが成長していくために最善のものであり、負債であると同時に資産でもあります。その結果、今も多くのユーザーに価値を提供できています。

マネーフォワード MEのiOSエンジニアの椎名です。
今回は、MEにテストツール Magic Pod を導入した時の話と、そこで得た知見やMEでの活用方法をお話できればと思います。
テストでお悩みの方は是非御覧ください。

導入の経緯

MEではユニットテストのコードがほとんど無く、うまく自動テストが運用できているとは言えない状況で、品質の担保はQAテスターに頼っていました。
とはいえ、人によるテストには限界があります。テストのスコープが広がれば工数も大きくなりますし、その分ミスも増えます。

そこで、MEではE2Eテスト導入導入の試みがされることになりました。
なぜE2Eテストなのかというと、以下の理由があります。

• MEの運用ではユニットテストを網羅的に書く事は、過去の知見から得策ではなさそう
• そもそもQAの負荷を減らす事が発端なので、QAがしているテストに近い方法が良さそう

はじめにE2Eテストツールを自前で実装する事を考えましたが、想像以上に機能が複雑になる事と、WebViewは対応が難しい事、導入後のメンテが大変という課題がありすぐに断念…
そんな時、Magic Podの記事を見つけました。

Magic Podとは

TRIDENTさんが提供する、WebとモバイルアプリのE2Eテストをノーコードで自動化するクラウドサービス です。
(MEではWebへの導入はまだしていませんので、以下モバイル前提、主にiOSでの導入の話となります)