未経験から約半年でProfessional Cloud Architectを合格した振り返りをする

こんにちは、データAI部 Pythonエンジニアの工藤 ( id:irisuinwl ) です。

この度、Google Cloud の認定資格 Professional Cloud Architect に合格しました。
自分は去年の9月から Classi に join し、それまでオンプレミス中心で開発していたソフトウェアエンジニアでしたが、未経験から半年で資格を取得するに至りました。
本記事では、試験合格までに何を行い、何が効果的であったかを紹介したいと思います。

Professional Cloud Architect (PCA)の説明

PCAに馴染みのない方もいらっしゃると思うので、簡単にどう言った資格なのか、どのような試験範囲が出るのかを紹介します。

PCAとは、GCP を用いてソリューションを構築するクラウドアーキテクトの能力を認定する試験となっております。

Professional Cloud Architect は、Google Cloud の技術を組織が活用するために必要なクラウド アーキテクチャと Google Cloud Platform に関する専門的な知識を活かして、ビジネス目標を推進するスケーラブルで高可用性を備えた堅牢かつ安全な動的ソリューションを設計、開発、管理するスキルを持ったアーキテクトです。 Professional Cloud Architect

試験内容としては、顧客の抱えるビジネス課題・技術課題に対して、GCPのサービスとして何を選択すれば良いのかを選択形式で問われる試験となっております。
例えば、模擬試験の問題を抜粋すると

• Mountkirk Games は新作ゲーム用にリアルタイム分析プラットフォームを構築したいと考えています。新しいプラットフォームは同社の技術的要件を満たす必要があります。要件をすべて満たすことのできる Google テクノロジーの組み合わせはどれですか。
  • A. Kubernetes Engine、Cloud Pub/Sub、Cloud SQL
  • B. Cloud Dataflow、Cloud Storage、Cloud Pub/Sub、BigQuery
  • C. Cloud SQL、Cloud Storage、Cloud Pub/Sub、Cloud Dataflow
  • D. Cloud Pub/Sub、Compute Engine、Cloud Storage、Cloud Dataproc

と言った問題が出題されます。

出題される試験範囲は GCP のサービス全般と幅広い知識を求められます。例えば、以下のような区分となっております。

区分	GCPの関連サービス
Computing	GCE, GAE, GKE, Cloud Run, ...
Network	VPC, Cloud Load Balancing, Interconnect, ...
Storage	GCS, Cloud SQL, Bigtable, Firestrore, BigQuery, ...
Operation	Logging, Trace, Monitoring, Profiler, ...
ML/Bigdata	Dataflow, Dataproc, AI Platform, ...

受けようと思ったきっかけ〜 G.I.G. への参加〜

自分は、業務で GCP を初めて利用したため、開発時に色々とスキル不足を感じたので、 Googleさん主催のトレーニングである Google Cloud Innovators Gym( G.I.G. ) を紹介いただき、参加することとしました。

G.I.G. では、講義セッション、 Coursera の選択コース、Professional Cloud Architect or Professional Data Engineerの認定資格取得支援(いずれかの合格もプログラム修了目標)などを用いた、 GCP のトレーニングとなっておりました。
また、G.I.G. 専用の Google Chat チャットルームでのサポート、もくもく会や懇親会など、交流する機会もあり、滞りなく学習を進めることができました。
特に、毎回の講義セッションでは、ハンズオンで扱うサービスの概観とハンズオンと深く GCP を理解できる内容であったことに加えて、受講者全体の学習状況をモニタリングされており、モチベーションにも繋がりました。

全体的に、リモートという状況下でも非常に学習効果が高く、 PCA という目標に向かった学習をよくモチベートするトレーニングで、教育業界に携わる身として非常に参考となりました。

結果として問題なくトレーニングプログラム修了することができました。

どのような学習を行ったか

PCA 受験までに合格に寄与した学習内容を解説します。

ざっくり下記のように学びました。

• Coursera で GCP 全体のサービスの仕様を理解
• Qwiklabs を用いた勉強会を開き、演習を通してサービスの理解の解像度をあげた
• 社内サービスを作って、サービスの細かい仕様やアーキテクチャパターンを実践した
• 試験の過去問を解いて、理解に不足している箇所を対策した。

詳細を以下では解説していきます。

Coursera

GCP の概観は Coursera の講義で主に学びました。大体 2 ヶ月程度で完了しました。

受けたコースは以下です。

コース名	概要
Google Cloud Platform Fundamentals: Core Infrastructure	GCP の基本となるサービスを包括的に紹介するコース
Essential Cloud Infrastructure: Foundation	VPC と GCE の詳細を解説するコース
Essential Cloud Infrastructure: Core Services	Storage 系サービス, IAM, Cloud Operations の詳細を解説するコース
Elastic Cloud Infrastructure: Scaling and Automation	Interconnect, Cloud VPN, Cloud Load Balancing の仕様といった Network 系サービスの詳細と、 Deployment Manager 及び Terraform を利用したインフラ構築の自動化を解説したコース
Reliable Cloud Infrastructure: Design and Process	クラウドアーキテクチャを考える上での設計の考慮事項や要件定義を初めとして運用する上でのモニタリングまで、実践的な事項を解説するコース

これらのコースは PCA の試験範囲を網羅しており、GCP の知識が 0 の自分としては非常に有益でした。
範囲の網羅性のみならず、演習問題が豊富であったことと、 Qwiklabs というハンズオンプラットフォームによる GCP を利用した演習もあったので、 GCP サービスを深く理解できるコースとなっておりました。

また、試験のみならず日常業務に有益な内容ばかりでした。
特に、Reliable Cloud Infrastructure: Design and Process はアーキテクトの思想やどのように GCP で構築したサービスの運用を行うかについて言及しており、実際に GCP を用いた開発でも学んだ知識を活用する場面が多くありました。

Qwiklabs

GCP の理解を深めるために、 Qwiklabs を用いた勉強会を1ヶ月間、 GCP のインフラに携わってる方々と実施しました。
Qwiklabs

Qwiklabs は、クラウドサービスのハンズオンプラットフォームです。
ハンズオンの受講を行うと演習用のプロジェクトが自動でクラウドサービス上に配備され、クラウドリソースから自動でハンズオンの進捗と合否を判定できるサービスとなっております。

Qwiklabs の 1ヶ月サブスクリプションを頂く機会があったので、それを利用し、勉強会で目標コースを定め、各自が学んだ内容を発表するということを行いました。
勉強会では、以下のクエスト(ハンズオンの集まり)を行いました。 - Build and Secure Networks in Google Cloud - Perform Foundational Data, ML, and AI Tasks in Google Cloud - Engineer Data in Google Cloud

1ヶ月という期間でしたので 1 週間に 1 クエスト、 1 日 1 つハンズオンを行っていたような気がします。
この中でも Build and Secure Networks in Google Cloud は GCP のネットワーク系サービスを用いたアーキテクチャについて取り扱っており、学びが多かったです。
VPN制限と Identity-Aware Procy (IAP) との使い分けも考えるきっかけとなり、社内サービスを IAP 対応する取り組みなどにも繋がりました。

勉強会については、軽率に興味のある分野の勉強会を開くことができ、学んだことを現状のインフラにフィードバックすることができる環境が Classi にあったことが非常に大きかったように思えます。

GCPでサービスを作る

これが一番理解に繋がりました。実践が最強の学びな気がしてます。
入社してからおよそ以下のようなサービスをスキマ時間や自己啓発で構築してました。

• Cloud Armor, Cloud Load Balancing, GCE(Instance Group) を用いたドキュメントサービス
• App Engine, Cloud SQL, Cloud Storage を用いたモデル管理サービス
• GKEを用いたデータ可視化サービス

それぞれ具体的なアーキテクチャを紹介します。

Cloud Armor, Cloud Load Balancing, GCE(Instance Group) を用いたドキュメントサービス

入社してすぐ作ったサービスです。自動生成した Sphinx ドキュメントをデプロイしたサービスとなっております。
以下のドキュメントを参考に作成しました。

• https://cloud.google.com/load-balancing/docs/https/https-load-balancer-example?hl=ja
• https://cloud.google.com/iap/docs/load-balancer-howto?hl=ja

Dockerでアプリケーションを作るのは1日で済みましたが、 VPC, Firewall, Cloud Load Balancing の設定などインフラ構築に1週間ほど手こずった記憶があります。

App Engine, Cloud SQL, Cloud Storageを用いたモデル管理サービス

ある日モデル管理機運が高まって MLflow を構築したものです。
色々と熟れてきて Terraform とか使い始めたり、 App Engine が便利だと知って構築したものです。
Terraform書くのに結構困ったりで1ヶ月くらいかかりました。

また、権限まわりで面倒があったり、 GKE で構築したい気持ちが高まったので terraform destory しました。

GKEを用いたデータ可視化サービス

割と最近作ったやつです。 streamlit による可視化サービスを作りました。
普通に Terraform で管理し、 GKE クラスタを作って誰でも爆速に GKE でプロトタイピングできるようにしようって思いで作りました。
アプリケーションは1日で作れましたが、インフラ構築に1週間ほどかかりました。

---

そんなこんなで入社して様々なサービスを構築してきましたが、やはり自発的に手を動かすことの学習効果は高いです。
また、GCP サービスを選定し設計する経験にも繋がるため、非常に有益になります。

自分が GCP 未経験から様々なサービスを作れたことは、 Classi が組織として

• GCPの有識者に気軽に聞ける環境であったこと
• 監査ログのアラートや Security Command Center といった不味い操作を検知できる体制が整っていたこと
• IAMで欲しい権限を依頼して迅速に対応してもらえたこと

が起因していると考えております。

試験対策

公式模擬試験と Udemy の Google Cloud Professional Cloud Architect Practice Test を利用しました。

模試を受けて理解の浅い部分を特定し再学習、再度模試を受ける形で対策を取りました。
特に手元で実践が難しかった Peering と Interconnect などは重点的に復習をしました。
試験受験前に公式模試は満点, Google Cloud Professional Cloud Architect Practice Test は6割解けるようになりました。

まとめ

PCA合格のためにどのような学習を行い、何が寄与したかを振り返りました。
包括的な理解と実践と学習を支援する環境が大きな要因と感じました。
特に、貴重な機会をいただけた G.I.G. 事務局の方々に多大な感謝を述べさせていただきます。

資格合格がゴールではなく、ここで習得した知識を活かして Classi をより良いサービスにしていくことに尽力していきたいと思います。

Sentryを活用するためにやっていること

フロントエンドエキスパートチームのlacolacoです。 この記事ではアプリケーション監視プラットフォームのSentryをClassiの中でどのように活用しているかを少し紹介します。Sentryの運用に悩んでいる方の参考になれば幸いです。

Sentryの用途

Classiでは大きく2つの目的でSentryを利用しています。ひとつはアプリケーションのエラーの監視（以後エラー監視と呼びます）、もうひとつはWebフロントエンドのパフォーマンスの監視（以後パフォーマンス監視と呼びます）です。

Sentryは多くのプログラミング言語用にSDKがあり、Classiでは主にJavaScriptとRubyのSDKを利用してフロントエンド・バックエンド両方のエラー監視を行っています。パフォーマンス監視は最近利用しはじめたのですが、バックエンドではもともとDatadogによる監視をしていたので、Sentryのパフォーマンス監視はフロントエンドだけで利用しています。

エラー監視の運用

Classiはプロダクトを開発運用するためのいくつかのクロスファンクショナルチームが構成されており、その各チームでエラー監視を運用することを推進しています。

エラー監視はやるべきとわかっていても運用を継続するのが難しいものです。その大きな原因は導入初期のエラーのノイズ、いわゆるS/N比の低さです。エラー監視のためにずっとSentryの画面を見つめているわけにはいきません。エラーの発生を検知して迅速に対応するにはアラートの整備が欠かせませんが、導入初期はアラートが多すぎて通知されるのが日常化してしまいがちです。そのため、アラートの整備と同時にS/N比を向上していく取り組みも同時進行することが重要でした。

Classiでエラー監視の運用を定着させるために最初にやったのは運用ガイドの作成です。運用ガイドには次のことを書いています。

Slackでのアラート監視

Sentryのアラートの通知先としてSlackを使うことと、その通知を見逃さないようにするためのポイントを書いています。

• 自分のチーム専用のアラートチャンネルへ通知すること
• チャンネルの通知設定を「すべての新しいメッセージ」にしておくこと
• 通知が来たら必ず何らかの対応（以後トリアージと呼ぶ）をすること

トリアージ

エラー監視のS/N比を改善していくために重要なのがトリアージの作業です。トリアージでは、その内容がどうであれ同じイシューが一定期間アラートされないようにします。具体的なトリアージの内訳は次の3つです。

• 判断を先送りする
• 対応しないことを決める
• すぐ対応する

判断を先送りする場合、チームで決めた一定期間（1-2週間ほど）そのイシューを無視します。Sentryには条件付き無視の機能があり、一定条件の間はアラートの対象外にできます。すぐには対応できませんが、アラートは止めつつそのエラーの存在をあとで思い出すことができます。

1週間イシューを無視する機能

エラーの解決が見込めない、外的要因によるものであるなど、チームとして当面の間対応しないことを決めた場合は、通常の無視を選びます。直ちに対応することになった場合は、対応完了するまで（たとえば次スプリントまで）はアラートが出ないように条件付き無視を使うとノイズが減ります。

エラー収集の最適化

また、そもそもSentryに送信されるエラー自体を最適化していくためのガイドも作成しています。SDKの初期化設定によって対応しようがないエラーの収集を防ぐことができるため、S/N比を改善しながらSentryの課金クォータを節約することもできます。 この最適化については公式ドキュメントの Manage Your Event Stream, a Guide | Sentry Documentation をベースにして社内向けにチューニングしました。

チーム横断的なトレンドの追跡

各チームがエラー監視を運用していくことを推進する一方で、Classi全体でのエラーのトレンドも追跡しています。具体的には、毎週Sentryから送られてくるWeekly Reportの共有と、毎月の社内向けレポートの作成をしています。

月刊Sentry

毎週のWeekly Reportでは一週間でどのプロジェクトのエラーが多かったかがわかります。7日間の推移を見ながら、その推移が身に覚えがあるものかどうかを振り返り、もし把握していないエラーの増加があればチームに持ち帰って深堀りしてもらうようにしています。

毎週見ている2週分のレポート比較

毎月の社内向けレポートでは、SentryのDiscover機能を使って全プロジェクトの中での上位エラーを報告しています。Discoverはビジネスプラン以上になるとプロジェクトを跨いだ検索ができるようになってかなりパワーアップします。まるで別物のような使い心地です。

いつも使っているMost Impactful Issueクエリ

エラーへの対応でどのチームがうまく行っていて、どのチームが難航しているのかを俯瞰できることでフロントエンドエキスパートチームとしても支援の優先順位付けがしやすくなりました。

パフォーマンス監視

Sentryのフロントエンドパフォーマンス監視機能は Web Vitals の指標にも対応して非常に使いやすくなりました。

フロントエンドパフォーマンス監視

パフォーマンス監視は計測自体はできるようになったものの、これをどう活用するかについてはまだ道半ばであり、どのような運用が各チームの活動をサポートするものになるかを考えている最中です。たとえばリリースの前後でパフォーマンスの劣化がないかを確認することや、極端なパフォーマンス劣化をアラートすることなどをフロントエンド運用のガイドラインとしてまとめていきたいと考えています。

まとめ

エラー監視の観点を中心に、ClassiでSentryをどのように運用しているかを紹介しました。運用は持続的に機能し続けることが求められますから、手間のかからず、なおかつ効果の高い運用方法を今後も模索していくつもりです。 もしSentryの運用に力を入れているチームがあればぜひもっと詳しい話をしながら意見交換してみたいので lacolaco 宛にDMなどいただけると嬉しいです。 それではまた！

Classiで行われている部活動の紹介 〜CTF caféはじめました〜

こんにちは、Classi株式会社 プロダクト開発部所属のid:kiryuanzu です！ 2020年4月から新卒のエンジニアとして入社し、現在は学習記録でサーバーサイドエンジニアの業務を担当しています。
今回の記事では、Classiの中の部活動の一つとして運用されている「CTF café 」、そしてその部活の課外活動の一環として参加したHardening 2020のイベントの体験記を紹介します。

CTF café はじめました！

ご存知かもしれませんが、CTFとは「Capture The Flag(キャプチャー・ザ・フラッグ)」の略であり、フラグ(Flag)と呼ばれる隠された答えをセキュリティの知恵を駆使して探し出す競技のことです。競技の中身は、クイズ形式のものや実際にサーバを攻撃・防衛する形式といったものがあり多岐にわたります。

Classiの中にはセキュリティやCTFに興味を持つ方が多くいます。
過去のClassiのWantedlyの記事では、活動に関わっている野溝が女性限定のCTF大会「4-Girls CTF 2019」というイベントに参加した際の体験記を書いています。 www.wantedly.com

筆者自身も、入社前にこの記事を読んで「CTF、やったことないけど楽しそうだな〜、会社の中に詳しい人がいるのならちょっと触ってみようかな……!」と興味が湧き始めました。
そして、Twitterや入社後に作った分報チャンネルでCTF興味がある旨を呟いた後日のことです。「社内の有志を集めて一緒にCTFの問題を解いてみませんか！」と誘われ、CTFを始めるようになりました。

そのような流れを経て、社内のSlackに「#ctf」というチャンネルを立て毎週火曜のお昼にSlack callに集まる部活が誕生しました！その部活をCTF caféと呼んでいます。

部活動メンバーとの和気藹々とした様子を一枚におさめました

CTF caféの主な活動内容はオープンに公開されているCTFの問題(ksnctf, cpawctf, picoCTFなど)を協力して解き合ったり、定期的に開催されるセキュリティ関連のイベントに参加するといったものです。
ずっとガチガチにやるといったものではなく、問題を解きつつ近況を交えた雑談を挟んだり、古のインターネット話に花を咲かせることも時折あります。

筆者自身、完全初心者ということもあり最初はどう解くか分からない問題も多かったですが、CTF経験者のメンバーからのアドバイスによって、次第に頻繁に出てくる暗号の解き方を理解したり、「こういう時はstringsコマンドでバイナリファイルの中身を見たらいいんだ！」とすぐに気付くようになりました。問題で用意されるパケットキャプチャを覗きたい時はWireSharkを使うのも慣れてきました。
まだまだ初心者ではありますが、「この時にはこのツール/コマンドを使おう」と頭の中で繋がるようになってきました。
また、OSINT(簡単に説明するとネットに公開された情報だけで目的の情報を特定する形式の問題です)をやるようになってからは迂闊に店名や特徴的な建物が写り込んだ地理写真をあげるのはできるだけ気をつけようと思うようになりました。

活動記録に関しては、メンバーの一人がesaの中でセンスあるタイトル付きで毎回まとめて社内に共有しています。

「なれる! SE」風と社内で評判です

Hardening 2020 に行ってみた！

筆者がCTF caféに参加するようになって1ヶ月ほど経ったある日、部活メンバーから「Hardening 2020というイベントに参加してみませんか」と声をかけられました。

Hardeningとは、簡単に要約すると外部からの攻撃を防御しつつ、運用を任されたサービスの売り上げを最大化する競技のことです。このイベント自体はCTFに分類されるものではありませんが、CTF同様にセキュリティの知識を駆使して競技に挑むといった点では同様であると言えます。 公式サイトの説明では以下のように書かれています。

Hardening競技会は、基本的にチームに託されたウェブサイト(例えばEコマースサイト)を、ビジネス目的を踏まえ、降りかかるあらゆる障害や攻撃に対して、考えうる手だてを尽くしてセキュリティ対応を実施しつつ、ビジネス成果が最大化するよう調整する力を競うものです。

その説明だけを聞いた時点では、「どうやって守っていけばいいの……!そもそもどんな攻撃が飛んでくるんだ……!?」とまだまだ未知の領域でしたが、チームを組むことになった方々や過去にHardeningに参加したClassiの社内メンバーによって講習会が開催され、どのような準備や戦略立てが必要であるかを知ることができました。
準備期間は1ヶ月で、応募者の中から10人構成のチームを組んで準備を進め、本番当日は上記で説明したように出されたお題に応じてサービスを運用し、攻撃から守り抜くことになります。
ちなみに、大会応募時には個人応募とチーム応募(3人まで)を選ぶことができ筆者はチーム応募で部活メンバーの2人と一緒に参加しました。 他の7人のメンバーの方は、Classiと似たようなWeb関係の出身の方もいれば生活インフラのシステムや病院のシステムを運用されている方、学生とエンジニアの二足のわらじをやっている方など多種多様なメンバーで構成されており、普段交流できないような方々と協力し合いながら学ぶことができ、セキュリティ関係のコミュニティの空気感についても知ることができました。
チーム名はISUCONジェネレーターを使って「おにぎりまみれ」という名前に決まりました。アイスブレイクとして好きなおにぎりの具を言い合ったり、チームメンバーの一人かつClassi社員の野溝がロゴを作成しました。

結果は……?

チームの方々と一緒に大会本番に向けて準備を続け、ついに当日を迎えました。 本番中のインシデントでは、ショップのトップページが何者かに改ざんされ当時流行していたドラマの画像が貼られたindex.htmlに変えられてしまったり……(チームメンバーの1人かつClassi社員の高田が30分で直して事なきを得ました)。
運用の手続きに必要なWEBページがDNSエラーで到達不能になり、Discordで運営の方に購入サイトのIPアドレスを教えてもらい危機を回避するなどがありました。
技術的なイベント以外にも、発生したインシデントについて親会社の役員に説明を求められたという設定で、怖い役員に扮した運営メンバーの方から呼び出されるといったこともありました。どうやらこの公開呼び出しイベントは毎年お馴染みのようです。

そして結果は……！ 筆者も含めたClassi社員の3名が所属するチーム「おにぎりまみれ」が総合優勝しました！！！！！！

まさかの初参加でこのような素敵な体験をさせていただくことができ、本当に感謝しています。後日行われた振り返りの場でもこのような結果が残せたのは、チームワーク重視で動き続けたことがよかったのではないかとチーム内で意見が一致しました。

具体的には、チーム内のメンバーの誰かが困っている時はすぐにチャットで反応したり声かけを行うなど、リアクションを徹底して行い、誰かの発言が虚空に消えそうな雰囲気を感じた場合はすぐに反応をして不安を取り除けるよう動くようにしたことで、お互いの役割を認識し合いながら作業内容を把握して進めていくことができたのではないかと思います。

まだまだ「旅」は続く

CTF caféがきっかけとなりこのような大変面白い体験ができました。しかし、これで終わらず部活メンバーと共にセキュリティに関する知見を深め合いながら問題を解き進めたり、他の面白そうなセキュリティ関連の大会に参加して経験を積んでいきたいです！

Classiでは、このような面白い課外活動が活発に行われております。 この記事を読んで「自分もこのようなコミュニティに関わってみたい！」と感じた方の応募をいつでもお待ちしています！

リモートでPeople+AI Guidebookの輪読会をやった話

こんにちは。データAI部部長の伊藤(@tetsuroito)です。

Classiの組織はマトリクス型の組織を採用しており、縦では職能別の部門、横では機能チームごとに分けて、日々の業務にあたっています。

今回の記事では、データAI部とUXデザイン部が共同で取り組んだ輪読会の内容をお伝えします。輪読したものはGoogleが2019年に公開したPeople+AI Guidebookの日本語版です。

輪読会開催のきっかけ

日々の業務では横軸のチームで動くことが多く、部門間のやり取りもチーム内でやりとりすることが多くありました。しかし、縦の部門でそれぞれの職務における能力開発が担われており、UXデザイン部ではUIやUXデザインに関する専門的な能力開発が、データAI部ではデータサイエンスや機械学習などの専門的な能力開発がそれぞれ行われていました。

しかし、データサイエンスや機械学習などは取得されたデータから新たな価値を創出していく活動のため、システムやプロダクトにおけるユーザー体験がデータを生み出すメカニズムそのものに強く影響を与えます。

そのため、2つの部門で同じような課題意識を共有できる取り組みができないかと思っていました。そんな課題意識をUXデザイン部の副部長の松本さんに相談したところ、まずは輪読会をやってみようということになりました。

輪読会の開催概要

リモート環境下における輪読会なので、どのような体裁で開催するかは少し工夫をしました。

項目	方法
開催頻度	毎週金曜日11:00-12:00
読む物	People+AI Guidebook(翻訳版)
各回の概要	1回目：はじめに 2回目：ユーザーニーズ+成功の定義 3回目：データ収集＋評価 4回目：メンタルモデル 5回目：説明＋信頼感 6回目：フィードバック+コントロール 7回目：エラー +上手な失敗 8回目：ふりかえり
輪読会構成	前半30分 担当箇所を読みながら付箋に書き出す 後半30分 付箋を眺めながら気になった観点を議論する 締めにグラフィックレコーディングを確認する
使うツール	Miro

輪読会の開催方式は色々とありますが、今回は専門領域の異なるメンバーが参加しているため、同じ認識を持ちながらそれぞれの立場での読み解きの視点や感想などをシェアすることを重視しました。

そこで、特に担当箇所などは割り振らず、毎週決まった章をみんなで読んで、感想を出し合う形式にしました。各回の分量も適切なサイズに切り分け、事前に予習してこなくても大丈夫なように、前半30分を読む時間にあて、その中で気になる観点を書き出し、後半にそれを話し合うことで気づきを得られるようにしました。

今回、UXデザイン部のメンバーが参加してくれたことで、輪読会での議論の様子をグラフィックレコーディングにしてもらいました。最後にそれを眺めて振り返ることで、理解を促進するような構成にしました。

輪読会の様子

はじめにを読んで、輪読会に期待することを書いた初回

データ収集+評価の回

エラー+上手な失敗の回

このようにはじめの30分で章を読みながら気になった箇所を個々で付箋に書き出し、他の人がどのような観点が気になっているのかをみることで、また新たな発見や視点を得ることができました。その様子をグラフィックレコーディングで描いたのが右手に描かれている内容です。

ふりかえり

すべての章を読み終えた後に、輪読会自体のふりかえりも行いました。

People+AI Guidebookには章によってデータ系に近い章とUXに近い章がそれぞれありましたが、みんなが共通して印象だった箇所として、「メンタルモデル」や「期待値調整」、「AIの目的は自動化か拡張」などの観点があげられました。

また、最終的にAIシステムのためのUXデザインについて学んでいたはずが、一般的なシステム開発にも活かせる内容も多く、そうした気づきを得られてよかったことや、自身の関わっているプロジェクトにも活かせそうだという意見も多く書かれていました。

今回、職能を超えた活動をする上で、People+AI Guidebookが非常に取り組みやすいコンテンツだったと思います。こうした活動の媒介となるコンテンツがあるということは非常にありがたいなと感じました。

まだまだ質的な部分と量的な部分のコラボレーション事例はそれほど多くはありませんが、こうした活動をきっかけに良い取り組みができるように頑張っていきます。

AWS ECS監視のオオカミ少年化を防ぐために考えたちょっとしたこと

こんにちは。エンジニアの遠藤です。

Classiでは、Datadogを使ってシステムの各種メトリクスをモニタリングし、異常があればSlackにアラート通知を飛ばすように設定しています。

今回は、AWSのECSのタスク数に関するアラート通知の設定を変更する機会があり、そのとき何を考え、どう変更したのかという日々の運用の様子を紹介したいと思います。

もともとの設定

あらゆるECSのサービス（以後、サービス）のタスク数について、

aws.ecs.service.desired - aws.ecs.service.running

が5以上になればアラート通知を飛ばすように設定していました。

もともとのDatadogの設定

理由としては、例えばサービスAについては desired task が 10 で設定されていて、サービスBについては desired task が 20 で設定されていたとしても、上記の設定であれば問題なく異常（予期せぬ稼働タスク数の減少）を検知できて、汎用性があるからです。

問題

しかし、あるサービスでタスクのスケジュールベースのオートスケールを設定したとき、上記の設定では問題が発生するようになりました。

そのサービスのタスクは、17:00になると10 -> 30 にスケールアウトし、 18:00になると 30 -> 10 にスケールインします。

先のタスク数のモニタリング設定では、17:00に必ず aws.ecs.service.desired - aws.ecs.service.running = 20 となるので、毎日 17:00 にアラート通知が飛ぶようになってしまいました。

これだとアラート通知がオオカミ少年化しているので、なにか対策をしたいところです。

対策

一案として、上記のサービスのみ通知先のSlackチャンネルを変更し、もともと通知を飛ばしていたアラート用のチャンネルからノイズを取り除きつつ、別チャンネルで検知するという対応が考えられました。

ただ、温度感の高いアラート用チャンネルに通知されなくなるので、本当に予期せずタスク数が減少していることを検知する機会を逃すかもしれず、不安です。

何を監視・検知したいのかを改めて考える

そこで「何を監視したいんだっけ？」に立ち返って考えてみると、結局、検知したいのは予期せぬタスク数の減少です。

シンプルに、そのタスク数の減少をモニタリングすればいいのでは？という考えに至りました。 結果的に、以下のように設定しました。

変更後のDatadogの設定

通常稼働しているタスク数は10であるサービスなので aws.ecs.service.running が8以下になったとき、アラート通知を飛ばすように設定しました。
（ちなみにこのサービスについては Blue/Green デプロイをしているので、デプロイ時に稼働中のタスク数が瞬間的に10を下回ることはありません）

このモニタリングの設定は汎用的ではありませんし、タスク数の定義を変更するたびにアラートの閾値を変更する必要があるという若干のトレードオフはありますが、目的は十分に達成できるので採用しました。

まとめ

Datadogのモニタリングの小さな設定変更ですが、タスク数の予期せぬ減少は致命的な障害が起きている可能性が高いので、注意深くメンテナンスしていく必要があります。

Classiでは、今回のような運用の改善をポジティブに捉える文化が根付いていて、日々継続的な改善に取り組んでいます。

ほんの一例ですが、事例としての紹介でした。

これからもこういった日々のメンテナンスを怠らず、積極的に改善していけたらと思います。

GitHubのテンプレートリポジトリを継続的に運用する

フロントエンドエキスパートチームのlacolacoです。今回はClassiの中で運用しているGitHubのテンプレートリポジトリについて、その運用方法を紹介します。これが最善である自信はないですが、一例として誰かの参考になれば幸いです！

テンプレートリポジトリ機能とは？

docs.github.com

テンプレートリポジトリは通常のリポジトリと同様にcloneやpull、pushなどできるGitリポジトリとして機能します。テンプレートリポジトリが通常のリポジトリと違うのは、新しいリポジトリを「テンプレートから作成」できる点です。 テンプレートからリポジトリを作成することは、リポジトリをフォークすることに似ていますが、以下の点で異なります。（ドキュメントより引用）

• 新しいフォークは、親リポジトリのコミット履歴すべてを含んでいますが、テンプレートから作成されたリポジトリには、最初は 1 つのコミットしかありません。
• フォークへのコミットはコントリビューショングラフに表示されませんが、テンプレートから作成されたリポジトリへのコミットはコントリビューショングラフに表示されます。
• フォークは、既存のプロジェクトにコードをコントリビュートするための一時的な方法となります。テンプレートからリポジトリを作成することは、新しいプロジェクトを素早く始める方法です。

Classiにおけるテンプレートリポジトリ

テンプレートリポジトリは似たプロジェクトを何度も作成するときの雛形を管理する方法としてとても適しています。その一例として、Classiのフロントエンドエキスパートチームでは、AngularJSからAngularへの段階的移行を支援するテンプレートリポジトリを作成しています。

Classiのコードベースは機能やデプロイ単位に基づいていくつかのリポジトリに分割されています。そのため、ひとつの大きな移行ではなく、いくつもの段階的移行が並行して進行することになります。

AngularJSからAngularへの段階的移行では、AngularコンポーネントをCustom Elementsに変換して、それをAngularJSを利用している旧実装のHTML中に埋め込んで置き換えていくという手法を取っています。Angularコンポーネントは単にCustom Elementsにするためだけのソースコードではなく、移行の最終段階ではそのままAngularアプリケーションとして根本から置き換え可能である状態を作っていきます。

つまり、ひとつのプロジェクトの中でAngularのソースコードを通常のアプリケーションとしてデプロイできるビルド設定と、Custom Elementsのパッケージとしてデプロイできるビルド設定の共存が必要になります。毎回それぞれのプロジェクトにリポジトリの作り方をレクチャーしていくのは骨が折れますし、設定を改善したときにそれを全体に伝えるのも共通の土台がないため難しいです。

テンプレートリポジトリを運用することで、どのプロジェクトも同じスタートラインになっており、設定の改善も同じ変更を適用できることをある程度保証できるようになりました。また、実際にプロジェクトを進めていく中での発見をテンプレート側へ還元するループも生まれやすくなりました。

継続的な運用のための変更履歴

このようなテンプレート的存在は時間の経過につれメンテナンスがされなくなったり、テンプレートから新しく作成した時点からいままでの差分がわからないということになりがちです。この問題を緩和するために、テンプレートリポジトリの変更履歴を文書化しています。

具体的には、テンプレートリポジトリ内ではConventional Commits のルールに従うことで、 standard-version CLIを使ってCHANGELOG.md を自動生成できるようにしています。キリのいいタイミングでテンプレートのバージョンを更新することで、「テンプレートを更新したので各チームで変更点の追従お願いします」というコミュニケーションが容易になります。 コミットログだけではノイズが多いため、Conventional Commitsによってfeatとfixの差分がまとめられることで本当に重要な変更だけを伝えやすくなっています。

CHANGELOGの例

今後の課題

現状どうしても人力に頼っているのは、テンプレートのバージョンアップを派生先のリポジトリ達に伝えに行くところです。ここは何かしらの方法を使って自動化できないかと考えているところです。たとえばGitHub APIでそのテンプレートから作られたリポジトリを走査してIssueを作成にしにいくなどできるかもしれません。 また、変更の追従自体もテンプレート側のDiffをなぞって真似することになるため、マイグレーションパッチを適用するだけで済むようになれば楽になるかもしれないと考えていますが、テンプレートからの作成後に加えられた変更でパッチの互換性がなくなってしまうケースも考えると一筋縄ではいかないですね。

とはいえ、変更履歴とバージョニングを自動化するだけでもテンプレートリポジトリの運用がやりやすくなりました。読者の中でテンプレートリポジトリを運用している方の参考になれば幸いです。

SQL勉強会を通して痛感したデータ民主化への長い道のり

こんにちは、ClassiデータAI部の石井です。 私は2019年4月にソフトバンクからClassiに出向し、マーケティング部を経て、現在データAI部でデータエンジニアとして分析基盤の構築を担当しています。今回は私が現部署で最初に担当したSQL勉強会についてご紹介します。

背景

2020年春頃から、新型コロナウイルスの影響による休校や教育現場の急激な状況変化に対応するため、Classiサービスの詳細な利用状況把握の必要性が高まっています。 Classiは弊社の強みともいえる膨大な教育データを蓄積していますが、残念なことに全社的には貴重な教育データを活用しきれていないことが課題でした。 2020年夏に全社で行った「データAI部に期待すること」に関するアンケートでも、「基礎的なデータ活用方法を教えてほしい」という回答が多く寄せられました。 この状況をふまえ、データ活用のための知識の底上げを行い、全社的なデータ活用へコミットするべく、オンラインでのSQL勉強会を開催することにしました。

Y：やったこと

ターゲティングと目標設定

顧客のニーズを正しく捉えたプロダクトを継続して提供するためには、カスタマーサクセスとディレクターがデータ分析するスキルを身につけることが必要です。しかし、Classiではデータ活用の程度にばらつきがあり、施策の打ち出しや機能リリースを行っても、データを用いた効果検証ができておらず、その結果、さらなる施策の打ち出し等の際に顧客にデータに基づいた提案ができないという状況でした。 この状況に鑑み、最もデータを活用してもらいたいこの2職種を中心に参加者を募集。参加希望のあったカスタマーサクセス5名、ディレクター9名、セールス1名に対し勉強会を実施しました。 もともとは全社で1週間あたりの分析基盤利用者数が20名に満たない状況でした。まずは利用者数を20名以上とすることを目標に設定しました。

コンテンツ

業務におけるデータ活用のイメージがわきやすいように、カスタマーサクセスとディレクターそれぞれに各業務に近いデータを準備しました。 また、講義は参加者の習熟度を測るため下表のようなレベルに分けて行いました。

Lv.	説明	主な文法
0	SQLとは／RDBとは／Classiのデータについて SQLの処理順序／データ型	ー
1	1つのテーブルを利用して、データ抽出ができる	select/from/where/and/or/in/case/like
2	1つのテーブルを利用して、集計ができる	order by/group by/having count/sum/avg/distinct/
3	1つのテーブルを利用して、高度な集計ができる	with/日付関数/日時関数
4	2つ以上のテーブルを利用して、抽出・集計できる	join(left,inner,cross,full)/unionall

データAI部3名が講師を担当し、以下の流れで学習を進めました。

講義編：SQL基礎を学んでもらう（1〜5週目、1時間／週を計5回）
実践編：チームに分かれて実際に分析をしてもらう（6〜7週目の計2週間）
分析結果発表会（1時間）

工夫したこと

講義編

オンラインでの勉強会は、参加者のリアクションや講義のペースが速すぎないかが分かりにくいため、講義の最後に演習問題を入れ理解度をチェックする等、可能な限り参加者全員が理解を深められるようにしました。

実践編

2チーム（3名ずつ）に分かれて実施し、各チームに講師が1名ずつサポートで入りました。分析を行う上では、以下のステップを踏みました。

• 各チームメンバーが分析してみたいテーマを出し合う
• 出てきたテーマに対して講師が分析の難易度を設定する
• 難易度をふまえてチームメンバー自身で分析テーマを選んでもらう
• 抽出するデータの順序を決めて段階的に抽出してもらう
• 一つ一つ抽出できているかを講師が繰り返し確認、解説する

なお、ディレクターは全員他業務との調整がつかなかったためディレクター向けの実践編を開催できず、課題を残す結果になりました。

分析結果発表会

各チーム15分で発表・質疑を行いました。その後、今後のデータ活用の参考として、普段からSQLを使ってデータ分析しているカスタマーサクセスのメンバー2名に、実際に業務でどのようにデータ分析しているかについて15分ずつ説明してもらいました。

W：わかったこと

成果

勉強会開催中は講義内で分析基盤を使用したため、目標利用者数20名以上を達成することができました。 勉強会終了後は再び利用者数が減ってしまったものの、勉強会実施前に比べると利用者数が増え、勉強会の成果が出た形となりました。

分析基盤利用者の推移

振り返り

勉強会後、講師陣で振り返り、以下の気づきを得ました。

• 講義を進める中で、Lv.2のgroup byや集計関数の部分は概念が難しく特につまづきやすいので、演習問題の経験を増やして理解を深めるのが最適だと思いました。

• 実践編で、チームに分かれて分析した方がチーム内で意見を出し合って良い分析ができると予想していましたが、実際は各チーム内にいる講義編の習熟度が高いメンバー1名に依存する状況になり、全員の分析力を高めることの難しさを感じました。

• SQL初心者から「with句の抽出名やカラム名に日本語は使えないのか」という質問が出ました。日本語を使用した方が各データが何を指すかわかりやすいという意図かと思いますが、私には日本語にしようという発想がなかったので新鮮なコメントでした。

• 今回、本人の強い希望で勉強会に参加していたセールス担当から、「セールスはデータ抽出しないがデータを見ることはよくあるので、データ抽出を依頼する際にどの程度作業時間を要するか、どのように依頼したらスムーズかが分かり参考になった」と言ってくれました。セールスは業務中にデータ抽出する時間がないため今回はターゲット外としていたのですが、データ抽出との関連が薄そうな職種でも、勉強会への参加でデータを扱う業務への理解が深まるという思いがけない効果がありました。

• 分析発表会の参加者の気づきの中も参考になるものがあったので以下ご紹介します。

  • アウトプットイメージを先に明確にしたうえでテーブル抽出する
  • 仮説を立てる際の目的を明確にすること
  • 抽出データの構成を考えるスキルの向上（横持ち？縦持ち？等）

フィードバック

勉強会後、以下の３つの観点で参加者にアンケートを実施しました。

• 習熟度
• 満足度
• 今後のデータ分析に対する主体性

勉強会参加者16名のうち半数の8名が習熟度最高レベルのLv.4までマスターすることができました。また、講義編、実践編、講師の説明、コンテンツに対して5段階評価でそれぞれ4.6以上と、高い満足度を得られました。 しかし、勉強会本来の目的である「今後のデータ分析への主体性」に変化があったかのアンケートの結果、全体では5段階評価で平均3.2、SQLを習熟度Lv.4までマスターした参加者でも評価は平均3.7となり、高い満足度の割に低いスコアとなりました。 理由として、参加者コメントに「分析する時間が取れない」、「SQLの理解はできたが、現業務にどのように活用したらよいかが分からない」といったSQLの知識の有無とは別のところに課題があることが分かりました。

参加者コメント（一部）

• 意欲はあるのですが、他業務との調整がなかなかつかず。。
• ここで得た知見を今後どう活用していけるかがまだ見えてはいない
• 現時点で具体的なテーマ設定ができない
• より身近に使える題材を演習にできるとなお良かった

T：次にやること

今回の勉強会を通じて、データ活用を進めるためにSQLを学習することと別に、（１）分析時間の短縮化、（２）現業務と分析テーマとの結び付けに本質的な課題があることが分かりました。

（１）分析時間の短縮化について、Classiでは容易に分析できるように各プロダクトチームのユーザビリティが高いDWH/DMを再構築をしています。

（２）現業務と分析テーマとの結び付け方については、非常に難しい問題ですが、データ活用を推進している我々がデータを活用する立場の彼らに寄り添い、業務を理解した上で共に考えていくことが大切なのだと思います。 そもそも「”基礎”的なデータ活用方法」というのは、”基礎”技術ではなく「業務のどこで活用するのか」という意味での”基礎”であるということが参加者のコメントからもうかがえます。”基礎”と聞くと、”基礎”技術を思い浮かべがちですが、非エンジニアの認識は必ずしもそうではないようです。 現在は、各プロダクトチームに対するヒアリングにより一層力を入れています。データAI部が分析した結果を提供し、その際に分析手法も伝えるようにしたり、施策打ち出しや機能リリースのタイミングを見計らって関係部署に「今が分析のタイミング」とお知らせする等しています。

また、その他の勉強会後の活動として、SQLの理解度アップのために、ClassiオリジナルのSQL練習問題を100問作成（通称：100本ノック）してトレーニングしてもらっており、そこでわからない問題については定期的なもくもく会で個別サポートを行っています。

データ活用ができていないというのは他の企業様でもよく耳にする課題かと思います。今回ご紹介した弊社のSQL勉強会の学びが参考になれば嬉しいです。