皆さん、先日のJAWS-UG SRE支部#2はご覧になりましたか？
こんにちは。パネルディスカッションに５分だけ出演した @syou1024です。
いや、、、本当ごめんなさい🙇♂️🙇♂️🙇♂️🙇♂️🙇♂️
あのタイミングで家の回線が障害を起こしてしまい。。。
マンション全体で翌日15時まで回線障害で手を打ちようがなく、突然の退出になってしまいました。。
登壇前から声がブツ切れで聞こえておりちゃんと回答できるか不安を持っていたのですが、まさか全断するとは思っておらず。。
ご参加いただいた方々、ここまでご準備いただいた主催者の皆さん、本当に申し訳ないです。
そして、途中から急遽登壇してフォローしてくれた @grezarjpありがとう。
せめてもの償いとして、もしあの場にいたらどんなことを答えていたかこのブログでご回答させてください🙏
アーカイブを拝見した上で各テーマ毎に考えたことを以下に書きます。
みなさんこんにちは！
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
こんにちは。Androidアプリエンジニアのsyarihuです。
私が入社したのは2017年10月で、入社してから約4年が経過しました。マネーフォワード MEのAndroidアプリエンジニアとして、そしてスマートデバイス推進グループとしてさまざまな活動をしてきました。約4年の区切りということで、これまでの活動を時系列で振り返りたいと思います。
マネーフォワードには2017年10月に入社しました。
会社としては2社目で新卒2年半ほどからの転職だったのと、前職は主にサーバーサイドJavaエンジニアとして働きつつ、そこまで実装タスクは多くなかったもののAndroidアプリエンジニアとしても働いていました。そのため実務での経験は浅くAndroidアプリエンジニア界隈での知名度もそこまで無い時期でした。
そんな僕を、自身がプレミアムユーザーとしても利用する「マネーフォワード ME」のAndroidアプリエンジニアとして採用していただき、マネーフォワードに入社できたことはとても嬉しかったです。
マネーフォワードでは入社当初の希望通り、入社からいままで「マネーフォワード ME」のAndroidアプリ開発を主に担当してきました。
昨年からは「マネーフォワード ME」のAndroidアプリエンジニアを主務としつつも、兼務でスマートデバイス推進グループのメンバーとして、社内のモバイルアプリエンジニアの課題解決にも取り組んでいます。仕事の活動の幅を広げてさまざまな経験をさせてもらっています。
こんにちは、マネーフォワード サービス基盤本部 インフラ部に所属している中谷です。
先日、鈴木のブログにもあったように、サービス基盤本部では体制を変えていっている真っ最中です。（今までの組織体制の課題や、これからの本部としての目指す方向の詳細については、是非そちらのブログを参照してみてください。）
その新しい体制の中で “Enabling SRE” というチームが生まれるのですが、Enabling SREとはどういうチームなのか？どういう背景で生まれたのか？何をやっていくのか？ということを紹介したいと思います。SREの文化を根付かせたいけど、どうアクションすればいいかわからないといった方の参考になればいいなと思っています。
まずは背景を簡単に説明して、なぜEnabling SREが必要になったのかを知ってもらいたいなと思います。
マネーフォワードでは、初めは中央のインフラチームのみで全てのプロダクトの運用を行い、プロダクトの開発チームは機能開発に集中するという体制でした。しかしながら、プロダクトの数が増えていくにつれて、インフラチームのリソースが不足し始め、インフラチームがプロダクト開発のボトルネックになってきました。
このままでは中央のインフラチームのスケールに合わせる形でしかプロダクト開発のスピードが出せないということになってしまいます。それを回避するために、プロダクト開発の各プロダクトの開発チームに権限を渡していき、自分たちで開発のサイクルを回せるようにする必要があると考えました。そこで、権限を渡しやすいような新しい基盤を作り、プロダクト開発チームが自分たちで開発のサイクルを一貫してみれるように新しい基盤に移行をすすめていきました。
ただそういった中で、下のような別の課題が出てきました
1. 基盤をまだ作り込めていないということもあり、プロダクトの開発チームで開発サイクルを閉じていくにはまだまだ基盤上でのアプリケーションの開発/運用の技術的な難易度が高い。
2. 各プロダクトの開発チームは、自分たちで開発のサイクルを回し、非機能面も含めて見るべきだと考えている。しかしながら、権限を渡されても非機能面を見ていくための知見がないので、自分たちでみれるようになるまでにGapが存在している。
現在、一部のプロダクトは実際に中にSREチームを作り、自分たちで非機能面まで見ることができるようになってきています。しかしながら、自分たちでSREチームを作ったり、SREを実践できないチームがまだ存在しています。SREチーム立ち上げのための知見がなかったり、リソースが割けなかったり、といった課題が存在しています。
そして、主に上記の2.の課題を解決するためにEnabling SREが必要と考えました。（1.の課題に関してはPlatform SREの内容になってくるので本記事では詳細は割愛します）
こういった背景があってサービス基盤本部は体制を変えていこうと考えています。
こんにちは。マネーフォワード 関西開発拠点 村上です。
みなさん、Slack Workflow Builder 使ってますか？
左下からポチ―――って開始出来て便利ですよね。
ワークフロービルダーが新登場 : Slack で簡単にタスクを合理化
> 2019年10月15日 リリース
Slack Formで入力してもらった値って外部システムに送信したいですよね？
例えば、フィードバック管理システムや、バグトラッカー、タスク管理ツールとか。
しかしデフォルトではSlack Workflow Builderで外部送信できるものは多くありません。
自分達でツールを作ることもできますが、もう少し汎用的に使えるといいのに！！！！と悩んで2.5年経ちました。
そろそろ我々はFormの値を自由に手に入れる方法を、手に入れてもいいのでは？？？？
なんと、Zapierで神機能を見つけたことで実現することが出来たので今回筆を取りました。
公式Docがみつかってないのでどなたか見つけたら教えて下さい。またはいつの間にか動かなくなるかもしれません。
作り方は最後に掲載していますので、お時間ない方はスクロ――――ルしてください。
2021年9月に入社したエンジニアの佐藤と申します。
ビジネスカンパニーHR ソリューション本部 プロダクト開発部 クラウド人事管理グループ という部署で
マネーフォワード クラウド人事管理というプロダクトを開発しております！
初めての転職を経て約5ヶ月経ったのですが、
転職して感じたクラウド人事管理グループの感動したところを紹介したいなぁと思い書き始めました。
3点に分けて紹介したいと思います。
人事管理グループでは、継続してプロダクトを運用できる体制を維持するために「属人化を防ぐ」取り組みを行なっています。
特定の人がいないと運用が出来ない、という状況が常態化してしまうと、
配置換えや・退職が発生した場合に生産性が急激に低下し、継続的な価値提供が出来なくなってしまいます。
それを防ぐため、人事管理グループでは以下のような取り組みを行なっています。
「少人数のチームにて、一人からSREを始めるにはどうすればいいのか？」
2021年の10月からHR領域（マネーフォワードクラウド勤怠）でSRE組織を立ち上げているVTRyoです。
もっとサービスをより安定させたい！より向上したいといった話から、SREという役割を設置するケースは増えています。
しかし、SREという概念のなかったチームや部署で始めるにはどこから手をつければよいのでしょう。
SREの基本について記されたSRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチームには多くの原則が書かれていますが、同じことを丸々取り組むには前提や環境が違う部分も出てきます（SREのプラクティスを知るにはよい参考資料であることは間違いありません）。
というわけでこの記事では、以下の部分に答えられるよう進めていきます。
いいえ。会社内でもSREチームの特性は異なります。あくまでマネーフォワードクラウド勤怠におけるSREの始め方としてご参考ください。
タイトルにスモールチームとあります。マネーフォワードって小さくなくね？という認識ズレがあったまま進むと混乱するので、ここでマネーフォワードクラウド勤怠チームの状況について整理しておきます。
こんにちは。マネーフォワードでエンジニアとして働いている @sters です。普段は別の会社でフルタイム勤務していて、他の時間で マネーフォワード クラウド会計（以下、クラウド会計） のメトリクスやトレースを眺め、パフォーマンス改善をしています。
マネーフォワードでは、マイクロサービスアーキテクチャを採用した開発を進めており、多くのサービスが連携してプロダクトとその価値をユーザに届けています。詳しくはこちらの記事でどうぞ。
マネーフォワードのSRE、インフラエンジニア組織のこれから | Money Forward Engineers’ Blog
1つのサービスで1つのプロダクトを届けていたこれまでの形では、何かしらのエラーが発生したり、レイテンシが上昇するなどの問題が起きたときに、自分たちの実装やデータ、インフラストラクチャを気にするだけで十分でした。
しかし、マイクロサービスアーキテクチャとして複数のサービスが連携するようになると、1つの処理を完了するまでに何が起きているかを把握することが難しくなります。問題が起きたとき、自分たちのサービスが原因なのか、他のサービスが原因なのか、がわかりにくくなります。
この課題に対するひとつのアプローチとして、システム連携図のようなものをもったドキュメントを整えることができます。しかし、組織が大きくなれば開発の規模も大きくなり、新しい機能・新しいプロダクト・新しいサービス・新しい連携がどんどん作られます。そのたびにドキュメントを整えていくのはコストもどんどん大きくなっていきます。
どのサービスの、どんな情報を連携しようとしているのか、サービス間の連携はサービス自身が知ることができます。これがオブザーバビリティへの取り組みになります。トレースはオブザーバビリティへの取り組みのひとつで、実態を把握するために活用できます。
それぞれのサービス上で起きていることをそれぞれのサービス自身がトレースすることに加え、他のサービスへのリクエスト上へトレースに関する情報を付与することで、サービスを超えたシステム全体のトレースを取ることができます。これが分散トレーシングです。
マネーフォワードでは、主にDatadogを利用してオブザーバビリティへの取り組み、分散トレーシングを進めています。