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ヶ月（執筆時点）で、長い道のりのやっと一歩目を踏み出せたかな、という感覚です。険しい道ではありますが、入社の動機にもある「身近な人の将来を支えていける」こと、 そしてこの記事を見て下さった皆さんの、ひょっとしたら数十年後を支えられるような仕事が出来れば この上なく嬉しい限りです。 勿論、私一人では不可能なので、ほんの少しでも共感して頂ける方がいらっしゃいましたら、ぜひカジュアル面談などでお会いしましょう。 カジュアル面談からOK/アーキテクト・テクニカルリード職 - 株式会社エス・エム・エスのWebエンジニアの採用 - Wantedly

医療・介護・ヘルスケア・シニアライフの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ヶ月ほど経ちますが、今の所毎週継続できています。 開催ハードルあがらないよう、ほぼ準備がいらないこと中心に実施する ネタ出しブレスト会を定期的に行う（当面のスケジュールも決めてしまう） 勉強会、業務フローの見直し、チームビルディング等お題も様々 ネタ出しブレストの様子 おわりに キャリア開発グループでは、エンジニアリングはもちろんのこと、マーケターへの理解をより進め、同じサービスを成長させるという目的の元、これからも自身・チーム共に様々な観点から成長できるような組織にしていければと思います。 こういった働き方に興味がある方、ぜひ一緒に成長しましょう！

新型コロナウイルスの影響で、世界的にリモートワークで仕事を行う人が増えています。この記事は、新型コロナウイルスの流行に巻き込まれた当初の記憶を思い出しながら、コロナ下で本格的なリモートワークを始めたエス・エム・エスのいち社員が、どうやってリモートワークと向き合ってきたか書き起こしてみたものです。 試用期間の終わりと新型コロナウイルス流行の始まり とまどい リモートワークの風景 オンラインホワイトボードサービス ビデオ通話サービス リモートワークは「正しい」のか 試用期間の終わりと新型コロナウイルス流行の始まり 2019年の暮れに入社した私は、プロダクト開発部所属となり、介護事業者向け経営支援サービス『 カイポケ 』の訪問看護開発チームメンバーとなりました。 翌年の2020年4月には診療報酬改定 *1 というチームにとって一番大きなイベントが控えているという事から、事業所見学やヘルスケア展示会等にどんどん参加し、自身が関わる業界の現場感を理解するということを優先して行っていました。エス・エム・エスは、こういった動きを積極的にサポートしてくれる会社だったので、この先も現場の方々といろいろな話ができるのだろうなという希望に胸を膨らませていたのを覚えています。 しかし、その希望は新型コロナウイルス感染症の拡大によって脆くも崩れ去ってしまいました。 試用期間が終わりとなる2020年1月。エス・エム・エスの Slack でも新型コロナウイルスについての話題が出始めました。この時は日本で少しだけ感染者が出ている程度だったので、数ヶ月もすれば収まるだろうとたかをくくっていたのですが、状況はどんどん悪くなって行きます。2月になると、業務にも直接的な影響が出始めました。カイポケでは介護事業者向けにiPadのレンタルを行っているのですが、新型コロナウイルスの影響で中国の工場が稼働を停止した影響で、その調達にも影響が出ました。業務もリモートワークに切り替わり、今まで顔を合わせてホワイトボードの前でミーティングをしていたチームメンバーとも会えなくなりました。 別チームのものですが、当時のホワイトボード。 描いてあるキャラクターは カイポケのマスコットキャラクター カイポチ だと思います 世間でも、2月にダイアモンドプリンセス号において新型コロナウイルスのクラスターが発生し *2 、3月13日には新型インフルエンザ等対策特別措置法が改正されています *3 。4月7日には、とうとう緊急事態宣言が発令され *4 、誰の目にも世の中が一変してしまったというのが明らかな状態になっていったのです。 とまどい ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 ... 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 -- アジャイル宣言の背後にある原則 (agilemanifesto.org) これは、アジャイルソフトウェア開発宣言について書かれた文章から抜き出した内容です。 エス・エム・エスでは昔からアジャイルやスクラムの考え方を取り入れて開発を行っているのですが *5 、リモートワークはこの「日々一緒に働くこと」と「フェイス・トゥ・フェイスで話をすること」の難しさをぐっと押し上げました。付箋を貼ったホワイトボードや、チームメンバーが顔を合わせて会話がしやすい様にと設置されたハニカム構造に配置されたベンゼンデスクは、その価値を発揮できないまま誰も居ないオフィスの中で今も佇んでいます。 2020年のある日のオフィス コミュニケーションには、当初はかなり苦労しました。大きなディスプレイとホワイトボードの前でスタンドアップミーティングをしていたものが急にビデオ通話の世界になったのです。マイクとスピーカーの設定がおかしくて音声が聞こえない、画面共有がうまく行なえない、話し始めてもタイプ音とタッチノイズで聞き取りづらく、耳も痛くなる。リモートワークが始まった当初は、お世辞にも快適なコミュニケーションが取れている状況ではありませんでした。 開発業務を行う環境としても、いつも使っていた 27 インチのサブディスプレイは自宅には無く、13 インチの Macbook の画面にウィンドウをなんとか配置しながら、ギリギリ椅子と呼べるようなコンテナの上にクッションを置いて、だましだましリモートワークをやっているのが実情でした。 QA業務を担当するメンバーのリモートワーク対応も簡単なものではありませんでした。 カイポケにはサービス種別ごとに iPad アプリが存在していて、QA 業務を担当するメンバーはテスト用に iPad 端末を持っています。テスト環境へのアクセスは、オフィス内のネットワークから行う形で QA を行っていたのですが、これがリモートワークによって難しくなりました。この問題は、接続環境設定を jamf NOW で行い、iPad 端末を QA メンバーに郵送するという事で対応しました。(こちらは ブログ記事 にもなっています ) 帳票の出力も難しい課題でした。介護保険の請求は現在電子化されているのですが、訪問看護の請求は未だに紙を郵送する事で行われています。このため、出力した帳票が判別可能なものか、フォントサイズ的に潰れたりする部分が無いか、等のチェックを行う必要性が高く、無視できないものとなっています。参考までに、2020/04 の診療報酬改定で新たに採用されたの訪問看護療養費明細書 pdf へのリンクをこちらに記しておきますが、だいぶ情報が込み入っているのがわかってもらえると思います。 https://www.tokyo-kokuhoren.or.jp/insurance/circulate/pdf/app_houmonnkanngo_mei.pdf 自宅にプリンターを持っている人がチェックする等いくつか案も出たのですが、チェックする際の印刷品質を統一できない等の理由から、何名かの QA メンバーの自宅にプリンターを郵送する事でテストを行える環境を整備するという対応を行いました。 これらの対応の裏には、全社のインフラや機器整備をサポートするヘルプデスクによる VPN 等のネットワーク環境整備や、コロナ下で QA メンバーへの端末配送業務を出社して行っている QA チーム長の努力があったのを私は知っています。 この様な状況下ではリモートワーク推進派から「リモートワークを前提とした組織設計をした方が良いのでは」といった意見が出てきても不思議ではありません。実際、5月後半に社内でもリモートワーク中心の働き方にするべきでは無いのか? という議論が沸き起こりました。これに対して、プロダクト開発部長である田辺の回答は「完全なリモート中心への切り替えは行わず、リモートワークの比率を高めるが、恒久的なフルリモートワークというところまではいかない。あくまで暫定的な対応としてリモートワーク主体での働き方にシフトする」というものでした *6 。 私は、アジャイルの考えは物理的距離によるメリットを最大限活かそうとする開発スタイルだと理解しています。このローカルワークの価値を否定せず、それでも状況に合わせてリモートワークを取り入れる。この判断をしたという事は、私にとって、とても納得の行くものだったのです。 誤解の無いように書いておくと、エス・エム・エスのプログラマーは現在ほぼフルリモートの状態で働いています。私も、今年に入ってからオフィスに行ったのはロッカーに入っている荷物を取り出さなければいけない時ぐらいでした。方針としてはあくまで暫定的なリモートワークではあるのですが、組織としてはその期間徹底してリモートワークで働ける環境を作ろうとしています。 リモートワークの風景 感染状況に応じてリモートワーク対応をしているエス・エム・エスでは、リモートワークのサポートとして、以下のような取り組みを行っています。 書籍購入を Slack で完結できる仕組み [ブログ記事] 発案から運用開始まで3日。経費申請も出社も不要、技術書が自宅に届くデリバリー制度をスタートしました リモートでのチーム体験ツアー [ブログ記事] 2ヶ月かけて8チームに所属するアーキテクト向けオンボード「チーム体験ツアー」とは？ リモートで iPad の VPN 設定を行える仕組み [ブログ記事] リモートワーク下でのリモート実機QA環境を瞬速で構築した話 オフィスで使っていたディスプレイを自宅まで配送してくれる制度 通勤手当を在宅手当へ切り替え オフィスレイアウトのフリーアドレス化 物事が決まってしまえば、その方向性でしっかり動いていけるというのは弊社の強みだと考えています。他にも様々な変化があったのですが、ここではホワイトボードとビデオ通話を例に、エス・エム・エスのリモートワークでどうやってオンラインサービスが使われているのかを紹介します。 オンラインホワイトボードサービス リモートワーク以前にホワイトボードを使って行っていた振り返りやブレインストーミングといった作業には、当初 Jamboard を使っていました。しかし、付箋の数が多くなってくると色が足りなくなる。スペースが足りなくなって別ページを作ると付箋間の関係性が視覚的に表現できなくなる。といった使い勝手に関する課題が多く出てきてしまいました。 この課題をすっかり解決してくれたのが miro という オンラインホワイトボードサービス です。 描画領域をどこまででも広げる事ができるため、付箋を貼るスペースが無くなるといった事も無く、付箋には色を変える以外にもタグやリアクションを付けるといった事が可能で、リアルの付箋が持っている良い意味でのごちゃごちゃした感じを再現しやすいサービスになっています。また、タイマー機能も付いているため「10分間アイデア出しをしてください」という様なときも時計とにらめっこしなくても済みます。 使い勝手としては diagrams.net (旧 draw.io) に近いのですが、その UI や機能を更に洗練させた感じの使い心地です。 業務上 Figma ほどちゃんとした描画ツールは必要無いけれど、ワイヤーフレーム等ちょっとした図を書きたいという時にも、私はこの miro をよく使っています。 当初日本語の入力にバグがあったりしたのですが、現在は特に使いづらいところもなく、オンラインホワイトボードはこれだけを使っています。ちなみに、チャットや音声通話機能、画面共有機能まで付いているので、やろうと思えば Slack や Zoom を使わずに miro だけでコミュニケーションを完結させる事も可能です。 ビデオ通話サービス 顔を合わせて行っていた社内会議や外部の関係者と行っていた会議は、ビデオ通話サービスを使ったオンラインミーティングに変わりました。私のチームでは以下の様に音声通話サービスを使い分けています。 Google Meet (G Suite Basic) Slack Call Zoom 人数制限 100人 15人 50人〜 バーチャル背景 使える 使えない 使える UI シンプル シンプル 複雑でわかりづらい 機能 必要十分 シンプルすぎる 高機能 画面共有への書き込み できない できる できる ブレイクアウトルーム 使える 使えない 使える Google Calendar との連携 できる できない できる 総評 簡単に Google Calendar と連携でき、機能も必要十分。一番良く使っているサービス。 Slack からカジュアルに通話を作る事ができ、画面共有への書き込みも出来るためモブプログラミングで利用する事が多い。 高機能で音声、映像が安定している。大規模な会議で利用する事が多い。 当初は Slack Call を使う事が多かったのですが、チーム横断で行う通話では最大 15 人という人数制限が問題になる事が多く、Zoom もまだ試験運用段階だったため Google Meet を使う割合が徐々に増えて行きました。バーチャル背景の導入や、音声通話品質改善のアップデートもあり、現時点で一番コストパフォーマンスの高いビデオ通話ツールなのではないかと考えています。後は、共有中の画面への書き込み機能が追加されれば完璧です。Google さんよろしくお願いします！ さて、ビデオ会議で議論になりやすいのが「カメラを ON にするべきか?」という話題です。社内の esa にリモートワークのプラクティス集ページが投稿されたのをきっかけに、プロダクト開発部内でもこの議論が行われました。 プライベートと仕事の境界があいまいになってしまうというのはリモートワークの欠点です。こういった状況に対して、プライベートを守るためにカメラを OFF にするというのは正当な理由だと思います。しかし、表情からニュアンスを読み取ったり相槌を確認して会話を進めるといった、リアルの会議で行なえていたコミュニケーションの仕方を音声通話だけで行うのは難しいです。 最終的に、カメラを ON にする価値を認めつつも、プライベートを守るという意思は尊重するという結論となりました。 プライベートな物事と関わる判断を、「これが正しい」という線を引くのでは無く「それぞれが正しい」ので可能な範囲で選択できる状態を落とし所とする。この判断は中途半端な様に見えるかもしれませんが、コロナ下という難しい状況を乗り切りために柔軟さを持とうとする、とても重要な判断だった様に思います。基準を設けるという事は重要な事ですが、特に心理的な判断に関してはお互いが気持ちよく働くための「あそび」を持つ重要性もまた高いのではないでしょうか。 リモートワークは「正しい」のか この難しい状況の中、訪問看護チームはメンバーの試行錯誤と協力のおかげで、カイポケ史上初のフルリモートワークでの診療報酬改定を乗り越える事ができました。 コロナ下で、多くの人々がリモートワークを経験していると思います。その中で、リモートワークこそが「正しい」労働環境であるという主張を見かける事もあります。もしかしたら、そうなのかもしれません。 自宅から職場までの移動。 Slack や議事録にまとめられていない、すれ違いの 10 秒で交わした会話。 隣のチームから聞こえる仕事とは関係無い笑い話。 エレベーターを通って売店まで移動する合間に見えるオフィスの外の風景。 そんな必要ない物がスッキリ整理された、ノイズの無い理想的な労働環境。 残念ながら、私にはその様に思う事ができませんでした。リモートワークによって、今まであったものが何か失われてしまっている。この感覚が、私の心の中にずっと残り続けています。 相手の表情から意図を汲み取り、身振り手振りを交えて伝えたい事を表現しようとする。対面で人と話す事というのは、やる事の多い、ストレスのかかるコミュニケーションの仕方です。論理的な文章や、課題との因果関係が明確なデータがあれば、非同期的で非対面なコミュニケーションをしていた方がよっぽどストレスがかからないでしょう。しかし、ストレスがかかる事との引き換えに、同じチームで同じ物を作っている感覚や、言葉だけでは表現できな情熱を伝えるといった事ができていた気がします。 新型コロナウイルスの流行が始まって以降、アジャイル開発において物理的な距離によって発生する課題を解消しようという動きはエス・エム・エスを含む多くの企業が取り組んでいる事だと思います *7 *8 *9 *10 。しかし、私個人としては、やはりアジャイルな働き方はローカルワークができる環境がある事によって本来の生産性や創造性を獲得できるものだと感じています。 最後に、文中で引用した「アジャイル宣言の背後にある原則」の文章を再掲します。 ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 ... 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 -- アジャイル宣言の背後にある原則 (agilemanifesto.org) ずっとリモートワークを続けている今だからこそ、私はこの価値観を大切にしたいと考えています。 (筆者: プロダクト開発部桐生) *1 : 令和２年度診療報酬改定について （www.mhlw.go.jp） *2 : （2020年2月19日掲載）-- 現場からの概況：ダイアモンドプリンセス号におけるCOVID-19症例 (www.niid.go.jp) *3 : 施行日： 令和三年四月一日 -- 新型インフルエンザ等対策特別措置法 | e-Gov法令検索 (elaws.e-gov.go.jp) *4 : 新型コロナウイルス感染症緊急事態宣言（令和２年４月７日発出） -- 新型コロナウイルス感染症緊急事態宣言・まん延防止等重点措置｜内閣官房新型コロナウイルス感染症対策推進室 (corona.go.jp) *5 : 『 アジャイルサムライ 』『 SCRUM BOOT CAMP THE BOOK 』に関わった西村もエス・エム・エスに所属しています。 *6 : 当時の方針であって、記事公開時点と現在では変化している部分があります。 *7 : アジャイル開発では当初、クラスター化したチーム、つまり物理的に同じオフィスにいるチームを想定していました。「開発チーム内で情報を伝達するには、直接向き合って話すのが最も効率的で効果的な方法である」という考えを踏まえ、初期のアジャイルチームでは近接して活動することが前提となっていました。... ただし、分散チームの利点の裏には欠点もあります。 多くの分散チームにとって、アジャイルプラクティスである対面でのやりとりは困難です。 -- リモートアジャイルチームのヒント | Atlassian (www.atlassian.com) *8 : 10年の歳月をかけてリモートワークを洗練させてきたサイボウズだが、当初からうまくいったわけでない。むしろ、今、多くの企業が悩んでいるのと同じように、失敗からのスタートだったと言っていい。 -- 在宅勤務の苦悩　サイボウズは脱「リモハラ」に10年: 日本経済新聞 (www.nikkei.com) *9 : While no one knows how long the COVID-19 crisis will last, it seems inevitable that many of us will be working remotely for at least weeks if not several months. Productivity may take a hit, but it doesn’t have to hurt. An agile approach can keep remote teams functioning effectively and make them more resilient for the future. -- How to Remain Remotely Agile Through COVID-19 | BCG (www.bcg.com) *10 : Because people are and remain social animals, virtual proximity requires to maintain ways of connecting, building connections and team mindsets without physical proximity, doubling the focus on such “soft” topics. -- Agile Development in a Virtual Setting | Accenture (www.accenture.com)

@sunaot です。前に一緒に働いていた同僚からこんな質問が来ました。 組織が肥大化しすぎてアレコレうまく行かない事が増えてきたので『 ユニコーン企業のひみつ 』を読みました。 他にも他社の事例とかも見ていたりするのですが組織の布陣とか参考になるおすすめの書籍などありますか？ 今はマネージャーをやっていて組織の設計に困っているようです。回答をするために考えてみたのですが、開発組織の組織デザインをピンポイントで語った本というのがありません。『ユニコーン企業のひみつ』は Web のサービス会社のチーム開発について語った良い本なのですが、組織論ではないためほしいところとやや違ってきそうです *1 。 そこで、同じような悩みを抱えている人に向けてサービス会社の開発組織の組織デザインについて、実際に6年以上試行錯誤してきた立場から考えるべき観点というのをまとめてみようと思います。 結論から言ってしまうと、開発組織ゆえの特殊性というのはあまりありません。考えるときの原則を書くとすると、開発組織でなくても同じ内容になりそうなとても普遍的な内容になります。つまり、 「マネジメントの意思として取り組みたいテーマに対して、その実行とモニタリングに適した組織形態をとり、複数のテーマの兼ね合いの中で出るトレードオフに対して、総合的に一番やりやすい形をとっておく。不都合があればチューニングする」 という基本のところに落ち着きます。ただ、その中で「プロダクトの単位で同じ目的や目標を追って一丸になって動けること」はテーマに負けないくらい重要な視点になってくるので、かなり力強い制約として考える必要があります。 以降はこの説明をもう少し解像度を上げて説明していきます。重要になってくる点は、「使命中心編成と機能別編成の組織」「マネジメントの意思の視点」「フェアプロセスと3つの要素」です。 HIGH OUTPUT MANAGEMENT の使命中心編成と機能別編成の組織 一つのヒントとなるのはアンディ・グローブによる著書『 HIGH OUTPUT MANAGEMENT *2 』に載っている使命中心編成の組織と機能別編成の組織です。 使命中心型の編成だと、事業の単位で組織を編成しそれぞれの単位のやるべきことにフォーカスして働きます。事業が必要とする機能は一通りその組織に所属して、同じ目標（やるべきこと）を目指して動くようになります。たとえば、製品開発やセールス、マーケティング、購買のような機能をすべて持つ形です。この形態を選択する場合、全員が事業の顧客や目標に対して働くことになるので、市場への即応性が高まります。 続いて、機能別の編成だと、使命中心型とは反対に機能の効率性に注目して組織を編成します。製品開発やセールス、マーケティングといった仕事の機能を組織単位として、関わるそれぞれの事業に対して責任を持ちます。規模の経済による効率性や専門性の横展開といった点では機能別組織を志向するメリットがあります。一方、事業のやるべきことに対して当事者としてのスタンスが弱まりやすいのがデメリットです。書籍では使命中心型の組織の持つ即応性の特徴に対して、機能別組織にはテコ作用が得られるという特徴があると書いています。 『HIGH OUTPUT MANAGEMENT』ではこの2つの組織モデルに対して、両者を組み合わせ、フロントに立って市場に向き合う使命中心の組織とそれをバックアップする機能別組織を混合したハイブリッド組織という編成について解説し、「共通の事業目的を持つすべての大組織は、最後にはハイブリッド組織形態に落ち着くことになる」という「グローブの法則」を提唱しています。 書籍ではハイブリッド組織を運営していく場合の長所、短所とその中での注意点についてかなり詳細な説明 *3 があるので、より詳しい内容を知りたい方は書籍を読むことをおすすめします。 *4 マネジメントの意思のレイヤー 使命中心編成と機能別編成の組織のメリット・デメリットはある程度『HIGH OUTPUT MANAGEMENT』に倣うとしたときに、もう一つ開発組織を考えるときに重要なポイントがあります。それが、チームを主役に据えたときの製品開発の組織レイヤーと、マネージャーによるマネジメント意思、マネジメント範囲の視点で見たときの組織レイヤーです。 一つにはこれを一致させて、日常はすべて製品開発を軸とした組織レイヤーで済むような組織デザインがあります。Spotify Rhythm や Alignment at Scale を見ると、日常の製品開発の中である種のマネジメントの意思というのが紡がれ繋げられている様子が読み取れます。 blog.crisp.se blog.crisp.se 一方でまさにこういった組織デザインの話などもそのカテゴリに入ってきますが、使命中心組織のレイヤーでは拾いきれない (そして、トライブでもチャプターでもギルドでも拾えない *5 )、組織に対してのマネジメントのレイヤーというのが欲しくなることがあります。機能別編成の組織の観点で出てくることもあるかもしれませんが、それだけとも限りません。従来のピラミッド型組織であればラインのトップダウンでつなげていくことができるマネジメントの意思ですが、使命中心編成と機能別編成のハイブリッド型の組織形態や、ユニコーン企業のひみつで語られるような使命中心編成を中心にしながら機能の要素をオーバーラップさせていくような組織形態をとっている場合、不都合が生じるときがあります。 不都合があっても必要なことは実行していかねばならないので、それは別のレイヤーとして描いている組織図に対してオーバーラップさせていくというのが現実解になります (チャプターやギルドといった仕組みも、スクワッド＋トライブという土台となる使命中心編成の姿に、別の意思としてかぶせているレイヤーという見方もできます)。 チームが主役で中心だと言いながら、少し軸が別の活動をかぶせていくということで、巻き込みや納得、関係性や位置づけがやや複雑で難易度が髙いものになってきます。そのため、単純なピラミッド型組織でのマネジメントの意思の浸透とは違う性質の問題を解くことになります。 製品開発をしていく開発組織にとって、使命中心編成をベースにして機能別組織を組み合わせたり、チャプターやギルドを組み合わせていくスタイルはミッションを共有し、同じ目標を追いかけるための姿として自然なものです。 そこで、自然なものに対してオーバーラップしてくる自然ならざるマネジメントの意思というのは、ただ「ユーザーに良いものを届けて、価値を提供し、ビジネスの成長へ貢献しよう」という題目よりも扱いが難しく、それゆえに伝え方、進め方に注意が必要だと言えます。 最後に、このチームを中心とした組織に対してオーバーラップしてマネジメントの意思を注入していくときに必要な態度のヒントになるフェア・プロセスというものについて説明をしてこの文章を終わりにします。 フェア・プロセスと3つの要素 フェア・プロセスは『 ブルーオーシャン戦略 』で有名なチャン・キム、レネ・モボルニュの二人の教授が発表した論文に載っているコンセプトです。また、ブルーオーシャン戦略の実践プロセスの一部としても言及されています。 フェア・プロセスは、人間の基本的欲求に訴えるものだ。だれもが、組織のなかでの役割が何であれ、一個人として評価されたいと思い、「人員」「人的資産」などと評価されたくはない。だれもが、自分の知性を尊重してもらいたい。自分のアイデアを真摯に検討してもらいたい。そして、それぞれの意思決定が合理的である理由を理解したい。 HBR 2008年8月号『 フェア・プロセス：協力と信頼の源泉 』（再掲論文。初出は January 2003 “ Fair Process: Managing in the Knowledge Economy by W. Chan Kim and Renee Mauborgne ”） フェア・プロセスというのは七〇年代半ばから研究がされてきた結果に至るまでの公正なプロセスのことです。 人は、結果にもこだわるが、それに至るまでのプロセスにもこだわる。 つまり、その結果がいかに満足できるものでも、そのプロセスが不条理で、 公正さに欠けるものであれば、不信感を抱き、やる気を失う。 逆に、プロセスが公正で納得できるものであれば、意に沿わない結果でも甘受する。 このような「フェア・プロセス」の重要性は、ますます高まっている。 人々の協力と信頼関係こそ、組織能力やイノベーションの源泉だからである。 論文の中ではフェア・プロセスを実現するための三原則というのが挙げられています。 エンゲージメント 説明 具体的な期待 それぞれを順に説明します。 エンゲージメント 社員たちに影響が及ぶ意思決定について、彼ら彼女を巻き込み、意見を求め、それをアイデアや仮説を交換し合うことである。このことは、社員一人ひとりの存在について、またそれぞれのアイデアを尊重するという意思表示といえる。 これはわかりやすいでしょう。全員に等しく意見を言う機会があるということです。ただ、全員の意見を聞くべきという話とは違います。現実問題、時間や物理的制約があるのですべての人から意見を集めるというのは不可能です。それでも、過程で意見を言う機会というのはあり、出した意見は誰が言ったかによらず等しく検討されるチャンスがあるという点が重要だというのがこの原則です。 説明 社員たちが、なぜこのような意思決定に至ったのか、その理由を理解することである。すなわち、意思決定の根底にある考え方を説明することは、社員たちの意見を考慮し、全社の利益から考えて、そのような意思決定を下したことを、社員たちに納得させることである。 「納得させることである」と言われてしまうと、あまり好みではなく「おう、そうか」という気持ちになってしまいますが、その手前の「意思決定の根底にある考え方を説明することは、社員たちの意見を考慮し、全社の利益から考えて、そのような意思決定を下した」という部分はエンゲージメントからの流れとして、このように全員の理解をそろえていく努力をするプロセスとして非常に重要と感じます。 現代的にいうと、これは透明性の話でもあります。ただやはり意思決定をした当事者がそのロジックを説明するという意味で、説明こそ重要であるというのは、今回読み返しながらあらためて身にしみるものがあります。 具体的な期待 いったん意思決定を下したならば、ゲームの新しいルールを明らかにしなければならない。期待は上から寄せられるものだが、その際、どのような基準で評価し、失敗にはどのような罰が待っているのかについて、社員たちに知らせる必要がある。 フェア・プロセスにおいては、新しいルールや方針が何かよりも、新しい目的やその中間目標は何か。だれが何に責任を負うのかを理解されることがよほど重要である。 「失敗にはどのような罰が」というよりも、現代では失敗は学習の機会であり、罰は待っていないということについて知らせる必要と読み替える必要はありそうですが、主旨としては意思決定の結果がアクションへつながるように組織の期待 (ミッション・目標) を書き換えるということです。意思決定の結果、自分たちへの期待がどう変わったのかまで説明がされて、初めてその意味が理解されます。 フェア・プロセスが全員合意の合意形成プロセスではなく、リーダーシップの発揮をしていくために、優れたアイデアをすべてのアイデアから見つけ出そうという過程であり、そこからの実行のためのプロセスであるという点は最後に強調をしておきたいところです。 おわりに さて、こうやって書いてきてしまうとさもうちの会社はこういった組織デザインの原則に従い大変うまく運営されているかのように見えてしまうと思います。実際のところはまったくそんなことはなく、こうして理屈はわかっているにも関わらず組織は生き物で基本的なことを一つ徹底するだけでも本当に難しいと感じているのが正直なところです。 とくに個人的な課題としては、フェアプロセスのうちの「説明」や「具体的な期待」のあたりは組織のスケールで実践するには個人の技能というのでは不十分で、組織での実践のための仕組みというのが必要だと感じ、現在の開発組織としても課題意識があります。 それでも自分もふくめて働く人が気持ちよく働き、自分の能力を発揮して充実して働ける組織にしていきたいと思いながら日々やっているので、一緒に組織づくりをしていってくれるエンジニアリングマネージャーの方やマネージャーではなくともそういった組織に共感して働いていってくれる方を募集しています。 www.wantedly.com *1 : 参考になるような要素は多々書かれています。 *2 : インテルの元 CEO アンディ・グローブによるマネジメントの実践書です。論理的な思考がエンジニアにとっても親しみやすい内容で、開発会社でマネージャーの役割をする人にとっては必読の内容と言っていいと思います。 *3 : 非常に有用な議論がされていますが、2点だけ気になる部分があるのでコメントしておきます。 一つは機能組織を規模の経済の視点で社内下請けと評した点。これはバックアップの役割と明確なラインを引くことでわかりやすさを上げる効果があると思いますが、この定義にしてしまうことで機能組織の限界を決め、目的を狭くし、より市場への即応性が落ちるコンセプトだと感じます。自分であれば、仮に機能組織のマネージャーの立場をとるにしても、そのコンセプトの中で市場へ近い形の組織役割を置くだろうと感じました。 気になる箇所の2点目は、リソース最適化の視点が強い点。これも機能組織の規模の経済と集約による最適化のメリットをとろうとしているためだというのはわかるのですが、組織の成果を付加価値よりも費用効率へ向かわせやすいなと感じました。自分がやるのであればテコ作用のほうへより多く注目して、そちらを軸にして組織のコンセプトを考えると思います。 *4 : さらに言えば、どの組織形態をとるのであれ、その上で組織が提供するべき機能（採用、育成、評価、リーダーシップ・パイプライン、キャリア開発など）を誰がどのような役割で提供していくのかを設計する必要があります。組織ではなく個人のほうを起点としたときに、その人がどの形の組織へ所属していても組織からのバックアップを受けられているようにしていくことが必要です。 *5 : トライブやチャプター、ギルドといった用語については『ユニコーン企業のひみつ』に書かれているので気になる方は参照してください。

このエントリではエス・エム・エスのエンジニア採用におけるカジュアル面談について説明をしていきます。世の中ではカジュアル面談という呼称でさまざまな形のものが存在しています。よく聞くのは「カジュアル面談だと聞いて話を聞きに行ったら、志望動機を聞かれた」「カジュアル面談だと聞いて話を聞きに行ったら、選考要素がありお祈りメールを受けとった」などでしょうか。ここでは、エス・エム・エスのカジュアル面談の位置づけや考え方、進め方について知ってもらうことで、参加してくれる方の安心や参加を迷っている方への後押しができたらと思っています。 カジュアル面談の位置づけ 最初にカジュアル面談の位置づけから説明をします。エス・エム・エスでのカジュアル面談は、互いの期待のすり合わせをする場として設定しています。エス・エム・エスという会社と採用のうえで期待していることを知ってもらい、ご自身のキャリアの中でどういう位置づけの会社になるのかを知ってもらうことが一番の目的です。 「一般的にこういう位置づけで見られる会社です」という話もしますし、話を聞きに来てくれる方にとってどういう会社にできるかを会話するために、キャリアについて考えていることを聞かせてもらい、そこに沿った会社の紹介というのもしています。 私たちとしてはより多くの人にとってエス・エム・エスが仕事をする中での機会になるとよいと考えています。 参加する人 とくにご希望がない場合、カジュアル面談はエンジニアリングマネージャーが担当をしています。人事の採用担当が同席をしていることもあります。 その場で「より現場のチームの話を聞きたい」という話が出るときは、続けて興味を持ってもらったサービスの担当チームとのカジュアル面談を設定することもあります。 これは標準だとこの対応をしていますというだけなので、最初から絞った目的がある場合はリクエストをしてもらえたらそれにあわせた形のカジュアル面談を組むこともできます。たとえば、「テックブログの記事を読んだのでこの記事を書いた人と話してみたい」といったご要望があれば、言ってもらえればそのような場をセットすることも可能です。 時間 開催時間は随時行っています。営業日の日中から夜は21時くらいまでの間で、通常は1時間枠で実施しています。50分程度で終わることを目指していますが、話が盛り上がって1時間ぎりぎりまでかかっていることが多いです。 カジュアル面談の応募をいただいた後に、ご希望の日時をいくつか聞かせていただき、その中から予定の合うところで開催日の案内をしています。状況にあわせて、お急ぎの方なら早めの日程で調整をしたり、候補日が少ない場合もその中で極力調整をするようにしているので、ご希望がある方は遠慮なく希望の内容を言っていただければと思います。 開催場所と開催方法 開催場所は以前は芝公園にあるオフィスでした。最近は対面を避けるため、オンラインでのビデオチャットで実施をしています。オフィスの様子を見たいという希望があれば対応もしているのですが、最近はそういう声も聞かなくなりました。 ちなみに、オフィスの場所は東京タワーや増上寺が近く、散歩に出ると数分で芝公園周辺を散策できる気分転換の散歩にはもってこいの環境です。最寄りの芝公園駅からは徒歩2〜3分の距離にあります。浜松町・大門駅方面や三田方面へ歩くと飲食店も多く、ランチ事情は他の地域と比較してもとても充実している場所になっています。 カジュアル面談の進め方 カジュアル面談の時間の進め方です。ここでは標準的な進め方を書いているので、具体的な期待がある方は要望を言っていただけたらそれに合わせた進行をしています。よく「採用に直結しなそうなのに時間をとらせて申し訳ないのですが」という形でリクエストをされる方がいるのですが、カジュアル面談は「採用に直結しなくてもいい場」として開催しているので、遠慮なくご興味に応じてエス・エム・エスやそこで働いている人を知る場として活用してください。脱線した質問大歓迎です。 標準的な進め方としては、まず会社説明の資料の説明をしています。資料の中では、次のような内容を説明しています。 ミッションと事業の背景 事業領域とその概要 会社の性格と開発チームの概要（規模ややり方） 過去の業績 使っている技術 在籍者の出身企業の傾向 雰囲気やどういう人が多いか 在籍者の平均年齢と年代別の構成 会社を知る情報として提供をしています 当然ですが、その方の年齢を聞くことはしていません 働く環境 勤務環境（勤務時間や残業時間） ファシリティ 学びの支援 FLOSS との関わり 働いている様子の写真 文化と価値観 評価制度 よくある知りたいことについての説明を一通りしたところで、今の状況にあわせての課題感を聞かせてもらい、それにあわせた話をしていくことをしています。たとえば、転職活動をすでに始められていて具体的な話をしたい方であれば今の環境での課題感や思い、次の職場へ求めることといった内容を聞かせていただき、それに沿ったときにエス・エム・エスという会社がどういう会社になるのかについての情報提供をしています。あとは、個人のキャリアとして目指すものがある方の場合はそのキャリアに必要な経験の中で、エス・エム・エスであればどういう機会を提供できそうかという話をさせてもらっています。 通常、このあたりのご関心についての話をしていく中で、事業についての深ぼった説明であったり、開発の仕方についての詳しい説明といったところをして時間が終了ということになっています。 おわりに エス・エム・エスで行っているカジュアル面談について説明を書いてきました。ここまでの説明のとおり、基本的にカジュアル面談は『エス・エム・エスという会社がどういう機会を提供できるか』と『話を聞きに来てくれる方がどういう機会を求めているのか』についての期待をすり合わせていく形で、会社を知ってもらう場としています。 私たちは自分の会社が知られていないので知ってもらおうという姿勢でカジュアル面談をしています。もちろん事前に調べたうえで事業についてつっこんだ質問をしてくださる方もいてそれも歓迎なのですが、知らないからまずは話を聞いてみようという形で聞きに来てもらえたらと思います。

エス・エム・エスで、チーム開発の支援を主に担当している西村（ @nawoto ）です。今回は、チームを支援するうえで心がけている視点について書いてみます。 ソフトウェアとチーム開発について 弊社のようなサービス開発を行なっている会社だけでなく、今は多くの事業においてソフトウェアの存在が不可欠になっています。事業を成長させていくのは簡単でシンプルではありません。そのため、事業に寄りそっていくソフトウェアづくり自体も複雑な課題に対峙することになり、一筋縄ではいきません。 僕は、ソフトウェアづくりには誰かスーパーマンのような人の個人の力で成果を出していくことより、あらゆる局面でたくさんの知恵や能力を活かしていくチーム開発の方が成果を継続的に出しやすいので有効だと思っています。 チーム開発は難しい？ では、複数人で開発を行なっていれば、チーム開発として成立するのでしょうか？ 残念ながらそう簡単ではありません。単に人が集まって作業を進めるだけでは、うまく成果を出すことは難しいと思います。チーム開発では、メンバー同士が共通の目的に向かって、互いに協力していくことでさまざまな局面でも円滑に仕事を進めることができます。そうした活動を積み重ねることで、「作業が予定通り終わった」「プロダクトに良いフィードバックが得られた」など今より「うまく開発できてる！」といった小さな成功の数が増えていき、結果として成果に繋がりやすくなります。 もちろん、チームとしてうまく協力して円滑にソフトウェアをつくっていくこと自体も簡単ではありません。しかし、今は参考になるやり方が世の中に増えてきました。その代表的なものとしては、スクラムをはじめとするアジャイルな開発があります。 アジャイルな開発は、複数人で価値あるソフトウェアを届けていくためのやり方です。チームとして何をどう協力していくかが、さまざまな活動と共に示されています。これからチーム開発をやっていきたい人たちが、アジャイルな開発のやり方から始めることも増えてきました。また、自分たちのやり方がうまくいっていないため、アジャイルな開発を導入していくケースも増えているように感じています。 アジャイルな開発を目指せばいいの？ 自分たちのチームが手始めに目指す理想のチーム像として、アジャイルな開発から始めることは良い選択だと思います。何もお手本が無いなかで、手探りで仕事のやり方を良くしていくのは大変です。ただし、アジャイルな開発もチームでうまく仕事を進めていくうえでは、あくまで目指すべき姿のひとつであることを忘れてはいけません。 アジャイルな開発を実践している人は多少なりとも経験があると思いますが、実際にやってみると案外うまくいかないことが多いです。例えば、「スプリントの期間内に作業が終わらない」、「プロダクトオーナーが忙しくてチームの作業にあんまりコミットしてくれない」、「ステークホルダーからの指摘が多くて、プロダクトバックログの中身が膨大で煩雑なものになってしまった」などなど。 たくさんのチームがこうしたよくある課題に一度は直面していると思います。アジャイルな開発では、こうした表出した課題にひとつひとつ向きあって解消していくことでより良い開発に近づいていきます。 しかし、出てきた課題の解消のみに目を向けていれば良いのでしょうか？ 僕は、スクラムを始めたばかりの人向けの 勉強会 などを開催していますが、そこで度々聞かれる質問の中に「チームメンバーの自主性がなくどうしたら良いか？」や「上司などステークホルダーにスクラムを理解してもらうにはどうしたら良いか？」といったものがあります。 たしかに、こうしたことは日々の開発を円滑に進めるうえでは課題になっているかもしれません。そして、アジャイルな開発を目指していこうとすると、人や環境に関することも自分たちのチームではうまく実践できていないこと = 課題として捉えてしまいがちです。 けれど、チームメンバーに関するような人に関する課題や上司やステークホルダーがどこまで協力的といったチームの置かれている環境に課題などは、なかなか簡単には解決できないと思います。では、こうしたすぐに解決できない課題をどう扱って、どう解決に向けてアプローチしていくかをもう少し詳しく考えてみたいと思います。 未来に向かってアプローチしましょう ひとつの方法としては、課題やそれに付随する課題を整理・分析して、より本質に近い課題を見つけにいく。そして、それに対して適切な解決策を探していくのも良いアプローチです。 しかし、頑張って分析したにもかかわらず、その結果は自分たちのチームだけでは解決が困難だったり、「あれ？より手強い課題になったかも。。。」と解決により時間がかかりそうだということが分かって落胆することもあります。 また、大きな課題や解決に時間がかかりそうな課題にばかり目を向けていると正直、精神的にもしんどいと感じる人も多いと思います。(少なくとも僕はわりと凹みます) 僕も、上記のような課題→分析→解決する方法も行ないますが、並行して別の視点でも考えるようにしています。それは、自分たちのチームが理想の姿に着実に進めているかです。何かができていない = 課題だと考えるのではなく、あくまで自分たちのチームが着実に成長していることにフォーカスして考えます。大雑把な説明ですが、自分たちのチームの理想の姿をイメージして、そこに近づくまでのステップを考え、ひとつずつ着実に近づいているかを確認していくアプローチです。 どういうふうにアプローチするの？ もう少し詳しく説明するために、僕たちのチームの例を紹介していきます。 僕たちのチームは、リリースまでのリードタイムの長さに悩んでいました。その大きな原因のひとつとして、実装が終わってからQA作業を行なっていることでした。実装がひと段落してからQAメンバーに仕様の詳細を伝えて、テストケースを作成する。そして、そのテストケースをレビューしてテストを実施する。そこで見つかった不具合を解消してからリリースするので、一定の時間がかかってしまいます。そして、QAメンバーのリソース状況の影響も受けやすいので、そこを課題に感じていました。 そのため、僕たちのチームではQAメンバーを自分たちのチームに迎え入れて日々の作業を一緒にすることで解消しようとしました。しかし、単にチームに加わったからといって、すぐに一緒に作業をこなせるようになり、リードタイムが短縮するわけではありません。新しく加わったQAメンバーも自分たちは日々どういうふうに作業をしていいのか手探りな状況でした。そこでQAメンバーも含めて、どういう姿で一緒に開発していると理想的なのかを考えて、そこに近づけていくことようにしました。 まず、チームの一員として一緒に作業している理想の姿としてイメージしやすいのが、Agile Testing *1 や書籍『アジャイルサムライ』に出てくる「アジャイルなテスター」だったので、最初にそこを目指しました。既に言語化されているものを利用すると、理想形をゼロから考える時間を大幅に短縮できるので、先人には感謝です。 次に、そこに近づけるためのステップをいくつか考えてみました。 その中からまず最初のステップとしたのが、「一緒に協業するイメージを揃える」でした。誰でも知識として知らないことは実行にうつせないだろうという考えから、これを最初のステップにしました。具体的にやったこととしては、僕たちのチームはスクラムをベースとした開発をやっていたので、まずQAメンバーも含めた全員でスクラムガイドや入門書の読書会をチーム全員でやりました。それとあわせて、これまで開発を主にしているメンバーで実施していたスプリントプランニングやデイリースクラムなどに参加してもらいました。これでQAメンバーにもチーム全体で普段、何をやっているかをより具体的に知ってもらいました。 そのあと、『 Agile Testing Condensed 』の読書会もやりました。これによって、開発が得意なメンバーとQAメンバーの両方に、どういうふうに協業していくか、どういうチームを目指していきたいかをまずは知識としてインプットしました。 次のステップは、知識としてインプットができたので、簡単なものから実際にやってみて体験してみることでした。まずは今のスプリントで実装している新しい機能の一部をどうテストしていくかを議論するところから始めてみました。どの部分なら自動化できそうか、もちろん全てを自動化するのはとても時間と根気が必要なので、どの部分は手動テストでやってみるか。テストの観点はチームの誰もが見ても分かりやすいものになっているか、他に気になる点はないかなどなど、議論の論点も多岐にわたりました。そして、共通認識がある程度できたところで、試しに一部分の受入れテストの自動化を全員で実装していきました。 もちろん最初からテストの自動化がうまくできたわけではないですが、実際にやってみたことで次はどうしようという具体的な意見が出てきました。そこで次のステップとして、「一緒に作業をやってみる」から、「チームとして仕事のやり方をふりかえる」段階に進んでいきます。徐々に自動化するスコープをどこにするか、チームの置かれている状況を踏まえて、どこまでテストするべきかなどなどチームでもっとうまくやれることを探して少しずつ良くしていきました。たとえば、QAメンバーと呼ぶと壁があるように感じるので、テスト得意メンバーと呼ぶというものもありました。 まとめると、以下のようなステップを歩んできました。 一緒に協業するイメージを揃える お互いに意見を出す 一緒に作業をしてみる やってみた作業をふりかえり、次のゴールを考える To Be Continued (「壁を感じないようにしたい」「セキュリティテストをどうしよう」など) 最初に目指したのは書籍で描かれているような姿でした。それは僕たちのチームの方針としては今でも存在していますが、受入れテストの自動化はQAメンバーだけでも実装していきたいなどチームやプロダクトの特性にあわせたものに変わっていきました。チームごとで自分たちなりにどういう姿になりたいかはそれぞれのチームごとに変わっていきます。 たとえば、先ほどの「チームメンバーの自主性がなくてどうしたらよいか？」もそれぞれのチームごとに理想の姿は変わってくると思います。チームをよく観察して、もう少しチームメンバーの顔を浮かべながら、詳しく見ていくのはどうでしょう？たとえば、特定のメンバーの発言がプロダクトに関する議論のときには少なっている場合も自主性がないと感じるかもしれません。また、チームの全員が何かしらの全体に関する方針を決める場面でだけ消極的な発言になりがちなことも自主性がないと感じるかもしれません。この2つの例では、それぞれ理想とする姿も異なってくるでしょう。また、チームメンバーひとりひとりの個性は違うので、自主性の発揮の仕方も変わってきます。発言するのは苦手でも、チームのために一番難しい部分の実装を引きうけてくれる人だったり、実装するスキルは低いけど、みんなで合意した内容を忘れないようにドキュメントを書いてくれる人などです。そうしたメンバーの特性に応じて、チームの理想像を考えてみましょう。 そうすると「自主性がない」とひと言で表現したものは、実は「このチームでは、プロダクトの今後について考える際には多様な意見を出して、選択肢を多くした状態で考えていきたい」というのが理想の姿かもしれません。(あくまで一例です) そこに近づけていくステップとしては、たとえばこんな感じになるでしょう。 多様な意見が出ている状態のメリットを知識として知っている 各メンバーが、その状態についてお互いにどう考えているか共有できている 小さな成功体験を積む To Be Continued (まだ知らない知識があれば勉強会などを開催、全員が発言しやすくなるようにMTGの進め方を工夫するとかなど) ステップごとの実現の仕方は色々あると思うので、自分たちにあった形で実施していくと良いでしょう。たとえば、1on1 で頻繁にメンバーにフィードバックする機会があれば、そこを利用すればいいでしょうし、全員で勉強会やワークショップをしたり、個別に雑談のなかで伝えていくのも良いと思います。 ただ、理想の姿を考えるうえでの注意点として、自分の会社・組織だからここまでしかできないという制約を設けてしまうことはやめてください。それは理想の姿ではなく、現状の先入観を反映した姿でしかありません。理想の姿を考えるのは難しく思うかもしれませんが、誰でも練習をすればできます。たとえば、誰しもが「こんなに残業してるのは変だ」とか「誰もプロダクトの成果に関心がないのは変だ」といったモヤモヤを一つぐらいは持っていると思います。そうしたことを周りの状況などに左右されず解消できている姿を描いてください。最初は書籍で描かれていることを参考にしても良いです。そして、あとはチームメンバーの個性に寄りそった形でアップデートしてください。あとは、そこまでどう近づけていくかステップを考えましょう。別に間違っていても構いません。アプローチは様々あるので、ステップを実施してみて、うまくいかなければ別のステップを考えればいいだけです。もし、ステップをひとつ実施してうまくいけば、みんなでチームの成長を喜びましょう。 理想に近づけていくアプローチをまとめると、こんな感じになります。 できていないこと = 課題だ！とあまり深刻に考え過ぎない。特に解決に時間のかかりそうな(チームだけでは扱いにくい)テーマは、チームがどうなっていると良いかにフォーカスする チームの理想の姿をイメージしてみる。その際にメンバーの個性や適性を忘れないようにする 理想の姿に近づくためのステップを洗いだして、実施する順番を考えてみる ひとつのステップを実施してみて、理想の姿やステップをアップデートしてみる。メンバーの反応なども参考にしよう ステップが無事にうまくいったら、チームで成長を祝う！ 自分たちが直面している課題に正面から向きあうことは大切ですが、自分たちなりの理想の姿を解像度高く持ち、そこに着実に近づけていく。そして、近づくことで成長を実感できることも大事だと思います。 もし、こうした視点がみなさんのチームの成長に向けた活動の参考になれば幸いです。ぜひ、自分たちのチーム開発を楽しんでください！ *1 : Agile Testing については『実践アジャイルテスト』などの書籍に詳しく書かれているので、気になる方はぜひ読んでみてください

みなさん、こんにちは。介護経営支援開発グループでグループ長をしている岩田文彦です。 事業やサービスの成長に合わせて開発組織も大きくなると、新しい課題が浮かび上がってくることがあります。とくに、複数のチームに分かれて開発を進めていると、各チームで最善を尽くしていても、サービスやプロダクト全体で取り組む課題や舵取りが必要になってきます。サービス全体の技術的な課題にトップダウンで取り組んでしまうと、現場のエンジニアに、コミュニケーションの乖離やモチベーションの低下が生じがちになります。 そこで、私たちは、複数の開発チームの横断的な課題を対象にして意思決定する「プロダクトボード」という活動を始めました。この活動により、規模の大きなサービス開発でありながら、現場のエンジニアも参加しつつ、プロダクト全体を舵取りできるよう体制を整えようとしています。 エンジニアリングマネージャーの方や、一定規模の大きな組織でマネジメントやチームビルディングをどのように進めていくか考えている方、エンジニアで将来リーダーや組織のマネージャーになって、自分で何か決めていきたい方などに読んでいただいて、当社の開発の雰囲気を一部でも感じて頂ければ幸いです。 横断的な情報共有と意思決定が必要 介護経営支援開発グループでは、介護事業者向け経営支援サービス カイポケ を開発・運営しています。 『カイポケ』は、介護業務に加えて勤怠管理や給与管理などの40以上の機能・サービスで構成されています。機能・サービスごとに開発チームを組んでおり、運営担当者及びエンジニアを含む、大小合わせて10ほどのチームで構成されています。 特定業界向けのWebサービスとして、それなりの規模になっていると思います。 一方で、カイポケのシステム全体は、どちらかというとモノリシックになっています。ライブラリ・フレームワークのバージョンアップや、セキュリティの観点での取り組みの強化など、横断的な課題対応が欠かせませんが、各チームとしても優先順位を抱えています。 このくらいの規模になると、グループやサービス全体を見ての情報共有や意思決定が不可欠になります。 なお、カイポケの技術的な特徴や開発の様子は、次の記事でも紹介しています。 モダンな開発環境を追求するSMSの技術負債解消の軌跡 複雑なドメインにベイビーステップで立ち向かう 規模の大きなサービスで、全体の舵取りに現場の納得感が得られるか 2019年の夏ぐらいまでは、全体ミーティングの参加者も10名ほどだったので、1時間くらいの打ち合わせで、必要に応じて意思決定できていました。しかし、2020年春ごろから30名くらいに膨れ上がってきて、そこから事業の成長に合わせて、さらに開発組織が大きくなることが見えていました。 このころ、大きな意思決定や舵取りは、エンジニアリングマネージャーである私と、プロダクトマネージャー担当の人および技術責任者の田辺の３名でしていました。 とはいえ、あまり現場のなかに入って動いていない自分たちが、重要な舵取りを意識的にしていくのは、組織の拡大と成長を考えると厳しいところがありました。判断の的確さであったり、現場の納得の度合いであったりが、どんどん弱くなっていくだろうと考えていました。 現場のメンバーには、自分たちが開発している大きな意味でのプロダクト全体に対して、意思決定などの舵取りに、積極的に参加する機会を提供したいと思っていました。 プロダクト全体を対象に意思決定を責務に持つプロダクトボードを設置 そこで、プロダクト全体の運営について、横断的に自分たちで意思決定するプロジェクトチームみたいな場所を設けることにしました。これが「プロダクトボード」です。 ボードというのは、ボード組織とかボードメンバーといった、重要なメンバーが集まるミーティングといった意味合いです。 プロダクトボードは、組織図上で上位にあるマネジメントチームではありません。各開発チームと並列に存在している、ゆるいフラットな集まりです。各開発チームは担当する機能やサービスに責務を持っているのに対して、カイポケというプロダクト全体を対象にして、何かしらの意思決定を責務として持つということになっています。 ボードメンバーに必要になる、普段の取り組みと異なる考え方 プロダクトボードを設置するにあたっては、まずはボードの設立委員会を立ち上げました。そして、参加するメンバーや、位置付け、方針、意思決定する内容、運営プロセスなどを明確にしていきました。 話し合った結果の意思決定プロセスのフロー プロダクトボードを立ち上げて、まだ数か月程度です。春ごろに、法令改正や大きな修正があったので、そのあとスタートしました。現在は、週に1回、1時間ほど、このプロダクトボードで、全体的な意思決定と舵取りを行っています。 現在のメンバーは、カイポケのコア機能のエンジニアや、プロダクトマネージャーなど、およそ10名ほどです。クローズドな会議ではないので、必要なら誰でも自由にオブザーバーとして参加できるようにしています。 現在のところプロダクトボードでは、今期のロードマップやサービス全体としての優先順位を決めています。たとえば、ライブラリやフレームワークをバージョンアップするタイミングだとか、セキュリティの観点での取り組み強化、脆弱性診断など、個々の開発チームでは決めにくいテーマを取り上げるといった具合です。 プロダクトボードで決まった内容は、各チームのロードマップに反映してもらっています。 参加するメンバーには、自分たちのチームでの普段の取り組みと異なる考え方が求められます。自分のチームの個別最適化だけを考えるのではなく、プロダクトの全体最適化を考える必要があるからです。メンバーによって差異はあると思いますが、以前より納得感が得られているのではないかと思います。 課題解決に取り組む幅広い機会を、エンジニアに提供したい このような全体を調整する取り組みは、システムや組織規模が一定以上の大きさになれば、どこでもやっていると思います。しかし、リーダーやマネージャーの会議体として、上位組織に位置付けてあると、現場のメンバーには、やらされ感が出てくると思います。その点、フラットなゆるい位置付けのプロダクトボードという取り組みは、ちょっと珍しいかも知れません。 今後は、チーム横断的なプロジェクトとして発足して適宜アサインしたり、個人が善意で拾っていたものをシステム化したりというように、個人としてチームと折り合いを付けやすい形になっていけばと思います。 また、ボードを経験することで、他チームとの連携や上位レイヤーとのコミュニケーションを体験するという人材育成の側面もあります。マネージャーであったり、アーキテクトであったりと、弊社にもエンジニアのいろいろなキャリアラダーがある中で、プロダクトの課題を技術で解決していく幅を広げる機会になればと思っています。 最後に 元々、私もエンジニアとして、いくつかの大きな開発組織で仕事をしてきて、上位のメンバーが何かを決めて、それを下位のチームが実行するという硬直した状況をいくつも経験してきました。そのたびに、「上の方でまた何かやってるなぁ」といった違和感であったり、「もっと参加できたらなぁ」といった想いを少なからず持っており、いつかは、このような取り組みを実現してみたいと思っていました。 そして、プロダクトボードのような取り組みが有効に機能していって、チーム全体が自立的に意思決定できるようになっていくことで、組織をマネジメントする自分のような立場の人間が、ゆくゆくは見えなくなると良いなと思っています。 今後の取り組みや結果についても、このブログで共有していけたらと考えています。

はじめまして。エス・エム・エスで、エンジニアリングマネージャーとして働く岩田です。 エス・エム・エスは従業員が2千人近い企業であり、組織も整っている、安定した大企業というイメージを持つ人もいるかもしれません。 しかし、私の担当するクラウド型の介護事業者向け経営支援サービス「 カイポケ 」の開発組織は、まだまだ成長途中。土台を整えていくフェーズだからこその面白さを感じています。 この記事では、私がエス・エム・エスに入社を決めた理由や、組織改善の取り組みについてお伝えしていきます。エス・エム・エスの魅力が少しでも伝われば嬉しいです。 組織開発の力を試せる、成長できる“カオス”を求めて 私は、もともと技術やコンピュータに関心があり、大学も情報系の学科を専攻。卒業後はエンジニアとしてシステムやWebサービスの開発に携わってきました。 組織開発に関心を寄せるようになったのは、前職のメガベンチャーでの経験です。チームリーダーとしてマネジメント業務に携わるなかで、若手メンバーの育成やキャリア形成について考えることが増えて、カジュアル面談を取り入れたり、社内勉強会を企画したりしました。 育成に関わるようになると、育てたメンバーが辞めていくときに「あの時、岩田さんに相談したから決断ができた」といった言葉をかけてくれることもあり、嬉しかったですね。 同時に、20代の頃に抱いていた、スペシャリストとして技術力で勝負したい気持ちにも、変化が訪れました。技術を突き詰めるだけではなく、チームや組織が良い状態になければ、優れたプロダクト開発はできないのではないか。役職を重ねていくにつれ、一層そう思うようになったんです。 また、エンジニアのなかにはマネジメントに苦手意識を持つ人も少なくない。そこを埋めるようなキャリアを積んでいけば、より社会や業界において価値を発揮できますし、自分自身のチャンスも広がるのではと思ったんです。 エンジニアリングマネージャーの岩田 前職では、組織開発や育成も含め、自由にチャレンジさせてもらい、楽しく働いていました。しかし、40歳前後になって、培った力が外でも通用するのかが気になり始めました。「ここで何となく過ごしてしまって良いのか？」という気持ちもあって、転職を考えました。 重視していたのは「自分が成長できること」でした。今後のキャリアを考えたときに、「もう一段階、成長をしないといけない」という気持ちがあったからです。 そんな私に転職エージェントが紹介してくれたのが、エス・エム・エスでした。実は、数年前にも一度転職を考えていた頃に、話を聞いたことがありました。お客様に対して誠実な対応をしている姿が伝わってきて、素敵な企業だなと印象に残っていたんです。 数年越しに出会えたのも縁だと感じ、話を聞いてみることに。すると、開発組織は最初に出会った時の約1.5倍程度になっているものの、まだまだカオスな状態だとわかりました。「開発組織の改善が、会社全体の成長を牽引する鍵になる。今はそこに課題がある」とも言われました。 私は前職でも、組織が9年間で数倍に拡大するフェーズを体験し、ジェットコースターのような変化に対応するなかで大きく成長できた実感がありました。 話を聞いていて、エス・エム・エスはまさに同じような状況であると感じましたし、そこに前職とは違う立場で携わってみたいと思ったんです。立場が変わっても、前職での成長を再現できるのか、試してみるのも面白そうだなと感じました。 組織・チーム・人が一体となって、価値提供できるように 入社後は、介護事業者向け経営支援サービス「カイポケ」の開発組織に、エンジニアリングマネージャーとして配属されました。「カイポケ」は、介護事業者の経営改善に役立つ40のサービスで構成されているプロダクト。開発組織は、大小合わせて約10チームで運営しています。 まずは現状を探るために、チームの定例やメンバーとの1on1を通じて、組織の良い点や課題点を明らかにしていきました。 良い点としては、サービスや事業への愛が強く、真面目なメンバーが多いことが挙げられます。個人が自律的に動こうとし、能動的な助け合いが起きているのも印象的でした。 一方、いくつか解くべき課題も見えてきました。それらを踏まえ、入社後は大きく以下の施策に取り組んでいます。 プロダクト全体の意思決定をする専門チーム「プロダクトボード」の設立 チームごとのロードマップの可視化と共有 評価制度の運用 各施策について、どのような課題意識のもと立案したのか、どのように導入・運用を進めていったのかについて紹介できればと思います。 「プロダクトボード」の設立 プロダクトボードは現場のメンバーも参加し、プロダクト全体の意思決定をする機関です。今は、私と事業側のマネージャー、プロダクトマネージャー、エンジニア合わせて8名で運営しています。 課題意識 もともと、カイポケの開発組織では、チームの担当範囲についてはそれぞれが決め、横断的な意思決定はエンジニアリングマネージャーの私と事業マネージャーで担っていました。業務としては問題なく回っていますが、方向性を一つにまとめる場や人がいない状態でした。 これから組織規模が大きくなってくると、全体としてどう動いているのかが見えづらくなることが予想されます。エンジニアリングマネージャーである私が、現場の状況を掴むのも難しくなっていくはずです。 現場にとって納得感のない決断は、スケールを妨げることにもなりかねません。個人的な経験からも、現場に近い人たちが自ら議論して意思決定をするほうが、よりよい解にたどりつけると思っています。カイポケの開発組織も、プロダクトの方向性を自分たちで決められるようにしていきたいと考えていました。 また、カイポケの事業成長においては、新たな価値創出につながるプロダクトの実現と、既存プロダクトの安定化や市場ニーズへの対応が欠かせません。両方のバランスを取りながら、機動的に、組織としての意思決定を行う必要がある。そのためにも、事業戦略との接続や戦略実行を推進する機関を、新たに立ち上げるべきだと考えていました。 実施したこと まずはメンバーにプロダクトボードの目的を伝え、2021年の年明けから試験的にスタートしました。私と事業マネージャーによるファシリテーションのもと、各チームから1〜2名、合わせて10名ほどが参加しました。 しかし、端的に言うと、うまく機能しませんでした。前提やコンテクストの共有が不十分であったこと、人数が多すぎて十分に話せない人がいたことなどがあり、議論や意思決定が思ったようには進まなかったんです。 反省を踏まえ、約1カ月後に「プロダクトボード準備委員会」を立ち上げました。これは、プロダクトボードの背景にある課題意識を共有し、どんなチームを作るかを議論する委員会です。トップダウンではなく、準備段階から開発組織のメンバーを巻き込み、一緒に作り直していきました。 その結果、前提や課題意識を共有でき、見えていなかった現場の課題や改善のアイデアも、メンバーから挙がりました。 準備委員会での議論を踏まえ、プロダクトボードは人数を絞って進め方を調整し、2021年5月末に再び始動しました。運用しながら引き続きブラッシュアップしていきます。 ※ こちらのプロダクトボードについては後日改めて記事を作成する予定です。 チームごとのロードマップの可視化と共有 ロードマップは2020年の夏から始めた取り組みです。各チームが年度内に「チームとしてどこを目指すのか？」「その目的に向けて、どのように進むのか？」を考え、共有します。 課題意識 カイポケの開発組織は「現場のことは現場で決めたほうが良い解が得られる」という考えのもと、個人やチームが自立性を高めてきました。その考え自体には同意するのですが、チーム間の連携が弱く、サービスとして目指す方向性に意識のバラツキがあったんです。 足並みを揃えるためには、それぞれのチームが「事業や顧客にどんな価値をもたらしたいのか」という方向性を言語化し、それらをロードマップとして組織全体に共有して、お互いに理解を深める機会が必要だと考えました。 また、チーム単位でプロダクトの提供価値や開発の意義を深く考える習慣ができれば、チームメンバーはより中長期的な視点をもって日々の業務における意思決定を行えるようになります。それはプロダクトの成長にも寄与するはずです。 チーム間の連携やチームメンバーの成長、そしてプロダクトの成長を考え、ロードマップを作成しようと決めました。 実施したこと まずはプロダクトマネージャーと、ロードマップに加えるべき項目を話し合い、以下を設定しました。 テーマ（製品開発の狙い） （例）ノックアウト要素回避。顧客獲得促進。 テーマを選んだ背景 （例）厚労省シナリオの××から。顧客要望を基にした〇〇の仮説から。 価値提供先 （例）介護事業者。エス・エム・エスのカスタマーサポート。開発者。 価値提供先に届ける価値 （例）事業者の××が楽になる。開発者の生産性が向上する。 製品をリリースしたことによって得られる効果（テーマとの連動） （例）補助金の対象になり、獲得効率がアップする、競合他社への劣後防止。 これまで組織としてロードマップの作成は求めてこなかったこともあり、最初は「なぜやるのか？」と戸惑いの声も挙がりました。メンバーからの疑問に一つひとつ答えたり、毎月フィードバックのタイミングを設けてディスカッションを重ねたりして、浸透を図りました。 まだまだ、一体感が醸成できたと言えるレベルには達していないと捉えています。ただ、チームにおいて「自分たちがどこを目指すのか、何のためにやるのか」を考え、立ち返る意識が根付き始めている実感があります。所属するメンバーの目線も上がり、半年先、一年先を見据えて思考、行動できるように変化してきました。 評価制度の運用 評価制度については、正しい評価をしてメンバーの成長を促すために、運用の仕組みを整えました。 課題意識 カイポケの開発組織の課題として、一人ひとりの技術力のバラツキや育成の仕組みが足りないことが挙げられます。 当たり前のことですが、チームで働く人はロボットではありません。人間が成長できる制度や環境があり、それがチームのパフォーマンスにつながる状態をつくっていきたいと考えていました。 そのために、より成長や育成に寄与する形で、目標設定や評価制度の運用を整備しました。 実施したこと 2020年は、目標設定のスケジュール管理や、評価の観点を定めたシートの設計など、運用フローを整備しました。基本的には、成長を達成するために目標があり、その成果として評価をするという考え方に則っています。 2年目の今は、昨年見えてきた課題をもとに、改善を重ねているところです。例えば「年に一度の人事考課の他にフィードバックの機会がなく、自分の状態がわかりにくい」という声に対し、3カ月ごとに仮評価のタイミングを設定しました。メンバーが今の評価や目標との距離を把握し、安心して日々の業務に取り組める形をつくるのが、今期の取り組みです。 3つの施策を通して、組織全体で納得できる意思決定を行い、チームで方向性を共有し、個人が目標に向かって成長し続ける組織にしていきたいです。それによって事業やプロダクトでより価値を提供できるようになると思っています。プロダクトボードやロードマップ、評価制度はそれぞれ別の施策ですが、相互に結びついているのです。 いずれも「カイポケ」にとって、大きな変化となりましたが、上司は「やってみたらいいんじゃないですか？」と、自由に挑戦させてくれました。「まずはやってみよう」とトライし、何かあったらすぐ改善するスタイルで取り組んでいます。 事業の安定性と答えを探究できる余白が魅力 今のエス・エム・エスは、元々の強みであるセールスやマーケティングに加えて、エンジニアリングにも注力し、開発組織を強化していくフェーズです。ビジネスの基盤がありつつも、開発組織はまだまだ成長途上。正解も間違いもないからこそ、答えを自分の力で導き出せる面白さがあります。 事業側だけでなく、開発側にも大きな権限があり、良いプロダクトを作るための試行錯誤を繰り返せる環境は、希少だと感じています。 さらに、プロダクトを通して、働き手不足などで悩む介護業界にアプローチできる。日々ニュースなどで介護の話題が取り上げられるたびに、自分が取り組んでいる仕事の意義を実感します。 今後も、プロダクトを利用してくださるユーザーの方に、少しでも良い影響を与えられるものを作れる開発組織にしていきたい。そのために、一人ひとりが自律してフラットな関係を築いているけれど、必要なときには一丸となって困難に立ち向かえるような、個性豊かで柔軟性のある組織にしていきたいです。 また、エス・エム・エスのエンジニアメンバーがエンジニアの市場において「エス・エム・エスのエンジニアは、品質に妥協しない、誠実な人が多い」と評価してもらえるようにしたいです。