開発の「決める事リスト」には、判断するための観点も書いておく

ゲームを開発するに当たっては、画面やゲーム固有の仕様とは別に、システム的に決めなければいけない事が数多くあります。ログ出力のライブラリは何を使うのか、クライアント-サーバ間のプロトコルは何にするのか、ローカルにダウンロードしたアセットの暗号化はするのかしないのか、などなど。

こういった決め事を会社や組織の中で新しいタイトル開発のたびにやっていると、自然と「毎回同じような事を決めてるから、決める事リストやチェックリストを作って共有すれば抜け漏れが無くなって良い」という話になり、知見がある人を集めたりいくつかのプロジェクトから抽出するなりして「決める事リスト」が出来上がります。

この「決める事リスト」には何が書いてあるべきなのか、というのが今回の記事の内容です。結論としてはタイトル通り「判断するための観点を書こう」という話です。

最もシンプルなリスト

まず最もシンプルなリストとして、「○○のライブラリを決める」「✗✗のルールを決める」といった項目がひたすら並んだものが考えられます。実際に自分達で最初に作った時もそのようなリストになりました。これだけでも検討の経験が少ない人にとっては有用ですし、ベテランでも抜け漏れのチェックができるという点では役に立ちます。今まで何も無かった状態からそういったものができると、組織のノウハウを集めた雰囲気が出てちょっと良い空気になったりもするかもしれません。

ここからは具体的な例として「サーバのプログラミング言語を決める」という項目があったとしましょう。そんな基本的な部分までリストアップする必要ある？と思われるかもしれませんが、説明しやすい例として挙げています。

リストにこれだけ書いてあった場合、読んだ開発リーダーは「たしかにサーバの言語を決めなきゃ始まらないな」と思いますが、そこからは完全にその人の基準で考える事になります。「最近事例が増えてきて個人的にも気になってるGoにしてみよう」と考えるかもしれないし、「他のプロジェクトに合わせておいた方が何かと便利だからJavaにしておこう」となるかもしれません。判断が正しかったかどうかは終わってみないと分かりませんが、このような完全その人任せ方式は、特にリストを必要とするような経験が浅めのリーダーが担当する場合にちょっと心配です。

選択肢を明記する

ではうっかり変な決定をしないように、組織のCTOが検討した上で項目の隣に「JavaまたはPHPとすること」のように選択肢を明記するのはどうでしょうか。こうすれば開発リーダー次第で組織内に色んな言語が乱立してお互いのフォローができない、という事態は防げそうです。ただ、この2つのどちらかであればサイコロを振って決めてもOKなのかと問われれば、大抵の人は「いやいや、それぞれのメリットデメリットを検討して決めるべき」と考えるのではないでしょうか。

選択肢のメリット・デメリット検討を必須にする

そこで「なんとなくJavaにしました」を防ぐため、さらに「選択肢それぞれのメリットデメリットを検討の上決定すること」と書き添えておく事にします。

すると何が起きるかと言うと、「パフォーマンス: Java ◎ PHP ○」「学習コストの低さ: Java ○ PHP ◎」みたいな比較表が作られたりします。これが作られれば、件のCTOも「いや最近のPHPだとパフォーマンスは遜色無いのでは？」といった感じで判断の内容や妥当性を話し合ったり確認できますし、実際そこまでやればOKとも言えます（あくまで例なので◎○は気にしないで下さい）。

ただもう一歩踏み込むと、ここで比較する観点の洗い出しが相変わらずその人任せになっている点が課題として残っています。

判断するための観点を挙げる

ここでタイトルに書いた結論になりますが、「どんな観点で検討、判断すべきか」をリストに書いておくと、判断の妥当性や関係するメンバーの納得性を高くする事ができます。

今回の例に挙げた言語選定の場合、人によっては純粋にプログラミング言語としての特徴のみ比較してしまうかもしれませんが、たいていの場合は以下のような言語外の要素も検討した方が良いでしょう。

・その言語が扱える開発者は計画通りの人数を集める事ができそうか？
・そのプロジェクトで必須となるSDKやドライバはその言語をサポートしているか？
・今までと違う言語に取り組む事で組織の技術力の停滞を防げるのではないか？
・新しい取り組みを発信する事で若手の採用に効果があるのではないか？
・未経験の言語を選んで途中で行き詰まった場合のリスクヘッジはできるか？
などなど。

もちろん観点を明確にさえすればサクサク判断できるという訳ではありませんが、観点を練る中でその組織の規模や文化も反映できるので、組織としてリスト作りに取り組む意義は単に項目を並べた場合と比べてかなり大きくなると思います。

僕自身も現在開発にあたって色々決めている真っ最中ですが、それぞれ判断する際にどのような観点でそう決めたか、何故それが良いと考えたのかをできるだけ明記することで「決める事リスト」の改善を心がけています。

補足：　比較表の内容までリストに含めるべきか？

おそらくここまで読んで下さった方の中には「であれば、最初から比較表の内容まで埋めたものを共有すれば、読んで判断するだけになって更に良いのでは？」と考える方もいらっしゃると思います。それももちろんありですが、僕としては観点の列挙に留める方が良いと考えています。理由は、プログラミング言語ならばともかく、ライブラリやアーキテクチャなどは年々新しくて良いものが出てきたり欠点が改良されて使いやすくなったりなど大きな変化があるので、以前の比較内容が現在も妥当とは限らない（むしろ年単位だとたいてい変わって妥当ではなくなる）ためです。

つまり中途半端だったり下手すると誤情報になるかもしれない内容までリストに書くよりは、検討する観点だけを書いておく方が使う側にとって良いのではないか、というのが僕の考えです。また全然違う視点をいきなり持ち出してしまうと、きちんと最新の状況をキャッチアップしつつ比較検討するという作業を行う事で、それを行う人（開発リーダーなど）の成長やモチベーションアップにつながるという点でもそちらの方が良いと考えています。