Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ライブラリを作ってはいけない
∼それでも作りたいあなたへのアドバイス∼
2014/9/4 @ CEDEC2014
株式会社バンダイナムコスタジオ
黒畑喜弘
2014/10/11 ・講演当日に口頭で説明した内容を追加してあります。(CEDiL提出...
自己紹介
• 1998年 株式会社ナムコ 入社
• 1999年 蚊取り大作戦 (ナンジャタウン)
• 2000年 ディグダグ (パチスロ)
• 2003年 ミスタードリラー ドリルランド (GAMECUBE)
• 2003年∼2004年 ドンキ...
リッジレーサー6 Love FOOTBALL リッジレーサー7 鉄拳5 DARK RESURRECTION 鉄拳5 DARK RESURRECTION
ONLINE ビューティフル塊魂 エースコンバット6 鉄拳6 ソウルキャリバー レジェンズ ...
8年間で約100タイトル
正直辛かった。
社内ライブラリを作ると
何が辛いか?
おことわり
!
以後の内容は特定のプロジェクトや誰かを指しているのではなく、

ライブラリ開発およびサポートにおいて比較的よくある話であり、
他意はないことをご理解いただければ幸いです。
採用タイトルのスケジュールが不明
• タイトル側の情報はほとんど入ってこないため、マスター提出がい
つになるかも分からない。
• 最初にライブラリを渡したときに聞いたスケジュールは、ずれにず
れまくってあてにならない。
• 人によって、提示され...
「明日マスター提出なんですが…」
というバグ報告が突然来る
• 心の準備をする余裕くらいは欲しい。
「我々とライブラリチームに温度差がある!!」
と偉い人に怒られる
• 緊急なのは分かるが、スケジュールも今聞かされたばかりでは、さ
すがにすぐに温度は上がらない。
マスター提出直前になってから
「この症状1ヶ月前から出てました」という報告が来る
• かなり多い。
• 原因がタイトル側かライブラリ側かを追求しておらず、ギリギリに
なって判明した思われる。
• 1ヶ月前ならもっと余裕を持って対応できたのに…。
知らないプロジェクトが
いつの間にか使っている
• 社内のサーバにファイルを置いておくと勝手に持って行かれる。
• マスター提出ぎりぎりになってから泣き付かれるという合わせ技。
マスター提出日が毎月やってくる
• 8年100タイトルだとひと月に1タイトルは必ず来る計算。
• 年末や年度末はそれどころではない。
旅行先に電話がかかってくる
• 旅行の予定は結構前に立てるものなので、なかなか繁忙期を予測し
づらい。
• 下呂温泉やニューヨークでバグ報告を受けたり、徹夜でバグ修正し
たあとに成田空港へ向かった経験あり。
人員は減らされはしないものの
どれだけ忙しくても現状維持
!
• ライブラリチームとして独立した組織になると、人件費が分かりやすく
目に見えてしまう。
• だが、ライブラリの採用によるコスト削減効果は数字には現れない(余
裕ができた分、仕様を詰...
その分野に詳しい人ほど

変な使い方をして不具合が出る
• ライブラリを無理矢理ラップして自分の好きな作り方に合わせよう
として、想定外の使い方をされる。
• メリットをことごとく潰すような使い方をされることも。
• キャリアの長い人に多い。
安定したと思っていたのに

他のタイトルに貸与するとバグが出まくる
• プロジェクトによるプログラミングスタイルの違いは思った以上に
大きい。会社が違うとそれどころではない。
• 何年も経ったのに基本的なところにバグが発見されたりする。
• 当...
タイトル側のバグなのに
ライブラリ側のバグだということにされる
• 実際にどちらにバグがあったかは、担当者のみぞ知る…。
スケジュールの遅延の言い訳として
ライブラリのバグが偉い人会議で広められる
• いろいろな要因があるはずなのに、目立ちがちなライブラリのせい
にされる。
• 風評被害もいいところ。
• 「あのライブラリ、バグだらけらしいよ」という が出回る。
シリーズものに使われたら最後
5年10年サポート
• 何年も前のライブラリをサポートするのは厳しい。開発環境を維持
したり、最新のSDKやガイドラインに合わせたり。
• なかなか最新版を使ってもらえず、最初に渡したバージョンに手作
業でパッチを...
金曜の夜にバグ報告を出し逃げされる
• すっきりして土日を迎えたいのはみんな同じ。
最新のライブラリやデータを渡したのに
反映されていない
• 修正箇所をメールで知らせたことによるコピペミス。
• プロジェクトのフォルダ構成がややこしくて、ライブラリファイル
を違うところに置いてしまっている。
• 担当者が今日は不在だった(情...
ソースで渡すと「高速化!!」
とか言って魔改造される=不具合発生
• 当然ライブラリの全容を理解しているわけではないので、不具合の
温床になりやすい。
• 改造による不具合の場合、ライブラリチームの環境では発生しない
ため、原因の追及が余計に難...
タイトル側担当者が
「このクソライブラリが!!」とかツイートしてる
• 無視しましょう。
打ち上げに呼んでもらえない
• …とはいえ、ライブラリチームは担当者としか面識がないので、実
は呼ばれてもちょっと困る。
• その担当者とも、丁々発止やりあった後だったりすると…。
なかなか完成しない
• 1∼2年くらいで完成させて手放そうと思っていたのが、もう8年。
• ゲーム機の世代が変わるのはまだしも、概念すら変わりかけている。
婚期を逃す
• 残念です。
なぜライブラリ開発は辛いのか?
• 開発業務の合間に軽く済ませられたサポート業務が、機能追加や対
応機種の拡大によって無視できないレベルになる。
• それらをコストもしくは人員の増強としてなかなか計上できない。
↓
「ブラック」化
「ライブラリを作ってはいけない」
ということが分かりましたね?
それでも作りたい?
…しょうがないなぁ。
辛くならないための方法
APIの数を極力減らして
変な使い方をされないようにする
• 想定外の使われ方は、潜在的なバグを呼び起こす。
• 多機能ではなく高機能を目指して、APIの抽象度は高めにする。
• 「アンチパターン」が参考になる。
ドキュメントとサンプルプログラムを
充実させる
• 多くのプログラマーは、サンプルプログラムをコピペして使ってい
る(断言)。
• サンプルが正しい使い方をしていれば、変な使い方はされない。
• 問い合わせに丁寧に答えつつ、「マニュアルの○ペー...
SDKのサンプルプログラムを
コピペして作る
• SDKも「ライブラリ」なので、どう使えば問題が起こりにくいかは
全く同じ。
• SDK開発者が使って欲しいと思っている方法で使ってあげよう!!
Windows版も作る
• 全員が開発機を持っている訳ではないが、Windowsはみんな持って
いるので、みんなでデバッグできる!!
• Windowsはメモリ保護もあるしランタイムでのチェックも可能。
• VisualStudioのエディタや...
全機種でデータを共通化
• ライブラリのWindows版を作ったとしても、データが違うと意味が
ない。
• 共通部分はリトルエンディアンに統一。現世代はこれが主流である
し、変換コストより運用上のメリットの方がはるかに大きい。
• 機種依存部分...
エラー処理をきっちりとやりすぎず
あっさり落とす
• NULLアクセスなどで落ちるはずのところを無理矢理回避してその
まま進行すると、想定外の部分で落ちて原因が分かりづらい。
• 使う側がエラーチェックしていないことも多いので、エラーのタイ
ミ...
頻度の低いバグを見逃さない
• こういったバグはマスター提出直前に「必ず」再発する。
• プログラムに「たまたま」はない!!
• 頻度が低くても、バグ報告をよく読んで状況を絞れば、再現しやす
い環境を作ることはそれほど難しくない。
ソースでは渡さず
ライブラリファイルで渡す
• 魔改造はさせないぞという意思表明。
• プロジェクトによってビルド設定が違っていたりして合わせるのが
面倒なので、それを回避するためでもある。
• マスター直前の場合、ライブラリの改造ではなく、使...
ライブラリファイルとデータに
バージョン番号を埋め込んでおく
!
• 更新ミスを判定するために、ライブラリファイルにSubversionなどのリビ
ジョン番号を埋め込み、それを取得するAPIも用意する。
• ヘッダファイルの定義を書き換えるだけ...
ブランチを切らない
• ブランチが増えたら増えた分だけ、サポートの手間が増える。
• どうせマージは失敗するよ。
• 全部trunkで行こう!!
プログラミング以外の作業は
徹底的に自動化
!
• ビルドはJenkins。古いバージョンのSDKでのビルドとか、ブランチへのパッ
チを当てたバージョンのビルドとか、自動化しづらい部分であっても手作業
は最低限で済むような仕組みを作る。
• W...
サポート窓口をRedmineなどの
案件管理システムにしない
• Redmineなどの高級なシステムは、必要以上にボタンやパラメータ
が多く、敷居が高い。使い方が分からず、口頭で来る人も多い。
• もちろん案件管理システムとしては優れているが、...
とりあえず何でもメールで受け付ける
• ライブラリチーム全員に配信されるメーリングリストを開設して、
とにかく何かあったらメールを投げてもらうようにする。
• 「バグ」や「要望」だけでなく、「相談」も見逃さない。
• 案件管理システムにはライブ...
「開発者による直接サポート」
を売りにしない
• 小規模なライブラリチームが「売り」として言いがち。
• 案件が同時に複数入ると簡単に破綻する。
• 案件への対応が遅れてクレームが来るだけでなく、肝心のライブラ
リ開発の進行も止まる。
サポート依頼に対する返答期限を
「最長で1週間」と表明しておく
!
• 一見遅いように感じるが、案外なんとかなる。相手もそれに合わせて
1週間余裕を持って問い合わせてくれる。
• もちろん余裕があればその日のうちに返答。あくまで最悪の状況のと
...
ご用聞きに行く
• 「便りがないのは元気な証拠」…であった試しがない。
• 最初は「大丈夫だ、問題ない」と言っていても、突っ込んで行くと
怪しい情報が出てくる。
• トラブルの芽は早めに摘む。
かつての同僚や同期から
情報を横流ししてもらう
• バグトラックシステムから関係ありそうな情報をピックアップして
もらう(ライブラリチームには閲覧権限がないことがほとんど)。
• 本当のスケジュールを聞き出す。
• 人脈は有効。
仁義は通す
• 横流ししてもらった情報をもとに動くとしても、必ずタイトル側の
担当者を通す。
• タイトル側の担当者は数少ない味方。
何でもかんでも
プログラムで解決しようとしない
!
• 実装が難しいなら仕様を削ってもらう、重いならデータを減らしても
らう、不安定ならその機能を使わないようにしてもらう。
• コードをこつこつ削るより、テクスチャ1枚リサイズしたほうが速い
こ...
これにて、めでたしめでたし
…とは行かないようです。
ツイートツイート 992
ホーム > プレスリリース > ソニー・コンピュータエンタテインメントとユニティ・テクノロジーズ 「プレイステーション」向け「Unity」を すべてのソ
フトウェアタイトル開発者の皆様に無償提供
ENGLISH
201...
社内ライブラリが
この先生きのこるには?
市販ライブラリ 社内ライブラリ
機能 汎用的 独自機能あり
コスト 価格競争が激しい 社内人件費高すぎ
サポート
サポート専任スタッフ
がいる
開発者が空き時間に
サポート
力関係
何でも言うこと
聞いてくれる
文句も言う
勝負にならない!!
生き残るためには…
• 特定のプロジェクト専用に進化させる。
• ライブラリを応用した独自のアプリを提供する。
• ゲーム業界以外に進出する。
• …他にも何かあればメール等で私までご連絡ください!!
まとめ
辛くならないためにやるべきこと
• バグを減らす。
• デバッグしやすくする。
• 情報を入手する。
• 時間に余裕を持つ。
• 何でもかんでもプログラムで解決しようとしない。
チームの労働環境が
悪くならないようにしましょう
• 最初の頃は焦る。採用タイトルは少ないし、不具合もたくさん出る
し、サポートのせいで開発は滞る。
• だからって、「ブラック」になっちゃダメ。
「今、無理しないでいつ無理するの?」
↓
10年にわたって無理し続けることになります。
でもやっぱり
ライブラリ開発は楽しい
周辺環境を整備して
持続可能なライブラリ開発を
続けて行きましょう!!
ありがとうございました
CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」
CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」
Upcoming SlideShare
Loading in …5
×

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

36,450 views

Published on

社内ライブラリを8年間に渡って作り、サポートし続けてきた講演者が、1~2年で完成するだろうという当初の想定とは裏腹に、なかなか進まない作業、得られないサポート、バグの押し付け合い、それら数々の修羅場から得られた、技術面およびサポート面でのノウハウをお伝えします。
http://cedec.cesa.or.jp/2014/session/ENG/8073.html
※2014/9/4にCEDEC2014@パシフィコ横浜で行った講演です。

Published in: Engineering
  • 汎用ライブラリとプロジェクトごとの専用ライブラリの切り分けが大切ですね。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

  1. 1. ライブラリを作ってはいけない ∼それでも作りたいあなたへのアドバイス∼ 2014/9/4 @ CEDEC2014 株式会社バンダイナムコスタジオ 黒畑喜弘 2014/10/11 ・講演当日に口頭で説明した内容を追加してあります。(CEDiL提出用)
  2. 2. 自己紹介 • 1998年 株式会社ナムコ 入社 • 1999年 蚊取り大作戦 (ナンジャタウン) • 2000年 ディグダグ (パチスロ) • 2003年 ミスタードリラー ドリルランド (GAMECUBE) • 2003年∼2004年 ドンキーコンガシリーズ (GAMECUBE) • 2005年∼2006年 リッジレーサー6, 7 (Xbox360, PlayStation3) • 2006年∼ 社内サウンドライブラリ NUSound アーキテクト
  3. 3. リッジレーサー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 みんなでパー ティ☆3代目! エコドライブ パックマン 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
  4. 4. 8年間で約100タイトル
  5. 5. 正直辛かった。
  6. 6. 社内ライブラリを作ると 何が辛いか?
  7. 7. おことわり ! 以後の内容は特定のプロジェクトや誰かを指しているのではなく、
 ライブラリ開発およびサポートにおいて比較的よくある話であり、 他意はないことをご理解いただければ幸いです。
  8. 8. 採用タイトルのスケジュールが不明 • タイトル側の情報はほとんど入ってこないため、マスター提出がい つになるかも分からない。 • 最初にライブラリを渡したときに聞いたスケジュールは、ずれにず れまくってあてにならない。 • 人によって、提示されているスケジュールが違う。
  9. 9. 「明日マスター提出なんですが…」 というバグ報告が突然来る • 心の準備をする余裕くらいは欲しい。
  10. 10. 「我々とライブラリチームに温度差がある!!」 と偉い人に怒られる • 緊急なのは分かるが、スケジュールも今聞かされたばかりでは、さ すがにすぐに温度は上がらない。
  11. 11. マスター提出直前になってから 「この症状1ヶ月前から出てました」という報告が来る • かなり多い。 • 原因がタイトル側かライブラリ側かを追求しておらず、ギリギリに なって判明した思われる。 • 1ヶ月前ならもっと余裕を持って対応できたのに…。
  12. 12. 知らないプロジェクトが いつの間にか使っている • 社内のサーバにファイルを置いておくと勝手に持って行かれる。 • マスター提出ぎりぎりになってから泣き付かれるという合わせ技。
  13. 13. マスター提出日が毎月やってくる • 8年100タイトルだとひと月に1タイトルは必ず来る計算。 • 年末や年度末はそれどころではない。
  14. 14. 旅行先に電話がかかってくる • 旅行の予定は結構前に立てるものなので、なかなか繁忙期を予測し づらい。 • 下呂温泉やニューヨークでバグ報告を受けたり、徹夜でバグ修正し たあとに成田空港へ向かった経験あり。
  15. 15. 人員は減らされはしないものの どれだけ忙しくても現状維持 ! • ライブラリチームとして独立した組織になると、人件費が分かりやすく 目に見えてしまう。 • だが、ライブラリの採用によるコスト削減効果は数字には現れない(余 裕ができた分、仕様を詰め込まれてしまう)。 • 「人を増やしたい理由を述べよ」と言われても、いつどれだけ来るか分 からないサポート案件にどれだけ時間を割くべきかが計算できない。
  16. 16. その分野に詳しい人ほど
 変な使い方をして不具合が出る • ライブラリを無理矢理ラップして自分の好きな作り方に合わせよう として、想定外の使い方をされる。 • メリットをことごとく潰すような使い方をされることも。 • キャリアの長い人に多い。
  17. 17. 安定したと思っていたのに
 他のタイトルに貸与するとバグが出まくる • プロジェクトによるプログラミングスタイルの違いは思った以上に 大きい。会社が違うとそれどころではない。 • 何年も経ったのに基本的なところにバグが発見されたりする。 • 当初はタイトル側の勘違いだと思っていたものが実際にバグで、平 謝りということも。
  18. 18. タイトル側のバグなのに ライブラリ側のバグだということにされる • 実際にどちらにバグがあったかは、担当者のみぞ知る…。
  19. 19. スケジュールの遅延の言い訳として ライブラリのバグが偉い人会議で広められる • いろいろな要因があるはずなのに、目立ちがちなライブラリのせい にされる。 • 風評被害もいいところ。 • 「あのライブラリ、バグだらけらしいよ」という が出回る。
  20. 20. シリーズものに使われたら最後 5年10年サポート • 何年も前のライブラリをサポートするのは厳しい。開発環境を維持 したり、最新のSDKやガイドラインに合わせたり。 • なかなか最新版を使ってもらえず、最初に渡したバージョンに手作 業でパッチをあて続けることに。 • 最新版なら簡単にできるはずの機能が使えなくて、はがゆい。
  21. 21. 金曜の夜にバグ報告を出し逃げされる • すっきりして土日を迎えたいのはみんな同じ。
  22. 22. 最新のライブラリやデータを渡したのに 反映されていない • 修正箇所をメールで知らせたことによるコピペミス。 • プロジェクトのフォルダ構成がややこしくて、ライブラリファイル を違うところに置いてしまっている。 • 担当者が今日は不在だった(情報が入ってきていない!!)。
  23. 23. ソースで渡すと「高速化!!」 とか言って魔改造される=不具合発生 • 当然ライブラリの全容を理解しているわけではないので、不具合の 温床になりやすい。 • 改造による不具合の場合、ライブラリチームの環境では発生しない ため、原因の追及が余計に難しくなる。 • 自分のバグより他人のバグを直すのが好きな人もいる。
  24. 24. タイトル側担当者が 「このクソライブラリが!!」とかツイートしてる • 無視しましょう。
  25. 25. 打ち上げに呼んでもらえない • …とはいえ、ライブラリチームは担当者としか面識がないので、実 は呼ばれてもちょっと困る。 • その担当者とも、丁々発止やりあった後だったりすると…。
  26. 26. なかなか完成しない • 1∼2年くらいで完成させて手放そうと思っていたのが、もう8年。 • ゲーム機の世代が変わるのはまだしも、概念すら変わりかけている。
  27. 27. 婚期を逃す • 残念です。
  28. 28. なぜライブラリ開発は辛いのか? • 開発業務の合間に軽く済ませられたサポート業務が、機能追加や対 応機種の拡大によって無視できないレベルになる。 • それらをコストもしくは人員の増強としてなかなか計上できない。 ↓ 「ブラック」化
  29. 29. 「ライブラリを作ってはいけない」 ということが分かりましたね?
  30. 30. それでも作りたい? …しょうがないなぁ。
  31. 31. 辛くならないための方法
  32. 32. APIの数を極力減らして 変な使い方をされないようにする • 想定外の使われ方は、潜在的なバグを呼び起こす。 • 多機能ではなく高機能を目指して、APIの抽象度は高めにする。 • 「アンチパターン」が参考になる。
  33. 33. ドキュメントとサンプルプログラムを 充実させる • 多くのプログラマーは、サンプルプログラムをコピペして使ってい る(断言)。 • サンプルが正しい使い方をしていれば、変な使い方はされない。 • 問い合わせに丁寧に答えつつ、「マニュアルの○ページにも書いて あります」と返せると、強い。
  34. 34. SDKのサンプルプログラムを コピペして作る • SDKも「ライブラリ」なので、どう使えば問題が起こりにくいかは 全く同じ。 • SDK開発者が使って欲しいと思っている方法で使ってあげよう!!
  35. 35. Windows版も作る • 全員が開発機を持っている訳ではないが、Windowsはみんな持って いるので、みんなでデバッグできる!! • Windowsはメモリ保護もあるしランタイムでのチェックも可能。 • VisualStudioのエディタやデバッガがとにかく優秀。 • 64bit版の実験台にもなる。
  36. 36. 全機種でデータを共通化 • ライブラリのWindows版を作ったとしても、データが違うと意味が ない。 • 共通部分はリトルエンディアンに統一。現世代はこれが主流である し、変換コストより運用上のメリットの方がはるかに大きい。 • 機種依存部分はチャンク形式によるブロック化で切り離したり。
  37. 37. エラー処理をきっちりとやりすぎず あっさり落とす • NULLアクセスなどで落ちるはずのところを無理矢理回避してその まま進行すると、想定外の部分で落ちて原因が分かりづらい。 • 使う側がエラーチェックしていないことも多いので、エラーのタイ ミングを掴めない。 • デバッガに落ちる瞬間を拾ってもらった方が分かりやすい。
  38. 38. 頻度の低いバグを見逃さない • こういったバグはマスター提出直前に「必ず」再発する。 • プログラムに「たまたま」はない!! • 頻度が低くても、バグ報告をよく読んで状況を絞れば、再現しやす い環境を作ることはそれほど難しくない。
  39. 39. ソースでは渡さず ライブラリファイルで渡す • 魔改造はさせないぞという意思表明。 • プロジェクトによってビルド設定が違っていたりして合わせるのが 面倒なので、それを回避するためでもある。 • マスター直前の場合、ライブラリの改造ではなく、使い方の変更で バグを回避する手法を提示する。
  40. 40. ライブラリファイルとデータに バージョン番号を埋め込んでおく ! • 更新ミスを判定するために、ライブラリファイルにSubversionなどのリビ ジョン番号を埋め込み、それを取得するAPIも用意する。 • ヘッダファイルの定義を書き換えるだけではダメ。ヘッダファイルは更新し たがライブラリファイルが更新されていないということもよくある。 • データに日付を 文字列 で埋め込んでおくのも手。タイムスタンプはあてに ならず、これならゲームを実行しなくてもバイナリエディタで確認できる。
  41. 41. ブランチを切らない • ブランチが増えたら増えた分だけ、サポートの手間が増える。 • どうせマージは失敗するよ。 • 全部trunkで行こう!!
  42. 42. プログラミング以外の作業は 徹底的に自動化 ! • ビルドはJenkins。古いバージョンのSDKでのビルドとか、ブランチへのパッ チを当てたバージョンのビルドとか、自動化しづらい部分であっても手作業 は最低限で済むような仕組みを作る。 • Windowsのバッチファイルで書いておくと、関連ツールのインストールが必 要ないので、自分以外の誰かに作業を任せるのが楽。 • ドキュメントはDoxygen。コード内に記述できるので面倒がないし、ライブ ラリとドキュメントのバージョンがずれたりすることもない。
  43. 43. サポート窓口をRedmineなどの 案件管理システムにしない • Redmineなどの高級なシステムは、必要以上にボタンやパラメータ が多く、敷居が高い。使い方が分からず、口頭で来る人も多い。 • もちろん案件管理システムとしては優れているが、窓口には適さな い。
  44. 44. とりあえず何でもメールで受け付ける • ライブラリチーム全員に配信されるメーリングリストを開設して、 とにかく何かあったらメールを投げてもらうようにする。 • 「バグ」や「要望」だけでなく、「相談」も見逃さない。 • 案件管理システムにはライブラリチームやサポート専門要員が入力 し、サイトのアドレスを返信して、以後はそちらでやりとり。
  45. 45. 「開発者による直接サポート」 を売りにしない • 小規模なライブラリチームが「売り」として言いがち。 • 案件が同時に複数入ると簡単に破綻する。 • 案件への対応が遅れてクレームが来るだけでなく、肝心のライブラ リ開発の進行も止まる。
  46. 46. サポート依頼に対する返答期限を 「最長で1週間」と表明しておく ! • 一見遅いように感じるが、案外なんとかなる。相手もそれに合わせて 1週間余裕を持って問い合わせてくれる。 • もちろん余裕があればその日のうちに返答。あくまで最悪の状況のと きの時間稼ぎ。 • マスター提出直前ではそういうわけにはいかないが、その対応が特別 なケースであることは理解してもらえるはず。
  47. 47. ご用聞きに行く • 「便りがないのは元気な証拠」…であった試しがない。 • 最初は「大丈夫だ、問題ない」と言っていても、突っ込んで行くと 怪しい情報が出てくる。 • トラブルの芽は早めに摘む。
  48. 48. かつての同僚や同期から 情報を横流ししてもらう • バグトラックシステムから関係ありそうな情報をピックアップして もらう(ライブラリチームには閲覧権限がないことがほとんど)。 • 本当のスケジュールを聞き出す。 • 人脈は有効。
  49. 49. 仁義は通す • 横流ししてもらった情報をもとに動くとしても、必ずタイトル側の 担当者を通す。 • タイトル側の担当者は数少ない味方。
  50. 50. 何でもかんでも プログラムで解決しようとしない ! • 実装が難しいなら仕様を削ってもらう、重いならデータを減らしても らう、不安定ならその機能を使わないようにしてもらう。 • コードをこつこつ削るより、テクスチャ1枚リサイズしたほうが速い こともある。 • 周りもプロのゲーム開発者。何らかの制限がある中でも、ベストな仕 事をしてくれるはず。
  51. 51. これにて、めでたしめでたし
  52. 52. …とは行かないようです。
  53. 53. ツイートツイート 992 ホーム > プレスリリース > ソニー・コンピュータエンタテインメントとユニティ・テクノロジーズ 「プレイステーション」向け「Unity」を すべてのソ フトウェアタイトル開発者の皆様に無償提供 ENGLISH 2014年9月17日 株式会社ソニー・コンピュータエンタテインメント ユニティ・テクノロジーズ ソニー・コンピュータエンタテインメントとユニティ・テクノロジーズ 「プレイステーション」向け「Unity」を すべてのソフトウェアタイトル開発者の皆様に無償提供 株式会社ソニー・コンピュータエンタテインメント(SCE)と、革新的な開発プラットフォーム「Unity」を提供するユニテ ィ・テクノロジーズ(本社:米国カリフォルニア州)は、2013年3月に合意した戦略的提携にもとづき、「プレイステー ション」向け「Unity」の「Unity Pro for PlayStation®」を提供していますが、この度さらなるパートナーシップの強化を図 り、「プレイステーション 4」、「プレイステーション 3」および「プレイステーション ヴィータ」向け「Unity Pro for PlayStation®」をすべてのソフトウェアタイトル開発者の皆様に無償で提供いたします。 1,029シェアシェア
  54. 54. 社内ライブラリが この先生きのこるには?
  55. 55. 市販ライブラリ 社内ライブラリ 機能 汎用的 独自機能あり コスト 価格競争が激しい 社内人件費高すぎ サポート サポート専任スタッフ がいる 開発者が空き時間に サポート 力関係 何でも言うこと 聞いてくれる 文句も言う
  56. 56. 勝負にならない!!
  57. 57. 生き残るためには… • 特定のプロジェクト専用に進化させる。 • ライブラリを応用した独自のアプリを提供する。 • ゲーム業界以外に進出する。 • …他にも何かあればメール等で私までご連絡ください!!
  58. 58. まとめ
  59. 59. 辛くならないためにやるべきこと • バグを減らす。 • デバッグしやすくする。 • 情報を入手する。 • 時間に余裕を持つ。 • 何でもかんでもプログラムで解決しようとしない。
  60. 60. チームの労働環境が 悪くならないようにしましょう • 最初の頃は焦る。採用タイトルは少ないし、不具合もたくさん出る し、サポートのせいで開発は滞る。 • だからって、「ブラック」になっちゃダメ。
  61. 61. 「今、無理しないでいつ無理するの?」 ↓ 10年にわたって無理し続けることになります。
  62. 62. でもやっぱり ライブラリ開発は楽しい
  63. 63. 周辺環境を整備して 持続可能なライブラリ開発を 続けて行きましょう!! ありがとうございました

×