9年開発を牽引して見えてきた、
 共通化すべきものと個別でつくるもの 〜プログラム言語編〜 

株式会社CureApp 開発統括取締役 / 医師　鈴木 晋 2014年に医師である佐竹晃太と鈴木晋が創業した医療系スタートアッ プ。治療効果が証明され、医療現場で医師が患者に処方するアプリ 「治 療アプリ」を製造販売する医療機器メーカー。 2020年、ニコチン依存症に対する治療アプリが、スマートフォンで動作す る治療用の医療機器として、 日本初、アジア初の薬事承認および保険適 用となる。2022年には高血圧に対する治療アプリの有効性を治験で証明 し、薬事承認を受けた。 NASH、アルコール依存症、がん、慢性心不全、 慢性腰痛症それぞれに向けた治療アプリを開発するほか、 ascureという 民間向けの健康増進サービスも運営する。 2010年に慶應義塾大学医学部を卒業。在学中にプログラミングを習 得し、卒後は医師免許を取得しながら、ゲノム解析の研究室と Web制 作会社にてソフトウェアエンジニアとして研鑽を積む。 2012年より2年 の臨床研修を経て、 2014年に大学の先輩であった佐竹晃太と CureAppを共同創業。 CDO(Chief Development Officer)とし、技術 から医学的コンテンツ、医療機器開発、情報セキュリティ、デジタルトラ ンスフォーメーションなど広く会社全体を指揮している。得意な言語は TypeScript。並行して2014年より福島市の須川診療所にて週 1回の 一般内科診療を行う。好きな言語は TypeScript。 薬みたいに、治療する アプリを作ってる会社 TypeScript好きな医師で CureAppの共同創業者 

→Google「 CureApp エンジニア」 

DRY or WET Don’t Repeat Yourself Write Everything Twice 

なんでも共通化すればいいわけじゃない。 じゃあ、何は共通化すべきで、 何は共通化すべきじゃないの？ 何を共通化すべきか、それが問題だ。 

1. クロスプラットフォーム開発 ★★★☆☆ 2. UIパーツの共通化 ★★☆☆☆ 3. Atomic Design ★☆☆☆☆ 4. UIと分離不能な機能 ★★★☆☆ 5. サーバー/クライアント間通信フレームワーク　★★★★☆ 6. 言語 ★★★★★ 7. インフラ　　 ★★★★★ 8. 開発環境 　★★★★★ 9. 組織体制　 ★★★☆☆ 詳しくはQiitaの記事で。 qiita.com/shinout → 9年開発・・・ 

No content

言語選定。それは常にトレードオフ 「初期メンバーが得意な言語で作りました。」 「速度が求められるのでC++にしました。」 「言語は毎PJごとにテックリードが決めます。」 その時、最大限のスピードを出す選択。 サービスに適した選択かは不明。 製品クオリティを重視。その分、エンジニアの 市場調達力や保守の難易度が上がる。 エンジニア満足度の向上。局所の最適解。 組織としてのノウハウ共有は行われにくくなる。 

常にトレードオフなら、何を重視するかだ。 製品の質？初期スピード？保守しやすさ？ 言語選定。それは経営判断。 会社の状況、戦略によるじゃん = 経営判断 

会社の状況、戦略 適切な言語は...？ 治療アプリ →クライアントサイドが複雑。 →Webもある。 →サーバーはデータ格納窓口。 多数のプロジェクトを持つ →共通化してスピードアップしたい 限られた資金 → iOS/Android/Web/サーバー/インフラ それぞれ専任のエンジニアは置けない 

合ってたっぽい。。。 

会社の状況(現在)と戦略(未来)の言語化が最重要。 そしたら手法は相談できる。そんな時代。 

で、実際TypeScript一択ってどうなの？ 

TypeScript統一戦略ってどうなの？ 明確なメリット 意外とそうでもない 辛い 非エンジニアから見える 責任、業務範囲が明確 ドメインコードを Universalに書いて共有 分析、機械学習 monorepo & CI 型は全環境で使える エンジニア採用しやすい トランスパイル 環境構築(React Nativeも) IaC (AWS CDK) 型合わせで低下する 短期的スピード エンジニア学習コスト低減 

非エンジニアから見える 責任、業務範囲が明確 とはどういうことか？ サーバーもフロントも同じエンジニアが 担当すれば、責任は明確に。 TypeScriptに統一するとそれが容易になる。 「この不具合の担当は誰？」 「それサーバーのほうですよ」 「フロントチームが忙しいから この機能はリリースできません」 

分析系もTypeScript？→ いいえ、pythonで。 開発系は「技術部」 分析系は「情報部」 組織を分ける 運用DBから定期的にDataLakeにdump システム境界は明確に 情報部: pythonやSQLに一部のドメイン知識 ドメイン知識重複問題はある 開発エンジニアは分析はしない スキルセットや成長の問題 「どっちもやりたい」は現状できない 

TypeScript統一戦略ってどうなの？DRYの観点から。 明確なメリット 意外とそうでもない 辛い 非エンジニアから見える 責任、業務範囲が明確 ドメインコードを Universalに書いて共有 分析、機械学習 ツールチェーンの共通化 monorepo & CI 型は全環境で使える エンジニア採用しやすい トランスパイル 環境構築(React Nativeも) IaC (AWS CDK) 型合わせで低下する 短期的スピード TSのデメリット(DRY関係なし) DRYのメリット DRYのデメリット エンジニア学習コスト低減 

何をDRYにすべきなのか？ ユーザーから遠い部分はDRY。近い部分はWET。 人、開発環境、インフラ。 一方コード自体はそうでもなかった。 開発の低レイヤーほど共通化する 価値が出てきそうだ。 UIの共通化はしんどかった。 

ユーザーから遠い部分はDRY。近い部分はWET。 覚えやすい。 ※画像は世の中の典型的なイメージを揶揄したにすぎず、実際にすべてのエンジニアが DRYでカスタマーサポートが WETであるというのはバイアスが含まれています。 

まとめ 言語選定は経営判断。 組織の現在と未来の言語化が最重要。 TypeScript共通化で得られた最たるメリットは エンジニアの責任の明確化だった。 何を共通化すべきで、何を個別化すべき？ →ユーザーから遠い部分はDRY、近い部分はWET