はじめに
はじめまして。ヘルスケア事業部にて開発を担当している今村と申します。
私は、金融系のSIerからエス・エム・エスに転職し、介護職向け求人情報サービス「カイゴジョブ」、看護師向け求人情報サービス「ナース専科求人ナビ」、管理栄養士・栄養士向けコミュニティ「エイチエ」、遠隔指導特定保健指導サービス「遠隔チャット指導」などの事業を担当してきました。転職して10年以上経過していますから、この会社ではかなりの古株ということになります。
エス・エム・エスでは様々な事業を展開しているため、その事業のフェーズやとりまく環境に応じてとりうる戦略が違っていて、必ずしもプロダクトの価値だけが事業の成功要因ではないこともあります。具体的には、プロダクトは競合と横並びだけど、オペレーションによって競合より優位性を獲得するようなケースです。
例えば弊社が事業の柱の1つにすえている医療介護向けのキャリア事業では、プロダクト = 人材紹介の登録サイトですが、そこで担っているのは主に集客です。しかし、人材紹介の売上は「紹介手数料」をもらうことで成り立っているため、集客したユーザーのニーズを汲み取って適切な転職先をご提案する「後工程」も集客と同じかそれ以上に重要となります。特に医療分野は、どの企業も集客には力を入れています。その場合、プロダクトによる差別化の余地は少なくなるので、オペレーションによって求職者と顧客の双方がハッピーになるようマッチングしていくことが成功の鍵となります。
このため、エス・エム・エスのエンジニアは、プロダクトの改善に関わるのみならずオペレーションの改善に関与する機会も多くなります。そして私の経験上、オペレーションの改善には、技術力より要件定義や業務分析力に強みを持っている方のほうが、力を発揮しやすいと考えるようになりました。
今回はその点について掘り下げてお話したいと思います。
事業の成長とともに起こったこと
どのような事業でも、事業開始当初の段階でオペレーションが固まっていて、成長の段階に達しても同じオペレーションを維持していられることはまず無いと思います。
実際に事業を始めてから見えてくることが多いというのもあるし、そのオペレーションを行う人材を事業成長のスピードにあわせて増員することが難しく、その代わりとしてオペレーションの効率化が求められるからというのもあるでしょう。そういった諸般の事情により、オペレーションは常に流動的かつ改善が求められ続けるものと言って良いと思います。
弊社においては、私が入社した当初この改善はプロダクトの中に作られた管理システム、あるいはExcel上で行われていました。管理システムについては、プロダクト開発の合間に浮いた工数でエンジニアが改善したり、ExcelについてはVBAや関数に秀でた現場の担当者が居て、その人が中心となって改善が行われていました。
しかし、そういったアプローチによるオペレーション改善は、事業の変化についていけたとはお世辞にも言えないものでした。
管理システムについては、改善の優先度がプロダクトの改善より低いことが常でしたし、Excelに関しては担当者のスキル依存であり、仮に素晴らしいものが出来上がったとしても、次の担当者に同様のスキルが無ければメンテできなかったからです。一部は、VBAのスキルをたまたま備えていたプロダクト開発のエンジニアが巻き取ったなんてこともあったほどです。
SaaSを使ったオペレーションのはじまり
弊社では、期初に事業部ごとの「戦略」を作りグループへの浸透を図ります。その際にもオペレーションの高度化や効率化は必要と謳われていました。
そのような背景があり、弊社では徐々にExcel運用や管理システムを捨てて、SalesforceやkintoneなどのSaaSを使うようになっていきました。その結果、導入当初は現場の改善が進んで盛り上がることになりました。
しかし数年経つと、上記のSaaSの活用もシステムの様々な制約に直面するようになり、停滞したりトラブルを抱えるようになってきました。アプリケーションが乱立し、データ間の依存関係もよく分からず、さらに1アプリにフィールドを詰め込みすぎてシステムが定めていた上限に達しそうなものさえあったと聞いています。
今でこそローコードやノーコードと言ったキーワードとともに「エンジニア要らずのDX改善」などともてはやされているSalesforceやkintoneですが、いずれも提供してくれるのは「コードを書かなくて良い環境」のみです。しかし考えてみると、開発において「コードを書く」フェーズは全体のプロセスの中のごく僅かに過ぎません。その手前の、要件を洗い出して設計に落とし込むという作業は残り続けます。それをエンジニア抜きで進めていたわけですから、やはりどこかで限界が来るのは必然と言えるしょう。
こうした反省もあって、エス・エム・エスではSalesforceやkintoneを使ったオペレーションにおいても、エンジニアが参画するようになりました。まだまだ事業によって濃淡はあるものの、弊社のオペレーションの改善においては、エンジニアも一丸となって改善に取り組むのが当たり前となりつつあります。
エンジニアとオペレーション改善
私が所属するヘルスケア事業部でも、事業のスタートこそExcel運用が多かったものの、徐々にkintoneへの移行を進めています。kintoneのアプリを作成する際には、エンジニアが必ず要求を出す段階から関与し、kintoneを含んだ業務フロー全体の流れも把握し、他のアプリやデータと整合するようコントロールしています。実はkintoneの導入が決まった当初は、エンジニア抜きで利用を進めるという案もあったのですが、他の事業での失敗の経緯を説明してエンジニアも参画することになったのです。
kintoneを担当するようになってからは、長期的な視点でのデータの設計、安全なアプリケーションの連携方法の模索、kintoneの標準機能で賄えない部分を内製するかサードパーティのプラグインで対応するかの検討など、考えることが多岐にわたると実感できるようになり、もしエンジニア無しにスタートしていたら1、2年という早いスパンで業務が破綻していただろうと思うようになりました。
ただこういった業務は、プロダクトの開発と比べるとなかなか地味です。どちらかというと、要件のヒアリングや設計に重きを置くからです。自分で手を動かしてコードを書くことが必ずしも正解ではなく、場合によっては「作らない」という判断こそが求められます。
一方、不特定多数のユーザーがターゲットとなるプロダクトと違い、価値の提供先は社内になるわけですから、より具体的な課題を聞くことができます。このため要件定義や業務分析をうまく行い、kintone上でオペレーション改善につながる仕組みを提供すれば、それだけで業績に大きく跳ね返ることもあります。
一例を挙げますと、とある架電にまつわるオプションサービスの運用業務を、Excelからkintoneに移行する小さなプロジェクトが事業に大きく貢献したことがあります。
私が担当したそのプロジェクトは、単に移行するだけでなくオペレーションも効率化したいという要望がありました。そこで細かく要件のヒアリングを行い、誤入力や入力漏れが無いよう制御し、状態管理もひと目で行えるよう作り込んだうえでkintoneアプリケーションを提供しました。結果、そのオプション商品による架電効率が向上してKGIが大きく伸び、オプションサービスの販売数増に繋がりました。しかもこのオプションサービスは、メインのサービスの重要指標を改善するためのものであったことから、メインのサービスの契約継続や受注にも良い影響を及ぼしたのです。
これは特に効果が高かった事例ですが、他にも日々このようにオペレーションの改善に関与し続けていると、少人数の組織体制でも多くの業務を捌けるようになる利点もあります。その結果として、受注が増えても業務のキャパシティが溢れてしまうリスクを減らせるので、安心して事業を伸ばしていけるという側面もあるだろうと考えています。
多様な事業、多様なエンジニアニーズ
昨今、事業会社のエンジニアに求められるスキルといえば、特定のプログラミング言語やフレームワークをうまく扱うためのものだったり、AWSなどのインフラを柔軟かつ安全に構築するためのものだったり、技術力に重きを置いていることが多いと感じます。それはおそらくプロダクトの改善こそが、その事業の成長にとって不可欠だからでしょう。「プログラミングのスキルを身に着けて、SIerから事業会社に転職しました」というような話も聞きます。
しかし弊社のように、多くの事業を抱え、事業フェーズやとりまく環境がそれぞれ異なる状況においては、プロダクトの開発に力を発揮するエンジニアだけではその成長を支えられないこともあります。
すでに述べた通り、必ずしもプロダクトの優位性だけが事業の競争力の源泉とは言えないからです。
そのため、SIerで培った経験や能力を存分に発揮しつつこれから技術力を高めていきたいエンジニアや、技術力の向上よりも事業の成長に貢献することに関心のあるエンジニアなど、様々なバックグラウンドを抱えている方々に活躍する場を提供できるのが弊社の強みではないかと考えています。
もし事業会社のエンジニアとしてのキャリアに関心があれば、現時点でのスキルの過不足は考えずに、一度弊社のカジュアル面談をご検討いただければと思います。あなたの今のスキルや経験を必要としている事業が、見つかるかもしれません。
