はじめに

　この文書は、「ゲームの仕様書に必要なコト」の続きです。
「ゲームの仕様書に必要なコト」の中に書いたゲームの仕様書の「目的」について、プロジェクトのリーダーシップとフォロワーシップ、そして、組織論的なものも少し扱ってみよう、という割と意欲的な、ものです。
　だものですから、ゲーム作りだけでなく、ゲームをプロジェクトとして作る場合に、ゲームの仕様書の「目的」とはどのように扱ったら良いのか？というものになるかな、と思います。
　とは言うものの、私はフリーのゲームデザイナーに過ぎず、実際に大きなプロジェクトのリーダーをやった事はありませんから、あくまで、伝え聞いたり読んだりした事を元に作った論、と言う事になりますので、その点、ご承知おきくださいです。

リーダーシップとフォロワーシップ

　さて、フォロワーシップの説明の前に、その対となるリーダーシップのおさらいです。
　ここでは、リーダーシップもフォロワーシップも、ゲームの仕様書の「目的」を扱うための限定的な意味合いで扱いますから、きちんと組織論を学びたい方は、そういう書籍をご参照くださいね。

リーダーシップ

　ちょっと調べると「組織を率いる能力」の事、と出ます。良く聞く言葉ですから、読者の皆さんもご存知だと思います。
　では、ゲームの仕様書の「目的」だとどうなるでしょう。
　そのものずばり「目的」をリーダーが書く、と言う事になります。
　つまり、ゲーム全体の構成やユーザー体験など、細かい点までリーダー（ディレクター）が決めていく、と言う事を意味します。
　もちろん、実際にはそういう現場はあまりないかも知れません。リーダーの負担が大き過ぎますからね。最近のゲームの大きさを考えると。

フォロワーシップ

　こちらはもしかしたら耳馴染みないかも知れません。
　フォロワーは、リーダーの下でプロジェクトを行う人、と言う意味になります。
　そしてフォロワーシップだと、リーダーの指令と現場での意見が食い違った時に、積極的、建設的に議論していく、という意味合いになります。

潜水艦

　この言葉を知ったのは、元海上自衛隊海将の伊藤俊幸氏がとあるラジオ番組のゲストとして語った内容からでした。
　氏が潜水艦の艦長をしている時、例えば潜水艦を出航する場合、艦長が命令を発してトップダウンで動かしていくのではなく、どちらかと言えばボトムアップに近い形で下から出航準備が整い、出航できるようになると、出航しますか？という形で上がってきて、それに対して艦長が「OK」か「待て」と言う判断をする、というお話でした。記憶で記述しているので、細かい食い違いがあるかも知れません。
　補足すると、いつ出航するかと言う計画は既に決まっていて、それに対して各部署が準備をして、出航可能になったら、それを艦長に伝える、という流れだと思います。
　そして、どうしてそのようにしているか、というお話がとても興味深かったです。
　海上自衛隊、つまり、事と次第によっては艦長が負傷するなどして任務を遂行できなくなる可能性があるから、だそうです。もしトップダウンでしか潜水艦が動かせなかいとしたら、艦長が任務遂行不能になった途端、指揮系統は破壊され、潜水艦は動かなくなってしまいます。
　先のボトムアップ式であれば、艦長に出航可能と伝える人物が艦長に代わる事ができます。
　そのため、だと。

ゲーム仕様書の構造

　ちょっと話が脱線します。
　ゲームの仕様書について、説明した方がこの先の話が進めやすいと思ったからなんですが、皆さんはゲームの仕様書って、全体としてどんな構造になってると思いますか？
　もちろん、各項目があって、それを詳細に記述する、と。
　まあ、そうなんですが、実際は大きなカテゴリに分けて、カテゴリの中に小さいカテゴリを入れて、という階層構造になるんです。
　サンプルとして、だいぶ昔のものになりますがターン制のRPGを取り上げてみましょう。
　下の図は、ゲームの仕様書の階層構造です。もっと多岐に渡りますが、説明のサンプルとしてはこの程度で良いかなと。

リーダーが決める「目的」とフォロワーが決める「目的」

　前述のリーダーシップでも述べましたが、すべての仕様書の「目的」をリーダーが定義するのは、現実的ではありません。
　では、どうしたら良いか。
　リーダーが決めるべき箇所だけリーダーが決めて、残りは各部署の担当にお任せする、という方法を考えています。
　これはちょうど、潜水艦がいつ出発するか、は艦長が決めるけれど、各部署の作業内容や人員配置はその部署で行なって、出航可能になったら艦長に伝えられる、という事に置き換えられると思います。
　では、リーダーが決める「目的」って何でしょうか？

リーダーが決める「目的」

　私はゲームの目的は、プレイヤーにゲーム体験を提供する事だと思っています。
　ですから、そのゲーム体験は「どんなもの」にするか、という点はリーダーが決める必要があります。すべての仕様書はその目的を達成するための手段なんですから。
　おそらく、この「目的」は企画書に書かれていると思います。
　そうすると、その他の「目的」ですが、先の図１をご覧頂くと、大体この辺りくらいがリーダーが決める「目的」ではないかなぁ、と思います。
　リーダーのやり方によっては、２階層目くらいまでかも知れません。（PCパラメータ、敵パラメータは書かないよオレ、という方、多い予感）
　この辺りは、リーダーとフォロワーの関係性で決まるかな、と思います。

フォロワーが決める「目的」とその理由

　リーダーが決めた仕様書の「目的」の下の階層などがフォロワーが仕様書の「目的」を決める事になります。
　なぜリーダーではなくフォロワーなのか？と思いませんか。
　先にも書きましたが、リーダーが全部を書く事は大規模なゲームでは現実的ではありません。ですが、それは今回お話しするメインの理由ではありません。
　それは、その仕様書をフォロワーが自発的に書くためです。そのために自分で「目的」を定義するんです。
　そしてそれは、リーダーにとっても有用なんです。担当フォロワーが、ゲームの大目的をきちんと理解しているか、を把握する事ができるからなんです。
　もちろん、仕様に落ちたものから目的を導く事もできますが、それだと仕様が出来てからになりますし、仕様から目的を導くのは少し手間がかかります。
　また、対話の論点が「目的」から仕様の詳細の話になる可能性も割とあります。
　フォロワーが書いた「目的」がリーダーが作りたいゲームの「目的」と合致しているか、それを確認して、必要なら修正する、そういう事が比較的容易に行えると考えるからです。

フォロワーが「目的」を書くもう一つの理由

　実はこれが重要なのでした。
　この辺からお話が組織論ぽくなります。
　ちょっとだけドラッカーを齧った時、こんな感じの話がありました。
　社長という業務は、社長をやっていないと分からない。
　それを聞いて、そうれはそうだろうと。
　でもこれを事業承継という視点で見ると、怖いですよね。
　代替わりすると、社長業務を知らない人が社長になる、という事ですから。
　それで、事業部制、という仕組みが生まれたんだそうです。
　事業部を小さい会社と見なして、そこでの社長という経験を積む。
　そういう仕組みです。
　そこで有望な人が次の社長になる。そのための事業部制、というお話です。
　で、フォロワーが「目的」を書くもう一つの理由って。
　もう想像がついたのではないでしょうか。
　潜水艦の話もこれにつながります。
　プロジェクトリーダーが万が一、任務遂行不能になったら、代行できる者を用意しておく。
　これが、フォロワーが「目的」を書く理由です。
　もちろん、プロジェクト期間中にリーダーが任務遂行不能になる、という可能性に対処するだけではありません。
　次のプロジェクトでは別の人がリーダーをするケースもあるでしょう。会社組織が大きくなっていけば、プロジェクトは同時に複数立ち上がる事も起こると思います。
　その時、ちゃんとリーダーできる人が他に育っていなかったら？
　とてもリスキーです。
　このケースでも、リーダーになれる人を育てておく事は重要になります。
　そして、その手段としての、フォロワーが「目的」を書く、なのでした。

おわりに

　ゲームの仕様書とは少しずれたお話だったかも知れません。
　ゲーム仕様書の「目的」をきちんと書くのは、とても大事な事ですし、高い視点が必要な作業です。
　今回、ゲーム仕様書の「目的」をフォロワーが書く、という話を書こうと思ったきっかけは、
下田 紀之氏の著作「ゲーム開発プロジェクト管理の基本」を読んだからでした。
　この著作の中でゲーム仕様書の目的はディレクターが書く、とあり、そうなんだ！と思ったためです。
　私は小規模だったり、一部門（戦闘とかね）をまるまる任されて仕様書を書くのが多かったので、目的を他の人が書いて、それに沿って仕様書を書く、という経験がありませんでしたから。
　そこで、ゲームの仕様書の「目的」をディレクターが書くのって、なんだか弱点があるような気がする、と考えを巡らす内に、この記事の内容となったのでした。
　この記事では、ゲームの仕様書の「目的」、という点に絞って書いていますが、勘の良い方なら、この手法は他に応用して、次のリーダーの育成に使える方法に気づくのでは無いかと、期待しています。
　この記事の内容が、皆さんの糧となれば幸いです。