サービス開発を迷走させるコツ
この記事は アジャイルCasual Advent Calendar 2014 - Qiita の23日目です
ネタが足りないのでこの前聞いた話をまとめて埋め草にしようという魂胆です
情報を集めない
- ビジネス判断を行う際には、判断材料として情報が必要です。
不足があるとその部分を「勘と経験」で埋めます - また、情報をむやみに集めすぎると重要な情報がそうでない情報に埋もれて有効に活用できなくなります。
ローマ初代皇帝が元老院の定数を倍に増やしたことでに(彼の目論見通り)元老院の力が弱まったことに似ています。 - 重要な情報と、そうでない情報とはなにか、を定義しないこともこの傾向を加速させます。
ドメインを理解しない
- ドメインとはどういった構造をしているか？
ビッグプレイヤーが存在しないとしたらなぜ存在しないのか？
ユーザーやニーズの所在や構造をモデル化しているか？
…これらを行うためにはドメインへの理解が必要です - ドメインを理解しない人間が考えた施策はだいたい外れる可能性が高く、また当たってもヒットの大きさが足りないケースが多くなります。
- ヒット率の高さを補うために、ドメインを理解する代わりに世間的にはやっているサービスを表面的にパクった機能のリリースが志向されます。
ヒット率の問題は補えますが、代償としてより無軌道にサービスが肥大化し始めます。
ビジョンを定めない
- インセプションデッキで定義される内容、英語で言うStrategyやPrincipleの部分を定めません。
- 結果として、「なぜこの機能はリリースされるのか？そうすることでユーザーのどういう利便性が向上し、どういった利益が得られるか？」というシナリオがメンバーの中で理解されず、「指示された機能をよくわからないまま実装する」という状態に開発者が陥ります
そういった状態で実装された機能は利用品質が低く、イケてなくて、ぼやっとした機能になりがちです。
想定通りのパフォーマンスを発揮し、コスト以上に利益を回収できる確率は低下します。 - メンバー間でサービスに対する理解が共有されないため、サービス開発の迷走の火種になります。
- 結果としてサービスがヒットしたとしても機能追加を繰り返すほどジェンガのように不安定で無秩序な状態に陥り、乱脈なサービス開発ゆえに後進サービスに陳腐化される可能性が高まります
思いつきにすがりつく
- 偉い人の思いつきが、十分な洗練を経ずに企画から実装、リリースが急がされます。
これは「なぜこのサービスが伸び悩むのか」という問題を「この機能がリリースされればすべての問題は解決される」と思い込むことで「この機能をどうすればリリースできるか」という問題にすり替えることを目的としています。 - ユーザーの「xxができたら使うのに」という声に安易に従います。
これは上記3つの合わせ技で「なにをすれば改善できるのか」が判断できないので、ノイジイーマイノリティや誰かの無責任な一言に追従してしまうのです
HITしなかった機能を無思慮に放置する
- リリースしたもののほとんど使われなかった機能はあると思います。
こういった機能は「Closeする」という決断をされぬまま、維持するためのコストがかかり続けます。
このコストは多くの場合可視化されず、それでいてそれなりの額が他で稼ぎ出した利益や他に回されれば多くの利益を生むであろう資源を食いつぶしながら存続します。 - これらを防ぐには「撤退条件」や「成功条件」、「存続意義」を定めておくのがコツです。逆にやりたければこれらは定めないほうがよいでしょう。
俺たちのペアプロ戦記
論旨
従来のやり方
私のチームはそれまでこんな感じでタスクを進めていました。
- タスクの終了条件を決めてアサインされる。
- タスクの仕様を説明される
- プログラムする
- レビュー受ける
問題点
ところが新プロダクトの開発を上のフローで進めるうちに、問題点が噴出しました
聞く側
- プログラム中に細かいところを何度も聞きにいくのが面倒くさい
- 確認待ちで作業が止まる
- レビューが帰ってくるまでの待ち時間が長い。
- 帰って来た頃には半分くらい忘れている
- レビュー待ちの間に別のタスクを始めるので仕掛中のタスクがどんどん増える
- レビュワーの指摘でタスクの仕様が変わる事がある その場合タスクが振り出しに戻る
聞かれる側
- 何度も聞かれて作業が中断される
- 聞くなら一回にしてほしい
- レビュー依頼の件数が際限なくたまる
- すこしでもレビューを貯めてしまうと、レビュー待ちしている人が別のタスクを始めてまた積んでいくので、レビュー待ちが複利で増える
- 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 つらい
複雑な処理を避けるには？
- 処理の複雑さ＝仕様の複雑さ
- 複雑な仕様を簡単な仕様にすれば、処理も簡単になる
- 最初の段階でドメイン設計やモデリング、デザインを頑張れば簡単にすることは可能
- 最初にリソース投下して設計する事、また途中で定期的に再設計、リファクタを繰り返し整理された設計を維持し続ければ複雑なドメインは避けられる。つまり複雑な処理も避けられる、はず。
ところがぎっちょん
- すべての複雑な仕様を簡単な仕様にすることはできない
- 仕事の要求上複雑な仕様が湧いてくることは避けられない
知らなかったのか仕様からは逃げられない
レポート機能を作らざるを得なかった
- 解析軸は可変でなければならない
- 解析期間も可変でなくてはならない
- ほか付帯条件もいろいろつけられるようにしたい
- 別システムにするほどの複雑さではない
- 意外と細かいレポートの要求機能
苦戦する実装
- レポートでたびたび呼ばれる集約関数が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の世界に帰りたい
