サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
画力アップ
tech.mfkessai.co.jp
こんにちは、23卒の新卒エンジニアのfujinoです。今回は弊社のサービスでReactのフレームワークであるRemixを使い始めた話をしようと思います。 背景 弊社では今までVue.jsのフレームワークであるNuxt.jsを用いてフロントエンドを実装していました。 これは、採用当時は生のhtmlが使えるのが良いと思っていたことや、Vue.jsの経験のあるフロントエンジニアがチームにいたことが理由でした。 しかし、最近ではTypescriptとの親和性や、コミュニティの大きさなどの理由からReactの方が勢いがあるように感じます。 弊社でも少し前からReactに移行することを決定し、現在進行形でNuxt.jsからReactへの移行プロジェクトを進めています。 Reactの主要なフレームワークとして、Next.jsとRemixが挙げられます。 両者の違いとして、Next.jsはSSG(Stat
こんにちは、マネーフォワード ケッサイのテックリードをやっておりますgarsueです。 最近、CDNのエッジで動くサーバレス環境が充実してきましたね。 代表的なものとしてはCloudflare WorkersやfastlyのCompute@Edgeなどがあります。CloudflareではKey-Valueストアもあり、S3やGCSのようなオブジェクトストレージまで揃いつつあるようです。 そんな流れに乗って、Cloudflare Workersを使ってGoで実装した計算ロジックをエッジで動かせるか検証してみました。今回はその結果をレポートします。 TL;DR アップロードサイズ制限があるのでTinyGo使って小さいwasmバイナリを作る wrangler.tomlで type = "CompiledWasm"のモジュールとしてwasmバイナリをアップロードする wasmのエントリポイント内で
あけましておめでとうございます。Open Policy Agent(以下OPA)/Rego x 監査で継続的監査をあたりまえにしていきたいと思っているMoney Forward Kessai(以下MFK)のshinofaraです。 Regoとは、OPAのポリシーを記述する言語です。 本日はOPA / Rego Advent Calendar 2021の影響を受けて、MFKでOPA/Regoを活用して実現している監査に関することの1つを紹介できればと思いブログを書き始めました。 そもそもOPAって何?に関しては、以下のZennに詳しく書かれておりますので、こちらのブログでは割愛させていただきます。 OPA/Rego入門: OPA/Regoとはなんなのか MFKではOPAで何をチェックしているか 昨年「2021年に入ってやめた3つの開発に関わる仕組み」を書かせていただきました。今回はその中で書
GCP上では誰もが同じ権限に、そして開発者全員が一時的に権限付与できるツール「granter」について こんにちは、マネーフォワードケッサイ(以下MFK)SREチームのshinofaraです。今回は権限の仕組みを見直した話と、それを実現する為に開発したgranterというツールについてお話したいと思います。 また今回granterのcore部分をmfkessai/granter_coreとして公開しています。 granter登場以前の世界 MFKでは、2017年の創業時からGoogle Cloud Platform(以下GCP)とGoogle Workspace(当時はG Suite)を選択して利用してきました。 GCPの Cloud Identity and Access Management (IAM)では、Workspaceで作成した個人のアカウントだけでなく、Groupに対して権限
久しぶりの登場となりましたマネーフォワードケッサイ(以降MFK)CTOの篠原です。 事業が成長し続ける事で、情報管理、GCPリソース等のアクセス権限や、そしてオペレーションやセキュリティ観点でのリスクコントロールなどを意識する場面が増えてきます。 今回、MFKとして正しいと思う形で正しく運用できているかを保証する為に導入していた仕組みなどを、0から再設計しなおしたお話ができればと思います。 まず今回のテーマである正しいとは何かを書き出したいと思います。 GCPリソースに対するメンバーの権限は必要最低限に留める事 本番環境にデプロイされるソースコードが社内で定める条件を満たしている事 社内ツールで読み書き可能なメンバーが必要最低限である事 またそれぞれで意図通り運用されたことを保証できる事 一部ではありますが開発組織によって定義される正しさは異なると思いますので、ここではMFKの考える 正し
BigQueryの布教活動をしていますna0です。 この文書は、BigQueryリソースに対する期待値をラベルで明示する提案を行うものです。 組織全体でデータ品質に合意するための第一歩としてBigQueryリソース ラベルを使ってみませんか。 ラベル品質のベースラインとして、マネーフォワード ケッサイで運用している規約を紹介します。 BigQueryリソース ラベル規約 この文書は、データ活用を促すためのBigQueryラベル規約を定めるものです。 提案、指摘をお願いします。 結論 BigQueryリソースに対する期待値をラベルで明示しましょう 一貫性を持ったラベル付けのために、規約を整備したのでご協力ください 課題意識 BigQueryの利用者が増えていくと、リソースに対する期待値も様々です。 期待値に合うリソースなのかを利用者自身で判断できる状態が望ましいです。 期待値がずれていると、
4年ほど本番運用してきたGoogle Kubernetes Engine。4年の間で変化し続けてきた弊社のIngress周りの歴史 きづけば2021年ですね。12月末に書いたこの記事は年末休暇の関係で、公開がこのタイミングになりました。あけましておめでとうございます。 今回は、マネーフォワードケッサイが利用しているGCP/GKEのIngreeまわりを振り返ってみたいとおもいます。 創業初期 2017年3月時点ではGCPには証明書を自動的に作成する仕組みがなかった事もありますが、まだまだ証明証は信用の為にEVを買うという考えが強かったので、EV証明書とワイルドカード証明書を購入してIngressに設定してました。 証明書の自動作成と更新できるように ユーザが利用するドメインのみ購入した証明書を使い、社内利用のドメインは、cert-managerを利用して作成したLet’s Encriptの証
MF KESSAIでは「マネーフォワードグループ、新型コロナウイルスの感染拡大防止に向け在宅勤務を実施」のタイミングから全従業員がWork From Homeを実施しています。 しかし弊社では創業時からWFHでも安全に安心して行える環境、そして組織体制を構築してきました。 そのおかげか今回の新型コロナウイルス(COVID-19)への対応として原則在宅勤務となった際にも、大きく生産性を下げる事なく実施する事に繋がりました。 全従業員がWFHの状態でも生産性を高め続けるためには、コミュニケーション、ハンコ、作業環境など様々な課題が存在すると思います。今回は仕事で一番利用するエンドポイント(端末)とアカウント管理基盤、そして情報管理として利用しているG Suiteに関してご紹介したいと思います。 考え MF KESSAIでは、創業初期からZero Trustという概念に関して考えてきました。 ま
こんにちは、MF KESSAIでバックエンドのエンジニアのgarsueです。 2019年もあっという間すぎて戦慄しています。 今回はMF KESSAIでのGoのテストについて、ちょっと工夫してる点を書いてみようと思います。 並列テストによる問題 Go標準のテスト実行コマンドgo testはデフォルトでパッケージごとにテストを並列実行します。 通常は何もしなくてもテストが並列実行されてうれしいのですが、たまに困るケースがあります。 ファイルやDBなどの外部のリソースを触るテストが並列実行されて競合してしまうケースです。 MF KESSAIでは、テスト用のMySQLに接続して実際に読み書きを行うテストを多数書いています。 それらが並列実行されることで、各テストのテストデータ同士が競合してしまうという問題がありました。 開発初期はとりあえずgo test -p 1として並列実行を諦め、問題を回避
はじめまして、MF KESSAIでバックエンドエンジニアを担当している近江です。 今回は6月に行ったIKIOI(※)向上合宿で取り組んだ、entityからコード自動生成した話をしようと思います。 ※IKIOIとは、弊社のチーム開発力を示す指標です。(詳細はこちら) なぜコード自動生成しようと思ったか? MF KESSAIでは新しいentityを追加する場合、 ドメイン層にentity追加 ドメイン層に追加したentityのRepositoryインターフェースを定義 entityのファクトリを追加 インフラストラクチャ層にRepositoryインターフェースの実装を追加 実装したコードのテストを追加 といったコードを書いています。 ただこの1-5のコード、単にCRUD用のコードだけの実装であればビジネスロジックは関係ないので、1のentityさえ定義されていれば2-5のコードは自動生成できま
概要 今回は、OpenAPI Specification(以下OAS)駆動でREST API開発をすることで享受できる恩恵と制限についてお伝えできればと思っています。 序文 MF KESSAI(以下MFK)で、Backend開発を行っているusumachi(a.k.a usuimachinami)と申します。 開発に対し “気合ブリバリ” でそれはもう横須賀最強 麓沙亜鵺です。 さて、MFKでは導入企業様のさらなる請求業務の効率化を目指し、REST APIを提供しています。 開発に際してインターフェースの仕様定義のために、OASを利用して開発を行っています。 また、最近のMFKは試作(prototyping)を繰り返してより良いものを作ろうという動きがあります。 この方針とOASを利用した開発がとても適合しました。 OpenAPIとは OASとは正式名称でOpen API Specific
こんにちは、獏良天の風神こと@garsueです。 MF KESSAIでバックエンドのエンジニアをやってます。 先日、OpenCensus meetup vol.1にブログ枠として参加しました。 今回はそのイベントレポートとぼくなりの感想を書いていこうと思います。 OpenCensus meetup マイクロサービスやサーバーレスアーキテクチャなど、複雑化・分散化していく昨今のシステムでは、システム全体の状態を把握することが困難になってきました。 フロントエンド、クライアントサイドも年々複雑になっていますが、バックエンド以上に状態を観測することが困難です。 システム全体のいつ・どこで・何が・どうなっているかを把握できるようにすること、すなわちオブザーバビリティ(Observability、可観測性)1の担保が課題になっています。 その課題解決の一助となる技術としてOpenCensus2が注目
はじめに はじめまして、MF KESSAI株式会社(以下、弊社)の技術責任者(自称)を務めております篠原(@shinofara)といいます。 弊社の設立は3月と前ですが、先日公式に設立発表 がありました。 このタイミングで弊社の開発に関して、ご紹介いたします。 弊社では現在、BtoB間の決済をよりよくする為のサービスの開発を進めています。 技術ブログに書きたいネタはいっぱいあるのですが、1回では全部書ききれないので分割してお送りします(不定期)。 まずは開発・本番環境、そして、開発体制についてを概要程度でお話しします。 このブログに書く事 開発言語について 開発・本番の環境について 開発体制について 今後のブログの予定 使用技術 現在何を使って開発をしていて、そしてなぜそれを選んだのかを述べます。 言語 Go言語(Golang)をメイン言語としております。 /Go言語のロゴ、マスコットは2
MF KESSAI(以下MFK)のフロント担当、井原です。 この記事では、以前のエントリーでいつか別記事に書くと言っていたGraphQLのフロント側実装について年をまたいでしまいましたが書いていきます。 GraphQLについての説明は書きません。 導入経緯 サーバ側でのGraphQL実装#なぜGraphQLかを参照ください(丸投げ)。 Client Libraryの選定 GraphQLのClient Libraryはいくつか存在はしています。 存在はしていますが、Apollo Clientがとても優秀で一択でした。 というのも機能が整っているのはあるのですが、vue-apolloやnuxt用のapollo-moduleなどすでに環境も整っているため他の選択肢がありませんでした。 Apollo Client(以下apollo)は、GraphQLをシンプルにクライアント側で扱うことができるクラ
MF KESSAIでバックエンドのエンジニアをやっている@garsueです。 MF KESSAIではサービス開発初期からRDBへアクセスする際のO/R MapperとしてGORMを採用しています。 今回はMF KESSAIのバックエンドでGORMをどのように活用しているか簡単に紹介しようと思います。 当初の課題 弊社のシステムは基本的にドメイン駆動設計に則っているので、データの永続化と取得を行うリポジトリが存在します。 その具体的な実装の中でGORMを使っています。 当初の実装では、各リポジトリのメソッド内でクエリの組み立てを行っていたため、少しでも条件が異なれば別のリポジトリメソッドとして定義するような作りになっていました。 その結果、どんどんリポジトリが膨らんでいき、再利用性が低く見通しの悪いコードになるという問題が出てきました。 この問題はよくあるらしく、2018年の春のGo Con
MF KESSAIの篠原(@shinofara)です。 2017年3月に創業してからもうすぐ2年になります。 MF KESSAIって何 MF KESSAIというサービスは、導入企業様に提供しているサービスのUXはもちろん、サービスを支える裏側も成長を続けています。 しかし、これまで採用広報に力を入れる事ができなかったため、社外エンジニアの方からよく下記の質問をされる事が多くありました。 MF KESSAIってどんな会社? MF KESSAIって何をつかって、どんな風に開発してるの? その疑問を解消するために、MF KESSAI Handbookを公開しました。 MF KESSAI HANDBOOKについて MF KESSAI Handbookには、下記の内容を記載しています。 MF KESSAI株式会社について MF KESSAIというサービスについて MF KESSAIの利用言語について
MF KESSAI(以下MFK)のフロント担当、井原です。 今回は、2018年10月現在のMFKフロントエンド事情について書いていきます。 はじめに その時々の状況で一番作りやすそうな形を模索しながら構築してきました。 そのためサービスによって環境に多少の差異があります。 ただ、共通して必ず何か新しい技術、フレームワーク、やり方等を取り入れてみるというのを取り組んでいます。 これを通して、少しずつ自分たちにとって一番作りやすい方法を模索しています。 MFKにはUIのあるシステムがいくつかあり、それぞれで異なる技術が使われています。 それらの構成について紹介します。 大雑把な分類 現在MFKには、画面のあるサービスが大雑把に分けると4つあります。 コーポレートサイト系 オペレーター用画面 ユーザ用画面 カスタマーサポート用画面 必要要件と作られた時期によって、これらは環境がだいぶ違うものにな
MF KESSAI(以下MFK)の近藤です。 前職はスマホゲームのクライアントをC++で書いてたり、受託案件のサーバーをPHPで書いてたりしましたが、いまはモリモリGolangでサーバーのコードを書いてます。 MFKでは開発の方針としてフロー効率を重視しています。今回はMFKでのフロー効率を意識した開発の進め方を紹介します。 そもそもフロー効率がいいとは フロー効率のいい状態とは、処理待ちになっているタスクが少なく、タスクの着手から完了までの時間が短い状態です。一方でリソース効率がいい状態とは、開発者の作業待ち時間が少なく、常になんらかの作業ができている状態です。 詳しくは下のスライドをご参照ください。 「フロー効率性とリソース効率性について」 なぜフロー効率を重視し始めたのか MFKではスクラムのスプリント期間を1週間として開発を進めています。しかし、1週間以内に完了していないタスクが多
はじめまして。フロントエンドエンジニアを名乗らせていただいております、MF KESSAIの井原です。 入社してもう1年以上経っているのですが、初めてのブログになります。 今回は入社して最初の仕事だった、PDFの作成にHeadless Chromeを使った話です。 経緯 自分が入社して最初の仕事は、wkhtmltopdfというツールを使って請求書のPDFを吐き出すというものでした。 このツールは名前の通りHTMLをPDFに変換するもので、Qt上のwebkit系ブラウザを用いているため、普段使っているブラウザで見る見た目に近いPDFを作ることができます。 ですが当時のwkhtmltopdfで利用しているブラウザは非常に古く、JavaScriptもES2015以降の書き方はもちろんできないですし、CSSもflexboxなんて便利なものもありませんでした。 さらには、改ページを制御するために要素の
MF KESSAIでバックエンドのエンジニアをやっている@garsueです。 先日、社内向けサービスの新規開発でGraphQLを採用することになりました。 今回はその経緯や実装方法についていくつか参考記事を交えながら紹介していきます。 なぜGraphQLか 今回新規で開発するサービスは以下のような特徴があります。 MF KESSAIの内部は複数のサービスに分かれていて、それらをふんだんに利用する 社内向けなので直近でそこまで高負荷になる見込みはない フロントエンドとバックエンドのすり合わせにあまり時間をかけたくない(そんなに時間はない) まず複数サービスとの協調という点について、マイクロサービスをベースとしたGraphQLとGoによる開発を紹介した記事Using GraphQL with Microservices in Goにある内容をそのまま適用できそうだなというところからGraphQ
はじめまして。フリーランスのデザイナーの石原(@is8r_)と申します。 MF KESSAIさんでは業務委託のデザイナーとして創業当初よりお手伝いさせていただいております。 書いている事 MF KESSAI TECH BLOGは、静的サイトジェネレーターHugoで構築されておりまして、制作するにあたりアレコレ知見を得ることができたのでこちらでご紹介させていただきます。 Hugoの導入を検討されている方の参考になれば幸いです。 Hugoを採用した経緯 といっても単純な話なのですが、MF KESSAIではサーバーサイドの開発にGolangを採用していて、ブログを構築するにあたり、数ある静的サイトジェネレーターの中でもGolangで動いてるのがあるぞ!という事でHugoを採用する事となりました。 技術ブログ以外のMF KESSAIのサイト、コーポレートサイトやランディングページなども同様にHug
MF KESSAIの篠原(@shinofara)です。 前回「MF KESSAIはどういう技術・体制なのか」の続きになります。 今回お話すること 創業した3月から数ヶ月前までは、1つのdocker-compose.ymlで開発できるとてもシンプルなサービスでした。 ですが数ヶ月前から徐々にマイクロサービスへと舵をきり進みだした事で色々辛みが生まれてきました。 この問題の対応として、サービス単位で分離した所、以前より開発しやすくなりました。今回は開発環境の歴史と問題、そして現在の構成についてお話します。 MF KESSAIの開発環境の歴史 創業初期(2017年3月〜6月) 6月頃までは、ユーザー向けWEBサービスではなく社内ツールの開発をしていました。 当時の docker-compose.yml ブログの為に色々省略して書き出しています。またmfkessai/hogehoge のイメージは
MF KESSAIの篠原(@shinofara)です。 これまでは、本社のマネーフォワードの開発ブログに場所を借りて投稿していました。 これからは先日公開した当ブログ「MF KESSAI Tech Blog」をMF KESSAIのものづくりチーム全員で更新していきます。 そして今回は当ブログがどのようなアーキテクチャを採用して運用しているのかをお話します。 このブログで伝えたい事を3行で 文量のあるブログとなっていますので、読む時間を取れなくても結論は何かさくっと理解できるように、3行にまとめました。 MF KESSAIは元々ブログを投稿していたマネーフォワードの開発ブログを卒業して独立した HugoとGithubを使ってPull Requestベースでブログの運用を出来る仕組みを整えた インフラの運用にサーバレスアーキテクチャ(Firebase HostingやGoogle App En
MF KESSAIの鈴木(@makiton)です。 昨年の7月に本社より異動して9か月経ち、Goにはだいぶ慣れたけどRailsを忘れつつあります…。 今回のお話 今回はカジュアル面談でよくご紹介している、当社の開発文化について書いてみたいと思います。 1週間の流れ 我々はスプリント期間1週間のスクラム開発を基本にしています。 したがって、1週間は計画から始まり振り返りで終わります。 過去には1週間にこだわらずやろうということにしていた時期もありましたが、今は必ず1週間です。 アプレッソさんの記事にもあるとおり、1週間は日常生活のサイクルなのでリズムを合わせやすいというのは非常にあると思いました。 スプリント計画 前述の記事では水曜に計画をされてましたが、我々は月曜にやっています。 チームのベロシティを目安として今週リリースできそうな量のストーリーを優先度順にスプリントボードへ移し、今週のリ
このページを最初にブックマークしてみませんか?
『Money Forward Kessai TECH BLOG』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く