左：エンジニア 藤田　右：取締役CTO 畠中

取締役CTO 畠中 翔一

学生時代からインフラの構築やWebアプリの立ち上げを多数こなす。2020年11月に株式会社メディカルフォースを設立し、現在のmedicalforceをフルスクラッチで開発する。開発の傍ら、深層学習を用いた研究が国際学会に採択されるなど、機械学習(AI)や最先端の技術にも精通する。

エンジニア 藤田 瞭

中学からプログラミングを始め、高校時には日本情報オリンピックの本選にも出場。その後東京大学数学科に入学し、大学院では対称性の研究をするも、研究があわず中退を決意。その後、メディカルフォースにジョイン。現在はエンジニアとして主にバックエンドの開発などに取り組んでいる。

『medicalforce』とは？

美容クリニック・自由診療の現場業務を１つのシステムで管理・連携を可能としたオールインワンSaaS。予約・問診・カルテ・会計をはじめとする日常業務から、経営管理ダッシュボードやCRM（リマインド・ステップ配信）を搭載することで、経営や集客強化にも活用してもらえるシステムを提供しています。業務の円滑化だけをゴールとせず、クリニックの経営促進に寄り添うサポートまでを担うサービス提供を目指しています。

本日はメディカルフォースで働くエンジニアお二人のインタビュー企画。CTOの畠中さんとバックエンド開発を担当する藤田さんへお話を伺いました。エンジニアから見たメディカルフォースの強み、エンジニアチームが考える開発方針や一緒に働きたい人物像などいろいろ聞いてみました！

ーーお二人はどのような立場で開発に取り組んでいらっしゃいますか？

畠中：僕は、CTOとして当然開発や仕様に対して責任を持っています。開発していくものの管理とか、何をどういう形で、どんなスケジュールで進めていくのかだったりを見つつ、あとは長期的な目線でチームとしてどういう方向に向かっていくべきなのかを考えながら、中長期的なものに落とし込んで考えています。他には開発体験の向上、バックエンドのレビュー、採用計画の策定だったりと多岐に渡ります。

藤田：僕は、主にバックエンド開発を担当していて、開発体験の向上、サービスのパフォーマンスチューニング・監視・テストの仕組み化などを担当しています。

ーーエンジニアチームの開発体制や役割分担などがあれば教えてください。

藤田：現在はバックエンド3名、フロントエンド3名の合計6名でチームを構成しています。役割分担でいうとプロダクトのドメイン知識やメンバーの意向、適正を鑑みてタスクのアサインを調整していますね。ゴリゴリにコードを書いていくタスクなのか、それとも仕様を理解してユーザーが使いやすいように作っていくタスクなのかによって求められることが変わってきますので。とはいえ、コードやドメインの知識が属人化しないように全員がフロントもバックも満遍なくできる状態になるようにはしています。

ーープロダクトの開発スタイルで重視していることはありますか？

畠中：先ほど触れられてましたが全員がフロントもバックも理解していることですかね。僕らみたいなスタートアップのプロダクト作りには双方の理解が大事で、お互いにどういった所で困りそうかみたいなのを理解していないとなかなか難しかったりします。

開発組織の面では、顧客目線に立って、機能について議論を行う文化が定着しているかなと思います。例えば顧客はこんな機能を求めている、こういった使い方をするからUI・UXを見直そうなど。こういった議論ができるのは、エンジニアがユーザーインタビューに参加し、ユーザー理解に努めているからだと思います。またプロダクト開発・設計について全員が裁量を持っていて、機能開発はもちろんのこと、リファクタリングや開発環境改善など非機能の開発にもしっかりと時間をとって取り組んでいるのも大きな特徴と言えると思います。

藤田：開発スタイルと言っていいのか分からないですが、コードを難しく書きすぎないというのは意識してますかね。普遍的なものというか一般的な書き方を心がけてます。自分でもすごくいいコードが書けた！と思っても1か月後には全くダメになっていることも多くて（笑）。というのも自分が素晴らしい「作品」を作っても、それが他の人にも書けたりすんなり理解できないと意味がないんですよね。コードを読むのは､周りの開発者や､将来の自分ですし、コードは一度書いたら終わりではなく､ずっと保守を続けないといけないものですから、コードが読みづらいと処理の理解や修正に余計な時間がかかったり、不具合も起きやすくなってしまうのでそれは避けるようには心がけていますね。

コードレビューで言うと、実装したコードは必ず実装者以外の誰かが目を通し、レビューを行っています。形式的ではなくても日常的に実装方法の相談をしたり、「こういう実装で問題ないか？」といったやり取りを頻繁に行えるようなフランクな雰囲気があると思います。

ーーほかのチームとどのような連携を進めているのでしょうか。

畠中：3週間に1回プロダクトのアップデートを行なってるので頻繁にビジネスサイドとも情報連携をしています。出た課題をもとに、また新しい開発を進めるという、スクラムの基本的な流れがしっかりできています。緊急性が高いものに関してはスプリントレビューを待たずにすぐに連携して解決できる課題はダイレクトに解決しています。でもユーザーからの意見や要望をもらっても、必ずしもそれがmedicalforceにとって本当に価値があるものか、というのは別の話だと考えているのでそこはしっかり時間をかけて議論をしていますね。

ーー使用する技術スタックと技術選定の基準がありましたら教えてください。

畠中：開発組織全体でフルサイクルエンジニアを増やしたいのと、誰かが抜けたとしてきちんと回るような組織にしたいので、一つの言語でリリースまでの工数が少なくなるような技術選定を心がけてますね。フロントエンドだけでなくバックエンドもTypeScriptを使ってるのは今どきだなって個人的には感じてます！あとMaterial-UIやReactを選んでる理由は宣言的にUIが書ける、エコシステムが整ってることでよりスピードを上げた開発ができるのが主な理由です。他で言うと、スケールのことも考慮してLambda、Auth0、Amplifyなど自分たちでマネージドしないといけな部分が少ないサービスを主に使うようにしてますね。その一方で長期的な負債にならないようにフルマネージドなサービスをインフラとして使いつつも、IaCのサービスを用いてインフラをコード管理してブラックボックスにはならないようにはしてます。

藤田：基本的にはなんでもトライできるチームなので、メンバーがやりたいことは積極的に取り入れていますが、最近の傾向だと枯れた技術と新しい技術の両方をバランスよく扱っています。例えばNoSQLであれば大きいトラフィックだったり大量のデータを扱うのには優れていますが、システムが複雑になったり大規模になるにつれてRDBMSの方が向いている場面もあったりで、一長一短なんですよね。あと新しい技術はナレッジがまだ溜まっていないこともやっぱりあって、公式サイト以外に信頼が置ける情報がなかったり、以前に同じバグを踏んだ人の情報が見つからなかったりします。そうなると試行錯誤しながらコードを書くことになって結果的にコストが跳ね上がってしまうんですよね。とはいえ同じ技術にこだわって開発し続けることが常にベストというわけではないのでスケールや技術の進化に応じて常に最適なものを追い続けることが大事だと思ってます。

ーー医療系SaaSならではの業界の特徴や、開発の苦労などはあります？

藤田：やはり美容医療の分野になるので、どうしても馴染みがないエンジニアがほとんどなんですよね。顧客の気持ちを理解したり、求めていることの意図を汲んだりするのに時間がかかることだと思います。例えば美容医療だと「特定継続的役務提供」といって一定期間を超える期間にわたって、一定金額を超える金額を支払う契約があります。医療脱毛のコース契約などがイメージしやすいと思います。法律で一定のルールはあるのですが、それでもクリニックによってコースの種類やコースの運用方法が違うことがほとんどで、さらに経理処理なども絡んでくるのでそれらに適応するのに最初はなかなか苦労しましたね。なのでエンジニアがきちんとユーザーを理解したりドメインの知識を得るために、お客様のクリニックに訪問して、実際に使われている現場を見学したり、操作説明に伺ったりして、自分たちが開発したものがどのようにクリニックの現場で使われているのかをイメージできるようにしています。

ーーエンジニアチームの魅力とチームに求める人物像を教えてください。

藤田：やはりSaaSの会社なので自らの手で作り上げたプロダクトを顧客に直接に届けられて、かつメディカルフォースの会社業績に直結しているように感じられるところは面白いと思います。

先ほど畠中さんが言っていたように、一般的なエンジニアは職種が分けられていることが多く、フロントエンドかバックエンドのどちらかに専念することが多いと思いますが、うちではどちらの経験も積めることで、技術理解が深まりエンジニアとしての技術領域を広げることができるので、それは魅力の一つだと思います。あとは新しい技術に対しても積極的に導入する風土があるので、業務を通じて新しいことに触れられるのはエンジニアとしてもメリットが大きいです。

畠中：チームとしてのゴールさえ定まっていれば、色々なやり方や価値観があっていいと思っていて、むしろその多様性がチームの成長に繋がると思っています。自分の強みを理解していて、なおかつその強みに固執しすぎずにチームの課題に柔軟に動ける人が多いんじゃないかなと思います。あとはチームで働くことが楽しめる人がいいです。一人で何かをやることがないわけではないですが、色々な人と協調して働いていくことが多いので、協調性をもって一緒に頑張れる方と働きたいですね！

本日は以上になります。お二人ありがとうございました。

今回はエンジニチームの思想や開発に対する想いを伺いました。

最後まで読んで頂きありがとうございました。

※本文中に掲載されている制度や事例、部署名、役職等の内容は、掲載当時のものです。