WACATE 2018夏に参加してきました。ワークショップで実験してきました。

さて、みなさまいかがお過ごしでしょうか？

いまさっき書き終わった記事が吹っ飛び、泣きそうな「なそ」です。

もう一回書く気力を私にください……

今回の参加レポートはいろんな方から上がると思いますので、わたしはワークショップで行ったチーム運営の実験話をしようと思います。

WACATEでは、夏・冬と年2回あり、夏は1つのテーマをどっぷりワークショップを行う。冬は色々なテーマをたくさんやる。そんな年2回のWACATEで「夏」です。ワークショップです！！中身は多くを語りません。他の人のレポートを見てくださいー

　今回のワークショップでは、「なそ」ミッションと題して(個人の暗黙的なミッション)を行いました。そのミッションは3つになります。

1. 個人タスクは極力減らす　
2. チーム全員が納得しながら進める
3. 自分がいなくても、メンバーが主体的にワークショップを進められる

　チームの雰囲気と行動をどうしていきたいかを、チーム内であげました。上はやりたいこと。下は見送る項目。見事にチームのみんなで一致しました。この時点で良いチーム！！

　ただし、このミッションを行うために、支配者的なリーダーシップを行うことで達成することはできないです。それは全ミッションを達成できないのですが、特に3が達成できないためです。サーバントリーダシップで進めて行くのが理想でした。

　特に進め方を決めるときも、「1回だけやってみようよ」と提案してます。もう一個の代案を提示したり、他の人にも意見を求めりもしています。トップダウンとも、ボトムアップとも言える両方が納得して進められるようにしたことで進め方の納得感が生まれました。生まれたよね……？

　個人的な評価に関しては、できたと思っています。チームメンバーもそう思ってもらえれば嬉しい限りです。

　最初はツイートで、パッと話をして終わりにしようと思ったんですが、なかなかな文字量になりそうなのと、繋がりがうまく表現できなかったためにブログにしようと思います。 (最初は他のチームとの違いを言いたかっただけだったので数回で終わる予定でした)

うちの班の読み合わせは、代表者が読み上げて、みんなで気になるところをあげて共有していくというほかの班との違いがあります。誰もなく#WACATE

— なそ@さとうひろゆき (@hiroyuki3gou) June 17, 2018

 仕様書の読み合わせ

うちの班の読み合わせは、

1. 個人で最初から最後まで目を通す
2. 代表者が1段落を読み上げる
3. みんなで仕様を共有する
4. 繰り返す

　私が普段やっている読み合わせとは違うチャレンジをさせてもらいました。普段は、各人で最初から最後まで読んだ上で、疑問点や指摘事項、気になる点をあげてもらいます。その後にチームで共有するという読み合わせをします。結構時間がかかるんですよね。

　今回変えたことで、個人の作業時間を減らすことできました。また、各人が悶々と考えがちになる時間をチームの時間にしたので、すぐにチームの議論とすることができました。共有の時間が生まれないです。議論の時間＝共有の時間となります。

みんなで進める

　全員で一つのモデルをやっていきました。全員で状態遷移図を書いたので、人によって粒度が違うことがないように対策できています。

1. 状態を各人が3分で書き出す
2. みんなで「せーの」で共有する
3. イベントを各人で4分半で書き出す
4. みんなで「せーの」で共有する

　そうして出来上がったのは、写真になります。濃い青は状態。水色はイベントです。重なっているのは、各人が出した項目の被りや統合によって重ねてます。こうなると全員が納得して作っていますよね。全員で話ししながら作っているので！！

　ただ、状態遷移図から状態遷移表に落とし込む時は、みんなが納得している状態である かつ 1人で作業した方が良いというチームの判断となっています。1人で作業した方が良いからだけではなく、みんなが納得している状態だからが前提条件になります。

巣立ちのとき

　状態遷移図が書き終わった段階で約1時間くらい残っていました。ここから全員で状態遷移表やテストケースを書いてもよかったのですが、どうせなら次のモデルを実施してみたい。どこまでできるのかと思い、ユースケース図を書くことを提案しました。そして、ユースケース図を書くときに、私は一歩引いてみましたが、問題なく進み始めて無事にうまくいったと思います。

　一歩引いた私は資料作りに専念しました。もう一人は状態遷移表を記載してもらいました。5人チームなので3人でした。特に何かをした訳ではないですが、ユースケース図を書くときにも、状態遷移図とやり方を一緒にしました。

1. アクターを4分で書き出す
2. みんなで「せーの」で共有する
3. ユースケースを4分で書き出す
4. みんなで「せーの」で共有する

　あとは棒人間と矢印を書いて整理しました。ほとんど、状態遷移図とやっていることは変わりません。そのため、状態遷移表を書いている人もモデルとやり方を知っていれば進められるはずです。

どんなふうになったの？

こんな感じで進めた結果がこちらになります。

順番に説明していきます。

「気になること」は仕様を読んで行く中で、気になったことをあげて行く場所。

解決したら、右の「きまった！！きめた！！」に移動して赤字で記入。

状態遷移図を作る際にみんなで考えた資料です。これらを元に下の状態遷移図を書いたものになります。これらをみたときに不安点が上がってきたので赤い付箋を張っています。だって不安なんだもん。チームの重要なテストにしています。チームの不安な想いを解決するのも重要な要素です。

状態遷移図。途中で気になったことやイベントの間違いが書かれています。番号は状態遷移表へのトレーサビリティを確保しています。

逆光で見にくいですが、上の3枚はそれぞれの進め方を書いています。その下が状態遷移表とテストケースになります。付箋を使った表という発想がすごい！！

ユースケース図です。右はユースケースからテストケースです。操作手順とかはみんなで共有しているからそんなに詳しく書いていません。チーム内で共有して暗黙知になっているのは許容しています。

個人のタスクを極力減らすために

　タイムキープでも、各人のタスクは、チャレンジ時間と追加時間を3分と言っているのに2分半にしたりと鬼畜な事もしましたが、だいたい間に合ってました。1回だけ伸ばしましたが、全体的に短くて問題ありませんでした。これは普段の作業時にも無意識のバッファを積んでいるかもしれないです。そこに意識的にバッファを積んでさらに時間を見積もっている可能性があります。これが悪いことだとは思いませんし、当然だと思います。実際の現場では絶対にしません。これはワークショップだからやったことです。

チームメンバーへ ごめんなさい。　

最後に

　これは、WACATEだからではなく、普段の業務でも一緒になります。誰かと一緒に働くことで、情報共有の時間も含めて考える時間になるので、私は好きです。現場のメンバーの多くがメンバーのタスクを把握している、お互いにフォローできる、仕様がみんなで共有されている状態になることが理想だと思っています。ここでの経験を現場に活かして、さらに良いチームを作れるようにしたいと思います。

それでは！！

(なんとか、書き上げることができた……)