2015/01に読み終えた本
正月に、2015年1月に読んだ本をブクログでふりかえる - delirious thoughts を真似て書いてみようと思っていたのを月末に思いだしたのでした。
今月は3冊…意識の低さよー。
アジャイルソフトウェア要求を結構読み込んでいたというのあるけど、もうちょい時間を作りたいですね。
正月に、2015年1月に読んだ本をブクログでふりかえる - delirious thoughts を真似て書いてみようと思っていたのを月末に思いだしたのでした。
今月は3冊…意識の低さよー。
アジャイルソフトウェア要求を結構読み込んでいたというのあるけど、もうちょい時間を作りたいですね。
第十六章「ベロシティの見積もり」 - AEP読書会 | Doorkeeper
2015年1回目でした。今回はGMOグループからも何人か来ていて、これも藤村さんのリクルーティング活動のおかげか!? と、私もがんばろうと思いを新たにしました。
今回のテーマの「ベロシティ」ですが、私自身あまりうまく使えないなーと悩んでいたところ、ディスカッションの中でいいヒントを貰えました。
PO(やマネージャ)としては当然できることが多くなるほうがいいので「ベロシティを上げるにはどうしたらいいか」という話になります。
一方で、開発チームとしては中期の見通しを立てるために「ベロシティを安定させたい」と思っています。
ここに歪みがあって、こじれてしまうと見せ掛けのベロシティ(完了条件をごまかしたり、過剰見積をしてベロシティが上がったように見せる)にチームが走ってしまったら元も子もないので、今までは「ベロシティは安定させるもの」というスタンスをとってきました。
ディスカッションの中では、ベロシティは無限に上がり続けることはないが、チームの限界近くまで上げて安定させるべき、という話がでてきました。
そう聞くと当然のことなんですが、回りの状況や、私自身が開発チームに近い場所にいるせいもあって「今だって一生懸命やってるよ」という気持ちが強かったんですよね。
でも、開発チームが工夫や調整、仕組みの改善を精一杯やってるか?って言われると、過去のプロジェクトを見ても胸をはって言えるプロジェクトってあんまりないし、そういう面では甘えもあったのかな、って。
Scrumの根っこ というスライドに「責任から逃さないのがSM」という言葉があって、こういう表現の仕方は考えたことなかったな、とハッとしたのでした。
「ベロシティを上げろ」という人には「安定させるものなんです」、開発チームには「どうやったらもっと早く進めるか」という二枚舌でいくのがいいんだなという自身が得られたので、今回もよい読書会でした。
夕方からプロジェクトの残作業棚卸しをしていて、@shikakunが見積りを計画に悩んでいたので、相対見積りやタイムボックスの考え方について話していました。
最初は私達プログラマがどうやっているかを説明していたのですが、話していくうちに「これ職種関係ないじゃん」ということに気付いて、それなりにいい話になったような気がします。
長期的なプランニングを考えるときは、それらをえいやっと足して計画をたてればいいし、イテレーションプランニングでは相対見積りを時間見積りにざっと変換して、タイムボックスのタスクと合わせて計画していけばよいです。
計画は最初に立てて終わりではなく、現実に合わせて変えていける、計画し続けることが非常に大切です。その為には、がちっと引かれたガントチャートよりは、相対見積りと絶対値の見積りをうまく組合せた「直近の計画は詳細に、長期計画はざっくりと」というアプローチがとれる、いわゆるAEPスタイルがすごくいいなーと思っています。
もちろんプロジェクトの性質や状況はありますが、普通の人が普通にソフトウェア開発をするのであれば、「計画通りに進めること」よりも、プロジェクトを通した学習によって起こる「変化を受け入れること」ができる計画やプロセスを採用したほうが、メンバーのモチベーションの面でもメリットが大きいと主観ですが感じています。
こんな話を10分くらいしていたんですが、そういえばうまく見積りと計画ができたのか聞いていなかった…
kenchan/rspec-default_https_header です。
APIサーバの Request Spec を書こうと思ったときに、毎回 OAuth のトークン設定したり、 CONTENT_TYPE: 'application/json'
とか付けるのは人間のやることではないので、もうちょっと簡単にできるようにしました。
最初は r7kamura/rspec-request_describer がいいかなと思ったんですが、ちょっと枠組みがエクストリームな感じなので、最初から導入したりえいやっと書きかえるならよかったんですが、もうちょっとゆるめのやつが欲しかったのです。
わりと便利だと思うのでよかったらお使いください。
話題の mookjp/pool をなんとか使いたいと思って、社内の仮想環境上で動かしてみました。
ペパボの社内用サーバは mizzy/maglica というツールを使って管理されてるんですが、まだCoreOSは実績がなかった気がするので、dockerが一番まともに動くであろう Ubuntu 14.04 上でチャレンジしたところ無事動いたのでした。
だいたいは、READMEにあるamazon linux用の手順でよくて、
scripts/init_host_server
を実行するというだけでとりあえず動きました。(2015/01/20現在)
社内ではCIにDroneを使っているプロジェクトがいくつかあるので、まずはその辺から使えるようにしていこうかと。
prevs.io - Your environment, just one click のエンタープライズ用がでるのはまだまだ先だろうから、社内でカジュアルに使える環境があると便利なんじゃないかと思っています。
Dockerの周辺技術はぜんぜんキャッチアップできていなかったので、ちょうどいい機会だからいろいろ勉強しよう。
ペパボではエンジニアの評価面談を技術基盤チームでやっているので福岡まで行ってきました。
ちょうどお昼に到着する飛行機だったので、まずはまぐろ料理紀文 (まぐろりょうりきぶん) - 天神/魚介料理・海鮮料理 [食べログ] というところで黒鉄火丼なるものを頂いた。
海苔の下はネギトロ的なやつなんだけど、めっちゃ山葵がきいてたけど美味しかった!あと、血合を煮たやつが無限に食べれて、これもめっちゃ旨かった。
夜は各自という感じだったので、行ってみたかった一人モツ鍋のお店 元祖博多麺もつ屋 - 天神南/もつ鍋 [食べログ] に。
最初から麺が入っていることもあって、焼酎1杯とこれでお腹いっぱいでした。カウンター8席だけなんだけど、味が2種類あるので2人できて分けてる人もいて、それもよさそうだなーと思ったのでした。
お昼は 天ぷらのひらお 天神店 - 天神/天ぷら [食べログ] 。
写真忘れたけど、説明する必要はないですよね。おいしかった。
夜は本気の鮨ということでかなり警戒していたんだけど、予約できなくて別のところに。
あんちぽさんの「面白いところと普通のところどっちがいい?」に満場一致で面白い方となったところ、 河太郎 中洲本店 (かわたろう) - 中洲川端/魚介料理・海鮮料理 [食べログ] だった。
呼子のイカ、初めて食べたけどこれはやばい。
お昼は 博多ごまさば屋 - 赤坂/居酒屋 [食べログ] 。
福岡のランチのおいしいところはなにかが無限に食べれるところが多くて、ここでは南蛮漬みたいなのが食べ放題でこれも旨かった。
夜は福岡メンバーと 海鮮食堂 すいか - 赤坂/居酒屋 [食べログ] というところでわいわいと。このお店、ぐるなび - 海鮮食堂 すいか(大名/魚料理) の写真がめっちゃ残念なかんじなんだけど、ふつうに美味しかった。いわしの梅揚げおすすめ。
その後は、二次会で近くのバーで3時くらいまで。おつかれさまでした…
お昼はpinkoさんとちんさつさんと スリランカ料理レストラン 不思議香菜ツナパハ&東方遊酒菜ヌワラエリヤ でカレー。
なにやらめっちゃ辛いということだったんですが、まぁせっかくだからと普通の辛さ(?)のやつを。たしかにかなり辛いけど、ココナッツカレーひさしぶりだったのでおいしかったです!
御飯のことしか書いてませんが、面談では初めましての人もたくさんいて、いろいろなお話を聞けてよかったです。
領収書とか保証書とかなんかいろいろ入っている押入れの中を全部出して一掃しました。
5、6年前に買った家電の保証書とか、賃貸契約書とか、数年前から放置されている常備薬とかいろいろでてきたのであった。
無いと思っていた精密ドライバーとか、ガムテープとか、コロコロの替えとか、だいぶ有益なものも発掘できたのでよかったよかった。
一回休みでした。
給料日の金曜日で社長のケンタロさんの誕生日会ということでレジェンド花金でした。
相変わらずエンジニアの人たちと最近どうっすかとか、評価面談どうでしたか、みたいな話をしていたような。
若者分を補給できたのでよかったかな。
ペパボでは半期毎に評価面談があるので、上長であるあんちぽさんと30分ちょっとおしゃべりをしました。
評価制度そのものは ペパボのエンジニア評価制度をパワーアップした ー deirious thoughts から変わっていないので、3つのポイントについて半年どうでしたか?という感じで進んでいきました。
技術基盤チームという特定のサービスに依存しないチームに所属しているので、実際に売上をあげている各事業と、そのユーザにどういう影響を与えられたのかが説明しにくいという話をしたら、「技術基盤チームにいるってことはそのロジックをちゃんと説明できないといけないよ」というコメントをいただいて、おっしゃる通りがんばりますという気持ちになりました。
あとは、去年やれなかったこととか、今思えばこうしたらよかったとか、今年はこういうのがんばりたいとか、そういう話をして終わり。
またすぐ2015年上期の目標をたてないといけないのだけど、これやったらすごいという目標をやりきれるようにがんばろう。