2024-09-06

24年度新卒エンジニアが研修を終えて

こんにちは。4月にClassiへ新卒で入社した伊森です。

私は4月から8月上旬までの約4ヶ月、Classiのエンジニアとして働くための新卒研修を受けてきました。今回はその研修期間を経て、大まかな内容の振り返りや身についた考え方を紹介していきます。

入社前の状態
研修内容の概要
AWS研修
- 良かったところ
- 物足りなかったところ
QA研修
- 実際に手を動かすテスト項目の作成課題
- 「品質が高い」とはどの状態を指す言葉？というディスカッション
万葉カリキュラム
研修プログラム以外にも学んだこと
まとめ

入社前の状態

大学生時代はPythonを使用した画像処理を主に勉強しており、これまでWeb上で動くものを開発する世界に踏み込んだことはほとんどありませんでした。そのため、Webの基本的な概念であるHTMLなどはぼんやりとした理解に留まっており「触ったことはあるがそれでゼロから何かを作成したことはない」状態でした。

具体的なことを何も知らなかったのでWebに関連する技術はとにかくなんでもやってみたく、そのため入社前面談では「フロントエンドもバックエンドもとにかくやってみたい！」ということを伝えていました。 2024年度の新卒入社は私1人だったのもあり、その意向を汲んで今年度の研修カリキュラムを作成していただきました。

研修内容の概要

以下が研修内容となっています。研修項目を完了することで、Webサイト上で動作する最低限のWebアプリケーションが構築できるようになっています。

4月にはWebアプリケーションエンジニアの基本的な知識としてGit&GitHubの使い方やフロントエンドに関する知識を身につけ、5, 6月にはバックエンドを含めたより専門的な知識をフィヨルドブートキャンプを筆頭に学んでいきます。そして、7月には身につけた知識をもとにWebサイト上で動作するアプリケーションを構築する万葉カリキュラムを行います。

４月

Git & GitHub研修
フロントエンド研修 (HTML, CSS, JavaScript, Angular)
AWS Cloud Quest を用いたAWS研修
自己紹介ページの作成

５・６月

フィヨルドブートキャンプで外部研修
- HTML & CSS
- JavaScript
- Ruby, Ruby on Rails
- データベース
- Webセキュリティ
そーだい塾
RubyKaigi2024

７・８月上旬

QA研修
万葉カリキュラム
- フロントエンド: Angular
- バックエンド: Ruby on Rails, PostgreSQL
- Dockerによる開発環境の構築
- AWS上に本番環境を構築

上記の研修の中でも、今年度初の試みとなる研修2つと、その経験が特に生きたと感じられた研修1つの計3つを紹介していきます。

AWS研修

Classiの従来のAWS研修ではUdemyという動画教材を参考に、実際にインフラを構築する研修をされていました。今年は趣向を変え、昨年10月に日本語化の対応されたAWS Cloud Quest: Cloud PractitionerでAWSの基本的な概念を学びました。

以下ではAWS Cloud Questについて簡単に紹介していきます。

AWS Cloud Questとはゲーム形式でAWSのサービスについて学ぶことができる教材です。ゲームのコンセプトとしては、街で困っている人をAWSのサービスを通して解決していき、目標のクエストを全て達成するとゲームクリア！となっています。

Cloud Practitionerコースでは12個のクエストが用意されています。内容としては、S3, EC2, RDSなどのAWSの基本的サービスについての紹介から、アクセス集中や天災に対する耐障害性などのAWSの利点について学ぶことができます。

各クエストは学習・計画・実践・DIYの4つに分かれています。学習・計画ではクエストを達成するための前提知識の紹介とクエストのざっくりとした流れが紹介されます。実践・DIYでは実際にAWSコンソール上で手を動かしていきます。実戦ではこれからやることが順番に示されるのでその通りに手を動かし、DIYでは実践の内容を踏まえたお題が出され、クリアするとクエストが達成となります。

以上を踏まえ、AWS Cloud Questを用いた研修の良かったところ、逆にここは物足りなかった…と思ったところについて紹介していきます。

良かったところ

AWSが各クエストに特化した環境構築をしてくれるので、特定の内容だけに絞って学びやすくなっている
クエスト達成の可否は構築された環境上で所定の動作を踏めているかをAWSが監視して判断してくれるため、基準がわかりやすい
GUIでのAWSの操作に慣れることができるため、サービスに対して親しみを持ちやすい

物足りなかったところ

Cloud Practitionerでは各要素について広く学ぶことができるものの、サービスを構築するための具体的手順はあまり学べなかった
例えば環境構築の際にはEC2インスタンスの作成方法まではわかるが、次にどうやってインスタンス内部に構築するかなどの手順は学べなかった

AWS Cloud Questの強みは何よりも環境構築をしてくれることです。AWS全くわからない…という人にとっては手軽にサービスに触れるための環境が用意されているのはとても初心者に優しい仕様です。一方で、AWS Cloud Quest: Cloud Practitionerでは一つのWebアプリケーションを作成する際のAWSのサービス同士の連携方法は学べませんでした。サービスの全体を知るにはAWS Cloud Quest外のドキュメントなどを読む必要があります。総括としては、Cloud Practitionerコースは基本的なサービスの学習ができるので、AWSに対する知識を０から１にするには非常に優れた教材です。今回こちらで学習させていただいて、大きく知識を身につけることができました。

そして、AWS研修の最後には学んだことを発表する会を設けていただきました。学んだAWSのサービスの網羅図を作成し、多くの方に見ていただきました。

発表の際に作成した網羅図 (当時のまま) です。改めて見ていると当時指摘いただいたことがわかったり、例えばルーターはネットワークのトラフィック処理をするサービスであって、アクセス許可を制御するのはルートテーブルじゃないか？などの認識が間違っていた点を発見したりして味わい深いです。

5日間のAWS研修でしたが、始める前は知識ゼロだったことを考えると、AWS Cloud Questを通じてAWSのサービスに親しみを持つことができました。ぜひAWS未経験の方にやっていただきたいです。

QA研修

こちらも今年度から初の試みの研修となっています。研修内容についてはQAチームメンバーの方が記事を作成されているので、より詳しい研修の目的はそちらの記事をご覧ください。

私からはQA研修前後のQAに対する意識の違いについて述べていきます。研修前の状態を正直に申し上げると、QAという単語自体が何を意味する言葉なのか知りませんでした。Question Answer…？という状態です。その状態から始まった研修でしたが、QAとは？という講義から始まりClassiにおけるQAの体制を紹介していただき、日々の業務の流れやテスト項目の作成方法を学んでいく形式の研修はとても理解しやすかったです。

印象深かった研修内容は二つありました。それぞれ順に紹介します。

実際に手を動かすテスト項目の作成課題

この研修では、「macOS標準のリマインダーアプリに対してテスト項目を作成するなら？」というお題で、実際の業務で使われているテスト観点表を利用してテスト項目の作成を行いました。

この研修の良かった点は二つあります。一つ目に、初日の段階では観点表の使い方を軽く紹介するだけに留められたことです。最初は手本を見ずに一人で考えてテスト項目を作成しました。こうすることで、翌日にQAメンバーの方が作成された観点表と比べると改善点が浮き彫りになるのが非常に面白かったです。

二つ目に、受けたフィードバックや考えたことを翌日の課題に反映できたことです。この課題は計4日間実施され、前半は単体テストを、後半は組み合わせテストの観点表を作成しました。この形式にしていただくことで、前日作ってきた課題の反省点をすぐ翌日の課題に反映させることができました。それによってフィードバックを受けてすぐにやり直すことができるスピード感が生まれ、さらにQAチームの方が作成された観点表に私が作成した観点表が近づいていくのは成長を実感しやすい仕組みでした。

「品質が高い」とはどの状態を指す言葉？というディスカッション

ここでは、QAチームの方が日々考えている「品質が高いこととは何をもって定義されるか？」を一緒に考えていきました。最初に品質の種類について紹介していただき、障害を起こさないためには？品質の責任の所在は？などを一緒に考えていく時間をとっていただきました。

このディスカッションを通じて、今まで私が考えていた「品質が高い」というのは、ユーザー目線に限定されていたことに気づきました。具体的には、「この機能が揃っている！」や「応答が早い！」などの視点しか考えられていなかったのです。

QAチームの方からご回答いただいた「品質を高める」ために実践されていることとしては以下の点がありました。

テスト項目を網羅的に作成し、リリースを細かくしてすぐに巻き戻しができるようにする開発の話
チームで品質に責任を持ち、品質の定義をみんなで考える意識の話
必要な時はエンジニアに仕様に対する説明資料を作成していただき、不明点の解消を図る見える化の話

この経験から、外部的な品質に対する視点だけではなく内部的な品質を評価する視点が増えたと感じています。

総括して、QAチームの業務について知る研修はソフトウェアエンジニアとして働く上で非常に重要でした。今回学んだことを活かして、テストの観点をQAメンバーの立場になって考えたり、製品の品質についてこれからも考えていきたいです。

万葉カリキュラム

オリジナルのカリキュラムは以下になります。

この研修はWeb上で動くアプリケーションを作成することをテーマにした、Classiの新卒研修では恒例となる研修です。今年はフィヨルドブートキャンプでプログラミングの技術について深く学ばせていただいたので、万葉カリキュラムではアプリケーションの機能面を充実させることよりもWeb上での実装を重視した研修となりました。

Web上で動くアプリケーションを作成するのは初めての経験だったため、Dockerの環境構築やCIを活用した開発もこの研修を通して学びました。最初は設定ファイルの書き方がわからず非常に苦戦しました。わからないことは尽きなかったため、他の人に対して質問をする力がつきました。また、今やっていることを発言しながら作業するWorking Out Loudの精神が育まれたと感じています。

また、アプリケーションを作成する際に古い書き方になっていないか？わかりにくい書き方になっていない？などをGitHubのPRでレビューしてもらうことで、事前に気をつけるべき点を意識するようになりました。以前はできなかった公式ドキュメントを参照する力も養われ、アドバイスをいただく際に信頼できる情報源を知ることができました。

この研修では、開発と単体テストを同時に行うことを実践していました。この際にQA研修で作成したテスト観点表が役立ちました。具体的には、テスト項目を考えるときやテストの網羅性を検討する際に自然とテスト観点表が思い浮かぶようになり、考えるための土台になったと感じています。

最後にAWSへ構築した環境へデプロイを行いました。最初に構成図を作成し、それをもとに手順書とサービス構築を行いました。作成した構成図は下の通りとなります。

デプロイの際にはAWS研修でサービスについて学んだことでAWSに触れるハードルが大きく下がったように思います。GUIの画面やサービス構築方法を知っていたのはこの時の作業で非常に役に立ちました。

一方、AWS研修ではわからないことも多くありました。今回の実装はEC2インスタンスやRDSが1つしか存在しておらず、環境として特殊だったこともありますが、例えば「WAFのルールを適用させるためにALBを使う必要がある。ALBの環境構築には最低二つ以上のAZに分かれたサブネットが必要になる。」という所で複数のサブネットを用意していなかったためにつまづきました。

また、Rubyの環境構築の際に無料利用枠のt2.microインスタンスではCPU使用率が100%になって環境構築ができないことがありました。結果的にそれぞれのインスタンスのCPU性能などを知る良い機会になりましたが、この辺りでうまくいかずに苦労しました。

それでもデプロイが完了し、作成したアプリケーションがWeb上で動いているのを見るととても達成感が得られました。同じことをする上での今後の自信に繋がりましたし、ここまでの成果が4ヶ月間の集大成となると感じられるように作られている研修プログラムが非常に良かったです。

研修プログラム以外にも学んだこと

研修期間中にここが良かった！見習いたい！と思ったことを書いていきます。

良かった点の一つ目として、新卒だからと言って良い意味で手加減をされなかったことです。もちろん細やかな誘導はしていただいていたのですが、これもできるといいねという発展課題の提示や、ここは○○が理由で間違っているという指摘は妥協せずにしていただきました。細かい助言や指摘を受けることで関連知識を身につける機会が必然的に増えましたし、いきなり答えが提示されなかったことで問題解決する力を養えたように思います。

また、私が研修で気づいたことや知ったことを共有すると、メンターの方も知らなかったやり方や技術だったことがありました。そんな時にもメンターの方は素直に知らないと言って新しい知識を取り入れられたり、一緒に学んでいこうという姿勢を見せてくれました。この学びに対する姿勢はClassiのバリューにもあることですが、見習っていかなければと感じさせてくれました。

まとめ

Classiの新卒研修はフルサイクルエンジニアを目指す上でとても理にかなった研修プログラムでした。Git&GitHubの使い方やフロントエンド研修から始まり、フィヨルドブートキャンプやAWS、QA研修で細かな技術を学び、万葉カリキュラムではデプロイをしてWebでアプリケーションを動かせるまでになりました。スポットで開催していただいたそーだい塾や日々のやりとりを経て、エンジニアとして働くための心構えを身につけていきました。

フルサイクルエンジニアを目指す研修は私が入社前からやりたかったことです。この研修を通じて、Webアプリケーションについてほぼ何もわからなかった私が、ここまでできるようになったことにとても満足しており、エンジニアとして大きく成長できました。今後は実際の業務で恩返しや価値の提供をしていけるように頑張っていく所存です。

読んでいただきありがとうございました！

2024-09-05

SRE NEXT 2024にSILVER SPONSORとして協賛&参加してきました

勉強会・イベント

ソフトウェアエンジニアの onigra です。2024年8月3日から4日にかけて開催された SRE NEXT 2024に参加してきました。

https://sre-next.dev/2024/

ClassiはSILVER SPONSORとして協賛し、いただいたスポンサーチケットで参加しました。

https://x.com/onigra_/status/1819594542586401140

印象に残ったセッション

工学としてのSRE再訪

さくらインターネット株式会社の yuuk1 さんの発表です。

SREの工学（Engineering）的側面に着目し、日本国外の発表事例を紹介しながら、Webサービスの運用にまつわるさまざまな問題の発見と解決に向けたアプローチの紹介を交えつつ、聴衆の視点を少し未来に導くような発表でした。

また、書籍『ウェブオペレーション』から「ウェブオペレーションは技芸であり、科学ではない」という一文が紹介されました。私自身思い当たることが多く、ウェブオペレーションは（特に障害対応において）経験から来る勘であったり、言語化や他人に教えるのが難しいスキルに頼りがちな側面があります。

発表を通し、SREはウェブオペレーションにおける技芸的な要素に再現性を持たせるために発展してきた分野なのかもしれないと感じました。

SRE NEXT 2024のテーマであるBEYOND NEXTを感じさせる、知的好奇心を刺激される発表でした。登壇後記も公開されておりますので、ぜひこちらもご覧ください。

工学としてのSRE再訪 - SRE NEXT 2024登壇後記

Enabling Client-side SLO

株式会社Luupのぐりもおさんの発表です。

LUUPにおけるクライアントサイド（iOS, Android）SLOの検討と導入、それにまつわるプロセスや課題についての発表でした。iOS, AndroidのSREやオブザーバビリティの話題・事例はまだ少ないと個人的に感じており、興味深く拝聴しました。

発表を通して、導入プロセスはサーバサイドと大きな差異はないなと解釈しました。SLOをUpside, Downside, Actualの3つ作成し、段階的に目標を目指す運用はこれまでSREに関する発表を多く行ってきたLUUPさんの積み重ねを感じさせる、弊社でも適用したいプラクティスだと思いました。

また、発表で触れられていた再設定前のクリティカルユーザージャーニーは個人的に納得感のある内容だったので、新たに設定された内容がどんなものか非常に興味深かったです。

淡々とお話しされていましたが、「信頼性は会話です」と強調して語られてたことが印象的でした。ぐりもおさんの粘り強いEnablingと高度なソフトスキルがあってこそ、ここまでの内容に至ったのだろうと感じました。

ご本人から発表内容について改めてまとめられておりますので、ぜひそちらもご覧ください。

SRE NEXT 2024でクライアントサイドへのSLI/SLOの導入についてお話しました

SkyWayが遭遇したWebRTC の可観測性に関する問題と開発者向け可視化サービス提供までの道のり

NTTコミュニケーションズ株式会社の yuki_wtz さんの発表です。

NTTコミュニケーションズさんが提供するWebRTC Platform SkyWay において、WebRTCとプラットフォーマーならではの課題についての発表でした。

お客様へ説明責任を果たすための情報源としてのオブザーバビリティは、まさにプラットフォーム提供者ならではの開発背景だと感じました。スライドで見られる通信状態の詳細な情報は、プラットフォームとSDKを使う開発者の気持ちを考えると、デバッグが捗ってとてもありがたいと思います。

WebRTCは知ってはいるが使ったことのない技術ということもあり、楽しく拝聴いたしました。

その他印象に残ったこと

まい泉のお弁当はつまみやすく美味しくて、めちゃめちゃ良かったです！！多めに余ってしまうトラブルもあったようで、微力ながらも協力（食べる）させていただきました。個人的に、とても満足感が高かったです。

Lunch Sponsorのメルカリ様の提供により
まい泉のお弁当を配布いたします🥪#srenext https://t.co/10bLjLTvT9 pic.twitter.com/5flfrGfttA
— SRE NEXT (@srenext) August 4, 2024

胃袋のスケールアップとスケールアウトの両方が必要 #srenext https://t.co/ws4mdfetBn
— 𝐶𝑖𝑎𝑜 (@onigra_) August 4, 2024

最後に

SRE NEXTは初参加でしたが、とても楽しく参加することができました。登壇者の方々、スタッフの方々、スポンサーの方々、本当にありがとうございました！

既に2025年の開催についても発表されてますね。来年はClassiからもプロポーザルを出したい！

https://blog.sre-next.dev/entry/2024/08/26/090342

SRE NEXT 2025も楽しみにしています！ありがとうございました！

2024-09-03

tetoru は Ruby 3.3 + YJIT で本番運用しています

Ruby

プロダクト本部 tetoru 開発部の中田です。普段は giraffate という ID を使っていることが多いです。ここでは、弊社が提供している小中学校向け保護者連絡配信サービス tetoru の利用している Ruby のバージョンを 3.2 から 3.3 にバージョンアップしたときの話を共有します。

概要

tetoru では、本文章の執筆時点で Ruby 3.3.4 + YJIT で Rails アプリケーションを動かしています。YJIT とは、Ruby が備えている Just-In-Time (JIT) コンパイラの機能で、これを有効化することで実行時に機械語が生成されアプリケーションの高速化につながります。YJIT に関する詳細についてはこちらの記事をご覧ください。 Ruby 3.2.2 + YJIT から Ruby 3.3.0 + YJIT にバージョンアップした時には多少レイテンシの改善が見られました。一方で、バージョンアップしてから tetoru の Rails アプリケーションを動かしている ECS のメモリ使用率が上がり続けてしまったため、これの改善対応を行いました。また、その後 Ruby 3.3.1 にバージョンアップしたタイミングで ECS メモリ使用率の改善が見られ、前述した改善対応を元に戻しデフォルトの設定で動かしています。

レイテンシの改善

Ruby 3.2.2 + YJIT から Ruby 3.3.0 + YJIT にバージョンアップした時に、全体の平均で 10% ほどレイテンシの改善が見られました。以下は tetoru 全体のレイテンシ（90パーセンタイル）です。黄実線において 24 日 12:00 過ぎあたりに Ruby 3.3.0 + YJIT にバージョンアップしています。点線は黄実線 1 週間前のレイテンシです。Ruby 3.3.0 + YJIT にバージョンアップした後、黄線が点線を下回っておりレイテンシが小さくなっていることが確認できます。バージョンアップするだけで10%もレイテンシを改善できるのはとてもありがたく、改めて Ruby に貢献している方々に感謝したいです。

メモリ使用率の悪化

リリース直後から tetoru の Rails アプリケーションを動かしている ECS のメモリ使用率が上がり続けるという事象が発生しました。

下図はその ECS メモリ使用率のグラフです（70% に位置する赤い点線は tetoru で定めているアラートの閾値です）。下図で 24 日 12:00 過ぎに Ruby 3.3.0 にバージョンアップしましたが、その後通常時のメモリ使用率を超えても上がり続けていました。実は、数ヶ月前にも一度 Ruby 3.3.0へのバージョンアップを試みたことがあるのですが、その時も同様にメモリ使用率が上がり続けていたため、一時的に Ruby 3.2.2 へ戻したことがありました。このため、今回のバージョンアップでは、Ruby 3.3 YJITのメモリ管理とRJITを参考にYJITが生成するコード量を小さくするため --yjit-exec-mem-size に 3.3.0 のデフォルト値 64MiB（ここを参照）より小さい値 32 MiB を設定し、また tetoru では Datadog を利用していますがYJITのコード生成サイズを示す code_region_size を Datadog で取得できるようにしたりと準備していました（YJIT関連のメトリクスは ddtrace のバージョン 1.13.0 から取得できるようです）。しかし、それでもなおメモリ使用率が上がり続けてしまっていました。

このため、更なる対策として Ruby 3.3.0 からデフォルトでオフになった Code GC をオンにすることを決めました。Code GC とはYJIT生成コードのサイズが --yjit-exec-mem-size に達すると全ての生成コードを破棄して以降呼ばれたメソッドを再度コンパイルし直すという機能で、Ruby 3.2 ではこれがデフォルトでオンでしたが、Ruby 3.3 からデフォルトでオフになりました。この Code GC をオンにする修正をリリースしたのが 24 日 18:00 ごろで、その後は Code GC がオフの時に比べてメモリ使用率の傾きが落ち着いたのが見て取れるかと思います（一部傾きが大きい時間帯もありますが）。

最終的にメモリ使用率が落ち着いたのは Ruby 3.3.1 へバージョンアップしてからでした。これをリリースしたのは 26 日 12:00 前で、これ以降はメモリ使用率が上がり続けるようなことはなくなりました。また、--yjit-exec-mem-size を小さい値に設定したり Code GC をオンにするといった対応を行っていましたが、Ruby 3.3 でのパフォーマンス改善の恩恵をより受けるために、その後 --yjit-exec-mem-size をデフォルト値に戻し、さらに Code GC もデフォルト値のオフに戻しましたが、メモリ使用率が極端に上がり続けるようなことはなくなりました。

ちなみに、なぜ Ruby 3.3.0 から Ruby 3.3.1 にバージョンアップしたことでメモリ使用率が安定したかについては、根本の原因については特定できていませんが、3.3.1 での修正を確認していると memory leak がいくつか修正されていたので、もしかするとそのいずれかが原因だったのではないかと推測しています。

所感

Ruby 3.3 YJITのメモリ管理とRJIT などの記事がすでに公開されており、メモリ使用率が上がった場合に取るべき手段をいくつか準備できていたのはとても心強かったです。改めてこのような情報を提供してくれる Ruby コミュニティに感謝したいと同時に、自分たちも Ruby に関する事例や知見などを積極的にコミュニティに還元したいという気持ちになりました。

また、今回のバージョンアップにあたって他社の事例を事前に調査していました。この調査をもとに、バージョンアップ時にメモリ使用率の増加が発生する可能性があるため増加した場合には（自分が調べた範囲では） --yjit-exec-mem-size を調整する、という手順を事前に準備していました。しかし、結果としてはこの予想は外れてしまい、前述の通り --yjit-exec-mem-size を調整してもメモリ使用率は落ち着かず追加の対応を行いました。このとき、改めて YJIT のドキュメントを見直して、Ruby 3.2 では有効化されていた Code GC を 3.3 でも有効化すれば、閾値を超えたタイミングで YJIT の生成コードが破棄される（パフォーマンスは多少犠牲にされることが予想されるが）ため結果としてメモリの使用率が抑えられるのではないかと仮説を立てこれを実行しました。このように、YJIT という難しい領域に対してもしっかりとドキュメント（場合によってはコード）を読み込めば仮説・実行し前進するためのアクションを行えると学びました。

最後に、この文章が Ruby 3.2 から 3.3 へアップデートする方の一助となれば幸いです。　

2024-08-29

QAチームで新卒エンジニア研修を開催して感じた効果

QA 新卒研修

こんにちは。プロダクト本部プラットフォーム部QAチームの牛木です。

今年度、新卒エンジニアの研修にQAチームによる研修が新たに追加されました。
今回は、その研修を開催した経緯と、実際に開催して感じた効果をお伝えします。

なぜ開催したか

QAチームの活動は、開発エンジニアの活動と深く結びついています。
開発エンジニアとして入社する新卒エンジニアに、QAチームの活動を知ってもらい、「品質」に対する理解を深めてもらうことで、開発プロセスで品質を作り込むことを意識した活動が行えると考えたからです。

開催した研修のカリキュラム

5日間にわたり開催しました。以下が実際のカリキュラムです。

開催の目的である「品質に対する理解を深める」ために2つのアプローチを用意しました。

一、QAの業務を理解する

「QAとは何か」「品質保証とは何か」という基本的なところから、QAチームの業務内容や体制、テスト工程からリリースまでの流れなど、具体的な業務フローを伝えました。

さらに、フリーディスカッションとして、「品質とは何か」「品質で意識することは何か」をテーマに対話を行い、考えを共有しました。

二、テスト項目書を作成する

座学やディスカッションだけでは、時間の経過とともに内容を忘れてしまうことがあるため、実際にQAの業務を体験してもらうためにテスト項目書を作成してもらいました。

流れは以下の通りです。

テスト項目書の課題を出す
新卒エンジニアがテスト項目書を作成する
レビュー会でQAエンジニアと対面レビューを行う

このサイクルを5日間で4回実施しました。

レビュー会では、レビュワーとしてQAマネージャーとQAエンジニアが参加しました。QAエンジニアには課題を事前に実施してもらい、新卒エンジニアが作成したテスト項目書と、QAエンジニアが作成したテスト項目書を見比べました。

4回の課題に対して、毎回異なるQAエンジニアにテスト項目書を作成・レビュー会に参加してもらいました。

テスト項目書作成の実践は効果的だった

新卒エンジニアからのフィードバックを受けて、実践を通じて私が感じた効果を2つ紹介します。

一、「全く知らない」状態から「なんとなく知っている」状態にできた

テスト項目書を実際に作成してもらう過程で、テストレベル、テストタイプ、テスト技法、テスト観点など、テストに関する基本的な知識を共有できました。

研修期間や構成を考慮すると本質的な部分まで伝えることはできませんでしたが、「全く知らない」状態から「なんとなく知っている」状態にするだけでも大きな進歩だと思っています。

最終日に新卒エンジニアからも以下のコメントをもらっています。

二、QAエンジニアと遜色ないテスト項目ができた

テスト項目書を作成するための基礎知識と、QAチームが使用しているテスト項目書のテンプレートの使い方をレクチャーし、初日から課題を実践してもらいました。初日はサンプルのテスト項目書がなかったので、試行錯誤しながら作成してもらいました。

課題に取り組んでもらう中で、対面の質問タイムも設けて確認を取りながら進めていました。ただし、そこでの回答は軽いアドバイス程度にとどめ、自由に作成してもらうこと、完了しなくても問題ないことを伝えていました。

新卒エンジニアはすでに3ヶ月間のエンジニア研修を受けていたため、どのようにテストを考えるかを知ることも目的の一つでした。

初回のレビュー会では、新卒エンジニアに悩んだ点を共有してもらい、QAエンジニアが作成したテスト項目書と比較しました。異なる箇所や改善点についてQAマネージャとQAエンジニアからアドバイスを受けました。

2回目以降の課題には、1回目のテスト項目書が活かせるように設計し、振り返りをしながら取り組むサイクルを繰り返しました。

最終日のレビュー会では、参加したQAマネージャとQAエンジニアから「新卒エンジニアの作成したテスト項目書が、QAエンジニアと遜色ないテスト項目書になっている」と高く評価されました。

新卒エンジニアに実施した研修実施後アンケートにも、印象に残ったこととしてテスト項目書作成について記載されていました。

新卒エンジニア研修はQAチームにも収穫があった

研修の開催は、チーム施策の効果を実感する機会にもなりました。

QAチームでは、属人的なテスト項目の作成を防ぐために、標準テスト観点やテスト項目書テンプレートを用意しています。
また、テスト項目書が開発エンジニアにもQAエンジニアにもレビューしやすいように、テストの網羅性が明確になるよう、マトリックス表を使ったテスト項目書の作成を推進しています。

今回協力してもらったQAエンジニアは、その方針を意識してテスト項目書を作成しており、新卒エンジニアからも、そして私自身も「見やすく、分かりやすい」と感じました。
誰が見ても直感的に明白であるテスト項目書を作成するという意識がQAチームで浸透していることを再確認できました。

おわりに：開催側として

今回の研修の開催を通じて、私自身特に痛感したのは、「品質」「テスト」の深さや説明の難しさです。自身の知識が汎用的なものであるか、その情報が古くなっていないか、教える立場として常に注意深くあるべきだと感じました。

また、研修を開催することで、チームの施策やQAエンジニアのスキルを再認識し、QAチームとして品質に向き合うことの意義を考える良い機会になりました。
今回得た学びや効果を活かし、来年度はさらにブラッシュアップした研修の開催に取り組みます。

2024-08-29

S3上のログデータをBigQueryにニアリアルタイム連携する基盤を作った話

データエンジニアリング Google Cloud

こんにちは、データプラットフォームチームの鳥山(id: to_lz1)とマイン(id: manhnguyen1998)です。

Classiでは、AWS上にあるサービスが出力したログをBigQueryに連携するプロダクト「Seneka」を開発し*1、社内の開発者・分析者に役立ててもらっています。

ログの連携はこれまでバッチ処理で行っていたのですが、この夏に技術的なチャレンジも兼ねてニアリアルタイムでの連携が出来るように移行しました。そこで、この記事で移行前後の構成と、移行時に気をつけたことについて、紹介できればと思います。

Senekaのそれまでの構成

改善方法を議論する前に、まずは従来の構成について簡単に紹介します。

アプリケーションまたはロードバランサーからS3にログファイルがアップロードされる
Cloud Composerで毎時実行されるDAGにより、以下の処理を実行
- Storage Transfer ServiceでS3からGoogle Cloud Storage（以下、GCS）へデータを転送
- GCSからStorage Write APIを使ってBigQuery上の一時テーブルにデータをInsert
- 一時テーブルのデータとデータレイクのテーブルとをマージ

従来の構成が完全に悪いわけではありませんが、毎時定期的に実行されるため、開発者はログの反映まで最大60分程度待つ必要がありました。

この構成のままでも、単純にバッチの実行頻度を上げればリアルタイム性を上げられます。しかし、それまでの作りの関係上、ファイルによっては何度も無駄に取り込みが行われてしまうといった問題がありました。このように、バッチ処理のアプローチのままではコスト面でも実行時間面でも限界があるため、イベントドリブンの構成にチャレンジしてみる価値は十分にあると判断しました。

Senekaの新しい構成

新しい構成は以下のようなものです。

アプリケーションまたはロードバランサーからS3にログファイルがアップロードされる
S3にファイルが置かれた時点でPutObjectイベントが発生し、SQSに通知が送られる
- GCP側でStorage Transfer Serviceのタスクが作成され、SQSメッセージをトリガーとして実行される
  - イベントドリブン転送 | Cloud Storage Transfer Service
GCSにファイルが置かれた時点でFinalizedイベントが発行され、それがPub/SubにPublishされる
Pub/SubトリガーによってCloud Functions*2が起動される
- BigQueryへのInsertの方式は従来と同様

結果

ログがBigQueryでクエリできるようになるまで、従来は最大60分程度かかっていましたが、新しい構成では数分でクエリ可能になりました。

今回、効果を正確に把握するために、あるELBの1日分のログを対象に「BigQueryに連携されるまでどれくらいの時間がかかったのか」を集計してみました。

上記から、最大6分未満でログが連携される世界になった、と言えそうです。すべてのログを調べたわけではありませんが、ECSサービスを含めた他のいくつかのログに関しても概ね同様の結果となっていました。

また、イベントドリブン化によってコストが増えることもなく、逆に約10%削減することができました。

21日はリリース前、22日-25日の間は検証期間で一時的にコストが増加しました（後述します）が、チューニング後の26日に本番リリースして以降はコストが削減出来ています。

工夫した点

移行においては以下のようなことを工夫しました。

Design Docによる認識共有

Classiには、Design Docを書く文化があります。

実装に取りかかる前にしっかりと調査を行い、その調査結果をもとにシステムを設計しました。提案のメリット・デメリットを明確にしたうえで、チーム内で意見を共有し、方針を確定してから実装に移るという流れです。

また、選定する技術については、以下の観点で調査・検討をしました。

サービスごとのクォータ・上限

クラウドサービスにはしばしば上限があります。システムの要求に対して、この上限を超えた場合に問題が生じる可能性があるため、将来的にこの上限を超える可能性があるかどうかを予測してサービスを選びます。例えば、Pub/SubトリガーのCloud Functionsの最大実行時間は9分です。もしこの9分を超える場合にどう対応するかなど、こうした上限を常に考慮しています。

サービスごとのコスト体系や無料枠

これは非常に重要なポイントです。選んだサービスのコストプランがどのようになっているか、また、どのようにコストを削減できるかを検討する必要があります。例えば、Cloud Functionsは月に200万リクエストまでは無料なので、Classiの規模であればイベントドリブンで実装してもコストを抑えることができると判断しました。

段階的な移行

新しい構成へ一度に移行するのはリスクが高いため、段階的に移行を進めました。

まず、検証のためにStaging環境で一部のバケットに対して新しい構成を適用し、影響を確認しました。検証中に、BigQueryのスキャンコストが高くなる現象が起きました。Staging環境でもそれまでと比べて数倍になっており、このまま本番環境に移行すると、1日数TB〜数十TBものスキャンが発生する可能性があると予想しました。

調査の結果、1日あたり24回のバッチからイベントドリブンの処理に移行したことで、テーブルへの書き込み頻度が大幅に増加しており、クエリの数が1日あたり数万件に達することがわかりました。

従来のInsert処理は、Delete -> Insert の流れで行われており、この構成には以下のメリットがありました。

データ取り込みの冪等性（Idempotency）を維持できる
既存のファイルが編集された場合でも再取り込みが可能

しかし、レコードをDeleteするときにどうしても走査が発生してしまい、それがスキャン量の高騰の主要因になっていました。今回の要件ではアプリケーションログが取り込み対象であるため、既存のファイルが編集される可能性は極めて低いといえます。レコードが所属するファイルの存在を確認するだけで十分であるため、より単純なInsert処理に移行しても問題ないと結論付けました。

本番環境に適用する際は、データの挿入先をテスト用のデータセットに変更し、旧構成と新構成でデータ内容に差異がないかを確認しました。差分がないことが確認できた後、安全に切り替えを行い、本番環境に移行しました。

段階的に移行を進めた結果、コストの問題や本番環境でしかわからないキャパシティの問題（後述します）にも、焦らず対処できるようになりました。

リリース前後に見つかった課題への対応

段階的に対応を進める中で、スキャン量以外にもいくつか問題が見つかり、さらなる改善が必要でした。

コストチューニング

本番環境でテスト用データセットへの挿入を稼働させた直後、ログの生成頻度が予想以上に高く、コストも非常に高くなってしまいました。先ほどのグラフで発生していたコストの一時的な山は、このときに発生したものです。

分析の結果、以下の3つの問題が見つかりました。

(1) スケーリング不足でリトライが頻発していた問題

最初に設定していたCloud Functionsのスケール上限を超えるリクエストが発生してしまい、リトライが大量発生したためにコストが増大していました。このため、Cloud Functionsのスケール上限を以下の通り増やしました。

インスタンスのメモリの使用率はまだ25％程度だったため、同時実行数を2に増やし、1つのインスタンスで2つのリクエストを処理できるようにした
最大インスタンス数を300に拡大した

この対応により、スケールの問題は解決できました。

(2) GCSのClass A操作数が多く課金が増加した問題

Cloud Billingのレポートを見ると、Cloud Storage ClassA OperationというSKUがコストの一因になっていました。

ドキュメントを確認すると、storage.objects.list というAPIの呼び出しがClass A操作に含まれており、コード内で listObjects メソッドを使用していることと関連していそうでした。

そもそも listObjects を使っていたのは、毎時のバッチで処理していた頃には1回の実行で複数のログファイルを処理する可能性があったためです。

今回は既存のコードを Functions Framework でラップすることで開発を省力化していました。そのため、かつて必要だった listObjects を呼び出す処理が残ったままとなり、これが無駄に動き続けていたのです。最終的に、該当の処理を getObject に変更し、無事にコストを削減できました。

(3) Data Lineage APIの課金が増加した問題

Data Lineage は Dataplex の一機能で便利なサービスですが、ログ連携用のプロジェクトにおいてはほとんど使用しておらず、また一時テーブルを大量に作る関係でコストが無視できない水準まで増加していました。利用を止めることで発生するデメリットもなかったため、APIを無効化してコストを削減しました。

上記の対応により、最終的に一日あたりのコストを移行前よりも低く抑えることができました。

メモリリーク解消

リリースしてから4日後、突然「Out Of Memory」というエラーが発生しました。メモリの使用状況を確認したところ、メモリが段階的に増加していることがわかり、メモリリークの問題が考えられました。

Goのpprofを使用してメモリ利用を分析した結果、解放されていないBigQueryのgRPCクライアントが見つかりました。そのクライアントを解放することで問題を解決しました。

リーク箇所の修正リリース以後は、メモリの使用状況やインスタンス台数が安定することを確認できました。

まとめ

以上、アプリケーションログの連携基盤にイベントドリブンの転送を用い、連携速度を大幅に向上させた話をお届けしました。

リアルタイムでログを分析したい、という要望は一般的なもので、これを可能にするソリューションは数多くあります。近い将来では、例えば BigQuery Omni のようなサービスやプロダクトも試す余地があると考えています*3。

BigQuery Omni を使用すると、BigLake テーブルを使用して、Amazon Simple Storage Service（Amazon S3）または Azure Blob Storage に保存されたデータに対して BigQuery 分析を実行できます。

BigQuery Omniに限らず、昨今登場してきているサービスは 「そもそもデータ転送をしない」 や、 「自前で仕組みを作る手間が要らない」 という方向性を指向しているように思います。

これは非常に大事な考え方です。データ基盤の開発と運用そのものに工数を使うよりも、貯めたデータを使ってどうやって価値を生み出すかという部分にフォーカスできた方がエンジニア組織としてのインパクトは大きくなるからです。

しかしながら、こうして自前で仕組みを設計・実装・運用することから得られる学びは大きく、そのことがまたインパクトを生み出すための力になるという側面もあるでしょう。

旧来のログ連携基盤による毎時の連携でも、「ものすごく困っている！絶対に数分で連携してほしい！」という声はなかったわけですが、この伸びしろにあえて挑んでみて得られた学びは大きく、また最終的にも成功を収める事ができました。事業インパクトを直接生み出す「攻め」でもなく、データ基盤の安定を図る「守り」でもなく、技術的な新しさを取り入れるチャレンジをする「遊び」として、個人的には非常に良い取り組みだったと思っています。

We are Hiring!

最後に取り上げた「攻めと守り、そして遊び」は、私たちデータプラットフォームチームが属するプラットフォーム部の今期テーマでもあります。

部長であるlacolacoと1on1をしていて出てきたフレーズなのですが、自分もとても気に入っており今季だけと言わずエンジニアリングをするに当たってずっと大切にしたい三要素です。

末筆となりますが、そんな「攻めと守り、そして遊び」の鼎立に挑むエンジニア組織で一緒に働きたい仲間を募集中です！少しでも気になった方は、以下求人からご応募・カジュアル面談の申し込みをお待ちしております。

hrmos.co

*1: Classiのデータ関連システムには、哲学者の名前をつける慣習があります。 ref: https://tech.classi.jp/entry/2021/05/31/120000

*2: Google Cloudから2024-08-22にCloud Run Functionsへのリブランディングが発表されましたが、本記事中では Cloud Functions と呼称します

*3:クエリパフォーマンスの懸念や、Order By句の使用等に関する様々な制限、またそもそもまだ東京リージョンに来ていないといったいろいろな制約から、今回はまだ時期尚早であろうと判断しました

2024-07-16

SRE留学体験記(第5期生)

振り返り

こんにちは、学習PMF部でエンジニアをしている辻です。私は2023年12月から2024年5月までSRE留学という社内制度を利用して、SREチームに期間限定で所属していました。
SRE留学とは？や、第1期生、2期生、3期生の体験記はこちらをご覧ください。 tech.classi.jp tech.classi.jp tech.classi.jp

留学を志望した理由

SRE留学をする以前は主にCALEというシステムの開発・運用を担当しており、その中でパフォーマンス改善やSLI/SLOの設定、Toil削減などに取り組んだことで、SREに興味を持ちました。
SREの活動に必要なAWSの知識やTerraformの知識、Classi全体のシステムの知識などを獲得して、学習トレーニングやCALEといったシステムでの開発や運用に活かせることを期待しました。また、SREチームに参加することで、単一のチームやシステムに関わるだけでは得られない視点を獲得できるとも考えました。

留学中にできたこと

基本的に、やりたいことをやらせてもらえる環境なので、留学中にしかできないことや学びになることを実施しました。日常的なタスクとして、SRE宛に来るTerraformのレビューや依頼の対応は行っていましたが、私が実施した代表的なタスクを2つ紹介します。

学習トレーニングのSLI/SLOの設定

CALEというシステムのSLI/SLOの設定を行った経験から、学習トレーニングでもSLI/SLOを設定したいと思いました。SRE留学前からSREチームでは学習トレーニングにSLI/SLOを設定することが計画されており、参加させてもらいました。
SREチームのid:ut61zさんと一緒に取り組むことで安心感があり、またSLO本読書会もこのタイミングで開催され、非常に有意義でした。学習トレーニングチームの方々と話し合いながら設定を決め、id:ut61zさんにも多く相談しました。設定後、このSLOの値を基に改善の議論が発生しており、今後もSREチームと連携しながら改善を続けていきたいと思います。

Opsサーバリプレイス

このタスクはチームで行いましたが、私は主にAnsibleの記述、CI/CDの構築、起動方法の設計・実装を担当しました。Opsサーバとはいわゆる踏み台サーバのことで、検証環境、本番環境でなんらかのオペレーションを実行するために利用しています。既存のOpsサーバはitamaeでプロビジョニングされているのですが、Classiではそのリポジトリのメンテナンスが不十分だったり、EC2関連のシステムの関心が入り混じったリポジトリからOpsサーバの関心の分離をしたいという意図があったため、AnsibleとPackerを用いて作り直しました。
既存のOpsサーバでは、起動方法にAuto Scalingグループを使っていましたが、デタッチ忘れやタグの付け忘れ、Opsサーバの消し忘れや立ち上げが手間などの課題がありました。
そのため、新しいOpsサーバの起動方法はChatOpsを採用し、AWS Chatbotを使ってより簡単に立ち上げることができ、管理しやすいようにしました。

起動と削除をSlack上で行えるようにしたことで、管理が容易になり、履歴も残るため、既存のOpsサーバでの起動方法の課題も解決しました。
このリプレイスのタスクで学習した許可セットなど、SRE留学中に、普段の業務ではあまり触らないところも触ることができ、勉強になりました。SRE留学から戻った後もこれらの知識は活きてくると思います。

これらのタスク以外にも、構成図の作成、Sandboxリソース作成の通知、GithubActionsの導入、証明書の更新など、SRE留学をしていなければ経験できなかったタスクを多く経験し、多くの学びがありました。

良かったこと

普段の業務では、あまり触れることのない部分に触れた

具体的には以下の機能などです。

SCPを含んだAWS Organization
IAM Identity Center
IR購入に関するあれこれ

SRE留学では、SREチームと同等の権限を持ってSREとして業務を行うので、普段では触れない部分に触れることができるのは、SRE留学の良いところだと思いました。

コードレビューを通してClassiのシステムへの理解とAWS・Terraformの理解が深まった

SREチームの朝会では、SREチーム宛に来たTerraformのプルリクエストをレビューするのですが、その中で出てきたわからないことはその場でSREの方に聞くことができるので、すごく勉強になり、レビューを行う過程で、Classiの全体のサービスやそのシステム構成をある程度把握することができました。
また、留学前は自身のチームの範囲のAWSサービスやそのTerraformコードの部分しか理解していませんでしたが、Classi全体で使われているAWSやTerraformへの理解も深まりました。

難しかったこと

横断的な動きができなかった

留学生の振り返りでよくこの点が挙げられていますが、他のチームから寄せられる質問への対応やプラットフォームに関することに積極的に関わっていくことができませんでした。「こういった場合どうしたらいいですか？」という質問がSRE宛のメンションで来ても、知識が必要ということと、SRE留学生としての立場では意思決定が難しく感じる面があり、あまり関与していくことができませんでした。

今後

ClassiのSREチームはプラットフォーム部のチームなので、直接的なSREingをプロダクトに対して行うというよりはプロダクトチームへのSREingの支援という側面が強いです。留学期間中に特定のプロダクトに対する直接的なSREingはあまりできませんでしたが、プラットフォーム部のSREチームに留学したことで、今まであまり触ってこなかった技術などに触れられてとても充実したSRE留学でした。SRE留学からプロダクトチームへ戻ったときに、その経験を活かし、よりアプリケーションの近くでSREingを実践していき、SREチームと連携しながら取り組んでいきたいと考えています。

2024-07-08

詳解Terraform読書会を実施しました

勉強会・イベントインフラ読書会・輪読会

こんにちは。プロダクト本部プラットフォーム部SREチームの id:ut61z です。 SREチームが主体となって書籍『詳解 Terraform 第3版』(以後、詳解Terraform)の読書会を社内で実施しました。

www.oreilly.co.jp

どう進めたか、実施してみた感想や反響、学んだことをご紹介しようと思います。

なお、過去にもSREチームが開催した読書会を実施しているので、よければこちらもご覧ください。

tech.classi.jp

詳解 Terraform 第3版について

詳解TerraformはTerraformについて体系的に学べる一冊で、サンプルコードとともにハンズオン形式でAWSのリソースを構築しながら学ぶことができます。

Terraformの実装方法、操作方法、注意点、特徴など全体像を把握するにはとてもよい書籍だと思います。

全体の構成については以下のようになっています。

1章: 従来のプロビジョニングツールとの違いと、インフラストラクチャを取り巻く環境の遷移とともにツールがどのように移り変わってきたかの紹介から始まり、IaCの利点やなぜTerraformを使うかについて解説がなされます
2章: AWSを用いたハンズオン形式でのTerraformの操作方法・定義の仕方についての紹介パートが続きます。EC2 1台で稼働する素朴なWebサーバ構築から始まり、徐々に周辺リソースを追加していくことで可用性の高いスケーラブルなWebシステムを構築することを目指します。Application Load Balancer、Listener、Listener Rule、Target Group、AutoScaling Group、EC2を用いた基本的な構成のWebシステムを理解することができます
3~7章: TerraformのState、Module、ループや条件分岐など動的なTerraformリソースの記述の仕方など、Terraformに搭載されている様々な機能について紹介され、やや応用的な使い方・記述の仕方について知ることができます
8~9章: 本番環境の構築にあたっての注意点、テストについて紹介されています
10章: チームでTerraformを運用するにあたっての勘所やデプロイワークフローの構築について触れ、組織へTerraformを導入・定着させていくための戦略についても紹介されています

なぜ詳解Terraform読書会を実施したか

ClassiではほとんどすべてのインフラリソースをTerraformで管理していて、SREチームだけでなくプロダクトチームのエンジニアもインフラリソースの構築・運用を行っています。

しかし、エンジニア全員がTerraformを用いたインフラリソース構築経験があるわけではなく、スキルやレベルにばらつきがあるのも事実です。

それを踏まえ、主に下記2点を期待して読書会を実施しました。

インフラストラクチャ、Terraformに対してとっつきにくさを感じているエンジニアの心理的ハードルを少しでも下げ、興味を持ってもらうこと
エンジニア組織全体のTerraformスキルのボトムアップを図り、より開発効率を上げること

どのように進めたか

週1回のペースで1章ずつ読み進めました。担当者は1章分の要約と感想を前半30分で発表し、後半30分でその章について参加者全員でディスカッションを行うという形式で読書会を実施しました。

今回の読書会において工夫した点は、SREチームのメンバーが各章のまとめにコメントを加えて、実際のClassiでの運用はどうしているかをコラムとして追加した点が挙げられます。

座学的な読書会にとどめず、実践的にClassiでTerraformを書くならどうすればよいかをイメージしやすいようにし、普段の業務との接続を試みました。

実際にやってみて

あくまで読書会として書籍を読み進めることをスコープとしていたので、主催者としてはAWSにリソースを構築することまでは参加者に強要はしなかったのですが、結果的には参加者の多くが実際に手を動かしてリソースの構築を行い学習を進めていました。

Terraformを触っている参加者であっても、ゼロからインフラリソースを構築する体験は普段の業務ではなかなか味わえないので、ハンズオンを進めながらシンプルなシステム構築を行い、改めてAWSやClassiのシステム構成への理解が深まったという感想もありました。

特に理解が深まった点として挙げられていたのは、Terraformのロックの仕組みや、Stateファイルの位置づけや特徴などについてでした。「Stateファイルには秘匿すべき情報が平文で書き込まれてしまうので注意すべき」など、これだけは抑えておこうという知識が参加者にインプットされたのも、実務に直結する知識として今後活きてきそうだという感触を得ました。

他にも、Terraformを組織にどのように導入するかについて言及されている章では、新しい技術を組織に提案・導入・定着させていくための戦略が記されていて、Terraformに限らず応用が効きそうだという感想もあり、思わぬ収穫があったメンバーもいたようでした。

一方で、どんな読書会でも起きがちな問題ではありますが、回を重ねるごとに中だるみをして参加者のモチベーションが低下し、参加を見送る機会が増えたという意見もありました。中間ふりかえりの回を挟んだり、途中で改めて目次を眺めてこの章は実務でどう役立つかなど、現在地の確認をしてモチベーションを維持するなどのアイディアが出ました。