大手企業を筆頭に、エンジニア組織の外注依存から内製化にシフトしようとする企業の報道を目にすることが増えてきました。 一方で、実際にエンジニア組織の内製化を進めようとするには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。 実際にケースとしても世の中に少ないことなどもあり、エンジニア組織の内製化に関する方法論について紹介されたコンテンツは少なく、各社が手探りの状態でこの内製化に取り組んでいると思われます。 そこで、まさにこれから内製化という難儀な仕事に向き合う技術組織の責任者の方の一助になればと思い、エス・エム・エスが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周目はテストに強いメンバーをチームに入れて、テストまでをチーム内で行える体制にしています。これで、より技術的負債の解消の速度が上がるはず。 まだ、技術的負債の解消のための環境整備は、現時点では自分のチームだけでしか実装できていません。今後は、この成功体験を横展開し、全社的に広げていきたいなと思っています。

はじめまして。エス・エム・エスでアーキテクトをしている三浦です。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に様々なツールをいれて開発環境を構築し育てていくように、チームや自分が動きやすい環境を作ることも必要です。課題を適切に把握するために、また課題を解決するために必要であればチーム外にも働きかけていく必要があります。それに対して協力を惜しむ人は少ないので、自ら動いていける方には働きやすい環境だと思います。 おわりに 　介護業界は複雑なドメインを有していますが、それを紐解き、システムに落としていく過程は非常にやりがいがあります。そんな複雑なドメインに一緒に立ち向かってくれる仲間を募集しています。エス・エム・エスの仕事に関心がある方は、ぜひこちらのスライドも見てみてください。