本記事の概要
本記事では私が開発に携わったシステムにおいて専門的な技術ロジックの仕様理解で行ったことを、下記項目に分けて記載しています。
- 実装担当の分担
- 再現性試験での品質担保
- 原理理解による自走力の定着
「HWとSWが密結合するIoTシステム」の開発に基づいています。
このシステムは、センサーが取得した生データ（物理量）をバックエンド等で高度に加工・分析し、ユーザーに意味のあるデータとしてWebUI（Next.js）上の時系列グラフに可視化・制御する構造を持っています。
1人目のSWエンジニア兼PMとして、この不確実性の高い開発をコントロールした知恵を共有しています。
役割分担によるリスクヘッジ
誰が考えるのか
まず考えたのは、ロジックを誰が考えるのか、というということです。
信号処理、という確立している分野の理論をソフトウェアに実装するわけですが、理解度によってリスクも異なります。
自社としてこれまでC#アプリケーションで実装していることもあり、開発言語は異なるけれどロジックは確立している状態でした。
そのため、センサーから上がってくる「物理量」を、ビジネスとして「意味のあるデータ」へと加工・分析するコアな信号処理ロジックは、私自身がバックエンドを担当し、API側で完全に吸収する設計にしました。
これにより、フロントエンド側（Next.js）の責務を可能な限りシンプルにし、外注チームが「データを受け取って描画する」ことに集中できる環境を整えました。
再現性試験による品質担保
フロントエンドにも物理量の解析機能が必要
センサーデータのコアロジックを私が実装するとしてもフロントエンドにも解析機能を持たせる仕様となっていたので、パートナー企業には私の実装したコードを展開して実装してもらいました。
ただ、開発言語がバックエンドはPython、フロントエンドはTypeScriptだったのでライブラリなどの問題で完全に同じロジックになるわけではない点が懸念点でした。
異なる開発言語でのロジック間で再現するか
ロジックは私のコードをもとに動作するものが出来上がったように見えますが「解析機能」であるため、開発言語が異なるかといって大きな乖離は許されません。
そこで、検証用のサンプルデータを連携し、フロントエンドの環境でも「同じデータを使って同じ計算結果が再現できるか」を定量的に評価しました。この評価を行うことでバックエンド、フロントエンドで解析精度が異ならないことを担保しました。
原理の理解による自走力強化
コピペでいいのか
コア機能が出来上がって、目立った不具合もなくてそれでいいのか、と言うとそういうわけではありません。
開発が終わると保守運用が待っているのでそこにも目を向けて開発段階から対応していく必要があります。
今のままでは開発言語に最適化したとはいえコードをコピーしただけとなってしまい、不具合が発生した場合に調査の質が担保できなくなってしまいます。
今後のために原理を理解する
私は、ロジックのベースとなっている技術ドキュメントや構造図を用意し、オンラインMTGで「なぜこの処理が必要なのか」という原理原則から説明する時間を設けました。
パートナー企業を単なる「作業者」として扱うのではなく、技術の背景を共有して認知の解像度を揃えることこそが、最大の品質管理（ガバナンス）になると考えたからです。
振り返り
成果
専門的なロジックについて、ただ仕様を説明するだけでは実装から開発、保守にかけてリスクが拭い去れません。
まずはリリースまでのリスクを最小化するために有識者がロジックを作り、評価を行う方針で考えたのは当時の進捗的にも適切なコントロールだったと思います。
教訓
- 専門的なロジックがある場合は有識者から確度の高いロジックを提供する
- 開発言語が異なる場合で同様機能を実装する場合は比較試験を行う
- 開発言語が異なる場合はどちらかの言語に統一できるか検討する（今回はバックエンドのPythonをTypeScriptにしてもよかった）