ご機嫌麗しゅうございます。 @kimukei です。 これは 【前編】Visual Regression Testing の内製化への道 🚀 〜Chromaticから代替ツールへ〜 の後編にあたります。 ではさっそく、どうやって Chromatic から代替ツールへ移行していったかを紹介していきます。 コンテキスト カイポケリニューアルでは 577 個の Story, kaipoke-ui 1 は 63 個ほどの Story を有している VRT しているスナップショット数はカイポケリニューアルで 969 枚、kaipoke-ui で 139 枚程度 カイポケリニューアルでは比較的動きの多い Modal や yagisan-reports 2 を使用した PDF を表示する Story が多く存在する これは、そんなカイポケリニューアルの pull request に実行する CI で Storybook の配信から VRT の実行とテストレポートの発行と配信までを 5 分程度に収めた物語。 また、それまで VRT の仕組みは Chromatic を使っていたため、なるべく VRT の体験は Chromatic のそれを損なわないように工夫しました。 ここで行う VRT としての CI と Storybook の配信と VRT の結果レポートの配信としての CD についてワークフローで行う処理の流れは以下のようになります。 Storybook を build Baseline 3 の取得 Storybook の撮影 撮影した画像と Baseline との比較（VRT） VRT レポートを作成 Storybook と VRT レポートをデプロイ & 配信 VRT で差分が検出されたときはマージをブロックする CI/CD の実行環境は GitHub Actions です。 VRT は reg-viz/storycap と reg-viz/reg-cli を用いて実現しています。 そこで、実現する中でいくつか知見が溜まったので紹介していきます。 Storybook, VRT について CI/CD 最適化の知見 GitHub Actions ランナーとコスト最適化 GitHub Actions hosted runner と AWS CodeBuild hosted runner のコスト比較 large runner についてホストが GitHub Actions hosted runner と AWS CodeBuild hosted runner とでコスト比較すると、CodeBuild の方が安いことがわかります。 GitHub Actions hosted runner pricing: https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-actions/about-billing-for-github-actions#per-minute-rates-for-x64-powered-larger-runners AWS CodeBuild hosted runner pricing: https://aws.amazon.com/codebuild/pricing/ ※ GitHub Actions hosted runner は arm64 アーキテクチャだと安いのですが、今回 chrome や chromium と puppeteer を動かしつつ継続的にメンテナンスしていく都合上 arm64 アーキテクチャの runner の採用は見送っています 今回私が選定した runner は CPU のコア数が欲しくて CodeBuild(ap-northeast-1)の general1.xlarge （$0.1002/min） なのですが、近しい性能を出そうとすると GitHub Actions self hosted runner の Linux 32-core （$0.128/min）を選ぶことになります。 また、CodeBuild の runner はネットワーク上、S3 との通信が速いため Baseline の取得が早くなる利点などもありました。 ジョブ分割の落とし穴 VRT の時間的なネックはだいたい撮影にあります。枚数が多いのです。そこでよく sharding をして job を分割する手段が取られますが、この場合 job 分割のオーバーヘッドがなかなか無視できません。 具体的には以下のようなオーバーヘッドが乗ってきます。 runner の割り当て待ち 前の job で作られた生成物のダウンロード（前の job では生成物をアップロードするコストも発生します） runner の割り当て待ちについてですが、GitHub Actions では標準 runner ではないものを使うとしばしば pick されるまで遅い現象が発生しました。 CodeBuild では provisioning なども発生するため、だいたい job の最初の step が実行されるまで 30 秒程度かかってきました。 reg-viz/storycap には parallel オプションが、 reg-viz/reg-cli には concurrency オプションが提供されています。 そのためここではあえて job 分割を避けて large runner を用いてその中で大量に実行することでオーバーヘッドを極力なくしました。（そのために CPU コア数が欲しかった！） ちょうどこれくらい大きな Storybook だと、build した生成物も 50MB 強くらいの大きさで、GitHub Actions の標準 runner を使っていると動作が安定しないことなども起こっていましたが、CPU コア数が潤沢な runner を選ぶとだいたいそこそこ潤沢なメモリも付いてきます。これが撮影動作の安定化なども副産物的にもたらしてくれました。 ちなみに CodeBuild hosted runner を用いているとマシンリソースについてのメトリクスも同時に取れるので、最適な runner 探しも捗りました。GitHub Actions hosted runner でもメトリクスは見ようと思えば見れますが、見るためのスクリプトを入れたりなどが必要で「そういえば」とふと思った時に見られる準備をしていないことがほとんどです。 この辺はマシンスペックのチューニングと共に job と step のチューニングも同時に行うと良いでしょう。 ワークフロー全体のネック部分や pick 部分の可視化を行うのに Kesin11/actions-timeline がとても便利でした。設定や基盤が不要でワークフローに差し込むとすぐにこのような図が見られるようになります。 actions-timeline の図 まとめると、一見効率的に思えるジョブの分割ですが実際には 生成物のアップロード・ダウンロードに時間がかかる ジョブ間のリレーで待機時間が発生 ランナーの割り当て待ちが複数回発生 むしろ 1 つの大きなジョブで実行する方が、総合的なパイプライン実行時間が短くなることがあるということでした。 並列実行できる step をバシバシ並列実行させていく コマンドはこんな感じで並列実行できます。 jobs: parallel-commands: runs-on: ubuntu-latest steps: - name: Run commands in parallel run: | command1 & command2 & command3 & wait Baseline のダウンロードと Storybook の撮影は並列化可能でどちらも時間のかかる処理のため並列化したことで 1 分程度の短縮につながっています。 これも large runner のスペックがあるが故ですね。 配信基盤の選択とサイズ管理 Storybook と VRT レポートの配信について「どこ」に配信するかは重要な問題です。 よく使われるのは Amazon S3 でしょうか。今回は Private GitHub Pages を選択しています。 Private GitHub Pages の利点 AWS で認証付き配信基盤を構築するよりも、Private GitHub Pages を使用する方がセットアップが容易で管理コストも低くなります。 前提として、弊社ではエンジニアはほぼフルリモートで開発しています。 そのため何かを限定公開する際にはアクセスできるのは弊社の人間のみにする何かしらの仕組みが必要になります。 S3 では VPN の IP のみアクセス可能にするのがお手軽ですが、VPN 接続がめんどくさいという体験上のネックポイントが発生します。 組織の Google アカウントと連携した認証を用意するには工夫が必要です。 弊社の GitHub リポジトリは Google アカウントでの SAML 認証を必須化しているため、Private GitHub Pages で配信することで VPN 接続の煩わしさを解決しつつ同時にセキュアな限定配信を可能にしました。 ただし、GitHub Pages には制限があります。 アーティファクトのサイズ制限がシビア 同時デプロイリクエストに弱い（順次処理が基本） それぞれ次のセクションでどうやって対応したのか紹介します。 アーティファクトサイズ管理の重要性 GitHub Pages のデプロイは 特定のブランチ（ここでは gh-pages ブランチ）の内容を artifact 化し、アップロード アップロードした artifact を Pages にデプロイ という流れで行われます。 この artifact は 1GB 程度に収めておかないと deploy の失敗確率が上がったり、deploy に時間がかかるようになります。 GitHub Pages のパフォーマンスを維持するために、 VRT レポートから不要な画像（差分がないもの）を除去 変更がない場合はレポートを作成しない判断ロジックを導入 デプロイは可能な限りまとめて実行（同時リクエストの頻度を減らす） Pull Request の merge/close タイミングでの gh-pages ブランチの掃除 定期的な古いファイルの gh-pages ブランチの掃除 を行いました。 VRT レポートから不要な画像を除去できたり、変更がない場合はレポートを作成しないようにできたのは、フロントエンド部分を実装しているエンジニアにヒアリングしたところ PASSED の画像はほぼ見ていないとこがわかったためです。 PASSED の画像をレポートから除外することでフルだと 50MB くらいの容量のレポートが大抵 2~3MB になり 90％以上のサイズ削減が見込めます。 同時デプロイリクエストの制御 GitHub の Deployments はリクエストを排他的に処理します。つまり、実行中の Deployments があれば他の Deployments のリクエストは失敗します。 また、GitHub Pages の Build and deployment には「GitHub Actions」と「Deploy from a branch」の 2 種類のやり方があります。 前者は完全にこっちが deploy の面倒を見る設定で、後者がブランチが更新されたら自動で GitHub の方でデプロイしてくれるやり方です。 「Deploy from a branch」の設定は自動でやってくれるのは嬉しいのですが、ブランチの変更頻度が高いと同時実行性の点で難があります。 重複実行が回避されるように、実行中に新しい実行リクエストが来たら現在の実行をキャンセルし、新しい実行を始めるように設計されていて、この設定はいじれません。 そのため、ブランチの変更頻度が高い場合に実行リクエストが続々と来てしまうと常に最新のリクエストを処理しようとして最初のリクエストの変更が延々と Pages に反映されません。 これを避けるために前者の「GitHub Actions」で Pages デプロイする方法を取りました。 この方法ですと、ワークフロー内の concurrency 設定で同時実行された際の行動を制御できるようになります。 ここではデプロイのワークフローは他の実行によりキャンセルされないようにして、それぞれデプロイをやり切るようにしました。 その際、Deployments のリクエスト自体は排他的ですので、後続の Deployments リクエストは失敗する恐れがありますが、前のデプロイが終われば成功します。 そのため自動的に rerun できる仕組みを構築 4 し、artifact name はみな同一にしておいて last write win の状況を作り、upload artifact を行う job と deploy artifact を実行する job とを分け、deploy artifact を実行する job のみ rerun が行われるように組むことで順次デプロイは解消しつつ最終的には最新の artifact が Pages にデプロイされている状況を作り出しました。 VRT の最適化 これまで Chromatic を活用していたため、開発者のメンタルモデルには Chromatic の体験が根付いています。 今回 VRT の手法を Chromatic から移行させるにあたり、いかに Chromatic の体験に近づけていったか、それぞれポイントを紹介します。 storycap により生成される画像ファイル名と対象の Story の連携改善 Chromatic の体験として大きいのが、VRT で検知されたスナップショットで該当する Story のページへ即座に飛べることがあります。 この体験を移行するのに、 reg-viz/storycap で生成される画像ファイル名から Storybook の URL に変換できる関数を実装し、VRT レポートのサマリーを Pull Request にコメントすると共に変更を検知したスナップショットについてそれぞれ該当する Storybook のリンクをコメントと一緒に添えるようにしました。 例） GitHub Actions へのレポート reg-viz/reg-cli で生成した VRT レポート内に Storybook のリンクを配置するのは難しいですが、これならばそこまで体験を損ねずに VRT の結果と該当の Storybook への遷移がしやすくなります。 アニメーション対策とテスト安定性向上 VRT は flaky さとの戦いです。 VRT の安定性を高めるための施策をいくつか実施しました。 CSS アニメーションを無効化 JavaScript アニメーションを一時停止 タイミングに依存する要素の制御 最初の 2 つは DOM のテスティングでもよくやる推奨されるようなやり方ですし、紹介は割愛します。 タイミングに依存する要素の制御については、 parameters.screenshot.waitFor で頑張るのが良いのですが、構造上やむを得ないものは parameters.screenshot.delay でお茶を濁す感じになりました。 さらに、カイポケリニューアルでは複数のフォントを扱っているのですが、たまにフォント読み込みが終わっていないのに撮影されたために誤検出するケースもありました。 その問題については、すべてのフォント読み込みまで待つ util を実装しました 5 。 他にもスナップショットを安定させるためのあらゆる待ち条件を util 化し、各 Story で管理しやすくしました。 さらに、テストの不安定性（flaky）を検出するための仕組みも構築しました。具体的には、Baseline となる画像群（すでに S3 にアップロード済み）と、デフォルトブランチの最新コードから新たに生成した画像群を比較するワークフローを実装し、定期的（デイリー）かつ複数回実行することで、環境や実行タイミングによる差異を検出しています。 約 1000 枚のスナップショットを扱う規模では、単純な数の問題からも不安定性が生じやすくなります。このため、検出 → 対応 → 再確認のサイクルを地道に繰り返すことが信頼性向上のカギとなりました。特に flaky テストは確率的に発生するため、複数回の実行による検証は非常に重要です。 PDF のビジュアルテスト PDF 生成は yagisan-reports を使用しているのですが、PDF に対しても VRT を実施したいとなると何かしらの viewer が必要になります。 wojtekmaj/react-pdf を viewer に活用し、PDF の VRT を実現しています。 PDF は他のコンポーネントに比べるとレンダリングにやや時間がかかるため、撮影タイミングの制御は必須です。レンダリングを検知するための data-testid などを設定し、その要素の表示を待ってからスクリーンショットを撮影するようにしています。 VRT 判定基準の最適化 VRT における変更検知の閾値設定は、いわば「匠の塩加減」のようなものです。例えば Chromatic では diffThreshold のデフォルト値として .063 (6.3%) を採用しており、この閾値の決定には経験と試行錯誤が不可欠です。 https://www.chromatic.com/docs/threshold/ しかし、Chromatic の 6.3% をそのまま reg-viz/reg-cli に適用すると、検知感度に違いが生じ、偽陰性（変更があるのに検知されない）が増加する傾向がありました。 また、 reg-viz/reg-cli では、より詳細な閾値設定が可能になっています： -M, --matchingThreshold Matching threshold, ranges from 0 to 1. Smaller values make the comparison more sensitive. 0 by default. Specifically, you can set how much of a difference in the YIQ difference metric should be considered a different pixel. If there is a difference between pixels, it will be treated as "same pixel" if it is within this threshold. -T, --thresholdRate Rate threshold for detecting change. When the difference ratio of the image is larger than the set rate detects the change. Applied after matchingThreshold. 0 by default. -S, --thresholdPixel Pixel threshold for detecting change. When the difference pixel of the image is larger than the set pixel detects the change. This value takes precedence over thresholdRate. Applied after matchingThreshold. 0 by default. https://github.com/reg-viz/reg-cli?tab=readme-ov-file#options 様々なパラメータを試した結果、最終的に --matchingThreshold 0.011 --thresholdPixel 100 という値に落ち着きました。閾値調整の基本姿勢としては、まず 0 に近い値（高感度）から始め、偽陽性（変更と検出されたくないのに検知される）が目立つようであれば徐々に値を上げていく方法が効果的です。これは偽陰性の方が発見・対応が難しいためです。 また、開発者のメンタルモデルとして、画像差分を画面全体の割合で捉えるよりも、変更部分のピクセル数で判断することが多いと観察されたため、割合ベース（thresholdRate）ではなくピクセル数ベース（thresholdPixel）での検知手法を採用しました。大きな画面であっても、開発者は画面全体ではなく構成コンポーネント単位で変更を認識しているためです。 VRT の承認プロセスとマージブロックの連動 プルリクエストのマージ制御には、GitHub の Branch protection rule にある「Require status checks to pass before merging」機能が効果的です。これにより、ステータスチェックとマージ条件を連動できます。 ただし、VRT を実施するワークフローでマージブロックを直接制御しようとすると問題が生じます。承認プロセスという強制的に成功とみなす「裏口的な手法」がワークフロー自体に混入してしまい、全体の見通しが悪くなりメンテナンス性を損なう恐れがあります。そこで私たちは、マージブロック制御を別の仕組みとして実装しました。 具体的なアプローチは以下の通りです： VRT で差分検出時、プルリクエストに専用のラベルを付与 このラベルが存在する場合、ステータスを pending に設定 ラベルが外れた場合、ステータスを success に更新 このマージブロック制御には on.pull_request.types: [labeled, unlabeled] イベントを活用し、ラベルの付け外しという単純な操作で VRT の承認管理を実現しています。 また、開発者からのフィードバックを受け、VRT 承認待ち状態ではコミットステータスを「failure」ではなく「pending」に設定するよう改善しました。pending 状態はブラウザタブで以下のように表示され、対応状況が視覚的に把握しやすくなっています。 ステータスが失敗の見え方 ステータスがペンディングの見え方 これは最新のコミットに対する status を制御することで実現できます。GitHub の REST API（ Create a commit status ）を使って、VRT の承認状態に基づいて最新コミットのステータスを操作し、「Require status checks to pass before merging」で設定している job 名のコンテキストで付与することでブロック制御と両立させました。 この一連の処理フローは以下のとおりです： VRT で差分検出時、GitHub App のトークンを使用 6 してプルリクエストにマージブロック用ラベルを付与 このラベルが付いている場合、最新コミットのステータスを特定の job 名のコンテキストで pending に設定 VRT の変更を承認する場合、VRT 結果を案内するコメント内のチェックボックスにチェックを入れる（issue_comment.types: edited イベントが発火） コメント編集イベントをトリガーに、承認コメントであることを確認してマージブロック用ラベルを除去 ラベル削除により、最新コミットのステータスを job 名のコンテキストで success に更新 これでマージが可能になる この仕組みにより、意図しないビジュアル変更のマージを防止しつつ、意図的な変更は簡単な承認プロセスで対応できるワークフローを実現しました。 まとめ カイポケリニューアルのプルリクエストに対する CI 処理で、Storybook の配信から VRT の実行、テストレポートの配信までを 5 分程度に収めるために実施した主な最適化ポイントは以下の通りです： ランナー選定の最適化 ： AWS CodeBuild hosted runner の採用によりコスト効率を改善 適切なマシンスペックの選定により VRT のパフォーマンスを大幅に向上 ジョブ構成の最適化 ： 多数の小さなジョブへの分割ではなく、単一の大きなジョブ内での並列処理を選択 並列実行可能なステップを特定し、効率的な実行パイプラインを構築 配信基盤の効率化 ： Private GitHub Pages を活用した認証付き配信の簡素化 アーティファクトサイズの厳格な管理による安定したデプロイ デプロイメントリクエストの効率的な制御 VRT の開発者体験向上 ： Chromatic に近い使用感を再現し、移行コストを最小化 アニメーションなどの不安定要素に対する堅牢な対策 効果的な判定基準の設定による誤検出の最小化 直感的な承認プロセスとコミットステータスの連動 これらの最適化により、577 個の Story と 969 枚のスナップショットを扱う大規模 VRT プロセスを約 5 分で完了できるようになりました。この改善は開発サイクル全体の効率化に貢献し、開発者体験の向上にもつながっています。 また、この移行を通して VRT や Storybook を配信するのに支払っていた月々の支払いを 90% 近く削減できました。 内製している UI コンポーネント群。Chakra UI をベースに作っている。 ↩ PDF の生成に利用している帳票発行エンジン。 https://denkiyagi.jp/yagisan-reports/ ↩ VRT をする際の比較元となる main branch のスナップショットを事前に S3 にアップロードしています。 ↩ https://github.com/orgs/community/discussions/67654#discussioncomment-8038649 が参考になると思います ↩ FontFace API の loaded プロパティを活用し、プロジェクトで使用するすべてのフォントを列挙して、それぞれの loaded() の Promise が解決するまで待機する実装としました。参考: https://developer.mozilla.org/en-US/docs/Web/API/FontFace/loaded ↩ GitHub App のトークンを使用する理由はデフォルトトークンだとイベントが後続のワークフローにフックされない GitHub Actions の仕様のためです。 ↩

はじめまして、都内の大学でコンピュータサイエンスを専攻している小野です。インターネット上ではゆう猫( @yuneko1127 )と名乗っています。RubyKaigi 2025には、株式会社エス・エム・エスから学生支援を受けて参加しました。この記事では、RubyKaigiに学生が初めて参加した経験やRubyKaigi 2025の面白かったセッションなどについて紹介します。 rubykaigi.org 参加の経緯 自分は専攻として情報科学を学習しているものの、専門はコンピュータビジョンとヒューマンコンピュータインタラクションで、プログラミング言語処理やRubyに特に詳しいというわけでもなく、RubyKaigiにはひょんな理由から参加することになりました。 自分のプログラミングは高校生のときにTechnovation Girlsというアプリ開発コンテストに参加したことから、本格的に始まりました。コンテスト後もプログラミングやコンピュータのことを勉強するのが好きで、気付いたら情報科学科に進学していました。大学進学を機に、Technovation Girlsへ日本から参加する学生を支援しているNPO法人Waffleで運営インターンを始めました。そのSlackでWeb開発の勉強をしたいと呟いたら、カリキュラム・マネージャーをやっている鳥井さん( @yotii23 )からRailsなら教えられるよと言われ、RailsからRubyを触ることになりました。その勉強会をやる中で、鳥井さんからRubyKaigiの学生支援があるから是非とおすすめされ、参加しました。 自分はRubyがネイティブ言語というわけでも、Rubyでプロダクトコードを書いているわけでもないですが、Rubyistに誘われ、RubyKaigiに参加しました。 参加の前に RubyKaigiに参加できると決まってから、楽しみだなという気持ちと共に、自分が行って大丈夫なのだろうか、場違いなのではないだろうかという不安に襲われました。結論を言ってしまえば、これは杞憂だったのですが、これを杞憂にするためにやったことが少しだけあります。 一つ目は、スケジュールを見て(翻訳も見て)何個かこれは見て面白いだろうし、分かりそうだなというものを決めておくことです。自分は、Rubyの細かい仕様はわからないけど、オートマトンや正規表現など情報科学の学問的な話やメディア系の情報処理(今回話題の音を出す系)の話は分かるので、そのようなものを積極的に見るようにしていました。 二つ目は、過去のRubyKaigiを流し見することです。実際に過去のセッションを見てみると自分がどのくらいわからないのかの検討ができるようになり、ついでに知識もつきます。また、去年あの話をしていた人だ！と一方的に知っている人が増えます。自分は、RubyKaigiの荷物をまとめているときに、RubyKaigi 2024の@tompngさんのKeynoteを見て、今回のTRICKを心から楽しみにしていました。 www.youtube.com 面白かったセッションの話 ここからは、たくさんあるセッションの中で個人的に感動した、面白かったセッションの話を少しだけしたいと思います。 Make Parsers Compatible Using Automata Learning Day1のKeynote後のMain Roomのセッションです。Rubyには2種類のParserが実装されていて、それぞれの互換性を確認する方法が問題になっています。たくさんのプログラムをパースして、その差分を確認するなど量的に確認することもできますが、この発表では、パーサーの一部をオートマトンとして表現することによって、その差分を明らかにします。パーサーをオートマトンの表現に変換することは、オートマトン学習という手法を利用することによって可能になります。実際にパーサーの一部をオートマトン学習によってオートマトン表現に変換することによって、パーサー間にある互換性の問題を発見することもできているそうです。 この発表の個人的なぐっと来るポイントは、オートマトン学習などの情報科学のアカデミックな知見が、実際にRubyのパーサーのバグの発見や互換性の維持に利用されているというところです。このようにRubyへ貢献する方法もあるのかと感動しました。ちょうど今学期に受講しているプログラミング言語処理の科目の直前の授業で、正規表現と有限オートマトンの話を聞いていたので、あの知識がここで今まさに使われていると感動していました。 TRICK 2025: Episode I Day1最後に行われた、見たことがない奇妙なコードをたくさん見ることのできるセッションです。先ほど説明したように、自分はTRICKを非常に楽しみにしていました。それぞれのTRICKに関して何も説明できないですし、会場でもひたすらにこんなことまでできるのか！と驚いていました。興味深いとか役に立ったとかではなく、ただただ驚愕し、興奮するセッションでした。この後、自分も奇妙なコードを書いてみたいと思い、RubyKaigiが終わった後にTRICKの審査員であるmameさんの著作『 あなたの知らない超絶技巧プログラミングの世界 』をすぐに読み始め、あと残されているのは書くことだけです。 Ruby Committers and the World CRubyのCommitterがステージに上がり、Rubyについて話し合うセッションです。Rubyの仕様に詳しいわけではないので、内容がよくわかったわけではないですが、Rubyのような巨大なOSSがどのように維持運営されているかの一端を垣間見ることができて非常に興味深かったです。MatzのkeynoteでもあったようにRubyが公開されてから30年経っても、現状維持だけではなく、修正や更新されて、たくさんのコミッターがいることがRubyとそのコミュニティの豊かさを示しているなとしみじみしていました。それと同時に、この話をよくわかりたいと思い、Rubyの使い方だけではなく、Rubyがどのように作られているのかにも興味がわきました。 RubyKaigiはどういうものだったか RubyKaigiは、単にプログラミング言語Rubyの言語処理に関する会議、といってしまうことのできないような、多種多様で魅力的なカンファレンスでした。セッションだけでなく、After PartyやDrink up、企業ブースや廊下や街中での会話まですべてがRubyKaigiの体験を構成していて、また来たい！と思うような会議でした。 そして、RubyKaigiに参加して、一番喚起された感情はRubyをもっと書きたいという衝動です。自分はプログラミング言語にあまりこだわりがないのですが、Rubyを手に馴染ませて、最初に手に取る言語にしたいと思うようになりました。そしてこのRubyKaigiから、何かしらの形でRubyのコミュニティに関わっていきたい、そして貢献したいと思いました。 松山、ありがとうございました。RubyKaigi 2026、函館でまた会いましょう！ 『世界の霧』というアプリで記録されている松山市での移動履歴

はじめに こんにちは、カイポケのリニューアルプロジェクトを担当しているエンジニアの田所( @ikuma-t )です。昨年10月に入社し、現在は請求関連の機能の開発を行っています。 カイポケが価値を提供する介護業界について、日常的には馴染みがないという方も多いかもしれません。私も入社以前は後期高齢社会における社会課題の1つであると漠然と認識している程度で、介護業界の制度についてはあまり詳しくありませんでした。「介護業界については未経験でも大丈夫」という言葉を信じ、この会社に入社しました。 今回は私のように未経験から介護業界へチャレンジするメンバーを支える、介護業界理解のためのワークショップ研修について紹介します。この記事では実際に介護業界に触れてみて感じた介護業界の難しさを踏まえた上で、研修ではどのようなことを得られるのか、また実際に研修を経てプロジェクトに参画してみての感想をお伝えします。 介護業界の難しさは細部の複雑さにある 制度自体の入り口はそこまで難しくない 約半年という期間ではありますが、介護業界に向き合って感じたのは「制度自体の入り口はそこまで難しくない」ということです。 介護予防・日常生活支援総合事業のサービス利用の流れ | 介護保険の解説 | 介護事業所・生活関連情報検索「介護サービス情報公表システム」 より 引用は厚生労働省の介護サービス利用までの流れです。「要介護1」であったり、「介護予防事業」などの見慣れない単語はあるかもしれませんが、利用者が介護を受けるまでのフローは（図自体が簡略化されているということもありますが）意外とシンプルです。 利用者が市区町村の役所に相談 利用者の情報を入力に、介護度（どの程度の介護を必要とするか）を出力する 介護度に応じた介護の計画を立てる 計画に基づいた介護サービスを受ける 自身の周囲に実際に介護を受けている/提供している方がいなくても、なんとなくお手持ちの健康保険証や、普段ニュースで見かける話題から、ぼんやりと大まかな流れを想像できるのではないでしょうか。 多様な環境に対応するために複雑にならざるを得ない 一方で実際に開発を進めていくとなると、当然先ほど示したフローチャートの範囲の知識だけではすべてを賄うことはできません。「おおよそのケースではこのフローに則るが、一部外れるケースもありうる」ということがよくあります。 制度は実際に介護を提供するためにあるものですが、その介護の形は人によってさまざまです。要介護者の症状や、要介護者のまわりの家族のあり方の変化、介護サービスを提供する行政の財政状況など複数の要因が絡み合い、それらに合わせて制度のあり方は変化しています。 このことは介護保険法の変遷や、今も3年に一度法改正が行われていることからもみて取れるでしょう。 また介護業界にあまり馴染みのない人にとっては、例外的なケースは制度以前にそれが必要となる状況自体を想像するのが難しく、余計に難易度が高く感じられると思います。 メンタルモデルをうまく構築することで早く理解できるようになる 新しい概念を自分のものにするための方法にはさまざまなアプローチがありますが、その一つに「メンタルモデルの構築」があります。以下はプログラミングの文脈で書かれたメンタルモデルについての記事からの引用です。メンタルモデルの定義について書かれた内容ではありませんが、メンタルモデルを成熟させることの意味が書かれているため引用させていただきました。 未知の概念を使えるようにするには、その概念についてイメージを頭に思い浮かべられるようにする必要があります。ここで浮かべるイメージをその概念の「メンタルモデル」と言うことにしましょう。僕らはより高度な概念を理解するためにそのメンタルモデルを思い浮かべながら文章を追いかけます。もしメンタルモデルと文章に矛盾が発生したらメンタルモデルを修正します。そうして矛盾が発生するごとに今までの事象を全てうまく説明できるように修正していき、メンタルモデルの完成度を高めていくのです。 はじめに #Haskell - Qiita 理解の基礎となるメンタルモデルを築くことにより、そことの類似性や差分から新しい概念を早く理解できるようになります。 介護業界の理解においても、例外的なケースと大枠のフローをひとくくりに摂取しようとすると、その情報量に圧倒されるか、あるいは1つ1つの情報の咀嚼に時間がかかってしまいます。そのためはじめの段階でしっかりとしたメンタルモデルを構築することが、介護業界理解の鍵となります。 ワークショップ型研修でメンタルモデルを構築する 介護業界理解のため、中途入社者向けにワークショップ型の研修が実施されています。 オフィスに集まり、1日かけてドメインエキスパートの方と介護業界についての理解を深めていきます。 東京タワーが見える会議室で1日学びます。 介護業界を、考えて、書いて、理解する ワークショップの中では講義パートとグループワークのパートがあり、グループワークのパートでは与えられたテーマを元に、介護業界について考えるという内容です。 ワークショップで扱うテーマは複数ありますが、一例として以下の内容に取り組みます。 チームでアウトプットすることで曖昧な知識に気がつくことができる テーマについて、まずは何も調べずに自分たちがすでに知っていることを元に仮説を話し合い、その後ネットで調べた情報やドメインエキスパートの方との会話を元に、介護を受けるためのフローを書き起こしていきます。 自分たちで手を動かしながら考えるため、単純に同じ量を座学で理解するよりもたくさんの気付きを得られるのがワークショップ型研修の良いところです。 この記事の冒頭に掲載したようなフローチャートを座学で学習する場合、ざっと見て「なんとなくこういう感じなのだな」と理解を止めてしまうことも多いでしょう。一方グループワークではチームに向けて自分の認識を共有しながらアウトプットしていく必要があるため、曖昧な部分を素通りすることはできません。 実際にワークショップを体験した際にも、「介護受けたいなら、たぶん最初は役所行っとく...よね？」といった会話からはじまり、なんとなく知っているけど、説明できない部分を1つ1つ明らかにすることで理解を深めていきました。 実際にグループで考えたフロー図 実際に介護の現場で長年働いてきたドメインエキスパートと一緒に学ぶ このワークショップ型の研修の講師役は、実際に介護の現場で長年働いてきたドメインエキスパートの方たちです。 実際に自分たちでテーマに対して調べていくと色々と細かいところが気になってくるのですが、その際にはドメインエキスパートの方に気軽に質問してその場で疑問を解消することができました。 ドメインエキスパートの方は研修のときだけでなく、実際のプロジェクトでもお世話になっており *1 、わからないことがあればSlackで気軽に確認したり、新しいエピックの開始時には、そのドメインの勉強会を実施いただいたりしています。 「ドメインエキスパートに気軽に質問できる環境」といっても、ほぼリモートかつ初対面だとなかなか質問しづらいものです。入社してすぐにドメインエキスパートの方と対面でコミュニケーションを取れる機会があることで、以降の開発時のコミュニケーションにおける安心感が違うと個人的には感じています。 実際に研修を受けてからプロジェクトに配属されてみて 実際に入社時研修を終えてプロジェクトに配属された際、当時チームが開発していた内容が研修に出てこないものだったため、（研修の理解度はばっちりだと思っていたこともあり）非常に焦った記憶があります。 ただしっかりと向き合ってみると、研修で培ったメンタルモデルをベースに、どの介護のパターンで、どこの業務で使うものかをスッと理解することができ、チームの開発にもスムーズに合流することができました。 *2 おわりに この後期高齢社会において介護業界に向き合うことは社会的意義のあることで、私もそこに共感して弊社に入社しました。 一方でエンジニアとして介護業界に向きあうことの魅力はそれだけではなく、この広く深い制度をどう理解し、保守性の高い実装に落とし込んでいくかを考える部分にもあると考えています。 今回はその理解を深めるための取り組みの1つとして、業界理解のためのワークショップ研修をご紹介しました。この記事の内容が介護業界に興味はあるけど、業界知識の不足に対して不安に思われている方の参考になれば嬉しいです！ カイポケ組織におけるドメイン知識の向き合い方について、以下の記事でも触れられているのでご覧いただければと思います。 tech.bm-sms.co.jp *1 : このブログ記事を書く際にもお世話になっています。 *2 : 開発チームやオンボーディングのメンター、ドメインエキスパートなど、気軽に聞ける環境があるということも寄与しています。

こんにちは、介護/障害福祉事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトでモニタリングやオブザーバビリティ周りを担当している加我 ( @TAKA_0411 ) です。 4/11に開催されたPHPカンファレンス小田原 (以下ぺちおだ) 2025の前夜祭にて「推しのコミュニティはなんぼあってもいい」というタイトルで5分LTをしてきました。本記事ではLTの内容に触れつつ、以下の観点でまとめます。 このテーマを選んだ理由 登壇後の反響 私がぺちおだに参加する理由 PHPカンファレンス小田原2025 イベント公式サイト phpcon-odawara.jp PHPカンファレンス小田原2025 前夜祭 phpcon-odawara.connpass.com 登壇スライド speakerdeck.com このテーマを選んだ理由 YAPC::Hiroshima 2024にてそーだいさん ( @soudai1025 ) が「自分の好きな技術領域やそのコミュニティにいても良いし、興味のある技術的に近い隣のコミュニティに参加するのも良い」という話をしていたのが印象的で、自分の体験も交えて発表したいと考えたのがきっかけです。 www.youtube.com 私は最近、主にJAWS-UGのイベントで運営・登壇・参加していますが、JAWS-UGとPHPコミュニティの距離は遠くないと感じています。「技術的に近い隣のコミュニティに参加すること」の意義を発信するにはぺちおだは最適な場だと思い登壇を決めました。 発表内容を考える中で、PHPカンファレンス北海道2024にAWS界隈の知人を誘ったエピソードが思い浮かびました。 知人は「PHPの話はあまり理解できなかったが、開発に役立つ一般的な知識を学び、自分の独学の答え合わせができた。何よりPHPコミュニティの人と話せて楽しかった」と言ってくれました。これこそ「興味のある隣のコミュニティに参加する」ことの価値だと実感し、複数のコミュニティに参加するメリットや、参加者が楽しめる要素について考えた結果が今回の発表スライドです。 今回のぺちおだ2025には札幌在住のAWS界隈の知人3名を誘い、4人で参加しました。全員PHPには詳しくなく主にAWSを扱っています。彼らにも参加後の感想をブログに書いてもらう予定で、私の仮説がどうだったかを楽しみにしています。 私自身、今はオブザーバビリティ領域に強い関心がありますが、AWSコミュニティやPHPコミュニティ、最近だとSREコミュニティを経て得られた学びを通じて「自分はオブザーバビリティに興味がある」と気づきました。AWSだけに詳しくてもWebアプリケーションのことが分からなければサービスの問題解決はできません。Production ReadyなWebアプリケーションを開発するスキルがない自分が「動いているWebアプリケーションで何が起きているのか、問題解決のための技術や考え方を学ぼう」と思えたのは、複数のコミュニティに参加したからこそ得られた気づきです。 登壇後の反響 LT登壇後に「実は私もJAWS-UGに参加してみたいと思っていて…」という相談を受けとても嬉しく思いました。あるJAWS-UGイベントへの参加を迷っているとのことでしたが、私は現地参加できずフォローが難しい状況でした。そこで、技術的なバックグラウンドが近い知人やコミュニケーション力のある知人を紹介しつつまずは参加してみてほしいと伝えたところ、当日のX（旧Twitter）で楽しんでいる様子が伝わってきました。勉強会後の懇親会にも参加し楽しんでもらえたようで、背中を押した身としても嬉しい限りです。 私自身がイベントを楽しむのも大切ですが、「技術的に近い隣のコミュニティ」の人の参加を支援したり、初参加の人と運営をつなげたりすることも最近の楽しみの一つになりつつあります。これはYAPC::Hiroshima 2024でそーだいさんのスライドにあった「次の人に水の場所を教えてあげる」にも通じるかもしれません。 私がぺちおだに参加する理由 私が関わっているカイポケのリニューアルプロジェクトはPHP以外の言語で開発されており、私自身も現在PHPを積極的に書いているわけではありません。過去にPHPを使ったプロジェクトに携わったことはありますが、それも今では昔の話です。 それでも昨年に続き今年もぺちおだに参加した理由は、「PHPコミュニティの居心地の良さ」と「ぺちおだの圧倒的なホスピタリティ」にあります。 PHPコミュニティの居心地が良い 今でこそ色々な技術コミュニティに参加している私ですが、私が初めて参加した技術コミュニティはJAWS-UG（AWS User Group – Japan）のJAWS DAYS 2014で、その次がPHPカンファレンス2015でした。特にPHPカンファレンス2015では初参加にもかかわらずスタッフに応募し、多くのPHPエンジニアの先輩や友人ができました。 一昨年まではカンファレンス運営スタッフとしても積極的に参加していましたが、地元北海道へのUターンを機に参加できなくなったコミュニティも増えました。PHPコミュニティもその一つです。そんな状況でのぺちおだ2025参加には不安もありましたが、PHPコミュニティの皆さんは温かく迎えてくれました。こうした居心地の良さがあるため、日程が合えばまた参加したいと思えるのが私にとってのPHPコミュニティです。 ぺちおだの圧倒的なホスピタリティ ぺちおだでは参加者が楽しめるような仕組みがいくつもあります。昨年のぺちおだ2024では前夜祭にIRT (Interactive Round Table) が行われ、本編参加前に参加者同士で交流を深めることができました。 PHPカンファレンス福岡2023での体験が色濃いのですが、全然野菜・前夜祭があったことで、みんなと仲良くなれた体験、あの設計の素晴らしさを小田原でも再現したかったため、公式で前夜祭を企画しました。 コミュニケーションに重きをおきたいため、IRTを行い、そのあとはみんなで飲みました🍺 asumikam.com 参考 : IRT: Interactive Round Table を実施します blog.phperkaigi.jp 去年に引き続き行われた「1分間フィードバック」に加え、今年は参加者の交流を深めるための新たな取り組みとして「ぺちおだ大合戦」が実施されました。 前夜祭 6人程度で1つのテーブルを囲み、乾杯と自己紹介（テーマは事前に運営から提示）が行われました。ドリンク片手に小田原の美味しいピザを食べながら談笑し、その後セッションとLTが始まります。ぺちおだ2025では「1分間フィードバック」という仕組みがあり、登壇者の発表後に1分間で付箋にフィードバックを書き、ホワイトボードに貼るというものでした。会期後のアンケートよりも気軽にフィードバックでき、印象が新鮮なうちに意見を伝えられる良い取り組みだと感じました。 付箋によるフィードバック 当日 一通りセッションとLTを聴き終わった夕方からは3人1組の「ぺちおだ大合戦」というチーム戦があり、参加者同士で大いに盛り上がりました。 ぺちおだでは、参加者同士のコミュニケーションを大切な軸の一つとしています。それを体現するコンテンツとして、参加者同士でランダムなチームを組んで競い合う、チーム対抗バトルを開催しました⚔️ note.com note.com ぺちおだ大合戦は春の陣・夏の陣・秋の陣・冬の陣の4つに分かれています。 春の陣：スポンサーブース巡り 夏の陣：PHPの関数をテーマにしたゲーム 秋の陣：PHPやWeb、小田原に関するペーパーテスト 冬の陣：HTTPステータスコード百人一首 各陣にはチートシートやドキュメント、公式noteに散りばめられたヒントもあり、多くの参加者が迷わず楽しめたと思います。特に冬の陣のHTTPステータスコード百人一首は、PHPに馴染みのない私や知人も問題なく参加でき盛り上がることができました。読み上げられたステータスコードに対して「これは自信があった！」とか「一度も使ったことがない」などの短い感想戦が繰り広げられていたのが印象深いです。 まとめ PHPカンファレンス小田原2025にて技術コミュニティについて考え発表してきた話でした。私はここ数年でそこそこ登壇するようになったのですが、5分のLTは人生初でした。資料作成にも発表の時間調整にも苦労しましたが、多くの方からポジティブな反響を頂けたので苦労の甲斐がありました。次はJAWS-UGにてPHPコミュニティに参加してみようという逆側の発表を画策しています。 私の主観ですが、ぺちおだは「学び」だけでなく、参加者同士の交流やイベント自体を楽しむことを重視しているカンファレンスだと感じます。現在、業務でPHPを使っていない私のような人でも参加しやすく、随所に楽しめる工夫が凝らされていました。コミュニティ運営に携わる身としても多くの学びがありました。改めましてぺちおだに関わる全てのみなさま、ありがとうございました & お疲れ様でした。 最後に一膳飯屋 八起さん (ぺちおだ会場のお隣) で食べた「小田原”鯵の鍋焼きご飯”」 がはちゃめちゃに美味しかったので置いておきます。 美味すぎワロタ #phpcon_odawara pic.twitter.com/Tg2AOJKAWS — しめじ/Kaga (@TAKA_0411) 2025年4月13日

皆さんはじめまして。 慶應義塾大学の中村颯といいます。 X(Twitter)ではみゅーら( @lit_myura )でやってるのでもしよければお話しましょう...! 僕は元々中学の時にプログラミング塾に通っていて、そこで出会ったのがRubyでした。そこから早8年位経って、今では元々通っていたところで僕がRubyを教えています。 そんな中で教え子たちのレベルがどんどん上がる中、僕が最新情報をキャッチアップしないで何が出来るのかと思っていたところ、RubyKaigi2025を見つけました。 今回僕はエス・エム・エスさんの学生支援を受けて、人生で初めてRubyKaigiに参加しました。実はテックカンファレンスへの参加自体が初めてであり、四国を訪れるのも初めてです。とても緊張しました。 今回はそのレポートとなります。 もしよければ最後まで読んでもらえると幸いです。 RubyKaigiに参加してみて まず、何よりも本当に楽しい3日間でした。正直なところ、内容の8割ほどは理解が及ばず、自分の力や知識では分からないことだらけでしたが、それでも十分すぎるほどの刺激がありました。 特に、会場ではブースにいる時間が長く、セッションを聞くよりも1対1でお話できる時間が多かったのもあって、わからないことも含めてじっくり対話できたのがとても良かったです。そして、やっぱり改めて感じたのは「みんな、本当にRubyが好きなんだな」ということ。 趣味でRubyを使用しているという方も多く「仕事では使わないけど、自分でなにか作るならRubyを触る」なんて声も聞きました。そのように愛されているプログラム言語が日本で生まれたRubyであること、それが自分にとっても大切な言語であることは本当に純粋に嬉しいなと思いました。 あと全体的にノベルティのセンスが本当に良くて終始テンションが上っていました。 御朱印帳とか、今治産のタオルとか。これからも使い続ける事になりそうなものばかりで思い出の数々です。 ↑個人的には砥部焼にワクワクしちゃいました。 Rubyに対する意識 僕自身もともとRubyへの愛着はありましたが、今回のRubyKaigiを通して改めて「Rubyを使えばなんでもできる状態」に自分を持っていきたいという気持ちが強くなりました。 先程も記載した通り、セッションの多くは理解するのが厳しかったです。 ただ、それ以上に登壇者たちが本当に楽しそうに、情熱を持って話している姿が印象的でした。内容が完全に理解できなくても「この人の話は面白そうだな」と思わせる力がありました。特にDAY1冒頭のima1zumiさんのセッションでは、文字コードに対する「好き」が伝わってきて、RubyKaigiへの期待が爆上がりしちゃいました。 そして、DAY1最後に行われた「TRICK 2025: Episode I」では、今まで自分が見てこなかったようなタイプのコーディングを目にしました。自分はこれまでRubyを「Webサービスを作るためのバックエンド言語」として扱ってきて、その目的のために効率や完成度、スピード、そしてユーザビリティを重視することが当たり前だと考えていました。だからこそ、最近ではAIを使ってコーディングすることも増え、何より「完成品」に価値があると思い込んでいた節があります。 しかし「TRICK 2025: Episode I」の場では、コードそのものを楽しむ人たちの姿がありました。誰かの役に立つコードではなく、自分の工夫や遊び心が詰まったコードを披露し合う様子を見て「ああ、自分で書くっていう行為自体にも、楽しさってあったよな」と思い出しました。 そんな経験から「自分が心から楽しめる、自分にとっての絶対的な言語」があるって、すごく素敵なことなんだと感じました。もちろんサービスを作ることや、複数の言語を使いこなすことも大切ですが、「ものづくりの過程そのもの」を楽しめるかどうかで、その人の意識や取り組み方って大きく変わってくるんだなと改めて実感しました。 もちろん処理速度や適材適所の選択はあると思いますが、どんなものでもRubyでつくれる自分でありたいし、Rubyを通じて楽しさを感じ続けたいと思っています。普段はWebサービスの開発などでしかRubyに触れない僕ですが、それ以外の部分にも触れてみようって思うきっかけになりました。PicoRubyとかの話も面白かったので、組み込み型のRubyとかから挑戦してみるつもりです。まずはいわゆるLチカからはじめてみます。 また、JITによる高速化の取り組みなども含めて、Rubyを進化させようと本気で取り組んでいる方が多くて、その熱量がすごいと感じました。でもそれが、何かに追われているような雰囲気ではなく、「自分が楽しいからやってる」という雰囲気なのが印象的でした。それぞれが自分のやりたいことを自由にやっていて、それがちゃんとRubyの未来につながっているというのは本当に素晴らしいなと思います。 その中で、あれだけあたたかく話しかけてくれる人たちがいるRubyコミュニティに、これからも関わっていきたいと思いました。 地域.rbなども含めて、今後もいろんな形で参加したいと思っています(東京近郊でおすすめの場所があれば教えて下さい)。 まとめ RubyKaigi2025を通じてこのような場所にいられること自体が幸せで、このコミュニティの一員になっていきたい、と思えるような時間でした。 今の僕はまだRubyをシンプルな使い方しかできていません。でも、これからもっと深く学んでいけば、見えるものも話せることも増えていくはず。今以上にRubyが楽しくなる未来が待っている、そんな希望が持てた3日間でした。 また、海外の参加者の多さにも驚きました。規模が本当に大きくて「このサイズが初めてのテックカンファレンス」というのは贅沢だったなと…。自分が興味ある分野で、生の英語や世界中の人の声を直接聞けるというのは本当に貴重な機会だったと思います。 しかし、個人的な反省点が1つだけあります。名刺を持っていかなかったのは、かなりもったいなかったです。もっと交流できるチャンスがあったのに…と少し悔しい気持ちもあります。次回はしっかり準備して、もっといろんな方とつながれるようにしたいです。 本やサイン会などを通して、近い距離感で学べる空気感も素敵でした。それぞれが違う視点で世界を見ているのに、目指している先は同じ。動き方は違っても、みんながRubyの未来を見て行動している。そういう姿にたくさん出会えたことが、何よりの収穫でした。 改めて、助けてくださった皆さん、お話ししてくださった皆さん、本当にありがとうございました。 また、支援してくださったエス・エム・エスさんにも改めて感謝申し上げます。 最高のRubyKaigiでした。 次のRubyKaigiやKaigi on Rails、そして他のRubyコミュニティでも、また皆さんとお会いできるのを楽しみにしています！

合同会社 makigai（マキガイ） の貝瀬です。2024年6月からスクラムマスターとして、介護/障害福祉事業者向け経営支援サービス「カイポケ」に関わる組織やプロセスの改善を支援しています。 カイポケリニューアルプロジェクトでは、LeSS（Large Scale Scrum：大規模スクラム）を導入しています。本記事では2025年1月に実施した座談会の残りの部分（Part3）をご紹介します。 Part1、Part2については以下の記事をご参照ください。 tech.bm-sms.co.jp tech.bm-sms.co.jp 人物紹介 キム ダソム（以下、キムPO） エリアプロダクトオーナー 田村恵（以下、田村PO） エリアプロダクトオーナー 原野誉大（以下、原野EN） エンジニア 伊達大晃（以下、伊達EN） エンジニア 福田尚亮 スクラムマスター兼ファシリテーター 貝瀬岳志 全体のスクラムマスター兼本記事の執筆者 組織のアジリティ向上を目指したチーム再編 —— 12 月はクロスファンクショナルチーム(注: プロダクト開発に必要なスキルを保有している、または習得できるチーム)を目指すため、キムさん、原野さんの組織で既存の複数チームをフロントエンドとバックエンド混成になるように再編成したタイミングだったかと思います。まずは、当時の懸念について教えてください 原野EN：私のチームでは既に11月の時点で、フロントエンドエンジニアがバックエンドも担当することになっていました。それは当初の期待通り、やりやすくなったかなと思います。一方、再編成後の新チームでは、複数の文化を持ったチームメンバーが混ざりあうので変化がより大きく、難しい点が出てくるだろうなと思っていました。 キムPO：中長期的な視点では、自律的なクロスファンクショナルチームを作っていくのは実現したいことでしたが、原野さんと同様に、文化の違う2チームが1チームになる時に文化の違いや開発の進め方の違いがどうなるのかが気になっていました。今思えば構造的な問題が原因ですが、チーム再編前はバックエンド開発を先行し、その後別のスプリントでフロントエンド開発が追従するといった進め方を取っていたので、混成チームになったときの具体的な進め方がイメージできませんでした。議論しながら進め方を決めていくなどのチームビルディング期間が必要になると思っていたのですが、当時は大きなリリースを控えていた時期なので、一時的に起こるであろうスピード低下をどのように取り戻していくのかが気がかりでした。そういった中での再編成は、本当に大きなチャレンジだったと思います。 —— うまくいった時のリターンに期待しつつも、大きなリリースの直前に体制を変えていくことによるリスクも大きかったですよね。1 月現在も、「 Done の定義 」の再定義など、新チームでのチームビルディングを実施している最中ではありますが、現時点で見えているチーム再編成の効果についても聞かせてください キムPO：再編後に、混合グループによる複数チームプロダクトバックログリファインメントを実施したことによって、未来への不確実性が一定下げられた実感があります。クロスファンクショナルなフィーチャーチームを目指す過程の中で、当面のプロダクトバックログアイテムに対する全員の解像度を底上げできたことが良かったと思っています。全体に目を向けた影響で、とあるプロダクトバックログアイテムの開発を田村さん・伊達さんたちの組織と分担して進めるきっかけにできたことも大きかったです。 また、うまく行かないことが出てきたときに、元のフロントエンドとバックエンドで別れたチームに戻すという話ではなく、新チームの中で解決すべき課題と捉えている状況も良い点かなと思っています。例えば、フロントエンドの開発タスクが多いという事実に対して、チーム全体のスキルアップを課題として捉え、バックエンドエンジニアがフロントエンドの実装にチャレンジできるような戦略をチーム自身が議論して実行に移しています。実際既に、バックエンドエンジニアがフロントエンドタスクを消化できるようになっているという成果もでているので、チャレンジして良かったなと思っています。 原野EN：もう少し広い範囲で振り返って見ると、LeSSの導入から毎月のように大きな変化が起こり続けていたかなと思っています。スプリントが2週間なので、2スプリント経過して変化に慣れてきた頃に、また大きな変化が起きて、みたいな。ただ、この4か月でプロセスや組織を変化させていくこと自体に慣れてきて、アジリティの高いチームになってきた実感があります。1つ1つの大きな変化はキムさんが中心となって推し進めていたわけですが、うまくいかない可能性も大きい中で、どんどん進めていくところはすごいなと思いながら見ていました。変化に追従するチームも大変ですが、変化を働きかける方はもっと大変だろうなと感じます。 キムPO：ありがとうございます。一方、どんどん変化している状況の中で、各取り組みに対する評価が曖昧になっている点を課題として感じています。最終的にはチームの安定化を目指したいと思っていますが、直近ではプロダクトロードマップに関連する計画と実績の差分、各スプリントにおけるベロシティなどが見るべき指標になるのかなと思っています。 原野EN：話をしていて、この座談会自体が1つ1つの変化に対する見直しのきっかけになっていることに気づきました。 —— 組織の適応性は、 LeSS フレームワーク の中でも重要なポイントとしてあげられていますね。スクラムマスターとして支援に入ってから、変化に対してどう適応していくのかという議論が各所で建設的になされていたことが印象的で、組織としての重要な価値観に通じるところなんだろうなと感じています 将来の展望 —— 最後に、組織やチームに対する今後の期待について一人ずつ聞かせてください 伊達EN：私の組織では、既にバックエンドやフロントエンドなどの技術領域での役割分担が減ってきている実感があります。その先は技術領域というか、プロダクトディスカバリーや品質保証など、エンジニア以外の職種に頼っている領域にも広げて行きたいです。完成の定義を拡張して、価値提供に必要なことはスプリント内で何でもできるような、問題解決力の高いチームになっていけるといいなと思っています。 田村PO：私の組織ではクロスファンクショナルなチーム分割をしたばかりですが、今後はプロダクトマネージャーやプロダクトオーナーが担っている業務、具体的にはプロダクトバックログアイテムの作成などもチームの誰もが担当できる状態にしていけると良いなと思っています。 原野EN：新しいメンバーがチームにジョインしたり、新たなチームが作られたりすることが今後もあると思うので、そこで起こりうる課題に対しても、うまく乗り越えていきたいと思っています。クロスファンクショナルなチームにはなってきましたが、組織全体としてドメインカットでチームが作られているので、そのあたりを解消していくことが今後の課題かなと思っています。あらゆるチームがあらゆるドメインを対応できるような変化が起こると思っているので、その変化に期待しています。 キムPO：私のプロダクトは今後2〜3年後を見据えた時に、まだまだ拡充すべき機能・サービスが控えているので、今よりメンバーが増えていくはずです。現在はクロスファンクショルチームで開発を進めていく過渡期かとは思いますが、メンバーが増えたときに個々のチームを安定させた状態で、どのようにスケールアウトしていくかが次の課題になっていくだろうなと思っています。今できることは引き続きやっていきながら、未来の視点も入れながら、準備を進めていきたいと思ってます。 —— クロスファンクショナルなフィーチャーチームを進める過程で、どんな領域でも学習しながら進めていけるチームになっているので、結果として組織全体のアジリティが向上していくんだろうなと思っています。スクラムマスター一同としても、皆さんの期待を実現できるように、引き続き支援させていただきます。座談会に参加いただきありがとうございました まとめ 計3回に渡って紹介してきたLeSS座談会では、以下のようなトピックを扱いました。 Part1：LeSSの導入から初月まで LeSS導入時の印象や期待 LeSS導入後初月に起きた変化 Part2：LeSS導入後に起きた役割と組織構造の変化 チームの自律性向上のための役割廃止 コンポーネントチームからクロスファンクショナルチームへ Part3：変化を続ける組織と将来の展望 組織のアジリティ向上を目指したチーム再編 将来の展望 短い間にLeSSの導入・プロジェクトリードという役割の廃止・クロスファンクショナルチーム/フィーチャーチームへの再編、といった大きな変化が起こり続けましたが、プロダクト開発の当事者自らが主体となって考え、実行してきたことが伝わったのではないでしょうか。 他方、スクラムマスターやマネージャーは、LeSS導入における 3 つの原則 などを念頭において、当事者への強制は避け、観点を広げるための働きかけや、当事者が必要とする支援を行うよう努めています。LeSSは日本国内においての事例が少ないので、導入を検討している組織の参考になれば幸いです。

こんにちは！カイポケリニューアルの開発推進チームでエンジニアをしている @_kimuson です。 フロントエンド開発において視覚的リグレッションテスト（Visual Regression Testing、以下 VRT）は欠かせない存在です。 私たちのチームでは長らく Chromatic を活用してきましたが、プロジェクトの成長に伴い、よりスケーラブルでコスト効率の高いソリューションを模索する必要が出てきました。 本記事は 2 部構成の前編として、内製化の決断に至った背景と代替ツールの検討過程を紹介します。 後編では実際の実装プロセスと移行作業の詳細に焦点を当てる予定です。 内製化の決断 🤔 Chromatic の利点 Chromatic は Storybook をベースにした VRT を提供する SaaS です。 簡単なセットアップで優れた開発者体験と直感的なインターフェースを提供しています。 私たちのチームが特に価値を感じていた点は以下の通りです： 最小限のセットアップのみで Storybook をベースにした VRT を動かすことができる VRT のしきい値も効果的に設定されており、特にチューニングせずとも Flaky（不安定な）テストを最小限に抑えられている わかりやすい差分の表示と、Story 単位での変更承認/拒否の柔軟なワークフロー VRT により、安全にフロントエンドを編集できる点 コードレビューの際に変更によって UI がどう変更されるのかが自動でわかる開発者体験 VRT に加えて Storybook がホスティングされ、非エンジニアに再現の難しい状態の UI を共有できる点 Chromatic に大いに助けられてきましたが、プロジェクトの規模拡大に伴い課題も見えてきました。 内製化を検討するきっかけ 💰 最大の課題はコストでした。 我々のチームではスナップショットの総数が月あたり約 13 万スナップショットずつ増加しており、検証開始の時点で合計約 70 万スナップショットに達していました。 Chromatic の課金形態はスナップショット数に対する従量課金であり、スナップショットに対して線形に金額が増えていきます。プロジェクト規模に適したコスト構造を考え、内製化を検討するに至りました。 月辺り 13 万スナップショット増加していることからもわかるように、フロントエンドのコードベースと機能拡大に伴って、この費用は今後も増加が予想されます。 そこで、Chromatic の優れた開発体験をできる限り維持しながら、よりコスト効率の高い代替手段を探ることにしました。 代替ツールの検討 🔍 内製化にあたって重要だったのは、Chromatic が提供していた価値をどう置き換えるかという点です。 代替ツールを検討する前に、まず Chromatic から得ていた主な価値を整理しました。 Chromatic から得ていた価値 💎 Chromatic は単なる VRT ツールにとどまらず、フロントエンドの開発フローおよび品質保証に幅広く価値を提供しています。 特に以下の 3 つの価値が重要でした： リグレッションの検知 UI に意図しない変更が入っていないかを自動的に検知 継続的な品質保証の基盤 開発体験の向上 PR の変更によって UI にどのような影響があるかを視覚的に確認 Story 単位での変更承認/拒否により、コンポーネントごとの細かなレビューが可能 Storybook 共有によるコミュニケーション基盤 デザイナーやプロダクトマネージャーとのコミュニケーションツールとして機能 再現が難しい条件の UI 状態も、Storybook でパラメータを固定して共有可能 コンポーネントの全バリエーションを一覧できるカタログとしての役割 これらの価値をできる限り維持しながら内製化を進める必要がありました。 Storybook のホスティングを代替する 「3. Storybook 共有によるコミュニケーション基盤 」について、Storybook をホスティングできることについては、Storybook 自体は静的な配信に対応しています。 ですので、単に「ブランチごとにビルドをして AWS S3 等のホスティングが行えるサービスでホスティングする」仕組みだけ作れれば良いので、GitHub Actions で AWS S3 にアップロードするワークフローを組むことで対応できる見立てが立ちました。 VRT の実行およびレポート確認を代替する Storycap + reg-suit Storycap と reg-suit の組み合わせは、オープンソースで VRT を実現する広く使われているオプションです。 VRT の実現には、大きく分けて スクリーンショットを撮影する部分 UI の差分を検知する部分 レポートを表示する部分 の要素が必要ですが、Storycap が 1 の撮影部分を、reg-suit が 2 と 3 の差分の検知とレポート部分をカバーします。 実際に既存の Storybook に組み込んでみて挙がった課題点とそれぞれの対応案は以下の通りです: ビューポートサイズ 📱: デフォルトでは正方形に近いサイズで、多くのページでは適切ではなかった 対応: デフォルトのビューポート指定を追加（823 x 1,512） CSS アニメーション 🔄: ローディングアニメーションが diff になる問題 対応: 提供される disableCssAnimation では固定できなかったので、isSnapshot モード時にスピナーのアニメーションを停止する Storybook のデコレータを追加することで対応 Play Function ▶️: Chromatic では自動的に待機していた Play Function の完了を待たない問題 対応: delay 指定または明示的に waitFor を使用 それぞれの課題も個別対応できることが分かり、十分実用に耐えそうだということで確認できました。 また、reg-suit によるレポートも視覚的にわかりやすく、差分の確認方法も複数用意されています。 Lost Pixel Storybook ベースの VRT を実現する他のツールとして、 Lost Pixel も検証しました。 Lost Pixel は reg-suit + Storycap 同様に Storybook のスクリーンショットを撮影し、変更を検知するためのツールです。Platform 版（SaaS）と OSS 版の 2 つの選択肢がありますが、OSS 版を検討しました。 Lost Pixel は前述の要素において 1 と 2 をサポートします。 差分はどうやって把握するのかというと、最新のスクリーンショットをコミットしておき、スクショを更新することで GitHub の PR の UI から確認する思想で作られています。 自分はあまり使ったことはなかったんですが、複数の差分表示方法を GitHub が対応していて変更内容自体はわかりやすく確認が可能でした。 実際に試用した結果、以下のような特徴がわかりました： セットアップの容易さ : 設定が reg-suit 系に比べて「Easy」によっており、ほぼデフォルト設定だけで動作する 安定性 : Chromatic や reg-suit で個別・特殊対応が必要だったケースも、特に追加設定なく安定して動作していた かなり Easy かつ安定した VRT が実現できていて感触はかなり良かったです。 一方、 課題点 も見つかりました。 実行速度が遅く、ローカルマシン(M2 Max 64GB Mac) でスクリーンショットのみで約 9 分 並列化のオプションは提供されるが、sharding のオプションがなく大規模プロジェクトでの実行時間短縮が難しい ほとんどカスタマイズは不要でしたが、Story 単位のオプション制御は弱くドキュメンテーションも限定的でカスタマイズはしづらい レポート機能が提供されず、GitHub の diff に依存する必要がある 技術比較と選定 ⚖️ 上記の検証結果をまとめると以下のようになります: 各ステップにおけるツール比較 スクリーンショットの capture ツール 良い点 悪い点 Storycap 実行時間に難はあるが、並列化および sharding オプションが提供され、スケールに耐える Chromatic よりフレイキー気味で個別対応が必要になりがち。play function 非対応 Lost Pixel (OSS) 安定している 実行時間に難があるかつ sharding できないのでスケールに限界 リグレッション検知・レポート ツール・サービス 差分チェックの体験 reg-suit レポート UI が提供され Chromatic に近く使いやすい体験。Story ごとの Accept/Deny/Comment ができない点は Chromatic に劣る Lost Pixel (OSS) レポートは提供されず、ローカルまたは CI で新しいスクショをコミットし、GitHub の diff で確認する想定 事例はほとんど見かけませんでしたが スクショ部分を Lost Pixel リグレッション検知とレポート部分は reg-suit のような構成も一応取ることができるので、併用する案も含めてそれぞれ選定を行い、 reg-suit + Storycap の構造を取ることに決めました。 理由: スクリーンショットの capture : Lost Pixel も簡単かつ Flaky さが少なくて感触は良かったのですが、実行時間のスケーリングが厳しそうな点で選択できないと判断しました 検証時点でも 1000 以上の Story が存在しており、今後も増えていくことを考えると sharding が不可能な点は致命的でした リグレッション検知・レポート: Chromatic に習熟している開発者の生産性を極力落とさずに移行してもらうためにもレポート画面がある点で reg-suit は魅力的だったため、採用しました Lost Pixel の場合、ワークフローが煩雑になってしまう点もマイナスポイントでした reg-suit + Storycap の構成では、Chromatic と比較すると開発者体験は若干劣るものの、以下の点で優位性がありました： コスト 💰: 大幅な削減が見込める カスタマイズ性 🛠️: ワークフローの各段階をカスタマイズ可能 実行環境の制御 🎮: 自社環境で実行するため、実行ノードのスペックやタイミングを制御可能 一方で、以下のトレードオフが存在します： 開発者体験の低下 : Story ごとの Accept/Deny/Comment ができない 差分確認は GitHub のコメントを使ったやり取りになる 特殊な Story に対するカスタム対応が必要になる場合がある 運用コスト : 初期構築と継続的なメンテナンスが必要 GitHub Actions の実行時間と費用のバランス調整が必要 これらの比較を行い、コスト削減効果と許容できる開発者体験のバランスを考慮し、 Storycap + reg-suit を採用することで決定しました。 やや開発体験の低下はあるものの、十分許容できるラインと判断しました。 まとめ 📝 Chromatic からの移行を検討する過程で、複数の VRT を提供する OSS とアプローチを検証しました。 その結果、コスト削減効果と開発者体験のバランスから、Storycap + reg-suit の組み合わせが最適であるという結論に至りました。 主な決め手となったポイントは以下の通りです： 大幅なコスト削減 : 月額費用の大幅な削減が見込める 許容可能な開発者体験 : 体験は Chromatic には若干劣るものの、主要な機能は維持できる 1-2 を満たしながら現実的な CI の実行時間を維持できる 今回は採用しませんでしたが、組織が小さいタイミングでの Chromatic はほぼ最低限のセットアップで高度な開発体験を提供してくれますし、Lost Pixel (OSS 版) も簡単さ・安定性で優位があり、重視するトレードオフによって良い選択肢だなと思いました。 次回予告 後編では、Storycap + reg-suit を使ったワークフローを実際に構築していく際の工夫した点や移行のプロセスについて紹介する予定です！ お楽しみに！

こんにちは！カイポケリニューアルのサービス提供管理チームでバックエンドのエンジニアをしている清田です。ここ3ヶ月はフロントエンド開発をしています。 この記事ではバックエンドを主戦場とするエンジニアがフロントエンド開発に挑戦して学んだこと、見えてきた風景について紹介します。 (以降、バックエンドを BE 、フロントエンドを FE と略します) また私の個人的な体験ですが、FE 開発に貢献するためどのように学習したのかについても共有します。 BE エンジニアの FE 開発への挑戦、おすすめです！ なぜ FE 開発をするようになったのか 私が FE 開発に挑戦するようになった背景には、いくつかの要因がありました。 チーム編成の変化 まず、チーム編成が職能別からユーザーへの価値にフォーカスした編成に変わったことが大きいです。 カイポケのリニューアルプロジェクトでは、 ドメイン毎のサービスで構成されたアーキテクチャで開発を行っています 。 私は居宅介護支援事業所のケアマネジャー向けのケアプラン作成に関するドメインの中で、BE の機能開発を行うチームに属していました。 カイポケのリニューアルプロジェクトの開発チーム全体で LeSS が導入されたことにより、 2024年12月に居宅介護支援の領域では「サービス提供管理チーム」という名称で、デザイン、 FE 、 BE 、QA それぞれの職能に強みを持つメンバーが同じ1つのチームになりました。 (※ 導入理由などについては、 LeSS の導入で変わるマネージャーの役割 に詳しくあります) この編成の狙いの1つには、将来的には希望するメンバーについては職能を横断して別領域に挑戦しながら、チーム全体で提供できるユーザーへの価値を高めていくことも含まれています。 チーム構成の課題 チーム内での FE, BE それぞれを強みとする開発者の人数比率がアンバランスになった(FE:BEの人数比が 1:3 だった)こと、タスク量が FE のものの方が当時は多かったこともあり、FE の開発ができるメンバーを増やす必要がありました。 (現在は他チームからのメンバー移動などもあり人数比率は FE:BE でだいたい 1:1 です) そのため、FE の主力の開発者(以降 FE メンバー)が新機能開発や難易度の高い開発に注力し、 BE メンバーが細かなバグ対応のような難易度の低いタスクや、そもそも GraphQL schema を定義し共有することで連携が必要だったエラーハンドリング系のタスクなどを一気通貫でこなすことになりました。 個人的な挑戦 私自身、 FE 開発に挑戦したいという思いがありました。BE から FE まで一気通貫で開発できるようになりたかったからです。 また、エス・エム・エス入社前は開発言語としては Java メイン、入社後も Kotlin を書いていたので、言語的に TypeScript での開発体験は気になっていました。 加えて React での component をベースにした開発を経験することで、BE の開発で求められる頭の使い方とは違うものを吸収して、ものづくりをする際の考え方の視野を広げたいとも考えていました。 そのため、FE 開発に挑戦することにしました。 足りていない知識は何なのか 今回の FE 開発の挑戦には、担当するプロダクトは変わらないため BE 開発時代に得たドメイン知識はそのまま活用することができました。その上で FE 開発を始める前に自分に足りていない知識や経験は次のものでした。 FE の技術スタックの複雑さ(清田個人の知識の積み上げがないという意味です) 開発環境が異なる(=Visual Studio Code を使用する)ことによる負荷 FE の技術スタックの複雑さ 私の FE のスキル感は、2021年ごろに JavaScript Primer と 『りあクト！ TypeScriptで始めるつらくないReact開発 第3.1版』 を一周やったことがあるくらいで、業務ではしっかりと FE に触れたことがありませんでした。 そのため、 HTML、 CSS の基礎と TypeScript の書き方と Next.js の概要についてキャッチアップが必要と考えました。 開発環境が異なる(=Visual Studio Code を使用する)ことによる負荷 これまでの BE 開発の経験から IntelliJ をずっと使っていたため FE 開発でも IntelliJ を使うという選択肢もありました。 ただし今回は以下の理由から Visual Studio Code(以降 VSCode) で開発することにしました。 FE 開発では VSCode が一番使われていること 2024 年の JavaScript と TypeScript のトレンド: 開発者エコシステムアンケートのインサイト FE メンバーはみな VSCode を使っており気軽に知見を聞けること 『達人プログラマー（第2版）』 の「第3章 基本的なツール」の 「職人のように常に道具を増やすことを心がけてください。」に従って開発時のインターフェースとしての道具も増やしてみたかったため どうやってキャッチアップしたか 個人的な体験ですが、BE エンジニアが FE 開発に挑戦した際にどのようにキャッチアップしたかを共有できればと思います！ (もちろん現状でキャッチアップできたとは思っておらず、以下に挙げるものは今も継続的に取り組んでいることです！) 技術スタックを知る まずは、プロダクト開発をするにあたっての前提として必要な HTML、 CSS、 TypeScript、 React、 Next.js の基本的な知識について以下の内容を手を動かしてキャッチアップしました。 HTML、CSS については、MDN ドキュメントの 入門モジュール と コア学習モジュール の中でプロジェクトの開発で知識として必要そうな箇所 TypeScript については、 『プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで』 で基本的な文法と型の種類について React、Next.js についてはチュートリアル( React Foundations 、 App Router )を実施 次にプロジェクトで使われているライブラリについて先に軽く調べておきました。 ただこちらはそれぞれを動かして試す時間はないため、導入されている意図を予測し、 〜をつかうことで〜が嬉しい！？ みたいなフォーマットで自分なりに導入理由を想像してメモを残すに留めました。 VSCode ホームポジションから動かずにソースコードを行き来する 個人的な好みの問題なのですが、ソースコード内を移動する時にホームポジションから動かずに操作したい派です。 既に実装がある程度進んでいるプロダクトの開発時ではソースコードを読む時間が一定あります。 一貫性を持った実装にするために参考にするべき実装を探す時や、 component の階層が深くなっていった際の定義の移動を、思考の流れを止めずにホームポジションで行えることは既存のコードを理解するためにとても重要です。 コードリーディングに着目してショートカットを紹介している記事 【VSCode】コードリーディング特化のショートカット集 が本当に参考になりました！ あとは IntelliJ ではショートカットを覚えるほどではないものについては Find Actions を多用する派なので、VSCode でも Command Palette は多用しています！ モブプロでの学習 最初の開発については、FE メンバーとFEに挑戦するメンバーでモブプロで進めました。 FE の実装においてはどのようにソースコードを追うのか ディレクトリ構造 TypeScript のちょっとした文法 テストの書き方(どの粒度でどのように書くのか) などの疑問点を同期的に質問しながら作業することで開発の流れや実践的なスキルを学ぶことができました。 なお、最初の開発以降は、初めて取り組む実装の際は必要に応じて FE メンバーに協力をお願いしてペアプロやモブプロで開発することもあります。 プロダクト開発を通じた学習 実際にプロダクト開発することは何よりの学びになりました。 修正箇所の Figma のデザインやアプリケーションの操作から、コードを書くべき場所に当たりをつけてソースコードを読んでいく過程で component を組み合わせて画面が作られていることを実感しました。 個人的に FE 開発に限らず意識していることですが、少しずつ違う性質の実装タスクに取り組むことで担当できる領域を広げていきました。 そして、プロダクト開発を通じて以下のようなことを段階的に学んでいきました。 Figma から情報を読み取って実装に反映する CSS の box model の style の調整について(margin、padding の使い方) Figma の Dev Mode で確認して実装したものと DevTools で対象の element を選択して Computed したものを見比べて style が正しいか確認する Testing Trophy の考えに従い、 component 単位でテストを書き、ユーザの動作を保証することについて エラーを表現する component の新規追加 component の props で ReactNode を渡すようにして JSX で柔軟にエラーに関する情報を渡す なによりこれらは FE メンバーに PR にて提案や指摘をいただいて学べたことです。ありがとうございます！ FE メンバーの PR をみる バックログリファインメントに参加し実装背景や実装方法の方針がわかっているタスクについては、FE メンバーの PR を覗いて、TypeScript らしい書き方や自分では思いつかない実装方法や考え方について学ばせていただきました！ FE 開発をやって良かったこと BE エンジニアが FE 開発に挑戦して学んだこと、見えてきた風景について紹介します。 システムの使われ方をより明確にイメージできるようになった FE 開発でユーザーに近い部分を実装したため、ユーザーが実際にカイポケを使用する時のことがよりイメージできるようになりました。 FE のタスクとしてエラー時の UI や表示するメッセージを考える時だけでなく、BE で API (GraphQL server の実装)を追加する際にも、クライアントでどのようにそれが使われるのかを以前よりも解像度高く考えることができるようになりました。 デザインへの興味がでてきた FE 開発の中で学んだこととして、 Figma の Dev Mode で確認して実装したものと DevTools で対象の element を選択して Computed したものを見比べて style が正しいか確認する をあげたのですが、実際は多くの場合は Figma と社内 UI ライブラリで提供されている component の名前が一致しており、デフォルトの値が指定されているので細かな調整をすることは少なかったです。 これはデザインシステムを整備いただいていたからのようです！ (詳しくは デザイナーとエンジニアで育てる組織の共通言語としてのデザインシステム ) この驚きを機に UI の世界の共通言語やそれを表現する component に興味が出てきて、いろんなライブラリの component を眺めたり、他社のデザインシステムをカタログ感覚で見るようになりました〜 shadcn/ui 、 Tailwind CSS 、 Chakra UI の提供する component を見たり、プライベートで shadcn/ui を使用して画面を作ってみたりしています！ FE 系の話題について目に留まるようになった 日々ちょっとした時間にチェックしている、 はてなブックマークのテクノロジーの人気エントリー や Zenn の Trending で流れてくる FE 系の話題について、表面的ですが何について書かれているのかわかるようになりました！プロダクト開発をした経験により見える世界が広がりました。 VSCode での開発に慣れた 道具を増やすことを意識して VSCode を使い始めたのが功を奏して、 Cursor を使用したり、最近盛り上がっている Cline を動かしてみたりといった新しい開発体験をプライベートの開発でカジュアルに試せるようになってきました。 (変わらず IntelliJ のことも好きなので JetBrains の Junie も楽しみにしています！) また、VSCode を不自由なく扱えるようになったことで他の言語の開発やソースコードリーディングに対するハードルも下がりました！ ソースコードリーディングの力がついた 画面の表示や操作から仮説を立ててコードを追っていき修正箇所を見つける、という経験を通じてソースコードリーティングの力がつきました。 ユーザの操作 → API 呼び出し(FE の実装) → BE の実装 まで一気通貫でソースコードを追って問題を見つけられるようになりました。 BE の技術の幅も広がった プロダクト開発とは関係がなくなるのですが、 TypeScript と VSCode での開発に慣れたのでプライベートで Hono を使用した実装の素振りもしました。 ( RPC の開発者体験がとても気持ちよかったです) (広く浅くにはなりますが)別言語や別の思想の Framework を触ることで、自分のスキルセットの中でメインで使っている技術の書き方にも活かせたり、扱える技術の幅を広げることができたのでよかったです。 FE 開発に挑戦したことでチーム開発に貢献できたこと これまでに BE エンジニアが FE 開発に挑戦したことによる個人的な収穫について記載しました。 ここではチーム全体で提供できるユーザーへの価値を高めていくために貢献できたことについて紹介します。 FE メンバー(FE の主力の開発者)が実装難易度の高いタスクや新機能の開発に注力できるようになった BE メンバーが、細かなバグ対応やエラーハンドリングのタスクを一気通貫で実装できるようになったことで、FE メンバーがよりインパクトの大きい開発に注力できるようになりました。 (今後は BE メンバーも徐々に実装の難易度が高いものにも挑戦していく予定です！) なお、最初の2週間はモブプロの予定をたくさん入れていただき、BE メンバーが自走するまで手厚くご協力いただきました。今でも詰まってしまった際にサポートいただいています。ありがとうございます！ バックログリファインメントでの BE/FE の対応状況を整理しやすくなった FE のタスクについてバックログリファインメントを行う際に BE メンバーがいることで、 BE の対応状況や使用する API について共有することができるため、タスクの見積もりの確度を高めるのに貢献できました。 FE、BE どちらもローカル時の困りごとの解消を手伝えるようになった BE では単体テストや Subcutaneous Test で動作を保証しながら開発をしているため、 これまでは FE をローカルで起動していませんでした。 (ユーザの動作は dev 環境で確認していました) FE 開発を機に初めてローカル起動するようにしたことで、BE の起動方法の知見と紐づけて以下のようなちょっとした手伝いができるようになりました。 特定の branch で BE を起動して動作確認する方法をドキュメント化して共有 ローカルで BE のデータセットアップが不足していてエラーになるのを解消する 最後に FE 開発は BE エンジニアにとって新たな世界が広がり、スキルセットを拡げる絶好の機会です。 また BE と FE の垣根を越えることでチーム内での協力体制を強化しつつ、プロダクト開発全体の効率化に貢献することもできるはずです。 この記事が FE 開発にも興味がある BE エンジニアの方にとって役に立てれば何よりです。以上です！

キャリア事業部のエンジニアの田実です！ 3/21〜23に開催されたPHPerKaigi 2025に協賛＆参加＆登壇したのでそのご報告になります！ phperkaigi.jp シルバースポンサーとして協賛していました！ エス・エム・エスはPHPerKaigi 2025にシルバースポンサーとして協賛しました！ キャリア事業部ではエンジニアを募集しております！ PHP/Laravelも利用しておりますので興味がある方は是非お話ししましょう！！ ソフトウェアエンジニア カジュアル面談(PM/EM/SRE/QAも歓迎) / 株式会社エス・エム・エス 登壇: Alpine.js を活用した
Laravel MPA フロントエンド最適化戦略 speakerdeck.com Alpine.js というJavaScriptライブラリについて紹介させていただきました。Alpine.jsは前職も現職も導入経験がありオススメな技術の一つなのですが、国内ではイマイチ盛り上がっておらず是非紹介したいなと思い今回の登壇に至りました。 本発表を聞いてAlpine.jsを使ってみたいと思った方が増えてくれたら嬉しいですし、皆様の技術選定に少しでもお役に立てれば幸いです！ 今回は時間の都合上カットしましたが、Viteによるビルド、Vitestによるテスト、TypeScriptによる型導入、Biomeによるフォーマット・Lint適用、Sentryによるエラー検知などMPAのフロントエンド改善を現在進行系でバシバシやっていますので、こちらもどこかで機会があれば発表できると良いなと思っています。 ちなみに、今回の登壇準備にあたり生成AIを活用しました。具体的にはGeminiやChatGPTを活用し以下の内容の調査・壁打ちをしました。 スライド構成 CfPの内容からスライド構成を出してもらい、観点漏れを指摘してもらいました。 発表内容 Alpine.jsによるUIコンポーネントテストの方法を教えてもらいました。これは検索してもなかなか出てこなくて自分の当時の知識では思いつきもしなかったです…。 技術のPros/Consにおいて、自分が考えている以外の観点のものが無いかを確認しました。 スライドや構成検討に毎回頭を悩ませているのですが、生成AIを使うと気軽に壁打ちできるためいつもより捗った気がします。技術調査も生成AIにより効率的に理解することができました。特にAlpine.jsのような有識者があまりいない技術領域の調査においては大変心強かったです。 参加した感想 php-srcのコアな内容や以前の職場での取り組みを聞けて技術的にも仕事的にも非常に刺激を受けました。登壇が終わって一息つくはずが他の人の発表を聞いたり話していたら次の登壇への活力が湧いてくるのは何故でしょうね…？ｗ また、技術イベントの懇親会への参加は5年ぶりだったのですが「あの有名なライブラリの作者さん！」や「めっちゃ面白いLTしてた方！」や「部署違いで全然話したことない同僚！」といった方々と楽しくお話できたのは貴重な機会でしたし、対面で会って話すことの良さを改めて感じました。 最後になりますが、スタッフの皆様、素晴らしいカンファレンスをありがとうございました！ 登壇者・参加者の方もお疲れ様でした！！

エス・エム・エス BPR推進部 キャリア横断開発グループ データ基盤チームの手塚と申します。2024年9月に当社に入社し、早くも半年が経過しました。 この記事では、私自身が実際に感じたことを「仕事の進め方」と「文化」の2つの観点からご紹介します。SIer・SES企業から転職を検討している方、またはエス・エム・エスに興味をお持ちの方にも、参考になる情報をお届けできれば幸いです。 経歴 前職ではSESエンジニアとして、BI画面開発やデータ連携（ETL）の開発業務に携わっておりました。SES（System Engineering Service）とは、契約期間に基づき、クライアント企業に対してエンジニアの技術力や専門スキルを提供するサービスです。具体的な働き方としては、お客様の要望や課題をヒアリングし、それを基にシステム開発を行い、納品、運用、保守まで一貫して担当していました。 SESと自社開発（エス・エム・エス）の違い 仕事の進め方 仕事としての関わる範囲・人 まず、入社して感じたことはエンジニアとしての役割が非常に広い点です。 私の所属するデータ基盤チームでは、「社内のデータ活用の推進」を目的の一つとして、日々多種多様な案件に対応しています。例えば、半日で対応可能な簡単な案件から、1年以上を要する大規模プロジェクトまで、案件の規模は様々です。 また、キャリア横断開発グループに所属していることから、担当する案件も単一のサービスに留まらず、エス・エム・エスが展開する多岐にわたるサービス群に及びます。そのため、社内外の多くの関係者と連携しながら業務を進める必要があり、関係者との調整や意思決定に苦労する場面も少なくありません。ですが、その分、自らの仕事が会社全体の事業に貢献しているという当事者意識と、大きなやりがいを感じることができます。 （オレンジ箇所がキャリア横断開発グループとして対応しているサービス領域） 一方、前職のSESでの働き方は、プロジェクト全体のごく一部分のみを担当することが多く、担当領域が限定されていました。そのため、関わる社内外の関係者や部署も固定化され、プロジェクトによっては、リーダー層の方のみがお客様と直接コミュニケーションを取り、現場のエンジニアは、プロジェクト開始時と終了時の挨拶以外、お客様と直接会話する機会がほとんどないケースもありました。 開発手法・仕様の決まり方 開発手法も異なっていました。前職ではウォーターフォール開発が主流で、要件定義→設計→開発→テスト→リリースと必ず前工程が完了してから次の工程に進んでいました。 対して、データ基盤チームではアジャイル開発を採用しており、一連の開発工程を短期間で繰り返します。ウォーターフォール開発は、経験の浅いエンジニアにとっては、各工程でやるべきことが明確で進めやすいというメリットがあると感じていました。しかし、開発に時間を要するため、成果物がなかなか目に見える形にならない点や、リリース直前にお客様からのフィードバックによって大幅な手戻りが発生し、モチベーション維持が困難になる点が課題でした。 アジャイル開発では機能単位のリリースで改善が実感でき、ユーザ側にも成果物の共有がしやすく、反応が感じられる点が非常に良いなと感じてます。 また、仕様の決定プロセスも大きく異なります。前職では、仕様は基本的にクライアントからの要求に基づいて決定されるため、私たちから積極的に提案を行う機会は限られていました。しかしながら、エス・エム・エスのような自社開発企業では依頼者が身内なこともあり、直接業務担当者とコミュニケーションを取りやすく、仕様についても柔軟に決定することが可能です。データ連携の仕様についてもエンジニアから提案する場面をよく見かけます。 キャリア横断グループと前職の仕事の進め方の違いをまとめると以下の表のような感じです。 キャリア横断グループ SES（私の前職） 関わる範囲 複数サービス プロジェクトの一部 関わる人 複数の担当者 固定の担当者 開発手法 アジャイル ウォーターフォール 仕様の決まり方 柔軟に決定 （こちらからも提案） 基本的にクライアントからの要求で決定 文化 企業文化として重要視していること 企業文化についても、前職とエス・エム・エスとでは大きな違いがあると感じています。 まず、最も大きな違いとして感じたのは、業務において重要視していること（目的）です。前職のSES企業では、SIer・SES企業ではよくあることかもしれませんが、「開発すること」自体が目的化しており、お客様からの要望に「いかに応えるか」に焦点が当てられていました。また、SES契約という契約期間に制約がある働き方であったことも影響し、プロジェクトに関わるフェーズによっては、プロジェクトの成功よりも「納品すること」が目的となり、お客様がそもそもなぜシステム開発を依頼したのか、という根本的な課題にまで目を向けることが難しかったと感じる場面もありました。 エス・エム・エスでは、目の前の案件に対し、本質的な解決を目指す姿勢が強く感じられます。例えば、MTGでエンジニアが「この課題は、必ずしもシステム開発をしなくても、スプレッドシートの機能だけで解決できそうですね」と発言し、実際に開発せずに課題解決を目指す場面がありました。その時は、非常に感銘を受けました。 私の所属するBPR推進部のミッションは、「成長と変化を促進するビジネス基盤を構築することで、価値提供先の本来業務への集中を実現し、会社と事業の成長に貢献する」ことです。そのため、開発という手段に固執せず、ユーザー自身で解決できる課題は、その方向でサポートするという姿勢を目の当たりにし、前職との文化の違いを強く感じました。 前職では、お客様の要望によって仕様が決まる場面が多く、その要望に対し「既に決まっていることなので」と、半ば思考停止の状態で業務を進めざるを得ないこともありました。（いつしか自分自身もその状況に慣れてしまい、このままではいけないと感じたのが、転職を考えたきっかけの一つです。） 社内コミュニケーション 社内コミュニケーションの質に大きな違いを感じています。 前職では、Teamsが導入されていたものの、活用方法は業務連絡が中心で、雑談などのコミュニケーションはほとんどありませんでした。原因として、エンジニアが別々のプロジェクトに派遣される働き方のため、コミュニケーションが同じプロジェクトのメンバーに限定されていたことが挙げられます。また、他のメンバーの業務内容やコミュニケーションは、上長クラスでなければ把握できない状況でした。 そのため、プロジェクトは異なっていても同様のツールを使用しているケースがあるにも関わらず、情報共有がスムーズにいかないことがありました。社内全体として、勉強会や共有会などの活発な情報交換の場を設けづらい環境だったと、今振り返ると思います。 一方、キャリア横断グループのエンジニア内では、雑談から仕事の相談まで、活発なコミュニケーションが行われています。Slackのオープンチャンネルを通じて異なる部署のやり取りを知ることができ、他部署のメンバーにも気軽に質問できる場面が多く見られます。 また、データ基盤チーム内のコミュニケーションも活発です。朝会の「100の質問」や、レトロスペクティブ、勉強会など、定期的な共有の場が設けられています。そのため、他のメンバーの業務内容が見えやすく、情報共有が非常に円滑だと感じています。 私自身、入社して4か月後に他部署の人を交えて読書会の開催ができました。このような活動ができたのも、キャリア横断グループの活発なコミュニケーション文化のおかげだと感じています。 キャリア横断グループと前職の文化の違いをまとめると以下の表のような感じです。 キャリア横断グループ SES（私の前職） 重要視していること 課題解決にフォーカス クライアントの要望にフォーカス コミュニケーションレベル 雑談～仕事の相談まで 基本的に業務連絡のみ コミュニケーションの頻度 複数回/週 勉強会も定期的に開催 不定期 さいごに 自社開発企業とSESとの違いを仕事の進め方や文化という観点から違いを述べさせていただきました。個人的に感じた最も大きなギャップは、重要視していることが「課題解決」であるのか「お客様の要望」であるのかです。課題を解決できれば手法にこだわらない姿勢は自社開発企業に合っている方だと感じますし、エス・エム・エスには楽しめる環境が揃っていると思います！ また、エス・エム・エスは新しいメンバーを募集しています。 私達データ基盤チームでは、データ基盤の運用から、データパイプラインの開発、データマートやダッシュボードの開発、AIを用いたソリューションの提供など様々な業務を通して事業を支援しています。これまでの取り組みは別記事でも発信しておりますので、以下ページもご覧いただけると幸いです。 tech.bm-sms.co.jp tech.bm-sms.co.jp tech.bm-sms.co.jp エス・エム・エスの事業に携わってみたい方、BPR推進部へ興味のある方は、ぜひこちらのページものぞいてみてください。 open.talentio.com

合同会社makigai（マキガイ） の貝瀬です。2024年6月からスクラムマスターとして、介護/障害福祉事業者向け経営支援サービス「カイポケ」に関わる組織やプロセスの改善を支援しています。 カイポケリニューアルプロジェクトでは、LeSS（Large Scale Scrum：大規模スクラム）を導入しています。本記事では2025年1月に実施した座談会の続編（Part2）をご紹介します。 Part1については以下の記事をご参照ください。 tech.bm-sms.co.jp 人物紹介 キム ダソム（以下、キムPO） エリアプロダクトオーナー 田村 恵（以下、田村PO） エリアプロダクトオーナー 原野 誉大（以下、原野EN） エンジニア 伊達 大晃（以下、伊達EN） エンジニア 福田 尚亮 スクラムマスター兼ファシリテーター 貝瀬 岳志 全体のスクラムマスター兼本記事の執筆者 チームの自律性向上のための役割廃止 —— 10月にはマネージャー酒井さんから、プロジェクトリードを廃止するという働きかけがありました。プロジェクトリードはLeSS導入以前に、「チームを跨いだコミュニケーションでお見合いが発生することを避けるため、また、マネージャーやプロダクトオーナーの負荷を分散するために定義した役割」でした。自律的な クロスファンクショナルチーム (注: プロダクト開発に必要なスキルを保有している、または習得できるチーム)を目指すことが目的でこの役割を廃止することになりましたが、当時どのような印象や期待があったのかを聞かせてください。 キムPO：長期的な目標から見て、ワンチームで取り組んでいくことを目的に役割を減らすというのはポジティブに感じていました。反面、これまではプロジェクトリードがチームとの窓口を担ってくれていたので、当面は結構カオスになるのではないかという懸念もあり、期待半分・不安半分といった印象でした。 田村PO：私もほぼ同じ印象でしたね。これまでだと、プロジェクトリードにとりあえず依頼しておけばいい感じにやってくれていたのですが、チーム全体に投げかけたときにボールがちゃんと拾われるかどうかという不安は大きかったと思います。中長期で目指していく姿を考えればこのタイミングで廃止しておくべき、ということも理解していたのでネガティブではなかったものの、めっちゃ不安でしたね。 伊達EN：私は田村さん管轄のプロダクトを担当しているチームですが、すでにプロジェクトリードの役割が薄れてきていたので、そこまで何かが大きく変わることはないだろうと思っていました。酒井さんの働きかけより前から、個人というよりチームとして仕事を進めていたので、不安は特に感じていませんでした。 原野EN：9月ごろにミーティングが増えたなと思っていましたが、会話の内容は、チーム分割に関するものだったり、リリースまでのスコープに関するものだったので、プロジェクトリードの役割は想定よりも重い役割に変わっていった印象でした。元々のプロジェクトリードは当番制でも良いくらいの薄い役割で、チームの全責任を担うような重い役割ではなかった認識だったため、その役割をなくしていくことにポジティブでした。個人的な意見であってもチームの代表としての意見として捉えられる可能性があったので、チームの合意をとった方がいいかなとか、悩みながら発言していた記憶もあります。ただ、プロダクトマネージャーやプロダクトオーナーの立場からすれば、プロジェクトリードを廃止することには不安があるんだろうなとも思っていました。 キムPO：スプリントプランニングの1部でも、私からの質問に対してプロジェクトリードの方が回答してくれることが多いので、チーム全体のことを把握しているんだろうなという前提でコミュニケーションを取っていました。それがチーム全体に窓口が広がることで、時間がかかるのではないか、責任の所在が曖昧になるのではないか、といった不安がありました。 原野EN：キムさんのいうような問題が起きて、また元に戻るんじゃないかという懸念もありました。長期的には賛成でしたが、いきなりガッと変化できることでもないので、短期的にはやり方考えないとね、という気持ちが強かったです。 —— 10月から変化が始まって、責任の所在が曖昧にならないか、必要以上に時間がかからないかといった懸念があったかと思いますが、現時点では当時感じていた懸念に対してはどういった状況でしょうか。 原野EN：各チームで代表をローテーションするような折衷案を試したり、いい感じの塩梅を探していく形を取っていった結果、懸念していたような問題は起きなかったと思っています。また、自分自身のGitHubのコミットグラフをみてみたんですが、10月くらいからコミットが増えたなという結果になっていました。そういう意味では、コードを書く時間がかなり増えて、ミーティングが結構減ったなとも思います。 キムPO：私も当時の懸念に関する課題は、顕在化せずにここまで来ていると思います。例えばSlackではチーム宛にメンションしていますが、ボールが落ちたりスルーされることもなく、どなたか必ず回答してくれているので今は安心感があります。ただ気持ち的には、こんなに広範囲でメンションしちゃっていいのかな、ゾーンに入っている時に邪魔しちゃ悪いかな、みたいなことは感じています。気にせずにやっちゃっていますが（笑）。 —— エンジニアのお二人からみて、チーム宛のメンションが飛んでくることへの悪影響や懸念はあったんでしょうか。 原野EN：自分は元々気にならないタイプですし、そもそも変化の前から自分宛にメンションが来ていた状況だったので感覚は変わっていないですね。 伊達EN：同じく気にならないタイプですが、特定の誰かに依存しすぎていること自体が良くないと思っていたので、チームに投げかけてもらった方が当事者意識も出てきますし、むしろその方がポジティブだなと思っています。 原野EN：そうですね、自分は普段から全部知っておきたいというか、気になってSlackを堀り漁っているくらいなので、メンションが飛んできた方がむしろ楽だなとも思います。 —— ちょうど私もスクラムマスターとして支援に入ったタイミングでしたが、責任の所在やコミュニケーションに関する部分は、チームの皆さん自らが課題として捉えられていることを感じていました。自分たちでやり方を決めるところから活発に議論されていて、実行に移していたことが印象的でした。当事者意識という言葉が出ましたが、従来から当事者意識の高い方が多い組織なんだろうなと感じています。10月に関して他のトピックはありますか？ 原野EN：9月の段階ではチーム編成など組織に関するトピックがあるとプロジェクトリードが巻き込まれていましたが、徐々にその役割がマネージャーに移っていったのかなと思います。 —— ちょうどこの時期に、マネージャーの酒井さんからLeSSにおける マネージャーの役割に関する課題提起 をされていましたね。 コンポーネントチームからクロスファンクショナルチームへ —— 11月に入ったタイミングでも、大きな変化があったかと思います。キムさん、原野さんたちの組織ではLeSS導入以前、バックエンドとフロントエンドが別々のチームで分業していましたが、フロントエンドチームがバックエンドタスクを学習しながら取り扱い始めた時期だったかと思います。大きな問題もなく取り扱えていた印象ですが、何か工夫した点はあったんでしょうか？ 原野EN：フロントエンドチームがバックエンドタスクとして最初に扱ったのは、既存のコードに対して細かい修正で済むような内容でした。まずはバックエンドエンジニアも交えたモブプロで環境構築して、後はまあひとまずやってみようぜ、というくらいの気軽なノリで始めた記憶があります。私が前職でKotlinを扱ったこともあったので、個人的にもなんとかなるのではないかと思っていました。分業していた時は、ここから先はバックエンドなので自分たちフロントエンドチームはここまでで・・といった遠慮や線引きの意識から、気まずさを感じていたので、自分たちが一貫してコントロールできるように変化することは、チームとしてポジティブだったかと思います。 キムPO：フロントエンドチームはまさに期待していた通りの変化が起きたかなという印象です。当時扱っていたプロダクトバックログアイテムは不確実性が低いものでもあったので、移行がスムーズにいったのかなと思います。結果として、他のチームもクロスファンクショナルチームにしていきたいということを考えるきっかけにもなりました。 —— 11月の変化としてもう一つ、田村さん、伊達さんの組織ではチーム分割の検討がされていました。当時の狙いとして、コミュニケーションコストの低減とチームが取り扱う領域の変化への対応があったようです。分割するときに気にした観点や、最終的にどのように意思決定したのかを聞かせてください。 田村PO：チームの人数が増えてきたことによるコミュニケーションの取りずらさとコミュニケーションコストの増加がきっかけで、チーム分割を検討し始めました。さらにチームが扱うドメインも増えていくことが見えていたので、当初はドメインに対してチームを割り当てて分割する方法を考えていました。一方その分割の方法では、元々フロントエンドエンジニアの人数が少なかったのでうまく分割できるのかという不安もありました。そういった事情があり、酒井さんと貝瀬さんにどういうチームの分割の仕方が良いのかというところから相談していたのですが、最終的にはドメインに紐づかない2チームに分割するという形に落ち着きました。各チームが取り扱うドメインが複数になるので、「ドメイン知識のキャッチアップが大変になるのでは？」といったところが気になりましたが、チームが1つだった時からやっていたことではあったので、悩みながらも意思決定しました。チーム分割は10月頃から考え始めて、分割後のチーム編成が決まったのは12月頃だったかと思います。チーム編成は全員参加のワークショップで決めたのですが、その取り組みは非常に良かったですね。 伊達EN：当時は「フロントエンドエンジニア」「バックエンドエンジニア」という職種で入社したメンバーが多かったのですが、フロントエンドエンジニアが少ない状況の中で、適切にチームが分割できるのかという不安はありました。田村さんと同じように、今後扱うドメインが増えていったときに適切に対応できるかという点が特に気になっていたところです。 —— 1月からは分割後のチーム活動が始まっているかと思いますが、結果的に当時の懸念は解消されているでしょうか？もしくは解消されていないでしょうか？ 田村PO：まだ動き始めたばかり *1 なので変化が見えきっていないですし、課題はこれから出てくるかもしれないのですが、先ほどもお話したチーム分割のワークショップができたこと自体、非常に良かったと思っています。個々人のスキルを全員で見える化して、どういうふうに組み合わせていけばフィーチャーチームになれるのか？個々人のスキルを伸ばしたり補完し合うにはどうすべきなのか？といった会話をしながら、メンバー全員でチーム編成を決めていけていけたのが本当に良かったです。チームの名前をメンバー自身で決めたのも良かったですね。今後については、チーム単位のスクラムイベントの他にチーム横断の LeSSイベント もやっていくことになるので、チーム横断でも補完しあえる部分が出てくることを期待しています。 伊達EN：チーム分割のワークショップは本当に良かったですね。新チームでの活動は1月から始まったばかりですが、スキルを可視化してお互いへの期待も話し合えたことで、事実、フロントエンドエンジニアとして入社した方がバックエンドのKotlinをキャッチアップし始めていたりします。それ以前は個人的に、「フロントエンドエンジニアとして入社された方にバックエンドの仕事を期待していいのか？」みたいな懸念を感じていました。ワークショップを通じて個々人の得意領域は尊重しつつも、より価値提供・課題解決にフォーカスしていけそうな動きが見え始めているのですごくポジティブな印象を持っていますね。ドメインが増えた時に期待通りに適応できるかというのはこれからですね。 原野EN：伊達さんがフロントエンドエンジニアにバックエンドのことを期待していいのか？という話をされるのは非常に面白いですね。 伊達EN：私はフロントエンドエンジニアとして入社したんですけど、昨年の6月くらいに当時所属していたチームの人数が一時的に減ったことがきっかけで、今はフロントエンドもバックエンドも両方やっているという感じなんですよね。 原野EN：伊達さんは、「自分ができているんだからみんなできたっていいでしょ？」というスタンスでいっても面白かったんじゃないかと思いますが（笑） 伊達EN：もしかすると、私の動きを見てくれていたので、他のチームメンバーも近い動きをしてくれたのかもしれないですね（笑） —— 分割後のチーム名は職種やドメインを使わずに、チームメンバーがアイデアを出し合って決めたということを聞きましたが、2チームともすごく個性的な名前でいいなって思いました。では最後に、12月に起きた変化に関しても聞いていきたいと思います。 まとめ LeSS座談会Part1に引き続き、Part2では導入後に起きた役割や組織構造の変化を紹介しました。座談会の紹介記事はPart3で最後になります。引き続き公開をお待ちください。 *1 : 座談会を実施したのが一月中旬

こんにちは、鄧 皓亢（でん はおかん）です。カイポケリニューアルプロジェクトのアーキテクト兼PdM（プロダクトマネージャー）としてエス・エム・エスに2024年に入社しました。 もともとはバイオ系の研究をしていましたが、「より早く価値を提供できる仕事がしたい」という思いからデータサイエンティストにキャリアチェンジしました。そこから飲食店向けのSaaS開発、CTO経験を経て、データ分析・データ基盤構築の知見を活かし、現在のポジションに至ります。 キャリアの変遷──データとプロダクトの融合へ 最初はバイオ分野の研究をやっていましたが、研究の成果が形になるまでの時間が長いことに課題を感じ、より早いリリースサイクルを求めて飲食店メディアのデータサイエンティストとしてキャリアチェンジしました。 飲食店メディア自体は楽しいですが、需要と供給のマッチングと言いつつ本質的には一部ポピュラーな店舗の在庫がスケーラビリティのネックになりがちでした。一般的にはポピュラーではない店舗の集客をいかに改善する話になりがちですが、個人的に面白いと感じたのはポピュラーな店舗でもその席在庫の管理方法によって無駄にネット予約分の在庫に制限をかけている場合があり、それ自体は管理方法やオペレーション改善によって改善できる部分があると感じました。 そこから、より顧客の課題にフォーカスするために飲食店むけの予約管理とネット予約をSaaSとして提供しているスタートアップに転職して自分で営業・カスタマーサポート・i18nをしつつ海外事業の立ち上げに関わっていました。 その後、当時CTOだった増井さん（ masuidrive ）に誘われて東京本社勤務となり、Salesforce導入・データ分析・データパイプライン構築・新規事業立ち上げ・システム設計など、プロダクトとデータの両面から事業を支える役割を担うようになりました。最終的にはCTOとして活動し、組織全体の技術戦略にも関わることになりました。 エス・エム・エスとの出会い──人と文化に惹かれて エス・エム・エスとの出会いは、田辺さん（ @sunaot ）から声をかけてもらったことがきっかけでした。その後、三浦さんとお話しし、最初は業務委託としてデータプラットフォームチームの立ち上げに関わることに。 立ち上げの経緯は以下をご覧ください。 tech.bm-sms.co.jp 業務委託として関わりながら、データ基盤の整備を進める中で、単なる技術的な課題解決だけでなく、組織の文化や働く人たちの姿勢に強く魅力を感じるようになりました。 僕が今把握している範囲では上場企業のステレオタイプみたいなお堅いイメージは全くなく、業務委託の期間も含めると一年半以上関わってきましたが、現状維持バイアスの塊みたいなものも全く感じませんでした。 スキル的にも優秀な方が多く、個人的にはどうやってこのようなメンバーを集めてきたのか、どうやってこのような文化を定着させたのかに興味を持っており、仕事の合間で深く掘り下げてみようと思いました。こうした環境に惹かれ、最終的に正社員としてエス・エム・エスにジョインすることを決めました。 執筆時点での個人的な仮説ですが、歴史的にカイポケという大ヒットサービスがあり、その設計やスケーラビリティの課題を解決するために今のカイポケリニューアルチームが組織されたので課題解決と現状に囚われない文化が定着したのではないかと考えてます。もしこの仮説が本当だったらリファクタリングはシステムだけではなく、組織や文化に対しても良い影響があることになるので、今まで一部の企業でリファクタリングを忌避していた価値観も見直す必要があるのかなと思います。 現在の役割──カイポケリニューアルを支えるアーキテクト & PdM 現在、僕はカイポケリニューアルプロジェクトのアーキテクト兼PdMを務めています。 アーキテクトとしての役割 カイポケリニューアルでは、システムとチームを細かく分けていますが、アーキテクトとしては組織の形にとらわれず、さまざまなチームと連携しながらシステム設計や開発プロセスを改善する活動を行っています。 tech.bm-sms.co.jp また、技術面だけでなく組織的な課題の改善にも取り組んでおり、技術とビジネスの橋渡し役としての視点を持ちながら仕事を進めています。 PdMとしての役割 プロダクト組織に閉じずに、全社の業務改善を推進するような責務を負っているBPRチームと一緒に、契約管理システムとカイポケの機能を連動させる仕組みを考えたり、今後必要になってくる認証・認可の仕組みをどう設計するかについても企画を立て、よりセキュアかつスムーズなユーザー体験を提供できるように取り組んでいます。 データプラットフォームの視点も継続 さらに、データプラットフォームチームのメンバーとしても引き続き活動しており、カイポケリニューアルによるデータ移行の仕組みを構築。リニューアル後もスムーズにユーザーが移行できるよう、裏側の仕組みを整えています。 まとめ──未来へ向けて 短期的な目標としては、カイポケリニューアルを無事リリースし、安定性・信頼性を担保しながら、ユーザーの声を反映した改善サイクルを確立することです。 しかし、僕が目指しているのは単なる「リニューアル」ではなく、その先にある新しい価値の創出です。 エス・エム・エスにジョインし、技術と組織の両面からのアプローチが、より良いプロダクトづくりにつながることを実感しています。 今後も、データとプロダクトを掛け合わせながら、新しい価値を創出していくことを目指し、引き続き挑戦を続けていきます。 もし興味を持っていただけたら、ぜひカイポケリニューアルに関する取り組みをチェックしてみてください！

合同会社makigai（マキガイ） の貝瀬です。2024年6月からスクラムマスターとして、介護/障害福祉事業者向け経営支援サービス「カイポケ」に関わる組織やプロセスの改善を支援しています。 カイポケリニューアルプロジェクトにおけるLeSS（Large Scale Scrum：大規模スクラム）の適用範囲の広がりとともに、スクラムマスターも組織化しました。2025年1月に、スクラムマスターの1人である福田がファシリテーターとなり、LeSSの実践当事者を集めて座談会を実施したので、その模様をお届けします。 それぞれの立場からみた変化、変化の前後で感じたこと、今後の組織に期待していることなどを聞かせていただきました。 座談会は非常に盛り上がったため複数回に分け、Part1となる本記事では、LeSSの導入から導入後初月までのお話を紹介します。 LeSS導入時の経緯やマネージャー視点でのふりかえりは過去記事をご参照ください。 tech.bm-sms.co.jp tech.bm-sms.co.jp 人物紹介 キム ダソム（以下、キムPO） エリアプロダクトオーナー 田村 恵（以下、田村PO） エリアプロダクトオーナー 原野 誉大（以下、原野EN） エンジニア 伊達 大晃（以下、伊達EN） エンジニア 福田 尚亮 スクラムマスター兼ファシリテーター 貝瀬 岳志 全体のスクラムマスター兼本記事の執筆者 LeSS導入時の印象や期待 —— LeSSの導入に伴ってどのような印象や期待があったのか。まずはプロダクトオーナーの目線から聞かせてください。 キムPO：元々スクラムは導入していたんですけど、私の担当エリアの中でもワークフローが我流になっている部分がありました。ワークフローが組織横断で統一されていく点を最初に期待していました。バラバラになっていることでコミュニケーションのズレが生じていると感じていたので、導入前よりは少なくなるのではないかという期待ですね。 田村PO：スクラムイベント内では完結しきれない、チームを跨いだコミュニケーションが多かったと感じていましたが、そこにかかるコミュニケーションコストが下がっていくことを期待していました。また、私の担当エリアではPBI（Product Backlog Item）の管理方法もチームごとに独自の方法で管理されていました。エリア全体をみる立場としては、ある程度統一されることで、認知コストが下がる点にも期待していました。 —— エンジニアの二人からも同様にLeSS導入時の印象や期待を聞かせてください。 原野EN：LeSSが導入される前の前段として、7月くらいからスクラムイベントのやり方や体制がすごく変わってきていて、大体1ヶ月半くらい立って安定してきたところにまたやり方が変わるのかと、当時は感じていました。現在進行形でもそれは感じていますが、ただそれ自体はネガティブな感情ではなく、右足を出したら次は左足を出す、といったような受け止め方をしていました。もう一点、LeSSが導入される以前からプロジェクトリード（注釈：組織内で独自に定義した役割）という役割を任されていたのですが、最初の期待値よりも上がってきていているのを感じていました。 —— プロジェクトリードは、組織の変化をチームに浸透していくハブみたいな役割もあったんでしょうか？ 原野EN：そうですね。当時はそのような期待があったように感じます。チームとチーム外とのコミュニケーションハブを担っていた部分もあったので、新しいやり方を導入するたびにどのようにチームに説明して進めていけばいいのかを考える機会が多くなったと思います。 伊達EN：自分はプロジェクトリードではありませんでしたが、すでに大きめの組織だったので、LeSSを導入していくという話を聞いたときに、今までのやり方を変えていく上でのハレーションは起きないのか？ということも含めて、楽しみに感じていました。 —— 良い意味で驚いていますが、皆さんポジティブな話ばかりですね。 キムPO：マイナスではないんですけど一点あげると、LeSSの導入にあたって貝瀬さんがまとめて下さっていた会議体の拘束時間を見てやばいなと思いました。個人的には、結果的に拘束時間はグンと下がったと感じています。ただ、固定で開かれる会議体が目の前に可視化されたのを見て、当時はめっちゃ拘束されるじゃん！と感じていたことを思い出しました。 原野EN：自分の場合は、スクラムやLeSSのイベントと、その他の会議で開発の時間がなくなるな、みたいな状況でした。既存の会議にアドオンになるので最初は時間もコストもかかりそうな印象を持っていましたが、関係者間で合意されているならいいのかなと思っていました。仮に開発速度が遅くなったとしても何か言われそうな雰囲気はなかったので、その点はポジティブでしたね。導入前の会議体は徐々にリファインメントなどのイベントにマージされていったので、自分の拘束時間も徐々に減っていったと思います。 LeSS導入後初月に起きた変化 —— ここまでは、LeSS導入前または導入過渡期のお話を聞かせていただきました。実際にLeSSを導入してみて、9月というタイムボックスでのお話を聞かせてください。 原野EN：自分の場合はプロジェクトリードという役割を担っていたことで、LeSS系の全部の会議体に出たり呼ばれたりすることが大きな負担でした。10月以降にプロジェクトリード廃止の動きがあったので、自分の負担はチームに分散されていくことになっていきましたが。 —— 実際にLeSSを導入した後で会議の拘束時間はどうなりましたか？ キムPO：さっきも少し話したのですが、結果的に拘束時間は減りました。固定枠は増えたんですが、臨時開催されていた会議体が複数チームプロダクトバックログリファインメントやオーバーオールプロダクトバックログリファインメントなどの会議体に吸収されていった結果かと思います。 原野EN：慣れていくにつれて、いつどこで何を会話すべきかの目星もつけやすくなりましたね。 キムPO：チームにとっては、スプリントプランニングをしやすくなる効果もあったようにと思います。突発的に発生するミーティングでも、優先順位と自分たちのキャパシティを踏まえて、今このまま話を続けるべきなのか、用意されているイベントの中で話すべきなのかというコミュニケーションが増えた点をポジティブに感じています。 —— LeSS導入前の課題としてあった、チーム間のコミュニケーションロスのようなものに対して良い影響があったんでしょうか？ キムPO：すごく良い影響があったと思います。LeSS導入前の7月・8月あたりでは、とあるPBIの開発に着手することを決めた後、蓋を開けてみたら、他のチームと話して決めないといけないことが出てきたり、先に依存関係を解消しないと進められないことが分かったりと、チーム間を跨いだ課題が私の担当エリアで頻発していました。このオーバーヘッドが原因で、当初立てた計画どおりに進まないケースもかなりありました。同タイミングでPRD（Product Requirements Document）の作成プロセスが整備された影響もあるんですけど、LeSSの導入により複数チームで会話する機会が公式に設けられ、早い段階で依存関係とか結合度合いの確認ができるようになったので、後からオーバーヘッドが発覚することや、不確実性が内在する状態でスプリントを実施する度合いがかなり減ったかなという印象があります。 田村PO：私の担当エリアから他エリアに調整・確認したいことがでてきても、相手が大変そうな時期だと遠慮が先走ってしまうことがありました。エリア間の調整の機会が公式に設けられたことによって、そういった遠慮をする必要がなくなったのは大きいかなと思います。 —— 導入の初月からまさに狙い通りの変化が起きているなという印象を受けました。逆にLeSSを導入した影響で気になるようになったことや、うまく行かなくなったことなどがあれば教えてください。 原野EN：これまで目を瞑っていたようなことが表に出てきた感覚があります。ポジティブなニュアンスなんですが、表に出てきて会話ができるようになった分、スケジュールやリリースターゲットを意識して、向き合う必要が出てきたのかなと思います。今までチームやエリアを跨いで横断的に見えなかったものが見えるようになった結果、気にする対象や視点も広がったのかなと思います。 キムPO：LeSSの導入はワークフローだけではなく組織設計を考えるきっかけになりました。当時はフロントエンドとバックエンドでチームを分けていたので、LeSSを実践するにあたって フィーチャーチーム （注釈：顧客中心のフィーチャをエンドツーエンドで創出できるチーム）が理想だというのは理解しつつも、どうやって変えていけばいいのかをかなり考えました。また、LeSS導入前から定義されていたエリアやドメイン、プロダクトマネージャやプロダクトオーナーなどの役割などをどう捉え、再定義するのかなども考えるきっかけになりましたね。 原野EN：スプリントバックログだけでなくプロダクトバックログもチーム単位でバラバラだったので、どの単位で何を管理するのかという課題も出てきましたね。 —— 9月は出尽くした感じですかね。ではそろそろ10月のお話にうつっていきたいと思います。 まとめ 今回はLeSS座談会で扱ったトピックのうち、導入から導入初月までのお話を紹介しました。私も当日の座談会に同席していましたが、当時の雰囲気を振り返ることによる新たな気づきもあったようで、非常にポジティブな雰囲気でした。続編についても鋭意執筆中ですので公開をお待ちください。

こんにちは。介護/障害福祉事業者向け経営支援サービス『カイポケ』でエンジニアリングマネージャー（以下EM）を担当している小宮山( @Eirandesmsrad11 )です。 先日、Developers Summit 2025に参加しましたので、参加したセッションの感想をレポートします。 event.shoeisha.jp 参加したセッションの感想 自動テストの世界に、この5年間で起きたこと 要約 E2Eテスト界隈における5年間のお話です。資料はこちらとなります。 speakerdeck.com 5年前はE2Eテストの導入に際して「テストコードの作成、テストコードのメンテナンス、テスト実行環境の構築と運用」の3点を課題として挙げる顧客が多かったが、CypressやPlaywrightといった新しいツール群やGitHub ActionsでCI/CDのパイプラインに組み込みやすくなったことで、テストのハードルが下がってきた。 今は「E2Eのカバレッジを上げたいが何をすれば良いか」「どうすれば障害予防に効果があるテストになるか」といったテスト設計に関する課題に変わってきているとのことでした。 これらは非定型の業務で改善が難しかったが、生成AIはこういった業務にも適用可能なため、生成AIを活用することでこれらの課題解決に繋げようとしているそうです。具体的には、文章以外の情報を含む仕様書を分析してテスト設計を行うようなイメージですね。 感想 E2E界隈にも生成AIの波が来ていると感じました。 一方で、E2Eテスト全体で何を保証するために実施するのかという点は、人が継続して考えなくてはならない大事な部分であり、AIを課題解決の手段としてうまく活用していかなければならないという思いを強くしました。 エンジニアキャリア図鑑　～エンジニアリングマネージャー VS テックリード～ 要約 ログラスさんによるEMとテックリード（以下TL）の対談セッションでした。 ざっくりですが、それぞれ以下のような仕事内容とのことでした。 EMの方の仕事内容 スクラムチームのマネージャーとして、チーム全体のマネジメントを行う スクラムイベントでチームに問いかける チームの方向性が会社全体の方針に沿っているか（個別最適になっていないか）を確認する 未決定だが将来必要になりそうな事柄に対して、プロアクティブに対応する TLの方の仕事内容 （ログラスさんの社内ではTLという役割は明確には存在していないそうです） 普段はスプリントに参加して、一人のエンジニアとして働く チーム横断するプロジェクトの立ち上げや参加 事業側と連携して、これから発生するであろう課題に対して先手を打って対策をしておく 感想 EMの実際の仕事内容は組織によって大きく異なるため、ログラスさんの事例を聞けたのは参考になりました。EMとTLがうまく役割分担しつつ協力している様子も印象的でした。 仕事をする中で感じることが近い部分もあり、非常に共感できるお話でしたね。 業務理解の深化と実践～ドメインモデリングで基幹システムを捉える 要約 モノタロウさんの基幹システム刷新推進のお話です。資料はこちらとなります。 speakerdeck.com イベントストーミングに力を入れており、繰り返しながら全員でドメイン理解を深め、モデリングを進めているとのことです。 詳細は資料に記載されているので、ぜひご確認ください。 感想 エス・エム・エスでもカイポケのリニューアルを進めており、同様の事例はとても参考になりました。セッションを聞いていて、進め方が非常に合理的だと感じました。 新システムへの移行は現在進行中とのことなので、移行完了後のお話もぜひ伺いたいですね。 リーダブルテストコード～メンテナンスしやすいテストコードを作成する方法を考える～ 要約 単体テスト、E2E、QAそれぞれの領域に精通されている3名の方による対談セッションでした。資料はこちらとなります。 speakerdeck.com 単体テストおよびE2Eで読みやすいテストコードを作成するための留意点、セルフチェックやレビューの進め方について、具体的な事例も交えながら対談するセッションでした。 たとえば、セルフチェックやレビューの進め方として、最初に個々のテストコードを確認するのではなく、単体テストの場合はテストレポート、E2Eテストの場合はテストシナリオといったテスト設計の確認を先に行う、という提案がなされていました。 また、テストの抜け漏れを防ぐためにAIも活用されているそうです。 感想 具体的なコード例もあり、非常にイメージしやすい内容でした。 t_wadaさんのお話は以前から好んで聞いていますが、今回もテストの重要性を改めて再認識することができました。 急成長する企業で作った、エンジニアが輝ける制度 要約 エンジニアを派遣するビジネスで、成長を促す枠組みをうまく作ることができなかった部分を、VPoEの方が整備していったというお話です。資料はこちらとなります。 speakerdeck.com 具体的には、エンジニアの評価制度やキャリアプラン、ナレッジ共有を通じたチーム醸成の取り組みについて語られていました。 感想 エンジニア経験のない経営層と、どのように共通の見解を持ち、会社の制度として確立していったのかという生々しいお話を聞けて有意義でした。 とても大変だったと思いますが、それでも形にしていける登壇者の推進力の凄さには敬服しました。 目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる 要約 日々の仕事の中で内省とフィードバックのサイクルを回すことで成長できるというお話です。資料はこちらとなります。 speakerdeck.com 具体的には、以下のサイクルを回すことが提唱されていました。 日報でTODOと見積もりを作る（週報でもOK） 実際に自分でタスク管理しながら実施する その日の終わりに結果を振り返る 振り返りをもとにネクストアクションを設定する 感想 セッションのタイトルだけを見ると、ただ頑張って仕事に取り組めば成長できるという印象でしたが、実際には仕事の進め方そのものを仕組み化・改善することで成長につながるという、非常に納得できる内容でした。 全体を通しての感想 まず、生成AIが引き続き熱いと感じました。どの企業の方も生成AIを高いレベルで開発に取り入れるか、プロダクトに組み込んでおり、普及が進むとともに利用シーンも増えている印象です。エス・エム・エスでも、より積極的に活用していきたいと思いました。 こういったイベントに参加して、困難な課題に向き合っている人たちの話を聞くことで、自分も頑張ろうという元気をもらえます。引き続き、参加していきたいです。

はじめまして、全社SREの高橋です。 全社SREでは、組織全体のサービスのリライアビリティとアジリティを向上させるために、横断的な視点で日々活動しています。その取り組みにおいて、「コスト最適化」も重要なテーマの一つです。 今回は、その具体的な施策の一つとして、AWSにおけるコスト最適化を支援する「コスト最適化チェックリスト」についてご紹介します。 はじめに まず、私たちが重視しているのは「コスト最適化」であり、単なる「コスト削減」ではありません。コストは少なければ良いというものではなく、適切な箇所に適切な金額をかけている状態があるべき姿です。「コスト最適化」を通して、無駄なコストの排除だけではなく、必要なリソースに対して適正な料金が発生している状態にし、より効率的な運用を目指したいと考えています。 弊社においてAWSを含むシステムに関わるコスト管理は、多くの場合は各事業部が担当しています。しかし、「どのような観点から最適化を進めればよいかわからない」という声も上がっています。さらに、開発など他の業務に追われ、コスト最適化に十分な時間を割くことが難しいのが現状です。 また、全社SREはAWSの運用やコスト管理に関する知見を一定持っていますが、すべての事業部やサービスを個別に確認するには膨大な時間がかかります。加えて、各事業部の業務内容や計画を詳細に把握しているわけではないため、何が適切か判断するのが難しく、積極的に介入しづらいという課題もあります。 そこで、全社SREでは「コスト最適化チェックリスト」を作成し、各事業部がそれに沿って確認を行うことで、一定のコスト最適化に向けた取り組みができる仕組みを構築しました。 コスト最適化チェックリストとは 「コスト最適化チェックリスト」は、AWS利用料の削減において最低限実施すべき項目をまとめたものです。 このチェックリストを通じて、各事業部が最低限のコスト最適化を実施できるようになっています。 コスト最適化チェックリストの概要 チェックリストは、以下のような項目で構成されています。 コスト管理 コストアラートの設定 コスト最適化ロードマップの実行 アイドルリソースの削除 未使用のEC2インスタンス、EBSボリューム、RDSインスタンス、Elastic IPの削除 スケジューリング 定常稼働が不要なリソースの停止・起動のスケジューリング 料金プランの最適化 リザーブドインスタンスやSavings Plansの活用 中断が許容できる処理ではよりコンピュート費用の安いSpot Instanceの活用 スケールアップ/ダウンを自動ですることでコストメリットが出る場合は、Serverlessを利用 データ転送 リソースの配置を工夫したり、キャッシュを活用するなどしてデータ転送コストの削減 ストレージ ストレージクラスやライフサイクル管理 保管期間の最適 スペックの見直し 過剰なインスタンスサイズの是正 安価でパフォーマンスの良いインスタンスタイプの利用 項目選定において心がけたこと AWSにおけるコスト最適化の具体的な手法は非常に多岐にわたり、すべてをチェックリストとして列挙すると膨大な量になってしまいます。十分に時間を割けない中で「どのような観点から最適化を進めればよいかわからない」という場合、膨大な量のチェックリストだと結局対応が難しいままとなってしまいます。 そこでいくつかの観点で選定を行い、チェックリストとして現実的な内容や項目数になるようにしました。 網羅性 AWSのコストは、特定の要素だけを最適化しても十分な削減効果が得られません。そのため、主要なコスト要因（コンピュート、ストレージ、データ転送、ログ管理、料金プラン）を幅広くカバーし、全体的なコスト最適化を実現できるようにしました。 可視化 網羅的な項目を俯瞰できるようにしたことで、各事業部が行うべきことや気にすべき観点を大まかに把握できるようにしています。 Quick Winと中長期的施策のバランス 短期間で効果を得られる施策（Quick Win）と、継続的な取り組みが必要な中長期的施策をバランスよく含めるようにしています。 即効性のある施策だけでは根本的な改善につながらず、一方で中長期的施策に偏ると効果が出るまでに時間がかかるため、両者を組み合わせることで短期的にも中長期的にもコストメリットを得られるようにしています。 運用負荷と効果のバランス 低負荷な施策と運用の工夫が必要な施策をバランスよく取り入れています。 未使用リソースの削除やスケジューリングなどは手間が少なく、短期間で効果を得られる一方、Savings PlansやGravitonへの移行などは計画的な対応や運用の工夫が求められます。両者を組み合わせることで効率的なコスト最適化を実現します。 AWSのベストプラクティスとの整合性 AWS Well-Architected Framework（特に コスト最適化の柱 ）を参考にしました。また、一部項目はAWS Trusted Advisorの推奨事項からも引用しています。 項目の粒度 具体的に書きすぎると視野が狭くなる恐れがあるため、ある程度幅を持った記載にしています。ただし、非エンジニアでもWeb検索などで情報を簡単に得られるように、関連するキーワードを盛り込むようにしています。 弊社の実態 弊社で利用頻度の高いサービスやコストを圧迫しやすいサービスに特に着目し、優先的に項目に含めるようにしました。 今後の取り組み このチェックリストの回答内容は、全社SREがレビューし、必要に応じて追加のフォローを行っていく予定です。各事業部が適切なコスト最適化を実施できるよう、状況に応じたアドバイスやサポートを提供しながら、実効性の高い運用を目指します。 また、チェックリスト自体も定期的にアップデートしていく想定です。AWSのコスト最適化は、一度対応すれば完了するものではなく、ビジネスの成長やシステムの変化に応じて、継続的な見直しと改善が求められます。そのため、最新のベストプラクティスやコスト管理のトレンドを踏まえながら、常に最適な形に維持していきます。 最後に 弊社のように複数の事業を展開し、さらにマルチアカウントを運用している企業においては、同様の課題を抱えているケースが少なくないのではないかと考えています。特に、期初が4月の企業にとっては、まさに今、予算策定やコスト管理の見直しといった取り組みが本格化する時期ではないでしょうか。 本取り組みが、そうした環境でのコスト最適化に向けた一助となれば幸いです。

株式会社エス・エム・エスのプロダクト推進本部の人事をしているふかしろ( @fkc_hr )です。2025年4月16日から18日にかけて、愛媛県松山市の愛媛県県民文化会館にてRubyKaigi 2025が開催されます。 rubykaigi.org 当日はRubyコミッターの しおい( @coe401_ ) をはじめとする弊社社員が参加予定です。 今回、学生の皆さんのRubyKaigi参加を支援いたします。チケット代や交通費・宿泊費を自己負担することなく、カンファレンスに参加いただけます。 本記事では支援の概要と応募方法についてお知らせいたします。 支援人数 3名〜5名 支援応募条件 RubyKaigiのポリシー（ https://rubykaigi.org/2025/policies/ ）に同意し、技術を楽しんでいただけること 大学、大学院、高専、専門学校に所属する学生であること（学校種別・学部・学科・専攻不問ですが、支援決定の方には学生証等の確認をさせていただきます） カンファレンス終了後、SMS Tech Blog（ https://tech.bm-sms.co.jp/ ）に参加体験記・ブログを書いていただけること tech.bm-sms.co.jp 支援内容 RubyKaigi 2025参加チケット RubyKaigi期間中の宿泊費 ご自宅最寄りの空港からの往復交通費 ※ 経路が空路以外の方は要相談 当日のエス・エム・エス社員との交流にかかる費用（ランチ会、懇親会等） 当日のその他のサポート（楽しんでいただけるよう、必要に応じてエス・エム・エス社員がお手伝いします） 任意：エス・エム・エス社員とのカジュアル面談 支援参加フロー 書類選考 オンラインでの面接（1回） 参加決定 ※ 選考にあたっての必須事項 卒業予定年 GitHubアカウント RubyKaigi参加経験の有無と参加したい理由（簡単な内容で大丈夫です） これまでの制作物やエンジニアとしてのアウトプット（URLや簡単な説明） 応募フォーム 下記リンクから遷移した先に設置されているボタンから入力フォームに遷移し、ご応募ください。 RubyKaigi 2025 学生エンジニア参加支援応募（ https://open.talentio.com/r/1/c/smsc/pages/104418 ） 募集期間 2025年2月16日（日）23:59まで →2025年2月24日（月・祝）23:59まで 最後に 弊社がRubyKaigiをはじめとする技術カンファレンスに協賛や学生支援を行う理由については、下記の記事をご覧いただければと思います。技術を楽しみ、社会に貢献し続ける組織で成長していく醍醐味を知っていただけると幸いです。 tech.bm-sms.co.jp すでにエンジニアとして就業している皆様へ ここまで読んでいただきありがとうございます。弊社では一緒に働く仲間を募集しています。ご興味が少しでもありましたら、カジュアル面談をさせていただけると幸いです。

こんにちは！カイポケリニューアルの開発推進チームでエンジニアをしている @_kimuson です。 カイポケリニューアルのプロジェクトでは、CI/CD ツールとして GitHub Actions を主に利用しています。モノレポを採用していることから、ワークフローファイル数が膨大になっており、手動実行したいワークフローの検索性が課題となっていました。本記事では、この課題を Chrome 拡張機能で解決した方法について紹介します。 問題 GitHub Actions には、ワークフローを手動を実行する機能が提供されていて、わかりやすい例だと deploy などのワークフローでよく利用します。通常、これらのワークフローは以下の流れで実行します。 GitHub Actions のページ（ https://github.com/<owner>/<repo>/actions ）に遷移する ワークフローの一覧から手動実行したいワークフローのリンクをクリック ワークフロー個別のページに遷移し、「run workflow」を押す しかし、ワークフローの一覧については「初期表示では 10 件のワークフローしか表示されず、 Show more workflows ボタンを押すことで 30 件ずつ追加表示される」という仕組み上、workflow 数が多くなるリポジトリでは目的のワークフローを見つけることが非常に困難になります。 実際、モノレポの方針を採用し 150 件以上のワークフローが存在するカイポケリニューアルのプロジェクトでは、目的のワークフローを見つけるには 5 回の追加読み込み+ページ内検索が必要です。 GitHub はこの問題に対してピン留め機能を提供していますが、チーム共有型で上限が 5 件という制限があり、カイポケリニューアルの規模では十分な解決策とはなりませんでした。 Chrome 拡張機能 による解決 これらの課題を解決するため、Chrome 拡張機能を開発し、GitHub Actions ページに新しい UI を追加しました。 主な機能は以下の 2 つです： ワークフローのインクリメンタルサーチ機能 個人単位でのピン留め機能 GitHub の REST API ではなく internal な API を利用して情報を取得することで、Personal Access Token（PAT）の発行なしで利用できる設計で実装しました。 ワークフロー検索機能 本拡張機能の核となる機能はワークフローの検索機能です。 検索機能は以下の方針で実装しています: GitHub 上で .github/workflows ディレクトリのファイルツリーを閲覧するページで使われている API を利用して、ワークフローファイルの一覧を取得する この一覧に対してインクリメンタルサーチを実装する これにより、ワークフロー名の一部分を入力することで、目当てのワークフローを即座に見つけられるようになりました！ ただし、正規の workflow 一覧を取得しているわけではないので Dependabot Alerts のようなワークフローファイルが存在しないものは検索できない (把握できていませんが) 何らかのルールで workflow の出力が制御されている場合、追従できない といった制約があります。 しかし、実際の利用シーンでは概ね困らないだろうなということで許容しています。 個人用ピン留め機能 検索機能に加えて、個人単位でのピン留め機能も実装しました。この機能では、拡張機能の検索結果から特定のワークフローをピン留めすることができます。 チーム全体でよく使用するワークフローは概ね共通していますが、カイポケリニューアルのような複数チームが関わるプロジェクトでは、各メンバーが頻繁に利用するワークフローは異なります。個人単位でのピン留め機能により、このような個別のニーズにも対応できるようになりました。 技術的に気をつけたポイント UI のテーマを GitHub に揃える 私は GitHub のダークテーマを普段使いしているのですが、PoC を作って他の開発者に試してみてもらったところ、デフォルトテーマでは文字が見えないという問題が発生しました。 拡張機能自体でテーマを用意すると煩雑になるので、GitHub のスタイル設定を活用する方針を選択しました。具体的には、以下のような変数を用意してスタイルの適用に利用しています。 export const colors = { textColor : "var(--fgColor-default)" , backgroundColor : "var(--bgColor-default, var(--color-canvas-default))" , buttonBackgroundColor : "var(--button-default-bgColor-rest, var(--color-btn-bg))" , buttonBorderColor : "var(--button-default-borderColor-rest, var(--color-btn-border))" , } as const それぞれの値は GitHub の UI 上で実際に利用されている CSS 変数です。 このアプローチにより、GitHub のテーマ設定を自動的に反映し、統合されても違和感の少ない UI を実現しました。 読み込みは GitHub 全体で行い、MutationObserver でページ遷移を検知する この拡張機能の読み込み設定は以下のようになっています： { "content_scripts": [ { "matches": ["https://github.com/*"], "js": ["src/content/index.ts"] } ] } 当初は https://github.com/*/*/actions のパターンのみを対象としていましたが、GitHub の別のページにアクセスしてから遷移すると発火しないので全体に適用する今の形に変更しました。 ただし、別の GitHub のページで拡張機能を読み込むと、読み込み時に DOM を初期化できないので工夫が必要です。MutationObserver を利用してページ遷移を検知するようにしました。 let oldUrl = '' const observer = new MutationObserver(() => { if (oldUrl !== window.location.href) { oldUrl = window.location.href window.dispatchEvent(new CustomEvent('urlChange')) } }) export const observeUrlChange = () => { observer.observe(document.body, { subtree: true, childList: true, attributes: true, characterData: true, }) } observeUrlChange() window.addEventListener('urlChange', () => { // DOM の初期化処理 // https://github.con/<owner>/<repo>/actions/* の形式なら初期化する }) これにより、Actions ページへの遷移を検知したタイミングで React コンポーネントをマウントできるようにしています。 SPA 的な遷移を行うサイトに UI を拡張機能で追加する場合には、こういった対応をする必要がありそうです。 まとめ 本記事では、大規模リポジトリにおける GitHub Actions ワークフローの検索性の課題を、Chrome 拡張機能で解決した事例を紹介しました！ GitHub の内部ファイルツリーAPI等を利用することで、実装コストを抑えてかつ 別途 PAT を発行せずに利用できる GitHub のテーマの仕組みをそのまま利用することで、GitHub に調和したUIを実現 という感じで、割と使いやすい Chrome 拡張機能になったんじゃないかなと思います。 この拡張機能は「github-actions-search」として公開しています。 Chrome Web Store: https://chromewebstore.google.com/detail/github-actions-search/dpcfpkccefabmlfokoilfejeinconhjm?authuser=1&hl=ja リポジトリ： https://github.com/d-kimuson/github-actions-search 利用もコントリビューションも歓迎なので、同様の課題を持つ方はぜひご利用いただければと思います！

はじめまして、介護/障害福祉事業者向け経営支援サービス「カイポケ」エンジニアの杉浦です。 過去数回に渡り障害児支援領域のリプレースについて説明してきました。 今回は障害児支援領域のリプレースで実施した、旧システムから新システムへのドメインモデルの変更に伴うデータ移行について紹介いたします。 リプレースで行ったこと リプレースでは新たなドメインモデルを設計・構築することを行いました。それに伴い、データモデルも新たなドメインモデルに合わせて変更を行いました。そのため、旧システムのデータを新システムに移行する必要がありました。 また、データベースサーバも変更され、旧システムではAurora MySQLを用いていましたが、新システムではAurora PostgreSQL（Serverless v2）を採用しました。PostgreSQLを採用した理由として、新システムで利用する範囲では機能面で大差がないため今後開発の規模が拡大していく カイポケリニューアル と同じサービスを採用することにしました。 上記により、異なるデータモデル、異なるデータベース間の移行について検討する必要がありました。 データ移行対象 今回のリプレースの対象は「請求機能」であり、その他の機能は旧システムを使い続けます。そのため、新システムに移行するデータは旧システムの請求業務に関わるデータのみを対象とします。請求業務に関わるデータは2015年4月から2023年12月までの8億レコード以上ありました。 次節では実際にこれらのデータをどのように移行していったかを解説します。 手法 データ移行ではいくつかの手法を検討しました。まず初めに検討したのはAWS Database Migration Serviceでした。Aurora MySQLからAurora PostgreSQLへの移行であるため、利用できるのではないかと考えました。しかしながら、新システムでは大きくテーブル構造が変わるため、元々1レコードだったものが複数のレコードに分割されるケースや、逆に削除されるケースなど、複雑な変換を行う必要があったため利用することができませんでした。 次に検討したのが新システムのコードを流用しKotlinで移行のツールを作成することでした。オンラインとバッチの両方を検討しようとしましたが、オンラインでの移行について経験が乏しく、リリースの期間が差し迫っていたため、経験があるバッチ処理での移行を検討することとしました。 当初検討したバッチ処理の流れは次の図の通りです。抽出・変換アプリでは旧DBからデータを抽出し、新DBのテーブルの形式に変換してCSVファイルに書き出します。書込アプリでは出力されたCSVファイルを新DBへ書き込みます。 データ量が多いため、抽出・変換アプリ、書込アプリそれぞれを分割して並列実行することだけ先に決め、その後、書込アプリ → 抽出・変換アプリの順に検討を進めました。 1 . 書込アプリ まずは最もコストの重い書き込み処理について検討しました。 書込処理はPostgreSQLのCOPYコマンドを利用する方法を取りました。COPYコマンドはCSVファイルなどからデータベースに直接データをコピーする機能で、1トランザクションでファイルの内容を高速に格納することができます。 ただし、各種制約であるNOT NULL制約や主キー制約、外部キー制約はかかるため、あらかじめCSVのデータは格納するテーブルの制約を守った状態で作成しておく必要があります。なお、KotlinからはJDBCドライバのCopyManagerクラスを用いることでCOPYコマンドを扱うことができます。 2. 抽出・変換アプリ 新システムはドメインモデルに合わせてテーブル設計が行われており、旧システムとは乖離したテーブル構造になるため１対１の変換はできません。 そこで、旧テーブルの各カラムを新テーブルのどのカラムにマッピングするか、移行する際のルールはどうするかを図にまとめながら変換の設計を進めていきました。 上記の図は、前回の記事『 カイポケ障害児支援領域のリプレースで実施したドメインモデリング 』で説明したドメインモデルである「学校休業日」の移行の設計図になります。このような設計を各ドメインモデルに対して実施していきました。 3. 主キー採番アプリ、シーケンス更新アプリ 書込アプリでは前述したようにCSVを作成した段階で外部制約を守った状態にする必要があります。ただ、変換処理は分割して並列実行するため、主キーを重複せずに採番することが課題でした。KVSを採用することで重複せずに採番できると考えましたが、令和6年4月の法改正が控えているためリリースまで時間がなく、今回の構成ではKVSを採用していなかったことからリスクが高いと判断し見送りました。そこで、抽出後の分割されたCSVファイルを読み込み採番を行う主キー採番アプリを作成しました。 また、COPYコマンドではシーケンス番号の更新処理は行われないため最後にシーケンス番号を更新するアプリを追加しました。 最終的なバッチ処理のステップは次の図のとおりです。 移行結果の検証 リプレースではデータベースの構造が大きく変更されたため、データが正しく移行できているか検証する必要がありました。今回のリプレースは請求機能に特化していたため、過去に旧システムで計算済みの請求結果と新システムで計算した請求結果に差異がないことを確認する作業を行いました。 検証作業では、小さな不一致から大きな不一致までいくつかありましたがチームメンバーと協力し原因を究明し修正を行い、最終的に移行結果が正しいことを確認しました。 移行作業 移行は事前移行と当日移行の２ステップで行いました。リプレースを行うシステムは請求業務という特性上、一度請求を確定したデータに関しては金額の修正が発生しない限りは格納されたデータに変更はありません。そのため、金額の修正が発生しづらいデータに関しては事前に移行し、金額の修正が発生したデータに関してはリリース日に行う当日移行としました。この事前移行により当日移行のダウンタイムを最小化することができるメリットがありました。 事前移行は稼働前の新システム側のデータベースに、旧システムのデータベースのリードレプリカを作成し、10時間をかけて移行を行いました。事前に本番想定のリハーサルを何度か実施し、バッチ処理のバグ修正や移行時間の計測を行ったため、致命的な問題なく事前移行を完遂することができました。 リリース当日は移行以外にも旧システムからの切り離しなどがあることにより、システム全体を6時間停止する必要があるため、利用者が少ない休日の昼間にリリースを行うこととしました。移行は当初の見積通り2時間程度で完了し、システム全体では4時間半の停止でリリースを終えることができました。 リプレースを終えて リプレースから1年が経過し、本記事を執筆するまでデータ移行にまつわる問題は1件も発生しませんでした。これはひとえにチームメンバーの協力があったからに他なりません。移行検証は私が中途入社して3ヶ月目から携わった内容でした。ドメイン知識はありませんでしたが、Slackで気軽に質問できる環境やドキュメントを残す文化があったおかげでキャッチアップに苦労はありませんでした。その中でもドメイン設計のドキュメントは意思決定のプロセスが図表で残っており、お客様の業務フローから考えられる最適な解をチームで検討していることがわかりました。エス・エム・エスはお客様に向けてよいプロダクトを提供したいという意思を全員が持っており、各々がメンバーの作業をフォローする意識があると感じました。 これからもチームで協力して難易度の高いお客様の課題を解消していきたいと考えています。

はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」の介護レセプトチームで働いている沖口です。介護レセプトチームは3つの独立したサブチームで開発を進めており、今回は1つのサブチームの活動として行ったチームビルディング活動について紹介します。チーム内ではこのサブチームを班と呼んでいるため、本稿でも「班」「チーム」で呼び分けを行います。 チームビルディングを行う前の課題感 私の所属している班は日々の開発プロセスに従い開発は進められはするものの、私の主観では「チームメンバーへの頼りにくさがある」「各メンバーもチームで仕事をする時、やりにくさを感じているのではないか」と感じる場面がありました。 頼りにくさ、やりにくさは例を挙げると以下のようなものがあります。 相手が忙しいかどうかわからないため、話しかけにくく、自分で時間をかけて調査をしてしまう... 相手の得意・不得意なことが把握できず、頼るべきか迷ってしまう... 不得意なことを周囲に共有しにくく、その分野でサポートを受けにくい... 施策を前に進める役回りが固定化しているので、進行役やサポート役に自発的に手を挙げてくれると嬉しい... これらの状態が少しでも良くなればと考え、課題の整理と具体的に何をするかを検討し始めました。 個人で課題の整理 なぜ改善を行いたいのか目的を整理する まず手始めに現在プロセスに従って開発はできている中で、なぜ改善を行いたいと考えているのかを考えることにしました。「やりにくさを解消したい」を目的に置くのではなく「やりにくさを解消した結果どうなりたいか」を考えてアウトプットしていきます。 ここでのアウトプットは最終的に班の理想の状態として一つにまとめ、後続のギャップや具体的な理想的な行動を考えるためのインプットとしました。 理想の状態と現在のギャップを整理する 理想の状態と現在のギャップについて整理していきました。主観ではありますが、自分の考えるチーム活動はこうなんだけど班ではうまくできていないなと感じる部分を出していきました。 チームビルディングを行う前の課題感で上げた「頼りにくさ」「やりにくさ」と言った部分がこのタイミングで言語化できました。ギャップを整理する際にセットで、具体的にどのように行動できていれば理想的なのか？についても挙げ、解像度を高めることができました。 改善活動を想像しながら列挙する 班がどういった活動であれば目的にあった改善に向かうのかを想像し、チームビルディング手法にとらわれず雑多に列挙しました。具体的なチームビルディング手法については同僚と会話をした上で決定することを考えていたため、ここでは会話ができる程度に以下のアウトプットをしました。 チームビルディングのイベントが、一方的に情報や意思決定を伝える場ではなく全員が意見を出し合う場になっている どんな状態なら今より良くなる？どんな所に不安を感じる？と言った普段しない会話をしている 会話の結果、良いチーム・良いチームの行動をドキュメントにまとめて見返せるようになっている 同僚とチームビルディングイベントの設計 同じ班のKさんと別の班のチーム作りが得意なHさんに協力して貰い、miroを読み合わせながら私の課題と感じる部分について会話しました。私の考える課題やそのギャップについて深掘りや認識違いがないか、班ではどのようなチームビルディングの手法が適していそうかについてフィードバックを貰いました。 (グレーの付箋はフィードバックの数々) 同僚との会話の結果、以下のチームビルディングを行うことにしました。 ドラッカー風エクササイズ を班で会話しやすいよう質問項目をカスタマイズした上で実施する ドラッカー風エクササイズで会話したことも踏まえながら、良いチームと思う行動をメンバーで書き出す会を実施する チームビルディングの実施 班の当事者である私も会に集中できるようにと、別班のHさんに会の開催及びファシリテーションを請け負ってもらい、チームビルディングを実施しました。 チームビルディングの説明 まずはチームビルディングを行う目的・背景を参加メンバーに共有しました。課題の整理や同僚のFBも踏まえ最終的には以下のように書き出して共有しています。 ⚪︎目的 班で働く人がユーザーへの価値提供までの道のりを不安なく、自信を持って進められるようになっていきたい ⚪︎分解 メンバーやチームへの期待、不安を知り、一緒に働く人の考えも知った上で一緒に仕事をしているチームを作りたい 個々がサポートを信じて自分で進められる信頼関係のあるチームを作りたい ⚪︎背景 今チームビルディングをしたいのは、現状より少しでも価値提供のしやすい土台を強めていきたいと思っていて、そのために必要なのは一緒に働く人やチームの考えを知って協力しながら仕事を進めていくことだと考えている お互いを知っていれば以下のことに悩まずに一緒に仕事ができる これを依頼するの、大変かもしれない 自分としては大事だとおもったけど自信がない 小さいことで頼りにくい 時にはこれまでやったことがない仕事も進んでやってみて、必要な時には信頼できるメンバーに頼る こういった信頼関係を作って円滑に安心できるチームになっていくといいなと思っている ドラッカー風エクササイズの説明 次にドラッカー風エクササイズの実施についての説明を行いました。ドラッカー風エクササイズについては目的やゴールイメージに合わせて項目を一部アレンジしています。 ⚪︎目的 思い込みをなくし、お互いを知り、期待を伝え合う ⚪︎ゴールイメージ 相手に期待していることを伝え、期待されていることを認識すること 各メンバーの考え、得意なこと、不得意なことを知り自分以外のメンバーのことを知る 得意なことは頼る、苦手なことは助けるといった行動ができるようになる ⚪︎実施内容 以下の項目について各自事前に記載 得意なこと、好きなこと 苦手なこと、うっとなること 自分はどのようにチーム・班に貢献していきたいか それぞれのメンバーに期待すること(他メンバーへの期待を一人ずつ書く) 会では読み合わせを行いながら質問や会話をすることで理解を深める ⚪︎グランドルール 安心してこの会に参加して会話できるように以下を意識して参加する 少しでも良くするための活動であり、お互いや現状を非難するものではないです！ 会話が大事なので小さいことや重複する意見だと感じても積極的に会話に参加して欲しいです！ できるだけ質問をしてみましょう！ お互いの考えを否定せず、考えについて質問をしたり異なる意見について会話してみましょう！ 不安や悩みはウェルカムです！不得意なことを周りがサポートしやすくなります！ ドラッカー風エクササイズの開催 （ドラッカー風エクササイズの風景） ⚪︎読み合わせ 一人ずつ自分の得意と感じていること、苦手と感じていること、どのように貢献したいと思っているかを話していきます。その後、期待することについては記載したメンバーが本人に対して賞賛し、ネガティブなFBも交えながら期待することについて伝えていきました。 今回は会話することが重要と考え、制限時間を設けずに実施しました。 ⚪︎会話 会の雰囲気は最初は緊張感もありつつ、参加者全員が一人一人の記載について意見を出していく形で終始記載内容について会話がありました。 以下のような会話をもとに参加者が深掘りのコミュニケーションが行われました。 得意/苦手だと思っていた 得意/苦手だと知らなかった 得意なことに書いてないけどこれも得意じゃないですか？ こういった部分でも貢献してると思う 期待のパートでははっきりと期待を伝えるということを各自行っており前向きに会話がされていました。 期待されていると知らなかったので次からやる 今はできていないけど目標にしようと思った この期待されている部分は苦手なので何を求められてるのか確認したい 言われて気づいた ネガティブなフィードバックについても、ネガティブなフィードバックも前向きに捉え改善のために会話を行うことができました。 受けた側は反論をせず学びとなる部分や改善方法について会話をする 普段のコミュニケーション齟齬から受けたネガティブフィードバックについては受けた側から意図を説明を行い、フィードバックを行った人が納得して次から気にならなくなる 冒頭に挙げたチームビルディングを行う前の課題感についても期待として率直に伝え合うことで各メンバー同士で認識を合わせることが出来ました。 良いチームや良いチームの行動をまとめる会の開催 ドラッカー風エクササイズでお互いを知り、期待を伝え合うことが出来た雰囲気のまま、各自が良いチームや良いチームと思う行動を出し合い、班の行動規範としてまとめる活動をしました。 ⚪︎意見を出し合って分類 参加者で各々が考える良いチームについて自由に意見の付箋を書き出し、付箋について感想や別の考え方について会話しながらカテゴリごとにまとめていく活動を最初にしました。 ⚪︎完成イメージ 活動の成果 参加者したメンバーは会を通して得たフィードバックをもとにできることから改善活動をしており、冒頭に挙げた「チームでの仕事のしにくさ」は改善していると感じています。特に積極的に発言をして関わるなど、できるところから仕事をリードする姿勢は班の中の行動として現れてきておりチームビルディングをした効果を実感できています。コミュニケーション不安や苦手な部分を補うことに躊躇はなくなり、今後ユーザーへの価値提供に集中するための土台ができたと感じています。 会を通しての参加者の反応 活動の学び 私がチームビルディングの実施前に課題と感じていた部分は蓋を開けてみると「期待を率直に伝え会話をする」ことで改善に向かうものでした。参加者が各々勇気を持って期待やネガティブフィードバックを率直に伝え、会話をすることが出来たため効果が現れたのだと思っています。共に働くメンバーとコミュニケーションをとる大切さについて再認識できる良いきっかけでした。 また、今回良かったことの一つとして会の設計段階で班内、班外のメンバーに意見を聞き具体的な会を設計したことがあります。準備段階で一人で考えたことの方向性は誤ってないか、どうしたら改善に向かうのかについて会話をすることで班に向いているチームビルディングを設計できることが出来たと思っています。 今後はチームビルディングの場に頼ることなく、班の中で期待や考えを伝え合い振り返り・改善していけるようになれたらと思います。

こんにちは、カイポケ開発部の城内と、株式会社グッドパッチUIデザイナーの乗田拳斗です。 現在、エス・エム・エスはグッドパッチと介護/障害福祉事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトを行っています。今回は本リニューアルプロジェクトにて行っているエンジニアとデザイナーの連携についてご紹介します。 エス・エム・エスとグッドパッチの取り組みについてはこちらのブログもご覧ください。 goodpatch.com 背景 カイポケは15年以上の歴史の中で介護事業のさまざまなサービス種類に対応を進め、現在は4万を超える事業所へサービスを提供しています。 高齢化が進む日本社会では、介護領域の制度改正やそれに伴う現場対応など、目まぐるしい変化が起こり続けており、こういった介護業界の変化や数年に一度行われる法改正へ対応していくことが求められます。 カイポケはモノリシックなアプリケーションとして構築されてきたので、拡張に次ぐ拡張でさまざまな機能が複雑に絡み合う大きなプロダクトになっています。今のカイポケは現在の介護事業を支えるプロダクトになっていますが、長期的なタイムスパンでこれらの法改正などの要望に応えていくことを考えた場合に、より良いシステムのアーキテクチャにすべく改善プロジェクトのチームで検討を重ねてきました。 これらの背景から、システムを改修する際の修正範囲の局所化と新しいサービス種類への対応などといった拡張性の担保、生産性向上のための並列性の確保を目的にマイクロサービスアーキテクチャへ移行を進める「カイポケリニューアルプロジェクト」を取り組んでいます。 カイポケリニューアルプロジェクトの詳細やフロントエンドチームの技術選定についてはこちらのページと記事をご覧ください。 careers.bm-sms.co.jp tech.bm-sms.co.jp デザインシステム 現在のカイポケは1000ページ以上ある大規模なプロダクトです。長年の機能追加によって改修の影響範囲が見えにくくなり、部分的な改修が続いた結果、全体的に一貫性が損なわれ、少しずつ機能が異なる同じようなページが増えていきました。 今回の改善プロジェクトではこの1000ページ以上のユースケースを整理し、プロダクトの構造を再設計しながらページ数を削減する作業を行いました。 一方、現在のカイポケと同様に機能追加によってページが増えることが想定されるため、さまざまな変更が行われても一貫したUIを維持するための仕組みを構築する必要がありました。 そこで、今回のリニューアルプロジェクトは大規模なプロダクトを円滑に開発し、将来の運用コストも下げるために「デザインシステム」を構築しながら行いました。 プロジェクトチームではデザインシステムがチームとプロダクトの利用者の双方に価値をもたらすために、デザインシステムを構築・運用する目的を3つ設定しました。 作業の効率化 意思決定の効率化 価値の最大化 これらの目的を達成するために、まずは最も多くのメンバーに価値をもたらすプロダクトのコンポーネントライブラリから構築を開始しました。 デザインシステムの構成や方針については、こちらの記事もご覧ください。 note.com 運用中のデザインシステムのドキュメント Figmaライブラリ コンポーネントライブラリを用意するに際して、従来からUIデザインに使用していたFigma上でライブラリの構築を開始しました。 まずはデザインとフロントエンドとの連携を強化し、作業と意思決定の効率化を達成することを目的に、基盤に据えるフロントエンドライブラリの選定からスタートしました。後述する選定プロセスの結果、フロントエンドライブラリにChakra UIを選定しました。 実際にコンポーネントを設計するフェーズでは、Chakra UIのAPI仕様書やソースコードを参照しながら、チームで用意したいコンポーネントがChakra UIで提供されている場合はそのコンポーネントのプロパティ名やエレメント名に準拠したり、フロントエンドエンジニアと議論を重ねながら構築を行いました。 ボタンコンポーネントのプロパティの例 テーマ（デザイントークン）についてもコンポーネントと同様に、Chakra UIのテーマの構成を参照しながら、カイポケのブランドに沿ってカラーやタイポグラフィ、Border Radiusなどの定義を行いました。 Primitive Colorの例 デザイナーがフロントエンドライブラリを確認して、その内容に合わせながらFigmaライブラリを構築するプロセスは決して簡単なものではありませんでした。 一方でその成果として、フロントエンド側との連携が強固なFigmaライブラリを構築することができました。エンジニアと共創する際には共通のコンポーネント名やそのプロパティ名を使用して齟齬なく会話ができる他、UIデザインを実装したり、その成果物をレビューする際にも要素を読み替えることなく連携できるため、作業と意思決定の効率がリニューアル前に比べて格段に向上しました。 Chakra UIの選定 デザインシステムのフロントエンドの開発は2022年から開始しました。デザインシステムを実装するにあたり、0から自分たちでコンポーネントを実装する方法もありましたが、開発効率と品質向上のため、既存のUIライブラリを活用する方針を選びました。その中で、UIの一貫性とアクセシビリティ、広く使われていて開発速度を優先するという当時の要件に最もマッチしていたことから、Chakra UIを選定しました。 ※この記事執筆現在、Chakra UIはv3系がリリースされていますが、選定当時はv2系でしたので、これから記載する内容はv2系を前提としたものになります。 主な理由としては以下の点が挙げられます。 標準でモーダルやテーブル、レイアウト系のコンポーネントが整っている カラーやタイポグラフィ、スペーシングの値などのデザインルールが定義されている アクセシビリティが考慮されている Propsでスタイルを記述できて、拡張が容易 Figmaが提供されている 特に優れていると感じたのは、Propsでスタイルを直接指定できる点と、テーマの管理や拡張が非常に簡単でスマートな点です。この機能により、デザインの一貫性を維持しつつ、開発スピードが大幅に向上しました。 Chakra UIの各コンポーネントは、デフォルトのスタイルを持ったUIライブラリですが、このデフォルトスタイルは、Themeを使用して上書きすることが可能です。各コンポーネントの構造（Anatomy）が定義されており、それぞれのパーツに対してスタイルを柔軟に上書きできるようになっています。 Alertコンポーネントの例: https://v2.chakra-ui.com/docs/components/alert/theming より引用 Chakra UIの選定の際には、デザイナーがFigmaでデザインしたUIを Chakra UIでプロトタイプ実装をして、Chakra UIのThemeのカスタマイズで対応できることを確認しました。 また、Chakra UIのコンポーネントはアクセシビリティが考慮された設計がされています。例えば、モーダルやドロップダウンといったインタラクティブなコンポーネントは、キーボード操作に対応しており、適切にフォーカスが移動します。特にモーダルでは、フォーカスがモーダル内に留まる「フォーカストラップ」が実装されており、キーボード操作で誤ってモーダル外部にフォーカスが移動してしまうことを防ぎます。これにより、アクセシビリティが向上し、UI操作が一層スムーズになります。 こうしたアクセシビリティ機能を自前で実装すると大きな工数がかかりますが、Chakra UIを利用することで、これらを簡単に取り入れることができ、開発リソースをサービス固有の提供価値につながる開発に集中させることができました。 デザインと同期したコンポーネントの実装 前述の通りChakra UIはThemeという構造を持っていて、コンポーネントごとのスタイルだけでなく、デザインシステムで利用されるカラーやタイポグラフィ、スペーシングといったグローバルトークンやセマンティックトークンを定義することも可能です。 Default Theme - Chakra UI 今回のプロジェクトでは、デザインシステムの構築にこのThemeの機能を利用しています。Themeとして定義できるプロパティはStyled Systemの仕様に定義されていて、この仕様にあるプロパティであれば、デザインシステムに合わせた値を設定することができるようになっています。 ここで定義したトークンがエディタ上で補完されると便利です。Chakra UIはThemeから補完するための型定義ファイルを作成するCLIを提供しています。 CLI - Chakra UI このCLIをnpm scripts等で実行することで、補完に利用できる型定義ファイルを作成してくれます。 // package.json { ... "scripts" : { ... "theme" : "chakra-cli tokens path/to/theme.ts" , "theme:watch" : "chakra-cli tokens path/to/theme.ts --watch" , } , ... } また、コンポーネントのPropsの名前や値はFigmaのComponent Propertiesと揃えています。 これにより、フロントエンドエンジニアはFigmaで参照したComponent PropertiesをコンポーネントのPropsに設定することで、Figmaと同じ見た目のコンポーネントを実装できる状態になっています。 StorybookとChromaticを活用したUI変更の自動検知 デザインシステムのコンポーネントは、見た目の変更がアプリケーション全体に波及するため、コンポーネントを変更した際の影響範囲を把握することが重要です。そこで、今回のプロジェクトではChromaticを活用してVisual Regression Test（以下VRT）を自動化しています。 www.chromatic.com ChromaticはStorybookをベースにしたUIテストのサービスです。 Storybookで作成したUIコンポーネントのVRT、UIのレビュー、GitHubやFigmaとの統合などができるようになります。Chromaticと連携するとStorybookのホスティングもやってくれるので便利です。今回のプロジェクトでは、ChromaticとGitHubを連携させてVRTとStorybookのホスティング環境として利用しています。 Chromaticは、Storybookに登録されたコンポーネントをレンダリングして、ベースブランチとの見た目の差分を検出して画像として表示してくれます。 左側の画像が基準となるベースラインで、右側が新しい変更の画像で緑の部分が差分です。: https://www.chromatic.com/features/visual-test より引用 今回のプロジェクトでは、Storybookをすでに導入していて、デザインシステムのコンポーネントはもちろん、アプリケーションを開発しているフロントエンドエンジニアも機能開発中に利用しており、ページやUIのカタログ化とデザイナーやPdMがUIの挙動を確認する際に利用しています。既に構築されているStorybookの資産をそのままChromaticに活用することで、デザインシステムのVisual Regression Test用の実装コストを最小化しています。 GitHubでプルリクエストを作成するタイミングでChromaticのVRTを実施するようにしていて、プルリクエストで発生したコードの差分が、UIとしてどのような差分を発生させるかを確認できるようにしています。開発の規模が大きくなってくるとコンポーネントの依存関係が複雑になってくるので、そのような変更をキャッチしてくれるのは安心です。特にデザインシステムのコンポーネントの修正は、それを利用しているアプリケーション全体に影響が発生する可能性があるため、ChromaticのVisual Regression Testがあることで、意図しない変更が発生した場合に気づくことができるので、リファクタリングを行う際にも非常に有用で心理的なハードルも下げてくれます。 こうした運用により、デザインシステムの改修がアプリケーション全体に与える影響を素早く検知し、視覚的な変更点をチーム全体で確認することが可能な構成をとっています。デザインシステムがアプリケーションの中心的な役割を果たすようになるにつれ、こうした可視化・検証プロセスは、品質を維持するために欠かせないものとなっています。 おわりに 今回紹介したデザインシステムをプロダクト開発に活用した結果、「作業の効率化」「意思決定の効率化」「価値の最大化」というデザインシステム構築時に目的として定めた3つの効果をチームで享受できました。 しかし、依然として解消したいチームの課題は多く残っている状態です。デザインシステム構築前と比較すると作業効率は格段に向上しましたが、その一方で、私たちが達成したい目標と現在の状態を比較するとまだ大きなギャップが存在します。 現在は開発しているプロダクトの良い体験をチームの誰もが簡単に再現するための仕組み作りや、今よりも更に効率的にプロダクトをデザイン・開発し、ユーザーへ最速で価値を提供するための仕組みを構築することに着手しています。 エス・エム・エスではデザインシステムに興味がある開発メンバーを募集しています。カイポケでのデザインや開発に興味を持ったり、チャレンジしてみたいという方がいれば、ぜひこちらも覗いてみてください。またカジュアルに話だけ聞いてみたい、といった方も大歓迎です。こちらのページよりお気軽にご連絡ください！