執筆者
S.M.
実証概要
今回はモビリティ関係の実証実験について、ブログを書いていこうかと思います。実施事項の全てや詳細の記載はできませんが、雰囲気や私が反省したこと、感じたこと、学んだことが伝われば幸いです。半分反省文みたいになってしまっておりますがご了承ください。
まず、本実証試験は実証フィールドにて関連企業数社が合同で行ったものとなります。弊社とPoCの受注契約を結んでいるクライアント様が他方の企業様に実証を依頼し、必要なシステムや環境を用意していただきました。そのフィールドでの実証試験は4日間にわたり、弊社では比較的大規模な実証試験でした。
この実証試験に向けて私は先方からご要望のあった課題解決に関する機能実装と社内完結の野外検証およびシステムの動作確認を行い、当時の私は万全の準備を行ったと考えておりました。
1・契約締結
クライアント様とPoCの受注契約
2・環境準備
他企業様による必要なシステムと環境の用意
3・機能実装
課題解決に関する機能の実装と検証
4・実証試験
連続4日間にわたる大規模な実証試験の実施
実証試験の反省と他社エンジニアからの刺激
きたる実証試験本番
1日目に弊社システムの不備が発覚し、2日目の昼頃までその対応に追われることとなりました。この原因としては、追加実装時と動作確認時にごくごく限定されたテストケースのみを扱っていたため、実証試験現場の環境にうまく適用できなかったことが挙げられます。こちらに関して、部長からは「環境や条件によって変わるもの、変わらないものをしっかりと見極めて、変わる可能性のあるものを変更・調整できるようなシステム構築を心がけなさい」というご指導をいただきました。
また、同じく初日にシステム間の通信不良、2日目にも通信遅延が確認されました。初日の通信不良に関してはなんてことはないただのファイアウォールにブロックされていたことがわかり、通信遅延は送信部の重複送信と送信サイクルによる影響であることが実証試験後の後日発覚しました。事前の動作確認時に発覚しなかったのは、ネットワーク構成が本番とテスト時で変わっていたこと、そのネットワークを構築するPCのOSが異なっていたことが原因です。動作確認時のネットワーク構成およびシステム構成は本番とできるだけ近づけることで事前に検知できたと考えております。
実証試験中の他社エンジニアからの刺激
ここからは他社のエンジニアと合同で実証試験に臨んで学んだことを共有します。
2日目と3日目の前半にかけて他社システムにも不具合が生じたのですが、他社のエンジニアの方の対応がとてもスマートで憧れました。不具合が発生した時でも自信を持って理路整然と仮説を立てて検証を行う、基本的なことと言われればそうなのですが、初日の弊社側システムの不具合発生時には私は普段の状況であれば出来ることも現場緊張感の中では思うように頭も体も動きませんでした。自身の開発しているシステムの各モジュールについて、どのような目的・背景があり、どういう流れで処理を行い、その過程でどこにどういう影響があるのかを把握しなければ、不具合が生じたときに関連している場所はここだからここを確認・修正すればいいということが明確に把握できないと思います。
①コンパクトな実装
機能を実現するのに必要十分でコンパクトな実装
②整頓されたコード
人が管理しやすいアーキテクチャで整頓されたコード
③充実したドキュメント
システムの理解を助けるドキュメント
そして、それを可能としているのは、機能を実現するのに必要十分でコンパクトな実装、人が管理しやすいアーキテクチャで整頓されたコード、そしてそれらシステムの理解を助けるドキュメント、これらなのではないかと考えています。関連知識を学習し、実践を通して身につけ、実務に活かしていけるように精進していきたいと思います。若輩者ではありますが、せめて一般的なエンジニアに比べて見劣りしないくらいのエンジニアにはなりたいですね。
実証試験報告会
安堵と達成感
そんなこんなでトラブル続きの実証試験でしたが、最終日にはシステムの不具合も解消され、ようやく先方が望んでいた試験を行うことができ、期待したような挙動が確認できました。その日は本当にホッとした心持ちで、その夜に食べた400gステーキはとても美味しかったです。
学びと成長
さて、これで実証試験自体は終了しましたが、その後１週間足らずで提出された43ページの報告書も完成度が高いものでした。実証試験に直説関わったメンバーだけでなく外部の方も理解できるような丁寧な報告書でこの量と質をこの短期間で仕上げられるのかと感嘆しました。この報告書の構成や内容は今後報告書を作るにあたって大いに参考になると感じました。また、先方からの「トラブルが頻発したので時系列にまとめてどれが信用できるデータなのか区別したい」というご要望ももっともに感じましたので、今後(そういう機会がないようにしたいとは思いつつも)そういう機会があった場合には、データとトラブルを時系列にまとめ、信用できるデータとできないデータに区別して報告したいと思います。
報告書の特徴
・43ページの高品質な内容
・1週間足らずで完成
・外部の方も理解できる丁寧さ
・時系列でのデータ整理
今後への活かし方
・報告書の構成を参考にする
・トラブルを時系列にまとめる
・信用できるデータを区別する
・システムのブラッシュアップ
この他にも、懇親会での衝撃的なお話や技術トレンドなどの勉強になるお話などもありましたが、今回の実証試験は非常に得難い経験として、色々と思い出深いものとなりました。後続の実証試験に向けて、今回反省したこと、学んだことを活かして、システムのブラッシュアップをしていきたいと思います。
