今回お話しを伺うのは内上 昌裕。harmo株式会社の代表取締役Co-CEOでありながら、DevOps部 部長として、現場PM（プロジェクトマネージャー）・PdM（プロダクトマネジャー）を担当しています。 

エンジニア、PM候補、PdM候補、DevOpsで転職をお考えの方は必見！ 

フルリモートやフルフレックスなど充実した制度が整っており自由度が高い環境に興味がある方は、ぜひ記事をご覧ください。 

Project Manager / Product Manager 
DevOps部 部長
おくすり手帳事業本部 副本部長
代表取締役 Co-CEO

１．PM/PdM内上さんのバックグラウンド 

―――今までの経歴を教えてください。 

20年以上の社会人生活の中で、ずっとIT業界に身を置いてきました。最初の半分はSIer、つまり受託開発の現場でシステム開発に従事していました。そこで得た知識と経験が、事業会社に転職後の後半のキャリアに大きく影響を与えています。 

 お世話になった事業会社のなかではリクルートが最も長くいましたが、リクルートに入社した当初、私のバックボーンであるシステム開発のスキルを活かし、ID・ポイントのプラットフォーム開発のPMを務めていました。おそらく皆さんもご利用のリクルートIDやリクルートポイントのような、今では広く利用されているサービスの中核部分の開発に関わっていたんです。 

 当時はまだホットペッパーグルメなども、それぞれ別のポイントシステムを持っていました。これらを一つのID・ポイントに統合するというタイミングで私が参画しました。いわば「リクルート経済圏」というものを実現していく局面に居合わせました。 

 ここで学んだことは、PMとして、システム開発の側面だけでなく、事業側との連携が非常に重要だということでした。事業側のサービス・ユーザーパターンなどを理解し、それを漏れなくプラットフォームと連携設計しきることが大きな体験でしたね。いかにスムーズな移行導線にするかといったところで、細かい部分に至るまで指差し確認をした記憶があります。 

 このような仕事を通じて、事業側との強い連携が築け、その後の新規サービス開発のプロジェクトでも指名されることが増えていきました。新規サービスでは、事業側の方々はどうしてもシステム開発について分からないことが多いんです。だから、システムの基本設計、APIの開発、データベース設計まで、基本的なシステムの構築は私のほうでまとめてやる役割でした。 

 また、システム側をまとめると、必然、ビジネス要件や業務要件をシステム要件に落とし込む仕事も担いました。この経験は、ビジネス面・システム面の両方を理解し、プロジェクト全体の推進する能力を養うことに役立ち、その後のPdM・プロダクト企画というキャリアにつながっていきました。 

―――炎上経験があると聞きましたが、どんな経験だったのでしょうか。 

 私が新規サービスプロジェクトに関わり始めた時は、大体プロジェクトが炎上しているタイミングで依頼されることが多かったんですよ。記憶に残っている炎上プロジェクトとしては、決済まわりのシステムでの炎上でしょうか。 

 その時は、関連部門の新卒3年目の担当者に、何度も時間をとってもらって業務フローを教えてもらったり、非常に地道で泥臭い作業でしたが、そういう業務とシステムの整合性を整理しきる、という経験が今の自分に繋がっていると思います。リクルート時代は、そういう泥臭いことをやっていたのが、思い出深いですね。 

2．業務を取り組む際の考え方について 

―――システムを開発する上で、何を大事にしていますか？ 

私たちは電子お薬手帳サービス「harmoおくすり手帳」を開発する上で、当たり前すぎますが、ユーザーの体験を起点に考えており、具体的にUX（ユーザーエクスペリエンス）を最優先に考えています。仕様を決める際には、UXが基本の大きな基準となります。 

例えば、エンジニアから「今のiOSやAndroidの仕様上、こう作ってもいいですか？」という提案があがってきます。そんな時、私はいつも「UXはどうなりますか？」と質問します。もし「問題ない」という回答があればOKですが、問題がある、というか違和感がある場合は「他にどんな実現方法があるか」を一緒に考えます。 

つまり、UX、ユーザー体験を起点としたプロダクトづくりをどこまで徹底するかが、プロダクトの成功には欠かせないと考えています。技術的な制約、セキュリティ的な制約がありながも、ユーザーがどのように感じ、どのように使うかを第一優先にすることが、システムやサービスの設計において最も重要な要素なんです。 

―――ユーザーを起点に考えるようになった背景を教えてください。 

長年IT業界にいると、さまざまなプロジェクトの進め方を見てきました。よく問題が起きるケースは、システムの実現性があまり考慮されないまま、営業や企画側が、お客さんと話したことを決定事項として、「これを作って」と言うパターンです。逆に、エンジニアに意思決定が偏りすぎている組織だと、容易に実現可能な技術制約から物事を考えてしまい、結果的にユーザーが使わないものを作り上げてしまうこともあります。 

だから私は、ユーザーの視点と、システムの実現性という点を、常にエンジニアと議論しながら、最適な開発を決めています。スタート地点はいつもユーザー。これを忘れないようにしているんです。 

さらに、私はシステム開発の経験があるので、エンジニアと話す時点で、企画をすでにシステムとの橋渡しが可能な状態にしてあります。やりたい企画・理想像を現実のシステム設計に落とした時、実現可能かという判断が重要ですが、企画の時点で無理なものは無理だと判断していくことで、その後の開発スケジュールの遅延を抑え、仕様未確定で開発のスピードが極端に落ちることもありません。 

―――ユーザーを起点に考えて、どのような世の中を実現したいですか？ 

ユーザーを起点に考えた時、私たちが実現したい世界は、「十人十色の医療体験を当たり前にする」ということなんです。これはharmoのミッションです。 

長期間にわたって薬を飲み続けることは本当に大変です。薬の形状ひとつをとっても、その飲みやすさが継続的に薬を服用する人には大きな影響を与えるんです。 

harmo は おくすり手帳アプリで、ユーザーに便利に使ってもらいながら、こういった問題にも取り組むために、大学と共同で研究を進めたりもしています。harmoおくすり手帳のユーザーに対し、どんな薬が好まれ、継続して服用されやすいかのアンケートを集めて分析しています。 

上記は一例ですが、こういったデータを基に、年齢や性別、健康状態によって異なる医療体験を、ITの力を活用して個々に最適化していく、それが私たちの目標なんです。 

―――実体験としてのエピソードはありますか？  

私は家系的に気管支が弱くて、昔から喘息になりやすいんです。最近、風邪を引くと咳が長引いて喘息の手前までいきます。 

はじめ咳を止めたくて内科に行くと、「風邪が残ってますね」と診断を受け、咳止め薬が処方されましたが全く効きませんでした。その後、呼吸器系のクリニックに行くと「喘息の症状です」と診断を受け、ステロイド吸入薬を処方されたことがあります。その時はピタッと症状が治まり、薬によって症状の治まり方が全然違うことを実感しました。 

このとき、医療において患者側に知識や選択軸がないことがないと実感しました。私自身もITサービスを通じて、個々に最適化した医療体験を作っていきたいと思っています。 

―――開発手法はどのように決めていますか？ 

基本的には不確実性を判断軸として、ウォーターフォール・アジャイル・ハイブリッドで開発を進めています。 

教科書通りかもしれませんが、患者さま向けのアプリに関しては、アジャイル開発を多く使う傾向があります。不確実性が高く、患者さまからの要望次第で、すぐに改善できる方がいいですよね、という考え方で進めています。一方で、医療機関向けのシステムは、業務の手順が業法によって明確に決まっているものもあります。こういった領域ではウォーターフォール開発の方が効率的です。 

状況に応じて、アジャイルか、ウォーターフォール、あるいはハイブリッドを選択して柔軟に進めることが大事だと考えています。すべてウォータフォールを適用するのも、すべてアジャイルを適用するのも、ともに間違っていて、案件によって最適なものを選択する、ということを意識しています。 

―――業務上で何かの判断するときにはどのようなプロセスで意思決定をしていますか？ 

私は、チームのメンバーの意見を取り入れて意思決定をしています。自分ひとりの判断が常に正しいとは限らないと思っているので、周りの意見もしっかり聞くようにしています。実は以前、toC向けのサービスをPdMとして運営している時に、論理的に考えると絶対に売り上げが上がるはずのUIリニューアルを行ったんです。でも、結果は全く逆で、まさか売上が下がるなんて一ミリも予想していなかった事態に陥りました。「選択回避の法則」とか言われるやつです。本当に思いっきり失敗してしまったことがあったんです。 

その経験から、自分ひとりの判断っていうのは、結局のところ個人の見解に過ぎないと痛感しました。私という人間は所詮、40代男性のN=1なわけですから。だからこそ、みんなの意見を聞いて、判断材料に加えるようにしているんです。 

３．働き方について 

―――内上さんのチームでの働き方や仕事の進め方について教えてください。特に、プロジェクトのリリース日の管理や、チームメンバーの働きやすさに関してどのような考えを持っていますか？ 

土日は休みで、平日にすべての仕事を済ませるという世界が理想だと思っています。私自身、受託開発の会社にいたときは、土日に出勤したり、年末年始に仕事をするエンジニアをたくさん見てきました。それが本当に嫌だったんです。一番辛かったときは、リリース日に本番動作確認で致命的なバグが見つかって、その日の深夜まで対応したこともありました。 

そのため、リリースタイミングにエンジニアの負担をいかに最小限にするかを重視しています。平日に小出しにリリースしたり、とにかく分散させたりしています。いかに無理せず持続的に働けるかに意識を払っています。 

そして、仕事が終わった後にはみんなで喜びを分かち合いたいんです。無理してこなした仕事は、疲れ果てて終わっても嬉しくない。だから、無理を感じている人は早めに言ってほしいと、定期的にチームに伝えています。終わったあとに嬉しくないと、次への意欲に繋がらないと心底思っています。私自身、チームのメンバーには無理せず働いてほしいと思っています。 

―――リモートワークは可能ですか？また、リモートワークではどのようなことに配慮していますか？ 

harmoではフルリモートでの勤務も可能です。しかし、リモートのみですと、流行りの1on1のミーティングを開催しても、つい業務の話ばかりになってしまうことが多いんですよね。それを解決するために、例えば、私一人とエンジニアが三人のように、複数人でのグループを作って、意識的に雑談を交えた打合せをするようにしています。少なくとも三人くらいいると、一対一よりも会話に入りやすくなると思うんですよ。それに、他のメンバーのことももっと知ることができますしね。要は、面白い話を共有しながら、笑顔を作って、楽しみながら働けるよう工夫しています。 

―――現在、子育てしながら働いている方もいらっしゃいますか？ 

実際にharmoでは、子育てしながら働いている人は結構いますよ。特にエンジニアの私のチームには、私を含めて子育て中のメンバーが4人いるんです。フルフレックス制ですので月間の総労働時間さえ満たせば、就業時間は自由に決められます。そのため途中で子どものお迎えに行くことも可能ですね。 

誰もが自由に病院へ行ったり子どものお迎えに行ったりしていいんです。みんなで「いってらっしゃい」と送り出すような、そんな状態が当たり前の環境があります。もちろん、結果は出さないといけないので業務調整は行いますけどね。家事・育児、誰もが通る道です。ですから定例の会議を設定するときも、みんな家庭の事情やプライベートな事情があるでしょうし、「この時間枠を定例化して大丈夫ですか？」とか言いながら会議のスケジュールを調整しています。 

４．最後に 

―――どういう方に応募していただきたいですか？ 

今働いている環境に自由度がなくて自分のパフォーマンスを出せないと感じている人にぜひ応募してほしいですね。たとえば、時間的な制約や、有無を言わせぬ組織文化の制約などで困っている人は、harmoでその力を存分に発揮してほしいです。大企業では役割分担が厳密に決まっており、「あなたはこれだけやってください」という感じになりがちですが、harmoではもっと柔軟に働けます。 

harmo は組織サイズもまだ大きくなく、機会を活用したい人にはどんどんお願いしています。お客さんとのユーザーヒアリングをやってみたければどうぞ、という感じです。自分の経験を広げたい方にとっては最適な場所です。ベンチャー企業だからといって、「無理はしない」がモットーですので、無茶ぶりはしないので（笑）、安心して応募してください。ぜひ、一緒に働きましょう！