モバイルゲームクライアント開発のテクニカルディレクターなどを最近やっている須藤 崇浩 | 面白法人カヤックと言います。

こちらは面白法人グループ Advent Calendar 2022 の24日目の記事です。

明日はクリスマスですね。クリスマス翌日に売れ残って割引されたスイーツを買って美味しい思いをするのが好きです 🎂

本記事では表題に関して、昨年から参加しているモバイルゲーム開発案件で立ち上げから試行錯誤してる事について書いていきます。

「何故か開発後半でコードが複雑になってメンテナンスしづらくなる」「人間に書かせるべきでは無いのではないか？」..などコードの品質について悩んだ経験のある方に多少なりとも参考になる内容になれば幸いです。

目次

• 目次
• コードレビュー
  • 開発初期
    • 「チームとして良いとされるコード」とは？
  • 開発後期
• 新人のオンボーディング
  • 複雑度の低いシステムから徐々に難易度を上げていく
  • 実装前の設計を慣れてる人と一緒にやる
• 同じIDE使う
  • コーディングスタイルを制限させてコードレビューでの指摘を減らす
• エンジニアを短期間に複数人入れない+人数を増やしすぎない
  • 最大人数
• その他ここで触れてないことについて
  • テストコードを書く
• おわりに

コードレビュー

大雑把に以下の理由でレビュワー2人体制で進めてます。

• 片方が調子悪い場合でももう片方でカバー出来そうだから
• レビュー箇所のメンテナンス出来る人を増やしたいから（でも全員で見るのは効率が悪いので絞っている)
• レビューの品質追求以外に、メンバーの教育目的にも使いたいから

また、後述する様に開発時期によってレビュワー選定の基準がありました。

開発初期

この時期には品質のブレを少なくした方が「チームとして良いとされるコード」がシステム全体に行き渡り、チーム全体でのイメージを固めるまでの速度が早いのでレビュワーを少数に限定してます。

そもそも初期は人数も少ない場合が殆どなので基本的に相互レビューする様な関係になるしか無いんですが。

「チームとして良いとされるコード」とは？

ちなみにこれについて少し脱線して解説します。

良いコードは一般的なイメージとしてもある程度固まっている印象がありますが、その上で一緒にコードを書いていくチームの上限にあたる実力に沿った形で議論→合意を繰り返して固めていくものだと思っています。

なので、「一般的に良いとされるコード」と「チームとして良いとされるコード」は一応分別して書いてます。

でも長いので、以降は「良いコード」に省略させていただきます。

開発後期

開発日数が積み重なりチームの練度が上がってきたらレビュワーの選定基準を変えてます。

状況に応じて以下の様な役割と目的を分類してレビュワーをアサインしています。

• 新人(能力関係なくチームに入りたての方)：良いコードについてコードレビューする事で理解を深めて欲しいから
• 良いコード書ける人：レビューを通じてより良い設計や書き方を指摘してほしいから
• 将来そこ周辺をメンテするかもしれない人：レビュイーに比べると自分で書いてないので理解度では劣るけど、レビューする事でふんわりレビューした機能への理解が深まるので将来そこ周辺の実装をお願いできるかもしれないから

新人のオンボーディング

開発している途中で人の入れ替わりがあったり、開発体制を拡大するためにエンジニアを増員する事があります。

基本的には新人の経験やスキルによりますが、2ヶ月くらいの間はOJTの対象として迎え入れています。

気をつけている点は以下です。

複雑度の低いシステムから徐々に難易度を上げていく

参考になる実装を提示しながら実装方法について解説してます。

• 画面の作り方
  • 一部の要素のみの変更
  • 画面の新規作成
• 新規種類のアセット追加作業
• サーバーと通信する実装など...etc

実装前の設計を慣れてる人と一緒にやる

システム全体の理解度が他メンバーに比べて低い状態なので、コードレビュー時の議論や指摘を抑えるための対策で実装に入る前に以下を確認しています。

（コードレビューはレビュイーとレビュワーのシステム理解度や実力にギャップが大きい程マージまで時間がかかると思っているので）

• 開始から実装完了までの段取り確認
• どういったクラスを設計すればよいか、どの周辺システムを使えばよいか...etc

同じIDE使う

私のチームはUnityを使っている案件なのでみんなで同じRider: JetBrainsのクロスプラットフォーム.NET IDEを使うという方針があります。

理由としては以下になります。

• IDEの機能についての共有がしやすい
• Pluginも便利なのあったら共有できる
• コーディングスタイルを制限させてコードレビューでの指摘を減らす

コーディングスタイルを制限させてコードレビューでの指摘を減らす

制限させる事によってインデントやスペースなどのスタイルが担当者によって左右されなくなるので、文章としてのコードが読みやすくなる恩恵があります。

私のチームではEditorConfigファイルを共有してそれを各自のIDEに導入しています。

設定にコーディングルール違反などの漏れパターンがあったら更新してチームメンバーに再共有されます。

EditorConfigは各テキストエディターに幅広くサポートされてるので、Rider以外を絶対に使いたい方が居ても一応許容できる体制にはしています(RiderはUnityに対するサポートが手厚いので強く推奨してますが)

エンジニアを短期間に複数人入れない+人数を増やしすぎない

先程も触れましたが基本新人が慣れるまでの期間を2ヶ月くらいと見て、少なくともその間にまた新人をチームに入れないようにしています。

割れ窓理論というものがあり、システムの中で一部でも品質の低いとみなされるコードがあってそれが見れる状態にあると、たまたまそれを参考にしたりした人が他のシステムにもその品質を流用されてしまい低い品質が広がってしまう可能性があると思うので気をつけています。

最大人数

また、最大人数にも気をつけています。

開発する製品の規模や種類にもよりますが、一般的なモバイルゲーム開発においてクライアントエンジニアは10人以下になるのが理想だと肌感で思っています。

同じシステムを触る人間が10人を超えると人力では品質保証が難しく、静的解析やアーキテクチャの制限度合いを上げるなどの対策をしなければいけないと思っているので。

（何か自動化の余地があったり、期間で動くものを作らなければいけないスケジュールの場合....などの問題があることが多いと勝手に思ってます。）

大人数での開発について考える事自体は楽しいですが、可能ならやらずに済むのが楽だと思ってるし、製品規模やスケジュールに適した体制やアーキテクチャや品質目標を採用すべきだと思っています。

その他ここで触れてないことについて

テストコードを書く

過去に2案件程で試したのですが、コスパを考えると割にあわない経験をしたので個人的に諦めてます。（周りでもっと成功事例が増えれば再挑戦したいです）

理由としては以下がありました。

• ゲームクライアントを構成する要素の多くは画面に表示される情報になるため、そこのテストをどうするかが難しい
  • 弊社だとせいぜい以下の様な仕組みを実行する程度に済ませています

techblog.kayac.com

• ゲーム制作は試行錯誤のイテレーションが多く、その試行錯誤の多くにクライアント側の表示内容に関する制御処理が多く、更新頻度が高いから
• コードのみで完結して、仕様変更の影響を受けにくいまとまった処理など(OSSのライブラリや、ゲームシステムの基盤など)に対しての品質保証には有効だとは思っています

おわりに

ここまでお読み頂きありがとうございました。

こういった事柄に関する知見はプロジェクトや環境によって異なる解決（≒正解）があるのと、つい外向けに出すと綺麗事を並べたり事実をボカしてしまうので難しいのですが、なるべくそのままの状況をお伝えしました。

もし宜しければ「私はそう思わない」「うちはこうしてる」...など感想をTwitterやブクマでシェア頂けると嬉しいです！！