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