こんにちは、フォースタートアップス株式会社のエンジニアの八巻（@hachimaki37）です。主にタレントエージェンシー支援システム（SFA/CRM）のシステム開発を担当し、フルスタックに開発を行なっております。
半年間に渡りチームの業務改善（以下、改善と呼ぶ）をリードして参りました。今回の記事では、具体的なHOWを中心に、どんな課題がありどのような狙いを持って改善に取り組んできたのかについて紹介します。
目次
8000文字を超える記事です。各項目で内容は完結しているため、一から熟読する必要はありません。気になる目次から飛んで拝読頂ければと思います。
以下の方々を対象としております
- 改善をはじめて行う方
- 何から手をつけていいか模索している方
- 改善のHow Toを知りたい方
- 具体的にどんな改善案があるのか知りたい方
- 改善の勘所を知りたい方
- 改善を始めた経緯・モチベーションを知りたい方
チームについて
メンバー
- PDM: 1名
- Engineer: 3名
- SRE: 1名
- Designer: 1名
計6名のチームです。小規模なチームのため、PDMが開発Issueを取ったり、エンジニアがプロジェクトリードしたり、SREがフロントエンドのIssueを取ったりと、ポジションはあれど横断的に開発を進めています。
開発スタイル
スクラムを採用しております。ただし、スクラムイベントをすべて行うのではなく、デイリースクラム、リファインメント、レトロスペクティブなど、必要なイベントをかい摘み実施しています。スプリントの期間は2週間です。
プロジェクト管理ツール
ZenHubを使用し、Issuesを管理しております。
改善に対するアンケート
半年間に渡り行ってきたチームの活動に対して、アンケートをとりました。アンケートは6項目になっています。そのうち、特に改善に対する結果がわかりやすかった3項目を紹介します。
※私を除く、5名のアンケート集計です。
アンケート結果に対する感想
今回の改善を通じて、チームが「良い方向に変化した」と感じられたメンバーが多くいたことはポジティブに捉えています。一方で、個々人について考えた際、仕組み化による負荷・新たに露見された課題など、まだまだ改善できることはあるなと思いました。
これまでに至ったストーリーを紹介します。
なぜ改善に取り組んだ？
「スプリントごとに価値のある有用なインクリメントをもっと生み出したい」と思ったためです。
チームには、EM・スクラムマスターはおらず、チーム全員で意見を出し合い、改善サイクルを回しております。価値あるインクリメントをもっと生み出していきたい、そんな想いをチームで持ちながら、現実は日々の業務に追われ、なかなか改善に手が回らないという状況でした。日々ルーティン化されたイベント、意義や目的を失ったミーティング、形骸化されたスクラムイベントなどに課題感を持ちました。
たとえば、デイリースクラム。本来の目的は、「スプリントゴール達成に向けた進捗を確認し、進捗にボトルネックがあれば、何かしらのリカバリーを図る」と認識しております。しかし、実際は「作業」をチーム内で共有するだけのイベントになっていました。
伸び代があるこの状況を改善すれば、もっと価値のあるインクリメントをチームで生み出せると思い、まずは半年間、積極的にチームの改善・チームビルディングを担い、取り組みました。
ベロシティの変化
あくまで参考値ですが、改善指標としてチームのベロシティ推移を見ていきました。
注記
ベロシティ増加を目的としておりません。図の波形は個々のスキルアップを始め、人数比や入れ替わり・CD改善なども起因していると考えるため、あくまで参考値としてご覧頂ければと思います。
結果的に、改善実施前から数ヶ月が経過した今、チームのベロシティ平均は上昇傾向になってきました。
やったこと
改善の存在意義を決める
最初に存在意義を定義します。それは、活動を進めていくにつれ、迷いや目的を見失うシーンが発生すると考えたからです。なぜ時間を割いて改善を行う必要があるのか？そのような状況下で支えになるのが、この存在意義です。物事の判断や方向性を示す羅針盤を作り、走り出しました。
アジャイル宣言の背後にある原則 では、「顧客満足を最優先し、価値のあるソフトウェアを早く・継続的に提供すること」を思想としております。これを目指していくためには、「安定的にパフォーマンスを出せるチーム構築」が重要だと考えました。そこで、これを改善の存在意義としました。
チームの課題感を探る
チームのボトルネックを探り、何を改善すれば水の流れは良くなるのかを考えました。
改善の2つのキーワード
組織改善についていろいろ調べていると、2つのキーワードに辿り着きました。1つは「自己組織化」、もう1つは「バーナード組織の3要素」です。
- 自己組織化とは
物質や個体が、系全体を俯瞰する能力を持たないのに関わらず、個々の自律的な振る舞いの結果として、秩序を持つ大きな構造を作り出す現象のことである。
つまり、変化し続ける外部環境や発生する課題に対して、組織を構成するメンバー一人ひとりが、主体的・自律的に適応することができる組織・チームを指します。
- バーナード組織の3要素
アメリカの経営学者チェスター・バーナードが提唱した、組織が成立するために必要な3つの条件のことを言い、（中略）「コミュニケーション」「貢献意欲」「共通目的」の三要素が不可欠であり、どれか一つでも欠けている場合には不完全な組織として、組織が健全に機能しなくなると定義づけました。
引用元：バーナードの組織の三要素とは？組織に必要な3つ要素を理解し導入するためのポイントを解説 | オンライン研修・人材育成 - Schoo（スクー）法人・企業向けサービス
つまり、「コミュニケーション」「協働の意欲」「共通の目標」の3つを一定水準満たした組織・チームを指します。
ご自身のチームは、どの領域にプロットされる？
これらについて、私の見解を以下にまとめました。
私の考えでは、チームが第4領域に達してから改善をスタートすべきです。自己組織化が目的ではありませんが、自己組織化されたチームでなければ改善を行ったとしても改善の効果を実感しづらいと考えます。第4領域は、主体的・自律的に適応することができる組織・チームです。第4領域にプロットされるチームの場合、改善の方向性を決め、ボトルネックを解消していくことで、大きく水の流れを改善できると考えます。
ご自身のチームがどの領域にプロットされるかにより、課題は異なり、改善内容も大きく変化します。チームの日々の振る舞いや観察、メンバーとのコミュニケーションからご自身のチームがどの領域にプロットされるかを考え、仮説を立てることがまずは重要だと考えます。
改善方針を決める
私たちのチームは、ある程度自己組織化されたチーム状態にあると考えたため、第4領域にプロットし、改善を進めていく形をとりました。改善方針としては、開発プロセスで弊害となる問題や課題を中心に「発見と解決」を繰り返すことがチームを前進させる上で最も重要だと考えました。新たに何かを取り組むよりも、まずは今行っているイベント群を徹底的に改善する方針としました。
具体的に行ったこと
※実施結果を書いておりますが、定量的に計ったものではありません。
※以下、抜粋した改善例です。これら以外にも小さな改善を含め、さまざまな改善サイクルをチームで回しております
ストーリーポイントの基準を再定義する
課題
- ポイントの基準が不明確
- ポイントの基準理解が個々人で異なっていた
影響
- ポイントが大きいストーリーを見積もるときほど個々人でポイントの基準がズレていた
打ち手
- ポイントが2, 5, 13の課題となるストーリーポイントの基準を定義した
- 結果
- 複数の基準を定義したことで、ポイントの認識齟齬が減少した。それによってリファインメントのスムーズな進行が可能となった。また、見積もり時にメンバー間でポイントに差が生まれても基準の認識について議論する時間が減り、作業内容に着目した議論がよりできるようになった
Issueのテンプレートを作成する
課題
- Issueの記述内容にばらつきがある
影響
- 私達のチームではリファインメント開催ごとに書記をランダムに決めている。これは良い点もあるが、一方でIssueの詳細や内容にばらつきが見られ、情報の過不足に繋がり、実装漏れや仕様確認が適宜発生する悪い点もある
打ち手
- 開発者が「やりたい（実現したい）こと」を理解できるよう、Issueのテンプレート化とルールを作成。「日付」「ref」「チケットの作成理由」「チケットの完了定義」など、記述内容をテンプレート化し、Issueのデフォルトに設定した
- 設定方法：リポジトリ用に Issue テンプレートを設定する - GitHub Docs
- 結果
- テンプレート化したことで、従来発生していた仕様確認や実装漏れが減少。その結果、Issueアサインから着手までの時間やコミュニケーションコスト、アウトプットの認識齟齬減少に繋がった
Velocity Trackingをチームに導入する
- 課題
- ベロシティに波がある（以下、参考データ）
影響
- スプリントゴールを安定的に達成していくことがもっとも重要であると考えている。ベロシティに波があることは一定ペースで価値を提供しきれていないということ
打ち手
- ベロシティの推移をチームで認識・理解する必要があると考え、ZenHubのVelocityTrackingをチームに導入、説明の機会を作った
- 結果
- 運用自体を再検討する運びとなり、失敗に終わる。人数比を始め、突発的なIssue対応やチームへの共有範囲、ベロシティ増加が目的ではなかったことなど、懸念点が多くペンディングとなった。当時をふりかえると、ベロシティを上げることに目が行きがちで、品質よりもリリースを先行してしまう心理状態となってしまったことが反省点。別の打ち手を現在模索中
チームメンバーの相互理解を深める機会を作る
課題
- 新規メンバーが既存メンバーへの隔たりを感じている
影響
- チームでは、新しくジョインするメンバーの自己紹介の場を作っていたが、古株になるにつれ、既存メンバーについて知る機会（誰が何をやってきて、どんなことが得意不得意で、何に興味があるのかなど）がなく、新規メンバーからすると既存メンバーへ隔たりを感じていた
打ち手
- 自己紹介の場に目的を作り、コンテンツを実施。相互理解を深める機会をチームに作った
- 結果
- 以前よりも意思疎通をストレスなくおこなえるようになった。また副次的な効果として、対話量が増加したことで、ミーティングなどで議論が活発になる機会が増加した
Issues整理とプロジェクト管理ツールの運用ルールを再定義する
※Pipelineとは
Issueの流れを表すレーンで、そのissueが完了するまでのステータスを表します。私達のチームでは、New Issues→Sprint Backlog→In Progress→Review/QA→Closedとしています。
- 課題
過去のPipelineの全体像
影響
- Pipelineの形骸化、一向にCloseされないIssuesが散乱し、無駄な確認作業が適宜発生する。Issueの優先順位や緊急度、および重要度をスクラムボードで理解することが難しく、適宜PDMに確認する必要があった
打ち手
改善後のPipelineの全体像
以下運用ルールを定義
New Issues
- 新しいIssueを配置
- 次のスプリント計画を立てるまでに、極力Issueをレビューし、優先度（Icebox, Product Backlog, Sprint Backlog）を振り分ける
- リファインメントを通じて、このパイプラインを極力空にする
Icebox
- やった方が良いが着手する優先度は低いIssueを配置
- スプリント中に想定されたIssuesが完了した場合などに着手する
Product Backlog
- 今スプリントでは対応しないが、次回以降にやるべき優先度の高いIssuesを配置
- 次のスプリント計画に使ってもOKとする
Sprint Backlog
- スプリント期間中に終わらせる優先度が高いIssuesを配置
- 次のスプリントまでに空になっていることが望ましい
In Progress
- 進行中のIssueを配置
- 必ずアサインされた担当者（このIssueを完了にする責任を負う）が設定される
Review/QA
- EngineerによるReview期間にあるIssueを配置
- 開発はすでに完了している状態とする
Design Review
- Engineer Reviewが完了し、DesignerによるReview期間にあるIssueを配置
- UI周りを中心にReviewがなされる
Closed
- PRがmain branchにMergeされたIssueを配置
- 対応不要だったIssueなどを配置
結果
ふりかえり
半年間にわたり、チームを巻き込みながら改善を進めて参りました。チームの協力がなければ進めることはできません。
また、チームの時間を使うということは、チームにとって良い影響を生み出していかなければなりません。もっとこうしたら良いのではないか？こうするべきではないか？メンバーからさまざまなアイディアを頂く中で、結局成し遂げたいことは何なのか。
それは、「安定的にパフォーマンスを出せるチーム構築」です。改善の存在意義を決めていたことで、これを達成するためには何が必要か、何を優先とすべきかが明確になったように思います。
たとえば、OpenAPIの更新負荷や使用ツール代替案の検討という提案がありましたが、改善の存在意義の『安定的にパフォーマンスを出せるチーム構築』とは違う問題だと判断し、実施を見送りました。やらないことを判断することができ、改善の本質に時間を割くことができたと考えます。
チームとしてどうあるべきか、どういうバリューを持って突き進むべきか、まだまだ改善できることはたくさんあると思います。
うまくいかないという名の成長痛を感じながら、チームでアイディアを出し合い、より良いチームへの変貌を遂げられるよう、これからも日々精進していきたいと思います。
あとがき
最後に採用情報です。
当社では、まだまだ採用募集中です。ぜひ一緒に成長していきませんか。ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。
