QUO CARD Digital Innovation Lab Tech Blog

クオカード デジタルイノベーションラボの技術ブログです

クオカード デジタルイノベーションラボのオンボーディング体験記

こんにちは! クオカード デジタルイノベーションラボで採用を担当しております、金子です!

1つ前の記事「「エンジニアにとって魅力的な会社でエンジニア採用がしたい」私がクオカードに入社した理由」ではクオカードに転職するまでの経緯について振り返りましたが、この記事では入社後のオンボーディング体験を振り返ってみたいと思います。

※オンボーディングとは 乗り物に乗っていることを意味する「on-board」を由来とし、新しい仲間の順応を促進する取り組みを指す言葉です。 人事用語では、新しく会社・組織に加わった人材にいち早く職場に慣れてもらうことで、組織への定着・戦力化を促進するための取り組みのことを指します。

それぞれの取り組みにおいて、よかったと感じた点とより良く改善したいなと思った点もありのまま書いていきたいと思うので、これからクオカードに入社される方や少しでも興味を持っていただいた方の参考となれば幸いです。

オンボーディング体験記

早速入社初日からのオンボーディング体験を振り返ります。 なお、以下の内容はあくまで「デジタルイノベーションラボの採用担当」である私個人の話になりますので、所属するチームやロールによって多少異なることをご留意ください。 (今後は他のメンバーのオンボーディング体験も発信していけたらと考えています!)

1日目

デジタルイノベーションラボは、基本フルリモート(出社もOKだが、遠方に住んでいるメンバーもいたり、現状はほぼフルリモート)ですが、入社初日のみオフィスへの出社をお願いしています。 理由としては、セキュリティ面でオフィスでしか設定できないものがあるためです。 ということで私も初日はオフィスへ出社しました。 その日はもう1名QAエンジニアのYさんが同日入社ということで同期の存在に勝手に一気にテンションが上がりました(笑)

そして選考は全てオンラインだったので、画面上で会っていた方々とリアルで会える、あのなんとも言えない嬉しさを噛み締めつつ、まずは全社朝会に参加し、自己紹介をしました。 (クオカードでは毎月1日にオフィスとオンラインのハイブリッドで全社朝会が開催されていて、代表からのお話や各チームからの共有、新入社者の挨拶などが行われています)

そこからは、まずはPCの設定や各アカウントの登録を進めます。私は人生初Macということもあり、色々と苦戦していたのですが、サポートとして出社してくれていたQAエンジニアのHさんがとても丁寧に教えて下さったこともあり、なんとか無事設定が完了しました。

そしてその日はデジタルイノベーションラボで歓迎ランチをしていただけるということで、普段はリモートのメンバーも出社していて、みんなで叙々苑の焼肉弁当を美味しくいただきました。(事前に叙々苑の焼肉弁当のことは聞いていたので、密かにとても楽しみにして家族にも自慢していました) クオカードでは、コミュニケーション支援として、社内懇親会費助成制度というものがあり、各部・課・グループごとに1人当たり1回5,000円が年間4回まで補助されます。 今後もこの制度を活用してチームの懇親を深めていきたいと企んでいます。

よかった点

歓迎ランチではチームの雰囲気を知ることができ、安心しました。基本はリモートでのコミュニケーションがメインとなるので、ここで1度直接多くのメンバーと会うことができてよかったです。

より良く改善したい点

ランチ会場は大きい机がどーんとある会議室だったのですが、遠い席の方とはほとんど話せなかったので、次歓迎ランチをする際にはできる限り全員と会話できるような工夫ができればと思っています。

2日目午前中

2日目からはリモートとなり、午前中に人事担当者から入社時説明をしてもらいます。内容としては勤怠や給与、人事制度や評価制度、福利厚生サービスの案内など、実務以外の部分で働く上で知りたい情報を丁寧に説明してもらいます。

よかった点

選考時にも知りたいことは質問していたのでほぼ把握していましたが、より詳細な説明をしてもらい安心しました。 そして、入社時に「info連絡網○○さん_○年○月入社」という人事メンバーとのチャンネルが作成されるので、その後も手続き等に関してなにか気になる事や心配な事があれば気軽に問い合わせることができるのもありがたかったです。

2日目午後〜2週間

人事からの入社時説明が終わった後は、実際の実務に入る前のキャッチアップを進めます。 ここでも具体的にどのようなことをしたか、振り返ってみたいと思います。

ドキュメントや映像でのキャッチアップ

まずオンボーディング時に確認すべき情報として、BacklogのWikiに「チームのミッション・ビジョン」や「目指す方向性」、また「何を」「どう作るか」や「開発の進め方」「コミュニケーションガイドライン」といった情報が明記されています。 また、システム構築環境についての説明動画やサービスについてのドキュメント等でキャッチアップを進めていきます。

よかった点

実務に入る前にこれらの情報をインプットすることで、チームの皆と共通認識を持つことができ、コミュニケーションが取りやすくなると感じました。 特に目指す方向性やコミュニケーションガイドラインがしっかりと明記されているのを見て、それらを体現しているチームの仲間になれたことが嬉しく、自分もこれからしっかり体現していきたいと感じました。 また、全社でオープンコミュニケーションを実践し、人事情報などのセンシティブな情報を扱う場合以外はほぼ全ての情報にアクセスできるため、決定事項だけでなく決定までのプロセスも知ることができてよかったです。

適宜改善したい点

スタートアップのようなスピード感を大切にしているデジタルイノベーションラボは、おそらく今後も変化し続ける組織です。いつ誰が入ってきても正しく必要な情報にアクセスできるよう、これらのドキュメントのアップデートをし続けていきたいと思います。 (実際に、リーダーである齋藤さんから「セットアップで引っかかったところやドキュメントでわかりにくいところがあったら改善したいので教えてください」と連絡があり、気になった点を伝えたところすぐに修正してもらえました。)

デイリーやスクラムイベントへの参加

デイリーやスプリントレビュー、振り返り、プランニング、リファインメントなどのスクラムイベントへ参加し、チームで取り組んでいるプロジェクトにおける理解を深めていきます。

よかった点

1番最初に参加した回にて、メンバーの方が「このMTGではこんなことしてます」という説明をしてくれて、安心して参加することができました。

ヘルプチャンネル

このブログでも何度か発信されている通り、デジタルイノベーションラボでは「15分ルール」を導入していて、15分調べてもわからないことはヘルプチャンネルでヘルプを出そう、というルールになっています。 そのヘルプチャンネルには、デジタルイノベーションラボ全チームのメンバーが参加していて、ヘルプに対して知見を持ったメンバーが回答をしてくれます。 オンボーディング期間中も、このヘルプチャンネルを活用してわからないことがあれば気軽に質問することができます。

よかった点

最初はわからないことを「誰に」「どのチャンネルで」聞けば良いのかわからない、ということがあると思うので、それがわからない状態でも「誰か知っている人教えて〜!」と安心して質問できるヘルプチャンネルの存在はありがたかったです。

書籍

入社時に以下2冊の書籍が渡され、オンボーディング期間に読了します。

・あなたのチームは、機能してますか?

アジャイルな見積りと計画づくり

よかった点

上記2冊はそれぞれデジタルイノベーションラボが目指す組織のかたちや目指す開発の進め方について書かれており、ここでもチームで目指したい方向性について共通認識を持つことができました。

雑談会

週に1度、新入社者とチームシャッフルの4〜5人のメンバーでオンラインでの雑談会(1回30分×4回)が実施されます。これまでの経歴や趣味などが書かれた自己紹介スライドを用いて、お互いの自己紹介をします。残りの時間はそれぞれの趣味について話したり、新入社者である私から気になったことを質問させてもらったりしました。

よかった点

メンバーの人となりを知ることができてよかったです。先述の通りMac初心者の私は、おすすめのツールなどを聞いたところ、皆さんありがたい情報を提供してくれて嬉しかったです。

より良く改善したい点

オンラインならではの難しさではあると思うのですが、チームが異なり業務上のやりとりをしたことがないメンバーもいるので、開始時に若干緊張感のある空気が漂っていました。 今後は採用担当としてやりとりしたことがある私が全ての会に参加させてもらうことで「あ、知ってる顔だ!」と、少しでも緊張感を拭えればと思っています。

最後に

実際のオンボーディング体験を振り返ってみましたが、いかがでしたでしょうか。 今後は採用担当として、ご入社を決めていただいた方が入社後に安心できる、そしてより活躍できるような新たなオンボーディング施策も考えていきたいと思います。

ここまでお読みいただき、ありがとうございました!

クオカード デジタルイノベーションラボでは新しい仲間を募集しています。

少しでも興味をお持ちいただけた方は、是非カジュアル面談でお話させていただければと思います!

quo-digital.jp

「エンジニアにとって魅力的な会社でエンジニア採用がしたい」私がクオカードに入社した理由

はじめまして! クオカード デジタルイノベーションラボで採用を担当しております、金子です!

今回ご縁があり、2024年2月にクオカード デジタルイノベーションラボに採用担当として入社しました。

入社後1ヶ月のタイミングで、記憶に新しいうちにクオカードに入社した経緯を4つの転職軸に基づき、振り返ってみたいと思います。

今後のキャリアについて考えている方やクオカード デジタルイノベーションラボに興味を持っていただけた方の参考になれれば幸いです。

自己紹介

まずは簡単に自己紹介します!

職歴としてはクオカードが4社目で、これまで歯科医院の受付や総務人事→建設×IT企業の総務人事→ヘルステック企業の採用担当と経験してきました。

休みの日はキャンプや登山など自然の中で過ごすことが好きです。最近は車を車中泊仕様にカスタムしたので、これからまずは北関東の道の駅をめぐる車中泊に挑戦したいと思っています。あと最近家の目の前の畑を借りだしたので、おいしい野菜も作りたいと思っています。

転職軸

今回私は転職活動を進める中で、以下3つの転職軸(転職先を選ぶ際に重要視する点)がありました。

1.やりたい仕事ができるか

ここはもちろん転職を検討している方たちの多くが重要視するポイントかと思います。

私の場合、やりたい仕事は、これまで携わりとてもやりがいを感じていた「事業会社のエンジニア採用担当」で、より細分化すると以下の2点を重要視していました。

①(将来的にでも)エンジニア組織の中でHRBPのような動きができるか

ご存知の方も多くいるかもしれませんが、HRBPとは「Human Resource Business Partner」の頭文字を取った言葉で、経営者や事業責任者のビジネスパートナーとしての視点から、組織の成長を促す「戦略人事」の事を指します。

上記の通り、採用はもちろん、エンゲージメント向上を実現することでよりチームとしての成果をあげてもらうための、オンボーディング改善や制度整備など、将来的には多岐にわたり組織の成長を促す取り組みにも挑戦できる環境を希望していました。

②採用における考え方がマッチしているか

例えば極端な話、「スキルだけでなく、バリューマッチも大切に、入社後大きく活躍していただける方がいたら採用したい」のか「とにかく人手が欲しいのでとりあえず一定スキルを満たした人がいたらどんどん採用したい」のかなど、会社やチームによって採用に関する考え方は様々だと思います。

私は採用に携わる中で「求職者と組織、両者にとって幸せな採用」を実現したいと考えていて、そのためには前述で言うと前者のような採用を行いたいと考えているので、同じような考えをもっている会社・チームの中で採用を進めることを希望していました。

2.エンジニアにとって魅力的な会社か

2つ目は、エンジニア採用担当として、心の底から「うちの会社はこんな魅力があるので、ぜひ転職先としてどうですか?」と言えるか、ということに繋がります。 HRBPを目指すのであれば、「魅力ある組織の実現」に向けての取り組みも担うべき点ではありますが、現段階でより「エンジニアにとって魅力的な会社」であればある程良いと考えていました。

こちらもこれまで面談等でエンジニアの方たちから聞いてきたお話をもとに以下3つの観点に細分化していました。

①事業内容

どんなサービスを提供していて、社会にどう影響を与えているのかなど。

②業務内容ややりがい/成長できる環境か

どんな技術を使用し、どんな開発体制で進めているのか、それによってどう成長できるか、どんなキャリアを築くことができるかなど。

③働く環境/条件

フルリモート/フルフレックスなどワーク・ライフ・バランスが充実した環境か、給与など。

上記3点において、それぞれどんな魅力がある会社・チームなのかを知るべく、気になる会社があれば、その会社のエンジニアポジションの求人やテックブログなども読み漁っていました。

3.働きやすさ

先程「エンジニアにとって魅力的な会社か」の観点の1つとしても挙げましたが、自分自身にとってもやはり重要な要素でした。 私の場合、少し都心から離れている+駅から徒歩25分程の立地に住んでいることもあり、できればリモートメインであること、そして将来的にもし子供が生まれた場合、仕事と子育てを両立することができる環境であることも1つのポイントとして気にして見ていました。

なぜクオカードに入社したのか

このように、できる限りしっかり会社とチームを知っていきながら進めていた転職活動において、最終的になぜクオカードに入社することになったのか、前述の3つの転職軸に基づいて振り返ってみたいと思います。

1.やりたい仕事ができるか

①(将来的にでも)エンジニア組織の中でHRBPのような動きができるか

今回の採用ポジションは「デジタルイノベーションラボ(エンジニアやデザイナーが所属しているチーム)付の採用担当」で、まずは採用をメインとし、オンボーディングやエンゲージメント改善にも携わることができるということで希望とマッチしていました。

②採用における考え方がマッチしているか

ここは主に一緒に採用を進めるデジタルイノベーションラボ リーダーの齋藤との面接時の会話の中で「スキルだけではなく、バリューマッチを大切にしているので、本当にマッチする人がいなければ採用しないという選択をします。」と言った話があり、実際に自分の面接の中でもお互いに採用におけるマインドが合っているか、バリューマッチしているかとすり合わせるような質問が多く、この点もマッチしていると感じました。

2.エンジニアにとって魅力的な会社か

①事業内容

元々QUOカードQUOカードPayを知っていたので、ある程度認知されていて、自分や身近な人もユーザーとなり得るサービスに携われること、そしてより多くの方に価値を提供するため、これから新規開発も予定しているとのことで、魅力ポイントだと感じました。

②業務内容ややりがい/成長できる環境か

テックブログを読み漁る中で、「脱社内外注を進めています」の記事を読み、「エンジニアはシステムを作る存在ではなく、顧客(利用者)の課題を解決する存在」として取り組んでいることを知り、共感してもらえるポイントではないかと感じました。また、新たな技術を導入しやすい環境や週に1度技術顧問を招いて勉強会を行っているなど、スキルアップしながら挑戦し続けられる環境であることも魅力に感じました。 ただ、発信力という観点で言うと現段階ではまだ課題があると感じました。今回のように自分でブログを読み漁りに行くと色々な情報が発信されていることを知ったのですが、それ以前から知っていたわけではなかったので、ここは伸び代として入社したら取り組みたいと感じました。

③働く環境/条件

フルリモート可/裁量労働制ということでワークライフバランスを充実させやすい環境であること、また、「​​リモートワークスタイルチェックをやってみました」「プロダクトグループの評価制度」等の記事を読み、「エンジニアやデザイナーが本質的な業務に集中できる環境作り」に注力されている点も魅力に感じました。

3.働きやすさ

こちらは前項でも記載の通り、ワークライフバランスを充実させやすい点と、他にも親会社が大きい会社であるということもあり、退職金制度が確定拠出年金確定給付年金の2種類あったり、有給休暇が入社日から付与されるなど、制度が充実していること、そして子育てしながら働きやすい環境であることも魅力に感じました。

と、このような経緯で入社したわけですが、今のところ上記転職軸において「思ってたんと違った・・・」ということはなく、慎重にリサーチしたかいがあったと思っています。

ただもちろん、入社してからの気づきもたくさんあるので、そちらは次の記事で紹介したいと思います。

最後に

ここまでお読みいただき、ありがとうございました!

クオカード デジタルイノベーションラボでは新しい仲間を募集しています。

少しでも興味をお持ちいただけた方は、是非カジュアル面談でお話させていただければと思います!

quo-digital.jp

PagerDuty と Sentryを用いて自動で緊急連絡するシステムを構築しました

デジタルイノベーションラボのゴルゴです。

先日、PagerDutyとSentryを活用して、バッチ処理で特定のアラート条件を満たした際に、担当の営業にオートコールを行うシステムを構築しました。今回はそのシステムの紹介をしたいと思います。

背景

ラボでは以前から、特定のアラートが発生すると営業部に対してSlackで通知を行っていたのですが、Slack通知だけでは担当者が自ら確認する必要があります。すぐに気付いて対応してもらいたいので、電話でもコールされるようにしたかったのです。

ラボの運用チームがアラートを検知して、手動で営業部にコールする方法も考えられましたが、それでは運用チームの負担が大きくなってしまうので、できるだけ運用チームを介さずに、直接営業部にオートコールを行うことを目指しました。

幸い、ラボ内では既にシステム障害を検知して運用チームにオートコールを行う仕組みがあったので、今回はその既存の仕組みを応用し、特定のアラート時には営業部に直接オートコールを行うようシステムを構築しました。

利用サービス

Sentry https://sentry.io/welcome/

アプリケーションに組み込んでおくことで、エラーの発生検知と追跡を支援してくれるサービスです。 今回は特定の条件を満たした場合にアラートを発生させ、PagerDutyに通知するために使用します。

PagerDuty https://www.pagerduty.co.jp/

インシデント対応の自動化を提供するクラウドサービスで、システム障害や重要なイベントが発生した際に、適切なメンバーにリアルタイムでアラートを送信してくれます。 今回はSentryからのアラートを受け取り、受電担当者にオートコールするために使用します。

通知の流れ

今回実現したシステムでの通知の流れです

通知の流れ

導入までの流れ

1.営業部門との調整

まず最初に行ったのは担当部署との調整です。課題の説明と、オートコールの受電担当者を決めて貰うよう相談し、担当者が受電したあとにどのような対応をしてもらうかも予め調整しておきます。

2.PagerDutyとSentryのIntegration設定

2.0.サービスの登録

今回はPagerDutyとSentryいずれのサービスもラボ内で導入済みだったのでアカウント作成はしていませんが、必要に応じてそれぞれのサービスのアカウント作成から行ってください。

2.1.PagerDuryにサービスの作成

公式ガイドのサービスを作成を参考にして、今回のシステム用に新規のサービスとエスカレーションポリシーを作成します。 エスカレーションポリシーには最終的には担当部門のメンバーを登録しますが、この時点では開発メンバ等を登録しておくといいでしょう。

2.2.PagerDuty側にインテグレーション設定

サービスを作成したら今度はSentryとのインテグレーション設定を既存のサービスにインテグレーションを追加するを参考に行います。 設定すると Integration Key が生成されますが、このKeyはあとでSentry側に設定する必要があるので控えておきます。

2.3.Sentry側にIntegration設定

今度はSentryの管理画面で、PagerDutyへのIntegration設定を追加します。 Sentryの公式ガイドを参考に行ってください。

3.バッチ設定

続いて実際にバッチの改修に入ります。

3.1.バッチへのSentry組み込み

まずはバッチからSentryへメッセージを送れるようにSentrySDKの組み込みと設定が必要です。今回のバッチはMicronautで実装しているのでJavaの設定手順に従ってSDK組み込みと設定を行いましたが、プラットフォームによって設定方法は異なるので、こちらから調べて設定してください。

3.2.アラートメッセージ送信

設定ができたら、実際にバッチで条件を満たした際に、Sentryへイベントメッセージを送るようにコードを修正します。 ここで設定したメッセージが最終的にPagerDutyからの通知でも使用されるので、ある程度内容がわかるようにしておきます。

  // 通知条件を満たした場合の処理
  Sentry.captureMessage("XXXでエラーが発生しました。至急Slackを確認して対応してください", SentryLevel.ERROR)

4.Sentry管理画面でのアラート設定

次はSentryの管理画面で設定を行います。 Sentryにログインし、Alerts > Create Alerts でアラート条件の作成をします。

特に大切なのがSet Conditionsで、次のように WHEN, IF, THEN の設定をします。

WHEN イベントを受信のたびにオートコールしたいので、毎回アラートが作成されるように条件は全て消しておきます。 初期状態だとA new issue is createdが設定されていますが、これだと最初の一回しかアラートが発動しないので注意してください。 しばらく条件を無しにできることに気付かず苦労しました。

IF 今回はイベントの message に 先ほど設定したメッセージを含んでいることを条件にします。

THEN PagerDutyへ通知を送りたいので、Send a notification PagerDuty を選択し serviceにはIntegration設定しておいたサービスを選びます。

Set Conditionsの設定画面

5.設定確認テスト

ここまでの設定を終えたら、バッチからアラートメッセージ送信→Sentryでのアラート検知→PagerDutyで検知しオートコール、という一連の流れを確認できるはずなので、検証環境等を使って動作確認しておきます。

6.受電担当者のPagerDutyアカウント作成

動作確認がうまくいったら、PagerDutyのエスカレーションポリシーに登録するため、受電担当者のPagerDutyアカウントを作成します。 ユーザーの追加ガイドを参考に、先に決めておいた受電担当者に招待メールを送り、登録作業をしてもらいます。

7.エスカレーションルール設定

複数の受電担当者がいる場合には通知の順序や、一人目が応答しない場合に次の人に連絡するまでの間隔等を設定します。

8.テストコール

エスカレーションルールへの設定順の確認や、実際に受電する人に慣れてもらうためにもテストコールをします。 PagerDutyではオートコールが掛かってきた際にダイヤルボタン回答で、Acknowledge(対応する)や、Resolved(解決済み)にステータスを設定できるのですが、着信に出なかったり応答してもステータスを回答しなければ、次の受電者へ通知がされます。 テストコールを実施してエスカレーションルールどおりになっていることを確認できれば、全ての設定が完了です。

お疲れ様でした。

終わりに

今回の仕組みの導入により、運用の負荷を上げずに担当部署に緊急連絡することができるようになりました。 導入しておよそ1ヶ月ですが「休日にアラートのSlack通知が発生しても気付けないかも。。」といった心配事が減り、こころなしか眠りが深くなった気がします(笑。 これからも、充実した眠りのために?自動化をすすめていきたいと思います。

この記事がどなたかの助けになれば幸いです。

子育て中の方へ: 便利な職場制度のご案内

デジタルイノベーションラボの齋藤です。

子育てをしながら働くことは大変なことです。そこで、特に育児中の方々に役立ちそうな会社の制度をいくつかご紹介します。

※以下は2023年11月時点のものになり、今後変更となる可能性があります。

  • 裁量労働制(中抜けOK)

  • フルリモート可

  • 育児時間

  • 時間単位の有給休暇

  • 企業主導型保育園事業への対応

  • 子の看護休暇(子ども1人につき年5日※上限10日:有給)

  • 積立有給休暇

  • 配偶者の出産

  • 出産祝い

  • 夜間・休日の対応

  • デジタルイノベーションラボの子育て中のメンバーの割合

裁量労働制(中抜けOK)

裁量労働制です。基本的に朝5時から夜22時の間で勤務いただくルールとしています。

フルリモート可

新型コロナウイルス感染症の流行以前から、リモート勤務を導入しています。遠隔地に移住したスタッフも在籍しています。

育児時間

1歳未満のお子様をお持ちの社員は、1日に2回、各30分以上の育児時間を取得可能です。この時間は1回30分までは通常勤務と同様に扱われます。

時間単位の有給休暇

1年について5日の範囲内で時間単位の年次有給休暇が付与されます。

企業主導型保育園事業への対応

社員が企業主導型保育園を利用したい場合、提携手続きをサポートします。

子の看護休暇(小学校入学前までの子ども1人につき年5日上限10日:有給)

法的には無給で問題ないものの、当社では有給休暇としています。

積立有給休暇

使用しきれなかった有給休暇は、病気や子どもの看護のために積み立てることができます。最大60日までです。通常の有給休暇上限40日とは別で積み立てることができます。

配偶者の出産

配偶者の出産予定日の7日前から出産日の7日後までの間に3日有給を取れます。

出産祝い

会社とレッツ中央(福利厚生)両方からそれぞれ支給があります。

夜間・休日の対応

柔軟な勤務時間を心がけている一方で、夜間や休日の緊急対応をお願いする場合があります。予期せぬトラブルを避けるため、休日の前日や夜間にシステム更新は避け、業務時間内でのバッチ処理を行う(オンラインにできるものはそうする)などの取り組みを進めています。

参考までに、2023年1月1日から2023年11月10日までの夜間・休日対応の実績は以下になります。

障害対応:2件

深夜メンテナンス:2件

デジタルイノベーションラボの子育て中のメンバーの割合

デジタルイノベーションラボの2023年11月時点の子育て中のメンバーの割合は約37%になります。

スクラムマスター研修を受講してきました

デジタルイノベーションラボPayチームのゴルゴ&鳥海です。 先日、スクラムマスター研修を受講してきたので、その感想をお届けします。

受講の背景ですが、私達は3年前からスクラム開発を導入していて複数の開発チームが有ります(Payチームもその一つ)が、専任のスクラムマスターはいません。そこでプロダクトオーナーからの提案で、スクラム開発への理解を深めるためにスクラムマスター研修を受講することにしました。

https://www.jp.agilergo.com/online-csm-coplien-202303

研修は4日間で、講師のJames.O.Coplien氏はデンマークからのリモート授業。同時通訳で理解できるか多少心配だったのですが、実際受けてみたところ、あまり問題はありませんでした。 講義の内容はスクラムガイドの細かい解説や、スクラム開発に必要な心構えなどが中心で、時折演習も交えて行われました。以下が印象に残った点のメモです。

  • コミットメントの意味 - 約束や確約と捉えられがちだが、チームがゴール達成に向けて最善を尽くすという気構え。想定と異なり満たせないことは当然ある。その場合は検査と適応で学習していく必要がある。

  • 適切なリファインメントの量 - 2〜3スプリント分がすぐに取り組める状態にまでリファインメントが終わっていると良い。先のタスクをあまり詳細に詰めても無駄になる。リファインメントが不足していると、予想より早く計画したタスクを終えた場合に、次に取り掛かる作業が不足して無駄になる。

  • PBIのタスク化は必要な無駄 - PBIのタスク化は必要だが無駄な作業。短時間で終わらせて実際の開発を行う時間を確保することが重要。
  • デイリースクラム - 目的は課題の見える化。課題について話し込まずに短時間で終わらせる。課題への対応は別途時間をとって行う。
  • スクラム的に正しいかを問うスクラム警察は必要無い」。現場の状況に応じて改善を続けていくことが大切。
  • スクラムマスターに適した人 - よく話を聞く人、信頼関係を作る、円滑なコミュニケーションを確立する、対立が発生した場合は仲介をする、タフになる必要がある。オープンになる必要がある。オープンというのは正直ということでもある。
  • ベロシティ - ベロシティを高めることに意味はない、あくまで指標と考えたほうが良い。ベロシティを調整する、というのはよくない考え方。ベロシティは計測するのみ。フィーチャー工場にならないように!それよりも何が価値のあることなのかを分かっていることが重要。
  • スプリントゴール - スプリントゴールは一つに絞るほうが、チーム全体としてのまとまりが出る。私たちのゴールは何だろうか、ということをもっとみんなで言語化してみるとよいかもしれない。
  • スクラムチームの信頼 - スクラムチームは日頃スプリントゴールを満たしていくことでステークホルダーからの信頼を積み重ねていく必要がある。この信頼は超大事。

全般的に、従来からの理解とは大きなズレはなかったものの、普段スクラム開発に取り組む中でぼんやりと疑問に感じていた点がいろいろ腹落ちし、得るものが多かった研修でした。今後自信を持って開発に取り組んでいけそうです。

また、研修の仕上げとして後日スクラムマスター認定試験を受験する必要があります。合格率はかなり高いようなので逆にそれがプレッシャーですが、しっかりと研修内容を復習して臨みたいと思います。

以上、スクラムマスター研修の感想でした。今後もよりよい開発を行えるよう、日々改善を重ねていきたいと思います。

Four Keysの取得をはじめました

少し前からFour Keysの取得をはじめました。今回はそれについて書きます。

背景

Four KeysとはLeanとDevOpsの科学でも紹介されていますが、GoogleのDevOps Research and Assessment (DORA) チームが確立したソフトウェア開発チームのパフォーマンスを示す指標です。

https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance?hl=ja

クオカードでも開発生産性の向上は一つの重要なテーマですが、現状を定量的に把握しないことには改善しているのかどうかの判断ができないため、Four Keysを取得する事にしました。実はかなり以前から取得しないといけないという意識はあったのですが、手が回っておらずこのタイミングになってしまったという状況です。

今回の対応

計測にはSwarmiaというツールを利用しています。 結果は各チーム単位にSwarmiaの管理画面で各指標の値を確認し、スプレッドシートに書き込むという運用をしています。 可視化はダッシュボード化も検討しましたが、他に優先度が高いバックログがあるため、まずは大きな工数を掛けずに始めることにしました。

実際の計測について

4つの指標のうち、変更のリードタイム とその他(デプロイの頻度、変更障害率、サービス復元時間)でSwarmia上での確認方法や必要な設定が異なったので、それぞれどのようにして確認できるようにしたか記載します。

変更のリードタイム

変更のリードタイムは、SwarmiaとGithub Organizationを連携させることで、Githubに作成してあるチーム単位での指標が表示されるようになりました。

デプロイの頻度、変更障害率、サービス復元時間

こちらの指標を確認するには、まずはSwarmiaが用意しているDeployments APIを通してデプロイ情報を送る必要があります。 https://help.swarmia.com/sending-deployment-information-to-swarmia

Github Actionsでデプロイ情報を送信

開発チームのリリース作業では主にGithub Actionsのワークフローを使ってデプロイしているので、デプロイに成功したあとに上記APIを呼び出すステップを追加することで、Swarmiaにデプロイ情報を送るようにしました。 中には、1つのワークフロー内でFrontend/Backend等、複数のアプリをデプロイするケースもあるのですが、そういったケースでは全てのデプロイが成功した場合のみ送るようにしました。

一部情報は手動で設定

ここまででデプロイ頻度がわかるようになりますが、変更障害率、失敗率を算出するには、さらに追加の情報も必要です。 何らかの意図通り動かない失敗デプロイがあったとして、その修正のためにデプロイを行った場合には、どのデプロイに対する修正であるかわかるようバージョン番号を指定する必要があります。

この指定は、APIでデプロイ情報を送る際にオプションパラメータ(fixesVersion)で指定もできるのですが、修正バージョンは人が指定する必要があることから、ワークフローの入力パラメータを増やしたり、ワークフローを起動するSlackBotに手を加えたりと工数がかかってしまいます。

そこで他の方法がないか調べたところ、通常のデプロイとして送った情報に対し、あとからSwarmiaの管理画面上でfixesVersionを指定できることがわかったので、修正デプロイを行った場合には手動で設定するような運用手順としました。

連携した結果

これらの対応を行うことで、 デプロイの頻度、変更障害率、サービス復元時間 の指標についても確認できるようになりました。

現状

現在の各指標の値ですが、変更障害率はHigh(変更失敗が少ない),その他はMediumが多いという状況です。何を改善すれば良いか明らかになった為、顧客に価値を提供しつつそれぞれの値を改善していきたいと思います。

Kibanaでユーザ単位の権限管理をできるようにしました

デジタルイノベーションラボのIです。 QUOカードPayのElasticsearch/Kibana環境でユーザ単位の権限管理をできるようにした件について書こうと思います。

背景

AWSのALBのログをElasticsearchに取り込み、Kibanaで可視化しています。

マネージドサービスであるOpenSearch Serviceを使用しているのですが、VPC外部からアクセスするためにnginxをプロキシとしてKibanaにアクセスしています。そのプロキシECSのALBリスナーにおいてCognito認証を組み込んでいました。下記のような構成です。

今回、あるユーザにおいて特定のフィールドを閲覧できないようにしたいという要求が出ました。

何か方法はないか探したところ、OpenSearch Serviceにおいて「きめ細かなアクセスコントロール」を有効化しCognito認証を行い、ユーザごとに別のIAM Roleを割り当てることで実現できそうでした。

記事①

記事②

基本的にはこの2つの記事の通りに作業を実施したのですが、いくつか考慮すべき点があったのでそのあたりを中心に書きます。

変更点

プロキシのHTTPS化

OpenSearch Serviceできめ細かなアクセスコントロールを有効化する際はトラフィックHTTPS化が必須です。

既存構成ではALBより先ではHTTP(80)で通信していたので、ここをHTTPS(443)化する必要がありました。

記事①を参考にしたのですが、この記事においてはnginxをEC2でホストしています。プロキシのためだけにEC2を運用したくはないので、既存構成と同様にECS(Fargate)+ALBを使うことにしました。つまり下記のような構成です。

nginx公式のDocker imageをベースとし、nginx confファイル差し替えとSSL証明書の設置を行ったimageを作成しました。

confファイルは以下です。基本的には記事①に記載されているとおりですが、2つ差異があります。

まず、Elasticsearch バージョン7.10 を使用しているため、_dashboards ではなく _plugin/kibana エンドポイントを指定しています。

また、nginx 1.15.0 以降ではsslディレクティブはdeprecatedとなっているため削除し、listenディレクティブにsslを追加しています。

server {
    listen 443 ssl;
    server_name $host;
    rewrite ^/$ https://$host/_plugin/kibana redirect;

    ssl_certificate           /etc/nginx/conf.d/ssl/cert.crt;
    ssl_certificate_key       /etc/nginx/conf.d/ssl/cert.key;

    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    location /_plugin/kibana {
        # Forward requests to Dashboards
        proxy_pass https://${PROXY_PASS}/_plugin/kibana;

        # Handle redirects to Cognito
        proxy_redirect https://${COGNITO_DOMAIN} https://$host;

        # Update cookie domain and path
        proxy_cookie_domain ${PROXY_PASS} $host;
        proxy_cookie_path ~*^/$ /_plugin/kibana/;

        # Response buffer settings
        proxy_buffer_size 128k;
        proxy_buffers 4 256k;
        proxy_busy_buffers_size 256k;
    }

    location ~ \/(log|sign|fav|forgot|change|saml|oauth2) {
        # Forward requests to Cognito
        proxy_pass https://${COGNITO_DOMAIN};

        # Handle redirects to Dashboards
        proxy_redirect https://${PROXY_PASS} https://$host;

        # Handle redirects to Cognito
        proxy_redirect https://${COGNITO_DOMAIN} https://$host;


        # Update cookie domain
        proxy_cookie_domain ${COGNITO_DOMAIN} $host;
    }
}

既存構成ではALBリスナーにおいてCognito認証を設定していましたが、OpenSearch Serviceで設定するため削除しました。

また前述のnginx設定だとKibanaへ302リダイレクトされるため、ターゲットグループのヘルスチェックのSuccess codesには302を設定しました。プロトコルHTTPSです。

特定フィールドのマスク

記事②の手順24~31にあたる、IAMLimitedUserRoleを割り当てたCognitoユーザーグループ: limited-user-group のKibana操作権限設定の部分です。

今回は読み取り権限のみかつ、request_uri, request_uri_path, request_uri_query, redirect_url というフィールドを閲覧できないようにしたかったので、インデックス許可を以下の様に設定しました。

これにより、limited-user-groupに所属したユーザにおいては、このフィールドのデータが以下のようにマスクされます。

終わりに

繰り返しになりますが、概ねAWS公式ドキュメント通りに進めてやりたいことが実現できました。

そもそもOpenSearch Service側ではなくALBでCognito認証をするというやや邪道な構成だったので、この機会によりよい構成に変更できてよかったです。