「スクラム開発におけるマネジメント、評価指標・サポート・オンボーディング」に参加しました
この記事は「ScrumFestSapporo2020 Advent Calendar 2020」の18日目の記事になります。
前日の記事はこちら。
分散アジャイルチームについて考える会の「スクラム開発におけるマネジメント、評価指標・サポート・オンボーディング」に参加しました。
distributed-agile-team.connpass.com
お話してくれた人
@tunepoloさんです。
RettyではLessでスクラムを実施していて、その複数のスクラムチームのマネージャーをされてます。
今日の発表ではもやもやしてるポイントもそのまま持ってきてくださいました。もやもやがあるというところに現在進行形の雰囲気があってよかったです。
お話のポイント
- スクラムチームそのものの評価
- スクラムチーム個人の評価
- やることが変わっても使える指標がよい
- 開発への貢献、リリースまでの日数、障害数
- 持ち場を持たせる
- その人がリードできるもの
- やることが変わっても使える指標がよい
- 1 on 1
- 週1で30分
- 早めのフィードバックの機会
- POやSMとではなくマネージャーと行う
- 上下関係にしたくない
- 週1で30分
- 問題のエスカレーション
- 複数チームでふりかえり結果を共有
- チームの立ち上げ
- チームメンバーの選び方
- バランス良く配置したり、チームに決めてもらったり
- SMの選び方
- 立候補や適性などその場に応じて
- リーダーや管理職候補ばかりにしない
- SM兼任
- RettyではDevとの兼任（SM専任はキャリアに繋がるのかという疑問もあり）
- メンバーをチームに入れる時
- 準備期間は設けない
- チーム開発になれる
- チームメンバーの選び方
- マネージャー育成
- プレーヤーとしては一旦手を止めてもらう
- プレーヤーマネージャーは求められる能力が違うので並走は難しい
- テコ入れポイントを見極める
- メンバーの成長に喜びを感じられる人
- プレーヤーとしては一旦手を止めてもらう
感想
まず、実験を評価するというのが良いと思いました。
「評価」という観点で見た時に、実験のように失敗するかもしれないものや直近の成果に繋がらないものって評価されにくいと思うのですが、長距離を走るための持久力を付けてもらいたいという観点をもって見ているところが素晴らしいと感じました。
また「POやSMはDevとの兼任」としている理由の１つが「SM専任にしてしまった時に将来的なキャリアに繋がるのか疑問に感じている」という点についても、評価されにくい役割へのキャリアをきちんと考慮されている印象を受けました。
いずれも「見えにくいところにこそきちんと気を配ろう」としている点が印象深かったです。
1on1については最近私はもっぱらされる側なのですが、過去にはする側だったこともあってその当時のことを思い出して聞いていました。
する側だったときにその1on1の目的がメンタリングなのかティーチングなのか評価なのか面談なのかというところにフォーカスしてから始めていなかったなぁというのが、今さらの反省点です。
する側が「メンタリングするぞ！」と思っていても、される人が「評価面談だ！」と思うと、聞く内容から答え方まで大きく変わってきそうだしそこを合わせておかないと何も引き出せない1on1になってしまいそうだと思いました。
このイベントはきょんさんが「今日はこんな感じで進めます」「このあとのOSTはこんな感じで進めます」「Muralはこんな感じで使います」と毎回説明をきちんとしてくださって、初めて参加する人にやさしい設計になっているところがすごくいいなぁと感じています。
自分も運営する時にはこういうところに気を配れるようになりたいなー。
アンチパターンをうまく活用しよう
この記事は「ScrumFestSapporo2020 Advent Calendar 2020」の15日目の記事になります。
前日の記事はこちら。
にくさんがアンチパターンについて書いてくださった記事を読みつつFacebookでディスカッションしていてアンチパターンの活用術みたいなものを思いついたので雑にまとめてみました。
アンチパターンとは
Anti Patternではこのように説明されています。
アンチパターンとは、問題から悪い解決策に移行する方法を伝えるパターンです。(悪い解決策から良い解決策へと移行する方法を伝えるパターンである改善パターンとは対照的です)。
悪しき慣行を識別することは、良い慣行を識別するのと同じくらい貴重である場合があります。
よく練られたAntiPatternはまた、なぜ悪い解決策が魅力的に見えるのか(例えば、それが実際にいくつかの狭い文脈で機能する)、なぜそれが悪いことが判明したのか、そしてその代わりにどのような肯定的なパターンが適用可能であるのかを教えてくれます。
もうひとつ紹介。SQLアンチパターンの著者であるBill Karwin氏は以下のように述べています。
問題の解決を意図しながらもしばしば他の問題を生じさせてしまう技法を指します。
この２つから、私はアンチパターンというものを以下のように理解しています。
問題から悪い解決策に移行する方法を伝えるパターンのこと。良かれと思ってやっているにもかかわらず結果として裏目にでてしまうことがしばしばある。
アンチパターンの必要性
アンチパターンの必要性とはなんでしょうか。まず前提として以下の考えがあります。
悪しき慣行を識別することは、良い慣行を識別するのと同じくらい貴重である*1
ここにBill Karwin氏の言葉を重ねると、こんな感じになります。
悪しき慣行を識別することは、良い慣行を識別するのと同じくらい貴重であるが、悪しき慣行の中には良かれと思ってやっている場合も多々ある。
この「良かれと思ってやっている」あたりがミソです。つまり「悪しき慣行」の中には、
自分やチームが善意に基づいて行動しているがゆえに、実はそれが悪しき慣行であるということに気づきにくいものが存在する
ということです。
さらに、その結果がぱっと見良いものであったりするとなおのことわかりにくいため、知らず知らずに陥っていることが多いのだと思います。
紙粘土スクラムから学ぶアンチパターン
紙粘土スクラムの例でいうと、スクラムマスターがなんでもやってあげちゃう"過保護なSM"とかがそうです。
SMも自分がチームの役に立っていることを感じられますし、SM以外からみても問題は解決するわ仕事は進むわで、結果だけ見るとなんか良さそうですね。 ですが、実はめちゃくちゃSMへ依存している状態なので、スクラムチームの能力が上がってるわけではなくそのSMがいなくなると簡単に崩壊します*2。
でも、これって過保護なSMがいてくれる間は良い結果が出てるだけに、気づきにくいかもしれません。
このパターンが怖いのはスクラムチームみんなが「良い慣行をしている」と思っていて、チーム内に違和感を感じている人がいない場合です。
違和感に気づくための"第三者の目"
違和感というのは「何かと何かの差分を感じて、その差分に心地悪さを感じる」ことだと思いますが、ここに気づくにはある程度経験やスキルや知識がいるのではないでしょうか。
では経験もスキルも知識もない人が気づくにはどうしたらいいでしょう。
１つは、第三者から指摘してもらうということだと思います。
自分の悪しき慣行には、自分以外の誰かの助言が役立ちます。
ではチームの悪しき慣行には？ 他のチームが教えてくれるかもしれません。 では他のチームも気づいていなかったら？助言してくれるチームや誰かが近くにいなかったら？
そういうケースも含め、「第三者の目」になってくれるのがアンチパターンという「パターン化された事実集」なんだと思います。
アンチパターンの活用する
アンチパターンの活用の仕方はチームの習熟度によって変わると考えています。
以下は「スクラムチームが、スクラムのアンチパターンを活用する」場合をチームの習熟度別に考えてみた例です。
A. 全員ほぼ未経験のスクラムチーム
何か良くて何が良くないかを感じるための経験がそもそも少なく、違和感を感じることができないチームです。
Anti Patternにはこう書かれています。
よく練られたAntiPatternはまた、なぜ悪い解決策が魅力的に見えるのか(例えば、それが実際にいくつかの狭い文脈で機能する)、なぜそれが悪いことが判明したのか、そしてその代わりにどのような肯定的なパターンが適用可能であるのかを教えてくれます。
まずは世の中にあるスクラムのアンチパターンと呼ばれるものを集め*3、そこに書かれていることをチーム共通の形式知としてもっておくと良いと思います。
そうすることで、まずチーム内のふるまいに対し「このままで良さそう？良くなさそう？」判断ができるようになり、見過ごすことや気づかず過ぎることを減らせます。
B.チームに1人以上の有識者がいるスクラムチーム
有識者がいる、もしくは違和感に気づくことができる人がいればアンチパターンを使わずとも「悪しき慣行の匂い」は嗅ぎ分けられそうです。
一方で、違和感の理由を、気づいていない人達へ説明することには苦労するかもしれません。そういう場合にアンチパターンを基準として示すと良いと思いました。
「私の経験では、このままいくと失敗すると思う」よりも、パターン化されたエビデンスに則った説明と改善案のほうがより説得力があります。
チームの改善には誰かの基準ではなくチーム共通の基準となりうるものを示すほうが明瞭で良いと考えています。
C. 習熟したスクラムチーム
だいぶ習熟して頭と体にアンチパターンが染みつけているチームの場合は、すでに「アンチパターン集」は必要ないかもしれません。 この頃になると、自分が気づかなかったとしてもチーム内で声を掛け合う体制もできていたり、アンチパターンを見つけるというよりチームの違和感として察知することができる、つまり定義されていないアンチパターンについても見つけることができそうです。
チームが習熟するにつれ「アンチパターン集」との関わり方は変わってくると思いますので、自分のチームがどのレベルなのかを意識するとよいと思いました。
いずれのチームでも、レトロスペクティブという機会でディスカッションして改善していくのが良いと思います。
終わりに
大事だなと思ったのは
それが良い結果を生んでいたとしても、チームのふるまいとして良いこととは必ずしも一致しない
ということです。
チームに困っている人がいたり良くない結果になっている時は違和感に気づきやすいですが、結果だけみれば良い時や今だけみると誰も困っていないという時にこそアンチパターンが役に立つと感じました。
なんか、ディスカッションしていて少しいい感じにまとめられそうなので忘れないうちに書きました。
参考
Bill Karwin氏の言葉
ScrumFestSapporo2020：シャケクマ誕生秘話
この記事は「ScrumFestSapporo2020 Advent Calendar 2020」の12日目の記事になります。
前日の記事はこちら。
今日はスクフェスのキャラ、シャケクマについて誕生秘話を書きます。
北海道らしさを出す
北海道らしさってどんなんだろうと考えた結果、思いついたものたち。
- ラーメン、寿司、スープカレー、シメパフェ、ソフトクリーム、アスパラなどおいしい食べ物
- クマ、キツネなどの動物
- 木彫りのクマ、まりもなどのお土産
木彫りのクマの「クマ＆鮭」の組み合わせからなんかギャザってる感だせるかもと思いました。
「ギャザる」感じを出す
これだと鮭の立ち位置が「クマの食糧」なので、弱肉強食でありギャザってはいませんね。
なのでクマと鮭は仲良しな感じを出したく、鮭がクマのしっぽを噛みつくという逆パターンにしたらどうかと思いました。クマがお出かけしようとしているところに鮭が「自分も一緒に行く～」と言っている感じです。
クマが手持ち無沙汰だったので北海道名物アスパラを持たせてみましたが、スクフェス後に道外の方から「アスパラ=北海道名物ってイメージがない」というフィードバックをいただきました。なるほど。
北海道のアスパラ太くて甘くてジューシーで、とにかくめちゃくちゃ美味しいのでぜひ食べてみてほしいです。ちなみに天ぷらにして熱々を抹茶塩でやけどしながら食べるのが個人的におすすめです。
こんな祭りもやってますよ。
もっとギャザりたいとよくばる
「ギャザる＝わいわい」を出したくてひつじも追加してみました。
ところが「取ってつけた感がある」とスタッフから不評だったのでこれはボツになり結局「鮭とクマ」に落ち着きました。
まぁ、実際「鮭とクマ」で構図を考えていたところに後から取ってつけたのでうまくなじませることができず、ご指摘通りです。
イラレとペンタブ投入
ここまでの作業は鉛筆で下絵を描いて取り込み、マウスを使って ファイアアルパカで書くということをやっていました。
マウス！！！！
今まではそれでよかったんですが（よくない）今回はいろんな人たちの目に触れるキャラクターを作るということでペンタブとイラレを用意してきちんと作業を進めることにしました。
やっと人間らしい創作活動ができます。
完成
最後に北海道のマークと文字を入れて「シャケクマ」の完成です。
自分の作ったキャラクターがTシャツになって皆さんが着てくれたり、zoomの背景にしてくれたり、発表スライドに使ってくれているのをみるとめちゃくちゃテンションがあがりました。
ボツいろいろ
すしロゴ
結局使わなかった寿司ロゴ。
シャケクマと合わせるとごちゃごちゃするということで出番がありませんでした。
イベントパスのネックストラップにしようと思っていたのですがオンライン化で必要なくなり、だったらTシャツの襟元にいれようとおもっていたのですが結局やらずにおわりました。
個人的には好きなので何かで使いたいんだよなぁ。
いくラム
ボツになったヒツジをなんとか使えないかと思い、北海道名物イクラ丼と組み合わせてみました。
が、鮭の立場から見た時に「子供が喰われている」感が若干ブラックな感じがしたのでやめました。
「ふりかえりには、ストレスマネージメントの考え方が役に立つ！」に参加しました
この記事は「ScrumFestSapporo2020 Advent Calendar 2020」の11日目の記事になります。
前日の記事はこちら。
今日はこちらに参加したのでイベントレポートになります。
distributed-agile-team.connpass.com
ストレスマネージメントという分野についてあまり知らなかったのですが、「ストレスマネージメント」というのがどうふりかえりに役立つのか知りたくて参加しました。
お話してくれた人
@scrummasudarさんが自分の経験から得た心理学的な知識をもとにお話ししてくれました。
声が落ち着いていて話し方のトーンが丁寧で、聞きやすかったです。
ストレスの話
- ストレスにも色々ある
- デイリーハッスル：日常生活や生活を送る上で頻繁に体験する不愉快な事柄や心配事。
- ストレスの二面性
- 疾病モデル：ストレスは疾病の発症あるいは増悪因子として働く
- 成長モデル：ストレスが成長の源
- ストレスには両方の面でとらえるのが大事
- 統制可能性
- 自分の意志や行動で変えられるかどうか
- 統制可能性が低ければストレスフルに感じる
- 自分の抱えているストレスが自分で制御できるかどうかも大事
- 予測可能性
- 予測可能なものはストレスやショックの程度が低い
- 予測不可能なものはストレスやショックの程度が高い
- 統制不可能、予測不可能なことは受け入れることが大切
- コーピング
- ストレスに対処するということ
- 問題焦点型コーピング：問題を変化させたり避ける方法を見つける
- 情動焦点型コーピング：情動をあらわにし、リラックスする
- まずは、軽量な情動焦点型コーピング。興奮状態を抑えるためにリラックスする。
- 冷静ではない状態で問題焦点型コーピングに取り組んでも難しい
ふりかえりに役立てる
- 人の状態に注目する。結局実施するのは「人」である
- ふりかえりで問題解決方法が見つからない時でも、焦らず軽量な情動焦点型コーピングから。
- 対処方法を事前に知る
- コーピングは突然思いつくものではない
- 情動焦点型コーピングは100個くらい見つけておくとよい
- 具体的の方がよい「甘いもの」より「ヤマザキのツインシュー食べる」
ワーク
仕事におけるデイリーハッスルを書き出してみる
- 集中したい時や急ぎの仕事がある時に、大きい音量で音楽を流される
- 集中したい時や急ぎの仕事がある時に、やたらと話しかけてくる（雰囲気で察してほしい…）
- ずっと独り言言ってたり、貧乏ゆすりする人がそばにいる
- ハマっていたり難しいことに直面している
ストレスをふりかえる
自分のデイリーハッスルを見直してみると音や話しかけられることなど統制不可能なものにストレスを感じる傾向がありますね。
普段はさほど気にならないんですが、ハマっているときや気持ちに余裕がない時がどうもだめなのです。
自分の情動焦点型コーピングを書き出す
- King Gnu聴く
- 宇宙の動画を見ると、自分の悩みが小さく感じてどうでもよくなる
- なんでストレスを感じているのかとことん分析してみる
- ねことモフモフする
- 怒りを言葉に出してブツブツ言いまくる（1人の時）
質問
に参加者の方からこんな感じの内容をいただきました。ありがとうございます。
チームが課題を共有し一丸となって目的に向かうことももちろん大事だけど、受け止めようと思って受け止められるものと、受け止めようと思っていても受け止められないこともある。
そうじゃない状態、力を抜いた時にこそより良いアイディアが浮かんだりすることもあるので、そういう状態を作るようにするのは良いかも。あえて全然関係ないことをみんなでやってみるとか。
あー、確かに。 真正面から向き合うんじゃなくてみんなで肩の力を抜くのは良さそう。
簡単なところでは雑談とか飲み会やランチからスタートしてみて、ゲームやスポーツをやってみてもいいかもなぁ。
おわりに
自分は最近ネコを飼いました。
モフモフしているだけでめちゃくちゃ癒されるし、子供たちも疲れて帰ってきても猫を見るとめっちゃ笑顔になります。あと1日中家にいて誰とも話さない日もありますがネコと話しているとあまり孤独を感じません。
我が家共通の情動焦点型コーピングです。動物ってコーピングの効果がすごく高い気がします。
「ひとりでやる」から考え始めたら気持ちが軽くなった話
この記事は「ScrumFestSapporo2020 Advent Calendar 2020」の9日目の記事になります。
前日の記事はこちら。
今回は前置きが長いので目次付けました。
本題は"ひとりでやる"あたりからになります（でも前置きを読まないとたぶん話の流れがわからないと思うので、最初から読むのを推奨）。
スクフェス準備中に私が陥った状態
スクフェス準備中の夏、私はこんな状態に陥りました。
短納期業務にアサイン（しかも初挑戦言語） ＋ 娘が利き腕骨折で全治３か月 = イベントに対するモチベーション低下
私の場合、困ったときにすぐ頼れる大人が近くにいないこともあり*1、ほぼ全てのことをワンオペでこなしております。
今回のダブルパンチで時間的にも精神的にも余裕がなくなってしまい、目先のことをこなすので精一杯な状態になりました。
頑張りすぎてちょっとヤバい状態に陥った過去もあり、その経験から「テンパりそうになったら、テンパる前に何かやめる。いのちだいじに。」を自分との約束にしていました。
一時離脱
コロナの影響でスクフェスが延期になったこともあり、自分の「やることリスト」から実行委員業務を外しました。
復帰
休日対応や残業もそこそこありましたがなんとか短納期業務を終えることができました。
この頃スクフェス大阪やスクフェス三河での発表コンテンツや、スクフェス札幌のオンライン化に向けた準備は残ったメンバーが進めていてくれました。感謝しかありません。
その後、娘の骨折も徐々に良くなり通院も毎週だったのが隔週や3週に1回に減ってきました。時間的にも精神的にも余裕が生まれてきたのでこの時期にまた実行委員業務へ復帰しました*2。
疑問
スクフェス札幌実行委員は実質ボランティアの集まりなので、動ける人が少ない時は動ける人の負荷が高まります。この現象は仕事でもよくあると思います。
自分だけが忙しくなるとなんだかハズレを引いているような気がして「自分ばっかり頑張っていて、あの人は全然やってくれない」という気持ちになりませんか？
私は精神が未熟なのでよくなってました。
スクフェス札幌の実行委員のメンバーはどう感じたんだろうと思い、聞いてみました。
”ひとりでもやる”
メンバーの1人に「人手が足りなくて自分ばっかりタスクこなしている状態になったとき、『いづは全然やってくれない』みたいに恨めしい気持ちにならなかったの？」と聞いたら、
「仮にスクフェス札幌を実施したいという人が誰もいなかったとしても自分はやりたいと思うからひとりでもやろうと思ってたし、その時はひとりでできるぶんだけをやればいいと思ってた。でも一緒にやってくれる人がいればできることも増えるしなにより楽しいことは間違いないから仲間が増えてくれるのは嬉しい。だから、そういう風に思ったことはない。」
と言われました。*3
これが、これまでの自分にない考え方だったのでなかなかの衝撃でした。
私が得たこと
この「ひとりでもやる」という答えから自分が学んだことは、
「ひとりでできる量を、ひとりでやる」という状態からスタートすると気持ちが軽くなる
ということです。
「みんなでできる量で、みんなで始める」にしてしまうと、人手が足りなくなった時にいない人を責めがちになったり、できない理由を「あの人がやらないから」にしてしまいそうになります。私はなります。
つまり、引き算思考です。
「ひとりでできる量で、ひとりではじめる」だと、やる量もかける労力も全部自分次第で調節できます。もちろん一緒にやるよって言ってくれる人がjoinしてくれたらその分やれることが増えますし楽しさも増えます。
つまり、足し算思考です。
あったものが減っていくよりも、ないと思ってたものが増えるほうがハッピーですね。
自分はワンオペ歴が長いのもあり「やらないとならないことがたくさんある」という「量固定」の状態からスタートすることが多く、自然と何に対しても引き算思考から入るクセがあったと思います。
これをきっかけに「ひとりでできる量を、ひとりでやる」の考え方に切り替えることができ、過剰に他人へ期待することが少なくなりました。
最後に
「最初から期待しなければ良い」というのはよく聞きます、こんかの学びはおそらくこれと同じことではあるんですが、"期待しない"という言葉からは孤独な感じがするのと、人に期待すること自体はそんなに悪いことではないと思うのでこのフレーズが好きではありませんでした。
「ひとりでできる量を、ひとりでやる」から始める
と考えることで「前向きに宛てしない」というスキルを手に入れました。 こんな考え方も、スクフェス札幌というイベントがあったから自分が学べたことだと思います。
よし、2時間で書いたのでおわり。ちょっと時間かかっちゃった。
後日談
後日実行委員の数名と会う機会があり、その時にこんな話をしたんですがうまく話せていなかったのであらためてまとめてみました。
上手にアウトプットできない私が気づいたこと
この記事は「ScrumFestSapporo2020 Advent Calendar 2020」の8日目の記事になります。
前日の記事はCREATIONLINEの安田さんが書いてくれました。
今日はアウトプットすることについてひとりごとを書いています。
最近は以前にもまして自分がインプットしたことをアウトプットすることが大事だと感じています。
アウトプットが大事な理由
すべて私の場合になります。他の人には当てはまらないかもしれないです。
イベントに参加してわかったと思っても実際にその場で即座に理解できる量が少ない。ほんわかしか理解してないことが多い。これだとどんなに良い体験だとしても、その場にいた人以外と何が良かったかをうまくシェアできない（うまくないシェアならできる）。
ほんわかした理解は、他の何かの情報と線で結びつきにくい。何かと結びついてない記憶はすぐ忘れてしまう。
ブログでアウトプットしようとすると文字にする必要がある。つまり自分が言語化、文章化できないと手がとまる。言語化、文章化できていないということは人に伝えられるかの前に、自分が理解できていないということ。つまり理解が足りない（=ほんわか状態）。
こんな理由があり、「よし、どんどんアウトプットしよう」と意気込みました。
問題発生
やってみると、こんなスパイラルに陥りました。
- 言語化や文章化する能力が圧倒的にたりない。
- ゆえに、「この言葉にできない気持ちをなんと伝えたらいいだろう」というなにかの歌詞のような状態に陥ってしまう。
- 言語化するために言葉を調べたり、読みやすい文章にしようと試行錯誤しながら書く。すると1記事書くのにすごい時間かかる。5時間とか平気でかかるので数がこなせない。
- そうすると、アウトプットすることへの肉体的、心理的負担が大きい。めんどくさくなる。
- アウトプットせず「ほんわか」の状態でとどまることが多くなる。
- 1へ戻る。
アウトプットする速度が上がればこのスパイラルから抜け出せるのにな。
急にひらめく
過去の自分のブログをみていると「頑張って丁寧に書こうとしている」「1記事あたりの文章がやや長い」に気づきました。
単純にもっと短い記事にすればいいんじゃない？なんだったらもっと雑でもいいんじゃ？
あれ、スパイラル逆回りにすればもしかしてうまくまわるんじゃ？
- 言語が稚拙でも文章が雑でもよいので、自分の知っている言葉でとにかくアウトプットする。つまり品質は求めない。
- アウトプットすることへのハードルが下がる。
- 思考→言語化の練習になる。
- アウトプットスキルがあがる（かもしれない）。
やってみる
日々小さなきづきがあり小ネタはたくさんもっているので、しばらく逆スパイラルを試してみます。
なので、この記事は1時間以内を目標に思いつくままにざざっと書いています。
おまけ
言語化や文章化する能力を高めるには本をたくさん読むことも大事ですね。
「こんな気持ちはこう表現するんだな」という自分の言語化チートシートの内容が充実してくれば良い文章をささっとかけるようになりそう。
おしまい。
「やさしいふりかえり（初心者向け）」というワークショップを開催しました
この記事は「ScrumFestSapporo2020 Advent Calendar 2020」の6日目の記事になります。
前日の記事はこちら。
12/5(金)に最近アジャイル札幌でシリーズ化してきているやさしいシリーズの第2弾「やさしいふりかえり」の講師をしました。
10月末から行っているこの「やさしい」シリーズのイベントは、文部科学省「専修学校による地域産業中核的人材養成事業」の「札幌（北海道）をモデルとした地域創生のためのIT人材育成と企業連携推進事業」（主幹事校：吉田学園情報ビジネス専門学校）と連携して行っているものです。
やさしいシリーズとは
アジャイル札幌のやさしい講師がやさしく教える初心者向けの学習コンテンツです。
座学＋ワークのスタイルで「参加者が手を動かして学ぶ」ということを大切にしています。
年内は第3弾まで実施することが決まっていますが、おそらく今後も増えると思います。何をやるかについては「皆さんが何を知りたいと思っているか」に寄り添っていきたいと考えていますので「こんなこと知りたい！」というのがあればぜひご連絡ください。
それがやさしいシリーズ第4弾になるかもしれません！
第1弾：やさしいスクラム
講師：@YasKamito（本コンテンツは終了しました）
第2弾：やさしいふりかえり
講師：@izumii19（本コンテンツは終了しました）
第3弾：やさしいテスト
講師：@nemorine（2020/12/19(土) 13:00 - 17:00開催）
やさしいふりかえりとは
ふりかえりとはアジャイル開発でよく耳にする改善活動のことで、Scrumではレトロスペクティブと呼ばれていますがどちらも同じ活動のことを指しています。
「アジャイル開発でよく耳にする」と書きましたが実際には教育や医療などあらゆる現場でも実施されています。
ただ、経験したことのない人にとっては「改善活動」がやや抽象的過ぎて、一体何をすることなのか、どうやってやるのかイマイチわからないと思います。
「やさしいふりかえり」はそんな方達向けにふりかえりの基本知識やフレームワーク、実施のコツなどのベーシックな知識と、実際にワークショップを通じて改善の効果を体験してもらうための学習コンテンツになります。
以下のような方達に向いています
- ふりかえりが何か全くわからない方
- ふりかえりというワードは聞いたことがあるが実際にやってみるには少しハードルが高いと感じている方
- ふりかえりをやってみたいが、近くに経験者がいない方
- ふりかえりを実施しているが、なんかうまくいかない方
- オレオレふりかえりになってしまっているので、基本に立ち戻りたい方
当日の様子
当日のコンテンツについてはDoorKeeperをご覧ください。
また、スライドについては文部科学省なのか吉田学園情報ビジネス専門学校なのかちょっと記憶が曖昧なのですが、こちらから後日公開されると思います。
参加者は開発者から教育現場で従事されている方まで色々な方達が集まり総勢10名でオンライン形式での実施となりました。
前半は座学でふりかえりの基礎知識について学び以下のようなことを理解していただきました。
- ふりかえりとはなにか、やる目的
- いつ、だれと、どうやって始めるのか
- たくさんあるフレームワークからどれをやればよいのか
- よいふりかえりにするために、ちょっとしたコツと大切なこと
後半はKPTとYWTを体験してもらいました。
ワークは手を動かすので単純に楽しいですね、座学だけだと眠くなりますしね。
アクシデント
後半には「miroを使ってグループワークとふりかえりを２イテレーション繰り返し、改善の効果を感じてもらう」というワークを用意していたのですが、ここでまさかのmiroメンテナンス中(!!)
急遽、前半に行った座学の質問タイムを前倒してメンテナンス終了時間が来るのを待ち、その後無事ワークを実施できました。ホッ。
午前中は普通に使えていたので完全に油断してました。
miroの公式ではメンテナンスについての時間が「Saturday at 04:30 AM UTC 」と説明されているので皆さんが使っていないであろう時間にメンテナンスしてくださっているようですが日本だと思いっきり昼間ですね（メンテナンスお疲れ様でした）。
講師として
昼間は業務があるため夜と土日で資料作りをしたり、グループワークの構成を考えるのに時間のやりくりが大変でした。
ただ、グループワークはアジャイル札幌のメンバーが仕事の合間を縫ってプロトタイプを一緒にやって考えてくれたり、スライドのレビューもしてくれたりとたくさん協力してもらえたので、最後まで「参加者にとってよい学びの場にしよう」というモチベーションを切らさずに当日を迎えることができました。
こういうことを通じて「仲間に恵まれている」というのを、最近より一層感じます。
今後は「自分が知っていることを誰かに役立てるための何か」をもっとアウトプットしていきたいと思っています。
それには自分が知っていることが枯渇しないようにしないとならないですね、がんばろう！
さいごに
やさしいシリーズはまだ続きますのでぜひぜひご参加くださいね！
