この間実際の仕事の際に、「プランナーはちゃんとプログラマーに実装してほしいことを伝えるように」という話が出ていました。
これって何気にどの現場でも課題になっているんですよね。
プランナーの言うことがプログラマーに伝わらない、プランナーが実装したいものと違うものがプログラマーが実装したとかですね。
私はプログラムもプランナーもやるので、プランナーがプログラマーにどうやって伝えるとよいのかという部分を説明したいと思います。
■根本がわかっていないと伝わるはずがない
いきなり結論なんですが、一番大事なのはこれなんですよ
自分の担当部分しかわかっていない人は、正しく何を実装するのかを伝えることができません。
たまに自分の担当部分しか興味がないとか、理解しようとしないプランナーがいますが、まあ仕事放棄をしているのと変わりませんよ。
何でそうなるのかというところを説明していきます。
■必要なのは要件を伝えること
要件（ようけん）とは、重要な用件や大切な用件、あるいは必要な条件のことを指す。
Weblio辞書
開発する人であれば要件定義っていう言葉を聞いたことがあると思います。
これをちゃんと定義しないと伝わりません。
わかりやすく言うと、「何を実現したいのか？」という部分をちゃんと説明しないといけないということです。
当たり前じゃん、と思うかもしれませんが、割と部分的な実装のほうを説明してしまうことが多いです。
その部分的な実装が何を目的として作られているものがわからないと、プログラマーの作業の効率が悪かったり意図していないものが出来上がらなかったりします。
具体例があったほうがわかりやすいですかね。
今FGOで「ぐだぐだ邪馬台国」っていうイベントをやっています。
ここで「収穫クエスト」というものがあります。
定期的にそれを実行することでアイテムがもらえるという仕様なのですが、これをプランナーからプログラマーに実装してもらうときに
「イベント中に8時間に1回選択するとアイテムがもらえる機能が欲しい」とだけ伝えても、駄目だということなんです。
確かに必要な機能としてはこれなのですが、その前提として「定期的にユーザーがゲームを起動したくなるような仕組みが欲しい」というものがあると思うのですよ。これが伝えられていないとだめ。
なんでかというと、実装が可能なときにはいいのですが、実装が難しいときにこの前提が伝わっていないと適した代案が出てこないのです。
あと「8時間に1回選択できるけど繰り返し選択することができない」というものが出来上がったりもします。
こちら「イベント中に8時間に1回選択するとアイテムがもらえる機能が欲しい」という条件自体は満たしていますよね。
あとこの条件がわかっているのであれば「8時間といっているが別の時間も設定できた方がいいのではないか？」、「そういう選択が複数できたほうがいいのではないか」ということも伝わるじゃないですか。
それが簡単に実装できるのであれば、プログラマーからプランナーに伝えることで要素を増やすことができます。
逆に難しいのであれば、懸念点として伝えることで企画の方向転換をすることもできます。
前提条件を伝えることは重要で、それも含めて要件なんですよ。
■要件を考えるうえで重要なこと
でも前提条件を伝えるときに気を付けておくことがあります。
そのゲームの他の要素がコンフリクトしていないか？ということですね。
例えばソーシャルゲームであるけどユーザーに時間を使わせないことを売りにしているゲームだったとすると、この仕様はコンセプトからずれていますよね？
そういう矛盾した仕様が提示されるとプログラマーの動きは止まるわけなんですよ。
プログラムの何が大変って、もともと「Aという用途で使用する想定」で考えていたものを違う想定で使うときですね。
はたから見ると同じような機能であっても、作り直したほうが早いということがままあります。
なので最初の想定を変えたくないのですよ。だからそこがはっきりするまで作り始めることができなかったりします。
あと別の仕様と食い合っていたり、他の仕様のせいで効果的に働かない仕様になっていたり。
そういう懸念があるとプログラマーの動きは止まります。
ちゃんとそのあたりも踏まえて説明できないとだめですね。
下手するとそのあたりを気にせずに仕様を組んで実装依頼を投げるプランナーもいますからね。
もう事故レベルなんですけど、大概のプログラマーはよく考えず作ってやり直しになるような経験をしているので、そういう状況になっていないか気にして進まなくなったりするのです。
■根本がわかっていないといけない
なので一つの仕様を依頼するのであってもそのゲームの根本が、コンセプトがわかっていないといけない。
最近ユーザーエクスペリエンスという言葉がはやっていますね。
ユーザーにどういう体験をさせたいのか。
それってまさにコンセプトに即した仕様がどうなっているか、ということなんですよ。
繰り返しですが、小さな仕様であってもゲームの根本目的に即していないといけない。
逆にそのあたりをちゃんと理解しているプランナーの言うことであれば、プログラマーも安心して言われたとおりに実装することができます。
自分の言っていることが伝わらない、ということに悩んでいると自分の担当部分しか見えなくなっていくと思います。
でもそういうときこそゲーム全体がどのように設計されているのか、ということを知ることで効率よく作れるようになります。
逆に各プランナーの担当者がうまく仕様実装の説明ができていない、というときにはディレクターがゲームの方針を説明できていないのかもしれません。
そういう時は各担当の努力を増やすのではなく、一度情報の整理をしてみるといいかもしれませんね。
ちょっとありきたりな話ですが、「急がば回れ」なんですよ。