「想定通り」とはならないリファレンスアーキテクチャの実装
その最たるものが「使ってもらえない」という問題だ。リファレンスアーキテクチャもいきなり使用するにはハードルが高かったのだ。さらに開発者が各拠点・各部署に点在している体制では、全体に周知する仕組みがないため、「多くの社員は存在すら知らなかった」。
こうした状況のなか、化学事業部からの個別支援依頼が状況好転の足掛かりとなった。「リファレンスアーキテクチャがある程度適用できそうな見込みがあり、利用者からのフィードバックも得られる好機だった」（幸浦氏）という目論見のもと、チームとしての導入実績作りも兼ねて、プロジェクトの周知活動の第一歩となる支援業務を実施した。
アーキテクチャの適用先は、物質反応データにおける解析業務だ。反応データの取得・成形・BIツールによる解析が業務の流れだが、各フローで技術検討を行う際のツールやサービス・フォーマットなどは定められておらず、チームや個人ごとにバラバラのツールを利用していた。それにより、データの比較や議論すら難しいといった問題が生じていたのだ。
「事業部の理想は、取得したデータに対して統一的・適切な処理が実行され、生成されたデータが一箇所に保存されるとともに、全開発者がそれにアクセスできること。これによって分析や議論が効率よく、活発に行われる状況を『あるべき姿』と定義した」（幸浦氏）。
事業部のニーズを受け取った幸浦氏はさっそく、リファレンスアーキテクチャをベースにAWSとGitHubを利用したデータ解析パイプラインを構築することで理想の実現を試みた。
ところが、最終的に実装したアーキテクチャは当初の想定からかなり変容したものになった。こうした「見込み違い」の理由について、幸浦氏は順を追って解説してくれた。
まずはドメインに対する理解不足。「システム開発あるある」ともいえるもので、開発側に化学の知識がなかったために、実際の使用形態を想定することが難しかったという点だ。開発側はAmazon S3に置かれるデータ1つにつきAmazon SQSを1つ発行するという流れを想定していたものの、開発を進めるとメタデータや実験計画のようなAmazon SQSを発行しないデータが存在することが発覚し、手戻り（再設計）が発生してしまった。
幸浦氏は「詳細な仕様を確認できていなかったことへの反省もある」としたうえで、「開発当初は考えていなかったが、不測の事態に対応できるよう柔軟な設計・実装を心がけることが大切だと痛感した」と、苦い経験からの学びを聴衆に伝えた。
