皆さんあけましておめでとうございます、2022年ではお初の登場になります技術広報のluccafortです。
年末に髪の毛を染めようと思ったら思いの外明るい色味になってしまい、金髪っぽくなってだいぶヤンチャな風貌になっています（ウケる）
さて、本投稿は元々は社内向けにPVや情報発信の傾向分析、仮説検証をおこなうために用意していた記事となっています。
その記事を元に多少の手直しをして社外発信用として加筆修正したものとなっています。
日本語がおかしいところがありましたら、その添削の名残だと思っていただければと思います。
本記事では便宜上2021年を今年、2020年を前年、2022年を来年として扱っています。
これは元となる記事を書き始めた時期が2021年12月29日だったことに起因している点をご了承ください。
エンジニアブログでは初めまして、CTO室グローバル部のnishimura.yukariです。
前部署のCIO室から会社の社内異動公募制度（チャレンジシステム）を経て現在の部門で働いています。
（異動に至る経緯や想いは色々あるのですが、ちょっと長すぎるので別の機会にまたnoteにでも・・・）
先日、当社CTOから発表した通り、マネーフォワードのエンジニアリング組織では今後3年以内の公用語英語化を進めています。
グローバル部はその先駆者として、東京勤務ながらチームの公用語を英語に切り替え、様々な国出身のエンジニアが集って開発を進めている部門です。
そんな部署に異動志望を出した私自身といえば、実は【マネフォにジョインするまで、流暢に英語を話す人を周囲でほとんど見たことがなかった】ほど、英語とは無縁の学習環境からの出発でした。
エンジニアらしく最新鋭テクノロジーツールの助けを全力で借りつつ、自分の足りない英語力をカバーしながら勉強する日々です。
ところで、昨年末にマネーフォワードの社内Slackでは「今年買って良かったもの」をシェアするのが流行っていました。
そこで私も便乗して、2021年にお世話になった【英語学習お役立ちツール】をシェアしたところ、年明けになって前部署での知り合いの方からこんなメンションが。
およよ・・・確かにエンジニア的観点でテクノロジーを活かした記事ではありますが、その発想はなかった。
こんにちは。関西開発拠点の村上です。
現在新規事業立ち上げをやっており、Day1からデータを見ながらプロダクト改善に取り組んでいます。
プロダクトをリリースした初日からデータ活用は始まっており、
チームではデータを見ながら会話をすることもしばしばあります。
元々インフラエンジニアだったので、データ基盤を真面目に作り始めることのコストやデメリットを感じていたので
Day1からData Informedを実現する為に非常に軽量に利用開始できるツールとして選定したAmazon QuickSightを簡単にご紹介します！
についてお話していきます。」想定読者は、新規事業担当や起業したばかりのプロダクトマネージャーやユーザーリサーチ、UXリサーチを担当する人です。
こんにちはマネーフォワード CTOの中出(なかで)です。
どうやらエンジニアブログが年間の投稿数100に到達しそうだということで、最後の100番目を私が担当させていただくことになりました。
luccaさん、エンジニアブログの盛り上げと最後のお膳立てありがとうございます。
なにを書こうか考えたのですが、実は今年の11月末をもってCTOに就任してから丸5年がたち(2016年12月1日就任)、色々あったなーなどと一人で感傷に浸っていたのを思い出し、そんな感じのことを書いてみるのも良いんじゃないかと考えました。
特になにか主張したいことがあるわけでもなく、単なる個人的な振り返りです。
私はマネーフォワードの創業メンバーではありませんし、CTOとして入社したわけではありません。
元々創業メンバーの一人がCTOを務められていましたし、自分がCTOになりたいとも思うこともなければ、なるという想像をしたこともありませんでした。
たまたま、前任の方がCTOを退任することを決められて、後任探しをする中で私に声がかかり、私は元来振られた仕事をお断りすることをあまりしない性質なのでお受けしてみることにしました。
こういう時はいつも思うんですけど、まあ命までは取られないだろうと。
私は、私と一緒に仕事してくれている方々はみな気づかれているかと思いますが、すごく楽観的なのです。
楽観的にお受けしてみたものの、はっきり言ってなにをやればいいか全然わかりませんでした。 初期のCTOあるあるなのではないかと思います。
何やればいいかわからないので、取り敢えず社内のエンジニア全員と1on1してみようと考え、それを四半期毎に繰り返しやってみようと思いました。
それぞれのエンジニアから1on1で課題感を聞いていたのですが、私もそれまで現場のエンジニアとして普通に働いていたので、そんなに目新しい課題は見つからず、しかもエンジニアの数がどんどん増えるので、全員と1on1していくことが回らなくなり、2周ほどしたところで全員と1on1する試みは打ち切られました。
当時の状況を書いておきます。
私がCTOになった当時のエンジニア組織は60-70名程度だったと記憶しています。マネーフォワードが設立されて4年半が経過していました。
まあまあ既に大きくなっていたけど、全員顔と名前が一致する、ほぼ全員と話したことあるぐらいの感じでした。
サービスはME(家計簿)、クラウド会計などを含めて既に7-8個あり。それぞれのサービスごとにチームが作られていました。
今もそうですが1サービスあたりにすると10名以下ぐらいの開発チームで構成されていて、それぞれが独立してサービスの意思決定をして開発している。
一方、全てのサービスが一つのDBを共有して動いているという状況でした。
やあ （´・ω・｀) ようこそ、バーボンハウスへ。 このブローグはサービスだから、まず読んで落ち着いて欲しい。 うん、「また」なんだ。済まない。 仏の顔もって言うしね、謝って許してもらおうとも思っていない。 でも、このブローグを見たとき、君は、きっと言葉では言い表せない「ときめき」みたいなものを感じてくれたと思う。 殺伐とした世の中で、そういう気持ちを忘れないで欲しい そう思って、このブローグを書いたんだ じゃあ、注文を聞こうか。
（出典元: バーボンハウス、一部改変 by @luccafort ）
マネーフォワードで技術広報をやっている自称実質MVP受賞者の @luccafortです。
アドベントカレンダーを書いてブログ納めしたと思ったら、年間100投稿がみえてしまったのでやるぞ！となって今度こそ年内最後のブログを書いています。
ブログと賽の河原って親戚かなにかなんだろうか…？
ともあれ、2021年のアドベントカレンダーは無事完走できました！ 🎉🎉🎉
誰も落とすことなく、入れ替わりも発生しないという信じられないくらい平和なアドベントカレンダーでした。
代わりにぼくのレビュータスクが積まれまくって死ぬかと思う過密スケジュールになったけど。
……来年はチーム制を導入しようと心に固く誓った吉宗であった。
（アドベントカレンダーのふりかえりは後日、改めておこなうのでここでは割愛します。）
今回はブログに焦点を絞って2021年のマネーフォワードエンジニアブログをふりかえる記事を書こうと思います。
社内の半期MVPに自身が所属する部署のMVPとして選出されたことが書こうと思ったきっかけです。
（ノミネートされるときに具体的な事例を書いてくれています、これだけで嬉しすぎます）
ぼくはこういった○○MVPなどの表彰とは縁遠い人生を送っていたので「もらえるならほしいなぁ」という漠然とした思いを持っていました。
ただそのためには「個人ではなく組織を動かせるパワフルさ」が必要だと理解しており、自分にそこまでのパワフルさ、チームを引っ張っていくリーダーシップのスキルはないなと諦めていました。
が、今回MVPノミネート（受賞はしていない）されたので、いいきっかけだし確かにうまくいった手応えもあるので記憶ではなく、記録に残すか！と思っていまこの記事を書いています。
この記事でお伝えしたいことはたった1つで「マネーフォワードでちゃんとエンジニア以外で挑戦したことが評価されたよ」ということです。
なので、今回は技術広報として特に評価してもらえたブログについてデータとともにふりかえっていこうと思います。
しばし、ご歓談にお付き合いください。
これは2021年12月28日現在のデータを元に記事が作成されています。
28日以降もデータが変動するため、皆さんがみているタイミングの実際の数値と異なる可能性があることをご了承ください。
いやー、大分寒い季節になってまいりましたね。
こんにちは、CTO室 副室長 兼 マイクロサービス推進部 部長の伊東です。
自他共に認める「褒められて伸びるタイプ」です。見かけたら何かしら褒めてあげてください。
今年8月に入社してから初のブログ投稿になりますので、お手柔らかにどうぞ。
私は前職でも今でも「チームのパフォーマンスを120%発揮させるリーダーであること」をモットーとしています。そんなありきたりなビジネス書のタイトルのようなモットーを掲げる私が、チームの力を発揮させるために常日頃から意識していることの一つを今回はご紹介します。
マネーフォワードが大事にしている Mission/Vision/Value/Culture のCulture の一つに Respect があります。
※マネーフォーワードの掲げるMVVC より図を引用
私はこの Respect が超大事だと思っています。MVVCの図でも、Respectを含むCultureは土台となる部分に描かれていているあたりもいい感じですよね。この絵は大好きです。
プロジェクト／チームの歯車が噛み合っていない、プロジェクトが上手く行っていない場合の原因の一つとして「Respect が不足している」ということは、ままあると思います。
上司・部下・同僚・お客様・ユーザー・協業先・競合先などなど様々なステークホルダーと仕事では関わります。私自身、振り返ってみて仕事がうまく行っていたときは 相手に対する Respect を持てている時だったと感じます。何事もうまく行かずにイライラとした状況を思い起こすと、周囲に対する Respect が不足している時だった、と思い当たることが多いです。
読者のあなたは、最近、人に感謝を伝えたり、人を褒めたりしていますか？
職人・匠の世界のように「ハードな」「厳しい」環境を生き抜いてきた人には通じないケースもある、ということを経験で学んだのですが「仕事なんてやって当然で、褒められるなんてことは滅多に無いんだぜ」という考えの人はまぁまぁ世の中に存在していると思います。
私は全くそう思いません。私達の仕事に「やって当たり前」の仕事なんて存在しません。誰もが、自分の人生の貴重な時間とエネルギーを使って頭を捻りながら手を動かして何かを成し遂げてくれている／何かを前進させていることは、それだけで尊敬・称賛に値すると思っています。そういう意味で、誰でもできる定形タスクも、人を選ぶ難しいタスクも、区別なく、１つ１つのタスクを対応したり／対応のフォローをしてくれた人に常に感謝や尊敬の気持ちを忘れずに持とうと思っています。
私の考える Respect は、相手に感謝する。相手を褒める。その気持ちを表に出すことで、発揮されるものだと考えます。
こんにちは。12/1 サービス基盤本部の本部長を務めている鈴木(@syou1024) です。
マネーフォワードの全社のサービスのインフラ関連の組織について、今までとこれからについて話そうと思います。同じような悩みを持つ方のヒントになったり、またマネーフォワードのSRE、インフラエンジニアに興味を持って頂けたら嬉しいです。
現在のマネーフォワードでは、全社のプロダクトのインフラを担当するサービスインフラチーム、幾つかのプロダクトの開発チームの中に存在するプロダクトのSREチームと、複数のインフラ、SREチームが存在します。
サービスインフラチームはサービ基盤本部に所属していて私が管掌しています。また、サービス基盤本部の本部長就任前にプロダクトのSREチームを一番最初に作ったのも私です。
マネーフォワードのインフラの組織が「なぜそうなってるのか？」。まずは私から見えてる歴史をお話しします。
創業から2017年頃までサービスインフラチームとプロダクトの開発チームの役割は以下でした。
責務
Pros
これによって以下のようなメリットを享受出来てました。
Cons
しかし、少し考えれば分かるのですが、これらのメリットはプロダクトの数が少ないが故に享受できたメリットです。プロダクトの数が増えるに連れ、以下のようなデメリットが出てきます。
1. サービスインフラチームに業務が集中し、開発のボトルネックに。
1. サービスインフラチームの認知負荷の限界を超え、各プロダクトの状況を掴めず、ケアできない。
こんばんは、12/26以降の年末ブログです。[Champagne]時代からのファンです。
アドベントカレンダー終わったのにまだブログ書いてるのかって思いましたか？
弊社ではいま、ある目標のために有志が集まってブログを書いています。
これもそのうちの一本です。
大丈夫、まだ2021年だ。
今年はなんだかたくさん記事を書いたなあなんて振り返りつつ、特にエモい話をする予定はありません。
今日はTensorFlowをわざわざ自分でビルドしてみたのでその話でもしようかなと。
ところで皆さんTF派？PT派？(ミスター派？洋さん派？のノリでお願いします)
いままでTensorFlowしか使ってなかったんですが、最近はもっぱらPyTorchを使うようになりました。
どうもCTO室AI推進部の@ken11です。
PyTorchを使う機会が増えたのはひとえに僕が依存しているhuggingfaceがその方が楽だからですね。
時と場合によってもちろんTensorFlowも使っています。
さて、TensorFlowをソースからビルドする方法ですが、公式ではこちらで解説されています。
このリンク読めばいいだけ、といえばそれまでなんですが、せっかくなので少し紹介したいと思います。
※Linux環境かつGPU無しが前提です
こんにちは。
マネーフォワードのセキュリティおじさん、坂本です。
当社のCSIRT「MF-CSIRT」をはじめ、セキュリティ業務全般を担当しています。
今回は、マネーフォワードの社内報『月刊マネフォセキュリティ』の取り組みについて紹介させていただきます。
社内への情報セキュリティに対する意識向上・啓蒙は、各社でも取り組んでいる活動かと思います。
当社でも定期的な全社研修などでリテラシー向上を図っていましたが、
などの課題がありました。
そこで、研修よりも効果的に、情報セキュリティを身近に感じて興味をもってもらうことを目標に、月一での発信活動を始めてみました。
2021、年の暮れからこんにちは。
サービス基盤本部インフラ部の @grezarjp です。
2021年も終わろうとしているこのときに、嬉しいニュースがあります。Terraformのrefactoringがかなりやりやすくなりました。今日はTerraform v1.1.0から導入されたmoved blocksという機能によってTerraformのrefactoringがどのように楽になったのか、その機能とともに紹介したいと思います。
まずはTerraform v1.1.0のリリースノートをご覧ください
https://github.com/hashicorp/terraform/releases/tag/v1.1.0
movedblocks for refactoring within modules: Module authors can now record in module source code whenever they’ve changed the address of a resource or resource instance, and then during planning Terraform will automatically migrate existing objects in the state to new addresses.
moved blcoksが導入され、module内でplan時点でのstateの移動が可能になったとあります。
これまでもTerraformではresource名やmodule名などを変えるようなrefactoringを伴うときに、リソースを再作成しないようにするために terraform state mv によってコードを変更後にstateの移行を行うことができました。しかし、terraform state mv にはいくつかの問題点があります。
terraform state mv する必要がある1についてはCLIベースで手続き的にstateの移行操作を行うしかなく、変更量が多いときには作業量が多くなりミスも発生しやすくなります。