高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている前田隼輔です。2018年7月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。今回は、介護業務という複雑なドメインに対して、既存のモノリシックなシステムに対してどのようにアプローチして改善しようとしているのかについて紹介します。 　 カイポケ は、介護業務に加えて勤怠管理や給与管理などの様々な機能を備えている介護事業者向けの経営支援サービスです。通常、介護業務は介護保険制度に則って行うので、介護事業者向けのサービスでは介護保険制度（介護保険法）に追従していく必要があります。介護保険制度は３年ごとに法改正があり、情勢などに合わせて変化し続けています。カイポケでは長らくオフショア開発をしていましたが、ドメイン知識やノウハウを社内で貯め、サービスを拡大・安定化して長く提供していくために内製化を進めており、積極的にエンジニア採用を行っています。 複雑なドメイン 　介護保険で受けることができるサービス（介護サービス）は、自宅を生活の拠点としたまま受けられるものや生活の拠点を移して利用するもの、さらに車椅子のレンタルや、手すりの取付といった自宅改修など多岐に渡ります。これら提供する介護サービスの種類によって業務内容は全く異なり、加えて、訪問看護サービスなどの医師や看護師を介したサービスを提供する場合には医療保険制度、サービス付き高齢者向け住宅の運営には国土交通省および厚生労働省が定める高齢者住まい法などが関わりより複雑なものにしています。 　また、日本では高齢化社会と言われて久しいですが、社会の構造は日々変わっています。その変化に対応するために制度自身も変わっていきます。介護保険制度では３年毎（医療保険制度は２年毎）に法改正が行われ、介護事業を続けるにはこれに追従しなければなりません。 　もちろん、我々が提供しているシステムとしても対応していく必要があります。しかしながら、介護保険の法改正は４月に施行されるのに対してシステムに落とし込むための情報が出揃うのが当年の１月以降順次となっており、より柔軟に開発できるようにしておく必要があります。 コンテキストの境界線をみつける 　上述のように、介護保険制度は複雑に変化していきます。複雑に変化し続けるドメインと向き合っていくためには、コンテキストの境界を意識し、システムを小さく作っていくことが望ましいと考えました。 　介護業務の主な内容はもちろん「介護サービス利用者に対するケア」にありますが、介護事業所の運営には「従業員や利用者の情報管理」、「ケア内容の記録」や「介護報酬の計算・請求」などを行う必要があります。管理や記録、金額計算などの運営に必要なこれらの業務はシステムの得意とするところであり、我々はこの部分をサービスとして提供しています。従業員のシフトを組み、実際にケアを行った場合はその内容を記録し、記録した内容は介護報酬の計算に利用するといったように、いずれの業務もそれぞれ関連してはいます。しかし、これらをシステムとしても密に結合すると、ロジック変更時の影響範囲が思わず大きくなったり、新しくシステムに携わる人が理解しにくい状態となってしまいます。今後も変化する介護報酬制度に対応し続けるため、できるだけ小さくてかつ意味のあるコンテキストを探した結果、今は特に法改正の影響を受けやすい「介護報酬の計算」にフォーカスし、ロジックを別アプリケーションとして切り出すアプローチに挑戦しています。 　「介護報酬の計算」とは、介護事業所が利用者に対して１ヶ月のうちに提供した介護サービスの費用を請求するための明細書を作る業務となります。この計算ロジック一つとっても介護サービスの種類や介護事業所および利用者の状態によって大きく異なり、深いドメイン知識が必要となります。別のアプリケーションとして切り出すアプローチは、開発チームとしても分離しやすくなり特定のドメインにフォーカスできることに繋がりました。 境界づけたコンテキストを分離する 　「介護報酬の計算」のコンテキストを分離し、そのロジックを別アプリケーションとして切り出しますが、計算の元となるデータは既存システムのものを利用する必要があります。計算ロジックを提供するアプリケーションを疎にするために、既存システムのデータベースからデータを読み込むアプリケーションを別に用意しました。計算ロジックとデータ読み込みのそれぞれのアプリケーションはマイクロサービスとして提供し、既存システムとはAPIゲートウェイを介して連携するようにしました（下図）。 　APIゲートウェイを介したマイクロサービスにしておくことで、リリースを新アプリケーションの開発チームだけでハンドリングしやすくなり、また、今後既存システムから「介護報酬の計算の元になるデータを作成するドメイン」を分離したときにも連携しやすくしておく狙いがあります。 ロジックを切り替える戦術 　コンテキストで分けられたドメインを別のアプリケーションとして切り出すことで、そのコンテキストに集中することができるようになります。しかしながら、既存システムの特定のロジックを別のアプリケーションに切り替えるには戦術が必要になります。すべての機能を作りきってから切り替え方法を考えるのではなく、段階的に切り替えて行くことにしました。 第1段階: 検証 　既存のシステムからそのままソースコードを移植するのではなく、堅牢で改修しやすいシステムにするには、ドメインを理解してロジックを作り直すことが重要になります。しかし、開発メンバーはドメイン知識が十分に蓄積されているわけではありません。そこで、早い段階で本番環境のデータを使って計算することにしました。 　既存アプリケーションでのイベントをフックとして新規アプリケーションでも計算し、それぞれアプリケーションでの計算結果を比較検証しています。このアプローチにより、実業務でのエッジケースを発見することができ、ドメイン知識の拡充にも役立ちます。また、既存のイベントをフックにしているのでパフォーマンスの課題も気づきやすくなります。現在はこの検証段階であり、差分をみながら開発の優先度決めなどを行っています。 第2段階: ダブルライト 　十分に検証を行ったら、続いては新規アプリケーションの計算結果を利用する段階になります。既存データベースが複数のアプリケーションから参照されていることもあり影響範囲が計り知れません。また、既存データベースに書き込まれた計算結果に対してさらなる操作を行っている部分もあり、それらの機能を実装するとスコープが広がってしまいます。まずはスコープを小さくしてリリースするために、すべての参照を一度に切り替えるのではなく、新規アプリケーションの計算結果を既存データベースに書き込むことを考えています。 　この段階では、介護報酬の計算ドメインとしてはアプリケーション（ロジック）は分離されているがデータベースは分離されていないという状況になります。しかし、ロジックが他のコンテキストから分離されているだけでもドメインの変化への対応はとても素早くなると考えています。 第3段階: 切り替え 　計算結果の参照先を新規アプリケーションに切り替えていく段階になります。これによって計算結果のリソースは共有データベースから開放され、介護報酬計算ドメインとしてアプリケーションおよびデータベースともに分離することが望めます。 　この段階的に切り替えていくアプローチでは、作りきってから組み込むのではなく既存システムの裏で新規アプリケーションを動かしており、新規アプリケーションではAPIを変更したいタイミングも出てきます。しかし、既存システムはリリース時にシステムダウンが必要となってしまうので、直接呼び出す場合新規アプリケーションでのAPIの変更の度に既存システムもシステムダウンを伴うリリースが必要となってしまいます。これを柔軟に変更できようにするために、既存システムからのリクエストは計算に利用するキーのみにとどめて、小さいアプリケーションを挟んで新規アプリケーションを呼び出すようにしました。 技術選定 　一部機能を新規アプリケーションとして切り出すアプローチのため、既存のアプリケーションにとらわれずに技術選定を行うことができます。ドメインロジックを表現するメインのアプリケーションを Kotlin x Spring Boot、現行システムとの受け渡しなどの周辺のツールを Go で構築しています。また、複数のアプリケーションから構成されているので、開発を容易にするために各アプリケーションをコンテナ化し、ローカル環境では docker-compose、本番環境ではAmazon ECSを用いることにしました。 型で計算式を表現する 　Kotlinを選択した理由としては、現行システムが Java で記述されていることを踏まえて学習コストが小さく Java よりも表現力が高いためです。 例えば介護報酬において、報酬額は介護サービスごとに定められた単位数に介護サービスを提供する地域ごとに定められた単価を乗算することで算出します。点数と単価をかける計算は、病院などでうける診療報酬でも同じであるため馴染みがあるのではないでしょうか。 介護報酬額 = 単位数 x 単価 　Kotlinでは演算子オーバーロードといった機能があり、これにより作成したクラスを使って計算式を表現することができます。 class 単位数( val value: Int ) { operator fun times(tanka: 単価): 報酬額 = 報酬額(( this .value * tanka.value).toInt()) } class 単価( val value: Double ) class 報酬額( val value: Int ) { override fun toString(): String = "報酬額は ${ value } 円です" } fun main() { val amount: 報酬額 = 単位数( 200 ) * 単価( 10.9 ) println(amount) // 報酬額は2180円です } 　例えば単位数と報酬額をどちらもInt型で定義してしまうと、改修を繰り返すうちに思わぬところで変数が使い回されたりしてしまうことがあります。単位数と報酬額をクラスとして分けておくことで、報酬額に単価をかけるといったドメインでは存在し得ない計算をコンパイルレベルで防ぐことができます。 プロジェクトを進めるために 　正しさを求めるのではなく、そのタイミングでのベストな選択肢を選ぶことを心がけています。正しさを求めてしまうとその裏付けが必要になり、足が止まってしまいます。実際に、上述のスコープについても何度もスコープを小さく切り直しています。これはドメイン知識が身についてコンテキストの境界線が見えてきたからであり、最初の選択肢が間違っていたことを意味するものではありません。ただし、ベストな選択肢を常に取れるようにできるだけ疎でシンプルにしておくことは重要です。 　また、全て自分たちだけで完結しようとせず他チームとの関係構築も意識しました。既存システムに関わるチームとは別チームとして編成されているので、現チームからジョインしたメンバーなどは課題感などを感じにくくなってしまいます。ドメイン知識においても、非エンジニアや既存システムに携わっている別チームのほうが圧倒的に豊富な場合があります。特にフルリプレイスから現行システムの一部分にフォーカスするように方向性をシフトしたため、初期にはプロジェクトとしての期待値が擦り合ってないことを感じていました。どのように実現しようとしているかを適宜説明し、期待値の調整などを行って他チームとも協力を仰ぎやすい関係性が築けていると思います。 エス・エム・エスにおけるアーキテクトの役割 　システムアーキテクチャを考えることや技術選定は役割の一つです。しかし、技術やアーキテクチャは課題を解決するための手段に過ぎません。置かれたコンテキストにおいて何が課題かを見極め、意思決定を繰り返して、システムやそれ以外の方法で解決に導くことが重要な役割となります。アーキテクトの仕事については、こちらの記事で詳しく紹介しています。 tech.bm-sms.co.jp 　また、エンジニアが貸与されたPCに様々なツールをいれて開発環境を構築し育てていくように、チームや自分が動きやすい環境を作ることも必要です。課題を適切に把握するために、また課題を解決するために必要であればチーム外にも働きかけていく必要があります。それに対して協力を惜しむ人は少ないので、自ら動いていける方には働きやすい環境だと思います。 おわりに 　介護業界は複雑なドメインを有していますが、それを紐解き、システムに落としていく過程は非常にやりがいがあります。そんな複雑なドメインに一緒に立ち向かってくれる仲間を募集しています。エス・エム・エスの仕事に関心がある方は、ぜひこちらのスライドも見てみてください。

高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側が開発側に相談なしに顧客に開発の話をしてしまったり、開発側が事業側の声に耳を傾けない、といったものです。 また、エンジニア側がサービスへの理解や、どのような目的で何のために開発するかという目的意識を持ちにくくなります。「この仕事はいったい何につながっているのだろう？」という疑問がわくこともあり、働き続けるなかで次第にやりがいがなくなっていくエンジニアも多いのではないでしょうか。 ただ、デメリットばかりではありません。それは、エンジニアが開発に集中できること。ある程度のボリュームのある開発に取り組む場合は、必要な要件を事業側でしっかり固めてくれた方が、エンジニア側で一気に開発していきやすくなります。デメリットばかりなわけではありませんが、それでも優劣がついている状態で働きたいエンジニアは少ないのではないでしょうか。 エス・エム・エスでは、開発側と事業側とが同じチームに属して、共にサービス運営やシステム開発を進めるのが「普通」になっています。フラットな関係で、いかに事業や開発に取り組んでいるのかを次で紹介したいと思います。 事業側と開発側がフラットになることで生まれる3つの利点 私が所属しているカイポケの事業部では、サービス運営や企画面などを担う3〜4名の事業側担当者と、5〜6名のエンジニアの合計10人ほどが一つのチームになっています。 例えば、労務管理系のプロダクトチームでは、プロダクトオーナー、開発、運用、CS（カスタマーサクセス、顧客対応窓口）が参加して課題共有の週次定例を開催しています。会議では、毎回確認するトピック、直近でホットなトピックを扱ったあと、コミュニケーションの仕方で改善できることなどをディスカッション。こうした時間があることで、問い合わせ対応、不具合対応などについて、それぞれの立場でどのように解決に貢献できるかを前向きに話せる雰囲気が作れています。 他にも、経営支援チームでは、新プロダクト開発にむけた定例ミーティングを、プロダクトオーナーと開発で実施しています。この会議では、戦略的な位置づけ、ビジネス的に実現したいことなどの情報をもとに、開発側で要件や実現方法を整理してディスカッション。1時間枠だと語り尽くせないということで、近々1日みんなでディスカッションするオンライン合宿を行う予定です。このようにフラットな関係で仕事をすることによって、様々な利点が生まれています。例えば、以下のようなメリットがあります。 事業の仮説検証サイクルを素早く回せる 顧客のフィードバックをすぐプロダクトに反映できる 施策の技術的な実現可能性を判断しやすい まず、1について。フラットなチームのなかでは、試作したいプロトタイプや、仮説検証手段なども事業側と一緒に検討しています。シンプルな要求を実現するための小さいシステムを作り、確認しながら進めていくので、仮説検証サイクルを素早く回せます。 次に、2について。カイポケのカスタマーサポートが受けた問い合わせのなかで、技術的な側面に対するものは、エンジニアに調査依頼が来ます。カスタマーサポートとエンジニアとの距離感が近く、お客様の温度感がダイレクトに伝わってくる状態。顧客のフィードバックをすぐプロダクトに反映できるだけでなく、ものづくりの責任を体感できます。 最後に、3について。事業側と距離が近いことで相談が生まれやすく、エンジニアは相談された内容が技術的に実現可能かどうかを早期に判断できます。そのため、判断までの速度も上がり、最適な設計をしやすくなります。開発するものが何につながっているのかを知ることで、「ユーザーに価値を届けるために頑張ろう」というモチベーションも上がります。 もちろん、最初からスムーズに連携できたわけではありません。事業側もエンジニア側もお互いにどんなリクエストを出したらいいか、コミュニケーションの距離感はどれくらいが適切か等がわからず、苦労しました。カスタマーサポートとも、お問い合わせの緊急度と、システム側の重要性とがかみ合わず、ぎくしゃくしたこともあります。小さな案件を積み重ねながら、互いを理解し合えるようになり、今のようなチームになったと感じています。 事業と開発がフラットな組織なら技術的負債も解消しやすい どのようなサービスでも同様に一定の技術的負債が蓄積しています。その際に直面する大きな課題は、過去の遺物となってしまった機能のクローズです。 当初想定していた価値がお客様に提供できていなかったり、利用者が想定より少なかったりと、貢献度が低い機能も多くあります。 こうした機能の保守や運用にもコストや人員が割かれており、不要な機能は思い切って捨てることも重要です。 ただ、実際に機能をクローズしようとするのはそう簡単なことではありません。 その中には有償でサービスを利用しているケースがほとんどなので、利用者は少ないものの、積極的に利用しているユーザーにとっては必要な機能だったり、外部サービスと連携していたりすると、簡単にはクローズできません。 こうした機能のクローズ作業は、事業側やユーザーなど関係者も多く、なかなか進捗させるのが難しいものです。なぜ、この機能を閉じるべきなのか、このままにしておくと事業にどのような影響が生じるのか。特にシステムに与える影響範囲については、エンジニアにしか理解・提案することができません。 実際に、事業的にはクローズとしようと意思決定した機能についても、エンジニアの視点からみえる現状の利用状況、他の開発などと優先順位を比較した結果、あえて1年程度クローズ時期をずらしたものもあります。 エンジニアが技術的負債に気づいたとしても、優劣のある関係だったとしたら、事業側に技術的負債の解消を提案するのは難しいでしょう。技術的負債の解消は関係者も多く巻き込む、負担が大きな作業です。技術的負債は解消せずともしばらくシステムは動くなかで、能動的に技術的負債の解消のために取り組むためには、チームが一丸となっていなければならないと思います。 業界の変化に適応し、事業に貢献するために学習し続ける 優劣のないフラットな組織であることが、新規の開発や技術的負債の解消にも有用であることをお伝えしてきました。最後に、フラットな組織だからこそ生みだせる学習サイクルについて紹介したいと思います。 ビジネスも、システムも、一度つくったら終わりではありません。環境は常に変化し、それに合わせてビジネスやシステムもアップデートをしていく必要があり、エンジニアも常に学習をし続けなければならないと思います。 カイポケが解決したい大きなテーマは、どういう機能やサービスを提供すれば、ユーザーの業務や経営が改善され、持続的に理想の介護提供に注力できるのか。この問題の解決のためには、ただプロダクトを開発するだけでなく、現場の状況や経営課題、法制度などに対する理解が必要不可欠です。 カイポケ事業部では、入社時に介護業界の知識や競合する介護業務支援ソフトの内容、介護現場の実態などの研修を実施したり、各プロダクトごとやチームごとに定期的に勉強会を開催して、能動的に学習するようにしています。 例えば、介護報酬に関する法改正があったときには、医療機関が健康保険組合に提出する月ごとの診療報酬明細書「レセプト」に関連する業務のチームで勉強会を開催したり、過去にあったシステム改修事例を事業側に伝えたりして、制度に対してプロダクトとしてどう対応するかを早期に理解し、プロダクトに反映しているのです。 エンジニアはこうした介護業界や法改正についての理解を深め、生じる変化も学習していくことで、価値あるサービスの開発が可能になります。言われたものを作るという姿勢ではなく、共にサービス運営やシステム開発を進めるという姿勢だからこそ、こうした学習が起こりやすいと考えています。 能動的に学習が起こり始めると、開発チームにも様々な変化が生まれます。例えば、既存のアプリケーションの改修案件であれば、事業へのインパクトを考慮した改修案を提案するようになったり、エンジニア都合ですべてを完璧に直すために工数を使うことは考えなくなるなどの変化が起こります。一方で、長期的に見てリスクが高い負債が残るものについては、十分に説明を行ってある程度工数を要求して直すようにしておくなど、事業にとって最適な行動をとるようになっていきます。 こうした行動を実現するためには、技術的な部分だけでなく問題解決やプロジェクトファシリテーションのスキルがより重要になります。不明瞭な部分を咀嚼して、何を解決すべきなのかという目的にフォーカスしつつ議論をファシリテートしていく。ビジネス要求、システム的な制約などをひとつずつ整理して、会話のコンテクストを常に合わせながら合意形成していくなどのスキルが上がっていきます。 そうすると、日常的な業務の中で「こんなことが実現できたらいいなぁ」という、ふんわりした要望を聞いたときに、「どう関わるとそれを形にできるのか？」を考えて積極的な関わりが可能になります。関係者集めて情報収集のディスカッションを実施する、esaに情報を整理して「やりたいのはこういうことですか？」と、実現に向けて前に進める、勉強会のような活動だけではなく、日常の中で事業に向き合っていくといった取り組みが増えていきます。 エス・エム・エスは、システム開発することだけがエンジニアの仕事ではなかった。そんな気づきが得られる職場です。日々たくさんの学ぶべきことや考えることに向き合いながら、事業側と共に企画や施策を進めていくことで、他の職場では得られない経験を積んでいます。そんなエス・エム・エスの仕事に関心がある方は、ぜひこちらのスライドも見てみてください。

エス・エム・エスでは、より働きやすく居心地の良い空間を作るために様々な 社内制度 を提供しています。2020年8月からは、 エンジニア向けの技術書が自宅に無償で届く 福利厚生を開始しました。 この制度を利用すると、Slack内の購買用channelに、書籍のAmazon URLを書いて購買担当者にメンションをするだけで、即日注文され自宅に技術書が届きます。出社も経費申請の必要もありません。 本記事では、新しい取り組みについて詳しくご説明するとともに、エス・エム・エスで行われているエンジニアの支援やその根底にある想い、社風が感じられるエピソードをご紹介していきます。 Slackでポストすれば完了。技術書が自宅に届く福利厚生 エス・エム・エスには、もともと技術書の購入支援制度がありました。 Slackで一声かけるだけで会社に書籍が届く シンプルな制度です。 しかし、新型コロナウイルスの影響で自宅からのリモートワークが中心となり、今までのように会社に書籍が届く形での運用は難しくなってきました。新たなワークスタイルでも社員の学びを支援していくために、取り組みを更新する必要がありました。 エス・エム・エスには50人前後のエンジニアが在籍しており、普段から意見交換も積極的に行われています。技術書購入に関しても、どのようにするのが一番良いのかアイデアを出し合いました。しかし、誰かが会社に本を取りに行き、さらに転送するのは現実的ではありません。新たな制度が必要でした。 そこで、全社横断的な仕事を担当するコーポレート部門に相談したところ、「購買用のSlackチャンネルに書籍のURLをポストしてもらい、住所をDMしてもらう」という方法に落ち着きました。 Slackから購入の依頼をすると、コーポレート部門がアマゾンで書籍を購入し、購入時に送付先を自宅に設定してくれます。一般的にアマゾンで書籍を購入すると、納期についても連絡が来ますが、コーポレート部門はメールの内容をもとに具体的な納期についてもSlackでお知らせしてくれます。 書籍発注チャンネルでのやりとり 書籍購入のための実際のやり取りの画面 発案から運用開始まで3日。部門の壁を超え、建設的に対話する組織カルチャー エンジニアの学習支援の他に、エス・エム・エスには特徴的な社風があります。それは 部門間の風通しの良さ です。 今回、当初はエンジニアチーム内で相談をしていましたが、なかなか決め手となるアイデアが出ませんでした。そこで、コーポレート部門に「一緒に考えて欲しい」と相談を持ちかけたところ、2日後には新しい運用体制の提案があり、3日後から利用開始となりました。このように、社内で新たな取り組みをする際、私たちは積極的に コーポレート部門に相談 をします。コーポレート部門は全部署からの相談を一手に引き受けていますが、要望や相談を持ちかけたときに嫌な顔をされたことは一度もありません。 背景説明をして、どうすればスムーズに実現できるかを一緒に考えてもらった結果、すぐに回答を出してもらいました。以下のSlackのスクリーンショットの画面は当時のメッセージなのですが、「神」スタンプが多く押され歓迎されました。 実施後の社内での評判も良く、採用の場面や社外で取り組みについて話した際も「それはいいですね」と言ってもらえることが少なくありません。 部門間のやり取りが少なく縦割りの組織体制だと、相談を持ちかけても変化が遅くなってしまうこともあるでしょう。しかし、前例やしがらみにとらわれず、部門の壁を超えて 目的に向けて一緒に考える ことが重要だと私たちは考えます。もちろん、エンジニア同士も気軽に意見を言い合える環境です。 エンジニアをサポートするための環境づくり このような社内体制・制度の背景には、エンジニアにできるだけ仕事に集中してもらい、良い環境で働いて欲しいという想いがあります。 営業などの社外に出る職種と異なり、エンジニアは外に出ることや接待も少なく、経費精算の機会はほとんどありません。経費精算のやり方を忘れてしまいがちですし、紙で印刷して領収書を糊付けして提出するなど、慣れない作業に少なからず心理的ストレスもあるでしょう。そもそも経費精算などの事務作業に苦手意識を持つ人も少なくありません。 できるだけ事務作業の負担を減らし仕事に集中してもらうためにも、シンプルな仕組みづくりは非常に重要です。 さらに、エス・エム・エスには学びたいエンジニアを積極的に支援しようという社風があります。書籍購入支援だけではなく、サファリブックスオンライン（オライリーの電子書籍読み放題）の提供やカンファレンスの参加費にも積極的に投資しています。 相談してすぐに「 どうやったら実現できるか 」を考え、方法を決定し、進めていけたことは、とてもエス・エム・エスらしいエピソードです。新たな制度の詳細だけではなく、本記事から私たちの普段の取り組みや社内の雰囲気が伝われば嬉しく思います。 今後も、作業を最小化する取り組みや仕組みづくり、エンジニアが働きやすい環境作りを継続して行い、発信していく予定です。ぜひ記事をご覧いただければ幸いです。

介護や医療、ヘルスケア、シニアライフなど の4つの 領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで、技術責任者をしている @sunaot です。2015年2月に入社して以来、技術責任者として開発組織の構築や開発基盤の整備をリードしてきました。 今まで私がソフトウェアエンジニア（以下、エンジニア）の採用面談を延べ800件ほど担当してきた経験を振り返ると、ソフトウェアアーキテクト（以下、アーキテクト）をキャリアのゴールに据えているエンジニアも多いようです。ただ、アーキテクトを目指している一方で、実際にアーキテクトになるためには、どういった会社組織でどのような経験をしたらいいのか分からないというケースも見受けられました。 今回は、アーキテクトを目指したいエンジニアの方向けに、アーキテクトになるために必要な4つの経験や、それが経験できる会社組織について紹介します。 アーキテクトという職種の仕事や価値については、『 「継続性アーキテクト」という生き方 』の記事で詳しく述べていますので、ぜひ目を通してみてください。 1.自分で設計したソフトウェアをメンテナンスする経験 1つ目は、自分でソフトウェアを設計し、それを長期間メンテナンスするという経験です。ソフトウェア開発に一気通貫で関わることで、開発に必要なあらゆる判断力がつけられると考えています。 ソフトウェアの設計の仕方自体は、エンジニアリングの教科書的な書籍を読んで概要をつかみ、実際に設計することで、具体的なスキルや経験が身につけられると思います。しかしそれで本当に満足のいく設計ができるようになるのかというとそうではありません。 この点について、ソフトウェア開発者の 和田卓人さんが「質とスピード」のスライドで引用している言葉 にとても共感しているので、引用して紹介します。 「ソフトウェア開発に最初から最後まで関わるという経験は、とても貴重だった。なぜなら、プロジェクト開始時のダメなデザインのしっぺ返しを、後で自分でモロに受けるからだ。ほとんど考えずコードを『アンダーエンジニアリング』していた。後々これを過度に修正してしまい、全てを『オーバーエンジニアリング』し作り込みすぎてしまったぼくがデザインしたシステムは概ねシンプルさと洗練さを丁度よく兼ね備えていたと思うし、他のエンジニアのデザインの問題点も、比較的すぐに気づくことができた。判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすることだと思う」 自分で作ったシステムをメンテナンスする経験によって、メンテナンスしやすいようにとこだわって設計したソフトウェアが、実際には思うように役に立たなかったり、こだわった部分が意味を為さなかったりと、失敗に気づくことが多くあります。 開発をしていく中で得た知識や経験を、いつどの場面で使うのか。それがとても重要なことであり、その使い方や使う場面を理解できるのが、自分で設計したシステムのメンテナンスから得られる財産だと思います。 2.フロントエンド、ミドルウェア、インフラ、バックエンドのすべてを経験する 2つ目は、フロントエンドからミドルウェア、インフラを含めてバックエンドまでを、すべて自分で経験することです。 大規模な開発組織では分業体制を敷く会社が多く、フロントエンド、バックエンド、インフラと、それぞれの分野で専門性を磨く人材も存在します。そのため、各領域を専門とするアーキテクトも存在しています。 しかし、本来であればアーキテクトは、ソフトウェアシステム開発の全体像を知っている方がいい。なぜなら、フロントエンドの構成がバックエンドの構成に関わっていたり、バックエンドをミドルウェアやインフラを含めた大きな枠組みで設計するなど、ソフトウェアシステムは全体がつながっているからです。 例えば、自社でリリースしたソーシャルゲームが大当たりして、既存のシステムを数百万ユーザーが安定して利用できるシステムに拡張するとします。大量のアクセスをさばけるようにする必要がありますが、そのための方法はひとつではありません。インフラ部分やミドルウェアで解決する手段もありますし、バックエンドで対応することもできます。 大規模な開発や複雑な開発では、ひとつの領域だけでは問題をクリアできないこともあります。インフラ部分で対応しつつ、プログラムの構造を書き換えるなど、複合的な解決手段を取ることも珍しくありません。 ソフトウェアシステム全体の構造から考えて最適な設計を行うためにも、アーキテクトにはシステムを構成する各要素を経験することが必要なのです。 3.Webオペレーションの経験 3つ目は、サービスを実際に運用する（以下、Webオペレーション）経験です。自分で開発したサービスや、すでに運用されているサービスのオペレーションを担当し、運用中に出てきた課題を自分で解決していきます。 Webオペレーションはいわば構築したシステムに対する答え合わせです。設計のときに気にしていたことはテストで答え合わせをすることもできますが、観点が漏れていたことは運用の中でしか見つかりません。 運用中に見つかったさまざまな「設計の穴」を、次のシステム開発に生かすことで、より良いシステムを設計できるようになるでしょう。 4.エンジニアとしてビジネスに向き合う経験 4つ目は、エンジニアとしてビジネスに向き合う経験です。アーキテクトの仕事は、最終的にビジネスの意思決定と関係します。 サービス開発の中での判断の一部は、時にビジネスとしてもタフな決断になることがあります。そういったときには、判断のための材料を提示して議論する必要性が出てきます。特に、技術側とビジネス側で意見の分かれるような開発のときは、ビジネスのフェーズやビジネスモデルもふまえて考えるべきです。 ビジネスのフェーズやビジネスモデルによって、技術的な最適解は変わりうるということを頭に入れて、選択肢の検討をしなければなりません。どうしたら技術とビジネスが両立できるのかを考えていくのもアーキテクトの役割です。 もしビジネスのことまで考えられないと、「この開発をしたいのですがよろしいでしょうか？」とお伺いを立てるアーキテクトになってしまいます。ビジネスのことも理解していれば、「この開発はビジネス的にも意味があるはずなので、この案で実行していこう」とパートナーとして一緒に決めていくことができます。 アーキテクトに必要な4つの経験を積むための環境とは？ ここまでアーキテクトに必要な経験を4つに分けて紹介してきました。 1.自分で設計したソフトウェアをメンテナンスする経験 2.フロントエンド、バックエンド、インフラのすべてを経験する 3.サービスを運用する経験 4.エンジニアとしてビジネスに向き合う経験 これらの経験を得やすい環境の例としては、小規模なスタートアップがあります。一般的な初期のスタートアップでは、小規模なサービスを数人のエンジニアで担当します。一つひとつの仕事の難易度は高くないケースが多く、2年〜3年も在籍していれば、サービス開発や運用に関するほとんどの経験が積めるでしょう。 ただ、スタートアップでは人数が少ないため、自分の仕事に対して客観性を持つことが難しくなります。優れたアーキテクトになるためには客観的に自身のエンジニアリングの仕事の水準を知る必要があります。この点を補うためには、テクノロジーを重視しているメガベンチャーを経験するといいでしょう。そうした会社には優れたエンジニアがたくさん在籍しています。実際の仕事を通して、一流のエンジニアがどのような思考をし、どのような質とスピードでアウトプットをしているかを知ることができます。 両方の組織を通して経験を積むと優れたアーキテクトのキャリアに近づけると考えています。 ここまで、アーキテクトを目指すエンジニア向けに、私が考えるキャリアのヒントを紹介してきました。ここからは宣伝になってしまいますが、今回紹介したアーキテクトに必要な経験という視点で見た場合のエス・エム・エスという会社を紹介して終わりたいと思います。 エス・エム・エスではサービスの種の状態から育てるようなフェーズの事業から売上が100億を超えるような規模の事業まで様々な事業をやっています。エンジニアの仕事の範囲はサービスの企画に関わるところから自身でコードを書いて開発をし、インフラの構築をし、ウェブオペレーションを通してサービスの日々の面倒を見ていくところまで自分の仕事として担当します。アーキテクトになるための経験を全部体験できる環境です。関心のある方はぜひスライド資料『 アーキテクトの生き方 』を見てみてください！ アーキテクト人材のキャリアの考え方から、エス・エム・エスでのアーキテクトとしての機会や環境について紹介しています。  少しでも気になったら、軽く話してみるだけでも結構ですので、下記リンクからご連絡ください。お待ちしています。

介護や医療、ヘルスケア、シニアライフなどの 4つの 領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで技術責任者をしている @sunaot です。2015年2月に入社して以来、技術責任者として開発組織づくりやサービスの内製化を進めてきました。 「『継続性アーキテクト』という生き方」というタイトルをつけていますが、タイトルで名詞化しているのは釣りで、アーキテクトの仕事について書いています。これは私がアーキテクトという仕事の可能性について考える中で、「継続性」に注目するとその仕事の価値がより発揮されていくのではないかと考えた内容をまとめたものです。 アーキテクトが抱える葛藤 私は役割柄、採用などでソフトウェアエンジニア（以下、エンジニア）と面談をする機会が多く、年に約200人くらいの方と話をしており、キャリアについて話を聞く機会も多くあります。その中で多くの方のキャリアのゴールとして挙がるものの一つに、ソフトウェアアーキテクト（以下、アーキテクト）があります。おそらくこれにはいくつかの意味があります。 まず、システムアーキテクチャの全体像を描ききれるような能力を身に着けたいということ。それから、システムアーキテクチャの根幹に関わるような部分での技術的な意思決定をできる裁量を得て、自身の能力を最大限に活かしたいということ。そして、その重要な役割に見合った待遇を得たいということ。 実際に優秀なアーキテクトとして働ける人材は採用市場での需要が非常に高く、エンジニアにとって技術で敬意を抱けるわかりやすい役割です。キャリアのゴールとして意識されるのもうなずけます。このときにイメージされるアーキテクトの仕事としては、高い設計能力を活かしてソフトウェアアーキテクチャを設計し、その完成形を形にすることかと思います。 一方、実際にソフトウェアアーキテクト（やそれに近い立場）として活動をしている人たちは、「本当にそれほどよい設計というものが必要とされているのか」「”Just enough” （ちょうどよい塩梅）な設計はどのくらいか」といった葛藤を抱えていたりすることはご存知でしょうか？ クリーンアーキテクチャやドメイン駆動設計のようなソフトウェアの設計に関する技法を学び、人一倍質の高いソフトウェア設計について関心があるはずのアーキテクトが、設計の価値について疑問を持ちながら働くのはなぜでしょうか。 一つ目の理由は、完成させてリリースすることではなく、サービスを成功させるということが仕事の中心になったことが挙げられます。とくにサービスの立上げフェーズではサービスがユーザーにとって価値を持つのか、使ってもらえるのかといったことのほうが大きな課題であることが多く、ソフトウェアの設計には新しい問題はないことが多かったりします。 二つ目の理由として、ソフトウェアが完成しなくなったことが挙げられます。サービスとしてチームが継続的に改善をしていくことが当たり前になりました。これによって一人の人が完成させた設計の姿というものの意義が相対的に薄れ、ソフトウェアの設計は継続的な開発とチームの能力によって常に変化していくものとなりました。 様々な能力水準を持つ人たちが入れ替わりながらソフトウェアをメンテナンスしていく場合、油断をすると深い設計意図を持った初期設計は容易に崩されることになります。 アーキテクトは、優れた設計をするために能力を高めた結果、高度な設計をするよりもほどよいわかりやすさで軽量にスピードをもって開発をしていけるほうが価値があるのではないかという感覚を持つに至る人が多いようです。 では、アーキテクトの価値は減ってきたのか。それをこれから考えていきたいと思います。 アーキテクトが必要なソフトウェアの「規模」と「複雑さ」 アーキテクトが必要とされるシステムの特徴は、技術難度が高いこと。技術難度の高さには「規模」と「複雑さ」という要素があります。規模と複雑さの両方の特性の難度を持ったシステムも存在します。 「規模」の難度が高いとは、システムの規模が大きいソフトウェアの開発です。関わる人が多いことも大規模システム開発という呼び方をしますが、ここではあくまで作っているものの規模の大きさを指しています。機能や業務が多く、その結果としてシステム規模が大きくなる場合と、多くのユーザーによる大規模トラフィックをさばくためにシステム規模が大きくなる場合が代表例です。 機能や業務が多い場合の例としては銀行や保険のような金融業や大手のECなどが挙げられます。大規模トラフィックをさばくための例としてはLINEやメルカリのようなサービスが挙げられます。 「複雑さ」の難度が高いとは、システム化する対象のドメインが持つ困難さです。設計難度の高い課題として知られている非同期処理や並行処理、分散処理などに関する技術的な解決を必要とするようなものが代表例になります。そのもの単独で難度が高いのもありますし、信頼性や応答速度が一定の水準を求められたり扱うデータの件数や容量といった複数の条件を考慮した結果、実用可能な設計を考えると難度が高くなるということもよくあります。 例えば、同時接続数の多い動画配信の仕組みや大量のメッセージを遅延なく並行に送信し続けるメッセージングアプリの仕組みなどは「複雑さ」の難度が高い場合の例と言えます。 「積み重ね」がアーキテクトの可能性を広げる 技術難度の高い問題を解くことはアーキテクトの大きな価値です。ただ、サービスの成長が停滞してくると新しい課題というのが生まれにくくなってきます。こうなってくると、アーキテクトが腕を振るう仕事というのが少なくなるため、アーキテクトは新しい課題を求めて別のサービスの立上げへ仕事の場を移したり、社内でその場がないとなると職場を変えて自分の次の活躍の場を探したりします。 こうして新しい課題を求めて次々と仕事の場を移していくのは、性質の違う課題を解き続けて自身の能力を発揮できるという楽しみはあります。一方、サービスの成長の停滞とともにリセットして次を探すという形になるため、自身の設計判断や問題の解決が最後に社会にインパクトを残すというところまでつながりにくいという課題もあります。 では、アーキテクトに他の選択肢はないのだろうか。そう考えていた自分にとってヒントになったのが関将俊さんという人の存在です。関さんはRubyKaigi や JaSST、XP祭りなどのカンファレンスでご自身のチームやプロダクトについて発表をしています。続けて発表を見ていく中で、ストーリーが続いていることに気づきました。たとえばご自身の仕事のチームとXPについて話をしている発表だと、2004年から2007年、2008年、そして2019年と、同じコンテキストで続いているチームの話をしています。 時系列で発表を追っていくと、チームやプロセス、そしてソフトウェアの成熟度合が上がっていっていることがよくわかります。関さんの話の環境はスタートアップがサービスを立ち上げるというような文脈とは違っているのですが、このその時その時の状況で必要な工夫を重ねていくことで成熟度合を上げていくという仕事の仕方はヒントになります。 現代では「作って終わり」という開発は減り、リーンスタートアップのような考え方が一般に知られるようになりました。こうした変化の中でアーキテクトは、目新しい問題を解き続けるというキャリアとは違う、新しいキャリアを歩けるようになってきました。 こうした新しいアーキテクトのあり方を、この記事では「継続性」のアーキテクトと呼んでいます。スナップショットでサービスにとって必要な設計をするのではなく、サービスに継続して関わり、成長段階に合わせて必要な設計をし続けるという役割です。 優れた初期設計をつくり難しい問題を求めて転々とするのではなく、サービスの成長段階に併走して、その時々に出てくる課題をアーキテクチャとチームの中でどのように解決していくかを考え、実行をしていく。 体制や成長、目指す姿など、その時々のサービスの状況にあわせて設計の見直しをかけたり、チームへ働きかけたりして仕事の場の成熟度合を上げていく。そして、それによって社会に価値のあるインパクトを出す仕事をする。 自身の仕事にこだわりを持っているエンジニアにとって、そんな継続性のアーキテクトの仕事は魅力的な仕事になると考えています。 「継続性のアーキテクト」が活躍できる環境とは？ 最後に「継続性のアーキテクト」が実現できるのはどのような環境か。企業やサービスに必要な条件を、5つ挙げてみました。 1．今後長きにわたってニーズが増えるマーケットである 2．マーケットの置かれた環境が変化していく 3．対象となるマーケットで1位になる力を持っている 4．ビジネスモデルが変化していく 5．システムが硬直化することを許容しない 継続性のアーキテクトとして働くには、1つ目に、ビジネスの寿命が長いことが条件になります。どれだけサービス開発の場を継続性をもたせてやっていこうとしても、ビジネスが終わったら寿命はそこで終わりです。これから長期間に渡って、ニーズが拡大していく市場であることはなによりも大事な条件になります。 2つ目に、属するマーケット自体の環境が変化しやすいと、それに合わせてビジネスが変化する必要があります。経済動向や法規制の影響など外部要因でビジネスが変化を求められる環境は、ドメインの変化にあわせて変化していく必要があり、継続性のアーキテクトの価値が発揮しやすい環境です。 3つ目は、そのマーケットで他社に打ち勝ち、1位になれる力を持っているかどうかです。採用面談をしていると、「〇〇業界に興味があるので、その業界に属する企業に行きます」という言葉をよく聞きます。興味のある業界に属する企業に就職することはすばらしいことですが、その業界の中で競争力のあるポジションを取る力があるかは重要です。その力がないと、やはりビジネスの寿命によってサービス開発の継続性は途絶えることになります。 4つ目に、ビジネスモデルを変化させていけることもポイントです。たとえ成長を続けるマーケットであっても、ビジネスモデルに変化がない場合は新しい性質の問題は生まれにくくなります。 そして、5つ目は、すでに運用されているサービスが硬直化していないこと。多くの場合、リリースしてから順調に拡大し、収益もそれなりに上がっているサービスは、変更しないことが優先され変化することに保守的になります。システムを硬直化していくことを良しとしない文化を持つ企業に行くことは継続性のアーキテクトが価値を発揮する大事なポイントです。 こうした条件を兼ね備えた環境であれば、ビジネスの変化に応じてソフトウェアが変化し続けていくことが価値を持ちやすいため、継続性のアーキテクトという働き方が実現できると考えています。 筆者の所属しているエス・エム・エスではここに書いたような視点で、アーキテクトという仕事を位置づけています。待遇もふくめてアーキテクトがキャリアのゴールになるような会社にしているので、関心のある方はぜひスライドも見てみてください。 アーキテクト人材のキャリアの考え方から、エス・エム・エスでのアーキテクトとしての機会や環境について紹介しています。 少しでも気になったら、軽く話してみるだけでも結構ですので、下記リンクからご連絡ください。お待ちしています。