自己紹介

2018年4月新卒入社、TIG所属の関です。
アジャイルソフトウェア開発をテーマに不定期で記事を書いており、今回はその第2弾です。

過去記事はこちら

• アジャイル開発を2年弱実践した開発者目線で語るアジャイルソフトウェア開発

今回は、「日常編」と題して、 アジャイルソフトウェア開発において普段行われていること をテーマにします。未経験の人が実際の開発現場をイメージできるように、私のチームでの典型的なやりとりや、具体例を厚めに取り入れました。

当社では私以外にもアジャイル開発に取り組んでいるメンバーもおり、そこで得た知見はJFPUGオープンセミナー2021 DX時代のプロジェクトのあり方で登壇しました などのアジャイルタグのついた過去記事で取り上げられております。アジャイルはチームを単位として機能し、各々のチームが置かれた状況によってアプローチも変わってくるため、見比べてみても面白いかもしれません。

前回のおさらい

前回の記事では、近年注目を浴びているアジャイルソフトウェア開発の起源と定義について触れました。ここでおさらいも兼ねて少しまとめておきます。

アジャイルソフトウェア開発とその原則によると、アジャイルソフトウェア開発とは、下記の価値観に基づくソフトウェア開発でした。

• 個人と対話
• 動くソフトウェア
• 顧客との協調
• 変化への対応

大まかに内容をまとめると、次のようになると思います。

• 顧客、開発者、ステークホルダのコミュニケーションによる信頼関係と協力関係を重んじる。
• ビジネス側と開発者からなるチームは互いを尊重し、仕事を完遂するための適切な権限与え、責任をはたす。
• 現在わかっている全ての情報を、プロセスや計画にフィードバックし続けることで、改善と変化への対応を継続的に実施する。
• 最終成果物であるソフトウェアが利用され、継続的に価値を与え続ける状態を目指し、維持する。
• 直接的に問題を解決するシンプルなプロセス、設計を良しとし、無駄は徹底的に省く。

管理や技術面だけでなく、人間的な側面にも大きな価値を置いている というのがウォータフォールを含むフェーズ型プロセスとの大きな違いとわかるでしょう。

これらの考え方について、より詳しく知りたい方はケントベックのエクストリームプログラミングが詳しいので参照してみると良いかと思います。

この記事では、アジャイルソフトウェア開発を具体的にイメージするため、普段どのように開発を進めているのかを説明しようと思います。

アジャイルソフトウェア開発の進め方の概要

この記事では、アジャイルソフトウェア開発において普段行われている活動をメインテーマとして取り上げますが、その前により大きなスパンでの流れを見てみましょう。大まかに下記の流れで進みます。

1. 「ビジネス側」と呼ばれる人たちが、 誰の、何の課題を解決するのか？ を明確化します。この際、具体的な手段は後で検討するため必要以上に踏み込まないようにします。そして、経営層含む関係者に説明した上で予算などの必要リソースを調達します。
2. 開発者を集めて、チームを結成し、1で明確化した 「誰の、何の課題を解決するのか？」 を共有します。ビジネス側の人もチームの一員です。
3. やりたいことを、 ストーリ ないし プロダクトバックログ と呼ばれる単位に分割します（以降、 プロダクトバックログ と呼ぶことにします）。
4. ビジネス的な価値に基づき、プロダクトバックログを優先度付けして、四半期等長めのスパンの計画を立てます。
5. この計画を元に、 スプリント ないし イテレーション と呼ばれる一定期間ごとに区切られた開発活動を行います（以降、 スプリント と呼ぶことにします）チームが普段行う活動はこれになります。
6. 一連の開発活動のどこかで、ソフトウェアの利用開始に必要なプロダクトバックログが揃います。これ以降の早いタイミングで利用が開始され、具体的な価値を受け取れるようになります。
7. 計画は実態に合わせて更新され、目的が達成されるか予算が尽きるまで開発を行います。

フェーズ型プロセスとの違い

ウォータフォールのようなフェーズ型プロセスとの大きな違いは次の2つです。

• 利用開始タイミング
• 作業の進め方

利用開始タイミング

最終工程の完了を持って利用を開始するフェーズ型プロセスと異なり、アジャイルは 優先度の高いものから一連の開発サイクルを回して実装を進め、可能な限り早いタイミングで利用を開始します。

「アジャイルを使うと高速な開発ができるようになる」といった言説の真の意味がこれです。
アジャイルを使うと開発のスループット（単位時間当たりの開発量）が増えるのではありません。 アジャイルでは、現実に基づくフィードバックを活用し、価値を受け取るために必要なことを継続的に捉え続けます。これにより、不要なものを作らない、不要なことをしないようにします。その結果、利用開始タイミングが早まります。

実際のところ、（利用されるかどうかは別として）単純なコード行数という意味でのスループットは、フェーズ型のプロセスの方が大きくなる可能性があります。アジャイルではチームの人数をあまり増減させないのに対して、フェーズ型のプロセスは開発フェーズに大量に人員を投下し並列で開発を進めるためです。前工程の成果物の質が高く、過不足を十分に抑えられ、最低限の利用開始に必要な機能が多い場合は、フェーズ型も有効なアプローチということです。

一方でアジャイルが重視しているのは、 利用を開始して価値を受け取るタイミングを早め、フィードバックを受け取れるようにすること です。フィードバックを活用することで、無駄な開発物を減り、コンパクトだが変化に強く価値のあるプロダクトが生まれ、その状態を維持することで継続的に価値を提供します。

作業の進め方

次の大きな違いは、フェーズが進むと前工程に戻ることはないフェーズ型に対して、アジャイルでは プロダクトバックログに必要なすべての作業がオンデマンドで継続的に行われる ということです。

具体的には、設計が挙げられるでしょう。フェーズ型における設計で重視されるのは、「開発コストを下げること」にあるでしょう。そのために、要求仕様をソフトウェアに確実に変化させるために必要な概念を洗い出し、リスクを下げ、実装者にその内容と構造を伝えるための文書を作ります。このため、仕様、設計は凍結されるべきものであり、変更は手戻りとなるため、よしとされません。「納期までに全てのフェーズを完了させること」が至上命題であるため、開発済みのコードの変更もよしとされません。

一方、アジャイルでは、 ソフトウェアを構成する要素が有益に関連した構造を生むことで、変化に強い状態が継続的に維持されていること を重要視します。このため、設計は実装の前段階だけで行われる活動ではありません。実装により分かった情報をフィードバックすることで設計を改善することもあります。最善の方法がわからない場合、いくつかのプロダクトバックログを実装し、その結果を踏まえて再検討を行い、設計に反映させていきます。

スプリントにおける活動

このセクションでは、前節に記載した流れのうち、5の「スプリント内でどのような活動を行なっているのか」を説明します。開発がどのように進んでいくのかの実際のイメージが湧くようになるはずです。

1から4のプロジェクト開始の準備については、後日取り上げたいと思います。

用語説明

特有の用語が多く出てくるために、ここで説明をしておきます。

• スプリント
  • アジャイルソフトウェア開発において進捗を測る際に用いる固定した期間のこと。
    • 1週間 or 2週間で固定することが多い。
  • この単位で成果物を届け、計画から成果物の披露、反省までのフィードバックサイクルを回す。
• プロダクトバックログ
  • プロジェクトで開発するソフトウェアを、ユーザ視点で切り分けた機能のこと。
    • 「ストーリ」「フィーチャ」と呼ばれることもある。
  • どのような背景で、誰が何をするのかがユーザ視点で書かれているのが特徴。
    • 「誰々が何々できる。その背景はxxxだからだ」といった形式の簡潔なものになる。
    • 一般的な機能一覧に記載されるような詳細な説明は必要になるまで保留されるため書かない。
  • ビジネス側はプロダクトバックログに優先度をつけて管理する。
    • 優先度の高いものから順番に実装を進め、並行着手は最低限にする。
    • 優先度は主に下記の観点で設定すると良い。
      • 価値が高いもの。
      • リスクが大きいもの。
      • 効率化が見込めるもの。
• スプリントバックログ
  • スプリント内で実施するアクションのリスト。
  • 各アクションは、半日から2日程度で実施できる単位になるまで分解する。
    • プロダクトバックログが小さい場合はそのままスプリントバックログになる。
    • そうでない場合は、プロダクトバックログを分解して複数のスプリントバックログを作る。
      • 「分割を行うこと」自体をスプリントバックログにすることもある。

スプリントの進み方

大まかな流れ

私のチームが行っている活動を例にして、大まかな流れを説明した後、個別にどんな内容が行われるのか解説します。これはあくまで例であって、各々のチームの都合により部分的に入れ替えたりしても良いと思います。スプリントは次の流れで進みます（）内は私の所属するチーム内で使っている略称です。

1. Refinement(リファインメント)
2. Planning（プランニング）
3. Daily（デイリー）× スプリントの日数
4. Review（レビュー）
5. Retrospective（レトロ）

RefinementとPlanningがスプリントの準備段階です。Refinementでは、前スプリントで明らかになった情報と現状を踏まえて、ビジネス側と開発者の認識合わせ、計画の修正、Backlogの優先度見直しと次スプリントの内容の決定をします。その後、Planningにて開発側にて、Planningで追加されたBacklogの詳細見積もりを行い、最終的な目標を決定の上、ビジネス側に報告します。

その後、日々の開発作業がスタートします。毎朝決まった時間でDailyと呼ばれる会議を開きます。ここでは、前日何をやったのか？ 困っていることはないか？ 今日何やるのか？ といった進捗の管理などを行い、日々の作業を開始します。

スプリントの終わりがReviewとRetrospectiveです。Reviewでは、そのスプリントの成果をチーム + ステークホルダに報告します。フィードバックがもらえた場合は記録し、次のRefinementでアクションを決めます。Retrospectiveは大雑把に言えば反省会です。振り返りのフレームワークなどを使い、良かったところや改善できるところをチーム全員で話し合い、次のスプリントに繋げます。

ここからは、各々の会議について詳細を見ていきます。

Refinement

目的と参加者

この会議の目的は、 現状分かっているすべての情報を計画にフィードバックして精度を上げたり、実現可能なものに改善すること です。アジャイルソフトウェア開発における計画とは、大雑把な見積もりと優先度がついたバックログのリストとそれを元に設定した対応スコープです。なので、必要なことが判明した新たなバックログを追加したり、既存のバックログの優先度を見直したりします。

会議の参加者は、「ビジネス側 + 開発者」で構成される全チームメンバーです。必要に応じて、チーム外のステークホルダを一時的に呼ぶこともあります。会議のファリシリテータはビジネス側が担当します。これは、会議の目的が、計画の管理と、プロジェクトを方向性をより現実的なものにすることというビジネス側が担当するべき、ものだからです。

アジェンダ

アジェンダは次のようなものになります。

• 前スプリントでもらったフィードバックをどのようなアクションにつなげるのか。
• ビジネス側で外部チームや組織とのやり取りで明らかになった情報の共有。
• 開発側で前スプリントで明らかになった、リスクや実施が必要なアクション、改善提案の共有。
• 上記明らかになった情報を元にして、詳細未定だったバックログに対する追加の議論。
• 計画のアップデート

双方で分かった情報をチーム全体に共有し、チーム内に存在するあらゆる知見をもって議論を進めます。 隠し事はなしです。ビジネス側は見積もりを抑えるために要件を小出しにしたりするようなことは許されず、開発側は失敗、わからないこと、進捗の遅れを隠蔽することは許されません。これらは、信頼関係の崩壊につながる邪悪で許されない行為だということをチーム全員が認識しておきましょう。不手際は双方で起こり得るため、思ったように進まず厳しい状況になることもありますが、すべてを白日の元にさらし、真実に目を向けて、チームとして解決策を模索します。

プロダクトバックログについての議論の流れ

プロダクトバックログはいくつかに分類できます。

• 完全に新規である程度の規模の開発が必要なもの。
• 既存機能の流用で実装できるもの。
• フィードバックに基づく軽微な改善。
• etc.

完全新規の場合が最も難しいため、この時の典型的な流れを具体例として見てみましょう。初期段階では次のようなやりとりがなされることが多いです。

• ビジネス側: 「このプロダクトバックログはどれくらいでできそうですか？」
• 開発側: 「完全新規なため単位が大きすぎるのと前提条件が不足しているため見積もれません。前提条件を揃えることから始めませんか？」
• ビジネス側: 「わかりました。ビジネス側からはこの辺りの情報集めて連携すれば良いですか？」
• 開発側: 「性能などの非機能の検討で必要なので、追加でxxxも調べて連携して欲しいです。後、yyyあたりの技術を使うことになりそうですが、チーム内でわかる人がいないので、調査しないとわからないです」
• ビジネス側: 「わかりました、調査用のスプリントバックログ用意します。具体的な目的と受け入れのための要件を設定しましょう」
• 開発側: 「ありがとうございます。次回、ビジネス側とこちらで分かった情報を合わせて、再度議論ですね。yyyについては、zzzのあたりを中心に調べれば良いと思います。大体aa日くらいかかるイメージですかね」
• （以下、スプリントバックログの詳細議論へ）。。。

ビジネス側も開発側も、実装に必要な情報や知見がすべて集まっていることは極めて稀といって良いです。 そのため、完全新規のプロダクトバックログの実装にあたってはこのような感じで、前提条件を出すためのスプリントバックログを設定します。この試みは、「スパイク」と呼ばれることもあります。その後の典型的な流れとしては、前提条件を元にプロダクトバックログを、1日から2日で実施可能なレベルのスプリントバックログに分解します。この分解自体が一仕事である時は、状況に応じて「分解そのもの」を目的にしたスプリントバックログを実施したりもします。スプリントバックログが出揃ったら本格的な実装開始になります。

私のチームでは次のような感じで実装を進めることが多いです。まず、初期ではハリボテレベルの実装でも良いのでとにかくデプロイ可能な状態にもっていきます。その際、インフラなどの設定も可能な限り行い、可能な限り早く統合された状態にします。そして、詳細実装は後回しにした上で骨組みとなるクラスや関数を仮実装で作成し、各々のクラスや関数がテストしやすい状態になったのを確認して、リスクの高い部分から各々テスト駆動で実装します。最後に、再度全体確認してあるべき設計になっているなら完成とします。この流れで、1日から2日で終わるようにスプリントバックログを設定するイメージです。この一連の流れがうまくいけば、その時点で最善の設計になっている最優先の機能が実装されたプロダクトが出来上がります。

統合を早め、テスト駆動で行うことにより、失敗のリスクを可能な限り前倒しにすることで、コストの削減を狙っています。

完全新規ではなく、既存の機能の流用やフィードバックを元にした改善のようなバックログはここまで大袈裟にはなりません。プロダクトの設計があるべき姿になっており、前提を覆すような内容が含まれていなければ、この手の変更は1回のスプリントでも複数実施できることも多いです。アジャイルの目標とする「変化対応力」の高いソフトウェアが構築されている場合、既存機能をうまく組み合わせるだけで価値が創出ることもあり、次第に開発が加速する感覚が得られることもあります。逆に、変更するたびにかかる時間が増えている場合は設計があるべきではないのかもしれません。時間をとって考察する時間が必要になるでしょう。

スプリントバックログの選び方

スプリントバックログはどのように選べば良い良いのでしょうか？
まずは、最優先のプロダクトバックログに紐づくもののうち、 価値に直結するもの、リスクの高い部分をより最優先に選択します。 ただし、全てをそのプロダクトバックログから選ぶのはお勧めしません。アジャイルにおける計画は「ありうる未来」にすぎず、「保証されるもの」ではありません。このため、 現実に即した計画にするためには、 ある程度のゆとりを持たせる必要があります。 ゆとりを持たせるためには、「そんなに優先度は高くないけど、確実にメリットはある」ようなアクションを入れると良いです。具体的には、開発環境の改善や、作業の自動化、スキル向上を目指す勉強会などのチームとしてのステータス向上を行う施策です。この工夫を行うことで、チームの生産性向上を行いながら、継続的にプロダクトを届ける流れが生まれます。恒常的に効果を発揮するような施策も多いので、黎明期は意図的に増やした方が良いと考えられます。20％程度はステータス向上に使えると理想的と思います。

また、アジャイルソフトウェア開発で重視される価値として、 チームの自律性 があります。その際に大切なのは、詳細やHowにばかり目を向けるのではなく、 バックログの背景、つまり「なぜそれが必要となるのか？」に目を向け続けることです。 背景や理由がわかれば、優秀なチームは自律的に方針を考案し、実施し、その結果を元にさらなる解決策を導き出すでしょう。これらは、ビジネス側が積極的に発信し、開発側はそれにしっかりと耳を傾ける必要があります。

Planning

目的と参加者

この会議の目的は、 スプリントバックログを効率的な進め方を検討しながらさらに細かいタスクに分割し、詳細見積もりを実施して、今回のスプリントの目標を設定すること です。

参加者は開発者全員で、ビジネス側の方は参加しません。これは、見積もり権限を持つのは開発者のみで、ビジネス側はその見積もりに対して口出しすることはできないためです。ビジネス側に許されているのは、提示されたコストを元に、バックログの優先度を入れ替えるか、開発者をクビにして交代するかのどちらかです。

会議の進め方

この会議の進め方は、チームが採用しているタスクの割り当て方法によって異なると思います。重要な原則は、 実際にタスクを行う人が見積もり、他の人はより効率的に進めるための進め方のアドバイスのみを行う ということです。我々のチームでは、「手空きの人が最優先のバックログの空きタスクを取る」という方式を基本方針としているため、見積もりは典型的なレベルの人が実施したケースを想定した全員の投票制で行っています。ただし、最近では利用技術が幅広くなってきた状況から、ある程度の分担が生まれているため、実際にタスクを実施する人のみ投票するといった方式も取り入れています。杓子定規に考えるのではなく、実情に合わせて原則が守られるようにするのが良いと思います。

見積もりが終わったら、ビジネス側に連絡し、OKだったらそのままスタート、ビジネス側の想定よりもコストが高い場合は優先順位入れ替えなどが発生します。この時、ビジネス側に許されるのは コストがかかる理由の説明を受けること と、 優先順位を入れ替えること のみです。 説明を受けて、作業の進め方の工夫を提案することはできますが、見積もりが高いからという理由のみで下げるように要求することはできません。

見積もり精度についての考え方

見積もりの精度ですが、チーム結成初期はハッキリ言って適当です。そもそも、見積もりが正確に機能するには次のような前提が揃う必要があります。

• プロセス、実施内容が標準化され、明確に定まっている。
• 作業者間の差異が十分に小さいか、最終的に平均値に落ち着くことが期待される程度に期間や実施数が大きい。
• 信頼可能な実データに基づいている。

これらの前提は全て満たされていません。つまり、見積もりを行ったとしてもその正確性には根拠がありません。

• プロセスは定められていますが、実施内容の詳細の決定は実施直前まで戦略的に延期されます。
• チームは少人数です。そして、開発者の能力のバラつきは極めて大きく、10倍以上差があることもザラです。
  • 開発者一人に注目しても、得意分野とそうでない分野の差は極めて大きいです。
• チーム結成時にはデータが存在しません。

これらに加えて、次の理由からも正確な見積もりはそもそも不可能です。

• 人間は（能力の低い分野において特に）自己の能力を過大評価する傾向にある。
  • ダニング=クルーガー効果としてよく知られている現象です。
  • 「できる」の基準は主観的なもので、実際に働いて成果を出すまで信用できません。
    • 「Aさんの”完全に理解した” << Bさんの”チョットデキル”」は頻繁に起きます。
    • これに伴い、想定外の教育コストが発生することがあります。
• タスクの所要時間、品質は、担当者、チームの能力に大きく左右される。
  • シニアとジュニアでは10倍以上の差があることはザラと思っておいた方が良いでしょう。
• チーム黎明期は見ず知らずのメンバーも多い。

このため、アジャイルソフトウェア開発においては、 スプリントごとに計画と実績を比較し、フィードバックを活用することで見積もり精度を向上させる アプローチをとります。計画は、「一度立てたら遵守する」という固定的なものではなく、「毎週振り返りにより改善することで実態を表すもの」へと役割を変えています。ビジネス側も開発側も、前回の予実を元に、次の計画を改善するように振る舞うようにします。

また、チーム結成初期は適当だった見積もりも、「このチームでやるとしたらこんなものかな？」という「おおよその感覚」ができてきます。そのような状態までいくと、未経験分野についても過去の流れを参考にして「だいたいこの程度の範囲に収まりそう」といった見積もりができるようになってきます。

Daily

目的と参加者

この会議の目的は、 前日までの進捗の確認と、チームの力を借りた効率化、その日の予定を立てること です。

参加者は開発者全員で、ビジネス側の方は任意で、基本的に参加しません。確実に全員集まるタイミングであるため緊急の相談などの際に参加することがあります。

他メンバーとの連携

この会議で大切なのは、 アウトプットを出すために、いかにして他メンバーの力を有効活用するか です。一部のメンバーに仕事が偏るのはダメですが、最終的にはチームとしてアウトプットを出すので、効率よく進めるために他メンバーを有効活用は推進するべきことです。

例えば、タスクを効率よく進められるように、取り組む前に、以前その機能を担当していたメンバーからインプットをもらう段取りをします。また、タスクを進めるうちに、「これ、有識者いるのでは？」や「自分の力では無理そう」といったことが起こります。そのような際には、この場で打ち上げて、他メンバーの力を借りたり、あるいは要員交代でより強力なメンバーに入ってもらったりといった対策が取られることになります。

このように、直接的な知見を求める他、参考になる情報を知っていないか、複数人いると効率化されるタスクへの応援を求める、といった工夫が実施されることもあります。

悩ましいのが、負担が偏りがちになることです。一般に、開発者のレベルは経験年数、学習速度、学習への熱意等の要因でかなりのバラつきを見せます。他メンバーのヘルプで優秀な開発者の時間が潰れると、高難易度タスクが進まなくなったり、不満が溜まったりといった弊害が発生します。そのため、効率良い学習方法をプロジェクトの資産として事前に残して自己解決できるようにしたり、直近で同様の対応を行ったメンバーが復習も兼ねて指導したり、といった工夫も必要です。

また、チーム内に必要なスキルが足りている人が圧倒的に不足していることが判明するといったトラブルも出てきます。その際には、とりあえず対処できそうなメンバーをぶつけて片付けた後、RetrospectiveやRefinementなどでその旨ビジネス側に打ち上げ、別途講義や勉強会を行ったりといった学習用のスプリントバックログを実施してチームとしてのパワーアップを狙った対策をとります。

Review

目的と参加者

この会議の目的は、 そのスプリントの成果をチーム内外に向けて発信し、フィードバックを受けること です。チーム外への発信はもちろん、チーム内で他メンバーが当たっていたスプリントバックログの成果も確認し、全員の認識の一致も確認します。

参加者は、ビジネス側含むチーム全体に加えて、チーム外ステークホルダです。

発表の形式

私のチームでは、まず最初に、ステークホルダと面識のあるビジネス側が今回のスプリントのテーマを含む軽い導入を行った後、開発者側がファシリテートする形式で進行しています。

発表の形式はチームや参加者に合わせてカスタマイズするのが良いと思います。ですが、「ソフトウェアを開発し価値を得ること」が目的なので、準備に時間をかけすぎるのは本末転倒です。できるだけ簡略に行うようにします。時間のかかるきれいな図やスライドは用意せず必要最小限の簡潔なものに留めます。説明事項を箇条書きにしたWikiを見せつつ開発物のデモを行ったり、準備が主目的のスプリントバックログの場合はその成果報告と今後の展望を共有します。開発チームが出す成果物は「動くソフトウェアとそれから得られる価値」であり、断じて「見栄えがよくかっこいい資料」ではありません。このことを参加者全員に周知し、決して忘れないようにします。

参加者からフィードバックを受けたら

この会議で得たフィードバックは ビジネス側の責任で記録、管理します。 そして、その後のRetrospectiveやPlanningで議題にあげて、次のアクションを検討します。開発側ではなく、 ビジネス側がフィードバック内容を管理するのは ビジネス側がプロジェクトの方向性に関する責任を負っている からです。フィードバックの内容によっては、コストメリットが薄すぎるなどの理由で却下することもありますが、基本的には前向きに対応する方向で進むことが多いです。

Retrospective

目的と参加者

この会議の目的は、 スプリントの進み方を振り返り、次のスプリントをより良いものにするための自主的なフィードバックをすること と、 自他の活躍について承認することで信頼関係をより確かにすること です。改善だけでなく、各人のチームへの貢献を承認し、信頼関係、協力関係をより強固なものにするというのが、一般的な反省会との違いになるかなと思います。

参加者は開発者全員で、ビジネス側の方は任意とすることが多いようです。私の所属するチームではビジネス側の方も積極的に参加してくださっています。直接対面していないステークホルダからのフィードバック共有や、翌日のRefinementの頭出しを含むコミュニケーションができるため個人的には参加していただくのは良いことだと思っています。

進め方

振り返りのフレームワークを使うと良いでしょう。よくあるのだと、Fun/Done/Learn や KPT などがあるでしょう。私の所属するチームでは、他者への承認が行いやすいため、Fun/Done/Learnを使うことが多いです。散々な結果に終わり、KPTを使うこともあります(笑)。

改善系の議題

改善系の具体的な内容だと、「一部のメンバーに負担が偏っていたり、ボトルネックになってしまっている場合に、その状況を緩和するにはどうするか考える」といったものがあります。特定のスキルがその人にしかないのであれば、「それを獲得する方法を整理し、他メンバーに習得させる」「そのメンバーは誰でもできるタスクを実行せずに他メンバーに依頼できるようにする」といった対策が取れるでしょう。

メンバーの貢献に対する承認

信頼関係、協力関係のために、まず最初にやるべきなのは、 誰かのアイデアがより良い解決策に繋がったり、予想以上の成果をあげる場面があったら、承認すること です。アイデアにより問題が驚くほど簡単に解決したり、実はそもそも問題ではないことに気づくといった場面は時折あります。仮に、他の人からすると大したことない成果であっても、その人に対する期待を上回っていたら、承認するのが良いでしょう。自分のアイデアがチームをより良い方向に導きそれが認められるというのは、大半の人にとって明確な成功体験であり、それを承認することはその人にとっても、他のメンバーにとっても良い影響を与えます。

ヘルプの可視化をしても良いでしょう。その際は、ヘルプを受けた人はヘルプしてくれた人に対して感謝の意を述べ、ヘルプした人は相手の成長に気がついた場合はそれを承認し、改善点があればフィードバックしたりします。ヘルプする側の負担はそれなりにあるため、その間はその人の進捗は止まります。ですが、このやりとりにより埋れがちな他者へのフォローは他の人にも見えるようになります。また、ヘルプされた側の基礎体力があるなら、その知見を吸収できるはずです。次回以降はその人も有識者として扱えることがチーム全体に共有されるなどの効果も見込めます。

あくまで、 良い行いを承認し信頼関係・協力関係を育むこと が目的です。チームメンバーは互いに対等であるため、忖度する必要はなく、無理やり捻りだす必要もないです。これらは信頼や協力とは対局にある態度です。

失敗の共有

その他だと、自己のやらかしや失敗を共有するというのがあります。未知の領域を扱う場合、 最初は無知やしょうもないミスが原因となり、ある程度のロスが発生するのは避けることができません。 ある程度の失敗を踏み抜いて初めて安定は得られます。このような失敗の共有は、他の人が同じミスをしないようにしたり、有識者として認識してもらうことで他チームメンバーのロスを軽減につながる可能性につながります。個人的には、単独なんでもできる人こそ、この手の共有をやるべきと考えています。他の人から見ると初めから全部できるように見える人も、単にドキュメントをしっかり読んでいるだけだったり、トライアンドエラーが凄まじく早いだけだったり、しょうもないミスで時間使ったりしているものです。単独でも成果を上げられる人は、他メンバーのフォローを行う機会も多く、一方的に持ち出しているような感覚に陥りがちです。これらの経験を共有し、他の方にもできる気にさせたり、あるいは他の方に自分も手伝えるかもと思ってもらえたりでき、他の方からも協力を得やすくなるかなと思います。

ちなみにですが、これらの失敗を共有が反省会でなされている場合、露骨に同じ失敗を繰り返している場合を除いて糾弾はしない方が良いです。糾弾された側からすると、そのようなリスクをとる意味は全くないので、同じ試みは二度と行われません。有力なメンバーの協力が得られなくなることはプロジェクトの死に直結します。

雑談

「ワクチン3発目打った、体調崩れてキツかった！ みなさんはいつ受ける？」「こんな勉強した！」みたいな本題には関係ない雑談をすることもあります。

おわりに

この記事なかなか書き終わらないなと思っていたら、原稿用紙30枚分以上の大作になっていました。ここに記載した内容は、現在も実際に活動しているアジャイルソフトウェア開発チームの日常を、そのメンバーが記載したものです。アジャイルソフトウェア開発がどのように進むのかについて、具体的なイメージを抱くには十分なボリュームになっていると思います。

この記事が、未経験の方のアジャイルソフトウェア開発の具体的イメージにつながり、誤解によるアジャイルプロジェクトの失敗を防ぎ、ひいては成功につながると嬉しいなと思います。