はじめに
アンケートモニタのログ集計基盤開発と運用を行っている長澤です。
前回投稿した記事『注目のAWS、マクロミルが導入した「AWSクラウド学習支援プログラム」とは』に続いて、今回はAWSのナレッジを高めるためにマクロミルのIT部門で毎年行っている定期プロジェクト『Technology Task』についてご紹介したいと思います。
前回の記事でご紹介の通り、マクロミルのシステムは一部除いてほとんどがAWSクラウドを利用したインフラ構成となっています。また、アーキテクチャ設計や利用サービス選定も社員主導で行っています。
自分も上記に漏れず、AWSコンソールにアクセスしない日はないくらい、AWSサービスを利用しています。技術ブログをご覧の方々の中でAWS基盤のシステム開発に携わっていれば珍しいことではないと思います。
自分には、業務の中でAWSを利用するからこその悩みがあります。
それは「仕事で使っていないAWSサービスはどのくらいあるだろう？使ったことのないサービスではどんなことができるんだろう？」というもの。
AWSが毎年開催するカンファレンス「re:Invent」をご覧になったことのある方であればご存知の通り、AWSは毎年とんでもないスピードで新サービスのリリース、既存サービスへのアップデートがなされています。正直な話、すべてのサービスを把握することは難しいと思います。通常システムは開発と運用・保守がセットになっているため、新しい技術を取り入れる開発に携わり続けることはレアケースです。そんなわけで、利用したことのないサービスが裏で増え続けていると思うと上記のモヤモヤが出てきてしまうのです。
意識高く技術トレンドのキャッチアップを行っている方はプライベートで新しい言語、ライブラリ、フレームワーク、AWSサービスを使ったりもすると思いますが、特にAWSサービスはコスト的な側面で使ってみたくても使えない、みたいなことがありませんか？
マクロミルにはそんなモヤモヤを解消してくれるIT部内プロジェクトがあります。
それが『Technology Task』です。前置きが長くなりすみません！
『Technology Task』とは
Global IT部内であれば誰でも参加可能な任意の部内プロジェクトです。
プロジェクト目的は大きく以下の通りです。
- 「新技術」に触れることによるIT部門・人材としてコアバリューアップ
- AWSや他のトレンド技術を含む「新技術」へのチャレンジ
- IT部門間のコミュニケーション促進
上記で述べている「新技術」とは、言語・環境・フレームワークによらず既存の社内システムで利用の無い、導入実績が無い技術すべてを指します。
新技術を利活用し、結果として何か形になるものをアウトプットすることがゴールで、そのプロセス自体に焦点が置かれているため、仮にアウトプットからビジネス価値が生まれなくても、プロジェクトとして失敗ではありません。
過去には以下がキーワードとして挙がり、実際にテーマとして採用されました。
- 自然言語処理 → 形態素解析と機会学習を用いた誤字修正アシスト
- 機械学習 → インプット画像ファイルへの特定処理自動化
- Amazon Alexa → 音声認識による実運用中開発環境サーバのコントロール
- Webクローリング/スクレイピング → 特定画像の収集自動化
ちなみに記事サムネイルとなっている画像は「人感赤外線センサ」で、このセンサの他にAWSサービス「IoT Core」と小型コンピュータ「Raspberry Pi」を組み合わせ「会社の会議室の空き状況をリモートで把握する」という題材に挑んだ際に撮影されました。（コロナ禍になってこのテーマ需要は減ってしまったかもしれません…）
AWSオフィスで行ったAWS社員の方との合同ミーティング風景
（コロナ禍前に撮影されたものです。現在では合同ミーティング含めすべてオンライン実施です）
『Technology Task』で利用するAWSサービスの中では、比較的新しいものが多く公式ドキュメントだけでは利用イメージが湧かないケースがあります。その場合は上記のようにAWSのソリューションアーキテクトの方とコミュニケーションを取りながら進めていきます。
『Technology Task』のプロジェクト概要
毎年細かい部分で変更はありますが、以下のマイルストーンで進めています。
1.ビジネスサイドからの課題収集／計画
開発側で抱えている課題だけでなく、ビジネスサイドにも定常業務での悩みや課題がないか予め伺います。
2. 取り組み課題選抜
上記の課題を対象に、既存システムで未利用の技術やAWSサービスを使えば解決できそうなテーマをピックアップします。大まかに実現可能性があればこのフェーズとしては良しとしています。
3. 技術選定・開発方針策定
上記で利用想定のAWSサービスに詳しいAWS ソリューションアーキテクトの方ともコミュニケーションを行いつつ、決められた期間で開発できそうなアウトプットを決め、同時にインフラ構成を練っていきます。
4.設計・開発
方針に沿って設計と開発を進めます。実装フェーズで初めて課題が浮き彫りになる／実現が難しいケースもあります。その場合、他の選択肢がないか再度検討するため前のフェーズに戻ります。
5.テスト
上記「設計・開発」で作成されたものが動作するか検証します。
ここでは運用に載せた際に、検証やフィードバックが可能なレベル稼働する水準が求められます。
さいごに
今回はプロジェクト自体の紹介がほとんどだったため、具体的な技術に関して記載できませんでしたが、次回以降では上記実際に過去行われたテーマで具体的に利用したAWSサービスや実装方法、課題ついてお伝えする予定です。お楽しみに！
