こんにちは。関西開発拠点の村上です。
現在新規事業立ち上げをやっており、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の移行操作を行うしかなく、変更量が多いときには作業量が多くなりミスも発生しやすくなります。
こんにちは。
マネーフォワード CTOの中出（なかで）です。
CTOの私が、普段「なにを感じて、どんなことを考えているか」について、四半期に一回社内へ共有している内容を一部編集し、エンジニアブログに公開したいと思います。
前回はこちら：マネーフォワードCTOが考えていること（2021年9月）
People Forward本部にGlobal People Partners（以下、GPP）という組織を立ち上げました。
この組織は前回のエンジニア組織の英語化で触れていた「今後の具体策」の1つです。
GPPは、日本語話者も非日本語話者もマネーフォワードで等しい従業員体験ができて、等しく活躍いただけるようにすること、そして言語を問わずに全ての従業員がお互いを尊重し、協力して仕事できるようにすることがミッションの組織です。
通訳・翻訳などを通して社内コミュニケーションのサポートを担うLanguage Specialistと、入国手続きやオンボーディング対応を主業務とするGlobal HR Operationsとしての機能をもっています。
グローバルエンジニアの採用を牽引してくれているメンバーにGPPのリーダーを兼務してもらい、新たに2名のLanguage Specialistにも入社いただきました。
お二人とも英語が母国語ですが日英のバイリンガルで、GPPのミッションに共感してジョインしてくれています。
今後の予定として、朝会などの日本語による発信を非日本語話者向けに英語で通訳いただいたり、英語化を開始した開発チームで英語でのコミュニケーションスキルが十分でないメンバーのサポートをお願いします。
また、GPPメンバーの採用強化も並行して進めています。
GPPのミッションに共感し、必要なスキルを有していてる方々の採用を継続して強化推進していきます。
こんにちは。
マネーフォワードのgotoken（@kennygt51）です。
インフラの基盤更改や新規サービスのリリースなど、普段の機能リリースとは違った規模の大きい作業がおこなわれる際には、その作業の全体像やスケジュールを整理するために、リリース計画を立てることがあります。
リリース計画が必要とされる規模の作業は、これまで数多くのITサービスでおこなわれてきたはずです。しかし、リリースを成功させるためのリリース計画を立てるノウハウが体系的にまとまった資料は数少なく、計画を策定する担当者の経験に依存しがちです。
この記事では、大規模なリリース計画を立てる上で重要だと感じた守るべき心がけを列挙するものです。もちろんリリースの規模や特性によって「絶対に守ったほうがいいこと」「そこまでやらなくてもいいこと」があると思いますので、すべてを鵜呑みにすることなく、適宜読み替えてください。
新規サービスのリリースなど、関係者が多岐に渡る大きなリリースを控えるエンジニアに、是非一読頂きたいです。
これだけは絶対に意識して欲しい点なので、一番最初に挙げることにしました。ここまで読んでくれたのなら、この記事の目的は9割達成されたといっても過言ではありません。
リリース計画の中で一番大切なのは何か問題が発生した時の切り戻しの計画です。「切り戻し」とは、リリース作業中に問題が発生した時にリリース作業を中止し、リリース作業を始める前の状態にシステムを
ロールバックすることを指します。