はじめまして。エス・エム・エスでエンジニアをしている宮坂です。 これまでは、主にWebサービスを提供する会社でエンジニアやマネジャーをしてきましたが、2022年1月に入社し、エンジニアとして介護事業者向け経営支援サービス「 カイポケ 」の開発に携わっています。 入社して間もないですが、エス・エム・エスに入社して感じたことを書いてみようと思います。 今まで何をやってきたか 学生時代からコンピュータを使った仕事に就きたいと思い、大学では情報工学を専攻。大学卒業後に入社した会社では、新規ビジネスの立ち上げを担うを行う部署に配属され、その立ち上げに必要な開発を担当していました。組込み機器の開発からWebアプリケーション、インフラまで様々な技術的な経験ができました。 ただ、その組織の性質上、プロトタイプの開発で終わることが多かったため、世の中の人たちに役に立つものを作りたいと思い、転職。その後、Webサービスのバックエンドのアプリケーション開発を主にWebサービスの会社を2社ほど経験しました。アプリケーション開発だけでなく、安定的にサービスを提供するための全体のアーキテクチャを考慮したシステム構築やチーム間の仕様調整なども経験し、エンジニアとして良い経験ができたのではないかと思っています。 また、どちらの会社でもエンジニアだけでなく、マネジャーもやったりしていたので、役割としても様々な経験をすることができました。何度かマネジャーとプレイヤーとで行き来しましたが、エンジニアとして手を動かしつつもマネジャーとしてうまくいかなかったことをどうやって他の人は解決しているのか？という視点も持ちながら働くことができて、いろいろと視野が広がったような気がしています。 エス・エム・エスに入社した理由 エス・エム・エスという会社を知ったのは、スカウトが来たときでした。正直、それまではどんな会社なのかよくわからず…。 ただ、介護や医療という分野は、自分たちの親の世代に差し迫っていることを実感していることもあって、今後のニーズも高く、「世の中の人たちに役に立つものを作りたい」という自分の指向にもマッチし、自分の経験を活かすには良いかも知れないと思い、話を聞くことにしました。 今まで経験した転職活動に比べると、多くの方々と面接や顔合わせをさせてもらいました。 そのお陰で、 ビジネスの戦略に筋が通っていて、堅実な開発をしている印象を持った 技術的負債の返却にエンジニアだけでなく会社全体で注力する姿勢が垣間見えた 一人で気負うことなく、チームで一緒になってゴールを目指せそう というようなことを思いました。 特に介護業界は慢性的な人手不足で、テクノロジーを活かして課題を解決していくことに意義を感じましたし、新たなデバイスなどを活用していく将来のイメージを面接の中で語られていて、自分の経験も活かせるし、さらに新たな技術的なチャレンジも今後できそうという面白さを感じました。 また、それぞれ別の会社で昔の同僚だった、 光宗さん と 岩田さん がいたのも大きかったと思います。特にリファラル採用というわけではなかったのですが、昔一緒に働いていた仲間とまた一緒に働けるというのは心強いという思いもあり、入社することにしました。 入社してどうだったのか 現在は、カイポケのアーキテクチャ改善に携わっています。 日頃接することのない介護業界の業務知識を得るのは難しく、聞き慣れない言葉も多いのですが、介護の現状や高齢社会を迎える日本の将来を考えると、介護業界をITの力で支えていくことにやり甲斐を感じつつ、日々キャッチアップしています。 入社すぐのオンボーディングには力を入れてやってもらいました。 オンボーディング担当者を一人を付けて様々なサポートするパターンが多い中、入社前から、いち早く立ち上がるためにはということで、チーム全体でオンボーディングを考えてもらったようでした。事前にオンボーディングタスクを洗い出し、誰が何をやるのか分担してもらうことで、自発的にオンボーディングに関わってもらったような気がしています。 こういったところにも表れているのですが、会社の文化として、担当一人が黙々と作業していくというよりは、チームみんなで作業する時間を確保し、その時間を使って物事をドライブしていく文化なんだなということを感じています。設計やプログラミングなども話をしながら作業を進めることが多く、一人で気負わず相談しながら進められていて、特に右も左もわからない時期に様々な意見や気付きをすぐにインプットしながら、キャッチアップできたことは非常に良かったなと思っています。 お陰で早い段階でチームに馴染むことができましたし、自分も何をやったらよいかわからないということもありませんでした。現在フルリモートでの勤務で、最初はどうなるかなという不安はありましたが、違和感なく今の仕事に取りかかれた気がしていて、チームのみなさんには感謝しています。 また、今のチームでは、ソフトウェア設計手法に DDD を採用し、アーキテクチャの改善に向けて介護領域の業務を再度分析しています。 Domain-Driven Design Starter Modelling Process に倣い、定義されている一つ一つステップを踏みながら、開発対象をソフトウェアに落としていっています。（Domain-Driven Design Starter Modelling Process の取り組みについては、今後具体的にご紹介できればと思っています。） 技術的負債やアーキテクチャの改善に対しては、今までの自分の経験ではエンジニアだけで仕事を進めていくことが多かったのですが、DDD を通して、エンジニアだけでなく、PdMやドメインエキスパート、デザイナー、QAが一丸となって進めています。入社前に感じたプロダクトの改善を組織全体で解決していこうという姿勢を体感することができていて、技術的な改善には比較的進めやすいのかなということを感じています。 これから アーキテクチャ改善は始まったばかりです。 自分としてはまだ触れたことのない Kotlin や GraphQL など新たな技術に触れながら、モダンなシステムアーキテクチャを採用しプロダクトを作り上げていくフェーズに不安を感じつつも、新たな価値が生み出せることに非常にワクワクしています。 自分は知識も技術もまだまだですが、今後より加速する高齢社会に対して、より良いプロダクトを提供し続けられるように、今後もチーム一丸となって頑張っていきたいと思っています。

はじめまして。株式会社エス・エム・エスに、2022年1月1日からEM(Engineering Manager) として入社した @emfurupon777 です。 少し前からEMという呼称がプロダクト開発、エンジニアリングの話題の中で普通に使われるようになり、SNSやブログ上でもEM自身から、その成果の見えにくさや結果が出るまでの時間軸の長さなどに起因する難しさを意識した発信が多くされるようになってきたように感じています。 今回、私の入社エントリとして、エンジニアリングのトップが存在する組織にEMとしてJOINする際に不安に思った要素と、それに対して取った行動を軽くまとめてみました。 はじめに エス・エム・エスでのEMの位置付け(私なりの理解) 弊社の人事組織としては部長、グループ長などは存在しますが、EMが会社組織上の職責を担っていないこともありえますし、EMでない者・・例えばテックリードが職責を担うこともありえます。実際、私の場合入社時の人事的な配置としては 同じくEMを務める岩田 の下につくという形でした。 が、 @sunaot が実は自らはCTOと名乗っていないころからも推測できるように、弊社もいわゆる普通のWeb企業。肩書きにこだわらない、ロールベースのカルチャーとなっています。正直、人事組織を気にしている人間はほとんどおらず・・というか組織図をみたことがない人の方が多いかもしれませんw 私は何者なのか EMを担うようになった経緯として、私の略歴をあげておきます。 所属 経歴概要 学生時代 ・情報工学ではあったが、学部までのため正直かじった程度の、業務の役には立たないレベル ・第1種、第2種、プロダクションエンジニア(どれも今は名称が変わったり無くなったりしている資格)など基本的な知識をえておくかーくらいな学生(SIer向きw) 1社目 SIer ・新卒入社 ・ケータイキャリア向けの開発をC/C++, Javaで経験 ・事業から遠くて悶々。。というSIerエンジニアにありがちな思いを抱きつつ勤務 2社目 医療Web 事業会社 ・JavaのWebエンジニアとして謎の会社に入社 ・主力サービスをはじめとする複数サービスの担当として開発から運用まで経験 ・メンバー => チームリーダー => EMと役割を変えて経験 ・急成長事業会社のスピード感とコスト感にカルチャーショックを抱きながら勤務 3社目 動画SaaS ベンチャー ・VPoEとしてJOIN ・プロダクトの開発に直接は関わらない、以外はなんでもやる ・資金調達しながら進むベンチャーとしての振る舞いを学びながら勤務 本題 不安要素 さて本題です。今回、ざっと振り返って主に感じた不安は以下のようなものでした。(細かいことまであげるともっと無数にありますがキリがないので、、) 技術的理解が不十分 開発プロセス、技術スタックを把握していないし、その導入経緯も不明 それぞれのエンジニアが書いているコードを(少ししか)見ていない 技術課題の把握やカイゼンの取り組みがどこで誰によって進んでいるか不明 障害対応の役に立てない（SPOF、ボトルネックなどの勘所がわからない） 事業を理解できていない ドメイン知識の習得に時間がかかる 事業領域が複数あり、そのフェーズもさまざまな会社のため、エンジニア以外のステークホルダー・プレイヤー把握が難しい 収益構造の理解がない 人が理解できていない 面接で直接お話しした同僚は少数 共通コンテキストがゼロ（に感じる）の人が多数で、それぞれ何をする人なのかわからない 信頼貯金がない これまで具体的にやってきたこと・得意なことが伝わっていない 同じ課題を乗り越えていないので、心理的距離がある EMとしての(主たる)ミッションを明確化しにくい 中長期のミッションは、究極的に表現すれば「◯◯なエンジニアリング組織にする」がミッションだが・・ 短期のミッションはふわっとしたもの、「要は諸々のバランス」になりがち アドホックなミッション/タスクは、これの優先順位はどう決めましょうね？のような意思決定に関する相談を受けたり、背中を押したりする・・・ことが多いが、ユニバース（全体感）が把握できていない中での振る舞いがむずかしい いざ書き出してみると、どれも一人のエンジニアIC(Individual Contributor)として入社した場合にも不安に思う要素かなと思います。では、どのような順番でこれらに取り組めば良いでしょうか？ 例えばEMを初めて経験した前々職では、担当するプロジェクトに取り組むことで、1->2->3->4->5のように、ある程度限定された範囲から徐々に広げるステップを踏みながら経験していきました。実際前々職で私の場合は約8年かけてEMに役割が移っていったので、主力サービスのコードは読んだことはあるし、事業構造や社内での人間関係や意思決定のクセのようなものまでそれなりに理解したうえでEM業にあたっていたように思います。 ただ、ここにEMとして入社という前提条件が加わると途端に困ったことになります。いちエンジニアとしての経験から・・となると、さすがに8年は大袈裟ですが同じように経験していったのでは、アウトプットとして期待されているものとは異なると思いますし、アウトカムとしても不十分な期間が長そうです。 ここで一人のEMとしては「今、俯瞰してみて大きな課題になっているのはなんなのよ？誰か教えて！」と考えますが・・・。ただ、世の中でこれが与えられることは稀なんだよな、と今回改めて実感しました。なぜなら！その課題抽出自体がEMのミッションに内包されているからですね。。 取りうると考えた手段・取った手段たち ひたすら訊く【全体への対策】 何はともあれ訊くことは大事です。相手の時間も使ってはしまうものの、Slackで素朴に聞いてみると、どこの組織でも人/情報をつないでくれるコネクターが存在するもので、そういった存在は非常に貴重です。 また、Slackやチームのミーティング、1on1してもHRTフルに迎えてくれたことが入社後の心理的安全性の確保に非常に寄与したように思います。 ローカル開発環境の構築【1への対策】 EMなので、まずはエンジニアリングを経験してみたいというのは自然なことですね。実際Github権限を得てcloneし、READMEに従って構築してみる・・とやってみることで、今後入社してくる仲間と同じオンボーディング体験をしてみました。どこの会社でもそうですが、独特のクセのようなものが存在しているが、後から入ったものにしか実感できない課題も散見され、カイゼンポイントが多数見つかるとともに理解が深まりました。 ドキュメント /コミュニケーション探索【1,2,3への対策】 弊社での探索対象はドキュメントはesaやgoogle docs、コミュニケーションはSlack、スケジュール管理はGoogle Calendarでした。 esaについては、オンボーディング用のエントリや同僚の自己紹介エントリから始めて、情報を効率よく得ることができます。ただし、重複して書かれていたり鮮度が落ちていたりというどこの会社でも起きる課題も正直あります。ここは読みながら必要に応じて適宜修正していくというのが基本ですね。(それが難しいわけですが) Slackはリモートワーク中心になった今、EMとしては情報の宝庫です。特定の人物についての「 from: @emfurupon777 」のような検索を起点にすることで、誰も資料をまとめていなくても、誰かに聞かなくても、入社のタイミングや、やってきたこと、場合によってはキャラクターの片鱗まで掴むことができる場合があります。今回もSlackリサーチは参考にさせていただきました。 Google Calendarは特に決定権者の予定をみると将来という、時間軸で少し先の見通しに関して得られるものがあります。個人的にはこれを徹底的にやる人と一切気にしない人とはっきり分かれる印象を持っていますが、ハックしていくと非公開設定だけどあの人とあの人が同じ時間を共有してるっぽいからあの手の話題をここで話してるな・・なんてことが推測できたりします。 グループミーティングへの参加【不安要素1,2,3への対策】 各チームのデイリースクラムを中心に週替わりで参加させていただきました。正直、どこのチームから参加すべきかどのミーティングから参加すべきか・・というのが悩ましいところなのですが、今回キッカケをEMの岩田が作ってくれたためスムーズに開始することができました。 1on1【不安要素1,2,3への対策】 グループミーティング行脚を手がかりにして各エンジニアのみなさんとご挨拶を兼ねた1on1を行っていきました。業務の内容に終始して終わることもあれば、プライベートに近いようなところがメインになることもある・・という感じではありますが、それぞれの人となりを知ってみるというユルいところと、もし相談に乗れることがあればその場で乗ってしまうというスピードをあまりかたく考えずに実施してみるのが重要かなと思って望みました。ただ、完全に行き当たりばったりではなく、前述のSlackサーチを可能な限り行っておくようなことも非常に役に立ちました。 プレイヤーとして振る舞えるポイントを見つけてやってみる【4への対策】 ここは好みの分かれるところです。所属チームが明確なICであれば、そのチームの納期に余裕があり、適度な粒度なタスクを拾ってPullRequest・・といきたいところで、EMでもこういう選択をする方が多いように思いますが、私個人としてはもう少し広く組織に貢献できる可能性を狙って、通常業務を改善できないか探るようにしています。 前職では勤怠のSlack打刻(人事側と調整が必要で意外と手間がかかる)導入をしたのですが、弊社では用語集の改善を選択しました。スプレッドシートで管理されているものがいくつか見つかったのと、ちょうどタイミングよく元同僚の @KawamataRyo が用語集ツールを公開していたので使わせていただくことにしました。 Firebase + Bolt.js + Spreadsheet で社内用語辞典をいい感じに使えるSlack Botを作ってみた。楽しい。 Fuse.js 使ってあいまい検索にも対応しているのがポイント。 https://t.co/CrSoZusQav pic.twitter.com/slDVIXaLdC — Kawamata Ryo (@KawamataRyo) 2022年1月11日 実は、弊社ではAWSを使うことが多いですし、GoogeDriveの外部共有も限定されているのですが、今回Firebase/GCPからSpreadSheetをデータストアとして使う構成というイレギュラーな協力依頼もSRE、情シスの協力をスムーズに得ることができ、今後も業務改善が行えそう・・と実感できました。 他にも勝手にReacji Channelerで情報を集めることなどをトライしています。EMとしてはコミュニケーションの場であるSlackは活用を考えてみる良いフィールドになると考えています。 組織開発アプローチ【4,5への対策】 1,2,3への対策で行ってきたことを総合して、組織開発アプローチで行えることを考え実施します。 AさんとBさんが話せる場を持てるようにファシリテーションを行う 普段話をしているマネージメント層にフィードバックを行う(ご本人としても伝えて良いことに限る) 人材開発アプローチ これは、今回まだ課題の解決としては行っていません。それぞれの関係性の中で学習機会を得たり、輪読会・勉強会などが行われているのを観測しているため、そこにあえて私が追加で働きかけるまで具体的なものを得られていないためです。 Slackで簡単に書籍購入をリクエストできたりするのがうまくワークしているのかもしれません。 tech.bm-sms.co.jp まとめ 取り止めもなく取りうる手段と私の経験をあげてきましたが、ICと比較して特徴的になる傾向にあるのは組織開発アプローチかもしれません。 天才的に強いエンジニアがいるんだからマネージャーはいらないのでは？という有名なGoogleのProject Oxygenの結論を地でいくようなことを考えている希少種がEMだと思っています。(個人的には、感覚的にも経験的にもEMよりはテックリードと呼ばれたいエンジニアが多いように感じています) この記事を通してEMが入社する際の参考になったり、EMがどんなことを考えて参加してきているか、をご理解いただくのに資すれば幸いです。 なお、弊社でもEMを積極採用中です。まだ大きくなり切ってはいないが組織開発が不要なほど小さくはない。というフェーズこそ組織開発経験にもってこいなので、興味がある方はぜひカジュアル面談からお話しさせてください。 また、今回はあえて触れていませんが、EMの大きな役割として採用があります。 エンジニア経歴をお持ちでキャリアの一環としてエンジニア採用を一緒にやってくれる方 あるいは採用人事でエンジニア採用に深くコミットしていきたい方 も募集していますのでこちらも気軽にご連絡いただければ幸いです！

はじめに エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」の開発をしている @koma_koma_d です。エンジニアとしての職務の傍らで、このテックブログの編集チームメンバーを務めてきました（「編集チーム」が何かについては後述します）。 当ブログは、2021年3月に開始し、この3月でちょうど1年になりました。この1年間のブログ運営では、うまくいったこともありましたし、うまくいかなかったこともたくさんありました。今回の記事では、この1年間をふりかえることで、 「企業のテックブログに携わる人たちに役立つ情報を提供する」 ことができればと思います。 ブログの始まりと編集チームについて 編集チーム発足まで テックブログを開設しようという考えは、実際に始動されるだいぶ前からあり、マネージャーなどが中心となり準備を進めていました。企画の検討や、ブログとは別にある 採用スライド資料 の作成などはこの段階からされていました。 しかし、マネージャー陣だけではブログの持続的な運営は困難ということで、2021年1月に私を含む3名に声がかかり、「編集チーム」が組成されることになりました。このチームの主な役割は、ブログの記事制作を担うことです。ブログを始めるのは簡単ですが、継続するのは困難です。記事を執筆してくれる人を探し、執筆が始まった記事を公開まで導くというのは、労力を必要とすることだからです。記事を一定以上のペースで公開していくためには、記事のデリバリーに責任をもつチームが必要だと考え、編集チームが発足しました。 編集チームの発足とブログの始動 編集チームのメンバーは、それまでに進行していたコンテンツ案のそれぞれを「担当編集」として引き継ぎ、執筆担当者の書いた原稿のレビューやスケジュール管理、実際のブログ公開作業などを担うようになりました。 そうして、いよいよ2021年3月にブログが始動しました。最初に公開したのは、Ruby コミュニティなどでも活動してきた技術責任者の @sunaot の記事2本で、幸いなことに、いずれの記事も広く読んでもらうことができました。 tech.bm-sms.co.jp tech.bm-sms.co.jp 始動してから取り組んだこと・工夫したこと さて、以上のようにスタートしたこのブログですが、ブログを始動させるタイミングでは、記事自体をデリバリーすることを優先して、コンテンツ以外の部分（デザインや運営の仕組み）は作り込まずに始めました。ここからは、始動してから取り組んだことや、始めた工夫について紹介します。 ブログデザインを刷新する ブログのデザインは、始動から少し経った5月に、社内のデザインチームに作ってもらったものに切り替えました。始動の前には既に「デザインどうする？」という話は出ていたのですが、「まずはブログとしては始めてしまおう」ということで、このタイミングでの刷新になりました。 「エス・エム・エスって見たこと/聞いたことある会社だな」と思ってもらえるようにしたいというのが目的のひとつなので、早い時期にデザインをコーポレートカラーに合わせたものに変更したのは良かったと思っています。ただ、アイキャッチ画像との平仄が合っていないという問題がつい最近まで存在していたので、もっと早く変更できていればという思いはあります。 定期的なふりかえりを実施する デザイン刷新と同じころに、月次での「ふりかえり」も始めました。 開始当初は Google Analytics を入れるだけ入れていたという程度で、とにかく記事をリリースしていくということに専念していたのですが、軌道に乗ってきたため、試行錯誤ができるように月次でふりかえりをチームで行うことにしました。 このふりかえりでは、記事のデリバリープロセス全体についての改善を模索するのですが、その一環として、前月に公開した記事を中心に、 Google Analytics などでさまざまなメトリクスを確認しています。記事はそれぞれがユニークなので、どのような記事（内容だけでなくタイトル・アイキャッチなどを含めて）が読まれやすいのかなどを分析し、試行錯誤を重ねるようにしています。 例えば、以下のようなメトリクスを確認しているほか、気になる動きが Google Analytics 上で見られれば細かく「どうしてそうなっているのか」などを掘り下げたりもしています。 ブログ全体での月間ユニークユーザー数 ブログ全体での検索流入ユーザー数 記事別の訪問数 記事別の検索流入数 Search Console での特定キーワードでの順位 執筆してくれた人の労に報いる ブログの継続のためには記事を執筆する人が不可欠です。記事の執筆をお願いしてきた人たちはみなさん協力的なのですが、そうはいっても記事を書くのは大変なことです。1本の記事がそのまま何かの成果（代表的なのは採用）に結びつくことはそうそうないのですが、執筆担当者が「書いてよかった、また書いてもいいな」と思ってもらえるように配慮しています。 たとえば、記事を公開したときには、Slackのエンジニア全員のいるチャンネルで編集チームメンバーから一言添えて共有しています。RSSフィードの機能で配信する手もあるのですが、 あえて手動で投稿 しています。 執筆者と一緒に記事を作ってきた編集チームメンバーはその記事の良いところを一番よくわかっていますし、執筆中の執筆担当者の苦労も知っているので、他の人にも見えるところで執筆担当者に感謝の意を伝えるとともに、社内の多くの人にその記事の魅力を伝えるという役割も担っています。 始動後に出てきた課題とそれへの対応 ブログを始めてから出てきた課題もたくさんあります。前述のふりかえりの場や、ブログ運営用の Slack チャンネル での話を通じて、課題に対して手を打っていきました。ここでは一部ですが、取り組んで良かったと思うことを紹介します。 始動後に速やかに増員を行った 3人体制で始まった編集チームでしたが、2ヶ月くらい経ったタイミングで、「結構これは負担が大きい」という声が上がり、編集チームの人員増強を行うことになりました。 それぞれが所属チームでのエンジニアとしての仕事も抱えていたため、所属チームでの仕事がばたつくと記事のデリバリーにも影響が及んでしまうという難点もありました。 この段階で即座に @sunaot が追加で3人のエンジニアに声をかけ、6人体制になりました。6人体制になったことで、障害対応や体調不良、重要なプロジェクトなどでメンバーの一部が欠けた際にも、補い合って記事をデリバリーし続けることができましたし、一人当たりの負荷が減って続けやすくなりました。 また、人数が増えたことにより、それぞれの人が持っているスキル（Google Analytics の読み方など）や、それぞれの人の近くにいる「いい記事を書いてもらえそうな人」の情報の情報が共有されるようになったのも、ブログ運営にとっては有益でした。 マクロのメトリクス以外のフィードバックを得るようにした 前述の通り、ふりかえりの場では、Google Analytics などのメトリクスを見ています。それらのメトリクスは、「記事がどれだけ読んでもらえたか」などといったマクロの傾向を把握するのには有益なのですが、「読み手に対してどういう影響を与えたのか」などはこれだけではわかりません。 そこで、エンジニア採用担当者や面接担当者から、「ブログを読んでもらえているか」や「ブログに対してどのような声があったか」などを共有してもらうようにしています。そうしたフィードバックを得ることで、「ブログを通じてどのようなことを伝えていく必要があるのか」を考える自分たちでも気づいていなかった「エス・エム・エスの特徴」を発見することもありました。 「むきなおり」を行うようにした 前述のように、「ふりかえり」は定期的に行い、「これまでの記事・取り組みはどうだったか」「次はどういう取り組みをすればいいか」という議論は常にしていました。しかし、どうしても限られた時間の中で実施しているため、もう一段抽象的な「何を目的として、どこを目指して行動をしていくのか」というレベルの議論をする機会は作れていませんでした。 その結果、始動のタイミングでは全員で話をしてある程度は合わせていたはずのチームとしての方針に対する理解が、時間の経過とともにバラバラになってしまい、コンテンツを考える際などの議論がまとまらないという場面が出てきました。 そこで、普段のふりかえりとは別に、「 むきなおり 」の時間を設けるようにしました。その場では、「ブログでどのようなことを目指しているのか」といった全体に関わる事柄を改めて話し合います。その中で、コンテンツ作りの方針や、ブログ運営の体制など、見直していくとよさそうな点を見つけられたので、一つ一つ改善していこうとしているところです。 ブログを運営する中でわかってきたこと 最後に、ブログを運営する中でわかってきたことを紹介します。 バズる記事だけが重要ではない 上記のようにふりかえりをしながらブログを運営していく中で、公開するコンテンツの位置付けについて少しずつ自覚的になってきました。 記事のなかには、SNSで「バズる」記事もありますが、ほとんどの記事はそうではありません。しかし、バズりはしなかったけど検索流入がありつづける記事や、広く読まれるわけではないが特定の読み手に刺さる記事（スカウトを送る際などに、その人に読んでもらうと良さそうな記事を添付したりしています）にも意義があるということが見えてきました。 また、ブログ全体としての記事の積み重ねによって会社のイメージが形成されていく（「エス・エム・エスさんはこういう記事が多くて、〇〇を大切にしている会社なのだなと感じました」というフィードバックをもらうことが繰り返しありました）という側面もあるということも発見でした。 編集チームでの仕事には副産物がある 編集チームのメンバーはエンジニアリングの仕事の傍らでブログ運営の仕事をしているのですが、ブログ運営を通じて得られる副産物がありました。この種の仕事はともすると「本当はエンジニアリングにもっと時間を使いたいのに」と敬遠されがちですが、以下に書くような副産物があると、ブログ運営に関わるインセンティブにはなりそうです。 他事業・他チームのエンジニアとの関わりが得られる エス・エム・エスは、40を超えるサービスを運営しており、エンジニアは（多くがプロダクト開発部という横串組織に所属してはいるものの）普段は担当するサービスのなかで仕事をしています。Slackでの雑談・勉強会や、社内のテックトークイベントなどで関わる機会もあるのですが、ブログ編集チームメンバーを務めることでこれまでにはない他事業のエンジニアとの関わりが生まれました。 まず、 編集チームの他のエンジニア です。編集チームは、記事コンテンツ案を考える都合などもあり、様々な事業のエンジニアの混成チームとなっています。事業ごとに扱っている技術スタックもビジネスモデルも異なるので、そういったチームで一緒に仕事をしていると、新たな発見がしばしばありました。例えば、私は担当している事業が介護事業者向けのSaaSで、基本的にはログインした後の世界を主戦場としているのですが、人材紹介のサービスを担当しているエンジニアは集客の部分にも強みがあり、SEOやGoogle Analytics などの扱いに慣れているので、ブログの運営面では学ばせてもらうことが多かったです。 また、 執筆担当者のエンジニアとの関わり も貴重でした。記事の中には、執筆担当者単独で書けてしまうものもありますが、編集チームメンバーと執筆担当者が二人三脚で進めていくものも多くあります。その場合、打ち合わせや非同期でのコミュニケーションを通じてコンテンツを作っていくことになるのですが、その過程でのやりとりで（最終的な記事には表れないような）裏話や、技術の詳細について話を聞くことがしばしばありました。執筆担当者はシニアなエンジニアであることも多いので、そういった話を直にきけるのは「役得」でした。 普段のエンジニアリングとは異なる学びがある 普段主にWebサービスの開発をしている私たちですが、広報目的のブログの運営はWebサービス開発とは異なる営みです。（一部Webサービス開発の知見が流用できるところもありますが）ブログを運営していく中では今まで考えたこともなかったことを考える機会が多くありました。 たとえば、以下のような事柄が挙げられます。 企画の検討（ペルソナの設定〜コンテンツの企画） Webマーケティングの観点（Google Analytics を用いた分析など） 読んでもらえるタイトルやアイキャッチ画像の検討 会社の発信としての質の担保 これらの事柄は、それぞれに専門分野として蓄積もある領域でもあり、私たちのブログ運営のなかではごくごく初歩的なことしかできていない（あるいは初歩的なことすらできていない）とは思いますが、勉強をするきっかけを得られたのはブログの運営に携わったことの良い副産物だったと思います。 俺たちの戦いはこれからだ！ 以上、ブログ編集チームメンバーとして1年間このブログを運営してきてのふりかえりを書きました。ブログ運営は順風満帆とはいえず、まだまだ課題は多くあります。たとえば、 どうすればもっと執筆者/運営の負担を減らせるか？ どうすればもっと「意味のある」ブログになるか？ などは常に付きまとってくる課題です。これらについては、常に社内でも議論をして改善を試みてきてはいますが、抜本的な解決策には辿り着いていません。今後も試行錯誤をしながらこのブログを運営していければと思います！

はじめまして。株式会社エス・エム・エスの土屋匠です。 弊社では医療・介護・ヘルスケア・シニアライフの４つの領域で高齢社会の情報インフラを構築しており、シニアライフ事業領域では高齢社会が直面する「高齢社会の生活にまつわる困りごとの解決が困難になる」という社会課題に対し、「多様な選択肢と質の高い意思決定情報の提供」を通じて解決を目指しています。 私はこの４つの領域のうちシニアライフ領域のエンジニアとして、介護で悩む人向けコミュニティ「安心介護」とケアマネジャー向けコミュニティ「ケアマネドットコム」の２つのコミュニティサービスの開発を担当しております。２サービスとも直近ではサイトリニューアルを行い、新しいアーキテクチャのもと課題解決に取り組んでいます。 今回は私たちのチームカルチャーや開発スタイルの一部について紹介したいと思います。 小さなチームでプロダクト開発をリード シニアライフの事業領域はIRで公開されている情報にあるように、他の事業分野と比較すると売上規模が小さく加速度的な成長を目指しているフェーズの事業が数多く立ち上がる部署です。横断的な部署とプロジェクトを組み連携しながら進めることもありますが、１名で事業立ち上げのプロダクト開発をリードしたり１つの開発チームで複数のサービス開発を担います。 チームメンバーには オープンソースのコードを読み、そのプロジェクトにIssueを立てPull-Requestを投げる 海外経験あり英語ドキュメントを難なく読んでしまう 先見性を持って最新のデザインツールやフレームワークの提案や導入をする など、多種多様な視点で集まったナレッジがプロジェクトの課題解決の後押しとなっています。 私たち開発チームの技術スタックと開発で使用するツール類の一部を紹介します。 カルチャー１「成長を加速させる当事者意識」 機能開発は誰にとってどんな目的の機能を提供するのかを明確にした上で、細かい仕様や技術選定などは個人に判断を委ねています。よくトップダウン型のチームだと開発チームの技術スタックや課題解決の質がトップの能力や経験に引きずられてしまうのですが、 個々の能力が最大化された状態のチームであるためには制約は少なく、ゴールのありたい姿だけを共有するようにしています。 時には細かい仕様の落とし込みなど実装する際にチームでの議論が必要になりリリースまでのリードタイムが長くなってしまうこともありますが、話し合うことでチームの全員がその意思決定に対して腹落ちして前に進むようにしています。 その甲斐あって、私たちは当事者意識を持ち主体的に働いており、個々の能力の最大化が個人のさらなる成長にも寄与しています。 カルチャー２「心理的安全性で改善が活発化」 私たちは失敗を許容できるチームでありたいと思っています。たとえば、サービス運営をしていると多かれ少なかれ不具合が発生しますが、それは失敗してもいいということではなく同じことを繰り返さないようにその失敗から学び成長できると捉えています。 チームでは誰が言ったかは重要ではなく、正しいことを正しいと言えてその実現に向けて愚直に取り組むことを大事にしています。 開発者が自身で改善Issueを立てることがあり、そこからプロダクト改善がスタートすることもあります。これはとても良い習慣で、誰かに遠慮したりせず常に物事の対象がプロダクトに向いています。 カルチャー３「生産性が高い非同期コミュニケーション」 同期的なコミュニケーションはZoomまたはGoogle Meetで２週間に１度の定例ミーティングで行っています。これは全員が持ち回りで前後２週間のタスクを共有します。この定例ではプランニングも兼ねているので、緊急度・重要度の判断軸に当てはめて事業戦略とすり合わせながら開発タスクを決めています。 それ以外のコミュニケーションは非同期で取ることがほとんどです。通常は同期的なコミュニケーションの比重が高いほうが一般的かもしれませんが、私たちのチームは非同期コミュニケーションの比重が高いのが特徴です。非同期コミュニケーションはSlackやGitHub上で全員が目にできる場所でオープンにしようと心掛けています。 課題共有や解決のアプローチなどはすべてGitHub Issue/Pull-Request/Wikiに残します。それをドキュメントと呼ぶには程遠いですが、思考や作業のプロセスを時系列にトレースして振り返ることができるようになっています。 プロダクトの開発フェーズ ２サービスとも直近のリニューアルでペルソナやユーザーストーリーからコア機能の再定義を行いました。現在は一定のアーリーアダプターが付いており、ユーザー自身の課題を解決するためにプロダクトを利用してもらっています。 そのようなフェーズですので、あらためてユーザーからのフィードバックを得て改善を進めており、プロダクトの細部に至るまで使い勝手を改善することや機能仕様を見直すことが第一に求められます。 もちろん必要があれば新機能の開発なども進めますし、定期的にビジネス側とKPIのすり合わせを行い、日々のプロダクトの利用状況を可視化することも大事な開発タスクとして取り組んでいます。 施策立案からリリース後の検証 まずはユーザーの声に耳を傾け、定量的なデータの分析を行い、ユーザーの課題を洗い出します。洗い出した課題に対してビジネス上のインパクトや課題の重要度・緊急度を鑑みて優先度付けをした上で高いものから順に仮説を検証していきます。もちろん解決策が疑う余地もなく有効である場合にはそのまま機能を作り込みにいくこともありますし、逆に解決策を作り込んで提供するにはリスクが高い場合には人手のオペレーションで試してみたり外部ソフトウェアなどのツールを利用して検証します。 プロダクトのフェーズからも分かる通り、改善スピードをあげて対応していくことが重要なのでリリースのタイミングは基本的にコードレビューと検証環境で動作確認が通ったら順次リリースしていきます。これは実装コードと対になるユニットテストやインテグレーションテストが通っていることが前提です。もちろんユーザーやビジネス上のクライアントへの影響がある場合には事前のアナウンスや日程の取り決めを行いリリースします。 リリース後の検証も定量的なデータを分析して評価します。日常的にモバイルやPCからサイトにアクセスして使われるコミュニティサービスという特性上、ある程度の母数のあるユーザーにすぐ届くので、ユーザーの反響が定量的なデータに反映されやすく、事業の手触り感を得やすいのも特徴の１つです。 開発者体験（DX：Developer eXperience）の向上 新しいアーキテクチャでの開発をスタートして以降、開発者体験の向上にも力を入れています。たとえば、言語・フレームワーク・ミドルウェア・ライブラリのバージョン管理を導入していますが、単に脆弱性に対するセキュリティアップデートだけの用途ではなく、開発者が生産性が高く気持ちよく開発することができる環境をつくるためでもあります。 具体的にはDependabotで依存ライブラリのバージョンアップを毎日行っています。Breaking Changesを含むメジャーバージョンへのアップグレードも発生しますが、利用の技術スタックの最新動向を知る機会と捉えて積極的に対応しています。 直近だと Ruby / Rails / Vue.js へのアップグレードを終わらせ、今後は AWS CDK のアップグレード対応を視野に入れています。そしてこれらの保守対応は事業施策と同じテーブルにあげて優先度付けされ対応していくので、プロジェクトで利用する技術スタックは比較的最新のバージョンに保たれています。 さいごに 私たちは小さなチームですが、その分フットワーク軽く自律的な行動ができるひとが集まっています。今後もシニアライフには様々なアーリーフェーズの事業が立ち上がることから、技術を武器に社会課題の解決に貢献したい仲間を求めています。 事業の初期段階からプロダクト開発をリードしたいひとがいましたら、一緒にワクワクするようなプロダクトをつくりにいきましょう。

はじめに はじめまして。ヘルスケア事業部にて開発を担当している今村と申します。 私は、金融系のSIerからエス・エム・エスに転職し、介護職向け求人情報サービス「カイゴジョブ」、看護師向け求人情報サービス「ナース専科求人ナビ」、管理栄養士・栄養士向けコミュニティ「エイチエ」、遠隔指導特定保健指導サービス「遠隔チャット指導」などの事業を担当してきました。転職して10年以上経過していますから、この会社ではかなりの古株ということになります。 エス・エム・エスでは様々な事業を展開しているため、その事業のフェーズやとりまく環境に応じてとりうる戦略が違っていて、必ずしもプロダクトの価値だけが事業の成功要因ではないこともあります。具体的には、プロダクトは競合と横並びだけど、オペレーションによって競合より優位性を獲得するようなケースです。 例えば弊社が事業の柱の1つにすえている医療介護向けのキャリア事業では、プロダクト = 人材紹介の登録サイトですが、そこで担っているのは主に集客です。しかし、人材紹介の売上は「紹介手数料」をもらうことで成り立っているため、集客したユーザーのニーズを汲み取って適切な転職先をご提案する「後工程」も集客と同じかそれ以上に重要となります。特に医療分野は、どの企業も集客には力を入れています。その場合、プロダクトによる差別化の余地は少なくなるので、オペレーションによって求職者と顧客の双方がハッピーになるようマッチングしていくことが成功の鍵となります。 このため、エス・エム・エスのエンジニアは、プロダクトの改善に関わるのみならずオペレーションの改善に関与する機会も多くなります。そして私の経験上、オペレーションの改善には、技術力より要件定義や業務分析力に強みを持っている方のほうが、力を発揮しやすいと考えるようになりました。 今回はその点について掘り下げてお話したいと思います。 事業の成長とともに起こったこと どのような事業でも、事業開始当初の段階でオペレーションが固まっていて、成長の段階に達しても同じオペレーションを維持していられることはまず無いと思います。 実際に事業を始めてから見えてくることが多いというのもあるし、そのオペレーションを行う人材を事業成長のスピードにあわせて増員することが難しく、その代わりとしてオペレーションの効率化が求められるからというのもあるでしょう。そういった諸般の事情により、オペレーションは常に流動的かつ改善が求められ続けるものと言って良いと思います。 弊社においては、私が入社した当初この改善はプロダクトの中に作られた管理システム、あるいはExcel上で行われていました。管理システムについては、プロダクト開発の合間に浮いた工数でエンジニアが改善したり、ExcelについてはVBAや関数に秀でた現場の担当者が居て、その人が中心となって改善が行われていました。 しかし、そういったアプローチによるオペレーション改善は、事業の変化についていけたとはお世辞にも言えないものでした。 管理システムについては、改善の優先度がプロダクトの改善より低いことが常でしたし、Excelに関しては担当者のスキル依存であり、仮に素晴らしいものが出来上がったとしても、次の担当者に同様のスキルが無ければメンテできなかったからです。一部は、VBAのスキルをたまたま備えていたプロダクト開発のエンジニアが巻き取ったなんてこともあったほどです。 SaaSを使ったオペレーションのはじまり 弊社では、期初に事業部ごとの「戦略」を作りグループへの浸透を図ります。その際にもオペレーションの高度化や効率化は必要と謳われていました。 そのような背景があり、弊社では徐々にExcel運用や管理システムを捨てて、SalesforceやkintoneなどのSaaSを使うようになっていきました。その結果、導入当初は現場の改善が進んで盛り上がることになりました。 しかし数年経つと、上記のSaaSの活用もシステムの様々な制約に直面するようになり、停滞したりトラブルを抱えるようになってきました。アプリケーションが乱立し、データ間の依存関係もよく分からず、さらに1アプリにフィールドを詰め込みすぎてシステムが定めていた上限に達しそうなものさえあったと聞いています。 今でこそローコードやノーコードと言ったキーワードとともに「エンジニア要らずのDX改善」などともてはやされているSalesforceやkintoneですが、いずれも提供してくれるのは「コードを書かなくて良い環境」のみです。しかし考えてみると、開発において「コードを書く」フェーズは全体のプロセスの中のごく僅かに過ぎません。その手前の、要件を洗い出して設計に落とし込むという作業は残り続けます。それをエンジニア抜きで進めていたわけですから、やはりどこかで限界が来るのは必然と言えるしょう。 こうした反省もあって、エス・エム・エスではSalesforceやkintoneを使ったオペレーションにおいても、エンジニアが参画するようになりました。まだまだ事業によって濃淡はあるものの、弊社のオペレーションの改善においては、エンジニアも一丸となって改善に取り組むのが当たり前となりつつあります。 エンジニアとオペレーション改善 私が所属するヘルスケア事業部でも、事業のスタートこそExcel運用が多かったものの、徐々にkintoneへの移行を進めています。kintoneのアプリを作成する際には、エンジニアが必ず要求を出す段階から関与し、kintoneを含んだ業務フロー全体の流れも把握し、他のアプリやデータと整合するようコントロールしています。実はkintoneの導入が決まった当初は、エンジニア抜きで利用を進めるという案もあったのですが、他の事業での失敗の経緯を説明してエンジニアも参画することになったのです。 kintoneを担当するようになってからは、長期的な視点でのデータの設計、安全なアプリケーションの連携方法の模索、kintoneの標準機能で賄えない部分を内製するかサードパーティのプラグインで対応するかの検討など、考えることが多岐にわたると実感できるようになり、もしエンジニア無しにスタートしていたら1、2年という早いスパンで業務が破綻していただろうと思うようになりました。 ただこういった業務は、プロダクトの開発と比べるとなかなか地味です。どちらかというと、要件のヒアリングや設計に重きを置くからです。自分で手を動かしてコードを書くことが必ずしも正解ではなく、場合によっては「作らない」という判断こそが求められます。 一方、不特定多数のユーザーがターゲットとなるプロダクトと違い、価値の提供先は社内になるわけですから、より具体的な課題を聞くことができます。このため要件定義や業務分析をうまく行い、kintone上でオペレーション改善につながる仕組みを提供すれば、それだけで業績に大きく跳ね返ることもあります。 一例を挙げますと、とある架電にまつわるオプションサービスの運用業務を、Excelからkintoneに移行する小さなプロジェクトが事業に大きく貢献したことがあります。 私が担当したそのプロジェクトは、単に移行するだけでなくオペレーションも効率化したいという要望がありました。そこで細かく要件のヒアリングを行い、誤入力や入力漏れが無いよう制御し、状態管理もひと目で行えるよう作り込んだうえでkintoneアプリケーションを提供しました。結果、そのオプション商品による架電効率が向上してKGIが大きく伸び、オプションサービスの販売数増に繋がりました。しかもこのオプションサービスは、メインのサービスの重要指標を改善するためのものであったことから、メインのサービスの契約継続や受注にも良い影響を及ぼしたのです。 これは特に効果が高かった事例ですが、他にも日々このようにオペレーションの改善に関与し続けていると、少人数の組織体制でも多くの業務を捌けるようになる利点もあります。その結果として、受注が増えても業務のキャパシティが溢れてしまうリスクを減らせるので、安心して事業を伸ばしていけるという側面もあるだろうと考えています。 多様な事業、多様なエンジニアニーズ 昨今、事業会社のエンジニアに求められるスキルといえば、特定のプログラミング言語やフレームワークをうまく扱うためのものだったり、AWSなどのインフラを柔軟かつ安全に構築するためのものだったり、技術力に重きを置いていることが多いと感じます。それはおそらくプロダクトの改善こそが、その事業の成長にとって不可欠だからでしょう。「プログラミングのスキルを身に着けて、SIerから事業会社に転職しました」というような話も聞きます。 しかし弊社のように、多くの事業を抱え、事業フェーズやとりまく環境がそれぞれ異なる状況においては、プロダクトの開発に力を発揮するエンジニアだけではその成長を支えられないこともあります。 すでに述べた通り、必ずしもプロダクトの優位性だけが事業の競争力の源泉とは言えないからです。 そのため、SIerで培った経験や能力を存分に発揮しつつこれから技術力を高めていきたいエンジニアや、技術力の向上よりも事業の成長に貢献することに関心のあるエンジニアなど、様々なバックグラウンドを抱えている方々に活躍する場を提供できるのが弊社の強みではないかと考えています。 もし事業会社のエンジニアとしてのキャリアに関心があれば、現時点でのスキルの過不足は考えずに、一度弊社のカジュアル面談をご検討いただければと思います。あなたの今のスキルや経験を必要としている事業が、見つかるかもしれません。

介護事業者向け経営支援サービス「カイポケ」の開発をしている @koma_koma_d です。 エス・エム・エスには、エンジニアの学習を支援する制度がさまざま存在しています。そのうち、AmazonのURLをSlackで伝えるだけで即日注文、数日で自宅に技術書を届けてもらえる制度については、以前の記事でご紹介しました。 tech.bm-sms.co.jp 上記の制度とは別に、 「オライリーのサブスクリプションサービスを使わせてもらえる制度」 があります（2022年3月現在）。今回は、このオライリーのサブスクリプションサービスをどのように活用しているのかを社内のエンジニアに聞いてみました。 オライリーのサブスクリプションとは？ オライリーのサブスクリプションは、正式には「O'Reilly Online Learning」といい、技術出版社の O'Reilly が運営しているサブスクリプションサービスです。普通に契約をすると年間499ドル 、（一部機能制限付ですが） ACMの会員になることで年間99ドル （2022年4月追記：ACM会員のこの特典は2022年6月末で廃止されるようです） で利用することができます。 www.oreilly.com このサービスでは、膨大な種類の技術書や講義動画、オーディオブックなどが読み放題/見放題になります。読むことのできる技術書には、オライリーから出版された書籍はもちろん、Addison-Wesleyなど他の出版社の書籍も含まれています。Webブラウザで閲覧する以外に、iOS/Androidのアプリで閲覧することができます（アプリにデータをダウンロードしておいて、オフライン状態で閲覧することもできます）。 リソースのほとんどは英語ですが、2020年11月ごろに 日本語書籍が一部追加 されて話題になりました。2022年3月現在では、102冊の日本語書籍を読むことができます。 オライリーサブスクリプションに、日本語書籍が！！！ タイトル検索も出版社検索もヒットしないので、ラインナップは今のところ不明だけれど、これはもうみんな課金するしかないのでは…? pic.twitter.com/IAZJDXcaPQ — kawasima (@kawasima) 2020年11月16日 どんなふうに活用しているか聞いてみた！ 今回、実際にこの O'Reilly Online Learning（以下オライリーサブスク）を利用しているエンジニアに、活用方法を聞いてみました。 関心のある技術やテーマを概観する or 拾い読みする 多かった回答は、 「新しい技術を勉強するときに、まずオライリーサブスクで検索して何冊かをざっと見てみる」 というものでした。オライリーサブスクでは（Early Release版を含め）新旧の書籍を読むことができます。書籍購入制度を活用することもできるのですが、技術調査段階だとスピーディにさまざまな本を見たいということがあるので、検索してすぐに&追加のお金をかけずに読むことのできるオライリーサブスクが便利だということでした。最近では、GraphQLやマイクロサービス関係の本をこれで読んでいるメンバーがいました。 learning.oreilly.com また、たくさんの書籍を読むことができるので、 関心のあるテーマについて複数の書籍の関連する章だけを拾い読みする ような読み方をしている人もいました。最近だと、EventStorming を実践しているチームがあるのですが、ドメイン駆動設計関係の書籍のEventStorming について言及している章を（後述する全文検索も活用しながら）探してきて、理解を深めるというような使い方です。 learning.oreilly.com 全文検索が便利！ 他には、全文検索を活用しているという声もありました。オライリーサブスクは サイト内全文検索にも対応 しているので、仕事をしていて出会うエラーメッセージやオプション名などをそのまま検索すると、関連する書籍がヒットすることがあります。もちろん公式ドキュメントを確認するのが最も確実ではあるのですが、公式ドキュメントでは簡単にしか書いていない事柄について書籍だとより詳しい説明がある場合も多いため、便利です。 翻訳書を読むときのお供にも また、これは私個人の話ですが、翻訳のある書籍を読んでいると、「ちょっと意味が取りづらいな？」と思う箇所に時折出会います。そういうときに、オライリーのサブスクで原書の該当箇所を確認するというのは結構な頻度でやっています。この1年ほど、社内で『プロダクトマネジメント』（原題は『Escaping the Build Trap』）や『エリック・エヴァンスのドメイン駆動設計』の読書会を実施しているのですが、いずれの書籍も原書がオライリーサブスクで読めるので、「ここってどういう意味なんでしょう？」「原文だとこうなってますねー」というやりとりをすることがありました。『プロダクトマネジメント』読書会をしているときには、翻訳で違和感のあるところを見つけて、訳者の吉羽さんにフィードバックを送るという場面もありました（ すぐ確認していただけて、正誤表に反映していただけました ）。 learning.oreilly.com 機械翻訳サービスと組み合わせると便利！ また、最近はGoogle翻訳やDeepLを使うことで、英語が苦手な人でも「オライリーのサブスクでざっと読む」が簡単にできるようになっています。オライリーのサブスクはWebブラウザで読めるものなので、たとえば Google ChromeのGoogle翻訳の機能を使うとシームレスに（わざわざコピペや範囲選択をせずに）翻訳をかけて読むことができます 。私個人も英語はどうしても読むスピードが格段に落ちてしまうので、「精度はともかくどんなことが書いてあるのかをさっと知りたい」というときには機械翻訳をオンにした状態で読んでいます。 おわりに 社内では、それなりの人数のエンジニアがサブスクのライセンスを持っているので、「オライリーのサブスクにあるこの本が良いよ」とか「オライリーのサブスクのこの本にはこう書いてあるよ」というやりとりがなされています。私個人は元々そんなに英語の技術書までキャッチアップしていなかったのですが、オライリーのサブスクを使うようになり、また同僚と同じものが常に参照できる状態で仕事をする中で英語の技術書が身近な存在になってきました。 英語の本を読んだらすぐ仕事ができるようになるかというとそんなことはないわけですが、日本語だけで得られるよりは格段に幅の広い情報に接することができ、中でもオライリーのサブスクは質・量ともに非常に充実しているので、一度使い始めるとやめられないサービスです。みなさんもぜひ契約してみてください&他に便利な使い方を知っていたら教えてください！

2021年10月にエス・エム・エスに、介護事業者向け経営支援サービス「カイポケ」のQAエンジニアとして入社した中村です。前職は第三者検証会社に勤めており、約15年ほどソフトウェアのQA業務に携わり、テスト設計/実施から始まり、テスト計画書/テスト報告書の作成やテストチームの管理など管理業務を経て、最近では、品質管理/分析、改善活動、テスト自動化といった業務を主に担当してきました。色々な現場を転々としてきましたがずっと一社で勤めてきたので、今回が初めての転職 🔰 となります。 本記事はQAエンジニアや品質に関心のあるエンジニアの方をターゲットと想定していますが、それ以外の方もエス・エム・エスにはこんなQA組織があるんだと、1つでも参考になる情報をお届けできれば幸いです。 転職の経緯 私が転職を考えた理由はシンプルで、色々な現場を転々として様々な製品や人たちに関わってきたことで、自身も事業を持つ会社に所属して腰を据えてより製品に向き合いたい・責任を持って製品に関わりたい、という思いが強くなったことにあります。転職先をエス・エム・エスに決めた理由はいくつかあるのですが、大きくは以下の3つとなります。 1. 今後の企業成長性が高く組織と共に自身も成長出来る環境にあること こちらの入社エントリー記事でも紹介されていますが、「市場/事業が伸びている」という点は私も重要な判断基準としています。 tech.bm-sms.co.jp 今後も成長していく企業に貢献していくことが自分自身の成長やモチベーションにつながると考えているからです。正直、入社前の介護業界知識は０に等しく、介護は大変そうという漠然としたイメージしか持っていなかったのですが、少子高齢化の社会で人材不足と財政難という非常に難解な課題があることは転職活動を通じて知ることが出来ました。そのような社会的な課題の解決に微力ながら貢献出来るということはやはり大きなやりがいになると感じています。 2. 職場環境が良好で働きやすい環境にあること 私が働く上で特に重視しているのが、人間関係やチャレンジし易い環境にあるかといった点になりますが、カジュアル面談や選考工程を通じて会社や人の雰囲気が合っているという感触を得ていました。詳細は「入社して感じたこと」に記載していますが、その判断に間違いは無かったと感じています。 3. QAとして経験してきた自身のキャリアが活かせる職場であること 改善活動・テスト自動化の導入など自分が経験しモチベーションを持っている業務が会社の求めていた部分とマッチしていました。後述する「取り組み事例」に進行中の施策を紹介していますが、早速その辺りを担当させてもらっています。 入社して感じたこと 気軽にコミュニケーションが取れる 現在はリモートワーク環境下ですが、コミュニケーションは非常に取りやすいです。定期的なミーティングも開催されていますし、ビデオ通話などで気軽にコミュニケーションが取りやすくなっていることも良いポイントだと思います。また、厳格な上下関係というものも無く意見を言いやすい環境にあると思います。 高い品質意識 品質を高める・より良い製品を作る・顧客に使ってもらう、といった意識の高いメンバーが集まっています。 開発やテストの規模を考えるとテスト期間中に検出される不具合の数が非常に少ないと感じました。業界知識や製品知識（古くからあるサービスですが、その当時のことを知る人がほぼいないという状況）が充分とは言えない中でもこうした成果が出ている点を見ると、いかに慎重&正確に企画、開発、テストがされているかが分かると思います。 また、エンジニアで介護業界を経験している方はあまりいないのですが、勉強会が各所で開催されているなど、ドメイン知識の習得はもちろん、顧客が何に困っているのか？どうすれば使いやすくなるか？といった情報のキャッチアップなど経験不足を補うための取り組みが活発に行われています。 チャレンジし易い 上長の理解もあり、方向性が合っていれば細かい部分のやり方や意思決定は裁量を持ってやらせてもらえること、短期の成果で見るのではなくゴールに進んでいることが分かれば失敗したり遠回りしても評価されることが、チャレンジのしやすさを感じる大きな要因になっていると思います。ただ、チャレンジへの制限はないので手を出す範囲を広げすぎるとパンクする危険性もあるので注意が必要ですが、上手くバランスが取れれば自身の成長にもつながる非常に良い環境だと思います。 オンボーディング 入社後の研修は充実しており、全体的な研修として会社の経営理念やルール、介護業界やカイポケの説明を受けられるので介護業界の知見が無くても大丈夫です。その後は各部門に移動してより詳細の説明や研修を受けることになるのですが、私が配属したQAチームでは、まずは製品を理解することを目的に操作マニュアルに沿ってカイポケを一通り触るところから始まります。その間のフォロー体制も充実しており、気になったことや不明点はすぐに確認出来る環境にありますし、定期的に1on1が開催されるので現場には馴染みやすいと思います。 QAチームについて ここからは入社してから私が取り組んでいる事例を簡単に紹介していきますが、その前に所属しているQAチームのことを簡単にご紹介しておきます。下記図の通り、QAチームは横断的な組織として存在しており、小チームを形成して各サービスチームに参加しています。 QAチームとしての役割は様々ですが、主に下記の作業を担当しています。 テスト前：仕様レビュー、テスト計画作成、テスト設計、テスト実装 テスト中：テスト実施、不具合報告、改修確認 テスト後：テスト結果報告、リリースサポート、市場障害対応サポート 取り組み事例①：開発/QAプロセスの整備 開発/QAチームでのコミュニケーションも適宜取れており、関係性も問題は無いように見えたのですが、関係者から話を聞いてキャッチアップしていくうちに下記のような漠然とした課題感が見えてきました。 作業の透明性を高める必要がある 上流フェーズでのコミュニケーション頻度が少ない リリース内容ごとに柔軟性が求められるため、プロセスを統一することが難しいという側面もあるのですが、まずは現状のプロセスを整理/可視化しつつ具体的にどんな課題があるかを明確にしようと考え、プロセス図を作成しました。 ※本取り組みは、以前 別の記事 でも紹介した「検証業務プロセスのフロー」をより具体的にして、更に開発側のプロセスや共通で実施するプロセスも記載した形になります。 以下は作成したプロセス図の一部ですが、下記の課題感が明確に出来ました。 テスト計画やテスト報告の共有に改善の余地がある 定期的な振り返りが合同で出来ておらず、お互いの課題感を共有するタイミングが取れていない 企画/仕様作成の段階でQAのアプローチが強化出来そう 今後は上記課題への対応はもちろんですが、最終的な目的はプロセスを作ってそれを守ることではなく、上流フェーズから品質・仕様・テストについてのコミュニケーションがもっと活発になる、改善点や課題に対しお互いの意見が言いやすくなるなど開発/QAの関係性がもっと強化される、ことにあると考えています。これらが仕組みとしてチームに定着するよう引き続き取り組んでいきます。 取り組み事例②：E2Eテスト自動化導入 ノーコードの自動テストツールが導入されたばかりで、調査や情報交換も活発に行われていましたが、時間的な余裕が無い&導入のノウハウが無いといった課題もあり、あまり進められていない状態でした。そのため推進やサポートが必要と判断しテスト自動化に関わっていくことにしました。 事前に何人かの方とお話しをしたのですが、E2E自動テスト実行やテスト実装には関わったことあるけど導入には関わったことがないというメンバーが多く、最低限知っておくべき知識のインプットは必要だと感じたので、まずは下記資料を参考にナレッジ資料（記載内容：メリット/デメリット・向き/不向き・導入フロー・活用事例など）を作成し勉強会を実施しました。 テスト自動化の8原則 （文献） システムテスト自動化 標準ガイド （文献） 初めての自動テスト Webシステムのための自動テスト基礎 詳細は割愛しますが、その後は所属サービスチームでのテスト自動化を推進すべく下記の流れで進めています。 計画策定 何を目的とするかによって対象や優先度は変わってくるのでまずはそこを明確に 目的を決める 自動化の対象を決める 優先度を決める 期日目標を設定しないとだらだらと進まなくなってしまうことも懸念されるので マイルストーンを決める 設計 テスト実装/メンテナンスをしやすくする 変数化/共通化 テストケースを他から独立させる 前処理/後処理 テストの質を人に依存しないよう一定に保つ Assert（どのタイミングで何をテストをするか） テスト実装（&テスト） 手戻りのリスクが大きいので徐々に精度を上げて作り込んでいくため 優先度が高いものから小さくスタート 現在はテスト実装まで進んでおり、ようやく形になってきています。ただ、今後の運用/保守を考えると、属人化への対策とテスト実行/結果確認を簡単に出来る仕組みの構築が課題としてあります。まだまだやることは盛りだくさんですが、弊社内でリグレッションテストの需要は今後確実に高まっていきますし、高速でテストを回す上で自動テストは必要不可欠ですので、重点的に取り組んで行く必要があると考えています。 最後に 以上、QAエンジニア目線での入社エントリを執筆させて頂きましたが、少しでも会社やQAチームの雰囲気・作業内容をお伝えできたでしょうか？しつこいようですが間違いなく言えることは、コミュニケーションが取りやすい、やりたいことにチャレンジしやすい、やりがいを持って仕事が出来る環境であるということです。 最後に「やっていきたいこと」として大きく2つの施策を紹介しましたが、不具合分析導入、ユーザビリティテスト強化、脆弱性テスト強化、市場障害の撲滅、などなど他にも考えなければいけないことはたくさんありますし、今後はQAの活動範囲もどんどん広がっていくことが予想されています。ですが、QAエンジニアの数はまだまだ足りておらず、一緒に働く仲間を絶賛募集中です！少しでも興味を持たれた方がいたらカジュアル面談へのご応募を宜しくお願い致します！！ tech.bm-sms.co.jp

これを書いているのはだれ？ 2012年から社会人になって、今年で34才になりました、空中清高です。Twitter とかではsoranakkってIDでやっています。前職の同僚からこんな 画像 を作ってもらったりしてる感じの人です。 なにをやってきたの？ Webフロントエンドエンジニア→Webサーバーサイドエンジニア→Androidアプリケーションエンジニアという経緯でソフトウェアエンジニアをやってきました。Androidアプリケーションエンジニアになってから、かれこれ8年以上経過していて、ソフトウェアエンジニアとしての経歴の大半がAndroidアプリケーションエンジニアです。 直近では株式会社Mobility Technologiesでタクシー配車のGOアプリのAndroidアプリケーションを開発していました。と言っても、開発していたのは一般に使われているGooglePlayにリリースされているGOアプリではなくて、タクシー車内にあるAndroid端末に自社サーバーから配信する感じのAndroidアプリケーションです。BtoBtoCなアプリケーションなので普通のAndroidアプリケーションとは違うところも多々ありましたが、まあAndroid端末の上で動作するアプリケーションを開発していたので、私の直近の経歴はAndroidアプリケーションエンジニアのはずです。 また DroidKaigi と iOSDC Japan のコアスタッフをしていて、微力ながらソフトウェアエンジニアコミュニティの活性化に協力していたりします。 どうしてエス・エム・エスに？ 実は3年前に DeNA に転職したときにエス・エム・エスからも内定を頂いていて、その時はお断りしたという経緯がありました。当時もすごく悩んだのですが、ラストワンマイルを解決することに尽力したいという想いがあり DeNA(後に事業譲渡してMobility Technologiesに転籍になった) を選びました。当時は (今もですが)運転免許を持っておらず、駅から先の移動手段については自分自身でも課題になっていて、その問題に自分自身が取り組むことに魅力を感じての選択でした。 それから3年ほど経過したある日に、エス・エム・エスで技術責任者をしている田辺さん @sunaot から連絡をいただきました。その時に「3年前はエス・エム・エスを断ったけど、そういえば DeNA に行ってやりたかった事ってなんだっけ？」みたいなことを思い出しながら、「あの時は出来なかったけど、今ならとりあえずどこにいてもアプリを使ってタクシー呼んで移動する、みたいなことがほぼ出来るようになってるな」「全部ではないけど、3年前にやりたかったことの一部ぐらいは出来たのかも」ってぼんやり思いました。また、「チームビルディングとか少し興味出てきたな。今期の目標に設定してやっていくぞ」みたいな時期でもありました。 そんな状況で田辺さんからエス・エム・エスの3年前からのアップデートや近況を聞いて、 「ちょうどこれから新しいチームを作ってやっていこうと思うのですが興味ありませんか？」 と誘われて選考を受けることにしました。「新しいチームでチームビルディングから関われるのって楽しそうだな」っていうのが選考を受けた理由の大半で、まだこの時はエス・エム・エスの事業やプロダクトのことについてはぼんやりとしてて「複雑っぽい課題があって挑戦しがいありそう」みたいにしか思ってなかったです。 エス・エム・エスに入社することになった決め手は？ そんな状況で選考を受けていく中で、現場の人やビジネスの人とプロダクトや事業の話をするにつれて、エス・エム・エスのやってること、やろうとしていること、めちゃ面白そう！ってなりました。 医療・介護の状況は国の方針、地方自治体の方針、法律改正などで複雑性は増していく一方で、同時に高齢化もどんどん進行している。これから起きるだろう問題は医療費や社会保障費の推移、人口推移等のデータから予想はされているけど、どう解決したらいいかは誰にもわかっていない。エス・エム・エスはそういった課題に対して打ち手を考えてサービスを開発し、課題解決に取り組んでいる。その取り組み方も現場経験者が社内にいたり、また現場に直接ヒアリングしたりしていて(最近はコロナ禍のため、直接のヒアリングはあまり実施できていないみたいですが……)、本当に課題と向き合ってプロダクト開発しているな、と感じました。 そして特に決め手となったのは、これからの高齢社会に必要なサービスを作ることが結果的には自分たちに返ってくるようになるだろうと言われ、たしかに将来自分が引退した時に使うだろうサービスを自分で作ってみるのは面白そうだ！って思ったことでした。 エス・エム・エスに入社してどうだった？ エス・エム・エスはさまざまなサービスを開発していていろんな部署があるのですが、その中でも私は介護事業者向け経営支援サービス「カイポケ」のリファクタリングを行うチームに所属しています。 現在のカイポケは介護事業の複雑さがそのまま反映されているような状態になっていて、 介護のさまざまなサービス種類(居宅介護支援事業、通所介護事業、etc,etc,etc,本当に大量のetc...)に次々と対応していったという歴史的背景からそれぞれが複雑に組み合わさった大きなプロダクトになっています。 カイポケは現在の介護事業を支えるプロダクトに仕上がってはいるのですが、今後の社会情勢の変化やますますの高齢化を迎えるにあたって、カイポケのサービスを5年、10年といった長期で見た場合に今より良い体制はないだろうか、という試行錯誤を続けてきました。 そういった背景があって、カイポケというサービスを適切な単位でのマイクロサービス化したりなどのリファクタリングを行うことで、他に影響しない閉じた改善を行いやすく変化に対して強いプロダクトにしようとしています。 リファクタリングのプロジェクトは本格的に始まったばかりで、プロダクションコードはこれから書いていく段階ですし、チームも出来立てほやほやな感じで、チームビルディングから始めています。また、利用予定の技術スタックもそれぞれに精通している人ばかりではない(私も含め、初めて触れる技術もたくさんある状態)ですし、そもそも対象としている介護事業の複雑さもあって、私たちのチームでは「わからない」を口癖にしようという活動をやっていたりします。 エス・エム・エスは誠実でいろんなことに前向きな人が多いと感じています。こういうのやってみようと言うとすぐに「いいね、やろうやろう」って返ってくる感じで、私的にはとても居心地がいい環境です。また、さまざまな経歴の人がいて層も厚いと感じます。介護業界からきた人もいれば、それとは全く関係ない業界からきた人もいるし(私もその一人)、大企業出身だったりスタートアップ出身だったりで、本当にいろんなバックグラウンドの人がいます。 技術に関しては「この技術を極めたい。この道のプロになる」という人より「プロダクト開発やりたいので、それに必要な技術は習得するぞ」みたいなスタンスの人が多いように感じます。この辺りは好き嫌いあるかもしれないですが、どちらかというと私も後者な感じなので合っているなと感じています。 チームは出来立てでいろんなことが決まっていないふわっとした雰囲気だけどチームで決めていく楽しさがあったり、本格的なDomain-Driven Designでの開発や、React、GraphQL、AWS環境構築などなど初めてやることばかりで毎日が新鮮で楽しくやっています。 エス・エム・エスにはどんな人が合いそう？ 介護業界は更なる高齢化社会を迎えるため、これから未知の問題がいくつも出てくるだろうと予測されています。なので社会の要請もどんどん変わるだろうし、それに合わせてエス・エム・エスのプロダクトもどんどん変えていく必要があります。そういった事業領域でエンジニアに求められるのは変化や未知なことに対する前向きな姿勢だろうな、と私は考えています。 例えば私のチームだと、「マイクロサービスとかバリバリやってたぜ」的な人ももちろん大歓迎なのですが、「マイクロサービスの開発や運営はそんなやったことないけど、やってみたい。他の経験から補いながらキャッチアップしてやっていくぞ」みたいな人も大歓迎です。実際、私のチームで使う予定の技術スタックで誰も専門でやったことがない技術もあります。また私自身も前職はAndroidアプリケーションエンジニアですが、今共通している技術スタックはKotlinや前前職でやったことがあるSpring Frameworkぐらいで他はほぼ初めてのことばかりです。なので新しいことでも状況に合わせて前向きにやっていける人は合っているのかなって思います。 この記事を読んでちょっとでも興味が湧いたら、エス・エム・エスでは転職の意志がなくても話を聞いてみたいって感じでカジュアル面談していますので、是非是非話を聞きに来てみてください！ tech.bm-sms.co.jp

はじめに 医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスのAnalytics&Innovation推進部（ 以下、A&I推進部）でデータ分析基盤開発を担当している長谷川です。 A&I推進部はエス・エム・エス社内のデータを横断的に収集し、データの分析や加工から、データに基づく施策までを行う部門で、現在は介護事業者向け経営支援サービスである「 カイポケ 」や、介護職向け求人情報サービスである「 カイゴジョブ 」のデータ分析やレコメンドシステムの開発を行っています。 今回はその中で「カイゴジョブ」における介護求人の課題をディープラーニングによる分類モデルで改善した取り組みについて紹介します。 介護業界の課題 具体的な説明に入る前に、簡単に介護求人の課題感を説明します。 ご存じの通り、昨今の日本は少子高齢化が進み、介護にまつわる課題が毎日のように新聞やテレビなどで取りざたされていることと思います。 介護業界に関する課題は多くありますが、介護の需要が増大する一方で生産年齢人口減少によりサービスを支える介護従事者の不足が大きな問題となっています。 こちらは公益財団法人介護労働安定センターの調査結果ですが、介護職員全体の不足感は65%以上と高く、また様々な理由により介護従事者の採用が困難になっています。 出典：「介護労働の現状」 http://www.kaigo-center.or.jp/report/pdf/2020r02_roudou_genjyou.pdf このような課題を解決すべく、エス・エム・エスでは介護職向け人材紹介サービスである カイゴジョブエージェント や、介護従事者向け求人情報サービス カイゴジョブ 、介護・医療・福祉の資格講座情報サービス シカトル などの介護・医療・福祉の資格講座情報サービスを通じて「医療・介護の人手不足と偏在の解消」に貢献を目指しています。 A&I推進部の取り組み A&I推進部は、数理技術や先端技術を用いたデータ活用を通じたイノベーションによるエス・エム・エスの事業課題解決を通じた業界への貢献をミッションとした横断組織です。 A&I推進部の業務はデータ分析からシステム開発、共同研究など多岐に渡りますが、今回はその中でもカイゴジョブの開発を担当するプロダクト開発部と協力して進めている施策について紹介します。 介護求人における課題 カイゴジョブは多くの介護求人を扱う検索求人サービスですが、それらの情報を求職者の望む形でどのように届けるか、求職者に寄り添ったうえでどのようなサービスを提供するかについて日々研究・改善を進めています。 求人票の情報の多くはカテゴリ化されたセグメントデータの他に、多くのテキストデータも入力されます。特に介護保険制度は2000年4月に施行された比較的若い制度のため、およそ3年ごとに大きな見直しが入り資格や用語などが変遷してきたという背景があり、その影響で入力されるテキストデータにもかなりの幅があります。 例えば「介護福祉士」は介護職で唯一の国家資格ですが、介護福祉士の受験資格として「介護福祉士実務者研修」があり、これは2013年以前は「ホームヘルパー1級」と呼ばれていました。 そのため「介護福祉士実務者研修」を有する従事者を求める求人票には「介護士」や「実務者（研修）」「ホームヘルパー1級」「ヘルパー1級」「旧ヘルパー1級」などの記載が現在でも多く使われています。 また資格としては「介護職員初任者研修」から「介護福祉士実務者研修」へ、さらに国家資格である「介護福祉士」へと続くため、「介護職員初任者研修以上」と書かれる求人票も多く、この場合は「介護職員初任者研修」「介護福祉士実務者研修」「介護福祉士」いずれかの資格を有する従事者を求めていることになります。 このように介護における応募資格は複雑に入り組んでおり、具体例を挙げるとこのような表記をされることが多いです。 ・初任者研修（ヘルパー2級）以上 ・ヘルパー2級（介護職員初任者研修修了者） ・介護福祉士 ※いずれか必須 ・ヘルパー1級、基礎研修、介護福祉士のいずれか 【いずれか必須】 ■介護福祉士 ■介護職員実務者研修（旧ヘルパー1級） 【いずれも必須】 ・ヘルパー2級（介護職員初任者研修修了者）以上 ・普通自動車免許（AT限定可） 【あれば尚可】 ・介護福祉士（優遇） このようなテキストデータから、介護事業所の求める資格情報を抽出し、レコメンドなどに利用する場合、正確性を担保しつつも様々な表現に柔軟に対応できるロジックが必要となり、A&I推進部ではこの課題に対して最初に正規表現を用いた抽出ロジックを検討しました。 正規表現による抽出 正規表現は法則化された文字列の一致を検出するケースにおいて正確に対象を抽出できますが、求人票のような意味合いは似ているが表現が複数あるようなテキストの抽出を行うには、例外となるケースが多すぎ、それらを全て拾うことが困難であることが分かりました。 例えば【いずれか必須】と【いずれも必須】では意味合いが変わりますし、歓迎資格でも【次の資格・経験お持ちの方は尚可】と【上記あれば尚可】では求人票のどの部分を指しているかが変わるため、正規表現による抽出は断念し、代わりにニューラルネットワークを使った分類モデルの開発に着手しました。 応募資格構造化モデル A&I推進部で開発に着手したモデルは、求人票の応募資格を入力データとし、あらかじめ決められたカテゴリ構造に属するか否かを推論するモデルですので、名称を応募資格構造化モデルとしました。 モデル選定の選定については、入力テキストを時系列と見立て、文章の前後関係を学習するLSTMやTransformer、大規模な事前学習タスクを学習することで汎用性を獲得したBERTがありますが、求人票の応募資格は記述に極端な乖離がなく、介護という専門領域では比較的専門的な用語が頻出することから、事前学習モデルは利用せず、LSTMとAttentionをベースとした独自モデルとしました。 LSTMはディープラーニングの中でも時系列データを扱うリカレントニューラルネットワークの一種で、RNNよりも長期的な依存関係を学習します。 さらにAttentionという、結果に対してどの単語が影響するか注意して学習させる機構を追加することで精度向上が期待できます。 カイゴジョブは介護領域の求人の中でも多くの職種を掲載しておりますので、構造化のカテゴリ数も多く、応募資格構造化モデルでは108種類の構造化を対象としました。 以下はその一例です。 開発当初は1つのモデルで108種類の構造化を行うように設計していましたが、カテゴリによっては訓練データに偏りがあり、また学習時間もかかるなどの問題があったためカテゴリをグループ単位に分割し、4つのモデルを並行で訓練することとしました。 LSTMモデルはテキストを時系列データとして扱うのですが、テキストをそのまま学習することはできず、文字列を単語単位に分割する必要があります。 テキストを単語単位に分割する場合、日本語は英語のように単語の区切りが自明ではないため、文字列を1単語ずつ区切るか、形態素解析器を利用して形態素という単位に分割する必要があります。 例えば「いずれか必須」という文字列があった場合、1単語ずつ区切ると「い」「ず」「れ」「か」「必」「須」の6単語になりますが、MeCabという形態素解析器を利用する場合は「いずれ」「か」「必須」の3つの形態素に分割されます。 応募資格構造化モデルでは求人票の文脈を理解させたかったので形態素解析器を利用した単語分割としました。 またその際、通常のMeCabでは「介護福祉士」は「介護」「福祉」「士」まで分割されてしまいますが、このモデルでは「介護福祉士」を1単語として扱いたかったため、必要な資格は予めMeCabのユーザー辞書に登録しました。 こういった固有表現に強い辞書として mecab-ipadic-NEologd があるのですが、介護の資格である「初任者研修」を正しく分割しないなどの問題があったため、今回は標準辞書にユーザー辞書を足す形で文字列を分割しました。 訓練はGCPのVertex AIを利用し、ai-platformでジョブ登録することで不要なインスタンスが起動し続ける状態を回避するとともに、インプットの訓練データを変数化し同一ソースで複数のモデル学習を並列で実行しています。 gcloud ai-platform jobs submit training $JOB_NAME \ --module-name $MODULE_NAME \ --package-path ./packages \ --runtime-version $RUNTIME_VERSION \ --region $REGION \ --job-dir $OUTPUT_PATH \ --python-version $PYTHON_VERSION \ --scale-tier BASIC \ -- \ --batch-size $BATCH_SIZE \ --epochs $EPOCH \ --train $INPUT_PATH \ 　... モデルの詳細 応募資格構造化モデルの訓練手順を以下に示します。 最初に応募資格テキストの半角文字を全角に変換、記号を除去するなどの前処理を施します。 そのうえで1.の応募資格をMeCabを使い単語単位に分割します。 2.で分割した単語の並びを入力として双方向LSTM+Attentionモデルを通し、各応募資格ごとの確率を出力します。 3.の結果を正解データと比較し、正解との誤差を算出します。 その誤差を最も少なくするために学習を繰り返します。 1～5を繰り返し、誤差が少なくなった時点で訓練を終了します。 モデルの精度と改善の仕組み 約9,000件のデータを用いて訓練を行い、500件のテストデータで評価した結果、99.5%の精度となりましたが、実際の求人票で推論すると成果率は約80%くらいまで落ちてしまいます。 カイゴジョブには誤った推論データをアノテーションできる専用画面が作られており、この画面を通じて入力した訂正結果を訓練データに追加して再訓練することで精度向上を図っています。 データ連携 応募資格構造化モデルはA&I推進部で開発・訓練を行います。 そのためカイゴジョブのサービスとは切り離されており、データの連携は日次バッチで行っています。 求人票をデイリーでA&I推進部の環境へ連携してもらうと、A&I推進部ではその中身を確認し、前日との差分のみを取り出したうえで応募資格構造化モデルで推論を行い、結果をカイゴジョブに戻す形でデータを連携しています。 モデルの活用 カイゴジョブでは利用者の希望条件にマッチした求人情報をメールマガジンという形で定期的にお届けしています。 求職者に入力いただいた希望条件と、求人票の内容をマッチングしたうえで求人票をお送りしていますが、その際に求人票から応募資格構造化モデルで推論した条件を利用してメールをお送りしています。 応募資格によってはほぼ100%の精度となるものや、改善が必要な資格もあり、一定の精度以上の資格のみメルマガで活用し、そうでないものは、モデルを改修して引き続き精度の向上を進めています。 さいごに エス・エム・エスには数多くのサービスがあり、特に介護、医療に特化したデータを数多く保有しています。データサイエンスを活用したサービス向上ニーズも高く、今回の記事で少しでも興味を持って頂ける方がいらっしゃいましたら是非お話を聞きに来ていただけたらと思います。 open.talentio.com

技術推進グループの窪です。 SMSでは主にインフラ全般を見ていますが、主な領域はユーザーサービス側のインフラを担当しています。 入社したのは2017年で、当時と比べるとSMSのインフラは大きく変化してきました。 入社当時はオンプレでしたが約2年半でクラウドに移行し、開発者それぞれがクラウド環境を利用でき、シームレスにログインできるようになりました。 その変遷をご紹介させていただきたいと思います。 入社時はオンプレがメイン 入社した頃はまだオンプレでサービスを運用しており、SMSの中でも介護事業者向けに提供しているカイポケが開発側もインフラ側も課題が大きかったためクラウドに移行する事が急ピッチで進められている印象でした。 当時、私を除いて4名のインフラエンジニアがオンプレを日々運用しており、サーバーやアプライアンスのハードウェアの運用、ネットワークの運用、事業部からくる依頼や調査、オンプレリソースの切り出し、コスト管理などの運用で手一杯で、スキルの継承も難しく属人化が進んでいるように見えました。 私もネットワーク機器やアプライアンスをオペレーションできるスキルがなかったので、インフラを構築してもらいたい時はインフラエンジニアに依頼して待つという状態でした。 このような事もあり全社的にクラウド環境への移行を計画しました。 オンプレからAWSへ移行 クラウドへの移行を進めるにあたり「運用の効率化による持続可能なインフラ体制」を目的とし、以下の方針で進めることとしました。 オンプレの構成を極力変更せずにAWSに移行する。 移行後に課題がある部分を改修し、極力クラウドネイティブな形とする。 既存以外の新規は全てクラウド上で構築し、構築するものはIaCを用いること。 オンプレをそのまま移行するのは「えっ？」と感じる方も多いと思いますが、SMSではとにかく高い頻度でサービスが作られるため課題を先に改修しても、事業が継続しない可能性もあるためクラウドに移すことでの運用負荷を下げる事に注力しました。 移行先は、オンプレで利用していたVMをインポートできる事や、AWSに慣れているメンバーもいたためAWSにしました。 移行の進め方としてはシンプルですが、環境やこれまでのやり方を大きく変えると技術以外の問題も発生しました。 特に課題として大きかったのは関係者の調整が多岐にわたった事と費用面の複雑さでした。 当時SMSは外部の委託が多かったため、結合しているシステムでは、社員にわからないことが増えていく負のスパイラルに陥る可能性のある中で進めていくこととなり、移行が完了するまでに2年半近くの時間がかかりました。 AWS移行時の失敗 AWSに移行する際に１つ大きな失敗をした事があります。 SMS全体のインフラを俯瞰した際にカイポケが最も巨大で、それ以外は比較的小規模なインフラ構成でサーバー要件も複雑ではなさそうでした。 オンプレでは集約率がコストパフォーマンスに影響し、減価償却の分母も大きくなると各事業部の負担も小さくなります。そのため、SMSも小規模なサービスで似た要件のものは同一サーバーに集約していたのだと思います。 後ろ向きな姿勢ではありますが、ブラックボックスが多い中極力変更を加えずにインフラを移行を完了したい事もあり同様の方法で集約して運用するやり方で移行を進めました。 具体的には、１つのAWSアカウントにサービスを集約し、それぞれのインスタンスにリソースタグを付け、インフラの集中管理とコスト効率化を維持させようと考えていました。 しかし、このやり方は実際に多くの問題を発生させました。 AWSは従量課金となり、オンプレのように減価償却で定率のコストではないためサービス単位で費用を分割した際に「A事業部はそこまでつかっていないのにコストが高い」などの公平性とコストが不透明になり事業部が正確なコストを把握しづらくなった事。 リソースタグに対応してないサービスがあり、その費用の分配に関する社内手続きが複雑になり請求処理などのコストが大きくなってしまった事。 権限を厳密にしようとすると権限管理が複雑になりポリシーの上限に達するなど、AWSの制約と運用コストが増えた事。 すぐに、この方式は止めることにしましたが既に移行してしまったサービスもあり是正するのに3年近くかかることとなりました… 後述するAWSのベストプラクティスを無視した構成であった事も原因の１つですが、事業を運営する上で必要な情報や経理などが必要とする情報をスムーズに提供できるかという観点も抜けていたので、構成や運用を１から検討することにしました。 改善されたSMSのAWS構成 現在SMSは全サービスをクラウド上で運用しており、100以上のAWSアカウントをSSOなどを利用して効率的に管理できるようになり、開発により集中できる環境を提供できているのではないかと思います。 構成 AWSのベストプラクティスにもあるのですが、環境ごとにAWSアカウントを作ることが推奨されています。 SMSでは多数のサービスがあるため、最大でサービスの数 * 環境数(Dev,Stg,Prod)となり110アカウントほど現在はあります。 この方式ではAWSアカウントが増えると運用コストも線形に増加しやすい事や、小規模なサービスではオーバースペック気味になるというデメリットもあるのですが、サービス単位で疎結合になりやすい事とインフラの見通しがよくなることで改善に取り掛かりやすくなります。 アカウント運用については、現在はAWS SSOが提供されており運用コストが低くなる構成が作れるのではないかと思います。 SMSは社内でoneloginを利用していたのでoneloginと連携する事で入退社と同時にAWSアカウントへのアクセス制御され、インフラは権限の管理だけに集中する事ができるようになりました。 アカウント管理でインフラ側でやることは「誰を」「どの権限」でログインさせるかだけに注意するのみです。 LPやHTMLのみの簡易的なサービスに関してはAWSアカウント単位で分離すると逆に運用の手間が大きくなるため同一VPC内でもサイト間の通信はプライベート通信を使わない事やVPC Peerをさせない事で通信レベルは疎結合を保ち、もしそのサイトが大きくなっても個別にAWSアカウントを作れば移設が容易な構成にしました。 共通リソースの提供 前述の通り、SMSではサービスが高い頻度で作られます。そのため共通で利用するリソースをManageと言われる共通リソースだけを提供するAWSアカウントを用意し、VPC Peerで接続するだけで提供できる形にしています。 Manageの役割は主に踏み台、メールサーバー、ログ収集、監視、監査です。 特に監査はアカウント数が多くなると、監査自体が困難になってしまうのでAWS Config、GuardDutyで全体のガバナンスを保てるようにし、違反があればSlackに通知されます。 こうすることで基本的なAWS利用ルールはあるのですが、いつでも気付けるようにすることで制限なしでAWSを利用できるようにしています。 AWS移行を終えて AWSに移行して運用負担が大きく効率化されたのはもちろんですが、最大のメリットは属人化する要素が少なくなったことと、インフラの透明性が高くなった事で個人への権限の分配がしやすくなったと考えています。 まだ試験段階ですが全エンジニアにAWSのサンドボックス環境を個別に提供もできるようになってきました。 オンプレやアプライアンスがあるとどうしても特定の人にスキルが偏ってしまい、スキルの継承もその人のやる気次第となり組織としては常にアンコントローラブルな要素を持つことになり、持続させることが難しくなります。 オンプレと比べると今は複雑さが少ないコスト体系なのでインフラ以外の人もコスト意識を持つことができ、IaCで管理すれば再現性も担保される状態にあるので当初目標にしていた「運用の効率化による持続可能なインフラ体制」に近づけているのではないかと思います。 おわりに こうして4年近くかけてAWS移行から定着へと進めてきましたが、実際には個別の運用や対応が続いていたり、レガシーシステムをクラウドネイティブに持っていきたいけど工数面などで進んでいなかったり、AWSの布教ができていなかったり、などの課題が多く残っている状態です。 特に事業部によって特性が異なり、個別対応が必要なケースは悩まされますが「インフラをどのように適用すると事業がドライブしやすくなり、SMSが成長し社会に貢献できそうか」と考えながら進められる仲間がほしいなと最近思っています。

はじめまして、2021年8月よりエス・エム・エスに入社した熊谷です、10月で37歳になりました。これまでに約60万人の会員を保有していたポイントカードシステムの開発や、営業支援システムの開発に携わって来ました。 “入社エントリを書いてみませんか？”と社内で打診があった際、「書いてみたい！」と二つ返事をしてみたものの、いざ過去記事を見ると、メガベンチャー、ナショナルクライアント、世界最大手クラウドベンダーからの転職など凄い経歴の方ばかり。 異色のキャリアを歩んでる自覚はあったので、「やはり私の入社エントリなぞ書かないほうが良いのでは・・？」とご相談したところ、”むしろそのキャリアも含めて書いてほしい”とのことでした。 この記事では私の入社前のキャリアから、転職を考えたキッカケ、入社を決めた理由、そして入社した後の印象を皆さんにお伝えできればと思っています。 それと併せて、もし入社エントリー tech.bm-sms.co.jp を見て”ハードル高そうだな･･･”と感じていた方がいらっしゃいましたら、 私のような人間もおりますのでどうぞご安心下さい とお伝えしたいです（笑）。 ぜひ気軽にカジュアル面談にご参加頂ければと思っています。 入社までのキャリア 新卒の話になると早15年前になってしまうことに年齢を感じます。当時は大手メーカーの携帯電話（まだ2つ折りが主流だった時代）工場にてソフトウェアQA部内の検査ツール開発を行っていました。 2年ほどその企業に在籍していましたが、その後は知り合いに誘われるがままに転職することに。 転職先の企業はいくつかの事業を持っており、その中の1つに立ち上げたばかりのタクシー事業もありました。タクシー事業の在籍になった私は、当時原野状態だったタクシーの管理システムをイチから作る気満々で居たのですが、気づけばあれよあれよと二種免許を取得しタクシーを運転する方に早変わり。その後3年間、タクシー運転手が私の仕事となりました。 この3年間がソフトウェアエンジニアとしてのブランクにあたるかというと実は違いまして、同企業で運営していた他サービスの開発相談なども同時に受けていたこともあり、タクシーに乗りつつ、黙々とプログラミングやシステム設計の勉強を進める、という中々に異質な生活を送っていました。 道玄坂にある「とある会社」の前でご乗車頂いた”プログラマっぽいひと”に片っ端から声をかけ、勉強を教えてもらっていた過去もあります。今考えると滅茶苦茶ですが、当時は急拡大する事業に対応するため必死でした。タクシー運転手がお客様に勉強を教えてもらう、という異常な状況にも関わらず親切丁寧に教えて頂いた方々、本当にありがとうございました。今の私があるのは皆様のおかげです。 そんな生活を重ねつつも、やはり開発側の比重が増えていき、3年後に同企業の開発部へ移籍となりました。 一番最初の仕事は当時60万人の会員数が居た共通ポイントカードサービスのシステムリニューアルです。 当時は私を含め社内のエンジニアは3名ほどしかおらず、運用・保守の大部分を外部企業に頼っている状況でしたので、社内リソースのみで運営出来るような”自社化”を含めたリニューアルを企画しました。 そして、この”たった数名の社内エンジニアで”というのがうまく作用しました。少ないリソースで運営していくには、最も重要な機能開発などに多くのリソースを割ける状況にしていかなくてはいけない。そう考えた結果、移行先のサーバーとしてHeroku、フレームワークにLaravelを選択し、「インフラ管理の大部分を省く」ということを前提にリニューアルを進めました。2014年のことです。 AWS FargateやGoogle Cloud Runに通ずるServerlessやコンテナ技術に当時からイチ早く携われているため、結果論ではありますが、この判断は正解だったと思っています。 さて、そんな形で同企業に在籍していく期間が伸びていくにつれ、会社が飛躍的に大きくなり、同時に私の役職も上がっていきました。プログラマから開発部の部長へ、そして事業統括というポジションから事業戦略に通ずるシステム投資の価値判断など。上流工程の部分はもちろんあるのですが、社外へ開発を依頼する前のプロトタイプ的な実装なども兼務していたので、最終的なポジションでもずっとコードが書けていたのはとても幸せでした。 転職を考えたキッカケ 在籍期間も12年を超えていくなか、自身も30代半ばの年齢に差し掛かり、色々と思うところも出てきました。前企業は特定の分野・業界に根ざしているわけではなく、チャンスと見れば未経験の業界にもドンドン進出していきます。当然失敗も多いのですが、「失敗して元々」「経験から学ぶ」がモットーのような姿勢からか、次々と新しい企画や事業が立ち上がります。 若いうちは”当たって砕けろ”の精神で立ち向かえた自分も、年齢を重ねるごとに「このままで良いのか？」と考える日々も多くなりました。 一方で、条件面や待遇に不満があったわけではありませんでしたので、「今の会社に残るかどうかも含め一度考えを整理したい」という思いから、いくつかの会社からお話を伺うことになりました。エス・エム・エスとの一番最初のカジュアル面談も、「お声をかけてもらったので」という程度のことですし、今だから言える話、何をやってる会社かも全く知りませんでした。お話を伺って初めて「あ、医療・介護の会社なんですね」と言うレベルです。 エス・エム・エスに入社を決めた理由 有り難いことにいくつかの会社からオファーを頂きつつも、最終的にエス・エム・エスに入社を決めたのには、大きく2つの理由があります。 1つ目は、面接を重ねていくに連れ、入社後のイメージが上手くついたことです。他社の採用面接と違った点の1つに、技術責任者の田辺さんを始めとして、「エス・エム・エスがいかに素晴らしい会社か」という話を延々とされるのではなく、「今会社にはどのような課題があって、どういった部分に困っているんです」という話しを多くして下さいました。 採用面接というのは中々に難しく、“お金と時間をかけている以上、基本的には入ってほしい”ものであり、“出来る限り自社のことを良く見てもらいたい”ものだと認識しています。 そんな中、課題の共有は極端に言うと出来ていないダメな部分を見せる行為ですので、中々に勇気がいることかなと思っていますが、結果として「（課題に対して）自分は何ができそうか？」「どういう形で貢献出来るか？」など、入社後の動きや働き方のイメージが具体的に出来たこと、また課題をありのまま共有頂ける誠実さを感じられたことが大きかったと思います。 2つ目は、最終面接でお会いした社長の後藤さんとの話です。私が後藤さんに対して投げかけた質問に対する回答が、入社の意思を固める決定的なものになりました。 その質問内容は、 「エス・エム・エスはどういった考えのもと事業やサービスを展開していくのですか？」 というものです。 この質問の背景には前述で記載した通り、当時在籍していた企業が様々な分野に進出していくことで素晴らしい経験をしてきた反面、苦労してきたことも多かったからです。何をやる会社なのか、何をやらない会社なのか。これを知る意図で質問したところ、次のような答えが返ってきました。 “人口動態の変化で生じる歪みのうち、社会保障だけでは解決出来ない領域を、ビジネスとして解決する” 私達が生きている日本という国で超高齢化は避けられず、2025年には人口の3.3人に1人が65歳以上と言われています。この流れが更に加速していく中、求められる社会保障のあり方というのも変わり続けています。土台としての社会保障というのは今後も欠かせないものとして提供されていくでしょう。一方、国の制度として広く提供していくことや社会の変化のスピードに合わせる必要があることを考えると、社会保障が埋めきれない領域というのも常に存在し続けます。ここにビジネスが介在して持続的に解決していく機会と価値があります。「エス・エム・エスは医療・介護の会社」なのではなく、「医療・介護」が社会保障だけでは解決出来ない領域の1丁目1番地だから、事業として手掛けてるんです。 この回答は、質問の背景にある「何を事業としてやるか・やらないか」という問いに対して、自身の中で完全にマッチするものでした。それと同時に”残りの人生で、どうせ長い時間仕事をしていくなら、わかりやすく誰かの為になりたい”という風に考え始め、これらの意識が「辞めるか残るか」と迷っていた前職に対し、一つの踏ん切りをつけられる理由になりました。 医療・介護は、現代を生きている私達にとって不可欠なものです。例え今は特別重要でなかったとしても、数十年後にはきっとたくさんお世話になるはず。なのでまず 自分自身を含めた、身近な人の将来を支えていける を目標にしようと思い、転職することを決意しました。 入社後の印象 前述の通り、課題感の共有を面接時にして頂いていたこともあり、入社前後におけるイメージのギャップはほとんどありませんでした。またエス・エム・エスの社員の皆さんも、カジュアル面談で感じていた誠実な人たちばかりで、非常に働きやすいな、と感じています。 配属先のチームは最初から固定されておらず、数週間に渡ってチーム体験ツアー tech.bm-sms.co.jp を通じていくつかのチームの様子をお伺いし、その中からエス・エム・エスの キャリア事業領域 において、業務基盤として機能しているカスタマーサポート/顧客管理ソリューションチームに入ることに決めました。理由は至ってシンプルで（入社前から話しは聞いてましたが） 一番困ってそうだったから です。 エス・エム・エスは2003年の創業以来、短期間で急成長をしてきました。その過程でグループの統合などもあり、作られてきたサービスや基盤などに未だチグハグな部分も残っています。これらを「あるべき姿」へ変えていくのが私のミッションになります。 もちろん話は単純なシステム改修に留まりません。経営戦略として必要になるであろう機能・データは常に要求されますし、ビジネスサイドとのコミュニケーションとバランスを取ることや、平時の運用業務もパワーが必要なものもありそうです。また、“業務でヘビーユースされているにも関わらず”メンテ不全になっているツール類もあったりします。これらが今後起こりにくくなるような、「組織文化」的な部分にも少しずつ踏み入っていく必要性を感じています。 WEBエンジニアの方々は、エンジニアがなぜ「カスタマーサポート/顧客管理ソリューション」なのかと思うかもしれませんが、最近のCRMツールはWEBのテックトレンドをかなり意識しています。 例を上げるとSalesforceです。最近は Salesforce DX という試みから、CLIからのデプロイ操作やGit管理も可能となり、スクラッチ組織という使い捨て可能なテスト環境が用意されたりなど、開発体験がかなりモダン化されました。利用できる言語も元々はAPEXだけだったのが、Winter’22では Salesforce Functions というServerless環境が用意され、Node.jsやJavaでコードが書けるようになりました。 また、現在はまだPilot版ですが、複数存在したAPIを全て包括するようなgRPCベースの Pub/Sub API も計画されています。 このような最新の技術スタックを追従したい方にも、私達の運用チームはぜひオススメです。 時代に寄り添い、変化し続けられること 「継続性アーキテクト」という生き方 - エス・エム・エス エンジニア テックブログ tech.bm-sms.co.jp の記事でも語られているように、現代では「作って終わり」という開発は減ってきており、サービスの成長段階やニーズによって「あるべき姿」を柔軟に変えていくことが望ましいとされています。 そしてそれらは、サービスのみに留まらず 社内で利用されている業務基盤としてのアプリケーションも同様なはず です。チーム・組織・会社がそれぞれの成長段階で、市場によって、社会によって、時代によって変化していきます。 上記を実現するために必要なことは、一言で片付けるなら「柔軟性のあるシステム設計が重要だよね」に集約されてしまうんですが、それが一朝一夕で達成出来ないことは、ソフトウェア開発に携わっている皆さんであれば共感して頂けるでしょう。 幸いにもエス・エム・エスは、これまで同事業領域において20年近い実績があり、その過程で生まれた業務知識が山のようにあります。これら1つ1つを紐解きながら整理し活かし、あるときはバッサリ捨ててビジネスプロセスから考え直したりなど、やれることも、やらなくてはいけないことも膨大にあります。 これらの作業は非常にタフではありますが、もともとタフな仕事を求めていたというのもありますし、「この状況下でこれだけ業績が伸びている」というのはウラを返すと、事業としてもまだまだ伸びしろがあるということなので、非常に楽しみな部分でもあります。 入社後2ヶ月（執筆時点）で、長い道のりのやっと一歩目を踏み出せたかな、という感覚です。険しい道ではありますが、入社の動機にもある「身近な人の将来を支えていける」こと、 そしてこの記事を見て下さった皆さんの、ひょっとしたら数十年後を支えられるような仕事が出来れば この上なく嬉しい限りです。 勿論、私一人では不可能なので、ほんの少しでも共感して頂ける方がいらっしゃいましたら、ぜひカジュアル面談などでお会いしましょう。

医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスでサービス横断で技術的な課題を解決して回っている @okazu_dm です。 直近はSREとしての業務などがメインでしたが、本日は私が運用を担当していた全社横断の利用規約とプライバシーポリシー(以下、利用規約等とします)の管理&配信サービス(以降、社内のコードネームであるnomosと呼びます)について紹介します。 nomosとは nomosは、上述したとおり利用規約等を管理、配信するサービスです。2019年の夏には一旦開発が完了した段階で私が引き継ぎました。引き継ぎから実際に活用されるまでは半年ほど間があり、その時間はシステムの一部を単純化、再実装するなどブラッシュアップに使っていました。大まかにどのような変更があったのかについては後のシステム構成の説明の中で適宜触れます。 nomosを作った背景 弊社では複数の事業領域に渡って約40のサービス展開しており、サービスの数がエンジニアに対して多く、したがって管理対象の利用規約も多くなっています。それらが各サービスのリソースとして分散されて管理されていた時期は以下のような問題がありました。 法務担当から利用規約等の文言の更新を依頼したい場合、誰に依頼をすればいいかわからない 一部同じ文言が入っている複数の利用規約など、一斉に利用規約を更新したい場合でも、直接の管理主体が分散しているため更新漏れが発生しやすい構造だった こういった問題の対処として利用規約等を集約管理する、またパーツ化して共通部分を再利用できるようにする、などの機能を備えた管理システムと、編集された利用規約をユーザに対して表示する配信システムがnomosとして開発されました。 また、2020年の民法改正(ここでは詳細な内容は省きます)への対応のため、利用規約の変更実施前に変更後の利用規約等を一定期間ユーザに対して表示する機能があります。 nomosのシステム構成 nomosは上述したように大きく管理システムと配信システムに分かれます。 それを踏まえて以下の図をご覧ください。 nomosのシステム構成（現システムに合わせた最新版） 管理システム まず管理システムから見ていきますが、こちらはGoogle App Engine(GAE)のNode.jsランタイム上でNuxtのアプリケーションをWebUIとして運用しています。 認証部分はFirebase Authentication、利用規約等のストレージとしてFirestoreを利用しています。 また、nomosでは利用規約をパーツに分割して管理、そして各サービスの利用規約はパーツを組み合わせて構成されているため、これらのパーツが更新されたときに関連するサービスの利用規約を全て更新する必要があります。 そういった管理画面の操作によって発生するある程度複雑な処理についてはCloud Functions上に実装されており、Firestore上のデータが更新された際にCloud Functions上の更新処理が呼び出されるようにトリガー機能 *1 を設定しています(参考: https://cloud.google.com/functions/docs/calling/cloud-firestore )。 当初はCloud Functions内でCloud Pub/Subを利用して更に多重でCloud Functionsを呼び出す仕組みなどもあったのですが、単純な呼び出しコストやシステム自体の複雑さ、数年スパンで見たデータ量などの観点からも並列化のメリットがあまりなかったため設計を単純化しています。 また、早すぎる抽象化がなされていたり全体的に規模に対して各所のコードの複雑すぎた部分は引き継ぎ後に整理して単純なものに置き換えました。 以下が管理画面の一部ですが、利用規約やプライバシーポリシーの文言の編集や編集履歴の参照、ユーザ管理などが全て管理機能に含まれています。 配信システム もう一方の配信システムですが、こちらは現在はGAEのRubyランタイム(引き継ぎ当初はGoで実装されていました)上で動作しているSinatraのアプリケーションがFastly経由でユーザに対して利用規約を配信しています。 基本的にはFirestore上の利用規約等を配信するだけなのですが、利用規約が更新されたタイミングでは以下の画像のように、更新後の利用規約と更新前(現行)の利用規約を同時に配信するような仕組みが実装されています。 その他の要素ですが、一部の静的なコンテンツについてCloud Storageを利用、監視についてはMackerelの外形監視のみとしています。 運用していく中で見つかった課題とその対処 また、開発当時に考慮されていなかった(または優先順位が低いと考えられていた)問題の中で運用していく中で対処が必要だったものとしては以下のようなものがありました。 1. サービスへの導入の際は移行期間の設定をオフにしたい需要があった nomosでは、編集作業を行うと利用規約の移行期間に入り新旧双方の表示が行われるようになります。 そのため、サービスの新規リリース時などで細かい調整が直前まで入るケースであっても新旧双方の利用規約が表示されている、という状態になってしまうという問題があり、エンドユーザに対して混乱を与える懸念がありました。 これに対してはサービスごとに移行期間の設定を変えるなどのアイデアもありましたが、対応コストの観点から最低限の対応しかできない状態だったため、以下の画像のように強制的に最新版への移行をするボタンを管理画面につけることで対応しました。このボタンを押すことで、新旧双方の表示を行っていた状態のサービスは強制的に旧利用規約を撤廃し新利用規約のみの表示となる、という仕様です。 2. 検索順位への影響についての意見が上がった 当初、nomosは https://policy.bm-sms.co.jp のドメインに対してサービスからリンクを貼ってもらう想定で開発されていました。しかし、実際にサービスに導入する中でSEO戦略への影響についての声が上がり、機能の開発の検討なども含めた議論が発生しました。結論としては機能を追加することはなく、ドメインを統一したい場合はサービス側でリバースプロキシを立てるだけの対応に留める方針となりました。 これについてはシステム的に問題があったという話ではないのですが、開発時のドキュメントを参照する限りプロジェクト発足時点でサービス運用者からの意見を吸い上げられていなかった仕様策定プロセス上の問題という側面はあるものと見ています。なお、現状nomos導入の前後で大きく順位が下がったという現象は観測されておりません。 3. コストが想定より高くなっていた 私が前任者(開発者)から引き継いだ後に1ヶ月ほど運用して、コストが想定より高くなっていることに気づきました。 そこでGAEのインスタンス数を確認したところ通常ユーザアクセスが発生するとは考えにくい時間帯でも常にインスタンスが立ち上がり続けていることが分かり、原因を調べた結果Fastlyのヘルスチェックに対してレスポンスを返すためにインスタンスが立ち上がり続けていることが判明しました。 多少間隔を長くしても全てのPOPが独立してヘルスチェックをする都合上、オリジンサーバへのリクエスト間隔自体を正確にコントロールすることは難しいことと、実質的にはMackerelによる外形監視で事足りることを踏まえてFastlyのヘルスチェックを使うことをやめました。 その結果、コストを当初の半分以下に抑制することができ、おおよそ想定の範囲に収まりました。 おわりに 私自身は現在は特定の事業のためのシステム開発をメインで行っていますが、このような社内ツールにエンジニアとして関わることもあります。こういった社内ツールはサービスと直接関係があるわけではないため、設計や運用で普段とは違った面白さや難しさがあります。また、引き継いだものをベースに更に低コストで手離れの良いシステムを考えるというのは良い経験になりました。 *1 : 2021年9月にGAになりました。 https://cloud.google.com/functions/docs/release-notes#September_09_2021

はじめまして。医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスでエンジニアとして働く光宗朋宏です。技術推進グループにて各サービスの横断的な改善に携わりながら、介護事業者向け経営支援サービス『カイポケ』のアーキテクチャ改善にもテクニカルディレクターとして関わっています。他チームや他部門とも連携しながら問題解決に取り組む日々です。 今回は、そんな私の考えるエス・エム・エスの面白さについて、入社の経緯や現在の仕事内容、今後の展望から、お伝えしたいと思います。 to Bのサービス開発や内製化への興味から転職 私はエス・エム・エスに入社するまで、主にto CのWebサービスやアプリケーション開発に従事してきました。旅行クチコミサイトから漫画雑誌アプリ、ヘルスケアメディアなどジャンルも様々。サービスの立ち上げからコミットしたものも複数あります。 前職の大手比較サイトや大手ソーシャルゲーム企業では、複数のWebサービスの立ち上げを経験しました。後者の企業では社内横断プロジェクトに関わる部署に所属し、新たに立ち上がった企画に開発メンバーとしてジョインするような動きをしていました。現在の仕事にもつながる部分かもしれません。 また、大手比較サイトではエンジニア兼マネージャー的な仕事にもトライしました。当たり前のことですが、人間は10人いたら10通りの思考や行動がある。何か失敗があっても、ただ否定するのではなく、相手が何を考えて動いたかを理解し、同じことを繰り返さないようにするには？を考える。当時身についたコミュニケーションは今も意識しているように思います。 そこからエス・エム・エスに入社したのは、シンプルに、今までと違うことをやってみたかったから、です。介護業界の知識や経験があったわけではなく、to Cのサービスやアプリとは別の仕事をやってみたいなという理由でした。 加えて、私が転職を検討していた2016年は、エス・エム・エスがこれから開発を内製化していくフェーズ。これまで外注していた業務をどのように内製化するのか、開発体制やプロセスをどう設計するのか、人が集まるなかで組織がどう変容していくのかといった辺りは興味を惹かれました。内製化についてはこちらの記事で詳しく紹介しているのでぜひご覧ください。 tech.bm-sms.co.jp tech.bm-sms.co.jp あとは、田辺さん（プロダクト開発部部長 田辺順）とは前職で一緒に働いていて、定期的に社内の様子を聞いていたんです。選考に進んで経営層と話す機会があったとき、両者の話にズレがなかったことも入社の決め手になりました。 複雑な介護ドメインをシステムに落とし込む面白さ 入社してからは、技術推進グループに所属し、基盤技術の調査・研究、各サービスの改善業務を担当してきました。カイポケのデータベースのパフォーマンスチューニングやオンプレミス環境からAWSへのシステム移行、 カイゴジョブ や ケアマネドットコム のリニューアル、その他には社内オペレーション改善、エンジニア採用活動などにも関わってきました。 私は介護業界について知識や経験がなかったため、入社してからキャッチアップし、介護の仕組み、とりわけ介護保険制度の複雑さ、変化の早さを知りました。それらはエス・エム・エスで開発をする難しさであり、面白さでもあると感じます。 例えば、カイポケには、利用者に提供した介護サービスに応じて、事業者が国に介護給付費を請求する「請求業務」の機能があります。この請求の点数計算は、サービスの種別や都道府県、行政ごとにルールが違う。それも3年に一度の介護報酬改定によって変化します。 また、データベースのチューニングをするなかで、扱うデータの特性も複雑さを増している要因だと感じました。請求業務で言えば、基本的には毎月1日から10日にかけて、事業者が請求をします。ですが、何ヶ月か遡って請求する人もいますし、一定期間を過ぎてしまうと遡って請求はできないなどの決まりもあります。こうしたルールを踏まえ、どのデータをどのくらいの期間までアクセス頻度が高いと見なし、データベースのパフォーマンス最適化を図るのかは、なかなか判断が難しいところです。 ですが、面白いのは、その複雑なルールさえ網羅しておけば、ある程度の動きが読めることです。to Cのサービスであれば、ユーザーのアクセスパターンは多様ですから、一定の幅を持たせて、データベースを設計しておかなければいけません。一方、例えばカイポケの請求業務であれば、事業者の人数や要介護者の内訳などで規模感などは読める。それらに則って最適な設計をすれば仮説通りに動くことも多いんです。その瞬間の気持ちよさはルールの決まっている土俵ならではかもしれません。 より拡張性を備えた設計へ、システム全体を俯瞰する役割を担う 現在、カイポケのアーキテクチャ改善に携わっています。 カイポケのアーキテクチャ改善では、訪問介護や通所介護、居宅介護など、サービスの種別ごとにマイクロサービス化を進めています。既存のシステムは、複数のサービスが一つのデータベースにアクセスするモノリシックな作りになっています。各サービスを独立させ、共通のインターフェースを介して連携できる仕組みに移行することで、より柔軟に変化へ対応できると考えています。 そのなかで私はテクニカルディレクターとして、システム全体の整合性や相互アクセスの仕組みづくりなどを考える役割を担っています。実際に具体のルールや細かい部分を決めて手を動かすのは、訪問介護や通所介護など種別ごとの開発チームなので、連携しながら進める形です。 詳しくは こちらのブログ に書かれていますが、まずはカイポケの重要な機能である「請求業務」の部分を切り出そうと、取り組んできました。私自身もどのようなロジックを組んでいくのが最適か、厚生労働省の資料を眺めながら検討したりしました。現状の仕組みをただ移行するのではなく、3年ごとの介護報酬改定や細かい点数計算のルール変更にも対応できるよう、拡張の幅を持たせながら設計し直しています。 採用している技術としては各サービス間のやりとりはGraphQL、開発言語はKotlinです。カイポケはJavaで書かれているためJava 16を採用する手もありましたが、モダンな言語でありながらJavaの資産も活かせる点、Androidの公式言語への採用実績などからKotlinに落ち着きました。 また、設計においてはカイポケの扱う業務ドメインの再定義も必要です。各事業部の方に、どこにアプリケーションコードがあるのか、どういった部分を改善したいかなどのヒアリングなども行なっています。カイポケは歴史の長いサービスですから、仕様を漏れなく洗い出すのは大変ですが、できる限り顕在化していないものの無い状態を目指したいです。 このように複雑かつ変化の多いドメインで、技術による課題解決を率い、一定の歴史と規模のあるプロダクトに変化をもたらしていけるのは、エス・エム・エスで働くやりがいだと感じています。 個よりチームの総合力で良いプロダクトを創る 複雑な問題に対し、一人の敏腕エンジニアが意思決定をするのではなく、チームの総合力で向き合うのも、エス・エム・エスの特徴だと感じます。みんなで納得して物事を動かしていく空気があります。私が日頃の業務で関わる人たちは、上から言われてやらされる感を持って仕事をすることはなく、「自分がどうしたいのか」を持っているように感じます。 自分の意見を発言するときも、年齢や期待される役割などは誰も気にしません。良いアイデアは良いアイデアですから。誰が言うかは関係ないといったカルチャーがある気がします。 また、そうやって全員で意思決定して動かしていけるのは、エンジニアや非エンジニア問わず、論理的に思考できる人が多いこともあるかもしれません。現状の問題に対し、状況や取り得る解決策、生じるコストなどを冷静に判断し、どうするかを話し合ってくれる人が多い。特に裁量を持っている人たちがそうした方ばかりなので、仕事を進めやすいですね。 個人としても、コミュニケーションにおいては論理的に、順序立ててわかりやすくを意識しています。誰にとっても理解できるように話すというのは、非エンジニアとのコミュニケーションだけでなく、エンジニア間でも重要です。専門用語で捲し立てて「わかった」と言われても意味がありません。社内では「ITに一切興味のない友人や家族にも説明してわかるように」と伝えたりします。 チームで意思決定をして物事を動かしていくという点で付け加えると、開発においてモブプログラミングを取り入れている人も多いです。 技術力を磨きながら、横断的な課題解決に携わりたい人 これから力を入れていきたいのは、UIやUXなどエンドユーザーの使い心地に直結する部分の開発です。個人的にも興味を持っている部分でもありますし、エス・エム・エスはサーバーサイドの得意な人が比較的多く、フロントエンドは優先度を上げきれていないので。会社としても、次のチャレンジとして適切かなと思っています。 開発組織としても、社内だけで設計や実装部分が完結する体制が整ってきて、これからプロダクトのビジョン設計や企画も含め、開発全体を担えるよう成長していく段階と捉えています。 その際には、プロダクトオーナーが「これを作ってください」とビジョンを描き、エンジニアがその通りに作るといった組織ではなく、たたき台をもとに皆の意見を反映していくような組織でいたいと考えています。視点も違えば意見も変わる。その違いが改善のヒントになることもあると思うので、大事にしていきたいです。 ここまで書いてきた通り、エス・エム・エスは個人としての技術的な探究をしながら、組織を横断して会社の課題解決にも携わりたいエンジニアにとって、良い環境だと思います。 なかでも、今注力して募集しているテックリードは、サービスを1から10に成長させるフェーズにおいて、周りを巻き込みながら技術的な課題解決をしていく役割です。エンジニア以外にも情報を伝播し、形にしていく部分を担います。（もちろん本人の経験や希望、状況によって、どれくらい手を動かすかも変わります） 自分なりにプロダクトのビジョンも描きながら、チームを巻き込み、技術力で開発を率いてみたい方は大歓迎です。少しでも興味を持っていただけた方がいたら、ぜひお話できたら嬉しいです。

2021年4月にエス・エム・エスに入社した阿部です。現在は介護事業者向け経営支援サービス「カイポケ」の障害福祉サービス事業所向けの機能開発を行っています。まだ入社して半年ではありますが、私がなぜ転職という道を選んだのか、入社して感じた前職との違い、などをお伝えしたいと思います。 現在転職を考えておられる方、エス・エム・エスに興味を持っていただいている方のご参考になれば幸甚です。 転職の契機と企業選択の理由 ここではまず、私がなぜ転職をしたのか、その理由をお話したいと思います。 私は、前職は新卒で日本を代表する大手電機メーカーへ入社し、主に鉄道・上下水・発送電などの社会インフラや、製鐵所、化学プラントなどの制御システムで使用される基盤ソフトウェアの開発を行ってきました。 思えば長いものです。10年というキャリアの中で様々な業務をこなしてきたことで、新卒の頃と比べて自分なりに大きく成長できたと感じていました。一方で、社内での役職が上がるにつれて、以下のようなモヤモヤ感も感じるようになっていました。 残業に追われながら仕事をこなすだけになり成長が鈍化してきた 纏め作業ばかりで「モノづくり」に携われていない この会社の仕事のやり方・考え方しか知らない そんな中、妻が妊娠したことをきっかけに、 今の業務量では子供の成長が見られないのではないか、このままでは子供に「何で今の仕事をしているの？」と聞かれた時に胸を張って答えられないのではないか 、という疑問を抱くようになりました。 このような疑問を持った理由は父にあると思っています。私の父は仕事で忙しく家にほとんどいませんでした。その部分では寂しさを感じてはいたものの、話をすると強い意思を持って仕事を行っていたことが垣間見え、その姿を尊敬もしてもいました。そのため、より子供に寄り添いつつも、父と同じように胸を張って仕事に望んでいる姿を見せたいと考えるようになったのだと思います。 前述のモヤモヤ感に加えてこれらの疑問を持ったことが、私が転職を決意した理由です。転職をするにあたっては、まず、自分はどのような企業に入りたいのかを考え、以下を転職の軸として転職活動を始めました。 現実的な業務量であること 子供の成長を見たいためです。前述したように転職を決意した大きな理由の1つであり、ここは外せませんでした。 モノづくりに携われること モノを作って動かす、ということには何事にも代えがたい楽しさがあると思います。特に、それが誰かの役に立つモノであれば尚更です。前職では昇進に伴い、取り纏め業務が多くなってしまいましたが、やはりモノづくりに携わっていたいという思いは強かったです。 異なる業種、異なるビジネスモデルを持っていること 10年間働いてきたことから、多くのことを学ぶことが出来ましたが、それはあくまでも一企業の中のものです。より広い視野を持つためには、異なる業種・ビジネスモデルを持つ企業で、今までとは違う経験をすべきではないかと考えました。 異なる技術スタック（Web、クラウド）を扱っていること 今まではずっとOSやミドルウェアなど、低レイヤーな技術を扱ってきました。このまま専門性を高めるのも面白いかと思いましたが、それよりも、これらに加えてWebやクラウドなどの上位レイヤーまでをカバーできると、技術者として大きく成長できるのではと考えました。 転職の方法は多くの方と変わらないかと思います。転職サイトへ登録し、エージェントを介した活動を行っていました。そして、上記の軸をエージェントの方々に伝え、紹介いただいた企業の中の1つがエス・エム・エスでした。 エス・エム・エスへの入社を決めた理由は、前述した軸が満たされていたことと、最後は「人」でした。新型コロナの影響でリモートでの面接・面談しかできませんでしたが、エス・エム・エスで働いている方々は大人な方が多く、選考プロセスもしっかりしている印象を受けました。また、面接・面談では部長やグループ長だけでなく、実際のサービス開発に従事しているチームの方々ともお話させていただく機会もあり、広くエス・エム・エスにフィットするかをしっかり見て頂けているという印象も持ちました。 長期的な視点で満足のいく転職であったかは社歴が浅いので正直なところ分かりません。ただ、現時点では転職を決断して良かったと感じています。子供の日々の成長が見られるのは嬉しいですね。　 さて、話は変わりますが、転職をする際は転職先がどのような企業であるかなど、様々なことを調べるかと思います。私も色々調べながら転職活動を行っていたのですが、エス・エム・エスに入社してから、転職前には想像していなかったいくつかの驚きを感じることができました。次節では、それらについてお話したいと思います。 エス・エム・エスで感じた３つのこと エス・エム・エスへ入社して感じた驚きとは、下記に示す前職との違いになります。 組織構造の違い 品質に対する意識の違い 技術的負債の溜まり方 組織構造の違い エス・エム・エスへ入社して感じた驚きの1つ目は組織構造の違いです。特に、他者とやり取りするときの心理的障壁の高さには大きな違いがあると感じています。 前職では組織が縦割りかつ階層構造に分かれていました。そのため、各種権限がそれぞれの部署に分散させられており、縦割りの壁を超えて業務を円滑に進めるための調整業務が必要となっていたり、各種レビューの場では自部署・他部署の役職の高い方々からの「指摘」が頻繁に発生していました。 エス・エム・エスも組織上、部やグループは分かれていて、それぞれの責任者は存在します。しかしながら、私の所属するチームはスクラムの構造を取っているため、QA、PO、開発などの役割が分かれているだけでそこに組織上の壁や役職の上下関係は存在しません。権限を持つ小さく閉じたフラットなチームとなっており、改まった調整業務やレビューの場での「目上の方からの」という接頭辞の付いた指摘はありません。 こういった組織構成の違いは色々な媒体で紹介されていますが、実際に体験してみると想像以上の感覚的な違いがありました。エス・エム・エスにおいても、大なり小なり調整業務は必要ですし、レビューで他者からの指摘を受けることも当然ありますが、そこで感じる心理的障壁は圧倒的に低いです。 ザ・日本企業に勤務している方は、営業や品質保証部、開発部のそれぞれの担当の席が同じ執務室内の1つの島にチームとして存在し、それぞれの上長は他の建屋にいて一切干渉しない・できない（＝その島の中で全てを完結させなければならない）状況と言えば分かり易いかもしれません。同じ平社員しかいないので気楽な会話ができますし、指摘にも柔らかさが出てきます。 ただ、良いこと尽くめではない側面も当然あると考えます。例えば、権限を持つフラットなチームで作業を進めるということは、業務プロセスや使用するツールも含め、開発・維持保守に係る多くの事柄を誰かに判断を仰ぐわけではなくチームで決定し、実行する必要があります。これは、結果としてサービスの仕様や品質の責任もチームに帰属するということになるため、サービスに対する当事者意識を高く持つ必要があるかと思います。 品質に対する意識の違い 2つ目は品質に対するスタンスの違いです。前職は圧倒的な高品質を目指していましたが、エス・エム・エスは品質だけでなく、コストや開発期間などの他の要素とのバランスを取る傾向にあると感じています。 具体的には、前職はインフラの制御システムを実装・提供しており、不具合により万が一にでもお客様の業務が止まってしまうと社会的問題に成りかねないことから、高品質・高信頼であることに大きな価値があるという考えがありました。そのため、提供するハードウェア、ソフトウェア、システム、それぞれのレイヤで厳しい品質要件が定められており、仮にお客様への納入後に不具合を検出した場合は基本的には最優先での対応を行っていました。 一方、私の所属するチームは前述した通りスクラムの体制を取っており、開発項目と不具合が同じプロダクトバックログへと積み上げられます。そして、これらをどのような優先度で対応していくのか、どの程度の品質を保つかなどもチーム次第となります。そのため、不具合が発覚した場合はお客様への影響度や修正コストを鑑みながら対応を検討し、場合によっては、暫定対応をまずは行い、本対応は他の機能追加などの案件との優先度に応じて対応時期を柔軟に調整することで、サービスの進化を止めずにお客様へのさらなる価値提供を優先することもあります。 ビジネスモデルや事業ドメイン、組織構成、企業の文化と風土、辿ってきた歴史など、前職とは様々な違いがありますが、企業が違えばこのような考え方にも違いが出るということに、新鮮な驚きを感じています。 技術的負債の溜まり方 最後は技術的負債の溜まり方についてです。転職前は「SIer=古い技術を使っていて、技術的負債が溜まっている」「SaaSベンダー=モダンな技術を積極的に取り入れ、技術的負債も日々解消できている」というステレオタイプなイメージを持っていましたが、実情はこの認識とは異なっていました。 たしかにSIerでは（前職の経験でしかありませんが）、事実としては古い技術を使うタイミングは多くありました。これは主に、24時間365日の連続稼働が求められるインフラを扱っていたことから高品質・高信頼の担保が絶対であり、そのために、長く稼働実績のある信頼できるソフトウェアを横展開して活用していたためです。（断っておくと、これは決して技術力が無いということではありません。むしろ、前職ではシステムを構成するソフトウェアのほぼ全てを内製化していたり、研究所との連携により独自技術を開発していたりと、技術力という面ではかなり高いレベルにあったと思います） しかし、思い返してみればこのように古い技術を使用してはいたものの、下記のような理由から技術的負債が作られない・解消されやすいという面もあったように思います。 開発プロセスが整備されており、時間をかけた設計やレビューが実施されることから、クリアな設計ドキュメントが残され知見を広く共有できる 高品質・高信頼を重視する文化が根付いており、短絡的なコーディングがされ辛い、されたとしてもコードレビューでチェックされる 人の入れ替わりがWeb系に比べて少なく、個々のソフトウェアに関する知見が貯まりやすい 一方、SaaSベンダーの場合はどうでしょうか。あくまで私の所属しているチームの話であることを断った上で、SIerとの違いについての所見を述べます。 SIerとは異なり、SaaSベンダーは自社サービスを提供しているため、運用中のサービスに対して機能の追加や変更を高い頻度で行なっていきます。当然、前述したような設計ドキュメントの作成やレビューは実施しますが、かけられる時間が相対的に短く、人の入れ替わりも多いことから、結果として開発を繰り返すに従い技術的負債が溜まり易い傾向にあると思います。また、SIerにあるような大規模なシステム更改プロジェクトもない（リプレイスが行われることもあるでしょうが、それはプロダクトとしての一大事業になるでしょう）ので、溜まってしまった技術的負債を一気に解消する機会もなかなかあるものではありません。 つまり、SaaSでは技術的負債は溜まらないとか、自然と解消されていくとかということはなく、ある面においてはSIerよりも難しい部分があるというわけです。ここはSIer時代に抱いていたイメージとは違っていました。 なお、私の所属しているチームでも、処理がブラックボックス化してしまっている、実装の意図が読み取れなくなってしまっている、といったさまざまな技術的負債があります。この積み重なった負債を解消したいという思いから、機能追加時に周辺機能のリファクタリングを行うといったソースコードレベルの負債解消から、工数をかけて他のモジュールへの結合度を下げるといったアーキテクチャレベルの負債解消まで、多岐に渡る取り組みを日々行っています。 これらの取り組みにより全ての負債が解消できるわけではなく、お客様の利便性にも変わりはありませんが、将来のサービスをより良いもにのする際の足枷を取り除くという面においては、大きな意味のあることだと考えています。 SIerからの転職で「やっていける」のか 本エントリーの最後は、自分への自戒も込めて、SIerからの転職を考えている方へ「実際にやれてるの？」という視点での私の経験を述べたいと思います。 私は、前職では基盤ソフトウェアの開発を行っていましたが、エス・エム・エスでは介護事業者向けのWebアプリケーション開発を行っています。開発するソフトウェアのレイヤーも異なれば、ビジネスモデルも異なり、さらにはお客様の業種も全く異なります。そのため、入社前は大丈夫なのかなという不安を持っていましたし、実際に入社して間もない頃は右も左も分からないような状況でした。 ですが、今現在をやれている or やれていない、のどちらかかと言われれば、「まあ、全くやれてない事はないのかな」ぐらいの感覚は持てていますし、右か左かぐらいは分かります。これは、私自身が大学で情報処理を学んでいたり、前職が（広い意味で）同じソフトウェア開発を行っていたというバックグラウンドを持っていることに加え、入社後もチームの方々からの数多くのサポートを受けられていることがあってのことだと思います。特に、入社して2か月弱は、オンラインで毎日1時間の質問・相談会を設けてもらったこともあり、それにより不明点の早期解消や精神的距離感を縮めることができたと感じています。 もちろん、他の方々と比べたらまだまだ天と地ほどの差がありますし、その差を埋めるためには介護業界のドメイン知識の習得、Web技術の習得のためのOff-JTも必要になりますが、入社前に感じていた漠然とした不安に対しては、そこまで気にしなくても良かったのかなと思います。 一方で、前職での経験を上手く活かせているのかと言われると、今のところはあまりありません。ただ、今までが無かったからといって今後も全く無いとは思っていません。これから先の業務を進めて行くなかで活かせるタイミングがいずれ来るはずですし、そこで活かすことが私に求められていることだとも思います。 そのためには、まずは現状足りない部分を補うための努力が必要ですが、それに加えて、前職で培ったエンジニアとしての芯をしっかりと持ち続ける、ということもエス・エム・エスで業務を進めるにあたっての重要な要素だと感じています。 まだまだ、ただの一兵卒ですが、この初心を忘れず、いずれエス・エム・エスの発展の一翼を担えるようになれたらと思います。

医療・介護・ヘルスケア・シニアライフなどの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで介護事業者向け経営支援サービス『カイポケ』でエンジニアリングマネージャーを担当している岩田です。 これまで、位置情報関連のWebサービス開発や、大手ソーシャルゲーム会社でのメディア開発などでサーバーサイドエンジニアとして開発に携わり、エンジニアリングマネージャーとしても組織に関わってきました。 今回は、事業の成長に伴う組織規模の拡大によるエンジニアリングマネージャーの急募という状況を背景に、エス・エム・エスにおけるエンジニアリングマネージャー（特にカイポケの開発組織における）の役割とやりがいについて、お話してみようと思います。 EMとは？ エンジニアリングマネージャーとはどういうものなのか？は、色んな所で話されていますが、どれも似たりよったりな内容ではあるものの明確にこれだ！という定義はないように思えます。 EMトライアングル *1 では、以下のように技術・プロダクト・チームの3つを柱に、それぞれの間にこぼれている役割を担うものとして定めていて、沢山の役割がありますよね。 （出典： Engineering Manager Triangle , エンジニアリングマネジメントトライアングルの考察：序 ） これを全て満たす必要がEMにはあるのでしょうか？ 世の中の会社で、EMを募集している会社はたくさんあります。 それのどれもが似ている部分はあるが、上記のEMトライアングルを全て網羅するような役割で募集はしていないように思います。 私自身も過去の職場でEMの役割をやってきました。現職と過去を比較してもEMの役割は異なっていますので、各会社/組織が置かれているフェーズや組織規模、プロダクトの大きさなどによっても異なっているのではないかと考えます。 また、EMが必ず必要なのか？というと、組織やチームの規模などによっては必ずしも必要ではないと思ってはいますが、EMという名前ではなくても役割を果たしてる人というのは組織の中には必ず存在していると思います。 そういった意味では、EMは技術・プロダクト・チームの3つの中で、空白地帯を埋める人なのかもしれないですね。 ただ、最近の流れを見ると、特に技術とチームの間にあるピープルマネジメントが強く求められている傾向にはあると思います。 このようにEMと一言で言っても多種多様な役割があって、また会社によっても異なっているんだなと改めて思いました。 では、実際のところエス・エム・エスでのエンジニアリングマネージャーとはどんなものなのか？を実際に携わっているカイポケの開発組織での役割について話してみたいと思います。 カイポケの開発組織とEMとは？ 私が現在携わっているカイポケというSaaSのプロダクトですが、一言で表すと 「業務効率化や財務改善など、介護事業者の経営改善に役立つサービスをワンストップで提供するサブスクリプション型のクラウドサービス」 となります。ご興味ある方は、 こちら をご参照ください。 さて、本題のカイポケのEMとは何か？ですが、開発組織の体制から話していきたいと思います。 カイポケの開発・運用は介護経営支援開発グループという開発組織が携わっています。 大小約10チーム（エンジニア（QAエンジニア含む）のみ）くらい存在しております。 関係性はフラットな組織体制となっており、よくあるようなチームリーダー的な役職はありません。 チームが最大限、自分たちで考えて自律的に能動的に動けるように、また目の前の課題や担当している機能などをどのように成長させていくかも含めて裁量を持って動けるような体制をとっています。 組織として意思決定などの役割は以下のような人たちがいます。 テクニカルリード 技術の意思決定などを行う人 プロダクトマネージャー プロダクトに対しての意思決定などを責務として持つ人 エンジニアリングマネージャー 人や組織に対しての意思決定などに責務を持つ 組織改善など組織を良くしていくための活動 組織横断（カイポケで言うと法律改正時対応のファシリテーションなど）での活動 カイポケの開発組織は、自律的に動くチームが主役の組織になっています。その中でEMはチームや人がより良く働けるように各メンバーと各チームへのサポーターとして、メンバーやチームの課題を発掘しプロダクトを前進させるための組織としての成長に貢献することが目的となります。そのため、「 人と組織の生産性最大化 」がミッションとなります。 カイポケEMの役割その１ ピープルマネジメント ピープルマネジメントを通じて達成していくことは、 お悩みごとや困りごとの発見と解決を行う キャリア形成のお手伝い 適切な評価でメンバーの成長に寄り添う 育成を通じて組織の戦闘力を上げていく が上げられます。 特に1については、人数の規模が拡大すると、それまで出会うことのなかった課題が突然噴出することがよくあります。なので、組織全体としては一番気を使うところになりますし、日頃から関心を持ってメンバーと接していく必要があります。 これらに対して、1on1やオンボーディング、目標設定/評価というツール類を駆使しています。 特に1on1は大切なイベントだなと思って取り組んでいます。 なぜなら、普段、一緒に行動することが少ないメンバーとの会話をする時間は大事な時間だと思っているからです。 大切なイベントだからといって特別なことはしていません。 一つ大事にしている心構えとしては、メンバーの方になるべく話してもらうように、私自身は 傾聴の姿勢 を強く持つということくらいでしょうか。 お互いに自然体で話したいな。と思うことを話せる場作りを行ったり、必要に応じてコーチングやティーチングなどを交えて成長へのサポートを行ったりします。 私が行っている1on1の当日までの流れは、こんな風になっています。 1on1の当日は、共有シートに何か書かれていれば、それをネタに会話を始めます。 ただ、毎回、何か書かれているわけではないので、そういう場合は、「今日は何を話しますかねー」という問い掛けからスタートすることが多いです。 雑談やアイスブレイク的なところから始まったり、その日は雑談で終わったりすることも多いです。 雑談なんかで終わって時間がもったいないとか思う人もいるかも知れませんが、私はそうは思いません。 1on1の目的はメンバーとのコミュニケーションを通じて、サポートしたり成長のアシストを行う時間だからです。 その目的を果たせるのであれば、形式としてこうあるべきという型にハマり過ぎないことも大事なのではないでしょうか。 　組織の課題や問題は、人に帰着することが多いと感じていて、誰かが不満に思っていることは個人的なことは除くと、組織全体の課題として解決していくことが本質的な解決につながるのではないかと考えます。 余談ですが、リモートワークによって、その難易度は格段に上がったなと思うことがあります。ただ、それはEMとしての腕の見せどころでもあると考えますし、今まで見てこなかった角度で見ていくことによる新しい発見ができるのではないかと思って逆にワクワクします。 ピープルマネジメントはポジションに関係なくできることであり、EMだからできることではないと思います。ただそれと同じくらいEMという役割における土台になるものだと考えています。 基礎だけど奥が深く、いつも大事にしたい役割の一つです。 カイポケEMの役割 その２ プロジェクトマネジメント プロジェクトマネジメントと大きな括りにしていますが、基本はチームが自分たちで自立的・能動的に考えて実践していくため、プロジェクトマネジメントとして日頃から何かを行っているわけではないです。 では、何に対して行うのか？というと、「組織横断で動く必要のある時」がメインターゲットになってきます。 組織横断で動く必要のあるものとしては、 大規模障害が発生した時 介護報酬改定で組織横断で取り組みを実施する時 組織横断での施策を実施する時 大きく3つくらいに分類されます。 日常的には、3.に関わることが多いです。 組織横断での施策は、プロダクトに対してのプロジェクトや組織改善に対してのプロジェクトが上げられます。 プロダクトに対してのプロジェクトは、 プロダクトボード という取り組みを行っているため、ボード内でのファシリテーションと最終的な意思決定者としての側面が強いかもしれません。 カイポケEMのやりがいはなにか？ カイポケでEMを担当することのやりがいはなんでしょうか？ カイポケ開発組織の課題として、 事業とプロダクトの成長速度が早く、組織がそこに追いついていないという現実がある。 EMという役割が必要ではあるものの組織の中での活かし方が定まっていない という2つの課題があります。 1つ目は、成長産業で事業を行いサービスを提供しているカイポケの成長速度が早く、それに対して組織として追いつけず成長を牽引できるような体制になっていないことだと考えます。 組織が事業やプロダクトに対して貢献していくために、将来を見据えた組織のあり方や足りないものを見つけ出して実装していくことが必要です。 また、優秀なメンバーがたくさんいる環境の中で、彼らのパフォーマンスを引き出しつつ、組織としてもより強くなっていくと考えています。 そういった組織をより強くしていくために、組織規模がそれなりに大きいとはいえ、まだまだ未成熟なフェーズのため完成された組織ではなく０ベースで色々なチャレンジを実践していき、発展途上の大きな開発組織をご自身の手で成長させていけるところがカイポケEMとしての魅力だなと書きながら改めて思いました。 2つ目は、チームを主軸とした組織体制の中でEMはどうあるべきか？が定まっていない。 EMの役割として色々と書きましたが、それはあくまでも、私が入社してからここまでに見てきた中でこういう役割は必要だなと思って定義してきただけのものになります。 他社さんのEMやEM界隈でのブログを読んでみると、もう少し違ったものになっていることが多いかなという印象があるので、ここからさらに組織が成長していくとそれに伴ってEMという役割の定義も変化していくのだと思っています。 なので、今ある姿が、本当に正しい姿なのか？に対しては絶えず疑問を持つようにしています。 一言にEMといっても、人に強い人やプロダクトや事業に強い人、プロジェクトに強い人など、同じEMという領域の中でも強みは人それぞれだと思っています。 そのため、EMという定義を頑なに1つ定めてそれ以外は違うと否定せずに、カイポケEMの軸を1つ作って個々人の強みを発揮していけるような役割定義を作っていけたらと考えています。 最後に今後どうしたい？ 色々とやりたいことはあるのですが、まずは、しっかりと組織のパフォーマンスが発揮できる環境を継続的に作り上げていきたいと考えています。 常々、外的要因や内的要因によって組織は変化していくものです。 どんな変化にあったとしても、常に変わらない最低限のパフォーマンスを維持しつつ、柔軟に最大限のパフォーマンスを発揮するためにはどうしたら良いかを考えて素早く実践できるような体制を作り上げていきたいと考えています。 たくさんの記事に溢れているような様々なこれまでにはない新しいアイデアを常に積み上げるのは難しいなと感じています。 それよりも当たり前にできていることをたくさん増やすことが今の組織にとっては最良の選択肢だと考えます。（簡単に育成と一言で言っても、けっこう大変ですよねw） 自分自身は、地道にコツコツと組織が良くなることを一つずつ積み重ねていこうかなと思いました（地味ですけどw） 最後に、ちょっと告知です。 最初の方でも少しご紹介させてもらいましたが、カイポケの開発組織では、絶賛、エンジニアリングマネージャーを募集中です。 www.wantedly.com 組織として人の育成やチームをより成長させるにはどうするべきか？など、まだまだ組織が未熟な状態です。 そのため、以下のような人とはお話をさせていただきたいなと思います。 人に対して、如何に成長をさせていけるか？（育成）、組織へ入ってきてくれた人たちが活躍していくにはどうするか？（オンボーディング）を一緒に人の成長を喜びに人に熱い気持ちを持ってくれる人。 プロダクトへの貢献を、組織としてどう達成していくかを意思決定をして組織・プロダクトの舵取り役としてプロダクト・組織の成長に対して組織マネジメントの観点で急成長を遂げるプロダクトに携わってみたいと思っている人。 これら以外でも、もっと人と組織に対して、働きかけをしたいと考えているここまで読んでくれた方。 まだまだ未熟な組織ではありますので、ご自身の手で組織をより良くしていける余地はたくさんあります。 ちょっと気になるな？と思った方は、まずはカジュアル面談でもいいのでお話しましょう。 *1 : プロダクトマネジメントトライアングルというプロダクトマネジメントの役割・定義をまとめたものがあります。その派生として、エンジニアリングマネジャーの役割をまとめたもの。

医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで介護事業者向け経営支援サービス『 カイポケ 』でQA組織の管理者をしている清水です。2019年1月に入社し、QA組織の管理者として組織づくりや体制強化を進めてきました。 本記事は入社した当時の状況から現在にいたるまでの組織強化の過程、QA組織としてこれからの展望をまとめたものです。 カイポケQA組織の歴史 カイポケはサービスを開始してからありがたいことに介護業界でのニーズが高く、サービスの拡大を追う形で開発組織形成をしている歴史があります。 QA組織はできてからの歴史が浅く、元々QAのメンバーはカイポケの機能チーム毎に開発の一部としてテストを実施するメンバーで配属されていました。2017年頃より品質を独立した組織で担っていくことをミッションとし、機能チームに特化せず独立したQA組織をつくりはじめました。 QA組織をつくりはじめたものの、カイポケの成長スピードの速さとサービスとしての複雑さもあって、安定した品質を実現することのできる組織の構築には時間がかかっていました。そうした状況下で、業務委託メンバー中心であったQA組織に、最初の社員として入社したのが私でした。品質保証の精度を上げるための取り組みを、スピード感をもって進めることが主な使命でした。 入社当時のQA組織の状況とこれまで 前述の経緯で縁があり2019年1月に入社しましたが、QA組織に加わった時の印象はよく覚えています。「やることがいっぱいだ」と。 当時、QA組織としては、リリース前の品質に対して防波堤以上の役割で価値貢献がほとんどできていませんでした。そのため、エンジニア側の期待感との温度差があったり、検証業務以上の関わりができないためQAメンバーがキャリアパスを描けずに組織を離れたりと、入社してすぐに様々な課題が目につきました。 また、俯瞰した目線でQA組織としてあるべき姿、求められている姿からと乖離があったとしても、最低限の検証業務自体はできているため、かえって状態の健全・不健全さが一見すると分かりにくい状態でした。そのため、危機意識や課題感があまり強く持たれておらず、取り組むべき課題の整理に苦労しました。 その上で大なり小なり取り組んだ課題は多いのですが、主に以下3つをまとめましたので各取り組みに関して掘り下げて紹介します。 QA組織として目指すべき指標の設定 テスト観点の妥当性考慮不足への取り組み 課題解決を担えるQA組織のメンバーの採用・育成 課題について詳しく書く前に、あらかじめ断っておくと、入社時は（確かに課題は多かったものの）ネガティブな印象だけではなく、ポジティブな印象も数多くありました（そしてそれは現在でも変わっていません）。 まず、QA組織のメンバーはサービスへ向き合う姿勢はしっかりと持っており、一緒に取り組んでいきたいなという気持ちが強く持てました。 またエンジニアに関しても、過去経験してきた現場ではQA組織の発言権が弱く対等に話ができない場面も数多く遭遇してきましたが、エス・エム・エスではエンジニアとQAが対等に業務に取り組める環境です。またエンジニアはスキル感や成長意欲の高いメンバーが多いため、働きやすいという印象は今も変わっていません。 環境に関しても上司は品質への意識が高いため、試行錯誤で失敗したり、芽が出るのが数年スパンの施策でも取り組む際に積極的に後押しをしてくれました。このことがが、後述するように苦労した点は多かったものの、モチベーションが下がらずやれた要因であったのではないかと思います。 QA組織として目指すべき指標の設定 一般的なQA業務は検証だけに留まらず非常に幅が広いため、現場によって役割が大きく違ってきます。 エス・エム・エスでは、QA組織ができてからは機能仕様が固まった段階から参画することが多く、リリース前の防波堤の役割に注力しており、検証業務がメインとなっていました。 また、プロセスが決まっておらず人により成果の差が激しかったほか、案件がワンショットで終わっているため、問題が起きた際の課題解決への取り組みも積極的に行われず、品質保証としては非常に不安定な状態でした。 さらに、解決に向けて難易度を上げている要因として、あるべき論の理想からチームに反映させようとするとハレーションが起きやすいこともありました。カイポケには機能チームが当時4つあり、各々のチームで独自の開発スタイルを持っているため、QA組織として取り組むべき課題と各チーム毎で取り組むべき課題とで分かれていたことが理由の一つです。また、QA組織の設立からの歴史は浅くても、検証業務自体は歴史があり、業務スタイルが一定文化としてあったため、抜本的に変えようとして大きく失敗した経緯もありました。 そこで、まず検証業務プロセスのフローやフォーマットを策定し、各チームでの不足分の明確化やプロセス導入への障壁を下げることを試みました。 図：キックオフ以後リリースまでの流れのフロー また、QAの役割についての意識を合わせることにも努めました。QAは、品質を担保・向上を担う役割として、検証業務以外にも要件定義から参入し、検証業務の中で培った操作に関する知見や、顧客要望の分析の成果を活かしながら、関係者と仕様を決めたりと、開発プロセス全体に関わっていくべきだと私は考えています。この点を繰り返しミーティングなどの機会で伝えるようにしました。 一方で、べき論だけでは具体的な行動に結びつきづらいこともあるので、プロセスの中に行うべき作業や、作成すべき成果物を定義し、運用をしていくなかで、徐々に身につけていけるように工夫しました。 自身で何が必要かを考えること、業務を行うなかで自然と意識付けられていることの両面で取り組んだことで、まだ取り組むべき課題はありますが検証業務以外にも意識は向けられるようになってきており、メンバーから取り組みたい施策の要請があるなど、成果を感じています。 テスト観点の妥当性考慮不足への取り組み 検証業務に際しては、テスト観点を作成しますが、従来作成していたテスト観点には妥当性を欠いている部分が多々ありました。つまり、本来であればテストをしなければならない観点が脱落してしまっていたり、逆にテストが必要ではない（修正の影響範囲外の）観点が入っていたりしました。限られた人員・時間で検証を行うためには、テスト観点の妥当性を向上させることが不可欠です。 妥当性を欠く主な要因としては、大きく以下の2つが挙げられます。 １：カイポケの構成が複雑で影響範囲の把握が難しいこと カイポケは本記事冒頭でも記載した通り、サービスの急成長に長期的な運用を考慮した構成が追いついておらず、影響ないと思われた機能で不具合が発生することもあります。機能追加や変更時にエンジニアと影響調査を確認しますが、現状では明確に範囲の線引きができるには至っていないことがあります。 QAの職責として、「不安なので検証を行おう」という姿勢でよしとせず、影響範囲に絞って検証を行うことを目指していますが、今のところは、「影響しないであろう」といった場合でも影響がないと根拠をもって言えない場合は、回帰テストのボリュームを減らせずに実施しています。 ２：検証条件の組み合わせの検討不足 カイポケ自体の仕様として組み合わせが非常に多い機能であり、粒度を粗くすると特定の組み合わせの不具合を見逃してしまいやすく、逆に細かくすると途端に工数が膨大になってしまうため、バランスを考慮しながら観点を作成する必要があります。しかし、まだまだ過分な組み合わせを実施していたり、条件の考慮不足から本番環境での不具合に繋がったりもしています。 課題を一掃できる銀の弾丸は存在しませんが、QA組織の内部に限定せず、エンジニアと一緒に「何ができるか」を考え、様々な施策を試しながら妥当性の向上を図ることを通じて、本番環境での不具合の減少や、品質を維持したままでの検証工数の削減が少しずつできるようになってきています。以下は取り組みの例です。 エンジニアとのコミュニケーション・シフトレフトへの取り組み 影響範囲を双方案件の早い段階から意識徹底 案件の振り返りで特記事項を関係者で共有 各案件での検証を通じた知見をQAチームとして次回以降に繋げる テスト結果の分析 ポストモーテム開催等で不具合発生傾向を分析し次回以降に繋げる 定期的な関係者間でのコミュニケーション Dailyでの朝会や昼会 プロダクトへの理解向上 カイポケを学ぶ時間を増やしたり、知見者から使われ方を学ぶことでユーザーストーリーを意識し観点作成精度を高める 課題解決を担えるQA組織のメンバーの採用・育成 入社当時は、検証ボリュームに対してQA組織のリソースでは足らず、開発や事業部など関係者にも手伝ってもらうほどでした。そのような状況の中では、検証だけで満足せずに、不具合を作りこませないなどといった課題に取り組むことは到底できませんでした。 このような状態からのスタートでしたので、もちろん、まずは検証業務を十分に実施できるようにすることが最初の一歩ではありました。しかし、検証業務ができるというのはあくまで通過点です。目指していたのは、当初から課題解決に取り組めるようなQA組織の構築でした。そこで、検証業務に特化せず俯瞰したチーム運営の経験や、課題解決能力が高いというスキル、当事者意識をQAエンジニアが持てるように、採用や育成、価値観の共有に取り組みました。 採用に関してはスキルセットを時間をかけ精度高く作成しミスマッチを極力防ぐようにし、リソースは不足しているものの妥協せず人選し定着率を上げることで、結果として長期で課題に取り組む際の交代引き継ぎのコスト削減に繋がりました。 また、育成に関してはメンバーがやりたいことや学びたいことを優先しながらチームに還元できる事を話し合うことを重視しました。必ずしも直近の課題解決に繋がらなくても取り入れることで、モチベーション高く取り組むことができました。そして直接的に繋がらなくても何かのタイミングで役に立つことがあったり、モチベーションが高く維持できることで他の施策にも意欲的に取り組めたりしました。 結果2年ほどでQA組織も大幅に拡大し、検証ボリュームに対しQA内でこなせる体制にはなりました。今では、チーム内で課題を出し解決に向けて対応を行ったり、防波堤としての役割から関係者と共に早い段階からQAとして指摘を仕様に反映させるなどの取り組みができる体制になってきています。 これからQA組織として目指していきたい姿 ここまで、入社時に感じた課題への取り組みを書いてきました。最近では、（もちろん課題は全て解消できているわけではありませんが）「QA組織としてのあるべき姿」を意識して、その実現に向けた取り組みにも手をつけられるようになってきました。 私が考えるQA組織として目指したい姿は、「ユーザーに人に教えたいと思えるようなサービスを、品質という観点から手助けできる組織作り」です。すべてはここが原点であり、目指す姿だと思っています。 人に教えたいと思わせるには、基本的な機能や品質が充足していることに加え、使用していて「使いやすい、便利！」と思ってもらえることが必要になります。 基本的な機能や品質が充足するには、前述で書いた品質を安定的に担保できる仕組みの構築と運用を行う必要があります。また、「使いやすい、便利！」と思われるにはユーザーの使い勝手や求めているものを正確に分析し、素早くリリースできる体制が必要だと思います。 このような考え方に立脚して、「では、そのような仕組みや分析を実現するにはどうすればいいのか」、というように、目指す姿から逆算して現在の位置を把握し、どんな課題を解決する必要があるかを考え、取り組んでいます。もちろん、これはQA組織だけではなく、カイポケに携わる開発者やプロダクトマネージャーを含む様々な関係者と一緒に行うことです。 その上で直近では以下の内容の取り組みに特に力を入れています。 テスト自動化 属人化せず連続性のある品質保証 検証だけでなくサービスを運営する上で全ての品質に関わる テスト自動化 テスト自動化に関してはまずE2Eテストに注力しています。マニュアルでの検証や、テストシナリオの運用工数を極力減らし、自動化できない観点、たとえば探索的テストなどに、よりQAエンジニアが注力できるようにしていきます。今後はエンジニアと協働し、単体・結合といった各フェーズでもどういった取り組みができるかを考えていきたいと思っております。 属人化せず連続性のある品質保証 属人化しない、連続性のある品質保証を行うには、検証業務プロセス整備の強化・知見の共有強化を通じて、どのメンバーであっても安定したパフォーマンスをだせるようにします。 現場の状況を加味し、都度チューニングしながらチームとしての最適な体制とは何か、どういったアプローチで理想に近づけるかを関係者と一緒に考えています。 また、カイポケ、介護業界、ユーザーによる使われ方など、検証する上で必要な知識が属人化しないよう定期的なミーティングや社内資料の作成に力を入れています。 検証だけでなくサービスを運営する上で全ての品質に関わる QA組織は検証業務にフォーカスされがちですが、仕様策定段階からサービス運用時全てでQAの組織が関わっていくべきと思っており、品質を向上させる上でQA視点でどういった施策が取れるかを考える必要があると思っています。 特にQAとしての役割は近年品質を保証することから管理することに意識が向けられています。品質の管理とは、不具合を作りこませないために何ができるかという事を考え、対処、改善する時にリードしていくことだと思っており、私自身そういった組織を作りたいと思っています。 図：QAの関わり方イメージ 取り組みとしては長期的で戦略・人材が欠かせず、現在は賛同してもらえる関係者を少しずつ巻き込みながら育てています。 さいごに 本記事では、カイポケにおけるQA組織とその活動について書いてきました。本文でも紹介したように、課題はまだまだありますが、より良い状態に対して日々取り組んでいます。課題への取り組みに際しては、開発者や上長の協力も受けやすく、「これをやってみたい」と思えば実際に取り組むことのできる組織です。自分で課題を見つけて、それに対して解決を試みるような動きはしやすい環境なので、QAエンジニアとして自身のやってきたことから更に1つ上のステップに挑戦してみたい方が合う環境だと思います。 カイポケでもまだまだやりたいことが数多くありますし、カイポケ以外のエス・エム・エスのプロダクト（たくさんあります！）にもQAの活動範囲を広げていきたいとも思っていますので、興味を持ってもらえた方がいらっしゃれば、ぜひお気軽にご連絡ください。 図：私が思うQAエンジニアとしてのキャリアアップのイメージ

エンジニア組織の内製化を進めるには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。エス・エム・エスは2015年よりエンジニア組織の内製化に取り組んできました。そのプロセスとそこで得られた反省や学びを技術責任者の田辺に聞いたインタビューの後編です。 tech.bm-sms.co.jp 前編では、2015年の入社から1年半くらいの間にやったことを話しました。リサーチから始めて会社の特性を理解しにいくということと、小さく始めて検証をするというスタートをきり、小さな新規サービスの立ち上げに上流からかかわって、アジャイルな開発がうまくいったということでした。 エス・エム・エスは当時40近い数のサービスを展開していたのですが、最初の1年半で内製化を進める主要なサービスと注力をせず終了するサービスや CMS 化で開発能力を必要としない体制へ切り替えるサービスといった仕分けをしています。主要サービスの多くは開発体制の規模が小さかったため、内製化が進んでいる状況です。後編では、主要サービスであるが開発体制が大きいためほぼ内製化の進んでいなかった「カイポケ」の内製化をどう進めたのかと、そこからの学びを中心に取り上げます。 1. 主要サービスの改革に挑む 当時の「カイポケ」は、どのような状況だったのでしょうか？ 田辺 　カイポケは、2014年にサービスのコンセプトを変更して、従来から提供していた介護保険請求の機能に加えて、経営管理・ファクタリングなど介護事業者の経営改善に役立つ機能をワンストップで提供するサービスにリニューアルしていました。 このリニューアルはその先のビジネス展開で非常に重要なものでしたが、一方でサービスの機能を急速に増やしたことで開発するソフトウェアの複雑さが増したことや、利用者の増加による負荷の増大など新たに解決しなければならない課題が見えてきている状況でした。 開発体制は、どうだったのでしょうか？ 田辺 　開発の拡大にあわせて開発組織の規模も大きくなり、当時は開発者とテストエンジニアを合わせると総勢100名を超え、それとは別にオフショアの開発チームがいるという大所帯になっていました。これだけで通常のサービスの1社分くらいの大きさの開発体制です。 最初はどのようなことから始めたのでしょうか？ 田辺 　ここでも最初にやったことは状況の把握です。私はこれまでにも自身として初めての開発現場に入っていき、課題解決をしていくという機会を何度か経験しています。そうしたときによく最初にチェックしにいくいくつかの要素というのがあります。このときもそこから状況を見に行きました。 見に行った点というのは次のようなものです。「要求の流れはどのようになっているのか」「起きている問題とそこへの対処の方針はどのようなものか」「構成管理はどこまでできているか」 なるほど。それぞれどのような内容なのでしょうか？ 田辺 　「要求の流れはどのようになっているのか」から説明します。要求というやや古めかしい言葉を使いました。これは少し広義にサービスとしてのカイポケへ求められる期待全般を指しています。カイポケのようなSaaSには、利用しているユーザーからの要望という形の期待もあれば、社内のセールスやカスタマーサクセスといったサービスを一緒に支えている人たちからの依頼という期待もあります。 こういったバックログをつくる一歩手前くらいの要望や意見、依頼といったものが、どこからどのように来ているのか、それを誰が知っているのか、それをどのように評価しているのか、「やると決めたこと」となるまでにどのような意思決定のプロセスがあるのか。そういったことを理解するのが、最初の「要求の流れはどのようになっているのか」というものです。 次に「起きている問題とそこへの対処の方針はどのようなものか」です。組織で起きている問題を理解しにいくには、起きている問題を具体的に見てみるのが一番です。そのときに見るのは、なにが起きているのかということ自体よりも、「それをどのように扱っているか」というプロセスのほうへ注目します。起きている問題をどのように評価しているか、そのときにどういった点を考慮しているか、解決すべき点をどこに置いて、どのようなアクションをしているか、その過程の意思決定ではどういうロジックで考えているか。こういった一連の流れを「自分だったら同じ問題をどう扱うのか」と比較して評価します。こうすることで、その現場の癖や制限といったものが見えてきます。 最後に「構成管理はどこまでできているか」です。これは単純にバージョン管理ツールが使われているかということも見るのですが、もう少し広い範囲を見に行きます。本番へデプロイしてユーザーがさわれる環境をつくるために、なにをどこまでどうやって管理しているのかを見るのが基本です。管理されている資源から環境を構築できるのかというのが次に見ている点で、構築された環境で変更が本番へ適用されるまでにどういう段階があり、それぞれでどういう品質が実現されているのかというところまでを見に行きます。ここは改善活動の基礎になるため、最初に見に行くことにしています。 見に行った結果、どんなことが分かったのでしょうか？ 田辺 　知りたいことを見に行った過程では、当然、実際に働いている人たちからはいくつもの課題や不安の声が挙がっていました。こういった場面で、リーダーシップを発揮する役割の人がするべきことは問題に構造を与えて、そこに優先順序をつけることです。なにを問題とみなして、それがなぜ起きているのかを解き明かして説明することが最初のステップになります。 このときに私たちが重要な問題だとみなしたのは次のものでした。「要求の管理があいまい」「問合せ対応やそれにまつわる作業が多く日々が消耗戦になっている」「内部品質向上のための組織能力が不足している」「ドメインである介護保険請求がそもそも難しい」 「問合せ対応やそれにまつわる作業が多く日々が消耗戦になっている」というのは新しい話ですね。これはどういう点で問題だったのでしょうか？ 田辺 　消耗戦というのは大量の人や時間を投入しながら、そこから未来へつながる価値が得られない活動の比喩として使っています。カイポケでは介護保険請求という非常に複雑な計算を伴う業務を扱っていて、この使い方や挙動についての問合せへの対応を開発チームでも行っていました。カイポケには充実したコールセンターの専任チームもあるのですが、問合せの内容によっては、コードを読み解いてプロダクトの詳細な仕様を調べなければわからないことや、バグなのか正しい挙動なのかを判別してお客さんへ回答をする必要があり、介護保険請求の業務の締日までに対応をしないとお客さんの業務が止まってしまう *1 ような問合せもありました。とくに月次の請求業務の締日間近の期間では、こういった問合せの頻度が高く、開発者が緊急度高く対応する必要がありました。 そうした状況の中で、日々のユーザーの困りごとを解消していくためにアドホックな対処をしていくこともたびたび起きており、それによってマニュアルオペレーションでの定常作業が増えていくといったことが起きていました。 利用してくれるユーザーに迷惑をかけたくないという一心で日々を回していくことへ強いコミットメントを持っている組織でしたが、そうした状況に疲弊している人も増えてきていました。 ここで問題視したのは「問合せへ対応していること」ではなく、「問合せ対応とそれにまつわる作業によって、そういった作業が発生する状況の根本解決へ時間を使えていない」という点です。結果的に個人の熱意を燃料にして日々はどうにかなっているものの、将来に向けての問題解消の見込みはないという状況が生まれていました。 これは問題を抱えながらもコミットメントが高い組織が無自覚に陥りがちな罠で、あちこちで見かけることがあるため、「消耗戦の悪魔のループ」という呼び方で説明をしています。 2. 混乱する現場でよく見られる、消耗戦の悪魔のループ 「消耗戦の悪魔のループ」とは恐ろしげな響きですね。どういうものなのでしょうか？ 田辺 　このループは、まず品質が悪いソフトウェアがあるというところからスタートします。ソフトウェアの品質が悪いと、デグレードが起きたり、必要な機能が不足したりします。すると、それを解決するために割り込みの作業が発生します。バグがあればその調査や修正の対応が必要ですし、機能不足のときにはそれに伴うオペレーションの作業が発生したりします。その割り込み作業がゆとりを奪って、さらに品質が悪くなるというループです。品質の悪さに対して個人の頑張りと労働量で支えているのですが、何か手を打たないと、時間とともにつらさが増していきます。構造としてジリ貧になるんです。日々が忙しくてつらいと言っている現場は、大体こうなっています。 「消耗戦の悪魔のループ」はどうやって抜け出せばいいのでしょう。抜け出し方はあるのでしょうか？ 田辺 　抜け出すためにはループを逆に回す必要があります。どこを起点にループを逆に回していくのかですが、まず、無理やりゆとりを作り出すことから始めます。よくやるのは、「固定の時間をゆとりのための時間として確保して守る」「理解を求めて依頼を断る」「チームを分けて割込から守る」といった手段です。こうして作ったゆとりの時間を品質の向上へ投資をしていきます。大事なのは品質へ時間を投資するというときにどこへ投資するかです。 カイポケではどこへ時間を投資することにしたのでしょうか？ 田辺 　この時点で決めていた投資対象は主に2つです。一つ目はインフラの体制強化とオンプレミスからAWSへの移行です。内部品質の向上が一朝一夕ではできないことがわかっていたため、地道な改善をしていくための時間を稼ぐ魔法を考える必要がありました。そこで強力な外部のインフラエンジニアを頼って一気に体制強化をして、アプリケーションを改善するまでの間の安定運用を実現することにしました。偶然そのタイミングで前職の優秀なエンジニアが ELASTIC INFRA というインフラの総合支援サービスを始めるということを聞いていたため、事情を話して協力してもらうことにしました。 二つ目の時間を投資する対象は、カイポケのコアのドメインである介護保険請求の改善です。Vertical SaaS であるカイポケは機能が多いため、全面的に改善に取り組むよりも、難度が高いところを局地戦にして戦力を集中させていくという方針を立てました。 3. 開発現場再生の 3 ステップで改善を進める 消耗戦に脱線しましたね。状況把握を進めた結果、いくつかの重要な問題を設定したという話でした。そこからどのように開発体制を立て直したのでしょうか？ 田辺 　ここでは次の3つに取り組みました。 まずは、全体の流量コントロールです。それまではさまざまなレイヤーの個人間での依頼や交渉で決まっていることもあった要求を、一元管理するようにしました。私は「やりたいことを全部並べて一覧に見えるようにして、今なにが一番大事か順番をつけて意思決定する」というのはとてもパワフルなツールだと考えています。期日ではなく重要さを評価して順序をつけるというのは大きな発明です。最初はなによりもこの実現に取り組みました。なぜなら、ゆとりをつくるために「やらないこと」を決めたいからです。順序がないと「やらないこと」を決めるために個々の依頼や相談に対してそのたびの交渉をすることになります。 二つ目は、消耗戦の解消です。これには消耗戦が起きている原因を理解して直していく必要があります。日々の問合せややっている作業が発生している理由について、理解を正しくそろえます。問合せや作業が低品質や機能不足によって発生するというのは、毎日の目の前のことを進めているときには気づきにくいものです。目の前のことを進めることも緊急度が高く大事ですが、同時に起きている現象について理由を正しく理解して、理由の解決にも一定の時間を費やしていくことが重要です。 そして三つ目に、内部品質の向上です。構成管理とユニットテストと自動化といった基礎の整備 *2 を進めること。そして、本番にリリース可能なソフトウェアの品質基準を適切に置くこと。それを設計とレビューによってコードを通して共通理解としていくこと。チームやプロセスによってソフトウェアの内部品質を担保していきます。 この内容を「開発現場再生の 3 ステップ」と呼んで進めていました。 進めていく中で思うようにいかなかった部分はあったりしましたか？ 田辺 　たくさんありました。今でも起きていたこととそこへの解消の道筋というのは大筋で外していなかったと思います。ただ、それでも過程では思ってもいないような形の苦労というのは多かったです。失敗もたくさんしています。 その中でも最大のものは、介護保険請求というドメインの難易度が高いこととそれにまつわるアプリケーションの改善が想像より何倍も大変だということです。 正直、技術的な課題だけであればもっと短期で課題の解消をしていけたと思うのですが、それが複雑なドメインとからんでいることで、技術の課題を単体で解消することができないということも多いです。ドメインに根ざしたところの難度を適切に見積もるというのは方針を考える上で重要だなと何度も学びました。 カイポケの改革は 3 年を超える長期戦ですよね。そうした中で苦戦や失敗をしているとビジネスや経営からの重圧というのは強くなったりしないんですか？ 田辺 　もちろん早く解決をしていきたいよねという話はするのですが、実は苦戦や失敗に対しての非難や重圧というものは取り組んでいる期間を通じて一度もなかったのです。これは他の会社ではあまりないことかもしれません。 エス・エム・エスという会社は仮説検証を非常に大事にしている会社です。そして、思考することも大切にするのですが、ある程度から先はやってみないとわからないという実践から学ぶ会社でもあります。それが建前でなく徹底しています。たとえばこうした改善をしていく場合にも、アプローチの良し悪しがわからない程度に様子を見ながらやって無難な変化になるよりも、ある程度結果がはっきりと出るくらい試しきることを良しとするという文化があります。もちろん、試すということは失敗するということもあるのですが、それは「仮説の検証が進んだ」としてプラスにとらえるのです。 そのため、私はこのカイポケの変化を進める過程で失敗に対して謝ることを求められたということがありません。プロフェッショナルとしての仕事が前提にはなるのですが、その信頼の上で働けるというのはやりやすい環境だと感謝しています。 4.エス・エム・エスにとって、技術活用のあるべき姿を実現するために あらためて、時間を戻せるなら、やり直したいことはありますか？ 田辺 　小さく試すという話とは矛盾しますが、文化や組織など仕組みを大きく変えにいくタイミングというのは別の選択肢があったなと思います。今振り返ると、もっと全体に対して大きく変えにいくことで、変化が早まった可能性があります。状況の変化を把握して、そのときに合ったやり方に変えるタイミングが大事なんだと思います。 内製化の場合もそうですが、変化に適応できる人とできない人が出てきます。でも、最初のうちは、変化を起こす人は少数派です。小さな変化が蓄積していくことで、それが多数派になってくる。そういう変化のフェーズに合わせて、やり方を変えるということです。 理解が進んでおらず変化が起きていないときに、一気にいくとぼろぼろになります。だから、初期の段階では、戦力を集中させて個別に進めていく。そのため、どうしても時間のかかる場面が出てきてしまいます。 一方、理解が進んできたフェーズでは、総量を増やして一気にいったほうが、全体の変化は早くなると思います。 組織の文化や制度・教育・採用などを含めて、次回やるなら、一気に変えるタイミングをもうちょっと早くしてもよかったかもしれないですね。 今後、エンジニア組織について、どんなことに取り組んでいきますか？ 田辺 　内製化が進み、サービスの成長やお客さんに向けてプロダクトをどう良くしていこうかというフェーズに来ています。ようやくエス・エム・エスの戦略のよさを活かしたうえでプロダクトによるさらなる成長を求められる段階に来たと思っています。 ここからは、技術によってプロダクトがより大きなインパクトを残せるようにしていきたいと考えています。エス・エム・エスのやっているプロダクトは社会に直結しているため、私たちが良い仕事をするとそれが世の中を良くすることに自然とつながっていくのが良いところです。これまでに培った技術でこれからの社会を良くしたい人にはぜひ一緒に取り組んでほしいと思います。 最後までご覧いただきありがとうございました。 内製化という難儀な仕事に向き合う技術組織の責任者の方の一助になればと思い前後編とまとめましたがいかがでしたでしょうか。 田辺が最後にも触れていましたがエス・エム・エスは実践からの学習を徹底している仮説検証を非常に重視している会社です。開発の一つ一つの現場もそうですが、組織の大きな変革においてもこの思想で長期目線で取り組んでいます。 もしこの記事を読んでいただき、このようなエス・エム・エスに興味をもっていただければ、ぜひカジュアルにお話しできれば幸いです。 *1 : 介護保険請求という業務の特性上、最終的にお客さんのキャッシュフローへ直結して売上の入金額が変わってしまうこともありえる重要なものなのです *2 : 構成管理とユニットテストと自動化が品質の基礎であることを教えてくれたのは達人プログラマーの The Pragmatic Starter Kit Series でした。そしてたしか以前一緒に働いていたときに @t-wada がこの3点を「現代の基礎」だと言っていたことで自分の中に定着した気がします。そこから10年以上経ち、もはや知恵にもならないくらい当たり前のものになっていますね

はじめまして。高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている菅井俊介です。2019年7月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発・運用を担当しています。 カイポケでは、エンジニアとビジネスサイド *1 が積極的に協力して開発やサービス運営を行っています。今回、カイポケにとって大きなイベントである2021年4月の介護報酬改定を乗り越えた話を紹介しようと思います。 まず、介護報酬改定の概要とその重要性について簡単にお伝えします。 介護報酬改定とは 2000年から施行されている介護保険制度は、3年毎に第N期としてテーマを置いて大きな見直しが行われています。今回の2021年4月からは第8期となり、「感染症や災害への対応力強化」や「介護人材の確保・介護現場の革新」などのテーマが設定されています。 参考：厚生労働省から通知された2021年4月介護報酬改定の概要 この見直しのことを介護報酬改定と呼んでおり、そこでは、サービスの金額が調整される程度のシステム対応が軽微で済むものから、既存の計算の概念や仕組みを覆すようなインパクトのあるようなものまで、様々な改正が行われます。 介護報酬改定対応の重要性 介護報酬改定はカイポケにとって、重要なイベントです。 カイポケのコア機能の1つとして、介護事業所が行う請求業務を実現する機能があります。 この請求業務は介護事業者が収入を得るために必要な業務です。 通常、介護事業者は提供したサービスに対して、その報酬の9割を国に請求、1割を利用者に請求することとなっています *2 。これは普段私たちが病院に行った際に3割しか負担していないものとほぼ同じ仕組みですので、それを想像していただけるとわかりやすいと思います。 さらに国に請求する9割と利用者に請求する1割を計算する仕組みはかなり複雑です。もし自身で制度を読み解いて請求しようとする場合、自立する程の厚さがある本の3冊分の内容から、関係する内容を理解する必要があり、普段の業務を行いながら実施するのはなかなか無理がある作業となってしまいます。 そのため、介護事業者はカイポケのように請求機能をもつサービスを利用するのです。カイポケとしては、以上のように介護事業者の収入に直結する役割を担っているわけですから、介護報酬改定の内容を正しくシステムに反映することは極めて重要となります。 介護報酬改定を対応していく上での課題 以上のように、カイポケにとって重要なプロジェクトである介護報酬改定への対応ですが、この介護報酬改定対応を行っていく上で乗り越えないといけない課題がいくつかあります。 開発チームから密に情報共有を行うコストの高さ 開発期間の短さによる成果物への認識合わせの難しさ 全ての変更をシステム対応することの難しさ これらの課題とその解決に向けた取り組みについて、以下で具体的に見ていきます。 開発チームから密に情報共有を行うコストの高さ 介護報酬改定の内容を気にするのは社内のエンジニアだけではありません。カイポケを使っている介護事業者も、業務を行うためには介護報酬改定の内容を知る必要があります。 そこで、弊社としても、介護報酬改定の内容やシステムでどのように対応するかをユーザーの方々に画面上にポップアップ表示できる業務支援ツールを用いて案内したり、後述の特設サイトでまとめるなど、わかりやすく伝える取り組みを実施しています。 このような顧客コミュニケーションを円滑に行うためには、開発チームから社内の顧客接点となる部門に情報を提供する必要があります。開発チームはシステム改修の内容については当然ですが、改修するために介護報酬改定の内容も正確かつ網羅的に把握しているためです。 しかし、開発チームが情報共有にリソースを割いてしまうと、肝心の開発作業に集中出来なくなってしまいます。 そこで、開発チームのスループットを最大化するための取り組みとして、法解釈分析班や法改正窓口を設けて情報の整理を行いました。これらの役割は以下の通りです。 法解釈分析班：開発チームの中でもドメインに詳しいメンバーで構成され、法解釈とカイポケへの影響を把握し、開発チーム内や法改正窓口に連携する。 法改正窓口：ビジネスサイドの介護やシステム開発に詳しいメンバーで構成され、社内で取りまとめた質問を一手に回答する役割。ここで回答出来ないもののみが法解釈分析班に渡される。 こういった役割を事前に明確にして臨んだことによって、ビジネスサイドを通して介護事業者にも正しく情報伝達し、開発チームは実装に集中できました。 開発期間の短さによる成果物への認識合わせの難しさ 介護報酬改定は確定された内容の公開が施行の直前であるため、確定を待ってしまうと開発可能な期間が短くなってしまうという問題があります。 今回の介護報酬改定でも2021年4月1日から施行される内容の確定版が通知されたのは2021年3月31日でした。 介護保険事務処理システム変更に係る参考資料（確定版）（令和3年3月31日事務連絡） 後述するように、機能によってそれがユーザーに必要になるタイミングは異なるのですが、例えば請求を行う計算機能であれば、4月に提供したサービスの請求は5月1日〜5月10日で実施するため、4月末までには機能改修が完了している必要があります。 必要になる改修の規模は介護報酬改定の度に異なりますが、内容が確定してからの1ヶ月で開発が間に合うものではないことが恒例です。 そのため、前年10月ごろから少しずつ公開される大まかな方針や、未確定の情報から内容を把握し、対応内容の検討や実際の開発に着手する必要があります。 ここで問題になるのが、「正しいものを作れるか」という点です。ソフトウェア開発では、開発チームが実装した成果物が、顧客あるいはプロダクトオーナーが欲しいと思っていたものとは違うということがしばしば起きます。求める成果物についての認識を合わせることに失敗し、それに気づかないまま実装してしまうわけです。 介護報酬改定の場合は、元来の制度が複雑・大規模であることに加えて、不確定な情報から仕様を考えていくこともあり、特に上記のような問題が発生しやすくなります。 このような問題を避けるために、早期から介護報酬改定内容をキャッチアップし、関係者の間で認識を合わせていく会を実施しました。 会の概要 介護報酬改定について、内容の整理と共有、見立てをつける 法解釈分析班として3名を選定 法解釈分析班が事前に資料を読み込み 最大50人程参加（開発、運用、QA、カスタマーサクセス） 参加者は自由に発言 これを大まかな改正の方向性が出始めた10月頃から、ある程度内容が出揃う1月までの4ヶ月間、週に1度のペースで続けました。 参加者の中には元介護事業所の職員で制度に詳しい事業部のメンバーも多く、介護のシステムにまだあまり詳しくないエンジニアでも、改正される内容の概要だけでなく背景や目的について共通の理解を持って実装を進めることができました。 全ての変更をシステム対応することの難しさ 介護報酬改定は対応範囲が非常に広いため、全て期間内に対応する事は難しいという問題があります。 介護保険の対象となるサービス種類（訪問介護、通所介護など）の数は非常に多く、請求に関するルールはそれぞれに異なる部分があります。介護報酬改定では、全てのサービス種類に共通の変更もあれば、個々のサービス種類に特有の変更もあり、変更内容は多岐にわたります。したがって、すでに述べたような短い開発期間の中ですべてに対応することは困難です。 そのため、「全部を納期までにやり切らないといけない」という発想ではなく、「どうすれば限られた時間とリソースで顧客への価値提供を最大化できるか」という考え方で開発を進めていきました。 価値提供を最大化するために、システムでの対応の必要性や機能改修が顧客に必要となるタイミングの観点で、開発を行う優先順位をつけていきました。 介護報酬改定の内容の中には、請求のための計算方法が変わるなど、システムでの対応が不可欠なものもあれば、申請書のフォーマットの変更など、システムでの対応までは必要でないものもあります。こういった違いを見極め、必要性の高いものから対応を行うことで、エンジニアのリソースを集中して開発できました。 また、機能改修が顧客に必要となるタイミングという観点も重要です。 以下の図に示す通り、介護事業者は1ヶ月の中でも時期によって行う業務が異なります。 ある月に提供するサービスの計画は前月の下旬に立てるため、介護報酬改定の影響を受けたサービスの登録をはじめて行うタイミングは3月下旬になります。一方で、ある月に提供したサービスに関する請求業務は、翌月の1日~10日に行うため、介護報酬改定での変更内容を反映した形で請求を行うのは、5月1日~10日になります。 つまり、同じ4月施行の介護報酬改定への対応でも、計画を立てる機能に対して、請求のための計算機能は、顧客に必要になるタイミングが1ヵ月ほど遅いわけです。したがって開発する上での優先順位をつけることができます。 例：4月にサービス提供する場合の業務の流れ 以上のような優先順位付けを行うには、介護事業者の業務を深く知っている必要があります。業務を深く知る存在というと、「ドメインエキスパート」という概念がありますが、そのような社内のエンジニアに魔法のように介護業務の知識をもたらしてくれる存在は最初からいるものではありません。もちろん、元々詳しい人も社内にはいるわけですが、全てを知っているわけではないため、日頃の開発の活動や、介護報酬改定での取り組みを通じて、業務についての知識（ドメイン知識）を組織として身に付けていくことが必要です。法改正を通して身につけていくための活動を積極的に実施しています。 このような取り組みの一環として、先述した介護報酬改定の内容をキャッチアップしていく会や、新規機能開発の際のユーザーストーリーマッピングなどを、介護事業者の業務に詳しいビジネスサイドのメンバーの協力を得ながら実施し、エンジニアの中にもドメイン知識を蓄積していくことができています。 優先順位をつける際には、顧客が手動で対応できるものについてはその方法を案内するなど、システムで対応する以外の選択肢も持って判断することも必要になります。 この際、システム対応するものはその変更点や使い方を、システム対応の優先順位を落としたものはリリース予定時期や手動での対応方法について、顧客がわかりやすいように詳しくまとめた特設サイトをビジネスサイドに作ってもらいました。 このように、顧客にとって不可欠なものを必要な時期までに届けることに開発チームのリソースを集中投下しつつ、それ以外の部分についても顧客の業務に滞りが出ないようにしたことで、顧客へ提供する価値を最大化できました。 まとめ 介護報酬改定は、介護事業者の方々にとっても、カイポケを運営している私たちにとっても、大きなイベントです。このイベントを乗り越えるためには、技術的なスキルだけでなく、様々な工夫が必要になります。今回紹介した3つの取り組みには、ビジネスサイドの理解や協力が必要不可欠です。エス・エム・エスでは、このようなコラボレーションを実現するための基礎となる、エンジニア組織とビジネスサイドとの関係作りに、日頃から取り組んでいます。 こちらの記事でも紹介している通り、希望していただければ現場のメンバーからも話を聞くことも出来ますので、興味を持っていただけたら是非カジュアル面談からでも聞きにきていただけたらと思います。 tech.bm-sms.co.jp *1 : ビジネスサイド：本稿ではカスタマーサクセス、セールス、マーケティング、コールセンターなど、顧客とのコミュニケーションを行う部署などの総括として記載しています。 *2 : 年齢と所得に応じて、国負担額は7~9割、残りの1~3割が利用者負担額が異なります。

大手企業を筆頭に、エンジニア組織の外注依存から内製化にシフトしようとする企業の報道を目にすることが増えてきました。 一方で、実際にエンジニア組織の内製化を進めようとするには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。 実際にケースとしても世の中に少ないことなどもあり、エンジニア組織の内製化に関する方法論について紹介されたコンテンツは少なく、各社が手探りの状態でこの内製化に取り組んでいると思われます。 そこで、まさにこれから内製化という難儀な仕事に向き合う技術組織の責任者の方の一助になればと思い、エス・エム・エスが2015年よりエンジニア組織の内製化に取り組んできたプロセスとそこで得られた反省と学びについてを共有したく、50人超のエンジニア組織で技術責任者を務める田辺に内製化の全貌を聞きました。 1. 簡単なシステムだと思っていたが停滞していた なぜ、エス・エム・エスのサービス開発体制を内製化することになったのでしょうか？ 田辺 　もともとは内製化がゴールではありませんでした。私は採用時に社長の後藤から「今後のエス・エム・エスにとって必要な技術組織のあり方を白紙から一緒に考えてほしい」と言われて入社をしました。なので、内製化も含めてフラットにその時の会社に必要なものはなにかを考え始めたというのがスタートラインです。状況を見ていく中で、当時のエス・エム・エスのサービス開発体制にうまくいってない部分が散見され、それを改善する手段として、内製化にシフトしてきました。 元々のサービス開発体制、どのようなものだったのでしょうか？ 田辺 　エス・エム・エスは、2003年に設立されました。大きな一つだけのサービスを追いかけるのでなく、複数のサービスを同時に展開し相互の位置付けを変えながら、成長を図ってきた会社です。私は2015年の2月に入社しました。そのころ、すでにエンジニアが30名ほどいました。当時の社内では「他でやっているサービスに比べて、エス・エム・エスのサービスはシステム的に単純なものだ」という認識があり、サービス開発は外部へ委託しての開発が中心でした。 そのころのサービスは、どんな状態だったのでしょうか？ 田辺 　すでに介護や医療の業界で重要なポジションを担うサービスがいくつもあり、日々使われるサービスとしてはきちんと提供していましたが、内部ではうまくいっていないところが散見されていました。 たとえば、新しい施策をやろうとリリースしても、問題が発見され、いったん切り戻して、再度リリースすると別の問題が発生する。それを何度か繰り返しているうちに、半年くらい何もリリースされていない状態になっているといったことが起きていました。他には、パフォーマンスが問題になる場合もあり、そういったときにも技術の実装面を理解している社員がいなかったため、技術的な論理の通った解決というのができず対症療法的に凌いでいる状態でした。 そのような状況だったため、経営としても、会社のケイパビリティとして技術のコントロールにリスクがあるという認識だったんです。 そういった状況を理解したうえで入社されたんですね 田辺 　そうです。いろいろ課題があるんだけど、そこは”現場の課題あるある”だと思ったので、過去の経験から自分が頑張れば解消できると受けとめていました。その上で、会社としては白紙から技術組織のあり方を考えてほしいというオーダーだったため、上場企業で経営直下でゼロからそれを考える機会は面白いと思いました。 ですので、最初から内製化がゴールだった訳ではありません。会社として、経営の中での技術レイヤーの根本的な課題を解消できる人材を求めていたのだと思います。 不安はなかったのでしょうか？ 田辺 　もちろん不安はありました。ただ、これまでのキャリアで似たような状況の現場で働くことが多かったため、確認するべき重要な点はわかっていました。それに基づいて、入社の前に確認したことが2つありました。 ひとつは、現場のエンジニアに味方になる人がいるか。変化を起こすのは一人ではできません。必ず、現場で味方になってくれる人が必要です。そこで選考の中で、「一番できるエンジニアと話をさせてほしい」と伝え、話をさせてもらいました。話してみると、エンジニアとして話の通じる人で、これなら一人でやらなくても大丈夫かな、と計算しました。 もうひとつは、経営で上司になるのがどういう人なのか。現場の課題解決をしていく中でも、本当にタフな意思決定をするときにはどこかで必ず経営上の判断が必要になる場面がやってきます。そのときにはたして信頼できる人物が経営にいるのかが重要です。当時のエス・エム・エスの場合、経営にエンジニア出身の人はいなかったため、判断を委ねる上司としてというよりもチームを組む同僚として信頼ができる人間がいるかが重要になってきます。結局、社長直下のポジションというオファーだったのと面接で複数回会っていた社長の後藤が同僚として働きやすそうで信頼できると感じたため、あとは現場の技術課題を自分がどうにかすればいいかなと、入社することにしました。 2. 開発組織の戦略と制度を固め、経営層と握る 入社して、最初にどんなことをやったのですか？ 田辺 　最初の2か月くらいは、リサーチですね。まずは、なにはなくとも現地現物。1次情報を聞きにいく。そのとき、自分のなかで仮説を立てたうえで、一番多くの現象を解決できる根っこになっている問題を見つけられるよう話を聞いていきました。 最初に知りたかったのは、エス・エム・エスのやっている事業や仕事のやり方の特殊性はあるのかです。私が知っている一般的に良いサービス開発を実現していけばよいのか、それともエス・エム・エスという会社特有の事情でそうではないものを探したほうがいいのかを理解しようと考えました。前者であればやるべきことがはっきりしますし、後者であれば固有の事情にあった解決を探すのが一番難度の高い問題になるためです。 たとえば、先ほどの「エス・エム・エスのサービスは他社に比べて単純で、高度な開発能力は必要がない」というのが真実で、それにあった事業開発のノウハウというので成り立っている会社なのであれば、私の知っている技術的なプラクティスが合わない可能性もあるわけです。 リサーチした結果、どんなことがわかったんでしょうか？ 田辺 　エス・エム・エス固有の特殊性というものはなく、シンプルに良いサービス開発組織を目指せばそれが会社にとっても良い方向へ行くだろうということがわかりました。 そもそも、エス・エム・エスでやっていることは、多様で複雑なことでした。複数の事業とサービスがあり、それぞれのシェアや成長段階、事業規模が違っています。それらの掛け合わせで、まったく特性の違うたくさんの事業が一つの会社に混在していたんです。 開発しているサービスも、簡単なものではありませんでした。本来実現したいサービスというのは、他社のサービスと比べても簡易な要素はほとんどなく、簡単ではないものを簡素なツールで組み立てていたので、簡単だと誤解していただけでした。 また、事業と開発組織の関係は、社内請負のような関係になっていました。エンジニアの主な役割は、事業部からの依頼から機能要件をまとめて委託先との間に立って通訳をしたり調整をする役割でした。するとエンジニアは、市場やユーザーに向けて製品を作っているのではなく、事業部という社内の人の依頼へ応えようと考えがちになってしまいます。社内の期待へ応えようというのはけして悪い考えではないのですが、あくまでその先のユーザーやマーケットというのを見て、ソフトウェアにとっての長期的な価値や影響の判断をしていくということとセットなのが重要です。 開発現場の課題については、”よくある現場課題あるある”という感じで、当時でも他の開発現場では効果が出ていたモダンな開発プラクティスが浸透していない状態でした。 まとめると、つくるべきサービスは特に他社と比べても簡単なものではなく、むしろサービスの多様さと相互の連携を考えると十分に難易度が高く、プロダクト開発のやり方やソフトウェア開発のプラクティスについても一般的によいとされることを実践していくことで改善していけるという手応えは感じていました。それができる強い開発組織をつくっていくというのが目先のゴールとして間違っていないだろうというが最初のリサーチで出した結論です。 そこから、どのような方針で、開発体制を立て直したのですか 田辺 　次々と新しい事業を作り続け、それを長期で成長させていくという事業展開の仕方を考えると、目指すべき開発の姿勢というのは、小さく正しく作り、事業の成長段階に合わせて少しずつ正しく大きくしていくことでした。それを、リスクと投資を時間軸に対して分散させる。それが事業構造に合っているし、本来必要とされていることでした。 これを実践していくには、ビジネスとプロダクト、そして技術に対して先を見据えてバランスを考え続けられる能力を持ったエンジニアが必要です。ビジネスの規模に応じてアーキテクチャのレベルでそのときの適切な形を考えられる技術力が必要ですし、エス・エム・エスという会社の複雑な事業モデルや事業の成長のさせ方を理解し、その先の成長で起きることを想像することも必要です。これは他社で言えば、CTOに相当する能力です。これを複数の事業で同時に進めていくことになります。このためにはそういう人材を生み続けられる強い開発組織が必要になります。 そこで、エンジニアという職種のあり方について組織戦略をつくり、経営と話して目指す方向をそろえました。エンジニアに求める仕事内容や水準も変えることになり、評価制度も改めました。制度だけ決めても動いていかないので変化のための時間軸も決めました。3年で変化しきることを目指して1年ごとにステップを置きました。社内が変わっていくことも必要ですが、実現のスピードを考えると変化の触媒となるような人を招くことが重要です。当初から、採用は最重要課題だと考えていました。 当時の戦略資料を読み返すと、1/3の人が変わることを一つの目安にしていました。変化の触媒として組織が変わっていくことを推進する人を内部の変化と採用で増やしていくことで、1/3の人が変わったときに大きく流れが変わると考えていました。これはティッピング・ポイント・リーダーシップの考え方に影響を受けています。 この1/3を生み出すために採用と育成の両面から実現の手段を検討していったというのが方針の中心になっています。まず人材要件が採用と育成の土台にあり、そういう人が採用や育成できるように、評価制度や仕事のあり方の再定義、組織の中でエンジニアが提供する価値の定義、価値を提供するためのスキルの明文化、サービスのオーナーシップのあり方、チーム開発の土台になる文化、学習することの習慣化、開発環境や勤務環境の見直しといったことを一つずつ進めていきました。 3. 小さな開発プロジェクトから実践を始める モダンな開発スタイルも、いきなり全社に展開したのでしょうか？ 田辺 　いえ。文化の醸成をするには一つのチームから始めて、そこから植物を株分けするように文化や習慣がインストールされたチームを分けて増やしていくというのが王道です。まずはそのセオリーのとおりに一つのチームから始めました。たまたまシングルマザー向けのメディアを新規で立ち上げるというプロジェクトがあり、エス・エム・エスの事業開発は私たちが知っている良い開発と合わない部分があるのかを検証することもできると思い、そこからトライすることにしました。 最初は互いに持っている文化や習慣を知っている人と進めることが大事だったので、技術力や文化的な背景をよく知っている知人のエンジニアに業務委託で来てもらい、3名の開発チームから始めました。 小さくスタートしたのは仕事の基盤になるようなツールについても同様です。開発環境の土台となるツールして、GitHubと、Slack、esaを導入しましたが、これも最初は良い振舞いとしての利用の仕方を知っている人だけを登録するところから始めました。透明性の点からはあの人は使えるあの人は使えないというのは良くない状態なのですが、文化醸成の初期段階では「ツールが使える」ということよりも「ツールを使ってどのように仕事をするか」ということが重要だからです。普及のための触媒になる人が少ない段階で「ツールが使える」というを重視して広く展開してしまうと、仕事で活用しきれない形で利用をする人数だけが増えてしまいます。これを避けるために、新しい人がツールを使い始めるときにはすでにそのツールを使って仕事をしている周囲の人の真似をしていけば自然と良い仕事の仕方の習慣が身につくという状況がキープできるような形で導入を進めていきました。 アジャイルな開発を進めるには、サービスを企画する人との連携も必要になりますよね 田辺 　そうですね。プロダクトオーナー役として参加したのはサービスの責任者役の人でした。 ここでエス・エム・エスで事業をやっていくのが面白いかもと思った最初の印象的な出来事があったのですが、彼からこういうサービスが作りたいと説明を受けたとき、なにを作りたいかの説明だけで20分くらいで終わりました。 そこで、なぜそのサービスを作りたいのかビジネスの目的を開発チームに伝えてほしいと話しました。なぜそれが知りたいのかと逆に質問されたので、「私たちは依頼されたものを作る専門家ではなくサービスの顧客やビジネスに対して同じ目的を持って取り組むチームで居たい。そのためには、なぜこのサービスをやりたいのかという理由を理解することは重要で、理解した上で技術でチームに貢献したいのだ」ということを説明しました。 正直、ここでの想像していた反応は「面倒だからそれっぽい説明をしてお茶を濁そう」というような態度だったのですが、驚いたのはこの後のサービス責任者の反応でした。しばらく私たち開発チームの考え方を理解するための質問をして、数分整理のために考えると、スイッチを切り替えたように「わかったのでそれなら最初から全部説明をし直しさせてください」と言い、あらためて最初から説明をし始めました。普通このような場合にサービスの戦略コンセプトやストーリーを準備もなく説明することはできません。すでにあるサービスであればまだしも、これはまだ存在していないサービスについての説明です。しかし、このとき彼はキャリア事業というマーケットの置かれている背景、その中での課題、今回のサービスが機会とみなしているポイントとそれを裏付けるファクトのデータ、その中でサービスが重視したいコンセプトといった内容をすべてひとつながりのストーリーとして一息に語ってくれました。語られたストーリーはこれまでまったくその業界を知らなかった開発チームにとっても、十分にやりがいと魅力を感じるもので、そのロジカルなストーリー展開に急にチームの熱量が上がったことを覚えています。 これが、私が「なるほど、これがエス・エム・エスか。この会社が戦略性に加えてプロダクト開発の強みを身に着けたら面白いことになるぞ」と感じた一番最初の体験でした。 4. 最初のチャレンジで、問題を解決できる手応えを感じた 最初の取り組みで、どのような手ごたえを感じましたか？ 田辺 　結果として、ここでもエス・エム・エスの特殊性というのはないということが確認できました。アジャイルな開発プロセスや技術的なプラクティスで一通り私たちにとっての普通のサービス開発をしてみても、開発期間や費用の面でもとくに事業開発の上で困ることはなく、機能や内部品質の面で十分に満足のいく形でサービスを送り出すことができるとわかりました。 初期の段階の検証が済んだことで、いよいよ本格的に内製化に進んでいった訳ですね 田辺 　そうですね。とはいえ、2015年の段階だと、まだ見えている範囲が狭いので、けっこう楽観的ですね。「モダンな開発スタイルに慣れた優秀なエンジニアが20人くらいいたら、余裕で変えていけるだろう」くらいに思っていました・・・ （ 「消耗戦の悪魔のループ」が登場する後編 へ続きます。） tech.bm-sms.co.jp

はじめまして。キャリア開発グループの大野です。 普段は医療・介護領域におけるキャリア関連（求人・人材紹介）のWebサービスを開発・運用しつつ、プレイングマネジャー的ななんでも屋をやっています。 今回は「マーケターとの境界線を超えていく」というテーマのもと、普段行っている業務の中で、役割にとらわれずやっている / もっとやっていきたいこと、それに向けた取り組みに関して話ができればと思います。 働く環境 私の所属するグループ（以降キャリア開発グループ）が普段仕事をする中で、最も関わりのある職種がマーケターとなっています。 ここでのマーケターの役割ですが、主にWebからの集客（キャリアサービスなので、求職者の方を集める）ことが主な役割となっており、マーケターの中でもSEO、広告、CRM等の領域で様々なスペシャリティを持ったマーケターがいます。 マーケターとの境界線を超えていく とはどういうことかを簡単に言うと、上記のようなマーケターの役割に対して、自分達がオーバーラップし、共にサービスの成長を進めていこう。 といった内容になります。 例えば、以下のようなメリットがあると実感しています。 マーケ領域の「できること」や「KPIのつながり」をマーケターと同じ粒度で会話できることで、よりサービス成長に直結した施策や問題解決が生まれやすい エンジニアより上位の考えから入ることで、技術負債が生まれにくい マーケター⇔エンジニア間のコミュニケーションコストが減り、無駄なドキュメントが減る キャリア開発グループでは、多かれ少なかれこういったことがエンジニアサイドからできるよう、マーケターとのコミュニケーションを増やしたり、KPIの共有を行ったりといった活動を行っています。 なぜ、そういう考えに至ったか 私自身、前職はソーシャルゲームの開発を行っており、ゲームというジャンルの特性上もあって、 その中でいくつか、エンジニアにも適性がある部分を感じ、サービスに対してよりエンジニアも一緒に考えていくべき、と感じるようになりました。 適性があると感じること 自社のサービスを論理的に理解・残す文化がある ノウハウ、ドキュメントなど 複雑なシステムになればなるほど、作り方がわかってるエンジニアが既存の仕様に強くなる 元々、数字や計算は得意な人が多い KPIを理解・計算したりすることのハードルが少ない システム面から、実現可能性を考えれる 「できること」の可否が自分で思考できる分、意思決定が早い 他職種から、エンジニア領域に入るのは難しい もちろん、エンジニアへの理解が高いマーケターもいるものの、それを大多数に求めるのは現実的でない 一方、これらの適性だけではサービス成長に行き届かない部分も多々あり、エンジニアが歩み寄った分、マーケターにはよりそういった部分に注力していける関係になれればと思います。 エンジニア違った着想からの提案 仮説・検証の頻度・精度の向上 より広いステークホルダーを巻き込んだ施策の立案 SEO知識やWeb広告の入札等、Webマーケ特有のスキルに関するキャッチアップ など 現状 では、現状のキャリア開発グループがどうかというと、もちろん人によりけりなのですが全体感としては以下のような状況です。 志向として、上記のようにエンジニアリング以外の部分でもサービス貢献しよう！と考えるタイプがほとんど 一方、KPIや事業構造の把握、ドメイン知識等の不足により、バリューを出せる部分が限定的でまだまだ課題は多い 課題に対する取り組み あるべき姿に近づけていくためと、昨今のリモート業務環境に伴い、以下のようなことを取り組んでいます。 個人の役割・チーム編成の見直し 会議体の変更 振り返り時間を使った知識共有 個人の役割・チーム編成の見直し 元々、1チームN人でNサービスを見るような形でチーム形成をしていたところから、チーム自体は変更せず、その中でサービス担当を決める形に変更しました。 イメージ これによって、以下のようなメリットが生まれました 似たサービスが多い中で、サービス固有の仕様を覚えやすくなった サービスに対する当事者意識が芽生え、主体性が増した 元々、横断的に対応してたため、横のサービスのフォロー自体も以前を変わらず行えている 会議体の変更 マーケターとのMTGを行う際、元々は「マーケター ☓ エンジニア」のMTGとして、かなりの人数が参加する会議となっていました。 特に、リモート中心のMTGとなり、人数が多くなると話しづらい状況も発生していたため、これも「サービス単位のマーケター ☓ エンジニア」でMTGをする形に変更しました。 少人数でのMTGになることで、マーケターとの距離感が縮まった 1サービスの話に集中することで、MTG時間が短縮した 余った時間でKPIの共有等、サービス理解に向けた時間に充てることができた 振り返り時間を使った知識共有 以前から、KPTのフレームワークに合わせてチームの振り返りを週次で行う文化がありました。 一方で、KPTを長く続けると、中々着手できないTryが溜まったり、Problemのネタ切れになったりと、除々に形骸化しがちな問題も発生していました。 そこで、思い切って振り返りの時間を勉強会や知識共有の時間に変更しました。 また、KPTも2,3ヶ月に1回程度は行っており、そこからTryの状況のみチェックする形で継続しています。 勉強会や知識共有会を行う上で、最も気をつけているのは「継続すること」になります。 今の形になって8ヶ月ほど経ちますが、今の所毎週継続できています。 開催ハードルあがらないよう、ほぼ準備がいらないこと中心に実施する ネタ出しブレスト会を定期的に行う（当面のスケジュールも決めてしまう） 勉強会、業務フローの見直し、チームビルディング等お題も様々 ネタ出しブレストの様子 おわりに キャリア開発グループでは、エンジニアリングはもちろんのこと、マーケターへの理解をより進め、同じサービスを成長させるという目的の元、これからも自身・チーム共に様々な観点から成長できるような組織にしていければと思います。 こういった働き方に興味がある方、ぜひ一緒に成長しましょう！