「紙業務が多いデイサービスの現場を効率化しながら、リアルデータを集めてリハビリを科学することで、高齢者の生活をより良くしたい。」——。Rehab for JAPANでは介護の領域にテクノロジーを取り入れ、人々の暮らしを豊かにすることを掲げています。Rehab for JAPANが提供するデイサービスの機能訓練業務を誰でも簡単・安心・効果的に行えるクラウド機能訓練ソフト「リハプラン」。その開発に携わる開発部で部長を務める宇井洋樹に、エンジニア組織のやりがいや課題、今後の展望について聞きました。

ユーザーにより近い場所で仕事がしたくて、Rehab for JAPANを選んだ

Rehab for JAPANに入社する以前の経歴を教えてください。

私はもともとエンジニアではなく、新卒で入社したキャノンマーケティングジャパンでセールスの仕事をしていたんです。

その後、エンジニアにジョブチェンジする形でワークスアプリケーションズに転職しました。当時、ワークスアプリケーションズには私の友人が多く入社していて、自分もそこに入ってみたらおもしろいのではないかという気持ちと、何か新規性のある仕事をしてみたいと思っていたんです。

ワークスアプリケーションズでは給与計算のパッケージソフトの開発や、クラウド、インフラ周りの仕事をしていました。当初は開発者や評価者の環境を保守するチームにいて、その後顧客のクラウド環境を保守するチームに異動。

ユーザーに近いところで仕事をしていると、こちらの利益が必ずしも顧客の利益になるわけではないこと、顧客の要求がこちらのやりたいことと必ず結びつくわけではないことなど、ひと筋縄ではいかない状況が多々起こります。

その中で落としどころを探して問題を解決していかなければならないという、同じエンジニアの仕事でも、それまでやってきた業務とは非連続な部分におもしろさを感じていました。

そういった中、Rehab for JAPANに転職したのは何がきっかけだったのでしょう。

2つあります。1つは、ワークスアプリケーションズ時代の同期がRehab for JAPANにいて、彼に誘われたこと。もう1つは、立ち上げのフェーズにあるようなベンチャーでより大きな裁量を持って仕事をしてみたいという思いです。

リファラルで入社した2年半前は従業員が20名ほどで、ユーザーにより近い場所で仕事ができそうだと思いました。自分が書いたソースコードがすぐに世に出て、それをユーザーが使ってくれるという点にやりがいがありそうだと感じましたね。

サービスを作って問題を解決することこそエンジニアの価値

開発部門全体としてはどういう業務を担っていて、それをどういったプロセスで進めているのでしょうか。

大きく2つあります。1つは、ロードマップにのっとって進める大きな機能の開発。もう1つは、弊社のサービス「リハプラン」にトラブルや不具合があったときに、バグフィックスをすること。

ロードマップにあわせて進める大きな機能の開発は、プロダクトマネージャーらと要件定義のすり合わせをしながら行います。

ざっくりとした要件定義を受け取ってディスカッションをし、そこから開発者が詳細なテストケースを書いていく。その過程で矛盾点が見つかれば、もう一度ディスカッションをして詳細な仕様を決めていきます。そして、設計も含めてソースコードを書いて、結合テストをし、リリースする。そうした一連の工程を開発者が行っています。

「リハプラン」のトラブル対応については、監視ツールで不具合をキャッチするパターンと開発者が自発的に不具合に気づくパターン、それから、ユーザーから問合せや連絡があって気づくパターンと3つあります。

なんらかの方法で不具合に気づいたらすぐに調査をして、それが深刻なエラーであればすぐに修正に入ります。特定条件でしか発生しないエラーの場合は、一旦お客様に回避策を取っていただいて、随時修正に入っていく。そんなふうに、バグフィックスにはいくつかのパターンがあります。

チームでどのように開発を進めていくのか、教えてください。

2021年8月までエンジニアは3名のみでしたが、9月頃から6名増えて、現在は9名で開発に当たっています。全員が1つの機能を開発するのではなく、たとえば4名ずつにわかれて2つの大きな機能の開発を進める、という具合です。

開発をするときには、チームのメンバーには最初にテストを書いてもらうことが多いですね。1枚のチケットに「あるべき姿」を書いてもらって、それをレビューして、実装する。チケットにはコードを書くパターンもあれば、ドキュメントを起こしてふるまいを定義するパターンもあります。そこから2週間1スプリントで開発期間を区切って、イテレーションを回していきます。

その中で、担当者はテストケースを書いて、実装して、プルリクエストを出して、レビューをする。コードがマージされたら世の中に機能がリリースされていく流れです。

開発方針で大切にしていることはなんでしょうか。

エンジニアの仕事は、コードを書いてサービスを作って、誰かの問題を解決すること。私はそう考えています。だから、中途半端なものは出せませんし、スピード感をもってお客様に早く価値を届けたい。そのために、リリースまでのプロセスになるべく開発者のストレスをなくしたいと思っています。

通常、サービスや機能をお客様にリリースするまでには、いろんなプロセスがありますよね。一般的に業務ソフトを開発しているような大きな組織だと、開発期間としてnヶ月あって、評価期間も1ヶ月ほどかかって、最終的にお客様に向けてリリースするのはそこからさらに半年後というケースもあります。

お客様の業務は止められないのでそうしたやり方をするのは仕方ないことですし、ある意味ではそのやり方が正しいと思っています。ですが、私はユーザーに対して早く価値を届けていきたいという思いが強いので、できるだけ面倒なプロセスは省いて、開発者にはノンストレスの環境で開発してほしいと思っています。

現場感覚を大切に、利用者の「困りごと」のヒアリングを怠らない

現在の開発部門にはどんなカルチャーがあると思いますか？

現場感覚を大切にしています。Rehab for JAPANにはデイサービス出身のメンバーが多く、現場の困りごとをリアルに知ることができるんです。もの作りをするにあたって、必ずヒアリングをしていますね。

また、個人的にはサービスをリリースすることにこだわっています。たとえば、11月18日までに出さなければいけない機能群があったとして、どうも一部がその日に間に合いそうにないと。そんなとき、納期までに間に合う機能はその日に出して、残りの機能群はあと2日でリリースします。

全体ができあがるまでリリースを遅らせるのではなく、その日に出せるところまで出して、あとは調整しながら製品をよくしていく。そうしたスピードとクオリティのバランスを取ることを意識していますね。

先ほどの、「ユーザーに早く価値を届ける」という考えにもつながるカルチャーですね。

そうですね。とはいえ、これまで開発部門は3名でずっとやってきたので、カルチャーはこれから作っていく成長段階にあると思っています。

社内全体で見ると、お互いにリスペクトをして協働するという文化があるように感じています。私が入社したとき、CEOの大久保さんがエンジニアをとてもリスペクトしていると言っていて。一方で私も、介護現場に近いCSやセールスに対してものすごくリスペクトしているんです。

そういった文化があるので、サービスを作るにあたってはお互いの目線を皿に乗せ合って、忖度せずに吟味するという雰囲気を感じます。

また、Rehab for JAPANが事業としている介護領域は、法律が複雑です。法解釈をきちんとしなければよくないサービスになってしまいます。一方で、ガチガチにしすぎてもユーザーにとって使いづらい。

こうした法律の解釈をエンジニアだけでやるのは大変です。厚生労働省の何百ページにも及ぶPDFを読み解いて、サービスに関係ある部分を抽出して整理してくれる、そんなメンバーが社内にいることは、ものすごく安心感がありますね。

Rehab for JAPANにはそういった両輪の感覚を持ったメンバーがいて、そこにものを作るエンジニアの立場からの理論的な整合性をミックスすると、よりよいサービスができると思っています。そういう意味で、開発部門だけでなく社内のみんなでサービスを作っている感覚がありますね。

「打席に立つ機会はなくならない」自分で判断し開発を進められる環境で成長できる

そんな中で、開発部門ではいまどんな課題を抱えているのでしょうか。

いま、「リハプラン」から派生した複数のサービスを開発しようとしています。そうなると、今後はシステムとして必要な要件がワンランク上がるだろうと。かつ、これまで連続性のあった開発課題から、何らかのアプリを作りたいといった非連続性のある開発課題が出てきています。

こうした技術的に大きな課題を既存のメンバーで解決しようとすると、スピードとのトレードオフになりかねません。いまこのチームにスペシャリティを持ったメンバーが何人か来てくれたら、もっといい開発ができるんだろうと思っています。

これから入社される方には、そういった課題解決に向けての動きを期待しているのでしょうか。

これから生じるであろう課題もですが、そもそも業務機能を作る人材も足りていません。

エンジニアが3名から9名になりましたが、これから自分たちがやろうとしていることに立ち向かうには、非連続的な技術課題に挑戦をしていかなければいけない。そうなったときに、既存のメンバーだけでは成り立ちません。

具体的には、複数のサービスを連携させる際、トランザクション管理をどうするか、APIの設定をどうするか、これらの課題は現在進行形で進めています。

詳細はお伝えできないのですが、介護現場スタッフが日々対峙している業務をさらに便利にする機能とともに、事業所経営の基幹となるシステムを作っています。

これらすべてに対応しようと思うと、ある程度の人数が必要です。エンジニアを3つくらいのチームにわけ、それぞれの機能の開発をしてリリースすることを想定していますが、そうなるとシステムの結合度を下げる必要があります。疎結合を思考すれば、それによってやるべきことは増える。

これらは一度レールに載せてしまえば動かすのは簡単ですが、何もない状態から作っていかなければいけません。たとえば、現在はWebアプリの開発しかしていないので、スマートデバイスアプリの開発をするとなったらKotlinやReact Nativeといった新しい言語を導入して開発する必要がありますし、そもそもAPIでやり取りするためのルールもない状況なんです。

そういった中で、いま開発部門に参画することでどんな成長機会が得られるでしょうか。

現状、デイサービスはよくてExcel、まだまだ紙業務が多い業種です。複数の紙帳票に二重、三重に同じような情報を転記する運用を強いられている。そのような非効率なことが現場の間接業務を増やしてしまっていると考えていて、よいシステムを導入すれば、お客様がより高齢者の方々に向き合う時間が増えるのではないかと思っています。

もう1つ、会社の理想として、今後デイサービスの業務を通じてデータを収集し、活用したいという思いがあります。これが実現できれば、データをもとに介護現場に対して「この人はこういう運動をすればこれくらいの改善が見られる」といった提案ができるようになります。

そのためには、介護現場の業務を効率化しながら、これまで紙や口頭だった情報をスムーズにデジタルデータに変えていけるようなシステムを作ってリリースしていく必要があります。

まだまだ作りたいものはたくさんありますし、今後はそれなりに開発規模も大きくなるでしょう。ですが、サービスを作る、守るに際しては、小さなチームで自由に動けるようにしていきたいと思っています。

人が増えたからといって打席に立つ機会が減ることはありません。裁量には責任が伴いますが、責任を負った上で自分の判断で開発を進められる人が育つような環境を提供したいですね。

自分は世のため人のためになるいいサービスを作っているんだという感覚を、みんなに持ってもらいたいです。

お互いにリスペクトできる人と一緒に、非連続的な技術課題に挑戦したい

事業が成長していく中で、どんな人と一緒に働きたいと思いますか？

いまのメンバーに見られるような、Rehab for JAPANの事業に共感してサービスを思考できる人、社会性の高いプロダクトを作りたいという人にはもちろん参画していただきたいですね。

ただ、個人的にはもう少し技術的に尖った人がいてもいいと思っています。

先ほど言ったように、開発部門だけでなく社内のいろんな人と対話をしながらサービスを作っていくので、協働する意識の高いメンバーが多くいます。技術的に尖っていたとしても、相手のスペシャリティを理解して、チームで1つのものを作りあげようと思える人であればなおいいですね。

今後は非連続的な技術課題がたくさん出てくるでしょう。そういう意味では、技術的に尖った人がいて、その人が挑戦したいフィールドと私たちのやりたいことがマッチしているのであれば、ぜひ一緒に働きたいですね。

株式会社Rehab for JAPANでは一緒に働く仲間を募集しています
Webアプリケーションエンジニア
リードエンジニア