忘却の彼方から蘇ってきたネトゲの賠償請求裁判

興味深かったのでメモ.
最初は判決文の解説記事をメモっただけだったのに,加筆していくうちに開発失敗したネトゲの歴史を探る旅に発展してた.

当初は,本件ゲームは同年3月18日までにリリースすることを目標としていたが,これに間に合わず,延期された。

その後,Y1は,同年5月21日付けで,Y2は,同月25日付けでXを退職したところ,Xは,Yらが開発設計仕様書も作成せず,突然の退職によって本件ゲームの開発が頓挫して損害を被ったとして,主位的に不法行為に基づく損害賠償として,予備的に労働契約上の債務不履行に基づく損害賠償として,5400万円の賠償を求めた。

裁判にまでいくのが珍しいだけで,ゲーム業界に限らずこの手のトラブルは日常茶飯事な気が.

明確な指示もないのに,信義則上又は雇用契約上,ゲームを完成させるためには必ずしも必要のない開発設計仕様書を上記のような手間と時間をかけて作成すべき義務があったということはできない。

まあ妥当な判決.

http://b.hatena.ne.jp/entry/d.hatena.ne.jp/redips+law/20151122/1448185741

  • id:living 記事内には書いてないけど、X社には前身となる会社があって、開発はその頃からスタートしていた。さすがに「1ヶ月でソシャゲ作って」という話ではない/「最大20対20の大人数のリアルタイムバトル」でぐぐると…
  • id:fuba “事実認定の中では,Y1が本件ゲームの開発のためにエンジニアを集めようとして行った行為について,Xから情報漏えいだとする警告がなされたとあり,このことが退職の契機になったとされる。” つらい
  • id:sue445 “最大20対20の大人数のリアルタイムバトル”ここだけでウッとなった

噂レベルだが,どうやらAmeba忘却のパンドラスフィア』?「最大20人対20人の大人数のリアルタイムバトルが楽しめる」というのが売りで,時期とサービス失敗という結果から見て,ほぼ間違いはなさそう.*1


今年上旬でAmebaで配信予定だった「忘却のパンドラスフィア」がどうなったのかと検索してみたら
開発スタッフの大多数が今年6月別会社(技術責任者他がアイレット)へ移籍して、事実上の配信中止状態に陥っていた…。
開発当時、技術責任者が勉強会に出席するほど技術の自慢をしていたのだけども、何があったのだろうか。
母体となった会社が中村建設…建設とゲーム会社、サイバーエージェントの提携の接点が不明だな…。

http://alfalfalfa.com/articles/137875.html

寒いねえ...

激怒したっていう例のアレ関連なのだろうか.時期的に近いという指摘は出てる.

  • id:eirun たとえ裁判での勝敗はどうであろうと、ただのプロジェクト単位雇用や期間雇用の技術者が訴訟に巻き込まれている時点で、生活への圧力は相当なものだよ。
  • id:nntsugu オーナーと喧嘩別れすると後がめんどくさい案件。訴訟対象者Y1、Y2が経営責任のあるポジションではない以上通るわけが無い訴訟。嫌がらせの意味も込もってたかも知れないね。皆さんお気をつけを。
  • id:uturi “一般論として,指示がないのに仕様書を作る義務まではないとした。” うむ。/これで企業側が勝ってたら労働者は永遠に退職できなくなるからなぁ。まともな判決でよかった。
  • id:aenea 実際に訴訟まで至らなくてもIT業界ってこういう脅しめいたの結構あるよなあ…平社員に責任あるわけないのに
  • id:akatuki_sato 従業員を訴えるのは無しだろ。役員になっちゃうと泥沼で裁判一歩手前でひどい目にあったオレが通りますよ。この手の千日手(苦笑)から引き上げる経験値ってなかなか蓄積されんだよね(´・ω・`)
  • id:mn112hr この判決、良いようでいてその実、ソフト開発って人に依存しているところがモノすごく大きい、っていう理解がされてない証左よなー…
  • id:zentarou 仕様書あっても作れないんじゃ……
  • id:tikuo333 忘却のパンドラスフィア って奴か? つか数人辞めただけで頓挫するってのはどうなんだと

以下の記事の通りなら社員数が10名足らずで,その中には社長や総務,イラストレーターなども含むとしたら,技術者なんて多くて5名かそこらじゃね.そこから2人も抜けたら,そらもうダメでしょ.

そういえばこんな話もあったっけ.

ぬまきち氏 『School days』を終えて『Summer Days』の制作に入っていたときにSchool days』のメインプログラマーで、一緒に創業したメンバーが結婚したのもあり、不規則なゲーム稼業に音を上げて会社を辞めたんです。その頃、もう一人の創業メンバーも、折悪しく先天性の病気が悪化して動けなくなったんです。そうなると、経営者としての自分の下にいてメインで動くのが、サブでやっていたプログラマーとグラフィッカーの2人だけになってしまった。この2人は双子の兄弟だったんですが、三代続く某巨大宗教団体の熱心な信者だったんです。それで、結果的に『Summer Days』が終わるくらいまで、会社が某巨大宗教団体に支配されるような状況になってしまったんです。

http://www.cyzo.com/2012/05/post_10647.html
  • id:pismo これって、開発設計仕様書の作成を指示すれば、エンジニアは作成義務を負うとも解釈できるよね。エンジニアにとってはマイナスにも転ぶ判決だろう。

それは今まででも同じことなので.契約書に明記されてて,妥当な工数が見積もりに入っていれば書く必要があるのは変わらない.そこの所で見積もりが2〜3倍,或いは2〜3桁ズレることもあるのが問題なわけだけど.「書かなかったから辞めさせないよ」や「賠償請求するよ」は,いずれにせよ無効だろう.

  • id:umakoya 「開発設計仕様書の作成はゲームの完成に必ずしも必要な書面ではなく」→業務内容として「プログラム開発と仕様書の作成」が明示されてたらアウトだったの?それでも業務上の責任は負わなくても良い?
  • id:Cujo 逆に今後、ヤバそうなとこは「最初に仕様書の策定を指示してくる」かもしれない罠。。。。。
  • id:hobbling これで指示が無きゃ仕様書作る必要なくなったな。逆に言うなら発注者はちゃんと仕様書をつくれるスケジュールをたてないといけなくなった。
  • id:megane1972 この件に関してはエンジニアが勝って当然なんだけど、仕様書や設計書は必要ないという判例ができてしまった。今後、仕様書いらないから安くしろ、という要求が来るかも?本来はきちんと書く工数を与えるべきなのに。

さてどうなることやら.

仕様書の闇については,PRESS ENTERの「冷たい方程式」がリアルで酷かった.

「じゃあ、実装前に書いてもらうんですか?」
「当然だ。内容は私がチェック、承認する。見積もりは出してもらって構わない」
「分かりました」あたしは受話器に手を伸ばしたが、渕上マネージャの話はまだ終わっていなかった。

「ただし、1本につき1人日だ」
「1人日ですか?」思わず声が高くなった。「1画面の詳細仕様書を1日で書けというのは無茶だと思いますが」
「1日で書けとはいっていない。追加の工数としてカウントしていいのが、1人日分だけ、ということだ。実際に何日かけようが、それはホライゾン社の都合だ」
「それじゃ、ホライゾンさんの損害になりませんか?
「うちの損害ではない」それがすべてだ、と言わんばかりの口調だった。
あたしは天を仰いだ。
(中略)
前の会社でも詳細仕様書は必須だったが、ここまで細かく作成したことはない。これだけの仕様書を真面目に作成していたら、それだけで軽く2〜3日は費やしてしまうだろう。
(中略)
「こういうのって下請法に抵触しませんか?」あたしは別の方向から攻略を試みた。「“買いたたき”に該当するんじゃ……」
 「再見積もりを行わずに、一方的に単価を決めれば抵触する」渕上マネージャは、あたしの浅はかな理論武装をあっさりはねのけた。「今回は、再見積もりを認めているのだから問題はない。早く伝えたまえ」

http://el.jibun.atmarkit.co.jp/pressenter/2012/02/6-efec.html

  • id:taretareta 設計仕様書通りのゲームなんて存在しない。というか、ゲームが完成してから設計仕様書は書くものだ。そんなの業界の常識。 それを承知で訴えたんだから、まあ絵に書いたようなブラック企業なんだろうな。やめて正解
  • id:mumincacao 後出しで仕様変更がぽんぽん出る割に締め切りはそのままが常習化してると『仕様書なんて描いてられっか』な状況になるよね・・・ それにしてもこんな嫌がらせしたらもう新しい人雇えなくなるような?(ーω【みかん

ほぼ同意.

たとえばパフォーマンスなんかが絡む処理の場合は,要求仕様に書いたから実現するわけではないってことさえも理解できてない人いるよね.*2

超音速で飛べる飛行機が実現可能かどうか分からない時代なら,それを可能かどうか知るには実験機を作って飛ばしてみるしかない.

タミヤ 1/72 ウォーバードコレクション No.40 ベル X-1 プラモデル 60740

タミヤ 1/72 ウォーバードコレクション No.40 ベル X-1 プラモデル 60740

マッハ3.3ならどうか.実現出来たとしてもそのコストや実用性はどうか.

仮に「マッハ5で飛べること」と戦闘機の仕様書に書いたからと言って,それを裏付ける技術なしにはマッハ5で飛べる戦闘機が実現されるわけではないのだ.*3

Firefox

Firefox


数値演算中心の業務系の単純な処理の場合では「パフォーマンスには相当な余裕がある」のが大前提で,そのことが忘れられてるのも一因かもしれない.もちろんパフォーマンス以外の部分でもこれは同様.グーグルカーがどこまで危険を事前予測できるか,悪天候でも処理できるかなんてのは,作ってみなきゃ分からない.*4研究要素が強くなればなるほどこの傾向も強くなる.

さて,そのゲームを支えるシステムで「最大20人vs20人のバトル」が実現可能かどうか,これが40人ならどうか.100人なら?

どこまで可能かは作ってみて,パフォーマンス計測してみなきゃ分からない.普通は作る前に「前回の同等システムではこのくらいの性能が出て,まだ余裕があったから20人くらは大丈夫だという目処がたった」みたいな予測があってやるものだけど,開発ノウハウ0のギルランデとその初の製品である「忘却のパンドラスフィア」の場合はそういう見積もりがあるはずがない.しかも他では使わない技術も多数採用してるというからなおさらだ.発表段階で「20人vs20人」と明記していたってことはその段階で既に完成していたか,さもなくば単なる希望的観測の宣伝文句しかなかったかのどちらかだろう.いまだに動いてないと言うことはおそらく後者だ.*5


飛行機でたとえるならMRJレベル.

...いやもっとヒドイな.飛行機製造のノウハウも全くないし技術者も揃ってないくせに,いきなり「エアバスA380クラスの巨大旅客機をリリースします」と発表しちゃったような感じ?しかも期日だけは明記して...仮にエンジン設計のベテランをボーイング社かエアバス社あたりから引き抜いてきたとしても,それだけで旅客機一つが作れるようになるわけとちゃうんやで.

クラウドで動き出す精鋭チームの夢と挑戦」

http://ascii.jp/elem/000/000/877/877076/

東京都の東部にあるギルランデ(GIRLANDE)。経営母体は建設会社だ。建設会社の代表であり、ギルランデの代表取締役社長でもある中村千喜が、建設業界のビジネスノウハウとゲームにかける熱い情熱を注ぎ込んだのがギルランデだ。

ギルランデの社員は総勢10名足らず。それでも、初のプロダクトとなるソーシャルゲーム「忘却のパンドラスフィア」(pandorasphere.jp/)をわずかな期間で完成させ、この春には提携先であるサイバーエージェントのアメーバ経由で配信する。

成功のキモはサーバーにあり

 ギルランデの立ち上げに当たり、中村氏がまず優先させたのが、強力なITインフラを構築できる人材の獲得だ。
「昨今のソーシャルゲームビジネス情勢を通じて、ソーシャルゲームにまだまだ大きな可能性があることは理解していたので、そのビジネスから会社をスタートさせることは最初から決めていました。そこで最重要課題となったのが、サーバーサイドのインフラをどう強固にするかです」と中村氏は振り返り、こう続ける。
ソーシャルゲームのキモはサーバーです。この部分が弱いと、どんなに面白くてもプレーヤーにストレスを感じさせてしまい、成功しない。ですから、優秀なインフラの技術者を必死に探しました

サーバー技術者を探すのは結構な話だ.だけど,たかがカードゲームとはいえ,20人ユーザーのリアルタイム対戦を行う大規模なネトゲで,サーバー負荷も大きくなる予定なのに,プログラマー軽視っていかがなものか.建築屋さんなだけに,平行プログラミングを嘗めすぎてやいませんか?

Java並行処理プログラミング ―その「基盤」と「最新API」を究める―

Java並行処理プログラミング ―その「基盤」と「最新API」を究める―

The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで

The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで

たかがカードバトルのゲームでここまでの技術は使わないと思うけどね.*6

それにサーバーは後から増強したり交換したりできるけど,コードの方はそうはいかない.もしスパゲッティコードになってたら,できるのはメンバー入れ替えて,最初から全部作り直すことだけだよ.そうなったら仕様書の有無なんて関係無い.

キャリアの原点はリナックスを扱うサーバーエンジニアだが、後にウィンドウズプラットホーム、クラウドへと守備範囲を拡張。現在は日本で十数名のみが保持するマイクロソフト ウィンドウズ アジュールの現役MVP(モスト バリュアブル プロフェッショナル)だ。

提供:マイクロソフト

「見る所そこかよ?」って気分.

廣瀬氏によれば、今回のゲームではプログラムだけでなく、演出、音響などのユーザーインターフェースの部分でも、他ではあまり使われることのない技術を多数採用しており、コンテンツの表現力を高めているという。さらに配信する「ソーシャルプラットホーム」に依存しない点も、「忘却のパンドラスフィア」の技術的な特徴の一つだ。

経営母体も建設会社なら,経営トップも建設畑の人間でITは素人.*7 人数は少ない.*8 この会社の初のプロダクト.おまけに他では使わない技術もてんこもり.*9さらにプログラマー軽視.

何があったかはわからんけど,たしかにいやな予感しかしない.

その際、僕が意識するのは、核となる事業アイデア以外「できる限り発明をしない」ことである。サービスそのものに新規性が高い場合、マーケティングロジスティクスなどには逆に新規アイデアや危うい仮説はまったく入れないぐらいで丁度いい。仮説や発明の組み合わせを掛け算していくと、新規事業の成功確率と投入速度はどんどん落ちる。同時にチャレンジすることが多いと、失敗した時にも理由がわかりにくい。一歩目がうまくいったら、1つずつ仮説やアイデアを足していけばいい。

http://www.dhbr.net/articles/-/1967

http://d.hatena.ne.jp/JavaBlack/20131013/p2


あとさらっと「最大20人 対20人の大人数のリアルタイムバトル」って書いちゃってるけど,まさかとは思うが排他制御まわりでバグが発生してると*10,最低でも40台のスマフォと40人のテスターがいないと発生しないバグというのも出るかもしれないってことなんだけどな.*11 下手っぴプログラマーがそういうバグを出しちゃうと,デバッグ不可能になる恐れも.

日本では、サイバーエージェントとの契約によりアメーバ上でのみコンテンツを提供する。ただし、海外は適用外なので、台湾などアジア圏でのパンドラスフィアの展開を予定しているという。
 ビジネスとクラウドに精通した2人のプロフェッショナルと、若き才能たち――それぞれの誇りと夢、そして女神を乗せて、今もアジュールは走り続けている。


そりゃあサーバーもネットワークも最初から十分なものにしておいた方がいいんだろうけど,ネトゲなんてヒットするかどうかもわからんのに,ヒットすることを前提でサーバーに投資するのは無駄になりやすいのでは.それこそlazyに処理すべき部分ではないのか.

えーと、「十年保つインフラを作って欲しい」と言われてB2Bサイト構築したらリリース半年後に「事業撤退するんで廃棄」って言われたとき。リースや回線の違約金で構築費と同じくらい支払い発生してたわ。さすがに開いた口がふさがらなかったけど、大会社相手だとたまにあるのよねぇ。

※本コメントはフィクションであり実在の案件・プロジェクトとはなんの関係もありません。ないんですってば。

http://ascii.jp/elem/000/000/759/759037/


K3の駄文

http://k3dabunlog.hatenablog.com/entry/2015/11/23/160714

まあ当たり前なんだけど、経営の責任を末端の社員に押し付けるのは非常識よ、と。

この当たり前を分かってない経営者って結構多いよね。

自分も某派遣会社に登録した際、「過失による損害を与えた場合も賠償します」という内容の「身元保証書」なる書面の提出を求められて、「出さないよ」と蹴っ飛ばしたまま働いてますけどね。借金をするわけでも家を借りるわけでもなく、ただ仕事をするのに連帯保証人を用意しなきゃいけないって控えめに言っても非常識だよねと。そもそも大の大人に対して何だこの非礼極まる要求はと。

これもブラック企業あるある.IT業界あるある.

Twitterから見る「忘却のパンドラスフィア」の歴史

2014年1月

2014年2月

2014年3月


2014年11月


2015年



*1:20人対20人だけなら「天空のクラフトフリート」とかいうゲームもあるそうな. http://www.craftfleet.com/system/
「20対20のリアルタイムって、一瞬天クラかとおもったわ。 まぁ、あれちゃんと出てるけどさw 面白いのに運営がアホだから… 」 http://alfalfalfa.com/articles/137875.html

*2:パフォーマンスの例を挙げてるのは素人目にも比較しやすいからであって,実際にはそれ以外のことが問題となることの方が(圧倒的に)多いと思う.

*3:ロシア語で考えようとUMLで記述しようと,それは変わらない.なんで記述フォーマットを変えたくらいで,開発が効率化されたりするという珍理論が出るのか謎.

*4:例えばこれとか.「Googleのロボット自動車、「立ったまま停止中」の自転車にキョドる。停止中か走行中か判断できず」 http://japanese.engadget.com/2015/08/31/google/

*5:開始(予定)日が2014年2月10日だった「天空のクラフトフリート」が同じく「20人対20人のリアルタイムバトル」らしいから,ひょっとしてこれの宣伝文句を丸パクリしたけど,実現するスキルは伴ってなかったってことかな?

*6:「仕様書を書け」「仕様書さえ書けば問題は解決する」というような人って,こういう本を読んだことないんだろうなあ.仕様書を書くことも,それを実装することも難しい世界があるというのを,彼等はまだ知らない.

*7:小規模な会社なので,経営トップがプロジェクト全体にあたえる影響は非常に大きいと予想される.

*8:外注を雇っていた可能性はあるが,そう都合良く優秀な人が来てくれる保証はないので,それに頼るのは難しい.しかも他では使ってない技術を多数使っているとなれば,なおさらである.

*9:プラットフォームがMicrosoft Azureといのも.Azureってソシャゲでの使用実績とか,どの程度あるんだろうか.

*10:たとえば「探検ドリランドのレアカード複製技」なんかは,排他制御してなかったというバグだな. http://d.hatena.ne.jp/JavaBlack/20120219/p1

*11:これに特定スマフォの組み合わせでないと発生しないとかが出たら,端末を揃えるだけで地獄である.事情はちょっと違うけど,こんなのを見つけた.