こんにちは。
『マネーフォワード クラウド経費』のフロントエンドエンジニアをしている木村(@kimromi)です。

Ruby on Railsを利用してサービス開発を進めているプロダクトのフロントエンドの環境を整えていき、UIの改善やフロントエンド側の開発効率アップなどにつなげていくような動きを現在やっています。

なぜクロスブラウザのE2Eテストが必要になったか

ある日、IE11のみでJavaScriptエラーが起こり動作しないとの連絡が入り、慌てて対象のプルリクエストをリバートしたということが起こりました。

原因としてはライブラリの追加によるものでした。
現在フロントエンドの改修を行っていく中で、ライブラリの追加やビルド方式の変更などドラスティックな変更をすることが多くなってきています。

そのたびにMicrosoftからダウンロードできるVM環境を立ち上げ手元で確認するのは手間がかかり確認漏れも発生する可能性があるため、クロスブラウザでのE2Eテストの必要性を感じました。
また、BtoB向けのクラウドサービスという特性上、IE11からのアクセスが全体の約23%とGoogle Chromeに次ぐ2番目にアクセスが多いブラウザです。
Microsoftがサポートを切らない限りサービスとしてIE11のサポートを切ることはできないという判断で今後も付き合っていく必要があります。
IE11での自動テストを導入することでリリース前に不具合を検知することができ品質を向上させる目的もあります。

GitHub Actionsを選んだ理由

こんにちは。
2019年新卒の原田大輔です。
普段は「マネーフォワード クラウド会計・確定申告」のサーバーサイドエンジニアをやっています。

今回新卒エンジニア研修をきっかけに今までに挑戦したことのなかった新しい技術に挑戦し、Slackでの活動を可視化するツールを作りました。

その時の話です。

Slackの行動可視化ツール作るに至った背景

きっかけは1ヶ月間の新卒エンジニア研修でした。
研修は「自分が今までに使ったことのない技術」を使って各自プロダクトを作るという内容です。なんと、RailsGuidesやRailsTutorialの日本語訳を作っているYassLab Incの安川さんもメンターとして参加いただきました。
（エンジニア研修の詳細は、同期の富田湧平くんのエンジニアブログにも書かれているのでぜひ読んでみてください。）

研修とはいえ、せっかくプロダクトを作るなら研修が終わっても継続して使っていけるものを作りたいと考えていました。
そんな中、思いついたのが「Slack上の行動を元に何か面白いことができないか？」でした。

こんにちは。
CTO室のくりまお（@awa_kuri23）です。

マネーフォワードでは、毎年 開発合宿 を実施しています。

今年も前半・後半に分かれて、6月に開催しました。
その様子をお届けします。

開発合宿とは

開発合宿の目的

マネーフォワードの開発合宿は、新しい技術の習得や技術の活用に挑戦する「テクノロジーチャレンジ」を大きな目的としています。

マネーフォワードは、Valueのひとつとして『Technology Driven』を掲げています。
その実現には、中長期的な視点を持ってテクノロジーに対してチャレンジする気持ちと姿勢が必要です。

開発合宿では、非日常的な環境で、業務の割り込みなどをうけることなく、一泊二日で参加者各自がテクノロジーに対してじっくりと向き合います。

開発合宿のルール

• チャレンジする内容は、業務に関係あってもなくてもOK
• 必ずしも2日間でなにか成果物を完成させる必要はありません
• 個人開発・チーム開発（1チーム3人まで）どちらでも可
• 合宿内での成果発表では、「自分にとって何がテクノロジーチャレンジだったのか」について発表してもらう

こんにちは。
マネーフォワードでインフラエンジニアとして働いているgotoken（@kennygt51）です。
今回は、先日弊社のインフラチームで取り組んだ「Terraformのバージョンをチーム一丸となって一気にアップグレードする会」こと 『Terraform 0.12 Upgrade Battle！』 について紹介します。

『Terraform 0.12 Upgrade Battle！』開催の経緯

Terraform 0.12 リリースまで

マネーフォワードは、提供する各種サービスを動かすためのインフラとして、AWSを利用しています。そしてそのAWSリソースのほぼ全てを、Terraformを用いてコード管理しています。

遡ること半年ほど前でしょうか。実はインフラチームのメンバーは皆、事実上のメジャーバージョンアップであるTerraform 0.12のリリース を密かに待ちわびていました。Slackを見ると、何らかの情報解禁があるたびに盛り上がっていたのがうかがえます。

リリースが近づいてウズウズしています。

こんにちは。
経費精算サービス「マネーフォワード クラウド経費」の開発チームでiOSエンジニアをしている河島です。

本日、ICカードリーダー by マネーフォワードのiOS版アプリをストアに公開しました。
交通系ICカードから利用履歴を取得して表示したり、マネーフォワードのサービスと連携して家計簿や経費精算などに役立てていだだけるアプリになっているので、よろしければダウンロードして使っていただけると嬉しいです。

今回はそのICカードリーダーアプリの開発について共有してみようと思います。

動作イメージは以下のような感じです。

こんにちは、Androidエンジニアの syarihu です。

マネーフォワードの有志の社員によって執筆した「Money Forward Techbook」を技術書典7に出典します。
技術書典のサークル詳細はこちらです。

サークル詳細 | まねふぉ執筆部 | 技術書典
https://techbookfest.org/event/tbf07/circle/5719955576193024

興味を持たれた方はぜひ、チェックリストに追加していただけると嬉しいです。
配置は「う20C」です。当日ブースにてお待ちしております。

出典することになった経緯

出典することになった経緯を簡単にお話しようかと思います。
2019年4月ごろ、こんなツイートをしました。

入社してからいままで結構色々やったので、そろそろ振り返りのエンジニアブログ書こうかなぁ。

— syarihu@技術書典7 う20C (@syarihu) April 11, 2019

すると、知り合いのエンジニアたちから

• 「それって技術書典に持っていくやつじゃないですか？」
• 「いやぁ楽しみだなあ」

というリプが届き「おっ…なんかめっちゃきた」と思いつつ、ちょっとやってみたい気持ちもあったのでこんなツイートをしました。

でも技術書典に自分でサークル出展してみたい気持ちはちょっとあるんですよ

— syarihu@技術書典7 う20C (@syarihu) April 26, 2019

こんにちは。
マネーフォワード クラウドシリーズの会計・確定申告プロダクトでQAエンジニアとして働いているjoといいます。

QAグループが立ち上がり、早いもので1年が経過しました。

ただ…..社内外ともにあまり認知されてないんですよね…..悲しい…..辛い…..

なので今回は！！

『マネフォのQAエンジニアってこんな感じなのです』
を発信して、社内外問わず、みーんなに知ってもらおう！！

という気持ちを持って、日頃のお仕事内容やこの一年の変遷について書いていこうと思います。

興味のある方もない方も軽い気持ちでサクッと読んでいただけましたら幸いです。
では、早速！！

まずもって、なぜQA組織が作られたのか

QA組織の立ち上げを決断したK氏とH氏に話を聞いてみました。

エンジニアの澤田です。

この連載では、社内のRuby (on Rails)コードで気になった箇所の問題点やそこから発展して関連事項を議論しています。

連載6回目から受け渡しのパターンマッチングを考察しています。
パターンマッチングの文法的な要素のうち、オブジェクトを渡す側について連載6回目でまとめ、定数や変数で受ける側の要素について連載7回目でまとめました。

こんにちは。
人事の小川です。

来る8月23日(金)に、マネーフォワードグループ全体でサービスづくりに関するイベントを開催します。

▼イベント募集ページ
https://moneyforward.connpass.com/event/140296/

マネーフォワードとしては初めてとなるイベントを開催するにあたり、そこに込めた想いを言語化したいと思い、はじめてエンジニアブログに投稿してみました。

いわゆる「企画の裏側」ですが、この内容をご覧いただいた上で興味を持ってくださった方に、ぜひ参加していただきたいと考えています。

なぜやろうと思ったのか

私がマネーフォワードに入社して、4年半ほどが経ちました。
会社は大きく成長し、入社当時にあったプロダクトも進化し多くのユーザーに使っていただいており、多くの新たなプロダクトがリリースされ、グループ会社も立ち上がりました。

メンバーも増え開発組織は大きくなり、技術や手法など、変わったこともたくさんある一方、変わらないこともあると思っています。それは、サービスづくりにおける価値観（想いやスタンス）ではないでしょうか。採用担当として多くの候補者の方と接してきた中でも、入社を決めるポイントとして挙げる方が多いことからも、強く実感を持っています。

言葉では伝えにくいこの価値観を、リアルなイベントを通して感じてもらいたいと考えました。

エンジニアの澤田です。

この連載では、社内のRuby (on Rails)コードで気になった箇所の問題点やそこから発展して関連事項を議論しています。前回から、1つのテーマで長くなりそうなときは、複数の記事に短く分割する方針にしています(とは言いつつも、分割した記事が長くなり、それをさらに分割した今回の記事もまた長くなってしまいました)。前回の「マネーフォワード社内PRに見られるRubyの書き方について – (6) 受け渡しのパターンマッチング 1」から受け渡しのパターンマッチングを考察しています。