株式会社エス・エム・エス Advent Calendar 2024 シリーズ 2の12月19日の記事です。カイポケリニューアルプロジェクトでエンジニアリングマネージャーをしている荒巻( @hotpepsi )です。この記事では、カイポケリニューアルプロジェクトでのフロントエンドチームの2年間の活動をお伝えしたいと思います。 qiita.com フロントエンドチームの発足 2022年末、ユースケースをもとに、フロントエンドとバックエンドそれぞれで開発していくことになり、フロントエンドチームが発足しました。 詳しい経緯はこちら: 大規模SaaS 「カイポケ」の未来を支えるフロントエンドの技術選定 二つのアプリケーションと土台の検討 プロジェクトの最初のターゲットとして、二つのアプリケーションから着手していくことが決まりました。 共通部分を見据えて、まずはデザインシステムや開発ガイドライン、ディレクトリ構成の検討やテストライブラリの導入など、土台を整備するところからスタートしました。 デザインシステムやコロケーションなどを採用しました。 必要最小限の構成のNext.js アプリケーションを構築するにあたり、レンダリング方法やデプロイ方法が選択できるフレームワークとしてNext.jsやNuxtを検討し、土台のフレームワークとしてNext.js、GraphQLのクライアントとしてApollo Clientを採用しました。 まずは、できるだけシンプルにPages Routerでクライアント側のレンダリングのみで開発していきました。静的ファイルをCloudFrontで配信しており、リダイレクトとCloudFront Functionを活用することでDynamic Routesもハンドリングできるので、いまのところ配信用のNode.jsも不要になっています。 デザインシステム デザイナー陣は、UIドラフトから決定稿までをFigma上で作成しています。デザイナーの意図通りのUIを実現するため、FigmaとReactコンポーネントの双方で利用可能なデザインシステムを整備することにしました。コンポーネント名を揃えて、フォントやトークンなどがそのまま使えるようにしたので、Figmaが実装後のレビューやQAチームの確認にも使えるようになっています。 フロントエンドの実装としては、Chakra UIをベースとして、StorybookとChromaticでカタログを構築しています。 コロケーション 当初はテストを __tests__ に置くなどしていたのですが、コンポーネントが増えていくことに伴い、テストやGraphQLのファイルを別のディレクトリに置くと、いちいち探す手間がかかるので、同じディレクトリに置くことにしました。(このブログ記事などを参考にしました。 https://www.mizdra.net/entry/2022/12/11/203940 ) pageExtensions に page.tsx を指定して、ページのディレクトリにストーリー ( .stories.tsx ) も配置しています。 @graphql-codegen/near-operation-file-preset を導入することでGraphQLのファイルもコンポーネントのディレクトリに配置できるようになりました。 その他 そのほか、たくさんの技術的チャレンジがありました。そのあたりは去年のアドベントカレンダーの記事「 フロントエンドチームで今年やったこと100 」に書きました。 長期的な技術課題への取り組み：Tech Lead Teamの発足 2023年も半ばが過ぎ、アプリケーションの開発が進み、デザインシステム・CI/CD・テスト・feature flagなど、リリースを見据えた技術的課題がどんどん出てきました。とはいえ日々の開発では、新しい機能を開発してプロダクトを前進させることに意識が向いており、急ぎの問題は気づいた人が対処したりしていました。 アプリケーション毎のチームで開発を進めていく中で、フロントエンド共通の長期的な技術課題に取り組んでいく必要性が出てきたものの、横断的組織やテックリードといったロールを置いていませんでした。 そこで、横断的技術イシューをピックアップし、それぞれのイシューごとにミニチームを組成する「Tech Lead Team」という枠組みをEMの @atsushisakai が提案しました。チームとしてテックリードの役割を担うことで、チームで議論しながら課題解決し、集合知として蓄積していくことができる仕組みです。 Tech Lead Team 第一期の活動 初期のTech Lead Teamとしては、3ヶ月間で以下のようなことに取り組みました。 デザインシステムの現状のおさらいと、ロードマップや運用方針の策定 Chakra UIの現状やロードマップ、周辺ライブラリの調査と、別のライブラリに乗り換えるべきかの検討 WCAGなどアクセシビリティのガイドラインの調査や、プロダクトへの適用検討の土台として、ペルソナを設定 デザイナーの主なツールであるFigmaに関して、仕様のやりとりなどの運用上の課題の整理や、より良い連携方法の検討 カイポケの過去・現在・未来を見据えて、長期的にチームの指針となるような原則や実装方針の整理や議論 週あたりでは数時間の活動ではありますが、長期的にプロダクトを育てていくにあたっての様々な課題が明らかになりました。 Tech Lead Team 第二期の活動 Tech Lead Team第二期では、Design EngineeringとDevOpsという二つの分野で活動しました。 Design Engineering Figma APIでテキストやコメントを取得して、状態を管理したりlintにかけたりすることの実用性について検討 デザインシステムをチームとして運用していく体制の準備 高さやシャドウの他社事例の調査や定義 アクセシビリティの検査方法の検討 DevOps pull requestのメトリクスを可視化して、チーム開発やオンボーディングがうまくいっているかどうかなどを分析 Lighthouseでボトルネックを調査し、バンドルサイズの削減に着手 Jestの結果をQAチームが見やすいように整形してみる試行 別のUIライブラリに部分的に置換していけるかどうかの実験 Tech Lead Team 第三期の活動 第三期では、重要度のファクターを議論し、次のリリースマイルストーンで必要になりそうな課題や、開発体験や品質を上げる取り組みの優先度を上げて取り組みました。 Webフロントエンド版DX Criteriaをみんなでスコアリングした。毎週45分、Miro上で議論しながら1/4ずつ進めていった 現在取り組んでいるプロダクトのフロントエンドの非機能要件について、網羅的にまとめた 導入したものの、現時点では最善ではないライブラリからの脱却 ページヘッダのパターンの整理と共通レイアウトの整備 見た目の階層の整理と、ボックスシャドウのトークンの定義 フォントを極大サイズにしたときの崩れの修正 まとめ フロントエンドチームが発足して2年ほど経ちました。日々の活動としては職能横断のチームで活動しており、もはや一つのチームではないのですが、引き続き夕会や技術雑談などで全体でも会話する機会を持っています。 活動を振り返ってみて、フロントエンド領域はデザイナーとの連携、アクセシビリティ、パフォーマンス、開発体験など、幅広い視点を持つことの重要性が再認識できました。特にSaaSでは、短期的にはフィードバックを得ながら更新していきつつ、長期的には一貫性やメンテナンス性を保ち、より良いものへ置き換えていくなど、短期と長期のバランスを取る必要があります。 このようにエス・エム・エスは、長く使われるプロダクトへの経験が積める環境です。そして、土台は見えてきたものの、実はまだまだ、作りたいものが山積みな状況です。フロントエンドだけでなく、様々なポジションで開発メンバーを募集しています。興味を持った方は、ぜひお気軽にお声がけください。

この記事は株式会社エス・エム・エス Advent Calendar 2024の12月18日の記事です。 qiita.com こんにちは、株式会社エス・エム・エスで全社の業務改善を推進するBPR推進部で責任者をしている稲留（いなどめ）です。今日はAdvent Calendarの場を借りて、エス・エム・エスのBPR組織についてお話したいと思います。 まずはじめに、簡単な自己紹介 大学卒業後のファーストキャリアはSIerで、エンジニアとITコンサルタントとして、合計10年程度キャリアを積み重ねました。その後、事業会社で全社横断プロジェクトの推進や事業管理・管理会計・人事などのバックオフィス部門を経験し、2015年にエス・エム・エスにjoinしました。 現在は、BPR領域の責任者として、BPR推進部の戦略策定や浸透、人の採用や組織マネジメント、各種PJTの実行支援などを担当しています。 BPR推進部の具体的な仕事としては、事業部門の人達と共に、業務改善施策の企画や実行、PaaSやSaaSを中心とした業務システムの構築・導入・運用によって事業パフォーマンスの向上に貢献したり、会計、人事、法務、総務などのコーポレート部門の業務遂行や部門横断の意思決定を支えるシステム基盤を構築したりして、事業の拡大と会社の成長のために日々取り組んでいます。エス・エム・エスでBPRと呼んでいる領域は、会社によってはBizOpsやコーポレートITと呼ばれていることもあるかもしれないので、読者の皆さんの会社の事例に当てはめて、適宜読み替えて頂ければと思います。 事業の成長と会社の発展を支えるためのシナジーを最大化し従業員の生産性を向上するのがBPRのミッション エス・エム・エスの成長の道筋 エス・エム・エスが事業活動しているのは高齢社会マーケットです。少子高齢人口減少社会の日本においては、価値提供先の一つである高齢者が2040年までは増え続けることが確定しているため、継続的に拡張する成長市場であり、それゆえに強い競合プレイヤーも多数存在している熾烈な競争環境でもあります。そのような成長市場のなかで、競争に勝ち抜いて事業を拡大し、複数の事業領域を展開したり、多様なビジネスモデルをさまざまな国や地域で展開し、事業者◦従事者◦エンドユーザに重層的なサービスを提供する規模となることで、社会課題を解決できるようになると考えています。エス・エム・エスではそのような成長過程を通じて、ミッションとして掲げている『 高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける 』ことを目指します。 エス・エム・エスのミッションについては コーポレートサイト を参照 それぞれの事業が単体で顧客の課題を解決し、ビジネスとしても成長し続けることを目指しながら、同時に、エス・エム・エスという会社がそれらの事業を運営している意味合いを考えて、その効果を最大限発揮できるようにする必要があります。それは、主要事業で得た利益を新規事業に投資したり、会社全体の信用力を背景に資金調達をしたり、という財務的な側面もあれば、多角化経営をしているからには活かしていかないといけない、事業間シナジーの積極的活用と推進といったものまで、様々あります。BPRでは、この事業間シナジーがしっかりと発揮される状態を目指して活動をしています。 シナジーを最大化するとは、具体的にどういうことか？ エス・エム・エスという会社と、各事業がベストなペアとしてあり続けるためには、各種コーポレート機能が高い専門性を持って各事業をサポートして事業パフォーマンスを最大化することと、各事業が有している顧客情報やブランドなどの戦略的な資源を相互に活用したり、営業やマーケティングが持っている仕組みや知見などのケイパビリティを利用して事業領域を拡張することが重要です。 コーポレート領域では世の中的に多くのSaaSが溢れているので、それらのITツールをうまく活用して効率的に業務を遂行しながらも、事業活動や組織状態に関する情報を適切に蓄積し、事業支援や意思決定支援ができるようにすることが求められます。また、非エンジニアが多い領域なので、彼らの生産性を向上させるために生成AIなどのツールを導入したり、活用のリテラシーを高めたり、安全に使えるようなガイドラインをつくることで、個々の従業員の生産性を最大化することも重要になります。 事業間シナジーの領域では、ビジネスモデル毎にEnd-to-Endでのビジネスプロセスの改革を事業責任者やプロダクトマネジャー等と共に検討・推進しながら、事業間で共通する顧客情報を全社的に活用できるように情報設計、システム設計をしたり、事業間でのクロスセルが進むような連携施策の推進などが具体的な仕事内容になってきます。 事業の拡大と会社の発展を両立させるBPR組織に求められるケイパビリティ 経路依存性が高く複雑に絡み合った課題を解決するために、全体最適で物事を考える 顧客からの期待や要望を受け取って、様々な職種の人達が多様な専門性を発揮して顧客にサービス提供する一連の仕事の流れは、社内の多くの部署が情報のやり取りや加工をしながら進んでいきます。 よって、ある部門の、特定のプロセスにおける、個別のシステムだけを改善しても成果にはつながりません。多くのステークホルダーがそれぞれの目線で要求を提示する中で、それらがしっかりと顧客への価値提供につながるものなのか見極めて、優先度合いを決定し、実行に移していかねばなりません。 また、プロセス、システム、データ、組織、ルールやポリシーなどが複雑に絡み合って仕事は成り立っているので、様々な観点で検討し、最適と思われるソリューションを見出して、一体となった改革・改善を進めていかないといけません。 そのためには、特定のissueに対して個別最適だけで物事を考えるのではなく、単独の事象が起こる背景や構造を俯瞰で捉えて、対処する必要があります。 クロスファンクションでのプロジェクト遂行 そのような全体最適の視点をもって仕事を進めていくためには、対処するBPRのメンバーが幅広いissueに対応するための知見を持っているのが大前提ですが、すべてをBPRだけで実行するのは難しく、足りない知見をビジネスサイドのメンバーから引き出したり、様々な職種の専門家と連携したりして、進めることが求められます。Issueに対してプロジェクトをセットアップし、社内外の専門家や担当者と適切な役割分担を設定し、プロジェクトを遂行していきます。 そのような部門横断のプロジェクトを推進するBPR組織には、様々なメンバーがいます。価値提供先である事業やコーポレート機能を深く理解して、共に戦略を立案したり、施策を実行したりするビジネスアーキテクト、Salesforceやkintoneなどの特定のPaaSの構築・運用から、それらではカバーできない領域のシステムをフルスクラッチで構築したり、データ蓄積や分析のための基盤を構築したりする様々な専門性も持つエンジニア、多くのステークホルダーが関わるプロジェクトを企画実行するプロジェクトマネージャー、日々のシステムの運用を支えるシステムアドミン、従業員の問い合わせに対応するヘルプデスクなど、それぞれが持つ特性や専門性を活かしてチームとして動いています。 BPR組織で働くことのやりがい 業務改革や改善のプロジェクトを推進することは楽な仕事でありませんが、事業間連携やクロスセル施策の推進は直接的な売上の向上につながりますし、作業の自動化や効率化によって無駄な時間を大幅に削減することは、コストの削減や利益貢献につながり、BPRではそれらの成果を身近に感じることが出来ます。 また、社内には立ち上げ期、拡張期、規模化期、変革期などの様々なフェーズの事業が併存しているため、夫々で異なる業務遂行上のissueに触れることができるのは、単一サービスやプロダクトを提供している会社では味わうことができない、純粋に面白い経験です。そして、自分が構築や運用に携わっている事業活動を支援する業務システムに対して、社内の人から直接フィードバックがもらえることはとても励みになります。さらに、それらの事業支援文脈における直接的、具体的なやりがいや貢献だけでなく、中長期で事業が継続的に発展する会社の仕組み作りにもチャレンジすることが出来ることも、BPR組織で働く魅力の一つだと思います。 ビジネスアーキテクトの仕事については西田さんのブログを参照 ビジネスアーキテクト × Salesforce：改善だけで終わらない、戦略推進と戦術実行を追求する - エス・エム・エス エンジニア テックブログ データエンジニアの仕事については、橘さんのブログを参照 Google Cloudを活用したキャリア事業のデータ分析基盤 - エス・エム・エス エンジニア テックブログ おわりに 本記事では、多様なビジネスモデルをもつ成長企業におけるBPR組織のミッションやケイパビリティについてご紹介しました。ご紹介したとおり、BPRでは、ビジネスアーキテクト、プロジェクトマネージャー、Salesforceエンジニア、データエンジニアなど、様々な能力を持つメンバーが仕事を行っており、多くのポジションで積極採用を進めています！ 事業拡大や会社成長のための、業務改革や改善にチャレンジしたい皆様の応募をお待ちしています。一見すると業務内容が分かりにくいところがあるかもしれません。そのような場合は、カジュアル面談にて、お話しできればと思いますので、ぜひ、ぜひこちらのページものぞいてみてください！

この記事は株式会社エス・エム・エス Advent Calendar 2024の12日目の記事です。 エス・エム・エス BPR推進部キャリア横断開発グループ 事業者コミュニケーションチームの井上です。この記事では、私たちのチームが直面していた課題、改善に向けた取り組み、そしてその成果についてお話しします。 チームの概要と背景 私たち事業者コミュニケーションチームは、エス・エム・エスの人材紹介サービスをご利用いただいて働き手を探している事業所の求人情報を管理し、弊社のキャリアパートナーを通じて転職を検討している求職者の皆様へより適切な提案が出来るよう支援するチームです。 だからこそ、求人情報を正しく管理した上で最新の情報が入るようにシステムを担保し、迅速な価値提供を目指しています。 しかし、今までの取組み方では以下の課題により、迅速な価値提供が実現できていませんでした。 直面していた課題：3つの不透明 価値提供に時間がかかっていた背景には、以下の「3つの不透明さ」がありました。 1. 実装方針が不透明 チームリーダーが開発案件を開発メンバーに割当て、要件定義書と大まかな設計図を渡し、詳細な実装方法についてはメンバーが検討して決めていました。 実装方法の内容や進捗の確認についてはリーダーとメンバーが1対1のMTGで行っており、他のメンバーへの共有もありませんでした。これにより、以下の問題が発生しました。 メンバーが実装方法に悩んでいたとしても、相談相手がリーダーしかおらず、リーダーがボトルネックになり、開発が円滑に進まない メンバーが長期不在になった場合、開発が止まってしまう 2. 進捗状況が不透明 進捗確認はリーダーと夫々の案件を担当するメンバーが１対１で行っており、MTGをしないと順調なのか、遅れているのか分からない状態でした。そのため、以下の問題が発生していました。 定期的なMTGがないことで開発の遅延や問題の早期発見が出来ない チームリーダーが進捗把握するために不定期なMTGが日常茶飯事で発生するため、メンバーの活動時間が削られてしまう 3. 知識・経験が不透明 開発メンバーの活動内容がチームに共有されていないことで、以下の問題が発生していました。 特定の案件に経験がある人が継続して同じ案件に携わることで属人化していた 業務を別のメンバーに引き継ぐ際、該当業務に関連する資料が見つからず改めて作成していたが、実は社内のドライブに保存されていた ３つの不透明が相互に影響し合い、チーム全体の効率が低下してしまうことで迅速な価値提供が実現出来ていませんでした。 課題解決への取り組み 私たちは以下の施策で課題解決に取り組みました。 1. 実装方針の「見える化」 リファインメントイベントの導入 新たに生み出したい価値をチーム全員で話し合う時間を設けました。リーダーがステークホルダと話し合った内容をチームに説明し、チームが実現方法を話し合い、全員で合意するための時間です。 これにより、実装方法に悩んだ時はリーダーと相談ではなくチームメンバー同士で話し合い、解決できるようになりました。 完了要件の記入 「開発が完了したといえる状態とは何か」を明記するようにしました。これがあることでリーダーが実現したい状態と出来上がった機能のずれをなくすと同時に、メンバーが休んだときに他のメンバーが何をすべきかがわかり、実装を進めることができるようになりました。 2. 進捗状況の「見える化」 JIRAボード機能の活用 開発タスクを小さなチケットに細分化し、開発の進捗状況を「未着手」「対応中」「リリース待ち」「完了」などのステータスで管理し、一目でわかるようになりました。 デイリースタンドアップの実施 チームで毎朝の１５分、JIRAボードを見ながら進捗やブロッカー（開発が進んでない状態）をメンバー全員に相談するようにしました。問題の早期発見に繋がり、手が空いたメンバーが他のメンバーを支援することが容易になりました。 3. 知識・経験の 「見える化」 作成した資料をチケットに集約 JIRAのチケットに仕様書や試験書など関係する資料を関連付けることを始めました。これにより引き継ぎも容易になり、特定のメンバー以外でも開発内容を把握できることで、属人化から抜け出すこともできるようになりました。 課題解決による成果 実装方法、進捗状況、知識・経験をチーム全体で共有できた結果、課題解決前の月毎のリリース数の平均が12件に対し、解決後は月平均20件まで増加しました。これにより、以前よりも多くの数の求人情報に最新の情報が入るようにシステムを担保し、迅速な価値提供を目指しています。 今後の展望 知識・経験の「見える化」により、属人化を一定程度解消することができましたが、完全には解消に至っていません。 チームがシステムを適切に担保し、迅速な価値提供を継続するためには、属人化の解消が必要不可欠です。 属人化が生じていた原因である特定業務への知識・経験の偏りを解消するため、今後は開発業務のローテーションや勉強会の実施を通じて技術共有を進め、属人化の解消に取り組んでいきます。

この記事は株式会社エス・エム・エス Advent Calendar 2024の11日目の記事です。 エス・エム・エス BPR推進部 システム機能開発チーム長としてマネジメントを担当している及川と申します。 システム機能開発チームでは、「ナース専科 転職」や「カイゴジョブエージェント」等、医療・介護業界の人材紹介事業を運営する社員に向けた社内業務システムを提供しています。 本記事では組織のケイパビリティ向上を目指し、Team Topologies という考え方を軸として、開発体制の再設計を実現した事例をお話しします。 なぜ再設計したのか 以下の図は再設計前の開発体制を表しています。この時の体制は、開発のライフサイクルの単位で分割されていました。※紙面の都合上、一部の組織課題にフォーカスしています。 本記事での開発のライフサイクルとは、機能を開発し、改善し、メンテナンスを行うといった活動が挙げられます。それらが個別のチームとして組成されていることで、いくつかの問題が生じていました。 新機能開発チームは複数のプロジェクトを同時進行することで多くのビジネス要求に応えていました。プロジェクト型で進行していましたが、リリースが完了するとプロジェクトメンバーは解散するのでナレッジは組織ではなく個人に蓄積していく過程で、属人化が強化されていました。 運用保守チームは新機能開発チームが担当した機能の追加要望を対応していました。チームの数は１つだけでしたので、複数プロジェクトから生まれる改善要求はバックログに溜まる一方でした。製品品質の向上を優先し技術的負債が積み上がった結果、「新しい要求の調査に2週間かかる」ような複雑なシステムに成長していきました。 スパゲティのように絡み合ったシステムをリファクタする専門チームが生まれましたが、巨大化した技術負債に埋もれていました。改善を実現するためには沢山のステークホルダとの調整が必要で、見積もると数ヶ月〜年単位かかるものばかりでした。その間も新しい要求が新たな負債を生み続けていました。 これらの事象は個人の働き方や考え方が要因ではなく、組織構造の問題、つまり仕組みから生み出されるものでした。事実、チームのメンバーは総じて目の前の課題解決に一生懸命で、構造が生み出す問題に対してやりきれない気持ちを抱えている様子が見て取れました。 こうした課題を解決するために注目したのが Team Topologies です。一言で、「製品開発における価値提供の流れをスムーズにするための組織設計の指南書」といえます。開発組織の活動を単なる機能開発ではなく、市場や顧客の課題解決や新たな価値の提供として捉え、課題発見から解決までの流れを迅速かつ効率的に進めるためのチームの役割やチーム間の関係性が明確に書かれています。 どのように再設計したのか Team Topologies は価値提供の流れに沿ってチームを組成する考え方です。この分け方には正しい答えはありませんが、価値の最小単位とは何か、そして、１つ以上の価値が集まることで大きな価値となる単位は何か、だと考えていました。 これを整理するために３つの活動を行いました。 最初に、既存の機能をドメインモデリングで整理することで価値の最小単位を発見しました。更に、関連する複数の価値をグルーピングすることで大きな価値としてまとめた時に何が生み出されているのかを俯瞰しました。 次に、課題発見からエンドユーザへの価値提供の流れを Value Stream Mapping を用いて可視化し、その中にどんな価値が含まれるのかを確認しました。これを行うことで、あるチームが１つの価値提供の流れを担当するときに独立して開発のライフサイクルを回せるかを検討しました。 最後に、価値提供の流れを補完するアイデアとして、通称「リボン図」と呼ばれる、人材紹介事業のビジネスモデルから価値提供の流れの着想を得ました。 図中の１つ１つの四角の部分が、ビジネスモデルの活動のなかで生み出される価値といえます。 左側の活動から、求職者をウェブサイトや合同説明会などに「集め」て求人案件を紹介することで、事業所との面談に向かって求職者を「動かして」いきます。 右側の活動から、働き手を必要とする事業所に営業活動を行うことで「集め」、彼らが欲しい人材の情報を頂戴し、求職者に紹介することで「動かし」ていきます。 そして、求職者と事業者双方が気に入り入所の手続きを経る（「結ぶ」）ことで、我々は手数料としての対価を得ます。これがリボン図の中身になります。 以上、ドメインモデリングの考え方、バリューストリーム、ビジネスモデルの３つの材料がお互いの反証にもなっていることで、新開発体制の設計のロジックとしては充分と考えました。 最後に、現在のチーム体制の図を示します。 価値提供の流れにそって単独で価値を生み出すことができる体制 (Stream-aligned team)が６チームあり、それを支える体制(Complicated-sub-system, Platform, Enabling)が３チームある構成になります。 ※これら名称は Team Topologies で規定されているもので、詳しい説明は本編に譲ります。 価値の単位で組成された各チームのメンバーの最大人数は両手で数えられるほど少なくなりました。コミュニケーションパスが減り議論しやすくなりました。チームメンバーは固定で、ナレッジがチームに溜めやすい構造になりました。 ライフサイクルを分割せず、夫々のチームで新機能の開発と運用保守を担当するようになりました。新しいビジネス要求の対応と技術改善を同時並行することができるようになりました。 最後に、夫々のチームの機能スコープは価値提供の単位で制限されているので、認知負荷が下がりました。ステークホルダの数も減り、課題の解決が容易になりました。 現時点での成果 新体制発足後の活動量の変化をPR数を用いて説明します。 単純に価値提供の流れが増えたこともありますが、PRの数は以前と比べると33% 増加しました。 PRがクローズされるまでのリードタイムは81% 減少しています。 チームの責任範囲が良い意味で制限されたことから開発案件の粒度が小さくなり、扱いやすいサイズになったためと分析しています。 まとめと今後の展望 今回は社内向け業務システムの開発組織の再設計という「構造」の話をしました。 しかしながら、これだけですと枠組みを用意しただけで中身（文化）がありません。さらに「品質や価値提供速度が向上した！」と目に見えてわかるためには、個人の思考や振る舞いの変化と、それを実現する時間が必要です。 具体的な仕掛けとして、チームにスクラムを導入しました。 これがあることで、チームは考えるようになり、課題と向き合い、経験することで、持続的な成長を期待できるようになります。 機会があればお話したいと思います。 積極採用中！ エス・エム・エスは新しいメンバーを大募集しています。 私達キャリア横断開発グループでは、巨大な顧客基盤を保有するSalesforceを用いつつ、様々なクラウドサービスや Saasとも連携し、AIも多用して事業活動を支援しています。 経験できる業務の幅や深さは我々の構想次第です。自ら課題を発見し、解決するための手段を考え実行することができます。 失敗を恐れず学びとして楽しむことができる方、興味のある方は、ぜひこちらのページものぞいてみてください。

この記事は株式会社エス・エム・エス Advent Calendar 2024の12月13日の記事です。 qiita.com こんにちは、介護/障害福祉事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトでSREを担当している加我 ( @TAKA_0411 ) です。SREチームの中では主にモニタリングとオブザーバビリティに関する全般を担当しています。 この度、AWS re:Invent 2024に参加してまいりました。私にとっては初のAWS re:Inventということもあり、現地で感じたことや学びについてこの記事で振り返りたいと思います。 私と英語スキル この記事を理解する上で、私自身の英語スキルについて説明しておきます。 Reading : 概ね問題なし (面倒だからDeepLを使う) Writing : やや難あり (不安なのでDeepLを使う) Listening : 難あり (とてもきびしい) Speaking : 難あり (とてもきびしい) 開発業務における英語ドキュメントの理解は可能、メールやSlackによる英語のテキストコミュニケーションはぎりぎり可能、英語による会話のコミュニケーションには難ありと思っていただいて大丈夫です。ちなみにアメリカへの渡航も初めてなので不安が尽きません。 AWS re:Inventとは AWS re:Inventは毎年ラスベガスで開催されるAWSのグローバルカンファレンスで、公式サイトでは下記のとおり説明されています。 AWS re:Invent is a learning conference hosted by AWS for the global cloud computing community. The in-person event features keynote announcements, training and certification opportunities, access to more than 2,000 technical sessions, the Expo, after-hours events, and so much more. 翻訳すると「AWS re:Inventは、世界のクラウドコンピューティングコミュニティのためにAWSが主催するラーニングカンファレンスです。 AWS re:Inventでは、基調講演、トレーニング、認定資格、2,000以上のテクニカルセッション、Expo、時間外イベントなど、様々なイベントが開催されます。」となります。 AWS re:Invent 参加の経緯 弊社はクラスメソッド株式会社様のお世話になっており、ご縁がありまして今年のAWS re:Inventのツアーに同行させて頂ける運びとなりました。 classmethod.jp 以前からAWS re:Inventに参加したいと思っており、AWS Summit Japan 2024が終わった頃から上長に相談しつつ参加方法について模索していたため、ツアー同行の申し出を頂けたのは非常に助かりました。改めてこの場を借りてお礼申し上げます。 クラスメソッド株式会社の方々とおそろいのジャケットで参加したのですが、背中にプリントされたマスコットキャラのくらにゃんがとても可愛らしいデザインです。現地では多くの方から「そのノベルティはどこで手に入るの？」「私も欲しい」「イラストがかわいいね」「どこの会社？」などの声をいただきました。 “Go Global!” とは さて、タイトルにある “Go Global!” とはなにかを先に説明したいと思います。これは日本のAWSユーザーグループであるJAWS-UG (AWS User Group – Japan) の価値観 (ステートメント) の1つとして挙げられています。 jaws-ug.jp JAWS-UGのサイトに掲載されている4つのステートメントを紹介します。 Have fun! 私たちはあらゆる人が平等にアクセス可能なクラウドコンピューティングのユーザーとして、思想・人種・企業や団体・性別など個人の個性に関係なく繋がり、個人ではできない成長・発見を共有し合えることを喜びとします。 Make a difference! 私たちは新しいテクノロジーが起こすより良い社会の変化に貢献できることを喜びとして、クリエイティブかつポジティブに活動します。 Go global! AWSのユーザーグループは世界中にあり、国や地域を超えた交流が活発に行われています。 私たちもワールドワイドなユーザーグループの一つとしてフラットな交流に参加できることを喜びとし、国際的なユーザーグループの成長に貢献します。 Find new heroes! 私たちは100回の勉強会参加よりも1回の登壇へのチャレンジの方がより大きな成長ができると信じています。 私たちはコミュニティの活動を通じて、個々が持つ知識や経験だけでなく、JAWS-UGに貢献する誰もがヒーローになれる機会を共有します。 つまり、Go Global!というのは「世界中にあるAWSユーザーグループの参加者と積極的に交流しよう！」と私は理解しました。そう、AWSユーザーグループは日本だけじゃないのです。 ちなみに、私は2023年からAWS Community Builderというものに認定？選出？されており、世界中のAWS Community Builderと交流する機会を頂いております。 aws.amazon.com また、今年の8月にはJAWS PANKRATION 2024というイベントで登壇する機会があり、こちらでも日本だけではなく海外のAWSユーザーとコミュニケーションする機会がありました。 jawspankration2024.jaws-ug.jp しかし、やはり私の中の “Language Barrier” は厚く、比較的簡単に翻訳できるテキストコミュニケーションであっても積極的に行うことはできていませんでした。そのような状況でAWS re:Inventへの参加は大丈夫なのだろうかと不安を感じます。 現地での行動指針 AWS re:Inventには基調講演を含めた様々なセッション、Game Day、ワークショップ、EXPO、パートナー企業主催のパーティーなどがあり、体が2つ3つ欲しくなるくらい大量のコンテンツがあります。また、セッションは複数のホテルで開催されており、移動時間を考慮すると取捨選択しなければなりません。 AWS re:Inventに複数回参加している知人や、ツアーの主催であるクラスメソッド株式会社様からは「現地でしか体験できないことをしましょう」とのアドバイスを頂いており、下記のとおり現地での行動指針を設定しました。 1. 現地でキーノートを見る 現地の会場でキーノートを見るのはとても刺激的であり価値があると知人からオススメされたので最優先事項としました。特にAWSのCEOであるMatt GarmanとAmazon.comのVP & CTOであるDr. Werner Vogelsのキーノートをオススメされたので参加することにしました。キーノートの開始時間は朝8時 or 8時半で、移動時間や開場までの待機時間を考慮すると7時〜7時半頃に移動を開始する人が多く、朝に弱い私には辛い時間帯です。 2. re:Playに参加する re:PlayとはAWS re:Inventの最終日前日の夜に開催される大規模なアフターパーティです。著名なバンドやDJによる演奏がされたり、アトラクションがあったり、とにかく派手であることが特徴として挙げられます。ほぼ全ての知人からre:Playには絶対参加しろと言われており、毎年の楽しそうな様子も知っていたので参加するよう調整しました。 3. EXPOを見て回る EXPOとは名前の通りスポンサーによる展示ブースで、まだ日本では見たことのないSaaSの調査や業界の技術トレンドの調査、各産業別の事例などに興味があるため高めの優先度としました。英語が苦手な私が実際にブースの人と話してどれだけ会話が成り立つのか不安です。 4. 交流イベントに参加する AWS re:Inventの夜には企業スポンサーによるパーティーやAWS主催によるパーティーが開催されます。後者はAWS Community BuilderのMeetupや、AWS User GroupのMeetupが開催されるため、せっかくだし参加してみるか！と申し込んでみました。英語が苦手な私が海外のエンジニアと話してどれだけ会話が成り立つのか不安です。 5. セッションに参加する セッションの参加については優先度を低めで設定しました。なぜなら後でYouTubeにアーカイブが配信されることを知っていたからです。 (既に多くのアーカイブが公開されています) www.youtube.com AWS re:Invent振り返り それでは実際にAWS re:Inventに参加して得られた感想や学びについて挙げてみます。 1. とにかく必死で英語を話す AWS re:Inventの開催地はアメリカのラスベガスであり、会話は基本的に英語で行われるため、英語が苦手であってもなんとかしてコミュニケーションを行う必要があります。話せずにもたもたしていても残念ながら日本語で助けてくれる人は恐らくいません。自分でなんとかするしかないのです。そんな状況に置かれた私は「とにかく自分の意思を伝えよう」をモットーに行動しました。 初日は驚くほど口から英語が出てこずとても苦戦しましたが、2日目以降はそれっぽい文章を組み立ててなんとか会話を成立させることができました。最終日にDatadog主催のネットワーキングイベントがあったのですが、開催場所のお店を探せず迷ってしまい、案内カウンターで場所を聞いた時にすんなり英語で会話が出来た時は多少なりとも成長を感じました。 改めてなぜ英語でのコミュニケーションが苦手なのか、なぜ苦手意識を覚えるのかを振り返ってみると「正しい文法でなければならない」であったり「稚拙な英語で話すのは恥ずかしい」というのを過剰に意識していたからではないかという結論に至りました。もちろん正しい文法で話すことは大事です。しかし、文法がめちゃくちゃでもまずは自分が何を伝えたいのかを最優先にしてもいいんじゃないか、俗に言う 出川イングリッシュ でも良いと考えるようになってから、気持ちが楽になりました。 2. 相手の会話が聞き取れない 英語で話すことは多少なりともできるようになりました。しかし相手が言っていることを聞き取ることが全然できず、自分のリスニング能力のなさが辛かったです。ある程度自分の意思を伝えたとしても相手が話した英語をほとんど理解できないので会話のキャッチボールが上手くいかず、そそくさとThank youで会話を切り上げてしまう事もありました。 3. スマホの翻訳アプリはあまりアテにできない AWS re:Invent出発前に札幌で「re:Invent事前勉強会」なるものがありました。そこで私は「英語が苦手なのでスマホの翻訳アプリを駆使しようと思います」と発表しました。海外の方々が実際に翻訳アプリでコミュニケーションをしているのを見て、これなら自分でもできるのでは？と思ったのがきっかけです。 しかし実際には下記の理由によりほとんど使うことがありませんでした。 翻訳の精度が低い 翻訳によるタイムラグにより会話のテンポが悪くなる 1つめの翻訳の精度ですが、実際にMatt Garmanのキーノートを現地で聴いている際に翻訳機能を使ってみましたが、翻訳の精度が低くてあまり使い物になりませんでした。一方でJAWS PANKRATION 2024で大活躍したVoicePingやNottaといった文字起こしツールであれば精度が高くて使えるいう話を聞いたので、もしかしたらツール次第で上手く使える可能性が残されているかもしれません。引き続き調査していきたいと思います。 2つめのタイムラグですが、日常会話のような低遅延コミュニケーションにおいては翻訳アプリを都度経由することで会話のテンポが悪くなるため使うのが難しいと感じました。一方で道案内や何らかの手続きに関する質問など、あまり会話のテンポに左右されないものであれば使っても良さそうです。 4. 海外のエンジニアと友達になれると嬉しい 今回最も伝えたいことがこちらです。”Go Global!” というタイトルの回収です。 これまで私はAWS Community Builderでありながら海外の人たちとの積極的な交流は行ってきませんでした。あまり必要性を感じていなかったとも言えます。しかし、AWS re:Invent 2日目の夜に開催されたAWS Community BuilderのMeetupで一気に考えが変わりました。 とあるタイミングでご一緒したAbel Lopezさんはメキシコのクラウドエンジニアで、私と同じく JAWS PANKRATION 2024に登壇 していました。偶然その日私が着ていた同イベントの登壇者用Tシャツを見せたら「いいね！僕も登壇したんだよ！」と盛り上がり、今度一緒にメキシコでテキーラを飲もうよという話になったり「この言葉は日本語だとなんて言うんだい？」という話をしたりと、気軽に話しかけてくれたのがとても嬉しかったです。 また、別のタイミングでご一緒したJiyoung Leeさんは韓国のSecurity Engineerで、AWS China User Groupで行われた 12-Hour Amarathon Geek Talkに登壇 していました。彼と私には共通の知人がいたので話もスムーズで、気づけばInstagramフレンドになっていました。 5. LinkedInのアカウントを開設しておく 海外の方とSNSアカウントを交換する場合はLinkedInのアカウントがあると便利です。私のSNSアカウントはTwitter (X)、Facebook、Instagramを主に利用しているのですが、残念ながら3つとも持ってないという方が多かったです。 来年のAWS re:Invent参加に向けて 今回のAWS re:Invent参加により自分の英語力が浮き彫りとなりました。貴重な機会を活かしきれず正直とても悔しいです。もっとEXPOでブースの人たちと会話したりディスカッションしてみたかったですし、海外のAWS Community BuilderやAWS Heroともっと会話したかったです。しかしこれは伸びしろです。多少なりとも会話はできました。今回の経験をバネに語学力を高め、日常会話くらいができるくらいの状態で来年のAWS re:Inventに参加したいと思います。 AWS re:Inventに参加することでなんらかの技術力がすぐに伸びるとか、なんらかの知見がすぐに得られるというのはあまり無いかもしれません。しかし、長いエンジニア人生において「あの時AWS re:Inventに行けたのはいい経験だった」と思える場面があると信じています。そして、このブログをきっかけに来年AWS re:Inventに参加したいという社内のエンジニアが増えるよう頑張っていきたいと思います。 最後に覚悟の証を置いておきます。 Duolingo課金した — しめじ/Kaga (@TAKA_0411) 2024年12月10日 それでは来年のAWS re:Inventでお会いしましょう。

この記事は株式会社エス・エム・エス Advent Calendar 2024の12月12日の記事です。 エス・エム・エスで人材紹介の社内基盤開発をしている熊谷です。 今回はそんな社内システムの1つで、Honoを使って開発している事例をご紹介します。 なぜ私たちはHonoを採用したのか？ 人材紹介事業では、CP（キャリアパートナー）と呼ばれる、従事者様の転職のお手伝いをサポートする人員がいます。 従事者様とCPとのコミュニケーションは一般的に電話やメールなどで行われますが、LINEもよくコミュニケーションによく使われる手段の1つです。 従事者様がエス・エム・エスが展開している公式LINEに登録すると、公式LINE上で従事者様専任に割り振られたCPと従事者様との1to1のコミュニケーションが可能になります。 これらを実現するために、LINE Messaging APIを使った中間のWebサーバを社内で管理しています。 元々これらの仕組みは、EC2 + PHPという組み合わせで作られていたのですが、 コミュニケーション量が増えるに伴って費用も増えてきた 処理としては簡易で、EC2で稼働させる必要性がない 時間帯や曜日によって負荷に増減があるため、スケールしやすい基盤が向いている という事情から、Lambda + Node.jsで書き換える企画がスタートしました。 このWebサーバの要件をざっくり伝えると シンプルだけど10ページ分のWebページ（フォーム画面）が必要 Cookieを使う（サーバサイド処理が必要） というもので、色々なフレームワークを比較検討した結果、Honoが良さげだぞという結論に至りました。 決定打としては「jsxがテンプレートとして使えること」「Ryan Dahl氏がDeno FestでHonoを推してたこと」の2つでした。 採用してみてどうだったか？ 非常に良い！！！ というのが感想です、私たちが開発していて実際に良かった点を列挙していきます。 テストが書きやすい Web Standard APIのRequest/Responseを利用しているからこそ、リクエスト/レスポンスのテストの書きやすさが素晴らしいです /** * index.ts */ import { Hono } from "hono" ; const app = new Hono(); app. get ( "/hello/:name" , ( c ) => { const name = c.req.param( "name" ); return c.text( `Hello, ${ name } ` ); } ); export default app; /** * indx.test.ts */ import app from "./index" ; test ( "GET /hello/:name すると、'Hello, ${name}' が返ってくる" , async () => { const path = "kumagai" ; // app.request()で定義済みルートへアクセスでき、Responseオブジェクトが返却される const res = await app.request( `/hello ${ path } ` ); expect (res. status ).toBe( 200 ); expect (res.text()).toBe( `Hello, ${ path } ` ); } ); zod + reuqest parameter validation zodを使ったランタイムバリデーションがリクエストパラメータ等の検証に簡単に適合できるのが良いです const schema = z.object( { id : z.string().uuid(), } ); app.post( "/entry" , zValidator( "form" , schema), ( c ) => { c. status ( 201 ); return c.text( "Created" ); } ); test ( "POST /entry は、FormDataでid = uuidのみ受け付ける" , async () => { const body = new FormData (); // UUID以外はBadRequest body. append ( "id" , "abc12345" ); const res1 = await app.request( "/entry" , { method : "POST" , body } ); expect (res1. status ).toBe( 400 ); // UUIDは201 body. append ( "id" , "fc56abe1-d352-691e-bd8e-13102bf17549" ); const res2 = await app.request( "/entry" , { method : "POST" , body } ); expect (res2. status ).toBe( 201 ); expect ( await res2.text()).toBe( "Created" ); } ); jsxテンプレート jsxで直感的にフロントエンドが書けるのが素晴らしすぎる /** * todo.tsx */ import { Hono } from "hono" ; import { jsxRenderer } from "hono/jsx-renderer" ; import type { FC } from "hono/jsx" ; const app = new Hono(); app.use( "/todo/*" , jsxRenderer(( { children } ) => { return ( < html lang = "ja" > < title > My ToDo </ title > < body > { children } </ body > </ html > ); } ), ); const ToDoList: FC < { items : string [] } > = ( { items } ) => { return ( < ul > { items. map (( item ) => ( < li > { item } </ li > )) } </ ul > ); } ; app. get ( "/" , ( c ) => { return c.render( <> < h1 > 今日のToDoは？ </ h1 > < ToDoList items = { [ "掃除" , "昼寝" , "歯磨き" ] } /> </> , ); } ); export default app; 最後に 私たちがHonoを使っていて、とても感じるのは 「Honoって楽しい！！！」 です。チームとして迷わず開発できている点や、開発生産性も高く、何より 使っていて気持ちが良い というのが大きいと思います。 社内のプロダクトで使い始めたHonoですが、個人開発でも何かとHonoをベースに開発する機会が増えました。個人的には Bun + Honoで作ることが多く、TypeScriptやテストの取り回しも楽だし、Cloudflare Workerなどどこでも動くのは本当に魅力だと思っています。 この記事が、皆さんのHono採用きっかけの一助になればと思っています。

こんにちは。 エス・エム・エスでプロダクト組織の人事をしているふかしろ( @fkc_hr )です。 株式会社エス・エム・エス Advent Calendar 2024 vol.2 と 技術広報 Advent Calendar 2024 シリーズ3 の12月12日の記事です。自社のAdvent Calendarは埋まるかな〜ワクワク、とSlackのtimesチャンネルで呟いたら、人事も書くんだよ！と煽ってもらって(？)ここに至りました。 エス・エム・エスは例年さまざまなカンファレンスに協賛をしているのですが、今年はありがたいことにブース出展もさせていただく機会が多かったため、そちらの内容を振り返っていきます。 カンファレンスでエス・エム・エスを見かけてくれた方に思い出しながら読んでいただいたり、これからカンファレンス協賛・ブース出展するぞという方の参考になったりしたらいいなと思っています。 どのカンファレンスに協賛をしたのか 以下の通りです そのうちブースを出展したカンファレンスを主に振り返っていきます。私は該当する5つのカンファレンスを皆勤賞ですべて参加させていただきました。楽しかった〜 すこし裏話をすると、2024年12月現在では、モバイルアプリエンジニアはチームもなければ採用も積極的にしているわけではないものの、 DroidKaigi は弊社社員がスタッフとして参加しているので協賛をしていたり、はじめての JAWS Festa への協賛はSREの一人が、コミュニティ活動として協賛したいといってくれたおかげで協賛に至ったり、というコミュニティ貢献のためにも協賛という形で社として応援しているなと思ったエピソードもありました。 どんな準備をしたのか 今年は広報がんばるぞと決意していたこともあり、素振り的にブースがある協賛イベント用のキックオフ資料のたたきを作ったり、その他のノベルティやチラシの資料を一つのドライブにまとめたりしていました。 エス・エム・エスは複数事業を展開していて、プロダクト数も多いので、各カンファレンスごとにフォーカスして紹介したいプロダクト・チームが変わります。そのため全体感を把握できないまま役割分担などが進んでいく傾向があるので、全体感やスケジュールが分かるものにしました。 関係者や興味を持ってくれている人をあつめてキックオフと役割分担をしたら、あとは皆さんの応援をする…という形で進むのが理想なのですが、初めて関わる方も多くいるので、社内調整含めてフォローしながら、Slackで該当イベント用のpublicチャンネルを作成し定例で進捗を確認し…と進めています。 特に社内関係者でPR/IR/リスクマネジメントの部門への相談が必要だったり、支払い関係で経理/総務部門も巻き込みながら進むような内容は普段のエンジニアが業務上かかわらないことが多いため、各部門の判断材料となるような情報が不足なく伝わるようなフォローをしていました。 その中でも今後の持続性を考えて、ノベルティは他のイベントでもつかえるデザインにする、チラシの会社紹介のページは共通で活用する、メインの缶バッジ企画を固めておく、などをしていたので直近のKaigi on Rails はかなりスムーズに用意できたように感じます。 当日どう過ごしたのか 各社あまり差異はないと思いますが、シフトを組んで、できるだけ聞きたいセッションは聞き、カンファレンス自体を楽しんでもらいたいというのがベースの思考です。 ※シフトを抜粋したもの 企画として特に良かったなと思うものを2つ紹介します。 缶バッジ(現地生産) EMのふるぽんの企画で、「あなたのXアイコンを缶バッジにしてプレゼントします」という企画を行いました。 合わせてお渡しするネタ缶バッジもイベントごとに作成しました。デザインは絵文字ジェネレータで作ります。 特に現地生産もモバイルプリンター、缶バッジメーカーを活用して行えたイベントは非常にインパクトがあったのではないかなと思います。だんだんカンファレンス中で缶バッジをつけている人が増えていくのは不思議体験でした。 また、印刷や作成はバッチ処理的に作業していく仕組みだったので、申し込み・完成品の回収と2回ブースに足を運んでいただくことができたのも思わぬ良ポイントでした。 SNSフォローもお願いしたい、ノベルティも渡したい、会社やプロダクトの紹介もしたい、ソースコード公開をしてたら見てほしい、とコンテンツが多かったのですが、タイミング次第で長くブースに滞在していただくこともできました。 おみくじ デザイナーがコンセプトワークから行ったストーリー性がある企画でした。 「デザイナーと介護・障害福祉を『社会課題』で結ぶ」というコンセプトで、おみくじをきっかけとして提供し、介護を含めた未来を想像してもらい、該当する項目に「結」んでもらう。ここまでつながる体験設計をできるのはデザイナーだからこそなせるワザだなと思いました。 おみくじを結んでもらっている様子 コンテンツとしても、「おみくじ引いてみませんか」と声をかけることができるハードルの低さや、意外と結ぶという行動に手間取るのでその間に会社やプロダクトについて話すことが出来たことは収穫でした。 ここまで一貫した体験設計が出来なくてもハードルが低く興味を持っていただくきっかけを作る。なにか足を止めていただけるような、深い話をできる機会を創出するという点は今後のブース企画にも活かせそうです。 結果としてどうだったのか コミュニティ貢献が目的ですが、副次的な効果として得られたことを紹介します。 プロダクト組織の公式X( @BM_SMS_Tech )のフォロワーが1000人を突破した ノベルティをお渡しするためにフォローをお願いしたこともあり、Xのフォロワーが先日1000人を突破しました。実は今年度の始まりは300名弱だったため、カンファレンスが繋いでくれた縁だなと感じています。 継続的に情報発信をしていきたいと思っています！ エス・エム・エスよく見かけますと言ってもらえるようになった これはカンファレンスブースだけではなく、登壇やブログなどの発信の効果でもありますが、よく見かけると言っていただけるようになりました。嬉しいですね。 エンジニアも嬉しい、誇らしいと思ってもらえるように、これからも良い組織づくり、発信を行っていきたいです。 面談・面接でカンファレンスで社員と話して興味を持ったと言ってもらえるようになった 最高ですね。カンファレンス”だけ”が理由で採用に至ることはありませんが、応募のきっかけになる機会なのだなと感じました。 これからも継続的にコミュニティへ貢献するモチベーションになりました。 社内エンジニアやデザイナーの交流の足がかりになった 普段基本的にはフルリモートで開発をしているため、対面で会うのははじめて、というメンバーもいました。同じ技術スタックを別のチームで使っている場合でもカンファレンスの準備から感想戦など含めて交流するきっかけになったと感じています。 おわりに 広報施策に銀の弾丸はなく、なにごとも継続が大事だと感じています。エス・エム・エスのプロダクト組織がカンファレンス参加や学習を推奨しているからこそ、カンファレンス協賛を継続的に行えているのだと改めて感じる一年でした。 カンファレンスを実施してくださる運営の皆さん、参加していてエス・エム・エスのブースに来てくださった方、ありがとうございました。またお会いしましょう！

この記事は「株式会社エス・エム・エス Advent Calendar 2024」シリーズ1の12/17の記事です。 はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」でQAを担当している中村です。気づけば入社して3年が経ちました。現在は複数のQAチームに横断的に関わりつつ、チームのサポートや改善活動の推進など、幅広い業務を担当しています。 弊社では以前から、ノーコードのテスト自動化ツール「 MagicPod 」を使用し、E2Eテスト自動化を推進しています。今回の記事では今年取り組んだ「ローカルPC実行で定期実行を実現したこと」をテーマにお話ししていきます。 昨年のAdvent Calendarでも、E2Eテスト自動化のことを記事にしているので、ぜひそちらもご覧ください 🙏 tech.bm-sms.co.jp 取り組みのお話 １．前提 カイポケにおける自動テストの状況を簡単に説明します。 開発環境がプライベートネットワークなのでMagicPodのクラウド実行機能を使えない リモートワーク主体でプライベートネットワーク内で安定した通信が求められるので、自動テストの実行環境は仮想環境を使用している カイポケの推奨環境に準拠して自動テストの実行環境はWindowsとしている これらの制約がある中で開発環境に対して定期実行を可能にする方法を検討していきました。 ２．構成 仮想環境にPowerShellを配置し、それをWindowsのタスクスケジューラで定期実行する構成としました。JenkinsなどのCIツールを利用する選択肢も検討したのですが、以下の理由から今回の構成を採用しました。 CIツールの保守にコストをかけたくない テスト実行環境を軽量で運用したい 2-1. 構成イメージ 2-2. 実行フロー スケジューラにタイマーをセットする スケジューラでセットした時刻にPowerShellを実行する MagicPodDesktopを起動し自動テストを実行する ３．テスト実行スクリプト（PowerShell） PowerShellでは、MagicPod公式のヘルプ「 コマンドライン一括テスト実行（ローカルPC環境） 」も参考にしながら、主に以下の処理を行っています。 Proxy設定の更新 MagicPodDesktop設定ファイルの更新 テスト実行 次に、コードを交えながら各処理内容を簡単に紹介していきます。なお、説明のために処理を分割していますが、実際には1つのスクリプトで完結するように構成しています。 3-1. Proxy設定の更新 ## テスト環境を指定（実際には引数で取得） $targetProxy = "XXX" ## テスト環境向けのProxyServerを定義 $proxyList = @{ "STG" = "<STG_URL>:<STG_PortNumber>" ; "DEV" = "<DEV_URL>:<DEV_PortNumber>" ; } Function changeProxy { param ( $targetProxy ) try { # 接続先のProxyServerを設定 New-ItemProperty -LiteralPath "HKCU:Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name "ProxyServer" -PropertyType "String" -Value " $targetProxy " -Force # Proxy設定をon Set-ItemProperty -Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings’ -Name ProxyEnable -Value 1 Write-Host "Proxyが設定されました: $Proxy " -ForegroundColor Green } catch { # Proxy設定をOff Set-ItemProperty -Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings’ -Name ProxyEnable -Value 0 Write-Output "Proxy設定でエラーが発生しました" -ForegroundColor Red Write-Output $_ -ForegroundColor Yellow exit } } 3-2. MagicPodDesktop設定ファイルの更新 ## テスト実行用のパラメータを指定（実際には引数で取得） $testNumber = "XXX" $testPattern = "XXX" ## ファイルパスを指定 $magicPodConfig = " $HOME \AppData\Roaming\magic_pod_desktop\magic_pod_config.json" Function updateConfig { try { # MagicPodConfig.jsonを読み込んで更新する $jsonContent = Get-Content -Path $magicPodConfig -Encoding UTF8 -Raw | ConvertFrom-Json # テストケースを指定 $jsonContent .testSettingsNumber = $testNumber $jsonContent .testSettingsPatternName = $testPattern # JSONに変換 $updatedJson = ConvertTo-Json $jsonContent # UTF-8(BOMなし)で出力 [IO.File] :: WriteAllLines( $magicPodConfig , $updatedJson ) Write-Host "設定ファイルが正常に更新されました。" -ForegroundColor Green } catch { Write-Output "configファイルの更新でエラーが発生しました" -ForegroundColor Red Write-Output $_ -ForegroundColor Yellow exit } } 3-3. テスト実行 ## ファイルパスを指定 $magicPod = ls $HOME \AppData\Local\magic_pod_desktop\app- * \MagicPodDesktop.exe $magicPodConfig = " $HOME \AppData\Roaming\magic_pod_desktop\magic_pod_config.json" ## 実行コマンドオプションを指定 $argConfig = "run --magic_pod_config= `" $magicPodConfig `" " Function startMagicPod { Start-Process -FilePath " $magicPod " -ArgumentList $argConfig } さいごに 今回紹介した方法により、本番環境だけでなく開発環境でも定期実行を実現することができました。定期実行を導入することで、何か問題があった際にすぐに気づける安心感を得られたことは、大きな成果だと感じています。また、テストに問題が発生した時もすぐに改修できるため、テストケースの保守性向上にも役立っています。 ただし、現時点では定期実行の実現にとどまっています。今後はCI/CD連携を進めて、リリースプロセスに密接に関わる形に発展させることで、さらなる開発サイクルの高速化や品質向上を目指していきたいと考えています。 エス・エム・エスでのテスト自動化の取り組みは着実に進んでいますが、まだ発展途上であり、さまざまなチャレンジができる環境です。（常に「より良く」を目指しているので、終わりはないかもしれませんが…😅） 現在、QAエンジニアを積極採用中です！少しでも興味をお持ちいただけましたら、ぜひカジュアル面談でお話ししましょう！！

はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」のQAを担当している星です。2020年1月に入社し、チーム活動やQA組織づくりを通じて品質保証の体制強化や施策推進をしています。 2024年も残すところあと半月ほど・・ということで、今回の記事では今年一年であった変化、その中で取り組んでみた活動の内の一つを振り返ってみたいと思います！ 組織、私個人としても沢山のチャレンジをさせてもらった一年ですが、印象深い活動をピックアップして書いてみています。 どんな変化があった？ カイポケのリニューアルプロジェクトでは今年からLeSS（Large Scale Scrum：大規模スクラム）の導入にチャレンジしています。 tech.bm-sms.co.jp このプロジェクトでは以前よりスクラムをベースとした開発プロセスを導入しており、各チームに所属しているメンバーが日々試行錯誤をしながら開発や品質保証を進めてきました。 その中でスクラムマスターの参画もあり、LeSSのフレームワークへと最適化していく過程で、よりチームとして目線を合わせやすい状態、サポートが受けやすい状態となりました。 同時に、そういった変化の中でQAエンジニアが持つ専門性をどう活用し、成長しながら貢献していけるのかということを改めて考える機会が訪れているとも感じました。 この変化や機会の中で実際の動きを通じ、QAエンジニアとしてどう貢献していくべきかを改めて考えてみたい・・・！ 私自身はQA組織内の横断的な活動も担当させてもらっているため、入社時と比べるとチーム活動からは少し離れがちにはなっていたのですが、そういった思いのもとで今年はチーム活動にも積極的に参加させていただく一年となりました。 前提 カイポケ開発の各アプリにおけるチームはプロダクトオーナー、開発者、デザイナー、QAと異なる専門性を持った多数のメンバーにて構成されているケースが多くあります。 現在私が主に関わっているチームでも同様で、それぞれが得意な領域の技術を持って開発を進めるスタイルになっています。 関わらせてもらうタイミングでちょうどチームの再編があり、ワーキングアグリーメント（チームの約束事）の作成等、チームビルディングにも参加することができました。 一部抜粋にはなりますが、現状のワーキングアグリーメントには以下のような記載をしています。 スプリントゴール達成に向けて、ロールを越えて得意な武器（領域）で援護してほしい こちらも一部ですが、QAと呼ばれる活動に専門性を持ったメンバーが期待されていることとして以下記載がされています。 検証するシナリオやパターン知見から、要求に関する不確実性を評価してもらう事に期待している 作るものの「不確実性」（要求の変化や開発における変数等）は一定発生します。 私が所属するチームでは技術と要求の不確実性の切り口でPBI（プロダクトバックログアイテム）の評価、見積もりをしています。 QAと呼ばれるメンバーはこの中で、検証シナリオやパターンの知見を用いた要求の不確実性の具体化、それに対するフィードバックをしていくことを期待されています。 そこに対して貢献ができるポイントはないか考えながら活動していきました。 どんな感じでやっているか 上記にて書かれている「要求に関する不確実性の評価」、そこからスプリントを通じて「要求の不確実性を減らしていくためのアプローチ」として、一例として以下のような活動を通じてトライアルをおこなっています。 ディスカバリーフェーズから他チーム影響も考慮したテストパターンを考えていく PRD作成までの各ステップに参加、早期からテストプランニングやパターン検討を開始 プロダクトオーナーや開発者とのテストすり合わせ（インクリメントの共通認識化）をスプリント開始後の早い時期に実施する リファインメントにて受け入れ基準をチームで確認・最適化し、ストーリーポイントを用いて不確実性に対する会話をする こういった活動の中で適宜フィードバック、デイリースクラムでの透明性確保を通じ、不確実性を下げていくことをスクラムチームにおけるQAの活動の一部として取り組んでいます。 やってみてどう？ 活動の元になっているもの自体はスクラムの基本的な考え方に基づいているため、特に目新しいものではないのかもしれません。 また、これがベストプラクティスではないと思っていますし、アウトプットの精度やフィードバックの数を増やす等、より良くなっていけるように考えていく楽しみがあると感じています。 テストプロセスの更なる最適化、自動テストを駆使したリードタイムの短縮、ワーキングアグリーメントの「ロールを越えて」という部分でできることもまだ多くあり、より一層チームとして、個人として成長していける可能性を感じています。 個人的なこれよかったポイント 長々と経緯や現状を語ってしまいましたが、エス・エム・エスのQA組織では大切にしたいものの一つに「チームで品質保証」という行動指針を掲げています。 その実現に近づいている実感を持てたことが、私個人としてとてもよかったと思っています。 QA組織の行動指針とは？ 以前テックブログにQA組織の行動指針を言語化した記事を投稿しました。 tech.bm-sms.co.jp この中の一つに「チームで品質保証」というものがあり、「職種の壁を越えて協力することで複雑な問題を解消できる組織を目指したい」という思いのもと、この項目を設計していました。 私の中でこの指針とリンクした活動に携われたという実感があり、今回のテーマで書いてみようと思ったモチベーションにもなっています！ ※ちなみにこの記事内の行動指針は昨年初稿として書いたもので、絶賛ブラッシュアップ中です。詳細は追って発信したいと考えています。 （方向性の見直しではなく、組織スケールの中でもより伝わりやすいものにしていきたいと思っています） 1点補足として、本記事の活動や考え方のみが「チームで品質保証」を体現するものではないと考えています。 チームの特色によって構築していきたい開発スタイルは異なると思っており、その自由度が高いのもエス・エム・エス開発組織の良いところだと捉えています。 まとめ ということで、組織作りにおいて今回のような活動にトライしていきたいという思いが前提としてあり、実際の動きとしてコミットしていくことも微力ながら出来たため、非常に充実した一年になったと感じています。 もちろん全て私が提案・推進・実践したわけでないですし、関係する沢山のメンバーの多大なるサポートがあってこそなので、この場を借りてお礼申し上げます！ いつもありがとうございます！ 私自身、スクラム開発やアジャイルテスティングの経験が豊富なわけではなく、ましてLeSSとなってくると日々勉強だなぁと思う毎日です。 今年は会社の支援を受けて外部研修にも参加させてもらい、とても良い刺激になりました。 tech.bm-sms.co.jp 今回の取り組みに関してもチームプロセスとしてより明確化したり、洗練していくことは必要不可欠だと思っています。 スケールしていくプロダクトに対して取り組みをどのように適用し、どう貢献していくか考え続けたいという思いもあり、ここも継続してチャレンジしていきます。 また、冒頭でも少し触れましたが今回の取り組みはあくまでも一例で、QA組織では他にも多くのTryを進めています。 今回のようにチームで一緒に走っていく活動だけでなく、横断的な関わり方を模索し、品質の維持・向上とともに不確実性を下げていく活動がプロダクトや組織のスケールによって必要になると思っています。 そういった点も組織一丸となって引き続きチャレンジしていきたいと考えています。 来年もがんばるぞ！ 様々な活動にチャレンジできるエス・エム・エスのQA組織に少しでも興味を持ってくださった方は是非カジュアル面談よろしくお願いいたします！

この記事は 株式会社エス・エム・エス Advent Calendar 2024 vol.2 12月9日の記事です。 介護/障害福祉事業者向け経営支援サービス「カイポケ」のソフトウェア開発者の 空中清高( @soranakk ) です。 本記事では、毎月開催しているチーム交流のボードゲーム会について書きます。 はじめに カイポケにはたくさんの開発チームがあります。 普段はリモートワークが中心だけど、「たまには他チームとの交流会がしたいな」ということで橋口( @gusagi ) さんがボードゲーム会を企画してくれました。 チーム交流のボードゲーム会は任意参加の会で、月に1回、だいたい月末の金曜日の夕方に開催しています。本記事ではこれまで開催したボードゲーム会でこんなゲームをやったよ〜っていうのをできるだけ思い出して紹介したいと思います。 これまでに遊んだボードゲーム ロストレガシー 宝物がどこにあるのかを探すゲーム。 1ゲームの時間が短く、毎回展開が異なるためリプレイ性があり、テンポよくできるゲーム。 他の人にアクションすることが結構あり、コミュニケーションが取りやすいゲームです。 「〇〇さん、さっき 4 のカード持ってましたよね？」 ボブジテン カタカナ語をカタカナを使わないで説明するゲーム。 説明の仕方など、個性が出て面白いです。 「 インストール をカタカナを使わないで説明してください。」 ボーナンザ 豆畑で豆を育てるゲーム。 豆を交換する交渉が必要なゲームで、各々の性格が出てとても面白い。 「この赤い豆を緑の豆と交換して欲しいなぁ、Win-Winですよ、ね？」 もっとホイップを！ 見た目は甘いケーキだけど、ゲーム内容はかなりシビア。 他の人がどのケーキを食べて、どのケーキを残しているのかを見ながら真剣にケーキを選ぶゲームです。 「どのケーキを切ったらいいかな〜。(人の顔を見ながら)ここかな〜〜？」 確定申告ゲーム 確定申告をテーマとした双六型のゲーム。 確定申告にまつわる質問に答えたり、ホテルやカメラ、スーパーカーの領収書の使用目的を聞かれたり、ロールプレイが楽しいゲームです。 「〇〇さん、この経費の領収書でカメラを買ったってあるのですが、何に使ったんですか？」 ごきぶりポーカー ゴキブリやコウモリなどを押し付け合うゲーム。 押し付けられたカードが本当に指定されたカードなのかを当てないと、押し付けられちゃう。 「これはコウモリです。いえいえ、本当ですよ？本当にコウモリです。」 ブロックス ブロックを順番に置いていく陣取りゲーム。 ルールはシンプルだけど、奥深い戦略があるゲームです。 あれ？もう置ける場所がないかも？陣取り、むずかし〜〜 Not My Fault! 俺のせいじゃない! 順番にプロジェクト進捗を報告していく、ダウト系のゲーム。 納期は守らないといけないけど、すでに報告されている進捗も実は・・・？ 案外 徹夜で頑張りました が本当だったりして、面白かったです。 センチュリー: スパイスロード センチュリー三部作の一作目。 4種類のスパイスを交換しながら、自分だけの最大効率フローを作り出して勝利する！ 目指せスパイスマスター！ マフィア・デ・クーバ 正体秘匿の人狼系のゲーム。 役職を自分で選べるのと、マフィアのボス役とのロールプレイや掛け合いが楽しいゲーム。 「ダイヤは何個あった？」 「私が見た時にはもうダイヤは一つもなかったんです！私は忠実なる部下です！」 「役職は聞いてないよ。」 インサイダーゲーム 一人だけ答えを知っているインサイダーを含めて、お題を当てるゲーム。 参加者はマスターに質問し、マスターは Yes/No/わからない で答えるだけを繰り返して推理していき、お題を当てる。 お題を当てた後にインサイダーは誰だったのかを推理するゲーム。 お題を当てるパートとインサイダーを探すパートがあって、誰が正解に誘導したんだ？というのを推理するのが楽しいゲーム。 A「それは食べられますか？」 B「それは自宅にありますか？」 C「昨日食べましたか？」 D「調味料ですか？」 E「鼻にかけたらクシャミしますか？」 インサイダーは誰だ？ ボードゲーム会の意義 ボードゲームには様々な種類のゲームがあって、強制的に嘘をつく必要があったり、ロールプレイする必要があったり、様々なシチュエーションを共有できます。 またゲームで求められるものも、純粋な論理的思考みたいなものだけじゃなく、会話や表情など様々です。 こういったゲームを通じて、人となりを知れたり、あのゲーム面白かったですね、という共通の体験が出来たりして、チームビルディングに良いと思います。 また来年もいろんなボードゲームやるぞー！

この記事は株式会社エス・エム・エス Advent Calendar 2024 vol.1の12月9日の記事です。 エス・エム・エスで全社SREというロールで活動している Security Hub芸人 1 の山口（ @yamaguchi_tk ）です。 おすすめのAWSサービスは営業です（いつもお世話になっています）。 はじめに SRE（Site Reliability Engineering）は、運用の効率化とシステムの信頼性向上を目指すアプローチです。 私たち全社SREチームでは、組織横断的にSRE活動を開発チームにEnablingしていく取り組みを開始します。本記事では、その背景や目的、具体的に活動を予定している内容をご紹介します。 背景 現在、事業部に専属のSRE（Embedded SRE的な立ち位置のSRE）がいないサービスでは、主に全社SREがインフラの構築・運用を担っています。しかし、システムの運用については受動的な対応が多く、 「組織の信頼性のマインドセット:Google SRE の知見」 に記載のある組織の信頼性のマインドセットでは Absent な段階でした。 そのため運用負荷が集中し、信頼性向上や運用の効率化のための活動になかなか手が回らない状況でした。 エス・エム・エスは事業活動の性質としてサービスの数が多く、事業部に専属のSREがいない全てのサービスの運用の効率化、信頼性の向上を全社SREチームだけで行うことは現実的ではないため、新たなアプローチを策定しました。 SRE活動を開発チームにEnablingしていく目的 私たちのチームが目指すのは以下です。 開発チームの自律性を高める 開発チームがSRE活動を主体的に実施し、信頼性のあるシステムを構築・運用できる体制になることを支援します。 運用の効率化と信頼性の向上 運用負荷を軽減し、システムがより高い信頼性を保つ状態を維持します。 具体的な活動内容 以下のような手順で活動内容を決定しました。 全社SREチームが開発チームにEnablingするSRE活動を定義 定義した活動を開発チームに委譲する目標レベルを定義 定義した活動で成熟度レベルを評価するものを決定 開発チームにEnablingする活動は以下のようになりました。 活動 Enable対象 目指す委譲レベル 成熟度評価 SLI/SLO ⭕️ 尋ねる ⭕️ 監視 ⭕️ 尋ねる ⭕️ インシデント対応 ⭕️ 尋ねる ⭕️ ポストモーテム ⭕️ 尋ねる ⭕️ ドキュメント管理 ⭕️ 尋ねる トイルの撲滅 ⭕️ 尋ねる ⭕️ コスト管理 ⭕️ 尋ねる ⭕️ 脆弱性対応 ⭕️ 尋ねる ⭕️ インフラ設計 ⭕️ 同意する 開発効率の向上 ⭕️ 尋ねる ⭕️ セキュリティ対応 伝える Admin業務 伝える 知識共有とトレーニング 伝える ログの管理 伝える 委譲レベルはManegement3.0 2 を採用しました。 伝える：私が決定し、チームに伝える 説得する：私が決定し、チームを納得させる 相談する：チームに相談してから、私が決定する 同意する：チームと一緒に決定する 助言する：助言はするが、チームが決定をする 尋ねる：チームが決定し、後で私を納得させてもらう 委ねる：チームが決定し、私は気にしない 成熟度評価 サイバーエージェントさんの資料 3 を参考にさせていただきLevel1からLevel3までの成熟度を設定しました。 SLI/SLO Level1 SLI/SLOが設定されていない Level2 SLOが計測され、信頼性の数値としてチーム内で認知されている Level3 ベストプラクティスに基づいたSLO運用ができている 監視 Level1 監視についてのルールや要件がなく、場当たり的な監視になっている Level2 監視ルールが整備され、プロダクトの異常が適切に検知できる状態になっている Level3 ベストプラクティスに基づいた監視項目の設定、通知が行われている インシデント対応 Level1 対応フローが定義されておらず、対応が属人化している Level2 対応フローが定義され、チーム全体で反復可能な状態になっている Level3 ベストプラクティスに基づいた対応フローが行われている ポストモーテム Level1 障害報告書は書いているが、障害から学習できる状況になっていない Level2 障害をふりかえり、対応プロセスやプロダクトの改善につながっている Level3 ベストプラクティスに基づいてポストモーテムの導入、ふりかえりが行われている ドキュメント管理 Level1 必要なドキュメントが整備されていない Level2 必要なドキュメントが整備されている Level3 ベストプラクティスに基づいてドキュメントの維持や整備が行われている トイルの撲滅 Level1 運用作業と開発タスクが分断しており、運用作業の改善は場当たり的に行われている Level2 運用作業の見直しや改善が計画性を持って行われている Level3 ベストプラクティスに基づいてトイルの計測や改善が行われている コスト管理 Level1 コストの削減は場当たり的に行われている Level2 コストの評価や削減が計画性を持って行われている Level3 ベストプラクティスに基づいてコストの評価や対応が行われている 脆弱性対応 Level1 脆弱性対応は場当たり的に行われている Level2 脆弱性対応が計画性を持って行われている Level3 ベストプラクティスに基づいて脆弱性の評価や対応が行われている 開発効率の向上 Level1 プロセスは定義されているが自動化は行われていない Level2 CI/CDが構築され、一部で自動化が行われている Level3 ベストプラクティスに基づいて開発効率の評価や向上への対応が行われている 開発チームとのコラボレーション 開発チームとのコラボレーションについても、「開発チームが自律的に全てのフェーズを実施できている状態」を理想形と定義し、以下のように役割分担を整理しました。 フェーズ 事業部 開発チーム 全社SRE 備考 企画・要件定義 ⭕️ ⭕️ 設計 ⭕️ ▲ 全社SREが可用性、セキュリティの観点でレビューを行う インフラ初期構築 ⭕️ ▲ admin的な業務は全社SREが実施 その他は開発チームで構築 開発 ⭕️ インフラ変更等 ⭕️ ▲ 全て開発チームで実施 必要に応じて全社SREが支援、レビューを行う アラート対応 ⭕️ 営業時間内外問わず開発チームが実施 インフラ作業 ⭕️ ▲ Admin業務以外は開発チームが実施 メンテナンス対応 ⭕️ 開発チームが通知を確認して開発チームが実施 脆弱性対応 ⭕️ ⭕️ 基本的に開発チームが自律的に実施 緊急性の高いものに関しては全社SREが脆弱性を確認し開発チームに対応を依頼 今後の展望 全社SREチームでは、この取り組みを通じて「組織全体で信頼性を高める文化」を醸成していきます。 開発チームと密に連携しながら、組織横断的なSRE活動の推進に取り組んでいきます。 本取り組みに関する最新情報や進捗は、随時Blogで共有していく予定です。 SRE界隈でもAWS界隈でも「山口」だとレピュテーションがなかなか上がらないので、レピュテーションは「Security Hub芸人」で確保しています ↩ 「Management 3.0 デレゲーションと エンパワーメント」 ↩ 「SRE Technology Map 2023」 ↩

この記事は株式会社エス・エム・エス Advent Calendar 2024の4日目の記事です。 エス・エム・エス BPR推進部 データ基盤チームの橘と申します。 私は「ナース専科 転職」等のキャリア事業を中心に、社内のデータ活用の推進、データ基盤の開発運用を担当する、データエンジニアの役割を担っています。 はじめに キャリア事業のデータ基盤は、Google Cloud 上に、BigQuery を中心に構築しています。 近年、データ活用の需要はますます拡大し、事業部門がTableauやQuickSightなどのBIツールを介してデータ基盤を利用したり、Google スプレッドシートや BigQuery Studio からSQLを実行しての分析等が進んでいます。 データ基盤の活用を推進する中で、以下を目指し日々運用をしています。 必要なデータがどこにあるかがわかる(Discoverable) 必要な人が必要なデータにすぐにアクセスできる(Addressable) セキュリティやガバナンスが守られている(Secure) 昨年のAdvent Calendar の記事は、上記のDiscoverable、Addressableを達成するための手段の1つでした。 tech.bm-sms.co.jp 今回は、AddressableとSecureを実現する、権限管理について触れたいと思います。 キャリア事業は複数のサービスを抱え、サービス内に複数の活用できるデータが眠っています。データ基盤の拡大とともに、Google Cloud のプロジェクトも複数となり、BigQuery のデータセットだけを見ても、多数に分割して管理されています。 煩雑化と属人化が進みつつある権限管理を昨年見直し、運用をしてきましたので、その事例をご紹介します。 データ基盤における権限管理 私たちのデータ基盤は、Google Cloud のプロジェクトのIAM、BigQuery やCloud Storage などのデータへの読み書きのアクセス権限、App Engine アプリケーションへのアクセス権限など、複数個所での権限設定を運用しています。キャリア事業にかかわる社内のあらゆるデータを蓄積しているため、ユーザー側の見れるデータ、編集できるデータを最小限にするためにポリシーを設けて、データ基盤管理者がポリシーに沿って適切な権限を設定していく運用を続けています。 従来は、データ基盤管理者数名で、依頼ベースでGoogle Cloud のコンソール上から手動での権限設定の対応を行ってきました。権限設定自体はGUI上でも簡単にできますが、以下の問題がありました。 変更履歴を管理できない 複数人複数個所の設定が手動での運用だと大変 権限設定を依頼する人は権限を操作する権限を持たないため、変更箇所の指定をしにくい 上記を解消するために、構成管理ツール、Terraform を昨年度に導入しました。 元々データ基盤では管理するリソースが多くもなかったのでTerraformを導入していなかったという背景がありました。Cloud Storage のバケット毎、BigQuery のデータセット毎の権限設定等を目的にTerraformの導入をし、付帯的にインフラの構成管理としての導入も進めました。 導入から1年ほど経ったので具体的な構成や導入後のメリットをご紹介します。 Terraformの構成 まず、Terraformのディレクトリ構成としては以下になります。 . ├── modules/ │ └── 共通モジュールなど └── projects/ ├── プロジェクト1 │ ├── resources/ │ │ ├── bigquery.tf │ │ ├── cloud_storage.tf │ │ ├── iam.tf │ │ ├── members.tf │ │ ├── service_account.tf │ │ └...他リソースごとのtfファイル │ ├── .terraform.lock.hcl │ ├── main.tf │ └── variables.tf ├── プロジェクト2/ └...以降プロジェクト毎のディレクトリ/ キャリア事業のデータ基盤として複数のGoogle Cloud のプロジェクトがあるため、複数プロジェクトを一元管理できる構成としています。 projects/[実際のプロジェクトID]/resources 配下には、 biguery.tf 、 cloud_storage.tf などのリソース毎の定義ファイルを置いてます。例えば、 bigquery.tf は、BigQuery のデータセットごとのリソース管理と、データセットのReaderやWriterの定義を管理しています。 Google Cloud の権限は、GoogleグループやGoogleアカウント毎に定義が可能ですが、権限管理の目的内でのグルーピングができるように、 member.tf を作成しています。この中でlocal変数として、GoogleグループやGoogleアカウントをリストで定義して、各リソースに設定できるようにしています。 運用フロー まず、ユーザー部門がデータ基盤チーム宛に、権限設定の依頼をします。具体的に見たいBigQueryのデータセットを書いて依頼をしたり、業務上どういうデータを分析したいかなどの抽象的な相談をしたりします。 その要求をデータ基盤チームの開発者が受け取り、必要であればユーザー部門に業務のヒアリングを行い、Terraformのコードを書いてGitHubのプルリクエストを作成していきます。 プルリクエストをデータ基盤管理者がレビュー・承認することで、権限設定ができる仕組みとしています。 導入してから変わったこと いつ、誰に、どういう目的で、何の権限設定をしたかを把握できるようになった 複数プロジェクトまとめての権限の棚卸しがしやすくなった テキストエディタ上で設定を記述するため、AIによる自動入力の支援を得られるようになった ユーザー側の要求によってどの権限が必要かのレビューがしやすくなった 今まではデータ基盤管理者のみが権限を把握していたが、Terraformのコードを書く開発メンバーも、データ基盤の権限構成を理解できるようになった など複数のメリットがありました。 特に後者の2つはデータ基盤の管理の属人化を避けるためにも効果的で、データ基盤”チーム”として運用をしていく体制が確立したと思います。 まとめと今後の展望 以上、データ基盤における権限管理についてご紹介しました。BIや生成AIの発展とともに、ますますデータ基盤の利用機会も増えてきました。データのAddressableとSecureを加味した適切な運用はこれからも継続して見直していきたいと考えています。 エス・エム・エスは新しいメンバーを募集しています。 私達データ基盤チームでは、今回ご紹介したデータ基盤の運用から、データパイプラインの開発、データマートやダッシュボードの開発、AIを用いたソリューションの提供など様々な業務を通して事業を支援しています。 弊社の事業に携わってみたい方、興味のある方は、ぜひこちらのページものぞいてみてください。 careers.bm-sms.co.jp open.talentio.com

この記事は株式会社エス・エム・エス Advent Calendar 2024 vol.2の4日目の記事です。 エス・エム・エス Engineering Manager 兼 Hiring Managerの @emfurupon777 です。 はじめに 入社してからずっと関わってきている社内外交流の観点でも継続することの重要さを改めて実感じているので、継続を意識して取り組んでいることについてポエムってみようと筆をとっています。 とはいえ、全部書いてもなーというところで、社内・社外向けの取り組み一つずつ取り上げてみます。社内はLT会、社外は協賛カンファレンスでのノベルティ提供(アイコン缶バッジ)についてです。 ちなみにエス・エム・エスの経営理念は『永続する企業グループとして成長し続け、社会に貢献し続ける』で、設立当初から永続性、継続性が強く意識されているので、継続性について意識を高く持っておくのは自然な話だったりします。仲間は常に積極募集中ですのでこの継続性について興味持っていただいた方はカジュアル面談からぜひお話ししましょう。 社内LT会 1. 観測 エス・エム・エスに入社して社内でどんな取り組みがあるのかなーと思って調べてみるとテックトークという記載が見つかりました。(おお、あるじゃん。まずは参加してみるだけで良いかな？と一瞬思いました) ところが、開催が散発的になっていてしばらく開催されていなそう・・・わかります。やろうぜってなって数回やるとネタが尽きて一旦下火になったりするんですよね。よーし、再起動やってやろうじゃないの。と自分で進めることにしました。 2. 下ごしらえ LT会やるならという感じで世に知見は転がっていて、必要なものは明確。 よし。青島、確保だ！(古い) 会場 エス・エム・エス本社ラウンジ確保！ (100名くらい集まれる広さのラウンジがあったので社内規定みつつ、ガッとおさえる) 経費(軽食、ドリンク等) カルチャー醸成&採用広報文脈で確保！ 登壇者 初回を納会じたてにして確保！ 実績解除しつつ少し先の開催まで少しずつ確保！ ハイブリッド開催の手段 本社に来れるなら寿司でもつまみながらワイワイしたい とはいえ、遠方の人にも参加してほしいからハイブリッドでやりたい とはいえ、ちゃんと配信しようと思うとスイッチャー類とか買ったり運用したりが大変 社内の取り組みだし大丈夫やろ、ということでラウンジにある現地のマイクとZoomを組み合わせるアナログな運営方法を確保！ 3. 当日の仕切り 原則クロコに徹します。軌道に乗せて形式化できるまでは我慢の子。(これ大事ですね) 飲食の手配＆受取 司会 帰る前に経費精算(忘れるとめんどうなので) 4. 継続できているか？ 正直まだまだ続けてやっているとはいえない状況かなというのが正直なところで、まずは100回くらいやってみるのが大事かなと思ってます。それくらい続けていれば一緒に運営してくれる人も多くなってくるし、定期的に開催時期がやってくるのがわかるようになるのではないかと思ってます。 登壇者が集まらないという話を時々耳にしますが、エス・エム・エスの場合は開催スケジュール決めちゃって声をかけてみると意外と？なんとかなります。(といいつつ、私の経験上ではどこの会社でも実は声かけて相談すればなんとかなる) 自発的な登壇は基本にしたいし、もちろんそれも面白いのですが、少し前に入社してきたあの人、Slackで気になることを言ってたあの人、みたいな他薦での登壇依頼もしてみると、普段業務で関わっているのとはまた違ったキャラクターが出てたりして面白いです。内容もあまりこだわりすぎずに好き勝手に話してもらうくらいでやってます。 ノベルティ提供(アイコン缶バッジ) 1. 観測 エス・エム・エスは私の入社前からRubyKaigiをはじめとする技術カンファレンスでブース出展してきたようだというのがesaやSlack検索などで見えました。ブースで提供してきたのは・・・どら焼きとか？ エスエムエス様のスポンサーブースでどら焼きが大量に残って困っているとのこと。Rubyistのみんな助けて！！！ #rubykaigi #dorayaki #sos #sms pic.twitter.com/sC2VYzSyrJ — はたけやまたかし (@htkymtks) 2018年6月1日 私も食べるのが好きなのでいいなーと思うものの、カンファレンスによっては飲食の提供は禁止なんですよね。そして、各カンファレンスに沿った企画はそれぞれの領域のエンジニア仲間にお任せしたほうが刺さるはず。 そうなると、私のメインミッションが採用ということもあり、できれば幅広いイベントに一貫して適用できる、飲食以外のもの、がいいなーという思いが芽生えてきて、これに合致するネタを捻り出す必要がある、というところに至りました。 2. 下ごしらえ さてノベルティのアイデアを考えます。ステッカーとか定番ものやノベルティ制作サービスなどを探索に行って・・・決まりません。(みなさん経験ありますよね？) 周囲に相談しつつ、カンファレンスなどで話が盛り上がるのは誰かなーとペルソナを考えていくと、結局エス・エム・エスの社員に似た人かも？という話になります。 ならばということで皆の言動をSlackなどのコミュニケーションで観測しにいく期間に入ります。(大体3ヶ月くらい。Slackで検索かけたり、リアルで話してるのを横からみてたりします。怪しいw) 基本的なニーズを社員観察で探りつつ、具体的な物品をプライベートで出かけた先で集客状況と合わせてチェックを続けます(社員観察から遅れて初めて1-2ヶ月くらい)。 そんな中で下記の組み合わせでの実現に辿り着きました。 前述の社内LT会でオフィスで顔合わせても、リアルで会うのが初めてで誰かわからない（Slackアイコンとナマの同僚が結びつかない) 普段目にしているアイコンを缶バッジにして身につけてもらおう 区民祭りでやっていた、缶バッチを自分でガシャコンと作れる企画がちびっ子たち(私の子供含む)にウケていた ちびっ子が楽しいと思うならエンジニアにも受けるに違いない（偏見） 何人かのエンジニアに共有してみたところそこそこウケが良かったのでこれで進めることに決定！(残り時間が少なかったというのもあります) もちろんこういう素朴な疑問も頂きますが、いいんです。やってみて反省するんです、ということで突き進みました。 やるからには一定のクオリティは担保したいということで、缶バッジメーカーは業務用のを選びました。安定して生産できています。 3. 当日の仕切り 下記のようなものを用意しておいて、協賛ブースで現地生産を頑張るだけです。 独りでも完遂するぞ！という感じでやっていましたが、一緒に採用をやっている人事さんたちが妖精さんの如く一緒にやってくれましたありがとう。 応募フォーム (アイコン画像を間違いなくいただき、その利用に同意いただくため) モバイルプリンター 缶バッジ用切り抜きカッター 缶バッジメーカー 缶バッジパーツ 4. 継続できているのか？ 今年はありがたいことに協賛ブースを多く出すことができたので、下記カンファレンスにて缶バッジを提供することができました。 RubyKaigi 2024 (現地生産は無し) Kotlin Fest 2024 SRE NEXT 2024 Kaigi on Rails 2024 1年続けてきたので、来年も少しアレンジを加えて企画を継続するのか、新たな企画に起こし直すのかは検討中です。 最後に 今回の記事が同じような取り組みをしている方に読んでいただければ嬉しいです。 そして、LT会を複数の会社合同で開催したり、ブース企画を複数社で連動したりできると面白いかもなーと思っていますので、お気軽に公式Xなどにご連絡ください。 おまけ プライベートの話なんですが、今年は生まれて初めて庭に芝生をはりました。 まずはーということで庭の半分くらいに高麗芝。やってみてはじめて知ることが多く、日々学んでる感が半端ないです。夏芝と冬芝という気温の違いでの植生のギャップも面白い。来年から綺麗に芝生を維持継続できるように頑張ります。 冬枯れの夏芝(左上)と元気に生え始めた冬芝(右下)の様子比較はこちら。

この記事は株式会社エス・エム・エス Advent Calendar 2024 および Datadog Advent Calendar 2024の4日目の記事です。 qiita.com qiita.com こんにちは、介護/障害福祉事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトでSREを担当している加我 ( @TAKA_0411 ) です。SREチームの中では主にモニタリングとオブザーバビリティに関する全般を担当しています。 エス・エム・エスでは複数のプロダクトを開発・運用しており、オブザーバビリティに関するサービスの選定についてはプロダクトの規模感や特性、ユースケースなどを考慮し最適なものを導入しています。私が携わっているカイポケのリニューアルではDatadogを採用しており、サービス全体のオブザーバビリティの設計だったりSLI/SLO周りの設計などをみんなで考えつつ開発を進めている状況です。 会社やプロダクトにより導入しているオブザーバビリティSaaSは様々だと思いますが、私が直近で利用していたものは下記のように推移しています。 前々職 : Mackerel, Datadog 前職 : New Relic 現職 : Datadog 前職ではNew Relicの使い方を学び活用方法を考えるのに多くの時間を費やしていたため、自然とDatadogの知識や成功体験をリセットするUnlearnに至りました。そして改めてDatadogを利用するにあたり、Datadogを再学習 (Relearn) するにはどうすればいいかを考えこの記事を書いています。 オブザーバビリティSaaSの違いについて DatadogやNew Relic、SplunkといったオブザーバビリティSaaSは「システムが生成するテレメトリーデータを収集し分析し可視化する」といった機能の点においては概ね似たようなことが実現できると言えます。 Full Stack Monitoring より引用 インテリジェントオブサーバビリティプラットフォーム より引用 Splunk Observability Cloud より引用 一方で対応しているテレメトリーデータの種類や生成AIの活用、セキュリティへの対応といった機能観点での違いがあったり、テレメトリーデータを操作するためのUIが大きく異なっていたり、取り込むデータの単価や有償のアカウントの有無といったコスト観点での違いもあります。 Relearn Datadog ここからは私がエス・エム・エスに入社してからDatadogをRelearnするに至った経緯や実際に取り組んでみたことについて紹介します。 1. 理想と現実のギャップ 実を言うと入社直後の私は「New RelicもDatadogもやれること・やることは一緒だし、以前利用していたからすぐに思い出せるだろう」と過信していました。しかし、実際にはDatadogのWeb UIの階層構造の変化に戸惑ったり、Datadogの各種設定方法を思い出すのにそれなりの時間を要するという有様でした。 特に前職で利用していたNew RelicのNRQL (New Relic Query Language) があまりにも便利で多用していたため、DatadogにおけるSQLライク “ではない” テレメトリーデータの分析やアラートの設定方法を思い出すのに躓いてしまったことは否めません。 補足 : Previewというステータスですが、DDSQLというSQLライクなクエリ言語がDatadogにもあります。 https://docs.datadoghq.com/ddsql_editor/ というわけで、前々職でDatadogを利用していた頃から今に至るまで多くの機能やWeb UIにアップデートがあり、それにあわせて私の知識をアップデートする必要があることを痛感しました。それほどクラウドサービスの進化は早いのだと驚かされます。 基礎を固めるのは非常に重要であり、特にSaaSにおいては設計思想を学ぶことでより良い活用に繋がるというのは過去に得られた多くの学びのうちの1つです。Unlearn and Relearnということで改めてDatadogを学んでいきます。 2. ドキュメントや書籍による学習 Datadogの使い方を学ぶにあたり、公式のドキュメントやeBookを読みつつ、当時私が購入した書籍が手元にあることを思い出し読み返してみました。 Datadog Cloud Monitoring Quick Start Guide: Proactively create dashboards, write scripts, manage alerts, and monitor containers using Datadog (English Edition) 作者: Theakanath, Thomas Kurian Packt Publishing Amazon この本は洋書であるため、英語が得意ではない私にとっては読み進めるのに若干の負担があります。また、ところどころ現在のWeb UIや機能からビハインドがあります。しかし、Datadogの基本となる考え方や操作を思い出すのには全く問題ありませんでした。300ページという若干厚めの本ではありますが、覚えていた箇所を適度に読み飛ばしてDatadogの知識と記憶を少し取り戻すことに成功しました。 3. Datadog Learning Centerとの出会い さて、ここからが本記事のメインです。 私は技術に関しては書籍で学ぶことが多く、過去にはNew Relicを学ぶために下記の書籍を何度も読み返すことで設計思想を理解し活用してきました。 New Relic実践入門 第2版 オブザーバビリティの基礎と実現 作者: 松本 大樹 , 会澤 康二 , 松川 晋士 , 古垣 智裕 , 梅津 寛子 , 章 俊 , 竹澤 拡子 , 三井 翔太 , 大森 俊秀 , 大川 嘉一 , 中島 良樹 , 山口 公浩 , 齊藤 雅幸 , 小林 良太郎 , 髙木 憲弥 , 板谷 郷司 , 長島 謙吾 , 伊藤 基靖 翔泳社 Amazon Datadogにも入門書的なものがあると嬉しいといった旨の話をDatadogでSales Engineerを務めている Taka2さん に相談してみたところ「書籍についてはすぐに回答はできないが、Datadog Learning Centerというeラーニングがあるのでそこで学ぶことができる」という回答を頂けたのを思い出しました。 Datadogを気軽に試せる環境があればいいのに... というお声もいただいていたかと思いますが、 無料で何度でも環境払い出して使えるlearning centerがありますので、よろしければこちらも活用してみてください 監視対象のDemoアプリも立ち上がります https://t.co/RHHX3cafmC #datadog_japan_meetup https://t.co/RTGWICBLxt — Taka2 (@taka2noda) 2023年10月27日 実際にDatadog Learning Centerを触ってみようと思い下調べをしていたところ、詳細に書かれた下記のブログから有益な情報を得ることができました。 zenn.dev 今の自分にはちょうど良さそうだと考え、実際にDatadog Learning Centerのアカウントを作成していくつかのコースを受講してみました。 Datadog Learning Center Datadog Learning Centerの活用 まずは利用するためのアカウントを作成する必要があります。下記のページにアクセスし必要情報を入力してアカウントを作成しましょう。 アカウントの作成 アカウント作成後、ログインするとコースの受講具合・進捗具合を確かめることができます。途中でサイトから離脱した場合も進捗をカウントしてくれるので「続きは明日やろう」というのも問題ありません。 My Dashboard ということで、試しに基本となる3つのコースを受講してみることにしました。受講する順番はこの流れが個人的にオススメです。まずはオブザーバビリティについて学び、次にDatadogのWeb UIを触りながら全体像を掴む、そしてDatadogの基本的な機能の実践的な使い方を学ぶという流れです。 1. Introduction to Observability Introduction to Observability このコースではDatadogを使い始める前に「オブザーバビリティとはなにか」について学びます。オブザーバビリティとモニタリングの世界を初めて学ぶ人のために設計されており、Datadogやそれ以外のモニタリングサービス・ツールに関する予備知識は不要となっています。 このコースは動画を見て学ぶ座学形式となっており、オブザーバビリティの主要なテレメトリーデータであるメトリクス・トレース・ログについて理解し、モニタリングとアラートについて学ぶことができます。言語は英語ですが、日本語字幕のON/OFFや再生速度の変更などの設定が可能です。ちなみに日本語字幕は比較的良好な精度でした。 私はSREとしてテレメトリーデータに慣れ親しんでいるという自負はありますが、それぞれのテレメトリーデータの定義、構成要素、収集する必要性については言語化が苦手でした。曖昧な理解にとどまっていたのでしょう。しかし、このコースを受講することで各テレメトリーデータの定義についての理解が進み、言語化も前に比べて改善したと思っています。 仮に各テレメトリーデータの定義を忘れてしまってもこのコースに戻って来ることで何度も復習できます。このコースはDatadogの利用の有無に関わらず多くのエンジニアにオススメです。 2. Datadog Quick Start Datadog Quick Start 「あなたはマイクロサービスで構成されたEコマースアプリの健全性とパフォーマンス監視のためにDatadogを使い始めました」というストーリーで始まるこのコースでは、下記4つの項目についてDatadogの検証環境 (ラボ環境) を使用して学ぶハンズオン形式となっています。画面は検証環境のアカウント情報が記載されているコンソールと、レッスンのテキストで構成されています。 ダッシュボードの操作 ログデータの検索と可視化 サービスカタログによるサービス詳細の確認 モニターの管理 このコースはDatadogのWeb UIから各機能へのアクセス方法や、データを調査する際にどういった流れで行うのかといった基本的なDatadogの操作方法や考え方を学ぶことができます。私がDatadogをRelearnするにあたって必要だったのはまさしくこのコースであり、入社後すぐに取り組めば良かったと後悔する程度には得られるものが多かったです。 3. Datadog Foundation Datadog Foundation 最後に紹介するのはDatadog Foundationというコースです。このコースは下記の5つの機能を学ぶためのレッスンで構成されており、それぞれのレッスンは前後半2つのパートで構成されています。前半のパートでは座学で機能とコンセプトを学び、後半のパートではハンズオン形式でDatadogの検証環境を使用して設定変更などを行います。 Universal Service Monitoring (USM) and Service Catalog Logs Metrics Integrations Dashboars まずは動画を見て機能とコンセプトを知り、実際に検証環境でWeb UIを操作してみて理解するという構成がいい感じです。同じハンズオン形式であるDatadog Quick Startのコースに比べてそれぞれの機能をより深く学ぶことができるため、より実践的なコースであるという印象を受けました。特に後半のハンズオンパートは意外とボリュームがあり驚きました。コンソールにIDEのメニューが増えており、docker-compose.ymlファイルを見つつDatadogの検証環境の表示を比較するといったものがあります。 Datadogでのログ周りの集計やビジュアライズの方法をすっかり忘れてしまったこともあり、こちらのコースでしっかりと復習することができました。簡単な確認テストがいくつかあるので復習もできます。 まとめ Datadog Learning Centerを活用することでDatadogの知識をRelearnした話を書いてみました。 Datadog Learning Centerは無料で利用でき、実際にDatadogの検証環境が利用できる期限付きのアカウントが払い出されるため、書籍やドキュメントなどに比べて学習効率が高いと感じました。これからDatadogを触る人や、私のように久しぶりに触る人にとっては最適なコンテンツのように思えます。チーム共通の知識としてエンジニアの入社後のオンボーディングに組み込んでみたり、あまりDatadogを使いこなせていないチームに受講して貰って活用のきっかけにしてもらうというのも良さそうです。 Datadog Learning CenterにはDatadogの機能を学ぶためのコースだけではなく、前述のオブザーバビリティへの理解を深めるコースやSite Reliability Engineerについて学べるコース、OpenTelemetryを学べるコースなどもあります。先日のJAWS FESTA 2024では「オブザーバビリティはツールを導入するだけでは実現できない」という話をしましたが、オブザーバビリティの意義を正しく理解することでHowとしてのDatadogがプロダクトの課題を解決する手助けになるでしょう。 また、Datadogの認定試験ではDatadog Learning Centerの一部のコースを学ぶことが推奨されており、学習 → 認定 → 活用という一連の流れが上手く設計されているという印象を受けました。 www.datadoghq.com 私も来年こそはDatadog認定資格を取得しようと考えているため、まずは全てのコースを制覇しつつDatadogへの理解を深めていこうと思います。みなさまもDatadog Learning CenterでLearn・Relearnに挑戦してみてください。

この記事は株式会社エス・エム・エス Advent Calendar 2024の12月4日の記事です。 qiita.com 保育士人材バンク のサービスを担当しておりますエンジニアの田実と申します。 保育士人材バンクは保育業界で働く方と事業所のための就職・転職マッチングサービスです。 本記事では2024年の保育人材バンクの技術基盤改善の取り組みを振り返っていきます！ コンテナ化 今年一番大きかった基盤改善は何と言ってもコンテナ化です！コンテナ化前はEC2上にアプリケーションがホスティングされており、デプロイはrsync、ログはSSHでサーバーに入って直接ログファイルを確認、といった運用を行っていました。 EC2でホスティングされているためミドルウェアのアップグレードが気軽にできなかったり、デプロイ方法もアトミックな変更ではないためデプロイ中のアクセスがエラーになることもありました。ログの確認はログファイルを直接awk、sort、uniqコマンドを使って走査していく方法になるため手軽に確認できない課題がありました。開発環境に関しても１人１環境といった形で運用していたため、複数の施策を並行して開発する場合、対応内容がバッティングする問題もありました。 これらの課題を解決するためアプリケーションをコンテナでホスティングするよう改善を行いました。コンテナ化により、 ミドルウェアの変更が簡単に行えるようになった デプロイがコンテナベースになりアトミックな変更になった ログがCloudWatch Logsに連携され、簡単に確認・集計できるようになった プルリクエストごとの環境（Edge環境）が作成できるようになった など開発体験が大幅に向上しました。取り組みの詳細はSREチーム伊藤のPHPカンファレンス小田原2024での登壇資料にも書かれておりますので是非ご参照ください！ speakerdeck.com PHPとLaravelのアップグレード 保育士人材バンクのサイトはPHP・Laravelで実装されており、これらのアップグレードを行いました。アップグレードガイドの確認をしつつ、手動テスト・自動テスト・PHPStanによる静的解析・Rectorによる自動リファクタリングを行い、不具合を検知したりアプリケーションコードを修正しました。社内でも同バージョンへのアップグレードを行ったアプリケーションがあったため、知見を聞いて回ったりしました。 前日に急いで聞き回っている図 Cookieの暗号化・復号化のロジックが変わる変更で一部影響がありましたが、特に大きな不具合なくリリースができました。アップグレードにより、PHPやLaravelの新しい機能を利用できるようになり開発体験が向上しました。特にmatch式、Enum、Constructor Property Promotion、readonly の機能は積極的に活用しており、より保守性の高いコードを書けるようになりました。 GitHub ActionsによるCI/CD導入 コンテナ化に伴い、GitHub Actionsで ecspresso を使って自動デプロイを行っています。 また、GitHub ActionsによるCIも導入し、プッシュ時に以下の処理を動かしています。 Laravel Pint , Biome を使ったフォーマットチェック PHPStanによる静的解析 PHPUnitによる自動テスト・カバレッジ集計 technote-space/assign-author を使ったプルリクエストの自動アサイン 以前は手動テストやレビューで品質保証することが多かったのですが、CI導入によりデグレ防止やコード整形など一定の品質水準を保つことができています。 Laravel Pint導入に伴い既存ファイルを一括変更した図 Datadog APMの導入 以前はアプリケーションのパフォーマンス計測ツールを導入していなかったため、ボトルネックがどこにあるのかがわからず、パフォーマンス改善戦略を立てることができませんでした。また、パフォーマンスチューニング後の効果測定も難しい状況でした。これらの課題を解決するため、Datadog APMを導入しました。 Datadog APMによりN+1クエリやindexが効いていないクエリなどのボトルネックがわかっただけではなく、アクセス数が多いエンドポイントや、メルマガなどの施策によりスパイクしやすいエンドポイントなどアクセス傾向を把握することができました。 リリース前後のレイテンシ変動が可視化されたため、効果測定も容易になりました。 N+1対策の例。7.5s => 180msと40倍の改善！ 自動テスト拡充 PHP・Laravelのアップグレードやリファクタリングを安全に行うため、自動テストを拡充しました。4〜5ファイルほどしか無かったテストコードが、今では100ファイル以上、カバレッジも70%を越えました。PHP・Laravelアップグレードなど大規模な変更を行うときも自動テストにより不具合を検知するなど、自動テストの効果を実感しています。 octocovでカバレッジ集計しています。Code To Test Ratioはこれから頑張る！ PHPStanの導入 前述の通り、静的解析ツールとしてPHPStanを導入しています。未定義変数の参照、use漏れ、クラス名・メソッド名間違い、引数の過不足・型間違いなどの不具合を検知してくれるため、堅牢なコードを書くのにとても便利です。 現在はPHPStanをレベル6で運用しています。レベル6は引数や戻り値の型付けが必須なため ignoreErrors で対応しているのが現状なのですが、一部Rectorを使った自動型付けを行い型エラーを解消していたりします。 OPcacheの有効化 OPcacheが無効だったため有効にし、全体で200〜300ms程度のレスポンス改善を行いました。 16:00ごろに適用して全ページでレスポンス改善した図 パフォーマンス向上だけではなく、CPU・メモリ負荷も下がりインフラコストも抑えられています。ちなみに、PHPのバージョンによってはJITを有効化するとセグメンテーションフォルトが発生する事象があったため、安全のためJITは無効化しています。 アプリケーションログの改善 コンテナ化に伴い、ログをCloudWatch Logsに連携するようになったので検索性を向上するために構造化ログ（JSONL）にしました。具体的には以下のようにMonoLogのフォーマッタ・プロセッサーを設定しています。 <?php class CustomSettingApply { public function __invoke ( Logger $ logger ) : void { $ introspectionProcessor = new IntrospectionProcessor ( Level :: Debug, [ 'Illuminate \\ ' ]) ; $ webProcessor = new WebProcessor () ; $ logger -> pushProcessor ( new UidProcessor ()) ; $ logger -> pushProcessor ( $ introspectionProcessor ) ; $ logger -> pushProcessor ( $ webProcessor ) ; $ logger -> pushProcessor ( function ( LogRecord $ record ) : LogRecord { $ record [ 'extra' ][ 'platform' ] = 'laravel' ; return $ record ; }) ; foreach ( $ logger -> getHandlers () as $ handler ) { if ( $ handler instanceof StreamHandler ) { $ handler -> setFormatter ( new JsonFormatter ()) ; } } } } JSONLのフォーマット以外の処理だと以下のような情報も入れ、検索性やオブザーバビリティを上げる試みも行っています。 UidProcessorでリクエストIDを払い出し IntrospectionProcessorでログが吐かれたファイル名・クラス名・行番号などを記録 WebProcessorでwebリクエスト関連の情報を付与 Viteを導入 以前はSCSSのビルドを各自ローカルで実行し、ビルド物であるCSSをgitにコミットしてrsyncでリリースしていました。この方法だと、元のSCSSだけでなくビルド物をコミットする必要があるため、ビルド物のコンフリクトが多発していました。そのため、ビルドツールである Vite を導入し、開発時のHotReloadやデプロイ時の自動ビルドができるようにしました。これにより手動ビルドやコミット、コンフリクト解消の手間がなくなりました。 また、SCSSだけではなく一部のJavaScriptもViteでビルドしています。ビルドツールを入れることでライブラリのバージョン管理やキャッシュバスティングもやりやすくなりました。 不要コード・パッケージの削除 保守性を上げるために不要なコードは随時削除していきました。結果、40万行のコードを削除しました。 4400ファイル、30万行の大削除の図 CSS、JS、IMGの不要ファイルがほとんどで、grepしたりアクセスログを見て泥臭く削除していきました。PHPに関してはPHPStan、Rectorなどのツールを使って削除対象を特定したり、明らかに使って無さそうなwebエンドポイント・コマンドを逐次ヒアリングして削除していきました。PHPの削除に関しては、前述の静的解析や自動テスト拡充により誤って削除することもほとんど無かったです。 Renovateによる定期アップグレード 依存ライブラリのアップグレードを定期的に行うと、ライブラリの変更量が減り影響範囲が読みやすくなったり、最新機能を利用できるようになるなど開発体験を上げることができます。そのため、アップグレードを定期的に行う仕組みとして Renovate を導入しました。Renovateはアップグレードのプルリクエストを１つにまとめてくれるなど小回りの効く設定を入れられるのが運用上のメリットです。今は週次の当番制にしてRenovateが作ったPRを担当者がリリースするようにしています。 振り返り（スプリントレビュー）の実施 ２週に１回、振り返り会を実施するようにしました。エンジニアだけではなくマーケティングチームの方にも参加いただき よかったこと・続けたいこと Thank you！！感謝！！ やってわかったこと・気付き これどうする？これは変えていきたい の４つに分けて付箋を貼っていき発表しています。 個人的には「Thank you！！感謝！！」のところが良いと思っていて、エンジニア間だけではなくマーケティングチーム・エンジニア間で改めて感謝を伝える場として、とても良い振り返り会になっていると感じています。 まとめ 保育士人材バンクでの技術基盤改善の取り組みについて紹介しました。本記事では技術基盤の改善を中心に紹介しましたが、攻めの施策開発もそれ以上にたくさん行っています。これまで攻めの施策をしっかりやってきた、やっているからこそ守りの施策の意義が出ると思っています。改めて保育士人材バンクに携わっている、携わってきたすべての方々に感謝しつつ、今後もこれまで以上にエンジニアリングで事業を加速させていき、より社会貢献ができていければと考えています。

この記事は株式会社エス・エム・エス Advent Calendar 2024の3日目の記事です。 qiita.com 介護・障害福祉事業者向け経営支援サービス「カイポケ」の開発をしているエンジニアの神谷です。先日、AWS GameDayに参加し、セキュリティ・インシデント調査の疑似体験をしてきましたのでその様子をレポートします。 AWS GameDayについて AWS GameDay はAWSが主催する、仮想的に用意された環境の中で、課題を解いて参加チーム間で成績を競うゲーム形式のセミナーです。 今回参加したGame Dayは、「セキュリティインシデント疑似体験」がテーマとなっており、典型的なセキュリティインシデントを再現させたログを分析し、チーム対抗のクイズ形式で調査していくものでした。 私は、情報処理技術者試験で机上のセキュリティインシデント分析する問題を解いたことはありましたが、実際の業務で触れる機会はこれまでなかったので、体験できる貴重な機会だと思い参加を決めました。 おことわり: 問題の詳細な内容については公開が禁止されておりますので、このエントリーでは触れません。 演習内容 始めに、ログ分析に使用する、SIEM on Amazon OpenSearch ServiceのDashboard（以下OpenSearch Dashboardと表記） の使い方と、調査するシステムの構成の説明を受けました。 GameDayの大まかな流れは次のようなものでした。 疑似的な攻撃を受けたシステムのログがOpenSearch Dashboardで検索できる状態で問題が与えられ、参加者はログからインシデントを分析し問題に解答していきます。 問題では、どのシステムがどのように侵入されたのか、どのような影響を受けたのか、影響を受けたのはいつか、被害範囲はどこまでなのかといった分析能力が問われました。 問題に回答することでスコアを獲得、ヒントを使用したり間違った回答をするとスコアが減点されるため、スピードと正確性の両方が求められました。 エス・エム・エスチームは次のような作戦で課題にチャレンジしました。 ハイスコアを狙いつつも、参加メンバーが別々の問題を解くのではなく、全員で画面共有をしながらモブ作業をすることにしました。 参加したメンバー間にログ調査の経験やAWSのセキュリティなどの知識に差があったため、今回のモブ作業を通してお互いのスキルが高められるようにこのような問題の解き方にしました。 それでは、問題の内容について、ネタバレにならない範囲で紹介します。 序盤の問題は、問題文自体がヒントとなっており、かつログからも読み取りやすい典型的な攻撃手法だったため順調に回答を進めていきました。 中盤の問題は、少しログやヒントを読むだけでは攻撃者の意図が読み取りづらく、複数のログから絞っていくスキルが求められてきました。またTCP/IPやWebアプリケーションの知識も求められました。 残念ながら今回は最終問題に到達したところで時間切れとなりました。 今回私たちのチームでは、モブ作業で課題にあたったことで、 ログ解析に慣れていないメンバーがOpenSearch Dashboardの操作で困った時には有識者にナビゲーションしてもらい、スタックしてしまうことを回避できました。 また、難問にあたった際には、関連するログがここにあるのではないか、こんな条件で探してみてはどうか、互いの持つ知識でカバーができました。 結果的に、回答できた問題数は限られていましたが、限られた時間の中で無駄なくログ調査の経験を積むことができたと感じています。 演習終了後に今回の演習で扱われたセキュリティインシデントのシナリオの解説が行われました。 最終問題のシナリオには、調査を難しくする手法も使われており、前提知識がない状態でこのようなログを元にインシデント分析をするとなると解決まで骨が折れそうだなという印象を受けました。 得られた知見 最後に、今回のAWS GameDayを通して得られた知見についてまとめます。 今回 GameDayの課題としてOpenSearch Dashboardに用意されていたログは、複数のログを組み合わせて検索しやすいよう、あらかじめ正規化されたログになっていました。そのため、初見のシステムでも違和感なく調査を進めることができました。 一方で、ログが適切に正規化されていなかったり、素早く検索できる仕組みが整えられてない環境では、調査が難航することが想像できます。 セキュリティインシデント対策に限られた話ではありませんが、システムを設計する段階から、どのようなログがあれば万一の際にどこまで調べることができるのかを考えるきっかけになりました。 AWS GameDayは他のテーマでも開催されているようですので、見識を広めるために今後も参加してみようと思います。

スクラムマスターの貝瀬です。2024年6月から業務委託として、介護/障害福祉事業者向け経営支援サービス「カイポケ」に関わる組織やプロセスの改善を支援しています。 支援先の部門では、私が参画する以前よりカイポケリニューアルプロジェクトにスクラムをベースとした開発プロセスを導入していましたが、2024年8月にLeSS（Large Scale Scrum：大規模スクラム）を導入しました。今回はLeSSを導入することになった経緯と、導入の最初のステップを紹介したいと思います。 はじめに 本題に入る前に、私の略歴と、エス・エム・エスを支援することになったきっかけを紹介します。 私の経歴 現職の「 合同会社makigai （マキガイ）」を創業する前は、IT系の事業会社を中心に活動していました。キャリア3社目となる株式会社ディー・エヌ・エー時代に、開発部門におけるマネジメント上の課題を解決するために導入したのが私とスクラムとの出会いです。 以降、マネージャー・スクラムマスター・プロダクトオーナーなどの様々な役割で、既存事業・新規事業・オフショア開発・営業部門・人事領域などの様々なプロジェクト・組織にスクラムを導入・活用して、10年以上が経ちました。大小さまざまな経験（成功も失敗も）を含めると、3桁を超える程度のスクラム活用経験はあるかと思います。 そうして積んだ経験を体系的に整理し様々な企業にも共有してみたかったのと、スクラムの師匠であり友人でもある江端さんと一緒に働いてみたくて、プロダクト開発のコーチ集団Odd-e（オッドイー）の日本法人である Odd-e Japan （オッドイー・ジャパン）にも4年ほど在籍しました。 カイポケのプロダクト開発におけるLeSSの導入事例は、私の経験の中でも広く知っていただく価値があると感じ、こうしてブログを書くことになりました。 エス・エム・エスとの接点 ディー・エヌ・エー時代の同僚である田辺さん（ @sunaot ）の紹介で、2023年秋ごろプロダクトマネージャー向けの研修を開催したことが最初のエス・エム・エスとの接点でした。その後しばらくして、再び声をかけていただき、カイポケの開発関係者に向けて、スクラムの基礎から応用まで、実践できるようにしてもらえないかという相談を受けました。通常私は、スクラムマスターの方を育成する立場（いわゆるアジャイルコーチ）で参画することが多いのですが、カイポケには専任のスクラムマスターがいないということだったので、私がその役を引き受けることになり、現在に至ります。 LeSS導入の背景 LeSSを導入する前の組織構造は、1つのプロダクトに対して、複数のプロダクトオーナー、複数のプロダクトバックログ、複数のチームという構造でした。開発に携わる人数としては約50人程度だったかと思います。当時は、2チーム以上の協力が必要な開発を行う際に、以下のような問題が発生していました。 他チームに依存するPBI（プロダクトバックログアイテム）がある場合、着手したスプリント中に完成しない。 過去に完成させたはずのPBIに対して、突然他チームからの問い合わせや修正依頼が発生する。 私がスクラムマスターとして参画してしばらくの間は、問題の発生頻度が少なかったため、プロダクトオーナーやチーム、マネージャーやステークホルダーたちもさほど困っていないようでしたが、これは上記で述べた組織構造に起因する問題の一つです。いつか（おそらく半年以内に）必ず問題の優先順位が上がると予想していたので、チームレベルの改善を支援しながら、LeSS導入の準備を進めることにしました。 LeSS導入の戦略 LeSSはカイポケのように数十名規模の組織で1つのプロダクトを開発する際に有効なフレームワークです。LeSSの大雑把な構造としては、1つのプロダクトに対して、1人のプロダクトオーナー、1つのプロダクトバックログ、複数のチームが紐付きます。 公式サイト より引用 LeSSは守破離の学習モデルに沿って考えられており、「守（基礎となる部分）」は、LeSSの原理・原則と、ルールとして定義されています。カイポケへのLeSS導入にあたって最も重要視したのは以下のルールです。 単一のプロダクトグループへの導入では、最初から教科書的なLeSSの体制を作るようにします。これはLeSSの導入にとって不可欠です。 さらに大きなプロダクトグループを超えて大規模な組織に導入する場合は、現地現物を用いて、実験と改善が当たり前であるような組織をつくり、段階的にLeSSを導入します。 （出典：Craig Larman・Bas Vodde（著）、榎本明仁（監訳）、荒瀬中人・木村卓央・高江洲睦・水野正隆・守田憲司（訳）『大規模スクラム Large-Scale Scrum(LeSS)』、丸善出版、2019年、52頁） 上記を踏まえ、LeSS導入までの間に意識していたことは以下の3つです。 チームレベルのスクラム理解度・実践力をあげること 複数チームが関わる問題を観察し原因に対して仮説を立てること スプリントレトロスペクティブ等におけるチーム・組織に対する改善アクションが、部分最適になりすぎないよう選択肢の幅を広げること 取り組みの具体例についてはこの後紹介します。 勉強会を活用したスクラム理解度・実践力向上の土台作り スクラムのルールとLeSSのルールと自分たちのやり方との違いを知り、改善につながるネクストアクションを考えていただくことを目的に勉強会を開催しました。 過去にプロダクトマネージャー向けの研修を実施したことは冒頭で述べたとおりですが、熱心に参加されている方が多くいらっしゃったことを鮮明に覚えています。実際にスクラムマスターとして参画してみると、当時学んだことを現場で実践されている方が多いことにも衝撃を受けました。こうした経緯から、スクラムやLeSSに関する学習の機会を設ければ、自主的に現場の業務に活かしていただけるのではないかという期待があったためです。 実際に開催告知をした時のリアクション スクラムに関するワークショップ スクラム勉強会はワークショップ中心の、参加者自身に考えていただくスタイルで行いましたが、当初の狙い以上に盛況となりました。これは、人から与えてもらうのではなく自分自身で学ぶこと・改善することが習慣化していることを表す一例だと捉えています。さらには、プロダクト開発に直接関わる方々だけでなく、マネージャーやステークホルダーも積極的に参加されていたので、全体を巻き込んだ改善活動を促進する上での土台がしっかりしている組織であると感じました。私が主催する勉強会は現在も継続していますが、それぞれのチームでも、スクラムやLeSSに関する勉強会を自主的に開催しています。 参考までに、スクラム勉強会の参加者からいただいたフィードバックの一部を紹介します。 よかった。自分のわからないこと、解決できないことが、適切に難しいことだという現在地の確認になった QAで、組織やプロダクトの状況視点ではなく「スクラム」という視点で切り離して会話ができたことが自分にとってはよいことでした。社内で話すとどうしても「現状を鑑みて」になりやすいので、まずはフラットにスクラムを行うために必要な情報が整理でき大変勉強になりました。 スクラムマスター不在の状況で今までやってきたため、そもそもスクラムマスターの役割と必要性があまり理解されていないように感じています（自分も含めて）。グループワークの中で、4グループ中2グループが、スクラムマスターについて付箋を出していることからも、スクラムマスターの役割と必要性について取り扱ってほしいです。 LeSS 勉強しようと思って手つかずだったので概要がつかめて良かったです！ LeSS導入準備のための現地現物 私が参画する以前はスクラムマスター不在でしたが、チームの中でファシリテーターを決め、スプリントプランニングやスプリントレトロスペクティブなどのスクラムイベントを実施していました。そこにオブザーバーとして参加しながら、LeSSの導入によって改善が見込まれる事象を観察していました。同様に、プロダクトバックログやスプリントバックログをはじめとするスクラムの作成物、作成物に付随するアウトプット、スクラム以外の定例会議なども観察対象です。 一方、勉強会の効果もあってかチームから自主的にフィードバックを求められるようになってきました。例えば「他チームに依存するPBIが着手したスプリント中に完成しない」といった類の問題が出てきた場合にはLeSS導入時の妨げとなるような部分最適の改善にならないように、視野や選択肢を広げるためのフィードバックやオプション提示などをしていました。問題の真因が組織構造などにありそうな場合は、考察をまとめながら、フィードバックや提案の機会を待つようにしました。 冒頭でも触れたように、その機会が訪れるのは半年くらい先になるだろうと踏んでいたのですが、驚くことに私が参画してから2ヶ月後にはLeSS導入が決定、3ヶ月後にLeSSが開始されるという意思決定の早さでした。 多くのチーム、多くの方々が課題に感じていたことへのソリューションがLeSSだったというだけの話ですが、組織全体にスクラムの5つの価値基準が浸透していることが成功の秘訣だったと思います。 スクラムを成功させるためには、5つの価値基準をより高度に実践することが求められる。 確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage） チームは継続的な改善とお互いのサポートを確約する。チームは最善の成果を上げるために、スプリントでの作業に集中する。チーム、プロダクトオーナー、そしてステークホルダーは、作業と課題を公開する。チームのメンバーはお互いを能力があり自立した人間として尊敬し、一緒に働く人たちからも尊敬される。チームメンバーは、正しいことを実行し、困難な問題に取り組む勇気を持つ。 これらの価値基準は、作業、⾏動、そして振る舞いの⽅向性を⽰している。下される決定、実⾏される手段、スクラムの使⽤⽅法は、これらの価値基準を強化するものであり、減少させたり損なったりするものであってはならない。これらの価値基準がチームや⼀緒に働く⼈たちによって体現されると、スクラムの経験主義を支える三本柱「透明性」「検査」「適応」が実際に機能し、信頼が築かれる。 （出典：「スクラムガイド(LeSS版)」 https://less.works/jp/less/scrum-guide 、参照2024年11月14日） LeSS導入直前のSlack おわりに 今回の記事ではカイポケにLeSSを導入した経緯と、最初のステップについて紹介させていただきました。カイポケではスクラムおよびLeSSによるプロダクト開発を行っており、現在も、実験と改善を積み重ねながら進化中です。機会があれば、LeSS導入後の事例も紹介したいと思います。 社会課題の解決、顧客価値の創造、スクラムによるプロダクト開発、などに興味のある方は、ぜひエス・エム・エスへの入社を検討してみてください。

介護/障害福祉事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトでSREを担当している加我 ( @TAKA_0411 ) です。SREチームの中では主にモニタリングとオブザーバビリティに関する整備や調整を担当しています。 最近社外で登壇する機会がありまして、オブザーバビリティに関する内容の登壇をいくつかしてきました。同一テーマで複数回の登壇をするのが初めてということもあり、そこで得られたものや気付きについて振り返ってみたいと思います。 直近で登壇した / 登壇するイベント まずは直近登壇したイベントについてそれぞれ紹介していきます。 1. JAWS PANKRATION 2024 jawspankration2024.jaws-ug.jp 開催日 2024/08/24 (土) 12:00 PM 〜 2024/08/25 (日) 12:00 PM 登壇形式 プロポーザルによる採択を経てオンラインにて登壇 参加者数 約600人 JAWS PANKRATION 2024は2024年8月に開催されたAWSユーザーグループのイベントです。24時間連続でオンライン開催され、国内外のエンジニアが登壇するグローバルイベントと位置づけられていることからスライドは英語であることが必須となっています。 登壇希望者はCall for Proposalsを確認したうえでプロポーザルを提出し、運営チームの選考を経て採択されるというカンファレンスでよく見る形式となっています。私は下記の内容でプロポーザルを提出し、無事採択いただく運びとなりました。 # タイトル How to achieve full-stack Observability with AWS (フルスタックオブザーバビリティをAWSで実現する方法) # 概要 In modern distributed complex systems like microservice architectures, observability is essential for quickly identifying issues. While understanding the concept of observability as proposed by the CNCF, I will suggest methods to achieve full-stack observability utilizing AWS services. マイクロサービスアーキテクチャのような近年の複雑な分散システムでは、問題を迅速に特定するためにオブザーバビリティが不可欠です。 CNCFが提唱するオブザーバビリティの概念を理解しつつ、AWSのサービスを利用してフルスタックオブザーバビリティを実現する方法を提案します。 持ち時間は15分、オンラインイベント故に参加者とのインタラクティブなやり取りは難しいと考え、前半はCNCF (Cloud Native Computing Foundation) のWhitepaperを紹介しつつクラウドベンダーによるフルスタックオブザーバビリティの説明をし、後半ではAmazon CloudWatchでの実現方法の話をしています。 既にセッション資料とアーカイブが公開されています。 jawspankration2024.jaws-ug.jp 2. JAWS-UG函館 勉強会 vol.14 jawsug-hakodate.connpass.com 開催日 2024/10/05 (土) 登壇形式 登壇枠への応募を経てオフラインにて登壇 参加者数 19人 JAWS-UG函館はその名の通り北海道の函館市近郊で開催されているJAWS-UG (AWS User Group – Japan) の勉強会です。私は2024年6月に地元北海道 (札幌) へUターンしたということもあり、北海道つながりで登壇しませんかとのお誘いがありまして登壇する運びとなりました。 参加者の属性と登壇内容についてヒアリングしてみたところ初学者向けだと嬉しいという話があり、JAWS PANKRATION 2024の資料を一部改変して初心者でも理解しやすいよう心がけました。具体的には序盤のCNCFやフルスタックオブザーバビリティの説明を削って「オブザーバビリティとは何か」「モニタリングとは何が違うのか」といった内容に差し替えています。 3. JAWS FESTA 2024 in 広島 jawsfesta2024.jaws-ug.jp 開催日 2024/10/12 (土) 登壇形式 プロポーザルによる採択を経てオフラインにて登壇 参加者数 343人 JAWS FESTA 2024 in 広島は2024年10月に広島で開催されたJAWS-UGによる全国規模のイベントです。JAWS-UGは年に2回全国規模のイベントを開催していて、春に都内で開催されるのがJAWS DAYS、秋に地方で開催されるのがJAWS FESTAです。 登壇希望者はCall for Proposalsを確認したうえでプロポーザルを提出し、運営チームの選考を経て採択されます。JAWS PANKRATION 2024と同じ形式ですね。私は下記の内容でプロポーザルを提出し、11倍 (!!) という倍率の中で無事採択いただく運びとなりました。 # タイトル Amazon CloudWatchで小さく始めるWebサービスのオブザーバビリティ # 概要 https://jawsfesta2024.jaws-ug.jp/sessions/timetable/D-1/ 採択されたのがテクノロジートラックで持ち時間が20分ということもあり、JAWS-UG函館でお話した内容に加えて「Amazon CloudWatchの良いところ・頑張ってほしいところ」「Amazon CloudWatchとObservability SaaSの比較」を盛り込んで内容を調整しました。自分としては一連の内容の完成形のつもりで登壇に臨みました。 セッション資料は既に公開済みです。 speakerdeck.com 4. 第39回 JAWS-UG札幌 勉強会 〜JAWS FESTA 2024 in 広島 re:Cap〜 jawsug-sapporo.connpass.com 開催日 2024/11/19 (火) 登壇形式 登壇枠への応募を経てオフラインにて登壇 参加者数 20人 JAWS FESTA 2024 in 広島に参加していたJAWS-UG札幌のメンバーから「運営スタッフを担当していたのでセッションを聞けなかった」「タイムテーブルが被ってしまい聞きたかったセッションを聞けなかった」などという話があり、であれば札幌でre:Cap (振り返り) として登壇の再演をやりましょうという流れから発生したのがこちらのイベントになります。 再演ということで基本的にはJAWS FESTA 2024で話した内容をそのまま話す予定でしたが、イベント参加者と話して得られた気づきを反映したものをお話します。 登壇内容の振り返りと気付き 直近の登壇は全て同じテーマで「オブザーバビリティとは何か、Amazon CloudWatchでどのように始めるのか」です。イベントと参加者の属性に応じて若干内容を調整はしますが、ベースとなる内容はほぼ一緒です。 同じ内容での複数回の登壇には当初懐疑的でしたが、いざやってみるといくつかのメリットを感じることができました。 1. 発表内容の洗練 似た内容で複数回登壇することが過去なかったので気づかなかったのですが、繰り返してみると下記のような色々な反省点が見えてきます。 「スライドの内容が前後で微妙に繋がっていない」 「内容を補完するための図が必要」 「前提となる話があったほうがよい」 「結論がぼやけている」 資料は事前に社内でレビューしてもらい自分自身で何度もリハーサルしていますが、発表当日になってリハとは環境が変わることで違和感に気づいてしまうケースがありました。これは純粋に私自身のプレゼンスキルの未熟さだと思います。 しかし今回は一連の登壇を経て資料と発表のアップデートを行い、最終的には自分でも納得できるようなものに近づけた気がします。特にJAWS FESTA 2024では参加されていた方のブログで「20分という短い時間でしたがプレゼン内容が洗練されていた」という評価をいただくことができました。 2. 理解の深化 アクティブ・ラーニングにおいては理解度を深めるには実際に説明してみることが重要であると言われています。資料作成のために調査する → 登壇する → 参加者と話す → 気付きを得る → また調査する → 登壇するというループを経てオブザーバビリティへの理解が深まり、ようやく背景など含めて説明できるようになりました。 一連の登壇により資料をブラッシュアップする過程で話の根拠や背景を改めて調べ直してみたり、概念やサービスにアップデートがあるかを確認してみたり、他に参考となる資料がないかを探すことで知識を定着し理解が深まることに繋げられたと考えています。 発表内容に明確な間違いが無い限りは過去の登壇資料を見直すことがなかったのですが、今後は意識的に見直していくことで近いメリットを得られるかもしれません。 まとめと今後の展望 ブログタイトルにある「オブザーバビリティ登壇マラソン」のとおり、ここ数ヶ月間でオブザーバビリティに関する内容での登壇を複数回行ってきました。オブザーバビリティの考え方や実践方法、各クラウドベンダーのオブザーバビリティへの取り組みに関する発表を行い、資料のブラッシュアップを経て多くの知識を得ることができました。 今回の一連の登壇では、改めてオブザーバビリティに関する知識の継続的なアップデートは必要不可欠であること、特定のテーマでの発表を続けることで理解が深まること、興味のあるテーマを見つけたら繰り返し登壇してみることといった学びを得ることができました。 一方でサービス特有の課題、苦労、困難、失敗、解決といった他の人にはできないリアルな内容での登壇はまだできていません。オブザーバビリティやAmazon CloudWatchのような一般的な内容の登壇にも価値はあると思いますが、やはりサービスやドメイン固有の苦労話こそ面白さと価値があると私は考えています。ですので、今後はカイポケのリニューアルにおける苦労話や失敗談などを話せるようにネタ探しや挑戦をしていく次第です。 もし登壇の場や機会がありましたら、加我のTwitter (X) アカウント ( @TAKA_0411 ) まで気軽にお声がけ下さい。 おわりに 株式会社エス・エム・エスは「継続可能な日本の未来をつくる」テックカンパニーを目指し「高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける」をミッションに掲げて様々な事業を展開しています。 ヘルスケア・医療・介護・シニアライフ業界の課題解決やバーティカルSaaSの開発に興味のあるSREの方がいらっしゃいましたらぜひお話しましょう！

こんにちは、2024年8月にエス・エム・エスに入社した鈴木と申します。 入社エントリーかつ、現在担当しているカイゴジョブエージェントについてお話します。よろしくお願いいたします！ これまでの経歴 自社でWebサービスを提供している数社でエンジニアをやっていました。技術スタックとしては、オンプレミスサーバでPHP(Laravel、Zend、独自フレームワークなど)+jQuery+CSSといった組み合わせの時代のものから、AWS+React+Vite+TypeScript+Material UIといったものまで幅広く(浅く...とも言いますが)経験してきました。ログ調査や障害対応などの運用保守もやってきました。 入社したきっかけ カイポケでデザイナーとして働いている、元同僚からのリファラルがきっかけとなります。エス・エム・エスという会社を最初から詳しく知っていたわけではないですが、カジュアル面談、面接と進んでいくうちに「ここで働きたい！」という気持ちが強くなりました。 社会 > 会社であること 入社前にお会いした方が口を揃えて「社会のために自分たち(会社)はなにをすべきか」と話されていたのは印象的でした。入社して3ヶ月が経過しましたが、実際に社内でも同じ会話が当たり前に行われていて、建前じゃなく本当に共通の価値として認識していると感じました。 一緒に働きたい方ばかりだった わたしの仕事の都合もあり、一年以上に渡って面談・面接をしていただきました。上記のお話や、プロダクトに真摯に向き合い課題解決をしようとされている方、長期に渡り調整・ケアいただいた採用担当の方。こんな方々がいる環境で働けたら最高だなと思いました。 自分のスキルで貢献できそう 上記に加え、これまで培ったスキルや経験で貢献できそうだ、というところも大きかったです。 カイゴジョブエージェント どう貢献できそうか、という流れから、担当しているカイゴジョブエージェントの開発環境についてお話します。 カイゴジョブエージェントとは 介護職向け人材紹介サービス「カイゴジョブエージェント」は、すごく簡単に説明すると、介護職で転職を考えてらっしゃるかたに情報を登録いただき、転職支援エージェントが面談などをとおして適切な職場を紹介し、新たな職場でスムースに働いていただくためのフォローまでするサービスです。 2024年の4月にサービスとしてもリニューアルし、上記にくわえ、求人情報を探すコンテンツが追加されました。 システム構成 図にあるとおり、Next.jsとLaravel+Bladeが混在する形で構成されています。振り分けはAWSのELBで行われています。 開発環境、デプロイフロー 箇条書きにしましたが、開発を進めるにあたって、現時点でも充分な環境が揃っていると個人的には考えています。 GitHub上でブランチを切って開発 デイリーミーティングで進捗確認 プルリクエスト(PR)でレビュー依頼 レビュアーがApporove ローカルPCでの環境構築はMakefileで管理 初期設定、コンテナの上げ下げ、テストデータのinsertなど PRに特定のタグをつけると、自動で確認環境が起動 タグを検知すると、GitHub上でワークフローが走り、当該PRを確認できる環境が起動します。社内であれば誰でも確認できるため、企画職もここからチェックが可能です。 開発環境、プロダクション環境も自動デプロイ 当然、同じワークフローでプロダクションへのデプロイも自動です。万一不具合があったときも、revertするだけで1つ前の状態に戻せます。 全体の流れを表現したものが以下の図です。 コンテンツの確認やリリース作業に手作業が入らないところが非常に大きいと感じています。エンジニアにとって一番ストレスがかかり精神を消耗するところをなくし、より事業に貢献する開発に専念できる環境だな、と思っています。 開発の進め方 企画職のメンバーがバックログに施策や課題をセットし、開発メンバーと優先度を決めていきます。 開発内では別のカンバンでタスクを管理し、各々がどのタスク・レビューを担当するかを決め進捗管理、疑問点や不明点は毎日の朝会で共有するといった形です。 課題 1つ目は上述したような、アーキテクチャの見直しや改善が必要なシステム面です。 混在したフロントエンドをNext.jsに集約している途中であることや、A/Bテストをする度にあるディレクトリのファイルが横に増えていく構造が保守やレビュー効率を下げているところ、アーキテクチャ以外だとテストコードのカバレッジがまだ低いなどが挙げられます。 2つ目は、どういった意図や目的をもってこのタスク・案件が切られているのかといった事業目線と、システムがどういう作りになっていて、こういう目的ならこうしたほうが想定効果は8割になるが圧倒的にスピード感を持って開発できる、といった目線がまだ企画職含めたプロダクトに関わる全員で共有・理解しきれていないところです。 よくある話といえばそうなってしまいますが、決してネガティブということではなく、現状でもこれだけできているんだから、理解が深まればさらにいいものが速くできる環境になっていくんだろうな、という期待のほうが大きいです。 3つ目は、こういった話ができる人材が不足していることです(笑)少しでも興味を持った方は エンジニア採用情報 をご一読の上、ぜひご応募を！(PR) まとめ 「人口減少」「少子高齢」といったキーワードは、日本に在住する人間にとって他人事ではありません。大小あれど、これまで経験してこなかった社会課題に誰もが直面していくはずです。 そんな課題に対して「技術」「情報」を武器に解決していける環境・仲間がいる会社である、と入社してとても感じました。やりがいをもって日々業務に携われているなという感覚が非常に大きいです。 最後まで読んでいただき、ありがとうございました！

こんにちは、エス・エム・エス テックブログ運営の大縄です。 今回は、同時期に SRE としてエス・エム・エスに入社した加我さん、山口さんによる、コミュニティ活動に関する対談記事をお届けします。 自己紹介 —— 本日はよろしくお願いします。まずは自己紹介をお願いします。 加我さん： 私は 2024 年 4 月にエス・エム・エスに中途で入社しました。新卒では Java プログラマーとして中小の SIer に入社したんですが、色々と社内での調整があり、 QA エンジニアとしてキャリアをスタートしました。その中で、サーバーのミドルウェアの検証や評価計画を行う過程で OS のインストールやハードウェアの構成変更を経験しました。QA 業務自体は楽しかったのですが、でもやっぱりプログラミングをしたいという気持ちがあったので、PHP のバックエンドエンジニアとして 2 年間ほど活動しました。当時サーバー障害でレンタルサーバーのデータが消えるという問題が発生し、それをきっかけにインフラに興味を持つ様になりました。その後、インフラエンジニアに転身し、現在は SRE として働いています。元々はユーザーとの距離が近い toC のエンタメ事業が好きだったのですが、技術コミュニティ繋がりで弊社の空中さんと話す機会があり、エス・エム・エスの事業内容や技術的な課題、社会課題の解決というスケールの大きな話を聞いて興味が湧き入社を決めました。 山口さん： 私は加我さんの 1 ヶ月後にエス・エム・エスに中途で入社しました。最初は通信系の会社で公衆回線系の仕事をしていたのですが、もっと IT エンジニア的な仕事をやりたいと思って転職しました。ただ、転職後もサーバーやネットワークの構築の仕事が多く、再度プログラマーになるべく転職して生産管理系のシステムを担当することになりました。そこで Java や Oracle Database に触れるうちにデータベースに興味を持ち、DB チューニングをするようになりました。それがインフラへの関心へと繋がっていきました。その後フリーランスに転向し、インフラエンジニアとしての仕事に振り切りました。現在はエス・エム・エスで SRE として働いています。 —— 共に SRE として働かれているということですが、現在の業務内容を教えていただけますか？ 加我さん： 私はカイポケリニューアルの SRE を担当しています。まだリリース前なので SRE 的な活動はそこまでできていないのですが、トラフィックが増えたり障害が発生したときにどうするかなど、正式リリースに向けて土台を固めている最中です。現在は主にモニタリング周りの運用設計を進めています。チームごとにオブザーバビリティのレベル感が違うので、各チームにヒアリングを行いながら全体の運用レベルを合わせていくような活動をしています。今後は SLI、SLO についても考えていく予定です。 山口さん： 私は全社 SRE として活動しており、専任の SRE がいないプロダクトを横断的にサポートしています。今は Reliability に関わる業務よりオペレーションやインフラ面での業務が多く、全社統制の役割もあるので、インフラエンジニアや CCoE が近いかもしれません。最近はセキュリティに力を入れてるのですが、全体的な業務量が多いということもあり、トイルの削減にも力をいれてます。 コミュニティ運営のキッカケ・活動内容 —— お二人はコミュティ運営にも積極的に関わられていますが、どのような経緯で始められたのですか？ 加我さん： 2014 年頃、AWS を使ったサービスの構築・運用をしていたのですが、当時は AWS を学ぶ環境があまりなく、どうしようか悩んでいたところ、目黒で受けた AWS のハンズオンでJAWS DAYS というイベントを知り、そこからコミュニティというものを知り参加するようになりました。当初はコミュニティの参加者として活動していましたが、2015 年頃からPHP カンファレンス、PHPerKaigi、iOSDC などのイベント撮影スタッフを経て、2022 年に Media-JAWS というメディア系の AWS 活用事例や知見を共有するユーザーグループの運営メンバーに誘われ、運営に関わるようになりました。 山口さん： 私は 5 年前（2019 年）くらいから AWS に関わり始め、Control Tower や Security Hub などの全社統制の仕事をしていたときに参加した Security-JAWS の勉強会で、AWS のサポートの方の発表を聞いたのがキッカケです。そこで自分からも何か発表できることがあると伝えたところ、発表の機会をもらえることになりました。2022 年末ごろに JAWS-UG 千葉支部を紹介され、そこから本格的にコミュニティに関わるようになり、2024 年からは SRE NEXT のコアスタッフとして運営に関わっています。なのでコミュニティの運営歴という意味では加我さんと同じくらいですね。 —— コミュニティ運営では実際にどのような活動をするのでしょうか？ 加我さん： コミュニティのイベントは大きく分けて 2 つあって、「勉強会」と「カンファレンス」があります。勉強会はよく connpass などのイベントサイトに立ち上がるようなやつで、数週間〜数ヶ月に 1 回程度開催されています。テーマはその時々で、登壇者は身近な人から探したり、広く募ったりもします。私が運営に携わっている Media-JAWS だと関東近郊だけでなく、大阪、岩手、名古屋などでの開催もあるので、各地方で会場を貸してくれる方や現地で旗振りしてくれる方を探したりすることも重要だったりします。一方カンファレンスは基本的に年に 1 回開催される大きなイベントです。勉強会との違いは、規模はもちろんのこと、企業から協賛を募ったり、登壇希望者から提出されたプロポーザルを運営メンバーが確認し審査する、といった違いもあります。 山口さん： JAWS-UG 千葉支部もやることはほとんど同じです。JAWS-UG は年に 1 回以上のイベント開催が支部としての必要な条件になっているのですが、それだけだと支部としての活気がないので年に数回開催しています。千葉支部は支部の都市以外の方々にも届けたいという思いがあり、東京開催が多いです。カンファレンス運営は規模も関わる人も多いので、半年くらいのプロジェクトのようなイメージで準備を進めています。チーム分けして、ガントチャート引いて、定例会を開催して、みたいな感じです。 コミュニティ活動も業務の一環 —— 色々とやることがあるんですね！仕事との両立は大変ではないですか？ 山口さん： 主にカンファレンスについてですが、準備は業務後や土日に活動することがメインで、他の運営メンバー含めコミュニケーションもそのあたりの時間帯が活発です。なので、業務が忙しい時期に波があると準備に時間が割けなくなってしまうので辛い面はあります。自分がボールを持った状態で業務負荷が上がってしまうと他の運営メンバーの準備作業にも影響しまうので、作業を誰かにお願いするなど、ある意味マネージメント力も必要になってきますし、なるべく個人に依存する準備作業を作らない、業務の波を作らない、といったことも重要です。ただ、一番大変なのは自分が登壇する場合の登壇資料を作成することですね。 加我さん： 登壇資料作り、大変ですよね。私もそこそこ登壇の機会をいただいており、Interop Tokyo で Medis-JAWS の話をしたり、最近では山口さんも登壇された JAWS PANKRATION 2024 にも登壇しました。JAWS PANKRATION 2024では英語での資料作成が必要ということもあり結構大変でして、業務的にも期限が迫ったタスクがあったので業務時間を資料作成に充てられず、業務後に夜中まで資料を作成していたりもしました。ただ、本来は資料作成も業務の一環と捉えるべきという話は EM ともしていて、今後はあらかじめ計画に組み込むなど業務と登壇資料作成のバランスをとっていくのが健全だと考えています。 山口さん： コミュニティの運営活動を業務の一環として捉えてもらえるのは嬉しいことですよね。登壇資料作成もそうですが、制作物（パンフレット、ノベルティ、スタンプラリーの景品、アンケートパネル、バナーなど）の作成のように時間がかかる作業について業務時間を使えるので助かります。プライベート時間を全部使う必要がない、ということがコミュニティの運営活動の継続につながっていますよね。 加我さん： そうですね、あとはカンファレンス当日の運営を業務として扱えることも嬉しいですね。カンファレンスは土日祝開催が多かったり、前夜祭、Day1、Day2 みたいな感じで複数日開催する場合もあって体力的な厳しさがあるので、翌日に代休が取れて助かっています。 —— 業務の一環としてコミュニティやカンファレンスに関する活動を行いたいと思ったときにどのようなコミュニケーションをとっていますか？ 加我さん： 私は EM にイベントの運営や登壇について業務・出張扱いで良いかを確認しながら進めています。例えば登壇であれば、こういうイベントがあって、こういう内容で登壇するとこういう方々にリーチできると思うので業務として参加したいです、といった感じです。 山口さん： こういうイベントがあるから業務として参加してきて良いですか？くらいフランクなコミュニケーションをとるケースもありますよね。 加我さん： はい、ただ私の場合は札幌からの参加になるので、飛行機や宿泊の費用が多くかかってくることから、ある程度の参加意義を伝えることが必要だと考えています。フランクに確認しても問題ないとは思うのですが、Slack などオープンなところでこういったコミュニケーションをとることで今後参加したい方の参考になればと思っています。 山口さん： そうですね、現状は勉強会やカンファレンスに飛行機に乗ってでも参加したいという人がそこまで多くないのである程度融通がききやすい面はあると思うのですが、今後増えてきたときにコミュニケーションの内容が残っていることは重要だと思います。 協賛の提案にも積極的に支援 —— オープンな場でのコミュニケーションというと、山口さんがカンファレンスへの協賛に関するコミュニケーションを取られているのを見かけたのですが、そのときのお話を聞かせていただけますか？ 山口さん： はい。JAWS Festa 2024 in 広島に参加するときに協賛してはどうかという提案をしました。Kotlin Fest、RubyKaigi、SRE NEXT など、組織として例年協賛してきているイベントだけでなく、社員それぞれが意思を持って協賛したいといったものについても会社としては積極的に応援していて、費用面の支援を含めた社内稟議のプロセスも整備されています。 加我さん： イベントへの協賛については採用広報の観点もあるとは思いますが、私達は「その技術やコミュニティへのリスペクト」が前提としてあります。このような考え方や背景があるので会社として勉強会やカンファレンス参加など、業務につながるような学習に対して投資は惜しまないのだと理解しています。 コミュニティ活動が業務に活きる —— コミュニティやカンファレンスに関する活動がどのような面で業務に活きていますか？ 加我さん： コミュニティには様々な人がいるので、バックグラウンドが異なる人たちとコンテキストを合わせながらコミュニケーションをとっていくスキルを向上させられたと思います。特に SRE は社内に関わる人が多く、その時々で相手の目線に合わせた表現をしながら物事を進めていく必要があるので、コミュニティ活動の経験が役立っています。 山口さん： コミュニティ活動でいろんな人とコミュニケーションをとることで、人の輪が広がり、輪の中の方々の情報発信を拾いやすくなるといった側面もあると思います。そこで得た情報は、今の自分にとってすぐには役立たないけどちょっと先に役立つかもしれないといったものがたくさんあり、業務中にポンとやってきたボールを返すときに、そういえばこういう情報があったなぁという記憶があると調査しやすく、非常に役立っています。カンファレンス開催に着目していうと、プロジェクトみたいな感じで準備が進んでいくので、ファシリテーション、チームマネジメント、プロジェクトマネジメントなどの業務でも使うスキルが必要です。さらに、イベントを運営していく中でもそれらのスキル自体が磨かれていくので、うまくフィードバックループが回っているような感じがします。 加我さん： カンファレンスなどで登壇することも業務に活きている実感があります。登壇資料に記載する内容については、ざっくりとした理解ではなくしっかり定義を調べることが必要なので、資料を作る中で、意味を調べて、理解して、整理して、まとめる、ということがスキルアップにも繋がりますし、業務にも役立っています。 今後やっていきたいこと —— 最後に、お二人が今後やっていきたいことを教えてください。 加我さん： 会社として社外への発信や協賛を応援している状況なので、私自身が登壇することは続けていきたいですし、他の人やアウトプットが苦手な人にも発信してもらうにはどうすれば良いかなども考えていきたいと思っています。ですので、社外発信やコミュニティ支援について興味のある人が入社してくれたら嬉しいなぁと思っています。 山口さん： 改善してきたこと、逆にできなかったこと、苦労したことなど、一般解というよりも実業務でやってきたことを発信していきたいです。それが事業会社にいる強みだとも思っています。また、社外に発信したいといった人が増えた時に JAWS-UG のコミュニティの場を提供できるなど、何かあれば場を用意できるという状態を保っていきたいと思っています。 まとめ 今回はコミュニティ活動の話を中心に対談形式でお届けしました。対談内で出てきましたが、エス・エム・エスはコミュニティ活動、勉強会・カンファレンスへの参加や協賛を積極的に支援しています。その根底にある考え方について『 なぜ学習することへ投資するのか 』にも詳しく書かれていますので、こちらも是非ご覧いただければと思います！