Profile
電気通信大学大学院 情報理工学研究科 機械知能システム学専攻を修了した後、2021年エムスリーに新卒入社。電子カルテ開発チームにて開発リードを経験。現在はチームマネジメントも担っている。
エムスリーには、新卒で入社したエンジニアでも早い段階から大きな仕事を任される文化があります。実装だけを担当するのではなく、ユーザーや事業の課題に向き合いながら、何を作るべきか、どう進めるべきかを自ら考え、提案し、プロダクトを前に進めていくことが求められます。責任も伴いますが、その分得られる経験の幅は広く、多くのエンジニアが想像以上のスピードで成長していきます。
2021年に新卒で入社した穴繁は、クラウド型電子カルテ「デジカル」の開発に携わり、現在はチームリーダーとして技術課題の整理やメンバーのチャレンジ支援を担っています。学生時代は機械工学を専攻していましたが、音楽情報処理の研究をきっかけにプログラミングと出会い、ソフトウェアエンジニアの道へ進みました。入社後はミッションクリティカルなプロダクト開発に向き合いながら、アプリケーション開発からSRE領域まで技術領域を広げ、3年目にはチームリーダーの代打も経験しました。
なぜエムスリーで「何でもやる」エンジニアとして成長する道を選んだのか。リーダーとしての失敗から何を学び、AI時代の開発チームづくりにどう向き合っているのか。技術領域を広げながら成長を続けてきた5年間の歩みについて話を聞きました。
音楽情報処理とGitHubが開いた、ソフトウェアエンジニアへの道
学生時代はどのようなことをされていましたか？
実は情報系ではなく、機械工学系の学部を専攻していました。材料工学や流体力学、製図といったハードウェア寄りの分野を学んでいて、当時はソフトウェアエンジニアになるとは全く思っていませんでした。
転機になったのは研究室配属です。もともと音楽が好きだったこともあり、研究テーマとして音楽情報処理を選びました。音声波形を用いた楽曲分析やレコメンドモデルの高性能化・高速化といった研究に取り組み、その中で初めて本格的にPythonを使って機械学習モデルを構築する経験をしました。
研究ではGPUなどの計算資源が必要になることもあり、自ら大学の人工知能研究センターへ足を運んで利用を相談したこともあります。今振り返ると、興味を持ったことに対して自分から飛び込んでいく姿勢は、この頃から変わっていなかったのかもしれません。
とはいえ、その時点ではソフトウェアエンジニアを目指していたわけではありません。その時々で面白いと思ったことに取り組んでいた結果、自然とプログラミングに深く関わるようになっていった、という感覚の方が近かったですね。
ソフトウェアエンジニアを目指したきっかけを教えてください
研究を通じてプログラミングの面白さを知ったことが最初のきっかけでした。ただ、最終的にソフトウェアエンジニアを目指すようになったのは、所属していたサークルの先輩との出会いが大きかったです。
その先輩がWebスタートアップを立ち上げていて、遊びに行った際にJavaScriptやReactを使ったWebアプリケーション開発に触れました。研究では一人でコードを書くことが中心でしたが、実際の開発現場ではGitHubでプルリクエストを作成し、経験豊富なエンジニアからレビューを受けます。
その経験がとても新鮮でした。同じ機能を実装するにしても、設計の考え方やコードの書き方にはさまざまな選択肢があります。レビューを通じて、なぜその実装にするのか、どのような観点でコードを書くのかを学ぶうちに、ソフトウェアエンジニアリングそのものの面白さに惹かれていきました。
研究でプログラミングの楽しさを知り、チーム開発を通じてソフトウェアづくりの奥深さを知ったこと。この二つの経験が、ソフトウェアエンジニアとしてのキャリアを選ぶ決め手になりました。
「何でもやる」文化に惹かれてエムスリーへ。入社前の不安と、入社後に感じたギャップ
就職活動ではどのような軸で企業を選んでいましたか？
就職活動では大きく三つの軸を持っていました。
一つ目は、すでに多くのユーザーに利用されている大規模プロダクトの開発に携わることです。学生の立場では、成功しているサービスのアーキテクチャや開発プロセスに触れる機会は限られています。だからこそ、実際に多くのユーザーに利用されているプロダクトの開発現場に身を置き、その仕組みや考え方を学びたいと考えていました。
二つ目は、多くのユーザーを抱えるサービスだからこそ発生する技術的な課題に挑戦できることです。パフォーマンスや可用性、運用といったテーマに興味があり、そのような環境でエンジニアとして成長したいと思っていました。
三つ目は社会貢献性です。自分が開発したものが実際に世の中で使われ、誰かの役に立っている実感を持ちながら働きたいという思いがありました。その軸をもとに、スタートアップから大手企業まで幅広く見ていました。
その中でエムスリーを選んだ理由を教えてください
エムスリーとの出会いは逆求人イベントでした。当時CTOをしていた山崎さん(現CPO)と話したのが最初で、医療という大きな社会課題に向き合いながら事業を成長させている会社だと知り、純粋に面白そうだと感じました。
もちろん、その時点で入社を決めていたわけではありません。就職活動ではスタートアップから大手企業まで幅広く見ていて、自分が本当に求める環境はどこなのかを考え続けていました。
そこで大きな転機になったのが、エムスリーでの2週間のインターンです。出会ったエンジニアの方々は技術力が高いだけではなく、それぞれが好きなことや得意なことを持ち、それを深く追求していました。ギークでスマートな雰囲気があり、自分もこういう人たちと一緒に働きたいと思ったんです。
さらに魅力的だったのが、エムスリーの「何でもやる」文化でした。当時の自分はフロントエンドに興味を持っていましたが、将来的にはバックエンドやインフラにも挑戦したいと考えていました。エムスリーであれば特定の技術領域に閉じることなく、プロダクトに必要であれば何でも取り組むことができます。
また、エンジニアだけではなくビジネスサイドにも優秀な人が多い印象がありました。技術だけでなく、事業やプロダクトについても学びながら成長できそうだと感じたことが、最終的にエムスリーを選んだ決め手でした。
入社前に感じていた不安と、実際に入社してからのギャップはありましたか？
正直に言うと、入社前は少し怖さもありました。エムスリーは裁量が大きい会社だと聞いていましたし、一括新卒採用で同期が多い一方、長期間の研修があるわけではありません。入社後はすぐに実務へ入ると聞いていたので、自分が本当に開発チームの中で戦力になれるのか、不安を感じていました。
医療ドメインに対しても難しそうなイメージを持っていました。電子カルテや医療制度についてはほとんど知識がなく、専門性の高い領域についていけるのだろうかという懸念もありました。
当時の自分は、エムスリーに対して「崖から突き落とされて、あとは自力で成長するような環境」というイメージを持っていたんです。優秀な人が多く、裁量も大きい会社だからこそ、かなり厳しい世界なのではないかと思っていました。
ところが、実際に入社してみると、その印象は良い意味で大きく覆されました。エムスリーはチャレンジを重視する会社ですが、決して一人で放り出されるわけではありません。マネージャーは一人ひとりの状況や成長段階をよく見ていて、本人の能力や志向に合わせながら、少し背伸びをすれば届くような目標を設定してくれます。
自分自身も、デジカルで開発を進められるようになるまでメンターにサポートしていただきました。困ったときには相談できる環境があり、段階的にチャレンジの幅を広げていくことができました。
今振り返ると、エムスリーは単純に裁量が大きい会社というよりも、一人ひとりの成長に合わせて挑戦の機会を作ってくれる会社だったと思います。入社前に抱いていたイメージとのギャップが最も大きかったのは、その部分かもしれません。
医師にとってのエディタを支える。デジカル開発で学んだプロダクトづくりの難しさ
デジカルの開発ではどのようなことに取り組んできましたか？
入社以来、一貫してクラウド型電子カルテ「デジカル」の開発に携わってきました。機能開発の設計や実装だけではなく、既存実装の生産性向上を目的としたリファクタリングや、チームSREとしての活動など、幅広い領域を担当しています。
もともとはフロントエンドに興味を持って入社したのですが、「何でもやる」文化の中でバックエンドやインフラにも自然と関わるようになりました。その結果、エンジニアとしての守備範囲は想像以上に広がったと思います。
デジカルは医療現場の日常を支えるプロダクトです。そのため、機能を作るだけではなく、安定して動き続けることも同じくらい重要です。開発を通じて、技術だけでなくプロダクトや事業を支える視点も身につけることができました。
デジカル開発で特に難しかったことを教えてください
最も難しかったのは、ミッションクリティカルなプロダクトであることです。診療中に電子カルテが使えなくなると医療現場へ直接影響を与えてしまうため、一般的なWebサービス以上に高い安定性が求められます。
加えて、電子カルテならではの難しさもあります。私はよくエンジニア向けの説明として、電子カルテは医師にとってのエディタのような存在だと話しています。エンジニアが毎日使うエディタのUIが突然変わると戸惑うように、医師も日々使っている電子カルテの変化に敏感です。そのため、良かれと思った改善でもネガティブな反応をいただくことがあります。
だからこそ、プロダクトマネージャーと連携しながら、まずは小さくリリースして反応を見る。問題がなければ徐々に対象を広げる。そうした進め方を取っています。実装そのものよりも、どう安全に価値を届けるかを考える場面が非常に多かったですね。
就職活動で思い描いていた環境は実際に得られましたか？
想像していた以上に得られたと思っています。例えば、デジカルでは大規模なシステム運用ならではの技術課題に向き合う機会がありました。データベース関連をはじめとした、大規模サービスを支える仕組みの運用・改善に関わる中で、利用者が多いサービスだからこそ求められる設計や運用の考え方を学ぶことができました。
社会貢献性という観点でも大きなやりがいがあります。新しい機能をリリースすると、医師の方々から直接反応をいただけることがあります。自分たちが開発した機能について「便利になった」「待っていた機能が実装された」といった声を見ると、本当に使われているプロダクトを作っている実感があります。
就職活動のときに求めていた、大規模なプロダクト開発の経験、技術的なチャレンジ、そして社会への価値提供。そのどれもが、デジカルの開発を通じて得られていると感じています。
突然のチームリーダー経験。障害対応と抱え込みの失敗から学んだこと
チームリーダーになった経緯を教えてください
実は、もともとチームリーダーになることを目指していたわけではありません。きっかけは、当時チームリーダーを務めていたメンバーが育休に入ることになり、その代行を任されたことでした。
当時のデジカルチームでは、将来に向けた重要なプロジェクトが複数並行して進んでいました。加えて、ミッションクリティカルなプロダクトである以上、緊急対応も避けては通れません。そんな状況の中で、経営陣への報告やチーム運営など、それまで経験したことのない役割を担うことになりました。
正直、不安はありました。ただ、実際にやってみると想像以上に面白かったんです。開発だけをしていた頃には見えなかった組織や事業の課題が見えるようになり、まだ自分にできることがあるかもしれないと感じるようになりました。
その経験があったからこそ、翌年に正式なチームリーダーの話をいただいた際も、自然と挑戦したいと思えたのだと思います。
チームリーダーの経験を通じて、どのような学びがありましたか？
大きな学びの一つは、技術をビジネスの言葉に翻訳することの重要性です。経営陣への報告なども担当範囲なのですが、そういった場では単に技術的な説明をするだけでは伝わりません。何が起きたのか、それが事業にどのような影響を与えるのか、ネクストアクションとして何をするのかを整理しながら説明する必要がありました。
また、チーム内で行うKPTなどを通じて、チーム開発に対する考え方も学びました。個別の問題や挑戦について、チームとして対応を考えることを大切にしています。その考え方は、今のチーム運営にも大きな影響を与えています。
同時に、自分自身の課題もはっきり見えました。リーダーとして成果を出さなければという思いから、多くの仕事を自分で抱え込んでしまったんです。当時はそれが責任感だと思っていましたし、自分が全部やればチームは前に進むと考えていました。
しかし実際には、自分がボトルネックになっていました。一見すると何でも自分でやるスーパーマンのように見えるかもしれませんが、チームとしては決して良い状態ではありません。今思うと、もっと人に頼るべきでしたし、もっとメンバーに任せるべきだったと思います。この経験は、その後のチーム運営の考え方を大きく変えるきっかけになりました。
正式にチームリーダーになってから、考え方は変わりましたか？
かなり変わったと思います。代行時代の経験を経て、正式にリーダーになってからは、自分が成果を出すことよりも、チーム全体が成果を出せる状態を作ることを意識するようになりました。
例えば、面白い技術課題があったとしても、自分が担当するのではなく、その課題に興味を持っているメンバーと一緒に進めることを考えるようになりました。挑戦の機会を作りながら、成果と成長の両方につなげる。そうした進め方を意識しています。
また、以前は「自分ができることを増やす」ことに意識が向いていましたが、今は「チームとしてできることを増やす」ことの方が重要だと考えています。メンバーそれぞれが強みを発揮できる環境を作ることが、結果としてチーム全体の成果につながるからです。
もちろん、人に頼ることは今でも自分の課題です。それでも代打リーダー時代と比べると、「自分がやる」から「チームで成果を出す」へ少しずつ考え方を変えられてきたと思います。チームリーダーとして最も成長したのは、技術力そのものよりも、そうしたチームの力を引き出す視点かもしれません。
AI時代のゼロイチ開発。コードを書く速さより重要になった意思決定とコンテキスト共有
現在はどのような役割を担っているのでしょうか？
2024年からは、もともとチームリーダーを務めていた瀬越さんに加え、自分も二人目のチームリーダーとして参画しました。瀬越さんがプロダクトマネージャー寄り、自分がエンジニアリングマネージャー寄りという役割分担で、技術課題の整理やメンバーのチャレンジ支援、採用などを担当してきました。
現在はさらに役割が変わり、ゼロイチの新規開発案件で開発リーダーを務めています。設計や技術選定だけではなく、自ら実装も行いながらプロダクト開発を進めています。
既存プロダクトを改善していくフェーズとは異なり、開発体制やプロセスそのものを作るところから考えなければなりません。その難しさはありますが、新しいチームや開発の進め方を形にしていける面白さも感じています。
特に現在のチームでは、新しく採用した技術やアーキテクチャに初めて触れるメンバーも少なくありません。そのため、新しい技術を導入すること以上に、それをチーム全体へどう浸透させるかを重視しています。最近はAIを前提とした開発も増えているため、技術的な正しさだけではなく、チームとして継続的に成果を出せる開発プロセスやチームづくりを考えることも、今の自分の重要な役割になっています。
AIを活用した開発は、これまでと何が違うのでしょうか？
現在の開発では、AIがプロセスの中に自然に組み込まれています。メンバーそれぞれが日常的にAIを活用しており、実装によっては生成されるコードのほぼ100%をAIが担うことも珍しくありません。
実際に開発スピードは大きく向上しています。ただ、そこで見えてきたのは、コードを書く速度が上がっても開発全体が同じ速度で進むわけではないということでした。
今ボトルネックになりやすいのは、むしろ意思決定です。何を作るのか、どこまで作るのか、どのような設計にするのか。そうした判断の重要性は以前よりも高まっていると感じています。
また、AIを活用するほど、人間同士のコンテキスト共有も重要になります。AIは与えられた情報をもとにコードを生成するため、設計資料や意思決定の履歴を整理し、チーム全体で共有しておくことが欠かせません。現在のチームでは、そうした情報をできる限りGit上で管理し、AIも含めて活用できる状態を作っています。
AIによってコーディングの効率は上がりましたが、その分、意思決定や情報共有など、人間が担うべき部分の重要性はむしろ高まっていると感じています。
技術力以上に伸びた、ソフトスキルと事業視点
入社から約5年で、最も成長したと感じる部分はどこですか？
技術力はもちろん伸びたと思います。ただ、それ以上に成長したと感じているのは、ソフトスキルの部分です。
デジカルのような大規模な機能開発をユーザーに届けるまでには、実装力だけでは越えられない壁がたくさんあります。QAチームと協調してどこまで品質を保証すべきかを判断したり、リリース時のリスクに応じて段階的なリリースを計画したり、プロダクトマネージャーやサポートチームを巻き込みながら進めたりする必要があります。そうしたコミュニケーションや巻き込みのスキル、物事を前に進めるために領域を越えて動く姿勢は、エムスリーに入社してから身についた部分だと思います。
入社前は、エンジニアとして技術力を高めることに意識が向いていました。もちろん技術力は今でも大切ですが、実際にプロダクト開発に向き合う中で、良いコードを書くだけでは価値を届けきれないことを実感しました。ユーザーに価値を届けるために必要なことを考え、職種や役割を越えて動けるようになったことが、一番大きな成長かもしれません。
エムスリーで働く中で、事業視点はどのように身についていきましたか？
入社当初は、技術的に正しいものを作ることがエンジニアの役割だと思っていました。ただ、実際にプロダクト開発を進める中で、それだけでは十分ではないことを学びました。
エムスリーでは、どんな機能を出すかについても、プロダクトマネージャーが決めたものをエンジニアが作るだけではありません。エンジニアやQAも含めて、みんなで良いものを作っていくというスタンスがあります。
そのため、技術的に正しいかどうかだけではなく、それがユーザーや事業にとって本当に価値があるのかを考える機会が自然と増えていきました。役割を必要以上に区切らず、自分から領域を広げていくことも求められる環境だと思います。
チームリーダーになってからは、経営層のミーティングに参加する機会も増えました。事業を伸ばすためにどのような意思決定が行われているのかを近くで見られることは、大きな学びになっています。
その視点を持った上で、エンジニアとして今取り組むべき技術課題は何かを考え、チームで意思決定しながら進めていく。そうした経験を積めることは、エムスリーならではの成長機会だと思います。
不確実性を楽しめる人が活躍する。エムスリーで働くエンジニアのリアル
エムスリーで活躍している人、逆に合わないと感じる人はどんな人ですか？
活躍している人に共通しているのは、不確実性を楽しめることだと思います。
エムスリーには、最初から答えが決まっている課題ばかりがあるわけではありません。むしろ、何が正解なのか分からない状態からスタートし、自分たちで仮説を立てながら進めていく仕事の方が多いと感じています。その中で、自分で課題を見つけ、周囲を巻き込みながら前に進められる人は活躍している印象があります。
もちろん、その過程で失敗することもあります。ただ、失敗そのものを避けるのではなく、そこから学びを得て次に活かせる人は強いと思います。自分自身もチームリーダー代行時代に仕事を抱え込み、自分がボトルネックになってしまった経験があります。その失敗があったからこそ、今はチームで成果を出すことの重要性を強く意識しています。
反対に、やるべきことが明確に決まっていて、その通りに進めることに安心感を覚えるタイプの人は戸惑う場面があるかもしれません。裁量が大きい分、自分で考えて決める機会も多いので、その環境を面白いと思えるかどうかは一つのポイントだと思います。
新卒エンジニアが入社後にぶつかりやすい壁はありますか？
一番大きいのは、技術だけではなく成果を求められることだと思います。
新卒で入社すると、どうしても目の前の実装や技術的な課題に意識が向きがちです。自分自身もそうでした。ただ、プロダクト開発では限られた時間やリソースの中で何を優先するかを決めなければなりません。
その中で意外と難しいのが「やらないことを決める」ことです。エンジニアは新しい技術やアイデアに興味を持つ人が多いですし、自分もその一人です。しかし、すべてを実現することはできません。
だからこそ、さまざまな選択肢を検討した上で、「今回はやらない」と判断することも重要な仕事になります。最初は難しく感じるかもしれませんが、そうした意思決定を繰り返す中で、技術だけではなくプロダクトや事業を見る視点も身についていくのではないかと思います。
事に向かい続けた先で見えた、AI時代の開発組織づくり
これからのエンジニアに求められる力をどう捉えていますか？
AIの進化は本当に速いと感じています。正直、自分自身も半年後や2〜3年後にエンジニアの働き方がどう変わっているのか、完全には想像できません。それくらい大きな変化が起きていると思います。
そんな時代だからこそ、特定のフレームワークや言語だけに依存するのではなく、コンピューターサイエンスやソフトウェアエンジニアリングのような普遍的な知識を身につけることが重要になると考えています。コードを書くハードルは大きく下がりましたが、なぜその設計にするのか、なぜその技術を選ぶのかといった判断の部分は、今後も人間が担い続けるはずです。
また、学習のハードルが大きく下がったことも変化の一つです。以前であれば何日もかけて調べながら進めていたことが、今では対話しながら実際に手を動かして学べるようになりました。課題に感じていることを形にしてみたり、OSやデータベースのような仕組みを作りながら理解を深めたりすることも、以前より取り組みやすくなっています。
新しい技術を使いこなすこと以上に、変化を前向きに受け入れながら学び続ける姿勢が重要になっていると感じています。
今後、どのようなことに挑戦していきたいですか？
今、一番興味があるのはAI時代の開発組織づくりです。
開発スピードが大きく向上する中で、強いチームの条件も少しずつ変わり始めています。そうした変化の中で、これからの時代に成果を出せる開発チームとはどのような組織なのかを考え続けています。
現在携わっている新規プロダクト開発も、その挑戦の一つです。開発プロセスの中にAIを組み込み、ドキュメントを中心に知識を共有しながら開発を進めるなど、これまでとは異なる開発スタイルを模索しています。将来的には、自分たちのチームがエムスリーの中で一つのロールモデルになるような組織を作りたいです。
また、チームリーダーを経験して強く感じるようになったのは、自分一人でできることには限界があるということです。今取り組んでいるゼロイチのプロダクトも、自分だけでは絶対にローンチまでたどり着けません。メンバーが新たな役割を担い、自分が担当していた仕事を引き継いでくれるからこそ、自分も次の挑戦へ進むことができます。
だからこそ、これからは技術だけではなく、人を巻き込みながらチームとして成果を出せる組織づくりにも挑戦していきたいと思っています。
最後に、これから一緒に働く方へ伝えたいことを教えてください
エムスリーには、答えのない課題に向き合いながら、みんなで議論して前に進めていく面白さがあります。
最初から正解が用意されている仕事ばかりではありませんが、その分、自分で考え、周囲を巻き込みながら形にしていく経験ができます。
自分自身も、エンジニアとしてだけでなく、チームリーダーとして多くの失敗や試行錯誤を経験してきました。その中で感じるのは、完璧な人が活躍するのではなく、学び続けられる人が成長していくということです。
自分の考えに固執せず、新しい意見を受け入れながら成長できる人。答えのない課題を面白がれる人。そんな方と一緒に、新しいプロダクトや組織づくりに挑戦できたら嬉しいです。
