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

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

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

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

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

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

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

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

こんにちは！夏ですね。 @kimukei です。 今回は、弊プロジェクトの カイポケリニューアル で ADR を導入しましたというお話です。 ADRとは、「Architecture Decision Record」または、「Architectural Decision Records」の略でアーキテクチャ上で重要な決定を記録するドキュメントです。 詳しくは「 DOCUMENTING ARCHITECTURE DECISIONS 」 や「 Architectural Decision Records 」をご覧ください。 また ADR については、以前弊社の酒井が登壇したイベントでも触れられておりますので、こちらの記事もあわせて読んでみてください。 tech.bm-sms.co.jp ADR を導入しましたってエントリは巷には溢れかえっているので、今回はちょっと趣向を変えて実際に私たちが運用している ADR の形式にそって 「ADR を導入する」という意思決定に至った流れを書いてみようと思います。 以下に ADR の実例を示します。 ADR を導入する ステータス 2024年5月14日 Proposed 2024年5月17日 Accepted コンテキスト カイポケリニューアル は、プロジェクトが発足して3年以上経過している。 それゆえにすでにコンテキストは分厚いのだが、技術スタックの選定理由や当時の検討のログは散らばり、中には当時の在籍者に聞かないと詳細は不明なものがあり、疑問に思っても疑問が完全に消化しきれないことがある。 また、今後新しい技術の採用を考慮する際に、過去の選定理由やトレードオフスライダーを参照できないために、新しい技術の善し悪しの判断が曖昧になる懸念がある。 今後近いうちに、カイポケリニューアルにおいて非同期処理やイベント駆動処理の技術選定が必要になってくることが考えられる。その際の技術選定の議論やコンテキストをまとめておく必要性を感じている。 これらの課題を解消するため ADR を導入することが有効である。また、過去の情報を集めて ADR として再生成することで必要に応じて過去の意思決定も記録しておける。 決定 ADR を導入する。 ADR の目的は、他のチームや新メンバーに技術的な決定の経緯を共有すること。 つまり検討内容が完璧である必要はなく経緯を知ることで未検討な部分を後から追加検討したりできる。 アーキテクチャ上重要なものは、なるべく ADR を書く。 構造、非機能特性、依存関係、インターフェイス、構築手法の5つの観点で意思決定するものはなるべく ADR に書き起こす。 もし書くべきかどうか迷ったり気になった場合は相談相手としてADR 運用チームを指定できるようにする。 運用に慣れてきたらそれぞれのチームに相談やレビューなどを移譲する。 また、過去の意思決定について ADR があったほうがいいんじゃないかというものは GitHub Discussions ページを用意したので、そこにコメントして投票式で得票数の高いものから作っていく。 影響 新しいアーキテクチャや技術の導入の際には、議論の叩き台や決定したことの記録として ADR を書くようになることが想定される。 アーキテクチャ上のコンテキストや遵守方法が ADR に集中される。これにより参照性が高まり、新しく Join したメンバーのオンボーディングなどにも利用できる。 遵守方法 (Compliance) 構造、非機能特性、依存関係、インターフェイス、構築手法の5つの観点で意思決定するものはなるべく ADR に書き起こす。 新しいアーキテクチャや技術要素だったりを導入する際は ADR を書くことまでをなるべくタスクに含める。 ADR にはゆるめなテクニカルライティングのルールで textlint をかけているのでそのライティングスタイルに沿う。 備考 オリジナルの著者: @kimukei 承認日: 2024/05/17 承認者: ADR運用チーム、開発チーム 置き換え日: n/a 最終更新日: 2024/07/05 こんな感じです！ 参考にした ADR テンプレートは『 ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 』の第Ⅲ部 19.3 「アーキテクチャデシジョンレコード」や、 joelparkerhenderson/architecture-decision-record などです。 管理場所は GitHub 上でモノレポ化 1 したリポジトリで docs/adr/ を切ってそこで行っています。 Pull Request に discussion 履歴などが残ることや GitHub Actions があることによるCI/CDの自由度の高さ（フォーマットの遵守もそうだが、GitHub Pages に出力するなど）が便利ですし、最近だと AI の学習のためにこの手のドキュメントとコードをあまり離さないほうが良いかもしれません。 ちょうど最近弊社は GitHub Enterprise 化したので GitHub Copilot Enterprise がこの辺のドキュメントを読んでレスポンスをくれるようになりました。 運用してみて ADR のドラフトを叩き台にしてチームを跨いだ技術選定の議論が行われた たとえば、最近 SRE チームと開発の1チームでバッチ処理基盤が欲しいので作ろうという話をしていたのですが、その中で議論の叩き台として ADR のドラフトが活用されていました。 そして関係者が合意してドキュメントがまとまったら ADR の Pull Request を Ready for review にして ADR 運用チームからレビューをもらうという流れがとても自然でした。 過去の歴史を紡ぐ動きが出てきた カイポケリニューアルでは、通信に GraphQL を採用しているのですが、当時在籍していたメンバーがその経緯や考えていたことを ADR に書いてきてくれたりしました。 また、マイクロサービスアーキテクチャのトポロジーを組んでいる理由や、そもそものカイポケリニューアルに至った背景や決定が再言語化され ADR となりました。 大元の「なぜ」の部分がかなり明確になり、開発の意思決定もよりしやすくなったと感じます！ エンジニア以外の職種でもこのような決定を記録するやり方が広まった ADR は 「Architectural」な顔をしていますが、実際は Decision Record つまり決定の記録フォーマットとしても有用です。 PO や PdM でもProduct Decision Record(PDR) として、似たような決定事項やコンテキストを記録するフォーマットが使われるようになりました。 同じようなフォーマットが使われていると職種を横断してドキュメントを見にいく時も認知負荷を減らしてスッと入ってくるのでいいですね！ さいごに ADR、いい感じです！ フォーマット自体が決定の記録として有用なので汎用性があり、かなり組織文化にも影響をもたらすものだと感じます。 エス・エム・エスではともに試行錯誤しながらよいサービスを作ってくれる仲間を募集しています！ カジュアル面談も実施していますので、ぜひお気軽にご連絡ください！ カイポケリニューアルでモノレポにした話: https://zenn.dev/kimuchan/articles/f5ba954ca4fbf8 ↩

こんにちは、プロダクト推進本部人事のふかしろ( @fkc_hr )です。今年のSRE NEXTでGOLDスポンサーをし、当日はブースも出す予定です。 sre-next.dev エス・エム・エスには複数のSREチームがあり、様々な方とお話をできればと楽しみにしています。 今回は事前に一部メンバーから気になるセッションの紹介とブースでプレゼントできる缶バッジのご案内をいたします。 気になるセッション共有 大きな組織にSLOを導入し運用するということ、その難しさ カイポケSREチームの 加我 です。 サービスの信頼性の計測においてSLI/SLOを利用するというプラクティスはSREであれば多くの人が知っているかと思います。しかし、いざSLI/SLOを導入・実践しようとしても正しい運用ができず形骸化してしまい、頓挫してしまったという経験が私にはあります。DMM様のような大きな組織でSLI/SLOをどのように策定し運用しているのか興味があり、気になるセッションとして挙げさせていただきました。 医療キャリアチームSREの 伊藤 です。 医療キャリア事業には複数のプロダクトがあり、それぞれのプロダクト開発を複数のチームが担当しています。各チームの文化やSRE活動に対する習熟度にはばらつきがあります。DMM様の抱える課題感と似た問題を感じており、どのようにアプローチされているのか非常に興味があります！ Central SREとEmbedded SREのハイブリッド体制で目指す最高のSRE組織 全社SREの 髙橋 です。 エス・エム・エスにおいても全社SREと事業部毎のSREのハイブリッド体制を敷いています。組織としてより良いパフォーマンスに繋げるためにどのように関わっていくべきか、個人的にも日々試行錯誤しています。完璧な正解があるわけではないのですが、他社がどのようにしているか非常に気になります！ Becoming SRE - SREって何から始めればいいの？ ハピすむSREの上山です。 私自身SREという職種をあまり意識することなくエンジニア活動をしていましたが、結果的に技術スタックがSREと一致して今の環境があるので、SREを目指すとき何をしたら良いのかという観点が気になりました。 缶バッジプレゼントのご案内 事前申込みを頂いた方にはブースにてご自身のSNSアイコン *1 の缶バッジをプレゼントさせていただきます。 ※サンプル(直径57mmです) SRE NEXT 期間にエス・エム・エスのブースに取りに来ていただける方は以下のフォームよりご応募ください！ https://careers.bm-sms.co.jp/engineer/event-srenext2024 ※応募者数により、抽選とさせて頂く可能性がございます。 終わりに SRE NEXTにてみなさまとお話させていただくことを楽しみにしております！ また、SRE NEXTには参加できないが、エス・エム・エスに興味を持ってくださって、もっと話したいよと思っていただいた方は以下からカジュアル面談にお申し込みください。 *1 : 申込フォームに指定していただいたXアカウントで設定しているプロフィール画像

はじめに 2024年4月にエス・エム・エスに入社した泉澤です。現在、介護事業者向け経営支援サービス「カイポケ」のフルリニューアルプロジェクトに携わり、フロントエンドエンジニアとして機能開発を行っています。 careers.bm-sms.co.jp まだ入社して3ヶ月ではありますが、今までの経歴や転職した背景などに触れ、入社して感じた前職との違いや、この3ヶ月をどのように過ごしてきたかを振り返っていこうと思います。現在転職を考えている方や、エス・エム・エスに興味を持っている方の参考になれば幸いです。 今までの経歴と転職した背景 新卒でITメーカーに入社し、1年間法人営業を担当していました。当時は2020年でコロナ禍の最中だったため、入社早々に働き方がテレワーク中心へ切り替わる、学生時代の想像とは違う社会人生活のスタートとなりました。出社が不要になり可処分時間が増えた反面、オンライン商談やリモート飲み会など、画面越しでのやりとりに四苦八苦したことを今でも覚えています。 その後、縁あって未経験で前職の受託開発企業に転職しました。フロントエンドエンジニアとしてVue.js（Nuxt）やReact（Next.js）を用いた開発を担当し、教育、冠婚葬祭、不動産、官公庁など様々なドメインの案件に携わりました。入社して間もない頃から、慢性的なフロントエンドエンジニアの不足で開発リーダーを任せていただく機会があったのですが、エンジニアの層や案件の開始時期によっては経験できないこともあるため、早期にリーダーとしての経験を積めたことは幸運だったと思います。実装方針や技術選定の裁量権があり、環境構築からリリースまでの一連の工程に携わることができた経験は今でも代えがたいものです。フロントエンド開発の責任を背負うポジションだったため、開発に対して当事者意識が芽生え、エンジニアとして大きく成長するターニングポイントとなりました。 転職を決意したきっかけは、副業で自社開発企業の開発に携わっていた経験が挙げられます。小さなベンチャー企業でしたが、本業の受託開発企業のように納品して終わる関係性ではなく、継続して事業を成長させる働き方に魅力を感じました。副業メンバーでありながら経営会議に出席させていただいた際、チーム一丸となって何かをやり遂げる熱量に触れたことも大きな要因となっています。この経験から「継続して事業を成長させる働き方」に強い興味を抱き、転職活動を始めました。特に注視していたのは、携わる事業内容です。受託会社で様々なドメインの案件に携わってきた経験から自分の興味のある分野や自分ごととして捉えられる分野に対しては、モチベーション高く開発に取り組むことができると実感していたからです。 転職活動をする中で、様々な企業様と面談・面接をしてきましたが「自分自身が一番熱量を持って、当事者意識を持って働くならここしかない」と感じたのがエス・エム・エスでした。面談・面接の際に介護の将来についてお話を伺い、将来に対して強い危機感を覚えました。選考が進むにつれて自分がその課題の当事者となることを想像した時に、既に顕在化している問題に対して何もせずにいたことに後悔したくない。自分もその課題に取り組み、そして数十年後を振り返った時に「課題解決に貢献したんだ」と胸を張れる自分でいたいと思いエス・エム・エスへ入社することを決めました。 入社3ヶ月を振り返る 事業ドメインのキャッチアップ 入社後はカイポケリニューアルプロジェクトのケアマネジメントチームに配属されました。まず開発に関わって一番驚かされたのは、介護ドメインの複雑さです。3年ごとに見直される介護保険制度の改正も相まって、常に情報のキャッチアップが欠かせません。この背景があるため、新しい開発エピックに取り組む際の勉強会や、法改正による新しい情報の共有会などが都度、実施されているのが印象的でした。 最初の1ヶ月ほどはチームでのオンボーディングがあり、1日の中で疑問に思った用語や仕様について質問する時間を設けていただきました。社内情報ツール（esa、Notion、Miro）にある議事録も交えながら説明していただきましたが、質問した内容には大体まとまった資料が既にあることが多く、カイポケリニューアルプロジェクトでは全体的にドキュメントを残す文化が強いと感じました。また、説明を通じて必要な情報にどうアクセスするか、社内情報ツールのハウツーも学ぶこともできました。 個人的な事業ドメインのキャッチアップとしては、書籍購入制度を利用し、書籍からも学びを得るようにしています。全社向けに事業ドメインに関するおすすめ書籍が紹介されているので、迷わず優良な書籍を手に取ることができました。書籍購入制度ではもちろん技術書も購入できるので、その用途で利用している方も多く見受けられます。 フルリモートでスクラム開発に取り組む 私が所属しているケアマネジメントチームでは、開発手法としてスクラム開発を取り入れており、隔週でスプリントを回しています。複雑な開発エピックに取り組む際は、積極的にペアプログラミングやモブプログラミングの機会を設け、チームで認識を揃えながらスプリントゴールを達成できるように開発を進めています。開発チケットに関しての担当の割り振りは特になく、プルリクエストについても気づいたメンバーが対応する、自主性が重んじられる文化が根付いています。エンジニアに限らず、Slackでメンションが飛んでいなくてもスレッドに参加して意見を述べる方も多く見受けられ、当事者意識の強い方が多く在籍している印象があります。主体性の範囲が広いのは前職との大きな違いだと感じました。 スクラムイベントを含め、定期的に開催されるミーティングでは当番制でファシリテーターを回しています。質問をする前に背景情報を提示したり、枕詞を加えて言葉の意味合いを和らげたり、時には強調したりと、ソフトスキル面で多くの気づきを得ています。また、日々のミーティングの中には雑談系のミーティングも含まれているため、フルリモートで働くことが初めての私にとっては関わるメンバーの人間性を理解できる場として、逆に自分を知ってもらう場として非常に助かっています。 話が脱線してしまいますが技術的な発散の場としてはpotatotipsという週次で開催されている社内勉強会や、同じく週次ではありますが、フロントエンド技術雑談が設けられているのでフルリモートで働いていても様々な方と繋がりを持てている印象が強いです。 tech.bm-sms.co.jp 最後に 一概には言えませんが、面接官が違う職種の方や入社してから既に数年が経っている方だったりすると、入社後〜半年くらいのイメージを掬い取ることが難しく、実際に入社してみないとわからないケースがあると思います。私自身、企業に興味を持っても入社後どのような働き方になるのか想像が膨らまず見送ったことがあるので、それが少しでも解消できればと思いこの記事を執筆しました。 また、「スクラム開発が初めて」「フルリモート稼働が初めて」「介護ドメインが初めて」と不安要素が多めの状態で入社したのですが、それらを払拭する環境がエス・エム・エスには備わっていることが分かったので、同じく不安に思っている方やエス・エム・エスに少しでも興味を持っている方に伝われば良いなと思いました。 エス・エム・エスでは開発メンバーを募集しています。介護事業者向け経営支援サービス「カイポケ」のフルリニューアルプロジェクトに興味を持ったり、高齢社会や少子化という社会課題に対して挑戦してみたいという方がいらっしゃいましたら、ぜひこちらも覗いてみてください。改めて、この記事を通してエス・エム・エスに興味を持っていただけましたら幸いです。最後までご覧いただきありがとうございました。

はじめまして、介護事業者向け経営支援サービス「カイポケ」 のエンジニアの大縄です。 本記事では、カイポケの障害児支援領域のリプレースで実施したドメインモデリングについて、実際のドメインを題材にどのように実施したかを紹介させていただきます。 ドメイン駆動設計を参考に実施しているところもありますので、ご興味のある方の参考になれば幸いです。 リプレースの背景 障害福祉の制度は概ね 3 年に 1 度改定されます。プロダクトも新制度に追従していく必要があるのですが、制度が複雑であり開発日程もタイトであることから、プロダクトの仕様やコードベースを最適化することを犠牲にした結果、仕様が複雑化し、それに引きづられてコードベースも複雑度が高く肥大化した状態となっていました。 リファクタリングなどの改善は行なってきたものの、「複雑化した仕様」「肥大化したコードベース」に対して変更を入れることは容易ではなく、ユーザーへの価値提供を増やしたくても増やせない状況が続きました。 このままではまずいと感じつつもなかなか根本解決に踏み切ることができなかったのですが、次回の制度改定まで期間があり、ドメインやプロダクトに関する知識も蓄積できてきた、というタイミングが巡ってきたことから、根本的な解決としてリプレースを行うことになりました。 リプレースでは大きく以下の 3 つを行いました。 既存の仕様を参考にしつつも、複雑さを排除した新たなドメインモデルを設計・構築する 言語の表現力も借りて、基本に沿って秩序あるコードベースを再構築する ドメインモデルとコードベースに対し、変更容易性を維持する仕組み作りや取り組みをする 本記事では、「1. 既存の仕様を参考にしつつも、複雑さを排除した新たなドメインモデルを設計・構築する」に対する取り組みの一例を紹介させていただきます。 より詳細なリプレースの背景については「 ユーザーへの価値提供機会を増やすためにリプレースを決意した話 」で説明されていますので、是非ご覧いただければと思います。 題材とするドメインは「学校休業日」 リプレース対象であるいくつかのドメインのうち、「学校休業日」というドメインを題材に説明していきたいと思いますが、まずは題材の前提知識として「学校休業日」をモデリングした背景について説明します。 障害児支援領域には、学校に就学している児童に対して授業終了後または学校が休みの日に生活能力の向上のために必要な訓練や社会との交流促進などの支援を行う「放課後等デイサービス」というサービスがあります。 このサービスの利用料金の一部は自治体に請求するのですが、「授業終了後にサービスを提供した場合」と「学校が休みの日にサービスを提供した場合」で料金設定が異なり、また、サービス内容によっても料金が細かく分かれています。 カイポケには、日々のサービス提供の内容から利用料金を算出できるよう、あらかじめ学校の休業日を設定するための機能があり、この機能もリプレース対象の一つとしていたため、「学校休業日」をモデリングすることになりました。 2 つのステップで実施するドメインモデリング ドメインモデリングの定義は様々あると思いますが、以下 2 つのステップをドメインモデリングと捉えて実施しました。 【ステップ１】ドメインの理解 対象のドメインについて調べ、関係性や決まり事を整理する 【ステップ２】ドメインのアプリケーション設計 対象のドメインをアプリケーションで実現するための設計を行う 以降にそれぞれの詳細を説明します。 【ステップ１】ドメインの理解 このステップでは、対象のドメインについて調べ、関係性や決まり事を整理します。 まずは、放課後等デイサービスにおける休業日がどのように定義されているのかを調べました。 厚生労働省の資料（ 平成27年度障害福祉サービス等制度改正に関するＱ＆Ａ（平成27年3月31日） ）によると、以下のように定義されています。 ・学校教育法施行規則第 61 条及び第 62 条の規定に基づく休業日（公立学校においては、国民の祝日、日曜日及び土曜日、教育委員会が定める日、私立学校においては、当該学校の学則で定める日） ・学校教育法施行規則第 63 条等の規定に基づく授業が行われない日（例えば、台風等により臨時休校となる日）又は臨時休校の日（例えば、インフルエンザ等により臨時休校の日） なお、学校が休業日ではない日に、放課後等デイサービスを午前から利用した場合であっても、休業日の取扱いとはしない。 上記を入り口に、 学校教育法施行規則 を調べて「教育委員会が定める日」とはどんな日があるのかを把握したり、国民の祝日はどのように定められるのかを調べたりすることでさらなる理解を深めていきました。 また、今回の対象機能が「あらかじめ学校の休業日を設定するための機能」なので、事業所がいつどのように休業日を知るのかを実際の事業所にヒアリングさせていただいたりもしました。 そして、これらの内容を調査しながら整理し、以下のように図示していきました。 クラス図に近い図ではありますが、ステップ１では実装を意識せずにまとめていきました。（ドメインを理解できる形であればどのような形式でも良いと思っています。） 【ステップ２】ドメインのアプリケーション設計 このステップでは、ドメイン理解の図をもとにドメインをアプリケーションで実現するための設計を行います。 設計する際には『 エリック・エヴァンスのドメイン駆動設計 』で紹介されている "集約（Aggregates）" というパターンを参考にしました。 集約とは、関連するオブジェクトの集まりであり、以下のように実現されると理解しています。 集約の中からルートとなるオブジェクトを決め、変更は必ず集約ルートを経由する 集約ルートが集約内の不変条件（データが変更されるときに維持されなければならない一貫性のルール）をチェックする最終的な責務を負う 集約単位でデータの取得・永続化を行う 永続化の入り口には集約ルートしか渡せないし、集約ルートしか返せない 集約を利用した処理の流れを簡単に図示すると以下のようになると考えています。 カイポケ障害児支援領域のリプレース前のコードは、同一テーブルに対する処理が色々な場所で実装され、不変条件のチェックもそれぞれ実装されているケースが多々ありました。よって、集約の概念を取り入れ、関連する情報に対する不変条件のチェックや永続化処理を一箇所に集めることで重複を排除し、秩序あるコードベースを構築しようと考えました。 「学校休業日」の集約を定義する ここから実際に「学校休業日」をアプリケーションで実現するための設計をしていくのですが、まずは以下のように、アプリケーションとしてどのように学校休業日が設定できれば良いかを考えました。 公立の学校は市町村・または都道府県の教育委員会によって休業日が決まるが、私立の学校は学校ごとに校則で定められることから、学校ごとに休業日が設定できればどちらもカバーできると考える 学年ごとに休業日が異なるケースや臨時休業日があることから、利用者個別に休業日を設定できるようにもする 土日、国民の祝日はユーザーが設定できるものではないため、学校休業日を設定する際のデフォルト値として利用する（国民の祝日はシステムのマスタデータとして管理されているものを使う） 上記をもとに集約を定義し図示していきました。 集約を定義する際に考慮しなければならないこととして、「集約は小さくする」ということが挙げられます。なぜなら、データの取得・永続化やロック（楽観的排他など）が集約単位で行われるためです。集約が大きすぎると、パフォーマンスの悪化や複数ユーザーで作業ができないといった問題が発生してしまいます。そのため、「不変条件は何か」だけでなく「どのようなユースケースがあるか」ということも考えながら大きくなりすぎないように定義していきました。 「学校休業日」の場合、ドメイン理解の図に記載されているように、基本的には年度単位で休業日が決まるが月初や当日に初めて休業日を知るケースもある、ということから、何度も更新が発生することが予想され、また、利用者に対するサービス提供の業務が月単位のサイクルである、などの理由から月単位の集約としました。 また、名前付けについてもチームで合意をとりながら進めていきました。ここで定義した集約はそのまま実装に反映されるため、和名だけでなく英名も決め、アプリケーションで一貫して同じ名前を使えるようにしました。 ここでひとまず「学校休業日」の集約が定義できたわけですが、定義した集約をを使用して実際に利用者に対するサービス提供を登録することを考えると、現状のままでは利用者と学校が関連づいていないため月間学校休業日を特定できないという問題があります。 よって、ステップ１のドメイン理解に戻り利用者と学校の関連付けについて理解を深め、ドメイン理解の図を更新していきました。（利用者と学校の関連付けを「所属学校」として追記） そして、ドメイン理解の図をもとに同じように集約を定義していきました。加えて、利用者に対するサービス提供を登録するときに集約がどのように使われるかについても記載し、最終的には以下の集約定義となりました。 このように、必要に応じてステップ１とステップ２を繰り返しブラッシュアップしていきました。 ドメインモデリングは今後も続く 今回の成果物である「ドメイン理解の図」と「集約設計の図」は一度限りの図ではなく、メンテナンスし続けていくドキュメントの 1 つとしており、実際の改修の際にもまずはドメインモデリングをしてからバックエンド、フロントエンドの開発を行っています。 おわりに カイポケの障害児支援領域のリプレースで実施したドメインモデリングについて、実際のドメインを題材にどのように実施したかを紹介させていただきました。 モデリングの対象となったドメインは他にもいくつかあるのですが、振り返ってみると、チームで議論しながら進めていくことの難しさを感じることもあったように思います。しかし、ドメインに対する理解が深められ、また、チームでの意思決定が形として残ることが後の開発の助けにもなりましたので、やって良かったなぁ、と改めて思いました。 今回紹介させていただいた活動が少しでも参考になれば幸いです。

こんにちは！ 5月に株式会社エス・エム・エスへ入社しました、SREの西田和史です。 今日はAmazon Web Services（以下AWS。各サービス名も一般的な略称で表記します）周りのTipsを共有します。 解決したい課題 AWSマネージメントコンソールで特定のサービスのページを開こうとすると、たくさんのサービスがあることもあり結構手間がかかります。 よく使うサービスはホーム画面にリストで表示されていますが、リストの順番は毎回変わりますし、 検索機能も使いにくく、「ECR」など妥当なキーワードでも対応するサービスが出てこないこともあります。 解決策 Google Chromeのサイト内検索機能を使います。 手順 chrome://settings/searchEngines を開きます(もしくは次の画像のメニューのクリックでもOK) サイト内検索の項目で「追加」のボタンを押す 次のように入力して「追加」ボタンを押す 名前: awsサービスを開く ショートカット: aws URL（%s=検索語句）: https://console.aws.amazon.com/%s/home 使い方 EC2の画面に行きたい場合、 Windowsであれば Ctrl-L 、Macであれば Command-L でフォーカスをGoogle Chromeのオムニバー(アドレスバー)へ移動 aws ec2 と入力 (次の画像のような表示になる) エンターを押す コツと欠点 このテクニックを使うには、飛びたいAWSサービスのURLを予め知っている必要があります。 具体的には、IAMの画面に飛びたい場合、IAMマネコンのURLは https://us-east-1.console.aws.amazon.com/iam/home ですが、この https://us-east-1.console.aws.amazon.com/ と /home の間に挟まれた文字列である iam をGoogle Chromeのオムニバーで入力する必要があります。 この文字列は iam ec2 s3 など比較的そのままのサービスもありますが、 apigateway (API gateway)のようにスペースがないものがあったり、CloudWatch LogsやELBなど、この方法で開けないページもあります。 おまけ: この方法で開けない、ELBなどのページはどうやって開くか 諦めてGoogle Chromeのオムニバー上で loadbalancer と入力しています。 ELBのURLには loadbalancer という文字列が含まれているので、Google ChromeのオムニバーによるサジェストでELBのURLが一覧に表示されます。 何度も呼び出しているとやがて一番上にサジェストされるようになるので、最小限の手間で遷移できるようになります。

こんにちは、エス・エム・エスで人事をしているふかしろ( @fkc_hr )です。 今回、X Mileさんにお声がけいただき、アンドパッドさんと3社合同で「 バーティカル SaaSで拓く未来：社会課題に立ち向かう開発の舞台裏 )」というイベントを開催いたしました。 エス・エム・エスからはカイポケ開発部の酒井( @_atsushisakai )が登壇し「大規模 SaaS の技術的意思決定を支える三要素」についてお話しました。 当日はアンドパッドさんのコミュニティスペースでのオフライン実施と、YouTubeのオンライン配信のハイブリッド型で実施し、各社の執行役員や開発責任者 のLTとオフライン懇親会を実施しました。 バーティカルSaaSとは業界・業種に特化しているSaaSのことです。エス・エム・エスではカイポケが該当します。 各社向き合っている業界やプロダクトのフェーズは様々であるものの共通点の多さに懇親会も非常に盛り上がりました。 主催企業以外の方もいらっしゃったのですが、ドメインを深掘りしていくこと、法律などの制約の中でも最適な設計をしていくことなど様々な観点で興味を持っていただきました。 普段、介護・医療といった切り口で会話させていただくことは多いのですが、バーティカルSaaSという切り口は初めてだったので、改めて新しいきっかけを提供いただいたX Mileさんには感謝の気持ちでいっぱいです。 現在エス・エム・エスでは開発組織のXアカウント ( @BM_SMS_Tech )で以下の様な内容を発信しています。 テックブログ Podcast デザイナーnote イベント協賛や登壇情報 今年から Podcast や note なども開設していたり、外部イベントも増えておりますので、ぜひフォローのほどよろしくお願いいたします。 では、改めて今回のイベントに興味があったけれども参加しそびれちゃった方や、カジュアル面談でバーティカルSaaSについて話したい方は以下のフォームからご応募お待ちしております！

はじめまして 2024年にエス・エム・エスに入社した まゆゆ です。プロダクト推進本部の人事として @fkc_hr と一緒に日々 プロダクト推進本部の採用活動をしています。 エス・エム・エスに入社してこのブログが公開される頃には4ヶ月が経ったくらいのタイミングかと思います。 私は気がついたらなんだかんだ干支一周分くらいの年数をこのIT・Web業界で過ごしていて、いつのまにか半分近く採用領域に関わっていました。 ただ、その間にライフステージに変化があり、産休・育休を経て、途中で採用に関わるのはほんの少しだったりしたこともあったので、経験年数としては正味5年行かないくらいになるかなと思います。 今回、子育てをしながら日々仕事をされている方、弊社で子育てをしながら働くことに関心がある方に興味を持っていただけたら幸いです。 育休からの仕事復帰やコロナ禍を経て抱えた葛藤 今年の春に息子もめでたく小学校1年生になり、私自身としても2019年に育休から仕事に復帰して、ワーママとしても5年生になりました。 ワーママも5年やっていればベテランだねという声も聞こえてきそうですが、 振り返ってみれば、正解のないことに向かって、常に試行錯誤をしてきたような気がします。多分それはこれから先も変わらないと思っています。 特に2020年以降はコロナ禍で社会情勢も大きく変化があったりして、「子育て」という未知数な人生の一大プロジェクトを走らせている中で、さらに自分の意志だけでは変えられないものを抱えざえるを得ない感覚を持っていたのはきっと私だけではないはずです。 これは全ての方に言えることかもしれませんが、これまで抱えることのなかった不安な気持ちやモヤモヤが急に降ってきた時期だったかと思います。 この時期に子育てをされていた方々は、安心して子どもたちが保育園に行ける日は来るのだろうか？自宅保育と仕事の両立を続けることができるのだろうか？常にそんなことを気にしながら日々過ごしていた時期かと思います。 振り返ってみるとこの5年は、常に生活と子どもの状況と、それを取り巻く環境を見ながら変化をし続けてきたような気がします。それは今も同じです。 変化してきたものと変わらなかったこと コロナ禍でリモートワークを余儀なくされた企業も多く、混乱の中で働き方が大きく変わりました。 当初、自宅保育をしながらのリモートワークを我が家でもしており、当初はバランスの取り方にも大変苦労しました。 時が経つにつれ、制限がある中でも保育園に行けるようになりました。親としても、子どもが保育園に行っている間に仕事に集中でき、送り迎えも通勤がないことで時間的コストがそこまでかからずに済む環境でした。 育休からフルタイムで復帰後、時短の派遣に働き方を変えた時期もありましたが、リモートワークのおかげでエンジニア採用領域でのキャリアを積み上げることができたのだと、今振り返ると強く感じています。 コロナ禍がなければ、今でも働き方をかなりセーブをしているか全く異なる仕事をしていたのではないかと思います。 子どもの状況や社会情勢で働き方などは変わってきたものの、ずっとここ数年変わらなかったことがあります。 それはキャリアを通して社会貢献に関わっていくことです。 この考えは子どもが生まれてから明確に持つようになったのですが、自分は何かすごいことはできないけれど、健康に生まれて、健康上なんの不自由もなく生活や仕事ができる、この恵まれた状態を活かして少しだけでもいいから社会に貢献できることに関わっていきたいという思いが根底にあり、これまでも企業を選ぶときにはその軸を大切にしてきました。 そんな中、出会ったのがエス・エム・エスです。 エス・エム・エスのミッションへの共感 エス・エム・エスは「高齢社会に適した情報インフラを構築することで人々の生活の質を向上し、社会に貢献し続ける」というミッションを掲げています。 健康でいるとなかなか高齢社会についてあまりピンとこなかったりするかもしれませんが、今の高齢社会に合わせたサービスやプロダクトを社会に提供することで、子どもたちが社会に出た時に彼らの時間だったり将来に投資できるような状態を作り出すことができるのではないか？と思っています。 私の好きな音声配信番組で「我が子は社会からの預かり物だと考えている」という発言があったのですが、この考え方が私もしっくりきていて、それを立派に育てて社会に還してくことが今の親としての役目。 voicy.jp その役目の一つとして、子どもたちが少しでも生きやすい環境を作り出していくことが大事で、高齢社会の課題を解決することはつまり高齢世代だけではなく、子どもたちの未来に還元されていくものだと私は考えていて、エス・エム・エスのミッションにとても共感しました。 入社を決めた理由はたくさんあるのですが、これまでやってきたエンジニアの採用活動を活かして、少しでも多くの方にエス・エム・エスに興味を持ってもらい、一緒に課題解決を進めていく仲間を集めることができたらと思ったのが入社を決めた理由の一つです。 ちなみに、5月に公開したエス・エム・エスのPodcast「Hello!SMS」でもエンジニアリングマネージャーの ぐっち が入社理由について、エス・エム・エスのミッションと絡めて話しているので是非聞いてみてください！ open.spotify.com 実際に働いてみてどうか 実は初回のカジュアル面談から実際に入社するまでは1年近くのタイムラグがあったのですが、その中でカジュアル面談から選考を含め何度もお話しをさせていただいていて、働くイメージが湧いてきました。 リモートワークができる環境であることはもちろんのこと、単に子を持つ親世代が多いというだけでなく、父親母親関係なく、親として子育てをしているメンバーが多いことが面談や選考から伝わってきました。 実際に入社した後もイメージとのギャップはなく、環境とカルチャーのおかげでキャリアを継続することができています。 エス・エム・エスのSlackには#kidsという子育てメンバーが集まるチャンネルがあり、たまにこういったエピソードなんかをシェアしたりして、ほっこりしています。 とてもいい環境で働けているなという点で本当に感謝しても仕切れないのですが、今年の4月から小学校に入学してから保育園時代とは全く質の異なる大変さが降りかかってきていて、正直てんやわんやです。 一つ前のセクションで、「子どもたちの未来が・・・！」みたいな大きなことを言っていますが、実際は毎朝寝起きのまま髪の毛振り乱しながらお弁当を作ったり、まだ1人で通学ができないという子どもを自転車→電車→バス→徒歩でトライアスロンのように送り迎えする日もあったりして毎日をなんとか安全に送っていくのに必死です（笑） ただそういう日常の積み重ねこそが、大きな未来を作ることもあると信じてやっています。 終わりに このブログはいわゆる入社エントリなので、エス・エム・エスになぜワーママの私が入社したのかをお伝えできればと思い書き進めてみました。 しかし、それだけではなく、激動のコロナ禍を経ながら、ワーママ5年生になりやっと見えてきたことや、大変なこともあって、もちろんこれからも大変なことがたくさん待っているけど、なんとかやれているしやろうと思っている様子なども伝えて、ふとした瞬間にこのブログを読んでくださった全ての働く親御さんたちにちょっとでも共感してもらえたり、気持ちが軽くなってくれたら嬉しいです。 その上で是非エス・エム・エスにも興味を持ってもらえればと思います！

はじめまして。ひろき（ @pirotyyy23 ）です！ 先日、株式会社エス・エム・エスのご支援を受け、RubyKaigi 2024に参加してきました。 この記事では、Ruby未経験かつRubyKaigi初参加の目線で、RubyKaigiに関する記録を残したいと思います！ RubyKaigi2024に参加した経緯 私は昨年の今頃から学生エンジニアとしてソフトウェア開発に取り組んでいます。 ある日、友人から「RubyKaigiは最高だから絶対参加した方が良い！」とおすすめされたのがきっかけでした。 そこでエス・エム・エスの学生支援企画の募集ページを発見し、「こんなチャンス二度とない！」と思い応募しました。選考を経て、無事にRubyKaigi 2024に参加することになりました。 tech.bm-sms.co.jp 会場の様子 「めんそ〜れ！！」ということで、今回の開催地は沖縄県那覇市でした！ 会場は「那覇文化芸術劇場 なはーと」という建物で、「広い・綺麗・国際通りが近い」という控えめに言って最高のロケーションでした。 印象に残ったセッション 前々から伺っていたように、各セッションの内容はかなりハイレベルでした。 ただ、懇親会などでSpeakerの方々と直接お話しすることで、内容について理解を深めることができました！ Writing Weird Code ぺん！（ @tompng ）さんによるKeyNoteです。 このセッションでは、TRICK 2022で受賞した作品や、Rubyならではの特徴を活かしたWeirdなコードが紹介されました。 先月、TRICK2022(超絶技巧Ruby意味不明コンテスト for RubyKaigi)で金賞をとってきたプログラム(Quine)です。 全てのフレームが、魚達がその場所から泳ぎを再開する実行可能なRubyのコードになっています。 魚・水草・泡でコードの一部が欠落していますが、誤り訂正により復元しています。 pic.twitter.com/vQsGG5o7Of — ぺん！ (@tompng) 2022年10月18日 その中でもSelf TRICK 2024で紹介された「floral」という作品はとても印象に残っています。 selftrick2024/floral at main · tompng/selftrick2024 · GitHub 「floral」は、一見すると単なるbmpファイルですが、実行するとRubyのコードとして解釈されるという非常に興味深い作品です。bmpファイルのバイト値を解析すると、Rubyのコードとして解釈され、以下のような出力を得ることができます。 Rubyに関わらず、奇妙なコードを書くことでその言語に対する理解が深まると思うので、個人的にチャレンジしてみようと思いました！ The grand strategy of Ruby Parser Yuichiro Kaneko（ @spikeolaf ）さんによるParserのお話でした。 Kanekoさんとは、Day0のイベントでお会いし、そこでParserについて熱いお話を伺いました。 お話の中で、「LR構文解析」や「オートマトン」など、大学で学んだ言葉が多く出てきました。このことをきっかけに、「これは大学で学んだことを生かせるチャンスだ！」と思い、多くのセッションがある中で特にこのセッションに参加することにしました。 セッションでは、Kanekoさんが開発されたParser Generator「Lrama」についての詳細な説明がありました。（ちなみに、「リャマ」の正式な綴りは「Llama」ですが、内部で使用されているのがLRパーサであるため、「Lrama」と名付けられたそうです。） これまで主に言語やフレームワークの使い方に焦点を当てて学んできましたが、プログラミング言語の基礎となる部分について学ぶのも非常に興味深いと感じました。 セッションの終盤では、真のUniversal Parserとして言語に依存しないParser Generatorに関する話題も取り上げられました。 開催期間中の過ごし方 企業ブース RubyKaigi には、さまざまな面で支援を行うスポンサー企業が多数参加しています。 気になるセッションを見た後は、企業ブースにて多くの企業の方々と交流しました。 企業の方々とお話しすることで、各社のサービスについての理解を深めることができました。 「このサービスの中身が全てRubyで作られているんだ!」といった発見もあり、非常に興味深く楽しい経験でした。 また、将来のキャリアについても相談することができ、自分のスキルや経験に基づいて、どのようなポジションが適切かについてアドバイスを受けることができました。 エス・エム・エス社員との交流 Day1のランチとDay2のディナーを、エス・エム・エス社員の方々と行きました！ 沖縄のグルメを堪能しながら、おすすめのセッションやイベントについて伺ったり、普段の業務についてお話を伺ったりすることができました。 ディナーでは、Rubyを学ぶのにぴったりな本として、｢チェリー本｣をおすすめしてもらいました。 プロを目指す人のためのRuby入門[改訂2版] 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plus) 作者: 伊藤 淳一 技術評論社 Amazon かなり文量のある本ですが、来年のRubyKaigi の内容を少しでも理解できるようにするために、少しずつ進めていこうと思います！ RubyKaigi に参加してみて RubyKaigi 2024 に参加し、たくさんの方々と交流する中で、Rubyistの熱意を肌で感じることができました。 私は、RubyKaigi に参加するまで全くRubyを書いたことがなかった者でしたが、Day2あたりから気づいたらRubyMineを入れて、Rubyを書いていました。 それほどRubyistの方々がRubyを作ること・使うことを全力で楽しんでいる姿に魅了され、「私も書いてみたい！」と思うようになりました。 改めて、RubyKaigi の期間は最高に楽しく、学びの多い時間でした。 このような機会を提供いただいたエス・エム・エスの方々には感謝してもしきれません！ 本当にありがとうございました。

こんにちは。人材紹介開発グループに所属している大上です。私は2023年12月にWEBエンジニアとしてエス・エム・エスに入社し、現在は福岡県から完全リモートワークで業務を行っています。 フルリモートワークが普及する中、新しいチーム環境へのスムーズな適応は、多くの企業にとって共通の課題となっています。本記事ではこの課題に対して、私のチームではどのように取り組んでいるか、そして私自身がどのようにキャッチアップを行ってきたかについてご紹介します。 オリエンテーション 新たな職場での初日をいかにスムーズに迎えるかが大切です。PCや必要な機材は、入社日までに自宅に配送され、初日から準備万端で業務を開始できるようになっていました。入社当日は、1日かけてオリエンテーションを受け、会社の理念や制度などを詳しく学ぶことができました。このオリエンテーションでは、必要な情報を一通り把握でき、業務開始に向けてスムーズな移行が可能です。また、よくある質問や手続きの流れも事前にまとめられており、事務手続きで迷うことはありませんでした。 オリエンテーション後も、サポート体制は十分に整っており、チャットツールを通じて気軽に質問ができる環境が用意されていました。これにより、新しい環境でも安心して業務に取り組むことができます。 2日目には、配属されたチームメンバーと初めての顔合わせを行いました。この顔合わせでは、各メンバーが自己紹介ページを用いて自己紹介を行い、名前や役職だけでなく、趣味や得意なことなども共有されました。これにより初対面でも共通の話題を見つけやすく、リモートワーク環境でのコミュニケーションを円滑に進めるための良い工夫だと感じました。また、チームメンバーはリモートワークに慣れており、コミュニケーションもスムーズに取れるため新しい環境でもすぐに活動を始めることができます。 キャッチアップにおけるチームの環境 チーム内では定期的なミーティングが開催されています。ミーティングでは進捗状況や課題を共有し、これにより、メンバー間で情報が透明に交換され、全員がプロジェクトの最新状況を理解できるようになっています。ミーティングはエンジニアに限らず、他職種のメンバーも参加し、プロジェクト全体の進行状況を把握することができるため、一体感を持って取り組むことが可能です。 また、ミーティングで設定される具体的な数値目標や開発すべき機能の背景、そしてビジネスの目的を共有することで、チーム全員がより質の高いアプリケーション開発に向けて同じ方向を向いて努力できます。どの職種からも質問ができるオープンな環境が、業務の理解を深めるための良い機会を提供しています。 さらに、 esa などの情報共有ツールを活用することで、必要な情報をいつでも迅速に入手でき、同時に他のチームのエンジニアがどのような取り組みをしているかを知ることができます。これは、知識の共有とチーム間の協力を促進し、より効率的に業務を進めることに寄与しています。 このような環境が整っているため、リモートでもスムーズにキャッチアップを進めることが可能でした。 入社時に私が行ったキャッチアップ方法 私が特に意識したキャッチアップの方法として、２つのポイントがあります。 まず、学んだ内容を資料として残し、暗黙の了解をドキュメントとして明記することを心がけました。これにより、新たにチームに加わるメンバーが同じポイントでつまずくことを防ぎ、チーム全体の共通認識を揃えることができます。 次に、疑問に思った点や、形式ばったりしているルールについては、チーム全体で議論しルールを整備することを重視しました。これにより、より効率的な開発が行えるようになると共に、良好なチーム運営を実現できると考えています。 これらは新しく参加した際に気づきやすい事項でもあるため、積極的に提案を行うことが重要です。 加えて、私がジョインしたチームでは、メンバーがオープンに意見を出し合う文化が根付いており、議論の場がしっかり設けられていたため、積極的に提案を行うことができました。このような環境の重要性を実感し、将来的に自身が新メンバーを受け入れる立場になったときには、提案しやすい環境を整えることを心がけたいと考えています。 今後新しいメンバーをどのようにチームが受け入れていくのか ジョイン時に感じた課題や改善点を踏まえ、今後はさらに良い受け入れ体制を築いていくことを目指しています。この目標に向けて、チームとして最近取り組んでいるのがペアプログラミングです。新しく加わるメンバーと共にペアプログラミングを行うことで、彼らがシステムのアーキテクチャを理解しやすくなり、同時にコードの品質も向上します。 さらに、このアプローチを通じて直接コミュニケーションを取ることで、新メンバーとの距離が縮まり、チーム全体のコミュニケーションが向上していることが感じられます。この取り組みにより、私たちは持続可能な成長と革新を支える強固なチームワークを築いていくことを期待しています。 まとめ オリエンテーションから始まり、日々の業務、チーム内コミュニケーションの強化に至るまで、私たちはリモートワークの環境下で効率的かつ生産的に業務を進めるための戦略を継続的に改善し続けています。特にペアプログラミングのようなコラボレーティブなアプローチは、新メンバーがチームに溶け込む手助けをし、同時に全員が目指す品質と効率を高めることができる重要な手段です。 これらの経験を基に、私たちは新たにチームに加わるメンバーが直面するであろう障壁を低減し、より迅速かつスムーズに業務に取り組めるようにするための体制を整えています。積極的なコミュニケーション、透明性の高い情報共有、そしてオープンなフィードバック文化が、これを実現するための鍵となっています。 最終的に私たちの目標はリモートワークでも効果的に機能する協力的で結束力のあるチームを築くことです。そして、このような取り組みを通じてチームとしての成長だけでなく、個々のメンバーも成長を続けていける環境を提供していきたいと考えています。

はじめに 初めまして。人材紹介開発グループにて、介護職向け人材紹介サービス カイゴジョブエージェントの開発を担当している和田です。 本記事では、「プロダクションレディな品質」を目指すための取り組みについて紹介させていただきます。 同様の取り組みをしている方や、興味のある方の目に留まり少しでもお役に立てたら幸いです。 取り組みの背景 ある障害が発生した際に、原因の一つとして「リリース可能な品質水準について共通認識を持てていない」事が挙げられたのが発端でした。 「本番にリリースしていい状態 = プロダクションレディな状態」に対して、まず前段として開発のフローが一定の水準で確立されていることが最低限の品質担保に寄与すると考え、相互学習の場も兼ねて「構成管理」「テスト」「自動化」の観点で議論がスタートしました。 プロセス ここでは実際にどのようなプロセスで進行していくか紹介していきます。 テーマによって若干の差異はあるものの、大枠以下のようなプロセスで進めていきます。 議論フェーズ 一定期間議論するテーマを決め、参加メンバーでディスカッションを行う 参加メンバーはそのテーマに対して気になる事を意見していく 議論が発散しないよう留意しつつ、そのテーマにおける「プロダクションレディ」について共通認識を揃えていく オーナー(旗振り役)とサポート役の選定 オーナーの役割 進捗把握、課題整理、実行手順の取りまとめなど、必要な事を適宜行いプロジェクト実行を推進する サポート役の役割 基本的にはオーナーが行う各作業においての補助的な立ち位置で一緒に考え作業する 実行フェーズ オーナーとサポート役が、実行するにあたって流れをまとめる 各プロダクト毎に作業を進め、毎週オーナー役が進捗を確認し、全プロダクトの対応が完了するまでテーマの実行を推進していく 実際のテーマとそこから得た学び 取り組み自体がまだ浅いので現時点で完了したテーマがまだ存在せず、基本的に全て進行中のステータスにはなりますが、ここでは実際に今動いている以下のテーマについて自身の学びを交えて簡単に紹介させて頂きます。 データベースの構成管理 テストに対する認識を揃える データベースの構成管理 このテーマは、構成管理の一つとしてデータベースの管理を見直す取り組みです。 テーブルの変更履歴が正しく管理されていない、複数のプロダクトで同じテーブルをメンテナンスしている、などの問題があります。解決策について議論を重ねた結果、既存のモノリシックなデータベースをプロダクトごとに分割してプロダクト単位でデータベース定義の管理からデプロイまで行えるようにする、という方向でステップを踏んで作業を進めています。 学び 私自身データベースを分割することに対する知見が少なかったのもあり、O’Reillyの『 モノリスからマイクロサービスへ 』を参考に基本的な部分から学びました。 参加メンバー内でも同書籍を用いた勉強会も開催され、「うちのプロダクトだとこういうことなのか？」といった会話がなされて学びが多いです。 全てのテーマで共通していますが、各議論の中で他のプロダクトを担当するメンバーの意見、担当外のプロダクトで既に行っている取り組みなども知れるので参考になります。 テストに対する認識を揃える このテーマは、どのフェーズでどのようなテストが行われるべきか、また、それぞれのテストをどのように書くのか、などを整理し、プロダクト間で共通認識を持った上で各プロダクトのテストを作成していくための取り組みです。 学び 私自身、そもそもこのテストはどの開発サイクルで行われるべきで、それに必要なデータは何でどういったデータがあるべきか？といったことを深く考える機会は初めてでした。 この取り組みを通じてモブプロ的にテスト内容の検討やテストコードの追加なども実施され、学びを得る機会が多いです。 プロセスを通じて得られたこと 私の場合、データベースの構成管理の部分でオーナーとして活動していました。 上でも書いていますが、この領域に関する知見が少なかったので、他メンバーの考えや書籍を参考にしつつ解決までのロードマップを引くといった感じでした。 単に自己学習をした場合よりも、業務内でアウトプットを並行して行う必要があったので、より理解も深まる機会になったと思います。 加えて、オーナーの役割を担うことで、リーダーシップを取りプロジェクトを推進する経験が出来たこともよかったと思います。 ゴールはどうあるべきでどう進めるのか、ロードマップは納得できるもので行動に移せるのかなど、リーダーシップを取り、人を巻き込みながら共通の目標に向かっていく事は思っていたよりもプレッシャーを感じましたが、自身の成長に繋がっています。 最後に プロダクションレディな品質を担保する為に実施している取り組みについて事例を交え紹介させて頂きました。 私自身感じているのは、個別のタスクレベルで発生する課題だけでなくプロダクト横断レベルの複雑な課題に取り組む機会が多く、開発者として成長につながる場面にも恵まれている環境だということです。 もしこの記事を読んで少しでもエス・エム・エスに興味を持ってくださった方がいたら嬉しいです。

はじめに エス・エム・エスでエンジニアをしている @koma_koma_d です。みなさん、オブザーバビリティ、やってますか？今回の記事では、OpenTelemetryのSpan Linkについて紹介します。 そもそも、トレース、スパンとは？ オブザーバビリティにおける主要なシグナルとして、「ログ」「トレース」「メトリクス」の3つが挙げられます。その一つであるトレースは、システムの処理の流れをエンドツーエンドで追跡するための仕組みです。1つのリクエストが処理される流れを、部分に分割して可視化することができます。 トレースは、以下のような「スパン」のツリー構造として表現されます。スパンは、処理中の特定の操作を表現します。データベースへのクエリ、外部サービスのAPIコール、あるいはアプリケーション中の特定の処理ブロックなど、様々なものをこのスパンとして表現することができます。 この構造は、あるスパンを開始するときに、そのスパンが子としてぶら下がることになる「親」のスパンを指定することで作られます（「親」のないスパンが、1つのトレースのルートスパンとなります）。たとえば、Webアプリケーションのサーバ側のコントローラーがリクエストを受け付けたところでルートスパンを開始し、何らかの業務上の処理のまとまりをその子スパンにし、その中で行われるデータベースへのアクセスを更に子スパン（ルートスパンから見た孫スパン）にする、といった形です。 1つのトレースを構成するスパンは、システム内の単一コンポーネントから発行される場合もあれば、システム内の複数のコンポーネントから発行される場合もあります（後者の場合のトレースを特に「分散トレース」と呼びます）。トレースを活用することで、一続きの処理の中での個々の処理同士の依存関係を可視化することができ、たとえばどこの処理の遅延が全体の処理時間にインパクトを与えているか、どの部分でのエラーが起きたか、などを簡単に見ることができるようになります。 なお、分散トレースを実現するためには、サーバ間の通信時にスパンの情報を伝播させ、受信側で新しくスパンを開始する際にそれを親スパンとして指定する必要があります。この際に用いられるのがSpanContextで、これにはトレースID・スパンIDなどのスパンを特定する情報と、追加的な情報が含まれます。このSpanContextはシリアライズして送信されるのですが、後述するSpan Linkの場合にもこれを用いることになります。 opentelemetry.io 親子関係ではない関係を示すものとしてのSpan Link トレースは親子関係を持つスパンの集まりでした。しかし、ある一連の処理の流れについて、全てのスパンを親子関係で繋ぐことが常に最適であるとは限りません。親子関係とするには適さないが、関連があることは表現したいという場合に用いるのが「Span Link」です。 Span Linkについては、OpenTelemetryのドキュメントにも説明があります。 概念の説明 https://opentelemetry.io/docs/concepts/signals/traces/#span-links 仕様の概要 https://opentelemetry.io/docs/specs/otel/overview/#links-between-spans 仕様の詳細 https://opentelemetry.io/docs/specs/otel/trace/api/#link Span Linkによる関係が親子関係と異なるのは、 同じトレースに属さなくてもよい（親子関係の場合、子は親の属するトレースに属することになる） 1つのスパンから、複数のスパンに対して関係を持つことができる（親子関係の場合、親は1つしか持てない） の2点です。すなわち、これらの特徴が活きるシーンが、親子関係ではなくSpan Linkを用いる場面ということになります。上記のドキュメントのうち、 仕様の概要を記した資料 に、Span Linkが使いやすい場面が紹介されています。 1つ目は、前段の処理とは別のトレースとして新たに開始したい場面です。親子関係ではなくSpan Linkを使うことで、別のトレースでありながら前段のトレース（のうちのリンク先のスパン）との関連があることを示すことができます。 2つ目は、scatter/gatherと言われている、処理が一度複数に分岐して実行され、後から合流して続きの処理が行われるようなパターンです。スパンには親スパンは1つしか設定できないので、合流する際に直前の（別々に実行された）複数の処理のスパンを親とすることはできませんが、Span Linkであればそれら全てに対して関係を持たせることができます。 Span Linkを設定する方法：C#の場合 Span Linkを設定するのは簡単です。C#の場合は、System.Diagnostics名前空間のクラス群を使って実現できます。たとえば、SQS経由で起動される非同期処理のコンシューマ側のスパンから、プロデューサ側のスパンへリンクを作る場合には以下のようになります。なお、SpanContextの情報をSQSのメッセージに載せたり抽出したりする部分は、親子関係を作る場合でも共通です（自動計装の場合は、コードを書かなくてもライブラリ側でやってくれているかもしれません）。 /* プロデューサ側 */ // SpanContext情報を載せる Propagators.DefaultTextMapPropagator.Inject( new PropagationContext(activity.Context, Baggage.Current), message.MessageAttributes, (attributes, key, value ) => attributes[key] = new MessageAttributeValue {DataType = "String" , StringValue = value }); /* コンシューマ側 */ // SpanContext情報を抽出 var context = Propagators.DefaultTextMapPropagator.Extract( default , message.MessageAttributes, (attributes, key) => attributes.TryGetValue(key, out var value ) ? [ value .StringValue] : []); // Span Linkを指定してアクティビティを開始 using var activity = activitySource.StartActivity( "ConsumeMessage" , ActivityKind.Consumer, default ( string ? ), tags, [ new ActivityLink(context.ActivityContext)]); これでOpenTelemetry上のSpan Linkを作ることができます。 ※ちなみに、 DefaultTextMapPropagator を使った場合、トレースID・スパンIDなどの情報は traceparent という名前の属性として登録されます（TraceStateの情報も載せた場合は tracestate に載ります）。これは traceparent という名前のヘッダーをつけるのがW3CのTrace Contextの仕様だからです。 www.w3.org Span Linkはどのように可視化できるか？：Datadogの場合 さて、以上のようにして作ったSpan Linkは、オブザーバビリティツールの上ではどのように可視化されるのでしょうか。ここでは、Datadogの例を紹介します。Datadogでは、エージェントのv7.45.0でSpan Linkがサポートされるようになり、Web UI上は現時点でベータ版でSpan Linkがサポートされています。 https://github.com/DataDog/datadog-agent/releases/tag/7.45.0 https://github.com/DataDog/datadog-agent/pull/15767 https://docs.datadoghq.com/tracing/trace_explorer/trace_view/?tab=spanlinksbeta#more-information 先述の例のように、キューのコンシューマ側のスパンからプロデューサ側のスパンに対してリンクを作った場合、Datadogのコンシューマ側のトレースの画面で、中段の一番右に「Span Links BETA」のタブが現れます。そのタブを選択すると以下のように表示されます。 画面は説明がほとんど不要なほどにシンプルで、下段にSpan Linkの一覧（今回の例では1つだけ設定しているので1つだけ）が表示されます。どのスパンからどのスパンにリンクされているかが表示され、リンク先のスパンの画面にクリック一発で遷移することができます。便利ですね！ おわりに 以上、OpenTelemetryのSpan Linkについて、実際のコード例も交えて紹介しました。何かの参考になれば幸いですが、私自身まだまだOpenTelemetryの仕様を把握しきれておらず、有効活用できていないところがあります。 特に、今回ドキュメントに即してSpan Linkを使う場面の1つとして紹介した「1トレースとするのが適当ではない場面」については、正直ピンときていないところがあります。基本的には1トレースとして扱った方がオブザーバビリティツール上で一覧しやすいなどの点でメリットがあるように思うので、別トレースとして扱う方が好ましい場面というのがあまりピンときていません。ドキュメントでは、「サービスの信頼できる境界の内側に入って、サービスのポリシーが新しくトレースを始めることを要求する場合」と書かれているのですが、あまり具体的にイメージできていません。また、このようなポリシー上の事情以外にも、別トレースとして扱う方が好ましい場合があるのだろうか、というのもよくわかっていません。もしこのあたり知見や「うちはこうしてるよ」というのがある方がいたらぜひ教えていただきたいです。 私の運用しているアプリケーションでは、OpenTelemetryを使うことで、かなりエラー発生時などの調査がやりやすくなったと感じています。とはいえ、まだまだOpenTelemetryをフル活用できているとは言い難い状態ですので、これからも勉強しながら活用していきたいと思います。 もし記事中に誤った記述や技術活用上の改善点などがありましたら、筆者のXアカウント @koma_koma_d までぜひお気軽にご連絡ください！

こんにちは、プロダクト開発部人事のふかしろ( @fkc_hr )です。先日、 医療キャリア事業 に携わる開発組織についてのページを公開し、ブログでも紹介しました。こちらの記事および採用情報サイトのページでは、開発組織からの視点で医療キャリア事業について説明しています。 今回は、医療キャリア事業の事業責任者を務める 山本健 さんに事業の詳細や、開発組織との関わりについて伺いました。ぜひ最後までお読みください！ tech.bm-sms.co.jp careers.bm-sms.co.jp はじめに エス・エム・エスで医療キャリア領域の事業責任者を務めている山本です。製造業のベンチャー企業や結婚式場の運営会社で働いたあと、「残りの仕事人生は自分の興味のあるヘルスケアの領域で勝負しよう！」と考え、2012年にエス・エム・エスに入社しました。 この記事を読んでいるのはエンジニアの方が多いと思いますが、エンジニアの皆さんにも私たちのやっている事業の重要性や面白さが伝わるようにお話しできればと思います。よろしくお願いします。 医療キャリア事業について なぜこの事業が必要なのか 弊社のキャリア事業では、「 医療・介護従事者の不足と偏在を解消し、質の高い医療・介護サービスの継続提供に貢献する 」をミッションに掲げており、医療キャリア事業はその中の医療従事者向けの領域として、様々な医療従事者向けの 人材紹介サービス を運営しています。 エンジニア採用サイト の内容とも重複しますが、改めてこの医療キャリア事業の目的を説明しましょう。私たちの事業は、求人を出す医療機関と、求職者である看護師などの医療従事者との間を取り持つことで成り立っています。 一方の当事者である医療機関の直接の課題が人材の確保であることは当然ですが、医療機関というのは地域の医療を支える存在ですから、 医療機関の人材の需要というのは地域医療の人材の需要であり、その背後には地域の患者の医療サービスへの需要があります。「求人の裏には未来の患者がいる」のです。 地域の患者の需要は一定ではなく、変化するものです。これは需要が全体として増減するだけでなく、複数の医療の機能（病院、クリニック、訪問看護、介護施設など）の間での需要の移動もありますし、地域の間での需要の移動もあります。したがって、患者が必要とする医療が変化するのに対応して、人材の移動を促していくことが地域医療を支えるためには必要になります。 もう一方の当事者である医療従事者については、 それぞれの人がその人らしく医療従事者として働き続けられるようなキャリアの選択肢を提案 し、可能性を広げることを支援することが私たちの事業の課題になります。これはもちろん本人のキャリアのためでもありますし、資格やスキル、経験を持っている方に長く働いてもらって労働参加率を高めることはやはり地域医療のためにも重要なことです。 地域医療・医療機関について 医療機関の事情についてもう少し詳しくお話ししましょう。改めて言うまでもなく、高齢化の進行は医療においても大きな課題を生み出しています。高齢化が進めば医療への需要が増加しますから、その需要に応えるだけの医療機関の生産性の向上は重要な課題です。ベッドの回転率や平均在院日数を改善するためには、スタッフの充実が欠かせません。2006年の診療報酬改定で導入された7対1看護の基準も、このような高齢化社会の課題への対応の先駆的なもので、この時期から医療の領域における有料の人材紹介サービスというものもビジネスとして求められるようになってきたのです。 医療機関としては、人材を確保するため、本来であれば求職者に向けて自分たちの働く場としての魅力を発信していきたいわけですが、多忙な医療機関が自らそれを行うのは大きな負担になります。そのため、私たちのような人材紹介サービスが代わりに母集団形成や一次スクリーニングの部分を担う余地があるわけです。これは単にビジネスチャンスであるというだけでなく、大きな社会的責任を伴うものだと考えています。 医療機関のニーズにマッチしている求職者の方を適切に面接にまでお連れすることが、多忙な医療機関の負担を減らし、ひいては地域医療に貢献することになる わけです。そのためには、職場としての医療機関の状況、そこで求められる人材像に深い理解を持ったキャリアパートナー（転職・採用支援担当）の存在が重要です。このような専門性の高いサービスを届けられる存在になるために、医療現場で臨床経験を積んだ医療従事者のキャリアパートナーが全国に100名以上在籍しています *1 。こうした医療従事者のキャリアパートナーが果たしている役割については、2024年3月に発表した以下のプレスリリースでもご紹介していますので、興味のある方はぜひご覧ください。 www.bm-sms.co.jp 求職者について 求職者である医療従事者についても補足します。この業界では、高校生の時点でキャリア選択をしている人が多いことが特徴です。医療従事者としてのキャリアを選択する理由はもちろん人それぞれですが、看護師資格のような国家資格を取るためにたくさん勉強をして医療業界に入ってきます。多くの人は、せっかく得た資格とスキルを活用して、目の前の患者に適切な医療処置をしたい、患者に寄り添って良い看護サービスを届けたいと思って仕事をされていると思います。しかし、職場や家庭での ちょっとしたボタンの掛け違いで、今の職場だと自分らしく、患者に寄り添って働き続けられない、となってしまう人も多い です。患者中心ではなく医療機関中心の医療に違和感を覚えてしまったり、プライベートとの折り合いが付かなくなってしまったり、ですね。特に若手の方は、最初に働き始めた医療機関で上司との関係が悪くなって働き続けられなくなってしまうということもしばしば見られます。 そういう状況に陥ってしまったときに、もちろん別の業界に転職することも大切な選択肢の一つですが、せっかく努力してきて、医療という仕事に対する思いも持っているのに、業界を去るしかなくなってしまうのは、とても勿体ないことです。私たちとしては、そういった状況に追い込まれたとき、いや追い込まれる前の段階で、 「今の職場以外にも医療業界で働き続ける選択肢は常にある」という状態をインフラとして用意する ことがそれぞれの人の人生にとって大事なことなのではないかと考えています。 今後のプロダクト開発で実現したいこと 私たちが医療キャリア事業を通じて解決したい課題や果たしたい役割をお分かりいただけたでしょうか。ここからは、以上のような背景を踏まえて、プロダクトの開発を通じて実現したいことをより具体的にお話ししましょう。 医療機関にとって人材確保が重要な課題で、私たちのような有料人材紹介サービスはそれを一部肩代わりしているという話をしました。私たちのサービスの従来の建て付けは、医療機関から求人が出てきたときに、そこに対して求職者をなるべくたくさん集めよう、という形になっていました。しかし、これでは他のサービスとの差別化は困難です。広告やメールマガジンなどを活用して応募者を獲得すれば成長する、というのはある程度まではそうですが、 広告宣伝費をたくさん使ったところが勝つというマーケットとして扱ってしまっては早晩頭打ち になります。これまでとは違う考え方でサービス運営をする必要があります。 広告宣伝費勝負にならないためには、お客様である求職者に「このサービスがいい」と思って選んで使ってもらえるようにすることが必要です。「お客様が私たちを選ぶ理由」を作る必要があります。CM等で認知を取るのは一時的には有効ですが、使ってみてもらったあとに「他と変わらないね」となってしまっては元の木阿弥です。そうではなく、 使ってもらえばわかる「私たちを選ぶ理由」を作った上で、認知施策を打って使ってもらう のです。この「私たちを選ぶ理由」こそ、プロダクトの魅力ということになります。 こういった考え方から、まずは顧客接点のさまざまなところを、お客様の体験にとって望ましい形になっているか点検していっているところです。顧客接点となるのは、Webサービスとしてのユーザーインタフェースに加え、電話や対面、メールなどの人が関わる部分など多様です。キャリア事業というのはITだけで完結するものではなく、生身の人が介在する場面が出てくるわけですが、人とITとが一体化した、顧客体験のよいプロダクトにしたいのです。 顧客体験ということを考えたときに大事なのは、 医療キャリア事業が対象としている職種の多様性があります。それぞれの職種にはそれぞれ固有の専門性があるので、求職者向けの体験としては職種ごとに独自のものを追求したいという側面があります。一方で、医療機関の立場に立ってみると、1つの医療機関が様々な職種の方を採用しようとするので、医療機関向けの体験としては職種を横断して扱えるようになっていた方が望ましいです 。また、どの職種にも適用可能な裏側の仕組みというものもあります。現状は、職種ごとにバラバラにプロダクトが構築されてきているため、本来は1つのものに蓄積されていくべき情報がバラバラになってしまっていたり、仕組みが別々になってしまっていたりします。こうした点をシステムの内部構造含めて改善していきたいというのが実現したいことの一つです。技術者の視点からも「こうあるべき」というものを提示して、リードしてもらいたいと考えています。 プロダクト開発組織に期待したいこと この記事を読んでくださっているのはプロダクト開発職の方が多いと思うので、プロダクト開発の話をもう少ししましょう。 プロダクト開発組織の人たちとの関係の変化 私はエス・エム・エスに入社してからもう10年以上経っているのですが、入社当初はプロダクト開発組織の方々とはあまりしっかり話ができていませんでした。 以前は、開発組織と事業側との関係が密でなく、事業側から刹那刹那で断片的な情報だけで「こういうのが作りたい」「こういう機能が欲しい」と開発組織に依頼するというのを繰り返してきました。開発組織の方々との良い関わり方がわからず、理由などをあまり伝えずに作りたいものだけを伝えていたんです。前回依頼して作ってもらったものと今回依頼しているものとの間に一貫性がない、ということしばしばで、プロダクトとしての明確な方向性もない状態でした。 しかし、数年前に技術責任者の田辺さんがキャリア事業にも関わるようになってから、 「プロダクト開発の人たちも事業の前提や根幹を理解した上でより良いサービスづくりをしたいんだな」という印象を持つようになりました 。そして昨年、リーダーとして鈴木健二さんが参画されてからは、実際に「どういうふうにしたいから、今これを作るんだ」といった会話ができるようになってきました。今は開発もオーナーシップを持ってくれていると確信できているので、細部をどういうふうに作っていきたいかなどは信頼して任せられるようになっています。スケジュールなどについても、事業側が一方的に納期を設定して急かすということもなく、相談しながら進めています。 ものづくりはものづくりの人にリードしてほしい 先ほどプロダクトの顧客体験のところでもお話ししましたが、 プロダクトがどうあるべきかという点については、技術者の方にぜひリードしてもらいたい と考えています。ソフトウェアの内部の設計についてはもちろんですが、顧客にとって利便性の高いサービスの設計という観点でもエンジニアとしての知見を活かしてもらいたいです。 個人的な話になりますが、私はエス・エム・エスに入社する前に製造業の会社にいたことがあります。私は自動車の開発プロセスに関わっていたのですが、その時に出会った自動車のプロダクトマネージャーは、エンジニア出身の方ばかりでした。おそらく1台3万点の部品で構成される自動車というプロダクトの複雑さゆえという側面もあったとは思いますが、 エンジニアがビジネスと顧客についての知見を習得してプロダクトマネージャーになっていることで、売れて儲かる自動車作りができていた と感じています。当社の複数職種の人材マッチングビジネスを支えるITシステムも複雑な要件が多いと思っており、その複雑な要件を実現するためのアーキテクチャを決める能力のあるエンジニアが（ビジネスや顧客についての理解を身につけた上で）プロダクト作りをリードした方がよいと考えています。 そのような関係性を実現するためにも、エンジニアのリーダーには関わる事業の週次進捗に主体的に参加してもらうなど、社会や顧客からの要請・競合環境・それに対する自社の取り組みの変化の文脈をタイムリーに理解できる環境作りを心がけています。 エンジニアの皆さんへのメッセージ 私は趣味でヨットを長年やっているのですが、同じヨットに乗っている人たちは運命共同体で、各々が別の役割を持ちつつも、皆で支え合いながら安全に航海しゴールに辿り着かなければなりません。会社もこれに似ていて、 立場や職種が違ったとしても、互いに尊重しながら、運命共同体として協働し、同じビジョンに向かって進んでいく ことが大切だと思っています。 当社の事業に興味関心があり、エンジニアの立場でこの社会課題の解決に共に挑みたいと思って頂ける方と出会えたら嬉しいです。 （終） *1 : 2024年3月28日付弊社プレスリリース より。