フジトのひとりごと。

[Nein]

FUJITOさん、LSコミュの障害対応状況を教えて下さい。
もう、あなたしか頼る方がいないです・・・

[Amagami]

最近TPのたまりが遅いのですよ・・・

強スロウで衰弱ですね、判ります

モッチーさんのコリブリ・・・いやらしい・・・ぽっぴぃ

[Hamutaro]

モッチーさんの色紙いいですなぁ(*`-`)

[Barcag]

もっちー、絵上手い…
問題山積ですが、頑張ってくださいね。

[Milky]

Oh!! Yeah　と　おえーがかかっているのか…。
ふ、深い…！
さすがはもっちー。
忙しいなか、お疲れさまです。
ちゃんと休養はとったほうがいいですよ～。

[Namo]

お誕生日おめでとうございます！
寒暖の差がはげしいので体調に気を付けてください。

[coca]

3枚入りのうち2枚使ったって事は、残り1枚は、藤戸さんが書くのか・・・！？

もっちー上手ですねーゲェー
あさこさん実にシンプルでいいですね、ミスラっぽい（？
その前はタルタルだったとか覚えてないですし気にしない（・∀・）

[Rinn]

こんばんは。

今日もお疲れ様です。
藤戸さんのゆるゆる活動ヾ(゜ー゜ゞ)( 尸ー゜)尸です。


あしたも、アドゥリン探検するぞ～(´・ω・｀)

[popochan]

もっちーさんの意外な才能が？！
気温の激しさに、体調気をつけて下さいm(__)m

[Yoji_Fujito]

いやー、もうなんだか肩こりがひどくて、首筋なんか痛痒い今日この頃ですこんにちは。
休憩の時間ですよ。

きのうちょっと弾けすぎたので、たまにはちゃんとしたひとりごとをつぶやこうと思うんだ(ｷﾘｯ


今日は何の話書きましょうかねー・・開発の裏側的な話？でもします？

じゃー、バージョンアップに向けて、ウチらがどんな毎日を過ごしているのか、でもかきましょか。

■いわゆる日常の業務

バージョンアップをするまで、大体2つの大きな仕事を繰り返してます。

１つは「開発」。
作らなきゃ新しいものは出てきませんしね。
企画・プログラマー・デザイナーが協力して、コンテンツやアイテム、追加要素なんかを作ります。
いくつかの企画が並行して走るのが普通なので、担当者間での連絡がすごく重要。
うまくピースがはまらないと、まったく進捗しないこともあります。
いわゆる「コスト」もここに影響を与えてきますね。

はい、それともう１つは「検証」です。
FFXIの場合は主に品質管理部という別の部署と連携して進めます。
検証作業は新たに実装する内容自体の動作チェックだけではなくって、それが実装されることで他の要素が影響を受けないかどうかも確認していきます。
FFXIは10年の積み重ねがあるので、過去の要素との相互チェックは年々増えてとても大変！

この「開発」「検証」を交互に進めていって、徐々に完成度を高めていくわけです。
で、最終的にバージョンアップのパッチデータを仕上げて、皆さんお使いのマシンに配信するんですね。

ざっくり書くとこれが概要なんですけど、これだけで終わるわけないんですよね。
そうです、皆さんご存じの「緊急メンテナンス」ってやつです。


■NM Urgent-Maintenance

もう冗談として浸透してるんで使いますけど、
「峠のTaisaiが××落とした！」
といったたぐいの噂は本当に開発泣かせです。

だって、本当に落としてたらバランスブレイカーになるかもしれないですからね。
だからたとえ噂や嘘でも、改めて検証作業は行います。

それでもし本当だったら？
いよいよ奥の手「緊急メンテナンス」発動です。

ちょうど別のスレッドを読んでいて、なかなかスルドイ指摘をされてる方がいらしたのでちょっと引用。

あえて開発側にたって優先順位をみてみると対応の優先順位が見えてきます

最優先：ゲームの進行に係わる致命的な問題
今回のアップデートいえばイベントアイテムがイベントを達成しないと進入できないエリアにある問題はこれにあたります。このような問題は緊急メンテの対象になります。

優先：ゲームバランスを崩す深刻な問題
今回のアップデートではチケット増殖バグ、レイブの評価等が該当するでしょう。できる限り早期の対応、必要であれば緊急メンテの対象にもなります。

通常：直接ゲームの進行を阻害しない問題
一般に深刻ではないがバグや不具合というとこのランクになります。このスレッドで話題になっている問題もここに分類できます。通常業務のスケジュールに盛り込まれ順番に対応されます。目立つ部分については同じ分類の中で優先的に処理されることでしょう。

その他：上記の分類外の問題
表記や銘銘の統一、潜在的な問題で表面化していないものなんかがこの分類になるでしょう。優先度はあまり高くなく、通常スケジュールのなかであいたりソースが割り当てられることが主になるでしょう。

一般にオンラインゲームでユーザに優位になる不具合は深刻もしくは致命的な不具合に分類されます。なぜなら不具合を知っているユーザと知らないユーザに有利不利の差が生まれるからです。ユーザが不利になる問題は知っていても知らなくても一律になりユーザ間に差が生まれにくいので深刻な問題になるケースは少なくなります。

的確な分析です。およそこれで間違ってません。

実は検証時に出てきたバグに割り当てられる「バグランク」というものがあるのですけど、まさにこの分類です。
そしてRouさんが指摘されてるように、最優先・優先にある問題は緊急メンテナンスのトリガーになります。


緊急メンテが必要な案件ってやつは、じつにやっかい。
「調べる」コマンド的に言えば「計り知れない強さ」！

・・というのも、先ほど書いた「開発→検証」（原因究明→再現テスト→修正作業→検証）という一連のサイクルに加えて、そもそも急ぎのためにサイクルが著しく短いので、副作用が見つけられない恐れがあるからです。

例えば、ひとつのドロップテーブルを修正するために、更新されるファイルに含まれるデータが、該当箇所以外に変化がないことを確かめないといけなかったり。油断してこの検証をスキップすると、稀に更なる不具合（エンバグといいます）が追加されることも・・。

それゆえに、修正内容もできるだけ鉄板な、間違えようのない修正になることが多いですね。
例えば一時的にNPCを消したり。その間に根本治療を施して、後日再オープンみたいな形式もあります。

これがクライアントデータの更新を必要とする場合には、クライアント更新データを作ること自体に半日近く掛かってしまいます。クロスプラットフォームですからね。
そこから検証→ミスってたら修正して作りなおし→検証・・みたいな。

ゆえに、すぐ直りそうなものでも大変時間がかかったりします。


＞＞そしてはじめに戻る。



とまぁ・・こんな感じです。

緊急メンテとかね、ホントは無いようにしないといけないんです。
自分はわりと常習犯なので痛く反省・・・。


って、全然休憩になってない上に、ここむけのコメントじゃねええええ！

でも書いちゃおう。あらよっと。