JMDCの開発本部データ基盤開発部の新倉です。JMDCには大型案件に自由度高く取り組める環境があります。今回は私が実際に経験したDWHシステムの2度のリプレイスの事例をお伝えします。1度目はPL（プロジェクトリーダー）、2度目はPM（プロジェクトマネージャー）としてプロジェクトに参画。その経験からシステム移行プロジェクトを成功に導くポイントを解説します。
＜プロフィール＞※執筆当時
新倉 裕一郎（にいくら ゆういちろう）データウェアハウス開発部 データレイクグループ グループリーダー
新卒でソフトウェア会社に入社。大手ベンダー企業の介護パッケージソフト製造などの開発業務に従事。その後、SaaS型CRMサービスを展開するベンチャー企業に転職し、2015年5月に日本医療データセンター（現JMDC）入社。レセプトDWHシステムを担当し、2度のリプレイスを経験。現在はレセプトDWHシステムの保守開発や、クラウド環境でのシステム開発を行い、データレイクグループのグループリーダーを務める。
レセプトDWHシステムはデータを溜めて配るシステム
JMDCが行っているビッグデータ事業は、保険者データベースと医療機関データベースの2種類に分かれます。なかでも創業以来取り組んできた保険者データベース事業は、JMDCの根幹で売上の大半を占めています。健康保険組合などの保険者からレセプトデータ（診療報酬請求書）等をお預かりし、国内最大規模の累計1400万人のレセプトデータを含む保険者データベースを構築。この保険者データベースに匿名加工処理を施したうえで製薬会社、保険会社などにデータを販売したり、解析サービスや分析ツールを提供したりしています。
保険者データベースではレセプトを取り込むシステム、綺麗に標準化するシステム、データを溜めて配るシステムの3つを活用し、レセプトデータの管理と運用を行っています。その中で、私が担当するのはデータを溜めて配るレセプトDWHシステムです。
1度目のリプレイスでは、PLとしてセキュリティを強化
私はこのレセプトDWHシステムのリプレイスを過去2度経験しています。1度目は入社直後の2015年から2年近くかけて行いました。私自身、システム刷新プロジェクトに加わる前提でJMDCに転職したのですが、それまで医療系データを扱う経験はなかったため、入社後3ヶ月間はひたすらリプレイスに必要な知識を習得していました。
医療知識を学ぶなかで感じたのが、医療データの取り扱いの難しさです。同じ個人情報でも、医療系は特に厳しいと痛感しました。当時の営業部長から製薬の個人情報の取り扱い注意を、口酸っぱく言われていたのを今でも覚えています。
データの一次利用、二次利用の概念もその際に知りました。一次利用は、保険者や医療機関から預かった後に加工し保険者や医療機関に活用いただくデータで、二次利用は預かった後に匿名処理を施し製薬会社などに販売するデータです。一次利用のデータと二次利用のデータが明確に分けられ、二次利用可能なデータについては個人情報の取り扱いから特に厳格なルールが定められていました。
1回目のリプレイスの目的はデータを拡充して利便性を向上させること、高速化すること、サーバの保守期限へ対応することの3つです。当時のレセプトデータは現在の半分ほどで3〜4億件ほどでしたが、年間数千万件ずつデータ量が増加していたため、高負荷に耐えながら、高速化する必要がありました。
プロジェクトは当時使用していたNetezza（IBM Netezza®）を後継機に移行する大規模なものでした。私はPLとして、システムを変えるだけでなく、セキュリティ面も強化。具体的には、一次利用のみが可能なデータと、二次利用も可能なデータを明確に区別しました。どのようにデータが作られ、どこでどんなチェックをされているかを整理して、ドキュメント化。部署ごとに扱えるデータを区分けし、旧システムから大きな変更を加えたため、様々な弊害が起こり、リリース後はその対応に苦労しました。
丸一日かかっていた月次処理を8時間に短縮
このシステム刷新を通じた成果は大きく2つあります。1つ目は丸一日かかっていた月次処理を約8時間に短縮したこと。以前は一次利用、二次利用それぞれのサービスに全てのデータを渡していたため、処理に膨大な時間がかかっていました。一次利用と二次利用を明確に区別し、必要なデータだけを提供するように変更したところ、無駄がなくなり、時間短縮につながりました。
2つ目は縦割りだった組織に横のつながりを作れたこと。入社当初の開発体制は、システムに依存する縦割り組織だったため、横のつながりが薄い状態でした。社内の一次利用のサービス担当者と二次利用のサービス担当者の連携が取れていなかったのです。私は双方のマネージャーと毎週ミーティングを実施。仕事以外の雑談も含めて密なコミュニケーションを心がけ、横の連携を強化しました。
一方で、初めての経験ばかりで多くの苦労も味わいました。リリース予定2ヶ月前の最終テストでデータに不備があることがわかり、メンバー総出で原因の特定、改修、再テストを実施。結局、リリースは1ヶ月延期し、2017年7月になりました。PMが二人という異例の体制だったため、それぞれのPMの役割分担がうまくいっておらず、システム間の連携にも手こずったのが反省点です。
初めての経験のなかで試行錯誤を繰り返し、個人としてもプロジェクトを通じて大きな成長をできたと思っています。入社直後に大型案件を任されたことは、貴重な経験となりました。基幹システムを担当するバックエンドエンジニアは、細かいデータ作業がメインになるためJMDCに入社する前はあまり大規模な案件には関わったことがありませんでした。
JMDCでは、入社時点での医療・ヘルスケアの実務経験は不要で、入社後の案件や実務を通して知識を習得できる環境があります。私自身、医療系の実務経験はありませんでしたが、このプロジェクトを通して医療業界を隅々まで知ることができました。医療業界ならではのデータマートの知識も身に付けられました。
たとえば、レセプトの処理方法です。保険者からお預かりするレセプトは、電子と紙で分かれており、紙はCSVに加工されます。その情報は手書きのモノをCSVに移しているため、表記・表現のブレもあります。データとして扱う際にレセプトをどのように綺麗にするか、どうすれば使いやすくできるかなどユーザー視点での知見も得られました。
2度目はPMとして全体をリード。経営陣へのプレゼンスキルも向上
続いて2度目のリプレイスについて説明します。2度目は2020年から2021年にかけて行われました。システム刷新の理由は、サーバーの保守期限切れです。私は1度目のリプレイスを経験していたこともあり、PMを任され、立ち上げからプロジェクトをリードする立場でした。
今回は、PoCからプロジェクトをスタートしました。IBM社製の2製品とOracle、Verticaの4製品のなかから検討したのですが、結果的にはこれまで使っていたIBM社製のNetezzaの後継機に決定。最終的にOracleと比較して、既存のIBM社のシステムを使うのがコストパフォーマンス的にベストという結論に至りました。
当初本命視していたのはOracleで、開発工数は80人月ほどを見込んでいました。しかし、後継機を採用したことにより、コストダウンに成功し、30人月に。コストカットできたのは、既存システムの後継機はデータベースが以前と同じPostgreSQLで、現行のソースコードを利用できるためです。
2度目のリプレイスではチームメンバーの5名中、私を含む4人が1度目のリプレイスを経験していたため、事前に課題をつぶすことでプロジェクトはスムーズに進行しました。1度目とは違うPMを担当させてもらったことは、自分自身の成長にもつながりました。
たとえば、プレゼンスキルです。PoC後の本番開発は、予算承認を得るために役員を含めた部長以上の20名の役職者向けにプレゼンをする機会がありました。私はもともとプログラマーだったためプレゼンに自信を持っているわけではありません。エンジニアあるあるなのですが、内容をすべてPowerPointに書き、ただ読み上げるスタイルで、聞く人が眠くなるようなプレゼンだったんです。
ところが、コンサル部門の部長に一から指導を受けたことで、プレゼンスキルが劇的に向上。要点を抑えて資料も簡潔に作成し、想定される質問への回答も事前に準備するようになりました。そのおかげで、緊張しながら臨んだ会議でしたが、無事予算の承認をもらえました。
その後、一旦プロジェクトから離れますがシステム刷新も無事成功し、DWHは安定して稼働しています。突発的な不具合やバグは年に1回程度発生するくらいで済んでいます。現在は小規模の開発案件や運用などにチームで取り組んでおり、2年後のクラウド化を目指しているところです。
プロジェクト成功のカギは、コミュニケーションと信頼関係の構築
2度のプロジェクトを経験して私が学んだことは、大きく2点あります。1つ目はキーマンとのコミュニケーションの重要性です。プロジェクトをリードする立場のPMやPLがしっかりとシステムを理解したうえで、他部署や社内のキーマンとなる方とのコミュニケーションに臨めるかがカギとなります。
開発者はコミュニケーションが得意でない人が多いのですが、多くの方の協力が不可欠なリプレイス案件を成功に導くためには、密な連携が欠かせません。私は仕事上の会話以外にも、積極的なコミュニケーションで距離を縮めることを意識しました。コロナ前は、特別な話題がなくても定例ミーティングを開いたり、現在はSlackで週数回は必ず連絡を取ったりといった工夫をしています。
2つ目は仲間を信頼して仕事を任せることの大切さです。ここはプログラマー出身のPMだからこそ感じたことでもあります。どうしてもプログラマーは細かいところに目がいきがちで、あれもこれもやりたくなったり、口を出したくなったりしてしまいます。しかし、PMが細かい作業に追われてはプロジェクトはうまくいきません。PMは全体を俯瞰して見る立場として、開発はメンバーに任せ、スケジュール管理などに集中するべきです。
実際、私も1度目のリプレイスの際は自ら動いてしまったことがありましたが、2度目では細かい作業は全て仲間に任せて、プロジェクト管理に集中できました。思い切って任せるためには信頼関係を築くことが必要で、ここでもやはりコミュニケーションが大切になってきます。
私が7年以上もJMDCで働く理由
最後に、私がJMDCで働く理由についてお話しします。自分にとって2度のリプレイスプロジェクトを任されたことは、大きな財産となっています。私は2015年5月に入社し、かれこれ7年ほどJMDCに在籍しているのですが、これだけの大型案件に挑戦でき、自由度高く、裁量を持って任せてもらえる環境は非常に貴重です。特にベンチャーやスタートアップの開発職では、ある程度力を付けて2〜3年で転職するのがセオリーかもしれません。しかし、私自身JMDCで「挑戦してみたい」という仕事を次々と任せてもらううちに、気づけば7年在籍し続けています。
この7年で社内の開発環境や職場環境も大きく改善されました。CTOが純粋な開発者出身のため、エンジニアの働きやすい環境を積極的に考えてくれており、目指すキャリアの方向性に応じて、会社がサポートしてくれる雰囲気があります。実際私も、部署異動はせず、他部署であるデータ解析・抽出部署の業務をサポートする形で関わらせてもらったことがあります。自社のデータを渡す先がどのような仕事をしていて、どのようにデータを使っているかを知る機会が欲しくて、上司に相談したところ、実現しました。
JMDCではキャリアの希望は比較的叶いやすく、データ基幹開発部から他部署へ異動するメンバーも多くいます。バックエンドからフロントエンドへ移ったり、ネイティブアプリやWebアプリチーム、データサイエンティスト、アドホックを分析する部署に異動したり。上司との1on1の頻度が多く、キャリアに関して相談しやすいため、理想のキャリアを叶えたい人にはとても良い環境だと感じます。
今後のキャリアプランとして、私は組織マネジメントよりも開発プロジェクトを率いるPdMの方向性を考えています。今のところ、自分の目指す方向に進めていると思うので、これからも自分で考えて動く裁量の高い環境で力を付けながら、理想のキャリアを実現していきたいです。
最後までご覧いただきありがとうございました。
もし少しでも弊社にご興味をお持ちいただけましたら、こちらの採用ピッチ資料に詳しいことが記載してありますので、ぜひ一度ご覧ください。
