課題
仕様を決めて、その通りに実装を終えたはずなのに、後になって「実はこれでは足りない」と判定されることがある。決めたことは実装されているのに、なぜ物足りなさが生まれるのか。
この記事でわかること
- 仕様通りに実装しても「物足りない」と判定されることがある理由
- スペックの分析だけでは見えない実装の質を、確認するときの視点
解決できるようにすること
以前、終了したスマホゲーム「リトルノア」への思い入れをきっかけに、都市育成×攻め込み系の新しいゲーム企画「Nestria」を立ち上げた話を書いた（終了したゲームへの思い入れだけで、新しいアプリの仕様は本当に固まるのか）。今回は、その仕様が一通り固まり、最初のバージョンを作り終えたところから始まる。実際にプレイした記憶を基準に持ち出したことで、それまで気づけなかった実装の物足りなさが見つかり、方針を立て直すことになった経緯を紹介する。
本文
最初のバージョンが完成し、残っている課題を整理してもらった
最初のバージョンの実装が一通り終わったところで、AIに「Nestriaに残っている既知の課題」を整理してもらうことにした。すると、「仲間になる2人のキャラクターが、実装として丸ごと存在していない」という報告が返ってきた。
でも、これはおかしい。「坑道の入口」や「月灯り調合所」といった、そのキャラクターに関連する施設や、戦闘に助っ人として出てくる仕様は、たしかに決めていたはず。そう伝えると、AIがあらためてコードを直接確認し直した。
報告は不正確だった。でも本当の課題は別にあった
確認の結果、キャラクター自体は実装済みだった。AIの最初の報告が不正確だったことになる。ただし、掘り下げてみると、別の3つの課題が浮かび上がった。仲間の入手・編成の仕組み自体がまだ無いこと、関連する2つの施設が名前と条件だけで実際の生産の仕組みを持っていないこと、そしてもう2種類のオリジナルキャラクターが戦闘要員としてまだ手つかずであること。どの記録にも、これらを「今回は対象外にする」という明記が無いままだった。
この3点を、次に手を付ける課題として起票した。
「実際にプレイした記憶」を基準に、重いことを伝えた
次の作業に取りかかったところで、AIへもっと重いことを伝えた。「このゲームは、実際にプレイして記憶に残っている理解と、ジャンルやスペックだけを分析した理解とでは、当然ズレがある。これはコミュニケーション不足の結果」というもの。参考にしていたリトルノアは自分が実際にプレイしたことのあるゲームで、その体験の記憶を基準に照らすと、最初のバージョンは合格ラインに届いていなかった、ということだった。
これ以降、AIには単に要望を聞いて実装するだけでなく、参考にしている作品や同じジャンルの標準的な仕様を、その都度自分で調べながらヒアリングを進める役割を担ってもらうことにした。
決めていなかった基本の7項目が出てきた
自分からあらためて指摘したところ、都市に置ける建物の数、レベルアップでの増え方、建物の配置方法、画面の向き、メニューの構成、朝・昼・夜の見た目、集める要素の有無という、かなり基本的な7項目が、最初の構想時にも実装時にも詰められていなかったと分かった。
AIがリトルノアの実際の仕様や、同じジャンルの定番作品の仕様を調べ、比較できる材料を作ってきた。それを見ながら、1項目ずつ、この作品ではどうするかを決めていった。
「使えるものがあるじゃないか」で、前の判断がひっくり返る
拠点の見た目をどうするか確認している途中、思わぬ発見があった。別に個人開発していたアプリに、ズームや視点移動ができる見下ろし型の描画の仕組みが、既に実績のある形で存在していた。それを流用する方針に切り替えることになり、これは以前「この種の視点は採用しない」と決めていた判断を、実質的にひっくり返すことになった。
決めたことを、もう一度突き合わせて矛盾を探す
ここまでの決定事項を数えると、24項目になっていた。これだけの量を積み重ねると、決定同士が矛盾していないかが心配になる。あらためて全体を突き合わせて確認したところ、見過ごせない未確認点がいくつか見つかったが、追加のやり取りで1つずつ解決し、最終的に矛盾が残らない状態にできた。
実装をやり直す順番を決めて、まず4段階を終える
最後に、実装の進め方を相談し直した。土台作り、画面まわりの再構築、ゲームシステムの拡張、遊び続けるための仕組み、そして最後の統合確認という5つの段階、16件の作業に分け直した。この時点ではまだコードには一切手を付けていなかった。
その後、5段階のうち最初の4段階分の実装を終えた。残る最後の統合確認は、専用の絵素材と音の準備が整うまで、いったん止まっている状態になっている。
まとめ
今回の一件は、「仕様として決めたことを、その通りに実装した」というだけでは、実は足りていなかったという話だった。スペックの分析だけを基準にしていた間は気づけなかった物足りなさが、実際にプレイした記憶という基準を持ち出したことで、初めて具体的に見えるようになった。結果として、最初のバージョンのほとんどを作り直す規模の方針転換になったが、その分、決め切れていなかった基本項目や、使える技術を見つけられたのも収穫だった。
| 項目 | 内容 |
|---|---|
| 結論 | 仕様通りの実装でも、実際にプレイした記憶という基準に照らすと物足りなさが見つかることがある |
| 教訓 | スペックの分析だけで判断せず、実際に体験した記憶のある参照作品を基準に持ち出すと、それまで見えなかった質の物足りなさに気づける |
| 対象読者 | 個人開発でゲームやアプリの企画・実装を進めている人、AIとの要件定義をスペック分析だけに頼っている人 |
同じ状況に陥ったときの回避策
- 仕様やスペックの分析だけで「実装できているはず」と判断せず、実際に体験した記憶のある参照作品と直接見比べる機会を作る
- AIからの「未実装」「存在しない」という報告は、コードや記録を直接確認し直すまで鵜呑みにしない
- 決定事項が積み重なってきたら、途中でも全体の整合性を見直すタイミングを設ける
この記事は、筆者が実際に個人開発している複数のモバイルアプリの開発記録（2026年9月2日〜3日）を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。
