Classi開発者ブログ

教育プラットフォーム「Classi」を開発・運営するClassi株式会社の開発者ブログです。

Classiセキュリティ強化への道・前編~Micro Hardeningで修行編~

こんにちは、サイバーセキュリティ推進部の野溝(@nomizooone)です。普段はClassiサービスの脆弱性診断や顧客対応などを担当しています。今回は、Classiのセキュリティ強化のための取り組みについて書きます。

エンジニア個人のセキュリティ対応力を高める施策

Classiは2020年に、大規模な個人情報漏えいインシデントを起こしてしまいました。

インシデントの詳細についてはこちらで情報公開をおこなっています。

このインシデントを二度と繰り返さないために、様々な取り組みをおこなっています。もちろん、技術的に高度なセキュリティのしくみをとりいれたり、組織として体制を整えるなどの対策も重要ではありますが、Classiで働くエンジニア個人のスキルアップも重要な要素のひとつと考えています。

セキュリティインシデントの対応を学ぶには、実際にセキュリティインシデントを経験するのが一番効果のある方法であると言えます。しかし、だからといって実際に事故を起こすわけにはいきません。

サイバーセキュリティ推進部では、エンジニア個人のセキュリティインシデントへの対応力を養うため、Hardening Project(ハードニングプロジェクト)がデザインしている「ハードニング競技会」に積極的に参加を推奨しています。

ハードニング競技会とは

脆弱性の潜むビジネスシステム(ECサイトなど)へのハードニング(堅牢化)力の強さを総合的に競うコンペティションです。Hardening Projectというボランティアのメンバーによって2012年から運営されていて、その設計の素晴らしさから、2022年にはグッドデザイン賞も受賞されています。

「ハードニング競技会」が2022年度グッドデザイン賞を受賞した際のプレスリリース

実践演習に特化したMicro Hardening

ハードニング競技会の詳細な説明は今後の記事に譲りますが、そのハードニング競技会のコンセプトをよりカジュアルにし、教育目的に特化した川口設計様のMicro Hardening(マイクロハードニング)を今回Classiで社内向け研修として開催しました。

Micro Hardeningの内容がどのようなものかは、川口設計様のサイトに掲載されている漫画がわかりやすいのでよかったら読んでみてください。

川口設計様のサイト

Micro Hardeningについて、簡単に説明すると、まずチーム毎に架空の事業環境となるECサイトなどが与えられます。そのサイトには数多くの脆弱性が潜在しており、攻撃者がそこを狙って攻撃を行います。それと同時に、たくさんのお客様もECサイトを利用し商品を購入します。脆弱性の対応によって攻撃者の攻撃を防ぎながら、お客様の購買行動を阻害しないこと。つまりセキュリティを高めながらビジネスを守ることが求められます。(※攻撃者もお客様もBotです)

Micro Hardeningのイメージ
Micro Hardeningのイメージ

リアルタイムに売上と防御点によってスコアがつけられ、チームの実力が数値として可視化されます。

Micro Hardeningでは、45分間を1セットとしてこれを繰り返し行うことが特徴です。

演習はセットごとにリセットされ、次セット以降も同じ環境で同じ攻撃が行われます。これを数セット繰り返すことで、初回で受けた攻撃の対処方法を次セットで試すことができるなどの多くの実践的な学びに繋げることができます。

Micro Hardeningには、無料で参加できる「コミュニティ版」と企業内部で開催する「クローズド版」があり、Classiで行ったのは後者のクローズド版です。Classi社員同士でチームを組み、インシデント対応の技術やコミュニケーションを学んでいく目的でした。コミュニティ版とは少しレギュレーションが違う部分があるので、Micro Hardeningについて検索してこの記事にたどりついた方はご了承ください。

Micro Hardeningで行ったこと

具体的なMicro Hardeningの内容を書くとネタバレになってしまうので、私が施策の参加者として行ったことを中心に書きます。

まず、研修参加者の8名を選出し、4名ごとに1チームを組成しました。 参加者には、チームをガイドする役割となるHardening経験者の他、未経験であっても普段からセキュリティに興味を示している若手を中心にバランスよくスカウトしてきました。通常業務の時間を割いての研修参加になるので、業務の調整を少し心配しましたが、Classiは教育の会社だけあって学習に意欲的な社員が多く、フォローをお願いすることになる他の社員の方にも快く協力してもらえてありがたかったです。

当日の記念写真
当日の記念写真(左上は川口設計の川口さん)

事前準備でやったこと

事前に川口設計の川口さんから、競技環境のシステム構成などが書かれた資料が提示されました。私の所属しているチーム2ではそれを参照しながら簡単な準備を行っていました。

指定された構成がやや古いバージョンであったり(※古いものの方が情報があるので対応がとりやすいからだそうです)普段の業務では扱わないサービスも多く、いきなり本番を迎えるには不安があったため、Oracle VM VirtualBoxを使ってOSのインストールを行うところから環境を作ってみる、という準備を行いました。 果たしてこの準備が直接的にどの程度役に立ったかは不明ですが、チームビルディングを行うという意味で一緒になにか作業を行い質問しやすい・お願いしやすい関係性をつくる、という点で成果があったのではないかと思います。和気あいあいと準備ができてよかったです。

その他、コマンドやパスワードの一覧を記載したチートシートを作成し、なるべく対応が円滑に行えるように工夫をしました。

演習当日の動き

弊社は基本的にフルリモートで業務をおこなっているので、当日も全員リモートで参加しました。

休憩を挟みつつ第1セットから第3セットまでを行い、全員が環境に慣れてきたところで川口さんの簡単な解説が入り、その点を踏まえて準備⇒最終セットへ。という流れでした。 4セットを終えてスコアはこんな感じでした。

演習全体のスコア
演習全体のスコア

2行目がチーム2のスコアです。前セットの学びを次に活かすことで順調にスコアを伸ばすことができました。

競技中はグラフが提供されて、スコアの伸びがわかるようになっています。第1セットのスコアグラフはこちらです(※チーム3番は参考値とのことです)

第1セット競技中のスコアグラフ
第1セット競技中のスコアグラフ

第1セットでは、途中でセキュリティ対応のつもりで誤ってデータベースのユーザーを削除してしまい、システムが全停止しそれ以降の売上が一切入らないという失敗をしました。しかも手順がわからず復旧もできませんでした。これが現実だったら大惨事です…想像しただけで背筋が寒くなります。

しかし、Micro Hardeningであれば泣いても笑っても45分で終わります。次セットでは気持ちを切り替え、同じミスをしないようすること、さらに次のセットでは、ユーザーを削除するのではなくパスワードを変更するという適切な対応(おそらく)を行うことができるようになりました。

そんな訳で成長した私達の最終セットのグラフはこちらです。

最終セット競技中のスコアグラフ
最終セット競技中のスコアグラフ

最初のグラフとスコアの伸びが全然違います。このように、対応能力が可視化される環境の中で、Micro Hardeningの演習セットを何度も繰り返し、高速でフィードバックをうけて素早く改善を回すことで、チーム全体の成長が促進されることを身をもって体験することができました。Classiでも生徒の学びの力を高めるための様々な機能を開発していますが、学習効率を高めるという点で大変参考になりました。

ふりかえり

当日もチーム別に簡単に振り返ったのですが、後日今回のMicro Hardeningに参加したClassiメンバー全員であらためてふりかえりを行いました。

Fun/Done/Learnでふりかえり
Fun/Done/Learnでふりかえり

Fun/Done/Learnのフレームで振り返ってみました。 小さくて申し訳ないのですが、特に右下に付箋が多く貼られていて、全員にとって学びの多い場であったことがわかります。

特に、以下の学びを得たことが複数のメンバーから挙げられていました。

  • インシデント対応における事前準備の大切さを知ることができた
  • 根本的なセキュリティ対策の大事さを理解した
  • チーム内コミュニケーションの大切さを改めて認識した

まとめ

Classiセキュリティ強化への道・前編~Micro Hardeningで修行編~でした。 実践的で貴重な経験を積ませていただいた川口設計様、本当にありがとうございました。

さて「前編」の表記の通り、実はこの記事にはまだ続きがあります。

最初にご紹介した、ハードニング競技会(通称:Hardening本戦)が2022年11月15日に沖縄の万国津梁館にて開催され、今回Micro Hardeningに参加したメンバーの一部が本戦にも参加することが決定しています。

このMicro Hardeningは、普段の業務におけるセキュリティ対応力を高めると同時に、一部にとってはHardening本戦に向けての修行の意味もあったということになります。果たして修行の成果がでるのか、それとも辛酸を嘗めることになるのか、後編をお楽しみに!

データAI部で3年間続けた輪読会の話

こんにちは!開発本部で本部長をしている id:tetsuro-ito です。実はデータAI部というデータ系組織の部長も兼任しています。今日はデータAI部で3年ほど続けた輪読会の話を紹介します。 3年間の中でさまざまな環境の変化や人の入れ替えがありながら、6冊の本を輪読しました。最近ではメンバーも増え、個々人の興味関心もばらついてきたことから、いったん定期開催してきた輪読会の開催をストップし、また必要に応じて読みたい本が登場した際に再開するというアイドリング状態になりました。そういうわけで、このエントリは振り返りの意味合いも込めています。

ちなみに過去のブログでもデザイン組織であるUXデザイン部と共同で開催した輪読会の記事も書いていますので、参考にリンクしておきます。

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

輪読会の開催背景

そもそもデータAI部でなぜ輪読会を開催しようとしていたかを少し振り返ります。社内のドキュメントを紐解くと、輪読会は2019年7月から開催をしていました。 データAI部は2018年6月に前身であるAI室として誕生し、4名のメンバーからスタートしました。その後、採用によりメンバーが増加したり、立ち上げた室長が別の部署に異動したりと、黎明期ならではの激動の時期を歩んでいました。そうした状況であったため、チームとしてあまり機能していたとはいえない状況でした。加えて、全員中途採用で入社したメンバーの集まりであったため、その知識やスキルもばらつきが多い状況でした。

そこで、データAI部のインプットやコミュニケーションの場として、輪読会を開催することになりました。

輪読した本の一覧

これまでに輪読した本の一覧とかかった期間をリストで紹介します。 ほとんど決め事はなかったのですが、ゆるい制約として、データAI部の業務に役立ちそうなもの、一人で読むと心が折れてしまいそうな重厚なものという選定条件を設定していました。一人で読み切れるものは各自で読めば良いので、全員で読むということを考えると、それなりに骨が折れる内容の本の方が良いだろうと思ったからです。この選定条件は良いストレッチをかけてくれたので、良かったと思います。

タイトル 期間 参加人数
Pythonによる数理最適化入門 3ヶ月 7人
プログラミングコンテスト攻略のためのアルゴリズムとデータ構造 6ヶ月 11人
行列プログラマー – Pythonで学ぶ線形代数 1年 11人
People + AI Guidebook 3ヶ月 13人
データ指向アプリケーションデザイン 6ヶ月 9人
Real World HTTP 9ヶ月 17人

輪読する本の選び方

輪読会の終盤の時期に差し掛かると、次の選定本を何にするのかという議論が始まります。 そこで、メンバー各々が輪読会で読みたい本をピックアップし、それを輪読会の時間を使って議論します。 候補の対象となる本の冊数は優に30冊を超えるのが常です。データAI部のメンバーがそれぞれの本の良さをPRし、全員で投票を繰り返します。そこでもっとも票を集めた本が次の輪読会の対象本として選定されます。

データ指向アプリケーションデザイン選定時の投票リスト

この方式では選定までに少し時間がかかりますが、データAI部のメンバーがどんな本に興味関心を持っているか、最近はどんな本が話題になっているかなどが可視化され、選定本に選ばれなくても、これをきっかけに読んでみたりなどの副次的な効果もありました。

輪読会の進め方

読む本を決めたら、その次の輪読会までに全員が本を購入し、ざっと全体を俯瞰しておきます。そうすることで、その本がどんな内容なのか、自分はどのあたりを担当したいのかなどの目処が立ちます。 そして、業務時間内の毎週決まった時間を固定枠として確保し、参加者全員の予定を入れておきます。業務などで参加が難しい場合は気軽に欠席可能、自分が担当であっても気軽にリスケが可能というようなカジュアルなテイストの運営を心がけていました。

最初の頃は挙手制で担当したい章や節を割り振り、回していましたが、最終的にルーレットで担当者をランダムでアサインする方式へと変わっていきました。

担当決めのルーレット

担当範囲の決め方

担当範囲は読む本の内容によって、柔軟に設定すると良いです。私たちも当初、1章単位で担当するという粒度で運営を行っていました。しかし、本によって章の内容の濃淡はさまざまであることがわかりました。場合によっては何週間も同じ人が担当することになってしまい、心が折れて輪読会の継続のピンチに陥ってしまいます。 そのため、私たちは一人当たりの担当範囲を広くするのではなく、章内の節を2節担当するという方式で、細かいサイクルを回すようになっていきました。 「行列プログラマー」を1年かけて読んだ際に、進めるのに非常に苦労したため、こうしたやり方を編み出しました。これはなかなか良い方法だったなと、今振り返ると思います。

こまめなサイクルと振り返り

初回で全員分の担当範囲を割り付け、輪読会を実施した後に、KPTのフレームワークを用いて、進め方についての振り返りを行いました。

行列プログラマー輪読時の中間振り返りのまとめ

このように通常のソフトウェア開発でよく行われる仕組みを輪読会にも応用することで、円滑な輪読会の運営を実現できました。 読み始める前では、どうしても内容の濃淡や章や節の構成、難易度などがわからないので、担当が一巡した頃に進め方の振り返りをして、やり方を変えていくという方法はとても良い効果があったと思います。

チームビルディングへの効能

輪読会を開催する前はデータAI部のメンバーの集まりは週に一度の定例会で、自分の業務の進捗報告や困っていることの相談をする場だけしかありませんでした。当時はコロナの前でもあり、毎日出社をしていたことやメンバー同士の席が近かったことから、気軽に雑談や相談ができていたため、それほど困ることはありませんでした。しかし、チームの連帯感という点ではやや欠けている部分もありました。 そこで、輪読会において、共通の目的に対して役割分担をし、意見を交わしながら進めていくような擬似プロジェクトとしての役割も持たせていました。普段の業務とは異なる性質のものなので、雑談や豆知識なども共有しやすい空気ができました。挫折せずにやり切る習慣も少なからず作れたのかなと思います。 また、本の内容によってはソフトウェアエンジニアやデザイナーをゲストとして招待し、一緒に進めていくことで、自分達の専門外にいるメンバーの解釈の仕方や物事の捉え方を認識できたこともあり、チームの中だけでなく、チーム外メンバーへの理解の促進にも一定の効果があったように思います。 前述したデザイナーとの共催の輪読会では振り返りにmiroを使い、毎回ワークショップ形式で読み進めながら、その内容をグラフィックレコーデイングにまとめるなど、データAI部のメンバーだけでは絶対に取り入れないだろうなというツールややり方にもチャレンジできました。 2020年以降はリモートワーク前提の働き方にシフトしたため、今までのやり方をUnlearnして、オンラインでの輪読会はどのように行えば良いかなどの試行錯誤もでき、非常に良い体験となりました。

オンライン/オフラインでの特性

元々オフラインで輪読会を開催していたこともあり、最初は会議室に集まって発表者がプレゼンテーションを行うスタイルでした。最初は数理最適化の本を輪読したこともあり、数式や図などを説明する際にはホワイトボードを用いてスムーズに行うことができました。逆にPythonコードを説明する際はプロジェクターでエディタなどを表示して共有していましたが、あまり体験として良いものではなく、各自が共有されたコードを手元で確認しながら内容を聞くというものでした。

途中からオンラインでの輪読会の運営に移行しましたが、この特性が真逆となって跳ね返ってくることがわかりました。オンラインの場合、ホワイトボードがないため、数式や図をサクッと共有したい場合のソリューションがなく、非常に苦労しました。オンラインでのホワイトボードなどもいくつか試してみましたが、オフラインのホワイトボードと比較すると、体験が悪く、徐々に利用しなくなってしまいました。

一方、良い面もあります。先ほど説明したコードの共有の部分ですと、自分のPCの画面を共有することになりますので、オフラインのケースよりも圧倒的に体験が良くなりました。 加えて、本を選定するときに電子本の有無はそこまで大きな理由ではなかったのですが、オンラインでは画面が共有できるため、電子本を所持しておくと、該当の記述を共有しやすく、最終的には多くのメンバーが画面を2分割し、一つの画面に本の担当箇所、もう一方の画面にesaにまとめた自分の説明用資料を共有するスタイルが主流となりました。

輪読会に限った話ではありませんが、オンラインの輪読会の場合、参加者の反応などがわかりにくいケースが多く、発表者のモチベーションが下がってしまうことがあります。特にオンライン時での開催は聴衆のスキルが重要となり、発表者が説明している時の相槌やチャットによるリアクション、自分の知っている他の文献の共有などの輪読会を盛り上げていくためのフォロワーシップが非常に重要であることも痛感させられました。このスキルはオンラインMTG全般で役に立つため、良き学びとなりました。

さいごに

企業内で輪読会を開催するのが難しいという声はよく聞きます。しかし、ここまで紹介してきたように、本の知識をインプットするだけでなく、メンバー同士の交流を促せたり、チームビルディングという観点でも良い効果が期待できる取り組みだということがわかりました。私たちは3年間で6冊読み切ったことで、どんな技術書でもみんなで読みきれるという実感を得ることができました。 一方で同じような取り組みを継続して行うことでの惰性感のようなものも生まれてきたため、一度取り組みをストップし、改めて必要なタイミングで再開する意思決定をしました。 リモートワークが中心となった働き方の中で、横のつながりや斜めのつながりを作るという目的でも、輪読会はとても良い効果を期待できます。この記事がこれから輪読会を開催してみたいと思う方の参考になれば、筆者としては嬉しい限りです。

iOSDC Japan 2022に参加しました!

はじめに

こんにちは!Classiでモバイルエンジニアをしております、id:indiamelaです。

iOSDC Japan 2022で初めてオフライン参加してきましたので、そのご報告をさせていただきます!

(去年参加した横田さんによるエントリはこちら↓) https://tech.classi.jp/entry/2021/11/17/182544

iOSDC Japan 2022の紹介

iOSDC Japan 2022 はiOS関連技術をコアのテーマとしたソフトウェア技術者のためのカンファレンスです。

弊社Classiは今回、シルバースポンサーを務めさせていただきました!

https://iosdc.jp/2022/

今年は9/10~9/12の3日間開催され、初めてのオンラインとオフラインのハイブリッド開催となりました。

コロナ禍での開催でしたが、チケット発券数は過去最大とのこと。オフラインの入場者は少ないと思いきや、3日間とも大賑わい!オンラインでも同じように盛り上がっており、どちらで参加しても十分楽しめるものでした。

1階ブーススペースの様子
セッションの様子

印象に残った発表

ここからは、私がiOSDCを振り返って特に印象に残っている発表を簡単にご紹介させていただきます。

ウーニャ、しってる。みんなふんいきでSwiftUIをつかってる。

https://fortee.jp/iosdc-japan-2022/proposal/28a7ecff-a0f1-40c9-80a5-b8ed2fb0fd94

DeNAのウホーイさんによる発表です。タイトルがインパクトあって笑っちゃいましたが、内容はとても真面目。

SwiftUIはUIKitに比べて直感的に書きやすいが故に、何も考えずに書くと巨大なViewが出来上がってしまいます。こうした膨れ上がってしまうViewをうまく分割して、読みやすくする方法について分かりやすく説明してくれています。

ClassiではまだリリースしているアプリでSwiftUIを採用しておりませんが、今後採用するにあたってとても重要な知識を学ぶことができました。

Swift Concurrency時代のリアクティブプログラミングの基礎理解

https://fortee.jp/iosdc-japan-2022/proposal/397d52a7-8f62-4c40-8392-2dc081227189

ZOZOのばんじゅんさんによる発表は、リアクティブプログラミング(RP)の基礎に立ち返って考えるというものでした。

発表後にばんじゅんさんとお話する機会があったのですが、どうやら学生時代にRPの研究をされていたとのこと。

昨今RPが主流となってきた時代にSwift Concurrencyが新たに出てきて、一体どう違うの?みたいな疑問は私だけでなく多くの人が持っていたかもしれません。

それらを時代背景やそれぞれの本質を捉えながら解説していて、疑問の解消につながる素晴らしい発表でした。

Swift Concurrency時代のiOSアプリの作り方

https://fortee.jp/iosdc-japan-2022/proposal/b50a5503-00e3-4dd3-ba1a-b28cd59c6a33

koherさんによるこちらの発表は、まるで自分が実装しているかのように話の流れが綺麗で、とてもわかりやすい内容でした。Actor Protocolなど、浅い知識で留まっていた事の理解が深まり、またテスト実装にもどう取り入れるかを学ぶきっかけになりました。

私たちClassiメンバー内でも「この動画は新人が入ってきたらぜひ観てもらいたい」という声が上がるくらい好評でした!

モバイルアプリのオブザーバビリティを向上させるプラクティス

https://fortee.jp/iosdc-japan-2022/proposal/6bafac07-06f1-4846-964e-78dccfb29185

サイバーエージェントのnadeさんによる発表です。オブザーバビリティの向上を今期の目標とする私たちにとっては一番と言っていいほど良かった内容でした。

近年SREの手法をアプリケーションまで拡大する動きが広まっている一方、モバイルアプリの信頼性を担保することはとても難しいものです。そうした中で、モバイルアプリにおけるオブザーバビリティとは何なのか、どうやったら向上させることができるのかについて丁寧に解説して下さいました。

この発表の後、私たちはnadeさんに直接話を伺いながら具体的なネクストアクションまで決めることができ、とても実りのある時間になりました。

実は私たち...

実は私たちClassiネイティブアプリチームは、2020年から始まったフルリモート体制以来、一度もオフラインで集まることがありませんでした。

それが今回のiOSDC 2022をきっかけに、全国からiOSアプリ開発者が集結!開催前日には本社で仕事をしながら親睦を深め、イベント中もたくさん議論する事ができました。

こういうきっかけ作りができた事もとても嬉しかったです。

おわりに

今回はオンラインとオフラインの同時開催でしたが、お祭りのような雰囲気を味わったり多くの人とコミュニケーションできるのは、オフラインならではの魅力だと改めて感じました!

最近は休みの日にiOSDCのTシャツを着てアーカイブされた動画を観たりしています。まだお祭り気分が抜けきってないようです。笑

以上、iOSDC 2022の参加レポートでした!来年も楽しみにしています!

SRE留学体験記

​​こんにちは、開発本部のliaob88です。

私は今年の2022年4月から9月までの半年間、SRE留学制度を使ってSRE留学を行っていました。今回はそのSRE留学制度に関する記事を書きたいと思います。

記事の構成としては、まず始めに@lacolacoさんよりSRE留学制度についての説明をしていただきます。その後私の方から実際にSRE留学をしてみた上での感想や振り返りを書いていきます。

SRE留学制度とは

こんにちは、開発支援部の部長をしている@lacolacoです!今日は主役ではないので軽く制度の紹介だけしてバトンタッチします。

SRE留学制度とは、普段はプロダクトチームでアプリケーション開発に携わっているエンジニアに、期間限定でSREへジョブチェンジしてもらうというものです。チームの戦力が一時的に低下する代わりに、実務を通じて短期的に効率よく学習できます。留学を終えてチームに戻ると、獲得した新しいスキルや経験によってチームが自己解決できる問題の幅が広がります。また、エンジニア個人としてのキャリアの可能性も広がりますし、開発組織としてもサービス全体の運用レベルの底上げが狙える、三方よしな施策です。

しかしそんな都合のいい施策は当然ながら簡単に実現はしません。これを可能にするのは本人の高いチャレンジ精神と学習意欲、そして留学生を受け入れて教育するSREチームの受容力です。このあたりは語りたいことがたくさんあるのですが、それはまたの機会に。

ともかく、今年の4月からスタートし、この記事を書いているliaob88さんが第1期生です。10月からは入れ替わりで第2期生の留学が始まります!この後の記事で語られると思いますが、本人にもチームにも非常にいい影響を与えているので、留学制度は今後も継続発展させていくつもりです。

以上が前説でした。それでは本編をどうぞ!

なぜSRE留学をしたのか

私がSRE留学をすることになったきっかけは、上司からお誘いをいただいたことでした。お話をいただいた時は素直に驚いたのと、「自分なんかがやっていけるのだろうか」という不安を感じました。

しかし、私は元々SREに興味があり、SREが普段どのような業務をどのような考え方で行っているのかについて知りたいと思っていました。そしてこのような機会はなかなか訪れないかもしれないと思いSRE留学を決めました。

SRE留学では何をしたのか

大きく分けてSREの通常業務と所属チームとコラボレーションをして進める業務の二つがありました。

SREの通常業務

大きく分けると以下のようなことをしました。

  • 他チームからの相談、作業依頼、レビュー依頼対応
  • 改善活動
  • 障害対応

他チームからの相談、作業依頼、レビュー依頼対応

SREはサービス開発、運用における技術的な相談を他チームから受け付けています。

  • 〜ということを実現したい。なので、こういうアーキテクチャでそれを実現していこうと考えているが、SREの意見を聞きたい
  • このサービスの運用で〜という問題がある、なので〜のようにしたいと考えているが、どう対応していくのが良いかSREにも聞きたい

などなど、内容は様々です。このような各種相談に対してSREとして意見を出し、他チームの開発をサポートしていました。

また作業依頼、レビュー依頼の対応もSREの大切な業務の一つです。Classiのインフラには、SREのみが操作できるリソースや、変更、作成においてSREからのレビューを必須としているリソースがあります。そのためSREには日々インフラ関連の作業依頼、レビュー依頼がたくさん届きます。そちらの対応を他のSREと共に行いました。

改善

改善もSREの重要な業務の一つです。SREは日々他の作業に追われながらも地道に改善を続けています。

私が留学期間中に行った改善としては以下のようなものがありました。

  • 監視環境の整備
  • 業務フロー改善
  • 不要なインフラリソースの削除
  • インフラリソースの最適化によるコストカット

その中から今回は、監視環境の整備の一環として行ったAmazon DynamoDBに関する、DatadogのMonitorやWidgetの整備について少し触れておこうと思います。

現状複数のサービスがアーキテクチャの一部として使用するなど、Amazon DynamoDBはClassiにおいて、運用上とても重要なインフラの一つとなっています。しかし私がSRE留学を開始したタイミングでは、その監視環境は十分に整備がされておらず、改善が必要な状況でした。

私はこれまでにも、DatadogのMonitorやWidgetを使って監視環境を整備する作業は経験していたので、やればできそうと思い、この改善業務を担当しました。

(例. 作成したAmazon DynamoDB関連のMonitorとWidgetの一部)

実際にやってみると、Amazon DynamoDB自体についても学ぶ瞬間が多くあり、結果的に非常に有意義な業務となりました。

そして何よりも、監視環境の整備というサービスの信頼性を高めることにつながる施策を実施できたという点については、SREとして良い改善ができたのではないかと考えています。

障害対応

障害対応もSREの業務の一つです。特に、複数サービスで共有されているリソースが起因となって起きる障害は、影響範囲も大きくSREも障害対応を行います。

私が留学していた期間においても、そのような障害が何度かあり対応に参加しました。しかし参加したどの障害対応においても、解決に貢献することはあまりできず、個人的には悔しい思いをしました。自分もいつかこのような障害対応においても貢献ができるように成長しなければいけないと強く感じました。

所属チームとコラボレーションをして進める業務

SRE留学制度には、留学生を将来的に所属チームに戻し、Embedded SREingを実践していく人材に育てていくという狙いがあります。 この業務は、そのような制度の狙いに沿ってアサインされた業務でした。

内容としては、所属チームで進められていた新規サービス開発案件にSREとして参加するというものでした。そこでは主にインフラ開発全般を担当しています。こちらは留学期間終了後も、所属チームにて引き続きリリースに向け開発を続けていく予定です。自分がメインでインフラ開発全般を担う機会はこれまでなかったのでとても良い経験になっています。

SRE留学で何を学ぶことができたのか

たくさんのことを学んだ留学期間でしたが、ここでは特に印象的だったことを3つ挙げたいと思います。

低レイヤーの知識とその重要性

SREの業務では、OS、DB、Networkなどの低レイヤーに関する知識を求められる機会がありました。特に先に述べた影響範囲が大きい障害の障害対応では、そのような知識を求められる瞬間が多々あり、知識の必要性を痛感しました。

そうした経験から留学期間中に低レイヤーに関する学びも少しずつ始めました。 また、学習の一環として使用したprocess-bookについては、「process-book読もう会」という勉強会を主催し、頼りになる先輩方や優秀な後輩たちと共に議論を交えながら読み進めました。 「process-book読もう会」に関しては、ぜひこちらの記事も合わせてご覧ください。

tech.classi.jp

まだまだ知識は足りず、これからも学び続けていく必要を強く感じています。ですが、低レイヤーを学ぶことの必要性を実体験を通して感じることができたことは、良い機会だったと今は考えています。

現状の各サービスの状況やインフラの全体像

SRE留学をする以前は、現状の各サービスの状況やインフラの全体像については把握できていませんでした。

所属チームが担当するサービスやそのインフラに関する知識はある程度持っている一方で、他チームが担当するサービスやそのインフラに関する知識、そして各サービスで共有しているリソースに関する知識はほとんどない、という状態でした。

一方、先に述べた通りSREの業務には他チームからの作業やレビューの依頼対応、技術的な相談対応があります。その中にはチームの枠を超えて、Classiが運用するサービスを俯瞰した上で判断を下すことが求められるものもありました。そのような業務を通して、所属チームが担当するサービスだけでなく、他チームが開発、運用するサービスや、そのインフラなどについても、その概要については多少ながらも把握することができました。

これはSRE留学ならではの学びだったと思います。所属チームに戻った後、他チームとコラボレーションをして進めていく業務が発生した際などにもきっと良い影響がありそうだと考えています。

pre-mortem thinking

SREの業務の中には、失敗が許されないものも多くあります。そのため常に最悪を想定して、切り戻し手順をきちんと確認した上で業務を遂行をすることが求められました。

しかし私はこれまで、どちらかと言えば失敗から学ぶことが重要視される環境で業務を行っていました。そして私自身もそのような環境に甘えてしまい、失敗に備えることをあまり実践してきませんでした。

そのような自分が、SREの業務を担当した途端に、最悪を想定して業務を遂行できるという都合の良いお話はもちろんありません。何度も手痛いミスをしました。その中には復旧作業が大変なものもあり、今でも苦い記憶として心に残っています。

そしてこの経験を個人的に振り返っていた際に、上司に教えていただいたのが pre-mortem*1 thinkingです。pre-mortem thinkingを使った業務の流れは以下のようになります。

  • 業務の遂行に失敗した状況を具体的に想起する
  • 想起した内容から、なぜ失敗したのかに関する根本原因を探る
  • その根本原因に対する防止策を考える
  • 業務を始める

この方法であれば少なくとも想定できる失敗については回避できるようになるので、失敗の可能性を大きく減らすことができます。pre-mortem thinking を教えていただいてからは、なるべくどのような業務でも、まず失敗を想定して、必要であれば切り戻し手順を書き出してから始めるよう意識しています。

もちろん今でも、失敗をすることは悪である、とは考えていないですし、そういう教えをされたことはありません。ただ、どうしても失敗が許されない状況というのは、今後も必ずどこかであると思います。そういう業務を遂行する上で、効果を発揮する思考法を学ぶことができたのは良い経験でした。

SRE留学で何が難しかったか

一方でラーニングゾーンに身を置いてもがき苦しみ、その一方で影響範囲が大きく、失敗すれば各所に迷惑がかかるような重要な業務を担っていく日々に難しさを感じました。SREとして求められる能力とのギャップに自信を失いながらも、前を向いて業務を続けていく必要がある状況に、体力的にも精神的にも疲弊してしまった瞬間が何度かありました。

しかし幸いにも、上司や他のSREと定期的に相談の場を作ることができていたので、そのような場を活用して定期的に気持ちをリフレッシュしながら、なんとか無事留学期間を終えることができました。その点については上司や他のSREに本当に感謝しています。

今後

半年間の留学期間を終えたので、10月からは所属チームに戻り業務をしていきます。

SRE留学の文脈で今後やってみようと考えていることは「SRE留学を経験すると、所属チームの業務がどのように映るのか、そしてどのように貢献できるようになるのか?」という問いに、自分なりの答えを出して運営側にFBすることです。私はSRE留学制度卒業生として、この制度がより良い方向に向かうよう貢献することが求められていると思います。そこにはこの留学制度へのFBも含まれていると考えています。

なので、所属チームでの業務についてまた一から学び直しチームに貢献できるよう努力するとともに、SRE留学制度卒業生としてSRE留学制度の運用や改善になんらかの貢献ができるように頑張っていきたいと思います。

Classi のエンジニア3名が RubyKaigi 2022 に参加しました

はじめに

こんにちは!開発本部所属のエンジニアの id:kiryuanzu です。
9月8日(木) 〜 9月10日(土) にRubyKaigi 2022が開催されました。
今回弊社ではシルバースポンサーとして協賛し、3名のエンジニアがオフラインで RubyKaigi に3日間通して参加しました。本記事では参加メンバーによる感想レポートをお送りします。

参加する前

筆者自身は学生時代に何度かオフライン参加を経験したのですが、同行した2名の新卒エンジニアは今回が初参加となりました。行く前にできるだけ RubyKaigi がどんなものか知っておこうということで、開催1ヶ月前から igaigaさんによるプログラム解説を実施していただき、発表される内容の予習を行いました。
他にも、津の気になる飲食店をみんなで探して事前に予約したり、会ってみたい他社のエンジニアさんや OSS開発者の方について話すといった活動をやりながらイベント当日を心待ちにしていました。

当日の様子

1日目最初の発表から Ruby の WebAssembly でブラウザで動かすといった視覚的にもインパクトが強く今後身近に使われそうな機能の紹介と内部の実装の解説から始まり、自分含めたメンバーみなとても興味津々で聞いていました。発表後に「楽しそう、使ってみたくなった!」と「実装の話難しかったけどわくわくした……!」という感想をみんなで語り合うことができRubyKaigi ならではの会話だなと思いました。

現地にはいなかったメンバーの方も Slack 上での RubyKaigi 談義に花を咲かせており、過去に参加した先輩メンバーから「自分もわからない話が結構ある。だけど、内部実装の話とかめっちゃ面白いので今はわからなくても来年はわかるようになりたいと思えて何を勉強したらいいだろうと考えられる。だから、わからないけれど面白そうな話に出会えただけで価値があるよ」とアドバイスをもらいました。わからないことだらけであっても前向きに学ぼうと考えることができ、参加したメンバーにとって勇気をもらえるメッセージで印象に残りました。

イベント中では様々な他社の人にお会いし交流することができました。その中でも、筆者が個人的に印象に残っている出来事はエス・エム・エスさんの社員の方達と交流したことです。Classi に今在籍されている方で、以前エス・エム・エスさんで働いていた方がいたことがきっかけで会話が弾み、当時の思い出やどんな活躍をされていたかといった話題で盛り上がりました。

他にも、エス・エム・エスさんの社員さんの中には Classi ユーザーの方もいて機能の気になるところについて教えてもらうといったことがあり、想定していないところでユーザーの声を聞けて大変楽しかったです。

社員のみなさんと一緒に写真も撮っていただきました。

また、業務中に技術記事を探している時によく名前が出てくる方や新卒研修に入っていた課題図書を翻訳されている方など、会ったことはなかったけれどお世話になっていた方々 のお顔を拝見することができたのもRubyistが集まるイベントならではといった体験でメンバー一同とても刺激を受けることができました。

ご飯の方面でも大変満足な日々を送ることができました。参加したメンバーの id:kudoa が美味しそうな写真を撮ってくれたので一部公開します。

1日目夜は津駅周辺にある松重というお店に行きすき焼きを食べました。前菜含めて素敵なお味でした。

2日目は Ruby コミュニティでお世話になっている方達と一緒に竹屋牛肉店というお店に行きました。新卒メンバーが肉だけでなくご飯大やガーリックライスも注文していて大変良い食べっぷりだったのが印象に残っています。

他にも、泊まったホテルでは毎朝まむし丼(鰻が使われたご飯料理)、運営の方達が用意してくださったお弁当など毎日美味しいものをいただきました。

運営のみなさん、素敵なお店に連れて行ってくれたRubyコミュニティの方々、そして今回のイベントに行く際「せっかくなのだから美味しいものを食べてほしい」と快く出資してくださった先輩メンバーに改めて感謝の気持ちを伝えたいです。

ここからは新卒エンジニア2人による感想パートです。

id:kudoa さんの参加レポート

2022年4月から新卒エンジニアとして入社しました id:kudoaです。
このような大きいカンファレンスのオフラインでの参加はかなり久しぶりでした。
参加する中で特に印象深かったことについて報告します。

発表

カンファレンスの発表はかなり難しいものも多かったのですが、会社で予習して取り組んでいたおかげでより多く吸収することができました。
魅力的な発表は多くありましたが、そのなかで自分が特に印象に残った発表に触れたいと思います。

他の発表は予習をしていたのですが、この発表だけは「調べないで見た方がいい!」と言われていたので準備しないで臨みました。
内容はすごく読みにくいコードや芸術性の高いコードを紹介するもので、シンプルにプログラミングのアイデアの面白さを感じられる内容でした。
プログラミングに初めて出会った時のような新鮮な気持ちを思い出す発表で、オフラインイベントならではの盛り上がりに興奮しました。

社内でも演者のしおいさんが書いた記事をおすすめされることも多く、一方的にお世話になっている方でした。
Wiresharkというnetwork packet analyzerをmrubyで動かせるようにしたという内容で、個人的に関心のあるCTFで使用されているツールだったので興味のある内容でした。
機能が足りないと思ったら自分で作る!というエンジニアの気概を感じて楽しかったです。
また、観客とのコミュニケーションが活発でコミュニティからの愛を感じる発表でした。

Stringのエンコーディングの速度を改善していくという発表でした。
問題提起からボトルネックを見つけ改善するという、探索的に進めていく過程がまとまっていて、すごく勉強になりました。
ちょうど業務でサービスのパフォーマンスの改善をやっていたこともあり、親近感を感じる発表でした。

そのほかにも魅力的な発表は多くありましたが、中には難しいものも多かったです。
ただ、「なんか面白そう!」「来年は理解できるようになりたい!」というモチベーションが湧くものが多かったです。

RubyKaigiでの発表がすぐに日常の仕事に活かせるかは分かりませんが、純粋に技術を楽しむ気持ちやそれを試したくなる好奇心を感じることができました。

交流

このようなオフラインのイベントでは、休憩時間やお昼休みで実際にコミュニケーションができる時間が多くありました。
Rubyコミュニティの方々は良い意味ですごく砕けていて、楽しく話しやすい方が多かったです。
以前からRubyKaigiに参加されているid:kiryuanzuさんが繋いでくださって、本当に多くの方と交流させていただきました。

人生で初めての名刺交換もできました。

クリアコードの方と名刺交換した筆者

また以前Classiで特別講義をしていただき、RubyKaigiを主催しています松田さんにも直接お礼を言うことができました。

tech.classi.jp

自分と同じぐらいの若手エンジニアから、世界で活躍するようなトップエンジニアまで分け隔てなく交流できるのは、このようなカンファレンスならではだと感じました。

エンジニアとして頑張るモチベーションが上がる充実した時間になりました。

まとめ

このような大きいカンファレンスは初めての参加で不安もありましたが、会社の先輩方やRubyKaigiに参加されていたエンジニアや運営の方々のおかげでとても有意義な時間となりました。
今回の参加で満足せずに、引き続きRubyコミュニティに参加していきたいという気持ちが強くなりました。
貴重な機会を頂きありがとうございました。

すずまささんの参加レポート

こんにちは!新卒1年目のすずまさです。

今回 RubyKaigi 初参加で、こういった技術カンファレンス自体も初めてでした。

また、入社してから Ruby を触り始めたので、Ruby 歴も半年未満と浅く、界隈に知り合いがたくさんいるわけでもないので、行く前は緊張と不安が少しありました。

行ってみた印象

印象を一言で表すと「面白くて質の高い大学講義 兼 大規模オフ会」でした。 参加する前に抱いていた不安は杞憂で、実際始まってみると私のような Ruby 初心者でも共感できたり、勉強になる発表が多かったです。

また、何度も参加されている id:kiryuanzu 先輩が引率してくださったおかげでたくさんの方と交流できました。 みなさん初対面でも優しく朗らかで、普段の仕事の話や趣味の話もできてとても楽しかったです。

弁当待ちで並んでいる Matz さんと津餃子の話をしたりもしました(笑) まさかこんなに気軽に話せるとは思っていなかったので面白かったです!とても気さくで優しい方でした!

印象に残った発表はたくさんありますが、特に記憶に残ったものを 3 つ紹介しようと思います。

Ruby meets WebAssembly
1 日目の一番最初に見たのがこの発表でした。
WebAssembly を使って Ruby をブラウザ上で動かすという話で、実演が多くすごさがわかりやすかったので、私も含めて会場全体が盛り上がっていました。
後半の実装の話は正直難しくてあまり理解できませんでしたが、「よくわからないけどすごい…!!」という感動が味わえて、この後の発表へのわくわく感が溢れてきました。

Create my own search engine.
ポケモンカードの検索エンジンを作った話をされていました。
技術的にも勿論おもしろいのですが、趣味が前面に出ておりとても楽しそうに話をされていたのが印象に残っています。
趣味で開発して未完成のままやめてしまったプロジェクトがあるので、この発表に感化されて久しぶりにまた再開したくなりました。

The Better RuboCop World to enjoy Ruby
RuboCop で遭遇しがちな問題点を整理し、それに対してこうすればもっと良くなるんじゃないかという話をされていました。
初心者にありがちな悲劇として「RuboCop に怒られたので通るようにメソッドを分けました!」という例が挙げられていたのですが、まさに自分が最近通った道だったので耳が痛かったです。
私のような Ruby 初心者から熟練者まで共感できるポイントのある、とても良い発表でした。

感想

私がプログラミングを始めてからの大半の時間はコロナ禍でオンラインになっていたので、こういったオフラインのイベントはとても新鮮で楽しかったです。

初めてで経験も乏しい中ここまでちゃんと楽しめたのは間違いなく先輩たちのお陰なので、本当に感謝の気持ちでいっぱいです。

交流する人たちもすごい人ばかりだったので非常に刺激を受けました。 発表に関しては理解が追いつかないことがかなり多かったので、次回までにもっと強くなって完全に理解できるようになりたいです!

終わりに

以上が新卒2人の感想パートとなります。2人とも最初は、オフラインのカンファレンス参加の経験が少なく不安な面もあったようでしたが結果的にすごく楽しんでいただけたようで何よりです。
今回の RubyKaigi では筆者含めて参加メンバーみな刺激を受けたイベントになりました。この経験を経て、次に勉強したいことや挑戦してみたいことなど、新たな目標がたくさん生まれたように思います。
次回に向けて、RubyKaigi の良さを周知する活動を続けることで一緒に参加するメンバーを増やせたらと考えています。
それでは、来年の松本でまたお会いしましょう!読んでいただきありがとうございました。

最後に、Classi では一緒に働いてくれるメンバーを絶賛募集中です!Ruby を書くのが好きな方、教育サービスに携ることに興味がある方など、ぜひご連絡いただけると幸いです。

hrmos.co

hrmos.co

フルリモート環境である開発本部の課題を解決するために始めてみたこと

こんにちは。技術戦略室にてエンジニアをしています、中島です。

以前、リモートワーク環境におけるコミュニケーション課題の一つである「質問」についてブログを書かせていたただきました。 tech.classi.jp

弊社では今でも全社的にフルリモートを続けていますが、やはり人と人との接触機会は以前より減っています。そのため、計画的偶発性も少なくなっているのではないか、と考えています。

※ 計画的偶発性とは?

個人のキャリアの8割は予想しない偶発的なことによって決定される。その偶然を計画的に設計し、自分のキャリアを良いものにしていこうという考え方。 計画的偶発性理論 - Wikipedia

今回は、こういった状況を改善するために始めてみた施策について紹介します。

開発本部の課題と仮説

施策の内容へ入る前に、今私が所属している開発本部の抱えている課題と、それに対する仮説をお伝えします。

「Classi」というサービスはユーザー様から見ると1つのサービスですが、その中には先生・生徒・保護者様向けに様々なサービスが存在します。 classi.jp

開発チームはそれぞれのサービス毎に存在していますが、サービス内の機能は他のサービスとも複雑に依存しあっています。そのため、ちょっとした修正、お問い合わせの調査、システムアラート対応などをするだけでも他のチームとのコミュニケーションが必要になります。

しかし、チームを越えてコミュニケーションを取ることが少し難しいという現状が明らかになってきました。 なぜ難しいのでしょうか? リモートワーク以前であれば、コミュニケーションを取るために少し社内を歩き回るだけで、お互いに気軽に話しかけやすいという側面がありました。

ですが、リモートワークでは、まずはSlackでの文字でのやりとり、話すためにはMTGの設定をしなければいけなくなりました。リモートワーク以前に入社している人からすれば、相手を見知っているので気軽さはさほど変わらないのかもしれませんが、リモートワーク以降に入社した人もたくさんいます。

チームを越えた仕事が発生した時に初めて、全く知らない人とコミュニケーションを取るのと、少しでも人となりを知っている人とコミュニケーションを取るのでは、違いがあるのではないでしょうか?

その仮説を基に、チーム外の人とのコミュニケーションを促進できるような施策=雑談をしていこう!となりました。

本当に?

コミュニケーションを取れば、雑談をすれば、本当に課題が全て解決するのでしょうか? そもそも、こういった制度はあまり受け入れられないことも重々承知しています。 なので開発本部の制度として建て付ける際に、それでも意義があると自分自身納得する必要がありました。そんな中、弊社VPoTであるしんぺいさんの記事を読みました。

nekogata.hatenablog.com

私には考えもつかない視点で書かれていてとても好きです。上記の文章とともに、弊社のesaの中ではさらに社内の課題を交えた議論がたくさんの人とされていました。

その中で自分が腑に落ちたことは、雑談してもコミュニケーションがうまくいかないことはあるしプロトコルが合わない人もいる。それをもっと早い段階で(仕事で関係性を持つ前に)認識しておく(器官を育てておく)ことが大事なのではないか。そうすれば本番ではもう少し上手くやれるのではないか?ということです。(上手くとは、無闇に衝突しないなど)

そういった事前の場としても機能するのであればやる意義はあるのかな、と思ったのでした。

新しく始めた制度について

新たに「Zatsu談制度」を始めました。名前にあまり深い意味はありません。

この制度の目的は、開発本部内で横の繋がりを作り、チーム外で気軽に話せる人(場)を作ることです。 開発本部内での、弱い関係斜めの関係を作ることを主目的としています。

弱い関係、斜めの関係ってなんぞや?と思った方は是非上記のリンクを御覧ください。

例えば、同じチーム(強い関係)にしか所属していないと、そのチームにだけ注目してしまい、他のチームから孤立してしまう可能性があります。 考え方・施策・行動など、そのチーム内で個別最適が進むと、いわゆる”サイロ化”が発生します。

「開発本部の課題」にも書いた通り、Classiはサービス(プロダクト)の依存関係が複雑に絡み合った状態で開発されてしまっているため、必然的に外のチームとコラボレーションしながら課題解決に取り組む必要があります。サイロ化した状態ではコラボレーションが進みません。情報伝播や相互理解を促進するためには、弱い関係も必要です。

ちなみに「弱い関係」についてはデメリットもあるそうです。気になる方は「組織デザイン」をご一読ください。

また、斜めの関係性を構築することで、チーム外の関係だからこそ相談できたり、異なる視点を得られたり、新たに別の関係性が生まれたりするのではないでしょうか。

そんな想いでこの制度が立ち上がりました。

Zatsu談制度の運用方法

制度をどのように運用しているかを紹介します。

  • Zatsu談制度は、基本は 1on1 形式で行います
    • 縛っているわけではないので、他のペアと開催するのでもOKとしています
  • ペアの選定仕様は以下となっています
    • 誰かの意図・思惑は入れず、ランダムとする
    • チーム外の人とペアにする
    • 過去にペアになった人と違う人をペアにする
  • ペア選定作業はGoogle Apps Script (GAS) で実現しています
  • 制度の1実施期間を、3ヶ月に固定しています
  • 期間が終了すると、ペアを再選定します
  • 一度のZatsu談期間が終わったら、開発本部メンバー全員にアンケート形式でフィードバックをもらいます
  • 相談窓口として、Google Formsを用意しています
  • 参加が難しいという方もいると思うので、強制はしていません

Zatsu談で何話そう?

突然、雑談してね!と言われても困りませんか?なので色々なZatsu談ネタをesaにまとめて共有しています。

例えば弊社ではチームごとに偏愛マップやモチベーショングラフを作っていたりするので、そのリンクを集めたり、16personalitiesStrength finderの結果を共有したりしています。

conversation topic
雑談ネタの紹介

また、Slackには色々な趣味チャンネルもあるので、そこから話題を広げることもできそうです。

 Recommended Slack channels
おすすめSlackチャンネル

esaには、自己紹介ページを作っている方も多数います。日報を書く方もいて、ペアの日報を読んでいるという方もいました。自分を知ってもらうためには一定の自己開示も大切ですね。

1回目の実施が終わってみて

7月末に1回目のZatsu談期間が終了しました。そのタイミングでアンケートを取ってみたので、一部の内容を紹介します。

Zatsu談回数

  • 複数回実施してくださった方が半数以上を占めました
  • 1回で終わってしまい続かない方が多いのではないかという予想でしたが、定期的な開催が多く見られました

満足度・目的達成度

1: 不満足 5:満足

1: 達成されてない 5:達成されている

  • まだ制度を始めたばかりなので、もっと左に寄るかなと思いきや、満足度・目的達成共に右に寄っていました。一定の評価をいただけてホッとしました

Zatsu談制度があってよかったこと

制度があってよかったことをたくさんいただいたので、一部を紹介します。

- 直接役立ったり効果があるかはわからないが、Zatsu談ペアになった相手とはちょっと気安い雰囲気は生まれると思う
- ペアになった人をハブに、今まで関わったことのない全く知らない人と話す機会を得られました
- 知らない部門の人や業務で関わりがない人と話せるのは良い
- 会社の歴史のシェアや暗黙知のシェアにもなる
- 業務に関係ないプライベートの雑談ができるのが楽しかった!
- 普通に人生の先輩として話すだけでも学びがあった!
- 合同Zatsu談しているところもあって良いと思った!
- 別の領域の人と接点を持てて、その人が別の会で発言されてるのを見ても「Zatsu談で話した人だ!」と顔が浮かんだり、雑談で話したことと紐づいたりして理解が深まった
- 普段絡みの無い人と話をすることができた
- たまに雑談する間柄だったけど、改めて機会ができてよかったと思う。
- 仕事以外のことを気軽に話せて楽しかった。今後、何かあったときに話しかけるハードルは下がりそう。
- 業務であまり話さない人と話すきっかけが強制的にできるのでよかった。
- 通常業務では関われなかった関係ができた。新卒とペアになったので、他の新卒や研修にも興味を持つようになった。
- 普段話さない内容であったりちょっとした相談を気軽にすることができた。
- 恐らく殆ど接点がなかった&これからも少ないであろう方とお話できたのが嬉しかったです。
- 話すきっかけはできました

この他にも「やってみたら楽しかった!」「Zatsu談制度以外のところでもZatsu談してみた!」「チーム内のコミュニケーションも見直してみた」などの嬉しい声を聞くことができました。

しばらくこの制度を続けてみて、いずれまた状況をこちらで報告したいと思います。

他にやろうとしていること

Classiはサービスもシステムも複雑と何度か書いていますが、その影響もあり中途入社した方は入社当初のキャッチアップに苦労している面も見られます。

中途入社者が組織に適応するまでには一定の期間が必要だと言われています。(組織再社会化) 技術戦略室ではこの点をサポートするべく、中途入社者を受け入れるチームと協力して開発本部のオンボーディングを見直す動きも始めています。

まだまだやりたいこと・やれることはたくさんあるので、引き続きみんながごきげんにミッションを達成できるよう、開発本部の課題を解決していきたいと思っています。

RubyとRailsのコミッターである松田明さんの講演でプログラミングを楽しむモチベーションが上がりました

2022年4月から新卒エンジニアとして入社しましたid:kudoa です。

先日社内でRubyとRailsのコミッターである松田明さんによる特別講義が開催されました。
開催の経緯や感想、当日出た質問を紹介します。

開催の経緯

2022年の新卒研修では、研修内容に関連した話題について自身で調べた内容を発表する機会がありました。
その発表の内容に、OSSのコードを読んだ発表など、それぞれの興味があることを深く掘り下げるものが多くありました。
発表が終わった後、その発表が良かったという話が上がり、OSS活動を積極的に行っている松田明さんをお呼びして講演していただくことになりました。

新卒研修に興味がある方は以下の記事もご覧ください。 tech.classi.jp tech.classi.jp

特別講義のテーマ

特別講義のテーマは、これから職業エンジニアとして人生を進める私たち新卒に向けて、楽しくプログラミングを続けていくためのヒントとなるものでした。

松田さんは20年以上職業プログラマーをされており、OSS活動やコミュニティ運営などもされています。そこで得られた経験や実感についての発表でした。

このような世界で活躍するエンジニアの方から直接話を聞ける機会はすごく貴重なので、楽しみにしていました。

印象に残った話

この講演の中では沢山の興味深い話がありました。 その中でも私個人が特に印象深かった話を紹介します。

プログラミングの最大の楽しみは「コミュニティ」

仕事で楽しめるプログラミングはプログラミングのごく一部でしかなく、最大の楽しみは「コミュニティ」であると話されていました。

松田さんは実際に、Asakusa.rbやRubyKaigiの主催など多くのコミュニティ運営に関わっていたり、世界中のカンファレンスで登壇を行っています。

その中で他のエンジニアとの関わりや新しい発見や経験を得ることができ、その活動がとても充実しているという話でした。

松田さんがコミュニティを大切にしている話は、自分にとって嬉しかったです。
自分もエンジニアコミュニティが好きでこの業界を選んだのですが、技術的に最前線を走るエンジニアの方も同じことを考えていることに親近感を覚えました。

また世界中のカンファレンスでの思い出や、そこでのエンジニアのコミュニティの面白さが語られました。
カジュアルな雰囲気で美味しいご飯やビールを楽しみながら技術の話ができるのは、すごく楽しそうで新鮮でした。

このようなイベントを通じて国内だけでなく世界中に友人ができることが、とても魅力的だと感じました。

OSS活動は義務ではなくて権利

OSS活動は「エンジニアがしなければならないもの」というものではなく、「誰でも参加することができる権利が与えられているもの」なので好きなところからつまみ食いしながら楽しんで欲しいという話がありました。

コード一つで世界中の人と関われるというのは、他にはないエンジニアの特権です。
松田さんも実際にOSSの活動を通じてエンジニアのコミュニティと関わったり、世界の有名なエンジニアと一緒に仕事をしたりしているという話もありました。

業務の中だとその会社のエンジニアとしか関わることができませんが、OSS活動であれば世界中の素晴らしいエンジニアと一緒に開発ができます。
そういった活動での経験がコミュニティの関わりに繋がったり、業務にも良い影響があるのだと感じました。

確かに今まで私は、OSS活動というと貢献しないといけないというイメージが強く、技術的に未熟な状態で貢献できることがあるのかと躊躇していました。

この話を聞いた後、自分にもできるとこから気軽にやっても良いと感じるようになり、敷居が下がりました。
今ではドキュメントの修正のPRを出したりするなど簡単な事から始めるようになったので、考え方が変わるきっかけになったと思います。

実際の自分が出したドキュメントの修正のPR

当日の質問

講義では話されなかった当日出た質問について一部紹介します。

Q. Ruby/Railsにずっと時間を投資できた理由を知りたいです。他の技術に目移りしなかったのですか。

Rubyの次に来る言語とかはひとりのプログラマーとしては気になりますが、自分はRubyやRailsのことが大好きで両足突っ込んでしまっているので、今更他の言語を主戦場にする気にはならないです。
むしろ「RubyやRailsの市場は俺が耕した」と思っているし、それで自分がRubyをやめてしまったら無責任だとも思うので、これからももっとみんなにRubyやRailsを使ってもらうように働きかけていく活動は続けていくと思います。

OSSへの人生最初のパッチはどうやりましたか。良いアプローチの仕方を教えて欲しいです。

僕の場合はあんまり参考にならないかもです。昔はもっと世の中は雑だったし、Railsとかも普通に使っているのに普通にバグっているという状態でした。
仕事で使うにしてもパッチを当てながらでないと使えなかったです。
なので敷居が高くなかったし、自分が困っているからやっていた感じでした。
今は整ってきてしまっているので、そこから問題を探すのは当時より難しそうではあります。
それでも、世の中のOSSからバグが無くなることは絶対にないので、まだまだ解決するべき問題は無限にあるはずです。

[予告] 9月のRubyKaigiに現地で参加します

Classiは2022年のRubyKaigiのスポンサーをしています。スポンサーチケットを頂いたので、新卒を含めたエンジニアと現地に行きます。

今回の松田さんの講演の中で、カンファレンスをより楽しむためには予習をすることが大事だという話がありました。

今私たちはRubyKaigiをより楽しむために、技術顧問のigaigaさんと毎週RubyKaigiのスピーカーセッションの内容などの予習会を行っています。

参加した後に現地のレポートも報告するので楽しみにしていてください。

© 2020 Classi Corp.