概要
テンプレートや規約が無い環境では、エンジニアに共有される概要や仕様書は作成者によって内容が変わってくる
機能の一部がまだ仕様未作成だったり、「何が変わるか分からないけど拡張性高く作っといてください」と言われることもある
そんな中でも開発を進めなければいけない
「流石にここは変わらないだろ」と思っている部分に変更が入っても、「今からじゃ時間が足りません
」ということにならないようにしたい
まだ発展途上だが、自分の仕様書や仕様作成者との関わり方, 考え方を書き留めておく
仕様書
書いてある数字は変わりやすい
「装備枠は2つ」「同じキャラクターが3つ揃ったら進化する」「アイテムの最大所持数は4個」
仕様書にこう書いてあっても油断しない
できる限り変更に柔軟な実装をしておく
事前に対応できないものには、対応にどのぐらい工数がかかるかを自分の中に持っておき、いざ変更要望が来た時に答えられるよう準備しておく
画面遷移と表示要素は変わりずらい
「ホーム画面 -> バトル準備画面 -> バトル画面」
といったような画面遷移は変わりにくい
また「ホーム画面ではプレゼントボックスとバトル開始ボタンを表示する」のように、表示する内容は変わりづらい
その代わりデザインは常に変わり続ける
値の最大値最小値
全ての数値には最大値と最小値を持たせた方がいい
また、有効桁数や文字列の最大長も決める
例えばキャラクターのレベルや攻撃力、攻撃力倍率など
これが自由すぎると、予期せぬ不具合が発生する
決めるコストと不具合修正のコストを比べた時に、決めるコストが圧倒的に低いので決めておくべき
基本的に最初から記載があることは少ないので、エンジニアから足りていない部分をどんどん提案する
データの形をそのまま採用しない
時々想定のDBのテーブルまで記載してくれる人がいる
とてもありがたいが、実装との兼ね合いがあるため自分らで再度考え直すこと
ここにこだわりを持っている人とまだ会ったことがないので、変更要望が通りやすい
実装されたロジックと仕様書が対応づけられているようにする
仕様書に記載されているロジックの分割で実装されていると、後から入ってきた人やエンジニア以外の人に説明しやすい
また、不具合が発生した際も修正しやすいし、偉い人に話しやすい
仕様作成者
細かいことも変更されたものもドキュメントへ記載してもらう
口頭やチャットのみで情報伝達を終わらせない
細かいことでも必ずどこかへ記載してもらう
機能実装の際には 仕様書へ記載 -> 実装する という流れを守る
「先に実装進めちゃって」というのも極力許さない (※もちろん期限優先で)
面白さについて話す時には発言に注意
「面白くない」と言うのは最終手段にする
相手も人間で、作ったものにそんなことを言われたくない
「ユーザーの選択幅が少ない」や「プレイ目的を感じにくい」なども同様
もうさっさと自分が面白そうなものを作ってしまうか、「うわーーー、ここにミッションとかあったら絶対面白いんですけどどうですか！？」みたいに無邪気な感じで言っちゃう
面白さについて議論モードに入るのは時間の無駄になることが多いし、結論がふわっとしがち
仕様の変更への温度感を伝える
「ここは変えられます」「ここは時間かかります。」とかをどんどん伝える
そのために仕様の変更の話には敏感になっておく
運用時のデータ量を聞いておく
ページングは必要？イベントの期間かぶりはある？
ユーザーが所持するアイテムの総定数はどのぐらい？
運用時にどのぐらいのデータが作られるかを確認しておく
仲良くなる
これが一番
仕様の方針や運用時の想定など、いっぱい聞き出しちゃおう
まとめ
開発に楽しくなりすぎない
ビジネスを阻害しないために、仕様をある程度ハンドリングすること