CEDEC2014 「ライブラリを作ってはいけない～それでも作りたいあなたへのアドバイス～」

ライブラリを作ってはいけない
∼それでも作りたいあなたへのアドバイス∼
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

社内ライブラリを作ると
何が辛いか？

おことわり
!
以後の内容は特定のプロジェクトや誰かを指しているのではなく、 
ライブラリ開発およびサポートにおいて比較的よくある話であり、
他意はないことをご理解いただければ幸いです。

採用タイトルのスケジュールが不明
• タイトル側の情報はほとんど入ってこないため、マスター提出がい
つになるかも分からない。
• 最初にライブラリを渡したときに聞いたスケジュールは、ずれにず
れまくってあてにならない。
• 人によって、提示されているスケジュールが違う。

「明日マスター提出なんですが…」
というバグ報告が突然来る
• 心の準備をする余裕くらいは欲しい。

「我々とライブラリチームに温度差がある！！」
と偉い人に怒られる
• 緊急なのは分かるが、スケジュールも今聞かされたばかりでは、さ
すがにすぐに温度は上がらない。

マスター提出直前になってから
「この症状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 for
PlayStation®」をすべてのソフトウェアタイトル開発者の皆様に無償で提供いたします。
1,029シェアシェア

社内ライブラリが
この先生きのこるには？

市販ライブラリ社内ライブラリ
機能汎用的独自機能あり
コスト価格競争が激しい社内人件費高すぎ
サポート
サポート専任スタッフ
がいる
開発者が空き時間に
サポート
力関係
何でも言うこと
聞いてくれる
文句も言う

生き残るためには…
• 特定のプロジェクト専用に進化させる。
• ライブラリを応用した独自のアプリを提供する。
• ゲーム業界以外に進出する。
• …他にも何かあればメール等で私までご連絡ください！！

辛くならないためにやるべきこと
• バグを減らす。
• デバッグしやすくする。
• 情報を入手する。
• 時間に余裕を持つ。
• 何でもかんでもプログラムで解決しようとしない。

チームの労働環境が
悪くならないようにしましょう
• 最初の頃は焦る。採用タイトルは少ないし、不具合もたくさん出る
し、サポートのせいで開発は滞る。
• だからって、「ブラック」になっちゃダメ。

「今、無理しないでいつ無理するの？」
↓
10年にわたって無理し続けることになります。

でもやっぱり
ライブラリ開発は楽しい

周辺環境を整備して
持続可能なライブラリ開発を
続けて行きましょう！！
ありがとうございました

CEDEC2014 「ライブラリを作ってはいけない～それでも作りたいあなたへのアドバイス～」

Recommended

More Related Content

What's hot (20)