2018年を振り返ると、一言で表すなら「体系化」です。年初はプロジェクトごとに車輪の再発明を繰り返していましたが、年末には再利用可能なエンジニアリング体系が整っていました：統一されたビルド方法、プロジェクト横断で共有できるコンポーネントライブラリ、チームレベルのコード品質規則。技術的な負債もかなり解消でき、基盤整備もほぼ完成しました。総括する時期が来ました。
一、年間の技術マイルストーン
TypeScript の全面的な導入
年初、主力の中後台プロジェクトに TypeScript を導入する決意をしました。当時チームの抵抗は小さくなかったです——「型を大量に書いて何の意味があるの」という声が最もよく聞こえてきました。
推進戦略は段階的に：まず新しいモジュールで使い始め、徐々に既存のコードを改修しました。2ヶ月後、インターフェースの署名を変えてリファクタリングすると、エディターがすべての影響を受ける呼び出し箇所を即座に示してくれて、チームの態度は懐疑から依存へと変わりました。年末時点でプロジェクトの TypeScript カバー率は70%を超え、コアビジネスモジュールは完全に対応しました。
Webpack 4 への移行
Webpack 3 から 4 へのアップグレードは、単なる設定変更ではありませんでした。プロジェクトのコンパイル時間は平均 120 秒から 40 秒に短縮され、splitChunks でスマートなコード分割を行ったことで、ファーストビューの JS サイズは 680KB から 420KB に圧縮されました。同時に統一されたビルド設定を build-scripts パッケージとして整備し、新プロジェクトの初期化時間が半日から 30 分に短縮されました。
Vue の深化と React の探索
Vue については響応式の原理とコンポーネント設計パターンを深く掘り下げ、社内コンポーネントライブラリの設計から公開までの全工程を主導しました。同時に React を体系的に学び始めました——Vue を置き換えるためではなく、技術選択においてより合理的な判断ができるようにするためです。年末にデータ可視化の要件を受けたとき、React + D3 のアプローチが Vue での実装より滑らかで、デュアルフレームワーク能力の実際の価値が証明されました。
Node.js BFF レイヤー
年末から BFF（Backend for Frontend）ミドルレイヤーの構築を開始し、Koa でインターフェースの集約とデータ変換を行いました。まだリリースしていませんが、完全なフローを通しで動かし、フロントエンドとバックエンドのレイヤー分離の実現可能性を検証しました。
二、エンジニアリングの成果
コンポーネントライブラリの構築
@company/ui コンポーネントライブラリを主導して完成させ、テーブル、フォーム、フィルター、チャートコンテナなど 40 以上のビジネスレベルのコンポーネントをカバーしています。設計思想は「UI ではなくビジネスパターンをカプセル化する」というもの——例えば <SmartTable> はソート、フィルタリング、ページネーションの完全なインタラクションをカプセル化しており、ビジネス層は列定義とデータソースを設定するだけです。
現在 5 つのプロジェクトが導入済みで、コンポーネント再利用率は 60% に達しています。新プロジェクトの UI 開発工数は平均 40% 削減されました。
ビルド最適化のデータ
| 指標 | 年初 | 年末 | 改善 |
|---|---|---|---|
| コンパイル時間 | ~120s | ~40s | 66% |
| ファーストビュー JS サイズ | 680KB | 420KB | 38% |
| 新プロジェクト初期化 | ~4h | ~30min | 87% |
これらの数字の背景には HappyPack マルチスレッドビルド、SplitChunks コード分割、tree-shaking、ModuleConcatenationPlugin（スコープホイスティング）の総合的な活用があります。
コード品質ツールチェーン
ESLint + Prettier を導入してコードスタイルを統一し、husky + lint-staged でコミット前チェックを実施しました。チームのコードスタイル論争はほぼゼロになりました——ルールは設定ファイルに書かれているので、Code Review でいちいち口論する必要がありません。
三、コード品質の進化
型システムとエラーハンドリングの変化が成熟度の向上を最もよく表しています。典型的な API 呼び出しを例にすると：
// 年初スタイル：動くが脆弱
async function handleSubmit() {
this.loading = true;
const res = await axios.post("/api/order", this.form);
if (res.data.code === 0) {
this.$message.success("送信成功");
this.$router.push("/orders");
}
this.loading = false;
}
// 年末スタイル：型制約あり、エラー分類あり、境界保護あり
interface OrderForm {
productId: string;
quantity: number;
remark?: string;
}
async function handleSubmit(): Promise<void> {
this.submitting = true;
try {
const order = await orderApi.create<Order>(this.form);
this.$message.success(`注文 ${order.id} が作成されました`);
this.$router.push({ name: "OrderDetail", params: { id: order.id } });
} catch (e) {
if (e instanceof ApiError) {
switch (e.code) {
case "STOCK_INSUFFICIENT":
this.stockError = true;
break;
case "ORDER_LIMIT_EXCEEDED":
this.$message.warning("注文上限に達しています");
break;
default:
this.$message.error(e.message);
}
} else {
throw e; // 非ビジネスエラーはグローバルエラーハンドラーに委ねる
}
} finally {
this.submitting = false;
}
}
変化は単に「型を追加した」だけではありません。核心的な変化は：API 呼び出しに戻り型制約があり、エラーにはビジネス分類の処理ロジックがあり、予期しないエラーが飲み込まれることなく、finally が状態の一貫性を保証しています。コードを書く心境が「動けばいい」から「3ヶ月後の自分でも読んで理解できるように書く」へと変わりました。
四、チーム協働の経験
Code Review 文化
年中頃からチームで Code Review を推進し始め、初期は抵抗が大きかったです。転換点は、最初の Review で N+1 リクエストのパフォーマンス問題を発見したときでした——フロントエンドがダイアログを開くたびに 50 件の並行リクエストを発生させており、修正後にダイアログの読み込みが 3 秒から 0.5 秒に短縮されました。実際のデータで話す方が説教より効果的です。
年末には Code Review がチームの習慣になり、PR のマージには必ず誰かの Review が必要になりました。さらに重要なのは、Review の内容が「セミコロンが足りない」から「この抽象化レベルは適切か」「この状態管理方法に最善策はあるか」へと変わったことです。
知識共有
チーム内で 4 回の技術共有を行いました：TypeScript の実践、Webpack 最適化戦略、コンポーネントライブラリの設計思想、Vue パフォーマンス最適化。毎回の共有が自分の知識を体系的に整理する機会になりました。チームの他のメンバーにも共有を促し始め、「アウトプットがインプットを促す」学習の雰囲気を育てています。
五、未達成の反省
率直に言って、今年あまりうまくできなかった部分がいくつかあります：
テストカバー率はまだ低いです。コアロジックの一部に単体テストを書きましたが、日常的な習慣にはなっていません。コンポーネントライブラリのテストはそれなりに整っていますが、ビジネスコードのテストはほぼありません。これは怠けているのではなく、優先度の判断です——今年はまず「0から1」のエンジニアリング基盤を解決することを優先し、テストは「1から10」の品質保証として 2019 年に取り組みます。
CI/CD パイプラインはまだ運用担当者が管理しています。Jenkins への理解は「設定を変えれば動く」レベルにとどまっており、自動デプロイ、環境管理、ロールバックなどのフローをまだ体系的に習得できていません。これはアーキテクト視点で補うべき能力です。
ドキュメント体系が不十分です。コンポーネントライブラリには README がありますが、完全な使用ドキュメントと API 説明がなく、コンポーネント間の設計上の決定も記録されていません。新しいメンバーが加入したとき、ドキュメントの重要性を痛感しました——「なぜこうなっているのか」は書いた人しか知らないのです。
これらの問題を失敗とは見ていません。「エンジニアリング体系の構築」と「エンジニアリング体系の成熟」の間の距離が見えてきたということです。2019 年の目標はその距離を縮めることです。
六、2019年の計画
技術の深化
- テストの体系化：コンポーネントライブラリに完全な単体テストを整備し、ビジネスコードのテストカバー率目標 60%+。E2E テスト（Cypress や Puppeteer）の探索。
- CI/CD の自主管理：フロントエンド専用の CI/CD パイプラインを構築し、lint、test、build、deploy の全フロー自動化を実現。
- React の深化：使用レベルにとどまらず、hooks のソースコードと Fiber アーキテクチャを深く理解する。新しいプロジェクトを React でゼロから構築し、クロスフレームワーク経験を積む。
- 監視とアラート：フロントエンド監視体系を構築し、エラー捕捉、パフォーマンス指標、ユーザー行動追跡をカバー。設計段階から取り組み、サードパーティ SDK を導入するだけでは終わらせない。
アーキテクチャ能力
- マイクロフロントエンドの調査：チームのプロジェクトが増えるにつれてデプロイと保守コストが上昇しています。マイクロフロントエンド方案（qiankun / Module Federation）を評価し、現在の技術スタックに適合するか検討する。
- BFF レイヤーのリリース：年末の Koa BFF プロトタイプを本番対応に仕上げ、フロントエンドとバックエンドのデータレイヤー分離を実現。
- コンポーネントライブラリのドキュメントサイト：コンポーネントライブラリのドキュメントサイト（Storybook 類似）を構築し、API ドキュメントとインタラクティブなサンプルを整備。
チームビルディング
- Code Review のルールをチームの Wiki に書き込み、新しいメンバーが自動的にフローを把握できるようにする。
- 「毎週技術共有」の仕組みを確立し、チームメンバー全体をカバー。自分一人のアウトプットに依存しない。
- 技術方向を独立して担当できる人材を 1〜2 名育成し、「アーキテクチャ」を個人の能力からチームの能力へと転換する。
まとめ
- TypeScript の全面的な導入。プロジェクトカバー率 70%+、リファクタリング効率とコードの信頼性が大幅向上
- Webpack 4 移行完了。コンパイル速度 66% 向上、ファーストビューサイズ 38% 削減
- コンポーネントライブラリ構築を主導。40+ ビジネスコンポーネント、5 プロジェクトが導入、新プロジェクトの UI 工数 40% 削減
- Code Review 文化の定着を推進。形式化から実質的な技術議論へ
- テストカバー率、CI/CD、ドキュメント体系は来年必ず補うべき弱点
- 2019 年のコア方向：品質保証の体系化 + アーキテクチャ能力の拡張 + チームへの技術継承