共通化でモチベーションと効率が低下した話

自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。

背景

当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。

その中で行われたのが二つの共通化です。

コードの共通化

今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプリでは画像やテンプレートを管理しつつロジック部分は共通モジュールを参照するようにしました。これによってサブモジュール一回の更新で多くのアプリにその更新が反映できるようになるという目論みです。

チームメンバー(プログラマー)の共通化

コードを共通化したことにより少ないメンバーでアプリの開発が出来るという見込みから複数のアプリのメンバーが統合し、これまでアプリA・アプリBという編成だったチームが、ガチャ・イベントといった機能別のチームになりました。

結果は失敗だった

結論を言ってしまえばこのやり方は明らかに失敗でした。

プログラマーのモチベーション低下

これまでのやり方では各アプリごとのチーム¹であったため自分の開発するアプリをやり込みながら意見を言い合って技術者も企画出しに参加していましたが、対応しなければいけないアプリが増えてひとつのアプリに愛着を持ってやり込むということが難しくなり、仕様を理解する程度にしかプレイしなくなりました。そうすると自己肯定的に開発をするのではなく単に時間を切り売りして作業をするという感覚になり技術者のモチベーションは低下しがちになりました。

開発効率の低下

ゲームロジックをサブモジュール化するというアイディアは似たようなアプリを運営する上で効率的なようにも見えましたが、実際に運用すると柄替えとはいえ細かな仕様の違いがあったりアプリごとのイベント開発もあるためだんだんと無理が出てきて、結果的にひとつのアプリの修正が他のアプリに影響してしまうため簡単に更新をすることが出来ず開発が硬直してしまうこともありました。また、グリモバのカードゲーム時代もそれほど長く続かないことは明らかだったので共通化すること自体が不可能になっていきました。

教訓

これらの失敗から再確認できたことは以下のようなことです。

人間は機械ではない

一見効率的なように見える管理手法も人間の感情やモチベーションを考慮していない場合があります。仕事をする人のモチベーションがあがらなければ大抵のプロジェクトは失敗するか開発期間が長くなります。

無理に共通化しようとしてはいけない

プログラミングに関わる人は共通化することで後の開発が楽になったりコードがかっこ良くなったりということを目論んで共通化を考えますが、それは今回の失敗の様に逆に開発効率を下げることもあります。また、共通化がプロジェクトの意図からかけ離れた技術者のエゴでないかを考えることも必要かもしれません。

おわりに

今回は共通化の失敗について書きましたが、現在は各アプリごとのチーム編成になり、このときに作った本当に共通化するべきモジュールは技術支援チームというアプリを横断的に開発をするチームがメンテナンスをして現在も使われているので完全な失敗ということではありません。

プロジェクトには今回の失敗ようなこともあるということを頭の片隅に入れておくといいと思って投稿してみました。

1. これまでも技術基盤チームやインフラチームなどアプリを横断的に見るチームはあったし、デザイナーも他アプリのヘルプなどで横断的に見る人もいた。 ↩