こんにちは、インテグリティ・ヘルスケア（以下、IH）広報の入山です。

今回は、IHの開発環境についてプロダクト開発部のお2人にインタビューをしました！

現在、IHのエンジニアグループでは新たなメンバーを募集中となります。これを読んで頂いている方々にとって、IHの普段の開発業務について、イメージが膨らむ良い材料となれば幸いです。

はじめに：IHでの開発の概要

インタビューの前に、そもそもIHではどんな開発が行われているのか？について、サラッと概要をご説明させていただきます。

▼何を作っているのか？

IHでは、オンライン診療システム「YaDoc」を開発・提供しています。

YaDocはWebサービスで、

• 患者ユーザー向けに、iOS,Androidのアプリケーション
• 医療従事者（医師・薬剤師など）向けに、ブラウザで動作するWebアプリケーション

を提供しています。

また、YaDocには「モニタリング機能」といい、様々なバイタルデータ（血圧・体重・SPO2など）を患者が記録し、医療従事者が参照する機能が備わっており、オンライン診療時だけでなく、通常の外来診療の際の参考データとしても活用されると同時に、製薬企業や大学研究機関の臨床研究のプロジェクトにも活用されています。

▼YaDocのビジネスモデルは？

YaDocのビジネスモデルは主に以下の２つになります。

1. オンライン診療システム、またはバイタルモニタリングシステムとして、医療機関への月額課金モデル。
2. 臨床研究のデータ取得プラットフォームとして、製薬企業・医療機器メーカー・大学研究機関へのスポット利用料モデル。

▼どんな体制で作っているのか？

IHのプロダクト開発部は

• エンジニアグループ
• デザイナーグループ
• QA（品質保証）グループ
• ディレクショングループ

これら4つのグループで構成されています。

プロジェクトごとに、各グループからメンバーが参加し開発を進めていきます。

▼アジャイル？ウォーターフォール？

開発モデルは、ウォーターフォール型を採用しています。

• 要求整理
• 要件定義
• 設計
• 開発
• テスト

という流れで開発が進んでいきます。

各フェーズ移行時には、フェーズ移行判定が行われ、必要な情報が適切に準備されることで、戻りが少なく、品質高く納品できる体制をとっています。

▼どんな開発があるのか？

開発内容は主に自社プロダクト「YaDoc」に対する

• 追加機能開発
• リファクタリングやフレームワーク・ライブラリのアップデートといった改善
• バグフィックスといった修正

といった内容が、メインとなります。

▼重要視していることは？

重要視しているポイントは

• 品質
• ユーザー体験
• スケジュール

です。

■品質面について

患者さんの入力するデータを参考に、医療従事者はその患者さんの治療計画を立てたり、論文を書いたりします。そういった背景から、必然的に高い品質を求められるシステムになっています。それに答えるために、QA（品質保証）チームをプロダクト開発グループ内にもち、開発全体の品質を確保するように努めています。

■ユーザー体験について

YaDocで管理されている疾患（病気）は、高血圧・糖尿病・喘息といった一般的な慢性疾患にとどまらず、がん・希少疾患・難病、といった重篤な疾患も管理されています。そういった疾患を患っている患者さんの生活や気持ちは、想像だけでは補うことが出来ません。

要求整理・要件定義フェーズでは、患者さんや医療従事者へのインタビューや行動履歴を参考に、UI/UXを検討し、継続利用につながる心地よいユーザ体験を目指して、開発を進めています。

■スケジュールについて

設計段階に入ると、プロジェクトにアサインされたエンジニアが工数見積を実施し、それ以降はその見積をもとに進捗管理が進行していくことになります。ざっくりではなく、しっかりと見積が立てられるスキルも、IHとしては重要なエンジニアリングスキルだと考えています。

以上がざっくりとしたIHの開発の内容でした。

より詳しく話が聞きたいという方は、8/17(水)19時、8/25(木)19時に、エンジニア向けトークイベントを開催しますので、ぜひ聞きに来てくださいね！

▼2022年8月17日(水) 19:00‐20：00　オンライン開催

▼2022年8月25日(木) 19:00‐20：00　オンライン開催

●社員インタビュー

▼ご協力いただいたお2人

• （左）ソフトウェア・エンジニア　関東 大さん（プロダクト開発部　エンジニアグループ　2021年入社）
• （右）開発ディレクター　高橋 良枝さん（プロダクト開発部　ディレクショングループ　2022年入社）

▼担当している業務内容について教えて下さい

（高橋）私はディレクターとして、YaDocの新機能開発を担当しています。要件定義〜リリースまでの進行管理業務を行っており、複数案件を並行で対応しているので、マルチタスクな働きが求められています。

最近は、新たな取り組みとして、グループを横断して各案件ごとのアサインメンバーの稼働調整と、新しくはじまる案件の進捗を考慮した開発時期の予測計画の立案を行っています。この業務は、部署の責任者と相談しながら対応しています。

（関東）私の主な業務は３つです。

• 1つ目はYaDocアプリの不具合の修正です。これはサービスの運用中に、社内のサポートセンターから報告があった不具合の調査、修正対応を行う業務です。
• 2つ目は案件業務で、YaDocをより良いサービスにするため機能改善や、ユーザーからの要望で機能の開発などを行っています。
• 最後の3つ目は、サービスを提供しているインフラのメンテナンス実施などです。これはインフラリソースのセキュリティ強化対応やリソースのバージョンアップなどのメンテナンスを行っています。

おふたりとも「YaDocの一部」の開発というより「YaDoc全体」に関わっているという印象がありますね。プロダクトの「一部」ではなく「全体」に係れる環境は、魅力的な環境と言えるかもしれませんね。

▼開発グループ内のコミュニケーションについて教えて下さい。特にエンジニアとディレクターの関わり方は？

（関東）実装中は、進捗や課題の共有を行いますが、エンジニアとディレクターとの関わりが多いのは実装前の仕様確認だと思います。

ここはエンジニアの私より、開発ディレクターの高橋さんの方が話せるかもしれません(笑)

（高橋）そうですね、開発ディレクターの方が関わるフェーズは多いと思います。

まず、私の仕事の流れですが、クライアントと実現したい提案内容を営業の方から共有を受け、エンジニアグループ長とどのようにしたらシステムが構築できるか、実現可否について話し合いをしながら方向性を決めます。場合によっては既存仕様と関連技術方法を事前に調査しなければわからないこともあり、調査内容に応じて適切な作業を依頼します。

その後、「要件定義」工程では、実装担当のエンジニアメンバーのアサインを確定し、機能仕様を決定します。「設計 / 実装」工程では、要件定義で決めた内容を、スケジュール通りに進んでいるか、遅れが発生していないか、遅れていたらその原因と対策は何か？などをWEB会議やSlackでコミュニケーションをとり進めます。

IHでは、テスターは専任のQAグループからアサインされるので、「試験実施」工程期間中では、試験実施作業はお任せすることができます。私の前職では人が足りない場合は、ディレクターもテスターとして手を動かしていましたが、全く対応する必要がなくなりました。 テスターからあげられた結果について、単純なミスであればエンジニアに作業を遂行していただき、やるかやらないかの判断が必要な時は、エンジニアと議論をして結論をだし、テスターと連携をとり、進行を管理します。

リリース時も、エンジニアによる作業とテスターが既存の機能全体に影響が出ていないかの確認を実施してくれます。その作業時間の進行を管理して、無事にリリースを終えるまでがディレクターの関わる範囲です。

ディレクターがハブとなって、エンジニア・QAといった各グループが必要なディスカッションを実施し、アウトプットをするイメージですね。各部署にプロフェッショナルが居るため、それぞれが本来の業務に力をさける環境だという点も伝わってきます。

▼コミュニケーションのタイミングやツールは？

（関東）そうですね、エンジニアとしては、仕様確認などテキストベースで進めることが多いです。時には、開発ディレクターとのMTGを設定して確認作業を進めることもあります。 説明が難しい場合は実際の画面のキャプチャを使い、理解しやすい形で伝えるよう意識しています。

（高橋）私の場合は、案件ごとにグループ横断のチームができるのでチーム内でのコミュニケーションが発生します。定期的な会議を実施したり、Slackでいつでもメンバー同士の会話ができるように、最初にコミュニケーションのルールを作ります。その後、メンバーが何か気になる点があれば、個別に確認をとるようにしています。

また、案件を進める上で全体が行き詰まらないように、自分のところで情報を止めないようにしています。イシューがあれば、解決をするために、求める情報を収集するべく周囲に聞いて回ります。重要度に応じてスピード重視で進めます。早め早めに結論を出し、指示するよう心がけています。

コミュニケーションにおいて意識をしている点が異なり、興味深いですね。関東さんは、技術的な会話になることから、伝わりやすさに重きを置いていて、高橋さんは、スムーズに案件を進めていくために、メンバーの会話のしやすさやスピード感をもった判断を心がけているのかなと感じました。

▼入社前と入社後のギャップは？

（関東）今回が初めての転職だったので、エンジニアチームにどんなスキルをもった人がいるのか、どのような業務に関われるのかは気になっていました。

入社後は、すぐに案件に関わりました。 Ruby on Railsの経験がなかったので、技術的なキャッチアップと既存サービスの仕様の理解を進めながら開発を行う必要があり、とにかく必死でした。不安を抱える時間は少なかったですね。 今では、ディレクター、エンジニア、デザイナー、QAの複数グループとの関わりがあるため、知見を広げていくには良い環境だと思います。

（高橋）入社直後は、メンバーが在宅勤務のため、自分と関わりがない人は何をしているのかよく分からなかったですし、相談が発生した時は、どう連絡をすればよいか、手探りでした。ただ、業務を可視化する仕組みを作ったり、自ら積極的に周囲に接することを心がけることで、在宅勤務でもスムーズに業務ができるようになったと思います。

IHのプロダクト開発部は、ポジションごとに4つのグループに分かれていますが、実際の業務はグループを横断していますので、縦割りの意識なく接することができています。

入社直後は、緊張感が続きますよね。お2人はキャッチアップに夢中になったり、自ら周囲とコミュニケーションをとったりと、主体的に業務に関わり入社後すぐにパフォーマンスを発揮しておられて素敵だなと思いました。

▼IHで働いてみて感じた「良さ」は？

（関東）IHはフルリモートの業務環境なので、出社のストレスがありません。まだ社員全員と話したことはありませんが、シャッフルランチで一緒になったときには、皆さん気さくに話してくれると感じています。 エンジニアチームはまだ構築中で色々揃っていない部分もありますが、どうしたらより効率的に開発が行えるのかなど、自分たちで考えてチームを作っていけるのは楽しいです。 既存の仕様がドキュメントにまとまっていないため、実際に動かしたり、コードから機能を追うことも多いです。 また、ただ仕様を実装するだけでなく、サービスの成長に合わせて設計を学べる機会があり、拡張性や開発効率を高めるための方法を考える機会があるのは面白いなと思っています。

（高橋）全体的に、中途採用の方がほとんどで自分の得意とできることを生かして行動するプロフェッショナルな方が多いです。責任者やグループ長のスキルセットも高いので、たいていの悩み事はしっかりと相談すれば解決しますし、建設的に一緒に考えてくれるので心強いです。そしてどうすれば効率よく進むかも考えてくださり、判断スピードがとても速い環境だと感じています。

ーーーーーー

いかがでしたでしょうか。

事業の成長に合わせて自社のサービスの開発を行いたいと思っている方や、開発のノウハウを活かし変化を経験しながらエンジニアとして成長したい方などに、興味をもっていただけたら嬉しいです！

お読みいただきありがとうございました。