敗戦

zankoku.txt

「フリーランス残酷物語 Advent Calendar 2016」10日目。

会社員時代を含め、これまで長年受託開発をしてきて、もちろん苦戦したものもあったが
、ほとんどのプロジェクトは、顧客の希望に沿うソフトウェアを納品してきた。しかし、
唯一、最後まで完遂することができず、どうにもならなくなり、ほうほうの体で逃げ出し
たプロジェクトがある。今日はその話をする。

それは、版権もののソーシャルゲームの続編を作るというプロジェクトだった。ある日、
別のプロジェクトでいっしょに仕事をしたことのあるXさんから、案件の打診が来た。打
ち合わせをして、座組みなどを含め概要を聞き、自分の稼働状況としては問題がなかった
ので、業務委託契約を交わした。プロジェクトの規模的に関係者も多く、ちょっと大きそ
うな案件だなとは思ったものの、この時点では、とくに問題を感じておらず、いつもどお
りコードを書いて仕事をこなせるだろうと思っていた(そうでなければ、仕事を受けない
だろう)。むしろ、版権の原作は好きな作品であったため、ちょっとテンションが上がっ
ているぐらいだった。

ただ、Flashでのゲームの実装ということで、あまり経験のない分野ではあったが、
ActionScript 3での開発経験自体は十分に積んでいたし、自分のプログラミング能力なら
問題ないだろうと思っていた。思い返せば、過信があったかもしれない。

    A社(パブリッシャー)
    ├── B社(テクニカルアドバイザー)
    │   └── Xさん
    │   └── わたし
    ├── C社(開発)
    └── D社(デザイン)

座組みとしては、上の図のような感じで、Xさんの在籍しているB社は、テクニカルアドバ
イザーのような形で入っていた。B社自体は、直接開発業務は行わない。主に開発を行う
のはC社で、これは、西日本の会社だった。サーバー・クライアントどちらもC社が担当す
る。パブリッシャーであるA社は東京の会社なので、C社以外は、A社事業所に集まって打
合せを行う。毎週定例が行われたが、C社は基本的にSkypeで参加していた。D社は、名の
通ったゲーム開発会社で、このプロジェクトではデザイン面を担当していた。今回の話に
はあまり出てこないが、やはり大変そうで、会議ではA社からの要求をはねのけるために
がんばっていた。大きなプロジェクトだったので、他にも関わっていた会社があったかも
しれないが、自分から見えていたのは、この4社ぐらいだった。最後に、わたしは、B社の
開発者という肩書でプロジェクトに参加していた。

そもそもなぜわたしがこのプロジェクトに呼ばれることになったのか。経緯などは詳しく
聞いていないが、おそらく、開発リソースが足りないという認識があり、とにかく手数を
確保したいという状況だったのだろう。当時、わたしは別に一件関わっているプロジェク
トがあり、そちらと同時に二足の草鞋で参加することになった。もう一件のプロジェクト
というのも、当初リリース予定からかなりリスケして大変だったのだが、それはまた別の
お話。契約としては、準委任契約で、作業時間をExcelに記録し、作業した時間分だけの
報酬をもらっていた。作業環境はリモートで、通勤は不要だった。

このゲームは当時稼働中の1作目があり、原作の人気もあり、けっこうなユーザー数を抱
えていた。にも関わらず、2作目を作るのは、運用面での不便さがあるためらしかった。
システムを完全に一新することで運用コストを削減するというのが、プロジェクトの動機
のひとつだ。そのため既存のユーザーを維持しつつのデータ移行も必要になる。また、こ
のプロジェクトの非常に厳しい制約として、当時、原作のほうでの大型企画が数ヶ月後に
控えており、その企画と連動させるために数ヶ月内でのリリースが必須だった。ふつうに
考えると間に合うわけのないスケジュールだが、別ゲーム用にC社が開発して展開済みの
ミドルウェア(?)を使いまわして、ちょっと修正する「だけ」なので、工数はかなり抑え
られるというロジックだった。

わたしがプロジェクトに参加した時点で、すでにプロジェクトはある程度進んでおり、仕
様としてはだいぶ詰まっているように見えた。Excelの資料などが大量にあり、最初にそ
れを読み込むだけでも一苦労だった。ただ、実装としては、サーバー側・フロント側とも
基盤部分などある程度進みつつはあったが、ほとんどの部分は、これから作っていく必要
があるという段階だった。

そんな中で、とにもかくにも、まずは参加しやすいところということで、ちょっとしたデ
ータベースまわりの移行ツールを作成するよう言われたので、仕様書を読み込みつつ、着
手した。二週間程度でその作業が終わると、クライアントがわのソースコードを渡された
ので、ソースの構成を確認し始めた。まずは1画面、実装をまかされた。リポジトリは
subversion。近年めっきり使わなくなっていたので、あまり使いたくないと思っていたと
ころ、しばらく後に、リポジトリをgitに変更するという方針変更があり、すこし安堵し
た。

実装作業は、C社を中心として行われていたので、C社のメンバーと密にコミュニケーショ
ンをする必要があった。そのため、C社内部の開発チャットにわたしも参加して、ライブ
ラリやAPIの使い方を質問して、開発基盤に関する知識を蓄積していった。このチャット
に参加している人間で、C社外部の人間は、わたし一人という状況で、外部からは見えな
い。

参加してから何週か過ぎて、わたしにもだんだんプロジェクトの雰囲気がつかめてきた。

C社の技術力は、お世辞にも高いとは言えなかった。まず一見して、インデントがめちゃ
くちゃであることにもびっくりした。また、gitの使い方をまともにわかっているメンバ
ーは一部だけのようだった。改行コードが個人によりバラバラで、ひどかったのが、一部
の人が古いバージョンのFlashを使ってMac環境から編集しているようで、ActionScriptの
コードが部分的にCRで改行されていることだった。gitはCRを認識せず、そのパッチは1行
と認識される。差分も見れなければ、まともにマージすることもできない。わたしは、コ
ミット前にCRを自動的にLFに変換するgitのフックを書いて提案したが、なぜかスルーさ
れてしまい、状況は改善しなかった。

中でも辛かったのが、APIが異常に重かったことだ。1回のリクエストが返ってくるのに十
数秒以上かかり、どう考えても開発作業に支障をきたしていた。おかしいのではないかと
思い、定例会議でAPIの遅さについて問題提起したが、いまはデバッグモードでログなど
がONになっているためだろうという返答が返ってきて、プロダクションモードで動かせば
問題ではないはず、ということで問題ではないことになってしまった。それにだけにして
は遅すぎるし、プロダクションモードにしただけで解消される問題とは到底思えなかった
。

Web APIがステートフルな仕様なのもおかしかった。サーバー側で状態保持しており、シ
ーンの進行に合わせて複数のエンドポイントを順序正しく呼び出していく必要があるとい
う仕様だった。設計者はHTTPの使い方をろくに理解していない素人だと思ったし、そもそ
もバグだらけだった。

あるとき、キャッシュエントリがredisの上限サイズの200MBを越えてしまい収まらないと
いう問題が上がってきて、なにかが根本的におかしい気がしたが、サーバーは今回自分の
担当範囲外だったのでスルーした。

プレイヤーの好みにカスタマイズできるアバターシステムが売りで、装備に合わせてアバ
ターSWFをサーバー側で生成し、クライアント側ではそれをインポートして使えばいいだ
けという画期的なシステムだったが、残念ながら、生成されるSWFはとてつもなく重く、
正しく動いておらず、表示はバグっており、使用を見送ることになった。そんなわけで方
針変更し、クライアント側のコード制御でアバターの装備をオーバーレイ表示するという
ことになった。

gitになったはずのリポジトリが、なぜか「gitは重い」という理由により、けっきょく
subversionによる運用に戻されることになった。gitを使いこなせているメンバーは少な
かったので、これはよかったと思う。むしろ最初からsubversionのままでよかった。ただ
、たしかに、数十MBある.flaファイルを何度もコミットするので、リポジトリはどんどん
肥大化していっており、それはそれで問題だった。

サーバーサイドについてはノータッチなので把握していないが、すくなくともフロントエ
ンド側については、実装や設計に関する指針のほうなものはまったく共有されておらず、
各自が場当たり的に担当部分を実装しているような状況だった。コードレビューのような
制度も当然ない。品質や書き方は、コードの断片ごとにまちまちだ。

まわりは問題ばかりだったが、では自分にも問題がなかったかと言えば、問題はあり、
ActionScript自体には慣れていたものの、それまで主にflexというコマンドラインで
Flashアプリを開発をする環境での経験しかなく、Flashのオーサリングツール自体は使用
したことがなかった。そのため、オーサリングツールでタイムラインにイベントを埋め込
んでスクリプトを発火させるといった独特の開発手法の熟練度が低く、悪戦苦闘していた
。定石のようなものもあまり把握しておらず、結果、コードの質も低くなってしまってい
たと思う。

そのような次第で、毎週参加する定例では、スケジュールに対する遅れが報告され、その
たびに守られることのない線表がアドホックに切り直されるという始末だった。ただし、
前述の原作大型企画があるため、最終的な納期が伸びることはない。実装すべき量は変わ
らないまま、期間だけがどんどん圧縮されていくような状況だった。どう考えても間に合
うはずがないという認識は、おそらく多くの人間が持っていたはずだが、それを口に出す
人はいなかった。

あるとき、一作目の制作に関わっていたというプログラマーが、パブリッシャーA社のス
タッフとして開発に参加してきた。彼は、悲惨なコードを見て、とても怒っていた。たぶ
ん、わたしの書いたコードも怒られていた。要求されてた機能をどうにかこうにか実装し
てやりすごしてはいたものの、製品としてリリースできる品質でないことは自覚していた
ので、申し分けなかった。ともかく、彼は怒りながらがんばっていた。

当然のごとく当初のリリース予定には間に合わず、原作の大型企画は公開された。そちら
のほうは、大成功を納めていたようでよかったが、こちらの地獄はそれとは関係なく続い
ていった。ある日、それまで開発の中心部で動いていたA社のディレクターから、メーリ
ングリストに「一身上の都合により退社することになりました」というメールが流れてき
たときは、びっくりしたが、さもありなんという感じだった。この時期になると、もう自
分も、いつどうやってこのプロジェクトから抜けようかということばかり考えていた。自
分としては、当初B社と交わしていた契約期間があったので、ともかくそこまでやりきれ
ば逃げ切れると思っていた。もはや、お金をもらう以外にこの仕事をやるモチベーション
はゼロだった。

ただ、ひとつ問題だったのが、自分が割り当てられていて、口約束でやると言ってしまっ
ていた機能が、どうにも契約期間内にやり切れなさそうだということだった。 自分の立
場としては、契約内容からしても、ともかく契約期間が終わってしまえばそれ以上作業を
する義理はないのだが、それは、わたしがチームのメンバーとして入っている開発担当C
社の開発者たちからすれば知らないことで、やると言ったのだから、最後までやってくれ
ないと困ると言われてしまった。ともかく、自分の直接の契約相手であるB社のXさんには
、次のスケジュール(たっぷりと休養を取る)があるので、契約を更新することはできない
旨を伝えて、契約終了までになにをやっておけばいいかという話を進めた。

状況がよくなかったのは、C社の内部チャットルームに、直接契約関係のないわたしが一
人で入ってしまっていたことだった。開発が問題なく進んでいればいいのだが、トラブル
が起きているとなると、その中で孤立してしまい、ともかく自分の身は自分で守るしかな
く、とても辛かった。たぶん、あそこに一人で入ったのは間違いで、B社の人にもいっし
ょにチャットルームに参加してもらい、間で調停してもらうべきだったと思う。とにもか
くにも、契約期間は終了なのでこれ以上はできないという話で押し切り、しかかりだった
機能をどうにかこうにかキリのいいところまで形にした。先方にどのような項目があれば
いいかヒアリングした上で引き継ぎ資料を作成して、プロジェクトを抜けることができた
。もろもろあったので契約終了日から数日足が出てしまったが、そのぶんの費用は別途請
求した。

去り際に、だれか開発に入れる人材はいないかという話がXさんからあったので、当時フ
リーランスになりたてだった知人のYさんを紹介して、入ってもらうことになった。去る
直前にYさんがC社のチャットルームに入ってきたことは確認したが、まったく発言はして
いなかった。その後しばらくして、YさんはSNS上で消息不明になってしまった。わたしは
抜けてしまってプロジェクトに関する情報をいっさいみなくなったので、YさんとB社・C
社の間でどういうやりとりがあったのかは知らない。数年後、Yさんは田舎の福岡で暮ら
しているという知らせが、風の噂で流れてきた。

そのゲームがリリースされたという話は、ついぞ聞くことがなかった。40人程度が6ヶ月
くらい動いたとして、1人月100万円とすると、ざっくり数億円が消えたことになる。

なぜ負けたか:

* そもそもスケジュールが最初から破綻していた(原作大型企画と連動するという計画が
  最初から無理だった)。
* C社の手に負える案件ではなかった(1作目の制作会社が開発を担当するべきだった)。
* フロントエンドに関して、すくなくともFlashでのゲーム開発エキスパートが2,3人は必
  要だった。

どうすれば同じことにならないで済むか:

* わからない。
* 打診を受けた段階では、このようなプロジェクトだとは夢にも思わなかったし、今後同
  じような情報を与えられても、同じように見抜けない可能性がある。
* 入る前にプロジェクトの状況を詳細に把握できていたら違ったかもしれないが、それも
  難しい。
* せめてできることは、プレッシャーに負けずに、安請け合いをしないよう気をつけるこ
  と。