Viewing entries in
Agile

Scrum Interaction 2022 のスポンサーになりました

Scrum Interaction 2022 のスポンサーになりました

こんにちは。アットウェアでアジャイルコーチやスクラムマスターとして活動している梶平です。

アットウェアは、2022年9月22日(木)にオンラインで開催される Scrum Interaction 2022 にスポンサーとして協賛します。

個人的な話になりますが、前回の Scrum Interaction 2019 では、ジェフサザーランドさんと、野中郁次郎さんが同じ場所にいらっしゃるという奇跡的な場で、私自身とても興奮したことを鮮明に覚えています。

更に組織変革の事例を多く知ることができたり、参加者同士のグループディスカッションもとても楽しく、学び多き時間を過ごせました。

興奮。楽しさ。学び。

それだけではなく、場から発せられているエネルギーのようなものが自分の中に入っていくような感覚もあり、自身の日々の活動について応援されているような、ありがたい気持ちにもなれました。

今回もアジャイルの力に助けてもらいつつ、自身・チーム・組織の変革に取り組まれている事例や、その中で感じる悩み・モヤモヤを聞き、そして参加者の方々と話し合えることがとても楽しみです。

とある日のふりかえりをKPTではない手法でやりました

とある日のふりかえりをKPTではない手法でやりました

今日は、とある日に実施したレトロスペクティブ(ふりかえり)についてご紹介します。

紹介内容は、場の目的にあっていると思うアクティビティ(ふりかえりの場で用いる手法)を選択したというお話で、実施して感じたことについて触れたいと思います。

TL;DR 3行まとめ

  • フェーズやメンバーの思いに合わせてレトロスペクティブのやり方を変えて試してみたらいい感触を得られた。
  • レトロスペクティブをどんな場にしたいかという認識を合わせてから本題に入ると、どのような場にするのかという指標になり、場がイイ感じで流れるように進んだ。
  • 目的に合わせてアクティビティを選択することで、効果的にレトロスペクティブを進めることを実感できた。

レトロスペクティブ(ふりかえり)といえば

弊社でもよく使われるレトロスペクティブの手法で「KPT」がありますが、レトロスペクティブのやり方は一つではなく、レトロスペクティブの場をどういう風に過ごしたいかで、アクティビティを使い分けられるといいなと、以前から思っていました。

場に集まる人の発言は、感情・関係性・過ごした日々の行い・日々の長さといったものを抜きには語れません。

その場に各自がどう挑むか、意義を感じられるか、状況をどう理解しているかは今後の振る舞い方や日々を過ごすアクションに大きく左右するのではないでしょうか。

そこで、今回は、アジャイルレトロスペクティブという書籍で紹介されていた、目的毎に向いている手法を組み合わせてやってみました。

私たちはどんな集まりか?

その日は、社内インフラやセキュリティに関わっているメンバー4人が集まりました。 専任の前任者から4人が引き継ぎ、チームとして活動しており、ざっくりいうと職場環境の維持や改善の対応に取り組んでいます。引き継いでから1年半程度が経っており、日々のタスクやチームはうまく回っているが、少し安定しすぎているチームです。前回のふりかえりから長い日々を過ごしたので、自分たちの今後のことも考えていきたいねと事前に話していました。

私たち、チームとしては「目標」「データ取集」よりも、個々の考えを元に「今後の活動方針」を合わせていきたいという各自が関わる意義を再認識したいフェーズと捉えています。

そこで今回やったレトロスペクティブの紹介

前提事項をお伝えするのが長くなってしまいましたが、今回やったKPT以外の手法(アクティビティ)をご紹介したいと思います。

選んだアクティビティ

1つ目: 場を設定するアクティビティ 「ESVP」

まずは集まってレトロスペクティブを開始する時の準備のアクティビティです。 この種のアクティビティを実施することによって、自分たちがどう思っているのか、温度感などを知ることができます。

有名なものだと「チェックイン」あたりですね。

私たちが今回選んだのは「ESVP」です。これは長いイテレーションを過ごした時に適しており、「レトロスペクティブの作業にフォーカスできるように、みんなのレトロスペクティブに対する考えを理解する」目的として最適とのことです。 面白いのが、4つの立場に分類して自分がどう思っているのかを伝えるが、他の人には自分がどの立場かは知られないということです。

よく言われる心理的安全性を確保して、発言を促せるという工夫があることに気づきました。

4つの分類

各自のレトロスペクティブの場にいる温度感そのものです。

  • 探検家:新しいアイデアを見つけたいと熱心な人。
  • 買物客:情報を見渡してて、アイデアを知りたいという人。
  • 行楽客:レトロスペクティブの作業には関心はないが、他のことをしているより良いと思っている人。
  • 囚人:参加を強制されていると思っている人。

書いて捨てた

IMG_2377.JPG

一人が全員から集めた付箋をみて、集計し書き出しました。 付箋は破ってゴミ箱に捨てることにより、誰がどの立場かはわからないけど、どういう人がどれくらいいる事実だけはわかっています。

結果を見てみると、想像していた通りではなく、ズレすぎず、面白かったです。 この場をどうしていくかの指標になりました。

2つ目: 何をすべきか決定するアクティビティ 「質問の輪」

次のアクティビはこの場で「何をすべきか決定する」です。 今回の場では洗い出しを行うつもりはもともとなかったので、感情・想いをベースに話を進めたり、均等に考えを引き出すことに重きをおきました。

このアクティビは、「次のイテレーションにおける試みやアクションステップをチームが選びやすいようにする。特にチームメンバーがお互いの意見を聞く時に使用するとよい」そうです。

私たちにぴったりです!!

ファシリテーターをおかず、均等に発言したり声の大小にかかわらず、しゃべる・聞くということがテンポよく、うまくできるという仕組みです。

やり方は簡単 質問に答えて質問をするだけ

円になって座り、最初の回答者を決めて「次のイテレーションで取り組みたいことはなんですか?」の質問に自身の考えを述べてもらいます。 これまでのやりとりを踏まえたうえで、自身の考えを述べて、さらに次の人に質問をするという流れです。これを2周くらいすれば、質問がブラッシュアップ・深掘りされて、気づけばいい感じにアクションが具体化と合意に近づいていきます。

どうだった?

ESVPの流れから、私たちがこういう状況にあることをどう思うか?から始まり、実はお互いが状況に応じて補完しあえる関係にあって、バランスよく活動できていることを知ることができました。 話題が自然と落ち着いていき、他人の考えやスタンスを知れることによる、心のゆとりや今後も続けていくことの障害がないことがわかったのです。

長いことやっていると人の参画・移動に関する話もあがって、そこのあたりの考えも知れて良かったです。 毎回だと窮屈になってしまうかもしれないと思いましたが、たまにこういう形でやるといいですね。 非常に生産的に話が進んでいった気がしました。

3つ目: レトロスペクティブを終了するアクティビティ 「感謝」

「ポジティブにイテーレションやレトロスペクティブを終える」目的に利用できるそうです。 長い期間やっていると日々あったこと、心に思っていたことをあらためて感謝の意を込めて感謝を伝えられるのははうれしいものです。

感謝することは任意で、誰も話さない時間がきたら終わるという、実施方法となります。

自然とでる言葉たち

この業務に関わっている人全員が、主たる業務というわけではなく、時間を確保をして協力しながら活動を進めています。 時には個々人が主たる業務のピークがきて、動きが鈍くなってしまう時もあります。 そういう時に誰かが主体的にやってくれたことはよく覚えていて、感謝の言葉が出ることが多かったです。

不思議なものですよね。自分がやった時のことは覚えていないのに、やってもらった行為はよく覚えているというのは・・・

このレトロスペクティブをとおして

終わってみると、普段よくやっている

  • ブレスト
  • タイムライン
  • KPT

などでおこなう「データの収集」「アイディア出し」「何をすべきか決定する」とは違うアクティビティで、終わった時の気持ちの感覚も独特のものがありました。求められていること・貢献したいこと・状況が変わることによって、立場を表明して立ち去ったり新陳代謝するは必要だと考えています。そういう時に、「いい意味でうまくできそうだな」という手応えが掴めました。自分たちが、なぜこの場にいるのか、考え続けたりやり方を工夫することの大事さをあらためて感じられました!

1時間30分があっという間で、いい時間を過ごせたと思うので、応用して他の場でも色々なアクティビティを選んで使ってみたいなと思いました。

XP祭り2015に参加してきました

XP祭り2015に参加してきました

みなさんこんにちは。KEYチームの武永です。

今回は、先日行われた 「XP祭り2015 “俺も!!”」 に参加してきましたのでそのレポートになります。

XP祭りとは

日本XPユーザグループ(XPJUG)が主催しているイベントです。
2002年より毎年秋に開催されています。
私は今回が初めての参加です。

今回参加したセッション一覧

私が参加したセッションは以下になります。 オープニングは間に合わず基調講演からの参加になりましたが。。。

基調講演「XP lives, XP dies, XP lives again!!」

角征典さんによる基調講演のスライドは以下になります。

基本的に全てスライドに書いてあるので御覧ください。
個人的に印象に残っているのは「ときめき」というワードです。

  • TDD -ときめき駆動開発-とは
    こんまり流片付け術 では「捨てるモノ」ではなく「残すモノ」を選ぶが、 残すかどうか迷った時に「それはときめくか?」と先生は聞くらしい。
    ときめきは個人的なもので教えるものではない、最強のツール。
    エクストリームプログラミング の23章「時を超えたプログラミングの道」は、
    ときめきの道であり、 XPをやるときもみんなが「ときめく」必要がある。
    「ときめくプラクティス」を選ぶべきである。
    XPは「価値」と言ってるけど、それは届けた後にしか分からないよね?
    だから「無駄」とか「価値」じゃなくて、「ときめき」が重要。
    これが「ときめき駆動開発」。TDDだよね!

プラクティスを選定するときに「ときめく」ことが重要というのは個人的にもスゴく共感出来ました。
実際にプラクティスを選定する場面に立ち会わせたことはありませんが、
何かしらの課題を抱えていて、それを解決してくれるかもしれないものに出会った時に「ときめく!」のだろうなとはなんとなく感じることができるので。
このあと1日中「ときめき」というワードがどこかから聞こえてくることや、 セッションの資料に出てくることもあったのでみなさん同じ気持だったのかなとか想像してました。

結構笑えるネタが盛り込まれていたらしいのですが、
私には分からないネタが多くて反応できなかったことが結構ありました(汗)

“共感”でつながるアジャイルチーム

こちらは「共感コミュニケーション」というものをワークショップで体験してみるセッションでした。
スライドは以下になります。

4つのプロセス

  • 観察
    録画再生のように明らかな事実
  • 感情
    自分/相手が感じていること
    エンジニアは感情を出しづらい/感情を抑える傾向にある職業だと本に書かれているらしいです
  • ニーズ
    何を必要としているか
    感情の裏には自分が必要としているものがあるはず
  • リクエスト
    具体的な要求
    叶わなくてもいいから口にだしてみる

このワークショップでは、「感情」と「ニーズ」の部分について 「感情」と「ニーズ」を結びつける練習を行いました。

最初に「自分の感情」を感じるということをしました。
例えば

  • ときめくプラクティスを聞いた時は「面白かった」。なぜなら「ひらめきが欲しい」、「刺激が欲しい」というニーズが「満たされた」からだ。
  • 基調講演を聞いて「ショックを受けた」。なぜなら一部理解できない話があり、「情報や知識がほしい」というニーズが「満たされなかった」からだ。

というように、どのような感情を持っているのか、その感情の元となるニーズを探ることで、
自分・相手が欲しているものは何かということを探っていくことをしました。

「自分の感情」を実際に他の人に上の例文のような形で話してみると 「本当にこの感情とニーズは合致しているな」と改めて納得した部分もありました。
しかし、「この感情はこのニーズと合致しているのか?」と自分に疑問を持って相手と本当のニーズを探してみると新たな発見もありました。
自分のことなのに実際に口に出してみると相手にも伝わるし、自分も新たな発見ができるという非常に面白い体験でした。

次にペアの人の話を聞いて、その裏にある「感情とニーズを探る」ということを行いました。
何かの感情にまつわる1つの出来事を相手に話して、相手はその裏にある「感情」を当てたあと、2人でニーズを探していくという練習でした。

これが非常に難しくもあり、面白い時間でした。
相手の話の裏に隠れている感情を探るのは難しく、そこからニーズを探るのはさらに難しかったですが、
探ろうとして深堀りして聞いていくうちに新しい情報が出てきてもっと相手のことが知れたり、
自分のことを知ってもらえるようになるのだなと感じた時間でした。

TDDライブコーディング

こちらは「ときめき駆動開発」ではなく本当に「テスト駆動開発」の方のTDDライブコーディングです。
まずはTDDについて説明と登壇者のきょんさんが大事にしていることの説明がありました。

TDDの3原則 by Uncle Bob

  • 失敗するテストが出来るまでプロダクトを書いてはいけない
    最初Greenにした時に、一気に追加実装してしまうのはTDDあるあるだがやってはいけない
  • 失敗するテストがある場合にはそれ以上テストを追加してはいけない
  • テストを成功させるプロダクトがある場合にはそれ以上プロダクトを追加してはいけない

要求や設計の反映

テストが失敗した時に判断できるようにする

  • バグを埋め込んでしまったからか。
  • 意図された振る舞いは変わらず関連性があった部分が何処か別の場所に移されていたのか。
  • 振る舞いがもはや正しくない。システムの前提が変わってしまっているのか。

分析と設計

  • 分析には主にミカドメソッドを使う
  • 設計には主にTDD/BDDを使う

そして実際にライブコーディング。
https://gist.github.com/kyonmm/6102436 にあるTODOリストをTDDでコーディングするのを見ていくセッションでした。
もっと時間があればワークショップにしても良かったらしいですが、90分枠でライブコーディングになったらしいです。

ライブコーディングの様子

そして出来上がったコードがコチラ

最初Greenにした時に一気に追加実装してしまうのは割りとやりがちなので気を引き締めたいところです。
きょんさんは非機能系(パフォーマンスとか)のテストも最初から入れるとのことで、
特に性能テストとかは最初から書いておくらしいです。
実際にどういうテストを書くのかあまり想像できていないので個人的に聞いてみたいです。

LT祭り

そしてLT祭り。
毎年レベル高いと聞いていたのですが、噂通りでした。

それぞれ公開されているスライドを以下に紹介しておきます。

クロージング

最後の最後に協賛の出版各社様からの献本が参加者にプレゼントされました。

私はプレゼントを貰える条件の1つ

XP祭りに初参加で、入社5年目以内

という条件に当てはまったのでこちらを頂きました。ありがとうございました。

最後に

非常に良い刺激を受け続けた1日でした。
一度読みましたが、もう一度エクストリームプログラミングを呼んでみようと思いました。
そして今回聞いたものですぐに使えそうなのものはどんどん実践していきたいです。
例えば共感コミュニケーションなどは非常に練習が必要だと思うので常に意識しながら会話していきたいですね。
今回参加できなかった他のセッションも興味深いものが多いので、スライドをあとで見ようと思います。
来年もきっと参加します!!

学生相手にAgile講習をした話

学生相手にAgile講習をした話

みなさんこんにちは。KEYチームの武永です。

こちらの記事にもあるようにatWareでは今年もインターンシップを受け入れています。 その中で私がインターン生に向けてAgile講習を行ったのでそれについて書いていきます。

Agile講習開催の経緯

KEYチームがメイン担当としてインターン生を受け入れており、
私と円城寺(円城寺の記事はこちらから)が認定スクラムマスターの資格を持っていて
実際のプロジェクトをScrumで取り組んでいることもあり、Agile講習を行うことにしました。
自分のAgileに対する知識・経験の把握と社外の人向けプレゼンの練習になると思って
私がメイン講師になり、円城寺のサポートを受け、講習を行いました。

Agile講習の内容

流れとしてはウォーターフォールの紹介、ウォーターフォールでの問題点から
紙ヒコーキワークショップを実施し、Scrumの説明という流れで行いました。
私はウォーターフォールのプロジェクトを経験したことが無かったので教科書的な説明になってしまいましたが。。。
使用したスライドは以下になります。

講習の様子

函館ラボにもインターン生が来ていたのでリモートで行いました。

以下の動画は実際に紙ヒコーキを飛ばしているところです。
楽しそうに実施してくれて良かったです。

紙ヒコーキワークショップ結果
予測 実測
1 5 1
2 3 4
3 8 10
4 11 8

紙ヒコーキを飛ばしたらみんなで後片付けをした後にScrumの説明を行いました。

本当は2時間程の予定でしたが、1時間半程で終了してしまいました。
学生の頃の経験で10分・20分程度の短いものの時間感覚はあるのですが、
1時間超えというものは初めての事だったので非常に良い経験になりました。

インターン生からの感想

講習後個別に感想を聞いてみました。

  • 分かりやすかった
  • 紙ヒコーキワークショップが楽しかった
  • なんとなく分かった
  • Scrumのことはなんとなく知っていて、ワークショップで「なるほど」となるところが結構あった。

直接聞いたので社交辞令的にプラスの意見が多かったのかは分かりませんが 皆さんから良い感想が聞けて非常に嬉しかったです。

反省点

学生側からはプラスな感想が出来ましたが講習を聞いていた社員からは
「話すの速かった」、「知っている前提の内容が結構あった」などのご指摘を結構受けました。
Agileの知識・経験不足、対象者を考えたプレゼン作りなどなど
自分に不足している部分を改めて実感できた良い経験になりました。

最後に

今回の講習を受けた学生の刺激になり少しでもAgile・Scrumについて勉強するきっかけ作りになれたなら最高だなと感じています。
それと同時に自分ももっとAgile・Scrumについて勉強していこうと思える機会になりました。

またこのような発表する機会があるのなら上手く行った点、反省点を活かして行いたいと思います。

認定スクラムマスター研修に参加してきました

認定スクラムマスター研修に参加してきました

みなさんこんにちは。KEYチームの武永です。

先日開催された認定スクラムマスター研修に参加してきました。

参加までの経緯

現在私が参画しているプロジェクトはスクラムを取り入れており、普段から「スクラム」や「アジャイル」という単語をよく耳にする環境にいます。
そこで、「スクラムについて学ぶことで実際の業務に役立てていきたい」、「アジャイル・スクラムについて学んで今後のコミュニティ活動などにも活かしていきたい」という思いを持ち参加することにしました。

認定スクラムマスター(CSM)とは

ScrumAllianceが認定してる資格の一つです。
「スクラム」と呼ばれるチーム開発手法における役割の1つになります。 スクラムにはスクラムマスターというロールがあって、そのロールをこなすための知識を認定しているのがCSMです。
決してスクラムをマスターしていますということを認定している訳ではありません。 (とはいえスクラムマスターの役目を果たすにはスクラムのことを正しく理解し、説明することが必要)

研修内容

  1. イントロダクション
  2. スクラムの歴史
  3. スクラムの理論、コンセプト、プラクティス
    1. アジャイルについて、アジャイルはなぜうまくいくのか
    2. スクラムの3つのロールモデル: プロダクトオーナ、スクラムマスタ、チーム
    3. スクラムの4つのミーティング: リリース計画、スプリント計画、デイリースクラム、スプリントレビュー
    4. スクラムの3つのリスト: プロダクトバックログ、スプリントバックログ、障害リスト
    5. プランニングポーカーによる計画
  4. リリース計画
    1. プロダクトバックログ
    2. プロダクトバックログ作成演習
  5. 生産とスプリント
    1. スプリントのゴール
    2. スプリント計画
    3. タスクボード
    4. デイリースクラム
    5. バーンダウンチャート
    6. ベロシティと障害物
    7. アーキテクチャとインフラ
    8. 完了の定義
    9. スプリント署名
    10. スプリントのプレゼンテーション
  6. ベロシティ・ゲーム
  7. 障害に打ち勝つ
  8. マネジメント、分散、スケールアップ

基本的にスライドを見ながらの座学を中心にワークショップを交えながらの2日間でした。

学んだこと、感じたこと

  • スクラムマスターの役割
    スクラムマスターとは開発が「スクラム」と呼べる状態にする人のことで、 開発チームに対して指示はすることもなく、プロセスの管理をする。
    チームがチームを管理して自律的なチームを目指す。
    スクラムマスターはチームが困っている時に助言する
    チームの障害となるものを取り除いていく。
    例えば、 プロダクトオーナー(PO)がスプリントの途中で別のアイデアを考えたからそれをスプリントに取り入れてくれという要求を出してきた際には

    「確かにそれはいいアイデアですが、このスプリントには入れずに次のスプリントに入れていきましょう」

    というようにPOからの新しい要求(障害)を取り除いて開発チームが上手くスプリントをこなしていけるように環境を整える役割を持っています。
    もし、この要求を受け入れてしまえば開発チームのリズムというものが崩れてしまいスプリントが上手く回らなくなってしまいます。このリズムを崩すこと無く開発を進めていけるようにするのがスクラムマスターの役割なのではないかと感じました。

  • 非効率の「3つのM」

    • Muda:ムダ
    • Mura:ムラ
    • Muri:ムリ

    この3つをどんどん無くしていくことでチームをより良いものへとしていくことが必要。

    「チームを加速させようとしていくのではなくムダ、ムラ、ムリを無くしていくことで間接的にチームを加速させていくことが重要」

    特にこの言葉が印象に残っています。
    何か良いツールや手法など新しいものをどんどん取り入れていくと、逆にどれも中途半端になってしまい、チームを減速させてしまう。そうではなくて現在のプロセスの中に潜む3つのMを取り除いていくことでチームを加速させてから新しいものを取り入れていく方がより良いチームへ成長していけるのではないかと感じました。

    スプリントを上手く回していく、より良いチームにしていくためにはどんどん3つのMを取り除いていく、改善していくということが大切です。

最後に

研修は受けましたが、まだ資格は取得していません。研修後、オンラインの試験を受けてから正式に認定スクラムマスターの資格が得られます。
「改善」というものを常に意識して自分達はチームの一員で自分達がチームを良い物に変えていくという考えがとても重要なものなのだと改めて実感した研修でした。
今回参加した研修でスクラムの「型(守破離の守)」を学ぶことが出来ました。まずは、ここで学んだことを実際に実践していくことで「知識」でしかない部分を「経験」にしていけばスクラムマスターに近づいていけるのではないか、より良いチームにしてくことができるのではないかと考えています。
とりあえず、早くオンライン試験を受けて正式に資格を取得したいですね。
もっと研修のこの部分の内容を知りたいなどありましたら以下のメールアドレスまでご連絡ください。
takenaga at atware.co.jp