合同会社 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つの効果をチームで享受できました。 しかし、依然として解消したいチームの課題は多く残っている状態です。デザインシステム構築前と比較すると作業効率は格段に向上しましたが、その一方で、私たちが達成したい目標と現在の状態を比較するとまだ大きなギャップが存在します。 現在は開発しているプロダクトの良い体験をチームの誰もが簡単に再現するための仕組み作りや、今よりも更に効率的にプロダクトをデザイン・開発し、ユーザーへ最速で価値を提供するための仕組みを構築することに着手しています。 エス・エム・エスではデザインシステムに興味がある開発メンバーを募集しています。カイポケでのデザインや開発に興味を持ったり、チャレンジしてみたいという方がいれば、ぜひこちらも覗いてみてください。またカジュアルに話だけ聞いてみたい、といった方も大歓迎です。こちらのページよりお気軽にご連絡ください！

この記事は 株式会社エス・エム・エス Advent Calendar 2024の12月25日の記事です。 介護/障害福祉事業者向け経営支援サービス「カイポケ」の事業責任者をしている園田一誠と申します。 2024年現在、SaaSのソフトウェア事業は数多く存在し、Vertical SaaSの中でも規模化したサービスも増えてきました。 Vertical SaaS事業は、BizとTechの総合格闘技で、事業面（セールス、マーケティング、サポート、事業開発）、資金調達、プロダクト開発（特定ドメイン知識をもとにしたプロダクト開発、スケーリング対応、etc…）など､変数が多く、非常に難易度の高い取り組みです。先日の ALL STAR SAAS CONFERENCE 2024 のイベント（私は行ってないですが会社の人が参加していた）では、Money Forward, LayerX, SmartHRといった、名だたるHorizontal SaaSの企業様が、各種ケーススタディを公開し、多くのリスナーが聴取していたと聞いています。 今でこそ、カイポケは118億円（ 2025年3月期計画 ）と、日本最大級のVertical SaaSに成長しましたが、順風満帆というわけではなく、事業運営、及びプロダクト開発において、数多くの失敗と試行錯誤を繰り返しています。また、2006年の事業開始から黒字化まで9年かかったという事実も有ります。そこで、一つのケーススタディとして、カイポケ18年間の歴史を、事業サイドとプロダクト開発サイドの両面から焦点を当てて執筆します。Vertical SaaSの運営をされている方や、プロダクト開発に関わっている方の参考になればと思います。 目次 カイポケの特徴と顧客数推移 カイポケの歩み（歴史年表） 2005年-2006年　事業構想期間 2006年-2007年　OEMでの参入 & 中小介護事業者の経営支援の構想 2008年-2013年　自社製品の投入 & コストリーダーシップの追求 2014年-2019年　内製化の戦い & 値上げによる収益化とサービス拡充 2020年‐2024年　技術的負債の解消 & 障害福祉領域への拡張 後から振り返っての感想戦 歴史から学んだ事 今後のカイポケのチャレンジ カイポケの特徴と顧客数推移 「 カイポケ 」は介護/障害福祉事業者向けの保険請求・業務管理ソフトウェアです。福祉業界というVerticalな市場において、 SaaS（ソフトウェア）だけでなく、人材、金融、購買、M&A支援等、多様なサービスを持っている 事が特徴です。顧客は、10-20名程度の中小事業所が多いです。 2025年3月期 第2四半期 決算及び会社説明資料より引用 ソフトウェアの有料契約顧客数（事業所数）の推移は下記の通りで、概ね順調に推移していますが、後述するように、途中に一度だけ顧客が離反したタイミングがあります。 直近の決算では、53,100事業所を超えています が、シェアとしては15%程度と、トップシェア群の1つではありますが、まだまだ拡大余地は大きいです。 過去のIR資料より筆者作成 ※2023年4月より事業所数計算の定義を変更している（一般的な定義に変更） カイポケファミリーの売上推移は下記の通りで、概ね順調に推移し、近年では成長が加速しています。 売上の伸びている理由としては、新規のソフトウェア導入数が増加しているだけでなく、周辺の経営支援サービスのクロスセルが順調に進んでいるという2点によるものです。 過去のIR資料より筆者作成 ※25年3月期は、2024年3月期末における計画値 カイポケの歩み（歴史年表） 2005年-2006年　事業構想期間 2000年に介護保険法が施行され、民間企業の介護事業への参入が認められました。国も介護の提供体制確保のために支援を行い、「これからの成長産業は介護だ！」という勢いも有り、民間からの新規参入が相次ぎます。 民営化以前から事業を行っている有力な介護ソフトのプレイヤーも存在し、既に一定の市場シェアを取っていましたが、介護ソフト未導入の事業所もまだ多く、余白も存在していました。2000年〜2010年頃は、高価格なオンプレミスのシステムがほぼ100%で、高価格、高い初期設定費用、長期（5年以上）のリース販売方式、代理店メインの販路、etc…と、小規模の事業所が使うのは難しい状況でした。 エス・エム・エスは2003年に創業され、既に看護師/介護従事者のキャリア事業を開始していました。そして、かなり初期（創業から数年以内）のタイミングから、「成長産業の介護領域における業務支援ソフトや経営支援サービス」に関する構想は存在していました。 2006年-2007年　OEMでの参入 & 中小介護事業者の経営支援の構想 低価格で色々なサービスが総合的にあるという形で、2006年に後発参入したのが「カイポケ（当時は「カイポケビズ」という名前だった）」です。創業者の肝入りで、「介護ソフトだけでなく様々な介護事業所の経営を支援するサービスが有る」というコンセプトでカイポケはスタートしました。一番最初のプロダクトは、自社ソフトではなく、他社ソフトにカイポケビズという名前をつけたOEM商品でした（初代カイポケ）。 OEMで販売しながらリサーチも行い、数年間小規模にトライアルを続けた結果、「クラウドで安価なレセプトソフトが有れば行けるのではないか？」という仮説が生まれ、エス・エム・エスは自社商品の開発をする事を決めました。 OEM時代の初代カイポケ 2008年-2013年　自社製品の投入 & コストリーダーシップの追求 創業から5年後の2008年4月に、エス・エム・エスはマザーズに上場します。 OEMから自社ソフトに切り替えるべく、自社ソフトの開発に取り組みますが、エス・エム・エスは業務ソフトの開発経験が無かったので、外注メインで開発を行い、2008年にPHP製の2代目カイポケがリリースされました。しかし、ソフトのクオリティが低く、結局その後、オフショア（ベトナム）の協力を得てソフトの作り直しを行います。そして、早くも2011年4月にはJava製の3代目カイポケ（現在のバージョン）がリリースされます。 コストリーダーシップ戦略を選択して、圧倒的に低い価格（単価3,000円程度と競合と比較して10分の1以下）で市場シェアを伸ばしました。その単価の低さから、売上は数億円で収益化は難しい状態でしたが、シェアを取った段階である程度の値上げを行う事、及びカイポケを日常的に使ってもらい、その顧客に対して求人広告等を売る、というモデルで進んでいました。 当初より、経営支援という、レセプト＋αという方向を目指していましたが、レセプトの開発と運営が想定以上に大変で、この段階ではレセプトの販売に留まります。また、顧客の日々の業務の忙しさから自力でのソフト導入に挫折する事業所が一定数存在していた事から、セルフでの販売だけでなく、セールスやサポートにも注力する必要が有る事も、大きな課題として捉えられていました。 短命に終わった2代目カイポケ 3代目カイポケ（2011年時点） 2014年-2019年　内製化の戦い & 値上げによる収益化とサービス拡充 この時期に、主要なソフトウェア以外のサービス（開業支援、購買支援、営業支援、ニュース、求人、記入事業等）が開始され、当初から掲げていた経営支援サービスというコンセプトが一部実現します。「サービスが増えて価値が上がった」という事で、3,000円→20,000円という大幅な値上げを実行。それにより収益化は成功しますが、既存顧客の一部は離反する事となります。 収益化した事により、セールス、マーケティング、サポートも手厚く行う事ができるようになり、ビジネスを担当する社員の数も2012年の20名程度から、2015年には130名程度まで増加します。成長は再び加速しました。 一方、サービスや機能を急速に増やした事によるソフトウェアの複雑化、利用者の増加による負荷の増大など、新たな課題も発生しました。また、開発体制的にもテストエンジニアを合わせると総勢100名を超え、それとは別にオフショアの開発チームがいるという状況で混迷を極めていました。その頃、 @sunaot が入社し、2015年よりエンジニア組織の内製化に取り組みました。（その時の状況や課題解決については@sunaotの過去の記事を参照ください。） 機能が増え続けた3代目カイポケ（2024年時点） 2020年‐2024年　技術的負債の解消 & 障害福祉領域への拡張 SaaSの顧客数の増加、及びFY19までに開始した複数の事業のグロースも進み、事業としては順調な成長をみせました。 一方、大規模障害が数回発生するなど、システムとしては不安定な状況が続きます。2016年から継続して続けていたAWS化を含めたシステム安定化への取り組みが奏功し、なんとか安定的な運用が実現されました。そして、長期的に技術的負債を解消するには、リファクタリングではなく、リニューアルをする必要が有るという結論になり、2022年からはカイポケのリニューアル（4代目カイポケ）が着手されます。また、この時期から、長らくBiz側に所属していたPdM組織は、エンジニア組織（プロダクト開発本部）に移管されます。 2014-2019年の時期には「サービスが多い事」が是とされていましたが、上記の文脈から、プロダクトやサービスの取捨選択も重要となり、プロダクトポートフォリオマネジメントが重要なテーマとなりました。各種サービスのクローズや3rdParty化が進む中、 事業のサービス提供範囲を、介護に限らず、障害福祉の領域に拡張させる など、収束する活動と拡張する活動が同時に動いています。 リニューアル中のカイポケ（ DesignerBlogより ） 後から振り返っての感想戦 最大の意思決定は「2006年」というタイミングで参入した事 カイポケが上手く行っている理由は色々と外部から説明されます。エス・エム・エスはオペレーションが強いとか、顧客の囲い込みが成功しているとか、etc…です。そういう事もあるのかもしれませんが、私は、在宅介護市場と介護ソフト市場が大きく伸び始めていた時期に（後発参入ではあるが）「このタイミングで参入した事」が最も重要だったと考えます。10年後に事業開始したとすれば、競合も多く、ここまでの成長は難しかったでしょう。 当初から、SaaS（ソフトウェア）単体ではなく「経営支援」というコンセプトで領域を捉えていた事も良かったと思います。当時のプレスリリースには下記のように書いてあり、既にソフトウェアだけでない世界観が見えます。 株式会社エス・エム・エスは、介護運営に必要なサービスをひとまとめにしたパッケージサービスの提供を開始します。ASPタイプの給付ソフト、国保連への伝送サービス、求人広告、ニュース、セミナー情報などを手がけ、また、ファイナンスサービスについては、スルガ銀行と業務提携し、事業者向けインターネットバンキング及び介護報酬早期入金サービスなども組み入れます。 （ @Press 株式会社エス・エム・エス 介護事業者向け会員サービスを開始 ）から引用 これは、エス・エム・エスの「新規事業を立ち上げる事を是とするカルチャー」にもFITしていて、組織能力との相性も良かったと考えます。 2014年の値上げは功罪ある 2014年に大幅な値上げをしていますが、外部のカイポケについて解説する記事では、本件については戦略的だと書かれている事が有るように見えます。事実、2015年から2016年にかけて、収益化に成功し、カイポケが本当の意味でPMFしたのはこの時期でしょう。 もともと、PMFしていないレベルでの低価格だったので、いずれかのタイミングで適正価格への変更は必要でした。しかし、とにかく市場シェアを獲る事を目的にするのであれば、もう5年くらい待てば良かったようにも思えます（とはいえ、それは当時の状況としては難しいでしょう）。グラフを見る限りだと、結局は値上げ後に大量に離反している事を考慮すると、最初から当初の価格で販売した場合による低成長シナリオと結局は着地は同一だったのではないかとも思えます。営業対応コストや顧客の離反、レピュテーションリスク、その他諸々を考慮すると、むしろマイナスである可能性も有ります。 個人的には、SaaSでビジネスをやるのであれば、Value BaseのPricingを行い、Valueが変化した際に、「徐々に」Pricingを上下させるという方が妥当なように思えます。また、顧客へのコミュニケーションは慎重に行うべきだと考えています。 エス・エム・エスの事業開発カルチャーはプラスにもマイナスにも働いた 前述の通り、エス・エム・エスには「新規事業を立ち上げる事を是とするカルチャー」が有りました。それは事業開発には有利に働きますが、プロダクト開発的には、プロダクト開発の複雑性を増し、プロダクトマネジメントの必要性が強く要求される、という面も有ります。 また、前述の通り、立ち上げるタイミングを逸しなかった事は良かったですが、OEM→外注→オフショア開発→それらの併用→内製化という流れの中で、技術的負債の返済を迫られる事にもなりました（前述の通り、 @sunaotはとても大変だったとの事 ）。そもそも、当時はそれ以外の選択肢を取れなかったとも言えます。 技術的負債は、そのメタファーの通り、複利で発生する利子込みで未来に返済する必要が有る一方、「時間（スピード）」を調達する事ができます。その「時間」を持って、事業を成長させる事ができたというメリットもあり、カイポケは実際にそれで成功したとも言えます。 技術的負債の定義や解釈については、Ward Cunninghamの発言を翻訳した” 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 ”を参考にしています。この記事に記載されている通り、メタファーに使われている負債は、経営者としてはニュートラル～ポジティブなイメージに近いと考えます。事業サイドである私は、技術における負の面だけでなく、この正の面にも目を向けています。 「負債」という言葉は、経営に近い人ほどポジティブな印象を持ち（資本のイメージ）、純粋な技術面に近い人ほどネガティブな印象を抱く（借金のイメージ）傾向があるように思われます。Ward が語っている負債のメタファーはどちらかというとポジティブなものです。 このエントリーを書いた後に、「世の中一般にそう誤解されている面はあるのですが、技術的負債は時間を調達するものではない」というコメントを@sunaotからもらいましたが、敢えてそのまま記事に出してしまいます。いつか反論記事が書かれるのではないかと期待しています。 歴史から学んだ事 SaaSの運営は、資金調達、ビジネス、プロダクト開発の3つを実現する必要が有ります。カイポケはそれぞれをバランス良く進めるというよりも、事業を優先した結果、技術的負債を貯めていく、という事を何度か繰り返していました。過去の失敗を糧にして、カイポケにおける意思決定も変わっています。 1つ目は、ビジネス、プロダクト、テクノロジーのバランスの取り方です。過去に私が TechBlogへの投稿で書いた ように、カイポケにおいての意思決定の際に、エンジニアリングリーダーシップ、プロダクトリーダーシップ、ビジネスリーダーシップという三権分立で考えています。私はこのうちのビジネスリーダーシップのみを権限として持つようにしていて、それぞれのプロフェッショナルの十分な議論の元、長期的に正しい意思決定となるように配慮しています。 2つ目は、広義のプロダクトマネマネジメント（サービス全体のポートフォリオマネジメント）の舵取りです。 カイポケのサービス全体のポートフォリオマネジメントを自身の最大の役割と捉え、サービスの拡張/クローズ、自社開発、3rdPartyとの連携、提携、etc… を意図的にマネジメントするようにしています。重要なのはプロダクト（サービス）で、我々がそのサービスのべストオーナーである事、そしてそれらが継続的に良いサービスであり続ける事が大切です。過去の何でも自前主義から決別して、カイポケはProduct Drivenな組織に大きく変わったとも考えています。 ところで、エス・エム・エスの歴史は事業創造の歴史でもあり、創業初期からカイポケ含めて毎年事業が立ち上がっているというのは、企業文化としては強みでもあると感じています。プロダクト開発とのバランスを考慮しながらも、これからも事業が毎年創出される事を、以前と変わらずに、目指していきたいと考えています。 今後のカイポケのチャレンジ この領域において、カイポケはまだまだ道半ばであり、医療・介護/障害福祉市場もまだまだ質量ともに、展開の余地が有ります。具体的には下記です。 市場シェア（カイポケのシェアは15%程度）を考慮すると、顧客数はまだ伸びる余地が有る 医療・介護/障害福祉領域は広く、ソフトウェアに限らず、展開可能なサービスの余地が多数ある 現在の市場トップシェア群から、中期的には圧倒的シェアへと移行させるが、それに伴い解くべき課題のフェーズが変わる リニューアルにより、ソフトウェアの提供価値が1段階上がり、解ける課題の質が変わる 医療や介護などの制度の複雑化やカイポケのユーザー数の増加に伴い、今後もドメイン固有の生成 AI など新しい技術にチャレンジしていく必要もあります。この事業の複雑性を楽しめる方や、未来のカイポケを作りたいエンジニア、PdM、ビジネス担当の方は下記フォームから是非お声がけください。また、 協業相談や単にディスカッションしたい方はこちら まで。

こんにちは、 @_atsushisakai です。介護/障害福祉事業者向け経営支援サービス「カイポケ」の開発責任者をやっています。 この記事は、 株式会社エス・エム・エス Advent Calendar 2024 の記事です。 開発チームに LeSS (大規模スクラム) を導入した 今年は担当しているカイポケの開発チームで大々的に LeSS を導入し、スクラムマスターの支援を受けながら、組織の形やプロセス全体を大きく変化させたり LeSS そのものを学びながらガイドラインに沿って細かく調整・適応していくことなどを行っていました。全てがうまくいっているわけでは全然ないので、LeSS の原理・原則を少しずつ理解しながら実験したりチャレンジを繰り返すことで様々な改善を継続しています。 カイポケにおける LeSS の導入経緯や状況についてはスクラムマスターが執筆してくださった記事に詳しいのでそちらに譲ります。 tech.bm-sms.co.jp この記事では、 「マネージャー」というロールが果たすべき責任について、組織に LeSS を導入する前後で起きた変化にフォーカスして書いてみようと思います。ここで語る「マネージャー」は Engineering Manager に限定せず、スクラムにおけるマネジメントの仕事一般を担うやや抽象度の高いロールとして書きますので前提としてご理解下さい。 LeSS 導入で目指す自己管理型チーム これは個人的にとても強く感じていることなのですが、LeSS を導入するとプロセスが変わるだけではなく、組織の形や働き方そのものへの変化をもたらします。LeSS を適用するといままでの働き方や組織の形だと違和感を感じ始める部分がポツポツと出始めます。 そのひとつがチームのあり方で、LeSS ではチームは「自己組織化」というだけではなく「自己管理」を行うことが求められます。 less.works 自己管理を行うチームでは、スケジュール調整やステークホルダーとの連携など、あらゆる問題をチーム自身が全員で行う必要があります。たとえば、タスクが遅れている場合にはチーム内で開発者が直接調整を行い、マネージャーやステークホルダーなど外部からの指示を待つことなく進捗を自己管理します。 このようなチームのあり方をはじめとする組織的変化に、マネージャーとしての自分自身の役割や責任の認識も適応させていく必要がありました。 LeSS がもたらすマネージャー像の変化 LeSS が組織に導入されていく過程で、チームが自律的に活動を行い自己管理されていくように変化していくとマネージャーは何を役割とするべきなのかを逆算的に考えていました。 LeSS において自己管理されたチームとマネジメントの責任分界点は以下のように示されています。 Types of Teams. (LeSS / Self-Management https://less.works/less/management/self-managing-teams より引用) "Self-Managing teams" においてマネージャーの責任は以下とされています。 全体の方針を設定する チームと組織のコンテキストの設計を行う この責任分界された環境下でマネージャーである自分はどんな仕事を優先的に考え、実行するべきなのでしょうか？ここからは、LeSS において改めて私自身が考えたマネージャーの役割と責任を整理していきます。 マネージャーにしかできない仕事に徹する チームが自己管理するようになって、より一層マネージャーはマネージャーにしかできない仕事に集中することが重要です。マネージャーの責任は以下のふたつだと考えます。 チームの自己管理能力を強化・維持すること チームが最大のパフォーマンスを発揮できるような組織構造を設計し、 LeSS 全体がスムーズに機能するよう支援すること マネージャーはチームの仕事に出来る限り足を踏み入れるべきではないと思います。チームの内部で発生している問題はあくまでもチームがその原因を自ら追求し、解決を行うことをマネージャーとして求めていきます。ただし、問題を放置するわけではなく、マネージャーの視点を持って現場に入り込みます。 例えば、チームにキャパシティ不足が発生しているときには、より広い目線で組織全体で調整を行うことができないかということについて考慮したり、能力不足が発生しているときにはチームがどうやって能力を強化するかということについての解決策を考慮し、提示します。 つまり、チームが自己管理の範疇で解決できない問題について、マネージャーはより優先的に思考し、起きている問題がステークホルダーや事業戦略に与える影響を把握しながら構造的な問題解決を図ることに徹するのです。 LeSS のマネージャーが気をつけること マネージャーはチームの課題解決を肩代わりする存在ではない ここまでに、マネージャーにしかできない仕事に徹する、と書きました。裏を返すと、チームが自分でやり遂げなければいけない仕事はかなり広いのです。チームが解決すべき課題をマネージャーが肩代わりするように引き受けてはいけません。 例えば、他のチームやステークホルダーとの情報共有の間に立って調整を行ってあげたりすることなどは、マネージャーがやらなければいけない仕事ではありません。こういった仕事は、チームが自ら取り組むことで目線が広がり自己管理能力が高まるチャンスかもしれません。 あくまでも、チームができることはチームにやってもらいましょう。チームはマネージャーを便利に使ってはいけませんし、マネージャーもチームの支援だからといって自己管理すべき仕事を奪ってはいけません。チームが成長する機会を奪ってしまわないように距離感を保ちながら自身の仕事がチームにとって適切な支援になっているかについて常に注意を配りましょう。 プレイングマネージャーとしての役割は LeSS では特に難しい LeSS におけるマネージャー像を実践する際、これまでプレイングマネージャーとしてチーム内で活動していた人にとって、新たな役割への適応はチャレンジングかもしれません。従来のプレイングマネージャーが担っていた多くの役割は、実はチーム全体で自己管理を通じて担うべきものであり、その結果、マネージャーとして必要な支援型リーダーシップの視点が不足する可能性があります。 この状況に対処するためには、次の3つのオプションを検討すると良いと思います。 開発者に徹する チームが自律的に運営できるようになる過程で、マネージャーとしての振る舞いをやめ、開発者としての役割に専念する。 チーム内でのコーチになる チームの開発者に最も近いところで、マネージャー自らが学習し、実践することで自律的なチームの手本となるように振る舞う。 支援型マネージャーに切り替える チームの運営には直接関与せず、LeSS のマネージャーとして、組織全体の視点からチームを強化・支援する役割に集中する。 いずれの選択肢を選ぶ場合でも、LeSS に適応するためには従来の「プレイングマネージャー」としての役割を見直すことが必要です。チームの自律性を尊重しながら、マネージャーとして本来求められる貢献がどのようなものであるのかを再考してみると良いと思います。 まとめ 組織に LeSS を取り入れることによって、マネージャーにはこれまで以上に広範囲で支援型のリーダーシップが求められるようになります。指示を出すのではなく、チームを信頼し、組織の中で自分だけができる貢献を見つけ、リーダーシップを進化させる必要があると、実際に自分がその立場に立って感じることができました。 私自身、LeSS の導入によって様々な意識変革が起こり、組織の変化の中でマネージャーとして試行錯誤を繰り返しながら進んでいます。この記事が同じ道を歩むマネージャーの皆さんにとって少しでも参考になれば幸いです。そして、興味のある方はぜひ一度、以下の LeSS のサイトで「マネジメント」の章を一読してみてください。 less.works もっと話を聞きたい、という方はカジュアル面談をしましょう！ open.talentio.com

この記事は株式会社エス・エム・エス Advent Calendar 2024 12月23日の記事です。 qiita.com はじめに BPR推進部EA推進Grでエンジニアをしている、尾宇江 @kotaoue です。 苗字が読みづらいので、社内では おうえ で活動しています。 ちなみに、BPR(Business Process Re-engineering)・EA(Enterprise Architecture)で、「部署を横断して会社全体の業務プロセスを改善していこう」みたいな目標のチームとなっています。 この記事では、10月1日からエス・エム・エスに入社し、Kotlin未経験だったおうえが入社から2か月でできた改善・できなかった改善を振り返って紹介します。 改善したシステムの概要 役割 = 介護/障害福祉事業者向け経営支援「カイポケ」の売上情報を計算し全社の会計基盤に統合する 構成と特徴 バッチを操作するWebサーバーとWebサーバーから起動されるバッチサーバーの組み合わせ 言語はKotlin ビルドツールはMaven 会計処理を行うため、J-SOX・IT全般統制（Information Technology General Control：ITGC）の監査対象 主な稼働タイミングは月初の数営業日に集中 集計したデータの帳票作成機能もあり 帳票のテンプレートを管理する外部サービスを利用するために、Windows環境も必要 README拡充 貸与されたWindows端末の管理者権限申請が通るまでの約1週間は、JavaやGitなどをインストールすることができなかったために、集中してコードリーディングとREADMEの拡充を実施しました。 後々、最初のコードリーディングが効いてくることが多く、Goodなアクションだったなと自画自賛しています。 ちなみに、GitHub Desktopは使えたので、PR作成などは可能でした。 GitHub Branch protection rules の設定 うっかりミスが怖いなということで、最初のPRを作成する前に未レビューだとマージできないように「Require a pull request before merging」のブランチ保護ルールを設定しました。 GitHubの権限さえあればすぐにできますし、心理的な安心感もかなり高いのでおすすめです。 ちなみに、同時に「Automatically delete head branches 」の設定も追加して、PR取り込んだらブランチ削除するようにしました。 GitHub Actionsでのテスト実行 まずはシンプルにmvn verify を実行するGitHub Actionsを用意しました。 この時点ではテストコードは0行ですが、 verifyすればコンパイルが行われ文法エラーなど最低限のチェックになるので、簡単な追加の割に満足度が高かったです。 name : Maven Test on : pull_request : jobs : build : runs-on : ubuntu-latest steps : - name : Check out the repository uses : actions/checkout@v3 - name : Set up JDK 11 uses : actions/setup-java@v3 with : distribution : "temurin" java-version : "11" - name : Run integrations-tests run : mvn verify octocov の追加 地道にテストコードを追加するときに、テンションを高く保てるように、最優先でカバレッジを見える化することにしました。 octocov と JaCoCo を組み合わせることでPRに↓のようにレポートしてくれます。 設定は <plugin> <groupId> org.jacoco </groupId> <artifactId> jacoco-maven-plugin </artifactId> <version> ${jacoco.version} </version> <executions> <!-- ユニットテストの前に JaCoCo エージェントをアタッチ --> <execution> <goals> <goal> prepare-agent </goal> </goals> </execution> <!-- ユニットテストのカバレッジレポートを生成 --> <execution> <id> report </id> <phase> test </phase> <goals> <goal> report </goal> </goals> </execution> <execution> <id> post-unit-test </id> <phase> test </phase> <goals> <goal> report </goal> </goals> </execution> <!-- 統合テストの前にも JaCoCo エージェントをアタッチ --> <execution> <id> pre-integration-test </id> <phase> pre-integration-test </phase> <goals> <goal> prepare-agent </goal> </goals> </execution> <!-- 統合テストのカバレッジレポートを生成 --> <execution> <id> do-repport-on-post-integrations </id> <phase> post-integration-test </phase> <goals> <goal> report </goal> </goals> </execution> <!-- カバレッジデータを集約して最終レポートを生成 --> <execution> <id> report-aggregate </id> <phase> verify </phase> <goals> <goal> report </goal> </goals> <configuration> <dataFile> ${project.build.directory}/jacoco.exec </dataFile> <outputDirectory> ${project.reporting.outputDirectory}/jacoco-aggregate </outputDirectory> </configuration> </execution> </executions> </plugin> でJaCoCoをpom.xmlに組み込んだあと name : Maven Test on : pull_request : jobs : build : runs-on : ubuntu-latest services : docker : image : docker:20.10.16 options : --privileged steps : 〜 中略 〜 - name : Run octocov uses : k1LoW/octocov-action@v1.4.0 - name : List files coverage run : octocov ls-files | sort -k1,1n な形でActionsに組み込みました。 最初のRun octocovだけでレポートはできるのですが、クラスごとのカバレッジも見えるとテンションが高まるのでoctocov ls-filesも実行しています。 ※ ソート機能がなかったので、sortを使っていますが、55.5% のような文字列でソートしているので 1%, 10%, 5% のような 並び順がおかしくなるのは一旦無視しました。 さらに詳細な行単位のカバレッジレポートはローカルでmvn verifyを実行したあと、./target/site/jacoco-aggregate/index.html に出力されます。 ちなみに、12月初旬でのカバレッジは の25.9%になりました！ テストコード追加 ↑の修正でGitにPushしたらテストが回る状態を実現できたので、あとは地道にテストを増加させていくことにしました。 ちなみに当初の予定では主要な機能のテスト作成 → KotlinやJavaのアップグレードという流れをイメージしていましたが、後述のMockKの問題によりテストコード追加とアップグレードをパラレルで実行することになりました。 MockKの導入 外部システムとのやりとりがあったり、細かいところには目をつぶって主要な機能のテストを作りたい、というような方針からMockしたいケースが発生することが予想できたので、まずは MockK を導入することにしました。 ただ、MockKはKotlin 1.5.* 以降でないとかなり制限がかかってしまうことが判明したために、カバレッジ3%くらいの状態でいきなりKotlinを1.5.* までアップグレードすることになりました。 この時点では主要な機能は fun testBatchExecute() { mockkObject(Batch) every { Batch.fetchData() } returns Unit every { Batch.processData() } returns Unit every { Batch.saveData() } returns Unit Batch.execute() verify(exactly = 1 ) { Batch.fetchData() } verify(exactly = 1 ) { Batch.processData() } verify(exactly = 1 ) { Batch.saveData() } } のような表層的なテストになる場合もありましたが、まずはここからという感じで準備しました。 H2 Database Engineの導入 データベースのテストには H2 Database Engine を利用することにしました。 当初はテスト時はローカルのデータベースに接続するのは少し修正箇所が多く難しかったために、インメモリのH2 Database Engineを採用しました。 設定は簡単で <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-surefire-plugin </artifactId> <configuration> <!-- Setting for H2DB on test --> <systemPropertyVariables> <db . url> jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE </db . url> <db . username> sa </db . username> <db . password></db . password> <db . driverClassName> org.h2.Driver </db . driverClassName> </systemPropertyVariables> </configuration> </plugin> <plugin> <groupId> org.codehaus.mojo </groupId> <artifactId> exec-maven-plugin </artifactId> <executions> <execution> <id> setup-db </id> <phase> pre-integration-test </phase> <goals> <goal> java </goal> </goals> <configuration> <mainClass> org.h2.tools.RunScript </mainClass> <classpathScope> test </classpathScope> <arguments> <argument> -url </argument> <argument> jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE </argument> <argument> -user </argument> <argument> sa </argument> <argument> -password </argument> <argument></argument> <argument> -script </argument> <argument> src/test/resources/schema.sql </argument> </arguments> </configuration> </execution> </executions> </plugin> のように設定するとschema.sqlに記述したCREATEなどが実行されてテストで利用できるようになります。 ただ、複雑なSQLを書いているケースは皆無だったのと、取得したデータをObjectで取り扱っているためにmockkObjectでMockしてしまえば事足りるケースが大半でした。 DBに投入したデータについては、ちゃんと後始末しないと別クラスに影響与えることも多いために、利用するかどうかはケースバイケースだなと改めて思いました。 LocalStackの導入 S3を利用していたのでLocalStackを導入しました。 ローカル環境で利用するのは Testcontainers を使えばかなり簡単で import com.amazonaws.auth.AWSStaticCredentialsProvider import com.amazonaws.auth.BasicAWSCredentials import com.amazonaws.client.builder.AwsClientBuilder import com.amazonaws.services.s3.AmazonS3 import com.amazonaws.services.s3.AmazonS3ClientBuilder import org.junit.jupiter.api.AfterAll import org.junit.jupiter.api.BeforeAll import org.testcontainers.containers.localstack.LocalStackContainer import org.testcontainers.utility.DockerImageName open class AbstractLocalStackTest { companion object { private lateinit var localStack: LocalStackContainer lateinit var s3Client: AmazonS3 var bucketName = "test-bucket" @JvmStatic @BeforeAll fun setUpBeforeAll() { localStack = LocalStackContainer(DockerImageName.parse( "localstack/localstack:latest" )) .withServices(LocalStackContainer.Service.S3) localStack.start() val endpoint = localStack.getEndpointOverride(LocalStackContainer.Service.S3).toString() val credentials = AWSStaticCredentialsProvider(BasicAWSCredentials(localStack.accessKey, localStack.secretKey)) s3Client = AmazonS3ClientBuilder .standard() .withEndpointConfiguration(AwsClientBuilder.EndpointConfiguration(endpoint, localStack.region)) .withCredentials(credentials) .withPathStyleAccessEnabled( true ) .build() if ( ! s3Client.doesBucketExistV2(bucketName)) { s3Client.createBucket(bucketName) } S3Service.setS3Client(s3Client) ErpS3Service.setS3Client(s3Client) } @JvmStatic @AfterAll fun tearDownAfterAll() { localStack.stop() } } な感じで設定すれば、あとは通常のS3に接続するようにテストできます。 ただ、Actionsで動かすのはコンテナ内でコンテナを動かすことになるので、↓の感じで少しだけ調整する必要があります。 jobs : build : runs-on : ubuntu-latest services : docker : image : docker:20.10.16 options : --privileged 〜 中略 〜 - name : Run integrations-tests run : mvn verify env : TESTCONTAINERS_HOST_OVERRIDE : localhost DOCKER_HOST : tcp://localhost:2375 linterの導入 Kotlinに慣れていないこともあって、お作法的な書き方がわからなかったので、 Ktlint を導入しました。 ちなみに、Kotlinを1.6.*までアップグレードしないとうまく動作しなかったです。 修正は2回のPRに分けて な感じで対応しました。 リポジトリのルートに.editorconfigというファイルを配置することでlintのルールを指定することができるために、「全部のルールを除外する」→「一つだけルールを許可する」→「ktlint:formatで自動ルール適用」→「commit」のようにしていけば、似たような変更だけでcommitをまとめることができるので、レビュワーも楽な気がします。 ちなみにktlint:formatで解消できないものは手動で解消する必要があります。 [*.{kt,kts}] ktlint_standard_backing-property = disabled 〜 中略 〜 ktlint_standard_body-expression = disabled max_line_length = 200 コンテナ化 システムはLinuxスタイルパスで設計されているが、開発環境はWindowsで開発しづらかったために、コンテナ化しました。 副産物としては「コンテナで動作させる ≒ 新しい環境を用意する」ということで、インフラからみたシステム理解がかなり進みました。 ※ ちなみにその後Macも貸与されて、WindowsとMacの2台持ちになりました。 Kotlinのアップグレード 1.3. -> 2.1. 最終的には2.1. までアップしました。 といいつつ、MockKが使えなかった1.5. 未満、ktlintが使えなかった1.6. 未満と違い1.7. -> 2.1.* はpomの数値を変更するだけでアップグレードできました。 Javaのアップグレード 11 -> 17 こちらも何も問題なくアップグレードできました。 ただ、Kotlinと違いサーバーにインストールされているJavaのVerも関連するのでリリースするタイミングには少し注意が必要でした。 pom.xml の最新化 ある程度テストも増加したので、mvn versions:use-latest-release で pom.xml  の各種プラグインをアップグレードしました。 Renovate pomもアップグレードできたので、大手を振ってRenovateを導入しました。 ちなみにJ-SOXの都合で承認フローを通っていない改修を本番リリースすることはNGなので、自動マージはOFFで運用しています。 構造化ログの導入 Logback を導入してログをJsonフォーマットに変更しました。 呼び出し元もログに出力したかったので、src/main/resources/logback.xml に以下のような設定を追加しています。 ちなみに、 で指定すると、特定のパッケージのログレベルを変更することができます。 nettyがかなりのDEBUGログを出力したので、個別OFFにしています。 <configuration> <property name = "LOG_LEVEL" value = "${LOG_LEVEL:-debug}" /> <appender name = "STDOUT" class = "ch.qos.logback.core.ConsoleAppender" > <encoder class = "net.logstash.logback.encoder.LogstashEncoder" > <includeCallerData> true </includeCallerData> </encoder> </appender> <logger name = "io.netty" level = "INFO" /> <root level = "${LOG_LEVEL}" > <appender-ref ref = "STDOUT" /> </root> </configuration> また、 import ch.qos.logback.classic. Level import ch.qos.logback.classic.LoggerContext import ch.qos.logback.classic.spi.ILoggingEvent import ch.qos.logback.core.AppenderBase import org.junit.jupiter.api.AfterEach import org.junit.jupiter.api.Assertions.assertEquals import org.junit.jupiter.api.BeforeEach import org.junit.jupiter.api.Test import org.slf4j.LoggerFactory class LoggerTest { private class TestAppender : AppenderBase<ILoggingEvent>() { var lastMessage: String ? = null var lastLevel: Level ? = null override fun append(eventObject: ILoggingEvent) { lastMessage = eventObject.formattedMessage lastLevel = eventObject.level } } private var appender: TestAppender = TestAppender() private var originalLevel: Level = Level .ALL @BeforeEach fun setUp() { val loggerContext = LoggerFactory.getILoggerFactory() as LoggerContext val logger = loggerContext.getLogger( "TestLogger" ) originalLevel = logger.level logger.level = Level .ALL appender.start() logger.addAppender(appender) } @AfterEach fun tearDown() { val loggerContext = LoggerFactory.getILoggerFactory() as LoggerContext val logger = loggerContext.getLogger( "TestLogger" ) logger.level = originalLevel logger.detachAppender(appender) appender.stop() } @Test fun testDebug() { Logger.debug( "Debug message" ) assertEquals( "Debug message" , appender.lastMessage) assertEquals( Level .DEBUG, appender.lastLevel) } } のような感じでログメッセージをテストすることができるので、テストも書きやすいです。 プロジェクト管理まわりでできた改善 開発サーバー・DBのスケジュール起動 開発用のサーバーやDBが常時起動していたので、EventBridgeで営業日の定時前に起動、定時後に終了といったスケジュールを用意しました。 J-SOX, ITGC関連の整備 会計情報を扱っているというシステムの特性として絶対に必要なITGCですが、運用が煩雑で開発フローと相性の良くないポイントも発生しておりました。 一例としては「PRをマージする際には必ず上長がレビュー→Approve→Mergeすること」のような運用があり、上長に負荷が集中していました。 このあたりの運用については監査法人の方と相談し、監査内容としても十分で開発フローとしても制約にならない運用に変更できました。 ※ これがこの記事のなかで一番のWinかもです。 レビュー体制の改善 これまでチーム内部でしかレビューを実施していなかったのですが、別チームのメンバーにもレビュー依頼を出すことにしました。 新たな視点でのレビューコメントをもらえることも利点ですが、「このPRはドメイン知識がかなり必要だからしっかりと説明しなきゃ」のようにチーム内部だと徐々にハイコンテクストになりがちだったコミュニケーションを整理して、新メンバーの参画時の準備としても有用に働いているのも利点に感じています。 SaaSのバックアップとBCP検討 帳票などで複数の外部サービスを利用しているために、各種サービスの設定をどのようにバックアップしておき、万が一の場合に復旧するのかといったBCPを検討しました。 ちなみにサービスのSLAを単体で見るとまず障害なんて発生しないように感じますが、複数のサービスのSLAをかけ合わせていくと、結構な頻度で何らかの障害が発生するということが目に見えてかなりドキドキしました。 できなかった改善 以下、やりたかったけど間に合わなかった改善についての簡単なメモです。 CI/CDパイプラインの構築 現状はActionsでテストしていますが、Deployまでは実施できてないです。 といいつつ、↓のmigrationツールの導入など前段の準備が必要なので、段階的に改善していこうと思っています。 migrationツールの導入 手動オペレーションを脱却することで、CI/CDへの頂きを目指したいです。 EC2脱却 EC2を起動してバッチを実行しており、速度とコストに改善余地があるので、Fargate や ECS on EC2 などに載せ替えようと考えています。 SCPのテスト 実はSCPでやりとりしている箇所があるのでテストを書きたいなと思っています。 TestcontainersでSCPサーバーを立てて通信しようかなーといったアイデアだけある状態です。 Salesforceのテスト  結構複雑な Salesforce Object Query Language (SOQL) を書いている部分もあり、レスポンスをMockするのではなくてSOQLもテストしたいなと思っているものの、あまり良い方法がなさそうで方針を検討中です。 J-SOX対応の自動化 監査用の提出資料の準備ですが、結構な工数がかかる上に、定期的に実施する作業なので、なんらか自動化して、より通常業務に集中できるチーム体制にしたいなと思っております。 まとめ といった感じで、Kotlin未経験者が入社から2か月でできた改善・できなかった改善のまとめとなります。 チームメンバー数が少なかったり、自由に行動させてもらえるという裁量の高さもあって、個人のやりやすい形で進行させてもらえました。 一つ一つは細かい改善ですが、1ヶ月2ヶ月と積み重ねていくとちょっとした量の改善になっていて満足度も高いので、気軽に改善する文化を広めていきたいなと思っております。 またテストコードの追加など地盤固め・守りの改善をしていくことで、新機能を追加する際に「対抗先システムに例外パターンも網羅したテストデータを用意しなきゃテストできないが、そのためにはパターンごとにデータ洗替が必要でとても大変…」といった状態から「自動テストで確認できてるのでコア部分に注力してテスト可能」といった効率的な状態に移行し開発スピードにも貢献できると思っております。 といった感じで、来年も「情熱」「誠実」を持って社会に貢献していけるよう開発・改善を進めていきます！

この記事は 株式会社エス・エム・エス Advent Calendar 2024の12月23日の記事です。 qiita.com こんにちは！ @aysuzuki です。自己紹介は こちらの記事 にまとめているので、ご覧いただけるととても嬉しいです。 入社からほぼ5ヶ月が経過しました。もう2025年なんて早いですね……。 キャリアパートナー エス・エム・エスではキャリアパートナー(CP)と呼ばれる、従事者(求職者)と事業者を繋ぐ転職・採用支援担当が双方とコミュニケーションをとり、より良いマッチングを創出しています。 より良いマッチングのためには情報の記録・収集・共有や、従事者や事業者に提案するための調査・検索が必要です。実際にCPチームが日々どんな業務をして、どのように情報を処理して検索をしているのかを学びに行きました。 エスノグラフィ まだ入社が浅いこともあり、CPチームがどういう職場・環境でどういった業務を行っているのか全くわからない状況でした。 まずはエスノグラフィ(行動観察)を行い、理解を深めるところから始めました。業務内容についてあまり詳しく書くことはできませんが、結果として以下のような考えに至りました。 エンジニアとしてできること 自分たちが作っているものがどう使われているかを実感する Analytics、ログ、行動データなどから見える部分もたくさんありますが、あくまでもそれは「使われた結果」だなと実感しました。実際に使っているところを見たりインタビューすることで、どういう状況でどういう思いで使っているのか、使われていないのか、を実感できたのは非常に大きいなと感じました。 人間にしかできない業務に集中できる環境を作る ここがエンジニアの本分ともいえますが、情報を探すのにスクロールが長すぎるページや、記録のためにツールからツールへコピペする、といった作業の割合はかなり多いなと感じました。 たった1日観察しているだけでも、エンジニアが数時間開発することで、CPチームの業務が数百時間楽になるんだろうな、と思われる改善ポイントもいくつかあったので、こういった課題解決のチャンスはまだまだたくさんあると思いました。 業務の可視化・課題発見をする そして「なぜ使いづらいUIになっているのか」「なぜその業務が存在するのか」のような、一歩引いた本質的な課題として捉えて解決していくことも、自分たちの役割だなと強く考えました。 上述した直接成果をあげられる短期課題の解決と、この本質的な課題解決の双方に取り組むことが「事業に貢献している状態」といえるのかなと思いました。 職種間の垣根や距離感を取り除く 最後に、このような機会を他のエンジニアやCPの方とも広くやっていきたい、と思いました。同じ会社にいる他の職種はこういうことをしている、あそこに知り合いがいて相談できる、という相互理解がある状態が、シナジーを生み出していくのではと考えました。 まとめ 普段からユーザーインタビューやテストを行ってる方々からすれば、当たり前すぎることかもしれませんが、普段開発業務に専念していると見えづらくなってしまうこともあるんだろうな、と思いました。 会社や団体によって対象となる職種やユーザーも違いますし、気軽に覗きに行く環境じゃない場合もありますが、もし同じ会社に営業部隊やユーザーに近しいチームがいるのであれば、足を運んで実感することで、ものづくりに対する考え方のアップデートができるいい機会になると思います。 少なくともエス・エム・エスはそういうことができる会社です！ご興味を持たれた方はぜひお話聞きに来てください(アピール)

この記事は株式会社エス・エム・エス Advent Calendar 2024 vol.2の12/20の記事です。 エス・エム・エス BPR推進部 EA推進Gr CSF開発チームの藤田と申します。 私は2023年8月にエス・エム・エスへ入社し、社内業務基盤として活用している介護キャリア・介護経営支援向けのSalesforceのシステム保守・エンハンス開発を行うチームのEM（エンジニアリングマネージャー）を担当しています。 前職ではSIerとしてSalesforce導入事業のPMをしていました。かれこれ15年ほどSalesforceに関わっています。 プライベートでは4人の子供を持つ父親です。10歳、8歳、3歳の男の子3人、0歳の女の子1人とバラエティーに富んだ生活送ってます。 CSFってなに？ エス・エム・エスでは現在、Salesforceの組織（環境）を3つ契約しています。 私が入社した段階ではMSF、CSFの2つが存在し、今年第3のSalesforceとしてカイポケM&A用のSalesforceが誕生しました。 MSF？CSF？何が違うの？という声を社内からもよく耳にするのでこの機会に紹介しておきます。 MSF：医療・介護キャリア向けのマッチングシステム。「M」は「Medical」から取ってます。 CSF：介護キャリア・介護経営支援向けのSFA/CRM。「C」は「Care」から取ってます。 前職ではSalesforceの新規導入がほとんどだったので、入社直後はSalesforceを複数組織契約していることやSalesforce組織それぞれに呼称をつけているのも新鮮でした！ 今回は我々CSF開発チームが管掌しているCSFについて語っていきたいと思います。 2017年1月に誕生したCSFですが、初期開発当初からなるべく標準機能を使って要件を満たすことをポリシーとしています。 特にUI部分は現在もほとんどが標準機能（フロー）や標準画面を活用しています。 Salesforceの運用や開発に携わったことがある方はご存じだと思いますが、SalesforceではUI部分はVisualforce、LWCといったカスタマイズ開発手法が用意されています。 これらのカスタマイズ開発を行うことでより柔軟な画面機能を実現することが可能な反面、開発コスト、メンテナンスコストが多大にかかることや、標準機能を使用することで得られるメジャーアップデートでの新機能追加の恩恵を受けられないというデメリットもあります。 前職でSalesforce導入をしていた際の自分のポリシーもなるべく標準機能を使うことだったので、このあたりは違和感なくジョインできました！ UIは現在も標準機能を活用する一方で、バックエンド系の処理は元々プロセスビルダーやワークフロールールなどの標準機能を多く活用していたのですが、最近はApexを使ったカスタマイズ開発も増えてきました。 その理由としては大きく2つあり、1つは周辺システムとの連携が増えてきたことです。後述する価値提供先のニーズを満たすため、社内外の周辺システムとのAPI連携にApex開発を用いたり、システム連携方式を検討するうえで保守性や可用性を担保するためにデータ格納先のオブジェクトとは別にシステム連携用のオブジェクトを作成し、Apexトリガーを使ってデータ連携を行ったりを積極的に採用しています。 システム連携方式の検討例 もう1つはバックエンド処理の複雑化です。元々プロセスビルダーやワークフロールールを積極的に取り入れていたのですが、これらの機能が廃止されフローに統合されることがSalesforce社よりアナウンスされています。それを受けてフローでの処理実装をメインに進めていた時期があったのですが、バックエンド処理をフローのみで構築する場合、複数オブジェクト×複数のループ処理などを実現するのは開発コストだけでなくメンテナンスコスト（他のメンバーが理解する、改修する）も多くかかってしまうことがあり、現在では新規の機能開発の場合は処理内容を踏まえたうえでApex開発を選択することも増えてきました。 複雑になったフローはこんな感じ（このフローは写っている範囲で全体の3割くらい） CSFの価値提供先はどこ？ 記事のタイトルのとおり、複数の介護事業者向けサービスの業務基盤となっているCSFですが、 具体的には主に3つのサービスに対して価値提供をしています。 介護/障害福祉事業者向け経営支援サービス「カイポケ」 ：業務効率化や財務改善など、介護/障害福祉事業者の経営改善に役立つサービスをワンストップで提供するサブスクリプション型のクラウドサービス。カイポケが提供する各サービスについてのフロント/バックオフィス業務に対してリードや商談、ケース、約20ほどのカスタムオブジェクトを使って業務基盤を提供しています。エス・エム・エスではカイポケを利用する介護事業者向けに介護に関する報酬改定について、特設サイトを公開しているのですが、令和6年度の報酬改定ではSalesforceのExperienceCloudを使ってサイトを公開しています！ ファクタリング（カイポケ早期入金サービス） ：エス・エム・エスのファクタリング（早期入金）とは通常、保険請求から2か月後に国保連から入金される介護・診療報酬を請求月に請求額の8割を、残り2割を請求月の2か月後に振り込むサービスのことです。これにより、前倒しで資金調達が可能であり事業者の資金繰りを安定化させることを目的としています。ファクタリングでは商談から契約管理、送金管理までほぼ全ての業務プロセスをCSF内でサポートしています。カスタムオブジェクトを約30ほど使ったCSF内で最も大きなアプリケーションです。 介護向け求人情報サービス「カイゴジョブ」 ：ホームヘルパーや施設介護職員、ケアマネジャー、サービス提供責任者、生活相談員など、介護・福祉の仕事に特化した求人情報を提供しています。最適な事業者とのマッチングを支援するサービスです。カイゴジョブについても商談や見積、ケース、約15ほどのカスタムオブジェクトを使って業務基盤を提供しています。カイゴジョブではカスタマーサクセスの方が使っている業務システムがSalesforce（CSF）/kintoneで分かれています（いつかは統合したい）。使っているシステムが違うことで作業依頼を毎回チャットに転記していたりするので自動で連携したい、や「カイゴジョブ」システムとCSFの情報を同期させて常に最新の状態を参照したい、を解決するためにAWSやETLを介したシステム連携を実現しています。 上記サービスのセールス、マーケティング、カスタマーサクセス、オンボーディング、契約管理、販売管理などの業務プロセスに携わる方々がいかに日々の業務を効率よくこなしていけるか、ほしい情報をほしい粒度で提供できるか、という要望や課題を元に既存の運用や仕組みにとらわれず、事業戦略や将来の変化を見据えたシステムのアーキテクチャをSalesforceというPlatform上で考えられる最善策を検討し実現していくのが我々の価値になっています。 CSF開発チームではどんなことしているの？ 一言でいえば「CSFに関するありとあらゆることをやっています！」になるのですが、例としていくつか挙げていきます。 エンハンス開発 事業側からの要望を受けて機能追加、機能改修を行っています。 現在我々の部署ではBusinessArchitect（ビジネスアーキテクト）が事業側とシステム開発側の間に立って業務改善を推進してくれているのでBusinessArchitectとタッグを組んで課題解決のためのシステム対応を進めています。 BusinessArchitectについては こちらの記事 で詳しく説明されています！ 複数サービスが共通のオブジェクトを利用していることも多く、デグレードしないために行う影響調査が最も重要です！ エンハンス開発は多くの場合、1チケットにつきエンジニア1名で進めていくのですが、エンハンス開発の中でも比較的大きな規模の開発は「大玉案件」としてプロジェクト化して複数名で進めていきます。 大玉案件の一例 カイポケリニューアルプロジェクト ：プロダクト開発との初めての大規模な協業です！ M&Aプロジェクト：カイポケM&Aに特化した第3のSalesforce組織立ち上げではCSFのエンジニアがCSFの知見や実装した機能を活かして実現しました！ 報酬改定特設サイトプロジェクト：エス・エム・エスの外部公開サイトでは初となるExperienceCloudを活用したWebサイト構築です！カイポケブランドのデザインに準拠するため、標準機能だけでなくLWCも多く活用しています。 データメンテナンス こちらも主に事業側からの要望を受けての対応になりますが、データを一括で登録/変更したい場合やデータの削除依頼などを日々対応しています！リード情報の一括登録依頼を見ていると事業部の皆さんがめちゃめちゃ頑張ってくれているんだ、と実感してます！ メジャーアップデート対応 Salesforceといえばこれ。年3回のアップデートに備えて既存機能が正しく動作するかの確認や新しくリリースされるSalesforceの機能をキャッチアップして取り入れたりしています。 システム監視 CSFでは出来るだけSalesforceの標準機能を活用して業務基盤を構築しているのですが、どうしてもニーズを満たすためにApexを使う場面もあります。カスタマイズ開発すれば意図しないエラーなども付いて回るため、エラーが発生した際にはなるべく早く検知し対応するためにSlackでのエラー検知を実装しています。 Slackでのエラー検知を実装する前はSalesforceから届くエラーメールを都度確認していたのですが、チーム内でのコミュニケーションの大半をメールではなくSlackで行っており、メールに気づく人が限られているため初動対応が遅れてしまうなどの課題がありました。今ではエラーが発生した際にはそのスレッド内で即座にチームでやりとりし、原因特定して影響の有無や対応要否を判断した上で迅速に対応するということが実現できています。 アカウント管理 CSFでは現在500名以上の社内ユーザーが利用されています。毎月の入退職によるアカウントの追加/削除の他、部署異動によってCSF内で行う業務が変わる場合などの権限変更対応を行っています。 上記のようにCSF開発チームでは日々さまざまな業務を実施していますが、一部を除き業務の担当者を固定していません。エンハンス開発やデータメンテナンスについてはメンバー1人1人が自分のリソースや作業状況を元にBacklogチケットの中で着手できそうなものを自ら取っていく、という方式にしており、メンバーが自律的に動いて仕事を進めていくことに重きを置いています。もちろん業務の中で想定外のことやうまくいかないこと、ミスしてしまうこともあると思いますが、朝会などの定例やSlack等のコミュニケーション手段を活用して積極的にアラートをあげてもらうことで私自身や他のメンバーがサポートに入りつつチームとして成果をあげていくことを目指しています。 今後の展望 私がエス・エム・エスに入社しEMとなってからCSFに関するOPSの改善等を取り組んできました。 優秀なアドミニストレーター・エンジニアの皆さんのおかげでさまざまなエンハンス開発を進めながらも大きな障害を起こすことなく運用が出来ていますが、まだまだ改善できるところやチームのケーパビリティ向上が図れると考えています。 今後取り組みたい施策としてCI&CDパイプラインの構築やデータストレージ対策（SalesforceConnectの活用）といった大きなものからOPSの改善などの細かいものまでやりたいことがたくさんあります。 また、価値提供先の事業規模も拡大していく中でより柔軟かつスピーディーに要望を実現する開発チームにしていく必要があり、そのためにはエンジニアはもちろん、チームの戦略やOPSを自分事として一緒に考え、周りを巻き込んで自ら実行できる人が必要です。 CSF開発チームでは、アドミニストレーター・エンジニア、テックリードやエンジニアリングマネージャーを募集しています！一緒にチームや仕組みづくりをしていきましょう！ CSF開発チームについてちょっと面白そうと思った方や、もう少し具体的な話を聞きたいと思った方、ほんのちょっとでも興味がある方は下記リンクからご連絡ください！ エス・エム・エス - エンジニアカジュアル面談