Android back キーと演出スキップについての考察
ふとした疑問。演出再生中に Android のバックキーが押された場合、ユーザは何を期待してるんだろう。普通に整理すれば無視（今だめですよ的な UI）が妥当だと思うだけど、バックキーっていいから進めよみたいな意味合いで使う印象だからスキップさせたほうがフレンドリーなのか？
— じぬ (@reximol) October 28, 2018
これについて考えていた。
多分スキップすべきではない
結論としては、少なくともいきなりスキップさせるべきではないのだろうなと思う。
ここでの Back キーの基本的な期待値は、前の画面に戻る、トップ画面であればアプリを閉じる（その確認ダイアログを開く）と書かれている。
前の画面に戻るのが適切な場合であれば、という記述もあるが、じゃあスキップさせますはまぁちがうだろうなと。
ちょっと古いが、こちらのページにも以下の記載がある。
> システム アイコン（「Back」キーなど）に期待される機能の定義を変えないこと。
じゃあどうするか
上述の標準的挙動の定義の中に、ポーズ（ダイアログ）を表示するという挙動が例として挙げられている。Back キーの期待値としてややずれている気もするが、これであればユーザの意図でなければキャンセルも可能である。
ポーズを出さない仕様のときはどうするか
> Back キーが押された際には何かアクションが起きるようにしてください。何もアクションが起きないとユーザーの混乱を招いてしまう可能性があります。
こういう記載があるので、無視するのはまずいだろうと思われる。Android 標準のトーストや、アプリの UI でなんらかのフィードバックを返す必要がある。
作業見積もりのやり方
仕事における作業見積もりについて、自分がしていることをまとめてみる。
やっていることは大きく3点。
- 自分がしたすべての作業を時間とともに記録する
- 自分がするすべての作業を見積り時間と共に記録する
- 自分が活動できるすべての作業時間を書き出す
背景
見積もりとは、「必要な時間」-「使える時間」> 0 であることを確認するためのものである。どうしてもこれが満たせない場合は、助っ人を頼むなり期日をずらすなり別途対応が必要になる。
早期にこれができるのなら、別段大した問題はない（と思う）。一番やっかいなのはギリギリになってこういう話をしなければならない場合だ。それを回避するために見積もり、すなわち「必要な時間」と「使える時間」をできる限り正確に算出する必要がある。
作業時間の記録について
自分はすべての作業時間を記録している。これの目的は、①使える時間を最大化すること、②必要な時間算出の精度を上げること、の二点である。
具体的には上記のようなまとめ方をしている。これを始めたきっかけは、自分が使えるすべての時間を可視化すれば、そこから見積もり精度を上げる何かが見つかると考えたからである。
実際の気付きとして以下のものがあった。
- 作業の区切りを意識しやすい
- ドハマリに気づきやすい
- 作業分割が的確だったか振り返りやすい
毎回作業に名前をつけることになるので、何をどこまでやるかということを考えながら作業する習慣がつく。また、定期的に時間を確認するため、自分の想像以上に作業に時間がかかっている際にも気付きやすく、効率的に時間を使える。
また作業見積もりの際にも、今までの作業にどれだけ時間がかかったかが記録されているため、当てずっぽうではない見積もりができるようになる。
必要作業と作業可能時間の書き出しについて
この2点は一つの資料にしているため、まとめて記載する。
特に大型機能開発の際には、設計よりも前にすべての機能を書き出すようにしている。また、その時点で見えている MTG などの予定もここで一元化してしまう。
これを始めたきっかけは、「必要な時間」とはすべての機能開発にかかる時間の総和であり、「使える時間」とは期日までに自分が実際に作業できる時間であると考え、ならばそれらをすべて可視化すれば算出ができると考えたからである。
具体的には上記のようなまとめ方をしている。
実際の気付きとして以下のものがあった。
- このリストが片付けば完了であるという安心感がある
- この通りに進めば期日通りに完了できるという安心感がある
- 作業完了日がひと目で分かる
- なんの見積もりがずれているかひと目で分かる
このリストには全タスクと作業できる時間がまとまっているため、作業完了日が明確に見える。また、見積もりと実際の作業時間を並べているため、振り返りをする際に必要な情報もまとまっている。
予想外の成果だったのは、安心感を持って作業できることによるメリットである。
間に合うのかどうかヤキモキすることが減り、不安だから見積もりをもう一度考えよう、といった開発以外の作業を抑えることにつながった。
この資料を運用する際には、以下の点に留意している。
- 増えたタスクはすぐに追記する
- 変更のあったスケジュールもすぐに反映する
- 見積もりの指針を揃える（ゆるいかキツいか）
ここに一元化されているという点が安心感につながるため、他のメモやカレンダーにタスクが分散しているのは望ましくない。また、差し込みスケジュールもある程度は避けられないため、それも随時反映していくことで、資料と実際の状態を等しくすることができる。
最後は振り返りの際に重要な点で、見積もりの指針がぶれていると正しく見直すことができない。キツめに見積もって遅れたなら誤差だが、ゆるめに見積もってなお遅れたなら、それは作業の重さや自分のスキルに誤認識があるかもしれない。
やってみたが合わなかったこと
下記のやり方も試したが、自分には合わなかった。
- 1.5倍の見積もり
- 2点見積もり
1時間と見積もったものを1.5倍として考え、が実際に1.5時間で完了した場合、確かに遅れは発生しない。ただし、なぜ1時間と考えたのにズレが起きたのかを発見しにくくなる。そのため、この方法は基本的に用いていない。
2点見積もりとはキツめの最小見積もりと余裕を持った最大見積もりの2点を予め置くことで、大きなズレを回避することができる手法のことを指す。悪い方法ではないが、自分の場合は初期の見積もりを1番精度高く行い、中盤以降は微調整をしながら進めていく。そのため、見積もりを2重でやるような形になってしまい、自分には合わなかった。
まとめ
自分のやり方を整理したものをまとめてみた。
やっていることは大きく3点。
- 自分がしたすべての作業を時間とともに記録する
- 自分がするすべての作業を見積り時間と共に記録する
- 自分が活動できるすべての作業時間を書き出す
やってみた上での気付きとしては以下の点がある。
- やること、所要時間、作業できる時間などすべての因子を可視化することで、大規模開発であっても一つ一つ分割して考えられる
- 情報が一元化されていることで作業途中の様々なストレスを軽減し、開発に集中することができる
「ゲーム開発マネジメント勉強会 vol.2」に行ってきました
「ゲーム開発マネジメント勉強会 vol.2」に行ってきました。
management-for-game-development.connpass.com
場所は目黒のアカツキです。
最近は業務でチームで開発を意識することが増えてきたため、勉強させてもらいました。
前半は登壇発表、後半はトークセッションという構成でした。
いきなり感想
具体的な話が多く聞けたので、非常に参考になりました。
登壇発表では、実際にアサインされたチームでの事例が話されました。チームごとに抱える課題、そしてそれをどう解決するのか、という内容が方針と手段をそれぞれ具体的に示されており、非常にイメージしやすかったです。
トークセッションでは各社ごとの違いが示されたのが興味深かったです。たとえばチームで用いているツール、用いることをやめたツール、最初にやること、定期的にやること、やらないこと、といった内容がありました。特にツールは各人思うことが多いようで、非常に面白かったです。
考察
マネジメントを「ゴールを示し」「安心できる環境を作り続ける」と定義しているのは、自分がまだ曖昧にしか見えていない PM のミッションを非常に明確化している印象を受けた。
また、多くの課題がある状況下での対処法として、無理矢理にでもシンプルな課題へと落とし込み、しっかりと進捗を実感できるようにすることでチームのモチベーションを下げずに進む、というのは非常に参考になる考え方だった。
トークセッションの中では、特にチームビルドの重要性と、そのために必要なマネジメントを感じることができた。自分ができるからみんなもできるだろう、ではなく、全員ができるような環境をいかに作っていくか、自分が環境づくりができるような関係性をどう作っていくか、ということが、マネジメントをする者にとって非常に重要な課題であると認識できた。
発表メモ
開発マネジメントとは
スピーカーにとってのマネジメントとは
- 開発を統括しゴールを目指すこと
- 仕事の話なので収益化は当然必要
- 「価値向上」を「計画」し、「実行」し、そこに「責任をもつ」こと
なのですが...
- 特にゲーム開発では普遍的なマネジメントモデルがない
- PM いない場合もある
- P 兼任のディレクターがいたりする
- P がいっぱいいる場合もある
- 立場と裁量が噛み合わっていないこともある
メンバーがマネジメントへの意識が希薄な場合が結構ある
- メンバー全員がマネジメントの意味を理解できているケースは少ない
- PM チームへの啓蒙も必要
- そうするといざというとき協力を頼めるようになっていく
事例1
- PM にゲーム作る（ディレクター業務）以外をやってほしい的な事例
- 実行のリスクをどう管理するか
- 見守ることは管理ではない
- リスクとは：コスト、スケジュールなど様々ん危険性をまとめた言葉
- リスクの把握をすることがマネジメント
- 把握とは：想定外の事態で何が起こるのかを予測しておく
- 想定外事象は影響度と発生率で評価する
- 例：インゲーム部分が決まらないと他のとこ作れないから影響度デカイ、みたいな
- わかりにくい事象でも各メンバーが報告しやすい関係性をいかに作っていくか
- 厳しく、優しく、上から、仲良く、混ざっていく、などやり方は様々
- PM もメンバーの一人（あくまでスピーカーが用いている考え方）
- あまり評価のやり方は固定しない方が良い
- 具体的な手法：視点を増やして精度を上げる、執念深く対策しまくる
事例2
- 売上悪いから助っ人して、的な
- 期待値：PDCA 回して KPI を改善する
- やること：ゴールへの道筋を示す
- 答えが簡単ならそもそも PM の増員とかいらないはず
- 複雑な事象をシンプルな問題に見せかける（これだけだと詭弁ぽい）
- もうちょっとちゃんと言うと...
- やることが多すぎるとリスク管理も困難、結果メンバーのモチベーションも下がる
- シンプルな大目標中目標を作って進捗を見えるようにする
- シンプルなゴールに向かうストーリーを用意し、進捗している実感を得られるようにする
疑問
- Q. シンプルなゴールとは、1番大きい課題や、近いものをまとめてしまう感じ？
- 本質に近いものを抽出する
- 事例：格ゲーなら格闘部分が楽しめるならチュートリアル改善は後回しでいいだろ、みたいな
- それらを現場主導で発見し、いかにスムーズに導くか、がマネジメント
事例3
- 炎上してるからなんとかして、的な
- リスク管理できるところまでスリム化する
- それができてから、作業遅延解決とか改善の話を始める
- やっちゃいけないのは、このまま頑張れ、的な放置
- ↑安心できる環境を作る、というマネジメントができていない
まとめ
- マネジメントとは
- 道筋を示すこと
- リスク把握、対策を継続的にやること
- 安心して開発できる環境を作り、改善を続けていくこと
トークセッション
トーカー
湯前 慶大 : 株式会社アカツキ VP of Engineering/認定スクラムマスター/認定LeSS実践者
山浦 大輔：株式会社ディー・エヌ・エー ゲームコンテンツ事業部 第一開発部 エンジニアグループ マネージャー
山田 元基：株式会社QualiArts 技術責任者/プロジェクトマネージャー
開 哲一：ワンダープラネット株式会社 執行役員 VP of Engineering
BTS/ITS
- JIRA は BTS としては有用（タスク量の可視化が容易なため）
- Wrike よかった
- Trello っぽい使い方もできる
- カンバンもガントもできる
- ゴチャゴチャしてない
- 管理が得意な人がやるとすごく高速にできる
- 欠点：高価
- EP は年間100万円
- 他のツールは？
- asana
- shotgun
- 物理カンバンの欠点はトラッキングできないこと
- とはいえ、そもそもタスクに対するトラッキングしない
CI
- jenkins の用途は？
- 静的解析とか
- プランナのデータ反映とか
- ガチャのシミュレーション（設定と合ってるか検証）とか
プロジェクト初期にやること
- ミッションの共有
- 何を届けるか
- 誰を相手にするのか
- 何を作るか
- 優先度の低いことを出すのが大事
- みんなで「やらないこと」の共通認識をつくる
スプリント
- 初期で設計もやってしまう（オレオレ設計を避ける）
- プレイ会ベースで振り返りをしている
- 朝会で良かったこと報告してチームビルドにつなげたりしている
ふりかえり
- 同じことをやってるような人たちでふりかえる
- KPT の量をチーム間で共有する
- K を多くすることが目標だったりもする
- サンクスカードとか
- スプレッドシートはみんな同時に書けるから良い
- 一斉に書くと、促されてみんな書くようになる
PM の悩み
どこまでチームメンバーに自己管理を任せるか
- 管理は個人の話
- ただし仕事はチームのものなので発信はしてほしい
- 発信の仕方は訓練次第
- タスクをちゃんと聞き取るのは発信者ではなくチームの課題
- プロトのときは個人で管理しないとやれないものも多い
- チームによりけりではある
- @まとめ
- 基本個人に任せたい
- ただし個人のスキルに依存してしまう
- なのでそれらを拾う動きは必要
Q. マイクロマネジメントは悪か？
- 最終的には悪だと思う
- ただし必要なタイミングはあると思う
- 最初とか
- 上から言われるのではなく、自分でタスク管理できたほうがモチベーションにもなるはず
上層部とのすれ違い
- そんなにあるか？
- 上から余計なこと言われても自分だけで止めたりとか
- 報告頻度とかコミュニケーションをいかにしていくか
- 数値ですぐ報告できるような準備はしておく
- でもまあ普段からコミュニケーションしているのでそんなに問題にならない
Gotanda.unity #8 行ってきた
Gotanda.unity という勉強会に行ってきた。
といっても先月ですが（汗）。
だいぶ遅くなったけど、復習も兼ねて印象深かったものの感想書く。
シンプルStateMachine
この粒度で実際に試して何がうまく行かなかったかを聞けたのは参考になった。
仮にこういう設計とプロダクトの齟齬を早期に発見するとしたらなにができるだろう、プロトで複数画面作って複数人数での開発を試して、とかになるのか。
シェーダー芸・入門から1ヶ月の道のり
ナニモワカラン状態から一歩一歩進んでいった話が聞けて心強かった。
写経大事写経大事。
Tilemapのアップデートについて(仮)
Unite でも聞いて気になってた！
発表中でも言ってたけど、自分がプレイしてたゲームを作れる、というのはゲームに関わっててよかったと思える。
その他
懇親会でも自作シェーダを見せてもらって興奮した。
エンジニア懇親会ならではって感じ。
感想
あまり勉強会行き過ぎないようにしてるけど（行くだけで成長した気になっちゃうから）、時々行くことでまた色々やってみよって気になれるのは良い。
あとインプットは継続してるつもりだけど、アウトプットできてないなってチクチク実感。これも勉強会の良いところ（震え声）
