まとめ この記事のサマリーはタイトルに書かれている通りです。 2021年3月から2025年6月（予定）までおよそ4年ほど専任してきた技術広報をやめて、プロジェクトマネージャーにチャレンジします。 この記事では技術広報をやめるまでの経緯とプロジェクトマネージャーを選択した理由について書いていこうと思います。 また、本記事は社内ドキュメントを元に構成などを見直し、社外公開用に書き直しました。 上記の点、ご留意いただければと思います。 Who are you? マネーフォワードで技術広報をしているid:luccafortです。 普段は三条にある京都開発拠点（以降、京都拠点）で勤務し、イベントやカンファレンスの際に必要に応じてマネーフォワードの各拠点に出張したり、カンファレンス会場に出張したりしています。 マネーフォワードでは当初IPOを目指す企業さまや中堅〜上場企業さま向けの会計ソフト、マネーフ

はじめに 初めまして、たまに実家に帰っては犬を吸っているganmoと申します。 新規プロダクト開発チームでリーダーをやっています。 私のチームでは長期の企画フェーズを経て、昨年12月に大規模な組織変更を実施し、新しい開発体制が本格始動しました。まずはPoC（Proof of Concept）フェーズとして、技術的な実現可能性の検証や、ワイヤーフレームをベースにしたプロトタイプアプリケーションの開発に着手しました。 組織変更前からスクラムを採用していましたが、新体制ではスクラムの運用がうまく機能せず、個人的にモヤモヤを抱えていました。 「スクラムがうまくいかない」 「形骸化している」 そんな悩みを私たちと同じように抱えているチームは少なくないと思います。 そこで今回は、あえてスクラムから一度離れ、ゲーミフィケーションの要素を取り入れた独自の開発スタイルを試してみた経験をお話しします。 当時の

はじめに 皆さんこんにちは、ERP開発本部 福岡第一開発部 Guardianグループの@tosite（てっしー）と申します。 普段はCRE（Customer Reliability Engineer）的な立場から、クラウド経費の保守・運用や運用改善などを推進しております。 突然ですが、皆さんは「ドラッカー風エクササイズ（以下、ドラエク）」というものをご存知ですか？ 「アジャイルサムライ」の著者であるJonathan Rasmusson氏が提唱した、チームビルディングのためのプラクティスです。 チームメンバー同士で以下の4つの質問に答え、それを共有することでチームの結束を高めることができると言われています。 私の得意なこと どうやってチームに貢献しようと思っているか 自分が大切にしている「価値」 チームメンバーが私に対して抱いていると思う期待値 詳しくは以下のブログなどをご覧いただければと思

ログ収集の重要性 近年、サイバー攻撃の増加に伴い、ログ収集と監視はシステムの防御戦略として不可欠です。特に、攻撃の予兆検知やインシデント対応などの観点からログ管理はセキュリティ強化の鍵を握っています。 またビジネス観点からも、ユーザーの行動分析や使用状況に合わせたサービス改善など、ログを適切に収集することの重要性が高まっています。 この記事ではフロントエンドのログ収集をより効率的なものにする方法を提案します。以下のような方々を主な対象読者としています。 主にフロントエンドの開発をされている方 ログについて興味のある方 何かしらのサービスを用いてすでにログ収集を実施している方 フロントエンドのログ収集方法に悩んでいる方 フロントエンド特有の問題 フロントエンドのログ収集は、バックエンドと異なりユーザーのブラウザ環境やクライアントサイドでの挙動に依存するため、特有の問題を抱えています。特に以下

はじめに こんにちは！マネーフォワードでエンジニアをしている寺澤（@locol23）です。 社内で開催された AWS GameDay に参加し、良い経験ができたのでご紹介します。 AWS GameDay とは 公式に AWS GameDay のページがありますので、概要を引用します。 aws.amazon.com AWS GameDay は、チームベースの環境で、AWS ソリューションを利用して現実世界の技術的問題を解決することを参加者に課題として提示する、ゲーム化された学習イベントです。従来のワークショップとは異なり、GameDay は自由で緩やかな形式で、参加者は固定概念にとらわれずに探索し、考えることができます。 なんとなくイメージが掴めたでしょうか？ GameDay とあるように、チーム対抗でポイントを競い合うなど、ゲーミフィケーションの要素が詰まっているワークショップイベントとな

この記事は、Money Forward Engineers Advent Calendar 2024の12月20日の記事です。12月19日はちーずさんで「React Flowで叶える柔軟なフローチャートの実装方法」でした。 CTO室の高井といいます。 みなさん、開発生産性を高めていますか？　はたして「推測するな、計測せよ」という言葉がこの文脈で適用できるのかはさておき、開発生産性の測定は大きなトピックです。当社では、ソフトウェア生産性の可視化のために Four Keys を採用していたり、開発者体験サーベイ を行ったりしてきました。それでもまだ、開発生産性をどのように捉え、測定するのか悩んでいます。 本記事では、現代的な開発生産性指標を理解するために、 Four Keys からはじまるエンジニアリングの生産性に関わる指標について、ざっと再確認をしていきたいとおもいます。なお、海外では Fo

この記事はMoney Forward Engineering Advent Calendar 2024 12月18日の投稿です。 12月17日は金子さん（@kyntk_1128）で「チームで向き合う開発者体験の改善：Webフロントエンド版DX Criteriaの実践」でした。 adventar.org 皆さんこんにちは。 沖縄から帰ってきて以来、あの碧い海が恋しくてたまらない、クラウド経費 Guardianグループの@tosite（てっしー）と申します。 今年も残すところあと10日程度と、年々加速していく時の流れを目の当たりにして軽く絶望していますが、一年をふりかえるときがやってまいりました。 今年は激動の一年で、いろんなことがありましたがその中でも個人的に一番大きなトピックはTOEICが700点を越えたことです。これはほぼ丸一年頑張ってきて、やっとの思いで成し遂げたことなので、達成したと

この記事は、Money Forward Engineers Advent Calendar 2024の12/17の投稿です。 adventar.org こんにちは、名古屋開発拠点のエンジニアの金子 @kyntk_1128 です。 今年公開されたWebフロントエンド版DX Criteriaをチームで実践してみたので、取り組みの内容や感想などについてまとめます。 WebフロントエンドDX criteriaとは？ 日本CTO協会が公開したガイドラインで、オリジナルのDX Criteriaが掲げる「2つのDXによって高速な仮説検証能力を得る」というビジョンをWebフロントエンド技術領域の観点から実現するためのサブセットに相当します。1 (Webフロントエンド版DX Criteriaの概要から引用) WebフロントエンドDX Criteriaの目的としては以下のようなことがあげられています。 変わり

この記事は、Money Forward Fukuoka Advent Calendar 2024の12/8の投稿です。 12/7は RemiM さんで つよいエンジニア(物理)を目指した記録2024でした。 adventar.org こんにちは クラウド経費開発チームの 宮村（みやむー） @miyamura.koyo です。 2024年12月よりクラウド経費のテックリードのオファーをいただき、引き受けることにしました。クラウド経費は全体として大きなシステム・プロダクトになっているため、私は全ての技術領域ではなく、主にバックエンド領域においてリーダーシップを発揮する予定です。 本記事では、テックリードを引き受けた今の心境、そしてテックリードの大義について考えたことをまとめたいと思います。 クラウド経費開発部の立ち位置と難しさ まず、クラウド経費開発部の立ち位置を私なりに簡単にまとめます。 と

はじめに おはよう、こんにちは、こんばんは。 技術広報の luccafort です。 今年もあっという間に12月に突入しようとしている今日この頃ですが、皆さんいかがお過ごしですか？ ぼくは推しのチームであるマンチェスターシティが最近公式戦5連敗を喫して大変精神が安定しておりません。 もう1つの推しチーム、インテル・ミラノは立て直したのにどうして……。 ぼくの安らかな精神的安定のためにもシティには早く中盤からの守備を立て直してほしいと切に願う今日この頃です。 閑話休題、タイトルにもある通り、来週からは12月ということでアドベントカレンダーが開催されますね。 各社今頃レビューの準備に戦々恐々としているのではないでしょうか？（ぼくは今すぐ帰って寝てしまいたいです） この記事は今年開催されるアドベントカレンダーを紹介しつつ、これまでのマネーフォワードのアドベントカレンダーの歴史を振り返ってみたいと

こんにちは。マネーフォワードでQAを担当しているSugaです。2024年6月から、QAチーム内でプログラミングの基礎を学ぶ取り組みが始まりました。今回はその取り組みについてご紹介したいと思います。 1.はじめに 背景 マネーフォワードのQAチームは「特定の部署に所属せず、全体としてのプロダクトの品質向上を目指す」という最終目標があります。そのためには数多くのアプローチがありましたが、今回はプログラミングの理解向上にフォーカスすることになりました。その理由として、QAチームにはプログラミング経験の個人差が大きく、開発チームと実装する予定のコード設計の話をした際に、開発の意図とは異なる意味で受け取ってしまうなどのコミュニケーションミスが発生することがありました。最終的にはコミュニケーションを重ねた結果、誤解は解消しましたが、このような状況を改善すべく、プログラミング学習を始めることになりました

はじめに どもどもマネーフォワードで技術広報をしている @luccafort です。 普段ぼくは技術広報として、さまざまなカンファレンスに参加しているのですが、 会社がスポンサーを行っている関係で参加するケースが多く、カンファレンスを純粋に楽しむケースが少なくなってきました。 今回のKaigi on Railsでは残念ながらブースの抽選から外れてしまったのですが、 それを逆手に取って、久しぶりにイチ参加者として純粋に楽しんできた参加レポートを書かせてもらいました。 ブログを書くまでがカンファレンス！と教わって育ってきたのでカンファレンスの帰りに新幹線で書き始めたのですが、 アウトラインの段階で1万字を超えてしまいました。 その後、推敲や添削を行っているうちに、公開タイミングを逃してしまいました。 今まさに #kaigionrails のブログのアウトラインを書きながら「こんなことあったな」

概要 こんにちは、クラウド会計のフロントエンドエンジニアをしている@IZUMIRUです。 今回は、実装する前に「調査としてテクニカルプロトタイピングを取り入れると良いぞ！」という話をします。ざっくり要約すると以下です。 テクニカルプロトタイピングとは、本実装に近いコードで早期に動作するプロトタイプを作成し、技術的リスクや仕様、UI/UX の検証を効率よく進める手法 この手法によって、課題を素早く洗い出し、設計や実装の優先順位を見直し、無駄な手戻りを防ぐ さらに早期にステークホルダーと認識を統一し、より価値あるプロダクト開発を促進する 成功のポイントは、 時間の制約を設けて不確実性の大きい順に注力し、チーム内の連携を強化すること ぜひこの記事をご覧いただき「テクニカルプロトタイピング（TP）やってみよう！」と思っていただけると嬉しいです。 テクニカルプロトタイピング（TP）とは 本記事でいう

こんにちは。 id:Pocke です。マネーフォワードでは Rails を用いた Web アプリケーションの開発と、RBS という Ruby の静的型システムの開発を行っています。 最近 RBS の開発をする中で、「不要な処理を削除すると実行速度が遅くなる」という不思議な現象に遭遇しました。この記事ではその現象を解説しようと思います。 なおこの記事は Ruby の知識を前提としないように執筆されており、Ruby の知識が必要となるところには注釈を加えて補足しています。 普段 Ruby を書かない方にも読んでいただければ幸いです。 問題を引き起こした変更 今回の問題は、RBS のメモリ使用量の削減を行っている中で遭遇しました。まずはどんな変更を行おうとしていたかを解説します。 変更の動機 最近私は RBS のメモリ使用量の削減に取り組んでいます。1 その取り組みの中で、RBS のパーサーが作

こんにちは、クラウド会計の開発チームでスクラムマスターをしているasatoです。 私たちのチームでは、以前はフロントエンド（FE）エンジニアとバックエンド（BE）エンジニアがそれぞれの領域だけを担当していましたが、最近では互いに越境し、どちらの領域でも自立して開発を進められるようになりました。このブログでは、その越境のために私たちが取り組んだことを紹介します。同じように悩む方の助けや勇気づけになれば幸いです。 背景 私たちのチームはスクラムでWebアプリケーションを開発しています。エンジニアは職種としてFEエンジニア、BEエンジニア、QAエンジニアに分かれており、FE・BEエンジニアはそれぞれの領域のみを担当していました。 しかし、プロダクトを開発し続けていく中で以下の課題に直面しました。 FEとBE間でのプロダクトバックログアイテム（PBI）の受け渡しの待ちが発生し、スプリント中にPBI

はじめに こんにちは。マネーフォワード ERP開発本部 ガーディアングループ クラウド経費チームのせっきーこと @sekky です。2024年4月入社で、今回が初めてのブログ投稿になります！ 想定する読者 この記事の想定読者は、「登壇の経験はあまりないが、将来的にはやってみたい。でも自分にはハードルが高いかも・・・」と感じている方です。 この前、他チームのメンバーと登壇について話した際、「近いうちに登壇やってみたいんですよね」と話したことが本ブログ執筆のきっかけとなりました。 それを聞いて、登壇をしてみたいがハードルが高いと感じている方が潜在的にいるのではないか、と思いました。 また、チームメンバーに登壇してもらいたいと思っているリーダーの方にもマッチするかもしれません。 「これまで登壇何回もやってきました！」という方向けではないので、すでに自信がある方はスルーしてください。 登壇をしたこ

はじめに こんにちは。 マネーフォワード福岡開発拠点でSREとして働いているM-Yamashita です。 今回の記事は、GitHub Actionsを使ったSlackへの自動投稿の話です。 現在、クラウド経費・クラウド債務支払サービスの開発においてクエストという制度を採用しています。クエストを新しく作成するたび、開発メンバーに知らせるために手動で都度Slackに投稿していました。この手動作業を自動化した話をお伝えします。 クエストとは 経費・債務支払サービスでは開発ロードマップに沿って日々開発を進めています。この開発と並行して、内部改善をしていくことも重要です。 弊社ではそのような内部改善を推進する制度として、クエストという制度を導入しています。クエストとは、誰かにしてほしいことをまとめた「依頼」です。受ける人にとっては、業務の合間にチャレンジする「課題」です。 クエストはGitHubの

こんにちは、id:Pocke です。マネーフォワードではクラウド会計Plusというプロダクトの開発と、RBS という Ruby の静的型のためのライブラリの開発の両方を行っています。今回の記事では、クラウド会計Plusの開発の話を書こうと思います。 TL;DR spec/fixtures/下に想像以上に多くのファイルがあることに気がついた inotify を使って不要なファイルを検出し、削除した 問題の発見 クラウド会計Plusの開発業務として、私は最近不要なコードの削除に取り組んでいます。その一環としてリポジトリの状況を調査していました。その中で以下のコードを用いて「拡張子ごとのファイル数」を計測しました。 $ git ls-files -z | ruby -e 'pp ARGF.read.split("\x0").map{File.extname(_1)}.tally.sort_by{

Posted by Atsushi Kojima and Wang Yingjie (conducted the work during his internship), Researchers, Money Forward Lab. はじめに 近年、GPT-4などの大規模言語モデル（LLM）が注目を集めていますが、これらのモデルは必ずしも日本の金融分野に特化して学習されているわけではありません。 この課題に取り組むため、私たちは日本の金融・会計分野にアラインメントされたLLMの開発に取り組んでいます。 本ブログでは、その開発プロセスと成果について紹介します。 モデル開発のアプローチ モデル学習のフローを以下に示します。基本モデルとして、LLAMA2 7Bに日本語テキストで継続事前学習したモデルであるrinna/youri-7bを採用し、さらに継続事前学習とsupervised fine-

2024年8月22日(木)からiOSDC Japan 2024が始まりますね！今年のパンフレットでは2022年新卒入社で、マネーフォワード Pay for Businessの開発に携わるsakaiさんと、マネーフォワード技術顧問のgiginetさんのインタビューを掲載させていただきました。 今回はパンフレットには入り切らなかった内容を、ブログでご紹介できればと思います。ぜひご覧ください。 ※このインタビューは2024年5月に実施したものです 全員参加型、対面でのコミュニケーションを重視した技術顧問勉強会 ── giginetさんは技術顧問として、日々の業務相談はもちろん、定期的に勉強会を開催してくれていますよね。勉強会はどのくらいの頻度で開催しているのですか。 giginet： これまでは大体3〜4ヶ月に1回ペースで実施していました。 オンラインで1時間半の勉強会をしていたのですが、もう3