今日ね、スプリントのレビュ・振り返り・プランニングの日だったんだけど。 今日のレトロスペクティブのファシリテーターが。「なんでKeepからなん？Problemからでもいいんじゃない？」って言うので。「じゃ、やってみようぜー」って。やってみました。 そしたら、みんなでチーン(´・ω・｀)ってなりました。理由がわかった。 KeepでもProblemでも言えることが「Problem」として出てくるんね。なるほどなぁ。 例えば、「ドキュメントを書くのに時間がかかった」という意見が、Problem First だと「なので、もっと早く書けないといけない」になって、Keep Firstだと「だけど、しっかりかけてよかった」になる感じ。 なので、Keep Firstの方が、良いポジティブな意見がいっぱい出て、場が楽しい雰囲気になるんだねぇと思いながら。お菓子食べながら。そう実感したよ。実感駆動！ ｢いま

OJT今年入社の新卒の方が大阪支社に配属になって｢いきなりどっかのチームにどっぷり入るより、色んなチーム見て回る方が面白い？｣ってことで、いくつかのチームを渡り歩くことになりました。 んで、僕のチームが2番目で、7月から1ヶ月間くらい一緒に仕事してました。 ｢このチームで学んだのはMind｣各チームを渡り歩く中で、毎回｢成果発表会｣って感じで、その1ヶ月で何を学んだかをみんなの前でプレゼンするんですけど、そこで ｢今回、このチームで学んだのはMindでした。技術も学んだのですが、それよりも、Mindの重要さと難しさを学びました｣ と言ってくれたので良かった٩(ˊᗜˋ*)و 何をやったかプロジェクトに参加失敗しても大丈夫な小さ目のタスクを渡してそれで学んでもらう、というのは1番目のチームでやってたので。 今回はチームが実際にやってるプロジェクトにメンバーとして参加してもらうことにしました。失

Geb面白いなーってつぶやきながら勉強してたら。 玉川さんが玉川さんを紹介してくれて。 ふむ。 りゅーじさんがひろこさんを紹介してくれて。 ひろこさんをお招きして社内Geb勉強会を開催しました。 ひろこさんのセッションを聞けて幸せなひとときでした。 ひろこさん。すごく分かりやすかったです！ありがとうございます！ りゅーじさん。ご紹介ありがとうございます！ さとりゅ。おぎおぎ。色々調整等ありがとー！ 日本全国とあと中国もつないでたかな？見に来てくれたみんなありがとー！ 僕は。実際のプロジェクトでGeb使ってみた話を実際のコードを見せながらお話しました。 コードは見せられないけど流れはこんな感じ。 スパゲッティパターン セレニウムで自動テストしようぜー！って言って、まず踏むのがこのパターンすね。 findElementとかでXPath使ったりしてもう何テストしてるかわかんないし、DOMに変更あ

リファクタリングしたよ 仕様変更のついでに。なんとなく思うところがあったのと、自分がコーディングしたいなーってので、ごいっとリファクタリング。テストはそのままに、ソースを跡形もなく書き換えてみました。 ウォークスルーレビューしたよ んで、今日一行一行説明しながらチームでレビューしました。けど、特に何も言われなかったなぁ。どうだったのか、明日のレトロスペクティブで聞いてみよっと。 時間かけすぎたよ 仕様変更の対応のためって考えると、時間かけすぎ！って感じなのだけどね。チームにこれを見せるのが、たぶん半年後のチームにとって価値がありそうだなと思ったのでやってみました。半年後に価値がなかったことに気づいたらそのとき謝るね。 守りに入るほどじゃないよ 何ヶ月か前にチームで書いたコードを、これが私たちの教典です！と崇めるようにコピペして他のプログラムを書こうとしてるけど、もっと読みやすくて変更に強い

振り返るだけのエントリー。 カウボーイコーディング バイト時代含めて5年くらいはベンチャーでカウボーイコーディングやらせてもらってました。自分が作ったソフトが売れなかったら会社が潰れるんだって危機感を持って仕事ができて幸せでした。XPを調べたりペアプロやったりもしたなー。 Waterfall その後SIerで3年くらい仕事したときに、エクセル方眼紙に出会いました。あんまあわないなーと思ったのだけど、入ったからには3年は続けよっかなと楽しみました。結局、色々勉強になりました。ここで一通りのWaterfallを経験できたのは良かったです。 Waterfall 2010 2010年の中頃に今の会社に入って、最初はWaterfallでした。その当時のやり方があんまり好きじゃなくて、スケジュール管理とかタスク管理とかを無理言ってやらせてもらいました。WBSとガントチャート作ってたっけな。 今考えたら

成功 なんとか無事にリリースすることができたね。みんな、厳しいスケジュールだったけど、よくやったよね。お疲れさま。さて、また次のフェーズに進もう。 といったときに必ず顔を出すあのあれ。 あれ？この設計、どうしてこうなってるの？要件に対して遠回りじゃない？ このメソッド、なんのためにprotectedにしてるの？privateじゃなくて？ 「前回と同じようにしてます」 ふむふむ、きたコレ。健全でいいね。 呪縛 成功って名前の呪縛。前回の成功の箱の中で次回も収めてしまおうとする。そうやって次に生み出されるものは、箱に収まるこぢんまり。 理由も考えなくなる。「前回成功したものを参考にしています」。だから間違えていても自分の間違いではありません。 何かを守ろうとしている大人って、そういうものなのかもしれない？ 疑い 僕らは常に過去の成功や現状を疑った方がいい。 この道は妥協して選んだんじゃなかった

自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる