Classi開発者ブログ

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

「技育祭2022秋」で登壇しました！〜年１登壇のススメ〜

勉強会・イベント

この記事はClassi developers Advent Calendar 2022の5日目の記事です。

こんにちは！9月入社でプロダクト開発部でエンジニアをしています @kaori_choです！ 今回、技育祭2022秋という学生向けテックカンファレンスで、パネリストとして登壇してきたのでその舞台裏についてお話します。 私としては人生初レベルの大きな舞台で、緊張もしたのですが大変貴重な経験となったので、これから「登壇」にチャレンジする方の参考になれば幸いです。

「技育祭2022秋」とセッション概要

技育祭は「技術者を育てる」ことを目的とした国内最大級の学生向けテックカンファレンスです。教育や育成といった事業に関わるエンジニアとしても、毎年陰ながら応援しておりました。年々参加者は増え、今年の参加者数はなんと3000人規模！ そのうち3日目の2022/10/17のセッションにて、パネルディスカッション形式で、女性エンジニアならではの強みや課題、キャリア戦略についてお話しさせていただき、200名ほどの学生さんにご視聴いただきました。

talent.supporterz.jp

登壇のきっかけ

登壇のきっかけは、主催者の楓さんとの前職からのご縁でした。私は女性エンジニアとして2011年から育休産休を経て今まで働いてきた経験があるため、今回の「女性エンジニアのキャリア」をテーマにしたパネルディスカッションを実施するにあたり、ママエンジニア代表（！）としてお声がけいただきました。

ただ技育祭は前述の通り「国内最大級」のテックカンファレンスで、今回も過去最高に豪華なゲストの方が登壇されるのを知っていたため、登壇が決まった際には社内のtimesチャンネルでテンパり散らかしました。

ひどく混乱した様子

事前準備：社内で素振りをお願いする

「これは一人では無理だ事故る」と判断した私は、社内で素振りをお願いすることに。 すると、すぐに5名以上の女性エンジニア・人事の方が挙手スタンプを押してリアクションをしてくれました（嬉泣）

みんなやさしいし嬉しすぎる😭しかもレスが早い

いざ、当日！

この日は日曜日だったため、子ども達を両親に預け、家からオンライン登壇の準備をしていざ挑みました。オンライン登壇だったので、時間の間違いだけが怖くて、1時間くらい前から家の中でソワソワと歩き回っていました。

セッション開始後は、テーマに沿ってパネリストの方とざっくばらんにお話しをしながら、 チャット等でもリアルタイムでリアクションがもらえて、とても嬉しかったです！

また、今回の登壇で「会社のお知らせに掲載される」の実績も解除しました🎉

今回パネリストとして登壇した感想

社名を背負って登壇するからには、学生さんからの認知もしっかりもらって帰るぞ〜！という魂胆も実はあったのですが（笑）、終わってみれば何より「私が一番楽しかったな〜！」というのが一番の感想です。 今回のウェビナー形式だと、参加者の方の表情は見ることができないのですが、チャットのリアクションで「女子学生エンジニア」の方がたくさん参加していることを感じられたのも、とても嬉しかったです。

そして、副次的に嬉しかったのは、今回の登壇がきっかけで"チーム外"のエンジニアの方々とより親しくなれたことです！

そういえば、コロナ禍になってからは、他チームの女性(エンジニア)とばったりトイレであって、「最近どう〜」みたいなお話をする機会がなくなってしまいました。 素振りのオンライン会議で、意図せず「チーム外の人とのコラボ」する機会を作れたのはとても良い体験でした。

私が「年に1度は登壇」にチャレンジしている理由

本記事はアドベントカレンダーのエントリーなので、少し年末っぽいお話もさせてください。 12月ですのでみなさん今年を振り返ったり、来年の目標を立てたりしているでしょうか？

実は、私が登壇をおこなっている理由は2つあります。

  • 女性エンジニアの存在をアピールしたいから
  • 登壇者が一番勉強になる（得るものが多い）と知っているから

1つめの理由は今回の登壇テーマそのままでもありますが、女性エンジニアはまだまだ少ないので、もっと増えてほしいという思いから機会があれば手を挙げ飛び込むようにしています。私自身も女性が少ない中で、先輩の女性エンジニアの存在に励まされてきたので、IT業界のジェンダーギャップ解消に向けて少しでも力になれればと考えています。いずれは、私が表に出なくてもよいようになってほしいのですが（笑）まずは女性比率が3割越えるまでは、挑戦を続けてみようと考えています。

2つ目の理由は、実は登壇者の話を聞いている人ではなく「喋ってる人が一番勉強になっている」のですよね。これは登壇や発表をしたことがある方々は、きっと画面の前でうなずいてくださっているはず。学んだことを人に喋ることは、自分の中での理解も深めます。資料を準備しながら、実はよくわかっていない部分が見えてくることも多いです。すでにわかっていることでも、質問をもらうことで違う見方に気づけます。

今回の私の登壇は、パネルディスカッションなのでただ楽しかっただけですが…（苦笑）そういう「楽しかった、面白かった、うまく話せず悔しかった」という感情すらも、登壇をしなければ得られなかったものです。

年1登壇おすすめですよ！

10年ほど前の私が新卒当時は「年に1つ言語を学びましょう」とか言われたものですが、今もそうなんでしょうか？

年1言語習得も素敵ですが、私からは「年1登壇」をおすすめします！

まずは小さく試してみましょう。

  • 社内のエンジニアを数人集めたライトニングトークで喋ってみる
  • 社外のイベントで登壇者に「質問」してみる
  • 社外のイベントに「登壇者」で申し込みをしてみる

こんな感じで私自身も、小さく小さく積み重ねて挑戦してきました。コツは「まずはポチる」こと。ネタは申し込んでから考えましょう！大丈夫です！ このアドベントカレンダーもそうですが、アウトプットすることを先に決めることで、インプットの質も量も変わってきます。 そして、この記事を最後まで読んでくださる勤勉な皆さんなら「意外とやったらできた」という経験にきっとなるはずです。 次はみなさんのお話しが聞きたいです。もし、この記事をきっかけに、今度登壇することにしました〜！という方がいらっしゃったら、ぜひ @kaori_cho にも教えてください！

最後までお読みいただきありがとうございます。

明日アドベントカレンダーは id:kiryuanzu さんの「Classiセキュリティ強化への道・後編～Hardening本戦へいざ出陣編～」です！楽しみですね♪

GitHub運用委員の紹介

運用 開発組織

みなさま、おはこんハロチャオ〜。開発支援部所属のid:aerealです。

この記事ではClassiにおけるGitHub運用委員という役割とその仕事について紹介します。

また、この記事はClassi developers Advent Calendar 2022 - Adventarの2日目の記事としてお届けします。

GitHub運用委員とは

Classiでは開発のコラボレーションツールとしてGitHubを活用しています。

Webサービスで事業を提供する企業にとって最も重要なソフトウェア資産といえるソースコードをホストするサービスですから不適切に扱えば重大な損害を被ることになりますし、最近はGitHub ActionsというCIサービスも利用できますから一歩間違えれば本番環境で稼働動しているサービスに大きな影響を与えかねません。

当社には情シスやサイバーセキュリティ推進部といった部署が存在し、基本的なセキュリティガードレールの設置や情報システムの管理はそれら部署が責任をもって行ってくれています。

しかしながら上記の通りGitHubは誤用・濫用してしまった場合の影響が大きく、また機能も多岐に渡るため、サービスと我々の業務フローを深く理解した上でより進んだサポートが必要と考えられます。

そういった背景からGitHub運用委員は生まれました。

GitHub運用委員はClassiのメンバーがGitHubを利用する上で望ましいデフォルトを提供したり、安全かつ快適に利用できるようサポートしたり、といったことをミッションに掲げています。

アカウント管理や基本的なセキュリティ施策 (SSOなど) は情シスやサイバーセキュリティ推進部と連携しお願いしつつ、よりサービスに寄り添った運用業務をしています。

活動内容

実際に我々が行っている活動をピックアップして紹介したいと思います。

各種クレジットの残高管理

ClassiではEnterprise Cloudというプランに加入しています。詳しい説明は省きますが、GitHubがホストするサービス形態の中で最も機能が充実しているプランと認識いただければ間違いはありません。

このプランにはGitHub Actionsなど従量課金制のサービスに対するクレジットが一定額含まれており、このクレジット以内であれば追加のコストを支払う必要はありません。

言い換えればこのクレジットを使い切ると追加のコストを支払わなければなりません。

特にGitHub ActionsやPackagesなどサービスのデプロイに不可欠なサービスも該当するので使えなくなった場合の影響はとても大きいです。

従来GitHubのWeb上で毎月各種クレジットの残高を確認していたのですが、単純作業な割にそれなりに重要で忘れてはいけないためなんとかしたい業務のひとつとなっていました。

GitHub運用委員はこの作業を引き受け、自動化および可視化することに成功しました。

Classiは既にBIツールとしてRedashを、データウェアハウスとしてBigQueryを活用しています。可視化と監視にRedashを、データの蓄積場所としてBigQueryを選び、APIから取得したデータをBigQueryに定期的に挿入する作戦をとっています。

たとえばGitHub ActionsのクレジットはGET /orgs/{org}/settings/billing/actionsというREST APIで取得することができます。

以下のような設定ファイルを書くとレスポンス結果をBigQueryのカラム定義にマッピングし、毎日自動でテーブルに挿入するツールを開発・運用しています。

{
  "action_billings": {
    "name": "action_billings",
    "timePartitioning": {
      "type": "DAY",
      "field": "calculatedOn"
    },
    "schema": [ // (1)
      {
        "name": "total_minutes_used",
        "required": true,
        "type": "INT64"
      },
      {
        "name": "total_paid_minutes_used",
        "required": true,
        "type": "FLOAT64"
      },
      {
        "name": "included_minutes",
        "required": true,
        "type": "INT64"
      },
      {
        "name": "minutes_used_breakdown",
        "required": true,
        "type": "RECORD",
        "schema": [
          {
            "name": "UBUNTU",
            "required": true,
            "type": "INT64"
          },
          // snip
          {
            "name": "total",
            "required": true,
            "type": "INT64"
          }
        ]
      },
      {
        "name": "calculatedOn",
        "required": true,
        "type": "DATETIME"
      }
    ],
    "source": { // (2)
      "kind": "rest", // (3)
      "config": { // (4)
        "method": "GET",
        "resource": "orgs/classi/settings/billing/actions"
      }
    }
  }
}
  • (1) … schema 以下でカラム定義を書きます
    • BigQuery APIのTableSchemaに相当するプロパティが使えます
  • (2) … source でデータの取得先を書きます
  • (3) … kind でREST APIを示します。他にあらかじめ取得しておいたJSONファイルを指定する file も対応しています
  • (4) … config でアクセスするREST APIのメソッドとリソース名 (パス) を書きます

このようにしておくことで似たようなコードを繰り返し書かずとも、設定ファイルを追記するだけで取得するデータを増やせます。

実際にPackagesの使用量も新たに監視することにしたのですが、設定ファイルの変更のみで簡単に追加できました。

さらに必要であればビューも定義します。 たとえば以下はGitHub Actionsの使用量を計算するビュークエリです。

SELECT
  total_minutes_used - LEAD(total_minutes_used) OVER (ORDER BY calculatedOn DESC) AS used_minutes_in_a_day,
  included_minutes - total_minutes_used AS remaining_minutes,
  calculatedOn
FROM
  `{{ .DatasetID }}.action_billings`
ORDER BY
  calculatedOn DESC

LEAD() 関数を使うことで前日と比較した値を計算できるのでこれを使ってその日に使った量を取得できます。

実際に利用料を観察しようと思うと月毎では粗すぎるため、日毎の利用料を可視化することである日を境に傾向が変わったことを認識できます。

最後にBigQueryをデータソースとして設定したRedashのグラフを作ります。

実際にプロットした様子が以下のグラフです。

github-actions-usage

月末にかけてきれいに減って月初で戻っている様子が伺えますね。

またこのグラフからわかるように9月はクレジットをぎりぎり使い切りそうでした。これも月末にいきなり気付くのではなく月の途中で発見し、変わった利用が起きたのかヒアリングしています。

ポリシーの制定と広報

GitHub運用委員はGitHubの社内エキスパートとして望ましいデフォルトを用意したり広めることもまた重要な責務となっています。

たとえばPersonal Access Token (以下、PAT) を使うとGitHubのAPIにアクセスでき、個人やチームの生産性向上に役立てることができます。

一方、粗い粒度でしか権限を与えられないため過剰な権限を持ちがちで漏洩した際のリスクも大きくなりがちです。

また個人に紐付く認可情報なので異動や退職などのイベントで引き継ぎ漏れが起きやすいです。

GitHub運用委員としてはPATのアクセス許可がリソースベースポリシーではなくアイデンティティベースポリシーになっていることも大きな懸念です。

ざっくりいえばアクセスされる対象 (APIエンドポイント、リポジトリなど) ごとにアクセスできるPATを一覧することができないので、知らぬ間に強い権限を持っているPATが増えているということが起きがちです。

つまりGitHub運用委員としてはPATはできるだけ使わないでほしい・どうしてもPATでなければいけないケースでのみやむなく使ってほしいものとして扱いたいです。

組織の開発者にとってもいらぬリスクを背負わず効率化にいそしんでもらうため、上記のような問題点と回避策をまとめてポリシーを定め広報しています。

たとえば以下のような内容をPATに関するポリシーとして定めています。

ちょっと待って！それ、本当にPATが必要ですか？

GitHub Actionsで実行されるワークフロー環境には、使い捨ての GITHUB_TOKEN が発行されます。 このトークンはそのワークフローを実行するレポジトリに閉じた権限が与えられます。

複数のレポジトリを横断しない限り、GitHub APIの呼び出しはActions備え付けの GITHUB_TOKEN で十分です。

Classiの設定では、GitHub Actionsに与えられるデフォルトの権限は contents:read だけです。 必要な権限は各ワークフローのYAMLファイルの中で明示的に permissions を記述してください。

参考資料

余談: PATとAudit Logの改善

上記でPAT自体やそれにまつわる運用上の懸念について述べましたが、GitHubのリリースによって改善されている点も多くあります。

たとえばFine-grained PATのリリースはとても大きな変更です。

参考: Introducing fine-grained personal access tokens | GitHub Changelog

GitHub Appsなどと同等のきめ細やかな単位で権限を設定できるのでまさに待望の機能といえます。

余談ですがfine-grained PATsのリリースにより従来のPATはclassic PATsと呼ばれるようになります。

しかしfine-grained PATsが銀の弾丸かといえば現時点ではそうはいえません。

GitHub Packagesなどへのアクセスはこの記事執筆時点で許可できないので引き続きclassic PATsを使う必要があります。 完全に置き換えるにはまだGitHubのリリースを待たなければいけない状況です。

また運用面ではAudit Logの改善が目覚ましい点にも言及しなければなりません。

Audit Logといういわゆる監査ログ機能がGitHubにもあるのですが、最近の変更で使われてトークンの情報がログに含まれるようになりました。

つまりあるAPIアクセスに使われたトークンの所有者が誰で、GitHub Appsなのかclassic PATsなのかfine-grained PATsなのかを把握できるようになりました。

参考: Display Authentication Token Data in your Enterprise Audit Log - Beta | GitHub Changelog

classic PATsをやむなく使うシーンがしばらく続くことを考えるとこの機能はとてもありがたいです。

このようにGitHub運用委員はポリシーを定める傍ら、新機能のリリースもしっかり追ってより現状に即したポリシーへのアップデートや利用の促進も行っています。

まとめ

ClassiにおけるGitHub運用委員の取り組みについて紹介しました。

筆者はClassiではじめてこういったGitHubの運用に深く関わるようになったのですが、とても強い権限が与えられるので今まで見たことのない画面が見えるようになってワクワクする反面、力の大きさに震えそうになることもあります。

しかしGitHubはソフトウェアを開発する上でとても大きな存在になっていますから、この運用をより安全・快適にすることでClassiの開発者全体に貢献できます。 そのテコで生まれる力の大きさはやはり楽しいです。

またこの記事で紹介したGitHubのAPIから取得したデータをBigQueryに取り込むツールは他にも様々なユースケースに沿えるような工夫をしているので、また改めて紹介したいですし、ゆくゆくはオープンなものにしたいという野望も抱いています。

以上、ClassiのGitHub運用委員の取り組みについての紹介でした。

明日12/3は id:tkdn よりお届けする予定です。

開発本部でレポートラインを整理してユニット制度を導入した話

開発組織

この記事はClassi developers Advent Calendar 2022の1日目の記事です。

こんにちは！開発本部で本部長をしているid:tetsuro-itoです！今年もこの季節がやってきましたね。僭越ながら昨年に引き続きトップバッターを努めます。

昨年の記事では、本部長に就任したあとで取り組んだ最初の内容をお伝えいたしました。今年もその路線を踏襲して、今年取り組んだ施策の内容や現時点での結果などをお伝えいたします。最後までお付き合いいただけると嬉しいです。

開発本部の抱えていた課題

開発本部はプロダクト開発部、開発支援部、データAI部の3つの部署によって形成されていますが、全体の7割ほどのメンバーがプロダクト開発部に所属し、残りを他の2つの部署のメンバーが構成するという歪な偏りがありました。加えて、当時のプロダクト開発部の部長が大半のエンジニアのレポートラインの上長として位置付けられており、部長1人が評価する人数が多く、大変でした。 さらに、上長の管掌範囲が広く、日々の仕事を評価しにくいために、所属しているチームのPdMがそれぞれのエンジニアの働きぶりの申し送りを行っていました。日々の働きぶりの観点の申し送りでは問題がありませんが、別の職能を持ったメンバーが申し送りを行うため、評価の観点では必ずしも機能していたとは言い難い状態になっていました。

また、Classiでは組織のパルスサーベイ1として、Wevoxというツールを導入しており、定期的に組織の状態を定量的にモニタリングし、施策を打っていく取り組みを行っています。そのパルスサーベイのスコアもあまり良い状態ではありませんでした。開発本部は月に一度、本部メンバー全員が集まって情報共有を行う「開発本部全体会」を行っています。そこで全員でWevoxのスコアを見て、何を改善していけばよいかのワークを行ったりもしました。

その結果、多くのメンバーが指摘したのが、「自己成長」という項目のスコアが低いということでした。これはエンジニアリング領域における能力開発、キャリア開発などを責務としている開発本部では、由々しき問題であると考え、すぐに対応策を検討しました。

まずはじめに取り組んだこと

まず一番はじめに取り組んだことは、現状の組織構造のas-isをきちんと把握するために可視化です。すると、前述した組織上の課題が非常に複雑な形となって姿を現しました。

当時のレポートラインの状況を可視化したmiroの図

上記のように、レポートラインが偏った構成になっていたり、入れ子の構造となっていたりと複雑な様子が明らかになりました。そこで、まずは組織の構造に階層を取り入れて、その役割を付与することにしました。

階層を取り入れたレポートラインの全体像

まず、本部長および部長、副部長をエンジニアリングマネージャーとして括りました。また、この集合をEM Boardと称して、開発本部における問題解決や組織運営に責務を持つような役割を定義しました。

また、部長とメンバーの間にユニットリーダーという役割を新たに定義し、それぞれのユニットを束ねてもらう役割を作りました。エンジニアのユニットという概念も定義し、下記のような定義を行いました。

  • 1ユニットあたりの最大の人数は5人まで
  • ユニット内の役割はユニットリーダーとユニットメンバーのみ
  • ユニットリーダーは評価時に申し送りを行う
  • ユニットリーダーは評価者ではない
  • ユニットのメンバーとプロジェクトのメンバーが一致しないこともある

ユニットの説明図

このような構造を取り入れ、開発本部メンバーのレポートラインを整理した結果が下記です。

整理後のレポートライン

このようにこれまでの偏った構造を是正し、ある程度適正なマネジメントサイズを意識してレポートラインを再構築しました。また、レポートラインにエンジニア以外の職能のメンバーが入ることをやめました。これにより、評価の納得性や不透明性も改善しようと試みました。

新設したユニットリーダーへのお願いや対応

これまでリーダーではなかったメンバーが突然リーダーに任命されても、すぐにはうまく立ち振る舞うことは難しいだろうと考えていました。そのため、ユニットリーダーへの依頼事項を非常にシンプルにし、下記の2つの事項をお願いすることにしました。

  • ユニットメンバーとの1on1を月に1回以上行う
  • ユニットメンバーの目標設定の相談に乗り、評価時には申し送りを書く

仮説を持って制度を検討したものの、検証できていない段階であったため、まずは今年の上期の半年間を利用して検証することにしました。 当然、ユニットリーダーからは不安や戸惑いの声もあがりました。そうした場合にEMとの1on1の中で相談してもらったり、ユニットリーダー間での相談などを推奨するなどの対応をしてきました。

また、1on1をする上で、コーチングの概念をインプットしてもらうべく、人事系の顧問の方に研修を行なっていただきました。1ヶ月程度の期間で全3回の講義やトレーニングを実施していただきました。全体のゴール設計や各回の位置付けは下記の通りです。

  • 全体ゴール
    • Visionに向かうための強固なエンジニアリングチーム
    • 個人の成長を促進できる組織の実現
      • EM・ULのスキルアップによって
      • 成長促進可能な組織構造によって
      • コーチングの効用や機能しないケースの理解
  • 初回の内容
    • コーチング、1on1とは何かが説明できる
    • 場の設定ができる
    • 信頼感をもっていただく振る舞いができる
    • 傾聴とはどういうことか？を体得する
  • 2回目の内容
    • 傾聴を体得する
    • さまざまな質問を使うことができる
  • 3回目の内容
    • 自分の成長ポイントを発見する
    • 成長実感がもてるアプローチができる

研修実施後にユニットリーダーが各々でメンバーたちとの1on1を実践し、1〜2ヶ月後にフォローアップの研修を入れることで、インプットと実践のバランスを意識したトレーニングを実施しました。

ユニット制度の効果検証

このように新たな制度設計、役割を付与し、トレーニングも課しながら半年間の実践を行いました。この制度の効果検証として、ユニットリーダー、ユニットメンバーそれぞれにアンケートを実施し、制度の改善や効果の検証を行いました。詳細は割愛しますが、調査項目としては下記のような内容を設計しています。

  • ユニットリーダー向けの調査項目

    • メンバーとの1on1の実施頻度
    • 自分の振る舞いの点数
    • 理由
    • どんな話題を話したか
    • EMとの1on1の頻度
    • EMとの1on1の満足度
    • どんな話題を話したか
    • 制度の改善点

  • ユニットメンバー向けの調査項目

    • リーダーとの1on1の実施頻度
    • 1on1の満足度
    • 理由
    • どんな話題を話したか
    • 制度の改善点

すべての結果を紹介することは難しいので、いくつかを抜粋して紹介します。 まずは1on1の実施の頻度についての結果です。

オーダーでは月に1回以上の1on1をお願いしていましたが、実態としてそのオーダー通りの実施は3割程度で、それよりも多い週に1度や隔週に1度の頻度で開催している実態が明らかになりました。

また、ユニットリーダーが自身の振る舞いについてつけたスコアはかなりのばらつきがあり、試行錯誤していた形跡が見て取れます。

ユニットリーダーは悩みながら試行錯誤していたのですが、それを受けていたメンバーの1on1への満足度の分布は下記の通りでした。

当初、私たちが想定していたものよりも平均的に大きな満足度のスコアとなっていました。これは非常に良い結果でもあると考え、引き続きこの路線を踏襲することにしました。この調査だけでなく、当初見ていた組織のパルスサーベイでも改善傾向が出ており、今回の施策の効果はいずれのメトリクスでも検証ができた状態になりました。

おわりに

制度を始めてみて、最初の振り返りとしてはまずまずの成果が出たと認識しています。しかし、まだまだ始まったばかりです。制度の設計や運用に課題がないわけではありません。今回さまざまな改善点や意見もあがってきました。そうした改善点も組み込んでいき、よりよい制度の運用を目指して、引き続き組織の取り組みを推進していきたいと思っています。

明日はid:aereal さんの投稿です。楽しみです！

  1. パルスサーベイ（Pulse Survey）は、会社が社員の満足度や心の健康度を把握するための調査です↩

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留学制度の運用や改善になんらかの貢献ができるように頑張っていきたいと思います。

*1:https://en.wikipedia.org/wiki/Pre-mortem

© 2020 Classi Corp.