こんにちは、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」から受け渡しのパターンマッチングを考察しています。

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

突然ですが、あなたのアプリでは削除された機能のリソースや過去のキャンペーンなどで使ったリソースをきちんと削除していますか？
クラスは消したけれどレイアウトや文字列リソース、画像リソースなどをそのままにしていませんか？

私が開発を担当しているAndroidアプリではそういった過去の機能で使われていた未使用のリソースがたくさん残っていました。
文字列リソースなどは残していても大きな影響はありませんが、特に画像リソースは不要なものが積み重なるとapkのサイズが数MBレベルで変わってきてしまうため、消しておくに越したことはありません。

しかし、不要なリソースをすべて特定するのはなかなか大変ですし、一気に消すのは怖いですよね。

そこで今回は@konifarさんが開発されているgradle-unused-resources-remover-pluginを利用して未使用リソースを一括削除する方法を紹介します。

gradle-unused-resources-remover-pluginとは

gradle-unused-resources-remover-pluginは、gradleコマンドを実行するだけで簡単に未使用リソースを削除できるGradleプラグインです。
除外ファイルを設定することができるため、Android Studioの機能にある「Remove unused resources…」よりもより柔軟に未使用リソースの削除を行うことができ、意図しないリソースの削除を防ぐことができます。

こんにちは。
2019年4月に新卒入社しましたサーバサイドエンジニアのたかです。
社内懇親会のコンテンツにて、新卒エンジニアが奮闘した記録をご紹介させていただきます。

発端

マネーフォワードでは、半期ごとに全社員が集まり、各事業の振り返りやワークショップを行う半期総会を開催します。

そんななか、総会・懇親会を運営担当から
「半期総会後の社内懇親会、新卒でコンテンツを運営して欲しい」
と依頼があったことが始まりです。

要件は
1. 懇親会コンテンツの時間は40分
2. 目的は社内コミュニケーションの活性化

そこで、往年の人気クイズ番組『クイズダービー』をマネフォ風にもじった『MFクイズダービー』を企画することに決まりました。

そして、「せっかくならゲーム進行に必要な部分を自分たちで作っちゃおう」という流れになった次第です。

どんなアプリケーション？

ゲームのフロー

1. 解答者チームと投票者チームに分かれる
2. 4択のクイズが出題される
3. 解答者チームは投票者チームに分からないように解答する
4. 投票者チームは正解する解答者チームを予想し、自分の持ち点からいくらポイントを預けるか決め、投票する。
5. 投票した解答者チームが正解した場合は預けたポイント x 倍率 の得点を獲得。不正解だった場合は預けたポイントは没収される。倍率は各問題、解答者チームごとに異なる。

この流れを6回繰り返し、総得点上位6つの投票者チームに食事券のプレゼントを贈呈する、というゲームです。

エンジニアの澤田です。

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

5回目の「マネーフォワード社内PRに見られるRubyの書き方について – (5) 文の環境」では文の環境を考察しました。
今までは1記事1テーマで書いていましたが、毎回長くなりがちだったので、今回からは、1つのテーマでも長くなるときは短く分割し、復数の記事にします。今回から受け渡しのパターンマッチングについて扱います。

【バックナンバー】

• マネーフォワード社内PRに見られるRubyの書き方について – (1) 配列の生成
• マネーフォワード社内PRに見られるRubyの書き方について – (2) ハッシュの生成
• マネーフォワード社内PRに見られるRubyの書き方について – (3) 文字列の生成や検証
• マネーフォワード社内PRに見られるRubyの書き方について – (4) 真理値
• マネーフォワード社内PRに見られるRubyの書き方について – (5) 文の環境

初めまして。
マネーフォワード新卒1年目の富田湧平です！

4月の入社式から2ヶ月にわたる研修を経て、6月から現場に配属されました。

今回のブログでは、
「マネーフォワードの新卒エンジニアが、どんな研修を受けたのち、現場での業務に入っていくのか」
について書きます。
マネーフォワードへのインターンや就職を考えている人にも多少の参考になれば嬉しいです。

簡単に自己紹介

簡単に、自己紹介をしておくとこんな感じです。

• 大学では経営学部で企業のビジネスモデルやマーケティングについて学んでいた。
• 当初は、ビジネス職で内定をもらったものの、エンジニアへの挑戦を決意して選考を受け、入社まで独学しながらキャリアをスタート。
• バイト・インターンでの開発経験なし
• プロダクトコードに触れたことがない（入社の半年前から、個人開発をやり始めて少しコードを触っていた程度）

こんな感じで、正直なところ研修前は業務に対するイメージもなかなか湧いておらず、不安な気持ちがありました。

研修紹介

まず入社してすぐの4月は、1ヶ月のビジネス研修を受けました。
メールの書き方や名刺交換などのビジネスマナー、社会人のいろはを学びました。

エンジニアの澤田です。

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

4回目の マネーフォワード社内PRに見られるRubyの書き方について – (4) 真理値 では真理値を考察しました。

今回は 文の環境について考察します。前回から間が空いた分、今回は長いです。説明の割合が多くなってしまったことをご容赦下さい。

【バックナンバー】

• マネーフォワード社内PRに見られるRubyの書き方について – (1) 配列の生成
• マネーフォワード社内PRに見られるRubyの書き方について – (2) ハッシュの生成
• マネーフォワード社内PRに見られるRubyの書き方について – (3) 文字列の生成や検証
• マネーフォワード社内PRに見られるRubyの書き方について – (4) 真理値