大坪新平 / メディキューCTO

MeDiCU CTO / ex-@wantedly / BigQuery / dbt / Kubernetes / Dvorak / 芸情13,14 / 未踏2018 / 翼35 / Explorers

[大坪新平 / メディキューCTO @potsbo]

会社が順調に成長してきてアーキテクチャが理想形からじわじわとシフトを始めたので今向かうべき方向をまとめました！要するに「複雑な2つのものの間に最強の interface が定義されたらいいよね」という誰もが考えたことがあるけど無理になって諦めちゃうアレを本気でやりますということです。

順調に成長しすぎて人も全然足りなくなっているので一緒に働いてくれる人も大募集してます！是非興味持った方はお話できると嬉しいです！

[大坪新平 / メディキューCTO @potsbo]

すごく同意。さらには「とりあえずは非決定的にやってあとから古典的に手法に置き換える」というような方法も出てくると思ってて、これがこれからの時代の技術的負債の借り方ないし返し方になっていくと思う

[naoya @naoya_ito]

決定的なことは古典的手法で、非決定的なことはAIで。境界をきちんと見分けて何でもかんでもAIに推論させない。こういうことを丁寧に紡ぎ上げてくってのは、たぶん中長期的にみて大事なことになってくんじゃなきかな

[大坪新平 / メディキューCTO @potsbo]

AIなかったら弊社の今のプロダクトをこの短期間でのリリース絶対無理だったなって思うので本当にすごいなこの発明

[大坪新平 / メディキューCTO @potsbo]

FDE初心者なんですが、自社パッケージ(プロダクトとあえて区別しない)という抽象部分と導入されたシステムという意味での具体部分があるときに、ユーザーとのコミュニケーションを通して前者に良い効果をもたらすことができるかどうかが鍵だと思ってます。

いわゆる従来の SIer のアプローチのイメージとして具体部分の重要度が高すぎて抽象部分が余り育っていかないというイメージがあります。(イメージです)

FDE的な動きが大事だという文脈で重要なのは「パッケージを顧客環境に合わせる」と「顧客環境から得られた知見でパッケージを成長させる」のバランスで、前者はエンタープライズでは避けては通れないけどギリギリまで後者のアプローチにできないかを考えられるかが重要だと思います。

顧客要望をカスタマイズ案件ではなく機能拡張のフィードバックだと捉えられれば強いし、機能拡張するときも既存ユーザーに影響がでないかむしろプラス要因に出来る出来たら最高だよねという

[chimuichimu @chimuichimu1]

FDEとSIerの客先常駐の違いとして「プロダクト有無」と言われることが多いけど、SIerも自社パッケージや3rdパーティの製品を担いでいたりするので、区別されるものというより「SIerの中にもFDE的立ち回りのエンジニアがいる」が正だと思う。そしてそういう人を"FDE"として高単価で売る流れも起きそう。

[大坪新平 / メディキューCTO @potsbo]

@Keisuke69 今小さい会社ながらCTOなのですがもしよかったらイベント内容とか教えてもらえると嬉しいです！

[大坪新平 / メディキューCTO @potsbo]

こういうのマジやめてくれ〜

[大坪新平 / メディキューCTO @potsbo]

もしかしたら PdM というものが何を指すのかが違うのかもしれないけど、自分は一つのプロダクトには PdM は一人であるべきだと思っている。0人でもたくさんでもない。
一人の人が描く世界観や統一感というものが合議的な方法では出てこないシャープさを出してくれる

バックログを整理していく、仮説検証を進める、優先順位を決めるだけの PdM なら別に何人いてもなんと呼んでも変わらないけど、あるプロダクトの思想を決めていくという意味での PdM は一人。映画やスポーツの監督が一人であるのと同じ。
全員で協力して個々人がオーナーシップを持っていくべきなのはそう。でも道を決めるのは一人。

自分の組織では FDE が何人生まれようと PdM は PdM で必ず一人置き続けたいと思ってる

[Shin丨AI×プロダクト開発の専門家🤵🏻 @shin_sasaki19]

「PdMを廃止しました」という決断をしたスタートアップの話が刺さりすぎた📝

■ なぜPdMを廃止したのか
・従来の組織は「営業 → PdM → エンジニア」というリレー構造になっていて、お客様の声とプロダクトをつなぐ役割が1職種に集中していました。しかし、これには構造的な問題があります。まず、エンタープライズのペインは『深さ』が命なのに、伝言ゲームで薄まる。そして役割分担がリレーである以上、後発SaaSにとっては遅すぎる。

そこで同社は「PdMに閉じ込める」という構造そのものを捨てました。代わりに採用した考え方が『1人1人がPdM・製品/機能責任者になる』というもの。役割名としてのPdMを置かず、それぞれのロールが製品責任を持つ形に再設計したのです。

■ 新設したロール「FDE」とは
特に印象的なのは、PdMの代わりに新設された「FDE（Forward Deployed Engineer）」という役割です。Palantirが起源の概念で「誰よりも業務を理解して、As-Is To-Beを描きながら、自分で開発し、お客様の『できない』を解決する役割」と定義されています。
FDEに求められるのは、ドメイン理解力、仮説構築力、実装力、コミュニケーション力の4つ。

・PMとの違いは『自分でコードを書ける／モックを開発し、語れる』こと
・エンジニアとの違いは『お客様と直接話して仮説を構築できる』こと
・PdMとの違いは『お客様が課題を解決することに責任を持つ／1社に深く入り込む』こと

つまりFDEは、ペインを聞く人と作る人が"同一人物"であるべきという思想を体現したロールなのです。

■ 「ラストワンマイル」と「WOWの終焉」
1つ目は『ラストワンマイル問題』。お客様の中でAIによってアイデアは広がっているけれど、それを組織として運用に乗せるところは、ほとんど進んでいない。個人で作れるもの（プロト・PoC）と、組織で回るもの（共通AIの組織導入、業務オペレーションへの組込み、ROIが出るプロダクト）は、別物。その差を埋めるのがFDEの仕事と位置付けています。

2つ目は『WOWが生まれにくくなっている』ということ。以前はAIで何かを見せるだけでお客様が「WOW」と言ってくれた。でも今はChatGPTもCursorもCopilotも皆が触っていて、お客様のリテラシーが圧倒的に上がった。普通のことではもう驚かない、と。

ではこれからは何で価値を出すのか。答えは「業務をお客様以上に深く理解し、質の高いアウトプットを、速く出せるかどうか」。

■ これから求められるスキル
『営業力 × コンサル力 × 開発力』の掛け算で全部できる必要はないけれど、何かが突出して強くないと辛い。器用貧乏では深いペインに届かない、と断言されています。

そして自分の強みを軸に、他の領域にも『越境する意志』があるかどうか。これがAI時代のケイパビリティを定義しているのだと思います。

PdMという職種が不要というより、職種として線を引くこと自体が後発スタートアップの足かせになっている、というメッセージとして受け取りました。AI時代の組織論として一読の価値ありです。

[大坪新平 / メディキューCTO @potsbo]

> 「データ」と「機能」はむしろ存在感を増す。

わかる。特に「機能」の部分。
「自分のAIが今数万円分のトークンを使って考えた結果」よりも「そのドメインの専門企業が数千万円投資してきたカリカリのロジック」のほうが絶対信用できるしその会社がその投資を回収して持続可能になるのも現実的

AI に何でもやらせずに「ドメインエキスパートが整理したロジックが存在するか」をまず考えるべきだしそれが作れれば、AIより安価により深い問題が高速に解けるようになるし、そこに対価は払われる

[炎鎮🔥 - ₿onochin - @super_bonochin]

そうそう、そして多くの人が勘違いしている SaaS is dead の根幹だと思うんすよね。
本当に価値あるものを提供しているサービスは普通に残る。使い勝手がいい「だけ」とか、キュレーションしてる「だけ」とか、ラップしてる「だけ」とか、人間の認知負荷を下げるため「だけ」に何かを提供しているサービスが要らなくなるだけ。
「データ」と「機能」はむしろ存在感を増す。
イメージとしては、小売りが要らなくなっただけ。

[大坪新平 / メディキューCTO @potsbo]

> デタラメな経営の企業が今も存続できている理由は、競合他社も同じようにデタラメだからというだけ

スタートアップやってて同じことを感じてる。自分くらいのデタラメさでスタートアップを成功に導けるのは実は今が最後なのではないか、
今後は人的リソースのキャップが外れたことでチャレンジャーが100倍に増えてその中で最高の経営ができないと芽が出ないのではないか、みたいな

少なくとも10年後のスタートアップでエンジニアに求められるスキルが今と同じではないことは確かで、今この瞬間と10年後なら今の方が自分が相性がいい可能性を考えておきたい

(多分2人目以降のエンジニアも同じ話があるからチャレンジしたい人は今一緒にやりましょうマジで)

[iwashi / Yoshimasa Iwase @iwashi86]

組織のAI活用に関する手厳しいポストだった。

・AIが思い通りに動かないことへの不満の多くは、ユーザー側が自分の望みをうまく説明できないことに起因している
・企業の最大の課題はAIの技術的な成熟度ではない
・ビジョンや目標が不明確で常にブレているという根本的な問題にある

・AIは実行に特化したツールであるため、何をすべきか明確な指示を与えられなければ無力である
・自社の目的を正確に把握しているごく一部の企業だけが、AIに適切な指示を与えて大きな成功を収めている
・多くの企業は自社の戦略や業務内容を明確に説明できず、ただなんとなくの成功で生き延びているのが実態

・実態が混沌としたブラックボックスのような企業において、経営陣がただ「AIを使え」と指示しても何も解決しない
・AIの恩恵を受けている企業は、自社の課題、目標、戦略、プロジェクト、コストなどを即座かつ明確に答えることができる
・ダメな企業は目標や戦略が四半期ごとにコロコロと変わり、見栄えを良くするためのその場しのぎの対応に終始している

・目標が不明確な企業がAIを使うと、無駄に手の込んだ資料などを作れるようになってしまう
・それで、事態がさらに悪化する恐れすらある
・デタラメな経営の企業が今も存続できている理由は、競合他社も同じようにデタラメだからというだけ

・大半の企業は自社を言語化する自己認識能力に欠けており、企業におけるAI活用はまだほとんど始まっていないと言える
・AIやテクノロジーを問題視するのではなく、自社の業務や目標を明確に説明できない組織のあり方こそを問題視すべき

・AIの登場により、小さな企業でも大企業と同等の力を持てるようになる
・すると、組織が整理されていない大企業は大きな危機に直面する

・今後のビジネスでは、自社の現状を明確に把握し、体制が整っている企業だけが生き残り、成長していくのでは
・企業は「AIに何ができるか」を問う前に、まずは「自社がAIを活用できる状態にあるか」を見極め、早急に組織を整理した方が良い

https://t.co/n43tX6pHL5

[木下喬弘 / メディキューCEO @mph_for_doctors]

「挿管の適応は救急医が挿管した方が良いと思ったとき」と教えられて育ったので、スタートアップの定義も「本人たちがスタートアップだと思ったとき」で良いと思ってる。

うちは調達してないけどスタートアップ。

なぜなら私がスタートアップだと思ってやってるから。

[大坪新平 / メディキューCTO @potsbo]

引き算は本当にそうですね。ボタンやスライダーは一度置いたらなかなか外せないのでギリギリまで我慢したいところ

1番いいモデリングを突き詰めるところを避けていいことはないので

[柴田 淳-【新刊】みんなのPython第五版/Pythonで学ぶはじめてのプログラミング入門教室 @ats]

UIもシステムも分からない人がAIにツール作らせると、ボタンやスライダーが無駄に多くなりますよね。デザインに必要な「引き算」ができないから。

[大坪新平 / メディキューCTO @potsbo]

AI信じて突き進むときの1番のトラップはこれだと思ってる
「違ったら後からまた高速にAIに直して貰えばいい」という楽観視も見るけど、どこまで開発が速くなっても「ユーザーとの約束を反故にする速度」には限界がある

ユーザーとの約束とは何か
定義は曖昧にならざるを得ないけど、「ユーザーが利用時に期待してること」という感じ
すごく暗黙的なものも含まれていね「どいいうメンタルモデルで使うものか」という曖昧性のあるものも含む
DBに気をつけなくてはいけないのは「安易な約束をしない」ため「どんな約束をするか慎重に選ぶ」ために重要なことの1つだからという整理をしてる

「適当に作ったDB」があると「適当に作ったDB制約から生まれたUIとメンタルモデル」が意図せず生まれてしまう。どれだけAIが賢くなってマイグレーションがコストじゃなくなったとしてもこの「生まれてしまったメンタルモデル」を崩すのが簡単ではない

[柴田 淳-【新刊】みんなのPython第五版/Pythonで学ぶはじめてのプログラミング入門教室 @ats]

これ、最悪なのは「UIしかできない人がDBスキーマを作る」ケースだと思う。
システム的な抽象化の視点がほとんど入っていないので、複雑すぎてメンテが難しいかしばしばメンテ不能なシステムになる。

[大坪新平 / メディキューCTO @potsbo]

エンジニアよりの人は Claude Code と、ドメインエキスパートやPdMよりの人は Devin と相性がいいと思ってます。弊社の場合は圧倒的に後者よりの人が多いので少なくとも費用面では Devin のほうが数倍から10倍程度の支払いになってます。

Devin は「気を使わなくていいあなた専用のエンジニアで、喋るのは苦手なのでMTGはできません」 という説明をするだけで Day1からドメインエキスパートにさわってもらえるのがデカいんですよね

別の言い方では Devin はライトに使う人がたくさんいるというものであって、Claude Code のようにヘビーにカスタマイズ(どうやって多重化してリモートで動かしてpermission を...とか)してヘビーに使う人がそれよりは少ない人数いるという違いだと思います

つまり「発信したくなるような工夫の余地/必要があるか」が大きく違うからという解釈です

[Keisuke Nishitani @Keisuke69]

Devinが企業では結構使われてると思われるのにTLではあまり見かけない理由、結局高くて企業ユース中心だからなんだろう
TLではどうしても個人開発とか個人が利用するツールの文脈が多くなるだろうし
あとは企業ユースだと金にならないからAI驚き屋も驚かない

[大坪新平 / メディキューCTO @potsbo]

病院にシステムを入れていくのにインフラエンジニア時代につけた知識に都度調べていくだけではキャッチアップスピードが足りないのでGWにもう一度体系的にやり直す

ここまでマスタリングTCP/IP一本でやってきたけど、正確さが高い代わりに実践的な感覚が個人的には掴みづらかった

実践的な example をたくさん吸収することが現場での瞬発力としてまじで大事だなって感覚が出てきたのでゴリっと読んでく

[大坪新平 / メディキューCTO @potsbo]

本当に人がたりません！一気にスケールしたいタイミングに来てるので一緒に働く人を大募集してます🙏

[木下喬弘 / メディキューCEO @mph_for_doctors]

メディキューでは創業からずっと「ICUデータ基盤の開発」に力を注いできました。

今、このシステムが臨床研究やAI開発、院内業務効率化SaaSの全てに活きてくることが証明されつつあります。

外部資本なしで黒字で成長している珍しいスタートアップですが、人が全く足りません。

特にエンジニア、営業、プロダクトマネジメントなど、様々な業種を募集しています。

「医療に貢献したい」という熱い思いを持つみなさんと一緒に働きたいです。

ご関心のある方はぜひこちらまでご連絡ください！

https://t.co/Kkyvbzgola

[大坪新平 / メディキューCTO @potsbo]

記事はこちら！

https://t.co/g2HAG1rmya

[大坪新平 / メディキューCTO @potsbo]

会社が順調に成長してきてアーキテクチャが理想形からじわじわとシフトを始めたので今向かうべき方向をまとめました！要するに「複雑な2つのものの間に最強の interface が定義されたらいいよね」という誰もが考えたことがあるけど無理になって諦めちゃうアレを本気でやりますということです。

順調に成長しすぎて人も全然足りなくなっているので一緒に働いてくれる人も大募集してます！是非興味持った方はお話できると嬉しいです！

[大坪新平 / メディキューCTO @potsbo]

この観点では計算リソースを持ってくれて Slack とか GitHub から何も考えずにタスクを開始できつつ、Claude Code くらいのサクサクした監視やフィードバックができるみたいなのが正解なのではないかなという気がした

[大坪新平 / メディキューCTO @potsbo]

Devin 型と Claude Code 型のどっちが最終的に正解になるか考えていたけどでは本質的な違いは何かというと最終的には「計算リソースのマネジメントをタスク依頼者が行うか」に尽きるかなと思った。

[木下喬弘 / メディキューCEO @mph_for_doctors]

インターンの村山くんがブログを書いてくれました！

例えば「人工呼吸中に昇圧剤を使用したか」という事象を、SQLで調べるにはどうすれば良いでしょうか？

単純そうで意外と悩ましい問題ですが、非常にクレバーに解決しています。

SQLに詳しくなりたい医療者必読です！

https://t.co/92p3TwwJT3

[大坪新平 / メディキューCTO @potsbo]

https://t.co/VWMYURfy7e
少なくとも小規模なプログラムをスクラッチから作る場合だと動的型付け言語のほうが実装が早くて安い。自分の直感はそれでも大規模になれば型システムが聞いてくるのではないかと思っているけど正直ここまできれいに傾向が出ると自信がなくなってくるな