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周目はテストに強いメンバーをチームに入れて、テストまでをチーム内で行える体制にしています。これで、より技術的負債の解消の速度が上がるはず。 まだ、技術的負債の解消のための環境整備は、現時点では自分のチームだけでしか実装できていません。今後は、この成功体験を横展開し、全社的に広げていきたいなと思っています。

はじめまして。エス・エム・エスでアーキテクトをしている三浦です。2020年10月にエス・エム・エスに入社しました。 以前は、複数のベンチャー企業でエンジニアやプロダクトマネージャーなどを兼任してきました。 まだ入社してわずかな期間ではありますが、なぜエス・エム・エスに入社したのか。入ってみて何を感じているかを書いてみようと思います。 「技術」「ユーザーの喜び」「事業成長」の3つを満たして働きたい 私はこれまで、エンジニアやプロダクトマネージャーとして、『はてなブックマーク』のフルリニューアルや、子ども向けの知育アプリの開発、AI（人工知能）を活用した需要予測サービスの開発などに携わってきました。 エンジニアになったのは偶然です。もともと、心理カウンセラーを目指していて、大学卒業後は、アメリカの大学院への進学を考えていました。その前に社会人経験を積んでみようと、医療に特化した市場調査の企業に入社しました。 最初はマーケットリサーチを担当していたのですが、ある時インターネット調査に特化したチームを立ち上げることになりました。そこで「三浦くん、インターネット好きだよね？　開発とかやってみない？」と、いきなり抜擢されて。青天の霹靂でした（笑）。 開発の経験は全くなかったのですが、やってみたら予想以上に面白かった。頭の中に描いたものを、コードを通してシステムとして実装し、実際に動かせる。それがとにかく新鮮でした。 何よりも、「ユーザーの反応がある」というのが大きな発見でした。医療系の調査をするシステムだったので、ユーザーは医師や薬剤師の方々。みなさん、とても職業意識が高く、作ったものに対して厳しいフィードバックを受けました。最初のころは、あまりの厳しさに急性胃腸炎にかかったことも（笑）。 それでも、反応があることが嬉しかったですし、フィードバックを踏まえてプロダクトがさらに磨かれることも魅力的でした。この経験を経て、カウンセラーではなくエンジニアとして生きていこうと決めました。 その後は、株式会社はてなや子ども向け知育アプリの開発をする株式会社スマートエデュケーション、AIを需要予測やマーケティングに活用するサービス開発をする会社など、ベンチャー企業で経験を積みました。 エンジニアやプロダクトマネージャーとして、事業を作る人たちと一緒にプロダクトの立ち上げに関わることが多かったです。実力不足で思ったような成果を出せない時期もあったのですが、失敗と反省を繰り返すうちに、技術と事業をセットで成長させていく面白さを感じていきました。 印象に残っているのは、スマートエデュケーションで取り組んだ保育園や幼稚園に向けたICT教材の開発です。プロダクトマネージャーとして、1カ月で教材のプロトタイプを作り、お披露目するというミッション。 その教材は、自分が描いた絵をスマートフォンで撮影し、モニターやプロジェクターに接続すると動き出すというもの。タイトなスケジュールで進行したプロダクトでしたが、実際に子どもたちに体験してもらったところ、「私の絵が動いている！」と目を輝かせて喜んでくれました。そのときは、涙をこらえるのに必死でしたし、子どもたちの表情は今でも忘れられません。その後、正式にリリースをして、事業を伸ばすことができました。 こうした経験を積み重ねて、「ユーザーが心の底から喜んでくれる、世の中のスタンダートになるものを作りたい」という思いが強くなっていきました。それ以来、「技術」「ユーザーの喜び」「事業成長」の3つが、私にとって仕事をしていく上で欠かせない要素になりました。 「高齢化」という社会課題に技術でアプローチするやりがい 私がエス・エム・エスに入社したのは、「世の中の当たり前になるプロダクト作り」に携われそうだと思えたからです。 エス・エム・エスは、高齢社会に求められる領域を、介護、医療、ヘルスケア、シニアライフの4つとし、40以上のサービスを開発・運営している会社。2025年には3人に1人が65歳以上になると言われており、高齢社会においてプロダクトを必要とする人が確実に存在しているのは大きな強みだと感じました。さらに、17期連続で増収・増益していて、事業基盤もしっかりしている会社です。2003年の創業から40以上の新規事業も生まれ、アジアを中心に17カ国にサービスを展開するなど、グローバルに活躍できるチャンスがある。私が大切にしている「技術」「ユーザーの喜び」「事業成長」の3つの要素に当てはまっていました。 ただ、現状のエス・エム・エスは、技術的な挑戦の余地があります。私が担当している介護事業者向け経営支援ソフト『 カイポケ 』は、2021年4月1日現在で31,100の介護事業者に使っていただいています。『カイポケ』は40以上の機能・サービスで構成されており、機能の変更はもちろん、新サービスの開始や古いサービスの廃止も継続的に行われています。また、社内でのデータ活用をもっとやりやすくするような改善も進めています。介護事業者の日々の業務を担っているシステムですから、サービスを安定的に利用していただきながら、こういった改善を進めていく必要があります。 これまでの経験を生かしながら、技術でのサービス改善をしていけば、さらに事業の成長を後押しできる。そう感じて入社を決めました。 入社後は、『カイポケ』のサービス全体のアーキテクチャ（基本設計）を考えるアーキテクトとして働いています。 入社してしばらくの間、週替わりで各チームに入って、MTGに参加したり開発の様子を見たりしていました。一つひとつのサービスの仕組みを理解して、どんな課題があるのかを探っていました。その様子の詳細については こちらの記事 をご覧ください。 実際にメンバーと接してみて、「ビジネス視点」と「ユーザー視点」が根付いた、とてもいいチームだと思っています。ビジネスに強い企業は、ビジネスサイドに比べて開発サイドのパワーバランスが弱いとも聞きます。エス・エム・エスもそうなのかもしれないと心配していたのですが、杞憂でした。ミーティングの様子を見ていても、お互いが意見を出し合って歩み寄りながらプロダクトの開発に取り組んでいます。 ユーザー視点が根付いているなと感じたのは、システムに障害が起きた時の対応です。真っ先に「ユーザーに対して申し訳ない」という一言が、エンジニアたちから出てきます。これまでいくつかの会社で働いてきたのですが、開発に夢中になるあまり「ユーザーの顔」を忘れてしまう人も少なくありません。 障害という不測の事態でユーザーの顔が真っ先に浮かぶのは、「ユーザーのためにプロダクトを届けたい」という意識が根底にあるからなのだと思います。 学ぶことが尽きない事業領域の面白さ ユーザーへの理解を深めるという点では、開発サイドのメンバーも、介護業界のキャッチアップを求められます。私も、社内で定期的に開かれる介護の勉強会に参加をして、国や自治体の取り組み、介護保険制度などについて学んでいます。これまでは「勉強会」といえば技術系のものが中心だったので、新鮮です。 エス・エム・エス社内で実施している勉強会のアジェンダ（一部） 介護業界は、事業者が利用者にサービスを提供した際に対価として支払われる「介護報酬」が3年に1度、改定されます。それに合わせて、機能の仕様も変えていかなければいけません。「変化」が前提だからこそ、開発サイドも知識のキャッチアップが求められます。ちょうどその改訂作業が現在進行中です。外部要因で仕様を変えていかなければいけない状況は初めてなので、非常にワクワクします。 「社会」の変化を直に感じながら開発に向き合えるのは、エス・エム・エスの魅力です。特に『カイポケ』は、高齢社会を支える「働き手」のためのプロダクト。介護の現場では働き手不足が取りざたされています。技術の力で彼らの負担を少しでも軽減させて、心から仕事を楽しめる状態を作りたい。数十年先も「介護」の仕組みがしっかりとまわる世界を作ることが、私の今の使命だと思います。

介護や医療、ヘルスケアなどの領域で、高齢社会に適した情報インフラを提供している株式会社エス・エム・エスの西村直人（ @nawoto ）です。私は2005年からソフトウェア開発においてアジャイル開発を実践しており、現在はアジャイル開発の考え方を軸にチーム開発の支援などを行っています。 エンジニア組織ではリリースを頻繁にできることが望まれますが、リリースすることに疲れたりしませんか？僕たちは「リリース疲れ」と呼んでいますが、疲れが溜まるようにどんどんリリースが辛いものに感じてきます。エンジニア以外に言ってもあまり理解してもらえませんが……。 そんな悩みを解決するべく、エス・エム・エスの開発チームで行ったのは、レゴを組み立てること。え、なんでレゴ？そんな「リリースレゴ」という取り組みについてご紹介します。 プロダクト開発を継続すると起こる「リリース疲れ」 事業は長く継続していくように構築されているもの。なので、ソフトウェア開発は一度リリースしたら終わりではなく、継続してお客様が利用できるよう、エンジニアは改善や改修のリリースを重ねていきます。 初回のリリースこそ達成感に満ちあふれますが、それ以降の機能改善のためのリリースはだんだんと日常化し、淡々とした作業になりがちです。いつしか「このリリースはきちんと事業に貢献できているんだろうか？」と、自分の仕事が事業に役立っているか疑問が生じるようになっていきます。 しかも、リリースは前向きな気持ちで臨めるものだけではありません。提供し始めてからの期間が長くなれば、リリースの中には古くなった機能の廃止や、苦労して導入したけれどあまり利用されなかった機能の停止などのリリースも増加していきます。こうしたリリースは、同じリリースでも前向きな気持ちで行うのは難しいものです。 時には、あまり利用されなかった機能を廃止するなどのリリースによって、一部のお客様にご迷惑をおかけすることが続き、リリースに対して恐怖心が芽生えてしまうエンジニアもいます。 こうした出来事が生じることもあり、継続してソフトウェアを提供していくと、「リリース疲れ」を起こします。仕方ないこともありますが、終わりのないリリースに士気が下がっていってしまう開発チームもありました。 「継続して良いソフトウェアを提供するために、この悪循環をどうにかできないか？」と悩んだシニアエンジニアと、さまざまな策を検討していたとき、ふと、かつての現場で行っていた「バグレゴ」を思い出しました。 バグレゴとは、バグが出てしまったときに、ブロックの「レゴ」を組み立てるというもの。これを応用して、リリースした分だけレゴをチームの皆で組み立てていったらどうだろうか？と提案。さっそくやってみることにしました。 「リリースレゴ」で開発現場に生まれたポジティブな変化 社内では「リリースレゴ」と名付けて、リリースのたびにレゴを組み立てています。リリースレゴのやり方は、以下の通りです。 ①レゴを購入する。最終的に形になる「作品シリーズ」がおすすめ ②プロダクトをリリースをする ③レゴの手順書を見て、リリースした数だけレゴを組み立てる。先の手順は見ない デスクに並ぶ完成したレゴの作品 リリースレゴを実践してみたチームでは、リリース報告を夕方の定例MTGで行っていたので、そのMTGで手順に沿ってレゴを組み立てていきます。その日のリリースが1個であれば、レゴも手順に沿って1段階分だけ組み立てます。先の手順は見ないので、最初はどの部分を組み立てているのかすら分からない状況でした。 「これ何の部分だか全然分からないっすね」 「もっと早めにリリースできるものあった気がするね」 といった会話が生まれ、チームはリリースに前向きな気持ちに。今までは保守的に計画して週に1つずつリリースしていたのが、来週は2つリリースしよう、機能をなくすような後ろ向きなリリースも早くやってしまおう、という言動が見られるようになりました。 リリースしてレゴのブロックを積むという作業を1ヶ月〜2ヶ月続けた結果、やっとレゴの作品が完成。 完成したレゴを見たチームメンバーから、次はもっと大きな作品に挑戦したいなどの前向きな言葉も出てきて、リリースを楽しめる雰囲気が醸成できました。その結果、リリースの数はこれまでの2倍以上増え、後ろ向きなリリースだけでなく機能を改善するようなリリースも多く出るようになりました。リリースレゴを導入したことで、チームパフォーマンスが明らかに向上したんです。 たまたまレゴを選んだのですが、結果的には正解だったと思います。手順書の先を見ずにレゴを一つひとつ組み立てていくと、最初はいったい何を作っているのか把握できません。ですが、レゴの入っていたパッケージを見れば最終形態が分かるので、完成した状態を思い描きながら進んでいけます。このレゴづくりの体験は、ソフトウェア開発にも通じるところがあると感じました。 ソフトウェア開発も、いま自分の行っている仕事の成果が見えにくくなることがあります。リリースを重ねることによってプロダクトが成長し、事業にも貢献していることは確か。しかし、それは目に見えません。自分たちが積み重ねてきたリリースをレゴによって可視化し、貢献した軌跡をポジティブに捉えられる取り組みは、チームにとってプラスだったのではないかと思います。 ※リリースレゴについては、当時のチームメンバーの寄稿したコラムが拙著『 SCRUM BOOT CAMP THE BOOK【増補改訂版】 』に掲載されているので、もっと詳しく知りたい方はぜひそちらも参照してみてください。 感情面も含めて合理的に考え、チームで学びをシェアする文化 「よくレゴを使ったアプローチなんか許されたね」 「遊んでるだけって思われなかったの？」 と気になる人もいるかもしれません。社内ではレゴを使った取り組みに対して難色を示す人はいませんでした。なぜなら、社内にはチームのパフォーマンスを最大化したい、という考えが広く浸透しているからです。 開発のパフォーマンスを最大化していくためには、「仕事に対する手触り感」や「恐怖心に向き合う」など、直接は仕事の成果につながらなさそうなことでも課題として捉え、解決していくべきだと考えています。そのために、開発の現場の最前線にいるエンジニアが解決策を考え、実行する自由があります。 リリースが積み上がって生まれたいろんなレゴ作品 あと、社内には、成功体験やノウハウを共有し、それを他のチームが積極的に真似するという文化があります。ある日、チームメンバーが社内Wikiであるesa内の広報エリアに、制作途中だったレゴの画像を載せたところ、他のチームから反応がありました。しばらくすると、いくつかのチームでリリースレゴに取り組み、ポジティブなコミュニケーションをする光景があちこちで見られるようになりました。 何事も相談しやすい雰囲気があって、自由に改善でき、成果の出た取り組みを他のチームでも活かせる会社の文化。この文化があるからこそ、エンジニア組織は強くたくましくなっていくのだと思います。 現場から自由に課題解決に取り組める 過去、さまざまなチーム作りに関わってきて感じるのは、開発におけるあらゆる問題は、現場のチームから改善するのがベターだということ。 何が本当の障壁になっているのかは、開発している本人たちにしか分かりません。だから、自分たちの組織外から誰かしらが課題を定義するよりも、実際の現場から課題が浮かびあがり、自由に解決に向けた取り組みが走り出していくことが重要だと思っています。 エス・エム・エスでは、現場のチームが元気になるようなチーム作りを現場から自由に起こせるように様々なことに挑戦しています。エス・エム・エスはエンジニアを積極採用中ですので、興味を持った方はぜひこちらのスライドも見てみてください！

タスク管理は、チームで仕事をしていく上で欠かせない一方で、永遠にカイゼンし続ける必要があるものです。チームごとに、どんなツールを選んでいるのか、それをどう利用しているのでしょうか。 エス・エム・エスでは、タスク管理の仕方もチームごとに裁量が与えられています。どのようなツールを利用してタスク管理をしているのか。「カイポケ」「カイゴジョブ」「ハピすむ」など、各サービスの開発チームに聞いてみました！ ツールの選定基準、利用の仕方、利用ツールのメリット・デメリットなど、開発チームによってどのような違いがあるのかを紹介していきます。 エンジニアチームごとに異なるタスク管理ツール 今回、話を聞いたのは、カイゴジョブ、ハピすむ、カイポケGengar、カイポケ障害、カイポケKSEE、カイポケSRE、カイポケ訪看など7つの開発チームのエンジニアメンバー。 それぞれのチームで使っているツールやチームのメンバー構成等を答えてもらったところ、以下のようになりました。 ちょっと細かいので、拡大して見てみてください 一覧にすると、Jiraを利用しているチームが目に付きますが、それでもチームによって導入しているツールや組み合わせは、GitHub、Trello、Asana、Jiraなどバラバラです。 エス・エム・エスは、チームごとにツールを自由に選んで決められるようになっているため、このようにチームにとってタスク管理に用いるツールも異なります。各チーム、どのようにツールを選んで使っているのか、順番に聞いてみました。 開発チームごとにどうタスクを管理しているか？ シンプルにTrelloを使いこなす、カイゴジョブ カイゴジョブは、Trelloにアドオン機能のAgile tools addonを導入して利用しています。課題の大きさを表す数値であるストーリーポイントは、タスク管理上割り当てたかったため、Trelloを利用し始めてすぐにアドオンも合わせて利用を開始。 Trelloのボードは、新着、Pending、プロダクトバックログ、スプリントバックログ、という着手タイミング管理レーンがあり、着手したらDoing、Review、確認、Doneという進捗レーンを進んでいきます。Doneのレーンは、スプリントごとに用意。 諸橋：Trelloの導入前は、ホワイトボードなどで物理の付箋を利用して進捗を管理していたものの、出社のたびに数枚剥がれているような状態が続き、デジタル化することになりました。 事業側のメンバーからは、スプレッドシートで管理したいという意見もありましたが、エンジニアメンバーはスプレッドシートでは管理がしにくいので何か別案がないかを検討。 エンジニア以外のメンバーでも活用ができ、複雑な仕組みにせずに導入が可能なツールとして、両者にとって使い慣れているTrelloに白羽の矢が立ち、導入することになりました。 ツールが複雑ではないからこそ、事業部の人からも要望のカードを気軽に入れてもらいやすいという点がメリットとして挙げられます。早い段階で要望を出してもらうことで、技術的な視点から検討をして前向きなコミュニケーションにつなげやすい状況が生まれているそうです。 ほとんどデメリットを感じることはないそうですが、Trello上で目印として利用しているラベル機能の色が足りない、カードのステータスが進捗してもレーンを移し忘れるなどが発生している点などが挙げられました。 AsanaとTrelloを組み合わせて効率管理、ハピすむ ハピすむは、AsanaとTrelloを併用して利用しています。ハピすむは、開発以外にも営業やコールセンターなど様々な職種が混在するチーム。そのため、Asanaを開発以外のメンバーも含めたチーム全体のタスク管理ツールとして利用しています。 Trelloは、フロー化されたOpsを回すためのタスクや状態管理に利用。プロダクトの管理画面とAPI連携しており、案件が発生したら自動でカード生成などの用途で活用しています。 三浦：このツールの組み合わせにする以前は、GitHub Projectを利用していたものの、日時管理がしたい、タスクのカテゴライズ機能が弱い、非エンジニアとも開発系のタスクを共有し、かつチーム間のタスク管理ツールをまとめたいといった要望や不満からツールを移行しました。 数あるツールの中でもAsanaに決めた理由は、管理方法は大きく変わらずカンバン形式による管理が可能、他ボードとの共有が非常にしやすい、機能が充実しているという点などがありました。 Asanaは、タスクの表示方法が多様であり、開発とそれ以外のプロジェクト間のタスクの共有管理などもやりやすい点、タスクに対して柔軟にフィールドを追加できたり、GUIで自動でルールを組める点などが利点に。 Trelloに関しては、手軽にカンバン形式のタスク管理ができる点と、開発しているアプリとAPI連携ができる点などが選定理由として挙げられました。一方で、Trelloで複雑なことをやろうとすると無理が生じやすく、その点は不便が生じるそうです。 GitHub でエンジニアファーストな管理体制、カイポケGengar カイポケGengarは、他職種とのコミュニケーションは頻繁に発生せず、エンジニアだけでタスク管理方法を考えることが可能でした。そのため、もともと利用しているエンジニアと親和性の高いGitHubでタスクも管理。GitHubであれば、ソフトウェアのコードと近いところでタスク管理ができる点も選定の基準に。 前田：マイクロサービスとして開発しているため対象のリポジトリが多く、タスクの見える化が主な課題だったため、もともと GitHub Issueを使っていたところに、GitHub プロジェクトボードを導入してカンバン形式でタスク全体の可視化に着手しました。 直近やるタスクはプロジェクトボードに乗せ、リポジトリに紐付かないものや Issue にならないものもメモ代わりにカードとして登録しておき、リポジトリに紐付けができるようになったタイミングで、Issueに転換して管理するという運用になっています。 GitHub プロジェクトボードは、タスクの粒度（小タスク）などが設定できない点、Issueレベルで期限が設定できない点などの不便はありますが、現時点で細かい期限設定が要求されないので、ラベルなどでやりくりしながら利用しています。 Jiraで統一、カイポケ障害 / EEVEE / KSEE / 介護レセ開発 / 訪看 Gengar以外の、カイポケの障害、EEVEE、KSEE、介護レセ開発、訪看のチームは、共通してJiraを利用。Jiraの導入以前は、別ツールを利用していたり、ホワイトボードを利用してアナログで管理しているチームもいましたが、一括してJiraに移行しました。 SREチーム：ホワイトボードなどからの移行した背景には、期日系は把握しにくい、付箋だと情報が残らず、詳細も残せない、リモートワークするメンバーが増えて物理での管理がやりにくかったなどの要因がありました。 Jiraを選んだ背景は、カイポケに関連するチームの中では利用実績があった、お問い合わせの二次対応や不具合の蓄積場所として日常的に使っていた、異動前のチームがJiraを使っていてメンバーが慣れていた、という点が挙げられます。 基本は、Jiraをタスクボードとして活用し、毎スプリントでタスクを遂行し、デイリーでタスク状況の確認などを行っています。デメリットにつながる要素は、画像添付などのレスポンスがGitHub Projectsなどと比べると遅い、ストーリーとタスクが両方同列に並んででてきてしまうため視認性が悪い、全部の機能をオンにするとJiraに働き方をコントロールされているようになってしまうなどがありました。 チームに合わせて自由にタスク管理の方法を選ぶ エス・エム・エスでは、タスク管理に用いるツールはチームごとにバラバラ。チームの規模、サービスの性質、仕事の進め方は異なるため、チームごとに合わせたツールを導入するのが合理的です。 チームごとに経験している内容はesaにまとめていっているので、事業フェーズやチームのサイズ感が変わった際には参考にすることもできます。 新しいタスク管理のツールは、どんどん生まれます。導入にあたっての予算的な縛りもなく、現状のツールに縛られることなく、チームごとに自由にツールを選定できる環境は、新しいツールを試したいエンジニアとしては嬉しい環境となっています。 もちろん、ツールの導入はチームの同意やリテラシーの差を埋めるための配慮なども必要です。こうした実際に導入するにあたって必要となる工数などを考えることもエンジニアにとっては良い経験。 今回はタスク管理にフォーカスして紹介しましたが、コードレビューのやり方や連携ツールも含めると、かなりの自由度で利用するツールや、手法をチームごとに決められるのがエス・エム・エスの開発チームです。エス・エム・エスではエンジニアを積極採用中ですので、関心を持った方はぜひこちらのリンクを見てみてください。

    はじめに 規模の大小を問わず、レガシー化したサイトには色々な課題が存在します。課題の根本的な改善のためにソースコードをゼロから書き直してリニューアル（以後、このことをフルリニューアルと呼称します）するということは、とても魅力的な一方でリスクもあります。フルリニューアルすなわちアンチパターンとされていることも多いですね。 ここでは「中規模程度のコミュニティサイトをフルリニューアル、すなわち一から全部作り直す」という選択をした背景や、その進め方について書いていきます。 なお、書きやすさのために筆者一人で思考・実行したように書いていますが、実際には事業部所属のもう一人のエンジニアもしくは二人の考えや行動をミックスしたものとなっています。   TL;DR PHP 5/Ethna & Smarty/オンプレ/オフショア開発7年ものを引き継ぎ/ツライ ↓ PHP 7/Laravel & Vue.js, Elixir(GraphQL)/AWS/内製開発/モウツラクナイ   どんなサイト？ 今回の記事の舞台となるサイトは、 エイチエ( https://eichie.jp/ ) という管理栄養士・栄養士に特化したコミュニティサイトです。一般の人には知られていませんが、ネットを使う世代の管理栄養士・栄養士の中で知らない人はまず居ません。会員数は既に10万人を超えており、ユーザ層も学生から70代までとバラエティに富んだサイトです。 機能としては一般的なコミュニティサイトですが、運営開始は2011年6月という、それなりに歴史のあるサイトです。リニューアル前にはベースとなるOSやソースコードのレガシー化も進んでいて、機能追加や変更を行うのがなかなか大変で、これぐらいの歴史のあるサイトにおける、あるあるな状況でした。   システム構成 エイチエがリリースされた2011年あたりにはクラウド環境もまだあまり使われておらず、サーバの置き場所と言えば自社のiDCあるいはオフィスのサーバ室というのが普通でした。何だったらエンジニアの足下に置いてあるサーバで動かしているなんて企業も、そう珍しくもない時代でした。さくらのVPSが運用開始したのが2010年9月というと、どれぐらい昔なのか実感できるのではないでしょうか。 開発言語はPHP5で、フレームワークはEthna( http://ethna.jp/ )を使用していました。WebサーバやDBサーバは Apache と MySQL(+Senna) という典型的なLAMP環境です。エイチエに限らず当時は、だいたいこういう構成のサイトが多かったですね。 OSはエイチエがリリースされた時期には CentOS 5 しか存在しなかったはずですが、リニューアル直前には VMWare 上の CentOS 6 で稼働していました。VM化とあわせてインフラチームがどこかで移行したのかもしれません。まぁとにかく、2021年の視点から見るとさすがに古すぎる環境です。   当時の状況 中規模程度のコミュニティサイトで一般的な機能しかなかったにもかかわらず、ソースコードの構成がやたら複雑でした。初期〜中期の開発には携わっていなかったため、これまでどのように意思決定され、どう開発されてきたのかは良くわかりませんが、「SQLは当然のように sprintf() で作られていた」と書けば、だいたい伝わりますよね？ のちほどわかったのですが、社内の別のコミュニティサイトのソースコードを流用したものをベースとして作られたという出自を持っていました。そのためソースコードは言うまでも無くDBにも使っていないテーブルはもちろんありますし、0や1など謎の値が格納されるけど実はどこからも参照されていないカラムなど、ソースコードの可読性や保守性を妨げるお楽しみ要素が満載でした。   同じ事をやるロジックは都度コピペをするのが温かみのある実装と言わんばかり にあちこちに点在し、何ならサイトのサイドバーのテンプレートファイルが複数存在していました。バナー1つを貼るだけでも複数ファイルを更新する必要があり、あるページにはバナーがでているけど、あるページには無いという事故もよくありました。ページによってサイドバーに表示する内容が少し違っていたので、当時、テンプレートファイルを分けたのでしょうね。わかります。一度 複数に分かれてしまっているテンプレートをあとから一つに統合するよう修正するのは、簡単そうにみえて実は結構大変でした。 色々な動作も遅く、PCには存在するのにSPには無いか、あっても正常に動作していないフシのある機能（あるいはその逆）ということもありました。もちろん最初からそういう状態ではなく、機能開発を日々積み重ねていくことで徐々に問題が蓄積していったのでしょうが、その状況でも日常的に使い続けて頂いていたユーザさんには本当に感謝しています。 そうそう、状況をさらに悪化させる要因がもう一つありました。開発当初のエイチエでは内製での開発は基本的には行わず、全て外部に発注するという方針で運営されていました。今でこそDXという言葉とともに内製化の重要性は広く知られていますが、当時はまだ本格的な内製化には踏み切っていませんでした。 その結果として、ソフトウェア開発についていじれるパラメータとしては「発注先をどこにするか」ぐらいしかなく、当時少しずつ流行り始めていたオフショア開発のトライアルとしてオフショア開発をしていました。 当時のエイチエには、納品物であるソースコードの品質を適切に判断できる体制も不足していたため、不安な状況でした。   オンプレ→AWS移行の話が来た 運用開始から数年経ったあたりから、エイチエの開発体制が段々と内製化にシフトし始めていました。 それまで外部に発注していたソースコードも、内部で巻き取りはじめました。その過程で、ボーイスカウトルールの精神で、発見された問題点に少しずつパッチを当てていってはいました。ただ、根本的にどうにかするには全体にばっさり手を入れないとどうにもならないなーと感じ つつも、日々の忙しさの中でなかなかその一歩を踏み出せずにいました。 2018年の8月頃に、そのような状況が変わる機会がありました。エイチエを運用開始した2011年から7年が経過し、世の中はすっかりクラウドファーストになりました。オンプレ環境は持たずにすべてAWSやGCPだけで運用するという構成も一般的になり、珍しくなくなりました。弊社もかなりの台数のサーバをデータセンターに抱えていたので、オンプレの インフラチームは ハードウェア故障や機器増設などの障害時対応で時間外労働をすることも多く、当時は大変だったようです。働き方や時間外労働、また世の中のトレンドなども鑑みて 今後のインフラ構成・運用像を検討した結果、オンプレ環境を全廃して全てAWSに集約するという意思決定がなされました。 このときの要件は、オンプレで動作しているサーバ群をAWSへ移行することだけでした。幸いにもその時の環境は VMWare 上で動いていたため、VMごとAWSに持って行けば移行作業は終わりではありました。 ところで筆者が所属している「ヘルスケア事業部」という部署は、非常に多くの事業やサービスを担当しているのが特徴です。エイチエ以外にも、モダンな環境のサービスも、そこそこの数があります。そのため、 仮にエイチエを現状のVM構成そのままで持っていって稼働することにし たとしても、実は一日中そのレガシーコードだけに向き合うわけではありません。エンジニアのモチベーションという意味では、レガシーコードをいじる時には無の境地でこなし、他の事業やサービスに力を入れるという選択肢も取れなくはありません。 しかしこの話を聞いたときに、「これはリニューアルをするチャンス」だと思いました。幸いにも無停止移行は求められていないため、「一時的にサイトが止まる」というイベントが社内にもユーザさんにも周知されることになります。このタイミングを逃すと、次にリニューアルに着手するチャンスは無い。いや、やろうと思ったらいつでもやれたかもしれないし、今後もできるかもしれません。ただ日々の忙しさの中にいると、何かきっかけが無いとスタートを切るのは心理的に難しいというのが正直な気持ちでした。 今回リニューアルに失敗したとしてもそれを捨ててVMでそのまま移行をすればいいだけなので、最悪の時の逃げは保証されています。一方でリニューアルに成功したときのメリットは大きい。エンジニア間で相談し、「フルスクラッチで書き直す」ことに決めました。   リニューアルのための期間を確保 「現行のシステムへの機能追加・機能改善はそのまま継続しながらも、リニューアル版のシステム開発を行う」ということができれば理想的なのでしょうが、事業部で稼働できる エンジニアは2人しかいませんでした。またその2人も、関わっている事業はこのエイチエだけではなかったため、残念ながら「リニューアル作業中は、現行システムに機能追加をしない」という選択肢をとらざるを得ませんでした。 機能追加が停止になる期間をどう確保しようか悩んでいたのですが、企画担当者や事業責任者と話してみると予想に反してすんなりと受け入れられました。それには、このような背景がありました。 色々な機能がよくわからないことになっていたので、一部はまだオフショアに開発を出していた。リニューアルして全てを内製にするとその費用が削減できるし、開発のリードタイムも短くなる 「ある箇所に広告（あるいは何らかの機能）を出したはずなのに、実は出ていないページが後からから見つかる」ことや、「 ログアウトしていると広告や機能が出ていない」など、作りの問題による機会損失がなくなる 応答速度が改善することによりサイトのPV増や直帰率の低減が期待でき、またHTMLも作り直すためにSEO面での改善も期待できる 当たり前のことが当たり前にできるようになるだけですが、これまでの状態を見てきた企画担当者や事業責任者には、かなり魅力的に見えたのかもしれません。 いろいろと議論した結果、リニューアル期間として半年間の時間を確保することができました。内製開発なのでかかるコストはPL上の内部人件費と、HTMLマークアップの外注費ぐらいです。ちなみにHTMLやCSSのマークアップはわりと時間が取られることが多いので、（LPなどの一枚物ならともかく）一から書くときには外部にお願いしてしまうことがわりと多いです。 全ての問題点が解決された理想のシステムとまでは言えなくても、リニューアル前に比べれば格段に良くなるはず。リニューアルの勝算は大いにありました。仮にリニューアルの開発の進捗が悪かったとしても、既存環境のVMをそのまま移行して稼働すればいいだけです。その場合でもOSのサポート期限が2020年11月あたりに来るのでそれまでにはどうにかしないといけなかったですが、まぁどうにかなるだろう、とわりと楽観的に考えていました。   こんな感じで進めていった 個人的にリニューアルプロジェクトの最大のアンチパターンだと思っている「良くわからないから、全ての機能を移行しましょう」をいかに避けるかというのが、成否のキモだと思っていました。 まずは機能ごとの利用数を把握するために、Google Analytics や Apache などのログとのにらめっこを始めました。幸いエイチエはコミュニティサイトなので、ユーザの生の声は掲示板の書き込みを見ていれば把握することができます。   1) 現行システムから機能を削って、様子を見る リニューアルの対象となる機能を減らすために、アクセスログなどを参考にして、明らかに使われていない機能や、そもそも正常に動いていない機能を少しずつ画面から削除して見えなくしました。ユーザの反応を掲示板で確認し、特に問題無さそうであればもうその機能のことは忘れて、他の機能へ取りかかります。 当時のエイチエには、当時流行った「一定のポイントがたまったら、何かいいものに交換できる」というポイント機能もありました。確かクオカードに交換できるようになっていたため、定期的にクオカードの棚卸しや追加発注などをしている様子を見たことがあります。その運用の負荷もそれなりにあったようで、無くすということで企画担当者とすぐに合意でき、ユーザに告知の上でリニューアル前に廃止をすることができました。廃止理由が交換のための出費を減らしたいとか、今あるポイントが使われる前に廃止してしまいたいというような後ろ向きかつ不誠実なことではなかったので、「告知から廃止まで、かなり長めの期間を取ろうね」と企画担当者と話したことを記憶しています。 幸いなことに機能廃止に関するネガティブな反応はほぼ0でした。実は使ってたんだという機能をリニューアルのタイミングで廃止してしまうと不満もあがりますし、追加開発の優先順位が狂ってしまいます。仕事の優先順位や取捨選択を他人の手に委ねると仕事に追いまくられるようなことになってしまうので、「現行システムの時点で機能を削減していく」というやり方は、なかなかうまくいったなと感じています。   2) あるべき動作で仕様を定義 持って行くと決めた機能は覚悟を決めてリバースエンジニアリングをしていきましたが、実装の謎の依存関係や動作をほどくだけで、リリース予定日が過ぎてしまいそうな感じでした。 仕様の現状把握をしようにも、今となってはなぜそういう仕様/動作/実装になっているかまったくわからず、また合理的とは思えない仕様だったところも多かったので、多くの箇所で「この機能のあるべき動作」を定義して、それに寄せていくようにしました。 たぶん後付けで機能追加されたからだと思うのですが、サイトに質問を投稿をするときに、PCには無くてSPには存在する入力項目があったり、あるいは片方には確認処理があるけどもう一方には無いみたいなことが普通に発生していました。多くの場合、PCとSPのどちらの動作があるべきなのかは自明だったのですが、どちらが正しいのか判断が難しいような箇所は、関係者一同でえいやで定義したところも少なからずありました。 あまり使われていない機能ではあったんですが、一部に Flash とかを使っているところもあったんですよねえ。IEを使っているユーザさんも多かったので全く機能が使えないということはなかったんでしょうが、それを発見したときには「Flashかぁ。。。」と感じたことを思い出しました。   3) 実装が重そうな機能は二次開発へ いらないと思われる機能のリストラが終わった後には、機能の優先順位付けをしました。使われてはいるけど利用者が少なくて、かつ実装やデータの変換・移行にちょっとだけ時間がかかる機能をピックアップし、二次開発に回すことに決めました。その中でも大きな機能の一つは「献立レポ」という、献立の画像を投稿できる機能でした。 栄養士・管理栄養士は料理の写真を見れば、よっぽど特殊なものでなければ作り方はすぐにわかるそうです。そのため普通のレシピ投稿サイトとは異なり、必要となる情報は使っている素材の種類だけで、レシピそのものはあまり必要とされません。季節やイベント時の献立をどうしようか、そのネタを探すのにいつも悩んでいるそうです。 ただ、社内の管理栄養士さんに確認してもネタ帳的に使うのが目的のため、その料理が何なのかがわかるだけで充分らしいのですが、当時のエイチエの献立レポの写真は、みなさん手持ちのスマホかなにかでフラッシュなしで撮影しているらしく、あまり美味しそうに見えないのが気になっていました。 以前どこかのサイトで、素人でも料理の写真を美味しそうに撮る方法に関する記事を読んだことがあります。その中に「素人の人が料理写真を撮ると、単なる記録になってしまっていることが多い」という記載がありましたが、まさに記録としての写真になっていました。特に美味しく見える必要は無いとはいえ、ちょっとだけ開発者のこだわりとして、投稿時に簡単なフィルタを通せるなどいくつか機能追加を行うために、 リリースを少しずらさせてもらいました。データ構造も少し複雑だったため、そこをほどくのも少し時間がかかりそうという理由もあるにはありましたが。 また工夫の一つとして、リニューアル後にその機能が無いことについて言及されないよう、リニューアル告知の時点でその機能は後日リリースで追加される旨も記載しました。もちろんそれでも言及されることはあるかもしれないでしょうが、リニューアル後の話題を少しでも、移行した機能が動く・動かない、使いやすい・使いにくいなどの話題に限定できたらなと考えていました。   4) 開発は得意領域で分離して、使えるものは使う 今回は学習期間を取る余裕が無かったので、「プレゼンテーション層（フロント）」「データアクセス・ビジネスロジック層（バックエンド）」で役割を分割し、各エンジニアが慣れている技術を使うと割り切って、各ソースコードをそれぞれ別々な言語で実装しました。 プレゼンテーション層の側は PHP/Laravel で、バックエンド側は Elixir/Absinthe で実装し、間の連携はGraphQLです。 GraphQLを採用した理由は2つあり、一つにはいちいち連携せずにプレゼンテーション層側が必要とするデータを柔軟に追加・変更できるようにするという、RESTじゃなく GraphQLが採用されるど真ん中の理由からです。開発中にお互いの実装を待つようなことをできる限り減らしたいと思い採用しましたが、狙い通りほとんど待ちが発生することは無く、快適に開発を進めていくことが出来ました。 GraphQLを採用したもう一つの理由は、栄養士の求人募集に関する機能の運用が、別の組織になる可能性が見えていたからでした。それを見越してフロント側は「Q&Aなどのコミュニケーション機能」と「栄養士の求人機能」とでソースコードをわけて実装されています。さすがに現代の日本において複数のソースコードが同一のDBに直接アクセスするようなことは避けたいので、組織間をまたいだ状態でもお互いが自由に開発・運用していけるようにと考えていました。コロナ禍で100%完全リモート環境であっても、お互いにいちいち同期とかを取らなくてもまったく困らずに平行開発できていることを考えると、GraphQLを選択しておいて良かったと感じています。 また、  全文検索はElasitcsearchを使い、質問やコメントなどが投稿された時点でSQS にメッセージをキューイングして、バッチで登録 CircleCIで自動テスト、Sentryでエラー監視、Mackerel でリソースや死活監視 など、特段珍しいものではありませんが、既にあるありものは普通に使うようにしています。   5) 管理画面を無くした 内部にエンジニアが居なかったからでしょうが、リニューアル前のエイチエではSQL一発で簡単に答えが出るようなものを含め、何でもかんでも管理画面に実装されていました。メニューが何階層にも入り組んでいて、やたらと機能が多かったです。 しかしこれは管理画面を使った業務を運用担当者にヒアリングし、都度必要な時点で手動対応することで問題ないことがわかりました。ダッシュボード的なものは Metabase で、ログ集計みたいなものは Amazon Athena, それ以外の定常的には発生しない業務は都度対応することにして、最初は管理画面丸ごと捨てることにしました。これでかなりの実装工数の削減になりました。 管理画面にあった機能は必要になった時点で作っていこうと思っていました。ただリリースから一年以上経過した現在でも、結局必要としたのはユーザや質問の検索と削除ぐらいだったため、非常に簡易的な管理機能を用意しただけで運用できています。   もうツラクナイ その後リリース日を迎え、リニューアルしたサイトがリリースされました。特に何事も無く無事にリニューアルに成功しました・・・と言えればハッピーエンドではあるのですが、デザインが大幅に変わったことで、リリース当初は悪い意味でのかなりの反響がありました。 幸い目立ったバグもなかったため、特にネガティブに受け止められている箇所を集中的に、何度も修正を行いました。半月ぐらいかかりましたが、その後はなんとか落ち着いてホッとしました。 リニューアル後はアクセス数やサイト利用者数もリニューアル後から有意に増えました。開発のリードタイムも拡張性も大幅アップしています。自分たちが作ったものなので、全体から細部まで把握しています。逆に言うと、言い訳ができないといえるのかもしれません。実施した施策がうまくいかないこともありますが、施策の試行錯誤や、場合によっては元に戻すようなこともストレス無くできるようになったので、関係者一同の喜びの総量は確実に増えたんじゃないかと思います。    エス・エム・エスでアーキテクトとして働くこと 話題は変わりますが、エス・エム・エスという会社は昔からワークライフバランスを大切にしてきた会社です。2010年頃は確か20:30完全退社で、現在では19:30完全退社（※現在エンジニア等一部職種はフレックス(コアタイム12：00～16：00)の勤務体系で、19:30完全退社の対象ではありません）となっています。この「完全退社」は単なるお題目ではなく、実際にオフィスから人がいなくなります。自分自身は「ワークライフバランスなにそれ？」という零細企業から転職してきたため、最初にその話を聞いたときは綺麗事だけでまったくの嘘だと思っていました。それが本当だと知って、とても驚いた記憶があります。 限られた時間の中で成果を出すには、いかに「今やることを減らす」「将来やることが増えないようにする」かがポイントになると思っています。今回のリニューアル作業であれば機能を事前に枝刈りして、いらないものは作らない。作るにしても作りすぎない。作らなければメンテナンスもいりませんし、壊れることもありません。もちろん作らないことそのものが目的では無いので、作ることを過剰に回避した結果として複雑なピタゴラ装置みたいな構造になってしまうぐらいなら、作る手間を惜しむことはありませんが。 事業部門に所属していると特にそう感じますが、事業会社は事業を前に進めることが目的です。（法令遵守とかルールを守った上であれば）その手段は問われません。実現困難なことを実現できてもあまり関係なく、逆に言うとどんなに少ない工数で楽々と実現しようと問題ありません。また、労働時間を増やして回そうという発想がそもそもありません。転職してしばらくは「もっと残業したい」といつも思っていました。いかに、頑張らずに回り続ける体制やシステムをつくるのかが重要だと思っています。何なら平常時はいつも暇でもいいとさえ思っています。   こういう人がエス・エム・エスにはマッチしそう 「課題解決」に興味がある人に来て欲しいと思います。課題が死ぬほどあります。事業をいかに拡大させていくかという未来の話もありますし、足下での事業運用の効率をいかに上げていくか。あるいは業務プロセスを改善するにあたり、ビジネスロジックのドキュメント化などの既にある物を可視化する仕組み作りとか。業務改善やデータ分析など、人がいればもっとできるということがたくさんあります。 色々なフェーズの事業があるので、0→1, 1→10, 10→100の経験をすることもできます。ソースコード・技術選択・運用設計など、上流でいい加減なことをやると、あとで自分の首が絞まる経験を実体験として積むことができます。自分事じゃないと本当の意味では腹落ちしませんし、理解も難しいです（ アーキテクトを目指すエンジニアの最短ルート - SMS Tech Blog を読んでみると、理解がより進みます）。 手でコードを書く以外の方法で問題解決をはかり、物事を前に進めていくことが好きだったり得意な人も向いているのではないでしょうか。Excelの組み合わせで業務プロセスを作るということは普通にやりますし、作らずにあるいはシステム間を繋ぐ程度の開発やカスタマイズでどうにかなったら「勝った」と感じるぐらいです（正確にはExcelでやりきろうとすると業務が散らかるので、最初はExcelにせよ、その後に業務整理してkintoneに置き換えることが多いです）。 一方で、メッセンジャーや指示待ちの人は向いてなさそうです。みんなたくさんのタスクを持っているので、依頼や進捗確認など、自分が積極的に動いていく必要があります。事業の課題ぐらいまでは出てきますが、その要件を誰かが固めてくれるわけではないので、そこからまとめあげて解決策に落とし込める人がマッチするのでは無いでしょうか。   我々は常に人手不足です。少しでも事業会社でエンジニアとして働くことに興味を持ったら、お気軽にご連絡ください。カジュアル面談も大歓迎です。コロナ禍で全てがリモートになってますので、お互い、よりカジュアルにお話できるかと思います。  

2020年、エス・エム・エスでもリモートワークの状況下で入社・転職する人がこれまでにないくらい増えました。そうすると、「入社時も入社後も社員に会えていない」「実際に顔を合わせることなく仕事を進める」といった経験も増えます。 新しい環境へと身を投じるのは、 少なからず 不安や戸惑い が伴います。それが 最初からリモートでの移行 となれば、さらに不安や戸惑いは大きくなるはずです。 しかし、そのような状況下でも、既存メンバーとコミュニケーションを取り、業務をスムーズに行わなければなりません。エス・エム・エスでは、新たに入社したメンバーへのオンボーディングとして、リモートでの「 チーム体験ツアー 」をはじめました。 このオンボーディングプログラムでは、単に社内のチームを「体験」することだけに止まらず、新メンバーはチームに溶け込み 突発的なプロジェクトにも対応しました 。結果、新しいメンバーは、エス・エム・エスで素早く立ち上がりました。本記事では、「チーム体験ツアー」の具体的な内容とその効果について詳しくレポートします。 2ヶ月かけて8チームに所属し、開発現場を体験 「チーム体験ツアー」に参加したのは、「 カイポケ 」のアーキテクトとして新たに入社した三浦さん。カイポケは、介護事業者向けの経営支援ソフトで、請求・経理・営業・開業支援など様々な機能を搭載。機能ごとにチームが存在し、三浦さんはカイポケのサービス全体のアーキテクチャを考える役割を担います。 リモートワーク下では、所属チーム以外の人と顔を合わせる機会が圧倒的に少なくなりました。特に全体の仕事を見渡す必要があるロールの場合は、コミュニケーションの機会を設ける必要があります。それぞれのチームに どんなメンバーがいるのか 、 どのような仕事の進め方をしているのか などを知ってもらうことが、この体験ツアーの狙いです。 また、新たに入社した三浦さんも新環境にワクワクする一方で不安も抱えていたそう。 三浦「実際に人と顔を合わせる機会がない状態で入社したため、どんなメンバーがいるのか気になっていました。また、これまでの仕事では一つのプロダクトに数多くの開発チームがいることがなく、カイポケの全体を把握することに対しても若干の不安がありました」 上記の課題を解決するために、チーム体験ツアーでは以下の取り組みを行いました。 1週間ごとにカイポケの各チームに参加。2ヶ月かけて8つのチームを体験。 チームの定例会、スタンドアップミーティング、朝会、各MTGへの参加 モブプロ、ペアプロに参加し開発の現場を経験 この取り組みに対しては既存メンバーも積極的で、体験する人にとってどうしたら良い体験が提供できるかそれぞれが真剣に考えていました。 チーム体験の受け入れ時のSlackの会話 コミュニケーション量が多く、ボトムアップで業務を遂行 実は、この体験ツアー企画は人事部からの提案ではなく、開発チームからのアイデア。今回の企画に限らず、エス・エム・エスでは、 自分たちが快適に仕事をするため にやってみたいことを 提案し、実現する文化 があります。 元々、エス・エム・エスには、中途で入社してきた人を温かく迎え入れる社風がありました。今回、リモートワークへと働き方が変わり、「どうしたら新しいメンバーを受け入れられるか？」を開発チームが考えた結果、体験ツアー企画が生まれました。他のメンバーもツアー実施前から良い反応があり、積極的に協力していました。 チーム体験受け入れの予定を知らせるSlack。その週に開催されるミーティングの予定が知らされ、三浦さんは任意で出席可能だった 実際に、体験ツアー企画を経験した三浦さんはどう感じたのか。本人にも話を聞いてみました。 三浦「リモートでの入社ということで漠然とした不安はありましたが、面接でも入社前後の対応でも、 丁寧にコミュニケーション を取っていただいたことが印象的です。内定後にSlackに入ったことで、これまでの仕事の流れが把握でき、 受け入れ体制への安心感 がありました。 また、私はこれまでにきちんとした研修を受けたことがなかったのですが、エス・エム・エスでは2ヶ月も時間をかけてチームを知る取り組みを行うなど、 会社の土台が安定している と感じました。」 三浦さんは、 人を知ることと開発の状況を知ること の2点を明確に意識して、参加したそうです。メンバーとコミュニケーションを取る際は、 プログラマー風林火山 の記事を参考にメンバーを風林火山に当てはめ、方々を理解するよう努めたといいます。 開発現場ではトラブルや障害はつきものですが、問題に直面したときにどう対応するか、人によって特徴やクセがあります。ミーティングや定例会で話を聞いたり、モブプロに参加しながら、それぞれのメンバーへの理解を深めていきました。 三浦「体験ツアーが終わった直後に障害が起こったのですが、いざ一緒に業務を遂行することになった時も仕事はスムーズに進行しました。私がこれまでに関わったメンバーの9割はオンラインのみでの対面ですが、チーム体験ツアーのおかげでスムーズに業務を行えています」 受け入れる側のメンバーも、「チームが日頃関わっている仕事を三浦さんがある程度把握できていたので、障害の原因調査時は、提案や質問などコミュニケーションが取りやすかったです。三浦さんの仕事に対する真摯な姿勢やパワーを感じることができました」とコメント。「チーム体験ツアー」を実施したことで、チームの普段の作業内容やお互いの情報を共有したことで仕事がスムーズだったと感じたそうです。 今後もチームにとって必要なコミュニケーション機会を提供 エス・エム・エスはチームごとの裁量が大きいため、カルチャーもさまざま。三浦さんは新しいチームに行くと他チームの様子を聞かれることが多かったそうです。チーム横断の動きが活発になると、新しい視点での開発が進みメンバーのマインドも成長するなど、プラスの影響が期待できます。 今回は全体を見渡すロールの新メンバーのための企画でしたが、今後も新たに入社してくる人たちにとって、必要なコミュニケーションの機会を提供していく予定です。

初めまして。エス・エム・エスでサーバーサイドエンジニアとして働く茂木です。2020年10月に入社したためまだ社歴は浅いですが、だからこそ、この記事をご覧の皆さんに近い目線で、社風や業務内容についてお伝えできると思います。 この記事では、私がエス・エム・エスに転職を決めた理由や、現在関わる仕事、社員の人たちとのコミュニケーションを通して入社前後に感じたことについて綴っていきます。 「エス・エム・エスはどんな会社なんだろう」 「会社の雰囲気は自分に合っているだろうか」 「具体的な仕事内容や、職場環境について知りたい」 こういった疑問に少しでもお答えできれば幸いです。 新型コロナウイルスの猛威を前に、エンジニアとして社会のためにできることはないかと考えた 新卒でエンジニアとしてのキャリアをスタートしてから、「新しい技術を学び、それを活かして開発をしたい」という思いを胸に働いてきました。新卒で入社した会社でPL/SQLを使った業務システム開発に携わり、その後、1回目の転職をきっかけに消費者向けサービスのサーバーサイド開発を経験しました。 ポイントサービス、飲食店検索サービス、フリマアプリのシステム開発など、どちらかというとエンターテインメント性の強い領域で働いてきました。 これらの仕事も人々の生活を豊かにする点では非常に重要です。しかし、日本には医療や介護をはじめ多くの社会問題が存在します。これらニュースを目にするにつれて、もっと社会貢献を実感できるような、社会にプラスの変化をもたらす仕事ができないかと考えるようになりました。年を重ねるにつれ 「何を学ぶか」から「何を作るか」 に意識がシフトするようになったんです。 ただ、その時点では転職するなど一歩踏み出すには至っていませんでした。変化のきっかけは新型コロナウイルスです。パンデミックによる負担が大きい医療業界などに対して、「 エンジニアとして、自分にもできることはないだろうか 」と強く考えるようになりました。 医療業界のなかでエンジニアとして転職先を考え始めてから、決めるまでには、あまり迷うことはなかったと思います。医療に特化している会社は数多くありますが、エス・エム・エスはテクノロジーを活かして医療・介護の領域で多くのプロダクトを展開しており、エンジニアとして関わることで生み出せる可能性が大きい印象を受けたからです。 入社して感じた、エンジニアの可能性を発揮しやすい開発組織 エス・エム・エスに入社する前は事業ドメインへの関心が強かったのですが、実際入社してみてエンジニアにとって非常に働きやすい組織だと感じています。 エス・エム・エスは複数の事業を展開しており、それぞれの事業の中に複数のチームがあるのですが、自分の意図を組んでもらった上で配属が決まります。「あなたはこの部署で働いてください」と一方的に指示されるのではなく、入社前からコミュニケーションを重ね、「どこのチームで働きたいか」と聞いてもらい、こちらの要望を伝えた上で最適なチームに配属されます。 私は求人サイトのWantedly経由で採用が進んだのですが、丁寧なコミュニケーションが印象的に残っています。エス・エム・エスでは、プロダクトによって使用するプログラミング言語が異なったりするので、配属先を決める際はそれぞれのプロダクトの説明を詳しく受けました。自分の経験を鑑みつつ、配属の希望を伝え、時間をかけてすり合わせを行います。 面接以外にもカジュアルな場を設けてもらい、1時間ほど時間をかけてじっくり話をするなど会社について詳しく知ることができていたので、入社後にも事前の印象とのギャップや認識のズレはほとんどありませんでした。 エンジニアとして自分のスキルセットや関心に合わせて配属を決められる点は非常に魅力的です。さらに、自分が他の経験をしたいと考えた際に、社内で経験可能なフィールドが広がっている点も魅力だと思います。 例えば、配属チームに関しては、入社後も希望ベースで異動が可能です。転職することなく、同じ会社の違う領域のプロダクト開発に挑戦可能な点は非常に魅力です。 私はエス・エム・エスに入社して2ヶ月半でいくつかのリリースを経験し、現在は介護事業者向けクラウドサービス「 カイポケ 」のマイクロサービス化プロジェクトに従事しています。 カイポケは約40のサービス・機能を提供しており、私が携わるマイクロサービス化プロジェクトでは、一部の機能をマイクロサービス化するための開発を担っています。 介護事業者の経営・業務の効率化や働き方改革をサポートする クラウドサービス「 カイポケ 」 介護の現場ではサービスごとに単価が設定されていており、請求時に合算する必要があります。また、書類作りも自動化されていないことが多く、「 カイポケ 」を使うことでこれらの煩雑な作業を自動化できるようにしています。「この機能を使っていただけたら、少しでも現場で働く方々の負担を下げることができる」と考えて開発できることは、エンジニアとして大きなやりがいです。 ドメインが複雑であることがおもしろい エンジニアにとって働きやすい開発組織となっているだけでなく、もともと自分が転職する理由となった医療業界に対するコミットもできていると感じます。医療・介護の現場で働くスタッフの仕事に合わせてソフトウェアを開発するのは日々様々な学びがあります。 医療・介護領域は、過去に開発していたプロダクトよりドメインが複雑です。介護は3年ごとに法改正があるため、ドメインに対する継続的な勉強と知識獲得が欠かせません。昔は技術的なプログラミング言語に対する勉強時間が中心でしたが、いまは業界知識を勉強する時間も確保するようになりました。 また、部署をまたいだコミュニケーションも積極的に行われています。例えば、エンジニアがビジネスサイドのメンバーに質問したり、業界知識に詳しいドメインエキスパートが最新情報をキャッチアップし、チームへの共有のためのMTGを設けるなど。 この会社では、どのロールの方も医療・介護の領域への情熱と、自社プロダクトに対する熱い想いを持っていると感じています。全体的に協力しあう姿勢があり、同じ目標に向かっていけている実感があります。 「何を作るか」 を重視して転職した結果、自らの学びも充実したと実感しています。今後は、エンジニアとして技術とドメイン知識の両面を身に着けてスキルアップしていきたいと考えています。プロダクトを開発する際は、プログラミング言語を明確な理由を持って選定していくことが求められます。 技術に対する深い理解はもちろんのこと、医療・介護業界の最新動向を知り、お客様や社会のニーズを汲み取った上で、適切な技術を選定しプロダクト設計・開発をすることが目標です。そうすることで、社内でも信頼されるエンジニアになれると信じています。

高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている前田隼輔です。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つ目は、すでに運用されているサービスが硬直化していないこと。多くの場合、リリースしてから順調に拡大し、収益もそれなりに上がっているサービスは、変更しないことが優先され変化することに保守的になります。システムを硬直化していくことを良しとしない文化を持つ企業に行くことは継続性のアーキテクトが価値を発揮する大事なポイントです。 こうした条件を兼ね備えた環境であれば、ビジネスの変化に応じてソフトウェアが変化し続けていくことが価値を持ちやすいため、継続性のアーキテクトという働き方が実現できると考えています。 筆者の所属しているエス・エム・エスではここに書いたような視点で、アーキテクトという仕事を位置づけています。待遇もふくめてアーキテクトがキャリアのゴールになるような会社にしているので、関心のある方はぜひスライドも見てみてください。 アーキテクト人材のキャリアの考え方から、エス・エム・エスでのアーキテクトとしての機会や環境について紹介しています。 少しでも気になったら、軽く話してみるだけでも結構ですので、下記リンクからご連絡ください。お待ちしています。