【全力土下座案件】JAWS-UG SRE支部#2登壇の件

皆さん、先日のJAWS-UG SRE支部#2はご覧になりましたか?

こんにちは。パネルディスカッションに5分だけ出演した @syou1024です。

いや、、、本当ごめんなさい🙇‍♂️🙇‍♂️🙇‍♂️🙇‍♂️🙇‍♂️

あのタイミングで家の回線が障害を起こしてしまい。。。
マンション全体で翌日15時まで回線障害で手を打ちようがなく、突然の退出になってしまいました。。
登壇前から声がブツ切れで聞こえておりちゃんと回答できるか不安を持っていたのですが、まさか全断するとは思っておらず。。

ご参加いただいた方々、ここまでご準備いただいた主催者の皆さん、本当に申し訳ないです。
そして、途中から急遽登壇してフォローしてくれた @grezarjpありがとう。

せめてもの償いとして、もしあの場にいたらどんなことを答えていたかこのブログでご回答させてください🙏
アーカイブを拝見した上で各テーマ毎に考えたことを以下に書きます。

続きを読む

0からはじめる社内勉強会〜がんばれQAエンジニア!〜

みなさんこんにちは!
HRソリューション本部でQAエンジニアをしてます。honaminです。
とつぜんですが、みなさんの職場では「社内勉強会」なるものが行われていますか?

マネーフォワードでは毎月多くの社内勉強会が行われており、「誰でも参加OK!主催OK!」という環境が整っています。また、社内勉強会カレンダーがあり、ビジネス、開発という枠組みにとらわれず、さまざまな種類の勉強会が共有されています。興味がある勉強会があればいつでもチェックして参加することが可能です。

社内勉強会の詳細はこちら
社内勉強会カレンダーのご紹介

せっかくこんなに恵まれた環境があるので、わたしも何かいっちょ勉強会やってみるか!
とおもって始めたのが「JSTQB FL* 勉強会」(全8回、2021年10月〜2022年2月まで実施)でした。今回は勉強会運営も含めた課題と実践について書いてみます。

*JSTQB FL(Foundation Level)
JSTQB(Japan Software Testing Qualifications Board)が運営している、資格認定制度の資格試験のひとつ。ISTQB(International Software Testing Qualifications Board)を通じて、アメリカやイギリス、ドイツなどのISTQB連携のテスト技術者資格と相互認証を行っているため、海外でも使える国際資格。ソフトウェアテストとはなんぞや、という基本的なところを一通り学ぶことができる。

シラバス無料はこちら
http://jstqb.jp/syllabus.html#syllabus_foundation

続きを読む

入社から約4年、Money ForwardのAndroidアプリエンジニアとしての活動を振り返る

こんにちは。Androidアプリエンジニアのsyarihuです。
私が入社したのは2017年10月で、入社してから約4年が経過しました。マネーフォワード MEのAndroidアプリエンジニアとして、そしてスマートデバイス推進グループとしてさまざまな活動をしてきました。約4年の区切りということで、これまでの活動を時系列で振り返りたいと思います。

syarihuの簡単な自己紹介

マネーフォワードには2017年10月に入社しました。
会社としては2社目で新卒2年半ほどからの転職だったのと、前職は主にサーバーサイドJavaエンジニアとして働きつつ、そこまで実装タスクは多くなかったもののAndroidアプリエンジニアとしても働いていました。そのため実務での経験は浅くAndroidアプリエンジニア界隈での知名度もそこまで無い時期でした。
そんな僕を、自身がプレミアムユーザーとしても利用する「マネーフォワード ME」のAndroidアプリエンジニアとして採用していただき、マネーフォワードに入社できたことはとても嬉しかったです。

マネーフォワードでは入社当初の希望通り、入社からいままで「マネーフォワード ME」のAndroidアプリ開発を主に担当してきました。
昨年からは「マネーフォワード ME」のAndroidアプリエンジニアを主務としつつも、兼務でスマートデバイス推進グループのメンバーとして、社内のモバイルアプリエンジニアの課題解決にも取り組んでいます。仕事の活動の幅を広げてさまざまな経験をさせてもらっています。

続きを読む

組織にSREの文化を作り上げていくEnabling SRE

こんにちは、マネーフォワード サービス基盤本部 インフラ部に所属している中谷です。
先日、鈴木のブログにもあったように、サービス基盤本部では体制を変えていっている真っ最中です。(今までの組織体制の課題や、これからの本部としての目指す方向の詳細については、是非そちらのブログを参照してみてください。)
その新しい体制の中で “Enabling SRE” というチームが生まれるのですが、Enabling SREとはどういうチームなのか?どういう背景で生まれたのか?何をやっていくのか?ということを紹介したいと思います。SREの文化を根付かせたいけど、どうアクションすればいいかわからないといった方の参考になればいいなと思っています。

はじめに

まずは背景を簡単に説明して、なぜEnabling SREが必要になったのかを知ってもらいたいなと思います。

サービス基盤本部の体制変更の背景

マネーフォワードでは、初めは中央のインフラチームのみで全てのプロダクトの運用を行い、プロダクトの開発チームは機能開発に集中するという体制でした。しかしながら、プロダクトの数が増えていくにつれて、インフラチームのリソースが不足し始め、インフラチームがプロダクト開発のボトルネックになってきました。

このままでは中央のインフラチームのスケールに合わせる形でしかプロダクト開発のスピードが出せないということになってしまいます。それを回避するために、プロダクト開発の各プロダクトの開発チームに権限を渡していき、自分たちで開発のサイクルを回せるようにする必要があると考えました。そこで、権限を渡しやすいような新しい基盤を作り、プロダクト開発チームが自分たちで開発のサイクルを一貫してみれるように新しい基盤に移行をすすめていきました。

ただそういった中で、下のような別の課題が出てきました
1. 基盤をまだ作り込めていないということもあり、プロダクトの開発チームで開発サイクルを閉じていくにはまだまだ基盤上でのアプリケーションの開発/運用の技術的な難易度が高い。
2. 各プロダクトの開発チームは、自分たちで開発のサイクルを回し、非機能面も含めて見るべきだと考えている。しかしながら、権限を渡されても非機能面を見ていくための知見がないので、自分たちでみれるようになるまでにGapが存在している。

現在、一部のプロダクトは実際に中にSREチームを作り、自分たちで非機能面まで見ることができるようになってきています。しかしながら、自分たちでSREチームを作ったり、SREを実践できないチームがまだ存在しています。SREチーム立ち上げのための知見がなかったり、リソースが割けなかったり、といった課題が存在しています。

そして、主に上記の2.の課題を解決するためにEnabling SREが必要と考えました。(1.の課題に関してはPlatform SREの内容になってくるので本記事では詳細は割愛します)

こういった背景があってサービス基盤本部は体制を変えていこうと考えています。

続きを読む

ZapierでSlackMessageをParseして外部システムとつなぐ

こんにちは。マネーフォワード 関西開発拠点 村上です。

みなさん、Slack Workflow Builder 使ってますか?
左下からポチ―――って開始出来て便利ですよね。

ワークフロービルダーが新登場 : Slack で簡単にタスクを合理化

> 2019年10月15日 リリース

Slack Formで入力してもらった値って外部システムに送信したいですよね?
例えば、フィードバック管理システムや、バグトラッカー、タスク管理ツールとか。

しかしデフォルトではSlack Workflow Builderで外部送信できるものは多くありません。
自分達でツールを作ることもできますが、もう少し汎用的に使えるといいのに!!!!と悩んで2.5年経ちました。

そろそろ我々はFormの値を自由に手に入れる方法を、手に入れてもいいのでは????
なんと、Zapierで神機能を見つけたことで実現することが出来たので今回筆を取りました。

公式Docがみつかってないのでどなたか見つけたら教えて下さい。またはいつの間にか動かなくなるかもしれません。
作り方は最後に掲載していますので、お時間ない方はスクロ――――ルしてください。

続きを読む

入社5ヶ月して感じた、スモールチームでスピード開発を実現するクラウド人事管理グループの感動したところ


2021年9月に入社したエンジニアの佐藤と申します。
ビジネスカンパニーHR ソリューション本部 プロダクト開発部 クラウド人事管理グループ という部署で
マネーフォワード クラウド人事管理というプロダクトを開発しております!

初めての転職を経て約5ヶ月経ったのですが、
転職して感じたクラウド人事管理グループの感動したところを紹介したいなぁと思い書き始めました。
3点に分けて紹介したいと思います。

1. 属人化を防ぐ取り組み

人事管理グループでは、継続してプロダクトを運用できる体制を維持するために「属人化を防ぐ」取り組みを行なっています。
特定の人がいないと運用が出来ない、という状況が常態化してしまうと、
配置換えや・退職が発生した場合に生産性が急激に低下し、継続的な価値提供が出来なくなってしまいます。
それを防ぐため、人事管理グループでは以下のような取り組みを行なっています。

  • 実装共有会を開き、自分の担当した機能の設計や実装について共有を行う
    • ナビゲーター、ドライバーという役割で詳しい人とそうでない人のペアを組み、ナビゲーターはドライバーを導く形で共有を行っています
  • スクラム開発を行い、誰がどのタスクを行なっても良い状況を作る
    • タスクはチーム全体のタスクとして扱い、「特定の人しか出来ないタスク」を作らないようにしています
    • 一方で、現実的には「アーキテクチャ設計・基盤実装」のようなテックリードクラスでないと難しいタスクもありますが、参考になる実装を行ったらそのパターンを別の機能で横展開したりと、その状態が続き過ぎないように努力しています
  • 技術文書の整備を行う
    • プロダクト仕様書、テスト仕様書のようなドキュメンテーションの整備を行なっています
    • アクセスしやすいようにディレクトリを整備したり、誰が見ても分かりやすいような文章になるように意識して整備しています
    • 一見地道な作業ですがドキュメントが整備されていることで、人が変わってもすぐに運用が引き継げるようにする狙いがあります(引き継いだプロダクトの資料が全くなく、慣れるまでに苦労した。という方もいらっしゃるのではないでしょうか…)
    • 「アジャイル開発においては動くプロダクト作りを優先すべきでは?」という観点もありますが、ドキュメントを整備することで長期的な生産性、開発スピードの維持に繋がると考えています
  • 特定のロールの人が欠けても回る状況を作る
    • テックリード、グループリーダーのような役割を担う人を2人はいる体制を作ることで、1人が欠ける状況でも良い意味で替えが効く体制を絶賛構築中です

続きを読む

How to start SRE in a small team, all by yourself.

「少人数のチームにて、一人からSREを始めるにはどうすればいいのか?」

2021年の10月からHR領域(マネーフォワードクラウド勤怠)でSRE組織を立ち上げているVTRyoです。
もっとサービスをより安定させたい!より向上したいといった話から、SREという役割を設置するケースは増えています。

しかし、SREという概念のなかったチームや部署で始めるにはどこから手をつければよいのでしょう。

SREの基本について記されたSRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチームには多くの原則が書かれていますが、同じことを丸々取り組むには前提や環境が違う部分も出てきます(SREのプラクティスを知るにはよい参考資料であることは間違いありません)。

というわけでこの記事では、以下の部分に答えられるよう進めていきます。

  • SRE本を読んだが、実際の組織やチームではどこから手を付けて良いのか悩ましい
  • 成熟したSRE組織の事例を見てもリッチすぎる故、ギャップが有って悩ましい
  • 実際の初期立ち上げ時、何から手を付けたのか事例が知りたい
これはマネーフォワード全社におけるSREチームの話ですか?

いいえ。会社内でもSREチームの特性は異なります。あくまでマネーフォワードクラウド勤怠におけるSREの始め方としてご参考ください。

環境と前提

タイトルにスモールチームとあります。マネーフォワードって小さくなくね?という認識ズレがあったまま進むと混乱するので、ここでマネーフォワードクラウド勤怠チームの状況について整理しておきます。

続きを読む

Datadogを使った分散トレーシングをクラウド会計で見えるようにした話

こんにちは。マネーフォワードでエンジニアとして働いている @sters です。普段は別の会社でフルタイム勤務していて、他の時間で マネーフォワード クラウド会計(以下、クラウド会計) のメトリクスやトレースを眺め、パフォーマンス改善をしています。

なぜ分散トレーシングが必要なのか

マネーフォワードでは、マイクロサービスアーキテクチャを採用した開発を進めており、多くのサービスが連携してプロダクトとその価値をユーザに届けています。詳しくはこちらの記事でどうぞ。

マネーフォワードのSRE、インフラエンジニア組織のこれから | Money Forward Engineers’ Blog

1つのサービスで1つのプロダクトを届けていたこれまでの形では、何かしらのエラーが発生したり、レイテンシが上昇するなどの問題が起きたときに、自分たちの実装やデータ、インフラストラクチャを気にするだけで十分でした。

しかし、マイクロサービスアーキテクチャとして複数のサービスが連携するようになると、1つの処理を完了するまでに何が起きているかを把握することが難しくなります。問題が起きたとき、自分たちのサービスが原因なのか、他のサービスが原因なのか、がわかりにくくなります。

この課題に対するひとつのアプローチとして、システム連携図のようなものをもったドキュメントを整えることができます。しかし、組織が大きくなれば開発の規模も大きくなり、新しい機能・新しいプロダクト・新しいサービス・新しい連携がどんどん作られます。そのたびにドキュメントを整えていくのはコストもどんどん大きくなっていきます。

どのサービスの、どんな情報を連携しようとしているのか、サービス間の連携はサービス自身が知ることができます。これがオブザーバビリティへの取り組みになります。トレースはオブザーバビリティへの取り組みのひとつで、実態を把握するために活用できます。

それぞれのサービス上で起きていることをそれぞれのサービス自身がトレースすることに加え、他のサービスへのリクエスト上へトレースに関する情報を付与することで、サービスを超えたシステム全体のトレースを取ることができます。これが分散トレーシングです。

マネーフォワードでは、主にDatadogを利用してオブザーバビリティへの取り組み、分散トレーシングを進めています。

続きを読む