Whiteboards for Jiraでレトロスペクティブを改善する

デジタルソリューション開発部 アプリチームの鈴木です。
アプリチームではJCBが提供する様々なサービスの開発・運用をしています。
サービスごとにチームを分けており、私はとあるWebサービスの担当をしています。

チーム全体の開発プロセスとして、スクラム開発を採用しています。
スクラム開発には毎スプリントごとにスクラムイベントと呼ばれる作業がいくつかありますが、今回はスプリントレビュー後に行う振り返りである「レトロスペクティブ」について、当チームで行ってきた改善の内容をご紹介します。

従来の方法

チームの立ち上がったタイミングでは、KPT法をベースとしたレトロスペクティブを以下の流れで行っておりました。

  1. あらかじめ、チームメンバはConfluence(Wiki)にKeep/Problemを記載しておく
  2. 今回のスプリントのふりかえり
    • 前回のTry内容をチェック
    • 記載されているKeep/Problemを確認
    • 議論したい事項に投票
  3. Tryのディスカッション
    • 投票数の多かった事項からフリーディスカッション
    • 次スプリントで改善したい内容を洗い出す
  4. Tryの具体的なアクションを決定
    • 洗い出した内容から、次スプリントで行う内容を決定
    • メンバ内で合意

具体的にはConfluenceにこのようなフォーマットを作成していました。
(Keepを例にしていますが、Problemも同様のものを作成して共同編集していました。実際は人数が多く、ひとつひとつの記載内容も長くなっていました)

この場合では投票数が最も多いBさんの「1. ●●勉強会が大変ためになった」から議論をしていきます。

課題点

この方法でもレトロスペクティブは行えるのですが、諸々の課題があります。

読みづらい

テキストベースで記載をするため、量が増えると読みづらくなってしまいます。
もう少し整理され、可能であれば直感的に見やすくできるとスムーズにレトロスペクティブが進むのではないか、と感じており、テキストベースではなくホワイトボードのような自由度の高いフォーマットが必要な状態でした。

投票数が分散してしまう

個人ごとに行を作成し、各々がKeep/Problemをレトロスペクティブ前に挙げていきますが、記載内容が被ってしまい、同テーマにもかかわらず投票数が分散してしまいました。
これにより「合計では投票数の多いテーマなのにディスカッションされない」事象が起きていました。

とはいえ、例えば「すでに他の人が書いている場合は同テーマで書かない」といったルールを追加するのは、活発な議論を妨げてしまうため、あまり適切ではありません。

議論が空中戦になりがち

口頭ベースの会話になってしまうため、論点の認識が合わなかったり、問題点が明確でないまま解決策を議論してしまい、より有効なTryを打ち出しにくい状況でした。

Whiteboards for Jiraの導入

このような課題を抱えるなかで、汎用的なホワイトボードツールとして、弊社の開発プラットフォームにWhiteboards for Jiraを導入しました。

Whiteboards for Jiraとは、ATLASSIAN Marketplaceで配布されているJira向けのホワイトボードツールです。
ホワイトボードツールの中でも高機能なだけでなく、弊社ではJiraを使ってプロジェクト管理をしていることから、Jiraとの親和性が高いことも魅力でした。

レトロスペクティブを改善する

Whiteboards for Jiraをベースにレトロスペクティブの改善をしました。

フレームワークを作る

現在では以下のようなフレームワークをもとにKeep/Problemを書いています。

利用イメージは以下のようになります。

サンプルをもとに改善点を解説していきます。

ジャンルと重要度の追加

今までのレトロスペクティブの内容から、Keep/Problemは大まかに「開発プロセス」「技術・スキル」「その他」の3つに分類ができました。
ジャンル分けを行うことで見やすいだけではなく、現状ではどのジャンルに課題があるのか直感的に把握できます。

また、同時に横軸には重要度を追加しました。
記入した個人の感覚で重要度を設定し、付箋の位置を変えています。
これにより重要度の高いKeep/Problemに集中しやすくなりますが、同時に「重要度が低いものでも記載しても大丈夫」といった心理的な安全性を生み出す効果もあります。
(実際「その他」の重要度が低めのものは昼食や最近の話など、雑談のタネとなるような個人のつぶやきが多く、盛り上がっている印象です)

同一テーマをまとめる

コメントや同じようなテーマを記入する場合は、すでにある付箋の下に対してWhiteboards for Jiraの「line」を使って関連付けをするようにしました。
下に追加をしていくため、横軸である重要度の影響は受けません。

同一テーマをまとめた上、投票の際は親となる付箋だけに投票するルールを決めることで、課題に挙がっていた投票数の分散を防ぎました。

議論用テンプレートの作成

議論が空中戦になってしまうのを防ぐため、このようなテンプレートを作成し、投票によって決まったテーマは各記入欄を埋めていく形でTry内容を検討していきました。

まずは「何が問題なのか」を定義し、その後に現状分析を実施して対応方針と具体的な内容を検討していきます。
論点が明確になるだけではなく、適切な課題解決プロセスを経ることで、問題明確化からTry実行へのロジックに筋道が通ります。
例えば長期的なTryを実践している際は、やることだけにフォーカスしてしまい「このTryはどうしてやっているのか」「そもそもの問題点は何だったのか」となる場合もありますが、その際に見返した際にも経緯が確認しやすくなりました。

実際に発生していた内容ですが、投票によって選択したProblemの「会議の実績がJiraに入力されていないことがある」には以下のように記載しました。

この場合はシンプルな記載内容になりましたが、問題が複雑な場合は「現状分析」や「課題明確化」がもっと長くなることが多いです。

アジェンダを改善する

作成したフレームワークをもとにアジェンダを再検討しました。

  1. あらかじめ、チームメンバはWhiteboards for Jiraの該当ボードにKeep/Problemを記載し、投票を済ませておく
  2. 今回のスプリントのふりかえり
    • できたこと、できなかったことを確認
  3. Keep/Problemの確認
    • 議論が必要ないレベルのものはその場でTryに追加
    • この間に再投票したい場合は票を動かす
  4. 投票数をもとに議論内容を最大3つ決定
    • 各メンバは議論したいテーマを選ぶ
  5. テーマごとにブレイクアウトセッションを設定し議論
  6. 各ブレイクアウトセッション内で議論した内容を全体に共有
  7. Tryを整理して合意
    • 場合によっては「タスク」として付箋からJiraのバックログに直接起票

改善前では時間の許す限り、投票数の多いテーマから議論をしていましたが、最大3つに絞ることによって少人数になり議論が発散しすぎず進みやすくなりました。

また、各メンバがテーマを自分で選択することによって、興味のある事柄に関して議論ができ、改善前よりも発言がストップせずに濃密な議論が行えています。

以上、当チームで行っているWhiteboards for Jiraを利用したレトロスペクティブの改善についてのご紹介でした。
このツールをベースにさまざまな改善をしていきましたが、なによりもホワイトボードと付箋がベースになっていることから、わちゃわちゃと楽しくふりかえりができるようになったことも大きな改善点かもしれません。

Whiteboards for Jiraはレトロスペクティブだけでなく、各課題の検討やロードマップの作成などにも利用しており、我々の開発に欠かせないツールとなっています。
興味のある方はぜひ導入を検討してみてはいかがでしょうか。

最後になりますが、JCBでは我々と一緒に働きたいという人材を募集しています。
詳しい募集要項等については採用ページをご覧ください。


本文および図表中では、「™」、「®」を明記しておりません。
Jira, ConfluenceはAtlassianの登録商標または商標です。
Whiteboards for JiraはSpartez Softwareの登録商標または商標です。
記載されているロゴ、システム名、製品名は各社および商標権者の登録商標または商標です。

GCPのConfig Controllerを使ってみた

JCBデジタルソリューション開発部、アーキテクトチームの長沼です。
アーキテクトチームでは、開発しているプラットフォーム・アプリケーションの設計開発支援や新技術の先行評価といったことを行っています。

この活動の一環として、GCPプロダクトの1つであるConfig Controllerを実際に動かしてみました。
Config Controllerは、Google Cloudのドキュメントによると「AnthosリソースとGoogle Cloudリソースのプロビジョニングとオーケストレーションを行うホスト型サービスです。」とのことです。
今回は、Config Controllerの準備とこれによるGCPリソース管理の例をご紹介します。

※以下は2021年7月時点のものとなります。Config Controllerのステータスは「プレビュー」であり、仕様は今後変更される可能性があります。

TL;DR

  • Config Controllerは、Config Sync +Policy Controller +Config Connector 等が入ったGKEクラスタを提供するもの
  • Git Repository -> Config Sync -> GKE上のリソース -> Config Connector -> GCPリソースという流れにより、 Git Repository上で宣言したリソース定義とGCPの実体リソースを紐付けて管理

Confg Controllerの準備

Config Controllerの概要および設定手順は以下で公開されています。

まず設定ドキュメント「Config Controller を設定する」に従い、Config Controllerを準備します。 具体的なコマンドについては前述の設定ドキュメントを参照いただければと思いますが、大まかな流れは以下となります。

設定手順:

  1. 管理クライアントへのCLI(gcloudやkubectl)のインストール
  2. デフォルトネットワーク(VPC)の作成
  3. 関連APIの有効化
  4. Config Controllerの作成
  5. Config Controllerに管理クライアントからアクセスするためのCredentialの取得
  6. Config ControllerからGCPリソースを管理するためのIAM設定(権限付与)
  7. Git Repositoryの準備、およびConfig Controller(内で動作するConfig Sync)との紐付け

以上の設定手順を行うと、以下のようなGKEクラスタが自動的に作成されているのが確認できます。 クラスタ名はConfig Controller名称の前に「krmapihost-」というプレフィックスが付いた形となるようです。 図の例ではConfig Controllerの名称を「testctrl」とした場合の表示となります。

また、このGKEクラスタの中を覗いてみると、以下のようなnamespaceが作成されています。

このことからConfig Controllerの構成、およびConfig ControllerによるGCPリソースの管理は以下の流れになると考えられます。
以降では図に示した流れでCloud PubSubのTopicを作成する例を紹介します。

Config ControllerによるGCPリソース作成例

実際にConfig Controllerを使って、Cloud PubSubのTopicを作成してみました。
まずConfig Controllerと連携したGit Repository (今回はCloud Source Repositories)に対して以下をPushします。
設定ドキュメントの記述によるとプロジェクト内リソースの管理には「config-control」namespaceを使用とのことで、このnamespaceにリソースを作成します。

apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
   labels:
      environment: test
   name: test-topic
   namespace: config-control

するとConfig ControllerのGKEクラスタ内「config-control」namespaceに同様のリソースが作成されます。 さらにPubSubの管理Consoleを見ると、以下のように新しく「test-topic」というトピックが作成されていることが確認できました。

気づき・注意点・補足

  • 調査時点でConfig Controllerは限られたリージョン(us-central1)での提供となり、東京リージョンでは利用できませんでした。
  • 設定手順5のCredential取得において、調査環境ではgcloud alpha anthos config controller get-credentials $CONFIG_CLUSTER_NAMEによるCredential取得は実施できませんでした。
    このため代わりにgcloud container clusters get-credentials krmapihost-$CONFIG_CLUSTER_NAMEで取得しています。
  • 設定ドキュメントに記述がありますが、Config Controller削除時は、まずConfig Controllerのクラスタ内にあるリソース削除が推奨されます。
    同クラスタ内のリソース削除後にConfig Controller本体を削除しないと、Config Controller経由で作成したGCPリソースは作成されたままとなる点に注意が必要です。
    例えば、前述の作成例でkrmapihost-testctrlクラスタ上のPubSubTopicリソースを削除せずConfig Controllerを削除すると、実際に作られたPubSubのTopicは残ったままとなります。

以上、実際に触ってみたConfig Controllerの紹介でした。KubernetesのリソースでGCPリソースを管理できるのは面白いですね!

最後になりますが、JCBでは我々と一緒に働きたいという人材を募集しています。 詳しい募集要項等については採用ページをご覧下さい。


本文および図表中では、「™」、「®」を明記しておりません。
Google Cloud, GCPならびにすべてのGoogleの商標およびロゴはGoogle LLCの商標または登録商標です。
記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。

JCBが取り組むサービスプラットフォームのご紹介

初めまして、JCB デジタルソリューション開発部の平松です。

この度、弊社JCBでは「思いついたビジネスを素早く市場に提供する」ことを目指して新たにKubernetesを軸としたマイクロサービスを構築するために新規プラットフォームを開発しました。
そして、ビジネス着想からリリースまでの期間を短くするためにビジネス部門とシステム部門が一体となって開発するサービス開発組織を立ち上げました。

その組織での活動の一環として、JCB社内の取り組みを発信するためにエンジニアリングブログを開設しました。
第一弾となる今回は、プラットフォームで利用している技術を紹介いたします。

f:id:jcb-tech:20210713135210p:plain
技術スタック

サービスプラットフォーム

基本はGCPを用いています。
アプリケーション実行基盤として採用したGKEがKubernetesの運用面(バージョンアップが容易である等)での有用性が高く、その他にも魅力的なサービスが備わっていることが導入の決め手です。
中でもCloud Spannerは、99.999%の可用性を持っていたりマルチリージョンで稼働してどのリージョンにデータをInsertしても他方にも即座に反映される仕様です。
内部でも”どうなってるのか意味がわからない”と会話しているくらい素晴らしいサービスです。
ぜひ詳細な仕組みが知りたいものです。

プラットフォームの構成パターンについて説明します。
オンプレミスやインターネットといった外部との接続設定についてはCommon Services Hostの中に集約させ、各アプリケーションのHost ProjectとはVPC Peeringでつないでいます。
アプリケーションの実行環境はGKEです。
GKEのクラスタは基本的に各アプリケーションで共有し、namespaceでアプリケーションを分割します。 各アプリケーションには当然ストレージなどといった固有のサービスが必要となります。
それらを設置するためのサービスプロジェクトをアプリケーションごとに作成し、必要に応じてGKE内のnamespaceと連携して通信します。

マイクロサービス基盤

マイクロサービスには当初セルフホストでのIstioの運用を考えていましたが、Anthos Service Mesh導入の際のGKEのチャンネルの選択の幅が拡がった1ことから、マネージドIstioであるAnthos Service Meshを導入することを決定いたしました。
Anthos Service Meshによるトラフィックの可視化・負荷分散など、今後の運用に活用したいと思います。

Infrastructure as Code (IaC)

GitOpsとして、ソース管理をGitlabで行っています。

GCPのリソース作成に関しては基本的にTerraformを用います。
Kubernetesのマニフェストと合わせて、基本的には開発環境を除くQA(Quality Assurance)・ステージング・本番環境は全てIaCにて管理していきます。
ただし開発環境は開発者の自由にサービスとかを試してもらうため、IaCオンリーの制限は設けません。
本プラットフォームは裏テーマとして、DX(Developer eXperience)の向上を掲げており、品質を担保した上での最新技術の取り込みは常にウェルカムな状況です。

CICD

CIに使うのは、Gitlab CIです。
各アプリケーションは、CI Runnerによってビルド・テスト自動実行などを走らせた後に作成したコンテナをGCRに格納します。
CDに関してはOSSであるArgo CDを用います。アプリケーションによって様々な公開手法が考えられるため、今後Argo Rolloutを導入することでカナリヤリリース等にも対応可能であることから選定しました。

セキュリティ

開発したアプリケーションに関するセキュリティ対策として、パロアルトネットワーク社のPrisma Cloudを導入します。
これにより、CSPMとCWPPという2つのセキュリティ基準を満たすことができます。
また、CIの一環でPrisma Cloudによるイメージスキャンを実施することで、アプリケーションの開発段階において脆弱性チェックを効率よく実施できます。

本番運用中に発生した問題についてもPrismaを利用していれば、Incident Explorer や Forensicによってインシデント発生時のコンテナの挙動を事後調査可能と見ています。

モニタリング・APM

サービスの運用監視は、DatadogとPrometheusなどの各種OSSを利用します。
アプリケーションとプラットフォームで異なるダッシュボードを用意し、インシデント発生時の初期の切り分けが容易となるように設計いたしました。

Datadogだけだと万が一Datadogが倒れた際にサービスの不具合が検知できなくなるので、その保険としてPrometheus等のOSSを組み合わせて第2の監視基盤を構築します。

この二重の体制でサービスの運用しています。

インシデント管理

運用時のオンコール制御として、PagerDutyを導入します。
PagerDutyを使うことにより、DatadogやPrisma Cloudから出力されるインシデントを検知し、手早く管理者へ通知できます。

選定の決め手は、オンコールスケジューリングを使うことによって、当番制の通知ルールを作ることができる点です。
これに加えて、Event Interigenceアドオンを追加することでアラート抑制機能が利用可能になる点がポイントでした。
本機能により過剰に同件アラートが発生した場合にオンコール担当者が疲弊したり正常な判断ができなくなる恐れを解消できると考え、採用しました。

まとめ

今回はJCBが取り組んでいる新規プラットフォームの実行・運用環境周りを中心に説明していきました。
他にもプラットフォームチームとしては、ゼロトラストな開発環境を設計・構築していますので、そちらの話も今後は記載していきたいと思います。
もちろんアプリの話題もアプリケーション開発チームを中心に投稿を予定しています。

個人的にもまだまだGCPの設計の細かい勘所については把握し切れていないので、その辺りの情報も今後まとめていけたらと思います!

終わりに

紹介したプラットフォームについては、Google Cloudの事例として紹介されています。

今後は大きな話題から小さな話題まで、様々なテーマで投稿していこうと思っていますので、今後ともよろしくお願いします。

最後に、JCBでは我々と一緒に働きたいという人材を募集しています。詳しい募集要項等については採用ページをご覧下さい。

最後まで読んでいただき、ありがとうございました。


  1. Anthosの検討時期では、最新版がサポートしていたGKE バージョンはRegularチャンネルのみでStableが選択できない状態でしたが、解消されました。

©JCB Co., Ltd. 2021︎