Cloud Composer 2へのupgradeでどハマりした話

この記事は Classi developers Advent Calendar 2021 の10日目の記事です。

こんにちは、データプラットフォームチームの滑川(@tomoyanamekawa)です。
Google CloudのCloud Composerのversion2(Cloud Composer 2)がpreview公開され、Terraformでも10月末から作成可能になりました*1。

「Cloud Composer 2ならworker数をautoscalingしてくれるらしい。そんなに設定変わらないだろうからサクッと移行しよう。」 くらいの軽い気持ちでCloud Composer 1からupgradeをしましたが、てこずってだいぶ時間を溶かしてしまいました。

そのハマったポイント4つとCloud Composer 2へupgrade完了した上での所感をまとめた記事です。

※追記:
2021年12月16日にgenerally available (GA)になりました。 https://cloud.google.com/composer/docs/release-notes#December_16_2021

*1:v3.90.0からnode_configを含めたCloud Composer 2をTerraformで作成できるようになった

composer: removed config.node_config.zone requirement on google_composer_environment (#10353) https://github.com/hashicorp/terraform-provider-google/releases/tag/v3.90.0

Amazon EventBridge(CloudWatch Events)で動かしているバッチをDatadogで監視する仕組みを構築した話

開発本部 認証連携チームでエンジニアをしている、id:ruru8net です。

これはClassi developers Advent Calendar 2021の9日目の記事です。
昨日の記事はこちらです。 Hardening 2021 Active Fault 参加レポート - 桐生あんずです

以前のClassi Advent Calender 2019では新卒が入社半年で社内サービスをリリースしてエンジニア楽しいってなったお話を書かせていただきましたが、あれから2年の間に業務の中で様々な経験をし、さらに知識やスキルを身につけていくことができました。

今日はその中でも自分が担当しているサービスの、バッチ監視の仕組みを考えたので紹介させてください。

背景

担当チームでは毎日深夜2時にDBからデータを削除するバッチを動かしています。
他にも社内では様々なバッチが動いていますが、これらを監視する仕組みは社内で確立されていませんでした。
そのためサービス稼働に影響の少ないバッチは実行中に問題があったり、そもそも実行されていなかったりしても検知されず、見過ごされてしまうことが多かったです。
弊社ではサービスの監視にDatadogを使用しているため、この監視体制にそのままバッチの監視を組み込むことでバッチの監視ができていない状態を是正したいと考えました。

前提

バッチファイル

Ruby on Railsを使い、rake taskとして実行させています。

バッチの仕組み

Amazon EventBridgeにてECS Fargateのタスクを起動させ、実行しています。これは既にdatadog-agentコンテナが動いている前提です。datadog-agentコンテナの設定方法は以下のURLを参考にしました。

https://docs.datadoghq.com/ja/integrations/ecs_fargate

バッチの構成図

使用する監視、通知ツール

• Datadog
• Slack

監視したいこと

バッチ実行において監視したいことは以下です。

1. 定期的な実行の成功と失敗

   • バッチ実行中に例外が発生した場合の検知
   • バッチ実行用のタスクの起動自体がされなかった場合の検知
   • 例外を発生せずに何らかの理由でバッチ実行のコンテナが終了してしまった場合の検知

2. 実行時間の異常

今回は定期的な実行の成功と失敗をメインとして、

• バッチ実行中に例外が発生した場合の検知

  • →発生した例外をDatadog Eventとしてエラーを送信。DatadogのMonitorにてエラー通知を監視するMonitorを作成しエラーが送られてきた場合はslackにアラートを送信する。

• バッチの起動自体がされなかった場合の検知

  • →バッチ実行の成功をDatadog Eventとして送信。DatadogのMonitorにて成功通知を監視するMonitorを作成し、成功通知が送られてこなかった場合はSlackにアラートを送信する。

という監視の仕組みを作っていきます。

バッチ実行を監視する仕組み

手順

1. dogstatsd-rubyを使ってバッチのスクリプトファイルにDatadogへEventを送信するよう書く

DatadogにEventを送信する方法は４つあります。

docs.datadoghq.com

• Custom Agent Check
• DogStatsD
• Email
• Datadog API

今回のようにsidecarコンテナとしてdatadog-agentを起動させているのであればDogStatsDを使ってEventを送るのがやりやすいと思います。

今回はRubyで書いているので基本的にはDatadogのドキュメントに書いてあるExampleと、使用するgemであるdogstatsd-rubyのドキュメントを参考にコードを書きました。 docs.datadoghq.com github.com

▽作成したバッチのスクリプトファイル

require 'datadog/statsd'

task batch: :environment do
  begin
    begin
      # バッチの実行時間を計測
      execution_time = Benchmark.measure do
        ###
        # 実行処理内容は省略
        ###
      end

      statsd = Datadog::Statsd.new(logger: logger, single_thread: true, buffer_max_pool_size: 1)
      begin
        # バッチの実行が完了したら成功Eventを送る
        statsd.event(
          'データを削除するバッチ', # Eventのタイトル
          "バッチ実行時間 #{execution_time.real}s", # 好きな内容をメッセージとして送れる
          alert_type: 'success',
          tags: ['env: development', 'service:rails-app'] # タグを指定
        )
      rescue => e
        logger.error e
      ensure
        statsd.close()
      end
    rescue => e
      begin
        # バッチ実行中に問題が発生した場合はエラーEventを送る
        statsd = Datadog::Statsd.new(logger: logger, single_thread: true, buffer_max_pool_size: 1)
        statsd.event(
          'データを削除するバッチ',
          "#{e.class}:#{e.message}",
          alert_type: 'error',
          tags: ['env: development', 'service:rails-app']
        )
        logger.info 'Datadogへのエラー通知送信完了'
      rescue => e
        logger.error e
      ensure
        statsd.close()
      end
    end
  end
end

def logger
  Rails.logger
end

解説

statsd = Datadog::Statsd.new(logger: logger, single_thread: true, buffer_max_pool_size: 1)

statsdのインスタンスを作成します。
dogstatd-rubyのバージョンや必要に応じてオプションをつけてください。

https://github.com/DataDog/dogstatsd-ruby#migrating-from-v4x-to-v5x https://www.rubydoc.info/github/DataDog/dogstatsd-ruby/Datadog/Statsd

begin
  # バッチの実行が完了したら成功Eventを送る
  statsd.event(
    'データを削除するバッチ', # Eventのタイトル
    "バッチ実行時間 #{execution_time.real}s", # 好きな内容をメッセージとして送れる
    alert_type: 'success',
    tags: ['env: development', 'service:rails-app'] # タグを指定
  )
rescue => e
  logger.error e
ensure
  statsd.close()
end

eventメソッドが取れるパラメータやオプションはこちらに書いてあります。 www.rubydoc.info

またドキュメントに書いてある通り、DogStatsDのクライアントが不要になった時には適切に破棄をするためにstatsd.close()します。

2.バッチを走らせてeventがDatadogに送られているかを確認する

https://app.datadoghq.com/event/stream にてeventの一覧が確認できます。 左上の検索欄に、eventのタイトルやタグで検索ができます。
このときの検索で、eventが一意に絞り込めるようなタイトル、タグをつけるようにしてください。

またメッセージの内容も一緒に出力されます。
ですので、ここに実行時間や、実行完了したときに欲しい情報を出力させておくと確認がしやすいです。

event例

状態
成功時	成功のevent
例外発生時	エラーのevent

3. Datadog Monitorを作成する

Monitors > + New Monitor > Event を選択します。
するとMonitor作成画面になります。今回は「バッチ実行中に例外が発生した場合の検知」と「バッチの起動自体がされなかった場合の検知」をする２つのMonitorを作成します。

バッチ実行中に例外が発生した場合の検知

エラーeventのみを絞り込むように設定し、alert conditionsをセットします。今回は24時間に一回動くバッチのため、24hoursを選択、また1つでもエラーeventを受け取ったらalertとして発火させたいのでAlert Thresholdを１にしています。

エラーeventを受け取った時にalertを発砲するDatadog Monitor 作成画面

バッチの起動自体がされなかった場合の検知

成功eventのみを絞り込むように設定します。
またeventをカウントする期間を24hoursにしてしまうと、前回のeventからきっかり24時間以内にeventが来ないとalertとなってしまうので、余裕を持たせるために25hoursにしておきます。
対象期間1つも成功eventがない場合はバッチの起動がされなかったとみなしalertを送るように、Alert Thresholdを1にします。

成功通知がない場合にalertを発砲するDatadog Monitor 作成画面

③で通知させたい先のslackチャンネル(slack-{チャンネル名}となっているもの)を選択します。
(DatadogとSlack連携のセットアップはこちら
https://docs.datadoghq.com/ja/integrations/slack/?tab=slackapplicationus)

④ではslackに投稿する際のテンプレートを作成します。
ここでは色々な変数やMarkdownが使えます。

4. Monitorで設定した通りにslackに通知が来ることを確認

Monitor作成時の右下にあるTest Notificationsで確認ができます。

Test Notifications

下のようにSlackに通知が送られるようになりました。

バッチ実行中にエラーが発生した場合の通知	バッチの実行確認ができなかった場合の通知

おわりに

実装について

DogstatsDによるEvent送信はバッチ処理中への埋め込みがしやすくとても使いやすかったです。
またバッチに限らず監視の仕組みを考える時にはまず、「何を監視したいのか」を整理するのがとても大事だなと思います。
今回は実行の監視のみしかできていませんが、今後は実行時間がかかり過ぎていた場合にalertを発報できるような仕組みも監視の項目に入れていきたいです。
(現状はeventのメッセージに対してMonitorを作成する方法が見つからず、別の方法を模索中です。)

監視の仕組み構築について

社内で確立されていなかったバッチの監視に対して、この仕組みを社内展開することができ、他のチームの人たちからも喜んでいただけたので嬉しかったです。
自分のチームだけでなく他のチームにとっても役に立つような仕組みづくりというのを意識して今後も頑張っていきたいです。

明日のClassi developers Advent Calendar 2021の担当はTomoya Namekawaさんです。お楽しみに。

リモートワークのための質問力向上研修を実施しました

この記事は Classi developers Advent Calendar 2021 の 7日目の記事です。

こんにちは。顧客サポート基盤チーム兼、技術戦略室にてエンジニアをしています、中島です。

みなさんは、日々仕事をする上で必須である「誰かに質問をする」という行為について、自信を持って適切に行うことはできているでしょうか？

先月弊社では外部講師である、株式会社フィッシャーデータのあんちべさん をお招きし、質問力向上のための研修を実施しました。今回はこの研修を実施するに至った背景、研修内容を少しお見せするのと、社内の反響をお伝えします。

質問力を向上しよう！と至った背景

弊社は2020年2月頃よりリモートワークへの移行を行い、1年半以上が経過しました。リモートワークのお困りごととして一般的にもよく聞かれる、コミュニケーションについての課題を見聞きするようになってきました。 （ちなみに私自身は2020年4月入社で、まだ片手で数えられるほどしか出社したことがありません）

特にコミュニケーションの一つである「質問をする」ということに対して、リモートワーク以前では気軽にできていた（ような気がする）のに機会が減ってしまったり、やり取りするのに時間がかかるようになってしまったり。

質問をする人も、回答する人も、双方ともになんだかしんどいぞ？と感じることが多くなってきました。 そんな時、とあるメンバーが「質問投げる時も受ける時も意識してもらえると助かるノウハウが多いよ」とあんちべさんのツイートをSlackで共有してくれました。

https://t.co/PrTfoAuhmN
技術的な質問を受けるとき、質問の内容が全然わからないこと多いんだけど、質問する側は1OIのつもりで回答者側から見たら2~3OIなことよくある。質問するということは技術で、ノウハウやアプローチがあるとまず理解して欲しい pic.twitter.com/moQF1Psql6

— (あんちべ! 俺がS式だ） (@AntiBayesian) 2021年10月22日

私は常々自分の質問の仕方が下手だなと感じることが多かったので、このツイートとツイート内にある記事にはとても感銘を受けました。本部長があんちべさんの質問の仕方研修を受けていたこと、その内容が今のClassiの課題にもマッチすることが多いのではないかという思いもあり、ぜひ具体的にお話しをお聞きしたく研修をお願いすることになりました。

質問とは何か

研修の始めにまずあんちべさんより問われました、「質問とは何ですか？」と。

このような抽象的な質問をする背景としては、今回の研修の目的「質問力を上げたい！」という共通のゴールのためには共通の言葉の定義をし、まず認識を合わせる必要があるということでした。まずは「質問とは？」の定義を以下のようにはっきりとさせます。

「質問とは問題解決のアプローチである」

定義のあとでよくない（けどよくある）質問の例を挙げていただきました。

• なぜよくないのか？
• なぜうまくいかないのか？
• そもそもなぜ質問するのか？
• 質問で実現したいことは一体何なのか？

これらのことを理解した上で、どのように質問に立ち向かっていけばよいのかを学びました。

知らないことを聞くということは質問をする上での一つのHowであって、本当にやりたいことではありません。質問とは何なのかを正しく把握することが、正しい質問への第一歩と教えてもらいました。

良い質問のために

どのような質問をすれば、成果に繋がるのでしょうか？ここでもまた「成果とは何か？」という問いを投げかけてくれました。成果を生み出すためには以下の3点セットが重要であるとのことです。

• マインド（方向性）
• 知識・スキル（方法論）
• 行動（実践）

ここまでの前段で質問とは何かというマインドを学びました。どれか一つでは駄目で、3つ揃うことでより複雑な問題のゴール（成果）に向かっていけるということです。

どのような質問をすればよいのか？

ここからは後半です。具体的にどのような質問をすればよいのか？の方法論を学びました。

質問の手法

質問の手法として2つ挙げてくださいました。手法の詳細については調べていただければと思います。

1. クローズド・オープンクエスチョン
   • 質問の背景次第で、使い分ける
2. チャンクダウン・アップ
   • 質問が噛み合っていない時に、抽象度を合わせる目的で使う

質問のレベル

質問の手法は背景次第で変わってくるため、どのような状態を自覚しているのか、質問者・回答者双方で認識を合わせる必要があります。そのために質問には「レベル感」があるということを学びました。

まずは以下の3段階から、どの状態の時にどういった質問をするべきか具体事例を元に理解しました。

質問のレベル

※詳しく知りたい方は以下の記事を見ると更に理解が深まるかも知れません

• The Five Orders of Ignorance
• 質問は恥ではないし役に立つ - Qiita

質問者と回答者の心得

「なんで教えて（回答して）くれないんだろう？」「なんでそんな質問するんだろう？」双方このように思ってしまい、社内の関係がギクシャクすることはありがちです。

「質問をする」という行為は、得てして「質問者による質問の仕方の改善」がフォーカスされることが多い気がします。ですが、回答者の存在も忘れてはいけません。双方ともに以下のような心得を持つことが重要だと学びました。

質問者と回答者の心得

質問者の心得にもあるように、感謝の気持ちを示すという手段の一つとして、弊社で導入している Unipos といったピアボーナスでも伝えることができそうです。

良い質問のためのチェックリスト

質問のレベルも自覚できていて、心得も問題ないと思っている。しかし不安が拭いきれない場合のために、質問文を作るときのチェックリストを頂きました。

良い質問のためのチェックリスト

私自身できていなかったことばかりで、頭の中の整理をする上で非常に有用なリストと感じました。この内容をしっかりと考えることで解決策を思いついて質問しなくても良くなった！ということもありそうです。 このチェックリストは社内でもとても反響がありました (印刷して机に貼っておく！と言う人や、SlackでPinしている人も複数名いました)

質問がうまくいったかのチェックリスト

質問のやり取りが終わった後、質問に対して不足がないかを確認する必要があります。以下が明確に得られていれば、次の動き出しもスムーズです。

• "As is → ギャップ → To be" が得られているか
  • 構造が明確になったか？
• ネクストアクションが得られているか（自分で思いつけたか）
  • 次の具体的なアクションが明確になっているか？

質問をして回答をしてもらったけど、もやもやが残ることがたまにありました。これはAs is, To beを描けずに質問をしていたんだなと私自身気付くことができました。

質疑応答

弊社から挙がった質問を一部抜粋して掲載します。詳細を載せるのは控えますが、興味のある質問もあるのではないでしょうか？

質問者されたときに圧をかけずにいい質問者としての成長を促すにはどうしたらよいでしょうか？ (やり方次第では詰める感じになってしまって難しそうに思いました)

なぜこの質問に回答するのか？を考えてから回答するとよいとお話しいただきました。

• 回答は育成のためと考える
• 質問者と回答者の間には知識等の高低差があるのが通常
  • 知っていて当然、のような態度を取らない
  • 質問者のレベルを把握（状況把握）し伴走する

いただいた回答内容は上の方で資料を掲載した「質問者と回答者の心得」にもあるところですし、あらためて意識していけるとよさそうです。

そもそも質問が出にくい組織の場合、どのようなコミュニケーションの課題があると思いますか？

あんちべさんからよくある課題を共有していただいた上で、改善のためによく行っている打ち手を3つお話し頂きました。

• 交流会を開催する
  • レビュー会や相談会
• 可視化される進捗管理をする
  • 上位者からの質問機会
• ざっくばらんな雑談会を設ける

回答者と前提や制約や諸々を共有できるように、丁寧に質問文を作った結果、Slack 上で結構なボリュームの文になり、回答者が「ウッ」ってなり、確認を後回しにされる経験が多くあります。オンライン上の適切な質問において、上記のような問題を軽減するテクニック等ありますでしょうか？

回答者としては、回答するために背景説明をしてほしい気持ちと、長文読みたくない！の矛盾した気持ちを持ってしまうことがあります。そのために質問者として心がけたほうが良い質問の仕方を教えてもらいました。

• 全体感が理解できるサマリを作る
• 構造化して補足する

研修の反響

元々エンジニア向けに企画した研修でしたが、部署を超えエンジニア以外の方も含めて50名近く集まってくれました。講義内容は弊社メンバーも思い当たることや気付きも多かったようで、講義中のチャットも大変盛り上がりました。

研修後の実務では、これ質問力研修で習ったやつだ！と言ってくれるメンバーもいて、共通言語としてインストールできた気がして嬉しかったです。

Slackで感想を書いてくれたメンバーもいました🎉

Slackでの反響

質問力の向上に役立つ記事になりましたでしょうか？打席に立ち続け回数をこなしていかないと質問力は磨かれないということですので、学んだフレームワークを活かして実務に挑んでいこうと思います。

とてもためになるお話しをあんちべさんよりお聞きできて、大変感謝しています。ありがとうございました！

研修時に使用されたあんちべさんのスライドはこちらになります。

JSConf JP に参加してきました

こんにちは。開発本部プロダクト開発部学習チームでエンジニアをしています、id:tkdn 武田です。

弊社もスポンサーとして後援していた JSConfJP へ参加してきましたので、今日はそのレポートと特に気になったセッションを中心に感想をまとめていきます。

なお、この記事は Classi developers Advent Calendar 2021 の 3 日目の記事です。

JSConfJP について

本カンファレンスは本年が 2 回目の開催です。前身となっている Node 学園祭が、各国で開催する JSConf といった冠のついた日本版 JSConf といった趣きのイベントとなり、2019 年から生まれ変わっています。私個人としては前身のイベントには 2017, 2018 に参加、JSConfJP 2019 に参加しているので、今回のオンラインイベント含めて 4 回目の参加になります。

今年は SpatialChat の会場が用意されスポンサーブースの設置もありましたが、自身の性格もあいまって話しかけるのは難しかったなという印象でした。Twitter でのハッシュタグつきの投稿は盛り上がっており、当日は私も見ていたセッションについて積極的にコメントしていました。

アーカイブが残っていますので見逃したセッションのある方や当日参加できなかった方は以下からご覧になれます。

• JSConf.jp Track A
• JSConf.jp Track B
• JSConf.jp Track C

ソフトウェアをめぐる話

最初に取り上げるのは Classi フロントエンドのプロジェクトに入っているツールの 1 つでもある Prettier、そのメンテナーである sosukesuzuki さんのセッション。そして、今年会社化され Deno Deploy など分散ホスティングサービスも展開する Deno、その中の人でもある kt3k さんによるセッションです。

エコシステムを支える OSS の努力や課題

sosukesuzuki さんのセッションで語られた印象的な部分は Prettier がエコシステムでどういった立ち位置にあるのかといったものです。

下記は TC39 Proposal の策定プロセスから、各ツールチェインに新しい構文がどう反映されどのパーサにどういった役割があるか発表のスライドから引用したものですが、かなり複雑な図に感じますね。

セッション後の質疑応答では sosukesuzuki さんの個人的な見解ではあるものの、「今の JavaScript を支えるツールチェインは歪な形をしている」という話が出ていました。

Rome などのオールインワンの OSS が代替ツールとして出てくることについても、各ツールが独自にもつパーサによる解析を統一すればコンピュータリソースの削減もできるし計算効率も高くなり無駄がなくなる、順当な流れなのではないだろうかというお話でした。このくだりは本当にいいお話だったので、執筆の際にも何度か繰り返し再生しています。

OSS のメンテナーが感じている所感をほかのソフトウェア（webpack, Babel）のメンテナーのインタビューも交えながらリアルな声を聞けたのは、OSS の実際というところを垣間見る良い機会となりました。

しばしば話題になる以下のようなメンテナー不足の issue を見るたびにユーザーとして心を痛める反面、ソフトウェアにできることは何なのかを考え、還元していかなければとあらためて感じました。

• We need regualr CRA maintainer · Issue #11180 · facebook/create-react-app
• Project dead? · Issue #3930 · axios/axios ※ 執筆時点ではすでに解決済みです

法人化しユーザー・ソフトウェアを増やそうとするプラットフォーム

スライドリンク：Deno のこれまでとこれから JSConf JP 2021

一方で Deno は法人化しており Deno Deploy をベータで公開しながらも GA した際には収益化も検討しているプラットフォームでありカンパニーです。すでに GitHub においての採用が発表されていますし、つい先ごろ発表された Slack の新しい開発プラットフォームのバックエンドとしても採用されています。

kt3k さんから語られたのは Deno のこれまでの歩みとこれからについてでした。Deno は Node.js の作者でもあった Ryan Dahl が Node.js をデザインした際の後悔を元に、それらを克服したプロジェクトとして立ち上げたものです。

Ryan Dahl の後悔はいくつかあるようなのですが、その中でも実行環境におけるセキュリティサンドボックスのモデルについてをここでは取り上げています。

Node.js は実行時の許可なくファイルの読み書き、ネットワークアクセスなどが自由にできますが、Deno では実行時のパーミッションオプション（--allow-read, --allow-net など）を有効にしないとできません。実行時に明示的に権限を与える必要があるのです。これによって高いセキュリティを期待できる点も採用事例が増えてきた理由でしょう。

ですが、セッションでも語られたように 10 月に大きなロードマップの追加がありました。それが Node.js 互換モードです。おい待てよと、Node.js との差別化のために生まれたはずなのに迎合しているのでは、といった意見がコミュニティや社内から湧き上がったそうです。

Node.js 互換といった 180 度の転換が Ryan Dahl 本人からの発案であることも驚きですし社内では反対意見が多かったということも驚きですが、背景としては Deno をインストールするユーザー数の今のところ横ばいであるのも起因しているようです（質疑応答より）。

スライドでも登場しますが、卵が先か鶏が先かのプラットフォームの問題にも触れ、ユーザーが少なければそのプラットフォームで動くソフトウェアは増えず、ソフトウェアが少なければそのプラットフォームを使うユーザーが増えないという Deno が今直面している状況と、今回の Node.js 互換モードが紐付けられています。

こういった Deno の裏側を知ることができたのも興味深くおもしろい話でした。

アクセシブルな Web のためのフロントエンド開発

最後に取り上げるのは yamanoku さんによる「アクセシブルなフロントエンド開発のこれまでとこれから」というセッションです。

この発表の前に yamanoku さんは「HTML だけで UI を作る限界、あるいは無理なくユースケースと向き合っていくためには」と題した発表も別の場でされており、そちらも強く私の印象に残った内容でした。

今回はその限界を示しながらもっとアクセシブルであるためには、といった内容が主題になっています。Web, HTML そして HTTP の父であるティム・バーナーズ・リーの引用も交えながら、アクセシブルとは普遍的に障害の有無に関係なく誰も使えることが本質だという力強い言葉に、Web が好きなフロントエンド開発者として冒頭から胸が打たれました。

そして肝心のアクセシビリティに関してですが、セッションの内容には恥ずかしながら自身にとっては初めて知ることが多く反省も多くありました。

たとえば SPA におけるルーティングの遷移後、スクリーンリーダーでの読み上げ時にページが変わったことを検知できないというデモを見て、初めて WAI-ARIA aria-live について認識できました。Angular では下記のような実装イメージで画面タイトルの変更をスクリーンリーダーを扱うユーザーに通知できます。

<div *ngIf="pageTitle$ | async as pageTitle" aria-live="polite">
  {{ pageTitle }}
</div>

発表のあとに調べると Angular CDK では LiveAnnouncer といったモジュールも提供されておりこちらもうまく活用できそうです。

@Component({/* ... */})
export class MyComponent {
  // ...
  constructor(liveAnnouncer: LiveAnnouncer) {
    liveAnnouncer.announce(this.pageTitle));
  }
}

ほかにも Custom Elements に直接 role 属性を与えずに JavaScript から内部的に与えるという Accessibility Object Model といった案もコミュニティから出ていると知りました。利用時に都度必要な属性を利用者が付与せず、Custom Elements の実装者が内部的に担保できるというのは納得の提案ではあります。

スクリーンリーダーへの対応というと身構えそうですが、スライドでも出てきたようにキーボード操作のタブフォーカスでアクセスが可能かといった小さなところからでも始められるはずです。UI が知覚可能であるかどうかということを気にかけるだけでも、考慮できるポイントが増えそうだと感じました。

JSConfJP オンライン参加を終えて

Node 学園祭から参加し続け、今回は初めてのオンライン開催でしたが、オフラインと変わりなく JSConfJP を楽しむことができました。カンファレンスでは新たに気付くことも多く、今回は特に OSS やソフトウェアが成立するためのプラットフォームの話から、我々開発者はどうコミュニティに貢献するのかといったことをあらためて考えさせられる良い機会を得ることができました。

まだまだ数は少ないですが社内メンバーの登壇やコミットメントという形でも成果を発揮しながら、Classi は今後もコミュニティを通じて OSS への還元を目的に、利用技術のカンファレンスやイベントに支援していく予定です。

またカンファレンスで得た知識、特に今回はアクセシブルな UI を実装していくことなどを現場のプロダクト開発に持ち帰りたいと思います。

JSConfJP 運営の皆さま、ご苦労さまでした！

Google Cloud Security Summitに登壇してきました

こんにちは、データAI部の滑川(@tomoyanamekawa) & 工藤( id:irisuinwl )です。 今日(2021-12-01)、2人でGoogle CloudのSecurity Summitに「Security Command Center から始めるクラウド セキュリティ運用」というタイトルで登壇してきました！ その報告と発表内では話しきれなかった各施策の実装面の補足の記事です。

マネージャーからエンジニアに役割を変えた話

はじめに

すっかり寒くなりましたが、皆さまいかがお過ごしでしょうか。Classiの佐々木（@sasata299）です。

タイトルにもありますが、9月まで担っていた開発本部長*1を離れて、10月からエンジニアに役割を変えました。この記事では、どんなことを思って、どんな風に考えて進めてきたのかをお伝えできたらと思っています。

最近やっていたこと

開発本部として80名を超える大きな組織となり、最近は主にこの辺りに関わってきました。

• 開発本部として大切にしたいことを決定
• CTOの責務を、VPoTとVPoEに分解*2
• アラート対応の体制化や手当検討
• 既存の部から役割を分けて分割する形で、開発支援部の新設
• 評価体制の変更

余談ですが、こういった組織課題に対して、当初はVPoTである丸山（id:nkgt_chkonk）、稲富（@laco2net）、佐々木という3人体制でスクラムで進めていました。実際やってみて、プロダクトづくりに限らず組織課題に対してもスクラムは有効なんだなというのを実感しました。

途中からは開発本部内の各部長も加えて少し形を変えましたが、今も変わらず、こういった組織課題にはチームとして継続的な対応を続けています。

マネジメントを経験してみての気付き

組織は生き物で日々いろんな課題が出てきますが、組織全体の生産性を上げる仕組みを作るなど、マネジメントとして関わることの魅力や悩みはたくさん感じてきました。

実際にやってみないと向いてる/向いていないもわからないので、いろいろな組織規模でマネジメントを経験することができたことは、とてもとても良かったなと思っています。

一方で、先に挙げたような課題に取り組んでいく中で、今、このフェーズで開発本部長に求められているのは、課題を抽出して抽象化して、解決策として適切な仕組みをつくる力なんだろうなと感じていました。 そしてそこは、佐々木に足りないところ、弱いところだな、とも感じていました。

課題は明確になってきていて、適切な人がやればもっと早く対策を打ったり仕組みが作れそう。だけど、佐々木が開発本部長でいることでボトルネックになってしまう。より良くなるために、もっと適切な人に開発本部長という役割を担ってもらうべきだと思ったんです。

エンジニアとしてやっていく

もう一方の理由として、コードを書きたい、コードを書いて貢献したい、というのがありました。ここ数年はよりボトルネックになっているマネジメントをやってきましたが、もともとコードを書くのが好きでエンジニアになったので。（大体の人がそうですよね）

加えて、マネジメントをやる期間が長くなり、また、組織の成長もあってマネジメントする対象範囲が広がったことで求められる役割も現場から離れてしまっていたので、エンジニアとしての現場感が無くなってきていてヤバいという危機感も強くありました。

こういったことを考え、開発本部長を離れてエンジニアとしてやっていきたい、と少しずつ代表と相談を進めていきました。

次の体制の検討

開発本部長を離れるにあたって一番の課題は「次の体制をどうするか？」というものでした。どんな形を取るとしても一定の不安や変化は発生しますが、それらを出来る限り小さくしたいと考えて進めました。

開発本部長に求められる役割やスキルを改めて整理し、誰がもっとも適任なのか。今のClassiにとって最善なのはどういう形なのか。いくつかの選択肢から経営陣とも何度も議論を重ね、開発本部内のデータ/AI部（データサイエンティストやデータエンジニアが所属する部署です）の部長である伊藤（@tetsuroito）に開発本部長をお願いすることを決めました。

伊藤のこれまでの社内での活躍やそれによる信頼もあり、10月からの体制を社内に周知した際には前向きな反応が得られました。あれもこれも完全に引き継げた！というわけではないので課題はあるのですが、まずは少しだけホッとしました。

今やっていること

10月からは役割を変え、新規事業の立ち上げにエンジニア（not マネージャー）として関わっています。「tetoru」という小中学校向けの保護者連絡サービスです。

tetoru.jp

エンジニアとして手を動かすのは久しぶりですが、ユーザに価値を提供するためにプロダクトを作っていくのは純粋に楽しいな〜と感じてます。 Classiは高校（一部中高一貫校含む）向けにプロダクトを提供しているのですが、「tetoru」では小中学校向けにプロダクトを提供していきます。

私事ですが、子供がちょうど小学生なので自分自身がまさにユーザーです。保護者として自分が使いたいプロダクトを自分で開発しているというのは楽しいし、エンジニア冥利に尽きます。早く子供の学校でも導入されてほしいし、大きくなったら子供にも自慢したいなぁと、そんなことを思ったりしています。

まだまだやりたいことはたくさんあって仲間を募集しているので、少しでも興味あれば気軽にお話させてください！

hrmos.co

おわりに

Classiに限らずだと思いますが、一度マネジメント側に行くと戻りにくい感じがしますよね。マネジメントをされている方がコードを書きたくて別の会社に転職するという話もよく聞きます。

マネージャーからエンジニアに役割を変えるキャリアを普通にしたいし、Classiであれば大変だけどやれなくはないだろうと思ったのでまずは自分自身でチャレンジしてみた、という話でした。この事例が少しでも参考になれば幸いです。

そういえば今日からアドベントカレンダーですね！弊社のトップバッターは伊藤なので、お楽しみに。

*1:以前の記事ではVPoEと呼んでいたのですが、紆余曲折あり、途中から開発本部長と呼ぶようになりました。

*2:詳しくは https://tech.classi.jp/entry/2020/11/13/120000 を参照ください

エラスティックリーダーシップ読書会 修了レポート

新卒入社三年目の小野です。校務チームで生徒を登録する機能の開発を行っています。 先日、弊社で新卒オンボーディングチームに所属されている @igaiga555 さんが主催するエラスティックリーダーシップ読書会を修了しました。会の概要や感想を書かせていただきます。

開催されるまでの流れ

新卒オンボーディングチームで、新卒メンバーにチーム開発時に知っておくべき知識を身につけて欲しい、という課題感があったようです。オンボーディングチームの方が、知識を身につけるには社内メンバーによく読まれている本を読むと良いのではと考えて、プロダクト開発部の雑談・相談チャンネルでマネジメントや組織についてのおすすめの本を募りました。結果、エラスティックリーダーシップ が最多得票しました。さらに、エラスティックリーダーシップについて、フロントエンドエキスパートチームの @lacolaco さんが「必読書で良いのでは」と強く勧めたことから、エラスティックリーダーシップ読書会をやろう、という動きが新卒オンボーディングチーム内で活性化したようです。その後、@igaiga555 さんが以下の呼びかけを行って、読書会が開催されることとなりました。

私は新卒入社の1人として必須参加だったこともありますが、社内で複数人の方がこの本を勧められていたのを見ていたため、本の内容に興味を持って参加しました。

読書会でやったこと

読書会は月曜日の1時間を使って行われていました。会の流れは以下です。

• 参加者が集まるまで雑談する。(2分程度)
• あらかじめ指定されていた章を各自で読みながら、感想をJamboardに書く。(人数により変動。だいたい25分)
• 残りの時間でJamboardを見ながら、参加者が1人ずつ感想を読み上げていき、他のメンバーはコメントしたり、質問などをして議論する。

感想は最初の1回目はJamboardではなくesaに各自で書く形式でしたが、@kiryuanzu さんの提案により2回目以降はJamboardを使うようになりました。各自違う色の付箋を使うことでコメントを書いたのが誰かすぐ分かるようになり、リアルタイムな議論がしやすくなりました。

Jamboardを用いた議論の例

印象に残った章

私個人として一番印象に残ったのは、4.2.1節「必要なゆとり時間はどれくらいか」の一節である、「学習時間の生産性が通常の生産性よりも10倍も低い」です。目の前の仕事に追われるサバイバルモードから、スキルを伸ばせる学習モードにチームを導いていくべきであり、またモードを移行するにはゆとり時間が必要であるという説明の一部としてこの一節が書かれています。当時、私はフロントエンドにページビューを取るためのタグを埋め込むという全く経験のないタスクを任され、進捗が思うように上げられずにいました。この一節から、経験がないことを学習しながら進めることは、時間が10倍かかるのだから大変でも当然である、という気付きを得ました。もっとも、5章において学習のためには逆境に飛び込む必要があることが述べられており、学習が決して易しいことではないことも書かれています。

次に印象に残ったのは、6章の「コミットメント言語」です。コミットメント言語とは、相手に言質を与える言い方のことです(ex: 今週中までに終わらせます、毎日何時間ずつタスクに取り組みます、など)。逆にコミットメント言語でない言葉は、実現できない余地を残します(ex: ○○する必要がありますね、できるだけ早くやろうと思います、など)。コミットメント言語を使い個人のコミットメントが明確になることで、目標達成を阻害する要因を見つけることに役立ちます。 印象に残ったポイントとしては、私自身がコミットメント言語でない言い方を使いがちであったことや、コミットメント言語を習得すること自体が不快なものである、と感じたことです。話し相手が聞きたいことを言ってしまった結果、コミットメント言語ではない言い方を使ってしまう傾向があると気付いたので、今ではコミットメント言語を使うよう心がけています。コミットメント言語を習得することの不快さは、6.6節「どうやって取り組みに彼らを乗せるか」、8章「自己組織化を促進させるためにクリアリングミーティングを行う」を読んで感じました。チームでコミットメント言語を習得するためには、自分がお手本になってコミットメント言語を使うことや、相手がコミットメント言語でない言い方をした場合は言葉を直していくことが必要になると述べられています。これはやる側にとっても、やられる側にとっても不快な取り組みであると感じますが、新しいことを学び、安全地帯から出る時には不快になることは必要であると述べられています。何かを学ぶ際には不快になることを避けるべきではない、ということが、5章~8章での主要なメッセージであると読んでいて感じました。

感想

まず本の内容については、具体的な手法については応用できそうだと思えた一方で、この本ではリーダーに対して極めて高い技術力とコミュニケーション力、飽くなき向上心を求めていると感じたので、「こんなに凄いリーダーになるのは難しい」とも感じました。しかし、本の内容で同意できるところはいくつもありましたし、良いチームを作るためにリーダーがどう動くべきかを理解して、さらにリーダーを補佐できるチームメンバーになるためには、リーダーシップについての知識は必要だと感じました。実際に目の前の問題をどう解決するか？チームでどのように振る舞っていくか？については、読書会の他の参加者や先輩と議論しつつ、チームを良い方向に導いていけたらと思います。

読書会としては、新卒メンバーが書いた本の感想に対して @igaiga555 さんからさらに考えの深まるコメントを返していただくなど、和やかながら学びのある時間でした。議論が盛り上がる一幕もあり、特に評価制度について、「学習に時間を使えるようになるためには、評価制度に工夫が必要なのではないか」という観点で話が盛り上がりました。

読書会を通して学んだ、”コミットメント言語” を使うといった点を普段のチーム開発で心がけたところ、「できないことをできないとしっかり言ってくれるから仕事がしやすかった」とディレクターの方からフィードバック頂きました。今後も読書会への参加や、本を読むことは継続しつつ、得た知識を仕事で使っていくことも欠かさず取り組みます。