200ページ超のベストプラクティスを巨大組織に浸透させるには？
ダイキン工業の戦略経営計画においては、ソリューション事業の推進が最大のテーマとして挙げられている。この方針のもと近年では、各事業部、各拠点でAWSを用いたクラウドソリューションの開発に取り組んできたが、その過程において「大きな課題が見えてきた」と幸浦氏は語る。
その課題とは、クラウドソリューション開発の標準的な設計が存在しないため、アーキテクチャが不安定だというものだ。基本指針がないと、開発者自身の能力がそのままソリューションの性能へと反映されてしまい、特定の優秀な技術者・ベンダーへ依存したり、拠点ごとに性能・品質にぶれが生じたりといった事態につながる。さらには拠点部門ごとに技術スタックや技術レベルが異なるため、過去に起きた不具合・トラブルの共有やアップデートが難しいという問題もあった。
こうした状況から脱却するには、設計の標準化を進めるほかない。幸浦氏はここで、標準化の青写真をピラミッド構造で定義したうえで、抽象度別に4段階の成果物を設定した。
最初に取り組んだのは、メインクラウドサービスとなっているAWSのベストプラクティスの設定だ。社外の有識者と協力してダイキン工業における標準的なAWS実装を策定し、アプリケーションを効率的に構築するポイントから、セキュリティ対応など機能的なところまで盛り込んだ。
ベストプラクティスをまとめるにあたっては、重要な点を各章の冒頭に明示することで読みやすく工夫したほか、ダイキン工業の社内規定を参照したプラクティスも記載した。AWS社と共同で内容の定期アップデートも行なっており、「非常に質の高いものができた」と胸を張る。
その一方で初学者には難解な部分も多く、ドキュメント自体も200ページを超えることから、幸浦氏自身も「全員が完璧に理解することは非現実的」としている。加えて実際の開発ではドキュメントの内容に立脚したうえで、プロジェクトの特色やシステムの要件に応じて臨機応変な対応が求められる。この点に対処すべく、幸浦氏はベストプラクティスに従った参考実装（リファレンスアーキテクチャ）も作成した。
実例として挙げられたのは、3層からなるリファレンスアーキテクチャとデータストリーミングだ。前者はAmazon Virtual Private Cloud内にWeb・AP・DBの3サーバーを持つ最低限の構成のアーキテクチャをデプロイするだけで使えるというものだ。後者はDBに溜まったデータをAmazon Kinesisに集約し、Enrich用AWS Lambdaで解析・分析のための属性データを付与し、JSON形式でAmazon S3に格納する仕組みだ。イベント通知でAmazon SQSを発行し、別のLambda関数で次の処理を行うパイプラインになっている。
「ダイキン工業のシステムで、使用頻度の高そうなものから随時リファレンスアーキテクチャとして作成を進めていった」と振り返る幸浦氏。標準化に向けてさまざまなアウトプットを行ったものの、成果物を作った後もさまざまな課題があったという。
