俺たちのペアプロ戦記

論旨

• いままでのタスクには困るところが結構あった
• いままでのタスクの進め方を改善していったら、ペアプロになった
• 最終的にペアプロになった
• ペアプロがなぜすばらしいかを言葉ではなく心で理解できた

従来のやり方

私のチームはそれまでこんな感じでタスクを進めていました。

• タスクの終了条件を決めてアサインされる。
• タスクの仕様を説明される
• プログラムする
• レビュー受ける

問題点

ところが新プロダクトの開発を上のフローで進めるうちに、問題点が噴出しました

聞く側

• プログラム中に細かいところを何度も聞きにいくのが面倒くさい
• 確認待ちで作業が止まる
• レビューが帰ってくるまでの待ち時間が長い。
  • 帰って来た頃には半分くらい忘れている
  • レビュー待ちの間に別のタスクを始めるので仕掛中のタスクがどんどん増える
  • レビュワーの指摘でタスクの仕様が変わる事がある その場合タスクが振り出しに戻る

聞かれる側

• 何度も聞かれて作業が中断される
• 聞くなら一回にしてほしい
• レビュー依頼の件数が際限なくたまる
  • すこしでもレビューを貯めてしまうと、レビュー待ちしている人が別のタスクを始めてまた積んでいくので、レビュー待ちが複利で増える
  • merge間隔が開く
  • レビュー未了だとmergeできないため、 main branch から孫ブランチやひ孫ブランチが発生する。
• 疑問点や質問を書いたり、細かく指摘を繰り返すレビューラリーが増える

問題の被害が無視しがたいレベルであり、作業スピードを悪化させました。 これでは目標リリース日までにリリースできません。 リリースできない場合、社長は激おこになり、我々はユーザーにその辺りの街灯に高く吊るされます

移行経過

我々はこれらの問題を解決すべく、いくつかのプラクティスを導入しました

• 最初の段階でgithubのIssueで話し合うようにした
  => 要件が固まるので質問に行く頻度が減った
• それでも話がまとまらない場合はホワイトボードで話し合った
• レビュー依頼したときに以下の事をすることでレビューの回数と時間を圧縮
  • レビュー依頼時に背景知識について5分程度で説明
  • 重点的に見てほしい場所をdescriptionに記述
  • 横に座ってリアルタイムでレビュワーの疑問点や指摘に応える

プラクティスを順次導入する事で作業スピードは改善し、徹夜や終電を連発しましたがなんとかプロダクトを期日までにリリースすることができました。

最終的に

リリース後、別の開発で上のプラクティスを洗練させた結果、以下のプラクティスにたどり着きました。

• 特定のタスクに対し、ホワイトボードの前に二人が座ってホワイトボード前と端末前を行き来しながらペア作業すれば以下の3つのフェーズをフィードバックを受けつつ高速に回転させられる。
  • 仕様策定
  • 実装
  • レビュー
• タスク粒度が大きくても比較的とても短時間で完了できるため、二人が拘束されたとしても一人ずつ作業するより生産性が高い事が分かった。
• 副次効果として、メンバーが密度の高い作業をこなすと短い時間で相当疲労するため、帰宅時間が早くなった。

これはなにかに似ていないでしょうか。
そう、ペアプロです。
ペアプロがなぜよいかが心で分かりました。
この瞬間私はペッシになりました

KPIボードをしゃべり場から意識高い状態に変えたい

この記事は アジャイルCasual Advent Calendar 2014 - Qiita のxx日目です。

しゃべりばis何

しゃべり場というのは昔NHKでやっていた「台本なし、司会者なし、結論なし」と言うコンセプトの番組です。

全員言いたい事を無遠慮に言い放って、結論とかでないけど言いたい事いってスッキリしたからいいよね！っていう番組です。

KPIってなんだっけ

KPIは「続けたいこと、やめたいこと、これから始めたいこと」をふせんで列挙する振り返りの一種です。 私がいたチームではKPIボードというのを使っていました。 KPIボードはKPIで書いたふせんを張る場所です。 保存する必要があるので、持ち運びできるホワイトボードを購入し、そこに貼っていました。

論旨

「言いたい事いってスッキリしちゃうことだけが目的のKPI」ってKPIじゃないよね、じゃあどうすればいい？
っていう話をします

KPIとは救われなきゃだめなんだ

KPIは一回やるだけでは意味がありません。

定期的に複数回おこない、「Problemにあがっていた問題は解決したか？」「Tryにあったことは実施されたか？」「Keepにあった試みは実施され続けているか？」をチェックする必要があります

KPIアンチパターン

Problemにふせんを一枚貼ればその問題が解決するほど社会は甘くありません。
実際には「あーあるねー」で終わっていつまでもふせんは残り続けます。
あるいは「あーあるねー」という反応すら得られず「誰かが何か言っているが俺には関係ない」になるかもしれません。

同じ調子でTryに貼られた試みは実施されません
Keepにあった試みは気づいたら消えています。

ふせんが消えるのは、事態が解決されたからではなく、提起者が諦めたときです。

「対応できません、放置します」はKPIボードに貼られたふせんに「対応しなくてもいいもの」が多数存在し始めるので、みんなのマインドセットが「ああ、ここに貼ってあるからと言って対応しなくてもいいんだ」という形に変わってしまうので、KPIボードの権威を低下させます。 かといって、KPIボードの鮮度を保つために長期間対応されないふせんをはがすことは、貼ったメンバー(問題提起した人間)の意欲にかかわります。また「どうせ問題提起しても対応されないんでしょ？じゃあ最初から書かないわ。面倒だし。」という悪魔のささやきに屈する人が増えるため、KPI活動の機能不全につながる可能性があります。

そこで純度と権威を保ちつつ、メンバーの士気をそがないために、「今はやらないが、問題としては認識している」ふせんについては棚上げリストへの移動を行います。 棚上げリストはKPIの構造を持ちつつ、KPIボードの通常のスペースとは別に作られます。

私は棚上げリストをglacier(氷河)とかgraveyard(墓場)とか呼んでました。
Magic the Gathering というゲームだとgraveyard(墓場)から特定の条件でカードを復活させる事ができるので私はこの呼称を気に入ってました。

アイスボックスという呼称もありますが、アイスボックスは、将来的に取り出すことを前提としそうな感じがあります。 しかし現実問題として、墓場に移動したふせんはたいてい復活しません。 「対応する必要がある問題」とみんなが認識していないからです。 なので、むしろふせんを貼ったメンバーのモチベーションの冷却のために存在します。

氷河にすぐに対応しない付箋を移すと、KPIボードのメイン部分を残ったホットで重要度の高いもので占めることが可能です。

結論なし、対応なし、しゃべってガス抜きしてスッキリして、明日から何も変わらない状態から脱却できます。 私はこのメイン部分をホットプレートと呼んでいました(早く対応しないと焦げるから)

すなわち、KPIのメイン部分にあるからにはなにかしら対応せねばならない、対応できないということは我々に問題があったということだ、という意識高い状態にメンバーのモチベーションを維持しやすくなります。

皆様のKPI、しゃべり場になってませんか？

新人プログラマに正月休み中を使ってプレイしてほしいゲームをセレクトしてみた。

Civilization

いわずとしれた電子ドラッグ 国家を運営し、領土から入る様々なリソースを各方面に分配し国家を育成する。
「もう１ターン、もう１ターンだけ・・・」 とか言っている間に夜が明けてしまうので電子ドラッグの名がついた。 4のほうが名作の名高いが、5のほうがルールが単純なため、5を新人プログラマにはおすすめしたい

BioShock 2

ホラーFPS、バイオショックの続編。 あの評価の高い前作から10年後が舞台。主人公はビッグダディ。 ヒロインが洋ゲー随一の美人。 導入部からエンディングまでの流れ、没入感はぜひ見てほしい。

Call of Duty::Advanced War

キャンペーンモードの長さが十分な分量に！ Dead Spaceの開発元が作った作品。 かつてのCOD::MW系列の面白さを取り戻した作品 ただしDead Spaceのインターフェースの流れを汲んでいるように見えるのと、ネイティブ以外にはスキルが直感的に分かりづらいようで、「開発者のマインドセットの崩壊」が感じ取られる。 プレイするときはwikiの助けを借りたほうがいいかもしれない。特にゲームシステム。

Age of Empire 3

伝説的FPS もう続編の出ないのが難点。 はまるんだ！

Rails で複雑な処理をつくったお

この記事は Ruby on Rails Advent Calendar 2014 - Qiita の17日目です。

前回は @gogotanaka さんの Railsを作った男たち - Qiita でした。

複雑な処理 is つらい

• Railsで複雑な処理を書くと死ぬ。
• 即死はしないけどあとで何度も苦労される
• 運用しつづけるとリソースをけっこう食っている事に気づく。
  いわばエナジードリンク。開発の活力の前借り

複雑な処理を避けるには？

• 処理の複雑さ＝仕様の複雑さ
• 複雑な仕様を簡単な仕様にすれば、処理も簡単になる
• 最初の段階でドメイン設計やモデリング、デザインを頑張れば簡単にすることは可能
• 最初にリソース投下して設計する事、また途中で定期的に再設計、リファクタを繰り返し整理された設計を維持し続ければ複雑なドメインは避けられる。つまり複雑な処理も避けられる、はず。

ところがぎっちょん

• すべての複雑な仕様を簡単な仕様にすることはできない
• 仕事の要求上複雑な仕様が湧いてくることは避けられない

知らなかったのか仕様からは逃げられない

レポート機能を作らざるを得なかった

• 解析軸は可変でなければならない
• 解析期間も可変でなくてはならない
• ほか付帯条件もいろいろつけられるようにしたい
• 別システムにするほどの複雑さではない
• 意外と細かいレポートの要求機能

苦戦する実装

• レポートでたびたび呼ばれる集約関数がActiveRecordと微妙に食い合わせが悪い
• scopeの中に処理が書かれるケースが続発
• スロークエリの巣になるケースも
• 「便利な機能が欲しい」「可視化のために」更に増える要求
• 速いクエリと表示しやすい形のクエリはしばしば排他的になる

やったこと

• レポートのModelクラスが汚れてしまうのは仕方がない。
• 速いクエリを投げて、表示しやすいように整形する変態メソッドを作る
• ほかを綺麗にするために汚れ役が必要だった

汚れ役を一つにおしつけて

• 面倒が起きたらだいたいこいつのせい。
• 調査時の容疑者探しが楽になった
• 引き継ぎ時に重点的に引き継ぐポイントが明確に。

結論

• この複雑な世界で、(仕様が)綺麗でままでいるのは難しい
• 誰かが汚れ役になる必要がある
• 引き継ぎは忘れてはダメ。絶対。

jrubyでWindowsで動くゲーム作った

この記事はRuby Advent Calendar 2014の15日目の記事です。

Windowsで動くexeファイルをRubyで作りたい！

序論

何をどうとち狂ったか、「ゲームを作ろう」「Windowsで動くexeファイルをRubyで作りたい！」そう思い立った俺たちは一路南米にとんだ。
南米では特に何も見つからなかったが、かわりに目的の技術であるJRubyFXとrawrという技術をインターネットで発見した
RubyでGUIアプリを作るならJRuby+JavaFX+Rawrで決まり！ - かなりすごいブログ

なお作者はRuby AC 17日目担当の @supermomonga

ももんが (@supermomonga) | Twitter

さんであります。ありがとうございます！

JRubyFX とは

• JavaFXをjrubyから使えるようにするライブラリである。
• ControllerとModelはそこまで変態ではない
• ViewはfxmlというxmlっぽいViewテンプレートをもとに、jsでDOM操作するような感覚でViewの要素をいじる必要があって、だいぶ感覚が違った。Slimとか使いたい。

rawrとは

• JRubyFXでできたプロダクトをいい感じにexecutable jarとかMac Appとかexeファイルにしてくれるライブラリ
• 配布したいものが作れる。便利。
• build_configiration とか久々にいじった

で、どうなった？

• 三ヶ月くらいでなんとか配布できるプロダクトが作れた。
• 学習コストはそれなり。RailsのようなWAFありきの感覚とは異なる。画面表示を作るための最低限の薄いF/Wという感じ。

よかったこと

• rubyの大正義であるメタプログラミングやラムダによって、似ているけど微妙に異なる処理を簡単に作れる。ゲームでは超大事。
• rubyなので簡単に試せる。だから簡単に失敗できる。つまり簡単にチャレンジできる。
• rubyなので文字列操作が簡単。ゲームの文字列表示がすごい楽。これは大きい。
• つまり ruby が使える事がよい。

わるかったこと

• rubyの大正義、pryが画面表示状態で使えない。死ぬ。
• rawrでexeを出力した後、Windowsで動かないケースが多すぎた。
  rawrのせいではないが、javaのバージョンの問題や、永続化の手段として使ったローカルへのファイル書き出しと読み出しで手間取った。Webの世界に帰りたい。
• Java7でビルドするとJava8で動かない。Webの世界に帰りたい。(最終的にJDK8をunpackしたものを同梱し、同梱のjavaファイルを使う事で回避)
• ローカルのファイル書き出しが文字化けする。Webの世界に帰りたい。

やっておいたほうがよいこと。

• 画面表示要素の元となる要素が入った配列を渡すと、いい感じに整形した画面表示要素を指定のListView配下に突っ込んでくれる処理とか書くと楽になる。
• 画面要素を操作する部分が散乱すると破滅の道しか見えない・

結論

• exeを作るときにrubyの便利さを持ち込めるのは大正義
• exeファイルが作れるのはいいよね、うん。
• Webの世界に帰りたい

(番外編)会社で仮眠する方法

アジャイルに働くためには休息も重要です

• そこで今日は休息の一形態、仮眠について書こうと思います。

会社で眠る動機について

• ついうっかり終電を逃してしまった
• 昨日飲み会で眠い
• 昼休みに仮眠して眠気を振り払いたい

そういう機会に恵まれる事はないでしょうか
いや私はできればごめんですが。

そういう時に寝る方法として、できればソファスペースを確保できれば最高です。
次善策として段ボールをしいて、更にその上に毛布など柔らかい布をしくとよいです
しかし、そういうのをいきなり職場でデプロイするのは難しいと思います。
あるいは難民キャンプ感が出て若手社員が「ここはブラック会社だったんや・・・」とか誤解されるかもしれません。

そこで、職場で調達しやすいもので仮眠しやすい環境を作る事が肝要です。
経験上、尻の位置より高い位置に脚を上げて、椅子をリクライニングさせると寝やすいです。椅子を向かい合わせに2つつけるのもよいでしょう。
あるいは脚置きを確保しておくとよいかもしれません。 そうするとさっくり寝られます。

現場のテストにかけるコスト

3行で

• 私はテストを書くべきだと思う
• テストのあるまともなプロジェクトを回したらテスト量は以外と少ない
• テスト書かないとかありえないよ

昔こんなコピペ流行ってましたねえ

うちはテスト書かないよ、スピード重視だから
TDDってあれでしょ？単体テストを大量に書くやつ

私、あれの元ネタ知らないんですけど、あのコピペってどこ発祥なんです？

話は全然変わるんだけど

大学時代に助教の方からこう言われました

「(コンスタンチンとヨードンが提唱した)構造化設計において、結合度と凝集度という概念がある。 
　これは知ってるよね。 
　通常はこの２つを最高レベルに保つことはできない。限界があるからだ。
　しかし例外的にこの２つを最高に保つ方法がある。なんだと思う？」
「わかりません」
「全部メイン関数に書く」
「それって保守性はどうなるんです」
「最悪だろうね。結局こういうのはトレードオフだから」

トレードオフ

よくCOBOLerあがりのおっさんと若人が「コードの見渡しが悪くなるからできる限りクラスは大きく作れ」vs「保守性考えてクラスやメソッドは細かくしろ」論争していたのを、SIer時代に見かけました

前者がGODクラスを作りたがっているのに対し後者は責任分割や保守性の観点からクラスやメソッドを適切に切りたがっています。
ここで注目したいのは後者も「適切に分割せよ」といっているだけで「とにかく細かくしろ」とは言っていないです

DDD的的な概念も思考停止して適用すると3行以下のメソッド1~2個だけしかもたないクラスが乱立するよな、絶対レビューではねられるよな、って思ってました。

原理的には別メソッドや別クラスにすべきだろうが
それをやるとコストがかかる割に「やらんでもわかるだろ」という部分なので「やりすぎ」になる  

というシーンはコードを書く上でよく発生します
このあたりはトレードオフだと思ってます

テストもトレードオフですよ？

テストも基本トレードオフだと思ってます。

テストを書くべき場所

バグがあった時にUXを大きく損なう、金銭に関わる、データ不整合を引き起こすなど重要な部分には必ず必要です。 しかし、ある値に定数をかけて返すなどのメソッドには必要でしょうか？ 不要だと私は思います。 単純なメソッド、一見してわかる箇所、あるいは影響があるユーザーは運営の人間だけの場所など重要度低いと判断されテストが書かなくても良いと思います。

テストのコスト

テストは書くのに初期のコストがかかります。
プロダクトコードが変更されればテストコードを変更するコストもかかります。
複雑なテストコードや入り組んだテストにはバグが潜みやすくなります
さらに、前提から変更されるような変更が入る場合テストの大半は壊れていないか、不要にならないかの判定のあと、かなりの部分が捨てられる恐れがあります。
これらのコストは判断に大きな影響を与えるべきだと思います

ノーテストorALL

「GODクラス志向の実装or責任分割を厳密に守った実装」のように「ノーテストorテスト書きまくり」のような極端な二択を持ち出される方がおります。
ダブルディバイディングといって営業や詐欺師が持ち出す恣意的に片方の選択肢に誘導する話術だそうですね。

実際には書くべきところにはテストを書く、書くにしても正常系onlyか、異常ケースのメイン部分を全部潰すか、画面確認できない部分だけ書くか、そういった「どこまで書く？」の判断はリスクやコストと利益のトレードオフと合わせて判断されるべきだと思います。

テストを書くと採算があいづらい場所

障害が起きても不利益が運営の人間にしかかからない場所
設計の変更が起きやすい場所
画面から確認しやすい場所
テスティングフレームワークの限界から、コードでは確認しづらく、逆に人目で容易に確認できる場所

テストは保険

20代独身で月に5万円くらい保険に注ぎ込まれている方はおりますか？
あまりいないと思います。
給与が低くてなにかをもっていないからです
保険料につぎ込むよりもお金を別の場所につぎこんだほうが有益だからです。

同様にテストにはコストがかかるので、そのリソースを他につぎ込んだほうが有益です。

しかし、より高齢で持ち家があって妻子のいる方ならありえる選択肢です。
持てるものが多く、収入が多く、なにかを失った時のリスクが大きいからです。

プロダクトも同じで「立ち上げ時期」や「稼ぎ」「既に得ているもの」によって依存すると思います。
スタートアップならほぼノーテストでもかまわないでしょう。
でもヒットプロダクトを抱えた会社の新規事業なら、本体事業への悪影響を考えて最初からテストをかいたほうがいいかもしれません。

じゃあどれくらい書けばいい？

正直「コンテクスト次第」「チーム次第」と言わざるを得ません。
ただそれじゃあ無責任だと思います。

githubなどの伸びているプロダクトはプロダクトコードとテストコードの比率は1:1だそうです。
だいたい感覚値と合う感じです。

結論

テストは用法用量を守ってお書きください。