よく噛んで食べる。

スクラム勉強会に行ってきました

@rinunuさんに誘いいただいた、スクラム勉強会に行ってきました。幹事の@matsukazさんとは少し前からmongoDB周りで色々お話させていただいていたのですが、この日が一番しっかり話したかなぁ。。行動力の素晴らしい方です。見習いたい。今回の勉強会はタイトルほど、すくらむすくらむしていなくて、アジャイル開発ってなんすかー( ﾟдﾟ)って人でも、とてもわかりやすい（であろうと思われる）プレゼンを聞くことができました。以下、メモの転載です。【@unlearnedさん】遅刻しての参加だったため、最初の方はお聞きできませんでした・・・ただ、結構な勢いでウォーターフォールをdisってたのが印象的でした。米国防総省ってそんなにウケるキーワードだったとは知りませんでしたｗ＜まとめ＞● ウォーターフォールはシステムの学習には有効　　→理解しやすい順番ではある。● アジャイルプロジェクトは大規模プロジェクトでも有効　　→米国防総省でも取り入れられている● 人は要求をあらかじめ定義できるほど賢くない● 整備されたドキュメントと、プロジェクトの成功には、弱い関係しかない● ウォーターフォールは失敗するやりかた（所感）個人的には１、３番目が分かりやすくて納得でした。いつも痛感するのが３番だったりするので、、、賢くない自分を補うためのベストプラクティスというか先人の知恵は、どんどん活用したいところです。国防総省なんやねん、と思っていたけど、国防総省がウォーターフォールモデルを標準として採用したことがその後のWFの広まりの発端？になってるから的な理由だったのですね。~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~【@bash0C7さん】★ アジャイルの先にあるもの「事業の成功」● アジャイル → "最速最高のプロダクトリリースサイクル"・アジャイル戦略室って組織がECナビさん（グループ）にはあるとのこと・事業のキモから・最速でpdcaサイクル● アジャイルざっくり・壮大なビジョン（の共有）・物語（ユーザーストーリー）たちで織り成す　　→ 物語がリリースの単位　　→ 付箋に書いて列挙・大事な順に一列に　　→ どれが一番大事なの！？　　→ product backlog　　　　→ 機能ごとにより詳細に(sprint backlog）・大事な物語に全てを集中・小さく分けて、確実に作る・実際に使ってもらって完成● スクラム（例としては3週間１サイクル）短い期間を繰り返す　　→ 次どうする？（スプリント）● アジャイルとは言うものの、、こんな失敗も・プロトタイプを捨てずに利用・小さく作りすぎる　　→ あるある過ぎて笑いながら涙目★ 重要な箇所から着実に動かす● アジャイル開発の事例[team]事業責任者/ドメインエキスパート/プログラマ/デザイナ？：ドメインエキスパートの役割は？　　→ そのマーケットに対して特に詳しい人。プロダクトオーナと同じ場合もある。プロダクトオーナ（事業責任者（/スクラムマスタ（やや外部）/チーム（作る人）・チーム→どれくらいで作れるか？・ヒエラルキーではなくフラット● ふろしきをしまう　　→ ひろげまくった夢をリリースに向けて収束させる● 厳密なタイムボックス　　→ タイムボックスごとに必ず成果物を★ 毎週（タイムボックスごと）に成果物が出る　　→ ってことは毎週、何か問題が起こる。毎週悩む。　　　　→ その都度捨てる、相談する。　　　　→ 期日は守る（所感）「物語」という言葉は、新鮮でしたが、自分自身のプロジェクトを振り返ってみたとき、新しい機能、サービスを作る上で、「ある１シーン」を細かく詰めていくことが、成功確率の高い手法であると感じていたので、とてもハラオチできました。そこからさらに、タイムボックスを決め、期間ごとに成果物をだしていく、という所はこれからの開発ですぐ実践してみたいと思います。=====================================================以下、懇親会的なところでの話のメモ。・ペーパープロトいいよ　　→ 行動を口に出してもらう　　（わからない所が明確化できる）　　→ ゲームは難しいかもしれないけど、SNSとか、webサイトとかは有効な手法　　→ ペーパープロトで出た課題は何度か繰り返しペーパープロトで詰めていく　　　→実装する前に、具体的なイメージにいかに落とすか、それをチームでしっかりと共有するか、　　　そのための手法として、ペーパープロトはとても有効なやりかたに思えます。　　　ブレスト的に、みんなで画面を書いた図を持ち寄っても面白いかも、と思ったり。● うまいことプロジェクトをすすめるために・見積に嘘をつかないこと（ちゃんと現実を伝える勇気）・何を捨てるか/何に借金するか　　→producerの引き出しからより良い物を引き出す、一緒に解決策を考える・自分を定量化する　　→わからないことは、短期間で自分を振り返り、見積もりを出せるようにする・ドラスティックに変える時にはリスクがともなうことをきちんと共有する【アジャイル戦略室の生まれた背景】・チームとしてどうやるか、が重要　　→事業責任者、プロデューサーに対してどう伝えるか　　プロジェクトはエンジニアだけではない。　　他のメンバーの理解を得るためにもエンジニアのみで立ち上げなかった。・先行事例があった（UI戦略室）・他のメンバーと一緒にスクラムマスター研修に　　→相談しながら得るものがあった・エンジニア、デザイナ、ビジネスメンバーをチームとしてで立ち上げ・新規プロジェクトと一緒にやる、というところまで準備をして立ち上げ　　→成果を周りにわかるように伝えることが重要・稼働の２、３割をさくのにOKをもらう　　→片手間でやるより、堂々と出来る（これ重要）【上記の新規プロジェクトでやってみて】・毎週振り返りをやってる・工期の半分いかないくらいでゴールが見えてきた（もちろん課題込みで）　　→ このタイミングでわかることが重要、そこから調整しつつ、きちんと期日に成果物を。・開発者のスキルより「姿勢」が重要　　→ 話しあって、最高の落とし所を見つける　　→ ゴールに対して真摯な姿勢を貫くこと（一蓮托生）● その他・「どう作るか」「円滑にすすめるか」は別の話　　→ スクラムマスターは別チームの人がやるのが望ましい　これは聞いてて悩ましかった。いきなり同じような組織を作るのは難しい。　もう少し小規模に、でも成果を人に伝えられる方法は考えないといけないと感じた。~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~長くなりましたがめも終わり。懇親会でも色々と現場のお話を伺うことができて、とても有意義でした！一口にアジャイルと言っても、その組織のカラーに合わせることが重要だなと感じました。ゴールは「事業成果」であって、そのためのプロセスなので。無意識にやってたこと、新しい気づき、たくさんの勉強会でした。最後になりますが、発表してくださった@unlearnedさん、@bash0C7さん、取り仕切り頂いた、@matsukazさん、お誘いいただいた@rinunuさん、ありがとうございましたー！

月間段位UP賞もらった

→アメーバピグで遊ぶ本文はここからもらった。ぱぐ。今回は？ぬいぐるみらしい。先月そんな記事書いた気がしないけど。もう少しブログ書こうかいな。

アメンバー限定記事test

ピグライフ

http://twitter.com/#!/search/%E3%83%94%E3%82%B0%E3%83%A9%E3%82%A4%E3%83%95リリースお疲れ様です！！かわいさ満点ですね。Twitterでも期待値の高さが伺えます。

学

蹴球部の後輩の、今年新卒の学（K林こーち）と晩飯を、渋谷で食って思ったこと。● 何かしらの存在価値を出す● 一緒にいるだけで、感化される人は素敵（モチベーションが上がる人）● 何するにも自分次第改めて、重要な事を再確認させてもらったと、本当に感謝したいっす。自分のいいところも悪いところも、まっすぐな学を見ていると本当に写鏡のように色々思えてきて、すごく貴重な時間でした。逆に、僕が素敵だなと思う人は、上記のいずれも優れているな、というのも思いました。正直、スレたこと言っちゃって学には申し訳なかったかなと思うのですがまた少ししたら、お互いにプラスな話ができたら嬉しいなと思います。学、ありがとう。また飲み行こう。

ＴＧＳ

⇒joeさんの東京ガールズスナップへついやってしまっている

無題

何ができるか、は当たり前の事として。『どういう』経験をし、その中で『何を』したのか。が、大切かな、という話を聞いた。重要な事だと思うので、メモ。

心を整える。

心を整える。￥1,365楽天これ。実家に帰ったら父が「読んでもいいよ」って貸してくれました。でもたくさん折ったり、書き込んだりしちゃってごめん、父。買って返すね(^_^;)サッカー選手、長谷部誠さんの著書。記憶に新しいアジアカップの事とか、ワールドカップの時のこととかを絡めつつ「何を考え」「どう行動している」か、を短くまとめて書かれています。ので、読みやすいです。読後感としては、「真面目」「高潔」みたいに感じるところがたくさんあり、好き嫌いは人によって結構あるかもなぁという印象でしたが、僕個人としてはこういう「真面目」な人が大好きです。「試合は生き物」「考えは変わるもの」という言葉が出てきますが、そういった不確定要素があるなかで、結果を出すために行動する姿は本当に真似したい。あと、本当に僭越ながら、共感できる部分がとても多かった。サッカー選手として、人として、「バランス系」の人なんだなぁと改めて印象を受けました。「僕は弱い人間なので」的な発言がいくつか出てきますが、相当なメンタルの強さを、本書の節々に感じますｗ啓発書に相当するんだと思いますが、同年代のプロフェッショナルとして、とても刺激をうけました。以下、線を引っ張ったところ。頑張っている人の姿を目に焼き付ける集団のバランスや空気を整えるグループ内の潤滑油になる組織の穴を埋める運とは口説くもの夜の時間をマネージメントする息抜きも、度が過ぎたら時間の浪費関わる人全てを幸せにするつもりで働けば、その気持ちは結果として還ってくる「このあとは、日本寄りのジャッジで頼むよ」サッカーと、ほぼ同年代というバイアスが、かなりかかってるとは思いますが、とても心に響く一冊でした。おすすめです。

Androidからの

Android携帯からの投稿

評価

・事業軸　---（１）・スキル軸　---（２）ていう軸がもしあったとして、エンジニア/クリエイターの査定をする場合、ウェイトが　　（１）＞（２）になると、逆に可哀想なことになるなぁーとふと思った。んだけどどうですかね。事業優先だと会社はいいんだけど、その人が外に出るときすごく困る。っていう考え方だと、　　（１）＜（２）　　（１）≦（２）をキープしてくれる組織は、実はとっても優しいのではないかと思った。# 実際どうなんだろう。この書き方は違う気がしてきた。。事業成果を軽視しているつもりは無いんです。すごく大事なので。なので、その状況で、成果をきっちり出すことを僕らは意識しないといけない。でもその裏にある意図をいつでも考えるようにしたいですね、っていう。# まぁ意図がいつでもあるかどうかは知らないですけど。# 人によるし。

第2回 MongoDB JP 勉強会に参加してきました

昨日行われた第二回MongoDB勉強会に参加してきました。２？３週間前に@snamuraさんから「勉強会あるから話してみない？」と言われて、gkbrしながら資料作って何とか発表させていただきました。MongoDB勉強会資料 View more presentations from Hiromune ShishidoMongoDBの使っている部分としては、ユーザー情報以外全部、みたいな形になってます。負荷試験をする中での苦労話みたいなところと、ドキュメント（RDBでいうrecord）の設計周りについて軽く触れた形になります。もう少し具体的な数値とか、Java以外の所をきちんとまとめられればよかったのですがそこは反省点でした、、、他でお話しする機会があれば修正したい所です。@doryokujinさんのShardingに関する話は、特にshardkeyの決定に関する点が参考になりました。migrationに関して正直「やってくれる」くらいにしか考えておらず話を聞きつつ若干不安になりましたがｗ@bibrostさんのセッションではとにかく「Rogueいいなぁ」というのが印象的でした。このセッションでかなりScala熱高まったのは間違いないと思います。（個人的には特に）その他の方のセッションもとても面白く、前日ほとんど寝ていなかったですが一切それを感じること無く勉強会が進むくらい有意義なものでした。あとは色々試行錯誤の段階かなぁというのと、やはり「何かに目をつぶる」という判断をどこかでしながらMongoDBを選ばれているな、という印象でした。ドキュメントの4MB制限（v1.8以降で上限が16MBになりますが）であったり、何をどこまでEmbedするのか、可用性、バックアップなど、まだまだノウハウ？というかベストプラクティスは模索している感じでした。# ドキュメントデザイン談義はほんとに別途やりたいところです。# あとshardkey選びとかｗそのなかで、ログ解析以外の用途として、大規模なサービスでの利用事例になると思われる今回のTachyでの利用は、おそらく今後も何かしらMongoDBを使おうとする方に有意義な情報が提供できると実感しました。また自分が得たものとしても、一人で、あるいは社内で困っているだけでなくこうして外部の方と話すことで一瞬で解決したりすることがあったのが正直めっちゃ助かりました。拙いプレゼンだったと思いますが、それでも参加し、登壇できたのはとてもよかったと思います。とりまとめいただいた@doryokujinさん、会場を提供いただいた@understeerをはじめ、フューチャーアーキテクトの皆様、ありがとうございました！

アメンバー限定記事見積もり

支え

こーゆーことが無いと気付けなかった、と言うのも悲しいような気もしますが人との繋がりとか、一言で支えられること、心にゆとりができる事、ってあるんだなと改めて感じます。そーゆーとこだけは今回の地震に感謝できる事かもしれないなぁと思ってみたり。でも普段から感謝を忘れないことが大切ですね。気をつけたいです。iPhoneからの投稿

半期振り返りのメモ

メモ。・取り組みたい試作は小さく、１イテレーションに組み込むことから目標に　　→全部やろうとしてもできない、どうきっかけをつくるか・IFを作るときは、相手の理解度、理解のしやすさを考える　　→テストしやすいとか、使いやすいっていう視点でしか見てなかった。　　最終的には同じ意味だと思うけど、こういう考え方もあるのかと。・少しでも不安、気になるところはアラートを上げる　　→これは改めて。定期的に報告はいれていたものの、ふとした"不安"もアラートとして上げておくことがやっぱり大切。今になって苦しくなってるので。。反省。。・半期、チーム開発にコミットしたことはよかったかも　　→それによって出来なかったことも多々あったが、あれもこれも手をつけることで、自分への言い訳要素を作るのも良くなかったので。まぁバランスですが。・プロジェクトの前進に全力を注いだ→改善すべき点だが、目をつぶってしまった、こともあったが、『その時、走りながらじゃないと改善できないこと』もある　　→喉元過ぎれば・・・というのがまさにそれ。そういう匂いのするものについては、頑張ってその時解決させる、という判断も重要になる。結構重要なFBをいただいたと思うので、色々ごたごたあるけれど、忘れないうちに。状況が状況だけれど、しっかり考えて、バランスよく。

コーディング規約

これもメモ。先日の結婚式の帰りに、友人（メーカーでエンジニアしてる）と話してて聞いたこと。==============================================================================変数の頭にrv（メソッドの引数）とかthe（インスタンス）とかつけるように決まってる==============================================================================っていう規約だって。あーこれはたしかにいいかもしれない、と思ったけど今まで見たソースにはなかったな。rv_hogehoge　ってjavaだとやらないしな。。でも一目でわかるという意味ではいいなぁ。チームで開発するときに、最低限あったほうがいいルールってやっぱりあるのかなぁと思ったりします。もしくはルールなしでクオリティを担保する方法。模索中ですが。

プロジェクトの進め方

殴り書き程度ですがメモ。■プロジェクトの進め方・時間は掛かるけど、共有の時間は絶対に必要。無駄に多くしないための工夫は必要だけど。・仕様の策定にはエンジニアと、QAチーム的な人が関わるべき。順序はやっぱり　機能→デザイン　だと思う。全部最後は自分の責任と思ってやるべきだけど、だからって全部自分でやるのは無理。誰かが仕切ってくれる事は基本的にないので、何をすべきか考えて、思うことは全部自分が発信してやる。発信する人同士がぶつかったら、そこで相談すればOK。手を動かす必要のあることも、誰かにお願いする必要も出てくるけど、それをためらったらダメな場面もある。「やってください」といえることは大切なこと。役割分担なんてあってないようなもの。というか無いと思ってるほうがいい。プロジェクトのためにやるべきことは気づいたときやるようにしないとダメ。こういうのは、ディレクションの部類にはいるのだろうか。pmbok周りとか新ためて読みなおしたほうが良さそうだな。。あとは転びかけたところからどう起き上がるか、だが。何か得たものがあれば随時メモしよう。

アメンバー限定記事うれしかったこと

Re:

http://ameblo.jp/joe-ab298/entry-10798866093.htmlこの記事に自己レス。『shardingされたコレクションには1つだけユニークなインデックスを持つ事が可能です。そのコレクションには他のユニークなインデックスは存在しません。（_id を除く）』これが何を指してるのか理解できた。ユニークな、っていうのは結局のところ一意制約のかかっているkeyを作ることができる、ということに他ならないんですね。だから衝突するようなキーをinsertしようとしたら、duplicate！って怒られるように設定ができるようです。昨日、mongoTokyoなるカンファレンスに参加してきましたが、結局みんなatomic Operation使ってauto increment 的なkeyを自作してるみたいなのでその辺を使うと柔軟さの中に少し制約が加えられるのかな、と。なので、「unique:true」とした場合には、指定したshardKeyが重複することはないですよ、ということになるんですね。参考：mongoDB 日本語ドキュメント（インデックス）http://www.mongodb.org/pages/viewpage.action?pageId=5800049shardingしてても、shardkey以外にindexは勿論張ることができるんだけど、性能を引き出すに当たっては、indexもさることながら、shardkeyの設計？が重要です。結局「どのshard（かたまり）に取りに行くのか？」を決めるのがそのkeyになるので、shardkey以外を検索条件にするような場合には、複数台あるshardサーバーを横断的にスキャンすることになるので、find()は遅くなります。なのでそこで悩んだらデータ設計考え直した方がいいのかもね、っていう話もあるのかなぁと思います。まぁいろいろ考えて、試したことは、いくつかあるので、どこかに残しておこう。

近道

社長のエントリをreblog.成長の近道http://ameblo.jp/shibuya/entry-10817418818.html（引用）１．まねをしながら常に自分で考える。勉強する。２．何故そのやり方になったのか、そうでない方法が何故ダメなのかを理解する。３．理解できたら自分なりの変化をつけていく。４．理解した上でオリジナリティを追求する。これはまさに近道というか、pdca回すためのフレームワークというか、そんな感じじゃないかなと思います。特にやっぱり「２」が重要だなぁと最近思っていて、自分でも「詰めが甘かった。。」と反省するときには、「２」が甘かった、ということが多いような気がします。「３」、「４」は、自分の今を振り返っても、まだまだできてないかなぁ、と。「３」とか「４」とかはやっていく中で失敗もあると思いますが、失敗に感謝して、改善を続けたい。# 「２」に戻ったりするのかな。流れ的には。環境で言うと、これを「実践」できる所がやっぱりいいなぁと思います。なので、、、まぁそういう事ですよね。推して知るべし。ということで３月も頑張りましょう！（ぇ

ありがとうございますー★

きゃー！シナクラ先輩がプレゼントくれた！嬉しい！ありがとう！Tachy・Tappieのみなさまにもお祝い頂きました。# リアクション薄くてごめんなさい同期のみんなも忙しい中ありがとう。あんじが聞くから２回も言っちゃったけど、今年は100万って数字を目標に、頑張っていきます。それ以外にも色々目標はあるけど、まぁ笑顔で１年過ごせたらいいな。