こんにちは！加島です。

COO草間（写真・右）とエンジニアの次田（写真・左）にインタビューを行いました。

弊社のCOO・草間と、エンジニア部門のエキスパート・次田による専門性高めの記事になっております。

ぜひご覧ください！

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

＊＊お互いについて

次田さんがMICINに新卒入社したきっかけはなんですか。

次） 以前TECH::CAMPというプログラミングスクールでメンターを務めていたのですが、起業準備中だった草間さんが生徒として参加されて、そこで知り合いました。その後、起業されてすぐに「うちの会社に遊びに来ないか」と誘われ、軽い気持ちで遊びに行ったのですが、そこでCTOの巣籠さんと会い、雷が落ちたような衝撃が走りました。あれは完全に恋のそれでした。スーパーイケてるエンジニアだ、この人と一緒に働きたいと思って、インターンとして関わり始め、気付いたら入社してました。

お互いについてどう思われますか。

草）プログラミングスクールの頃からずっと、次田さんのことを先生だと思っています。「このシステムを使って解きたいビジネス上の課題が何か」「それをどのような仕様で実現するのか」という点からディスカッションできる、頼もしいパートナーですね。

次）草間さんは、ビジネス側の視点だけでなく、開発側の都合や考えも深く理解した上でお話してくださる、お母さんのような存在です。ただ、頭の回転が尋常じゃなく速いので話す度にドキドキしています。

＊＊遠隔診療、新たな医療の実現

遠隔診療アプリ「curon」をどのような思いで作られていますか。

草） 遠隔診療、それ自体が新しい概念なので、日常生活にcuronが浸透するには時間がかかると思っています。それでも、チャットアプリとして不可欠な存在になりつつあるLINEのように、日常生活と切っても切れないような存在になればよいと考えていますね。

日常的に使われるアプリになるために、どのようなユーザー体験を作り上げたいと考えておられますか。

次）陳腐な回答ですが、その時々のユーザーの感じ方に気を遣って、直感的でストレスの無い体験を目指しています。

草）それに加え、先進的でワクワクするようなデザインよりも、安心感のあるUI/UXのテイストに仕上げようとしています。 遠隔診療のインターフェースが遊びに走ってしまうと、ともすると「医療」からかけ離れたものになってしまう恐れがあります。前提としてアプリを使用する患者さんは病気ですから、ホスピタリティの精神を大切にしたいですね。

医療というコンテクスト故に考慮しなければならないことがあるのですね。遠隔診療システムを設計する上での難しさはありますか。

草）curonは患者さんにとっては 単に遠隔診療アプリですが、お医者さんの業務効率化アプリという側面も持ちます。お医者さんの業務は当然複雑であり、コアな機能としては「問診・診察」 、「カルテの管理」，「医薬品/処方箋の配送」といった機能が必要になります。細かい所を見ていくと現状で不足する機能もあり、お医者さんの声を積極的に取り入れて改善しています。

次）とはいえ、全ての要望を実現しようとするのは望ましくありません。細かい機能が乱立し、全体としてまとまりのないサービスになってしまう恐れがあります。そこで、改善要望がある程度溜まってきたら、エンジニアとビジネスサイドを交えてワークショップを行っています。問題を洗い出し、それらをより抽象的なレイヤーで解決できないか議論しています。

＊＊プロダクトの大幅な変更を促進する企業文化

UI/UXに関して、最近大幅なデザインリニューアルがあったそうですが。

草）弊社の強みとして、小さくPDCAを回して機能開発をしていくサイクルと、長期的な視点に立って大きくサービスをリニューアルするサイクルの2つを意識的に分けている点があります。エンジニアチームの技術力がとても高いので、ユーザーからの要望がある程度体系化されれば、それをアプリに反映することは難しくありません。一方で、次田さんが言ったように、そうした小さな機能改善を積み重ねていくと、どうしてもサービス全体としての整合性を保つことが難しく、使いにくい部分が出てきてしまいます。その全体像と細部の「ズレ」を調整し、よりよいサービスにしていくために、大きなサービスのリニューアルを1-2年に1回程度を目安に行っています。その際には、新たな機能開発が一定期間止まってしまうので、ビジネス上の短期的なデメリットはあります。一方で、長期的にみたときには、メンテナンスの容易性があがって、新機能の開発やサービスの改善の速度を上げることができます。今は、そのバランスをうまくとりながら開発を進めているイメージですね。

次）リニューアルの背景については草間さんが仰ったことが全てです。ちなみに今回のリニューアルはアプリに改修を加えるといった形でも実現できたのですが、色々と思うことがあったため、思い切ってアプリを一から作り直すことで実現しました。比較的メジャーではないRxベースのReduxを採用したり、やりたいと言いつつなかなか手が付けられていなかった快適なデバッグ・テスト環境の構築に注力したり等、ゼロからだからこそ快くやれる事柄に妥協せずに取り組みました。結果として、よりテスタブルでメンテナブルに仕上がったと感じていますし、正しい判断だったと思っています。なにより開発していてとてもハッピーでした。

他方、患者用スマホアプリの開発体制をReact Nativeに移行されたのは、どういった経緯だったのでしょうか。

次） 当時AndroidアプリはJavaで、iOSアプリはSwiftで開発していました。しかし Androidの開発人員が不足していたこともあり、その両者を保守するのが苦しくなってきた時期がありました。React Nativeであればクロスプラットフォーム開発が可能で、かつReactの豊かさを享受することができます。また、MICINではお医者さんが使うwebアプリをAngularで書いているので、JS基盤を活かすことにもつながると考えました。

当時はReact Nativeはまだまだ発展途上でしたよね。新しい技術を取り入れることに抵抗はなかったのでしょうか。

次）React Nativeはちょっとしたアプリなら問題ないが、所謂普通のサービスのアプリとしては時期尚早だ、とはよく言われていましたし、僕自身懐疑的でした。ただ、実際にみんなで1週間程度プロトタイピングしてみると、全然イケるやんという結論に至り、他の諸々の開発をストップして移行することとなりました。

リニューアルのために開発をストップすることに対し、ビジネスサイドの反対はなかったのでしょうか。

草） 何が契約獲得のノックアウトファクターになっているのかは弊社全体で度々議論し、機能開発の優先順位を決めています。機能開発が止まることによって、短期的でネガティブなビジネスインパクトと、開発環境の改善による長期的な開発スピードの向上によるメリット。これらを天秤にかけた上で、移行する価値があると、ビジネスサイドとしても理解できました 。話し合いによってエンジニア、ビジネスサイド双方の互いに対する理解が深まり、 互いにやりやすい環境になっていると思います。

次）多くのエンジニアには、レガシーなものを保守するよりは時に新しい技術を積極的に取り入れてクリーンに開発したいという純粋な思いがあると思います。ですがそれだけでなく、実際の事業に際してそれによるメリットは沢山あります。プロダクトの品質に直接影響しますし、今後の開発のスピードにも影響します。新たなエンジニアの心を掴むセールスポイントにもなります。そうした点をちゃんと議論すれば、色々な取り組みを快く受け入れてくれるというのがうちのチームの魅力の一つです。

技術的な挑戦のために行われている取り組みはありますか。

草）MICINでは20Xと称して、エンジニア主導で新しい技術をベースにしてサービスや機能開発を行っていくという取り組みをしています。Googleの10Xが元になっていまして、業務時間の20%の時間を使って今のサービスを20倍よくする、というのが20Xの意味するところです。ちょっとしたサービスの改善を繰り返すだけという停滞に陥るのを避け、抜本的な改革によってサービスをリファインするという目的です。

次）一旦サービスから離れ、技術領域で興味を持っていることを共有し、MICINのサービスに活かせないかを検討します。一ヶ月程度のスパンでテーマを決めて、実際に作るところまでやって評価する。いわばR&Dですね。業務の一環として様々なことにチャレンジできるのはとてもハッピーですね。

草）エンジニアの方は常に自己研鑽を積まれている方が多いと思います。その自己研鑽の場をMICINとしても用意したいですし 、高めたスキルをアウトプットできる場であって欲しい。結果としてMICINの技術力が高められ、遠隔診療を普及するプレイヤーとしての弊社の価値も高まると考えています。