2020-11-16

ドラッカー風エクササイズ

Agile

はじめに
ドラッカー風エクササイズとは
ペパボエディション
おわりに
参考

はじめに

新しいチームに加入して数ヶ月経ちました。
なんとなくメンバーにも慣れて、開発の進め方も分かってきました。
ここいらでもうひと押しチームビルディングを推し進めるために「ドラッカー風エクササイズ」を実践してみましたのでまとめておきます。

ドラッカー風エクササイズとは

ドラッカー風エクササイズとは書籍「アジャイルサムライ」で紹介されているチームビルディングの手法です。

チームメンバーがお互いに自分の考え方などを開示し、お互いの期待値をすり合わせます。
「普段こういう事しているけど、実はこんなことに興味のある人だったんだ」という気付きを得ることでチームがより円滑に作業を進める効果が期待できます。

考え方を共有する似たプラクティスとして Moving Motivators がありますね。

やり方

メンバー全員が次の４つの質問に回答します。
- なかなか一つに絞るのは難しいと思うので Top 3 くらい挙げると良いでしょう。
- 他の人の回答に影響されないよう個別に回答してもらうと良いでしょう。
回答を全員で共有します。
- 質問ごとに全員の回答を眺めていきます。
- お互いの気付きを語り合いましょう。

所要時間

７名チームに対し、以下のタイムテーブルで実施しました。
１時間で十分な成果が得られます。

趣旨説明 : 5分
質問への回答：15分
回答共有：40分

４つの質問

1. 自分は何が得意なのか？(What am I good at ?)

自分の得意をメンバーに知ってもらい、自分を有効活用してもらいましょう。
また、自分の得意を認識する機会にもなります。

回答例
- 聞き上手
- 人当たりがいい
- すぐ終わらす
- 責任感が強い
- 細部にこだわる
- 混乱した状況を打破する
- 改善行動
- アイデアを出す
- 何でもチャレンジする
- 寛容
- etc.

2. 自分はどういう風に仕事するか？(How do I perform ?)

自分がどういう働き方をすると最も成果が出やすいかをメンバーに知ってもらいましょう。
明確なゴールがある方が動きやすいのか / ゴール策定から携わりたいのか。チーム作業がいいのか / 個人作業がいいのか。傾向によってチーム内のアプローチを変えましょう。

回答例
- 朝型です
- タスクリストを作ります
- 無駄がきらい
- ミニマリストです
- 細かく管理されるのは嫌いです
- 社内政治は嫌いです
- チームで仕事したい
- ゴールが見えていると動きやすい
- 感謝があると嬉しい
- 自由に動きたい
- 褒められると嬉しい
- 同じ作業の繰り返しがきらい
- etc.

3. 自分が大切に思う価値は何か？(What do I value ?)

自分が何を重視するかをメンバーに知ってもらいましょう。それによってメンバーはあなたから何が得られるのか、あなたがどういう行動をする傾向にあるのかを推測できるようになります。

お互いに違う価値観を持っていることを認識することは、不要なトラブルを回避し、チームビルディングをより円滑に進めることにも繋がります。

回答例
- 誠実であること
- 質の良い仕事をすること
- 楽しむこと
- 他者への尊敬
- 継続的な改善
- お互いに信頼できること
- 全員が楽しくできること
- 一貫性があること
- 面白いかどうか
- チャレンジングかどうか
- 自分のためになるか
- コードの綺麗さ
- コードの実行速度
- ドキュメントを重視
- コミュニケーションを重視する
- 家族と過ごす時間
- 自分の技量を上げること

4. わたしにはどんな貢献を期待されていると思うか？
(What contribution can be expected from me on this project ?)

自分に何を求められていると思うか。すなわち、お互いへの期待のすり合わせをしましょう。期待が可視化されていないと「XXをしてほしいのに、YYにばかり注力している」などの混乱が生じます。できるだけ早い段階でお互いの認識を確認し合いましょう。

回答例
- 高い品質のコード
- 素晴らしい UX の創出
- 魅力的なウェブサイトの作成
- 網羅的なテスト
- データ分析
- 現実的な作業計画
- リーダーとしての適切な報連相、決断
- チームビルディング
- スキルアップ
- モバイルアプリの知識や技術を共有・提供
- 開発力の向上
- 各プロジェクトのシステム的業務の改善

ペパボエディション

以上がドラッカー風エクササイズの基本的なやり方ですが、ペパボさんではこれをカスタマイズして使用されているそうです。
非常に良い手法で、わたしもチームに実践する際に取り入れさせていただきました。
ぜひ紹介させてください。

tech.pepabo.com

一方で（ドラッカー風エクササイズの）すべての質問は自分のことを書くことになっています。そのため、お互いの期待をすり合わせるためには、質問の答えをベースに話し合うことが必要です。
ペパボエディションでは、この「期待をすり合わせる」ことを第一の目的として、質問をチューニングしています。

ペパボさんではドラッカー風エクササイズを以下の３つの質問でされています。

自分は何が得意なのか？
チームメンバーは自分にどんな成果を期待していると思うか？
他のチームメンバーに期待することは何か？
- 自分以外のチームメンバー全員分を書いてもらいます。

自分を開示するオリジナルの質問２，３を省略して、代わりに質問4の「自分への貢献の期待」の逆視点である「他のメンバーへの貢献の期待」が追加されおり、「貢献の仕方の認識合わせ」により一層フォーカスしています。
人数の多いチームやお試し実践、まとまった時間を確保できない場合などに短時間で大きな効果を発揮してくれると思われます。

おわりに

チームに実践してみた反応はすこぶる好評でした。
予定通り「知らなかった一面が知れた」という声が最も多かったですが、
その対象は歳上の方やまとめ役を担っている方、若手メンバーが多かったことも印象的でした。フラットな関係を築いていたつもりでしたが、まだまだお互い遠慮していた部分があったようです。

以降チーム作業は新しく知ったお互いの一面を加味して進むように急速にシフトしています。
１時間たらずのプラクティスでここまで効果がでる点は予定外でした。
ぜひ「ドラッカー風エクササイズ」取り入れてみてください！

参考

チームメンバーの期待をあわせる「ドラッカー風エクササイズ」 | DevTab - 成長しつづけるデベロッパーのための情報タブロイド

The Drucker Exercise | The Agile Warrior

先輩に本音を言えてますか？遠慮があったら始まらない「ドラッカー風エクササイズ」で作る良いチーム | PINTO!

2020-05-10

プランニングポーカー

Agile Project Management Scrum 見積もり Planning Poker 開発

はじめに
プランニングポーカーとは
- 必要なもの
- やり方
特徴
- メリット
- デメリット
結論
おわりに

はじめに

先日参加したチームでのできごとです。
リーダーがプランニングポーカー初体験のメンバーにやり方を説明していました。
その中で以下のように指導されていました。

それぞれスキルや知識レベルがバラバラなので、このままやると見積もりが収束しない。
基準となる人を決めて「その人がやったら何日くらいの作業になる」で見積もりましょう。

むむむ？？？「その人がやったら何日くらい」！？
そのようなノウハウは聞いたことが無いです。。なんかちょっと違うような気もするが確信が持てない。。

勉強し直しました。

プランニングポーカーとは

プランニングポーカーとはチームの全員が数字が書かれたカードを使ってタスクの規模を相対的に見積もる手法です。
リーダーやベテランメンバーがひとりで出した見積もりよりも、漏れが無く、納得のできる現実的な値を出すことができます。
「ポーカー」というだけあって見積もり作業にゲーム感覚で取り組めるという利点もあります。

必要なもの

カード
0, 1/2, 1, 2, 3, 5, 8, 13, ... などの数字が書かれたカードを使います。
Mountain Goat 社のカードが有名です。Agile のイベントやスクラムの研修に参加するとたまにもらえます。
わたしの周りには自作を趣味にしている人もいます。素敵なデザインが提供されていたりもします。
https://www.surviveplus.net/ja/archives/137
見積もり対象
本稿では「ストーリー」と呼ぶことにします。
Scrum における Product Backlog Item にあたります。見積もるのに十分な情報が提供されている必要があります。

やり方

チームが全員集まります。
プランニングポーカーは議論が発生し、それなりに時間がかかります。
オープンスペースなどのワイガヤしても問題無く、時間の融通がききやすい場所をおすすめします。
メンバー全員にカードを配ります。
各自１セットが行き渡るようにカードを用意してください。
基準となるストーリーを設定します。
メンバー全員が理解できる小さなストーリーを選択し、その見積もりを「２」とします。
他のストーリーを優先度の高い順に見積っていきます。
全てのストーリーが見積もられている必要はありません。直近とりかかるものだけで十分です。
以下を繰り返します。
1. ストーリーに対し、メンバーはそれぞれが考える見積もり値のカードを「せーの」で提示します。
  - 見積もりは基準となるストーリー（見積もり：2）よりどのくらい難しいか、易しいか、複雑か、簡単かを相対値で示します。
    - この相対値をストーリーポイントと呼びます。具体的な作業時間ではない点に着目してください。
  - 見積もる際にアサインは決めません。
    「このタスクはAさんがやるからAさんが見積もればいい」にはなりません。
    全員が見積もりを提示します。
  - 見積もれない場合は「？」のカードを提示し、次のステップで見積もれない理由を解消しましょう。
    仕様なのか、完了定義なのか、おそらく何らかの情報が不足しています。
2. メンバーはそれぞれ提示した値の根拠を述べます。
  考えを共有することで認識のズレや考慮漏れ、不明点等が見つかります。
  議論や相談をしてチーム全体で問題を解決してください。
  - 一番大きい値を提示した人と一番小さい値を提示した人だけが議論する方法もよく耳にしますが、
    中間の値が同じだったり、近いからと言って認識が完璧に合っているとは限りません。
    なるべく全員で議論することをおすすめします。
  - 8以上の大きい値が提示された場合はそもそものストーリーが大きすぎる可能性が高いです。
    大きなストーリーは不確実性も高くなり、見積もりの精度は期待できません。ストーリーの分割を検討しましょう。
  ある程度議論されたら 1. に戻ります。
3. ステップ 1 と 2 を最大3回ほど繰り返し、全員が納得のできる値を見積もり値とします。
  - どうしても値が収束しない場合は「最大値」または「平均値」を採用して次に進みましょう。
    実際に開発を進めてみてから分かることがあるのも事実です。

特徴

これまで担当した多くのチームでプランニングポーカーを実施してきました。
メンバーの声とわたしの感想です。

メリット

情報が洗い出される
全員の考え、視点を通じてストーリーの漏れや不足を洗い出し、クリアにすることができます。
ストーリーを深く知ることができ、メンバーの誰が担当になっていても進めるのに必要十分な情報が得られます。
納得感のある見積もりになる
「リーダーがひとりで見積もった値で計画を立てられ、結局時間が足りずに残業する」なんてたまったものじゃありません。
全員で見積もることにより、納得のいく、見積もりおよび計画が得られます。
ストーリーを "自分ごと" として捉える
全員で見積もることで、ストーリー対チームの構図ができあがります。
メンバーそれぞれがそれぞれのタスクを消化するのではなく、チームが一丸となって開発に取り組む。チームビルディング効果を得られます。
楽しい
ひとりで不安を抱えながら見積もるよりも圧倒的に気が楽です。
見積もり値が他のメンバーと合致した場合も、一致しなかった場合も「ゲーム感」が得られ、ひとりで辛かった見積もり作業に楽しく取り組むことができます。

デメリット

時間がかかる
全員集合のうえに活発な議論をするためそれなりの工数がかかります。もちろん必要な工数です。
ですが、見積もり自体は何の成果物も産みません。ユーザーに価値を届けません。
「見積もりに時間の大半を奪われ、開発が進まない」ではナンセンスです。
Scrum では「計画会は１ヶ月スプリントで最大8時間」とされています。
Backlog Refinement などを活用し、タイムボックスに収まるよう事前の準備を頑張りましょう。

結論

今回改めて色々な書籍やドキュメントを参考にしましたが、「その人がやったら何日くらいの作業になる」という考え方には出会いませんでした。
おそらくリーダーがその時考えていた「良い方法」だったのでしょう。

個人的には、見積もりというそもそも不確実なものと向き合う作業に「その人がやったら」という視点の追加は「その人なら知っているだろう/知らないだろう」という不確実性が増すことになり、見積もりの難易度を上げることになるのではないかと思います。
スキル・知識レベルの偏りも含めて全員が自分の視点で考え、共有し、認識の一致を図るほうが健全ではないでしょうか。

おわりに

今回プランニングポーカーを勉強し直して改めて良い協調見積もり手法だと認識しました。
もし見積もりに負荷や不安を抱えていたら、ぜひプランニングポーカーを採用してみてください。
きっと改善がみえると思います。

まさかりもお待ちしております。😊

2020-05-01

LeSS (Large Scale Scrum) 入門

Agile Scrum LeSS Enterprise Scale 開発 Project Management PM

はじめに
LeSS とは
(Smaller) LeSS
LeSS Huge
おわりに
参考

はじめに

Scrum は 3 から 9 人で美しく回ると言われていますが、現実にはより多い人数のチームに所属することはザラにあります。同様に適切な人数で始めたはずの開発も発展につれ人数が増大することも度々起こります。

人数が多くて動きが鈍くなったチームは分割したくなりますが、チームはどのように分割するのが良いのでしょう？また、分割後はどのように Scrum を回せば良いのでしょう？

複数チームによる規模の大きい開発に対応する Agile の手法としては LeSS・SAFe・Disciplined Agile などが有名です。
今回は個人的に最も導入コストが低いと感じる LeSS に着目し、その概要を把握できるようフレームワークを中心にご紹介したいと思います。

LeSS とは

LeSS は Scrum の原理・原則、目的、要素、などを複数チームでの開発に取り入れた手法です。
上位概念を付け加えることで大規模開発に対応しており、開発チームの視点からは Scrum とほぼ差異が無いという特徴があります。

LeSS は 2 から 8 チームでの開発用の (Smaller) LeSS と、約 8 チーム以上での開発用の LeSS Huge という 2 つのフレームワークがあります。

(Smaller) LeSS

2 から 8 チームでの開発用のフレームワーク。

f:id:moraedon:20200501192028j:plain

Role

Product Owner
ひとり。Product Backlog Item の順序を管理する。
Team
Scrum で言うところの開発チーム。最大 8 チーム。ひとつのチームは 3 から 9 人で構成される。
Scrum Master
チーム数に応じて最大 8 人。Scrum Master はそれぞれ 1 から 3 チームを担当する。

Sprint のすすめ方

ひとつのプロダクトの開発を複数チームで進める。
Sprint は全チーム共通であり、Sprint 終了時にはリリース判断可能なインクリメントが得られる。

Artifacts

Scrum とほぼ同じ。

Product Backlog
（チームごとの）Sprint Backlog
Product Increment

Events

基本的には Scrum と同じだが、Sprint Planning 1 や Overall Backlog Refinement、Overall Retrospective などの全チームで開催するイベントが追加されている。
Product Owner はチームごとのイベントには参加しない。

なお、Scrum Master のイベント参加要否については明言されていない。

f:id:moraedon:20200501192226j:plain

Sprint Planning 1

Ready になっている PBI からどのチームがどの PBI に Sprint で取り組むか決定する。
Sprint Goal を定義する。

参加者
- Product Owner
- (Scrum Master)
- 全チームの全メンバーまたは代表者

Sprint Planning 2

チームごとに、Scrum と同様に、Sprint Planning 1 で決めた PBI を Sprint で Done にするための計画を立てる。
チームごとの Sprint Backlog が作成される。

参加者
- (Scrum Master)
- チームの全メンバー

Daily Scrum

チームごとに Scrum と同様の 3 つの質問などでチームの進捗を検査する。

参加者
- (Scrum Master)
- チームの全メンバー

Product Backlog 全体の精査を行う。
Team Product Backlog Refinement の前に実施する。

精査内容
- 各 PBI の理解を深める
- 大きな PBI の分割
- 各 PBI を着手可能にする
- （大雑把な）見積もり
- 関係性の深い PBI をグルーピングする
- どのチームがどの PBI に取組むのが良さそうか判断する
参加者
- Product Owner
- (Scrum Master)
- 全チームの全メンバーまたは代表者
- 対象となる PBI の分野の専門家

チームごとにチームが取り組む PBI の精査を行う。

精査内容
- 各 PBI の理解を深める
- 大きな PBI の分割
- 各 PBI を着手可能にする
- 見積もり
参加者
- (Scrum Master)
- チームの全メンバー

Sprint Review

スプリントのインクリメントをベースにプロダクトに関わる全員でプロダクトについて考える。
Sprint のインクリメントに対し承認をもらう場では無い。

参加者
- Product Owner
- (Scrum Master)
- 全チームの全メンバーまたは代表者

Team Retrospective

チームごとにチームの検査と次のスプリントの改善計画を考える。

参加者
- (Scrum Master)
- チームの全メンバー

Overall Retrospective

全員で組織システムやチーム間の連携などについて考える。
Team Retrospective のあとに実施する。

参加者
- Product Owner
- (Scrum Master)
- 全チームの全メンバーまたは代表者

LeSS Huge

8 より大きなチームでの開発用のフレームワーク。
Requirement Area で開発対象を分割する。
ひとつの Requirement Area に着目するとチーム目線では (Smaller) LeSS と LeSS Huge には違いが無い。

Requirement Area

プロダクトにおける顧客の懸念事項の主要な領域を分割したもの。
Requirement Area ごとにひとり Area Product Owner を立てる。
ひとつの Requirement Area には 4 から 8 チームが含まれる。

Product Owner は全ての Product Backlog Item に "Requirement Area" の Attribute をつける。
Product Backlog Item を Requirement Area でグルーピングしたものを Area Product Backlog と呼び、各 Requirement Area にとっての Product Backlog となる。