ゲーム開発と業務系システム開発は、大きなくくりで言えば同じソフトウェア開発というカテゴリーに属しています。
しかし、実際にはそのアプローチや文化には大きな違いがあります。
僕はどちらの開発経験もありますが、はじめてゲーム業界に転職した時や、久しぶりに業務系システム開発の仕事を請け負った時にそのような違いに戸惑った経験があります。
今回はそんなゲーム開発と業務系システム開発の違いについて説明します。
業務系システム開発の仕事をしているがゲーム業界への転職を考えている人、もしくはゲーム業界で働いているがゲーム以外のシステム開発に興味がある人にはぜひとも参考にしていただきたいです。
なお前提として、今回紹介する内容ではスタートアップの企業は除外しています。
ゲーム開発でも業系システム開発でも、スタートアップの企業はそれ以外の企業と比べて状況がかなり異なるため、今回紹介する内容に当てはまらないケースが多々あるからです。
開発する機能の目的の違い
ゲームの機能における目的
ゲームの機能では、まず何よりもユーザー体験と楽しさが最優先です。
どういうジャンルのゲームであれ、ユーザーにゲームを遊んでもらえるかどうかが成功のカギとなります。
より良いユーザー体験を提供するためには、以下のようなことを重視して機能を設計する必要があります。
- ゲームの面白さ
- ゲームバランスや難易度
- 魅力的なデザイン
- ゲームをより盛り上げる音響効果
業務系システムの機能における目的
業務系システムでは、機能性と効率性が最も重視されます。
ユーザーは日々の業務を効率よく進めるためのツールとして業務系システムを使うので当たり前と言えば当たり前です。
具体的には、以下のようなことを重視して機能を設計します。
- データの正確性や信頼性
- よりシンプルな操作性
- 生産性の高さ
- エラーの少なさ
目的の違いによる開発業務への影響
機能の目的が異なると、当然ながら開発業務へも影響します。
大まかには開発業務の各段階が以下のような違いが出てきます。
※どちらのシステムでも重視されるようなことは省略
| ゲーム開発 | 業務系システム開発 | |
| 企画段階で重視されること | ・より個性的・独創的なアイディア ・市場調査やターゲット層の分析 ・コンセプトやゲームデザインの作りこみ | ・クライアントまたはユーザーとの詳細な要件定義 ・具体的な業務フローやプロセスへの理解 ・要件定義書や設計書の作成 |
| 実装段階で重視されること | ・仕様を実現するための技術的な挑戦 ・ラグやジャギー等のストレス要員の排除 | ・安定性の高さ ・既存の機能やデータへの影響の徹底的な調査 ・細かいエラーハンドリング |
| テスト段階で重視されること | ・仕様で意図したユーザー体験が達成できているか ・ゲームバランスが適切か | ・性能が基準を満たしているか ・クライアント側の受入テスト |
ドキュメントの違い
ゲーム開発におけるドキュメント
ゲーム開発では、ドキュメントの柔軟性が重視されます。
「ログインボーナス」や「お知らせ一覧」といった、どのゲームにもあるような詳細に書かなくとも理解しやすい部分については簡潔にまとめることが多いです。
逆にゲームの独自仕様のような、理解が難しい部分に関してはかなり詳細に書くことが多いです。
説明の仕方もかなり自由です。
挙動を事細かく定義することもあれば、「○○のゲームの××の機能みたいな感じ」みたいに他のゲームを例に説明することもあります。
絵や図で説明することもあったりします。
要するに、「読む側が理解できればOK」というスタンスです。
フォーマットも割と自由度が高いです。
もちろん、「もともと決まっているフォーマットを勝手に変える」なんてことはやってはいけません。
ただし、より良いフォーマットがあれば「チーム内の合意後、次回にはすでに新しいフォーマットが適用される」みたいなことは珍しくありません。
仕様書では「どういう機能を実装するか」についてはきちんと書かれています。
一方で、「どういうエラーハンドリングをするか」「DB更新をどのタイミングで行うか」等の具体的な実装方法に関しては少ししか記載がないor全く記載がないことが多く、実装者の裁量に任されるパターンが多いです。
業務系システム開発におけるドキュメント
業務系システムでは、ゲーム以上にドキュメントの重要性が高いです。
詳細な要件定義書や設計書が求められ、開発の各段階はこれらのドキュメントに基づいて進行していきます。
したがって、どのドキュメントも説明が詳細なことが多いです。
ドキュメントはクライアント(ユーザー)に提出することもあるため、記載の仕方やフォーマットは厳密にルール化されています。
コードレビューと同じくらいの重要度で、ドキュメントのレビューもあったりします。
もちろん、時代や技術の変化にあわせてルールが変わることもありますが、会議等でしっかり議論を重ねた上で判断されます。
仕様書では「どういう機能を実装するか」についてはもちろんのこと、「Aの時はエラー1、Bの時はエラー2を出力する」「DBのテーブルXのカラムYを値Zに更新する」等の細かい実装方法についての記載もあります。
したがって、実装者に関わらずある程度コードの品質が担保されます。
(とはいえ、パフォーマンスやコードの読みやすさ等は実装者の力量に大きく左右されます)
開発手法の違い
ゲームの開発手法
ゲームではアジャイル開発が用いられることが多いです。
「作ったゲームが思っていたより面白くなかった」「より良いユーザー体験の案が思い浮かんだ」等の理由で、仕様の変更や追加はゲーム開発ではしょっちゅう起こり得ます。
そのため、短いサイクルで成果物をレビューでき、軌道修正をしやすいアジャイル開発はゲーム開発と非常に相性が良いです。
アジャイル開発では、状況がコロコロ変わることが珍しくありません。
仕様変更や追加は必ずあるものとして開発を進めていくと、精神衛生上よろしいかと思います。
また、実装を進めていく上で発覚した機能の改善点や懸念点はどんどん発言していく姿勢も大事です。
そうすることで、アジャイル開発をより効果的に活用することにつながるでしょう。
業務系システムの開発手法
業務系システム開発ではウォーターフォール開発が用いられることが多いです。
クライアント(ユーザー)と密接に関わり合いながらシステム開発をする必要があります。
したがって、専門外の人にも理解しやすく、計画的に開発を進めることができ、フェーズが明確に分かれていて進捗管理しやすいウォーターフォール開発が好まれる傾向にあります。
ウォーターフォール開発では、手戻りが発生すると工数が膨れ上がってしまいます。
したがって、仕様の変更や追加は慎重に検討する必要があります。
また、そういった手戻りが発生しないよう、ドキュメントをしっかり読み込み、できるだけ早い段階で問題点を洗い出すことが重要になってきます。
新技術に対する姿勢の違い
ゲーム開発における新技術
ゲーム開発では、ゲームの質をより向上しうるものであれば新技術の採用に積極的です。
最新のグラフィック技術やゲームエンジン、最近であればAI技術等は必要に応じてどんどん取り入れていきます。
(もちろん予算や時間の都合ですぐに採用はできないケースもあります)
良さそうな技術であれば、大手ベンダーが提供するツールでもOSS(オープンソースソフトウェア)でも関係なく取り入れていくことが多いです。
当然ながら、新技術を身につけるための学習コストは必要です。
最新技術の概要くらいは常に把握できるようにしておくと良いでしょう。
業務系システム開発における新技術
業務系システムの開発では、安定性と信頼性が最も重視されます。
したがって、基本的に新技術の採用には慎重な姿勢を取ることがほとんどです。
また、クライアント(ユーザー)の意向も考慮する必要があるため、会議等の関係各所への調整や技術検証にかなり時間をかけなければなりません。
仮に新技術を採用するとなっても、大手ベンダーが提供するツールならともかく、OSSは「安定性や信頼性が担保できない」といった理由で採用が見送られることもあります。
以前に僕もOSSの技術を使った機能開発をしていたことがありましたが、クライアントの意向により採用しないことに決まり、急遽開発中止になった経験があります。
スピード感の違い
ゲーム開発のスピード感
ゲーム開発はかなりのペースで進行することが多いです。
特に、カジュアルゲームのような規模が小さいゲーム程その傾向が強いです。
ユーザーの人気の移り変わりもありますし、競合他社が同じジャンルのゲームをリリースするリスクがあるため、できるだけ早いリリースが求められます。
また、ソーシャルゲームでも比較的早いペースで開発が進みます。
ソーシャルゲームはユーザーに遊び続けてもらう必要があるため、ユーザーがゲームに飽きるより早く機能追加や改修を進めなければいけないからです。
ただし、例外的に大手のゲーム会社が多額の資金を投入して開発するゲーム、いわゆるAAAタイトルでは年単位に時間をかけるケースもあったりします。
僕はAAAタイトルの開発経験がないため、あくまでも予想になりますが、技術的な課題の解決やコンテンツの作りこみにどうしても時間がかかるために時間をかけているのだと思います。
業務系システム開発のスピード感
業務系システム開発は、計画的かつ段階的な進行をするため、比較的落ち着いたペースで進みます。
とにもかくにも安定性と信頼性を確保する必要があるため、基本的に開発スケジュールは余裕をもって設定されるからです。
あらかじめクライアント(ユーザー)と合意を取って開発スケジュールが決まっているため、予定より早く開発を進めるメリットはゲーム開発程多くありません。
開発スケジュールに沿って、じっくり着実に開発を進めていくとよいでしょう。
「業務系システム開発の仕事しているけど、毎回スケジュールがカツカツなんだけど？」という人もいるかもしれません。
そういった場合は、もしかするとブラック企業に所属してしまっているのかもしれません。
その企業があなたに合っていないのであれば、できるだけ早く転職活動を始めることをおすすめします。
まとめ
ゲーム開発と業務系システム開発は、同じソフトウェア開発でも大きな違いがところどころあることがおわかりいただけたと思います。
これらの違いはそのまま業務の取り組み方にも影響があります。
当然、人によって好みのやり方があると思います。
あなたの仕事選びにも役立つと思うので、ぜひとも参考にしてみてください。
コメント