こんにちは、 @_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でお会いしましょう。

この記事は株式会社エス・エム・エス Advent Calendar 2024の12月12日の記事です。 エス・エム・エスで人材紹介の社内基盤開発をしている熊谷です。 今回はそんな社内システムの1つで、Honoを使って開発している事例をご紹介します。 なぜ私たちはHonoを採用したのか？ 人材紹介事業では、CP（キャリアパートナー）と呼ばれる、従事者様の転職のお手伝いをサポートする人員がいます。 従事者様とCPとのコミュニケーションは一般的に電話やメールなどで行われますが、LINEもよくコミュニケーションによく使われる手段の1つです。 従事者様がエス・エム・エスが展開している公式LINEに登録すると、公式LINE上で従事者様専任に割り振られたCPと従事者様との1to1のコミュニケーションが可能になります。 これらを実現するために、LINE Messaging APIを使った中間のWebサーバを社内で管理しています。 元々これらの仕組みは、EC2 + PHPという組み合わせで作られていたのですが、 コミュニケーション量が増えるに伴って費用も増えてきた 処理としては簡易で、EC2で稼働させる必要性がない 時間帯や曜日によって負荷に増減があるため、スケールしやすい基盤が向いている という事情から、Lambda + Node.jsで書き換える企画がスタートしました。 このWebサーバの要件をざっくり伝えると シンプルだけど10ページ分のWebページ（フォーム画面）が必要 Cookieを使う（サーバサイド処理が必要） というもので、色々なフレームワークを比較検討した結果、Honoが良さげだぞという結論に至りました。 決定打としては「jsxがテンプレートとして使えること」「Ryan Dahl氏がDeno FestでHonoを推してたこと」の2つでした。 採用してみてどうだったか？ 非常に良い！！！ というのが感想です、私たちが開発していて実際に良かった点を列挙していきます。 テストが書きやすい Web Standard APIのRequest/Responseを利用しているからこそ、リクエスト/レスポンスのテストの書きやすさが素晴らしいです /** * index.ts */ import { Hono } from "hono" ; const app = new Hono(); app. get ( "/hello/:name" , ( c ) => { const name = c.req.param( "name" ); return c.text( `Hello, ${ name } ` ); } ); export default app; /** * indx.test.ts */ import app from "./index" ; test ( "GET /hello/:name すると、'Hello, ${name}' が返ってくる" , async () => { const path = "kumagai" ; // app.request()で定義済みルートへアクセスでき、Responseオブジェクトが返却される const res = await app.request( `/hello ${ path } ` ); expect (res. status ).toBe( 200 ); expect (res.text()).toBe( `Hello, ${ path } ` ); } ); zod + reuqest parameter validation zodを使ったランタイムバリデーションがリクエストパラメータ等の検証に簡単に適合できるのが良いです const schema = z.object( { id : z.string().uuid(), } ); app.post( "/entry" , zValidator( "form" , schema), ( c ) => { c. status ( 201 ); return c.text( "Created" ); } ); test ( "POST /entry は、FormDataでid = uuidのみ受け付ける" , async () => { const body = new FormData (); // UUID以外はBadRequest body. append ( "id" , "abc12345" ); const res1 = await app.request( "/entry" , { method : "POST" , body } ); expect (res1. status ).toBe( 400 ); // UUIDは201 body. append ( "id" , "fc56abe1-d352-691e-bd8e-13102bf17549" ); const res2 = await app.request( "/entry" , { method : "POST" , body } ); expect (res2. status ).toBe( 201 ); expect ( await res2.text()).toBe( "Created" ); } ); jsxテンプレート jsxで直感的にフロントエンドが書けるのが素晴らしすぎる /** * todo.tsx */ import { Hono } from "hono" ; import { jsxRenderer } from "hono/jsx-renderer" ; import type { FC } from "hono/jsx" ; const app = new Hono(); app.use( "/todo/*" , jsxRenderer(( { children } ) => { return ( < html lang = "ja" > < title > My ToDo </ title > < body > { children } </ body > </ html > ); } ), ); const ToDoList: FC < { items : string [] } > = ( { items } ) => { return ( < ul > { items. map (( item ) => ( < li > { item } </ li > )) } </ ul > ); } ; app. get ( "/" , ( c ) => { return c.render( <> < h1 > 今日のToDoは？ </ h1 > < ToDoList items = { [ "掃除" , "昼寝" , "歯磨き" ] } /> </> , ); } ); export default app; 最後に 私たちがHonoを使っていて、とても感じるのは 「Honoって楽しい！！！」 です。チームとして迷わず開発できている点や、開発生産性も高く、何より 使っていて気持ちが良い というのが大きいと思います。 社内のプロダクトで使い始めたHonoですが、個人開発でも何かとHonoをベースに開発する機会が増えました。個人的には Bun + Honoで作ることが多く、TypeScriptやテストの取り回しも楽だし、Cloudflare Workerなどどこでも動くのは本当に魅力だと思っています。 この記事が、皆さんのHono採用きっかけの一助になればと思っています。

こんにちは。 エス・エム・エスでプロダクト組織の人事をしているふかしろ( @fkc_hr )です。 株式会社エス・エム・エス Advent Calendar 2024 vol.2 と 技術広報 Advent Calendar 2024 シリーズ3 の12月12日の記事です。自社のAdvent Calendarは埋まるかな〜ワクワク、とSlackのtimesチャンネルで呟いたら、人事も書くんだよ！と煽ってもらって(？)ここに至りました。 エス・エム・エスは例年さまざまなカンファレンスに協賛をしているのですが、今年はありがたいことにブース出展もさせていただく機会が多かったため、そちらの内容を振り返っていきます。 カンファレンスでエス・エム・エスを見かけてくれた方に思い出しながら読んでいただいたり、これからカンファレンス協賛・ブース出展するぞという方の参考になったりしたらいいなと思っています。 どのカンファレンスに協賛をしたのか 以下の通りです そのうちブースを出展したカンファレンスを主に振り返っていきます。私は該当する5つのカンファレンスを皆勤賞ですべて参加させていただきました。楽しかった〜 すこし裏話をすると、2024年12月現在では、モバイルアプリエンジニアはチームもなければ採用も積極的にしているわけではないものの、 DroidKaigi は弊社社員がスタッフとして参加しているので協賛をしていたり、はじめての JAWS Festa への協賛はSREの一人が、コミュニティ活動として協賛したいといってくれたおかげで協賛に至ったり、というコミュニティ貢献のためにも協賛という形で社として応援しているなと思ったエピソードもありました。 どんな準備をしたのか 今年は広報がんばるぞと決意していたこともあり、素振り的にブースがある協賛イベント用のキックオフ資料のたたきを作ったり、その他のノベルティやチラシの資料を一つのドライブにまとめたりしていました。 エス・エム・エスは複数事業を展開していて、プロダクト数も多いので、各カンファレンスごとにフォーカスして紹介したいプロダクト・チームが変わります。そのため全体感を把握できないまま役割分担などが進んでいく傾向があるので、全体感やスケジュールが分かるものにしました。 関係者や興味を持ってくれている人をあつめてキックオフと役割分担をしたら、あとは皆さんの応援をする…という形で進むのが理想なのですが、初めて関わる方も多くいるので、社内調整含めてフォローしながら、Slackで該当イベント用のpublicチャンネルを作成し定例で進捗を確認し…と進めています。 特に社内関係者でPR/IR/リスクマネジメントの部門への相談が必要だったり、支払い関係で経理/総務部門も巻き込みながら進むような内容は普段のエンジニアが業務上かかわらないことが多いため、各部門の判断材料となるような情報が不足なく伝わるようなフォローをしていました。 その中でも今後の持続性を考えて、ノベルティは他のイベントでもつかえるデザインにする、チラシの会社紹介のページは共通で活用する、メインの缶バッジ企画を固めておく、などをしていたので直近のKaigi on Rails はかなりスムーズに用意できたように感じます。 当日どう過ごしたのか 各社あまり差異はないと思いますが、シフトを組んで、できるだけ聞きたいセッションは聞き、カンファレンス自体を楽しんでもらいたいというのがベースの思考です。 ※シフトを抜粋したもの 企画として特に良かったなと思うものを2つ紹介します。 缶バッジ(現地生産) EMのふるぽんの企画で、「あなたのXアイコンを缶バッジにしてプレゼントします」という企画を行いました。 合わせてお渡しするネタ缶バッジもイベントごとに作成しました。デザインは絵文字ジェネレータで作ります。 特に現地生産もモバイルプリンター、缶バッジメーカーを活用して行えたイベントは非常にインパクトがあったのではないかなと思います。だんだんカンファレンス中で缶バッジをつけている人が増えていくのは不思議体験でした。 また、印刷や作成はバッチ処理的に作業していく仕組みだったので、申し込み・完成品の回収と2回ブースに足を運んでいただくことができたのも思わぬ良ポイントでした。 SNSフォローもお願いしたい、ノベルティも渡したい、会社やプロダクトの紹介もしたい、ソースコード公開をしてたら見てほしい、とコンテンツが多かったのですが、タイミング次第で長くブースに滞在していただくこともできました。 おみくじ デザイナーがコンセプトワークから行ったストーリー性がある企画でした。 「デザイナーと介護・障害福祉を『社会課題』で結ぶ」というコンセプトで、おみくじをきっかけとして提供し、介護を含めた未来を想像してもらい、該当する項目に「結」んでもらう。ここまでつながる体験設計をできるのはデザイナーだからこそなせるワザだなと思いました。 おみくじを結んでもらっている様子 コンテンツとしても、「おみくじ引いてみませんか」と声をかけることができるハードルの低さや、意外と結ぶという行動に手間取るのでその間に会社やプロダクトについて話すことが出来たことは収穫でした。 ここまで一貫した体験設計が出来なくてもハードルが低く興味を持っていただくきっかけを作る。なにか足を止めていただけるような、深い話をできる機会を創出するという点は今後のブース企画にも活かせそうです。 結果としてどうだったのか コミュニティ貢献が目的ですが、副次的な効果として得られたことを紹介します。 プロダクト組織の公式X( @BM_SMS_Tech )のフォロワーが1000人を突破した ノベルティをお渡しするためにフォローをお願いしたこともあり、Xのフォロワーが先日1000人を突破しました。実は今年度の始まりは300名弱だったため、カンファレンスが繋いでくれた縁だなと感じています。 継続的に情報発信をしていきたいと思っています！ エス・エム・エスよく見かけますと言ってもらえるようになった これはカンファレンスブースだけではなく、登壇やブログなどの発信の効果でもありますが、よく見かけると言っていただけるようになりました。嬉しいですね。 エンジニアも嬉しい、誇らしいと思ってもらえるように、これからも良い組織づくり、発信を行っていきたいです。 面談・面接でカンファレンスで社員と話して興味を持ったと言ってもらえるようになった 最高ですね。カンファレンス”だけ”が理由で採用に至ることはありませんが、応募のきっかけになる機会なのだなと感じました。 これからも継続的にコミュニティへ貢献するモチベーションになりました。 社内エンジニアやデザイナーの交流の足がかりになった 普段基本的にはフルリモートで開発をしているため、対面で会うのははじめて、というメンバーもいました。同じ技術スタックを別のチームで使っている場合でもカンファレンスの準備から感想戦など含めて交流するきっかけになったと感じています。 おわりに 広報施策に銀の弾丸はなく、なにごとも継続が大事だと感じています。エス・エム・エスのプロダクト組織がカンファレンス参加や学習を推奨しているからこそ、カンファレンス協賛を継続的に行えているのだと改めて感じる一年でした。 カンファレンスを実施してくださる運営の皆さん、参加していてエス・エム・エスのブースに来てくださった方、ありがとうございました。またお会いしましょう！

この記事は「株式会社エス・エム・エス Advent Calendar 2024」シリーズ1の12/17の記事です。 はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」でQAを担当している中村です。気づけば入社して3年が経ちました。現在は複数のQAチームに横断的に関わりつつ、チームのサポートや改善活動の推進など、幅広い業務を担当しています。 弊社では以前から、ノーコードのテスト自動化ツール「 MagicPod 」を使用し、E2Eテスト自動化を推進しています。今回の記事では今年取り組んだ「ローカルPC実行で定期実行を実現したこと」をテーマにお話ししていきます。 昨年のAdvent Calendarでも、E2Eテスト自動化のことを記事にしているので、ぜひそちらもご覧ください 🙏 tech.bm-sms.co.jp 取り組みのお話 １．前提 カイポケにおける自動テストの状況を簡単に説明します。 開発環境がプライベートネットワークなのでMagicPodのクラウド実行機能を使えない リモートワーク主体でプライベートネットワーク内で安定した通信が求められるので、自動テストの実行環境は仮想環境を使用している カイポケの推奨環境に準拠して自動テストの実行環境はWindowsとしている これらの制約がある中で開発環境に対して定期実行を可能にする方法を検討していきました。 ２．構成 仮想環境にPowerShellを配置し、それをWindowsのタスクスケジューラで定期実行する構成としました。JenkinsなどのCIツールを利用する選択肢も検討したのですが、以下の理由から今回の構成を採用しました。 CIツールの保守にコストをかけたくない テスト実行環境を軽量で運用したい 2-1. 構成イメージ 2-2. 実行フロー スケジューラにタイマーをセットする スケジューラでセットした時刻にPowerShellを実行する MagicPodDesktopを起動し自動テストを実行する ３．テスト実行スクリプト（PowerShell） PowerShellでは、MagicPod公式のヘルプ「 コマンドライン一括テスト実行（ローカルPC環境） 」も参考にしながら、主に以下の処理を行っています。 Proxy設定の更新 MagicPodDesktop設定ファイルの更新 テスト実行 次に、コードを交えながら各処理内容を簡単に紹介していきます。なお、説明のために処理を分割していますが、実際には1つのスクリプトで完結するように構成しています。 3-1. Proxy設定の更新 ## テスト環境を指定（実際には引数で取得） $targetProxy = "XXX" ## テスト環境向けのProxyServerを定義 $proxyList = @{ "STG" = "<STG_URL>:<STG_PortNumber>" ; "DEV" = "<DEV_URL>:<DEV_PortNumber>" ; } Function changeProxy { param ( $targetProxy ) try { # 接続先のProxyServerを設定 New-ItemProperty -LiteralPath "HKCU:Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name "ProxyServer" -PropertyType "String" -Value " $targetProxy " -Force # Proxy設定をon Set-ItemProperty -Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings’ -Name ProxyEnable -Value 1 Write-Host "Proxyが設定されました: $Proxy " -ForegroundColor Green } catch { # Proxy設定をOff Set-ItemProperty -Path ‘HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings’ -Name ProxyEnable -Value 0 Write-Output "Proxy設定でエラーが発生しました" -ForegroundColor Red Write-Output $_ -ForegroundColor Yellow exit } } 3-2. MagicPodDesktop設定ファイルの更新 ## テスト実行用のパラメータを指定（実際には引数で取得） $testNumber = "XXX" $testPattern = "XXX" ## ファイルパスを指定 $magicPodConfig = " $HOME \AppData\Roaming\magic_pod_desktop\magic_pod_config.json" Function updateConfig { try { # MagicPodConfig.jsonを読み込んで更新する $jsonContent = Get-Content -Path $magicPodConfig -Encoding UTF8 -Raw | ConvertFrom-Json # テストケースを指定 $jsonContent .testSettingsNumber = $testNumber $jsonContent .testSettingsPatternName = $testPattern # JSONに変換 $updatedJson = ConvertTo-Json $jsonContent # UTF-8(BOMなし)で出力 [IO.File] :: WriteAllLines( $magicPodConfig , $updatedJson ) Write-Host "設定ファイルが正常に更新されました。" -ForegroundColor Green } catch { Write-Output "configファイルの更新でエラーが発生しました" -ForegroundColor Red Write-Output $_ -ForegroundColor Yellow exit } } 3-3. テスト実行 ## ファイルパスを指定 $magicPod = ls $HOME \AppData\Local\magic_pod_desktop\app- * \MagicPodDesktop.exe $magicPodConfig = " $HOME \AppData\Roaming\magic_pod_desktop\magic_pod_config.json" ## 実行コマンドオプションを指定 $argConfig = "run --magic_pod_config= `" $magicPodConfig `" " Function startMagicPod { Start-Process -FilePath " $magicPod " -ArgumentList $argConfig } さいごに 今回紹介した方法により、本番環境だけでなく開発環境でも定期実行を実現することができました。定期実行を導入することで、何か問題があった際にすぐに気づける安心感を得られたことは、大きな成果だと感じています。また、テストに問題が発生した時もすぐに改修できるため、テストケースの保守性向上にも役立っています。 ただし、現時点では定期実行の実現にとどまっています。今後はCI/CD連携を進めて、リリースプロセスに密接に関わる形に発展させることで、さらなる開発サイクルの高速化や品質向上を目指していきたいと考えています。 エス・エム・エスでのテスト自動化の取り組みは着実に進んでいますが、まだ発展途上であり、さまざまなチャレンジができる環境です。（常に「より良く」を目指しているので、終わりはないかもしれませんが…😅） 現在、QAエンジニアを積極採用中です！少しでも興味をお持ちいただけましたら、ぜひカジュアル面談でお話ししましょう！！

はじめに 介護/障害福祉事業者向け経営支援サービス「カイポケ」のQAを担当している星です。2020年1月に入社し、チーム活動やQA組織づくりを通じて品質保証の体制強化や施策推進をしています。 2024年も残すところあと半月ほど・・ということで、今回の記事では今年一年であった変化、その中で取り組んでみた活動の内の一つを振り返ってみたいと思います！ 組織、私個人としても沢山のチャレンジをさせてもらった一年ですが、印象深い活動をピックアップして書いてみています。 どんな変化があった？ カイポケのリニューアルプロジェクトでは今年からLeSS（Large Scale Scrum：大規模スクラム）の導入にチャレンジしています。 tech.bm-sms.co.jp このプロジェクトでは以前よりスクラムをベースとした開発プロセスを導入しており、各チームに所属しているメンバーが日々試行錯誤をしながら開発や品質保証を進めてきました。 その中でスクラムマスターの参画もあり、LeSSのフレームワークへと最適化していく過程で、よりチームとして目線を合わせやすい状態、サポートが受けやすい状態となりました。 同時に、そういった変化の中でQAエンジニアが持つ専門性をどう活用し、成長しながら貢献していけるのかということを改めて考える機会が訪れているとも感じました。 この変化や機会の中で実際の動きを通じ、QAエンジニアとしてどう貢献していくべきかを改めて考えてみたい・・・！ 私自身はQA組織内の横断的な活動も担当させてもらっているため、入社時と比べるとチーム活動からは少し離れがちにはなっていたのですが、そういった思いのもとで今年はチーム活動にも積極的に参加させていただく一年となりました。 前提 カイポケ開発の各アプリにおけるチームはプロダクトオーナー、開発者、デザイナー、QAと異なる専門性を持った多数のメンバーにて構成されているケースが多くあります。 現在私が主に関わっているチームでも同様で、それぞれが得意な領域の技術を持って開発を進めるスタイルになっています。 関わらせてもらうタイミングでちょうどチームの再編があり、ワーキングアグリーメント（チームの約束事）の作成等、チームビルディングにも参加することができました。 一部抜粋にはなりますが、現状のワーキングアグリーメントには以下のような記載をしています。 スプリントゴール達成に向けて、ロールを越えて得意な武器（領域）で援護してほしい こちらも一部ですが、QAと呼ばれる活動に専門性を持ったメンバーが期待されていることとして以下記載がされています。 検証するシナリオやパターン知見から、要求に関する不確実性を評価してもらう事に期待している 作るものの「不確実性」（要求の変化や開発における変数等）は一定発生します。 私が所属するチームでは技術と要求の不確実性の切り口でPBI（プロダクトバックログアイテム）の評価、見積もりをしています。 QAと呼ばれるメンバーはこの中で、検証シナリオやパターンの知見を用いた要求の不確実性の具体化、それに対するフィードバックをしていくことを期待されています。 そこに対して貢献ができるポイントはないか考えながら活動していきました。 どんな感じでやっているか 上記にて書かれている「要求に関する不確実性の評価」、そこからスプリントを通じて「要求の不確実性を減らしていくためのアプローチ」として、一例として以下のような活動を通じてトライアルをおこなっています。 ディスカバリーフェーズから他チーム影響も考慮したテストパターンを考えていく PRD作成までの各ステップに参加、早期からテストプランニングやパターン検討を開始 プロダクトオーナーや開発者とのテストすり合わせ（インクリメントの共通認識化）をスプリント開始後の早い時期に実施する リファインメントにて受け入れ基準をチームで確認・最適化し、ストーリーポイントを用いて不確実性に対する会話をする こういった活動の中で適宜フィードバック、デイリースクラムでの透明性確保を通じ、不確実性を下げていくことをスクラムチームにおけるQAの活動の一部として取り組んでいます。 やってみてどう？ 活動の元になっているもの自体はスクラムの基本的な考え方に基づいているため、特に目新しいものではないのかもしれません。 また、これがベストプラクティスではないと思っていますし、アウトプットの精度やフィードバックの数を増やす等、より良くなっていけるように考えていく楽しみがあると感じています。 テストプロセスの更なる最適化、自動テストを駆使したリードタイムの短縮、ワーキングアグリーメントの「ロールを越えて」という部分でできることもまだ多くあり、より一層チームとして、個人として成長していける可能性を感じています。 個人的なこれよかったポイント 長々と経緯や現状を語ってしまいましたが、エス・エム・エスのQA組織では大切にしたいものの一つに「チームで品質保証」という行動指針を掲げています。 その実現に近づいている実感を持てたことが、私個人としてとてもよかったと思っています。 QA組織の行動指針とは？ 以前テックブログにQA組織の行動指針を言語化した記事を投稿しました。 tech.bm-sms.co.jp この中の一つに「チームで品質保証」というものがあり、「職種の壁を越えて協力することで複雑な問題を解消できる組織を目指したい」という思いのもと、この項目を設計していました。 私の中でこの指針とリンクした活動に携われたという実感があり、今回のテーマで書いてみようと思ったモチベーションにもなっています！ ※ちなみにこの記事内の行動指針は昨年初稿として書いたもので、絶賛ブラッシュアップ中です。詳細は追って発信したいと考えています。 （方向性の見直しではなく、組織スケールの中でもより伝わりやすいものにしていきたいと思っています） 1点補足として、本記事の活動や考え方のみが「チームで品質保証」を体現するものではないと考えています。 チームの特色によって構築していきたい開発スタイルは異なると思っており、その自由度が高いのもエス・エム・エス開発組織の良いところだと捉えています。 まとめ ということで、組織作りにおいて今回のような活動にトライしていきたいという思いが前提としてあり、実際の動きとしてコミットしていくことも微力ながら出来たため、非常に充実した一年になったと感じています。 もちろん全て私が提案・推進・実践したわけでないですし、関係する沢山のメンバーの多大なるサポートがあってこそなので、この場を借りてお礼申し上げます！ いつもありがとうございます！ 私自身、スクラム開発やアジャイルテスティングの経験が豊富なわけではなく、ましてLeSSとなってくると日々勉強だなぁと思う毎日です。 今年は会社の支援を受けて外部研修にも参加させてもらい、とても良い刺激になりました。 tech.bm-sms.co.jp 今回の取り組みに関してもチームプロセスとしてより明確化したり、洗練していくことは必要不可欠だと思っています。 スケールしていくプロダクトに対して取り組みをどのように適用し、どう貢献していくか考え続けたいという思いもあり、ここも継続してチャレンジしていきます。 また、冒頭でも少し触れましたが今回の取り組みはあくまでも一例で、QA組織では他にも多くのTryを進めています。 今回のようにチームで一緒に走っていく活動だけでなく、横断的な関わり方を模索し、品質の維持・向上とともに不確実性を下げていく活動がプロダクトや組織のスケールによって必要になると思っています。 そういった点も組織一丸となって引き続きチャレンジしていきたいと考えています。 来年もがんばるぞ！ 様々な活動にチャレンジできるエス・エム・エスのQA組織に少しでも興味を持ってくださった方は是非カジュアル面談よろしくお願いいたします！

この記事は 株式会社エス・エム・エス Advent Calendar 2024 vol.2 12月9日の記事です。 介護/障害福祉事業者向け経営支援サービス「カイポケ」のソフトウェア開発者の 空中清高( @soranakk ) です。 本記事では、毎月開催しているチーム交流のボードゲーム会について書きます。 はじめに カイポケにはたくさんの開発チームがあります。 普段はリモートワークが中心だけど、「たまには他チームとの交流会がしたいな」ということで橋口( @gusagi ) さんがボードゲーム会を企画してくれました。 チーム交流のボードゲーム会は任意参加の会で、月に1回、だいたい月末の金曜日の夕方に開催しています。本記事ではこれまで開催したボードゲーム会でこんなゲームをやったよ〜っていうのをできるだけ思い出して紹介したいと思います。 これまでに遊んだボードゲーム ロストレガシー 宝物がどこにあるのかを探すゲーム。 1ゲームの時間が短く、毎回展開が異なるためリプレイ性があり、テンポよくできるゲーム。 他の人にアクションすることが結構あり、コミュニケーションが取りやすいゲームです。 「〇〇さん、さっき 4 のカード持ってましたよね？」 ボブジテン カタカナ語をカタカナを使わないで説明するゲーム。 説明の仕方など、個性が出て面白いです。 「 インストール をカタカナを使わないで説明してください。」 ボーナンザ 豆畑で豆を育てるゲーム。 豆を交換する交渉が必要なゲームで、各々の性格が出てとても面白い。 「この赤い豆を緑の豆と交換して欲しいなぁ、Win-Winですよ、ね？」 もっとホイップを！ 見た目は甘いケーキだけど、ゲーム内容はかなりシビア。 他の人がどのケーキを食べて、どのケーキを残しているのかを見ながら真剣にケーキを選ぶゲームです。 「どのケーキを切ったらいいかな〜。(人の顔を見ながら)ここかな〜〜？」 確定申告ゲーム 確定申告をテーマとした双六型のゲーム。 確定申告にまつわる質問に答えたり、ホテルやカメラ、スーパーカーの領収書の使用目的を聞かれたり、ロールプレイが楽しいゲームです。 「〇〇さん、この経費の領収書でカメラを買ったってあるのですが、何に使ったんですか？」 ごきぶりポーカー ゴキブリやコウモリなどを押し付け合うゲーム。 押し付けられたカードが本当に指定されたカードなのかを当てないと、押し付けられちゃう。 「これはコウモリです。いえいえ、本当ですよ？本当にコウモリです。」 ブロックス ブロックを順番に置いていく陣取りゲーム。 ルールはシンプルだけど、奥深い戦略があるゲームです。 あれ？もう置ける場所がないかも？陣取り、むずかし〜〜 Not My Fault! 俺のせいじゃない! 順番にプロジェクト進捗を報告していく、ダウト系のゲーム。 納期は守らないといけないけど、すでに報告されている進捗も実は・・・？ 案外 徹夜で頑張りました が本当だったりして、面白かったです。 センチュリー: スパイスロード センチュリー三部作の一作目。 4種類のスパイスを交換しながら、自分だけの最大効率フローを作り出して勝利する！ 目指せスパイスマスター！ マフィア・デ・クーバ 正体秘匿の人狼系のゲーム。 役職を自分で選べるのと、マフィアのボス役とのロールプレイや掛け合いが楽しいゲーム。 「ダイヤは何個あった？」 「私が見た時にはもうダイヤは一つもなかったんです！私は忠実なる部下です！」 「役職は聞いてないよ。」 インサイダーゲーム 一人だけ答えを知っているインサイダーを含めて、お題を当てるゲーム。 参加者はマスターに質問し、マスターは Yes/No/わからない で答えるだけを繰り返して推理していき、お題を当てる。 お題を当てた後にインサイダーは誰だったのかを推理するゲーム。 お題を当てるパートとインサイダーを探すパートがあって、誰が正解に誘導したんだ？というのを推理するのが楽しいゲーム。 A「それは食べられますか？」 B「それは自宅にありますか？」 C「昨日食べましたか？」 D「調味料ですか？」 E「鼻にかけたらクシャミしますか？」 インサイダーは誰だ？ ボードゲーム会の意義 ボードゲームには様々な種類のゲームがあって、強制的に嘘をつく必要があったり、ロールプレイする必要があったり、様々なシチュエーションを共有できます。 またゲームで求められるものも、純粋な論理的思考みたいなものだけじゃなく、会話や表情など様々です。 こういったゲームを通じて、人となりを知れたり、あのゲーム面白かったですね、という共通の体験が出来たりして、チームビルディングに良いと思います。 また来年もいろんなボードゲームやるぞー！

この記事は株式会社エス・エム・エス Advent Calendar 2024 vol.1の12月9日の記事です。 エス・エム・エスで全社SREというロールで活動している Security Hub芸人 1 の山口（ @yamaguchi_tk ）です。 おすすめのAWSサービスは営業です（いつもお世話になっています）。 はじめに SRE（Site Reliability Engineering）は、運用の効率化とシステムの信頼性向上を目指すアプローチです。 私たち全社SREチームでは、組織横断的にSRE活動を開発チームにEnablingしていく取り組みを開始します。本記事では、その背景や目的、具体的に活動を予定している内容をご紹介します。 背景 現在、事業部に専属のSRE（Embedded SRE的な立ち位置のSRE）がいないサービスでは、主に全社SREがインフラの構築・運用を担っています。しかし、システムの運用については受動的な対応が多く、 「組織の信頼性のマインドセット:Google SRE の知見」 に記載のある組織の信頼性のマインドセットでは Absent な段階でした。 そのため運用負荷が集中し、信頼性向上や運用の効率化のための活動になかなか手が回らない状況でした。 エス・エム・エスは事業活動の性質としてサービスの数が多く、事業部に専属のSREがいない全てのサービスの運用の効率化、信頼性の向上を全社SREチームだけで行うことは現実的ではないため、新たなアプローチを策定しました。 SRE活動を開発チームにEnablingしていく目的 私たちのチームが目指すのは以下です。 開発チームの自律性を高める 開発チームがSRE活動を主体的に実施し、信頼性のあるシステムを構築・運用できる体制になることを支援します。 運用の効率化と信頼性の向上 運用負荷を軽減し、システムがより高い信頼性を保つ状態を維持します。 具体的な活動内容 以下のような手順で活動内容を決定しました。 全社SREチームが開発チームにEnablingするSRE活動を定義 定義した活動を開発チームに委譲する目標レベルを定義 定義した活動で成熟度レベルを評価するものを決定 開発チームにEnablingする活動は以下のようになりました。 活動 Enable対象 目指す委譲レベル 成熟度評価 SLI/SLO ⭕️ 尋ねる ⭕️ 監視 ⭕️ 尋ねる ⭕️ インシデント対応 ⭕️ 尋ねる ⭕️ ポストモーテム ⭕️ 尋ねる ⭕️ ドキュメント管理 ⭕️ 尋ねる トイルの撲滅 ⭕️ 尋ねる ⭕️ コスト管理 ⭕️ 尋ねる ⭕️ 脆弱性対応 ⭕️ 尋ねる ⭕️ インフラ設計 ⭕️ 同意する 開発効率の向上 ⭕️ 尋ねる ⭕️ セキュリティ対応 伝える Admin業務 伝える 知識共有とトレーニング 伝える ログの管理 伝える 委譲レベルはManegement3.0 2 を採用しました。 伝える：私が決定し、チームに伝える 説得する：私が決定し、チームを納得させる 相談する：チームに相談してから、私が決定する 同意する：チームと一緒に決定する 助言する：助言はするが、チームが決定をする 尋ねる：チームが決定し、後で私を納得させてもらう 委ねる：チームが決定し、私は気にしない 成熟度評価 サイバーエージェントさんの資料 3 を参考にさせていただきLevel1からLevel3までの成熟度を設定しました。 SLI/SLO Level1 SLI/SLOが設定されていない Level2 SLOが計測され、信頼性の数値としてチーム内で認知されている Level3 ベストプラクティスに基づいたSLO運用ができている 監視 Level1 監視についてのルールや要件がなく、場当たり的な監視になっている Level2 監視ルールが整備され、プロダクトの異常が適切に検知できる状態になっている Level3 ベストプラクティスに基づいた監視項目の設定、通知が行われている インシデント対応 Level1 対応フローが定義されておらず、対応が属人化している Level2 対応フローが定義され、チーム全体で反復可能な状態になっている Level3 ベストプラクティスに基づいた対応フローが行われている ポストモーテム Level1 障害報告書は書いているが、障害から学習できる状況になっていない Level2 障害をふりかえり、対応プロセスやプロダクトの改善につながっている Level3 ベストプラクティスに基づいてポストモーテムの導入、ふりかえりが行われている ドキュメント管理 Level1 必要なドキュメントが整備されていない Level2 必要なドキュメントが整備されている Level3 ベストプラクティスに基づいてドキュメントの維持や整備が行われている トイルの撲滅 Level1 運用作業と開発タスクが分断しており、運用作業の改善は場当たり的に行われている Level2 運用作業の見直しや改善が計画性を持って行われている Level3 ベストプラクティスに基づいてトイルの計測や改善が行われている コスト管理 Level1 コストの削減は場当たり的に行われている Level2 コストの評価や削減が計画性を持って行われている Level3 ベストプラクティスに基づいてコストの評価や対応が行われている 脆弱性対応 Level1 脆弱性対応は場当たり的に行われている Level2 脆弱性対応が計画性を持って行われている Level3 ベストプラクティスに基づいて脆弱性の評価や対応が行われている 開発効率の向上 Level1 プロセスは定義されているが自動化は行われていない Level2 CI/CDが構築され、一部で自動化が行われている Level3 ベストプラクティスに基づいて開発効率の評価や向上への対応が行われている 開発チームとのコラボレーション 開発チームとのコラボレーションについても、「開発チームが自律的に全てのフェーズを実施できている状態」を理想形と定義し、以下のように役割分担を整理しました。 フェーズ 事業部 開発チーム 全社SRE 備考 企画・要件定義 ⭕️ ⭕️ 設計 ⭕️ ▲ 全社SREが可用性、セキュリティの観点でレビューを行う インフラ初期構築 ⭕️ ▲ admin的な業務は全社SREが実施 その他は開発チームで構築 開発 ⭕️ インフラ変更等 ⭕️ ▲ 全て開発チームで実施 必要に応じて全社SREが支援、レビューを行う アラート対応 ⭕️ 営業時間内外問わず開発チームが実施 インフラ作業 ⭕️ ▲ Admin業務以外は開発チームが実施 メンテナンス対応 ⭕️ 開発チームが通知を確認して開発チームが実施 脆弱性対応 ⭕️ ⭕️ 基本的に開発チームが自律的に実施 緊急性の高いものに関しては全社SREが脆弱性を確認し開発チームに対応を依頼 今後の展望 全社SREチームでは、この取り組みを通じて「組織全体で信頼性を高める文化」を醸成していきます。 開発チームと密に連携しながら、組織横断的なSRE活動の推進に取り組んでいきます。 本取り組みに関する最新情報や進捗は、随時Blogで共有していく予定です。 SRE界隈でもAWS界隈でも「山口」だとレピュテーションがなかなか上がらないので、レピュテーションは「Security Hub芸人」で確保しています ↩ 「Management 3.0 デレゲーションと エンパワーメント」 ↩ 「SRE Technology Map 2023」 ↩

この記事は株式会社エス・エム・エス Advent Calendar 2024 vol.2の4日目の記事です。 エス・エム・エス Engineering Manager 兼 Hiring Managerの @emfurupon777 です。 はじめに 入社してからずっと関わってきている社内外交流の観点でも継続することの重要さを改めて実感じているので、継続を意識して取り組んでいることについてポエムってみようと筆をとっています。 とはいえ、全部書いてもなーというところで、社内・社外向けの取り組み一つずつ取り上げてみます。社内はLT会、社外は協賛カンファレンスでのノベルティ提供(アイコン缶バッジ)についてです。 ちなみにエス・エム・エスの経営理念は『永続する企業グループとして成長し続け、社会に貢献し続ける』で、設立当初から永続性、継続性が強く意識されているので、継続性について意識を高く持っておくのは自然な話だったりします。仲間は常に積極募集中ですのでこの継続性について興味持っていただいた方はカジュアル面談からぜひお話ししましょう。 社内LT会 1. 観測 エス・エム・エスに入社して社内でどんな取り組みがあるのかなーと思って調べてみるとテックトークという記載が見つかりました。(おお、あるじゃん。まずは参加してみるだけで良いかな？と一瞬思いました) ところが、開催が散発的になっていてしばらく開催されていなそう・・・わかります。やろうぜってなって数回やるとネタが尽きて一旦下火になったりするんですよね。よーし、再起動やってやろうじゃないの。と自分で進めることにしました。 2. 下ごしらえ LT会やるならという感じで世に知見は転がっていて、必要なものは明確。 よし。青島、確保だ！(古い) 会場 エス・エム・エス本社ラウンジ確保！ (100名くらい集まれる広さのラウンジがあったので社内規定みつつ、ガッとおさえる) 経費(軽食、ドリンク等) カルチャー醸成&採用広報文脈で確保！ 登壇者 初回を納会じたてにして確保！ 実績解除しつつ少し先の開催まで少しずつ確保！ ハイブリッド開催の手段 本社に来れるなら寿司でもつまみながらワイワイしたい とはいえ、遠方の人にも参加してほしいからハイブリッドでやりたい とはいえ、ちゃんと配信しようと思うとスイッチャー類とか買ったり運用したりが大変 社内の取り組みだし大丈夫やろ、ということでラウンジにある現地のマイクとZoomを組み合わせるアナログな運営方法を確保！ 3. 当日の仕切り 原則クロコに徹します。軌道に乗せて形式化できるまでは我慢の子。(これ大事ですね) 飲食の手配＆受取 司会 帰る前に経費精算(忘れるとめんどうなので) 4. 継続できているか？ 正直まだまだ続けてやっているとはいえない状況かなというのが正直なところで、まずは100回くらいやってみるのが大事かなと思ってます。それくらい続けていれば一緒に運営してくれる人も多くなってくるし、定期的に開催時期がやってくるのがわかるようになるのではないかと思ってます。 登壇者が集まらないという話を時々耳にしますが、エス・エム・エスの場合は開催スケジュール決めちゃって声をかけてみると意外と？なんとかなります。(といいつつ、私の経験上ではどこの会社でも実は声かけて相談すればなんとかなる) 自発的な登壇は基本にしたいし、もちろんそれも面白いのですが、少し前に入社してきたあの人、Slackで気になることを言ってたあの人、みたいな他薦での登壇依頼もしてみると、普段業務で関わっているのとはまた違ったキャラクターが出てたりして面白いです。内容もあまりこだわりすぎずに好き勝手に話してもらうくらいでやってます。 ノベルティ提供(アイコン缶バッジ) 1. 観測 エス・エム・エスは私の入社前からRubyKaigiをはじめとする技術カンファレンスでブース出展してきたようだというのがesaやSlack検索などで見えました。ブースで提供してきたのは・・・どら焼きとか？ エスエムエス様のスポンサーブースでどら焼きが大量に残って困っているとのこと。Rubyistのみんな助けて！！！ #rubykaigi #dorayaki #sos #sms pic.twitter.com/sC2VYzSyrJ — はたけやまたかし (@htkymtks) 2018年6月1日 私も食べるのが好きなのでいいなーと思うものの、カンファレンスによっては飲食の提供は禁止なんですよね。そして、各カンファレンスに沿った企画はそれぞれの領域のエンジニア仲間にお任せしたほうが刺さるはず。 そうなると、私のメインミッションが採用ということもあり、できれば幅広いイベントに一貫して適用できる、飲食以外のもの、がいいなーという思いが芽生えてきて、これに合致するネタを捻り出す必要がある、というところに至りました。 2. 下ごしらえ さてノベルティのアイデアを考えます。ステッカーとか定番ものやノベルティ制作サービスなどを探索に行って・・・決まりません。(みなさん経験ありますよね？) 周囲に相談しつつ、カンファレンスなどで話が盛り上がるのは誰かなーとペルソナを考えていくと、結局エス・エム・エスの社員に似た人かも？という話になります。 ならばということで皆の言動をSlackなどのコミュニケーションで観測しにいく期間に入ります。(大体3ヶ月くらい。Slackで検索かけたり、リアルで話してるのを横からみてたりします。怪しいw) 基本的なニーズを社員観察で探りつつ、具体的な物品をプライベートで出かけた先で集客状況と合わせてチェックを続けます(社員観察から遅れて初めて1-2ヶ月くらい)。 そんな中で下記の組み合わせでの実現に辿り着きました。 前述の社内LT会でオフィスで顔合わせても、リアルで会うのが初めてで誰かわからない（Slackアイコンとナマの同僚が結びつかない) 普段目にしているアイコンを缶バッジにして身につけてもらおう 区民祭りでやっていた、缶バッチを自分でガシャコンと作れる企画がちびっ子たち(私の子供含む)にウケていた ちびっ子が楽しいと思うならエンジニアにも受けるに違いない（偏見） 何人かのエンジニアに共有してみたところそこそこウケが良かったのでこれで進めることに決定！(残り時間が少なかったというのもあります) もちろんこういう素朴な疑問も頂きますが、いいんです。やってみて反省するんです、ということで突き進みました。 やるからには一定のクオリティは担保したいということで、缶バッジメーカーは業務用のを選びました。安定して生産できています。 3. 当日の仕切り 下記のようなものを用意しておいて、協賛ブースで現地生産を頑張るだけです。 独りでも完遂するぞ！という感じでやっていましたが、一緒に採用をやっている人事さんたちが妖精さんの如く一緒にやってくれましたありがとう。 応募フォーム (アイコン画像を間違いなくいただき、その利用に同意いただくため) モバイルプリンター 缶バッジ用切り抜きカッター 缶バッジメーカー 缶バッジパーツ 4. 継続できているのか？ 今年はありがたいことに協賛ブースを多く出すことができたので、下記カンファレンスにて缶バッジを提供することができました。 RubyKaigi 2024 (現地生産は無し) Kotlin Fest 2024 SRE NEXT 2024 Kaigi on Rails 2024 1年続けてきたので、来年も少しアレンジを加えて企画を継続するのか、新たな企画に起こし直すのかは検討中です。 最後に 今回の記事が同じような取り組みをしている方に読んでいただければ嬉しいです。 そして、LT会を複数の会社合同で開催したり、ブース企画を複数社で連動したりできると面白いかもなーと思っていますので、お気軽に公式Xなどにご連絡ください。 おまけ プライベートの話なんですが、今年は生まれて初めて庭に芝生をはりました。 まずはーということで庭の半分くらいに高麗芝。やってみてはじめて知ることが多く、日々学んでる感が半端ないです。夏芝と冬芝という気温の違いでの植生のギャップも面白い。来年から綺麗に芝生を維持継続できるように頑張ります。 冬枯れの夏芝(左上)と元気に生え始めた冬芝(右下)の様子比較はこちら。

この記事は株式会社エス・エム・エス Advent Calendar 2024の4日目の記事です。 エス・エム・エス BPR推進部 データ基盤チームの橘と申します。 私は「ナース専科 転職」等のキャリア事業を中心に、社内のデータ活用の推進、データ基盤の開発運用を担当する、データエンジニアの役割を担っています。 はじめに キャリア事業のデータ基盤は、Google Cloud 上に、BigQuery を中心に構築しています。 近年、データ活用の需要はますます拡大し、事業部門がTableauやQuickSightなどのBIツールを介してデータ基盤を利用したり、Google スプレッドシートや BigQuery Studio からSQLを実行しての分析等が進んでいます。 データ基盤の活用を推進する中で、以下を目指し日々運用をしています。 必要なデータがどこにあるかがわかる(Discoverable) 必要な人が必要なデータにすぐにアクセスできる(Addressable) セキュリティやガバナンスが守られている(Secure) 昨年のAdvent Calendar の記事は、上記のDiscoverable、Addressableを達成するための手段の1つでした。 tech.bm-sms.co.jp 今回は、AddressableとSecureを実現する、権限管理について触れたいと思います。 キャリア事業は複数のサービスを抱え、サービス内に複数の活用できるデータが眠っています。データ基盤の拡大とともに、Google Cloud のプロジェクトも複数となり、BigQuery のデータセットだけを見ても、多数に分割して管理されています。 煩雑化と属人化が進みつつある権限管理を昨年見直し、運用をしてきましたので、その事例をご紹介します。 データ基盤における権限管理 私たちのデータ基盤は、Google Cloud のプロジェクトのIAM、BigQuery やCloud Storage などのデータへの読み書きのアクセス権限、App Engine アプリケーションへのアクセス権限など、複数個所での権限設定を運用しています。キャリア事業にかかわる社内のあらゆるデータを蓄積しているため、ユーザー側の見れるデータ、編集できるデータを最小限にするためにポリシーを設けて、データ基盤管理者がポリシーに沿って適切な権限を設定していく運用を続けています。 従来は、データ基盤管理者数名で、依頼ベースでGoogle Cloud のコンソール上から手動での権限設定の対応を行ってきました。権限設定自体はGUI上でも簡単にできますが、以下の問題がありました。 変更履歴を管理できない 複数人複数個所の設定が手動での運用だと大変 権限設定を依頼する人は権限を操作する権限を持たないため、変更箇所の指定をしにくい 上記を解消するために、構成管理ツール、Terraform を昨年度に導入しました。 元々データ基盤では管理するリソースが多くもなかったのでTerraformを導入していなかったという背景がありました。Cloud Storage のバケット毎、BigQuery のデータセット毎の権限設定等を目的にTerraformの導入をし、付帯的にインフラの構成管理としての導入も進めました。 導入から1年ほど経ったので具体的な構成や導入後のメリットをご紹介します。 Terraformの構成 まず、Terraformのディレクトリ構成としては以下になります。 . ├── modules/ │ └── 共通モジュールなど └── projects/ ├── プロジェクト1 │ ├── resources/ │ │ ├── bigquery.tf │ │ ├── cloud_storage.tf │ │ ├── iam.tf │ │ ├── members.tf │ │ ├── service_account.tf │ │ └...他リソースごとのtfファイル │ ├── .terraform.lock.hcl │ ├── main.tf │ └── variables.tf ├── プロジェクト2/ └...以降プロジェクト毎のディレクトリ/ キャリア事業のデータ基盤として複数のGoogle Cloud のプロジェクトがあるため、複数プロジェクトを一元管理できる構成としています。 projects/[実際のプロジェクトID]/resources 配下には、 biguery.tf 、 cloud_storage.tf などのリソース毎の定義ファイルを置いてます。例えば、 bigquery.tf は、BigQuery のデータセットごとのリソース管理と、データセットのReaderやWriterの定義を管理しています。 Google Cloud の権限は、GoogleグループやGoogleアカウント毎に定義が可能ですが、権限管理の目的内でのグルーピングができるように、 member.tf を作成しています。この中でlocal変数として、GoogleグループやGoogleアカウントをリストで定義して、各リソースに設定できるようにしています。 運用フロー まず、ユーザー部門がデータ基盤チーム宛に、権限設定の依頼をします。具体的に見たいBigQueryのデータセットを書いて依頼をしたり、業務上どういうデータを分析したいかなどの抽象的な相談をしたりします。 その要求をデータ基盤チームの開発者が受け取り、必要であればユーザー部門に業務のヒアリングを行い、Terraformのコードを書いてGitHubのプルリクエストを作成していきます。 プルリクエストをデータ基盤管理者がレビュー・承認することで、権限設定ができる仕組みとしています。 導入してから変わったこと いつ、誰に、どういう目的で、何の権限設定をしたかを把握できるようになった 複数プロジェクトまとめての権限の棚卸しがしやすくなった テキストエディタ上で設定を記述するため、AIによる自動入力の支援を得られるようになった ユーザー側の要求によってどの権限が必要かのレビューがしやすくなった 今まではデータ基盤管理者のみが権限を把握していたが、Terraformのコードを書く開発メンバーも、データ基盤の権限構成を理解できるようになった など複数のメリットがありました。 特に後者の2つはデータ基盤の管理の属人化を避けるためにも効果的で、データ基盤”チーム”として運用をしていく体制が確立したと思います。 まとめと今後の展望 以上、データ基盤における権限管理についてご紹介しました。BIや生成AIの発展とともに、ますますデータ基盤の利用機会も増えてきました。データのAddressableとSecureを加味した適切な運用はこれからも継続して見直していきたいと考えています。 エス・エム・エスは新しいメンバーを募集しています。 私達データ基盤チームでは、今回ご紹介したデータ基盤の運用から、データパイプラインの開発、データマートやダッシュボードの開発、AIを用いたソリューションの提供など様々な業務を通して事業を支援しています。 弊社の事業に携わってみたい方、興味のある方は、ぜひこちらのページものぞいてみてください。 careers.bm-sms.co.jp open.talentio.com

この記事は株式会社エス・エム・エス Advent Calendar 2024 および Datadog Advent Calendar 2024の4日目の記事です。 qiita.com qiita.com こんにちは、介護/障害福祉事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトでSREを担当している加我 ( @TAKA_0411 ) です。SREチームの中では主にモニタリングとオブザーバビリティに関する全般を担当しています。 エス・エム・エスでは複数のプロダクトを開発・運用しており、オブザーバビリティに関するサービスの選定についてはプロダクトの規模感や特性、ユースケースなどを考慮し最適なものを導入しています。私が携わっているカイポケのリニューアルではDatadogを採用しており、サービス全体のオブザーバビリティの設計だったりSLI/SLO周りの設計などをみんなで考えつつ開発を進めている状況です。 会社やプロダクトにより導入しているオブザーバビリティSaaSは様々だと思いますが、私が直近で利用していたものは下記のように推移しています。 前々職 : Mackerel, Datadog 前職 : New Relic 現職 : Datadog 前職ではNew Relicの使い方を学び活用方法を考えるのに多くの時間を費やしていたため、自然とDatadogの知識や成功体験をリセットするUnlearnに至りました。そして改めてDatadogを利用するにあたり、Datadogを再学習 (Relearn) するにはどうすればいいかを考えこの記事を書いています。 オブザーバビリティSaaSの違いについて DatadogやNew Relic、SplunkといったオブザーバビリティSaaSは「システムが生成するテレメトリーデータを収集し分析し可視化する」といった機能の点においては概ね似たようなことが実現できると言えます。 Full Stack Monitoring より引用 インテリジェントオブサーバビリティプラットフォーム より引用 Splunk Observability Cloud より引用 一方で対応しているテレメトリーデータの種類や生成AIの活用、セキュリティへの対応といった機能観点での違いがあったり、テレメトリーデータを操作するためのUIが大きく異なっていたり、取り込むデータの単価や有償のアカウントの有無といったコスト観点での違いもあります。 Relearn Datadog ここからは私がエス・エム・エスに入社してからDatadogをRelearnするに至った経緯や実際に取り組んでみたことについて紹介します。 1. 理想と現実のギャップ 実を言うと入社直後の私は「New RelicもDatadogもやれること・やることは一緒だし、以前利用していたからすぐに思い出せるだろう」と過信していました。しかし、実際にはDatadogのWeb UIの階層構造の変化に戸惑ったり、Datadogの各種設定方法を思い出すのにそれなりの時間を要するという有様でした。 特に前職で利用していたNew RelicのNRQL (New Relic Query Language) があまりにも便利で多用していたため、DatadogにおけるSQLライク “ではない” テレメトリーデータの分析やアラートの設定方法を思い出すのに躓いてしまったことは否めません。 補足 : Previewというステータスですが、DDSQLというSQLライクなクエリ言語がDatadogにもあります。 https://docs.datadoghq.com/ddsql_editor/ というわけで、前々職でDatadogを利用していた頃から今に至るまで多くの機能やWeb UIにアップデートがあり、それにあわせて私の知識をアップデートする必要があることを痛感しました。それほどクラウドサービスの進化は早いのだと驚かされます。 基礎を固めるのは非常に重要であり、特にSaaSにおいては設計思想を学ぶことでより良い活用に繋がるというのは過去に得られた多くの学びのうちの1つです。Unlearn and Relearnということで改めてDatadogを学んでいきます。 2. ドキュメントや書籍による学習 Datadogの使い方を学ぶにあたり、公式のドキュメントやeBookを読みつつ、当時私が購入した書籍が手元にあることを思い出し読み返してみました。 Datadog Cloud Monitoring Quick Start Guide: Proactively create dashboards, write scripts, manage alerts, and monitor containers using Datadog (English Edition) 作者: Theakanath, Thomas Kurian Packt Publishing Amazon この本は洋書であるため、英語が得意ではない私にとっては読み進めるのに若干の負担があります。また、ところどころ現在のWeb UIや機能からビハインドがあります。しかし、Datadogの基本となる考え方や操作を思い出すのには全く問題ありませんでした。300ページという若干厚めの本ではありますが、覚えていた箇所を適度に読み飛ばしてDatadogの知識と記憶を少し取り戻すことに成功しました。 3. Datadog Learning Centerとの出会い さて、ここからが本記事のメインです。 私は技術に関しては書籍で学ぶことが多く、過去にはNew Relicを学ぶために下記の書籍を何度も読み返すことで設計思想を理解し活用してきました。 New Relic実践入門 第2版 オブザーバビリティの基礎と実現 作者: 松本 大樹 , 会澤 康二 , 松川 晋士 , 古垣 智裕 , 梅津 寛子 , 章 俊 , 竹澤 拡子 , 三井 翔太 , 大森 俊秀 , 大川 嘉一 , 中島 良樹 , 山口 公浩 , 齊藤 雅幸 , 小林 良太郎 , 髙木 憲弥 , 板谷 郷司 , 長島 謙吾 , 伊藤 基靖 翔泳社 Amazon Datadogにも入門書的なものがあると嬉しいといった旨の話をDatadogでSales Engineerを務めている Taka2さん に相談してみたところ「書籍についてはすぐに回答はできないが、Datadog Learning Centerというeラーニングがあるのでそこで学ぶことができる」という回答を頂けたのを思い出しました。 Datadogを気軽に試せる環境があればいいのに... というお声もいただいていたかと思いますが、 無料で何度でも環境払い出して使えるlearning centerがありますので、よろしければこちらも活用してみてください 監視対象のDemoアプリも立ち上がります https://t.co/RHHX3cafmC #datadog_japan_meetup https://t.co/RTGWICBLxt — Taka2 (@taka2noda) 2023年10月27日 実際にDatadog Learning Centerを触ってみようと思い下調べをしていたところ、詳細に書かれた下記のブログから有益な情報を得ることができました。 zenn.dev 今の自分にはちょうど良さそうだと考え、実際にDatadog Learning Centerのアカウントを作成していくつかのコースを受講してみました。 Datadog Learning Center Datadog Learning Centerの活用 まずは利用するためのアカウントを作成する必要があります。下記のページにアクセスし必要情報を入力してアカウントを作成しましょう。 アカウントの作成 アカウント作成後、ログインするとコースの受講具合・進捗具合を確かめることができます。途中でサイトから離脱した場合も進捗をカウントしてくれるので「続きは明日やろう」というのも問題ありません。 My Dashboard ということで、試しに基本となる3つのコースを受講してみることにしました。受講する順番はこの流れが個人的にオススメです。まずはオブザーバビリティについて学び、次にDatadogのWeb UIを触りながら全体像を掴む、そしてDatadogの基本的な機能の実践的な使い方を学ぶという流れです。 1. Introduction to Observability Introduction to Observability このコースではDatadogを使い始める前に「オブザーバビリティとはなにか」について学びます。オブザーバビリティとモニタリングの世界を初めて学ぶ人のために設計されており、Datadogやそれ以外のモニタリングサービス・ツールに関する予備知識は不要となっています。 このコースは動画を見て学ぶ座学形式となっており、オブザーバビリティの主要なテレメトリーデータであるメトリクス・トレース・ログについて理解し、モニタリングとアラートについて学ぶことができます。言語は英語ですが、日本語字幕のON/OFFや再生速度の変更などの設定が可能です。ちなみに日本語字幕は比較的良好な精度でした。 私はSREとしてテレメトリーデータに慣れ親しんでいるという自負はありますが、それぞれのテレメトリーデータの定義、構成要素、収集する必要性については言語化が苦手でした。曖昧な理解にとどまっていたのでしょう。しかし、このコースを受講することで各テレメトリーデータの定義についての理解が進み、言語化も前に比べて改善したと思っています。 仮に各テレメトリーデータの定義を忘れてしまってもこのコースに戻って来ることで何度も復習できます。このコースはDatadogの利用の有無に関わらず多くのエンジニアにオススメです。 2. Datadog Quick Start Datadog Quick Start 「あなたはマイクロサービスで構成されたEコマースアプリの健全性とパフォーマンス監視のためにDatadogを使い始めました」というストーリーで始まるこのコースでは、下記4つの項目についてDatadogの検証環境 (ラボ環境) を使用して学ぶハンズオン形式となっています。画面は検証環境のアカウント情報が記載されているコンソールと、レッスンのテキストで構成されています。 ダッシュボードの操作 ログデータの検索と可視化 サービスカタログによるサービス詳細の確認 モニターの管理 このコースはDatadogのWeb UIから各機能へのアクセス方法や、データを調査する際にどういった流れで行うのかといった基本的なDatadogの操作方法や考え方を学ぶことができます。私がDatadogをRelearnするにあたって必要だったのはまさしくこのコースであり、入社後すぐに取り組めば良かったと後悔する程度には得られるものが多かったです。 3. Datadog Foundation Datadog Foundation 最後に紹介するのはDatadog Foundationというコースです。このコースは下記の5つの機能を学ぶためのレッスンで構成されており、それぞれのレッスンは前後半2つのパートで構成されています。前半のパートでは座学で機能とコンセプトを学び、後半のパートではハンズオン形式でDatadogの検証環境を使用して設定変更などを行います。 Universal Service Monitoring (USM) and Service Catalog Logs Metrics Integrations Dashboars まずは動画を見て機能とコンセプトを知り、実際に検証環境でWeb UIを操作してみて理解するという構成がいい感じです。同じハンズオン形式であるDatadog Quick Startのコースに比べてそれぞれの機能をより深く学ぶことができるため、より実践的なコースであるという印象を受けました。特に後半のハンズオンパートは意外とボリュームがあり驚きました。コンソールにIDEのメニューが増えており、docker-compose.ymlファイルを見つつDatadogの検証環境の表示を比較するといったものがあります。 Datadogでのログ周りの集計やビジュアライズの方法をすっかり忘れてしまったこともあり、こちらのコースでしっかりと復習することができました。簡単な確認テストがいくつかあるので復習もできます。 まとめ Datadog Learning Centerを活用することでDatadogの知識をRelearnした話を書いてみました。 Datadog Learning Centerは無料で利用でき、実際にDatadogの検証環境が利用できる期限付きのアカウントが払い出されるため、書籍やドキュメントなどに比べて学習効率が高いと感じました。これからDatadogを触る人や、私のように久しぶりに触る人にとっては最適なコンテンツのように思えます。チーム共通の知識としてエンジニアの入社後のオンボーディングに組み込んでみたり、あまりDatadogを使いこなせていないチームに受講して貰って活用のきっかけにしてもらうというのも良さそうです。 Datadog Learning CenterにはDatadogの機能を学ぶためのコースだけではなく、前述のオブザーバビリティへの理解を深めるコースやSite Reliability Engineerについて学べるコース、OpenTelemetryを学べるコースなどもあります。先日のJAWS FESTA 2024では「オブザーバビリティはツールを導入するだけでは実現できない」という話をしましたが、オブザーバビリティの意義を正しく理解することでHowとしてのDatadogがプロダクトの課題を解決する手助けになるでしょう。 また、Datadogの認定試験ではDatadog Learning Centerの一部のコースを学ぶことが推奨されており、学習 → 認定 → 活用という一連の流れが上手く設計されているという印象を受けました。 www.datadoghq.com 私も来年こそはDatadog認定資格を取得しようと考えているため、まずは全てのコースを制覇しつつDatadogへの理解を深めていこうと思います。みなさまもDatadog Learning CenterでLearn・Relearnに挑戦してみてください。