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 年のコア方向：品質保証の体系化 + アーキテクチャ能力の拡張 + チームへの技術継承