JX通信社エンジニアブログJX通信社エンジニアブログ2023-03-24チーム規模が変動するチームでスクラムマスターとしてやってきたことお久しぶりです。今回私がスクラムマスター(以下SM)として所属するチームで、SMとして、およびチームで取り組んできたことなどを共有します。他社事例なども見聞きするなかで、今まで何をやってきたのかを共有することはそれなりに誰かの役に立つことがあると思ったのでこの度まとめました。前提この手の話を見聞きする上で前提が異なっていると解釈しにくいので、私たちのチームについて説明します。チームには業務委託や副業の方、つまり週5稼動ではない人たちもいました。最大でエンジニアは10人強いました。出入りは数ヶ月単位で発生していて、最小は5人です。PBI管理にはJIRAとNotionを併用しています。1スプリントは2週間です。チームはフルリモートです。リファインメントの整理スプリント計画で時間を押してしまうことが多く、リファインメントが慢性的に足りていないようでした。リファインメントは30分x4で週に2時間の枠だったのですが、30分x8の4時間の枠にしました。スクラムガイドでは作業時間の10%以下にすることが多いとあったので、その最大まで枠を確保しました。初めはチームからも「多いのでは?」という声もあったのですが、やってみると「今までむしろリファインメントが足りていなかった」と感じる声も上がって、今までよりスプリントゴールへの自信度があがりました。毎回実施するのはなく、不要な時はスキップしたり柔軟に対応しています。詳細見積もりの分離リファインメントで、詳細が曖昧な部分、または実現方法が複数あって決めきれない場合などに話しきれないことが度々発生していました。これはストーリーポイントを見積もるタイミングがリファインメントしかないとチームで受け止めていて、なるべく正確に見積もろうという意識から発生しているようでした。そこで、詳細見積もりの時間を枠として設けました。目的は見積もったPBIおよび見積もるPBIのストーリーポイントの精度を上げることです。こちらもリファインメントと同じだけ確保していますが、リファインメントとの違いとして次の特徴があります。POは参加しなくても良いチームも必要な人のみで話すチームが不要と思ったら予定を削除できる詳細見積もりで調整ができる前提で、リファインメントでは詳細が曖昧な部分があったとしても、それによってストーリーポイントに変動が起きそうかどうかに着目してもらい以前に比べて気軽に見積もりができるようになりました。結果的にスプリント計画でやっていた内容も分離でき、スプリント計画ではプランニングに集中できるようになりました。今のチームではストーリーポイントの数字にはフィボナッチ数を採用しています。ワーキングアグリーメントとストーリーポイントの基準の定期的な見直し前提にある通り、チームの変動が度々ありました。チームへの受け入れドキュメントの一つとしてワーキングアグリーメント(以下WA)を活用しました。ストーリーポイントも、チームが異なれば基準が変わるので、どんなPBIだとストーリーポイントがどの程度になるのかを参照できるようにドキュメント化しました。それぞれクォーターごとに見直しイベントを設定し、更新しています。別途スプリントレトロスペクティブでWAに採用したいことがあったり、見直したいという声があればクォーターを待たずに更新しています。スプリントゴールに目的を添えるPOから、スプリントゴールは目指してもらってるがその背景にある目的意識が浸透しているか不安という声がありました。何のためにそのスプリントゴールを目指しているのかがぶれていると、チームで判断が必要になった時に自分たちで判断できなかったり、間違った優先度で進めてしまうことが起きてしまいます。日々何のために開発しているのかを意識してもらうために、少し冗長にはなるのですがスプリントゴールに目的も含めるようにしました。このスプリントゴールを毎日リマインドし、デイリースクラムでも確認することで同じ目的を目指している意識を高めました。この形式にするタイミングで、スプリントバックログにあるものを全部達成することが良いという考えから、スプリントゴールを達成するというタスクベースから目的ベースへと移行できました。今のチームでは全AC(スプリントバックログの全消化)にはこだわっていません。予期せぬ差し込み依頼などがあった時にも目的に沿って、後にすべきか先に対応しないといけないのかチームで判断できるようになってきています。デイリースクラムの自分事化デイリースクラムを朝会として毎日行っています。SMのためにチームが日々の進捗確認をする場になっていました。SMがいなくてもチームがやっていけるようにすることが必要なのと、目的がチーム内でスプリントゴール達成への障害に気づくことなので、朝会で確認するフォーマットを規定し、事前に自分たちで朝会前にフォーマットを埋めてもらうようにしました。それまではSMがチームの話をメモしていくスタイルで話す粒度も人それぞれだった部分があったのですが、ブレが少なくなりより目的に対して機能する朝会になりました。終わりに多様なチームがあるのでそのまま適応できることもあれば適応できないこともあると思います。いう課題があって取り組むと改善できるのかを見極めて小さく試していけると良いと思います。詳細を知りたいとかあれば話せる範囲で話せるので、Twitterでもコメントでも書いてもらえると私も嬉しいです。13:08Tweetもっと読むコメントを書く2023-03-09APIをダウンタイムなしでAWSからGCPに引越しましたこんにちは。サーバーサイドエンジニアの内山です。私が所属するNewsDigestチームでは先日、モバイルアプリ用APIをAWSからGCPにお引越しする、というプロジェクトを行いました。会社の方針としてGCP利用を推進していることや、GCP特有のマネージドサービスの活用を視野に入れ、移行を決めました。今回のAPI移行では、大きく以下2パートの作業がありました。以下の制約を設けての移行としました。APIのドメインを変更しないダウンタイムなしで行うアプリ側には手を入れず、サーバーサイドチームで日中に完結させられるように・・と言う願いを込めた作戦です。今回のメインテーマは、以下の点をケアすることです。移行後の環境で最初からSSL証明書が有効な状態にする必要がある何か問題が起こった場合に速やかに切り戻せる必要がある移行を段階的に行なえると良いこれらについて、それぞれどのように対応したかを解説していきます。Balancing(以降CLB)を最前段に置いてバックエンドサービスにルーティングするという構成となっております。CLBでは、HTTPSプロトコルのフロントエンドサービス定義を作成する際に、GCP環境に用意しておいた証明書を紐づけることで設定を行います。Balancingに紐付けられるSSL証明書は以下の二種類があります。有効な証明書がない状態でリクエストを受けるとSSLエラーが発生してしまうので、GoogleマネージドSSL証明書の有効化のために稼働中のAPIのリクエストを向けるとなると、一時的なダウンタイムを許容するかメンテナンス中に行う必要があります。セルフマネージドSSL証明書は向き先変更前に有効な証明書を得ることができますが、証明書更新の手間が永続的に発生することとなります。両者のいいところどりをしたい・・ダウンタイム許容したくないし運用もしたくない・・ということで、今回は以下の作戦を取ることにしました。セルフマネージドSSL証明書を紐付けた状態で向き先変更を行うその裏でGoogleマネージドSSL証明書を紐付けて有効化を行うGoogleマネージドSSL証明書が有効になったらセルフマネージド証明書をCLBから取り除く結論、この手順で問題なく作業が行えました。GCPコンソールを利用する場合はほとんどぽちぽちで済むのですが、セルフマネージドSSL証明書の発行は手作業なため、再度行う際の備忘を兼ねて以下に手順を記載します。Encrypt証明書のTXT検証手順を採用しました。Encrypt証明書の発行手段として、今回はCertbotを利用することとしました。詳細は省き、作成時の作業手順を紹介します。ドメイン名やメールアドレスは適宜書き換えて参考にしてください。以上の手順で得られたfullchain.pemとprivkey.pemを、GCPのセルフマネージド証明書の要素としてコンソールなりAPIなりからアップロードし、しばし待てば準備完了です。編集してドメインとCLBのIPを紐付ければローカル環境からは事前にHTTPSアクセスが有効か検証できます。トラフィックを流す前にセルフマネージド証明書が有効化され浸透していることを確認することをおすすめします。Balancingに流してあげればOKです。・・が、前述したようにドメインをそのままにすることと、段階的な移行や速やかな切り戻しを実現するため、このステップで必要となった工夫について記載していきます。説明のため移行前のドメイン周りの状況を図示しておきます。移行前は、Route53でホストしているドメインのCNAMEをCloudFrontに向け、そこからオリジンへ流すような構成を取っていました。APIのドメインを変更しないことにしたため、上図で言うところのapi.example.comの向き先がGCP世界に向いている状態がゴールと言えます。Balancingを最前段に置いています。CLBはAWSのALBやCloudFrontとは違ってドメインが振られず、ロードバランサーにIPを紐付けることで疎通させる仕組みとなっています。そのため、CLBに紐付けたIPに向けたAレコードを作成することでドメインへのトラフィックをCLBに流すことになります。利用中のドメインにはCNAMEがセットされているため追加でAレコードを設置できません。(ダウンタイムが許容できるなら、既存のCNAMEを外してバツっと差し替えても良いですが・・)ではどうするのかというと、新ドメインでAレコードを作成して、そのドメインへのルーティングとして既存ドメインにCNAMEを作成します。この構成を取ると、CNAMEでの加重ルーティングを用いることが出来るため、どのレコードに何%のトラフィックを流すか指定できます。問題なければGCP側の加重を100にして全て流す、といったコントロールが可能です。これで、課題としていた段階的な移行と速やかな切り戻しが実現できます。まとめ以上2パートの作業を組み合わせ、ダウンタイムなしで段階的にAPIのAWS->GCP切り替えを行うことができました。Balancingの後段のサービスを別のものに切り替えるイベントが発生したりと、何度か加重ルーティングに助けられたシーンがありました。ワンチャンスで祈りながら移行・・ではなく、様子を見ながらゆっくり行える作戦で作業できたことが、精神的に本当に良かったですし運用工数も小さく絞れて大満足でした。NewsDigestの根幹APIに関してはこれで移行完了となりましたが、JX通信社全体で見るとまだまだインフラでもアプリケーションでも大幅なリファクタリング・リアーキテクチャが望ましい箇所が残っています。preparetrain各コンポーネントの設定を行う各コンポーネントの接続まとめ背景こんにちは!JX通信社シニアMLエンジニアのファンヨンテです。属人化しがちなR&Dをチーム開発するため社内共通のテンプレートコードを用いて機械学習が行われています。テンプレートコードにはハイパーパラメータ管理のパッケージとして、Hydraを用いています。(GCPのマネージドMLサービス)の相性が悪い部分があり、工夫なしではエラーになることがあります。AIのハイパーパラメータ調整を行うための工夫とサンプルコードを紹介しました。Pipelineで動作できるようにするための方法を記載しています。サンプルコードも公開しているので、一人でも多くの人の参考になれば幸いです。プロセスによって構成されています。