本記事の概要
プロジェクトを主導する中で、自分が最も得意とする言語やフレームワーク（私の場合、JavaによるWebシステム開発）以外の領域をパートナー企業に依頼する場面は多く存在します。
今回のプロダクトでは、WebUIのフロントエンドにVue.jsを採用しました。型の厳格化やコンポーネント構成の詳細は外注チームに委ねて開発を進めましたが、仕上がってきたシステムでは「バリデーションの不備」や「ライブラリの制約による仕様未達」といった品質上の課題が発生しました。
今回は、自分の理解が浅い領域において、いかにして技術的な課題を外注チームと共に課題を解消したのか、下記項目に分けて記載しています。
- 共通言語を定義する
- 根本技術で考える
「HWとSWが密結合するIoTシステム」の開発に基づいています。
このシステムは、センサーが取得した生データ（物理量）をバックエンド等で高度に加工・分析し、ユーザーに意味のあるデータとしてWebUI（Next.js）上の時系列グラフに可視化・制御する構造を持っています。
1人目のSWエンジニア兼PMとして、この不確実性の高い開発をコントロールした知恵を共有しています。
MDNを共通言語とする相互理解
フォーム等のバリデーション不足に対して、「もっとしっかりチェックしてください」と指摘をした際に、どことなくピンと来ていない様子でした。
会話を続けるうちに「バリデーション」という対処についての理解があっていないことがわかりました。そうなると、これ以上抽象的な指示を出しても品質は上がりません。
また、専門外のフレームワークであることはパートナー企業にも話していたので、説得力を欠いてしまいます。
そこで私は、Web標準規格の共通認識を作るため、MDN（Mozilla Developer Network）に記載された公式の仕様や技術ドキュメントを提示しました。基盤となる技術の原理原則を共有し、その上で具体的なバリデーション仕様を定義・提示することで、認識ズレを排したクリアな受入基準を構築しました。
JavaScriptを使用した代替案の検討
開発の過程で、採用していたライブラリの制約により「要求仕様が満たせない」という課題が発生しました。パートナー企業から「ライブラリの仕様上難しい」と報告された際、そのまま鵜呑みにして仕様を諦めるのはPMの敗北です。
私はVueのライブラリの表面的な機能だけに頼るのではなく、「ライブラリの枠組みに依存しない標準的なJavaScript/DOM操作やバックエンド連携でどう代替できるか」のロジックを思考し、自ら具体策を提案しました。フレームワークの知識が浅くても、プログラミング全体の構造やデータフローを理解することで、課題に対しても解決策が提示でき、類似の仕様実装を達成できました。
振り返り
成果
専門外の技術領域を扱う際、PMやテックリードに必要なのは「そのフレームワークの書き方を暗記していること」ではありません。
「技術の基本仕様（MDNなど）に立ち返って対話すること」、そして「ライブラリに振り回されず、ロジックの本質から代替案を示すこと」、この姿勢こそが、どんな技術スタックであってもパートナー企業から信頼され、高い品質を担保するための鍵になると考えています。
パートナー企業と双方納得した形で仕様を満たすことができました。
振り返り
- ホワイトペーパーは共通言語として機能する（個人の感想にならない）
- 基礎技術を学習することはフレームワークやライブラリに依存しない武器となる
- 「基礎」自体が更新、進化していることも事実であり学び続けることが必要