医療・介護・ヘルスケア・シニアライフの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つの施策を通して、組織全体で納得できる意思決定を行い、チームで方向性を共有し、個人が目標に向かって成長し続ける組織にしていきたいです。それによって事業やプロダクトでより価値を提供できるようになると思っています。プロダクトボードやロードマップ、評価制度はそれぞれ別の施策ですが、相互に結びついているのです。 いずれも「カイポケ」にとって、大きな変化となりましたが、上司は「やってみたらいいんじゃないですか？」と、自由に挑戦させてくれました。「まずはやってみよう」とトライし、何かあったらすぐ改善するスタイルで取り組んでいます。 事業の安定性と答えを探究できる余白が魅力 今のエス・エム・エスは、元々の強みであるセールスやマーケティングに加えて、エンジニアリングにも注力し、開発組織を強化していくフェーズです。ビジネスの基盤がありつつも、開発組織はまだまだ成長途上。正解も間違いもないからこそ、答えを自分の力で導き出せる面白さがあります。 事業側だけでなく、開発側にも大きな権限があり、良いプロダクトを作るための試行錯誤を繰り返せる環境は、希少だと感じています。 さらに、プロダクトを通して、働き手不足などで悩む介護業界にアプローチできる。日々ニュースなどで介護の話題が取り上げられるたびに、自分が取り組んでいる仕事の意義を実感します。 今後も、プロダクトを利用してくださるユーザーの方に、少しでも良い影響を与えられるものを作れる開発組織にしていきたい。そのために、一人ひとりが自律してフラットな関係を築いているけれど、必要なときには一丸となって困難に立ち向かえるような、個性豊かで柔軟性のある組織にしていきたいです。 また、エス・エム・エスのエンジニアメンバーがエンジニアの市場において「エス・エム・エスのエンジニアは、品質に妥協しない、誠実な人が多い」と評価してもらえるようにしたいです。

@sunaot です。『 「継続性アーキテクト」という生き方 』や『 アーキテクトを目指すエンジニアの最短ルート 』が興味を持ってもらえたので、この記事ではアーキテクトの仕事の重要な一部だと考えている「ビジネスの構造をアーキテクチャで表現する」ということについて書いてみます。 ビジネスの構造と書いてしまうと、業務のモデリングの話かなと思われるかもしれません。実際、設計手法について書かれている書籍では業務のモデリングの話が中心です。その時代の前提は、要求を持っている人としてのユーザーがいて、業務があって、そのシステム化をしていくというものでした。現在、サービス開発をしていくという中で直面している仕事はやや性質が変化していると感じています。正解となるサービスの姿というものはなく、やっているビジネスの状況やユーザーの関心も変化する中でサービス開発をし、サービス自身も変化をしていきます。サービス開発年代のモデリングでは、ビジネスの構造とサービスを利用するユーザーへのモデリングというのを意識していく必要があります。 まずは、ビジネスの構造をモデル化するとはどういうことかの説明から始めます。 ビジネスの構造をモデル化する *1 Martin Fowler のアナリシスパターンでは、モデリングの原則としてこのように書いています。 多くの企業において、このような基礎的な法則はほとんど理解されていないし、それを明らかにするにはかなりの努力を要する。このために概念モデルを作成する。概念モデル、すなわちメンタルモデルは、問題を理解可能にし、単純化する。 アナリシスパターン (Martin Fowler) 第一章導入より これは重要な原則を示している。すなわち、正しいモデルや誤ったモデルというものは存在せず、目的の仕事にとってどの程度使いやすいかの違いだけである。 モデリングの原則 モデルは正しいか誤っているかではなく、使いやすいか使いにくいかである。 アナリシスパターン (Martin Fowler) 第一章導入より これにならって表現すると、「ビジネスの構造をモデル化する」とは、「ビジネスの成功へ使いやすい構造を見つけ出し、ソフトウェアアーキテクチャとして表現すること」です。 ビジネスについて、そのビジネスに関わるものを通して目的（ミッション）を達成するための構造を明らかにします。営利企業である場合は、多くの場合に儲けの構造も含まれます。ただ、それ以外も含めた成功の構造を表現することになります。 どんなアクターがいて、どういう行為を行って、それによる相互作用はどのようになって、そこへどんな意思を入れていき、目的の達成（ビジネスの成功）へたどり着くのか。そのストーリーを理解し、概念を見出し、名前をつけていくことです。また、業務というのはこの実現のための個々のプロセスのことになります。 たとえば、SNS のサービスを開発しているとします。そこには複数の「お知らせ」が届く inbox があり、その中には有償版へのアップグレードの訴求メッセージが届いていたり、つながりのあるユーザーからのメッセージの通知が届いていたりします。 また、サイドバーには「広告」を掲載するための領域があり、表示の都度違う広告が表示されたりします。広告の内容にはそのサービスのアドオン機能の利用を働きかけるようなものがあったり、広告主の顧客から出稿されている広告があったりします。 このときに「お知らせ」や「広告」を機能として実現し、その内容はそれぞれの機能へ入力されてきたテキストとして表現するか、それともなにかしらの概念をコンテンツの中身の分類に見いだしていくかというのを考えることが、ここで言っている「ビジネスの構造のモデル化」になります。 その SNS が Twitter のような相互のつながりとそのインタラクションが価値のキーになっているものであればユーザー間のインタラクションへの柔軟性と拡張性を担保できるような設計が適しているでしょうし、 LinkedIn のようなクライアント企業からの売上を収益モデルとしているようなものであれば一見同じような機能でもユーザー接点は貴重な広告枠にもなるためそれを考慮した設計が適しているでしょう。 これをアーキテクチャの中で別のサービスとして分離するのかレイヤーとして表現するのかクラスの中で概念を表現していくか、あるいはあえて抽象化をしないのかというのは場合によりますが、少なくともそれを判断できる程度に自分たちのビジネスがどういう性質と構造を持つものなのかを理解することが重要になります。 なぜビジネスをモデル化することが重要なのか？ 自分たちのビジネスがどういう性質と構造を持つものなのかを理解することが重要と書きました。また、内容としても「モデリング対象を理解しそれを設計で表現する」ということであれば、業務のモデリングと変わることはなさそうに聞こえます。どうしてわざわざビジネスの構造のモデル化を取り上げて重要性を語る必要があるのでしょうか。 理由は、ビジネスは成功に向けて時間の経過の中で変化する必要があり、モデリングする対象自体が変化するからです。ビジネスは事実をどう解釈するかによって、ビジネスのモデル化された姿自体が変化し得るものです (そのビジネスをどういうものだと見るかという解釈が幾通りもありえます)。業務も時系列では要求が変化しますが、ある時点というスナップショットでは事実が観測できます。なにが行われているかという事実は観測することができるものの、それをどういうものだと見做すかという点で解釈の仕方に幅があるビジネスのモデル化というのは「現在の姿」でも不確かな部分があります。さらに、顧客となるユーザーとの関係性や他者との競争のポイントが変わってくる点も含めて「将来の姿」を考えようとすると、より大きな変化の動機になりうるので、それをモデル化し反映していくことが重要になると考えています。そして、業務や機能のレイヤーで考慮するよりもその前提となるものとして、自分たちのビジネスをどう解釈しているか、どう扱うか、アーキテクチャの中での位置づけを考えておくことが大切です。 ビジネスの意図をアーキテクチャで表現する ビジネスをモデル化し続ける場合、ビジネスとソフトウェアアーキテクチャを写像のように一致させ続けることになります。ビジネスの変化に応じてソフトウェアが変わっていくために、変化のポイントを理解し、変更と拡張に対して設計をしていきます。 このためにはビジネスの意図というのが機能とは別のレイヤで存在し、それをソフトウェアアーキテクチャで表現する必要がある視点を持つこと、それからそれができるくらいに自分たちのサービスの性質と構造を深く知りにいくことが必要になります。 仮にそうしない場合にもビジネスの要求自体はなにかしらの形でサービスへやってきます。構造の理解が甘いままにそれを機能として実現し続けていくと、本来は隠れていた関心事があちこちのコンポーネントやモジュールに散らばり、その歪みが長期的に変更や拡張を妨げていくことになります。 ビジネスの意図を理解し、その構造をモデル化していくことを実践するときにもっとも重要なのは、ビジネスを深く知り、自身でもビジネスの不確実性を含めて予測をし、その上で設計判断をすることです。そして、ソフトウェアエンジニアの眼によって、現実世界のビジネスを分析・解釈していくことです。 ソフトウェアアーキテクチャとして表現する 焦点を置くべきはプログラムの品質、正しさ、僕たちがメンテナンスしたり変更を追加できる能力です。 http://eed3si9n.com/ja/simplicity-matters ソフトウェア企業が長期にわたって価値を提供し続けるためには、ユーザーへの貢献・ビジネスの成長、そのストーリーとソフトウェアとの整合をとり続ける (写像) ということが非常に大事になってきます。 ここは「ユーザーへの貢献・ビジネスの成長、そのストーリー」にはっきりと意思があれば、踏み込めば踏み込むほど面白くて、その方針の不確実さと実現コストと後への影響を同時に評価し続けながら、具体化していくステップの踏み方を考え、一緒に議論し、それがビジネスとしてのストーリーにまた反映されていくことになります。そして、そこで得た理解と見通しから、またソフトウェアアーキテクチャを更新していきます。 これは、技術に精通していて具体化をしていくときの手段について、会話の中で評価可能なエンジニアだからこそできる仕事になります。 この記事を読んでいる人の中にも、ビジネスの方針が伝えられたときに「これは後々困ったことになるな」と感じたことがある人は多いでしょう。むしろ数え切れないほどあるのが通常かもしれません。ビジネスの方針を考えている人はソフトウェアへ無関心だから仕方のないことなのでしょうか？ 私はそうは考えません。たしかにソフトウェアの設計そのものへ関心がある人は少ないかもしれませんが、その結果、将来のビジネスの制約が増えてくると知ったら当然関心があるはずです。 このビジネスのストーリーをソフトウェアの設計へ織り込もうとすると、いくつかの選択肢があって、Aの選択肢をとったときには実現までの時間がかかる。Bの選択肢の場合は実現は手軽だが将来の選択肢や開発サイクルへの悪影響が考えられる。一方で、このストーリーははたしてどのくらいビジネスの中で重要なものなのか。今のテーマの中で順序をつけるとすると何番目のものなのか。インパクトと実現の確かさの見込みはどの程度のものなのか。そのときにA、Bの選択肢はインパクトや実現の確かさの見込みに対して筋の良いものなのか。他の選択肢はないのか。 こういったことを会話しながら今とるべき行動を決めていきます。 ソフトウェアの困難として目に見えないこと（不可視性）が言われますが、実はビジネスの構想も目に見えないものです。実現するまで検証ができないという点もよく似ています。共に不確実なものを扱っているので、それぞれに専門性を持つ人同士が今評価できるかぎりを評価し、いかに早く実際に試してみて市場からの結果で評価をするところまでたどり着くのかが大事なのだと思います。 ビジネスの意図、ソフトウェアアーキテクチャの中でのその表現の仕方、実現のしやすさと将来への影響、実行する場合の具体的なイメージ。これらを行ったり来たりしながら具体化するまでの道筋をつくっていく仕事がサービス開発年代のアーキテクトの仕事だと考えています。 終わりに ここまで書いてきたことは、従来のアーキテクトの仕事の文脈から外れた新しい概念かというと、実はそんなことはありません。従来から優れたアーキテクトであれば実際の仕事の中で自身の仕事のスコープへ入れていたはずの話になります。 たとえば、増田亨さんのTweetでは 良い設計とは何か 価値は 事業貢献 発展性 事業に貢献する設計原則は 事業方針との整合性 事業との直接的な写像 事業ついての能動的注意 発展性を生み出す設計原則は 関心の分離 一箇所に書く 分かりやすく組み立てる — 増田 亨 (@masuda220) 2021年3月17日 の中で、 事業に貢献する設計原則は 事業方針との整合性 事業との直接的な写像 事業ついての能動的注意 としてその仕事に言及されています。 また、事業会社で働くアーキテクトであれば、当事者として自身がビジネスの設計とソフトウェアアーキテクチャの設計を行き来している人がいることも知っています。 ただ、「わかっている人はやっている」ものの、あまり文書としてそれが説明されたものを見たことがなかったため、あらためてサービス開発の時代のモデリングの話として書いてみました。 ソフトウェア設計の能力を磨いた人がその優れた設計能力の先に発揮する価値の一つの選択肢として、ビジネスをモデル化することに興味を持ち、楽しんでもらえたらと思います。また、実際にエス・エス・エムでやっているビジネスはどういうもので、システムアーキテクチャとしての設計判断というのはどういう風にしているのかという話に興味のある方はぜひ話を聞きに来てください。 *1 : ビジネスモデルという呼び方があり、言いたいことは大筋違っていないのですが、ビジネスモデルも含めたビジネス全体の構造のモデル化を指したいのであえてその呼び方を使っていません

2020年11月にエス・エム・エスに入社した福嶋です。これまでに国内大手ソフトウェア企業でのシステム開発や、約200万人のユーザーが利用するWebサービスの開発などを経験してきました。 今回は、私がエス・エム・エスに転職を決めた経緯や、現在の仕事内容、今後目指したいことについてお伝えしてみたいと思います。 ユーザーと共にサービス開発に従事する楽しさ 「長いエンジニア人生をどのように過ごすか」 これはエンジニアであれば誰もが考えることではないでしょうか。定年を60才と考えると、エンジニア人生の半分を過ぎたとき、私はどう残りのエンジニア人生を過ごすかを考え、転職を決断しました。この決断に至るまでの流れを少し振り返ってみます。 私のエンジニアとしてのキャリアは、大学卒業後に国内ソフトウェア開発会社に入社し、パッケージ製品の設計・開発に携わることから始まりました。その後、転職してグループウェアサービスの開発チームに所属して、技術責任者を担当しました。ユーザーがいない状態から始まり、最終的に約200万人が利用するサービスまで育てるという経験ができました。 様々な開発を経験しましたが、印象に残っているのはチャット機能の実装です。プレスリリースを出したら、Twitterで「待ってた！」「使ってみたい！」という反応がありました。ユーザーの声に耳を傾けながら開発していたので、実装した機能にユーザーから直接フィードバックがあるのはとても面白かった。 機能の実装によって、サービスの使われ方が変化したのも印象に残っている理由のひとつです。チャット機能が実装される前は、掲示板がディスカッションの場所でした。チャット機能が実装されてからはちょっとした会話や議論がチャット上で起こるように変わっていった。チャットで決まったことが掲示板などにストック情報として記載されるようになり、グループウェアの使われ方が変わりました。 機能実装以外で印象に残っているのは、開発したサービスが社会に対して貢献できているという実感できたエピソードです。ユーザーに在宅医療をしているお医者さんがいらっしゃって、その方がグループウェアを使って患者さん1人につき1つのグループを作り、お医者さんと看護師さんと在宅ヘルパーさんも入ってコミュニケーションしている事例がありました。 その事例ではグループウェア上で、患者さんごとにグループを作り、患者名をグループ名に設定。そのグループに病院の職員のみなさんと、訪問看護ステーションの看護師やケアマネジャーなど、関係するスタッフが参加し、患者さんやご家族が抱えている様々な問題の共有や治療方針、ケアの方針の確認、伝達などに利用されていました。患者さんの状況について共有した情報が他の在宅ヘルパーにも伝わる状態が生まれ、患者さんも何度も同じ説明する必要がなくなった。患者さんはちゃんと見てもらえているという実感が得られ、満足できたそうです。自分が手掛けたプロダクトが社会に貢献できているなと感じられたエピソードです。 事業の強さは健全な開発環境につながる その会社では8年ほど働いていたのですが、「AWSに来ないか」と声をかけてもらったことがきっかけで転職。AWSでは、まずサポートエンジニアとして、AWSサービス単位のお客様の困りごとを解決する仕事をしました。 サポートエンジニアを2年9ヶ月ほど経験し、仕事の目標を達成したことを機会に、ソリューションアーキテクトへ職種変更しました。ソリューションアーキテクトの仕事では、クライアントの要望や要件を伺いながら、最適なAWSサービスの組み合わせやアーキテクチャをサポートします。私は、ソリューションアーキテクトの中でも、お客様のプロトタイピング開発を支援する仕事をしていました。 ソリューションアーキテクトである私自身はお客様のコードを書いてはいけないという決まりがあったのですが、クライアントと一緒にサービス開発を経験できたことはとても楽しく、サービス開発にやりがいを感じていたグループウェアサービス時代を思い出しました。 AWSでのお客様のサービス開発をサポートする経験を経て、「もう一度サービス開発をしたい」と考えるようになりました。そんなとき、登録していた転職サイトからスカウトメールが届き、これが自分のエンジニア人生としての残り時間の使い方を考えるきっかけとなりました。 「AWSでお客様の開発を支える仕事を続けるか、サービス開発の現場に戻るべきか？」 そう自分に問いかけたときに、開発者として働く方が幸せだと考えました。サポートと開発、両方の仕事を経験したからこそ、この結論に至ったと思います。また、サービス開発の現場に戻るべく、どの業界、どの企業でサービス開発をするかを考えました。 自分のなかでは「市場が伸びている」「事業が伸びている」などの点は重視しました。事業が伸びなければ、給与は上がらず、人の流出が激しくなります。そうすると、開発環境をモダンにするためにリソースを割くのは難しくなってしまう。開発環境が改善されていくために、財務的に健全な企業であることは重要だと考えていました。 その観点を持ちつつ、業界は絞らずに転職活動をしていました。お声がけいただいた企業の中から、エス・エム・エスを選んだのは、複数の観点から検討し、総合的に判断した結果です。先述の事業が伸びているかどうかに加え、モダンな開発環境があるかどうか、自分がサービス開発に従事できるかどうかなどが判断のポイントでした。 エス・エム・エスの市場におけるポジショニングも判断のポイントになりました。手掛けているサービスは、市場においてナンバーワンのシェアではない成長中のものも多くあり、それがよかった。すでに業界一位であれば挑戦する余地が少ないですし、ゼロから事業を立ち上げるのはやりがいはありますが、ハードルが高い。 エス・エム・エスは業界トップになるための挑戦権がある。かつエンジニアレベルやモダンな開発環境を備えているため、近い将来にトップを取れそうだと考えました。そんなエス・エム・エスに自分の経験を加えれば、事業成長をさらに加速できると思いました。 AWSを駆使したアーキテクチャへの移行をリード 他に内定をいただいた会社では、まずはSREとして仕事をして、将来的に開発に関わることはありえるという内容でした。自分は開発の仕事がしたくて転職を検討していたので、入社前に開発を約束してもらえていたのも決め手でした。 入社してからわかったことですが、前職がAWSだったのでエス・エム・エスのエンジニアの方々から「SREをやってもらったほうがいいんじゃないか」という意見も出たそうです。そのとき、エンジニアリングマネージャー（EM）の田辺さんが開発と押し切ってくれたと聞きました。おかげで現在、私は前職の経験を活かして介護事業者向け経営支援サービス「カイポケ」のチームでAWSアーキテクトと開発エンジニアを兼務しています。 入社して経験した大きな仕事は、AWSを駆使したアーキテクチャの移行です。エス・エム・エスは数年前にAWSに移行をしていたのですが、まだまだ使いこなせているとは言い難い状態でした。 カイポケの利用者が増加していくなかで、サービス運用を継続しながら改善や新規機能の開発に耐えうる設計にしていかなければなりません。以前の開発環境は、一部のコードを変更すると別の場所に不具合が出てしまい、新機能開発にも時間がかかってしまうこともありました。 この状況を解消するために、アプリケーション側で実施していた処理の一部をAWSのフルマネージドなサービスに移しています。これによって、アプリケーションがシンプルになり、機能の変更や追加の際に、不具合を発生させにくくなります。これらの開発をうまく進めるというのは、AWSアーキテクトとしての腕の見せどころです。 カイポケでは、新機能の開発に加えて、技術負債の解消、さらには2〜3年に一度の介護業界の法改正に対応する必要があります。まだ入社してから時間があまり経過していませんが、自分の経験を活かしてサービスの改善のために取り組んでいるところです。 もちろん、導入して終わりではなく、いかに運用していけるかが、今後の開発の精度の鍵を握るといっても過言ではありません。AWSアーキテクトとして、継続してシステムの運用に伴走していきたいと考えています。 また、カイポケには色々なチームがあり、どのチームもどのようにAWSを活用するとなおいいのか把握できていない状況。まず、私たちのチームがアーキテクチャを実際に構築することで活用事例を作り、他のチームにもノウハウを提供できるようにしたいと思っています。 変化に対応し、学習を重ねる開発組織 エス・エム・エスに入社して感じるのは、エス・エム・エスの事業領域である介護領域についての新しい知識を学ぶ重要性です。介護領域では、制度改正や改正に伴う現場対応など、目まぐるしい変化が起こり続けています。こういった変化に、どう技術を適用させるかは非常にチャレンジングで魅力です。 また、開発現場もこうした変化に対応できるように日々研鑽を重ねています。会社によっては、納期に追われるエンジニアが大きなプレッシャーを感じることも少なくありません。エス・エム・エスでは、試行錯誤を重ねることを良しとし、開発内容によっては時間がかかることも考慮してもらえています。そのため、事業のために必要な開発に集中できます。 また、他のエンジニアが書いたコードを見てレビューを行うなど、誰か一人に全責任が課されるのではなく、助け合う文化があります。うまくいかない時は原因を一緒に考えるなど、開発組織みんなで課題に取り組むような雰囲気です。 エンジニアのなかには自分一人で開発をしたい方もいるかもしれませんが、こうした開発組織のあり方は学びも起こりやすく、エンジニアとしての成長も加速できるのではと感じます。

医療、介護、ヘルスケア、シニアライフの領域で高齢社会に適した情報インフラを構築している株式会社エス・エム・エスでエンジニアをしている @moro です。 主に介護領域におけるキャリア分野のサービス、平たく言えば介護の担い手である従事者の方の就職・転職を良いものにするための事業に携わっており、特に カイゴジョブ という求人サービスの開発・運用をしています。 カイゴジョブについて カイゴジョブは 2004 年にオープンした、介護職向け求人情報サービスです。 2019年9月にフルリニューアルし、現在は Ruby on Rails で動いています。筆者は2018年にエス・エム・エスに転職してこのリニューアルに関わり、以来ずっとカイゴジョブの開発・改善を続けています。 現代のソフトウェアサービスでは、リリースしたら完了でそのあとは変更しない、というものは少なく、多くは継続的に変化し続けます。これは、サービスによって解決したい社会課題、つまり事業のありようが変化していくためです。 カイゴジョブも例にもれず、サービス開始当初からリニューアルに至るまでも、またリニューアルリリースから今日に至るまでも、たくさんの人々が・各々の思惑で・日々いろいろな施策を実施してきました。 ※ 本稿では、以下のように用語を使い分けます 事業 エス・エム・エスにおける介護領域のキャリア事業。あるいはその一部としての求人広告事業。 サービス www.kaigojob.com で運営しているカイゴジョブサービスといった、上記事業を遂行するために存在するサイトなど。 ソフトウェアプロダクト リポジトリ内のコードや、AWSインフラで動いているプロセス群といった、上記サービスをソフトウェアとして実現するための各種コードやデータ。 つまるところ、事業が変化すればサービスも変化する必要があり、そしてその実装であるソフトウェアにも変更が発生します。 本稿は、このカイゴジョブのリニューアルとその後の継続的なサービス開発を通じ、ソフトウェアを変化し続けられるようにするためにやっていることを紹介します。 「できるだけ全体」を知ろうとする 長く続いたサービスのリニューアルでは、初期担当者の異動や退職、サービス責任者の交代などの理由で、そのサービスの全体を知っている人がいないという事態がたびたび発生します。例にもれず、カイゴジョブのリニューアルにおいても、開発チーム内にすべてを知っている人はいませんでした。 一方、「すべて」を知っている人はいなくとも、日々それぞれの業務をしている人々はもちろん存在します。そこで、その人々と会話し、日頃の業務を知ることで、カイゴジョブというサービスの全体はどういったものであるかを描き出そうとしたわけです。 リニューアルのために関係者と会話をしていった結果、カイゴジョブに大きく3種類のアクターが存在し、それぞれ下記のようなユースケースがあることがわかってきました。 A: 介護従事者を採用したい法人として A-1. カイゴジョブに求人広告を出稿したい A-2. 応募してくれた求職者に連絡を取りたい B: 転職を考えている求職者として B-1. カイゴジョブに登録したい B-2. 求人情報を閲覧・検索したい B-3. 気に入ったものに応募し、転職プロセスを始めたい C: エス・エム・エス業務担当者として、上記の一連のフローを支援したい C-1. 法人対応の担当者として、顧客がカイゴジョブを利用できるようにしたい C-2. 広告担当者として、求人広告内容を確認し掲載したい。不備があれば顧客に修正依頼したい C-3. 請求担当者として、カイゴジョブの利用状況に応じて費用請求したい サービスを開発する場合、どうしてもインターネットから見える主要画面に力を入れたくなります。カイゴジョブの例であれば、Bがその「インターネットから見える」部分にあたるでしょう。ここの改善に注力したい感覚は、まったくもって妥当です。 しかしその体験を良くするにはBだけを作り込めばよいわけではなく、A-1ができる必要もありますし、そのためにはC-1や2の業務ができる必要があります。 さらに、サービス上でできることはB-3の応募が大きなポイントとなりますが、求職者にとっても事業者にとっても、本当に大事なのはそこからの転職プロセスであり、さらに入職後です。それをスムーズに実現するためにはA-2が滞りなく進むことが必要です。 そのためリニューアルの際は、Bの箇所だけでなく、法人がサービスの利用契約をしてから実際に求人広告を掲載するまでのオペレーションや月々の利用状況に応じた請求のオペレーションをどこまでこのシステム内に作り込むべきかを早期に議論しました。議論の結果、契約や請求にまつわる主要部分は外部のシステムに役割を完全に移行し、リニューアルしているソフトウェアからは自動/手動でデータ連携するのみに留めることとなり、リニューアルのスコープを小さくできています。そのように整理できたのも、早い段階でそこに境界を設定できることを可視化できたためであると思います。 この「まず粗く全体を作る手法」はリニューアルを終えた現在でも続けています。 もちろん、なにかのフィーチャに取り組む際に毎度が毎度「顧客契約〜請求」までの全フローを考えているわけではありません（逆にそれが必須となるのが、既存事業のリニューアルの大変さですね）。 それでも、2-4週間ほど掛かりそうな大きめのフィーチャについてはいまも「フィーチャ全体を粗くつなげる」「各要素を育てていく」サイクルを繰り返しています。 どんなフィーチャも利用者がそれを利用するためのコンテキストがあり、またフィーチャによって得られる便益があります。 ここでもやはり、フィーチャの目玉となる部分を作り込む前に「できるだけ全体」を俯瞰して理解できることは、結果としてフィーチャの磨き込みにおいても役立ちます。 「全体」をベースに重点箇所を育てる いったん「最初の全体」を描き出した次は、これらの業務を一通り辿れるようにすることを最初のマイルストーンとしました。 C-1. 法人対応の担当者として、顧客がカイゴジョブを利用できるようにしたい A-1. 介護従事者を採用したい法人として、カイゴジョブに求人広告を出稿したい C-2. 広告担当者として、求人広告内容を確認し掲載したい。不備があれば顧客に修正依頼したい B-1. 転職を考えている求職者として、カイゴジョブに登録したい B-2. 転職を考えている求職者として、求人情報を閲覧・検索したい B-3.転職を考えている求職者として、 気に入ったものに応募し、転職プロセスを始めたい A-2. 介護従事者を採用したい法人として、応募してくれた求職者に連絡を取りたい C-3. 請求担当者として、カイゴジョブの利用状況に応じて費用請求したい この段階では、Rails + 古典的なHTMLリンクやフォームでの遷移が中心で、デザインも仮組みです。 他システムとの連携においても「ここでJSONを取りに行く」「CSVをエクスポートする」くらいの精度で実装していき、内部のファイルレイアウトなどは「あとで決める」箱に入れておきました。実装としては、データの入出力部分を抽象化したアダプターを作成しておき、本実装した後に切り替えるという手法で仕上げています。 このような粗い実装であっても、一通りのフローをつなげて動かせるようになることで、リニューアル中のカイゴジョブは「皆それぞれリニューアルに期待している無限の可能性」から「粗くとも、それぞれのアクターが自身のユースケースを体験できるソフトウェアプロダクト」に変化しました。これには大きなメリットが2つあります。 1つめは、以降の開発プロセスに、現代的な継続的改善のプラクティスを導入できるようになることです。 たとえば、新フィーチャを開発するためにPull Requestをつくると自動テストが走り、レビューを経てマージすれば即座にステージング環境にデプロイされ、事業メンバーを含む関係者全員がその機能を触れる。そういった仕組みが有効であることはよく知られています。 2つめのメリットは、その触ってみる際に重点箇所の前後のフローも動作させることで、実際の利用者のコンテキストを体験しやすくもなることです。 たとえば「求職者が求人広告を閲覧し、応募する」体験を磨き込みたい場合、サイトに来てもらって会員登録するところから一連を動かせる場合と、開発者に依頼して払い出されたダミーアカウントで応募する場合では、得られる体験がまったく違ってきます。 こうして、実際のソフトウェアプロダクト（まだ粗いけど）を触ってみることで、ソフトウェアやフィーチャへの期待が具体化していきます。具体化した期待を実装してプロダクトが変わっていく様子を「ソフトウェアを育てる」と呼んでいます。 (例) 継続的に育てるためのブランチ戦略 リリース前はともかく、すでにリリースしたソフトウェアに対して未完成なフィーチャをコードベースに入れていくかは、ちょっと悩ましいところです。例えば開発ブランチを用意して、長期間そこで開発する場合、最後にマージするタイミングで苦労することがよく知られています。 この問題の汎用的かつ唯一の正しい手段はないでしょうが、カイゴジョブではフィーチャトグル ( Wikipedia )の仕組みを実装し、使っています（内部ではフィーチャフラグと呼んでいます）。 といっても、複雑な作り込みはせず、任意の箇所で条件分岐のための真偽値を返すだけの実装になっています。単純ですが十分に役立っています。 # Haml による Rails ビューでフィーチャフラグを利用する例 - if feature_flag.enabled?( :sugoi_feature ) #sugoi-feature %h2 すごいフィーチャのdivです このような牧歌的な仕組みだと、フィーチャフラグが野放図に増加したり、あるいは『フィーチャAとBが同時に有効なときのみXする』といった複雑な依存が発生して手に負えなくなったりといった懸念もあるでしょう。 しかし、今のところはチームできちんと棚卸しをすることにより問題は出ていませんし、仮に出始めても単純な if 文なので、コードレビュープロセスなどで改善できると思っています。 「全体」と思っていたものは変わる ここまで述べてきたように、はじめに「できるだけ全体」を描こうとすることには大きなメリットがあります。 中でも最大のものは、-- 逆説的ではありますが --「できるだけ全体」が真の全体ではないことがはっきりすることです。 私たち開発者も、ソフトウェアを使って事業を遂行する人々も、ソフトウェアがどのように動作するかを理解するには、動作させてみるのが一番です。「できるだけ全体」を動作させてみることで、見落としていたものや、もっと改善できる箇所に気づけます。 動作するソフトウェアにより得られたフィードバックの他に、開発期間中の事業環境の変化が、求められるソフトウェアと最初に描いた「できるだけ全体」との間に差異を生むこともあります。 また、ある時点での「できるだけ全体」を実装しリリースしたフィーチャが好評であれば、その部分を伸ばしていく事業判断がなされるかもしれません。 逆に残念ながらそのフィーチャを終了することもあるでしょう。 このように、「全体」と思っていたものは絶えず変化します。そしてその変化、ソフトウェアへの変更要求として現れてきます。 知った事実をシステムに取り込み「できるだけ全体」を拡張する 我々開発者は変更を喜ぶべきだ、そのために我々は雇われている。「要件変更」は我々のゲームの名前なのだ。我々のキャリアや給料はこうした変更によって支えられている。我々の仕事は、変更を受け入れてエンジニアリングする能力と、そうした変更を比較的安価にできるかどうかにかかっている。 （『 Clean Agile 』 「第2章 アジャイルにする理由 まっとうな期待」より） ソフトウェアを取り巻く環境は大なり小なり日々変わっていくので、ソフトウェアへの期待も大なり小なり日々変わっていきます。そこで私たち開発者も、変わっていく「できるだけ全体」に対して近づくように変更していきます。そうして近づいていくとまた事業が変わり、また望まれる全体が変わり……現代的なサービス開発はこの無限の繰り返しです。 私が大事だと思い日々心がけているのは、その無限に続くプロセスを悲観的に捉えず、楽しみながらソフトウェアを変更していくことです。 計画の最初期に全体を描ききれなかったのは失敗などでは決してなく、ラフスケッチを描いたことによって全員の理解が深まり、それにより新しい変更要求を発見できた証なのです。 この発見は、事業的な発見に限りません。コードベースと向き合っていくうちにドメインの理解が進み、結果としてコードをリファクタリングしたくなることもあるでしょう。 実際にカイゴジョブで起こった変更を紹介します。 (例)応募モデルのアーキテクチャをするっと変えた話 求人サービスたるカイゴジョブでは『求職者の方が求人広告を閲覧して応募する』という出来事がとても重要です。必然、その応募データが作成されたときは、応募者本人への確認メールや、広告を出している事業者への通知メールの送信など、様々な処理が発生します。 Railsというフレームワークにおいて「データAが作成されたらそこから操作Xと操作Yが起こる」ことを実装したい場合どうするか。 そうですね、ActiveRecord コールバック……は私のキャリアにおいてツラいことが多かったので避けました。 代わりに、Plain Old Ruby なフォームオブジェクトを用意し、応募可否のバリデーションや通知の送出をカプセル化するファサードとしました。 2018年時点では、このような単純な作りでリニューアル完了、リリースしています。 その後、無事にリリースされた新カイゴジョブで事業を進めていくと、やはり「応募」に係る処理は増えていきます。応募後にできることが増えていったり、通知手段や通知ルールを柔軟に設定できるようにしたり、応募可否制御のパターンが増えたりと様々なパターン分岐が必要となり、フォームオブジェクトが肥大化してきました。 その変化に対応して、コードベースの平穏を取り戻すべく、私たちは Rails Event Store を導入することにしました。 これによって、アプリケーション内で Pub-Sub 構造をつくるためのカタが確立し、各々の応募後処理の間の独立性を高めることができるようになりました。 これからなにか新しい応募後の処理を追加する場合も、既存の処理への論理的な影響は発生しないため、安心して拡張できます。 こうして、コードに現れる変化の要求を取り込み、我々のコードベースの「全体」は、応募後の追加処理を柔軟かつ安心して追加できるようになりました。 それを活かして、その後の新しい事業施策もスムーズにリリースできています。 一方で、RailsEventStore の採用にしても、完全にそれ中心で行くような判断をして作り込んだというわけではありません。 現時点で、Event Sourcingの概念を取り入れるメリットは少ないと判断して従来のデータモデルを使い続けていますし、イベント駆動で発火される処理も同期的に動作します。 あくまでコアなイベントと付随する処理の間にコード上の境界を導入し、依存関係をシンプルにするための利用にとどめています。 今後、Event Sourcingを採用するかステイすべきか、それとは別に処理を非同期にしたりさらにファンアウトの仕組みも導入すべきかなど、今後出てくる要求を見守りたいと思います。 このようにして、変わり行く事業と変わり行くコードベースの様子に注意をはらいながら、ソフトウェアを良い感じに保てるようにメンテナンスしていきます。 むすび エス・エム・エスでカイゴジョブの開発に携わりながら、私が日頃から心がけていることを事例を交えて紹介しました。 事業として今後やりたいことは多く、それに伴いソフトウェアも変化していきます。 そのような中で私も、開発者として腕を振るう余地もたくさんあり、変化対応を楽しみながらカイゴジョブを育てています。 今回紹介したカイゴジョブのコードベースも、開発開始から3年弱、事業の要求に随時答えてきた実用コードとしては、なかなか興味深いコードベースになっていると思いますので、興味のある方はお声がけください。また、ある程度のキャリアが長い方を中心に「リニューアルといえばデータ移行! どうやったの?」と思った方もいるかも知れません。そこは本稿の趣旨がブレるため省きましたが……大変でした。そのあたりカジュアルに話したい方もぜひ下記リンクからご連絡ください。 本ブログの別の記事 『「継続性アーキテクト」という生き方』 にて技術責任者の田辺も言っているように、エス・エム・エスには色々なステージの多くの事業があります。 本稿のような働き方のチームもあれば、また違った文化のチームもあります。 カイゴジョブチームを面白いと思った方も、他の話を聞きたいなと思った方も、ちょっとでも興味がありましたら下記リンクからご連絡ください。

2020年3月、エス・エム・エスの開発チームではリモートワークへの移行に伴い、 iPadアプリのリモート実機QA環境 を構築しました。 限られた期間のなかで、MDM（Mobile Device Management: モバイル端末管理）選定から社内承認、端末の確保、iPadの設定、ポリシーの確認までスピーディーに進行。プロダクト開発部の リモートワーク開始前日には、安全に自宅から実機での検証をできる環境が整いました。 本記事では、リモートでの実機QA環境を構築するまでの経緯や背景にあるエス・エム・エスのカルチャーについて、取り組みの中心となったプロダクト開発部エンジニアの清水智徳さん、神谷典孝さんに話を聞きました。 リモートワークへの移行、新たなMDMの導入を即日決定 これまでプロダクト開発部では、iPadアプリの実機検証を行う際、社内ネットワークを経由して検証環境に接続していました。 しかし、新型コロナウィルス感染症の影響でリモートワークへの移行が決定。社外からも検証環境にアクセスできる環境を構築する必要がありました。QAチームで「 カイポケ 」の品質保証を担う清水さんは、決定後すぐさま構築に向けて動き出します。 清水：これまで使用していたMDMでは、リモートで安全に検証環境へ接続するための細やかな設定や管理に対応できませんでした。私はMDMについてそこまで知見があったわけではないので、まずは社内の詳しい人を探しました。 そこで上司から名前が挙がったのがカイポケのプロダクト設計・開発を担う神谷さん。iPadアプリの開発経験があり、MDMの知見も豊富でした。 清水さんの依頼を神谷さんは快諾、新たなMDMを選定しました。選定にあたって考慮したのは、大きく以下の2点です。 iPad OSのプラットフォームに特化しているか OSの新しいバージョンに即日対応した実績があるか （カイポケのアプリは新しいOSが出たら即検証する必要があるため、スピード感を重視） 神谷さんが導入の申請を行うと、 上司からは即日承認が得られました。 “誰にも気づかれない”くらい、地道で素早い環境構築 1日たらずでMDMの導入が決定する一方で、清水さんは iPadの確保に奔走していました。 ちょうどカイポケアプリの大型開発案件と時期が被っていたこともあり、社内で推奨されている世代の端末を揃えるのは容易でありません。 さらに、必要な端末を追加購入しようにも、新型コロナウィルス感染症の影響で生産が滞り、市場にもiPadが不足している状態。既存の端末や新規購入の端末だけで、必要数を確保するのは難しかったため、レンタル会社からも手配をしました。 レンタル会社の選定にあたっては、以下のポイントを確認しました。 レンタルされる端末の状態は良好か 他のレンタル会社と比較して値段は妥当か 決まった支払方法で支払えるか（エス・エム・エスとして購入などの費用決算方法が決まっているため） さらにレンタル端末の利用にあたっては、以下のポイントを確認しました。 長期で使うものは購入、短期的に使用するものはレンタル会社といった線引き レンタルした端末を社内接続するセキュリティ上の懸念、回避策 その他にも地道な検討があった一方で、購入やレンタルの理由は明確だったため、「 上長からの予算承認などはとても迅速で助かりました 」と振り返ります。 無事に合計15台ほどのiPadを確保した清水さん。続いて神谷さんとともに、各端末のキッティング・配布を進めていきます。 できる限り効率的にキッティングを進めるべく、事前に必要な初期設定や作業当日のシナリオを整理し、作業に取りかかりました。 神谷：キッティングについては、技術的に『こうやればいける』というイシューへの見立てができていたので、あとは実行に移すだけという感じで。VPN設定ファイルの構築などのセキュリティ周りも、インフラチームの協力を得られ、大変スムーズに進みました。 ただ、一台ずつ手をアルコール消毒しながら、iPadを開封し続けるのは楽な作業ではなかったです。さすがにiPadの箱を見てもワクワクしなくなりました。 キッティングが完了した後は、あらかじめ清水さんが策定した端末の管理ポリシーに沿って、必要なメンバーへ端末を配布していきました。 清水：個人情報保護や情報漏えい防止の観点から、メンバー間で個人の住所を教え合い、受け渡すのは禁止しようと、リスクマネジメント部門と話をしていました。 そのため、基本的には私が中継地点となって、宅配業者を手配し、配送を行いました。4月と5月合わせて、40台以上は受け渡しましたね。 こうした地道な取り組みの甲斐あって、大きなトラブルが発生することなく、迅速にリモート実機QA環境への移行が完了。他のメンバーにとっては「 気づいたらできるようになっていたんじゃないですかね 」と、清水さんは振り返ります。 現在リモートワークへ移行してからも二人の取り組みは続いています、神谷さんはApple Business Managerの仕組みを使用し、ゼロタッチで設定が完了するようシステムをアップグレード。清水さんも、受け渡しや端末購入の予算承認の仕組みを効率化できないか、引き続き検討を進めたいと考えているそうです。 学習への惜しまぬ投資、無駄ない意思決定プロセス 今回の取り組みを通して、神谷さんは「 学習投資を惜しまない エス・エム・エスの良さ」を改めて感じた」と語ります。 MDMの導入に必要な知見は、2019年に会社の費用でWWDC（World Wide Developers Conference)に参加した際にインプットしたものもあったそうです。 神谷：エス・エム・エスでは業務時間外でも、カンファレンスの参加費用を負担してくれます。私も入社時に『海外のカンファレンスに参加したいです』と希望を伝え、WWDCに参加しました。 また、『参加したらレポート必須』といった決まりもありませんでした。そうした寛容な方針であっても、 自ら『皆に知ってほしい』と発信するメンバーが多い ですね。 WWDC2019に参加した際、神谷さんが社内共有したブログ記事（内容は2019年6月のものです） 学習を後押しするカルチャーと学習意欲の高いメンバーを挙げた神谷さん。加えて、清水さんは、MDM導入の決定や端末手配、配布に至るプロセスから、 スピーディーな意思決定や部署を超えた連携の強さ を感じたそうです。 清水：必要なことをロジカルに説明すれば、すぐに提案が承認されるのはエス・エム・エスの良さだと思います。個々人が裁量を持って動きやすい環境です。 また、上長はスピーディーかつ的確に、承認の可否や必要な検討箇所を指摘してくれる。個人の自由さと『抑えるべき部分は抑える』バランスが取れていると感じます。 また、他部署の人たちも協力的である点はとても心強かったですね。今回も神谷さんはもちろん、リスクマネジメント部門やセキュリティ部門の方も積極的に手助けしてくれました。 思いがけないきっかけから始まった今回の取り組み。その裏話からは、学習への投資を惜しまないエンジニアの技術力、無駄のない意思決定プロセス、個の挑戦を応援する組織カルチャーなどが伺えました。 今後もこうした良さを大切に育てながら、事業や社会の不測の変化にもしなやかに向き合っていきたいです。本取り組みを通じて、エス・エム・エスの魅力や社風が伝われば幸いです。

介護や医療、ヘルスケア、シニアライフの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エス（以下、SMS）のエンジニアの神谷です。コードを書く以外にも、採用などの組織づくり、開発環境整備など幅広く仕事をしています。 自分がSMSに入社したタイミングでは、開発現場にはよくある、開発環境がアップデートされていない、デプロイのためのコストが高く一度のリリースが大きくなってしまうなど「技術的負債」がたまっており、どのように負債を解消していくかを模索していました。 今回は、技術的負債の解消にどう取り組んできたのかを振り返って紹介できればと思います。少しでも、技術的負債に悩む方々の参考になれば幸いです。 技術的負債の解消に立ちはだかる様々な壁 自分は、iOSのエンジニアからキャリアをスタートしました。スタートアップでエンジニアをはじめたので、基本的にはなんでもやる姿勢で開発と雑用に取り組んできました。サーバーサイドのスキルも身につけながら、よりレベルアップすることを目指して、2019年1月にSMSへ入社しました。 入社時は、介護事業者向け経営支援サービス「 カイポケ 」の開発・運用をおこなうチームに配属されました。自分が配属される前からチームでは、技術的負債の解消を担っていたものの、カイポケは40個のサービスが集積したプロダクトということもあり、日々の運用だけでも対応する業務は膨大なものになっていました。 その対応に追われて、どうしても負債へのアクションは後回しになっている状態が続いていたのです。 入社したときから、技術的負債の解消に取り組むことは決まっていたのですが、技術的負債に取り組めるまでには超えなければならないハードルが、大きく3つありました。 ビッグイベントへの対応 リソース確保の仕方 開発環境の古さ まず、大きなハードルだったのは、2019年の「消費税増税」「元号改定」「介護報酬改定」という3つのビックイベントたちです。 一つひとつのビッグイベントに対応するために、開発のリソースは逼迫。さらに残りのビッグイベントは波状攻撃のように順番にやってきました。日々の運用と、社会環境の変化に対応するための開発とで現場は手一杯でした。 もちろん、何もしなかったわけではありません。「週に何日は技術的負債の解消に使う」と決めて、時間も確保していました。ですが、これもうまくワークしませんでした。週に何日しか時間の確保ができていないと、作業ごとに前回の作業内容を思い出すまでに時間がかかり、効率的に作業が進められなかったのです。 また、開発環境にも問題がありました。アプリケーションのリソースがファイルサーバーに置いてあり、どこのファイルを書き換えたら、どう振る舞いが変わるのかがわからない、手順書通りにやって動かないために、手作業が多いなど、問題が山積みでした。開発プロセスも管理できておらず、カンバンにはWIPのものがたくさんありました。 技術的負債を解消していくためには、組織体制を整えること、開発環境を整えることから始めなければ、とても進まない状態でした。しっかりと負債解消に向けたアクションをとるためには、抜本的な改革が必要だと考えたのです。 そこで、SMSの技術責任者である @sunaot に、負債解消のための青写真を持って提案しました。「ビッグイベントが終わったら、また運用にリソースをとられている間に、次のビッグイベントが来てしまいます。変えるなら今しかありません」といったことを話したと思います。 提案は思っていた以上にあっさりと承認され、ビックイベントの対応が終わった後に、負債解消のためのアクションをすることになりました。 技術的負債解消のためにとった7つのアクション 提案後、技術的負債の解消のために7つのアクションを進めていきました。重複する要素もありますが、実施したのは以下のようなことです。 技術的負債解消を最優先でやるために割り込みから保護してもらう やることをひたすらプロダクトバックログにする 捨てる（あきらめる）機能を決める カンバンからレビュー待ちのレーンをなくす 機能を小さく作っていく データベースからフロントエンドまで、常に結合した状態で進める リリース時期に幅をもたせる 1. 技術的負債解消を最優先でやるために割り込みから保護してもらう まず、技術的負債解消を最優先でやるために割り込みが起こらなくなるよう、技術的負債を解消する専門の小規模なチームをスピンアウトしてつくりました。カイポケの日々の運用を引き続き担ってくれるチームがいたからこそできたアクションです。これには、今でも感謝しています。そのおかげで、負債の解消に集中するチームができました。 2-3. やることをひたすらプロダクトバックログにする / 捨てる（あきらめる）機能を決める 続いて、とにかく良いプロダクトバックログをつくることに取り組みました。直近でやることが把握でき、タスクの規模感が見えていて、並べた順に進んでいければリリースができ、トカゲのしっぽ切りにできるものは下に置いてある、そんなプロダクトバックログの基本が反映されたものです。 プロダクトバックログをつくりながら、負債の解消を進める上で、リターンとかかるコストをチームで検討します。例えば、お客様が閲覧する画面の構成が変わってしまう開発があったときに、無理に再現しようとするのではなく、優先順位を下げる、といった対応をしていきました。すべてをなんとかしようとするのではなく、あきらめる機能を決めることも必要です。 4. カンバンからレビュー待ちのレーンをなくす カンバンに存在したレビュー待ちのレーンを外しました。レビュー待ちやコンテキストスイッチの無駄を作らないように、お互いすぐに声をかけてレビューしたり、ペアプログラミングを行うことを進めていきました。チーム編成も、リアルタイムでコミュニケーションができるメンバーを中心に構成しました。 5-6. 機能を小さく作っていく / データベースからフロントエンドまで、常に結合した状態で進める 全てのレイヤーを作り終えてからテストを行い、不具合が見つかれば差し戻すというサイクルで開発が行われていたため、改善していく必要がありました。新しい体制では、アジャイル開発のプラクティスを取り入れ、1週間のイテレーションで開発を進めていきました。レイヤーごとにすべて開発してから結合・検証するのではなく、インフラからユーザーインターフェイスまでのレイヤーを跨いで、スライスするように開発していきました。データベースからフロントエンドまで常に結合した状態で進めることで、テストをしやすい状態も作って、素早く検証できる環境をつくりました。 7. リリース時期に幅をもたせる 「いつリリースできるの？」と聞かれたときに二点見積もりの手法を使うようにもしました。最短かつ無事故で開発が進んだ場合と、トラブルがあったとしてもプロフェッショナルとしてここまでにはリリースしなければ、という場合の幅をもたせたリリース時期を回答するようにしていました。不確実性を減らしながらリリース時期の幅は徐々に狭めていき、ステークホルダーとの信頼関係構築に配慮しました。 開発プロセスや技術スタックもモダンな環境に引き上げる こうしたアクションを積み重ね、チーム内で密なコミュニケーションをとりながら、細かい開発を重ねて軌道修正を早く行うことで、「チームで完成させる」という意識を持ってもらうようにしました。開発環境を整える上で他にも実施したのが、技術スタックの改善です。技術スタックを考える上での基準は、以下の3つ。 デファクトスタンダード オープンソース メンテナビリティ 多くの企業で使われるデファクトスタンダードであり、オープンソースになっていてソースコードを自分たちで読むことができ、コミュニティが育っていて技術のメンテナンスが頻繁にされているというポイントを満たしていること。 インフラは既にAWSに移行済みでしたし、技術スタックの一部は元々使っていたものを踏襲しながら、上記の基準に合わせて入れ替えていきました。現在の技術スタックは以下のようになっています。 Spring Boot Kotlin 1.4 Amazon EC2 Amazon Aurora Amazon ElastiCache 技術的負債の解消のために重要な3つのポイント ここまで、技術的負債を解消するためにとってきた行動を紹介してきました。行動を振り返ってみて、技術的負債の解消のためには3つのポイントが重要だったと考えています。 負債のコンテクストがわかる仲間を集める 返却するとどんな嬉しいことがあるのかを丁寧に説明する 小さなチームで、プラクティスを少しずつ取り入れる まず1点目が、「負債のコンテクストがわかる仲間を集める」です。技術的負債の解消のために、外部からスペシャリストを招くこともありますが、状況把握までかなり時間がかかってしまうことが考えられます。 「負債はどこにあるのか」「この負債はどういう経緯で発生したのか」をすでに知っているメンバーで構成すれば、背景を理解した上で解消に取り組んでいきやすいと考えています。 2点目が、「負債を解消すれば、どんな嬉しいことがあるのかを丁寧に説明する」です。これは、開発チームだけでなく、社内の様々なメンバーにも伝えることが大切です。 技術的負債の解消は、外から見たら何をやってるチームなのかがわかりにくいにもかかわらず、結構コストをかけていることが多いかと思います。「アプリを昼間にデプロイできるようになる」「1日に何回も変更可能になる」などの技術的負債解消によるメリットを周囲のメンバーにも丁寧に説明していくことが、周囲からの理解を得ながら進めるためには重要です。 3点目に大切なのが、「小さなチームで、プラクティスを少しずつ取り入れる」です。開発環境を整備するために、いくつかのプラクティスを取り入れましたが、一気に取り入れるのではなく、メンバーが納得感を持てるように一つずつ試していきました。関わる人数を少なくしてコミュニケーションコストを減らし、一気に変えるのではなく納得感を醸成しながら進めていくことも重要です。 2周目の負債解消は“強くてニューゲームのはじまり” 技術的負債の解消に取り組んだ結果、フレームワークの刷新、スティッキーセッションからの脱却に成功。さらに、インフラ構成の自由度も上がり、細かな変更を素早く、安全にリリースできるようになりました。そしてこれからは、“強くてニューゲーム”のはじまりです！ 技術的負債の解消も、1周目はQAチームが別チームだったために、リリースできるかが最終的な段階までわからず、ヒヤヒヤしながら進めることになっていました。2周目はテストに強いメンバーをチームに入れて、テストまでをチーム内で行える体制にしています。これで、より技術的負債の解消の速度が上がるはず。 まだ、技術的負債の解消のための環境整備は、現時点では自分のチームだけでしか実装できていません。今後は、この成功体験を横展開し、全社的に広げていきたいなと思っています。