サポートということに関して

  • 現在まとめ中
  • 「こだわり」は必要ですが「こだわり=自己満足」ではありません。
    「こだわり=ユーザー評価(満足度等)」となるように、「こだわり」ましょう。
  • 「報・連・相」「5W2H」社会人としてこれらは知っておくべきことだと思います。
    これらができないとコミュニケーションを取れないなど問題となりますので、意識しましょう。

ソフトの不具合に関して

  • ソフトの不具合に関してはいくつかの種類があります。
    • ソフト自体のバグ
      基本的にはデバック不足、開発陣の連携不足、TOP判断のミス等により起こることがあります。
      また、出荷時に必要になるソフトの添付不足もソフトのバグに当たります。
  • 動作確認外による想定外の現象
    動作環境を満たしている場合でも、動作確認をしていない機器を含む環境での動作での環境依存での具合です。
  • OSのバグ
    OSに含まれるDLLやその他システムにおける潜在的なバグによる現象です。
    回避方法が存在している場合がありますが、大概使用環境個々に対して修正を行わなければならず、同一環境化でも使用者によって変化する場合があります。
    そのため、事前に対処することがほぼ不可能に近く、現象に対する対処を蓄積し、その後に生かす形をとることをお勧めします。
    もちろん、あらかじめわかっているのに対処しなければ、ソフト側の問題となります。
  • ハードウェアドライバのバグ
    ソフト側のバグというわけではないですが、動作検証等で回避できる問題だと思っています。
    以前から存在はしていましたが、基本的にハードウェアが違う、または発売したばかりでのドライバ熟成の浅さによる現象が主だったものでした。
    しかし、現在同一のハードウェアのドライバの新しいバージョンへ更新することで起こる場合が頻発しています。
    いろいろ出る話ではATiが不安定でnVidiaのほうが安定しているなどというのを聞きますが、自分が体験した限りではどちらも代わりがありません。
    たしかにATiのドライバに癖のようなものがある場合がありますが、同じようにnVidiaのドライバも癖があり、うまくいかない場合があります。
    また、いままでに体験した中では、ドライバそのものがメモリリークを行い、動作がおかしくなるという現象やニュースを確認していますし、現在もそういったドライバがリリースされている状態です。
  • ハードウェアの組み合わせに起因する現象
    ソフト側のバグというわけではないですが、動作検証等で回避できる問題だと思っています。
    一部のハードウェアの組み合わせに、なぜか動作が不安定になる組み合わせが存在しています。
    ドライバレベルなのかハードの問題なのか、それ以外なのか現象が起こるまでまったくわからない現象で、しかもハードのバージョンや、ドライババージョンの組み合わせのごく一部におきる現象です。
  • OSの使用劣化による現象
    Windowsは使用していると徐々に安定性を欠いていく場合が在ります。
    これは、ソフトのインストールやWindowsUpDate、ドライバのバージョンアップなどでDLLの置き換えやシステムプログラムの再配置などが原因で起こるようです。
    ただ、バックアップをした上で、HDDをフォーマットから再インストールをすることで、環境をリフレッシュできますので、これで回避可能です。
    WindowsUpdateやドライバのインストールなどは、Windowsを使用する前に最新の状態にした場合には影響が無いようです。(組み合わせによる不具合を除く)
  • 動作環境外における動作での現象
    これに関しては発売側の問題ではないのですが、ユーザーが納得しない場合が在ります。
    対処としては、情報公開で動作しない環境があることをはっきりと明示し、流通やショップにもきちんと情報を流す事と、動作環境の確認を購入者にしてもらえるよう働きかけ、POPなどをお願いするといいでしょう。
    それでも、回避しきれない場合も在りますが、事前に情報を公開していること、動作環境というものがどういうことなのかを説明することで収めることができるものと思われます。

事前準備

  • 各社のサポートを確認する
    • HPなどで現象やその対象に関する情報を乗せているメーカーは比較的多いので、そういった情報を収集しておけば、あらかじめどういったことが起こりえるのか等、心が前も含めて準備が可能。
  • パソコンの選定
    • 開発環境は、同一の環境をできるだけ作らないように構成しておくと、動作検証などのときに環境を増やすことができて、現象の再現、動作環境の範囲拡大になります。
    • 中古でもかまわないので、古目の環境やパーツをそろえておいて、稼動可能状態にしておけば、必須環境での動作確認などに役に立ちます。
  • メーカー協力
    • ハードメーカ各社は動作検証ルームの設置や、パーツの場合も各社日本支社(法人)へ連絡する事で、レンタル等で動作検証対応をしてくれる場合があります。
    • ハードメーカーホームページにも有用なサポート情報があるので、気になった項目に関しては情報として整理しておく事をお勧めします。
  • 情報の収集
    • Windowsの場合、日々情報が更新され、各社ホームページや、Fanページ等で情報の収集は欠かさないほうがいいでしょう。
    • 雑誌にかんしては、ネット上で公開されていない情報がたまに載っていたり、パーツ比較記事が役に立つので、店頭で確認した上で、購入、必要ページの保存をしておくと便利です。
  • 集めた情報に関して
    • できれば開発、販売にかかわる人間全員が参照できるように、見易く整形した上で社内Webページでの公開を行いましょう。
      その際、DBやCMS(PukiWikiとかXOOPSとかZOPE)を活用することで、メンテナンス性の向上も図っておきましょう。
    • 情報は死蔵していても意味がありませんし、見ているだけでも意味がありません、活用して、あらかじめ起きるかも知れないことを把握した上で開発を行いましょう。
  • 担当者
    • できればプログラマーとしての知識のあるサポート/デバック管理/製品品質管理の専任担当者が望ましいです。
      専任が無理なら、兼業で2〜3人担当にして、情報の共有を図りながら行ったほうがいいです。
  • 動作環境の決定
    • 自社で確認できない環境を動作環境にするのはやめましょう。
      最低動作環境などで、予測で動作環境を決定していると見受けられるソフトをいくつか見かけますが、大概動作しません。
      もちろんマーケット的な問題などあるとは思いますが、動作確認が取れる環境から、最低動作環境を設定しましょう。

デバック作業

  • デバック作業に関して
    • テストプレイだけがデバックではないです。
      たとえば、シナリオ内に使ってはいけない言葉(禁止用語や商標など)がないか、画像も使ってはいけないものや、表示してはいけないものが無いのか等、多岐にわたります。
      こういった細かい部分をテストプレイのときにまとめてやろうというのは、無謀です。
  • 企画段階
    • 営業的判断、経営的判断から基本となる制作期間(予定発売時期)を決め、その上でスケジュールを作成し、Go/NoGo?をまず判断するべきです。
      この際、残業や徹夜、人員の適時補充が行われないことを考えた上で余裕のあるスケジュールをたて、そこからマイナス一ヶ月で製作可能なスケジュールであるべきでしょう。
  • 企画段階での誇大妄想はやめましょう。
    プログラマーもCGさんもサウンドさんも魔法使いでも無ければエスパーでもありません。
  • シナリオ段階
    • シナリオ制作は、誤字、脱字の再確認、使用してはいけない言葉のチェック、シナリオの整合性の確認などを行いながら推敲を行うといいでしょう。
      なお、この際シナリオライターだけではなく、企画者、プログラマー、制作進行などの関係他者と一緒に行うことでミスや抜け落ちている項目などの確認を行いましょう。
    • 音声を収録する場合は、台本が必要になりますが、シナリオを作成する際に台本化することを前提に作成しておくと便利でしょう。
      掛け合いなどが無い限り基本的に声優さんが個別録音で行うことになると思われるので、下記のようになっていると便利ではないでしょうか。
      キャラクター名作業用PCMNo台詞
      [キャラ名]PCMXXXXX「〜〜〜〜〜〜〜〜〜〜〜」
      [キャラ名]PCMXXXXX「〜〜〜〜〜〜〜〜〜〜〜」
      [キャラ名]PCMXXXXX「〜〜〜〜〜〜〜〜〜〜〜」
      [キャラ名]PCMXXXXX「〜〜〜〜〜〜〜〜〜〜〜」
      作業用PCMNoは台詞の前に声優さんに言ってもらって作業しやすいようにしたほうがよいでしょう。
      また、実際には「縦書き」・「個人別」に台本を用意するほうがよいので、そういったキャラクターの台詞ごとに抜き出すツールや台本印刷用プログラムの作成をしておくと便利でよいでしょう。

  • プログラム段階
    • プログラムの際は必ずコメントをわかりやすいようにつけておくことを心がけましょう
      また、コメントをつけすぎてもむしろ見通しが悪くなるので、そのあたりは加減しながら記載するのが望ましいです。
    • 変数や関数の命名についてですが、意味のある言葉でつけるようにしましょう。
      命名の際にクラスごとや機能ごとに規則を設けてできるだけ統一しておきましょう。
      ただ、関数内の一時的なポインタなどのローカル変数は、短いコメントがあればわかるので「pClass」など簡略でかまわないでしょう。
    • クラスや関数のラッピングに関してですが、ラッピングし過ぎないようにしましょう。
      継承などを用いてラッピングすれば便利では在りますが、見通しが悪くなりやすく、修正が複雑になりバグの温床になりかねません。
      シンプルで見通しがよいプログラムを心がけましょう。
    • 関数は機能ごとに分けておいて、ClassやNameSpace?で纏め上げて、ファイルを分けておくことで扱いやすくなると思います。
      NameSpaceCG
      CGClass標準
      CGClass加工
      CGClass特殊
      NameSpaceBGM
      BGMClass標準
      BGMClass特殊

  • 原画、CG作成段階
    • 締め切りに関して安楽な考えを持たず、締切日の締切時間が24時などとは思わないこと 最低でも締切日終業時間より2時間は前に担当者の判断を仰ぐようにする
      締め切りぎりぎりでは、修正がはいる場合修正する時間が無くなるため、そのようにするとよいでしょう
    • 著作権や肖像権が発生する物体を画像の中に絶対書き込まないこと
      単純なところでは町の風景でも、看板は文字を変更しなければなりません。
      また、建物そのものに著作権が存在する場合があるので注意が必要です。
      そのようなことをして発覚した場合、行った人は懲戒免職だけではすまない可能性が在ります
    • 納得がいかない、没になった場合場合は小手先の修正では意味が無いので、
      できるだけ大胆に行うほうがよい結果になるかもしれません。
  • 告知段階
    • 初期の段階では作っていても、一切告知やうわさも流さないようにする
    • 計画している完成時期がほぼ固まってくるくらい製作が進んだときに、企画しているや発売予定のような形で流す
      イメージボードやテスト画像なども流す
    • アルファレベルの段階で発売時期(発売日ではなく発売の季節)を告知して完全に公にする
      大幅に公開試料を増やしユーザーの声などを拾い対処可能なら対処していく
    • ベータ2〜3またはRCの段階で発売日の告知などを行う
      外部テストを開始したり、連続動作のテストも同時に行い問題が無いことを確認する
  • マニュアル等付属品段階
    • テストプレイにあわせてアルファ版のマニュアルを作成し、テストプレイや修正が進むたびに正規マニュアルへ整形していく
    • 付属品や特典等はゲーム内で確実に変更の無いものを使用して作成する
      イメージなどの問題もあるのでゲームと関係の無いものや意味の無いものはやるだけ無駄になってしまうし、ユーザーも期待しない
  • テストプレイ段階
    • 担当プログラマーはできるだけTry&Errorを行い熟成を進めておく
      必要なDataがある場合(リアルタイム用3DDataは特に)はダミーと、製作が進む時点で先行してDataを渡してもらうようにする
      また、足りないダミーDataは基本的に自作する心意気で、作成できないものは早めにお願いをしてプログラムを行う
    • アルファテストの段階では、Dataがそろっていない可能性もあるが致命傷となりそうなバグを重点的に確認
      ストーリーの流れや台詞チェックなどもこの段階から進めていく
    • ベータの段階で外部テストや動作機器チェックを進める
      必須動作環境の確定する目的もあるので、細かに確認する
      また、Dataも基本的には最終版でチェックする
    • RCまたは最終ベータは、すべてのDataをフリーズさせて致命的なもの意外は変更を行わない
      プログラムも余分なコードを増やしたり変更を行わずバグの修正のみに特化する

動作検証

サポート

情報公開