Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

医療向け基幹システムを提供するスタートアップに入社しました

前回の退職エントリに続けての入社エントリです。

2022年7月1日より株式会社ヘンリーにSREとして入社しています。Java→Kotlin、AWS→GCP、Ansible→Terraformなど技術的には大きな変化を伴う転職でしたが、SREとしての観点や課題解決プロセスへの習熟、そして持ち前のひとがらのよさ(なぜか変換できない)などのポータブルなアビリティに助けられて2ヶ月生きています。このエントリーでは入社の目的と2ヶ月働いてみての転職の感想を残しておきます。

目標

新卒入社のころと違って自分なりの働き方やプロフェッショナルとしての在り方があるためそこまで厳密な目標は定めなくていいのかなと思う反面、振り返りや内省が成長の糧になることも確かなので、3つほど定めています。

1. 顧客と開発現場から学び、製品とチームを継続的に改善する

さすがに14年も経つと、ある程度はITエンジニアとしての基礎や専門性に自信がついてきます。その実態は、自信を持たないといけないという焦りかもしれませんが。。。

ともかく、継続的に仮説を検証して製品やチームに反映させることを通じて成長を積み重ねることや、その実行のための各種棚卸しや優先度付け、情報を整理したうえでの議論などはある程度可搬性のある技術として身についた気がしています。また昔「ソフトウェアを育てるにはユーザが多いほうがいい」と考えていたのとは違うやり方が多数あるということもSaaSやリーンソフトウェア開発手法の文脈で見てきたので、あまり規模にこだわることは本質的ではないのだなという気づきも得ました。ので前回の目標1を単純化して、継続的な学習の実行を新しい目標としています。

2. 製品を通じて社会の課題を解決する

今回転職活動を通じて多くの会社さんと話す機会を作っていただいたのですが、その中には全くときめかないところがいくつかありました。大きく分けると2パターンあり、自らを破壊的イノベーターと位置づけながら「なぜ新技術によってレガシーのやり方を駆逐できるのか」を説明できないところ、「新しいアプローチによって顧客事業を助けられる」と売上機会を説明するだけで「どのような社会的課題を解決するのか」を語ってくれないところには魅力を感じませんでした。

これは新卒で入った会社がブレークスルーによる社会的課題の解決にこだわっていたことの影響だと分析しています。新卒で入る会社が発想や働き方に強く影響するというのは本当なのかもしれません。いまの私は「新しい技術」だけでも「新しいアプローチ」だけでもない、「新しい技術で新しいアプローチを実現することで難しい社会的課題を解決する」働き方がしたいようです。

また同様の理由から、コンサルや請負開発のような自社で製品を持たない働き方を本業にするイメージは湧きませんでした。CD最適化や静的解析、ビルドツールといったスキルだけ見ると、むしろ多数のプロジェクトを実装して渡る働き方はマッチしているとは思っているんですけどね。Canは合ってもWantが合わないという感じなのでしょうか。

3. ドメインの課題を解決する手段とプロセスを理解する

これは俗に言う「チャレンジ目標」です。

私はいままでたくさんの部署や役割を転々とさせていただいて、製品開発だけでなく保守や研究開発、管理統制といった経験を積むことができました。また製品種別だけでもBtoB、BtoC、BtoE、社内ツールと多岐にわたる経験ができました。

が、一方でひとつのドメインに長く留まって業務課題を解決することはしてきませんでした。よく言えば多彩な観点からソフトウェア開発を支えられる人材ではあるのですが、前述したとおり社会的課題の解決に価値を感じている以上、ソフトウェア開発の手前つまり「ドメインの課題を噛み砕いて実行可能な計画に落とし込む」スキルを自分で持っておきたい気持ちもありました。

このスキルを得ることはソフトウェア開発者としての成長にもつながると思っています。ドメイン駆動開発の話です。出典を失念したのですが「昔は言語の表現力や計算機の性能が不足していたのでGoFのようなデザインパターン技法が注目された。現代では多くの障害が取り除かれた結果、変化するソフトウェアによる課題解決という核心に資するドメイン駆動デザインパターンが注目されている」という表現を読んで非常に納得できたことがあり、以降システム設計や保守に加えてドメイン駆動についても学んでいます。

今回の転職で「ドメインの課題を噛み砕いて実行可能な計画に落とし込む」ことを学び、観察し、実践する機会を多く得られそうなので、業務を通じて理解を深めていきたいと考えています。

入社2ヶ月時点での所感など

1. 異業界スタートアップで働いてみて

大企業向け基幹システムを提供するメガベンチャーから医療機関向け基幹システムを提供するスタートアップに転職したわけですが、業務内容自体は意外と変わりませんでした。少なくともベンチャー・スタートアップでは、自分で課題を見つけて周囲を巻き込んで解決していく「問題解決の核」としての働き方はかなりポータブルなんだなと感じます。

業界が変わって大きく違ったのは顧客の求めるものでしょうか。前職だとROI(情報投資効率)がひとつの大きな指標だったのですが、医療機関の電子カルテやレセプトコンピュータ(レセコン)だとまた違った話になるようです。またユーザがかなり多様なため、業務想定やユーザ体験設計などの難度が一段上がった気がします。

2. OSS開発ないし専門性と直接の関係がない役割へ転職して

静的解析関連のOSSを長年やっていることもあり静的解析サービスの企業はよく検討していたのですが、ビジネスモデルの問題かどうしても魅力的なポジションがなく、ここは早い段階で諦めていました。 そのため静的解析と直接の関係がない会社に入ったことは特に気にしていません。

またヘンリーはOSSを積極的にはやっていませんが、OSS経験があることは評価してくれていましたし、実際ここ2ヶ月でgradle-gcs-build-cache, tfmigrate, tfaction, gcs-proxy-cloud-runといくつかの貢献を業務として行えました。のでこれも気にせず正解だったと思います、まぁ前職でも言うほど業務ではOSSやってなかったですし。

3. 駐在員としての経験がフルリモートにマッチしているかも

オンライン会議前にアジェンダをまとめておくとか、とにかくドキュメントに落とすとか、カレンダーに不在予定含めすべてのスケジュールを入れておくとか、ソフトだが回りくどくない表現をするとか、Working Out Loudするとか。駐在員として本社の人とどうコミュニケーションするかを突き詰めた結果としてのコミュニケーションスキルはフルリモートで遺憾なく発揮されています。

ちょっと面白いのが「戸田さんはエンジニア以外にもやってることがわかりやすい」「コミュニケーションがいちいち工夫されていて、フルリモートのはずなのに存在感がすごい」というフィードバックをいただくことですね。工夫って……Slack書いてるだけだが?というのは置いといて、もはや意識的にやっていることではなかったので新鮮でした。

VPoEお墨付き↑の存在感🤗

まとめ

とりあえず2ヶ月を走りきり、今後もやれそうな感覚を掴めています。やるべきこと・やれることが山積みの状態ですが、健康に気をつけつつベストを尽くし、挑戦を続けていきます。

ちなみに今回の転職はLaprasさん経由でした。今週インタビューも掲載いただいておりますので、よろしければご覧ください:

note.lapras.com

あとド定番で恐縮ですがWe're hiringなので、戸田が選んだチームや社会的課題ってどんなのだ、というのが気になる方は採用情報も見ていただけると嬉しいです:

jobs.henry-app.jp