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

この記事は株式会社エス・エム・エス 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 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開発チームについてちょっと面白そうと思った方や、もう少し具体的な話を聞きたいと思った方、ほんのちょっとでも興味がある方は下記リンクからご連絡ください！ エス・エム・エス - エンジニアカジュアル面談

はじめに この記事は 株式会社エス・エム・エス Advent Calendar 2024の12月20日の記事です。 キャリア事業部でマネージャーをしている @kenjiszk です。実は2023年も アドベントカレンダーの20日目の記事 を書いたのですが、あっという間に一年が経ってしまいました。今年1年、キャリア事業部でどんなことを考えながらどういった取り組みをしてきたかということを紹介していきます。 「長期がすべて」とは？ タイトルにある「長期がすべて」という言葉は、ジェフ・ベゾスが1997年に株主に向けて送った手紙から引用しています(出典: Invent & Wander)。仕事には、長期目線と短期目線の2種類がありますがここでは長期目線がすべてと言い切っています。実際の現場でそんなことだけを言ってもただの正論暴力で物事は進んでいかないわけですが、意思決定者がそう言い切っていることには一定の価値があると思います。 私自身の解釈としては、何でもかんでも長期的なタスクだけを実行せよ、ということではないと捉えています。例えば、今の売り上げがないために会社が潰れてしまうのであれば今に集中することは正しい目線だと思います。一方で、短期的な目線だけで仕事をしていると物事の根本解決や業界自体を変えていくような変化を起こせません。技術的な例を出すと以下のような状況は容易に想像できます。 技術負債が積まれていくが返済はされないので、じわじわと真綿で首を絞められるように開発効率が落ちていく。 システムの抜本的な改善が行われにくく、それを利用して業務をする人の効率を線形にしか向上させられない。相対的に世の中が進化していく中で、大きな変化に乗り遅れる。 「長期がすべて」という言葉をもう少し噛み砕くと、意思決定を行う時には常に長期目線を持つ、ということかと思います。たとえば、 潜在的な市場規模は大きいが成長に時間がかかる事業を支えるために短期的な施策を行うこと 残存者利益を得るための短期的な集中投資 といったケースから生まれる仕事は、それ単体で見ると短期的な仕事に見えますが、長期目線を持った仕事と捉えられます。 人材紹介事業において長期目線が難しい理由 私たちのチームが開発している人材紹介サービスは、フロー型のビジネスであり短期目線に陥りやすい特性を持っています。サービス利用者は、毎年同じように転職をするわけではないので、今年使ってくれたユーザーが必ず来年も使ってくれるというサービスではありません。そのため、気をつけないと今年度の数字に反映できる仕事に視点が寄ります。その一方で、一年以上かかるような仕事についてはなかなか優先度が上がらない、スタート時は熱量は高いが年度末に向けて他の仕事に優先度が劣後していくという圧力も生じます。 システムの作りの悪さは短期目線を加速させる システムの作りの悪さがその傾向を加速させます。私たちのシステムでもこういった傾向は0ではありません。 たとえば、十分な機能を持つツールを提供できていなかったり機能拡張が難しい構造になっている部分において、今できることの範囲内で最適化を回してしまう、結果的に小手先で何か数字を上げるようなことだけに終始してしまう、ということが起きてしまいます。他にも、テストが不十分なので安心して開発できる範囲だけで機能拡張をしよう、といったことも繰り返していくと事業施策の幅をどんどん狭めていきます。 こういった状況においても、事業は成長をするのでパッチ的な対応でなんとか凌ぐという事を繰り返した結果、短期目線を加速させることになります。エンジニアの視点で考えれば、我々が拡張性のある柔軟なシステムを作れているなら組織は長期目線の仕事に着手しやすくなる、という点に気をつけないといけません。 今年できた取り組み 今年取り組んだ長期的な目線での仕事を二つほど紹介します。 ナース専科 転職のリブランディング フロー型のビジネスにおいても、長期的にユーザーと関係性を作る上で重要なのがブランディングです。今年の8月に、これまで「ナース人材バンク」という名前だった看護師向けの転職サービスを「ナース専科 転職」という名前に変更し、他の看護師向けのサービスとブランド統合を行いました。 https://www.bm-sms.co.jp/news-press/prs_20240805_nursesenka-renewal/ ブランドを作るというのは、ユーザーとの関係を長期で考えている証であり、単発の転職というイベントでユーザーを支えるのではなく、次の転職でも使いたい、職場で困ったことがあったらナース専科を頼ってみようと考えてもらえるようなサービス作りを計画しています。 キャリア事業横断システムのアップデート システム面でも、今年は大きな取り組みをスタートすることができました。詳しくはこちらのブログに書かれているのでぜひ読んでみてください。 tech.bm-sms.co.jp キャリア事業のビジネスの歴史は長いので、どうしても個別最適や目の前の数字の達成のための仕組みがあるのですがこれに対して、今考えられる理想的なアーキテクチャを議論し、それに向かってどのように階段を登っていくのかという議論をしています。 長期を考える時間を意図的に取る 基本的に事業としてやりたいこととエンジニアの人数を比較すると、やりたいことの方が必ず多くなります。そんな中で長期目線を考える時間を取ることには意思が必要です。キャリア事業横断システムのアップデートは今年に入ってから毎週チームメンバーとオフラインで顔を突き合わせて未来のあるべき姿を議論するといった時間を意図的に取るようにしています。 長期を考える仲間を募集しています 色々と偉そうな事を書きましたが、現実は目の前でやらないといけないことと、将来のために考えないといけないことの両方が山積みです。 少子高齢化により生じる医療人材不足の解決に対して長期的に一緒に取り組んでくれる仲間を募集しています！

この記事は株式会社エス・エム・エス Advent Calendar 2024の12月19日の記事です。 qiita.com エス・エム・エス BPR推進部の佐々木と申します。 BPR推進部は、全社横断でビジネスプロセスと、その中で扱われるITシステムを最適化し生産性を向上させることをミッションにした組織です。 私はその中でキャリア／介護・障害福祉事業者／ヘルスケア／シニアライフといった国内事業の改善推進を主管するEA推進Grのグループ長をさせていただいています。 今回はBPR推進部とプロダクト開発部が共同で検討を進めている、キャリア事業領域を中心とした各種のデータ・業務管理基盤の見直しについてご紹介できればと思います。 はじめに エス・エム・エスでは、介護/障害福祉事業者向け経営支援サービス「カイポケ」や看護師向け人材紹介サービス「ナース専科 転職」、介護職向け求人情報サービス「カイゴジョブ」など、主に介護・医療・障害福祉・保育といったドメインに対する 多様なサービスを展開しています 。 その中で、人材紹介サービス・求人情報サービス・教育サービスなどの、従事者の方々がよりよいお仕事に就業されるための一連のサービス群を「キャリア事業」というドメインとして捉えています。 今回ご紹介するのは、このキャリア事業においてサービスの提供や社内の様々なオペレーションで発生・蓄積されるデータを管理するシステムアーキテクチャの改善に関するお話です。 前提/背景 このキャリア事業はエス・エム・エスの事業の中でも 歴史が古く、多様なサービスを展開している領域 です。 これまで様々なサービスを小さく生み出し大きく育てていく中で、サービスや裏側にある業務システムは、その時々の要求や様々な制約を踏まえて個々に最適化されたシステム・データ設計がされてきました。 これ自体は決して悪いことではなく、ビジネスモデルやドメイン特性（キャリア事業の場合は主に向かい合う従事者や事業者の属性）、事業のフェーズによって、個々のサービスで管理したい情報や事業の変化スピード・量は様々であるため、それぞれに適した形で構築していくことは必然と考えています。 ただ生み出されたサービスが拡大していく中で、業務担当者（ステークホルダー）の役割も多様になり分業化されていきました。 その横で、さらに新たなサービスを展開していくと、既存の資産を有効活用する形でシステムとオペレーションも効率的に構築されていきます。 ですがシステム毎に持っている機能に横断的に手を加えたり、システムを跨いで保持したいデータが発生するなど、要求が複雑・高度になっていくと、その構造と多様なステークホルダーのニーズとのバッティングが制約となって、サービス改善のボトルネックになるケースも出てきました。 また個々のサービス間でのシナジーを生み出し、ユーザーに対しての価値を事業全体で最大化していこうとすると、サービス提供や運用の中で発生・蓄積される各種のデータを個々の中で閉じたものとせずに、事業ひいては全社の共有アセットとして蓄積・管理し、サービスの改善に活かしていくといった戦略的なデータ活用も求められてきます。 今後5年・10年という中長期のサービス拡大や提供価値の最大化を見据えた際に、キャリア事業においてコアとなる従事者や求人・事業者情報、各種サイト上のユーザー行動情報といったデータを、適切な粒度でモデリングしなおし、効率的に管理できるアーキテクチャに再設計することで、事業活動やユーザー行動の横断的な分析や、より有益なユーザーの方々への求人レコメンドといった機能提供を可能とし、事業成長に貢献するシステム基盤の構築を目指していきたいという機運が開発組織内で高まってきました。 実現したいと思っている世界観（コンセプト） あるべきアーキテクチャを考えていくにあたり、大きく以下の三つのコンセプトを立てました。 1. 役割に応じたシステムの統合と分割 社内外のオペレーション・プロセスのインターフェイスとなる機能群（プロセスマネジメントシステム）と、そこから生み出されるデータを蓄積・管理する機能群（データマネジメントシステム）を切り分け、ドメイン特性に応じたプロセスに対する柔軟なチューニングを可能にする。 事業にとってコアな情報を扱うデータマネジメントシステムは、各領域で分散せず統合管理することで、事業横断で最新の正確なデータが共有される構造にする。 2. システム内部構造の共通／個別の最適化 共有する機能やデータの中でも、ドメイン特性に関わらず普遍的な部分を共通化、ドメイン特性に応じて保持したいものは個別化することで、過度な共通化による影響範囲の肥大化を防ぐ。 3. システムの役割に応じた最適なアーキテクチャの選定 世の中のプラクティスを取り入れやすいSaaSベースの業務システムや、事業の競争力の源泉やドメインの独自性を受け止めるスクラッチ開発領域などを適切に見極めて、全体設計すること。 一つ一つはどれも当たり前のことを言っているにすぎませんが、事業が成長してきた今だからこそ、改めて最適なシステム設計を考えることができる観点だと思っています。 これまで進めてきたこと まずはエンジニアリング組織からの目線で課題感や理想像の言語化し、それを事業に投げかけてみるといったところからスタートしました。 エス・エム・エスのよいところはこうした課題感を、経営や事業責任者も交えたオープンな場にダイレクトに持ち込んで議論ができるところです。 この中で、エンジニアリング組織だけでは深めきれなかった、構造の変化にビジネス上の価値がどのようにあるかといった視点も踏まえ、事業全体でこのイシューにどう取り組むか（どのような時間軸でどれくらいの投資をしていくか）といったことをすり合わせてきました。 また、実際にシステムを扱って日々の業務を行ったり、直接的な顧客接点を持ってニーズの解像度の高い業務部門からも、意見を聞きながら進めていきました。 大きな業務の変革を伴う話でしたが、未来を見据えてより良くしていくことにポジティブなフィードバックをもらえ、非常に心強かったです。 今後 これまでは企画・検討中心のフェーズでしたが、2025年はいよいよ実行のフェーズに入っていきたいと考えています。 ここまで社会貢献性が高く、規模化している事業のシステムアーキテクチャの見直しを、誰かに言われたり決まったこととして降りてくるのではなく、自分たちが課題感を持って主体的に進められる環境や機会はなかなかないと思っています。 ただ悔しいかな参画メンバーは、みんな本務がある中で有志のような形で集まっているので、思い通りに時間が使えていないこともあり、今後は成果を意識したアウトプットを積み上げていきたいです。 本当はもっと色々と書きたいこともあるのですが、また別の機会に… ちょっと興味ある方、詳しく聞いてみたいという方は、カジュアル面談のような形でのご連絡大歓迎です！

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

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

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

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

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