半年ぶりのカキコ……ども……。気づいたらHRソリューション本部からMFBC-CTO室に異動していたVTRyoです。兼任で引き続きHR系のマネーフォワード クラウドシリーズも担当しています。 ソフトウェアエンジニアとしての経験値が増えてくると、次第にレビュー担当者になることが増えてくるでしょう。私が所属するSREチームでもTerraformの相互レビューが頻繁に実施されています。そこで、事件は起きたのです。 自信を持ってApproveしたPull Requestで次々に事故が起きてしまった 現在HR内のマネーフォワード クラウドシリーズは、モダンな開発基盤へとリプレイス作業を多く行っています。これまで動いていた基盤に感謝しつつ、新しいPlatformへと移行し、最終的に元あったリソースを削除します。 事件はこの リソース削除 で起きました。 チーム内レビュー OK リポジトリ管理者レビュー

こんにちは！Pay for Business チーム インターン生の嶋村です！ 2022年3月より Rails エンジニアとして長期インターンに参加しています。 先日、会計Plus チームのpockeさんにサポート頂きながら初めての OSS コントリビュートに挑戦しました。今回はその経緯と内容について紹介したいと思います。 成果物 まずは成果物の紹介です。 Update document of Range#to_s by shmn7iii · Pull Request #46230 · rails/rails Rails Guides のドキュメントを訂正し、無事マージされました！ Rails Guides の管理は Ruby on Rails 本体のリポジトリで行われているので、なんと Rails 本体のコントリビューターになりました！嬉しい！！ 経緯 事の発端はpockeさんのインター

マネーフォワードビジネスカンパニー クラウドERP本部 会計Plus開発部の西村です。 エンジニアリングマネジャーとして クラウド会計Plus の開発に携わっています。(執筆時) 本記事では ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方 を何度も読んだ私が toB 向けのプロダクト開発において経験し､考えたことを紹介します｡ 私は2021年1月にソフトウェアエンジニアとして入社し､グループリーダーを経て､エンジニアリングマネジャーとしてマネジメントに従事しているという立ち位置です｡ もちろん1人でなしとげたことではなく､チームで考えて､学んで､成長してきた記録です｡ https://www.oreilly.co.jp/books/9784873119465/ この本はインセプションデッキなどを紹介した アジャイルサムライ のジョナサン・ラスマセンの新作。著者が

エンジニアブログでは初めまして、CTO室グローバル部のnishimura.yukariです。 前部署のCIO室から会社の社内異動公募制度（チャレンジシステム）を経て現在の部門で働いています。 （異動に至る経緯や想いは色々あるのですが、ちょっと長すぎるので別の機会にまたnoteにでも・・・） 先日、当社CTOから発表した通り、マネーフォワードのエンジニアリング組織では今後3年以内の公用語英語化を進めています。 マネーフォワードCTOが考えていること（2021年9月） グローバル部はその先駆者として、東京勤務ながらチームの公用語を英語に切り替え、様々な国出身のエンジニアが集って開発を進めている部門です。 そんな部署に異動志望を出した私自身といえば、実は【マネフォにジョインするまで、流暢に英語を話す人を周囲でほとんど見たことがなかった】ほど、英語とは無縁の学習環境からの出発でした。 エンジニアら

こんにちは！ マネーフォワード クラウド横断本部のWebエンジニアの はるやま (@linnefromice) です。 現在クラウド横断本部で行っている既存サービスのリプレイスプロジェクトにおける開発チームでの開発プロセスの紹介をさせていただきたいと思います！ 背景 プロジェクト発足当時は2人だったのですが、現在5人にまでメンバーが増え、そのうちの1人は海外居住者なので現在入国できておらずフルリモートで参画しています。海外居住者でないメンバーに関しては最低週1出社としていて、チームとしてはほとんどがリモートでの勤務がベースになっています。 (当たり前なことではあるのですが、)途中参画したメンバーはそれまでの経緯や意思決定をキャッチアップも必要ですし、初期メンバーはそれに対するフォローだったり、メンバー同士の相談などもなるべく低コストでスムーズにしたいです。 上記のような背景があり、仮にフル

こんにちは。 「マネーフォワードホームカンパニー HOME本部 サービス開発部 PFMグループ」兼「CTO室 スマートデバイス推進グループ」に所属するsyarihu（しゃりふ）です。 今回は「CTO室 スマートデバイス推進グループ」のしゃりふとしてエンジニアブログを執筆しています。 当社では、モバイルエンジニアの課題に向き合い、解決する組織としてCTO室にスマートデバイス推進グループが2021年の2月に発足されました。社内のモバイルエンジニアに個々人がいま感じている課題について定期的にアンケートを実施し、アンケート結果から抽出された課題に対して、どういったアクションがとれるかを検討し、実際に解決に向けて動きます。 2021年2月に発足されてから約半年ほどが経過し、マネーフォワードのモバイルエンジニアの環境もだいぶ良くなってきました。 本記事では、スマートデバイス推進グループがどのような経緯

こんにちは。 インフラエンジニアの村上です。 マネーフォワードのインフラチームは、サービスに関わるインフラから、自社の作業環境、開発環境、さらにはサービスのインフラの中でも物理的なものからOS・ミドルウェア・アプリケーションのメンテナンス・ビルド・リリース・運用まで幅広く関与しています。 今回はGoogle Cloud PlatformのBigQueryを活用してアクセスログの分析環境を構築した時の話を紹介します。 この記事に書かれる事 データ分析基盤としてBigQueryを使用した話と データ量を例示しながら使用を開始した時のトラブルシュートとパフォーマンスについて紹介する。 データ移行のコツもうまく含めながら書いていく。 BigQueryを採用した訳 マネーフォワードの家計簿は350万人以上のお客様に利用いただき、 アクセスログは日々2.500万件程度増えております。 サービス開始から

「迷ったら、買え」 十代の頃、秋葉原のパーツ売り場で悩んでいた私の背中を押した先輩の一言です。 手に入れたグラフィックカードは中古2万円の型落ちPCにゲーミング環境として新たな息吹をもたらし、学生の私をMMO仮想現実世界へと引き込んで戻そうとしませんでした。 しかし後悔はしていません。 なぜなら圧倒的にパワフルで、快適な環境でゲームプレイを体験できたからです。 結果として、ゲームプレイの成績はめきめきと向上し、以前より一層に増してMMOにのめり込むようになりました。 （その良し悪しは別として） これは個人の趣味において、環境を最適化することでアウトプットが高まった一例と言えます。 閑話休題。 事業において開発者が直接触れる端末・環境は、事業のエンジンとも言える重要な基幹部分だと考えます。 この記事では Money Forward におけるエンジニア・デザイナー向けの提供端末・開発環境 にか

こんにちは。ハルキです。 4月から中学二年生になりました。 僕はこの春休み、パパが働いているマネーフォワードに職業体験インターンという形でお世話になりました。 プログラミングを始めたきっかけは、Scratchという子供向けのプログラミング学習サービスです。 小学校3年生の時にどハマりし、そこから6年生まで夢中になってやり込みました。 ただ、やはり子供向けなので最低限のことしかできず卒業。 その頃、マネーフォワードの方が開催してくれたバーベキューで酒井さんと出会い、そこでPythonを教わりました。 （酒井さんはビジネスマンなのにプログラミングもできちゃうすごい人なのです！） そこから、Chatworkで酒井さんとコミュニケーションを取るようになり、プログラミングで悩んだことがあったら酒井さんに報告して、バグがあれば直し方を教わるようになりました。 酒井さんは面白い記事を紹介してくれたり、そ

こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ

フロントエンドエンジニアの渡辺です。 業務委託で働いてる身ですが記事書くことになりました。懐深い。 先日「ESLintのルール設定を全て確認して設定をする」ということをしました。 （ESLintはv4.0.0時点で240以上の設定項目があります。） 普段はルール設定が膨大なので必要な項目しか見ないのですが、 全てに目を通してみると得られた知見が多くあったので共有します。 設定方針 まず、ESLintの膨大なルール設定をどう設定するかを決めます。 やり方は大体3パターンに分類できます。 緩いルール設定（eslint:recommendedなど）を元に、設定を足して厳しくする。 厳しいルール設定（airbnbなど）を元に、設定を引いて緩くする。 既存のソースコードを解析し、ESLintの機能でルール設定を自動生成する。 今回は「入れたいルールに絞って設定したい」という思いがあり、 eslint