瀬宮の球拾いブログ

エンジニアだったはずが、みんなにヘイストかける方がチームに貢献できた男のブログ

戦略と機動によって勝利する。

イギリスのフラーという人がその昔「相手を打倒(Defeat)することによって勝つことよりもManeuver(戦略、機動)によって勝利するべき」みたいな事を言っていました。
直訳すると「愚者は打倒によって勝利を得ようとするが、賢者はManeuver(戦略、機動)によって勝利を得ようとする」なのですが、意味的には合っていると思います。

事例としてはGoogleが「フィンランド打倒プロジェクト」として全力で検索と広告を押さえに行った事例が最も当てはまると考えます。実際にGoogleは検索と広告を制覇し、仮想敵だったフィンランド、すなわちマイクロソフトをかなりの期間、圧倒しました。
あの時点において検索と広告はオセロでいう「四隅」のような「ここを取れば圧倒的に有利に戦いを進められる場所」でした。

ところがオセロでいう「四隅」は現実のビジネスでは明示されません。どちらかというと重要な場所が動的に形成される囲碁に近いものがあると思います。強い場所とはどこかを見定める観察眼は必要です。観察眼を下支えするのは、過去の経験や定石、棋譜から学んだ知識と経験です。
しかも重要な場所は複数あるため、より重要で、かつ争奪戦に勝利できる強い場所を複数の選択肢から選択できる能力と、その前の選択肢を作り出せる能力が、プロダクトをマネージメントする上で重要と私は考えています。

最近のUXデザインを取り入れたヒットプロダクトの特徴をつらつら考える

最近のUXデザインを取り入れたヒットプロダクトの特徴を見ていると * 最初に「このプロダクトはなにをして自分にどういうメリットがあるサービスなのか」が明示的であること * ユーザーはプロダクトにやることを押し付けられるのではなく、「合理的な判断」に基づき自発的にやることを決定すること * ユーザーの週にプロダクトに使う時間を5時間、10時間、15時間と増やすために、ユーザーのフェーズが明確に決められていること * 課金ユーザーの動きと非課金ユーザーの動きがセパレートされていること * 作る人間が、ユーザーに何をさせたいか、ユーザーはどう楽しむのかを明確に理解していること(作っている末端の人間すら理解できないのに、サービス利用者が理解できるわけがない)

とかそういう特徴があるのかなと思いました。
ただ依然として00年代ごろのUXデザインでも十分なシェアを獲得し、十分な伸びを続けており、100人以上の社員を抱える企業はいますので上の要素は必須でもないんじゃないの、と思います。

セオリーを知るということ

チェスのことわざで、「序盤は教科書のように打て」というものがあります。

教科書とは「定石」のことです。要するにセオリーがあって、そこから外さないように打て、ということです。
では序盤で定石を外すとどうなるのでしょう?
例えばオセロの場合。
最初の10手で、定石から外れた場合ショボいスペックの3年前の家庭用ノートPCのAI相手でも負けます。
電王戦は高性能マシンが相手ですが、おんぼろPC相手でもオセロなら最初で定石を外せば負けます。
それくらい序盤で定石から外れることは致命的なことです。

定石とは、過去の積み重ねを頭の良い達人たちが要約した結果です。
スティーブジョブズのような教科書に載る側の超天才でもない限り、しかれたレールの上を走ったほうが効率的です。
苦労するのは中盤以降なので、セオリーにこだわらない打ち方をするのはそれ以降で良いでしょう。

富士山を登るにも、一合目から歩こうと車で半分まで登ってしまおうと、頂上にたどり着いて帰ってくることが目的なら、選ぶべきは楽できたほうだと思います。
苦労することに意味を見出すスポーツや娯楽ではなく、結果重視のビジネス目的なら特に、です。

変な奇策にこだわってしなくてもいい苦労をするのは賢くはないと思います。
セオリーを知り、知った上でそこから外れるのと、セオリーを学ばずに「柔軟な発想」と言い張るのは違うと思います。 たとえば体を鍛えずにボクシングのリングに登るようなものです。

ということで今日の結論は、セオリーを知ることは、「つまらないことで失敗することを避けるために必要だよ」という話でした。

明日からできるチームの開発生産性の向上

明日からできるチームの生産性向上という小ネタです。

だいたいどこのチームでも通じる鉄板ネタを使ってます。 スクラムしてなくてもアジャイルでなくてもできるネタです。

これで成果出して信用稼いで、それで次のやりたいことをやらせてもらう布石作りにするのが目的だったりします。

1. Pull Requestラリーの削減

レビューを受ける側がPull Requestを出した際に、レビュワーがコメントを付けた後に1作業を入れます。
2人でペアプログラミングのような形で修正させます。
なぜ修正して欲しいのか、どうしてこの形ではよくないのか、どのようなかたちにすべきなのか。
その3点を説明しながら一気に直させることでレビューラリーを1発で終わらせます。

PRのOpenしてからCloseするまでの時間が一気に減ります。
また、同様の指摘が再発する率が減るので、今後の時間の節約になります。
PRのCloseまでのリードタイムが減るため、同時に開かれているPRも減ります。すなわちWIP数の削減につながります。

詳しい方法を聞きたい場合は私から聞き出してください。ビール一杯で話すはずです。

2. PRにテスト内容を追加

PR か Issueを最初に作った初期段階でRSpecでテストすべき内容を書きます。
初期段階、というのはコミットが行われていないか、最初の一回を行った段階です。
なお私の好みとしては1stコミットはspecファイルを空で作った "Implement fake spec of ...."にするのが好きです。
「今回のPRでテストすべき正常系。およびテストで保証したい異常系(存在する場合のみ)」を書くと、だいたいDoneの条件に近似します。
本質的にはどこまで書いたらDoneか、を書かせたいのですがそれを未経験者に理解させるのが難しいためこちらを書きます。
「これもっと細かくPRを分割できるよね?」「そもそもやりたいことがおかしくない?」というツッコミを実装を始める前の段階で発生させることを目的としてにSpecについてPRに書かせます。
ただし、JSでの処理をテストにおいて記述することは難しいです。

これはかなり効果があります。PRというかタスクの質を向上させ、手戻りや「成果に繋がらないタスク」を減らせるからです。
実践方法や詳しい方法を聞きたい場合は私から聞き出してください。ビール二杯で話すはずです。

3. デザイナーからのコンテクスト説明

ProttやSketchにデザインをがっちり書く前に「ユーザーはこの機能を使ってなにをしたいか」「ユーザーにさせるUXをどう考えているか」「ユーザーはこの機能があるとどう嬉しいか」という説明を行います。
この説明の後にはデザイナーによるそう考えた仮説と根拠の提示、非デザイナーからの質疑応答があります。
時間はかかりますが、言語化された説明により開発サイドのモチベーションの向上やコンテクストの共有、「これいけるんじゃね感」や「腹落ち感」の醸成が期待できます。

つまり、ProttやSketchに実際にがっちり書く前に問題点の洗い出しとコンテクストの共有が行われるため、デザインの実装時間の短縮とデザインの効能発揮の打率向上が望めます。

個人的見解ですが、優秀なデザイナーの気合を入れたデザインは死亡フラグです。
実装者はProttoやSKetchからデザイナーの意図を推測し「リバースエンジニアリング」を行うため、再現度の面で粗が出ます。
また、ユーザーは優秀なデザイナーほど察しが良いわけでもなくストレスにも弱くまた流行のデザインと今までのデザインとの差異に拒否感を示しやすいので、おしゃれなデザインから意図を読み取れず離脱する傾向があります。

そこで一度デザイナーの脳内の現実歪曲フィールドから取り出し、「他人の眼」を経て揉み直すことでユーザーが受け入れやすく、また実装しやすいデザインを作れると考えています。
ペーパープロトタイピングなどでの非デザイナーの参画、特にディレクターやセールスの視点の取り込みもとても有効でした。

実践方法や詳しい方法を聞きたい場合は私から聞き出してください。ビール三杯で話すはずです。

バックログはタスクリストとは違う

私がバックログを運用するにあたりバックログ自体の目的を「ある単位期間までに見えているタスクとタスクのつまり具合と進行方向を示すこと。またメンバーやチームが自分で計画を行えるようにする土台になること」としています。 前者は情報を示すものです。 またバックログというものはアーティファクトなので、それとは別にバックログを見ながらのMTGには別の目的があります。つまり後者の目的、Planningのための共通インフラです。

異なる情報をもとにすれば異なる決断が下されます。 各人が異なる決断をすればチームはバラバラになります。それを防ぐために同じインフラをベースに方向性の揃った決断を促すためにバックログがあります。 バックロググルーミングとは同じ情報インフラをもとに、チームが情報と方向性と志向を同期させるPlanningの場です。

しかしアジャイル未経験者(あるいは経験の浅い人間にとって)タスクリストというのは「タスクの抜け漏れを防止する」ためのものとして捉える傾向があります。 イテレーションバックログとプロダクトバックログの区別もつけません。 この場合の抜け漏れ防止型タスクリストの特徴としてフィーチャーベースで書かれます。 「商品のキーワード検索機能をつける」「商品のジャンル検索機能をつける」こんな感じです。 極めて当然のことです。漏れ型タスクリストとは「あとで作業の抜けがないようにする」ことが目的なので、ユーザー視線をタスクリストに盛り込まれることはありません。

これがタイトなスケジュールと組み合わされた場合、悲劇的な結末が訪れる場合があります。 最初の方は「ユーザー目線」で動いていたはずがタスクリストの項目を期限内に消化することに夢中になるあまり、「期限内に項目を全て消化すること」が「最優先事項」になり、「ユーザー目線」はどこかに消えてしまいます。

人間は目に入る情報から判断を下します。また、記憶というのは急速に劣化していきます。 ユーザー目線のない抜け漏れ防止型タスクリストを見続けていると、ユーザー目線はいつか頭の中から消えてしまいます。

「完成したが、ユーザーがつかなかった。」 この状態になれば最悪です。 抜け漏れ防止型タスクリストの欠点は、ユーザーがつくことよりもプロダクトを完成させることを優先するようチームに強く促す点にあります。 SCP財団の収蔵物のように、抜け漏れ防止型タスクリストは存在するだけでチームからユーザー目線を奪い、完成したプロダクトをユーザー目線の抜け落ちたものになるよう促し続けます。

コンセプトの明快さと明確さによるコミュニケーションの削減

ダークナイトという映画をご存知だろうか。 名作すぎる名作なので多くはここでは語らない。

作中に二人の悪役が登場する。 一人はジョーカー。 もう一人はトゥーフェイス

この二人を軸に、「明確なコンセプトはコミュニケーションやマネジメント、摩擦を削減する」「不明確なコンセプトは逆にそれらを増加させる」という話をする。

ジョーカー。 彼は極めて明確な人物だ。何をしでかすかわからないが、とにかく人に有害な悪事を行うという一点で常に一貫している。 もし自分が舞台のゴッサムシティの住人でジョーカーを偶然目撃したらどうすればよいか? 対策も極めて明確だ。彼の天敵であるバットマンゴッサムシティ自警団(警察が役に立たないのでそういうのがある)に通報すればいい。 ゴールも同様に明確。ジョーカーがアーカムアサイラムに収容されたらこの事件は解決されたことになる。 注:アーカムアサイラムは精神病院。警察と刑務所が役に立たないので悪党はそこに収容される。

トゥーフェイス。 彼は、作品単位ではともかくシリーズを通しては不明確な人物だ。 成り立ちにも同情の余地があるし、そもそも作品単位で悪役になったり改心して自警団側の脇役ヒーローになったりする。 もし自分が舞台のゴッサムシティの住人でトゥーフェイスを偶然目撃したらどうすればよいか? もし彼が悪役ならバットマンに知らせるべきだが、自警団側の人間かもしれない。どう対策すればいいのかコンテクストを理解しないと行動できないから調べないといけない。 ゴールも不明確だ。アーカムアサイラムに収容される話もあるし、そうじゃない話もある。途中で自警団を抜けるかもしれない。

トゥーフェイスは不明確ゆえに、彼について対策を考えるときは多くのことを考える必要がある。 ジョーカーは「とにかくジョーカーをぶちのめせばOK」とシンプルであるのに大きな違いだ。

私がプロダクトについてコンセプトや背景を明確にするべきと考えているのは上に通ずる。「一貫したコンセプト」に沿って動いているなら「慎重に吟味」しなくても「聞かなくてもわかる、大体こういう感じなんだろ?」で協力なり支援なりあるいは静観なりの対応を決めやすい。 そうでないなら、情報をもらって協議して慎重に検討した上で判断しないといけない。 つまりそれはコストだ。 プロダクトに協力する側にとっても、プロダクト内から協力を求める側にとっても。

コミュニケーションやマネジメントのコストを削減するために、私は明快なコンセプトを、最初にコストをかけても決めるべきだと考える。それは必ず元が取れるからだ。

プロダクトオーナーの異常な雑用 または私は如何にしてプログラムするのを止めて雑用をするようになったか

タイトルについて

映画のパロディです。
ジョニーの凱旋が流れるシーンが好きです。

私の担当

チームにおける私の配置は

  • プロダクトオーナー
  • チーフエンジニア
  • 雑用係

の3つです

経緯

私は業務外でゲーム開発チームを運営しています。
役割分担は「システム」「シナリオ」「デザイン」の3人でした。
ひとまず開発が落ち着いた段階で、製品そのものはゲーム性を備えたので、販売を強化しようということになりました。
すなわち、販売強化に関わるタスクを誰かが受け持つ必要がありました。新しく人とかまだ雇えないし。
この時点でデザインさんは投入可能時間と要求作業量が均衡しており、新しいタスクは振れません。
シナリオとシステム、どちらが作業したほうがゲームのプロダクト価値をあげられるか、と考えた時、データ分析から、明らかにシナリオ量のほうがユーザーに訴求することが明らかでした。また、ゲームシステム開発はひと段落し、新たにシナリオスクリプトを投入すればほぼ追加開発がなくてもゲームリリースが回る状態になっており、システムのタスク需要が大きくなかった、という判断から、システム担当がシステム開発の時間を削り、販売強化にまつわるタスクを受け持ちました。

販売強化is何

大きくあげると「マーケティング」「販売宣伝」「カスタマーサポート」「データ分析」「売上集計」「渉外ぜんぶ」に分化されます。
あとでイラスト絵などの「外注管理」も加わりました。

そのあとも「いま、誰の作業時間を"本業"に当てれば最もプロダクト価値が上がるか」は常にリリース単位で検査の対象となりました。結果は上下するものの、「最も価値に寄与しない」最下位と判断されたのは常にシステム担当でした。
こればかりは同じゲームエンジンを使いまわすというプロダクト戦略の都合上やむをえません。
そのため、私は常に「雑用係」を担当しました。

雑用と便宜上言っていますが、こうして並べると分かる通り、製品開発以外の「超重要な業務」です。ないとプロダクトとして機能しません。作って終わりではありませんから。ですので、私もかなり真面目に取り組みました。
特に、マーケティングと販売宣伝には注力し、1年間で売上8倍の売上を達成しました。

担当の基本

1人に複数の役割を振ってもいいですが、責任を持つ役割を同列の2人に振ってはなりません。常識です。コーラを飲んだらゲップが出るレベルの。(エッセンシャルスクラムにそう書いてあった)
そのため、雑用係は輪番制や共同担当制をしかず、常に私が受け持ってきました。

担当制

ながらく担当として一人に担当すると「強い責任感」と「ノウハウの蓄積」による高いパフォーマンスが期待できます。逆に「どうでもいい仕事」で邪魔をしてしまうと「自分は軽んじられている」と感じて"本業"にも"副業"にも責任感を感じられなくなります(出典:ピープルウェア)
メンバーを専門職として尊重し、"本業"に高い生産性を出させるためには、誰かが"落穂拾い"を引き受ける必要があります。今回の場合はそれがプロダクトオーナーである私の仕事でした。

自分が担当したことによる利益

その甲斐あって、2つの利益が得られました。
1つは他の担当を雑用から解放したことで、プロダクト価値に寄与するシナリオやデザインの生産性が常に上がり続けたこと。
もう1つは、プロダクトオーナーが雑用を行ったことでユーザーのニーズや考えていること、販売媒体が我々に期待すること、売れ線の把握などがそのまますぐにプロダクト戦略に反映されたことです。

インメモリ理論

コンピューターサイエンスのセオリーとして、記憶媒体のI/Oを行わず、高速なメモリ上のみのデータを使って計算を行うとスループットが向上します。
同様に担当間で情報をやりとりするより、一人の人間が別の担当として仕入れたノウハウを別の担当としてふるまうときに利用することで、高いスループットと強力なシナジー効果が得られました。今回のケースで言えば、「カスタマーサポートや渉外担当、データ担当」という外向きの担当とプロダクトオーナーを兼任していた点です。
もっというならプロダクトオーナーがシステム担当も兼ねていたので、システム側のギミック実装が極めてスムーズでした。

プロダクトオーナー+エンジニア+雑用係

この組み合わせが機能したのは、私が比較的企画よりのエンジニアだったこと(逆に言うとガチガチの技術よりではない)と、なんでも一通りこなせる「便利屋」的なスキルを備えていたことが影響していると思います。
経験としては楽しかったですし、新規事業とかやるときにはまたこういうことをやってもいいな、と思いました。

データを見る限り、私が雑用することでチーム全体のパフォーマンスは向上しています。
「誰の本業がプロダクト価値に寄与しているか?」は計測していてよかったと思いました。

悲しい現実

上ではかっこいいことを言っていますが、なにか「必要なタスク」があるとわかったとして、みんな自分の仕事に全力投球しているので、新しいタスク引き受ける余裕なんてないんですよ。
雑用振れるような新卒メンバーがいるのは大きい企業だけなんです。
ということは、そのタスクは誰かが(主に自分)引き受けなければいけなくて、そのためには本来予定にあったタスクを外すか、あるいはその新しく湧いたタスクを後回しにするかの二択をせまられるわけです。
その現実から目をそらして、「無理してでも両方やろう」とか言えないわけですよ。特にある程度以上のタスクサイズなら。
そこで腹をくくって現実を受け入れて、計画修正するのがプロダクトオーナーの仕事だと私は思ってます。

結論

プロダクトオーナーならチームのために雑用とかやっても楽しいです。結果が出ている場合は特に。 f:id:ShinSemiya:20151207231948j:plain