ブラザー工業、全社IoT基盤の長期運用を前提に機能の見極めや属人化の排除を徹底

開発メンバーの入れ替わりを想定し属人化を避ける

　IoT基盤の開発において重視したのが長期運用である。瀧尻氏は「10年先を見据え、開発メンバーが入れ替わるなど人材の変化に対応できるよう工夫した」と強調する。

　属人化の回避策としては、まず開発したプログラムのデプロイ作業を標準化した。「デプロイ作業は緊張を伴い、本番環境でプロファイルやリージョンを間違えるリスクがある」（瀧尻氏）ことから、自動化ツール「GitHub Actions」（米GitHub製）を採用。「手作業でのデプロイを数クリックで間違いなく実行できるため、各段階のデプロイはチームメンバーが交代して当たるようにした」（同）

　人材の入れ替わりには「スクラム開発のプロセスが透明性の確保に効果的だった」と瀧尻氏は話す。「プロジェクトの全バックログ内容をメンバー全員が見られるため、知識・スキルの偏りが平準化され、どのバックログでも担当できるマルチロール化につながった」（同）とする。

　インフラの構成定義では「リソース定義ツール「AWS CDK」（米AWS製）によるコード化を徹底している」と瀧尻氏は説明する。「全員でレビューしたCDKコードだけを唯一の定義とする」「手動変更は禁止する」という方針を掲げ「環境間の差異や属人化しやすい設定を排除した」（同）という。

　さらに設計判断の理由をADR（Architecture Decision Record：アーキテクチャー決定記録）形式で記録している。「なぜそのときに、そう判断したのか、どこまでを考慮したうえで、そう判断したのかなどが、結果以上に大切な情報になる」（瀧尻氏）との判断だ。

　システムの複雑化を避けるために「IoT基盤の責務を明確に定義している」と瀧尻氏は強調する。「IoT基盤は土管としての本分を忘れず、追加機能を検討する際は、IoT基盤側に持たせるべきかをよく考え、安易に肥大化させないようにしている。先日も、ある要素を追加するかどうかを深く議論をし『追加しない』という決断を下した」（同）という（図2）。

図2：IoT基盤は長期運用を視野に、シンプルで変化に対応できる仕組みにした

　実装言語に「TypeScript」を選んだのも複雑化を避けるためである。「記述する数値や文字列をあらかじめ型付けできるという利点を評価した」（瀧尻氏）。加えて役割ごとにレイヤー（層）を分けて設計する「レイヤードアーキテクチャー」を採用することで「どのコードでも同じように読め、同じように書けるプログラムの統一性を確保した」（同）としている。

　運用面では「複数環境の効率的な管理に注力した」（瀧尻氏）。従来は3つの段階を複数のリージョン（環境）にデプロイし、合計10を超える環境を運用していた。それを「Amazon CloudWatchのクロスアカウント機能を使って監視ダッシュボードを1つのアカウントに集約した」（同）という。

10数年のスパンで次世代に入れ替えられるように

　新たに構築したIoT基盤を瀧尻氏は「それ自体は永続的なものではない」と考えている。「いつかは古くなってしまうとの認識から、10数年のスパンで次世代に入れ替わっていけるよう準備したい」（同）と力を込める。

　将来の移行に備えIoT基盤が発行する各種の識別子には世代識別子を持たせている。瀧尻氏は「新旧どの基盤にアクセスを振り分けるべきかを判断できる仕組みだ。IDを見れば、どの世代のIoT基盤が管理する対象かが分かる」と説明する。

　プロジェクトを振り返り瀧尻氏は、成功のポイントとして次の3つを挙げている。

●「今日取らなかったデータは明日取れない」としてスピードを重視する
●「何ものも永遠ではない」として持続可能な設計が必要である
●ともに挑戦し、学び、感謝できるチームを作る