久しぶりに仕事ではないコードを書いた
horesa.se に使われている horesase-boys の本文データを更新するための horesase-body というものをつくって1年間放置していたのだけれど、久しぶりに horesase-boys を更新したくなって立ち上げて、動かなくなっていたので修正をした。
Kaminari を使った
まず、画像を1000枚以上いっぺんに取得していたのだけれど、サーバに負荷かけそうだなぁと前々から不安だったので、 Kaminari を使うように変更した。
Kaminari は仕事のコードで使用していて、こういうコードを書けば良いというのがわかっていたのですごく簡単に変更できた。
以前は、触れたことがない(少ない)新しいものだったので、使うのに抵抗があっていれてなかったけど、今ではその抵抗感が信じられないくらいだ。本当に簡単。
こういう風に「食わず嫌い」的に使ってないけど使えば超簡単 みたいなものは結構多そうだなぁ。
そうそう、仕事のおかげでこういう気持ちになることが多くて、最近やっと RailsCasts を少しずつやってみるようになった。仕事で関わっているチームはどんどん良いチームになっていく感じがあって、すごく良い刺激を沢山うけるので、仕事のために使えそうなコードを覚えるのが楽しいと思える。そういう状態で Rails の勉強ができてとても幸せだ。
Rails4 にした
それからバージョンが古いのが気になったので Rails4 にアップデートしてみた。
はじめての Rails アップデート。
bundle update した
Gemfile 変更したあとに bundle install しかしたことなくって、その前に bundle update しないと関連Gemのバージョンを合わせられないっていうのにたどり着くのも時間かかった。bundle update がやってくれること初めてわかったかもしれない。
strong_parameter の対応をした
rails server したら attr_accessible で落ちていたので、該当行を消したら動いた。アッサリ！
3.2 -> 4.0 はそんなに update が大変じゃないらしいし、horesase-body は小さいから直すとこも少ない！
params[:horesases] を each して直でパラメータを設定して save してて、strong_parameter 使ってなくても保存できて大丈夫かな…と思った。each して一個ずつ取り出して save してるとこはどういう書き方が適切なんだろうなぁ。（そもそももっと簡単な書き方ありそう）
DEPLECATION WARNING がいっぱい
rake build したら DEPLECATION WARNING が3つくらい出た。
機能的には動いてたので、rails server の時にも出ていた config.whiny_nils だけ対応して終わった。
気になる
Rails4.0 を rails new した時に生成されるものと、Rails3.2 から 4.0 にアップデートした状態のものでは、config 配下の設定値や Gemfile の中身が全然違う気がする。update の時はここは直さなきゃいけない っていうのを掴むには、やっぱり 4.0 での変更点をチェックしなきゃいけないのかなあ。rails new で生成されるファイル見比べるのは骨だしな……
EPISODE #400 What's New in Rails 4 のASCII CAST の日本語(旗から飛べる) 見て確認しよ。
…と思ったらなんかまさにこれっていうのあったー！！
EPISODE #415 Upgrading to Rails 4
- 研修の時に聞いた「Rails は scaffold をしてみると書き方の違いがわかる」っていうのはなるほどだった。前にも聞いたことある気がする。
今日はこれで終わり
警告残したままで終わったけど、「こうやって一個ずつ解消していくんだなぁ」っていうのを少し実感できてよかった。
イミテーションワールド #prfm
http://www.adventar.org/calendars/126 の7日目です！
断腸の思いで決めました。どちらを書くかほんとうに悩んだ！！
こうして好きになっていった
PerfumeにハマってYouTubeで動画漁りをしてしばらくした頃、聴いたことがない曲の動画がたくさん入っているリストを見つけました。Perfume初期のライブ映像っぽくて、ヤスタカサウンドと完成された無機質な声が好きだった私は 生歌ってあんまり興味ないなー と思いながら聴いていました。そこで私は大好きなこの曲に出会ったのです！！
その名も カウンターアトラクション！！
カウンターアトラクション!?
どこか暗い曲が好きなんですよ！ 明るい短調、イントロでの転調、衝撃の暗い歌詞、寂れたメリーゴーランド感！ 私のど真ん中ソングでした。
意味
http://en.wiktionary.org/wiki/counterattraction
counterattraction (plural counterattractions)
Something that vies for the attention of a person or thing in competition with something else; a rival for preference.
ションションメドレー
最初は実はイミテーションワールドって気にならない曲だったのです。Aメロがかけ出しアイドルソングっぽい印象をうけて、そういうのがあまり好きではなかったから。でもリストを何周かするうちに気付いたわけです。カウンターアトラクションの前にイミテーションワールドがないとしっくりこないと！ これはどういうことなの!?
カウンターアトラクションはイントロで転調しているのですが、これってもしかしてイミテーションワールドとのつなぎなの？ もしかしたら偶然そうなっただけかもしれないし、メドレー用にアレンジしたのかもしれない。どちらにせよこのなめらかさは素晴らしいものだと思いました！
それからイミテーションワールドとカウンターアトラクションをセットで聴くようになって、イミテーションワールドも私の中で遊園地に通ずる世界観を確立していって、Aメロへの苦手意識が薄れていって、サビに入るときにウオーーってなるようになったわけです！
イミテーションワールド！
よく聴くようになってから歌詞も調べました。これも暗い感じするじゃーん！ 好物じゃーん！ 素敵じゃーん！
サビに入った直後の「あー イミテーションワールド」の部分は少し物悲しい感じのメロディになっていて、ここがグッときます。いや、それよりもサビに入る直前！「ファ ♭シ ♭レ」 ってあれがヤバいです！ これがもうグッと来るヤバい！！
余談
Perfumeメドレー入りのDVD
2007年に出ていたDVDが高騰したものがAmazonにあったのだけど新品あるなら新品がほしくて、3万円とかで悩んでいたのでありました。中古でも1万5千円とかするしな…
YouTubeで良いっちゃ良いんだけど、YouTubeのはいつ無くなっても不思議じゃない不安感があって、ほんとにほしいものはハードで手元においておけるのが幸せと感じるのでした。
Perfume動画漁りをはじめたキッカケ
アルバム GAME を持っているので、マカロニ聴いたことあったはずなんだけど全然覚えてなかった。
チョコレイト・ディスコが好きじゃなくてこのアルバムあまりきかなかったからかなぁ。
あと、本来ドツボといえる曲以外は映像から好きになることが多くて、マカロニも多分そうだったんだろうなー。CDで聴いただけだと退屈していたように思う。聴いて映像が思い浮かぶようになって自分の中に世界観ができてはじめて好きになるもの、あります。
Chrome で console の拡大縮小をするショートカット
偶然見つけたので書いておきます！
| 拡大 | 縮小 | |
|---|---|---|
| 画面 | ⌘+ | ⌘- |
| console | ⌘^ | ⌘- |
- 縮小のショートカットキーが同じなので、最初に拡大のショートカットキーを押すことでモードを切り替えます。
みつけた時は画面拡大とconsole縮小の組み合わせで固定されてしまって画面はどんどん拡大されるし console はどんどんちっちゃくなっていくし焦った…（バグ？）
クックパッドの開発コンテスト24に参加した(初動編) #24contest
去年は楽しそうだなと思って眺めているだけだったから、今年は参加しようと思ったのでした。
今日は私が参加しようと思ったところから、チームを組むところまでのことを書きます。書くぜ。
0. 参加すると決める
いろいろなきっかけがあって、自分に対して「参加しなければ不幸になる」と思いこむ呪いをかけてしまったので、今年は参加しなければならなかったのだった。デッド・オア・参加 みたいな心理状態だったので参加を選ぶしかなかった。モチベーションからネガティブスタートだったので考えこむことが多かった。
1. 成功を定義する
必ず成功するためにはハードルを下げてかからねばならぬ！ めいっぱい下げるのだ！ ハイハイで跨げるくらいに！
成功の定義するときの決まりをつくった
他者を意識しない成功にする
そもそも勝負事がものすごく苦手だ。ライバル視されるのもするのも苦手。他人が関わる悔しい気持ちは嫌いだし憎いし消すために色々したくなる。なので勝負を回避したくて、それには他者を回避するのが一番手っ取り早い。だからコンテストの性質がある目標はダメ。競うとかダメ。自分が中心じゃないとダメ。
技術と遠い成功にする
できること少ないので！！
成功を定義した
ゆるく楽しくやる
時間と比較のプレッシャーが苦手で、ハッカソンはそのどちらもあるから苦手意識が強いのだと思う。成功体験と思うには絶対的に楽しくなければいけない、楽しいにはゆるくなければいけない、だからゆるく楽しく！
2. メンバーを決める
最終的には一人でも参加しようとは思っていたけれど、成功に辿り着けない感じがするので、できるだけ一人では参加したくなかった。
一人で参加したくない
一人で参加すると考えた時に、成功するイメージがまったくもてなかった。技術的な自信の無さが大きく、デジタルで叶えたい夢も持っていないので、いざテーマが発表された時に動けるイメージがまったくない。イメージの結果がゼロなら良いんだけどマイナス方向に振りきれていて、夕方の薄暗い時間に、電気をつけない部屋の中で、一人で陰鬱として泣きながらひっそりと諦める様子まで頭に思い浮かんでいた……(暗)
マイナスのイメージはまったく払拭できなくて、それだと本番も間違いなく引きずられる。なので、一人では参加したくなかった。
仲間をあつめたい
もともとチーム開発への興味が強いのと、一人で参加したくないのとで、仲間を集めることにした。
チームというものへの興味
私が仕事で開発をする時、何よりも重要なのはチームだと思っている。なぜならば私は一人では開発できないから。
チームっていうのはおもしろくて。人が一人欠けたり増えたりするだけで、空気が変わる。人が同じでもとりまく環境が違えばまた変わる。なのでどこへ行っても毎回新しい。メンバーの隠れた役割がみつかるとおもしろい。チームにあわせて自分の形が変わるのもおもしろい。自分が入ったことによってチームが変化するのもおもしろい。よくわかんないけどすべてがうまくいくように、ハマるタイミングがあるとすごく楽しい。
単純に人に興味があって好きなのかもしれない。
仲間がいればきっとできる
私ひとりじゃマイナスだけど仲間がいれば成功イメージができる
- ちゃんと作品として形にできそう
- ハッカソンっていうのは時間が限られていて、だいたい今できることしかできない
- 自分だけだとできることが少ないけれど、知識が違う人と一緒にやれば表現できる範囲が増えそう
- ゴール前に諦めずに最後まで頑張れそう
- 一緒に考えたりできるから、多少の停滞があっても停止してしまうことはなさそう
- ゴールできなくてもチームでやったっていう成果が残るから頑張れそう
「いっしょにやらないか」
もひゃ氏 と みぃお氏 に声をかけた。
みぃお（@ayako119）
GGJでおせわになったときになんかすごかったけど私はあまり力になれなくて、今度何かやるときはプログラマとして一緒に って思ってその時が来たのだったーー
もひゃ（@onjiro_mohyahya）
もひゃのスキルは全然知らないんだけど、もひゃが感動したことをきくと感動が伝染して感動するので共感値が(私から一方的に)高い感じで、今度何か感動しそうなことを一緒に って思ってその時が来たのだったーー
おいしいものをつくって食べさせてくれる ※重要
「けっしてがんばらない」
あとに糧になろうが何だろうが、いま失敗したくないし成長とかチャレンジより精神安定をはかりたい。
期待したり競ったりがんばったりっていうのを念頭におくのはそれだけで私はつらくて失敗に近い感覚になる。
完成したら嬉しいし目指すのもいいんだけどけっしてがんばりたくない。ゆるく楽しくできる範囲でやりたい。
そう言ったらふたりは うんうん、いい、いい って言ってくれたから一緒にやることにしたのだった。
それから、ゆるく楽しくするために「普通の生活の中にハッカソンを入れる」を目標にした。
食事はおいしいものを食べて。夜は寝る余裕があるくらいのもの作りたいね、みたいな。
「当日は時間ないからコンビニ弁当とRedBullかｎ「アカン！(かぶせ気味) もひゃにおいしいもの作ってもらうんや！」
初動編おわり
回避するとき全力で
こうして最初のことをふりかえってみると、私にとって、自分から「いっしょにやらないか」って言うのは必要なことだったのだと気づく。自分でやると決めて、どうやったら自分の中での成功に達成できるか考えて、そのために動くということ。私はコードで成功に近づける自信がないから、コード以外のアプローチで成功に近づく必要があったのだったーー。
結構な逃げ道であった。
書いたことと実際におこったことで違うこと
この記事の中では、参加決意するときに成功定義を意識しているけれど、実際には少しずつ心のなかに固まっていったもので、「成功」という単語で意識したのはコンテスト終了後だった。メンバー決めの章でだいぶ暗い気持ちが出ているけれど、それは成功定義が固まっていなくてハードルが高いままだったからこその不安だったのだーーー。
次回予告
気が向いたときに準備編みたいなの書こうかなー。
とちぎRuby会議05に行って殻殻でお話してきた #toruby
2次会の殻殻で関さんと池澤さんとおはなししたことをまとめました。
※教えてもらったことと私の解釈が混ざっています！
「今日気になったのあった？」ってきかれて
仕様言語を使うメリットがいまいちわからなくて「Cucumberと一緒なのでは…?」って言ったら
(池澤さんと関さんが t_wadaさんのトークの simple と easy について話していた流れで)
あれはEasyだよ悪いEasy。
だって「ログインできること」って書いてあったとして、そのアプリケーションのログインってなんなの？ TwitterとFacebook、Amazonでそれぞれログインしててできることに違いがあると思わない？
Amazonはログインしてなくてもログインしている様に振舞っていて、右上にはログイン情報が出てるしカートもそのまま使える。決済の時だけログインを求められる。「ログインしている」の状態ってぜんぜん違うでしょ。
Cucumberで「ログインできること」って書くとじゃあそれはなんなんだよってなるし、なまじ書ける分書いた気になるし（以下 Cucumber dis）
すごい！！ ほとんど意識したことなかったけど確かに Twitter のログインってほんとにログインしてないと有効じゃない感じするしAmazonって決済の時なんでいちいちサインイン求められるんだろうって思ってた！！
（Cucumber disってたイメージあるけど私が仕様言語と雑な比較したせいかもしれない）
仕様言語を使うと仕様の検証ができる？
「仕様言語とXUnitでの検証が対になってるのが良いんですかね…?」「まあそうかもね」
みたいな話をしていて、その時点で私は仕様言語で書いたものは動かして検証しなければならないから結局XUnitで書くのと変わらないと思っていたんだけど、仕様言語で書いたものは検証じゃなくて「そのようにつくること」っていうまさに仕様書であるのでした。
仕様言語で書かれた仕様は厳密で、それがあるだけでコードの書き方とかできるものが違ってくる。そこに意味がある。XUnitは検証項目を書いても本体を実装しないと動かないし、動くものがないと細かい検証も書けないけど、仕様言語だと本体の結果である「RESULT」っていうものがあるから動かなくても事後条件が書ける。つまり仕様書を書いているのと同じー！（仕様書だってさんざんきいてたのにやっと理解した）
仕様言語で仕様を書こうとすると曖昧な部分を追求して考えなければいけなくなるから、書くこと自体に意味がある。つまりそれ自体が検証プロセスとなるなのだなぁと思った。（そういえばXUnitの検証ってコードの検証であって仕様の検証じゃなかった）
仕様の役割とテストの役割
「仕様言語で書くのは事前条件と事後条件だけ、実装するのはここだけ」
最初に仕様と検証とは対であるべきものなのかなと思っていたけれど、以前せきさんにテストの話をきいたときに、モデルテストを必要としていなかったのでその差が気になりました。でも私がイメージしていた対であるっていうのが間違いでした。（と最終的に自分が感じた）
実装は仕様を見て書いてるんだからそれを信頼すればいい、テストで見るべきなのはそれらが組み合わさってどうなっているかということ。ソフトウェアとしての振舞をテストするべき。モデルの試験では品質は上がらない いやあがるのかもしれないけれど「でも意味ないじゃん、そういうふうに書いてるんだし」っていうのをきいてなるほどと思った！
例えば複雑な計算が必要でテストがないと不安なロジックがあったらテストを書くのは妥当かも。
でもそれが不変で切り離せているロジックなら、テストを残す意味は無いかもしれないなぁ。
あと、API的に使われているものであればテストがあるのは良い気がしました。
例えば何かのgemでバグが発生していて一個のメソッドを修正したいとき、だれの環境でも動かせて結果が確認できるようなもの…あっ！ 使う人の環境が絡む仕様書はテストコードで書いた方が良い気がする！ 大発見だ…!! 私すごい…
仕様はどこに書くのか
モデルテストの話をしていて、この前はじめてモデルの試験を追加したのを思い出しました。
「誰が見てもこのメソッドの意味がわかるように」という観点で追加して、テスト書いて動かした段階でバグ検出できたのだけれど、それを仕様書として残すのはどうなんだろう？ 例えばコメントで書くのがいいのか、ドキュメント化するのが良いのか、仕様書ってどう残すのが良いんだろう？
仕様ってどこに残すのが良いんでしょうか
「それは…プロジェクトによるんじゃない？ 誰も読まなかったら意味ないし」
(ﾟдﾟ)!!!
これは衝撃でした！ 書けば読むものと思ったけど、よく考えたら私テストとかほとんど読まない。（よくない）
「一番だめなのは『書いてあるじゃん』っていうやつ」(グサッ)
「それって『言ったじゃん』と同じ？」
「いやそれはそこでレスポンスが発生してるからちょっと違う」(レスポンスじゃなかった気がする…カタカナ語…インセンティブ？)
どこに書いたら仕様を読まれるんだろう
せきさんのチームは仕様書とか仕様に関してコメント書いたら、実際に使う人(仕様書の読み手)に向けて音読してっていうの。だから、読み手がいるものはその場でチェックされるし、読み手がいない仕様書は書かない（書けない）というの、おもしろい！
「将来の自分に向けてコメント書くって言うじゃん」
「…いるの？」(将来の自分!!)
ぬまたさんのチームで仕事をしていた時に、みんなに影響ある(使ってほしい)ロジックを書いたら朝会のあとでシェアするというのをやっていたなーと思い出しました。仕様を共有するっていうのはやっぱりそれなりに工夫が必要なんだなー。読まないしなー（よくない）
おわり
新幹線つらかったけどまた来たくなりました。とちぎ！
（この記事は Cafe Roimu からお送りしました。クロワッサンサンドめちゃうま）
vimで自在にファイルを移動したい
たくさんのファイルをvimを開いて移動したい
$ vi *.txt
って開いたとき
:n
ってすると次のファイルに行ける。C-o で戻ることもできる。
※追記※
C-o は前のカーソル位置に戻るけど:nで開いてたファイルに戻れなくなっちゃう！
:N →前のファイル :n →次のファイル
これでもとのファイルに戻るし、また次のファイルに行ける！
Rails で model とか view にヒョイヒョイ飛んでいきたい
任意の場所で :R ってすると一番それっぽいところに飛ばしてくれる
Bundle 'tpope/vim-rails'
:BundleInstall
例えば controller ファイルの new action にカーソルを合わせて :R ってすると、対応する view のファイルを表示してくれる。view にいると対応する controller に飛ばしてくれる。
あと、= render ’form’ とかあるとき
挿入モードでもコマンドモードでもない状態(なんていうの？)で
form にカーソルあわせて gf すると飛んでくれる。便利！
読書感想文：XP再入門 (WEB+DB PRESS Vol.72) 第一章
感想書く気持ち
XP再入門、最近おともだちと読書会をしています。
読書会を始める前に[価値/原則/プラクティス]のあたりの読みあわせを行ったのですが、タイトルの抜粋だと内容がわからないものが多く(特に第2版)、実際に読み比べながら進めたほうが楽しそうだということでXP初版と第2版をAmazonで購入しました！ まだほとんど読んでいないのですが。
読書会は今のところ2回開催して、私は1回だけ参加しました。ゆるーく思うところを語れて良い感じがしています。
ですが、私は参加していて、自分の体験とリンクさせて考え込んでいることが多く、気付きとか意見交換よりもふりかえりの気持ちの方が大きくなっていました。人が話している時に考え込んでいて会話が抜け落ちてることが多いし、読書会するより1人で読んだ方が良いのかも…？
…と思ったので一度、1人で考えながら通して読んでみることにしました。
感想とか
XPが初版と第2版で全然違うときいて
XPは初版と第2版で対象者層に変化があるように思えました。開発チームからプロジェクトへ という印象で、内容も追加があってだいぶ変わっているように見えたので、なぜ「XP」という名前で改版したのかを疑問に思っていました。初版のXPを内包するものであってもそれは別物なのではないかと思ったのです。
ざっと第1章を読み終えたあとにXPの初版と第2版の序文を読んだのですが、紹介されている第2版の序文 "XP自体にXPのパラダイムをあてはめた" というのに第2版で出会った時に、わぁっと思うものがありました。XP再入門で読んだ時はなんだか気になるくらいだったのが、前後の序文を読むとわぁっとなります。ココすきー！ 初版のXPを自分たちの開発で用いてみて、フィードバックを得て、初版のものを変化させる必要があると思ったから第2版としたのだと解釈しました。
それと、第2版の価値に「尊重」が増えている所から、初版で大きく足りなかったことがそれなのかなと推測しました。「意識高い開発チームとレベル低い周りの奴ら」とか「1人一所懸命に頑張る管理者の俺とお喋りばかりする開発の奴ら」とかそういう感じになったのかな、とか。ありそう。想像が後ろ向き！
到達したいところ
足りなかった記憶
最近、思うところあってまとめていたことがあります。XPの話ではなく、今までアジャイル札幌の勉強会とか研修とか本を読んだりとかしたのと、自分が関わったプロジェクトをあわせて感じたことです。
背景：受託開発で上下関係や担当分野の違いによりチーム内でも距離がある感じ
開発者(作業者)だけで変えられる範囲で行うアジャイル開発は見通しの良さとか楽しさが得られても顧客に届く価値は変えられない。たとえばこまかくフィードバックを得るためにリリースやミーティングの回数を増やすとか、計画を必要なところから立てていくとか、そういう顧客とチームの両方の責任の持ち方や作業時間が変化するようなことは、お金が絡むのでお金の話をする権利がある人の理解が必要。
開発チームだけで変えられないってことは無いと思う(チームの形によっても違うと思う)けど、「変えられない」と断定調で書いたのは、私自身がなるべく広範囲の人と同調しないと目標に到達できなさそうだと感じたからです。
開発チームだけで同じ認識を持つのと、開発に関わるすべての人で同じ認識を持つのでは、実現できるものと実現可能性が違ってくるのかなと思っています。
顧客の価値というもの
勉強会や研修に参加して「最初は自分たちの出来る範囲で変えていく」というのを学びました。
色々とやり方も知って、自分ができることをやっていこうと思っていたのと同時に、私は「出来る範囲で変えられることだけが目的でも良いや」と思っていたのですね。
多分、いままではお客さんとの距離が遠かったし、成果品に対する責任もあまり感じていなかったから。開発(作業/成果)の質を上げることしか考えていなかったし、届ける価値＝開発の質 だと思っていました。
最近はお客さんと直接話す機会があったり、自分で考えられる幅が広いお仕事との出会いが多くて、「自分たちのできる範囲で変えられればいいや」だけではお客さんに届かないように感じています。それは直接見えづらいところが多いから届く価値にはなりにくい、というか、開発の質って高くてあたりまえなのかも…プロに頼んでいるわけだし…。
お客さんにとって必要なのはソフトウェアじゃなくて、その先の世界で何かが変わることなんですよね。なんか書いてて思ったけど、届けるっていうの違う気がする。一緒に到達するという感じかなぁ。あっ ここのタイトルに書いてる！(私すごい)
ここから考えると、今までは初版で満足していたけど今は第2版が必要 みたいな感じ(てきとう)。初版と第2版は到達点が違うんじゃないだろうかと思っています。開発品質と顧客の価値、みたいなもの。まだ読んでないので推測なんですけど！
XP自体にXPのパラダイムをあてはめたのにわぁっとなったこと
「XP自体にXPのパラダイムをあてはめた」 というので わぁっ となったのは、それが改善であることを示しているからかと思いました。到達できていないものをみつけて悶々としていた私には、ルールを自分自身に当てはめるのがとても良いものに思えたのです！ たぶん！
Kaizen mind~
著者の規世さんのチームの「プラクティスを常に評価する機構」(といった感じの問い) が自然な雰囲気で出るところ、素敵だと思いました！ ネガティブな要素をネガティブなままに伝えられる雰囲気が良い。めんどくさいとか意味がないとか、そういうこと。
ネガティブなままに伝えられないところの記憶
時に、過剰(≒不要)な努力でも美徳とするような環境に身をおくこともあります。そういう場所でめんどくさかったり手間に感じる気持ちを伝えると、怠慢だと一蹴されてしまうことが多いです。だからなんでこの作業やるんだっけみたいなのを1人で考えて、これこれこういう理由でこれはやめるべき みたいなのを無理矢理つくるんだけど、違うの、めんどくさいの。それで曲がった理由と目的は曲がった解決案を呼んでしまってめんどくささは解消できない、みたいなの、ありました。
ネガティブなままに伝えられるところの記憶
あるチームでは、毎週KPTでふりかえりを行なっていました。わたしはふりかえりが初めてだし、先ほど記載したような環境をいくつか経験したために、Problemを出すことを警戒して躊躇していました。
でもそのチームのふりかえりがおもしろくて、呑んだ時に終電を逃さないとか、早く帰るだとか、どんな内容でも出して良いという雰囲気を上手く作ってくれていて、すぐに馴染んだ覚えがあります。(馴染みすぎてたまに叱られた)
振り返りの時に「何がやりづらい」だとか「つらい」だとか気持ちに関わる部分を話せると、それをやめるのか、良くするのか、我慢してやらなきゃいけないのかということを話せます。本当のことを話しているので、曲がった解決案になることはありません。(解決しないことはあったけど) とても健全で、無駄がないように感じました。
私の好きなチーム
私は前述のチームに入って、チームや仕事への意識ががらっと変わりました。楽しまなくても楽しく働けることがあるんだなと思ったし、朝仕事へ行くのが辛くない働き方もあるんだなぁ、とも思いました。それまで、ものすごく辛かった、というわけでもないんですけどね。
規世さんのチームと、あの時のチームになんとなく似ている所があるように思っていて、それはフィードバックが大事にされているところかなと思いました。最初は「尊重」かと思ったけど、今XP第2版を見て、正しさとか改善とかは「フィードバック」に属す気がしましたし、尊重よりもしっくりきました！
（第2版と初版のフィードバックはちょっと違う？ 初版のは頭に入ってこない…）
おわりに
単語
- 顧客って単語がどうしても好きになれない（使ったけど）
- お客さんっていうのもなんか違う気がする（使ったけど）
- 最近、オーナーっていうのがしっくりきてる（使ってないけど）
書いた
満足した！
私のふりかえりを兼ねた読書感想文は私のふりかえりになってしまいます。満足しました。
2章以降はうまくあふれだしたら書くかもしんない
