この記事は株式会社エス・エム・エス Advent Calendar 2024の12月4日の記事です。 qiita.com 保育士人材バンク のサービスを担当しておりますエンジニアの田実と申します。 保育士人材バンクは保育業界で働く方と事業所のための就職・転職マッチングサービスです。 本記事では2024年の保育人材バンクの技術基盤改善の取り組みを振り返っていきます！ コンテナ化 今年一番大きかった基盤改善は何と言ってもコンテナ化です！コンテナ化前はEC2上にアプリケーションがホスティングされており、デプロイはrsync、ログはSSHでサーバーに入って直接ログファイルを確認、といった運用を行っていました。 EC2でホスティングされているためミドルウェアのアップグレードが気軽にできなかったり、デプロイ方法もアトミックな変更ではないためデプロイ中のアクセスがエラーになることもありました。ログの確認

介護事業者向け経営支援サービス「カイポケ」のエンジニアリングマネージャー、酒井(@_atsushisakai)です。 前回は、カイポケのフルリニューアルプロジェクトの紹介をさせてもらいましたが 、今回はローンチから17年も経過したカイポケのような大規模 SaaS プロダクトをフルリニューアルする、という大きなゴールを目指すプロジェクトに立ち向かうために、どのようなプロセスとマインドで開発を進めているのかをご紹介させていただきます。 フルリニューアルプロジェクトの特徴 まず前提として、このフルリニューアルプロジェクトは、いくつかの観点で、プロジェクトの進行難易度を高めるような特徴がいくつかあります。 作るべき「価値」が膨大に存在することが最初からわかっている このプロジェクトでは、すでに現在動いているカイポケの重要なお客様にとっての「価値」を大きく損なわないように開発を進めていかねばなりませ

こんにちは。FiNC Technologies(以下、FiNC)の サーバーサイドエンジニアをしている Ryusei （@ryusei_i_1025）です。 僕はエンジニア1年目なのですが、FiNCのマイクロサービスの最古の巨大サービスのリファクタリングをしてきました。 その内容と学びを一部ご紹介します。 FiNCでは、マイクロサービスを採用しています。 それぞれのチームがサービスのオーナーとなって、担当サービスをプロダクションレディとなるように管理しています。 大抵、マイクロサービスの中には、巨大な神サービスが存在すると思いますが、 僕が所属するチームは、2021年4月にこの最古の巨大サービスの担当になりました。 このサービスは、FiNCの歴史を物語っています。2013年に作られてから、現在までFiNCの中枢機能として、ビジネスを支えてきたサービスです。 現CEOの 南野 (@tente

こんにちは。予防ヘルスケア×AIテクノロジー（人工知能）に特化したヘルステックベンチャーFiNC TechnologiesでiOSアプリエンジニアをしています施です。台湾から日本来て、今の会社に入社し約2年が経ちました。 始めにFiNCアプリの「歩数記録機能」は初期の頃から提供している機能で、その時々で様々な改善を繰り返して来ました。そのため、いろいろな問題を抱え込んでしまっている、いわゆる「レガシーコード」のような状態になっていました。 この歩数機能を使った大きな新規開発を行う話が出ていたため、既存のコードが影響して問題が広がらないように、インターフェースの切り分けや関係性の整理などを行いました。 このような問題はよく皆さんも抱えている課題だと思いますので、 今回は、「レガシーコードとどう付き合っていくか」ということについてお話をさせていただきたいと思います。 背景2020年4月にFiN

FiNCでAndroidエンジニア 兼 スクラムマスターをしている吉田です。 日課は毎朝の散歩とラジオ体操です。 弊社では、2020年7月21日（火）に、糖質管理やアドバイスレポート機能など、ワンランク上の健康管理ができる新しいサブスクリプションサービス「FiNC Plus」をリリースしました。 FiNC Technologies、新月額サービス「FiNC Plus」を開始！ 糖質管理やアドバイスレポート機能など、ワンランク上のオンライン健康管理を月額480円で提供… 弊社ではユーザーに価値あるサービスを継続的に提供するためにアジャイル開発を取り入れているのですが、その実現方法は開発チームに委ねられています。そんな中、このFiNC Plusを開発している「dev2」というチーム(以後分かりやすく「Plusチーム」と呼びます)では、スクラムガイドに則ったスクラムでFiNC Plusを開発し、

「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ

FiNCの篠塚(@shinofumijp)です。4月からCTOを拝任しました。 本記事では1月から行ってきた「アーキテクチャレビュー」という取り組みについて紹介します。 FiNCではマイクロサービスを6年前から採用しており、順調にサービスも成長したおかげで、現在では稼働しているマイクロサービス数は50を超えるほどになりました。 マイクロサービスの採用により、限られた範囲での開発においては速度を落とさずスケールすることが可能という恩恵を得られましたが、一方でサービス数の増加は安定性、メンテナンス性をはじめとした様々な問題も生みました。その1つにアーキテクチャ全容の理解が困難になるという問題があります。例えば「ユーザが食事を投稿した際に食事アドバイスのプッシュ通知を送る」という機能1つをとっても、アドバイス管理サービスが食事投稿のイベントを検知するためにイベントを購読し、同サービスがアカウント

FiNC Technologies（以下FiNC）で SREグループのマネージャーをしている@ryok6tです。 今回は Infrastructure as Code（IaC）のお話です。 今や IaC、すなわちインフラの構成管理はコードで、というのが当たり前になっています。 しかし、以前のFiNC では全くインフラがコード管理されておらず、約50のマイクロサービスが持つ数千のAWSリソースが全て手動で作成された状態でした。 これにより生じた多くの問題に対処するため、Terraformを導入し、現在ではマイクロサービスごとに独立したstateを持った状態でコード管理されています。 この記事では、 既にある大量のインフラを、後から Terraform 管理下に入れた方法マイクロサービス x Terraform の運用Terraform の CI の運用などについて書いていきます。 *今回は「

仕事で東京出張があったので、目的の打ち合わせが終わった後にどこかに会社訪問してみたいなーと思ってtwitterで募集してみたのだが、突然だったからか、反応が悪かった。しょうがないから23時にラーメンを食べに行った。 うち来てもいいよ！という開発会社さんありませんでしょうか？ https://t.co/MuiT4eECmH— パトラッシュ@昇進エンジニア (@patorash) August 22, 2019 いきなり言われてもなかなかいいよって言ってくれるところはやっぱりないかなぁ。とりあえずラーメン食べに行くか…。— パトラッシュ@昇進エンジニア (@patorash) August 22, 2019 多分初めての日高屋。美味しかった！ pic.twitter.com/c7rhy1CLld— パトラッシュ@昇進エンジニア (@patorash) August 22, 2019 日高屋、初

This domain may be for sale!

Security JAWS 【第13回】 勉強会 での登壇資料 https://s-jaws.doorkeeper.jp/events/91099

こんにちは、FiNC Technologiesでエンジニアをしている@kenjiszkです。今回は、4/18~20に開催されたRubyKaigiの裏側でお留守番組のエンジニアたちがRailsのバージョンアップをしていた様子をお届けします。 RubyKaigiに参加している面々。今回は彼らの話はしません。なぜ開催された？弊社のアプリケーションはほとんどがRailsで書かれており、基本的にはセキュリティパッチが当たるバージョンを保つように定期的にRailsのバージョンあげを行うことにしています。また、定期開催されているサーバーサイドエンジニアの情報共有ミーティングで全Railsアプリのバージョンがどのくらいか？という確認もしています。 あれ？Rails 4.2？ 声を大にして言えませんが、Rails6のリリースが注目される昨今、Rails4がいるではありませんか！ これは一大事！ということです

こんにちは、FiNC Technologiesでエンジニアをしている@kenjiszkです。今回は、4/18~20に開催されたRubyKaigiの裏側でお留守番組のエンジニアたちがRailsのバージョンアップをしていた様子をお届けします。 RubyKaigiに参加している面々。今回は彼らの話はしません。なぜ開催された？弊社のアプリケーションはほとんどがRailsで書かれており、基本的にはセキュリティパッチが当たるバージョンを保つように定期的にRailsのバージョンあげを行うことにしています。また、定期開催されているサーバーサイドエンジニアの情報共有ミーティングで全Railsアプリのバージョンがどのくらいか？という確認もしています。 あれ？Rails 4.2？ 声を大にして言えませんが、Rails6のリリースが注目される昨今、Rails4がいるではありませんか！ これは一大事！ということです

こんにちは、FiNC Technologiesでエンジニアをやっています@kenjiszkです。2019.03.22~23の二日間に渡って開催されたRails Developers Meetup 2019に、進行/ランチ提供スポンサーとして参加しましたのでその様子について紹介したいと思います。

JAWS-UG（AWS User Group - Japan）は、日本全国に70以上の支部を持つ Amazon Web Services（以下AWS）のユーザーグループ です。… JAWS-UG（AWS User Group — Japan）が主催し、アマゾン ウェブ サービス ジャパン株式会社が後援するJAWS-UG最大のイベントです。全国のJAWS-UGメンバーが中心となってボランティアベースでイベントの企画、準備を行い、最新技術からビジネス、ライフスタイルなどAWSに関わる幅広いテーマの様々なセッションを開催するイベントとなっています。 ランチスポンサーとして参加しました

FiNCアプリは数十ものMicroservicesに分かれていますが、アプリを初めて利用した時に開始されるオンボーディングも、1つのMicroserviceとして存在しています。 チャットUIの応答式オンボーディングFiNCのオンボーディングは、会社の継続率/LTVの大部分を支えている実はFiNCアプリのオンボーディングは、内容をチューニングしただけでもアプリの継続率を1.5倍~2倍にしたり、会社の大部分の売り上げを支える企画をいくつも実現するなど、数ある中でも最も重要なMicroserviceになっています。 社内での運用ペースも凄まじく、実に半年で250回もの変更がリリースされています。リリースはデプロイを必要とせず、専用の管理画面から反映する作業は2~3分程度で行えます。 この記事ではそんなオンボーディングのMicroserviceをテーマに、以下のポイントについてまとめたいと思いま

こんにちは。FiNC Technologiesデータ分析グループ(Growth Team)/管理栄養士のTanjiです。 先日の登壇内容を書き起こしました。 オンボーディング施策で各種許可率を上げるコツや、離脱を防ぐノウハウを大公開します。 会場提供は株式会社Loco Partnersさんでした。 管理栄養士のグロースハッカー？少しだけ、自分の話をさせてください。 私は今、グロースハッカーとしてサービスを広げる仕事をしているのですが、もとはダイエットをサポートする管理栄養士でした。 FiNCでは3年間、管理栄養士としてFiNCのダイエット家庭教師というサービスに携わっており、ダイエット難民、生活習慣病予備軍、綺麗になりたい女の子…そういった方々とオンラインで直接コミュニケーションをとりながら、目標達成のためのサポートをしていました。 そんなある日、グロースハックチームへの異動という転機が訪

サーバー間 GraphQL と webmock-graphql の話 / server-to-server graphql and webmock-graphql

こんなエンジニアにおすすめ 「エンジニアとしての自分の市場価値を知りたい」 「近くにキャリア相談できる先輩エンジニアや上司がいない」 「キャリアアップしたいけど、自分に何が足りないかわからない」 「転職をしたいけど、自分の適切な評価がわからない」 「SIerからウェブに転身したいけど、不安もあって決断できない」 こんな悩みを抱えているエンジニアのみなさん、一度フラットにキャリア相談をしてみませんか？ 本イベントでは、上司でも転職エージェントでもない現役エンジニアマネージャーに1on1でキャリア相談ができます。 相談相手は、インターネット大手企業出身で現在は成長企業・スタートアップでエンジニアマネージャーとして活躍するシニア・エンジニアです。 エンジニア採用やマネージャーとしての評価・育成経験、ご自身のキャリア形成の経験から、メンターとして参加者のみなさんのキャリアパスを100%みなさんの立

きっかけこんにちは、FiNC TechnologiesでSREをしています kenjiszk です。今回はRelease Engineeringについて書きたいと思います。最近行われた2回の勉強会でデプロイシステムの話やリリースについての話をしたのですが改めてまとめてみると色々と発見があったのでブログとしてまとめてみようと思います。 Release Engineeringとは？SRE本によると、Release Engineeringとは以下の4項目の事です。 セルフサービスモデル各チームがリリースプロセスをコントロールできているかどうか。 高速性細かくて頻繁なリリースを行えているかどうか。 密封ビルドビルド処理に再現性があり、成果物に一貫性があるかどうか。 ポリシーの手順の強制正しいリリースプロセスが策定されていてそれが徹底されているかどうか。 FiNCのシステムで求められることは？前提と