この記事は株式会社エス・エム・エス 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 のコミュニティの場を提供できるなど、何かあれば場を用意できるという状態を保っていきたいと思っています。 まとめ 今回はコミュニティ活動の話を中心に対談形式でお届けしました。対談内で出てきましたが、エス・エム・エスはコミュニティ活動、勉強会・カンファレンスへの参加や協賛を積極的に支援しています。その根底にある考え方について『 なぜ学習することへ投資するのか 』にも詳しく書かれていますので、こちらも是非ご覧いただければと思います！

10月29日（火）～31日（木）に北海道札幌市で開催される「第83回 日本公衆衛生学会総会」にて、筑波大学と弊社Analytics & Innovation推進部が共同で行っている研究の成果が発表されます。 学会の概要 日本公衆衛生学会は1947年（昭和22年）に設立された、公衆衛生分野での主要学会の1つです。会員数は9,000人を超え、社会医学分野でも最大規模となっています。 会員は行政､ 大学等の研究・教育機関、保健・医療・介護・福祉や職域の現場実践者、企業など多岐にわたり、毎年開催される学術大会（総会）には4,000人ほどが集まります。 大会名：第83回 日本公衆衛生学会総会 会期：2024年10月29日(火)～31日(木) 会場：札幌コンベンションセンター、札幌市産業振興センター 大会の公式サイト： https://plaza.umin.ac.jp/jsph83/index.html 発表の概要 筑波大学との共同研究では、弊社が提供する介護/障害福祉事業者向け経営支援サービス「カイポケ」の匿名化データをもとに、医療と介護を取り巻く現状と課題を複数のテーマで分析しています。 今回の総会では、以下3つの演題が発表されます。 【発表1】 演題名 訪問看護事業所の保険収入における利用者の性・年齢・要介護度の割合による差 発表者名 伊藤智子1) 2)、長谷川正彦3)、富田眞紀子3)、小林秀3)、田宮菜奈子1) 2) 発表形式 ポスター発表 日時 10月30日（水）13:40～17:00 会場 札幌市産業振興センター 体育実習室（位置番号 089） 1)筑波大学医学医療系 2)筑波大学ヘルスサ–ビス開発研究センター 3)株式会社エス・エム・エスAnalytics & Innovation推進部 【発表2】 演題名 要介護高齢者に対する訪問リハビリテーションの実施時間と日常生活活動の関連 発表者名 樽見隼人1)、宇田和晃2) 3)、小宮山潤2) 3)、長谷川正彦4)、富田眞紀子4)、
小林秀4)、田宮菜奈子2) 3) 発表形式 一般演題口演 日時 10月30日（水） 14:50～15:50 会場 札幌市産業振興センター セミナールームB（第23分科会1） 1)筑波大学大学院 2)筑波大学医学医療系ヘルスサービスリサーチ分野 3)筑波大学ヘルスサービス開発研究センター 4)株式会社エス・エム・エスAnalytics & Innovation推進部 【発表3】 演題名 精神科訪問看護を利用する高齢者の3年間の要介護度推移に関連する要因の分析 発表者名 青柳沙佳1)、伊藤智子2)、長谷川正彦4)、富田眞紀子4)、小林秀4)、 
山海知子2)、田宮菜奈子2) 3) 発表形式 ポスター発表 日時 10月30日（水） 13:40～17:00 会場 札幌市産業振興センター 体育実習室（位置番号 196） 1)筑波大学大学院看護科学学位プログラム 2)筑波大学医学医療系 3)筑波大学ヘルスサービス開発研究センター 4)株式会社エス・エム・エスAnalytics & Innovation推進部

はじめに こんにちは、エス・エム・エスの小笠原です。以前 2つのカイポケSREチームを兼務している話 を紹介しましたが、現在はカイポケリニューアル側のSREを担当しています。 今回は介護/障害福祉事業者向け経営支援サービス「カイポケ」の開発におけるSREの活動事例として、基盤の構成管理を抜本的に見直した話を紹介します。 リニューアルプロジェクトの概要 最初に私が関わっている カイポケリニューアルプロジェクト について簡単に紹介します。 このプロジェクトは継続的な事業成長を目的としてサービスの安定性やプロダクトの優位性を高めることを目的とした「新カイポケ」の開発プロジェクトで、2021年に始動しました。 アーキテクチャから見直し、「拡張性」・「スケーラビリティ」・「開発並列性」をキーワードにした「新アーキテクチャ」を設計し、開発を進めています。 私もこのプロジェクトに2022年の年末ごろからSREとして開発に携わってきました。 プロジェクト開始時の基盤開発の方針 最初にプロジェクト開始時の基盤開発の方針について説明します。プロジェクト開始当初、開発メンバーの中でインフラを専門として動くメンバーは1人だけでありかつ、他部署の業務を一部兼任している都合もあり、SREとして一般的に期待される仕事をすべて担うにはリソース不足でした。 一方、アプリケーション開発を主に行うチーム（以降、アプリ開発チーム）には元インフラチームのメンバーや基盤開発に知見のあるエンジニアが複数人いたこともあり、基盤の開発・管理をアプリ開発チームとSREの間で以下のように担当分けする方針が敷かれました。 プロジェクト開始時点の管理範囲 土台となるAWSアカウントを始め、全体のネットワーク設計（VPCやsubnetなど）や横断で利用されるリソースをSREが管理し、それ以外のリソースはすべてアプリ開発チームで面倒を見るという役割分担です。 この役割分担を前提として、技術スタックについて開発チームの管理範囲は AWS CDK （以降、CDK）を、SREチームの管理範囲はTerraformを採用することになりました。 技術選定の背景 アプリ開発チームでCDKを採用したのには大きく３つ理由があります。１つ目はアプリ開発チームで基盤開発を主導していたメンバーがCDKに習熟していたこと。２つ目は使い慣れているプログラミング言語であるTypeScriptで開発できること。３つ目はSecurityGroupの設定など基盤の詳細について抽象化されていて基盤に詳しくないエンジニアにとって扱いやすいことです。これらは開発速度を上げるうえで大きな優位性になると考えていました。 一方、SREチームでTerraformを採用した理由は運用時の細かな取り回しの良さと規模の拡張に対応しやすいと判断したためです。特にSREが担当するレイヤ（AWSアカウントやネットワーク基盤など）の運用ではこの性質と相性が良いと考えました。 AWS CDKとTerraformの連携と拡張方針について CDKとTerraformは以下のようにParameter Storeを介してそれぞれの世界を接続させる形で連携することにしました。 CDKとTerraformの連携 リソース間に依存関係があるため、以下の順番で構築を進めることになりました。 SREがTerraformでネットワークリソースを作成する CDKで参照したい定数をTerraformを使ってParameter Storeに作成する 開発チームで定数を参照してサービスごとのAWSリソースをCDKで作成する 両者の責任分界点は明確なため、あとは各チームがそれぞれの担当するCDKのstackやTerraformのroot moduleを適切な粒度に分割・管理していけば将来的なシステムのスケールに対応できると考えていました。 開発初期は見立て通りうまく開発できた 開発初期からしばらくの間は基盤開発の状況は良かったことを覚えています。特にアプリ開発チームにおけるCDKを利用した基盤開発は以下の点でよく機能していました。 開発者が抵抗なく基盤開発に貢献できる TypeScriptで書かれた豊富な実装例 コードの書き味の良さ 試行錯誤のしやすさ cdk deploy → cdk destroy で片付けが簡単 個別のAWSリソースの詳細について深く考えなくて済む 詳細が抽象化された構成セット（ construct ）が公式から多数提供されており、それを少し修正するだけで基盤構築ができる アプリ開発者だけで開発を進められる レビューをすべてアプリ開発チーム内で済ませられる 当時は基盤の構成や設定をレビューできるメンバーが限られており、レビュー待ちが発生することが多かったのですが、アプリ開発チーム内でレビューを完結させることでスムーズに開発を進められることが大きなメリットと認識されていました この点についてはアプリ開発チームでは当初期待していたCDKのメリットを享受できていたと言えそうです。SREとしてもアプリ開発チームが自立して基盤の構築・管理のタスクを進めてくれるため負担が少なく助かっていました。 開発中盤からCDK開発に暗雲が立ち込めた 一方で、開発が中盤に差し掛かる段階でCDK開発に暗雲が立ち込めます。具体的には本番環境を作り始める頃に様々な課題が見えてきました。特に大きかったものは以下です。 デプロイが一大イベントになった 一回のcdk deployにすべての変更を押し込めた結果、アプリのデプロイと構成変更が同時に実行されるデプロイフローになってしまいました アプリの変更と構成変更が同時に行われることでデプロイ時の事故が起きやすくなったりstack更新のオーバーヘッドでデプロイ時間が全体的に長くなりました CDKで状態を持つリソースの管理がうまくできなかった 状態を持つリソースに関してstackの更新処理が途中でコケた際にエラー原因が特定できず、困ったらcdk destroyして作り直すという対処をしていました これは本番系では許容できない解決方法ですが、CloudFormationのトラブルシューティングが難しく、一つ一つ適切に対処することができませんでした CDKで作られるAWSリソースの品質が本番に持って行くには不安があった 例えばSecurityGroupの作り方に不備があり、意図した通りのアクセス制限が行えてないといった不備が見つかることがありました PRのレビューでは正常系の確認が主で、作成される実リソースの詳細に関するレビューはおざなりになっていました 多くの課題はCDK開発の知見を深める施策（技術的な投資）を増やせば解決できる可能性はあったものの、プロジェクトのボトルネックがアプリケーションの機能開発にあったこともあり、なかなかそちらにリソースを振ることも難しい状況が続いていました。 また、この問題に拍車を掛ける形で、アプリ開発チームでの基盤開発を主導していたメンバーの離脱があり、CDKの技術課題解決の推進力が大きく損なわれる事態になりました。 長期のプロジェクトなのでメンバーの入れ替わりがあることは仕方のないことなのですが、抜けた穴を補填できない状況ができたことは特に大きな問題でした。 基盤の開発・管理の立て直しを行うことになった 多くの課題が認識されるなかで基盤の開発・管理に関して抜本的な改善を図ることにしました。 愚直なアプローチとしては基盤開発の責務を現状維持しつつ、SREチームがCDK開発の課題解決に助力するという方法が考えられました。当時のSREチームは私が参加して二人になっていたこともあり、その選択肢もあり得たと思います。 しかし、SREチームには（開発の中で知見はある程度溜まっていたものの）本番系でのCDKの運用知見が少なく、またCDKのバックエンドであるCloudFormationをうまく扱っていくには相応の学習コストが必要なことが見えていました。 そして、今後基盤開発の課題の多くをSREチームが担っていくことを考えると、CDKとTerraformの２つの技術スタックを無理に維持していくよりは、SREが運用知見を多く持ち合わせていて既に基盤も整っているTerraformに統一していく方が効率的で、かつ将来のスケールにも対応しやすくなると考えました。 そこで、基本的に基盤の運用管理の責務をSREチームに全面的に移譲して、かつ技術スタックも統一していく方針で立て直すことが決まりました。 基盤の開発・管理の責務を全面的にSREに移した 役割としては以下のように基盤管理のほとんどをSREが担う形に変更しました。構成管理ツールはTerraformを主体に据えました。 プロジェクト中期の管理範囲 ただし、アプリケーションのデプロイについては構成変更と分離するために ecspresso を利用し、一部のAWSリソースはアプリ開発チームが手を入れやすいようTerraformのroot moduleを分ける工夫を行いました。 当時、サービスリリース前ではあったものの、多くのAWSリソースがCDKで構築・管理されていたため、CDK stackを段階に分けて少しずつTerraform化する対応を行いました。 結果 ツールの移行は開発に支障が出ないように段階的に行ったこともあり、全体で数ヶ月かかってしまいました。 移行期間中は基盤リソースが一時的に多重化されてコストがかかったり、デプロイ時間が遅くなったり過渡期の問題はある程度発生しましたが、移行を終えることによりそれまで抱えてきたCDKの技術課題を一気に解消することができたのはプロジェクトにとって中長期的な目線で大きなメリットを与えることができたと考えています。 移行後、顕著に改善できた点は以下です。 デプロイを高速化できた デプロイ時間を当初の約半分程度に削減できました デプロイ時の事故が減った 構成変更とアプリのデプロイを分離することで事故が少なくなりました 基盤構成のガバナンスを高めることができた Terraform管理時のプラクティスをそのまま横展開することでガバナンスを強化できました 大きな変更を入れる際にSRE（有識者）のレビューを入れることで品質の底上げがなされるようになりました 基盤に手を加えるオペレーションがしやすくなった CDK（開発チーム管理のリソース）への影響を考えながらオペレーションを組む必要がなくなり、Terraformで構成管理する際のオペレーションを考えるだけでよくなりました SREの動きやすさが大きく改善したことに加えて、デプロイの苦痛を減らすことができたことはプロダクト開発にとって地味ですが効果の大きな施策だったのではないかと考えています。 まとめと振り返り 大規模プロジェクトにおいてアプリ開発チームに基盤開発を任せる開発スタイルを試してみましたが、開発中盤でアプリ開発チーム単体での対応が難しい技術課題が増えたためSREに管理を任せる形に切り替えました。 この事例から得られる学びとしては、開発人員が多く期間の長いプロジェクトでは技術選定が当時の見立て通りにうまく進むとは限らないということです。 「最初からTerraformですべて管理していればよかったのではないか」という意見もあり、個人的にそれも一理あるなとは思います。しかし一方で、開発側にCDKの技術課題に取り組める人員を増やしたり、アプリ開発チームの中でCDK開発に関する知見を増やす取り組みに投資できていれば状況が大きく変わっていた可能性もありましたし、プロジェクト開始当初は基盤構成についてどのような形が良いかを開発チーム主体で機動的に模索したいという要望もあったりするなかで、Terraformからはじめる意思決定を最初から選択することは合理的ではなく難しかったと思います。 開発が進み、徐々に体制の変化や開発のボトルネックなどがわかってくる中で初めてこれまでの技術選定について振り返りや比較検討ができ、今後どうしていくのが良いかという確度の高い議論や意思決定ができたと考えています。 今回の事例を通して、先が読みにくい不確実性の高いプロジェクトでは完璧な技術選定よりは技術の評価や振り返りをしっかり行って、開発状況に応じて柔軟に技術の切り替えをすることが大切ではないかと感じました。 補足: CDKに関する技術的な所見 CDKに関して今回の事例を通して気付いた技術的な所見としては、小規模でシンプルな構成の基盤開発にCDKはよく向いているということです。 立ち上げまでの初速が非常に早く、スクラップ＆ビルドしたいときにはうってつけだと感じました。TypeScriptの型情報にAWSのベストプラクティスが書かれていたり、強力な型補完の恩恵があるため非常に楽しく基盤開発に取り組めることができました。これはTerraformにはない開発体験でした。 一方で、規模が大きく複雑な要件の求められる基盤開発で使っていくには相応の技術的投資が求められるため、構成変更を頻繁にいれたくなるようなメインのサービス・システムの管理には入れたくないと感じました。 特にCDKで細かくスタック分割したくなるときに運用・メンテコストが跳ね上がるように見受けられました。スタック分割をうまく行うにはL1 constructをはじめとしてCDKやCloudFormationの独特の設計や扱い方に習熟する必要があるのですが、これが非常に厄介なためです。 もちろん、ツールに深く習熟してさえいればどちらを使っても構わないのでしょうが、そうではない開発メンバーが多いプロジェクトの場合はツールの特性を理解して導入していくことが大切だと思いました。

介護・障害福祉事業者向け経営支援サービス「カイポケ」の開発をしているエンジニアの神谷です。中途入社してから5年たった今、これまでの活動を振り返ってみようと思います。 入社以来、顧客への価値提供を素早くできるようにするため、開発環境のモダン化や技術的負債の解消にトライし続けてきました。 最初は小さなサブシステムのリプレースにチャレンジし、リプレースの大まかな流れやカイポケで抱えていた技術的負債の解消パターンなどを獲得していきました。 tech.bm-sms.co.jp 直近ではカイポケ障害児支援領域の大規模リプレースに関わってきました。今回この大規模リプレースでチャレンジしたことについて、技術的な面にフォーカスして振り返ってみます。 カイポケ障害児支援領域の大規模リプレースに関してはこちらもご覧ください。 tech.bm-sms.co.jp tech.bm-sms.co.jp カイポケ障害児支援領域リプレースで意識したこと 今回の大規模リプレースを通して、業務知識のキャッチアップが最初の課題となりました。幸い、私がチームにJoinしたタイミングで、チームではドメインモデリングが進んでおり、ソースコードにまで落とされたドメインモデルを通して、業務知識の全体像を把握していくことができました。 また、実際に障害児通所支援事業所を訪問させていただき、カイポケを利用されている現場での課題を伺ったり、法改正に向けて現場の声を聞いたりすることで、理解度を高めていくこともトライしていました。 その他に、特に意識していたのは、以前のリプレースを通して得た知識をもとに テスト、運用フェーズを意識した設計をする レイヤーを跨いで、自動テスト可能な状態を維持し続ける ミドルウェアのアップデートを継続的に実施可能な体制を作る ことでした。次に具体的な例を挙げます。 テスト・運用フェーズを意識した設計 法制度が関係するカイポケのシステムテストを行う際には、法が施行される4月1日からは新しい法制度に対応しているが、3月31日以前は法改正前の振る舞いであること、といったシナリオのテストをすることがあります。 以前の法改正ではシステムや言語処理系の現在時刻を調整することで対応していましたが、これらは予期しない副作用を引き起こしたり、そもそもコンテナランタイムの上では使えない方法などもあり、避けるべきだという議論がチームでされていました。 そこで、リプレースにおいては現在時刻を扱う箇所は、現在時刻を外部からインジェクション可能な設計としています。 また、コンテナの環境変数から現在時刻を変更可能とし、テストチームから「法改正後の環境をテストしたい。法改正後の請求を行う5月の状態をテストしたい。」と要望があった場合でも、再デプロイのみですぐにテスト環境が用意できるようになっています。これは令和6年4月および6月の法改正対応で絶大な威力を発揮しました。 レイヤーを跨いで、自動テスト可能な状態を維持し続ける ソフトウェアのレイヤーを跨いでの結合テストを充実させるため、自動テストでは動かしにくいコードをリファクタリングしていきました。 実際のデータベースやクラウドストレージにアクセスするレイヤーもコンテナを活用することで「テストダブルで理想的にセットアップされている環境では動くが、リアルな環境では動かない」といった手戻りが極力起こらないようにしています。 具体的には TestContainers を活用することでデータアクセスレイヤを含む自動テストを拡充していきました。 テスト前にコンテナをたて、テストケースごとにコンテナを破棄することで毎回クリーンな状況からテストを開始し、不安定なテストとなることを避けています。 もっとも全てのテストを実際のストレージに接続して実施していてはテスト実行に時間がかかりすぎてしまうため、代表的なケース以外はテストダブルを使用するなどバランスを考慮しています。 ミドルウェアのアップデートを継続的に実施できるようにしておく カイポケの共通機能は社内でメンテナンスされているSpring Bootをベースとした薄いフレームワークに寄せられています。 リプレースにおいてもこのフレームワークを利用しているのですが、フレームワークをメンテナンスできる人が少なくなってきてしまっていたため、ソースコードのリーディング会や社内LT会でフレームワークの紹介、ドキュメントの整備などを行い、メンテナンスがされている状態へのリカバリーを行いました。 また、一度実験的に実装をしたものの、後に不要となった機能を断捨離することで、認知的負荷を減らし、メンテナンスが継続的に行えることを優先しました。 さらに、フレームワークの自動テストカバレッジを維持し、ミドルウェアのアップデート時に自信を持ってアップデートできるようにしています。 フレームワークはSpring Boot 2時代に社内で初回リリースされたものですが、大きな破壊的変更が入ったSpring Boot 3への対応を終え、現在3.X系の最新バージョンまで対応できています。 取り組みの結果と今後の展望 最初に取り組んだリプレースと比べ、今回は規模やステークホルダーも多く難易度は相対的に高かったものの、学習したことを生かし、もう1段階大きなリプレースを乗り越えることができました。 一方、今後トライしていきたいこともまだたくさんあります。 今回のリプレースのファーストリリースでは、フロントエンドからバックエンドまでを通したE2Eの自動テストや、フロントエンドの複数コンポーネントを跨いだ自動テストなどはスコープ調整や技術的背景から見送りました。 今後これらの自動テストを充実させ、開発速度と品質の両立を目指して探求していきたいと思っています。

お疲れ様です、SREの西田 ( @k_bigwheel ) です。 最近、バッチ処理を実行するための新しい基盤を構築したので、この記事ではそれの紹介をしたいと思います。 少々前提の説明を丁寧にやりすぎてしまったので、作ったものをまず見たいという方は「 構築したバッチ実行基盤のアーキテクチャ図と概要 」の項目へジャンプしてください。 バッチ実行基盤とは バッチジョブ、バッチ処理のための仕組みは、多くのWebサービスで設けられていると思います。 とてもプリミティブなものであれば、Webアプリが動いているEC2インスタンス/コンテナにログインして rake task ... などを実行するパターンが典型でしょう。 もう少し複雑になってくるとAWS CodeBuildとEventBridgeを組み合わせてサーバレスに定期実行したり、更に複雑な例ではApache AirflowやArgo Workflowで依存関係や実行順序・再実行の制御などを行う場合があります。 これらのうちどれを使うべきかはそのサービスのバッチ処理に求められる要求によります。基本的に高機能なものほど環境の維持や学習にコストがかかります。 GitHub Actions GitHub ActionsはGitHub公式のCIサービスです。GitHubリポジトリとの親和性が高く、今日では多くのエンジニアが使っているCIサービスです。 私は直近5年間このGitHub Actionsを非常に重用しており、正式リリース後はCIサービスとして最初の選択肢として常に使ってきました。 *1 GitHub Actionsをバッチ実行基盤として使うときのイメージ GitHub Actionsをバッチ実行基盤に据える、という考え方はあんまり聞かない手法だと思いますが、私は直近2社のバッチ実行基盤はそのように構築してきました。 典型的な実行イメージは以下です: GitHub ActionsのSelf Hosted Runner機能を使用してVPC内に実行箇所を確保 バッチ処理をWebアプリケーションと同じバイナリで実装し、DockerイメージをECRへpush GitHub Actionsのジョブ内でECRからdockerイメージをpull docker container run に適切なパラメーターを与えてバッチ処理を起動 GitHub Actionsをバッチ実行基盤に採用したときのメリット 次の様なメリットがあります。 1. バッチ処理を書くために追加の学習がほぼいらない GitHub Actionsは前述の通りすでに多くのエンジニアが使い方を知っているため、追加の学習コストがいりません。 Apache Airflowなどのワークフローエンジンを使う場合はその概念だけでなく、Pythonでの書き方やDAGの概念など多くを学ぶ必要があります。 2. GitHub Actions用の各種ノウハウが活用できる GitHub Actionsはシンプルな使い方もできますが、 workflow_run や on などで依存関係を表現することにより、その実行順序の制御は柔軟にできます。 また、reusable workflowやcustom actions、公開されたOSSアクションの利用など、車輪の再発明を避けるための各種手法も使うことができます。 3. 実行結果の確認やエラー通知・モニタリングなどが楽 実行の成否やそのログもGitHub Actionsの画面を使うことができるため、エラーの原因調査やエラー時の通知・実行回数やログのトラッキングなどもすべてGitHub Actionsのプラクティスを適用できます。 Apache Airflowなどのバッチ実行基盤を使うと書くと、実行結果の把握も不慣れで経験が必要なため、そこをスキップできることもメリットです。 これらのメリット1,2,3は開発チームが自信を持って自分たちの力のみでバッチ処理を管理運用することを支援します。これは、 チームトポロジー やスクラムの言う、1チーム完結で仕事ができるという理想へ近づくことができます。 4. 運用コスト(TCO: Total Cost of Ownership)が低い GitHubとGitHub Actionsをすでに使用している組織では、GitHub Actionsをバッチ処理基盤に採用することで増えるインフラ・SaaSはありません。また、後ほど説明しますが最近発表された「Self-hosted GitHub Actions runners in AWS CodeBuild」という機能を使えばAWSサイドのリソースの構築運用やコンピューティングコストもかなり低く抑えられます。 インフラを構築運用するSREの目線からすると、扱うものの種類が増えると認知負荷が増え、結局TCOも増えるため、この点も大きいです。 GitHub Actionsをバッチ実行基盤に採用したときのデメリット 逆に明確なデメリットもいくつかあります。 1. GitHub Actionsのダウンに影響される GitHub Actionsは、結構不安定なサービスです。 直近3ヶ月 の障害記録を確認してみましたが、2回ほど障害が発生しています。ここに記録されない軽微なものを含めるともう少し発生している体感で、だいたい毎月なにか起こっています。 そのため、その時間に必ず一度だけ実行してほしいジョブや、再実行でリカバーできない(=冪等性のない)処理などには向いていません。ここは処理側でGitHub Actionsの性質を考慮して冪等性があるように書いたり、最悪遅延しても大丈夫な仕組みにしたりする必要があります。 2. 起動が少し遅い GitHub Actionsのワークフローの実行は、実際にステップ1が実行されるまで30秒 ~ 2分程度の遅延があります。これはDockerイメージのpullや実行環境の用意などに時間がかかっているようです(後述するSelf-hosted GitHub Actions runners in AWS CodeBuildを使うとCodeBuildが実行環境を準備する時間もかかるため、全体で2~4分程度最初のステップの実行までかかります)。 例えば踏み台サーバー経由でコマンドを実行する場合、長くても数秒で実行に移れるので、ここは明確なデメリットです。一方で、実際にバッチ処理が運用に入った場合、この立ち上がりの遅さが問題になることはほとんどないです。問題になるのは主に処理のデバッグ・開発中で、1度実行して結果を確認するのに時間がかかるため開発効率が落ちます。この点は、 Debugging with ssh · Actions · GitHub Marketplace などのアクションを活用することで軽減するなどの工夫が必要かもしれません。 3. VPCの壁がデフォルトでは超えられない GitHub Actionsのデフォルトの実行環境である GitHub Hosted Runner は、AWSの外にあるサービスです。 バッチジョブからプライベートサブネット内のDBやインターナルALBへアクセスさせたい場合、当然そのままではアクセスできません。 これを解決するには方法については続けて詳しく書きます。 VPCの壁を超えるための手法について AWSでバッチ処理を行う場合、多くの人が頭を悩ますのがDBへのアクセスです。 バッチ処理はその多くでDBへのアクセスを行うため、DBへのアクセス経路を確保する必要があります。一方でAWS環境のDBはプライベートサブネットに置くことが多く、GitHub Actionsのデフォルトの実行方法( GitHub Hosted Runner )を使う場合、実行箇所がAWS内ではないためDBへアクセスすることはできません。 この解決策は僕が知っている限り以下の種類があります。 1. DBをパブリックサブネットに配置し、DBのpublicly accessibleオプションを有効にする DBをパブリックサブネットに配置し、DBのpublicly accessibleオプションを有効にするとDBの各インスタンスへグローバルIPが割り当てられます。そうすればインターネットのどこからでもアクセス可能になるため、GitHub Hosted Runnerからもアクセスできる寸法です。 RDSのサブネット間の移動は手間はかかるものの可能であるため( rds プライベートサブネット パブリックサブネット 移動 - Google 検索 )、後からこうすることもできます。 この方法の欠点はセキュリティ観点で比較的弱いことです。GitHub Hosted Runnerは使用するIPを固定したり専有したりすることはできないため(※ はてなブックマークのコメントで、Larger Runnerを利用すればIP帯を限定できると教えていただきました。Enterprise Cloud契約が必要でコストも変わりますが、有力な選択肢になりえます)、セキュリティグループで接続元を制限することもできません。ですのでDBのセキュリティはネットワークトポロジーで担保することはできずDB自体の認証機構のみに頼ることになります。それもあってAWSの設計としては一般にはバッドプラクティスとして考えられているようです。 蛇足ですが、私はこの手法は場合によっては有用と考えており一概に切り捨てるべきではないと思っていたりします( bastionを廃してRDSのパブリックアクセス可能(publicly accessible)を有効にしてはどうか提言 - kbigwheelのプログラミング・ソフトウェア技術系ブログ )。 2. 踏み台サーバーの利用 パブリックサブネットに踏み台サーバーを置き、DBへのアクセスを中継させる手法です。 比較的取りやすい構成ではありますが、 先述のブログ にも書いている通り、実はこれはDBのpublicly accessibleを使うこととセキュリティ水準的にはそれほど変わりません。また、踏み台サーバー内にファイルが置かれてインフラが状態を持ってしまい、踏み台サーバーの置き換え・アップグレードができないなどの問題がよく発生します。なので、この方法はおすすめしません。これでよい要件であれば、先程のpublicly accessibleのほうがセキュリティ水準は同じで運用コストはより低くて済みます。 3. Self Hosted Runnerの利用 GitHubにはデフォルトの実行環境(GitHub Hosted Runner)の他に、自分たちで実行環境を用意する Self Hosted Runner という仕組みがあります。AWSのVPCの壁を突破する方法としてはこれを使うことが一般的です。 ただし、このSelf Hosted Runner、結構TCO(Total Cost of Ownership)が高いです。 素朴なEC2インスタンスとして立てた場合、中のOSレイヤー以上のメンテナンスを自分たちで行う必要があり、また実行中以外もインスタンスが起動しっぱなしであるためコンピューティングコストが高くつきます。 Fargate でサーバレスに実行時のみ起動するアイデアは数年前からありますが、先行例はたくさんあるもののOSSの形で公開された定評のあるソリューションはありません。 Kubernetes上で動かすソリューションはOSSかつ公式に認められたものとしてありますが( Actions Runner Controller )、Kubernetes自体の運用コストが低くない上、EKS上のFargateはECSのFargateよりかなり立ち上がり時間が遅い(2022年時点で4~7分程度かかった)などの欠点もあります。 そんな中で、2024年4月に満を持して出たのがSelf-hosted GitHub Actions runners in AWS CodeBuildでした。 Self-hosted GitHub Actions runners in AWS CodeBuildについて 2024年4月のリリースが以下です: AWS CodeBuild がマネージド型の GitHub Action ランナーのサポートを開始 平たく説明すると、Self Hosted Runnerの実行箇所としてCodeBuildを選べるようになったというものです。 これによりSelf Hosted RunnerとしてEC2インスタンスを使った場合のようにOSレイヤーを管理する手間や利用時以外のコンピューティングコストを払う必要もなく、ECS Fargateのパターンのように自分たちで構築・運用する必要もなく、Kubernetesを使う場合のようにKubernetes自体とControllerの高い管理コストを払う必要もなくなりました。 前職ではEKSを使ってインフラを構築していたことと、まだSelf-hosted GitHub Actions runners in AWS CodeBuildが登場していなかったこともあって前述のActions Runner Controllerを使っていたのですが、現職ではECSベースかつCodeBuildを使用していることも後押しして、こちらを採用することにしました。 構築したバッチ実行基盤のアーキテクチャ図と概要 アーキテクチャはざっくりですが以下です。 キーポイントとしては Self-hosted GitHub Actions runners in AWS CodeBuildを使うことでシームレスに実行箇所をVPC内へ移す AWS - GitHub OIDC を使うことでIAM権限の取得をノンパスで行う IAMデータベース認証を使うことでDBへの接続も同じくノンパスで行う などです。これらにより、バッチ処理を書く方としてはCodeBuildの存在を一切意識する必要なく、またIAMユーザーやDBのパスワードについても別途GitHub Secretsなどへ保存する必要がなくなります。 GitHub Actionsのワークフローファイルの例 name : workflow-a on : workflow_dispatch : {} jobs : job1 : environment : dev # configure-aws-credentials アクションのためにid-tokenとcontentsの権限は必須 permissions : id-token : write contents : read runs-on : codebuild-batch_jobs_dev-${{ github.run_id }}-${{ github.run_attempt }} steps : # GitHub AWS間のOIDCを使ってノンパスでIAM権限を取得する - name : configure aws credentials uses : aws-actions/configure-aws-credentials@v3 with : role-to-assume : arn:aws:iam::1234567890:role/batch-jobs - run : aws sts get-caller-identity # IAM権限を正常に取得できていることの確認 # 次の2ステップは、取得したIAM権限でECRからdockerイメージを取得できることの確認 - uses : aws-actions/amazon-ecr-login@v2 id : login-ecr - run : | docker pull ${{ steps.login-ecr.outputs.registry }}/github/bm-sms/project-a/project-a:sha-aaaaa1215bb084e9ad3d6abf30b91348043bbbbb # 最後にIAMデーベース認証の動作確認 # GitHub SecretsやParameter Storeにパスワードを保存することなく、IAM権限からFederatedな一時DBパスワードを取得し、それを持って接続する # 通常、Publicly AccessibleではないDBにはGitHub Actionsからはアクセスできないが、 # self-hosted GitHub Actions runners in AWS CodeBuild を使用しているため接続が可能になっている - run : sudo apt update && sudo apt install postgresql -y - run : | # https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.PostgreSQL.html export RDSHOST="db-cluster.cluster-aaaaylxtbbbb.ap-northeast-1.rds.amazonaws.com" export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region ap-northeast-1 --username batch_job)" psql "host=$RDSHOST port=5432 dbname=hogehoge user=batch_job password=$PGPASSWORD" -c "SELECT CURRENT_SCHEMA, CURRENT_SCHEMA()" セキュリティ・証跡関連で気をつけたこと 補足的ですが、セキュリティ関連で気をつけたことについていくつか書いておきます。 本番環境でのバッチ実行への制限 上記の仕組みを素朴に作ると、本番環境でのジョブ実行が危険なほど容易にできます。 具体的にはGitHub - AWS OIDC連携をしているリポジトリへWrite権限を持っているユーザーは任意の処理を書けます。個人情報へのアクセスもできてしまうでしょう。一方でジョブ実行に必ず人力のApproveを求めるのは現実的ではありません。それは、バッチ処理の中には一日1回など定期的に実行するものがあるからです。 そこで、その辺りを解決するために次のように設定しました(詳細は後ほど説明します): Environment リポジトリの設定から次の Environment を作成する prod-with-review prod-without-review dev-with-review dev-without-review prod-with-review prod-without-review についれそれぞれ画像のように設定する 　 GitHub - AWS OIDC AWS側のOIDC設定を次のように行い、AWSの本番環境アカウントは prod-with-review prod-without-review環境 、 開発環境アカウントは dev-with-review dev-without-review の環境の権限があるときのみ使えるようにする resource "aws_iam_role" "batch_job" { name = "batch_job" assume_role_policy = data.aws_iam_policy_document.batch_job.json } data "aws_iam_policy_document" "batch_job" { statement { actions = [ "sts:AssumeRoleWithWebIdentity" ] effect = "Allow" condition { test = "StringLike" values = [ "repo:bm-sms/repo-a:environment:$ { var.environment } -with-review" , "repo:bm-sms/repo-a:environment:$ { var.environment } -without-review" , ] variable = "token.actions.githubusercontent.com:sub" } principals { identifiers = [ data.aws_iam_openid_connect_provider.this.arn ] type = "Federated" } } } data "aws_iam_openid_connect_provider" "this" { url = "https://token.actions.githubusercontent.com" } 3.(ブランチプロテクション)ルールセット 画像のように設定することでレビューなしで main ブランチを変更できないようにする 全体の意図を説明します。 まず、本番環境での実行は原則承認のステップを挟みたいため、AWSの本番環境アカウントへの接続には prod-with-review Environmentを要求し、Deployment *2 にはレビューを要求しています。 一方で、定期実行など仕組み上レビューを挟めない実行方式もあります。その場合は prod-without-review Environmentを使用しますが、その際でも実行ブランチは main に限定されており、同時にブランチプロテクションルールセットで main ブランチの変更には常にレビューと承認を必要とするため、レビューなしに本番環境で任意の処理を行うことはできません。 (補足: dev環境などは毎回の承認は冗長なため with / without の両方のEnvironmentを用意する必要は原則ないですが、環境差異を小さくしたいためあえて本番環境と同様に作り dev-with-review でのReviewのチェックだけ外しています) 証跡としての実行ログについて Self-hosted GitHub Actions runners in AWS CodeBuildを使った場合、バッチ実行のログはCodeBuild側にはまったく残らず、GitHub Actions側に残ります。そして、GitHub Actionsの実行ログはリポジトリへのwrite権限という比較的弱い権限で削除できます。そのため、悪意のあるユーザーがあるジョブを実行してすぐにログを消すことができます。 これの対策として、エス・エム・エスでは Datadog CI VisibilityのLog Collection を使うことにしました。これであればログを削除することはできません。 ジョブ自体の実行の証跡について ジョブ自体の実行の証跡については、 GitHub OrganizationのAudit log 機能を使用しています。 IAMデータベース認証のなりすまし可能問題について IAMデータベース認証を素朴に使うと実行ログの証跡としての価値が非常に下がってしまう問題については次のように対処しました。 AWS Identity Center下のIAMデータベース認証でも、トレーサビリティのある監査ログを記録する方法 クエリログへのアクセスを制限したい クエリに個人情報が含まれている可能性があり、クエリログへアクセスできる人を制限したい件については次のように対処しました。 AWS Identity Center下で個人情報を含んだCloudWatch Logsへのアクセスをスマートに制限したい 終わりに 本記事ではここ数ヶ月作っていた、CodeBuildとGitHub Actionsを使ったバッチ実行基盤について紹介しました。 この方式はまだ主流ではなく、GitHub Actions自体の稼働率に引っ張られるなど明確な欠点もありながら、GitHub Actions自体の普及率が爆発的に増えたことにより、大きなメリットが出てきた手法かなと思います。 個人的には、TCOがかなり低いにもかかわらずバッチ処理を書く側・実行する側のDeveloper Experienceがかなり良いこと、この記事に書いたような概要の説明とアーキテクチャ図があればSRE(構築側)への問い合わせをあまりしなくてもバッチを書ける (= スクラムチームやストリームアラインドチームの独立実行能力を担保しやすい)ことの2点で非常に気に入っています。 *1 : Github Actions 2年使ってみてわかったことまとめ #GitHubActions - Qiita *2 : Environmentを使ったGitHub Actions実行

はじめに こんにちは、カイポケのリニューアルプロジェクトを担当しているプロダクトマネージャーの田村恵( @megumu_tamura )です。 カイポケが価値提供している介護業界は、日本をはじめとする多くの先進国で急速に進む高齢化社会に対応するために欠かせない分野です。しかし、介護業界に携わっていない方にとっては、まだまだ身近な存在ではないかもしれません。今回は、介護を少しでも身近に感じていただけるよう、介護業界の概要や課題についてお話ししたいと思います。 そもそも介護とは？ 少し想像してみてください。もし自分が年を重ね、日常生活の一部が難しくなったとき、誰に助けを求めますか？そして、どのような支援があると安心できるでしょうか？介護は、そんなときに必要な支援を提供するためのサービスです。 介護サービスは、ただ身体的なケアをするだけでなく、利用者の尊厳を守り、生活の質を向上させることを目指しています。たとえば、病気や怪我をしたときに医療が必要になるように、介護は日常生活を支えるための重要な存在です。利用者が自立した生活を送れるよう支援し、家族の負担も軽減します。 介護が必要になった時に、すぐに介護サービスが受けられるわけではありません。介護サービスを利用するためには、市区町村への申請が必要で、要介護認定を受けた後に、ケアマネジャーが個別のケアプランを作成します。このケアプランに基づいて、適切なサービスが提供されるのです。 ( 介護予防・日常生活支援総合事業のサービス利用の流れ | 介護保険の解説 | 介護事業所・生活関連情報検索「介護サービス情報公表システム」 より) こうしたプロセスを経て提供される介護サービスは、利用者とその家族にとって安心の源です。私たちが日々当たり前に過ごしていることを、誰かが支えてくれていると考えると、その重要性がより実感できるのではないでしょうか。 介護業界の現状と課題 高齢者の増加に伴い、介護業界ではスタッフ不足や業務の過重労働が深刻な問題となっています。そのため、効率的な介護サービスの提供とスタッフの負担軽減が急務となっています。 1. 慢性的なスタッフ不足 介護業界では、スタッフの確保が困難な状況が続いています。高齢者の増加に伴い、介護サービスの需要が増加していますが、介護サービスを提供するために必要なスタッフ(主に介護職員)を確保することができていません。有効求人倍率は施設系や通所系サービスで3.79倍、訪問系サービスでは15.53倍にも達しています。 ( 「厚生労働省老健局 社会保障審議会介護給付費分科会（220回）」資料１ より加工して作成) 厚生労働省の報告によれば、2026年度には約240万人、2040年度には約272万人の介護職員が必要とされています。このような人材不足の問題は、介護サービスの提供体制に大きな負荷をかけており、現場のスタッフは限られたリソースの中で多くの業務をこなさなければなりません。 ( 「第9期介護保険事業計画に基づく介護人材の必要数について（令和6年7月12日）」 別紙１より) 2. 業務の非効率性と情報共有の課題 介護事業所では、依然として紙ベースの記録や手作業が多く残っており、業務の効率が悪い状況が続いています。特に、事業所間の情報連携にはFAXが使われることが多く、情報の一元管理や迅速なデータアクセスが難しい状況です。こうした状況は、業務の遅延やミスの発生を招き、スタッフが本来のケアに集中できる時間が減少しています。 厚生労働省の「令和5年介護事業経営実態調査結果」では、業務効率化のためのIT導入が強く求められています。ITの導入が進むことで、紙ベースの記録やFAXによる連携がデジタル化され、業務の効率化が進むと期待されています。 介護業界の魅力 ここまで現状と課題についてお伝えしてきましたが、介護業界は、非常に意義深い業界です。多くの介護事業者が、高齢者への深い愛情と献身を持ってこの仕事に取り組んでいます。彼らはただサービスを提供するだけでなく、利用者一人ひとりに寄り添い、心からのケアを行っています。このような姿勢が、介護業界の大きな魅力の一つです。 介護業界で働く人々は、日々の業務を通じて利用者の笑顔や感謝の言葉を直接感じることができ、それが彼らの大きな励みとなっています。介護の仕事は、決して楽なものではありませんが、その分やりがいや達成感も大きいのです。 また、介護事業者の多くは、理想の介護を実現するために事業を立ち上げています。彼らは、自分たちの手で高齢者の生活をより良いものにしたいという強い意志を持っています。このような事業者たちと共に、介護業界の課題を解決し、より良い社会を作り上げていくことは、非常に価値のある取り組みです。 さらに、介護業界はICTを活用して業務を効率化し、現場の負担を軽減する余地が大きい業界でもあります。介護現場のニーズに応えるためのプロダクトやサービスを提供することで、業界全体の発展に貢献することができます。私たちが提供する価値は、介護事業者がその理想を実現するための重要なサポートとなるのです。 介護業界は、高齢化社会が進む中でますますその重要性を増しています。この業界で働く人々にとって、介護は単なる仕事ではなく、人生の大切な一部です。私たちが提供するプロダクトやサービスで、介護事業者の皆様の熱意や努力を支え、さらに大きな成果を生む手助けをしていきたいと強く思っています。 介護業界経験のないエンジニアやデザイナーのみなさんへ 「介護業界のことやカイポケのことは少しわかったけど、なんだか難しそう」と不安に感じたエンジニアやデザイナーのみなさん、安心してください！エス・エム・エスでは、介護業界の経験がない方々にも入社後に知識を習得してエンジニアやデザイナーとして活躍してもらえるように様々な仕組みや取り組みを用意しています！実際、エンジニアやデザイナーのほとんどの方は介護業界は未経験、知識もない状態で入社しています。 介護業界の知識も学べる入社時研修とワークショップ 　エス・エム・エスでは、新たに入社するエンジニアやデザイナーに対して、1日半にわたる介護ドメインの内容を含んだ研修を実施しています。この研修では、介護業界の基本的な知識から、実際の事業所での業務フロー、そしてカイポケがどのように活用されているかを学びます。講義形式だけでなく、ワークショップ形式も取り入れており、具体的なケーススタディを通じて実践的な知識を身につけることができます。これにより、新入社員は現場で直面する課題を理解し、どのように解決していくかを実践的に学ぶことができます。 入社後もいつでも業界経験者などから最新情報を教えてもらえる環境 また当社では、介護ドメインについて詳しくないエンジニアやデザイナーが安心して働けるよう、以下のサポート体制を整えています。 専門知識の共有: 社内のSlackチャンネルやバーチャルオフィスの ovice というツールなどを使って、業界経験者に気軽に質問できる環境を提供しています。これは、日々の業務の中で生じる疑問や不安を即座に解消するための重要な手段です。 定期的な介護業界勉強会の開催: 毎週水曜日の17:30から30分間、介護ドメイン経験者による勉強会を実施しています。テーマは多岐にわたり、実際の事業所での経験や介護業界のトレンドについて学ぶことができます。これにより、チーム全体が常に最新の知識を共有し、業務に活かすことができます。 これらの取り組みによって、エンジニアやデザイナーが、それぞれのスキルを活かして介護業界に貢献できるよう、安心して働ける環境を提供しています。私たちと一緒に、介護業界の未来を作り上げていきませんか？

みなさんこんにちは！ エス・エム・エスでキャリア事業の基盤開発に携わっている川名と申します。 こちらの記事では2024/8/29（木）に開催された Salesforce Developers Meetup にて登壇させていただいた内容をシェアしたいと思います。 発表テーマはSalesforceのCIとなります。 Salesforce導入時に技術者などがおらず、検証やデプロイ環境がレガシーな状態で運用されている環境も多いかと思います。 以前参加させて頂いた Salesforce Architect Group Osaka のMeetupで取られた参加者アンケートにおいてCIを使っているユーザはたしか2割程度という事に驚いたのを覚えています。 テストやデプロイを自動化する事でリリース作業や開発負荷を減らす事が出来ると考えています。 そこでまずはシンプルなテストの自動化についてまとめてみましたので、 ご興味のある方は是非ご覧ください。 speakerdeck.com いかがでしたでしょうか。 これらはDeveloper Editionなどで試す事が出来るものなので是非チャレンジしてみてください。 この他にも必要なApexテストのみを実行する差分検証であったり、 クイックリリースを実現する方法なども別の機会にお話出来ればと考えています。 またお会いしましょう！

こんにちは、プロダクト推進本部人事のふかしろ (@fkc_hr) です。 8月2日、3日に開催されたSRE NEXT 2024に、エス・エム・エスのメンバーが参加してきました&弊社もGOLDスポンサーとして協賛いたしました。 sre-next.dev この記事では、メンバーの印象に残ったセッションの紹介・感想とブースの振り返りをお届けします！ みんなのイベント感想 山口（全社SRE） 全社SREの山口 (@yamaguchi_tk) です。 SRE NEXT 2024のコアスタッフをしていました＆Snykさんのスポンサーセッションで登壇（DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策）しました。（2日目のイベントの撤収時という疲労がピークの時に資料をアップしたのでURL設定をミスってしまい同じ資料が2つアップされています） speakerdeck.com SRE NEXT 2024が本格的に動き出したのが今年の1月くらいで、4月くらいからエンジンがかかって6月7月は追い込みくらいのスケジュール感でした。 SRE NEXT 2024では、主にイベント関連と制作物を担当していました。参加者から誤表記等の指摘はありましたが、イベントアンケートで概ね良い評価をいただいたこと、制作物が当日までにそろっていたこと、イベントが無事終了したので自分としては大満足でした。 自分が登壇したSnykさんのスポンサーセッション「DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策」では、ツカミからの伏線回収、まとめまで話し切ったためか、缶バッジ・スポンサーブースの宣伝をしすぎたのか分かりませんが、AskTheSpeakerではなくエス・エム・エスのブースにAskしにいく方が何人かいらっしゃったようで、「エス・エム・エスのブースの前でAskしないでください　そこにSpeakerはいません　反対側でスタンプラリーの抽選係をやっています」と歌いそうになりました。 SRE NEXT 2025でも引き続きコアスタッフをやる予定ですので、参加者に楽しんでいただけるイベントを作っていきたいと思います。 小笠原（カイポケSRE） エス・エム・エスの小笠原です。スポンサーセッションのLT枠で登壇して以下の発表を行いました。 speakerdeck.com 今回LT枠は5分と短く、その中でプロダクトに少しでも関心を持ってもらうために何を話すか悩みました。限られた時間で私たちの事業について知ってもらうために、具体的な話には踏み込まずにこれまでのプロジェクトの進め方とその中でどのように考えて意思決定を行っていたかについてご紹介させていただきました。 5分枠なので話しきれば終わりと思いきや、セッション後のAskTheSpeakerの時間で参加者や他の登壇者とLTの中身について深掘る機会を得られたことが個人的に楽しく印象的でした。SREのくくりでこれほど人が集まるイベントは少なく、またSREが各社少数チームで構成されることが多いこともあり、普段社内でしない会話もできたのではないかと感じました。 聴講したセッションで個人的に気づきがあったのはTopotalさんの「組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜」に関するセッションでした。 speakerdeck.com インシデント対応をフェーズに分けて細かく成熟度評価することで改善に取り組みやすくなる、という話があり、これは自社でも適用できそうだと感じました。 TopotalさんではSlackアプリケーションを利用してインシデント対応を定型化したりポストモーテムの作成を半自動化・支援するといったサービスを展開しており、確かにインシデントが多い現場ではこのようなサービスは有用だと思いました。 インシデント発生時、担当者はプレッシャーもありなかなか手順書ベースの対応はうまくできないことが多いです。実際には周りの人がそれを補うような動きをして運用でカバーすることが多いのですが、それを運用ではなく仕組みで解決するというアプローチがあるというのが気づきでした。とてもSRE的な発想で良いなと感じました。 上山（ハピすむSRE） ハピすむSREの上山です。 事前に気になっていた「Becoming SRE - SREって何から始めればいいの？」のセッションを聞いてきました。 技術スタックの話ではなく、SREという立場でプロダクトや開発チームとどう向き合っていくのか、という話がメインだったかと思います。 早すぎる改革はエンジニアに引かれるため信頼作りが重要という話や意思決定が早すぎるが故にembeddedしていたのが分離してしまった話では、私が感覚だけでやっていた部分や言語化できていなかったチームとの関わり方が議論されていて、非常に勉強になりました。 当セッションはパネルディスカッションなのでスライド資料は無いと思いますが、深い議論が行われていたセッションの雰囲気が伝われば幸いです。 ブース対応では、アンケート等を通して幅広い分野のエンジニアの方々と技術関連のお話をすることが出来てとても楽しかったです。 加我（カイポケSRE） カイポケSREチームの 加我 です。 SRE NEXT 2024では (恐らく) 人生初となるスポンサーブース周りを担当しました。会社やサービスの紹介、缶バッジ作成のご案内、各種アンケートのご案内などを通して多くの方とコミュニケーションができました。今回初めて用意したノベルティのサプリケース (お薬ケース) も好評だったようで嬉しく思います。 先日のブログ にてDMMさんの「大きな組織にSLOを導入し運用するということ、その難しさ」を気になるセッションとして挙げさせていただきました。 speakerdeck.com 過去に私がSLI/SLOを導入しようとした時に「SLOがユーザージャーニーを表現しきれていない」という問題に直面し、実現するためには大幅な計装が必要となってしまい頓挫してしまったという経験があるからです。これに対してDMMさんのセッションでは「マイクロサービスSLO」と「プラットフォームSLO」の2軸で考えるという話があり、強く印象に残っております。私達が開発しているカイポケも今後SLI/SLOの整備が必要なのでセッションで得られたものを活かしていきたいと思います。 また、2025年もSRE NEXTが開催されること、それに合わせてRoad to SRE NEXTが開催されることが発表されました。私は現在札幌に住んでおり、Road to SRE NEXTが札幌で開催されるとのことなので、もし機会がありましたらぜひ運営メンバーとして協力したいと思っております。 ということでSRE NEXTに携わったみなさまお疲れ様でした！ 高橋（全社SRE） 全社SREの 高橋 です。 今回初めてSRE NEXT 2024に参加させていただき、多くの学びと刺激をいただくことができました。 スポンサーブースで他社の方々と交流でき、コミュニティーの活発さを感じる2日間でした。 特に印象に残ったセッションはエムスリーさんの「Central SREとEmbedded SREのハイブリッド体制で目指す最高のSRE組織」です。 speakerdeck.com エムスリーさんにおける「Central SRE」と「Embedded SRE」のハイブリッド体制についてや、今後の体制の展望を聞くことができました。当社もオンプレミス時代およびクラウド移行時代を経るという似た変革を辿っており、共感できる部分が多くありました。また、ハイブリッド体制をとることのメリットデメリットや、Embedded SREとの役割分担についてもどのように捉えているかを伺うことができました。現在、当社も今後のSRE体制のあり方を模索している最中ですので、今後の参考にしたいと考えています。 来年のSRE NEXTの頃には自分もSRE2年生になっているはずなので、より成長した自分で広く深くインプットできるように邁進していきたいです。 最後に、企画運営をしていただいた皆様、素敵な機会をありがとうございました！ SRE NEXT 2024に参加した皆様お疲れ様でした！ おわりに エス・エム・エスのブースでは、「あなたのXアイコン缶バッジをプレゼント」という企画を行いました。2日間で約150名の方へお渡しができ、最後は見渡すと缶バッジをつけてくれている方が多くいらっしゃったのが印象的です。 Xでの拡散や、口コミでのお繋ぎありがとうございました。 Kotlin Fest 2024でも同様の企画をしたのですが、カンファレンスでよく起こる、アイコンと顔が一致しない。という問題の解消のためにご用意していました。 いつもよりかはキャッチーだったのですが、基本的には課題解決的な思想で始まったノベルティ・ブース企画で、社風が現れているなと感じました。 実はエス・エム・エスは缶バッジ屋さんではなく、「高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける」というミッションのもと、継続可能な日本の未来をつくるための事業づくりをしています。どんな会社かわからないので話を聞いてみたいよという方がいたら、カジュアル面談の申込みも受け付けていますので、ご応募ください！ 楽しいSRE NEXT をありがとうございました！

はじめに 介護事業者向け経営支援サービス「カイポケ」でQAを担当している中村です。先日、「カイポケ」に関わる開発エンジニア3名、QAエンジニア3名で「 Scrum Inc. 認定 アジャイル・テスティング研修 」に参加してきたので、その時のことを簡単にお話しします！ 参加の経緯や目的 私自身はこのイベントの存在を知っていたわけではありませんでしたが、同僚やマネージャーからの紹介と推薦により、会社の支援を受けて参加することになりました。もともとAgile Testingに関する少しの知見と強い興味を持っていたのですが、実践的なスキルを身につけることはもちろん、「組織に適用する方法を学ぶこと」や「組織が抱える課題を解決するための方法を得ること」を目的として参加しました。 ※エス・エム・エスはこのように研修への参加など学習をすることへの支援を積極的にしてくれるため、成長する機会やきっかけが得られやすい会社だと感じています。技術責任者の@sunaotが執筆した記事 があるので、詳細はそちらをご参照ください。 tech.bm-sms.co.jp ※エス・エム・エスのQA組織では「 Agile Testing Condensed 」を参考にした行動指針を作成しており、Agile Testingに関する関心は組織全体で強いものを持っていることも付け加えておきます。行動指針については、私と一緒にQA組織の運営を担当している星が執筆した記事があるので、詳細はそちらをご参照ください。 tech.bm-sms.co.jp 研修内容 ここからは研修内容をダイジェストでご紹介します。研修ではワークが多く、実際に頭と手を動かしながらチームで対話する機会がたくさんありました。そのため、丸2日間という長い日程でも、眠くなることはありませんでした（笑） その前に、会場の写真を1枚だけ撮ることができたので、雰囲気を伝えるために載せておきます。オープンなスペースでお菓子や飲み物も用意されており、リラックスして参加することができました。 DAY1 チーム決め・自己紹介 受講者30名のうち、エス・エム・エムのメンバーは6名で、全体の約2割を占める一大勢力でした。本研修ではチームでディスカッションやワークショップを実施する機会が多く、最初にチーム分けを行ったのですが、スクラムの経験や生成系AIの経験が均等になるように配慮されました。エス・エム・エスのメンバーはスクラムの経験が似通っていたため、チームはうまく分散してくれました。チームが決まった後は、それぞれが自己紹介を行い、チーム名を決めて準備は完了です。 マインドセットの転換 アジャイルではマインドセットを揃えることが非常に重要ですが、急な転換は難しいため、対話を通じて徐々に揃えていく必要があるとのことでした。重要性は理解していますが、各自のスキルや意識、社内での立場が異なるメンバーで構成されたチームだとやはり難易度が高く、じっくりと時間をかけて取り組む必要があることを再認識しました。 複雑さとアジャイル 自分たちが行っている仕事の複雑さを把握しなければ、アジリティの必要性を理解することはできないとのことです。この点についてはあまり意識していませんでしたが、日々の仕事を振り返ると、確かに多くの変数に向き合っており、事前に把握できない変数に苦労していることを実感しました。これはマインドセットの転換にもつながる部分でもあり、アジリティの必要性を関係者間で揃える必要があると思いました。 アジャイル、スクラムの起源 ワークを通じて「アジャイルマニフェストの12の原則の自己診断」や「スクラムの理解度を確認する」といったアクティビティを行いました。私を含め、すべてを完全に理解し実践できている人はおらず、スクラムのフレームワークに沿ってきちんと実施するのは難しいと感じました。これまで、専任のスクラムマスターが配置されているチームにあまり関わったことがありませんでしたが、やはりチームにはスクラムマスターが必要であり、特に成長途上のチームでは成長を促すために長期間専任で関わるのが望ましいとのことでした。 ※参考： アジャイルソフトウェアの12の原則 アジャイルテストとは この分野については元々書籍などで理解していたため、再確認の場となりましたが、テストマニフェストが2023年に更新されていることを初めて知りました。「品質に対する責任…」から「テストに対する責任…」に変わったようです。 変更点 変更前：Team responsibility for quality over tester responsibility. 変更後：Team responsible for testing over tester responsible. 実例による仕様 提示された受け入れ条件に対してGherkin形式で実例仕様を記載するというワークを実施しました。ワークの時間があまりなかったため、形式に沿って記載することで手いっぱいになってしまいましたが、書くこと自体の難易度はそれほど高くないと感じました。また、短い時間でも受け入れ条件の抜け漏れに気づくことができ、実例仕様への期待効果である「曖昧さをなくす」「共通認識を持つ」「リスクを軽減する」「開発効率の向上」を意識しながら、今後も活用していけば有用な活動になると感じました。 DAY2 受入テスト駆動開発(ATDD)、振る舞い駆動開発(BDD) ATDDもBDDも言葉としては知っていたものの、実践した経験がなかったため、楽しみにしていた部分です。Cucumber Test Frameworkを使用したデモとライブコーディングを通じて、DAY1で説明があったGherkin記法を用いたBDDの流れをなんとなくイメージできました。また、ATDDとBDDのどちらも具体的な実例を通じて要件を明確化していくことは共通しており、実際に使用する際にはどちらを選んでも良いという点にも気づきました。 CI/CDとテスト自動化を使用して、早期に、頻繁に「完成」を達成する テストピラミッドを使ったテストプランニング作成のワークを行いました。どんな機能をテストするか、どんなテストを行うか、どのテストレベル（手動テスト、E2Eテスト、統合テスト、単体テスト）で確認すべきかをチームで話し合いながら決めていきました。これは実際の現場でもエンジニアやプロダクトオーナーを巻き込んで一緒に取り組むことで、誰が、いつ、どんなテストを行うかをすり合わせをすることができ、チーム全体での品質保証活動につながると感じました。 AIでテストの有効性を高める チームごとにワーク形式でChatGPTに相談しながらテストプランニングを作成するという活動を行いました。私のチームでは、「受け入れ条件」をインプットし、「Gherkin形式」でアウトプットすることを試みました。その結果、素早くそれらしい形のアウトプットを得ることができたので、うまく活用すれば作業の効率化に大きく貢献できるという印象を持ちました。生成系AIを効果的に活用するためには、ゴール設定や作業手順を具体的に伝える、短いやり取りを繰り返し行う、などのコツがあるようです。 アジャイルテストに適した指標 アジャイルにおける品質はチームの責任なので、テスターの指標よりもチームとして品質指標を定義することが重要とされています。 指標の例 プロダクトの価値を測定するための指標 チームのイノベーション能力を測定するための指標 価値を市場に出すまでの時間を測定するための指標 これまでの経歴を振り返ると、テストケース数、テスト工数、不具合数などをよく収集していましたが、これらは主にテスター寄りの指標であり、アジャイルに適した指標には必ずしも含まれるべきというわけではなく、より多様な視点のテストを期待されていることに気づきました。 現場への導入に向けての研修まとめ 最後は「SMART」のフレームワークを使って各自目標を設定しました。目標設定だけして終わりにならないように、同じチームのメンバーとその後の状況を確認し合うようにと、講師の方から念を押されました。その後、研修受講の証として「Registered Agile Testing」の資格を取得して終了です。この資格は取得できることが急遽決まったらしく、最初に取得した30人のうちの1人になれたとのことで、地味に嬉しかったです。 さいごに 以上が、「Scrum Inc. 認定 アジャイル・テスティング研修」の紹介（かなり割愛していますが…）となります。 もともとAgile Testingについては書籍を読んだりオンラインイベントに参加してお話を聞いたりと、一定の知見を持っていたため、座学パートは学び直しの部分が多かったと感じました。ただし、講師の方への質疑を通じて新たな知見を得たり、ワークを通じて実際に考えたり手を動かしたりすることで実践的なイメージをつかんだり、また、自分が難しいと感じていたことが他の人も同様に感じていると知って少し安心できたりと、研修を通じて多くの学びを得ることができました。 今後に向けては、マインドシフトが重要なので、まずは身近な人との対話の機会を増やし、徐々に広げていくなど、じっくりと時間をかけて取り組んでいきたいと思います。また、自動テストを改善したいという意欲が高まったため、開発エンジニアと密にコミュニケーションをとりながら最適な自動テストを目指していくつもりです。何かしら成果が出てきた際には、また別の機会に紹介できればと思っています。 エス・エム・エスでは引き続きQAエンジニアを募集しています。今回参加した研修のテーマにもなっている「AgileTesting」は、冒頭で紹介したQA組織の行動指針に通ずるところがあり、積極的に取り入れていきたいと思っています。少しでも興味・モチベーションがある方は是非カジュアル面談や選考へのご応募よろしくお願いいたします！！

お疲れさまです、5月に入社しました西田 ( @k_bigwheel )です。先日、エス・エム・エスの開発組織ではZennのPublicationというサービスを導入しました。この記事では、導入の背景と導入開始から完了までの経緯を紹介したいと思います。 Zenn Publicationとは Zenn Publicationとは、Zennというエンジニア向けナレッジ共有サービスの機能の一つです。 公式の紹介ページ に「Zenn上にチームのメディアを開設しよう」とあるように、投稿した記事をPublicationという集合へ結びつけることで、企業や組織としての集まりを表現でき、ブランディングやPRに使えます。 導入活動まで 今回、Zenn Publicationの導入に動き始めたのは5/30で、導入が完了して使えるようになったのは7/18でした。なのでこの1.5ヶ月ほどで導入できたのですが、実はZenn Publicationを導入したい、導入しようという話は去年の3月時点ですでに持ち上がっていました。 社内のesaに複数のページが作られ、導入したい背景やメリデメがまとめられるなどしたのですが、このときは導入に至りませんでした。 その一つの要因は類似サービスとは異なるZenn Publicationの規約の特殊性(書いた記事がエンジニア自身に帰属するようになる)をどう扱うか、社内で整理しきれなかったことにあります。ただ、本質的に進まなかった理由は、Zenn Publicationの導入に大きなモチベーションを持つ人がいなかった点にあるかなと思います。エス・エム・エスではすでにこのテックブログや外部登壇などアウトプットの手段が複数用意されており、Zenn Publicationがなくとも代替の手段がありました。 導入活動開始 その約1年後の5/16に私(西田)が入社します。 私には技術Tipsをインターネット上へアウトプットすることに大きなモチベーションがありました。過去に Qiita や 個人ブログ へアウトプットしてきたこともありますし、業務中に得られた知見を社会へ還元することに強いモチベーションを持っていたためです。また、前職でそれを可能にするガイドライン整備をした経験もありました( 業務中に書いたことを明記することで堂々と社会へ還元する )。 入社直後はこういったTipsを同僚に共有するいい機会なのですが、それをするプラットフォームがまだなく、一方で一年前にZenn Publicationの導入を検討していたことに気づきました。そこで、エス・エム・エスでも同様のガイドライン整備を開始することにしました(5/30)。 導入する上での課題 Zenn Publicationを導入するに当たっては、大きく分けて2つの課題がありました。それが次の2つです: 開発組織外との調整(法的リスクやPR文脈でのリスクの管理) 開発組織内での調整(既存のアウトプット方法との整合性) 開発組織外との調整(法的リスクやPR文脈でのリスクの管理) 1つ目はZenn Publicationで記事を書く上でのリスクのコントロールです。 Zenn Publicationに書いた記事は社内からだけでなく、インターネットに接続している誰からも閲覧できるため、場にそぐわない内容や誤った内容を投稿すると炎上するリスクがあります。また、前述の通りZenn Publicationは一般的なテックブログなどと異なり、記事が企業ではなく書いたエンジニア本人に帰属します。この辺りを会社のルールや方針とどうすり合わせるかという点も課題でした。 まず前者の広報文脈でのリスクについては、投稿前にエンジニア最低1名のレビューを挟むことで安全装置としました。また、書く内容を純粋に技術的なものに絞ることで会社の文化やルールなどが間違って伝わってしまうリスクをなくしました。ここはもっと安全側に倒そうとすればいくらでもできるのですが(毎回PRチームのレビューを挟むなど)、良い技術Tipsが迅速に世の中で公開されることに価値があること、純粋技術的な話であればリスクはかなり低いことなどを考慮して公開までのステップは必要最低限にしています。 後者の記事の帰属の問題については、時間をかけて準備を行い、リスクマネジメントを担当する部署に理解をしてもらった上でその導入に同意してもらいました。前提として、私含め導入関係者が Zenn Publicationのコンセプト の 例えば企業のテックブログでは、多くの企業が更新を続けることに苦労しているようです。その大きな理由として、メンバーのモチベーションを維持することが難しいという点が挙げられると思います。 労力をかけて良い記事を書いても、それは会社の持ち物であり、自分ではコントロールがしづらいものです。たとえ内容の間違いに気づいても、修正することさえ難しいこともあります。 私たちは、記事は著者本人の持ち物であり、退職後も本人が管理できるべきだと考えています。 Publicationを脱退した著者は、Publicationに投稿した記事をそのまま残しておくことも、個人の記事に変更することもできます。どちらを選択しても、記事は著者の成果物としてプロフィールに残ります。 「それでは会社の資産とならない」と心配する経営者もいるかもしれませんが、この自由がメンバーが記事を書くことを促し、より会社のブランディングや採用につながるのではないかと考えています。 に共感していたことがあります。導入を主導した私自身にもこれが正しいという確信があったので、あとはちゃんと伝わる資料を用意してロジカルに説明すれば必ず同意してもらえると信じていました。実際、Slack上でのやり取りは数週間続いたものの、MTGとしては何度もすることなく1度で済んでいます。 ※ ただし、ここについては利用規約の読み取りの経験や関連する法律理解が一定ある私が担当していたこともスムーズに進んだ要因だと思います。利用規約をどう解釈してどう対応するかはまったく知識のない者にとってはかなり難しい問題ですので、経験のない人がやる場合はもっと大変だと思ったほうがよいでしょう。 開発組織内での調整(既存のアウトプット方法との整合性) 2つ目は開発組織内での調整です。 エス・エム・エスの開発組織では、これまでにすでにテックブログや外部登壇などの外部アウトプットがあり、社内用ナレッジサービスとしてesaなども導入していました。 そのため、Zenn Publication導入にあたってはテックブログと何が違うのか、社内esaに書くことと比べてのメリット、Zenn Publicationを導入し、維持していくコストとメリットが釣り合っているかなどを整理していきました。 その辺りは必要だろうと予測がついていたのですが、予想外だったのはアウトプットに対する組織の文化・考え方の点です。エス・エム・エスでは従来から業務中に得た知見であっても、個人のブログや登壇で話していい、という文化だったのですが、このZenn Publication導入によって、個人のブログへの執筆などが制限されるのではないかという不安が組織内で起こりました。これは入社1ヶ月未満だった私が知らない文化で事前に想像できておらず、Zenn Publicationのガイドライン作成の中で発覚しました。最終的に既存のアウトプットと整合するものにガイドラインを変えることで対応しました。これが、本格稼働前に発覚して修正できたのはとても良かったと思います(開始してから発覚したらゴタゴタするため)。 余談ですが、年をとって経験を重ねることで社内の法務部・PRチームとのやり取りはどんどん上手くなりましたが、こういった組織の文化・開発文化というものは組織ごとに異なるため、常に未知のものがあるなと思います。前職でも、入社後数年経ってから、アウトプットに関する考え方が組織と自分で大きく異なることに気づく、ということがありました。 導入完了 上記の課題2つが7月にクリアできたため、7/18に晴れて全体チャンネルで利用可能になったことを告知しました。 実際にできたPublicationが以下です。 zenn.dev 株式会社エス・エム・エス | Zenn 公開から1ヶ月以上経って、記事数は4とまだまだ *1 ですが、これから徐々に増えていけばいいなと思っています。 振り返り まず組織としての振り返りの観点で考えると、まずは、新たなアウトプットの手段が増えたことが単純に喜ばしいなと思います。エス・エム・エスの社内ではものによってはインターネット上にほぼない、もしくはまったくない知見や技術なども見つかっていますので、そういったものを迅速にアウトプットする手段は長期で見て社会に、そしてエス・エム・エスの開発組織としてもメリットになるでしょう。 個人として振り返ると、この一連の動きで社内の各部署とうまく連携できたこと、これをきっかけにエス・エム・エスの開発文化の理解が進んだことが大きなメリットでした。こういった開発組織の内外を跨いだ動きを苦手とする人も多いと思いますが、私はこの分野に強みがあるため、今回の導入が1.5ヶ月という短時間で大きな手戻りなく達成できたことはよい成功体験になりました。今回のZenn Publication導入のような組織規模での動きはレバレッジが効きやすく効果が高いので、チャンスがあればまたやっていきたいと思います。 *1 : この記事の公開時点では6記事。

2024年4月にエス・エム・エスに入社した田実（たじつ）と申します。 この記事ではエス・エム・エスに入社した理由を経歴を踏まえて振り返りつつ、入社して思ったこと、これからやりたいことを紹介します。 これまでの経歴 1社目はSalesforceの導入・運用支援を行う会社でSalesforceエンジニアとして働いていました。 顧客折衝・要件定義・設計・開発・テスト・リリース・保守と、様々な業界のシステム開発に一気通貫で携わることができました。SalesforceだけではなくAWSやHerokuを使ったWebアプリケーション開発や外部サービス連携などの経験もでき、システム開発エンジニアとしての下地を作ることができました。 働いていく中で、次第に技術自体への興味関心が強くなったことや、腰を据えて自身の技術力やサービスを伸ばしていきたいと思うようになり2社目の会社に転職しました。 2社目は自社サービスを開発・運用している事業開発会社で、ポイント交換やデジタルギフト、ファッションサブスクリプションの新規事業のサービスに携わりました。 GitHubを使った開発フロー、アプリケーション/DB設計、CI/CD、監視、アラート運用、インシデント対応など、自社サービスを運営していく上で必要不可欠な知識を身につけることができました。 施策系の開発以外にもPHPやライブラリのアップグレードや不要コードの削除、静的解析の導入など、大規模アプリケーションの技術的負債を解消する取り組みも行い、技術力を大きく伸ばすことができました。 このように腰を据えて技術力を伸ばしていきたいという当初の目的は満たせたのですが、次第に事業やプロダクト自体にも興味が出てきました。 3社目はノーコードのSaaSを運営する会社です。自分が魅力に思うプロダクトに携わることで、技術力・非技術力をもっと磨けるのではないか、日々の仕事の充実度も上がるのではないかと思い転職に至りました。 SaaS特有の事業的・技術的な難しさは多々ありましたが、好きなプロダクトを技術的にどう伸ばしていくかを考えることは非常に充実した時間でしたし、結果としてエンジニアリング力も上げることができました。 プロダクトの面白さを日々感じていた一方で、「プロダクト・事業が解決する課題・事業領域」に物足りなさを感じたことや、自身のライフステージの変化もあり今回の転職に至ります。 エス・エム・エスに入社を決めた理由 事業領域や課題は実際に聞いてみないと魅力がわからないなと思い、カジュアル面談は40社ほど受けました。カジュアル面談では「ビジネス・事業領域の面白さ」「自分の経験を活かせるか、伸ばせるか」を軸に見ていました。また、これまでの会社では独力で技術的改善を進める経験が多く、独力で進めることの限界を感じていました。そのため、チームで課題を解決する・チームと一緒に成長していく力を伸ばしていきたいという思いもあり、それを実現できそうな環境を探していました。 エス・エム・エスではカジュアル面談や面接を通じて、医療・介護領域における社会課題とそれにどう立ち向かっていこうとしているのかを丁寧に説明してもらいました。話を聞く中で、課題を解決したときのインパクトの大きさや課題の難しさを感じつつもビジネスや事業領域の面白さにワクワクしたのを覚えています。 人材紹介のサービスではPHP・Laravel・Salesforceが利用されていることや、技術面で改善していきたいポイントがあるということを伺い、自身の経験が十分に活かせる環境であることも入社の決め手でした。 エス・エム・エスではチーム間で技術やドメイン知識の共有を強化する動きがあり、人材紹介グループでは技術的な品質意識をチーム全体で上げていく プロダクションレディ の取り組みがあるなど、「チームで」やっていく経験やスキルを伸ばせそうなことも入社した理由の１つです。 また、自分自身もエージェント型の人材紹介サービスにお世話になった経験から、エス・エム・エスが運営している人材紹介サービス自体に対しても好印象でした。そんなこんなで今回ご縁がありエス・エム・エスに入社しました。 入社して思ったエス・エム・エスの良いところ 入社してから現在まで、 保育士人材バンク という保育士向けの人材紹介サービスのシステム開発・運営をしています。 入社前は、「エンジニアが要求・要件から主体的に関わってコーディングだけではなく本質的な課題解決ができそうな環境か」とか「開発環境も含めた改善業に対してネガティブではないか」あたりを気にしていたのですが、そのあたりは特に問題なく楽しく仕事ができています。 前者の懸念に関しては、マーケティングチームとエンジニアチームが協力して各種施策を進めているのですが、いわゆる「考える人」「作る人」といった分断は全くありません。エンジニアの意見が求められることもありますし、表面的な要求をそのまま実装するのではなく、本質的な課題を捉えないといけない場面もあります。 後者の改善に対する姿勢に関しては、前述のプロダクションレディのような技術的な改善の取り組みもあり、改善に対して前向きです。私もいくつか改善に対する相談などをSlackで投げたりしているのですが、いずれも建設的な議論ができています。強めの言葉やネガティブな発言をする人もいないので、心理的にもエンジニアとして働きやすい環境です。 esaを共有して良いリアクションをもらっている図 チーム間のエンジニア同士のつながりや技術的な共有をするような試みも多数行われています。esaで他チームが書いたドキュメントを見れたり #tech #php #ruby #golang のようなSlackの技術系チャンネルもありますし、チーム横断で交流できるようなチームビルディングのイベントも頻繁に行われています。 また、このテックブログの執筆・プロセスもかなり整備されており、編集チームが執筆のサポート・校正を行ってくれたり、公開予定の記事や日付もしっかり管理されています。こちらも継続してチームとして改善し続けている成果だと思いますし、良い感じに改善プロセスを回せている組織なんだろうなぁと思っています。 これからやりたいこと 現在担当している保育士人材バンクをもっと良くしていくためにはエンジニアリングによる施策支援が重要です。この「エンジニアリング」の部分をもっと効率的に、効果的に回していくために守りの改善もしていく必要があります。 トライしやすい環境を作り、不確実性の高いドメイン領域でエンジニアの力を活かせるようにできると良いなと思ってます。そのためにも、大小様々な課題に対して自分の能力だけではなくチームを巻き込んで良い感じな技術基盤を作っていきたいです。 そして自分が担当しているサービス以外のチームにも知見を共有し、人材紹介開発グループ全体のビジネスをより強化するような技術環境、組織を一緒に作っていければと思います。 また、人材紹介開発グループのテックブログの記事が少なめなのでそこも増やしていきたいと思っています。技術的にめちゃくちゃ良いネタをたくさん持っているので、自分も含めてチームとして書く流れを作れると最高ですね…！

はじめに カイポケリニューアルプロジェクトでQAエンジニアを担当している北村です。 今回の記事では、2024年1月に入社した後、自身の所属チームで行ってきた品質保証関連の取り組みについてお伝えできればと思います。 エス・エム・エスの品質保証活動について興味がある方は是非目を通していただければ幸いです。 エス・エム・エスのQA組織の行動指針について エス・エム・エスのQA組織は「行動指針」という形で、QAエンジニアが大切にしている考え方を言語化しています。行動指針の詳細については、以前の記事で説明しておりますので是非ご覧ください。 tech.bm-sms.co.jp 今回の記事では、行動指針の一つでもある「チームで品質保証」を実現するために行なっている施策について紹介いたします。 「チームで品質保証」実現の第一歩はテストドキュメンテーション ここでは「チームで品質保証」を実現するための第一歩として実践したテストドキュメンテーションについて説明します。「テストドキュメンテーション」は「テストに関する情報のドキュメント化」を指しています。少し紛らわしいのですが、今回の記事で言っている「品質保証」は「品質を向上するために行う作業全般」を指しており、「テスト」はQAエンジニアによる手動テストだけではなく、開発者テスト・自動テストも含めたテスト全体のことを指しています。「品質保証」と「テスト」を明確に定義して線引きをするというよりは、「テストも含めた品質を向上するために行う作業全般」の話をしているんだなという認識で読んでいただければ幸いです。 「チームで品質保証」つまり「チームメンバー全員参加の品質保証活動」を実現するためには、「品質保証活動の目的とは何か」「どうやってプロダクトの品質を向上させていくのか」について認識を揃える必要があります。「品質保証」という言葉だけでは人によって解釈・受け取り方が異なるため、具体的な活動内容が想像できるように「 品質保証方針 」というドキュメントを作成しました。 品質保証方針には「品質保証活動を行う目的」「品質を向上するための実際にやること」「Quality / Cost / Deliveryのバランスをどう取るか(トレードオフの関係という意味ではない)」といった情報を記載していて、この方針を元に各機能開発における品質保証活動をしていきましょう、という宣言のようなものです。 各機能開発においては、QAエンジニアが「 テスト要求分析レポート 」「 テスト計画書 」といったドキュメントを作成します。この２つのドキュメントを簡単に説明すると、「テスト要求分析レポート」は主に「テスト対象機能の特定」「テスト目的の設定」「テスト戦略の概略整理」という目的で作成し、テスト計画書は「テストの目的や目的達成に至るまでの具体的な手段・スケジュールを明確にする」という目的で作成します。 ここからは「なぜこのドキュメントが必要か」「このドキュメントを通じて何を達成したいのか」といったドキュメント作成の意図も交えながら各種ドキュメントについて解説していきます。 テストドキュメント各種について 「品質保証方針」について 「品質保証方針」は各機能開発における品質保証活動の前提となる考え方で、「私たちのチームは基本的にこうやって品質保証活動をしていきます」という方針が記載されているものです。「品質保証活動で達成すべきもの」「品質向上の基本方針」「品質保証プロセス」といった項目で構成されています。 「品質保証活動が達成すべきもの」とは 品質保証方針では、「品質保証活動が達成すべきもの」は「チームで達成すべきもの」とイコールであるという書き方をしています。そもそも「品質って何？」については現状明確な定義をしておらず、チームで掲げている目標を達成するための手段として品質保証活動があるんだよ、ということを表現しています。人によっては(あるいはチームによっては)「テスト・品質保証活動はチーム内の独立した活動である」という考え方もあると思うので、品質保証活動とプロジェクト活動が一体であることを強調しています。また、「Quality / Cost / Deliveryのバランスをどう取るか」についてもこの項目で言及しており、プロジェクトの状況に応じて「今の段階では早くリリース(Delivery)して価値検証を優先しましょう」「こういった機能については品質(Quality)を重視しましょう」といった方針が書かれています。 「品質向上の基本方針」について 「品質向上の基本方針」には、仕様の検討からリリースまでにどう言った方針で品質を向上させていくかを記載しています。「不具合は早期発見を目指す」「不具合は予防と検知に分けて対策を講じる」といった方針が記載されており、この方針に従ってテスト計画を立てていきます。 「品質保証プロセス」について 「品質保証プロセス」については、品質保証方針を前提とした各機能開発におけるプロセスを書いています。 簡単に表現すると以下のような内容です。 最後に補足的な話ですが、この品質保証方針は「初版」の段階で、これからチームのみんなでアップデートしていくものだと考えています。現状ではチームメンバーに対して共有するタイミングが少なく完全に浸透しているとは言えないのですが、今後は品質保証方針を通じてチームの品質保証活動を導いていきたいと思っています。 特に「品質の定義」「品質保証活動の目指すもの」についてはアップデートしていく必要があり、達成すべき品質の基準を作りながら品質保証活動を最適化していこうと思っています。 「テスト要求分析レポート」「テスト計画書」について 「テスト要求分析レポート」作成は「テスト計画書」作成前の情報整理のような立ち位置にしており、互いに結びつきが強いためセットで取り扱います。 それぞれに記載している内容は以下の通りです。 テスト要求分析レポート 分析のインプット(リファレンス) テスト対象の特定 テスト戦略の概略整理 テストフローの設計 テスト計画書 計画のインプット(リファレンス) テスト対象・目的・戦略 制約事項 リスクマネージメント テスト開始・修了基準 不具合管理 テストスケジュール 項目で見ると「テスト対象の特定」「テスト戦略」が重複していますが、テスト要求分析レポートではあくまで「概略を整理する」ことを目的としており、テスト計画では「明確な決定事項(これで進めるよ、と言えるもの)を記載する」ことを目的としています。ただし「テスト要求分析レポートではここまで書く。これ以上書かない」といった明確な基準を設けていないので、状況によって記載する粒度・いつどこまで決め切るかを柔軟に変更して対応しているというのが実状です。早めにテスト観点の整理や要求・仕様の構造化を行なって合意を取りたいのであれば、テスト要求分析の段階で行うこともあります。その時のニーズに合わせながら、テスト要求分析 -> テスト計画と段階的に品質保証活動を具体化していきます。 こういったドキュメントを作成しておくことで、後から見直した時に「あの時はこういう経緯・意図でこうゆうテストをやったんだな」ということがわかるので、貴重な資産にもなります。勿論リリース後に万が一インシデントが起きてしまった場合、どの工程に問題があったのか特定するのに役立てることができます。 また、これらのテストドキュメントは他のロール(PdM 、PO、Dev)にレビューしてもらっていて、レビューを通じてリリースまでに行う品質保証活動の認識を揃えています。他ロールのレビューは毎回必ず行っているものではないのですが、ドキュメントのレビューや情報共有を通してQAエンジニアが実現したい品質保証プロセスをチームに定着させていきたいと思っています。 ドキュメント作成の基本方針について ここまで「品質保証方針」「テスト要求分析レポート」「テスト計画書」という３つのドキュメントを作成しているという説明をしてきました。説明を読んでいる間「そんなにたくさんドキュメントを作って時間かからないの？」という疑問を持つ人もいたかもしれませんが、全ての機能開発で全てのドキュメントを作成しているわけではありません。テスト対象・テストで確認する観点が明確な時は「必要なものを必要な時に作る」を基本方針としています。必要かどうかは「ドキュメントを用いた情報整理が必要か」「誰とどんな合意を取りながら進めるべきか」と言ったところを勘案して決断しており、開発対象物やチーム・プロジェクトの状況に応じて適切な動き方をすることを重視しています。 その他「チームで品質保証」を実現するためにやっていること 実例マッピング 冒頭でご紹介したQA組織の行動指針についての記事でも簡単に紹介していますが、私が所属しているチームでも実例マッピング(Example Mapping)を導入しています。 実例マッピングでは開発がスタートする前にPdM ・PO・Dev・QAエンジニアが揃ってユーザーストーリーについて疑問点を洗い出し、解消していきます。こう言った活動からも品質リスクの軽減を目指しています。 私が所属しているチームでは、ロールに関係なくチームメンバー全員がサービス理解・ユーザーへの貢献に対してモチベーションが高く、仕様・デザインの共有の場では積極的に議論が行われます。プロダクト要求やデザイン共有の時点で、各ロールのフィードバックが行われ活かされていくと、その後の開発品質向上・不具合混入防止が見込めるのでとても有効です。 テスト実施状況・不具合抽出状況の計測 まだ導入して間もないのですが、バグヒット率(何件テストを実施し、何件どのようなバグが見つかったか)の計測を開始しました。テストの成果となる指標を中長期的に取ることで、「致命的な不具合がどれぐらい出ているのか」「QAエンジニアのテストでどれぐらい致命的な市場不具合を防ぐことができているのか」を可視化できる状態にしておくことが狙いです。どのような傾向が読み取れるのか不透明な状態ではありますが、まずは簡単に計測できるところから開始しています。 こういった傾向分析をチームの品質保証活動にフィードバックしていって、品質保証活動全体の質を向上していけたら良いなと思っています。 まとめ 私の所属チームでは、ここまでで説明したようなテストドキュメントを通して良い効果が出始めていますので、最後に少し紹介します。 例えば、テスト計画書レビューでは開発者とテストスコープやテストの仕方について議論する機会を作ることができています。開発者視点での品質リスクを出してもらったり、QAエンジニアから開発者に「こういうところはテストしておいて欲しい」といった依頼をしたり、効率的にテスト活動を行うための情報共有ができています。 PdMやPOにも同様の機会を設けているのですが、対象の開発案件で実現したいユーザーストーリーの認識を合わせたりテストの全体像を共有するだけではなく、プロダクトリスク・プロジェクトリスクといったリスク管理について議論をすることができています。リスク管理のところはPdM・POから良いフィードバックを得られることが多いです。 テスト要求分析レポートのチーム内QAレビューでは、特にテスト戦略のところでは議論が白熱することが多く、どの段階でどのような粒度でテストを行うか、どのようなテスト技法を使うかといったところを議論しながら進めることができています。 開発者・PdM・POそれぞれの得意領域で良いフィードバックをもらいながらテスト計画を改善し、テスト活動を実行していくことで「チームで品質保証」を実現していきたいと思っています。 ただ、今のテストドキュメントやテストプロセスが最善だと思っているわけではなく、チームの状況やプロダクトを取り巻く環境の変化に合わせて改善し続ける必要があります。テスト計画の内容は適切だったのか、計画通りにちゃんと実行できていたのかといったことを振り返るのがとても重要です。 今回ご紹介した取り組み以外にも行っている活動や、今後やりたいと思っていることもたくさんありますので、「もっと詳しく聞いてみたい！」と言う方は是非カジュアル面談の場でお話しましょう！

先日開催されたRubyKaigi 2024にエス・エム・エスもスポンサーとして参加しました。 tech.bm-sms.co.jp 社内で「実際どんな感じだったか知りたい」という声があったため、参加しなかったメンバーへ向けてフリートーク形式の「RubyKaigi共有会」を実施しました。 そこで今回は、共有会で取り上げたトークテーマと実際のやりとりをかいつまんでご紹介できればと思います！ 今回ご紹介するトークテーマは以下の4つです。 参加した目的について セッションについて ブースについて #kaigieffect *1 について トークテーマ「参加した目的について」 "RubyKaigiに参加する目的はなにか？"というところからフリートークは始まりました。"セッションを楽しむため"という話はもちろんのこと、”いままで過去仕事をしてきた人と会うため" というような再会の場として参加するという話もありました。 また、なにか特定の目的ではなく「 RubyKaigiに参加するため 」「 そこにRubyKaigiがあるから 」などの言葉も飛び出し、RubyKaigiの存在そのものが参加する理由になっているという話もありました。 トークテーマ「セッションについて」 "好きなセッションを教えて"、というような問いかけには「全部」という声がありながらもあえて1つあげるとすれば、というところでメンバーから思い思いのセッションが挙がりました。 まず話題に登ったのが二日目のキーノート " Leveraging Falcon and Rails for Real-Time Interactivity " でした。メンバーからは「取り上げられた技術に関して、"ちゃんと手を動かしてコード写経してみて動きをちゃんと見てみよう"と思うような、技術的にやってみたいと思わせるトークだった」ということが感想として述べられました。 同じく、初日のキーノート " Writing Weird Code " の話題でも盛り上がりました。参加していないメンバーに向けて、このセッションのどこがすごかったかを説明するのに苦労しながらも、過去のTRICK *2 のコードを紹介しつつ、セッションの衝撃を共有しようとしていました。 先月、TRICK2022(超絶技巧Ruby意味不明コンテスト for RubyKaigi)で金賞をとってきたプログラム(Quine)です。 全てのフレームが、魚達がその場所から泳ぎを再開する実行可能なRubyのコードになっています。 魚・水草・泡でコードの一部が欠落していますが、誤り訂正により復元しています。 pic.twitter.com/vQsGG5o7Of — ぺん！ (@tompng) 2022年10月18日 途中でパーサーについての話題になり、詳しいメンバーからの「なぜ去年〜今年のRubyKaigiではこんなにたくさんのパーサーにまつわるセッションがあったのか」について歴史的な経緯を含めた解説も交えつつ、今のRubyコミュニティでパーサーがホットトピックになっていることをその場で体験できるシーンもありました。 トークテーマ「ブースについて」 他社さんもふくめたブースに関しての話もいくつかあがりました。まずは最初にあがったのはSTORESさんによるRuby "enbugging" quiz でした。 product.st.inc 参加メンバーも、自社のブースにお客さんがいない時間帯に楽しんでいました。 またシンプルフォームさんによる自社ドメインにちなんだクイズや、SmartHRさんの人事労務に関するフレーズのタイピングゲームなど、各社のビジネス領域をうまく活用したブースに関して盛り上がりました。 また、ちょうど我々のブースの真裏のRuby開発さんでは、プロの理学療法士さんによるマッサージが実施されていたことも話題にあがりました。弊社メンバーも何人かお世話になっており、解説付きのマッサージを受けることができて良かった、というところで盛り上がりました。 我々エス・エム・エスのブースに関しても振り返る場面がありました。エス・エム・エスでは実際に自分たちが普段開発しているプロダクションコードを会場限定で公開する、という取り組みを行いました。普段どういう開発をしているのだろう、というところに興味を持ってみてくれる方が非常に多かった印象です。 トークテーマ「 #kaigieffect について」 "皆さんの #kaigieffect を教えて下さい"という話が最後のトークテーマとしてあげられました。「コードを書きたくなった」という定番の話のあとに、「英語を頑張らないと」という言葉が出ると参加メンバの多くから同意の声があがりました。英語話者の人とコミュニケーションする機会が多い、RubyKaigiならではの話題でした。 また、「(コロナ禍に入ったことで足が遠のいていた)地域.rbに参加したくなった」という声もありました。RubyKaigiでの交流を経て、オフラインでのミートアップへの気持ちが高まっていることが感じられる一幕でした。 最後に エス・エム・エス社内には、Rubyで開発しているプロダクトやチームが複数存在しています。今回のRubyKaigi 2024への参加を通して、普段仕事では関わらないメンバー間の交流が生まれたりもしました。そんな側面も含めて、RubyKaigiへの参加は有意義なものだったのではないかと思っています。 たくさんのプロダクトがあり、Rubyで開発されているものもそうでないものもある弊社ですが、もし少しでも興味を持ってくださって、どんなふうにやっているのだろうと思っていただいた方は以下からカジュアル面談にお申し込みください！ *1 : RubyKaigiや地域RubyKaigiに参加したことがきっかけで起きたことを #kaigieffect を付けてSNSでシェアするという文化があります。 https://x.com/snoozer05/status/91327881447350272 や https://scrapbox.io/iki-iki/%23kaigieffect を参照。 *2 : TRICKは "Transcendental Ruby Imbroglio Contest for rubyKaigi" の略で、日本語にすると「超絶技巧 Ruby 意味不明コンテスト in RubyKaigi」という超絶技巧のコードを競い合うコンテストのことです。

エス・エム・エスで開発組織のマネージャーをしている @sunaot です。余談ですが、このブログでは名乗るときにいくつかの言い方を過去にしていて、「技術責任者」「技術組織のマネージャー」なども名乗っています。面接の場では「プロダクト組織のマネージャー」と言っていたりもします。これは次々肩書きが変わっている...というわけではなく、どれもロールとしてはやっているので、そのときのコンテキストで一番適切なものを名乗っていました *1 。今回は、開発組織のマネージャーとしての側面から話すのが適切でしょう。 さて、 5月28日に開催されたファインディ株式会社主催のイベント で、「継続性視点での開発生産性マネジメント」というタイトルで発表しました。今回の発表内容は、映像が YouTube アーカイブに、スライドは Speaker Deck にそれぞれアップロードされ公開されています。 イベントのアーカイブ動画 『継続性視点での開発生産性マネジメント』 スライド 『継続性視点での開発生産性マネジメント』 そのため、細かな内容はそれぞれを見てもらうものとして、この記事では、 当日話した内容への補足 今回このテーマを選んだ動機 について説明をすることにします。 発表内容の概要と補足 発表内容を一文で説明するとしたら、 「戦略志向の組織マネジメントを通して高い組織パフォーマンスを実現し、ビジネスと開発それぞれの継続性を手に入れよう」 です。 戦略を考えるステップについてはスライド p44 に紹介しています。いかにこのコンテンツをつくるかについては、より具体的な事例を話すしかなく、今回はつっこんで話すことができませんでした。ここでは少しその補足をします。 まず、このようなプランを考えるときになにをやるのかやそのプラクティスがどれだけ切れ味鋭いかっこいいものかといったことへ意識がとられますが、そうした WHAT よりも大事なのが WHY にあたる部分です。このスライドでは、 「どのような状況か」「その中でどのような状態を目指すのか」「その過程でのイシューはなにか」の部分になります。今の状況をどう解釈するのかには無数の可能性があります。その中で将来に対しての見地から、 「今はこのような状況だと見ている」というスタンスを明確に置く のがまず最初の重要な仕事です。多くの場合、ここがなんとなくの現状認識・共通見解というところからスタートしてしまい、その後のアプローチが弱いものになる傾向があります。 ここでスタンスを明確にしていくにあたり重要になるのが 「その中でどのような状態を目指すのか」 です。物事の良し悪しの評価というのは文脈によって変わってきます。今どのような文脈だと考えればよいかの指針となるのが目指すべき状態になります。 最後に 「その過程でのイシューはなにか」 です。おおよその文脈が定まり、現在地へのスタンスを明確にしました。それでも、そこからゴールへたどり着く道筋はたくさんあります。まずはその道筋の中から考慮に値するものを選択肢として挙げていきます。そして、それぞれの選択肢を評価していく中で、どのルートをたどるにしても壁になってくる問題というのが浮かび上がってきます。それが組織全員で取り組むべき重要なイシューです。イシューの設定が良質なほど、その後の解決のフォーカスや実現過程の組織の動きがぶれずに問題へ立ち向かうことができます。 一連のストラテジーを作るのは EM 一人の仕事かというと、そうとも限りません。どこまでのパートを一人で考えるか、周りを巻き込み答えをつくっていくかは状況によって最適解が変わってきます。組織でこのプランを組み立てられるようにしていくのが EM の大事な仕事になります。 このテーマとした動機 今回のイベントは Findy さんが主催し、開発生産性をテーマにこれまでも多数の発表がされてきているものです。発表の機会をもらえたときに、当然なにを話すのかを考える必要がありますが、実はやや内容に迷いました。というのも、私は あまり開発生産性を目的としてなにかを考えたことがなかった からです。 もちろん、デリバリーの効率を上げるために開発者体験を向上させることや、ムダを省くこと、早い失敗から開発のサイクルへ継続性をもたらすことといった開発生産性へつながるプラクティスの一つ一つは大事にして来ています。むしろ人よりもそこへ費やした時間は長い方だと思います。ただそれらは Time to market を短くしたいと求めた結果であって、開発生産性へこだわってやってきたわけではなかったりします。 そして、発表の中でも少し触れましたが、そうやって 開発生産性の高い状況を求めても容易にそれが壊れうる ことも知っています。その最たるものはビジネスの状況悪化ですが、そこまで大きな要素でなくても、フィーチャー開発の過程でも環境への理解不足からデリバリーの効率のために投資したはずの環境はやはり壊れることがあります *2 。 そうした理解の中で、 開発生産性をことさらに取り立てて扱うことよりも、それを通して何を実現するのかへ目的を置いた発表内容にしたい と考えていました。そして、一般解としてのデリバリーの効率が高い状態を目指すのでなく、その効率というのも何に対して最適化させるかを考えるということを話すことにしました。ドメイン固有の問題を特定し、その問題に最適化をした解決をすることで、デリバリーの効率を上げることという機能効率の問題から、そのビジネスにおいて何がパフォーマンスを決めるのかという目的志向の問題へ問題設定を変えたかったのです *3 。 発表では必要なプロセスの説明はしましたが、具体的な話をあまりできなかったので、こちらにも補足をしておきます。たとえば、ソーシャルゲームの開発をしている場合によくある話としては繰り返し行われるイベントをどう扱うのかという話があります。類似したフォーマットのイベントを繰り返すことでビジネスの成長は得られるため、そこへ最適化をして効率を高めるというのはよく採られている選択だと思います。ドメイン固有の解の一例でしょう。 では、これは良い選択なのかというと、組織の視点では様々なことが考えられます。イベントにはフォーマットがあるため、基本的にはフォーマットに沿ってパラメータを変える程度の開発へ人やプロセスを最適化したとします。これは他の新しい機会を開拓する能力を下げるかもしれません。反対にそこで生み出した時間の余裕によって、新しいチャレンジをする機会をつくることができるという理解も可能です。 今自分たちが扱っているソーシャルゲームというものをどういうプロダクト、マーケットだと理解をするのか という前提の置き方で、答えは変わってきます。 こうしたことを考えながら、 自分たちの組織にとって組織のパフォーマンスが出ている状態というのはどのような状態なのかを定義し説明可能にしていく ことはとても重要なことだと考えています。なぜなら、それは長期的な組織マネジメントの土台になっていくからです。 *1 : 参考： 「sunaotに聞いてみた・後編 あえてCTOを名乗らない理由」 。 *2 : だから無意味だというのでなく、だから常にメンテナンスを怠らず面倒を見続ける必要があり、たゆまぬその活動には高い価値があるという話です。 *3 : デリバリーが重視される背景には、高いデリバリーの能力を持つことで結果的にマーケットに対する検証が高速に進み、それが次の価値を生む可能性を高めるという考えがあります。それ自体は否定していません。ただ、同時にドメインの視点も持ちながら考えていくことが良いと考えています。