社外研修にいこう

会社に行きたくなくなった日、反対方向の電車に揺られて向かうための海の用意がありますか？わたしはあります。どこかは秘密です。

昨日から明日まで3日間、社外の研修に行っています。システム設計の基本を学びに行っています。内容はまた研修が終わったら機会を改めてアウトプットをしたいと思います。
しかしなんというか世の中には色んな人がいるんだなあと思いました。そういう話をします。

研修の参加者は発注側と開発者のどちらもいます。混合でグループワークをしているので他の参加者の方々ともお話しするのですが、発注側のとある人がパンチ効きすぎていてすごい。もうこの人はすごいのでおじさんと呼びます。 研修中のわたしたちはもろもろ仕様書などを書いており、今日は状態遷移の線を一本引き忘れた仕様書を作成し隣のチームからのレビューでボコボコにされる楽しい演習でした。めちゃくちゃバグってるじゃんと笑っているところで、おじさんは言いました。
「これ書いたの誰？」

チームの成果物はチームの責任で作ったものなので、これは全員の責任ですからね！と反射的に大きな声が出て自分で焦りました。当たり前すぎて忘れていましたが世の中チームで働くという経験をしている人は少ないのですよね。いやまあそうですよね。冷静になればそうです。そんなこと言ってくるプロマネとかまじで嫌だなあとか絶対一緒に仕事したくないなとか思いましたが世の中そういうものなのかなと考えさせられました。
しかしおじさんは容赦なく畳み掛けてきます。「大きな指摘はなかったの？」「いや、今言いましたけどこの遷移がひとつ抜けていたんですよ」ここでおじさんは再び攻撃を繰り出してきます。
「なんだ。じゃあひとつ忘れただけ？」

いや結構ですよ、結構なバグですよ、その遷移をひとつ抜かしたせいで我らの設計したシステムは5000品目の商品を扱う発注システムで1品目ずつしか注文できないというすてきな仕様になっています。他のメンバーはちゃんとこの致命的バグを認識しているのに？このまま発注したら大惨事だけどその認識で本当にシステム開発を依頼する仕事をなさるのでしょうか？絶対一緒に仕事したくないなとか思いましたが世の中そういうものなのかなと考えさせられました。
社外を知るという目的は達成されたと感じています。文字通り知見が広がりました。世の中色んな人がいるんだ。べんきょうになるなあ。研修にいってよかったなあ。研修の後会社に帰ってきたら会話がつつがなく進んでいく環境に感動を覚えました。弊社はすごい！研修カリキュラムはまだあと1日残っていますが既にすごいおじさんと遭遇できているのでたいへん貴重な経験ができました！みんな社外研修に行こう！絶対に許すな！

良いチームは良いふりかえりから

今日は前向きに、ふりかえりについて書きます。

良いチームは良いふりかえりから

毎スプリントの終わりにやっている、ふりかえり。
その中で最近やってよかったことを紹介します。
（社内の開発チーム向けLTで発表した内容です）

agenda

ふりかえりは以下の流れでやります。

  1. Tryのふりかえり、エターナルキープ
  2. 今週の自分コーナー
  3. KPT（いつもの）
  4. Tryを朝会で毎日確認

1. Tryのふりかえり&エターナルキープ

KPTしても、せっかく出したTryするする詐欺になることがある。それはもったいないので、Tryをやりっぱなしにしないために、必ずTryのふりかえりをします。

  • 先週出したTryはTryできたか？
  • TryしたならProblemは解決したか？

をみんなで話し合います。

  • よくなかったらやめる
  • よかったら継続する（キープ）
  • 意識しなくてもできるくらい身についたら、エターナルキープ(EK)へ移動

エターナルキープとは文字通り永遠のキープです。
そしてエターナルキープの数はチームが挑戦してきたことの数、チームが積み重ねてきた軌跡そのものです。
たまにまとめて見返すと、達成感でしみじみします。

2. 今週の自分コーナー

ただのKPTでは飽きてきたのでなにか新鮮味を、という時に出てきたTryのひとつ。
ふせんに「今週の自分」を絵で描いてひとりずつ発表します。
とてももりあがります。アイスブレーク的な立ち位置です。

ここで書くのはなんでもあり。人物画から抽象画まで個性が際立つ。内容もプライベートなこともOKとしているので、個人のことをよく知れてコミュニケーションのネタにもなったり。
基本的にワイワイ楽しくやります！

3. KPT（いつもの）

ここからいつものKPT。ですが良いチームのふりかえりはここが違う。

  • Keep：みんなで喜ぶ
  • Problem：みんなで反省する
  • Try：チームで改善したいものをひとつ以上決める
    • やる。で終わらないやつ
    • みんなでやれるやつ
    • やる気のあるやつ

良いチームではK/Pどちらもたくさん出てきます。特にK。その週にチームで起きたことをみんながわかってるから、他の誰かが出したKもPも自然に自分事になる。

そして最大のポイントはチームで改善したいものをひとつ以上決めることです。特に、誰かがやるのではなくチームとしてやることというのが大切です。

たとえば超具体的な例ですが、

  • P：残業が多い。つらい→T：朝のうちに今日やることのゴールを決めておく。ここまで終わったら帰ろうの流れをつくる
  • P：ベロシティを上げたい。モブプロ全員でやるのはちょっと無駄が多いのではないか→T：4人チームなので2人ずつのペアに分かれて作業してみよう

のような取り組みをしました。これももちろん前述のように、スプリントの最後にふりかえりして成果が出ているかどうかを確認します。

4. Tryを朝会で毎日確認

Tryするする詐欺になりがちなもうひとつの要因として、Tryを忘れる、一旦ふりかえりが終わったら次のふりかえりまで見直さない…というのがあると思います。それを改善します。

  • 朝会チートシートに「Tryの確認」を入れる
  • Tryできてるか、毎朝みんなで確認

できてると「おっTryできてるじゃん〜」て元気になれます。
毎日確認されるので、忘れてると思い出します。
最終的に次のふりかえりでまた確認されるので、これはやったほうがいい！と各々が思ったことは自然に取り組むようになったと思います。

まとめ

ふりかえり、ちゃんとやってますか？惰性になってませんか？ この中で自分のチームでも取り入れられそうな要素があったら、ぜひ取り入れてみてください。ふりかえりが面倒になってきたとき、なにかひとつ新しいことをやってみる、それだけでもチームの空気が変わるきっかけになると思います。

良いチームは良いふりかえりから！！！
良いチームを作っていきましょう！！！

心の余裕を持ちたい話

先週のHUGっと！プリキュア23話で「30過ぎた大人には仲間なんていない」と発言する敵キャラが現れて物議をかもしていましたが、心の余裕がないとこうなってしまうのかなあなんてそこにある程度の実感を伴ってしまうあたりがつらい年頃です。

忙しいと余裕がなくなる。 余裕がなくなって良くないことのひとつに、「自分はこんなにがんばってるのに」という意識で苛立ちが他責の方向に行ってしまうことがあると思う。 同じ案件に関わる人たちのはずなのに、自分の周りとそれ以外で線を引いてしまう。自分の内側、その線より向こう側が外側。
だんだんと外側の人や作業に対して「わざわざ時間取って○○したのに」みたいな意識が出てくる。

「自分の案件は忙しいのに」
「自分のチームは忙しいのに」
「自分は忙しいのに」
自分の内側にある範囲がどんどん狭くなっていって、関連するチームやチームメンバー、一緒にやっているはずの人たちのことまで外側においてしまう。

仕事が果てしなくうまくいっていないとき社会人歴2年先輩の友人に「自分以外の人が全員自分をバカにしているような気がしている」と相談したら2年前に通った道だと言われたことがあるので、大抵だれしもみんなこういうことがあるんだろうなと思う。
とにもかくにも、進捗に安心感があるかないかだけでこのへんの心の余裕は全然違ってくるので見積もりとリリースプランニングをやりましょう。考えて見える化しておけば不安もやわらぐ。見えないものが不安になる。見えるものは怖くない。

もういい大人なんだから感情的にならずに仕事したいと思うしなるべく笑っていたいと思うけど、どうしても余裕がない時は苛立ったりしてしまう。というか結構感情が出る方なので落ち着きたい。空気を悪くして良いことなんてひとつもないと頭ではわかっているつもりだけれども全然ままならない。

チーム崩壊の足音一覧

スクラムなチームをうまく作るための手法を考えていたのですが、残念なことに、逆にこれが起きるとチームとしてヤバいという知見のほうが溜まってきたので書きます。

チーム崩壊の足音一覧

今日は3つ書きました

1. 仕事がチケットで表現されていない

プロジェクト始まりたてのときとかリーダーの立場の人にありがち。決して働いていないわけじゃないというかむしろがんばって進めてるはずなのにバーンダウンしていない、あるいは何をしているのかわからないのに一日が終わってしまうという時はこれかもしれない。

解決策：見えないタスクをチケットにする

後から追加でもいいからやったことをチケットに表現する。ストーリーポイントを振る。やったことをチームメンバにアピールする。

2. 各々の仕事を分業しすぎ

わかりやすいのはコーダーと調整役とか。
進捗が差し迫っていると特に、つい得意分野ごとにタスクを振りがちになってしてしまう。
ただし、ここで分けすぎると自分の仕事の範囲を守りに入るので危ない気配がする。
チームの目的はサービスに必要なものを開発することで、個人のタスクが終われば終わり、ではない。チームはチームでいよう。

解決策：極力ペア作業で進めるようにする。

これだけでとりあえず個人の仕事という形はやめられる。
少なくともペアのメンバ同士では認識を合わせるためにコミュニケーションを取るので、なんとなく一体感が出てくる。 ペアをシャッフルしたり朝会もペアごとに喋ってもらったり、このあたりは工夫がいるかもしれないけど、この一体感をチーム全体まで広げられるとチームとしての体裁が戻ってくる。
リーダー的な立場からも、ペアごとにタスクをアサインされているので、全体のうち進行中のタスクの見通しがよくなる感じ。

3. デイリースタンドアップやふりかえりをさぼる

なんとなく朝会やってないとか。ふりかえりに活気がない、惰性でやってる、進捗やばいから今週はふりかえり飛ばそう、などなど……

解決策：やばくてもイベントは極力ちゃんとやる

今日中にリカバリしないと無理〜〜〜みたいなとき以外飛ばしてはいけない。今日がだめなら明日には絶対やろう。
実際にこれやってるときとやってないときを比較すると実感としてわかるんだけど、こういうイベントをちゃんとやるということは、やっぱり大事。アジャイル開発のパターンを崩し始めるとチームがけっこうヤバいなという感じがしてくる。
自分はスクラム開発のやり方しか経験してないので、元から周りがそういう活動をやってるのを見ようみまねでやってたけど、こういうイベントでチームの空気ができていくんだなあ、昔の人はすごいなあなどと思う。

以上です

いかがだったでしょうか。
これは実体験に基づく見解なので非常に局所的なものだとは思いますが身近なところでこういう傾向があるときは注意しましょう わたしも次回この傾向が出てきたら気をつけようとおもいます
と言いながらも今まさに全部にあてはまるとても危険な状態なので、ここに書いたとおりひとつずつ立て直して、なんとかチームになりたいと思います。
しかし二人チームというのは難しい……先述したチーム内ペアともちょっと違う感じがするので、二人でどうチームを作っていくかというのは次の課題。

自分で自分の機嫌を取る術

あー。最近いそがしいですね。仕事たいへんですね。
余裕がなくなると、イライラしたり悲しくなったり人への当たりが強くなってしまったりしてしまいます。そういう日が増えてしまって帰り道でひとり反省会しています。
そうやって感情に振り回されると余計に疲れる。ひとり反省会するのもまあまあストレスだし。情緒が安定してる方ではないので、そこそこ感情に振り回されています。
自分の面倒は自分で見ろよということで、自分の感情が荒れていることを感じたらそこに理由をつけよう、という話です。
これはしばらく前から下書きに置いてあったエントリなのですが、気持ちが全く追いついておらず最近はなにひとつできていないので自戒を込めて投稿します。


例えばイライラした時に

  • 「自分はいまイライラしている」と気づく
  • 「イライラしているのはなぜなのか」と考える

メタ認知というらしい。
メタ認知 - Wikipedia

まず「あーいま自分めっちゃイライラしてるわー」って頭の中で言う。そしてその感情に、自分なりの理由を見つける。
これやるだけでもけっこう楽になる。

「なんかイライラする」→「お腹すいているからかも。おやつ食べよう」とか。
「気分が滅入ってきた」→「そういえば昨日寝不足だった。諦めて今日は早く帰って寝よう」とか
「なんてことない指摘ですごく悲しくなった」→「ちょうど頑張ってた作業だから過剰に捉えちゃったな」とか
そういうかんじ。なんなら気休めでも良い。

あるいは
「いま人の意見をネガティブに捉えてるな」と気づいた上で
「新しいことをやる時に不安になるのはありがちな感情」とわかれば
「今までと違う、やり方のわからないことだからやりたくないって感じてるんだな。でもやる気がある人がいるし、挑戦してみても良いかも」とか、仕事の中でも感情から距離をとって冷静になることでうまくやれそうな気がしたりする。

楽に生きよう

意識が逸れやすい人間なので、理由つけて納得感が得られたりちょっと目の前ににんじんぶら下げたりするだけでも案外なんとかなってる。
世の中こういうのをみんな結構あたりまえにやってるのかもしれないけど、わたしは社会人になってからこういう技を得た。とにかく楽に生きたい。

一日に取れるコミュニケーションの量には限界がある

というツイートを見て、わかる〜〜と思う日々。

最近なんだか人としゃべるのが仕事の大半という感じです。 チームでスクラム開発やってる以上コミュニケーションは必須、というかメチャクチャ大事。
要件の確認・調整、設計はホワイトボードで、製造はペアプロ・モブプロ。スクラムの活動、朝会・ふりかえり・プランニング。個人でもくもく進められる作業なんてごくわずかで、大抵のことはコミュニケーションが必要。 そして今の案件はとにかく時間がないので、ほぼずっと人と話してるようなかんじ。

そうすると定時になる頃にはどっと疲れる。よしコード書くのに専念するぞーと思っても、午後いっぱいペアプロするともう定時過ぎたら人と話したくなくなります。
とはいえ現状が現状、進捗が遅れている上にトラブルも起きている状況ではやむなしということで先週からずっと頑張ってましたが、職場のソファで座った瞬間無になり、一週間無理やりキャパを超え続けていたことを感じた昨日。

どうにもならないなりに解決策を考える。
で、なんとなく「声かけ」に心のハードルがある気がする。 疲れたけどやらなくちゃなーでも声かけるのだるいなーと思ってグズグズする時間があるので、ペアプロの時間は事前に決めておくことにした。事前にわかってれば心づもりができるので。来週からやる。
このへんをチームメンバーと共有してうまいことやれるようになりたいな。なるべくなら楽に働きたいので、自分の感覚のクセを理解して上手にコントロールできるようにしたい。

どうでもいいけど最近ラップバトルにはまっているので文章を考えるたびについ韻を踏もうとしてしまう。ただし特にセンスはないという現実。なにか書くたびに無駄に時間をかけている。どうせ今日も働くしかないんだ（CV伊東健人）
ちなみにうちは通勤快速止まるよ。

状態遷移表を作る

つくる！

  1. イベントリスト作成
  2. 状態遷移図作成
  3. 状態遷移表作成

の順でつくります

イベントリスト作成

仕様書から、イベントとアクションを見つける。

  • イベント：なんらかの処理とか日付とか。業務を行う上で起きるいろいろなこと
  • アクション：イベントによって起こること

というざっくりした理解。イベントの表現が難しい

漠然と、契約管理のシステムを例にして考える

イベント アクション
申込 契約を作る。契約が申込中状態になる
契約予約処理 契約が契約予約状態になる。月額商品を翌月1日開始で作成する
月初 契約が契約中状態になる。月額課金の開始

状態遷移図作成

状態を取り出す

  • 申込中
  • 契約予約
  • 契約中

状態から状態に行く矢印をひいて、アクションを書く

  • [なし] -申込-> [申込中]
  • [申込中] -契約予約処理-> [契約予約]
  • [契約予約] -翌月1日-> [契約中]

ここまでだと矢印が一方通行なので、たとえばキャンセルとかはあるのか？とか考える

  • [申込中] -キャンセル-> [？]

ありそう
なしに戻るのか、キャンセル済という新しい状態があるのか迷う。とりあえず新しく作ってみる。
アクションがキャンセルとなしで同じなら、一緒にしてもいいかも。

  • [申込中] -キャンセル-> [キャンセル済]

全部つなげて書いてみる

graph LR; a>開始] --> none(なし); none(なし) -->|申込| ordered(申込中); ordered(申込中) -->|契約開始処理| reserved(契約予約) reserved(契約予約) -->|翌月1日| engaged(契約中) ordered(申込中)-->|キャンセル| canceled(キャンセル済)

状態遷移表作成

イベント/契約の状態 なし(s0) 申込中(s1) 契約予約(s2) 契約中(s3) キャンセル済(s4)
申込 契約を作成/s1
契約予約処理 月額課金商品を翌月1日開始で作成/s2
翌月1日 s3
キャンセル s4

契約予約→契約中の遷移、月額課金は自動で始まるのでアクションではないかな…と思ったので、状態が変わることだけ書いた。

埋まってないところを考えて、全部埋める。
イベントが起こりえない場合はx
イベント起きるけど、なにもしない場合は/
を書く

イベント/契約の状態 なし(s0) 申込中(s1) 契約予約(s2) 契約中(s3) キャンセル済(s4)
申込 契約を作成/s1 x x x x
契約予約処理 月額課金商品を翌月1日開始で作成・s2
翌月1日 / / s3 / /
キャンセル s4 月額課金商品を削除・s4

翌月1日はどの状態でも起こり得るのでなにも起きない場合は/を書く。
申込は契約を新しく作るので、契約なし以外の状態では起こりえないはず。 契約予約キャンセルがありそう。ある想定で書いてみる。

このあたり、書いてなかったらサービス仕様書に反映してもらおう

graph LR; a>開始] --> none(なし); none -->|申込| ordered(申込中); ordered -->|契約開始処理| reserved(契約予約) reserved -->|翌月1日| engaged(契約中) ordered -->|キャンセル| canceled(キャンセル済) reserved -->|キャンセル| canceled

図もこんなかんじに修正

イベント/契約の状態 なし(s0) 申込中(s1) 契約予約(s2) 契約中(s3) キャンセル済(s4)
申込 契約を作成/s1 x x x x
契約予約処理 x 月額課金商品を翌月1日開始で作成・s2 x x x
翌月1日 / / s3 / /
キャンセル x s4 月額課金商品を削除・s4 x x

全部うめたー。
埋めると、このパターンどうだろうって考えるのでヌケモレがなくなる。はず。

所感

今まで見よう見まねで適当に書いてたので、型のお勉強でした。
結構すぐ状態遷移表書いてて、イベントリストや状態遷移図の段階を丁寧にやってなかったけど、やっぱ図のほうが読みやすいなーと思った。全部埋めるという意味では表を使うのが良いけど、見てわかるのは図が強い。
イベントが起こりえないのとなにもしないをあんまり区別してなかったのでちゃんと分けて書くようにする。

契約で話始めたけどこれ申込は別ドメインのほうが良くない？って途中で思ったけど書き直すのが面倒になったのでそのまま行った

参考

状態遷移表による設計手法（3）：状態遷移表を使用した要求分析モデル (1/3) - MONOist http://monoist.atmarkit.co.jp/mn/articles/1207/11/news001.html