for Startups Tech blog

このブログのデザインを刷新しました。(2023/12/26)

モブレビューを企画してやってみた

こんにちは、フォースタートアップス株式会社のエンジニアの八巻(@hachimaki37)です。主にタレントエージェンシー支援システム(SFA/CRM)のシステム開発を担当しております。

チームの新たな取り組みとして、モブレビューを今年に入ってから実施しています。今日までに8回ほどモブレビューを開催し、徐々にチームのイベント事になってきているのではないかと感じております。

今回の記事では、モブレビューとは何かをはじめ、どんな目的で、どのようにチームで進めているのかについて紹介していきたいと思います。

前提

チーム

  • PdM: 1名
  • Engineer: 3名
  • SRE: 1名
  • Designer: 2名

計7名のチームです。小規模なチームのため、PdMが開発 Issue を取ったり、エンジニアがプロジェクトをリードしたり、SREがフロントエンドの Issue を取ったりと、ポジションはあれど横断的に開発を進めています。

Pull Request レビューからマージまでのフロー

Pull Request のレビュアーには、Designerを除くメンバー1名をランダムにアサインする形をとっています。Pull Request のレビュアーにアサインされた方は、Pull Request のレビューに責任を待ち、Approveまでを担当します。Approve後、Pull Request を Main Branch にマージします。

現状

  • 大々的にリファクタリングの時間を取ることは難しい。そのため、開発者の善意(ボーイスカウト・ルールなど)で適宜リファクタリングは実施されている
  • Main Branch へのマージスピードと品質はバランスを考慮している。つまり、場合により優先順位が入れ替わる
  • 細かな技術ナレッジの共有機会は少ない
  • 基本的に Pull Request は、レビュアーとレビューイの1対1で行われる

モブレビュー実施のきっかけ

プロダクトフェーズにもよると考えますが、プロダクト開発を行う上で、技術的負債を少なくして高品質のソフトウェアを作成および保守していくことは重要だと考えています。なぜなら、日常業務が難しすぎる場合、プロダクトのスケールやイノベーションなどは間違いなく困難になるからです。

プロダクトの将来を見据え、今よりもチームは成長し、スケール・変化へ適応し易いアプリケーションにしていけたらいいなと思っていた時にこちらの記事に出会いました。

Chatworkフロントエンドが品質を保つために行なっているモブレビューについてのお話 - Chatwork Creator's Note

こちらの記事を参考に、チームの状況を鑑みながらモブレビューを計画し実施に至りました。

概要

モブレビューとは何か

ペアプログラミングやモブプログラミングは、聞き馴染みのあるプラクティスかと思います。モブレビューでは、「1つの Pull Request をメンバー全員でレビューを行う場」と定義し進めています。

モブレビューの場では、機能に対するレビューを行うのではなく、あくまで「ソースコードに対しての疑問点や改善点」を絞り出すことに焦点を置き、Designerを除くメンバーでモブレビューを実施しています。

心得

方向性や心理的安全性を高めるため、「心がけること」を定義しています。

  • プロダクトの未来をチームで作る
  • Re.special(チームのコアバリュー:「互いのリスペクトと個々のスペシャルが、チームの価値を最大化させる」といった意味)
    • 紆余曲折があり、今のプロダクトが稼働しています。過去のスペシャリティをリスペクトしながら、人ではなくソースコードに対して言及しモブレビューを行う

目的

現在のチームの状況を鑑みて、以下目的を定義しています。

参加者

  • Designerを除くメンバー

開催

  • 隔週1H(1PR/回)
    • 初回:キックオフ
      • 目的、意義、やり方などをチームに共有しました
    • 一回目:チームにイメージを伝えるため、私が用意した Pull Request にて進めました
  • オフラインで実施
    • 極力リアルタイムでコミュニケーションを取れるようにしています

担当

  • メンバー全員に担当が回ってくるように順番を決めています
  • レビューの題材となる Pull Request の定義は、チームにレビューして欲しい・したい・した方が良い「すでに Main Branch にマージ済みの Pull Request」を対象にしています
    • すでに Main Branch にマージ済みの Pull Request であれば、自分以外の Pull Request でもOKとしています

タイムスケジュール

  • 題材となる Pull Request の共有:5分
  • Pull Request のソースコードレビュー:15~20分
  • Pull Request にレビューしたコメントを各自共有:5分
  • Issue にするか否かを議論:15~20分
  • モブレビューのふりかえり:2分
    • 次回の運営に活かすため、どうだったかをふりかえっています
  • 次回の担当者を決める

一例

モブレビューにて、ソースコードをレビューした Pull Request の一部を紹介いたします。

  • 一つ目:

  • 二つ目:

  • 三つ目:

  • 四つ目:

  • 五つ目:

  • 六つ目:

  • 七つ目:

チームの声

毎回モブレビューのふりかえりを行っています。どのようなふりかえりがあるのかを一部紹介いたします。

  • 数分間では、Pull Request をレビューし切れないので、Pull Request のソースコード量は少量の方が良さそうです
  • ソースコード量(1000行くらい)がちょうど良さそうでした
  • 変更行数やソースコード量が少なくてもちょうどいい場合がある(触れてないドメイン・技術の場合など)
  • コメント数が多すぎるとモブレビュー内で議論し切れない
  • レビューのコメントに上がった tips をぜひ残していきたい
  • Issue 化するレビューのコメントには、🚀スタンプを押しましょう
  • 直近開発している Pull Request が題材だと仕様理解にもなるのでいいなと思いました
  • Pull Request に対するレビューのコメントが少ない方が議論しやすい
  • Pull Request のレビュー時間を10分に縮めても良いかも(おかわりありで)
  • レガシーなソースコードの Pull Request をモブレビューに持ってきても良いかも
  • 時間がなくて議論できなかったレビューのコメントも話せると良い

モブレビューの別の使い方

本来の目的とは少し異なりますが、毎回のふりかえりから以下のような使い方にもモブレビューは適応できそうに思いました。

まとめ

今日までに、8回ほどモブレビューを開催してきました。全体のレビューコメント数は93件。言い換えれば、93件分の知識や観点を共有する機会をチームに作れています。またモブレビューを通して、Issue 化されたリファクタリングチケットは14件。うち9件が改修され、Main Branch にマージされています。

モブレビュー自体は、何かすぐに効果のでるプラクティスではないかと考えておりますが、保守し易いアプリケーションになっていくこと、チーム全体の技術力アップに繋がっていくことで、Jカーブのような効果が期待できるプラクティスなのではないかと感じています。

これからも意味のあるプラクティスにしていけるよう、チームで試行錯誤しながら進めていきたいと思います。

あとがき

最後に採用情報です。

当社では、更なるサービスグロースを加速させるべく、エンジニアを積極的に募集しております。ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。

採用ページはこちら。(冒頭のTwitterにDM頂いてもOKです!)

CI/CD実行時間を50%以上短縮させた話とその1年後の現状

こんにちは。社内向けプロダクト「タレントエージェンシー支援システム(SFA/CRM)」(以下、プロダクト)にてSREをしている表と申します。 入社当初にCI/CDの改善を行い、約50%の時間短縮を実現しました。 CI/CDの改善から約1年が経過したため、実行内容と1年経った現状についてお話ししたいと思います。

前置き

本筋から逸れるため詳細は割愛しますが、本プロダクトのブランチ戦略はGitHub Flowを少し緩めに採用しています。 緩めにというのはmainブランチ、featureブランチに加えて、Stagingブランチの3つのブランチを切る運用のことを指します。 弊社ではStaging環境を複数用意しており、featureブランチからstaging_環境名 のブランチ名を切りpushすることで、CI/CDが起動し指定したStaging環境にデプロイされる仕組みをとっています。

docs.github.com

改善前のCI/CDの状況

プロダクトでは、GitHubActionsを利用しております。 上記のブランチ戦略の下、CI/CDの実行トリガーは以下のように設定しています。

  • StagingブランチをPushした時
  • featureブランチをPushした時
  • mainブランチへMergeした時

StagingブランチをPushした時とmainブランチへMergeした時の実行時間を計測しました。当時の直近20回の実行時間は、以下の通りです。

StagingブランチをPushした時

平均実行時間:32分37秒

改善前_Staging_Push

mainブランチへMergeした時

平均実行時間:48分23秒

改善前_Production_Push

StagingブランチをPushした時とmainブランチへMargeした時のCI/CDの合計実行時間が最低でも1.5〜2時間かかり、一つのPRにCI/CDによる待ち時間が発生していました。

CI/CDの実行時間を短縮するために行ったこと

改善策は、Dockerfile軽量化やマルチステージBuild、キャッシュの利用やテストの分割など複数あると思いますが、以下の改善案に着手しました。

  • ワークフローの実行タイミングの見直し
  • Jobの並列実行

上記2つに着手した理由は、実行時間という観点において一番効果が高いと考えたためです。各Jobの実行に5分ほどかかっており、これらのJobの実行タイミングを整理し並列に実行することで、Jobを直列で実行するよりも待ち時間が緩和されます。 またプロダクトの成長に伴い、コンテナ数の変化や各Job自身の実行時間の増加により、パイプラインの順序や直列での起動が現状に適さなくなり、Jobの実行順序の見直しが必要な箇所や並列実行への置き換え可能な箇所が散見されました。

ワークフローの実行タイミングの見直し

ワークフローの実行タイミングの見直しについては、主にテストの実行タイミングについて検討しました。私が所属するプロダクトでは、StagingブランチをPushした時、featureブランチをPushした時、mainブランチへMergeした時、それぞれのタイミングでコードを担保するためにテストを行っておりました。

(改善前)

改善前_ワークフロー

StagingブランチをPushした時、mainブランチへMergeした時のテストは、Build/Deployのワークフローに組み込まれているため、以下のような順番で実行されておりました。

  1. テスト環境のBuildテスト実施
  2. (テストがNGの場合は、ワークフローが止まる)
  3. (Production/Staging)環境Build
  4. (Production/Staging)環境Deploy

テストを担保した環境をDeployするという観点では問題ない構成でした。しかし、CI/CDの実行時間が約30分ほど発生し、都度待ち時間が発生する影響で、開発効率が低下するという課題がありました。 (上記背景からStagingブランチをPushした時はテストをしないという選択をし、運用しておりました。。。恐ろしい。。。)

実行時間の課題を解消するため、StagingをDeployする時のワークフローからテスト処理を外出しし、Staging環境のBuild/Deployを実行するワークフローとテストのみを実行するワークフローの2つに分割しました。 具体的には、テスト実行用ワークフローの発火条件にfeatureブランチをPushした時とStagingブランチをPushした時を追加しました。

(改善後)

改善後_ワークフロー

Build/Deployとテストを別のワークフローに分けることで、並列実行が可能となったので、環境Deployのワークフロー実行時間が大幅に削減できました。(Jobの分割でも並列実行ができますが、featureブランチをPushした時のテスト処理と共通化を実現したかったため、ワークフローごと分けました)

Jobの並列実行

ワークフロー全体の見直しが完了したので、次はワークフローの中を見ていきたいと思います。 今回はmainブランチへMergeした時のBuild/Deployとテストのワークフローを例に説明します。 検討前のワークフローの中は、以下のようになっておりました。

(改善前)

改善前_Job実行順番

Build&PushのJobとDeployのJobがあり、直列で実行されています。

  • Build&PushのJobでは、下記の処理を実行しています。
    • テスト環境を作成しテストを実行
    • WebイメージのBuildとECRにPush
    • JobイメージのBuildとECRにPush
    • CronイメージのBuildとECRにPush
  • DeployのJobは、下記の処理を実行しています。

テストと各コンテナイメージの作成、Deployについては、依存関係がないにも関わらず、全て直列実行になっているため、非常に時間がかかっておりました。

(改善後)

改善後_ワークフロー

上記の図のようにBuild&Pushの処理を4つのJobに分割し、Deployの処理を3つのJobに分割させ並列で実行させることにしました。

DeployのJobに関しては、前段のJobのいずれかが失敗した状態で、DeployされないようにそれぞれのDeployJobにneedオプションを設定し、テストのJobや各イメージのBuildとPushのJobが完了しないと起動されないように設定しました。

下記needオプションの実装例です。

needオプション

上記により全てのJobが並列で起動し、大幅な時間短縮が可能となりました。

ただ、Jobの並列化を行う際に、検討すべき前提条件と弊害がありますのでご紹介します。

Jobの同時実行数の制限

GitHubのプランにて、Jobの同時実行には制限があります。並列での処理に関しては、他チーム含めてPlanの範囲内で実行できるように調整してください。

https://docs.github.com/ja/actions/learn-github-actions/usage-limits-billing-and-administration

弊社では幸い制限に該当しなかったため、今回は特段対応はしておりません。

同一の処理の記載が増える

GitHubActionsのJob1つにつきRunnerを立ち上げるため、各Job起動時にCheckout等の処理が必要になります。そのため、同一処理が増え冗長になります。

弊社では、下記を参考にして共通化を行いDRYな記載を実現しました。

  • WorkFlowの再利用

docs.github.com

  • 複合アクション(composite)

docs.github.com

改善後のCI/CDの結果

StagingブランチをPushした時

 平均実行時間:17分00秒

改善後_Staging_Push

mainブランチへMergeした時

平均実行時間:22分23秒

改善後_Production_Push

改善の結果、以下の通り最大で約54%の削減を実現できました。

・StagingブランチをPushした時

 32分37秒→17分00秒  約 48%短縮

・mainブランチへMergeした時

 48分23秒→22分23秒  約 54%短縮

1年経過しての現状

パイプライン変更後、チームで見た年間のリリース数は、前年度に比べて10%ほど向上しておりました。全てがパイプライン改善の結果ではありませんが、幾分か影響していると考えております。 また、開発速度も上がりテストケースやイメージサイズもどんどん肥大していく中で、引き続きDockerfileの軽量化やGem、Packageの整理、不要機能の削除など細々とした改善活動を行っております。その影響もあってか、CI/CDパイプラインの実行時間は1年前と比べて増加はしておらず、当時の実行時間を保てております。

現状1年前のような大きな改善は行えておりませんが、フロント分離などの抜本的なアーキテクチャの変更などをチームで議論/検討しております。

現在は同一Deployラインの中に、Vue.jsとRuby on Railsが共存しております。 フロントエンドとバックエンドを分離することで、Deployラインの分割が可能になり、CI/CDの実行時間を大幅に削減できると考えております。(フロントエンド分離実施に向けた論点は、CI/CDではなく副次的な効果にすぎませんが、分離に向けた議論に関しては当記事の内容から外れますので割愛させていただきます)

また今回挙げたCI/CDの構成では、課題点があります。テストと各イメージのBuildとPushを並列で実行しているため、4つのJobの内いずれかが失敗した場合でもECRにPushされてしまうため、下記の事象が起こる可能性があります。

  • テストが成功していないイメージがPushされる
  • 3つのイメージで世代の不整合が起きる

例えば障害が発生した場合を考えます。障害発生前のイメージをDeployする際、障害発覚までの間に4つのJobの内いずれかに失敗したパイプラインがあった場合、1世代戻すだけでは障害前のイメージをDeployできない可能性があります。

現在の運用では、イメージの戻し作業は行っていないので影響はありませんが、今後に向けて対応を検討していきたいと考えております。

まとめ

エンジニアとして、プロダクトとして、ユーザーへの価値提供速度は非常に重要な指標の一つだと考えております。 CI/CDパイプラインは価値提供速度や開発効率に直結するため、非常に重要な改善対象です。 今後も機能開発が進みCI/CDに手を加える必要が出てくると思いますが、継続して改善作業を進めていきます!

あとがき

最後に採用情報です。 当社では、まだまだ採用募集中です。ぜひ一緒に課題解決していきましょう! ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。 採用ページはこちら

アジャイルチームのコアバリュー創りを紹介!あなたの「当たり前」は誰かにとっては「有り難きもの」

こんにちは、フォースタートアップス株式会社のエンジニアの八巻(@hachimaki37)です。主にタレントエージェンシー支援システム(SFA/CRM)のシステム開発を担当し、フルスタックに開発を行なっております。

ここ最近は、エンジニアリング以外にもスクラムや開発生産性、チームビルディングといったキーワードに興味があり、試行錯誤しながらさまざまな施策を練って進めております。今回は、所属チーム(以下、チーム)のエンジニアが中心となり、チームのコアバリューを創りました。 チームのデザイナー @Minmi303 さんに作成頂きました!

背景をはじめ、なぜコアバリューなのか、どんな課題があり、どのように計画してコアバリュー創りを進めていったのかなどについて紹介していきたいと思います。

本題に入る前に少しインスピレーションを掻き立てていきます。以下、3つの画像が登場します。あなたは、これら画像を見て何を思いどのようなことを感じますか。

お付き合い頂きありがとうございます。まず最初にお伝えしたいことは、これら画像を見て一人ひとりの感じ方は違うかもしれません。その所感そのものは、一人ひとりが持つ価値観であり、十人十色で素敵なものだと考えています。

一方で、多様な価値観があることも事実です。

中国の一部の地域では、食べ残すことで「満腹・満足」を表現すると言われております。綺麗に残さず食べるのではなく、一口分程度残すことで「食べきれないほど十分に料理を提供して貰い、満足だった」という気持ちを表します。

英国では、日本円でいう1万円札のような額が大きいお札を出すと怪訝な顔をされることがあります。場合によっては、断られることもあります。

サハラ砂漠のような乾燥した地域では、雨がふれば恵みの雨。つまり、「いい天気」を指します。

極端な例かもしれませんが、我々は多種多様な価値観と共にプロダクト開発を行う必要があると考えております。

お待たせしました。それでは、本題に入ります。

目次

チーム

  • PdM: 1名
  • Engineer: 3名
  • SRE: 1名
  • Designer: 1名

計6名のチームです。小規模なチームのため、PdMが開発Issueを取ったり、エンジニアがプロジェクトをリードしたり、SREがフロントエンドのIssueを取ったりと、ポジションはあれど横断的に開発を進めています。

背景

価値観の向き先が一人ひとり異なる中、チームは力を合わせてプロダクトやプロジェクト、ビジョンに向かって突き進まなければなりません。なかなか酷じゃありませんか?

なぜなら、

  • 人によって善意、良し悪しが異なる
  • 人によって優先順位やベクトル、志が異なる
  • 尚且つ、培ってきた経験が異なる

そんな十人十色の価値観の状況下で、チームはプロダクト開発をしていかなければなりません。だいたいあるのは、全社のMission Vision Valueです。少なからず弊社はそうでした。

プロダクト開発のチームに属する者として、どんな志を持ち、どのようなふるまいを行い、日々どのような意思決定をしていけば、目指す先へ少しでも近づくことができるのだろうか。そんなことを考えながら個人ではなく、チームとしての「明確でぶれない、共通認識の価値観」を創り、皆で同じ方向に向かっていくことが必要なのではないかと考え、推進して参りました。

コアバリューとは

コアバリューと言えば、Zapposではないでしょうか。Zapposは、カスタマーサービス神対応が大きな話題を生み、他社が真似出来ないような独自の企業文化を築いていることでも良く知られています。その独自の企業文化の軸となっているのがコアバリューです。 https://www.shikumikeiei.com/zappos-shikumi1/ https://hrnote.jp/contents/b-contents-editorial-zapposkai-180227/

では、コアバリューとは一旦どういった意味を持つのでしょうか。少し調べてみました。

  • 「中核となる価値観」。人が日々生きるうえで、判断を下したり、優先順位を定めたりするうえでその「ものさし」になるものを指します。
  • 企業あるいは個人が重要視する価値観のこと。個人や組織がものごとを判断するときの「ものさし」ともいえます。
  • 企業が最も重要であると考える価値観であり、日々、社員が考え、行動するうえでの指標として定めるものです。

https://www.corevalue.or.jp/core-values https://www.kaonavi.jp/dictionary/core-value/ https://www.dyna-search.com/jp/core-values

「価値観」と「ものさし」がキーワードになりそうです。つまりは、ものごとの「価値基準」ではないかと私は解釈しました。

どんな課題がチームにあったのか

全社のValueがチームの価値基準になることがベストだとは思います。しかしながら、プロダクト開発との結び付きが難しいというのが現状でした。実際にあった一例を紹介します。

エラーハンドリングにて

クリティカルな問題に成り難い箇所を、事前にどこまで考慮しておくべきかといった議論で意見が分かれました。

  1. 必要になったら考え、実装する
  2. 想定できることを事前に考え、実装する

結論、着地は1でした。確か最終的なジャッジは、多数決だったような気がします。方法論の良否ではなく、どちらを選択するべきかを、どんな価値基準で議論されたかが重要だと考えます。

採用活動にて

エンジニアの一次面接(技術面中心)にて、以下特徴を持ったAさんとBさんが一次面接を通過。二次面接では、チームへのフィット感を見極め評価して欲しいといった要望を受けました。採用枠は1枠です。

▼Aさんの特徴

変化への適応とスキルアップが重要です! なんせこの業界は技術変化が多いので、変化に適応してスキルアップしていかなければいけません。そのためには、スキルアップのみならず、やり切る力を重要視しています。その結果、チーム活性化に繋がりますし全てを還元できるわけではないですが、技術面で貢献できるのではないかと考えます。

▼Bさんの特徴

貢献をはじめ、チームでより良いサービス価値を創出していくことが重要です! 変化多様なご時世では、サービス価値をいかに早くユーザーへお届けできるかが重要です。サービス価値を上げていくために必要なことを考え、自分自身が変化へ適応しスキルアップしていくことが重要だと考えます。

あなたはどんな価値基準で、どちらの方を選択し、どちらの方と一緒に働きたいですか。

なぜコアバリューがチームに必要なのか

上記ケースのみならず、日々決断と意思決定が必要です。

プロダクト開発を行う中で、議論や意見を交わすことは非常にポジティブだと考え、むしろ逆に議論がなかったり、トップダウンで意思決定されていく方がネガティブだと考えております。

「共通認識の価値基準」がない場合、これらケースは個人の価値基準 vs 個人の価値基準のぶつかり合いになります。一方が他方を理解すれば良いという問題でもありません。価値基準が自身の思想になるため、どちらかが納得する or どちらかが折れる or 折衷案の着地になることが多いと考えます。

実現したい何か(目的)がチームにあるならば、もっと「チームの中核となる価値基準」に沿って議論した方が、その何かの実現可能性は高くなっていくのではないでしょうか。

つまり、これら課題を解消する「チームの中核となる価値基準」こそがコアバリューです。個人の価値基準からチームの価値基準に置き換えることで、決断や意思決定、行動する際の価値基準を作ることができると考えています。

コアバリュー創りの進め方

どう計画し、どのように進めたのかについて紹介します。

まず重要だと考えたことは、トップダウンをはじめとする特定他者の意見、意思が詰まったコアバリューにしないことです。コアバリュー創りに対する一人ひとりの興味関心や当事者意識、チームで生み出す過程をどう設計するかなど、非常に悩み考えました。検討結果としては、ワークショップを中心に行い、共通言語としてすでに存在している「プロダクトビジョン(業務プロセスを、シンプルかつ安全に進められる仕組みを提供します)」を活用することを軸に、計画を進めていきました。

※キャプチャーを添付しておりますが、あくまでイメージを掴むために添付しております。

キックオフ

推進していく上で、実施の意義と動機付けが非常に重要です。この土台をしっかり構築することで、軌道修正を容易に可能とします。そのため、概要についての説明機会をはじめ、チームが持つ疑問の解消に努め慎重に事を進めました。

  • テーマ:
    • 主観からカルチャーへ。我々チームのコアバリューはこれだ!
  • When
    • 週一回1時間 × 4回(結果、10回に渡りました..)
  • Where
    • オフライン
  • Who
    • PdM, エンジニア中心
  • What
    • チームのコアバリューを定義する
  • Why
    • チームの価値最大化のため。プロダクトビジョン実現に向けて、チームの良し悪しおよび一体感、決断や意思決定における共通認識の価値基準を創り、皆で同じ方角を指せるようにする
  • How

第一回 :個人が考える価値観に向き合う会

バリューズカードを活用しながら価値観に向き合いました。

  1. あくまで個人が考える価値観についてです。具体的には、「1エンジニアとして、個人が大事にしている価値観」に向き合いました。

  2. あくまで個人が考える理想的なチーム像に対する価値観についてです。ここでは、「1エンジニアとして、どういうチームが理想的かという価値観」に向き合いました。

最終的に1と2を照らし合わせながら、「チームにとって必要な価値観」を考える個人ワークを行いました。

第二回:プロダクトの価値観に向き合う会

第一回は、あくまで個人としての価値観を考えました。少しずつ個人の価値観からの脱却を目指します。ここでも、バリューズカードを活用しながら「プロダクト自身に成り切って、プロダクト自身に必要な価値観」に向き合いました。

最終的に3枚のカードを残し、なぜそう思うのかといった具体理由を記入する個人ワークを行いました。

第三回:コアバリューの原型創り

どのような価値基準を持つことが出来れば、プロダクトビジョンを実現できるのか。プロダクトビジョン実現を軸に、第一回と第二回の価値感をマージするグループワークです。ここでの重要観点は、自分達の「想い」です。私達は人間であり、感情が入り組むチームです。自分達がやっていて「楽しいのか?ワクワクできるのか?やりたいと思えるのか?」を自問自答することが重要だと考えました。

重要な価値基準をチームに創るため、第二回で行った複数の抽象的概念をより具体的にチームで議論し、類似の概念をグルーピングしました。最終的にチームの想いが集結した3つのコアバリューの原型が創られました。

第四回〜第七回:グルーピングの抽象化と命名

第三回で、コアバリューの原型を創りました。私達は、そのグルーピングした一つひとつの概念で「何を一番に伝えたいのか」。概念をもっと抽象的に捉え、一つひとつの命名を決めるグループワークです。ここで重要なことは、参加者全員で議論し決めることです。また、プロダクトビジョン実現という観点も忘れてはいけません(私は忘れかけました)。

※第5回目で、コアバリューの立ち位置はどこか?といった質問があり、「全社のMission Vision Value > プロダクトビジョン > コアバリュー」と定義しました。

チームで一番悩み抜いたことは、グルーピングの抽象化だと思います。価値基準の違いを感じながら、一つひとつの意味を考えていくことは非常に大変でした。抽象的な概念をできる限り具体的に考え、チームの共通概念を探り見つけていきました。

第八回〜第十回:コアバリューを定義する

最後のグループワークです。一つひとつのコアバリューの意図を伝えるため、注釈を考えました。今までの議論を踏まえ、チームには事前に注釈を考えて頂きスタートしました。

ここでもさまざまな議論が繰り広げられましたが、無事にチームの意思が詰まったコアバリューが完成しました🎉

最終的にmiroは何がなんだかわからなくなりましたが、チームで歩んできた軌跡です。

やってみての感想

当初の想定よりも遥かに時間を要しました。時間はかかりましたが、純粋にチームメンバーの考える価値基準に触れることができ、新たな考えを得ることができたと思っております。

自分自身の価値基準、信念を持つことは非常に重要だと考えています。まずは自分自身の価値基準に気づくこと、多種多様な価値基準があることを知ること、そして身近なチームメンバーの価値基準を受け入れていくこと、正解不正解、甲乙ではなく、そんなチームの日々の行動の積み重ねが、良いプロダクトを創るチームになっていくのではないでしょうか。

現場の声は実際どうなのか

コアバリューを創ってから約半年間が経過します。最後にコアバリューに関する意見をチームメンバーに伺いました。生の声を紹介します。

肌感ですが、コアバリューを体現できる限界数は3〜5つぐらいと考えており、多からず少なからずを計画当初に思っておりました。ポジティブな意見もあれば、私を含めまだまだ行動とのギャップには課題がありそうです。

コアバリューがチームの価値基準になり、決断や意思決定、自らが判断し行動ができるようになれば、もっとイキイキとしたプロダクト開発ができるのではないでしょうか。

次期アクションに向かってチームで推進していきます。これからがスタートです。

あとがき

最後に採用情報です。

こんな価値基準を持ったチームで一緒に成長していきませんか。ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。

採用ページはこちら。(冒頭のTwitterにDM頂いてもOKです!)

認定スクラムマスター(CSM)研修に行ってきました!

初めまして!フォースタートアップス株式会社でエンジニアをしている平野と申します。STARTUP DBというプロダクトの開発を担当しています。

今回は2泊3日で株式会社アトラクタさんの認定スクラムマスター研修に参加させていただきましたので、その話を書きたいと思います。

イントロダクション

僕達のチームでは開発手法にスクラムを採用しています。しかし、スクラムで開発をしていくなかで「僕たちが行っているスクラムって本当にこれでいいんだっけ?」と違和感を覚えました。そこで、スクラムの本を読むなどしてスクラムの勉強を始めましたが、僕の中の違和感は消えませんでした。そんな中、認定スクラムマスター研修を見つけました。エンジニアリングマネージャーに相談したところ、会社での研修扱いにして参加してよいとのことだったので思い切って参加してきました。

スクラムとは

複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。

スクラムガイドより引用:https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

ロールや作成物、イベント等が定められていますが、あくまでフレームワークなので、中身はチーム自身で決めていくことになります。

スクラムマスターとは

スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。

スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。

クラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。

スクラムマスターは、さまざまな形でスクラムチームを⽀援する。

スクラムガイドより引用:https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

スクラムマスターはスクラムを確立し自分のチームと組織にスクラムの理論を伝え、 チームが自己組織化するように導いていく存在です。

認定スクラムマスターとは

認定スクラムマスター(CSM / Certified ScrumMaster)とはScrum Alliance®が提供する認定資格です。認定スクラムマスター資格取得の試験を受ける為には、計16時間の認定スクラムマスター研修が必須となっています。

研修の流れ

僕が参加した研修は2泊3日の合宿形式でした。僕はオフライン形式の研修を選択しましたが、オンライン形式の研修もあるようです。6名で1チームを作り、3日間そのチームで行動します。

研修は座学とワークショップで行われ、全日、両方の形式を行いますが、

  • 1日目: 座学中心
  • 2日目: ワークショップ中心
  • 3日目: 座学中心

で行われました。

16時間の研修後、講師の方が、認定資格試験受験可能な方をScrum Alliance®に登録することで試験を受ける権利を得ます。試験は後日自分のタイミングで試験を受けることになります。

研修に参加するメリット 〜オフラインの場合〜

今回の研修に参加して2つのメリットを感じました。

  1. いろいろな立場・知識の人たちと話せる
  2. 講師陣の方とたくさん話すことができる
1. いろいろな立場・知識の人たちと話せる

この研修に参加する方達の立場・知識はさまざまです。

  • すでにスクラムマスターとして働いている方
  • これからスクラムマスターになろうとしている方
  • ほぼ知識がなく、新たにアジャイル開発を導入する方

この「いろいろな立場・知識の方がオフラインで一箇所に集まる」というのが1つ目のメリットです。なぜなら、朝食や昼食、夕食の時間など研修の時間以外に他の参加者と話す機会があるからです。

参加者は全員がチームに関して何かしらの悩みを抱えているようです。その悩みを共有し対応策を話たり、研修ではこう言っていたからチームに帰ったらこれやってみようかな、みたいな話ができます。すでにスクラムマスターとして働いている方からはスクラムの知識を得たり、リアルな現場の悩みを聞けます。スクラムの知識がない方からはスクラムに関していろいろな角度の質問が飛んできます。このようにいろいろな立場の方と話せることで自分に足りないスクラムの知識を認識できました。

2. 講師陣の方とたくさん話すことができる

ワークショップや座学の時間に講師と話すことができます。それに加えて、講師の方も朝食や昼食、夕食を一緒に食べますし、夕食後の歓談の時も同じテーブルで研修に参加している方との話に混じってくれます。この、講師の方と近い距離で話すことができる、話す時間がたくさん取れるのが2つ目のメリットです。「こういう時はどうしたら良いですか?」「うちのチームは今こんな状況で…」などの相談を直接講師の方にすることができます。講師の方はアジャイル開発やスクラムに関してかなりの知識と経験を持っています。たいていの質問には答えてくれました。

自分たちのチームが抱えている悩みを伝え、講師の方の経験からどう解決したかを聞いたり、アドバイスをもらったり、意見交換、講義の内容に関して質問するなど、かなり濃密な時間を過ごせました。

研修に参加して学んだこと

ワークショップの時間がたくさん取られていて、実践形式でスクラムを学べました。あくまで研修の内容はスクラムフレームワークスクラムマスターの役割等基礎的な事だけです。ですが、今まで間違っていた僕のスクラムの概念が正しい形で自分の中に落とし込めました。例えば、僕はスプリントレビューというものを重要視していませんでしたが、スプリントレビューはユーザーにとって不必要な機能のリリースなどを防ぐという大切なイベントである事を学びました。

結論と今後

1. なぜ認定スクラムマスター研修がおすすめなのか

認定スクラムマスター研修は座学だけでなく実践形式でスクラムについて学ぶ事ができる場です。これからスクラムマスターになる方や既にスクラムマスターの方、日々チーム開発に悩んでいる方にとって間違った知識や足りない知識が何か知る事ができ、正しい知識を身につけることができます。また、認定スクラムマスター研修に参加することでいろいろな立場・知識の人たちと話せますし、講師陣の方ともたくさん話す事ができるので現場のリアルな経験を共有できます。体系的にスクラムの実践方法を学びたい方におすすめです。

2. 研修に参加して学んだこと
  • スクラムの正しい知識
    今までスクラムに関して多少知識があると思っていましたが、僕の所属する開発チームが実践していたスクラムは足りないイベントがあったりスクラムの定められたルールに則っていないことに気がつきました。

  • スクラムイベントの実践方法
    2日目のワークショップでは、スクラムのルールに則って実際にチームでスクラムを実践します。このワークショップでスクラムの実践方法がわかります。

  • スクラムのイベントを全て実施する必要がある
    現状、僕の所属する開発チームはスクラムで定められた全てのイベントを行っているわけではありません。スクラムをやるのであれば全てのイベントを取り入れられるようにスクラムマスターが動いた方がいいなと思いました。

  • それでもスクラムは難しい
    合宿に参加したからスクラムの全てを理解したわけではないです。冒頭で言っていた「行っているスクラムってこれでいいんだっけ?」という違和感は完全に消えたわけではありませんので、これから更に学習と経験を積むことが大事だと思います。

3. 認定スクラムマスター研修後に実施したこと・チャレンジしたいこと
  • 1歩下がってチームをみてみる
    今まではチームの先頭に立ち自ら引っ張り、プロセスを変えることばかりに目を向けがちでした。ですが、全体を俯瞰し小さい変化に気づく事も大事だと気づきました。例えば、チームの発言で気づかぬうちに誰か個人を攻撃していないか、ミーティングにちゃんと参加しているか(PC開いて作業してしまってる人がいたり...)こういう事に気づいてもらえるように仕向けていくのもスクラムマスターの1つの仕事です。

  • コミュニティに参加する。
    これは今、参加できるイベントやコミュニティを探しているところです。悩みを共有しお互いに助け合えるコミュニティを見つけ、そのコミュニティで他の企業の話を聞くことで知識や足りない経験を補っていけるようにしていければと思っています。

これからもチーム開発に悩み続け、できる限りの改善をおこない、高いパフォーマンスが出せるチームにみんなでしていきます!

採用

弊社ではエンジニアを募集中です!ぜひ一緒に成長していきませんか?ご興味ありましたら一度カジュアルにお話をできたらと思います。

採用ページはこちら