Hejlsberg の TypeScript と C#：コードをスケールさせるツール

コードベースが大きくなるとき、なぜ開発者体験が重要なのか

コードベースが遅くなる理由は、エンジニアが急にコーディングを忘れるからではありません。遅くなるのは「理解するコスト」が上がるからです：馴染みのないモジュールを把握すること、安全に変更すること、そして変更が他を壊していないことを証明すること。

プロジェクトが成長すると、“ただ検索して編集する”は通用しなくなります。あらゆる欠けているヒントのコストを払うようになります：不明瞭なAPI、ばらばらなパターン、弱いオートコンプリート、遅いビルド、役に立たないエラー。結果は単に納期が遅れることだけでなく、より慎重な配信になります。チームはリファクタを避け、クリーンアップを先延ばしにし、製品を前に進めない小さく安全な変更ばかりを出すようになります。

Anders Hejlsberg が関係する理由

Anders Hejlsberg は C# と TypeScript の両方で重要な役割を果たした人物です。これらはどちらも開発者体験（DX）を第一級の機能として扱う言語です。それは重要です。なぜなら言語は構文やランタイム挙動だけではなく、エディタ、リファクタリングツール、ナビゲーション、コード作成時に得られるフィードバックの質といった周辺のツールエコシステムでもあるからです。

この記事では、TypeScript と C# を実用的な視点から見ます：それらの設計上の選択が、システムとチームが拡大してもチームの生産性をどのように助けるか、という点です。

「スケーリング」が本当に意味すること

コードベースが「スケールしている」と言うとき、通常いくつかのプレッシャーが同時にかかっています：

• チームの規模： コントリビュータが増えるとスタイルが多様化し、調整コストが増える。
• コードの規模： モジュールや依存が増え、未知の領域が増える。
• 変更頻度： リリースが増え、並行作業が増える。

強力なツールはこれらの負担が生む税（コスト）を減らします。エンジニアが瞬時に答えを得られるようにします：「これはどこで使われているのか？」「この関数は何を期待しているのか？」「これをリネームしたら何が変わるのか？」「これは安全にデプロイできるか？」。それが開発者体験であり、大規模なコードベースが進化するか化石化するかの差になることが多いのです。

Anders Hejlsberg の影響：実用的な視点

Hejlsberg の影響は、引用や経歴の羅列として見るよりも、プロダクト哲学として一貫して現れるのが分かりやすい：共通の作業を速くし、ミスを早期に明らかにし、大規模な変更を安全にする。

この節は伝記ではありません。言語設計と周辺ツールエコシステムが日常のエンジニアリング文化をどのように形作るかを理解するための実用的なレンズです。チームが「良いDX」と言うとき、彼らが意味しているのはしばしば C# や TypeScript に意図的に組み込まれたものです：予測可能なオートコンプリート、妥当なデフォルト、信頼できるリファクタリング、修正への道筋を示すエラー。

ツール文化における「影響」の見え方

開発者が言語やエディタに今や期待することとして観察できる影響があります：

• エディタはコードを“色付けするだけ”ではなく、コードを理解しているべきだ。
• リネーム、参照検索、ナビゲーションはリポジトリ全体で機能するべきだ。
• 型（存在するなら）は生産性を落とさずに向上させるべきだ。
• ツールは常時使えるだけの速さを保つべきで、リリース前だけ動作するのではない。

これらの成果は実務で計測可能です：避けられるランタイムミスが減る、より自信を持ったリファクタ、コードベースに参加したときにかかる「再学習」時間が短くなる。

なぜ C# と TypeScript を比較するのか

C# と TypeScript は異なる環境で動作し、対象も異なります：C# はサーバーサイドやエンタープライズ向けで使われることが多く、TypeScript は JavaScript エコシステムをターゲットにしています。しかし両者は同じDXの目標を共有しています：変更のコストを下げつつ、開発者が速く動けるようにすること。

両者を比較することは、原則とプラットフォームを切り分けるのに有用です。非常に異なるランタイムで同じようなアイデアが成功していれば、その勝利は偶然ではありません。フィードバック、明確さ、保守性を優先する設計上の明確な選択の結果です。

スケーリングの仕組みとしての静的型（単なる嗜好ではない）

静的型付けはしばしば趣味の問題として語られます：「型が好き」対「柔軟性が好き」。大規模コードベースでは、それは嗜好ではなく経済学の問題です。型は、より多くの人がより多くのファイルに頻繁に触れるときの作業を予測可能に保つ方法です。

強い型付けが日々にもたらすもの

強い型システムは、関数が何を期待し、何を返し、どの状態が許されるかというプログラムの約束に名前と形を与えます。それにより暗黙の知識（誰かの頭の中やドキュメントに埋もれているもの）をコンパイラやツールが強制できるものに変えます。

実務上、それは「これは null になり得るのか？」といった会話が減り、オートコンプリートが明確になり、見知らぬモジュール間でのナビゲーションが安全になり、意図がAPIにエンコードされるためコードレビューが速くなることを意味します。

コンパイル時チェック vs ランタイム障害

コンパイル時チェックは早期に失敗します。間違った型の引数を渡したり、必須フィールドを忘れたり、戻り値を誤用したりすると、コンパイラが即座に指摘してくれます。

ランタイム障害は後で現れます—QAで、あるいは本番で—特定のコードパスが実際のデータで実行されたときに発生します。これらのバグは通常コストが高い：再現が難しく、ユーザーを中断させ、リアクティブな作業を生みます。

静的型がすべてのランタイムバグを防ぐわけではありませんが、「そもそもコンパイルされるべきでない」クラスのエラーを大幅に減らします。

型が防ぐスケーリング時の失敗

チームが大きくなると、共通の破綻点は次のようになります：

• 不明瞭な契約： モジュールが何を保証するかを明示しておらず、使い方がずれていく。
• 安全でないリファクタ： リネームやシグネチャ変更が呼び出し箇所を見落とす。
• 隠れた結合： 無関係な部分が同じ緩いオブジェクト形に依存する。

型は共有マップのように機能します。契約を変えると、更新が必要な箇所の具体的な一覧が得られます。

トレードオフ（現実的だが対処可能）

型にはコストがあります：学習曲線、境界での注釈の追加、型システムで表現しづらい意図に対する摩擦など。重要なのは、型を戦略的に使うことです—公開APIや共有データ構造に最も重く使い、そうすることでスケーリングの利益を得つつ開発が書類仕事にならないようにします。

高速なフィードバックループ：モダン言語の隠れた利点

フィードバックループとは、日中繰り返す小さなサイクルです：編集 → チェック → 修正。一行を変えると、ツールが即座に検証し、コンテキストスイッチする前に問題を直せる、それが数秒で回ることが理想です。

遅いフィードバック：バグが遠くへ旅するとき

遅いループでは「チェック」は主にアプリを動かして手動でテストすること（またはCIを待つこと）を意味します。その遅れにより小さなミスが宝探しになります：

• コードをプッシュする。
• テストが後で失敗する（あるいはユーザーが報告する）。
• 誰かが意図を再構築し、問題を再現し、時間的プレッシャーの下でパッチを当てる。

編集と発見の間のギャップが長いほど、修正コストは大きくなります。

速いフィードバック：エディタ＋コンパイラがチームメイトになる

モダンな言語とそのツールはループを数秒に短縮します。TypeScript と C# では、エディタが打ち込んでいる最中に問題を指摘し、しばしば修正案まで示してくれます。

早期に検出される具体例：

• プロパティの欠如： user.address.zip にアクセスしているが address が存在する保証がない。
• パラメータ型の誤り： 文字列を渡しているが数値（または特定の列挙型）が必要な場合。
• 到達不能コード： return によってそれ以降が実行されないコードがある。

これらは「落とし穴」ではなく、ツールが素早く変換してくれる一般的なミスです。

チームでこれがより重要な理由

高速なフィードバックは調整コストを下げます。コンパイラと言語サービスが不一致を即座に検出すると、コードレビューやQA、他チームの作業に問題が漏れることが減ります。つまり往復が減り（「ここで何を意図していたの？」）、ビルドの破壊が減り、「誰かが型を変えて私の機能が壊れた」という驚きが減ります。

スケールするとき、速さはランタイム性能だけでなく、開発者がどれだけ速く自分の変更が妥当だと確信できるかでもあります。

ネイティブに感じられるツール：言語サービスとIDE統合

「言語サービス」とは、コードを検索しやすく、安全に触れるようにするエディタ機能群のことです。考えてみてください：プロジェクトを理解したオートコンプリート、正しいファイルに飛ぶ「定義へ移動」、すべての使用箇所を更新するリネーム、何も実行する前に問題を下線表示する診断。

TypeScript：常時稼働するアシスタントとしてのコンパイラ

TypeScript のエディタ体験が優れている理由は、TypeScript コンパイラが単に JavaScript を生成するためだけのものではなく、TypeScript 言語サービスを動かしている点にあります。

VS Code（や同じプロトコルを使う他のエディタ）で TS プロジェクトを開くと、言語サービスは tsconfig を読み、インポートをたどり、プログラムのモデルを構築して次のような質問に継続的に答えます：

• この値は今どんな型か？
• どのオーバーロードが呼ばれているか？
• ワークスペース全体でこのシンボルはどこで定義されているか？

だから TypeScript は、正確なオートコンプリート、安全なリネーム、定義へ移動、参照の検索、クイックフィックス、インラインエラーをタイプ中に提供できます。大規模な JavaScript 中心のリポジトリでは、その密なループがスケーリング上の利点になります：不慣れなモジュールを編集しても、何が壊れるか即座に指針が得られます。

C#：コンパイラ＋IDEが一体となって働く

C# も同じ原則から恩恵を受けますが、特に Visual Studio（および言語サーバ経由の VS Code）での深い IDE 統合が日常ワークフローに効いています。コンパイラプラットフォームは豊富なセマンティック解析をサポートし、IDE はそこにリファクタ、コードアクション、プロジェクト全体のナビゲーション、ビルド時フィードバックを重ねます。

チームが成長すると、頭の中でコードベースを「精神的にコンパイル」する時間が減ります。代わりにツールが意図を確認してくれます—呼び出している実際のシンボル、ヌラビリティの期待、影響を受ける呼び出し箇所、変更がプロジェクト横断でどのように波及するかを教えてくれます。

これは「便利さ」を越えてスケールする

小規模ではツールは贅沢かもしれませんが、大規模ではチームが恐れず動くための手段です。強力な言語サービスは、不慣れなコードの探索を容易にし、安全な変更を可能にし、レビューを容易にします—同じ事実（型、参照、エラー）が全員に見えるようになるからです。

リファクタリング支援：変更を安く、確実にする

リファクタリングは「本当の作業の後にする大掃除」ではありません。大規模コードベースでは、それがまさに日常の作業です：毎月、新機能が遅く・危険にならないようにコードを絶えず形作ること。

言語とツールがリファクタリングを安全にすると、チームはモジュールを小さく保ち、名前を正確にし、境界を明確に保てます—リスクの高い数週間に及ぶ書き換えを予定することなく。

日常的に必要になるリファクタリング

TypeScript と C# のモダンな IDE サポートは、次のような高レバレッジの操作に集中します：

• 安全なリネーム（変数、メソッド、クラス、ファイル、モジュール）
• メソッド／関数の抽出（長いブロックを読みやすく、テスト可能にする）
• シンボルの移動（クラスを別ファイル／名前空間／モジュールに移し、import／using を修正する）
• インポート／using の整理（ノイズを減らし微妙な衝突を避ける）

これらは小さな操作ですが、スケール時には「変更できる」か「誰もそのファイルに触らないか」の差になります。

なぜリファクタリングはセマンティックな理解を必要とするのか（テキスト検索ではない理由）

テキスト検索は、同じ単語が同じシンボルを指しているかどうかを判断できません。実際のリファクタリングツールはコンパイラのプログラム理解（型、スコープ、オーバーロード、モジュール解決）を使って「意味」を更新します。

このセマンティックモデルこそが、インターフェースの名称を変更して文字列リテラルに触れずに済ませたり、メソッドを移動してすべての import／using を自動で修正したりできる理由です。

良いツールが避けさせてくれる失敗モード

セマンティックなリファクタリングがないと、チームは避けられる破壊を頻繁に出します：

• リネームや移動後の壊れた参照
• 動的パターンやオーバーロード、シャドウ変数による見逃された呼び出し箇所
• コメントや文字列を誤って編集してしまう偶発的編集
• 一部のファイルがコンパイルし、他が静かに乖離する半分更新されたAPI

ここで、開発者体験は直接的にエンジニアリングのスループット（処理能力）になります：より安全な変更は、より早く、より多くの変更を生み、コードベースに埋め込まれた恐れを減らします。

TypeScript のアプローチ：JavaScript 世界への段階的な安全性

TypeScript が成功した大きな理由は、「やり直し」を要求しないことです。多くの実プロジェクトは現実として既に JavaScript で動いており、速く動き、出荷しています。TypeScript はその上に安全性を段階的に重ねられるようにします。

構造的型、推論、段階的型付け（平易な言葉で）

TypeScript は構造的型付けを使います。互換性は宣言された型名ではなく値の形（フィールドやメソッド）に基づきます。{ id: number } を持つオブジェクトは、別のモジュールから来たものであってもその形が期待される場所で使えることが多いです。

また 型推論 に大きく依存しています。多くの場合、注釈を書かなくても意味のある型が得られます：

const user = { id: 1, name: "Ava" }; // inferred as { id: number; name: string }

最後に TypeScript は 段階的 です：型付きコードと型なしコードを混在させられます。最も重要な境界（APIレスポンス、共有ユーティリティ、コアドメインモジュール）にまず注釈を加え、残りは後回しにできます。

「進めながら型を追加する」ことが採用を現実的にする

このインクリメンタルな道筋が、既存の JavaScript コードベースに TypeScript がフィットする理由です。チームはファイル単位で変換し、初期は any を受け入れつつも即時の恩恵を得られます：より良いオートコンプリート、安全なリファクタ、明確な関数契約。

厳格さはチームが徐々に上げるダイヤル

多くの組織は中程度の設定で始め、コードベースが安定するにつれて徐々に厳しくします—strict を有効にし、noImplicitAny を強め、strictNullChecks の適用範囲を広げるなど。重要なのは進歩であり、一週間でスイッチを一気に切り替えることではありません。

注意：型は意図を表すものであって真実を証明するものではない

型はあなたが「期待する」動作をモデル化します。実際のランタイム挙動を証明するものではありません。ビジネスルールや統合エッジ、外部I/Oに関してはテストが引き続き必要です。

C# のアプローチ：チームをスケールさせる生産性機能

C# は単純な考えに沿って成長してきました：「普通に書く方法」が最も安全で読みやすい方法になるようにすること。コードベースが一人の頭に収まらなくなり、複数人で保守する共有システムになるときにこれが効きます。

可読性と意図をデフォルトにする

モダンな C# は、ビジネスの意図のように読める構文を重視します。小さな機能の積み重ね（明確なオブジェクト初期化、データの「形」を扱うためのパターンマッチング、ネストした if を減らす表現的な switch 式）が合わさって、数十人の開発者が同じファイルに触れても部族知識の必要性を減らします。コードレビューは解読ではなく振る舞いの検証になるのです。

実務に合う安全性

スケーリング上の実用的な改善の一つにヌル許容性があります。C# は null を常に驚きとして扱うのではなく、意図を表現する助けをします：

• 「この値は決して null にならない」—消費者はそれを信頼できる。
• 「これは null かもしれない」—呼び出し側はその扱いを促される。

これにより多くの欠陥が本番からコンパイル時に移り、大きなチームでAPIが別の人に使われる場面で特に有効です。

Async/await の人間向け並行性

システムが成長するとネットワークやファイルI/O、バックグラウンド作業が増えます。C# の async/await は非同期コードを同期風に読みやすくし、並行性に伴う認知負荷を下げます。

コールバックをコード全体に引き回す代わりに、チームは「データを取得し、検証し、続行する」といった単純なフローを書けます。ランタイムが待ちを管理し、結果としてタイミングに関するバグや新人が学ぶべきカスタム慣習が減ります。

大規模ソリューションでも有用なツール群

C# の生産性ストーリーは言語サービスとIDE統合と切り離せません。大規模ソリューションでは、強力なツールが日常可能性を変えます：

• プロジェクト間を素早く移動（定義へ移動、参照を見つける）
• ソリューション全体の解析で破壊的変更を早期に検出
• 安全な自動リファクタリング（リネーム、抽出、シグネチャ変更）

これがチームが勢いを維持する方法です。IDEが「これはどこで使われているか？」「これを変えると何が壊れるか？」に確実に答えられると、開発者は改善を自発的に行えます。

成功しやすい（pit of success）一貫性

持続的なパターンは一貫性です：ヌル取り扱い、非同期フロー、リファクタリングといった一般的な作業は言語とツールの両方でサポートされます。その組み合わせにより、良いエンジニアリング習慣が最も簡単な道になります—まさにコードベースとそれを支えるチームをスケールさせる際に欲しいものです。

教える診断とエラーメッセージ（単に阻むのではなく）

コードベースが小さいときは曖昧なエラーでも「十分」かもしれません。スケールすると診断はチームのコミュニケーション手段の一部になります。TypeScript と C# はどちらも、ただ停止させるだけでなく「次にどうすればよいか」を示すメッセージを出すバイアスを反映しています。

「良い」エラーメッセージの特徴

有用な診断は次の3つの特徴を持つことが多いです：

• 実行可能（Actionable）： 次に取るべきステップを示唆する（「これを意味しましたか…」「ヌルチェックを追加してください」「非同期に変換してください」など）。
• 具体的（Specific）： 失敗のカテゴリではなく、期待される型や欠けているメンバー、対象のシンボルを明示する。
• 局所的（Local）： 問題の原因となる最小のコード領域を指すので、無関係なファイルを探索する必要がない。

圧力下でエラーは読まれることが多いです。学ばせるメッセージは往復を減らし、「ブロックされた時間」を「学習時間」に変えます。

警告 vs エラー：将来の自分を守るために警告がある

エラーは今の正しさを強制します。警告は長期的な健全性を守る場所です：非推奨のAPI、到達不能コード、疑わしいヌル使用、暗黙の any など。「今日は動くが将来壊れるかもしれない」問題を示します。

チームは警告を段階的に強化する運用ができます：初めは寛容にし、徐々に厳しくしていき、警告数が増えないように管理するのが理想です。

診断をチーム基準かつオンボーディングの資源にする

一貫した診断は一貫したコードを生みます。「ここではこうしない」という部族知識に頼る代わりに、ツールがそのルールを問題が起きた瞬間に説明してくれます。

これがスケーリング上の利点です：新人が見たことのない問題でも修正できるようになります。コンパイラとIDEがその場で意図を文書化してくれるからです。

パフォーマンスと増分性：大規模でもツールを速く保つ

コードベースが成長すると、遅いフィードバックは日々の税になります。それは単一の大きな問題として現れることは稀で、千回の待ち時間による死です：ビルドが長くなり、テストが膨らみ、CIパイプラインが短いチェックを一時間のコンテキストスイッチに変える。

実感できるスケーリング痛点

チームやスタックを問わずよく現れる症状：

• ビルド時間が伸びる（プロジェクトや生成コード、依存が増えるため）。
• テスト時間が膨張する、特に「全部走らせる」ことがデフォルトになると。
• CIフィードバックの遅延によりPRが積み、マージコンフリクトが増え、検証済みの結果に基づかないレビューが行われる。
• エディタの遅延（オートコンプリート、定義へ移動、リネーム）が発生すると開発者はツールを回避するようになる。

増分性が体験を変える理由

モダンな言語ツールチェインは「全部を再ビルドする」ことを最後の手段とみなします。基本アイデアは単純です：ほとんどの編集はプログラムのごく一部にしか影響しないので、ツールは以前の作業を再利用すべきです。

増分コンパイルとキャッシングは通常次を利用します：

• 依存追跡： どのファイル／モジュールが何に依存しているかを知る。
• 安定した中間結果： 解析済み構文木、型情報、コンパイル出力などを保持して再利用する。
• 賢い無効化： 変更した箇所とその派生だけを再計算する。

これは単にビルドを速くするだけではありません。大規模リポジトリでも「打ち込んでいる最中」に応答性を保てるからこそ“ライブ”言語サービスが成立します。

エディタ応答性を品質基準にする

リネーム、参照検索、診断が数秒かかるようだと人は信頼しなくなります—そしてリファクタリングは止まります。

フィードバックを速く保つ実践的手段

明示的な予算を設定しましょう（例：ローカルビルドはX分未満、主要エディタ操作はYms未満、CIチェックはZ分未満）。そして継続的に測定します。

その数値に基づいて行動します：CIのホットパスを分割し、変更を証明するための最小テストセットを走らせ、可能な限りキャッシュや増分ワークフローに投資します。目標は単純です：最速の経路をデフォルトにすること。

変化を前提に設計する：API、境界、保守性

大規模コードベースは通常、ひとつの悪い関数のせいで壊れるのではなく、時間とともに境界があいまいになることで失敗します。変更を安全に保つ最も簡単な方法は、API（内部APIも含む）を製品として扱うことです：小さく、安定して、意図的にする。

明確な契約（そして型が助ける理由）

TypeScript と C# の両方で、型は「これの呼び方」を明示的な契約に変えます。共有ライブラリが狭い入力、明確な戻り値形、意味のある列挙型を公開すると、暗黙のルールが減ります。

内部APIではこれはさらに重要です：チームの移動や所有権の変更でライブラリは読むだけでは追えない依存になり得ます。強い型は誤用を難しくし、リファクタを安全にします。呼び出し側がコンパイル時に壊れるからです。

境界で表面積を制御する

保守可能なシステムは通常レイヤー化されています：

• 公開サーフェス vs 内部： ほんとうにサポートするつもりのものだけを公開し、ヘルパーは非公開にする。
• モジュール／名前空間： 関連機能をまとめて発見しやすくし、偶発的な結合を減らす。
• 依存の向き： 高レベルのコードは低レベルのプリミティブに依存し、逆にはしない。

これは純粋なアーキテクチャの話というより、どこで変更すべきかを明確にするための実用的な手法です。

バージョニング、非推奨、チーム習慣

APIは進化します。計画しましょう：

• 新しいエントリポイントを旧来のものと並べて導入し、古いものを非推奨にして削除予定日を設ける。
• 共有パッケージのための軽量なチェンジログを保ち、アップグレードが考古学にならないようにする。

これらの習慣は自動化で支援します：内部インポートを禁止するリントルール、API変更のレビュー用チェックリスト、semverを強制するCIチェックなど。ルールが実行可能になると、保守性は個人の美徳ではなくチームの保証になります。

大規模コードベースをスケールさせるための実用的な要点

大規模コードベースが失敗するのは「間違った言語を選んだから」ではなく、変更がリスキーで遅くなるからです。TypeScript と C# に共通する実用的なパターンはシンプルです：型 + ツール + 速いフィードバック が日常の変更を安全にします。

コアテイクアウェイ

静的型は素晴らしい言語サービス（オートコンプリート、ナビゲーション、クイックフィックス）と緊密なフィードバックループ（即時のエラー、増分ビルド）と組み合わさったときに最も価値を発揮します。その組み合わせがリファクタリングをストレスの多い出来事から日常的な作業に変えます。

Koder.ai が DX の物語にどうはまるか

すべてのスケーリングの勝利が言語だけから来るわけではありません—ワークフローも重要です。Koder.ai のようなプラットフォームは「編集 → チェック → 修正」ループをさらに圧縮することを目指しています。チャット駆動のワークフローでウェブ、バックエンド、モバイルアプリを構築でき（WebはReact、バックエンドはGo + PostgreSQL、モバイルはFlutter）、結果は実際にエクスポート可能なソースコードとして得られます。

実務では、planning mode（変更前に意図を明確にする）、スナップショットとロールバック（リファクタを安全にする）、組み込みのデプロイ／ホスティング（カスタムドメイン付き） といった機能が、本記事のテーマに直接対応しています：変更コストを下げ、システムの成長に合わせてフィードバックをタイトに保つことです。

現実的に使える採用ロードマップ

1. ツール面の勝ちをまず取る。 IDE設定を標準化し、一貫したフォーマットを有効にし、リンティングを追加し、リポジトリ全体で「定義へ移動」やリネームが確実に動くようにする。

2. 段階的に安全性を追加する。 型検査を最も痛みのある箇所（共有モジュール、API、高頻度変更コード）で有効にし、時間をかけて設定を厳しくしていく。

3. 保護具を付けてリファクタする。 型とツールが信頼できるようになったら、より大きなリファクタに投資する：モジュールの抽出、境界の明確化、死んだコードの削除。コンパイラとIDEを活用して重い作業を任せる。

スケーリングがうまくいっている兆候

• 変更が予測可能：努力量を見積もれる。\n- リグレッションが減る：壊れる変更が早期にとらえられる。\n- リファクタが自信を持って行える：リネーム／移動／抽出が退屈で怖くない。\n- 新人がより早く生産的になる：コードベースが型とツールで自己説明的になっている。

実用的な次の一手

次の機能の一つをピックしてパイロットにしてください：触る領域の型を強化し、CIでグリーンを必須にして、着手前／後でリードタイムとバグ率を計測します。

もっとアイデアが欲しければ、関連するエンジニアリング記事を /blog で参照してください。