cedec2014 「ライブラリを作ってはいけない...
TRANSCRIPT
ライブラリを作ってはいけない ～それでも作りたいあなたへのアドバイス～
2014/9/4 @ CEDEC2014 株式会社バンダイナムコスタジオ
黒畑喜弘
2014/10/11 ・講演当日に口頭で説明した内容を追加してあります。(CEDiL提出用)
自己紹介• 1998年 株式会社ナムコ 入社 • 1999年 蚊取り大作戦 (ナンジャタウン) • 2000年 ディグダグ (パチスロ) • 2003年 ミスタードリラー ドリルランド (GAMECUBE) • 2003年～2004年 ドンキーコンガシリーズ (GAMECUBE) • 2005年～2006年 リッジレーサー6, 7 (Xbox360, PlayStation3) • 2006年～ 社内サウンドライブラリ ”NUSound” アーキテクト
リッジレーサー6 Love FOOTBALL リッジレーサー7 鉄拳5 DARK RESURRECTION 鉄拳5 DARK RESURRECTION ONLINE ビューティフル塊魂 エースコンバット6 鉄拳6 ソウルキャリバー レジェンズ スマッシュコート3 ファミリースキー ファミリージョッキー もじぴったん ∞プチプチ ソウルキャリバー4 テイルズオブヴェスペリア Galaga Legions スカイクロラ ファミリースキー ワールドスキー＆スノーボード もじぴったんWiiデラックス太鼓の達人 鉄拳6 BLOODLINE REBELLION NARUTO ナルティメットストーム のびのびBOY ミスタードリラーワールド 戦場の絆ポータブル マッスル行進曲 突撃！合戦スタジアム 塊魂 TRIBUTE ソウルキャリバー Broken Destiny 機動戦士ガンダム戦記 テイルズオブヴェスペリア TANK!TANK!TANK! 鉄拳6 太鼓の達人 Wii ドドーンと2代目！ テイルズオブグレイセス ガンダムビューカイブ 鉄拳6 デッドストームパイレーツ テイルズ オブ ファンタジア なりきりダンジョンX ACE COMBAT X2 ジョイントアサルト 機動戦士ガンダム エクストリームバーサス DEADHEAT マクロストライアルフロンティア BIG3 GUN SHOOTING(デッドストームパイレーツ) NARUTO ナルティメットストーム2 体で答える新しい脳トレ テイルズオブグレイセスエフ 太鼓の達人Wii みんなでパーティ☆３代目！ エコドライブ パックマン MAXIMUM HEAT ドラゴンボール ZENKAIバトルロイヤル ギャラガレギオンズ DX 太鼓の達人ぽ～たぶる DX テイルズオブエクシリア劇場版マクロスF サヨナラノツバサ Hybrid Pack GO VACATION 太鼓の達人 太鼓の達人Wii 決定版 機動戦士ガンダム エクストリームバーサス 湾岸ミッドナイト MAXIMUM TUNE 4 NARUTO疾風伝 ナルティメットストーム GENERATION .hack//VERSUS テイルズオブエクシリア2 デッドストームパイレーツ(立体視版) PAC-MAN Championship Edition のびのびBOY コトバシる アイドルマスター2 戦場の絆 Rev.3 鉄拳タッグトーナメント2 アイドルマスター2 アイドルマスター グラビアフォーユー! VOL.2 鉄拳 HYBRID リッジレーサー 塊魂 ノ・ビ～タ アイドルマスター グラビアフォーユー! VOL.3 アイドルマスターモバイルi 鉄拳タッグトーナメント2 鉄拳タッグトーナメント2 WiiU Edition 鉄拳レボリューション マリオカート アーケードグランプリDX 大乱闘スマッシュブラザーズ for NINTENDO 3DS, WiiU
8年間で約100タイトル
正直辛かった。
社内ライブラリを作ると 何が辛いか？
おことわり !
以後の内容は特定のプロジェクトや誰かを指しているのではなく、ライブラリ開発およびサポートにおいて比較的よくある話であり、
他意はないことをご理解いただければ幸いです。
採用タイトルのスケジュールが不明
• タイトル側の情報はほとんど入ってこないため、マスター提出がいつになるかも分からない。
• 最初にライブラリを渡したときに聞いたスケジュールは、ずれにずれまくってあてにならない。
• 人によって、提示されているスケジュールが違う。
「明日マスター提出なんですが…」 というバグ報告が突然来る
• 心の準備をする余裕くらいは欲しい。
「我々とライブラリチームに温度差がある！！」 と偉い人に怒られる
• 緊急なのは分かるが、スケジュールも今聞かされたばかりでは、さすがにすぐに温度は上がらない。
マスター提出直前になってから 「この症状1ヶ月前から出てました」という報告が来る
• かなり多い。
• 原因がタイトル側かライブラリ側かを追求しておらず、ギリギリになって判明した思われる。
• 1ヶ月前ならもっと余裕を持って対応できたのに…。
知らないプロジェクトが いつの間にか使っている
• 社内のサーバにファイルを置いておくと勝手に持って行かれる。
• マスター提出ぎりぎりになってから泣き付かれるという合わせ技。
マスター提出日が毎月やってくる
• 8年100タイトルだとひと月に1タイトルは必ず来る計算。
• 年末や年度末はそれどころではない。
旅行先に電話がかかってくる
• 旅行の予定は結構前に立てるものなので、なかなか繁忙期を予測しづらい。
• 下呂温泉やニューヨークでバグ報告を受けたり、徹夜でバグ修正したあとに成田空港へ向かった経験あり。
人員は減らされはしないものの どれだけ忙しくても現状維持
!
• ライブラリチームとして独立した組織になると、人件費が分かりやすく目に見えてしまう。
• だが、ライブラリの採用によるコスト削減効果は数字には現れない(余裕ができた分、仕様を詰め込まれてしまう)。
• 「人を増やしたい理由を述べよ」と言われても、いつどれだけ来るか分からないサポート案件にどれだけ時間を割くべきかが計算できない。
その分野に詳しい人ほど変な使い方をして不具合が出る
• ライブラリを無理矢理ラップして自分の好きな作り方に合わせようとして、想定外の使い方をされる。
• メリットをことごとく潰すような使い方をされることも。
• キャリアの長い人に多い。
安定したと思っていたのに 他のタイトルに貸与するとバグが出まくる
• プロジェクトによるプログラミングスタイルの違いは思った以上に大きい。会社が違うとそれどころではない。
• 何年も経ったのに基本的なところにバグが発見されたりする。
• 当初はタイトル側の勘違いだと思っていたものが実際にバグで、平謝りということも。
タイトル側のバグなのに ライブラリ側のバグだということにされる
• 実際にどちらにバグがあったかは、担当者のみぞ知る…。
スケジュールの遅延の言い訳として ライブラリのバグが偉い人会議で広められる
• いろいろな要因があるはずなのに、目立ちがちなライブラリのせいにされる。
• 風評被害もいいところ。
• 「あのライブラリ、バグだらけらしいよ」という噂が出回る。
シリーズものに使われたら最後 5年10年サポート
• 何年も前のライブラリをサポートするのは厳しい。開発環境を維持したり、最新のSDKやガイドラインに合わせたり。
• なかなか最新版を使ってもらえず、最初に渡したバージョンに手作業でパッチをあて続けることに。
• 最新版なら簡単にできるはずの機能が使えなくて、はがゆい。
金曜の夜にバグ報告を出し逃げされる
• すっきりして土日を迎えたいのはみんな同じ。
最新のライブラリやデータを渡したのに 反映されていない
• 修正箇所をメールで知らせたことによるコピペミス。
• プロジェクトのフォルダ構成がややこしくて、ライブラリファイルを違うところに置いてしまっている。
• 担当者が今日は不在だった(情報が入ってきていない！！)。
ソースで渡すと「高速化！！」 とか言って魔改造される＝不具合発生
• 当然ライブラリの全容を理解しているわけではないので、不具合の温床になりやすい。
• 改造による不具合の場合、ライブラリチームの環境では発生しないため、原因の追及が余計に難しくなる。
• 自分のバグより他人のバグを直すのが好きな人もいる。
タイトル側担当者が 「このクソライブラリが！！」とかツイートしてる
• 無視しましょう。
打ち上げに呼んでもらえない
• …とはいえ、ライブラリチームは担当者としか面識がないので、実は呼ばれてもちょっと困る。
• その担当者とも、丁々発止やりあった後だったりすると…。
なかなか完成しない
• 1～2年くらいで完成させて手放そうと思っていたのが、もう8年。
• ゲーム機の世代が変わるのはまだしも、概念すら変わりかけている。
婚期を逃す
• 残念です。
なぜライブラリ開発は辛いのか？• 開発業務の合間に軽く済ませられたサポート業務が、機能追加や対応機種の拡大によって無視できないレベルになる。
• それらをコストもしくは人員の増強としてなかなか計上できない。
↓
「ブラック」化
「ライブラリを作ってはいけない」 ということが分かりましたね？
それでも作りたい？ …しょうがないなぁ。
辛くならないための方法
APIの数を極力減らして 変な使い方をされないようにする
• 想定外の使われ方は、潜在的なバグを呼び起こす。
• 多機能ではなく高機能を目指して、APIの抽象度は高めにする。
• 「アンチパターン」が参考になる。
ドキュメントとサンプルプログラムを 充実させる
• 多くのプログラマーは、サンプルプログラムをコピペして使っている(断言)。
• サンプルが正しい使い方をしていれば、変な使い方はされない。
• 問い合わせに丁寧に答えつつ、「マニュアルの○ページにも書いてあります」と返せると、強い。
SDKのサンプルプログラムを コピペして作る
• SDKも「ライブラリ」なので、どう使えば問題が起こりにくいかは全く同じ。
• SDK開発者が使って欲しいと思っている方法で使ってあげよう！！
Windows版も作る• 全員が開発機を持っている訳ではないが、Windowsはみんな持っているので、みんなでデバッグできる！！
• Windowsはメモリ保護もあるしランタイムでのチェックも可能。
• VisualStudioのエディタやデバッガがとにかく優秀。
• 64bit版の実験台にもなる。
全機種でデータを共通化
• ライブラリのWindows版を作ったとしても、データが違うと意味がない。
• 共通部分はリトルエンディアンに統一。現世代はこれが主流であるし、変換コストより運用上のメリットの方がはるかに大きい。
• 機種依存部分はチャンク形式によるブロック化で切り離したり。
エラー処理をきっちりとやりすぎず あっさり落とす
• NULLアクセスなどで落ちるはずのところを無理矢理回避してそのまま進行すると、想定外の部分で落ちて原因が分かりづらい。
• 使う側がエラーチェックしていないことも多いので、エラーのタイミングを掴めない。
• デバッガに落ちる瞬間を拾ってもらった方が分かりやすい。
頻度の低いバグを見逃さない
• こういったバグはマスター提出直前に「必ず」再発する。
• プログラムに「たまたま」はない！！
• 頻度が低くても、バグ報告をよく読んで状況を絞れば、再現しやすい環境を作ることはそれほど難しくない。
ソースでは渡さず ライブラリファイルで渡す
• 魔改造はさせないぞという意思表明。
• プロジェクトによってビルド設定が違っていたりして合わせるのが面倒なので、それを回避するためでもある。
• マスター直前の場合、ライブラリの改造ではなく、使い方の変更でバグを回避する手法を提示する。
ライブラリファイルとデータに バージョン番号を埋め込んでおく
!
• 更新ミスを判定するために、ライブラリファイルにSubversionなどのリビジョン番号を埋め込み、それを取得するAPIも用意する。
• ヘッダファイルの定義を書き換えるだけではダメ。ヘッダファイルは更新したがライブラリファイルが更新されていないということもよくある。
• データに日付を”文字列”で埋め込んでおくのも手。タイムスタンプはあてにならず、これならゲームを実行しなくてもバイナリエディタで確認できる。
ブランチを切らない
• ブランチが増えたら増えた分だけ、サポートの手間が増える。
• どうせマージは失敗するよ。
• 全部trunkで行こう！！
プログラミング以外の作業は 徹底的に自動化
!
• ビルドはJenkins。古いバージョンのSDKでのビルドとか、ブランチへのパッチを当てたバージョンのビルドとか、自動化しづらい部分であっても手作業は最低限で済むような仕組みを作る。
• Windowsのバッチファイルで書いておくと、関連ツールのインストールが必要ないので、自分以外の誰かに作業を任せるのが楽。
• ドキュメントはDoxygen。コード内に記述できるので面倒がないし、ライブラリとドキュメントのバージョンがずれたりすることもない。
サポート窓口をRedmineなどの 案件管理システムにしない
• Redmineなどの高級なシステムは、必要以上にボタンやパラメータが多く、敷居が高い。使い方が分からず、口頭で来る人も多い。
• もちろん案件管理システムとしては優れているが、窓口には適さない。
とりあえず何でもメールで受け付ける
• ライブラリチーム全員に配信されるメーリングリストを開設して、とにかく何かあったらメールを投げてもらうようにする。
• 「バグ」や「要望」だけでなく、「相談」も見逃さない。
• 案件管理システムにはライブラリチームやサポート専門要員が入力し、サイトのアドレスを返信して、以後はそちらでやりとり。
「開発者による直接サポート」 を売りにしない
• 小規模なライブラリチームが「売り」として言いがち。
• 案件が同時に複数入ると簡単に破綻する。
• 案件への対応が遅れてクレームが来るだけでなく、肝心のライブラリ開発の進行も止まる。
サポート依頼に対する返答期限を 「最長で1週間」と表明しておく
!
• 一見遅いように感じるが、案外なんとかなる。相手もそれに合わせて1週間余裕を持って問い合わせてくれる。
• もちろん余裕があればその日のうちに返答。あくまで最悪の状況のときの時間稼ぎ。
• マスター提出直前ではそういうわけにはいかないが、その対応が特別なケースであることは理解してもらえるはず。
ご用聞きに行く
• 「便りがないのは元気な証拠」…であった試しがない。
• 最初は「大丈夫だ、問題ない」と言っていても、突っ込んで行くと怪しい情報が出てくる。
• トラブルの芽は早めに摘む。
かつての同僚や同期から 情報を横流ししてもらう
• バグトラックシステムから関係ありそうな情報をピックアップしてもらう(ライブラリチームには閲覧権限がないことがほとんど)。
• 本当のスケジュールを聞き出す。
• 人脈は有効。
仁義は通す
• 横流ししてもらった情報をもとに動くとしても、必ずタイトル側の担当者を通す。
• タイトル側の担当者は数少ない味方。
何でもかんでも プログラムで解決しようとしない
!
• 実装が難しいなら仕様を削ってもらう、重いならデータを減らしてもらう、不安定ならその機能を使わないようにしてもらう。
• コードをこつこつ削るより、テクスチャ1枚リサイズしたほうが速いこともある。
• 周りもプロのゲーム開発者。何らかの制限がある中でも、ベストな仕事をしてくれるはず。
これにて、めでたしめでたし
…とは行かないようです。
ツイートツイート 992
ホーム > プレスリリース > ソニー・コンピュータエンタテインメントとユニティ・テクノロジーズ 「プレイステーション」向け「Unity」を すべてのソフトウェアタイトル開発者の皆様に無償提供
ENGLISH
2014年9月17日株式会社ソニー・コンピュータエンタテインメント
ユニティ・テクノロジーズ
ソニー・コンピュータエンタテインメントとユニティ・テクノロジーズ「プレイステーション」向け「Unity」を すべてのソフトウェアタイトル開発者の皆様に無償提供
株式会社ソニー・コンピュータエンタテインメント（SCE）と、革新的な開発プラットフォーム「Unity」を提供するユニティ・テクノロジーズ（本社：米国カリフォルニア州）は、２０１３年３月に合意した戦略的提携にもとづき、「プレイステーション」向け「Unity」の「Unity Pro for PlayStation®」を提供していますが、この度さらなるパートナーシップの強化を図り、「プレイステーション 4」、「プレイステーション 3」および「プレイステーション ヴィータ」向け「Unity Pro forPlayStation®」をすべてのソフトウェアタイトル開発者の皆様に無償で提供いたします。
今回のパートナーシップ強化によって、SCEはインディーズ（独立系）開発者の皆様の活動をより強力にサポートしていくとともに、経験豊かな開発者の皆様のニーズにお応えするため、より多くの機能提供やより高いパフォーマンスの実現に向けてユニティ・テクノロジーズとの協力を深めてまいります。また「Unity for PlayStation®」の無償提供を通じ、SCEは今後も、ユーザーの皆様に「プレイステーション」ならではの豊かなゲーム体験をお楽しみいただける数々のソフトウェアタイトルを開発者の皆様とともに提供してまいります。
「すべての開発者の皆様に『プレイステーション』向け『Unity』を無償提供できることを大変嬉しく思います。とりわけインディーズ（独立系）開発者の皆様の熱意によって、独創的でクオリティの高い『プレイステーション』プラットフォーム専用ソフトウェアタイトルが次々に制作されています。すべての開発者の皆様が『プレイステーション』プラットフォーム上で新しい体験を創造していただけるよう今後もサポートしてまいります。」（SCE 研究開発本部 シニア・バイス・プレジデント 兼 副本部長 豊 禎治）
「これまで『Unity』を利用し制作された数々の素晴らしい『プレイステーション』プラットフォーム専用ソフトウェアタイトルが発売され、現在もより多くのタイトルが制作されています。『プレイステーション』向け『Unity』の無償提供は、これらのソフトウェアタイトル制作をより簡明にするとともに、『Unity』を利用する開発者の皆様が『プレイステーション』の開発コミュニティに参加いただくための最適な機会をお約束する重要な一歩です。」（ユニティ・テクノロジーズ CEO デイビッド・ヘルガソン）
「プレイステーション」向け「Unity」の提供を通じこれまで、Assault Android Cactus, BroForce, CounterSpy,DEEMO～ラスト・リサイタル～, ガラクZ, Night in the Woods, Oddworld: New‘N’ Tasty, Shiftlings, Starwhal: Just theTip, The Golf Club, TorqueLなど幅広いジャンルから数多くの「プレイステーション」プラットフォーム専用ソフトウェアタイトルが発売、制作されました。また、ソフトウェアタイトル制作において「プレイステーション」向け「Unity」が実現する適応性と柔軟性を通じ、開発者の皆様にとって理想的なゲームスタイルとデザインを幅広く実現しています。制作中のタイトルなどの詳細は、次のウェブサイトをご参照ください。http://unity3d.com/showcase/gallery/games?platform=572&genre=&gametype=t-all
以上
1,029シェアシェア
社内ライブラリが この先生きのこるには？
市販ライブラリ 社内ライブラリ
機能 汎用的 独自機能あり
コスト 価格競争が激しい 社内人件費高すぎ
サポート サポート専任スタッフ がいる
開発者が空き時間に サポート
力関係 何でも言うこと 聞いてくれる 文句も言う
勝負にならない！！
生き残るためには…
• 特定のプロジェクト専用に進化させる。
• ライブラリを応用した独自のアプリを提供する。
• ゲーム業界以外に進出する。
• …他にも何かあればメール等で私までご連絡ください！！
まとめ
辛くならないためにやるべきこと• バグを減らす。
• デバッグしやすくする。
• 情報を入手する。
• 時間に余裕を持つ。
• 何でもかんでもプログラムで解決しようとしない。
チームの労働環境が 悪くならないようにしましょう
• 最初の頃は焦る。採用タイトルは少ないし、不具合もたくさん出るし、サポートのせいで開発は滞る。
• だからって、「ブラック」になっちゃダメ。
「今、無理しないでいつ無理するの？」 ↓
10年にわたって無理し続けることになります。
でもやっぱり ライブラリ開発は楽しい
周辺環境を整備して 持続可能なライブラリ開発を 続けて行きましょう！！
ありがとうございました