株式会社ヘンリー エンジニアブログ

株式会社ヘンリーのエンジニアが技術情報を発信します

はじめての転職で難易度鬼のレセコン開発に挑戦している

はじめまして!
5月にヘンリーにレセコン開発エンジニアとして入社した岡部(id:takamizawa46)です。 早いもので、なんと入社してから約2ヶ月も経っていたので、振り返りをしながら入社エントリーを書いてみたいと思います。

ヘンリーにやってくる前

前職は名古屋のベンチャー企業で、機械学習やチャットサービスなどの受託開発や、採用管理ツールの自社開発を経験しました。 主にサーバーサイドを担当しつつ、なんちゃって*1EMなどもやっていましたが、今思うとチームメンバーの話を聞くだけのお粗末なものだったでしょう。当時のチームメンバーには迷惑をかけてしまったと思います。

入社したばかりの頃は、とにかくコードを書くのが楽しくて「コードが書ければ何でも良い」という乱暴な開発者でした。 しかし、不思議なもので開発に慣れてくると次第に「リリースしたシステムは使われているのだろうか...?」と考え始めるようになってきました。 前職では組織の体制上、どうしてもシステムの利用ユーザーとの距離が遠くなることが多く、開発したシステムや機能が本当に使われているのかを知るには難しい状況にありました。

転職を考えはじめる

自分のモチベーションが「良いものをつくっているか」に変化した事に気づいた頃に、何となく転職を考え始めました。

ただ、初めての転職だったので、何から始めれば良いのか全く分かりませんでした。
とりあえずカジュアル面談を受けつつ改めて転職理由を考えていたのですが、言語化するのは想像以上に難しく時間がかかりました。
何度も「転職理由は何ですか?」と聞かれ考えている内に、最終的には「良いものをつくりたい」という思いと「エンジニアとして、もっと成長したい」という理由に落ち着きました。

ヘンリーを選んだ理由

ヘンリーはXでフォローしていたSongmuさんのツイートを通して知りました。
当時は*2レセコンが何なのか全く知らずの状態で、軽い気持ちでカジュアル面談を受けたのですが、担当の縣さんから「複雑な診療報酬制度をシステムに落とし込んでいく難しさ、機能・改善をリリースしまくることが、そのままユーザーへの価値提供になる」という話がとても響きました。

また、国内でクラウド型のレセコン一体型電子カルテを開発しているプレイヤーはほとんどいない、というか診療報酬制度が複雑すぎて参入するのが非常に難しい状況があります。 逆を言えば「これだけ複雑なものを作れたらカッコよくないか...?」とワクワクさせられたのと、ヘンリーには強いメンバーが集まっており、このメンバーの中で難しい課題にチャレンジすれば間違いなく一段階上のエンジニアになれるんじゃないかという期待感がありました。

その後、選考を通した体験・丁寧なフィードバックが、最終的な決め手となりヘンリーを選びました。 ここまで丁寧にフィードバックをもらったことがなかったので、例え不採用だったとしても良い経験になったなと思えるような選考でした。

入社後のあれこれ

オンボーディング

入社後の1ヶ月間はオンボーディング期間として設定されています。
初日から医療ドメインのキャッチアップや現在のチーム・業務について学べるように自分専用のTODOリストが用意されており、会社として受け入れをしっかりやろうという体制が整っているなと感じました。

オンボーディングについてはnabeo(id:nabeop)さんの記事でも触れられています。

dev.henry.jp

全体的なオンボーディングに関してはとても整備されていると感じましたが、その一方で所属するチームのオンボーディングに関しては、まだまだ未整備の部分がありました。

環境構築の手順だったり、もろもろ関連サービスへ招待・権限付与をしてもらう必要があったり...と暗黙知になっている箇所がいくつかあり、自分がジョインしたことで明瞭化されたのは良かった点だと思います。 今後、新しくジョインするメンバーが困らないように詰まった箇所はドキュメント化することで、僭越ながら整備を行いました。

ドメインのキャッチアップ

いまだに頭を抱えることが多いです。
入社して1ヶ月は単語や概念のキャッチアップで精一杯でした。
ようやく何の会話をしているかは分かる状態になりましたが、詳細の議論になってくると、理解が追いつかないことがあります。 とにかく領域が広くて深いので、根気強くキャッチアップしていくしかありませんが、皆さんが丁寧に教えて下さるので大変、助かっています。

例えば最近、関わりがあった感染対策向上加算3はこんな感じです。

感染対策向上加算3は入院初日及び入院期間が90日を超えるごとに1回算定する。
90日を超えるごとの計算は、入院日から起算して91日目、181日目等と計算する。
なお、ここでいう入院とは、第2部通則5に規定する入院期間中の入院のことをいい、感染対策向上加算1及び2については入院期間が通算される再入院の場合は算定できず、感染対策向上加算3については通算した入院期間から算出し算定する。

引用元: A234-2 感染対策向上加算(入院初日)

どうでもいい話ではありますが、ドメイン知識がついたおかげで病院でもらえる明細書が楽しく読めるようになりました。 珍しい加算がされていたりすると勝手に盛り上がっています。

業務に関して

まだまだ思ったように手は動かないなと感じています。
ドメイン知識とコードベースへの理解が不足しているので、コードを読むのに時間がかかりますし、複雑な診療報酬制度をコードに落とし込むのは本当に難しいです。 少しずつできることが増えているはず...なので、早くチームの力になりたいです。

何度か質問されたことがあったので、技術スタックについても触れておきます。
自分は元々、動的型付け言語のRubyをメインに書いていたのですが、ヘンリーではバックエンドに静的型付け言語のKotlinを採用しており、技術スタックには差異がありました。 最初は苦戦するかな?と思っていましたが、そんなことはなくKotlinは非常に書きやすい言語だなと感じています。

特に障壁はなかったですが、一例として依存性の注入は、RubyというかRailsを書いていた自分にはあまり一般的なものではなく、書籍で読んだことはあれどプロダクションコードで扱ったことがありませんでした。ヘンリーではKoinというフレームワークで依存性の注入をしており、最初はどこでインスタンスを作っているのかと不思議に思ったのを覚えています。

とはいえ、今まで触れたことがない技術に触れられるというのは、やはり転職のメリットですね。

一緒に仕事をする仲間を募集しています

ここまで読んでいただき、ありがとうございます。
ヘンリーでは複雑なドメインの開発に共にチャレンジする仲間を募集しています。
これからも成長が見込める弊社で一緒に働いてみませんか?

興味のある方は以下の採用サイトから、ぜひコンタクトしてみてください。

*1:エンジニアリングマネージャーの略称

*2:レセプト(診療報酬明細書)を作成するときに使用するレセプトコンピューターのこと