  |
はてなキーワード: エンバグとは
ゲーム開発者とユーザーは数ヶ月〜数年レベルで生きている時間が違っている。
最近だと、とあるタイトルの制作発表に際して、「『このキャラを出して欲しい！」と言うツイートをたくさんすれば、DLC等で実装される可能性も出てくるだろうし頑張ろう！」なんて言った呼び掛けが見られたが、ゲーム開発者からすると申し訳ないがだいぶ難しい。
勿論私は件のタイトルに関わっているわけではなく、リーク情報を持っているわけではない。
(任天堂が関わっているタイトルの情報のリークなんてゲーム開発に携わる人間ならどれほどリスキーなことかわからないはずがない)
とある企業でコンシューマゲームの開発をしていたり、アプリタイトルの開発・運営をしていたりするただの会社員だ。
ただ、企業ごとに細かい差はあれ大体のゲーム開発の流れは同じだ。
↓
大枠を作る
↓
会社内でチェックを受ける
↓
本制作に入る
↓
会社内でチェックを受ける
↓
(しばらく制作・チェックの繰り返し)
↓
↓
↓
発売
これが大体2〜3年程度で行われている。
発売(配信)
↓
↓
↓
↓
アプデ配信
といった作業が発生する。
では、制作発表はこの計画のうちどのあたりで行うのかと言うと、大体は本制作に入ったあと、発売の半年〜1年前のことが多い。(それこそ任天堂は直前にサプライズ発表することもあるが)
よほどのタイトル・よほどのコアユーザーでない限り、客は何年も先の予定など待っていることができない。楽しみに待ち続けられるのはそれくらいの期間が限界なのだ。
また、その時期より前になってしまうと開発中に大幅な方向転換があることも多々あるため情報を出せる状態ではないことも多い。
「※画面は制作中のものであり、実際とは異なる場合がございます」なんて言葉を使っても許されないレベルに内容が変わることもザラにある。
だから、初報を打つ時期というものには本当に慎重になり、大半が固まった時点でようやく……となる訳だ。
そうするとどうなるかというと、その時点からユーザーが「こうして欲しい」「ああして欲しい」と言ったところで、対応しようがなくなる。
作り終わったものに手を加えるのは本当に怖い。エンバグの大きな要因になるからだ。
DLCを販売する予定があるのではあれば、大抵の場合は設計時点から「ここにこういうものを加える」と決めておくのが安全な開発だ。
また、後からDLCを作成する際には、技術面以外でも金銭面に負担が非常に大きい。
開発自体にコストがかかり、社内のデバッグでコストがかかり、プラットフォームの審査に費用がかかる。(プラットフォームの審査は年会費のものもある)
これは事前に作った上で時期をずらして配信とかであればかからないはずのコストだ。
だから、よほどの利益が見込めない限り後から付け加えるメリットがない。
もし仮にファンの要望が通ったとしたら、それは本当にたまたま元々の開発の予定と一致していただけの偶然がほとんどで、残りは「余程の利益が見込めた」場合だ。
これはアプリタイトルも全く同じで、カスタマーサポート(以下CS)にきた要望にすぐ応えることは非常に難しい。
例えば、給料日より後に引きたいからガチャの期間を延ばせと言われても、もうガチャの期間を決めたデータが入ったアプリが配信されているのでそれを修正するには新しいバージョンをリリースする必要がある。
しかし新しいバージョンの配信にはやはり開発、モニター、審査の3つの過程を通過する必要があり、そもそも時間的にもすぐ対応することは困難だ。
さらに、カードイラストなんかは発注と制作で数ヶ月はかかると思って欲しい。リアルタイムに客の声を吸収することは不可能だ。
CSに寄せられた要望がすぐに叶う場合は、たまたま開発でもその問題を認識しており対応していたか、もしくは余程の重大なバグで修正しなければプレイできなかったり、法務的な問題が発生してしまうものだったかのどちらかだろう。
その他に関しては、寄せられた要望に対してコスト面などを考慮しつつ時間をかけながら修正していくことになる。
「無能運営」「クソ運営」と気軽に送ってくる方々も、裏側にはいろんな事情があってそれぞれ会社という枠組みの中で必死に対応しているのだということをどうか理解して欲しい。
(私はCSからのお問い合わせ一覧を見ると、世の中にはいろんな方がいらっしゃるんだなと思うと同時ストレスで体調が悪くなるので、CS対応の同僚が心配で仕方ない)
長々と書き連ねてみたが、勿論ユーザー意見・要望を送ることに全く意味がないわけではない。
DLCでの対応は無理でも、続編が出るとしたら参考にすることだってある。
厳しい内容でも(できるだけ社会人としての最低限の配慮ある文面であって欲しいが)、真摯に受け止めたいと思っている。
我々ゲーム開発者は結局面白いと思ってもらえるゲームを作りたい一心で数年かけて開発を進めているいるのだから。
けれどその一方で、ゲーム開発者とユーザーとでは時間的に大きな差があり、その要望を全て聞けるわけではない事を理解いただけるよう願う。
Android版バグについて開示された文書を少し読むだけでいくつかのデマが分かった。
https://note.com/mugura/n/ncc3c61de39ea で情報開示されたPDFを読むことができる。
議事録側はまだ読んでいない。
最初にHER-SYSの開発のためにパーソルプロセス＆テクノロジー株式会社と税込約2億の契約があった。
COCOA開発は原契約を税込約3億へ変更とすることで対応した。
契約変更の時、再委託先を株式会社FIXERの1社から以下5社へ変更する申請がなされた。
厚生労働省 ┗ パーソルプロセス＆テクノロジー 2億6771万（税別。以下同様） ┣ FIXER 1億2062万 ┣ エムティーアイ 1615万 ┃ ┣ E社 355万（MTIから） ┃ ┗ D社 41万（MTIから） ┗ 日本マイクロソフト 2201万
| 株式会社FIXER | 新型コロナ感染者等情報把握管理システムの開発、監視運用、サポートデスクの一部業務、およびサービスの提供 |
| 株式会社エムティーアイ | 接触確認アプリケーション開発の一部、リリース後のヘルプデスク/運用保守業務 |
| E社（MTIからの委託） | メールサポート（日本語/英語） 接触者に対する電話サポート（日本語のみ） |
| D社（MTIからの委託） | 初期検収業務の一部、および保守開発準備業務の一部 |
| 日本マイクロソフト株式会社 | PMO支援、技術支援 |
デマについて
・まず2億から3億の差額約1億がHER-SYS側への繋ぎこみおよびiOS・Androidのアプリ開発に充てられていることになる。アプリ開発が3億のように言うとデマ。
・そして3次請けの位置の2社は業務範囲に開発は含まれていない。「多重請負でたったこれだけに」みたいな図でここの金額が出てきたらデマ。
ここからは憶測や調べ切れていないこと。（議事録側で分かることもありそう）
・COCOAのベースはOSSのCOVID-19Radarで、開発に関してはどこかにOSS利用という線を引いた方が分かりやすい。
・OSS利用を0円発注の搾取とは通常言わないが、今回に限っては、1国1アプリの条件がある中で、6月中旬公開の宣言されて実質納期になったり、
初期の品質批判がコミッターに直撃してリタイアしたところを見ると受託者に近いようにも思う。
https://www.itmedia.co.jp/news/articles/2006/23/news107.html
・開示された文書での契約期間は2020/7/31までだが、それ以降の体制は未確認。
・2020/9/28にiOS版の不具合（通知あるのに接触なし表示）修正のためにアップデートが行われ、その時Android版にエンバグが発生した。
https://www.asahi.com/articles/ASP236SR9P23UTFL00R.html
・政府CIO補佐官(ブクマカ)のツイートでは、EN API自体の制約や、アプリで選定された技術から人材・機材の手配の難しさに言及している。
https://twitter.com/masanork/status/1358207125546127362
https://twitter.com/masanork/status/1358187420492001281
・人材についてはMSがいるのにと思ったが、MSの支援が切れる事情でもあったのだろうか。
・COVID-19Radarでない方のまもりあいJapan（の一般社団法人Code for Japan）は新型コロナウイルス感染症対策テックチーム第1回から参加していたが、採用されないことになったについて根拠が不透明とある。
https://medit.tech/code4japan-not-incharge-of-contact-tracing-app/
・COVID-19Radarの中心がMS社員であったことや、Azure DevOpsなどMS一色の技術選定であったことなどから経緯を訝しむ考察があった。
https://blog.rocaz.net/2020/06/2140.html
https://blog.rocaz.net/2020/06/2171.html
https://blog.rocaz.net/2020/07/2257.html
・そして今回の開示された文書でもなぜCovid-19 Radarが選ばれたのか不明とある。
・選定が不具合と直接関係ないとは思うものの、利用人口少ない技術スタックを選んで人材不足になったなら遠因にはなってる気がする。
・大きくやらかした時に責任取り切れず法人ごと消えることの無さそうな大企業を窓口に選びたいところまでは分かる。
あの増田あの後どうなったかな、などと気になる事がよくある。もしかしたら追記があるかもと、見に行ってしまう。追記してくれると嬉しい。嬉しい気持ちはもちろんあるのだ。
しかし、考えや悩みを一旦なんの相槌も無く吐露するという、日常会話では発生せず、インターネット上のテキストコミュニケーションでもあまりない状況から生じる文章こそを楽しんでいる自分も居る。
そこは完結して、完成している。いくらか逡巡しながら、場合によっては少し言い回しを編集しながら、自分の中にあったわだかまりに名前をつけて書き出す。昔の公文書や文豪の私筆よりは重くなく、 SNS の投稿よりは軽くない、ここにしか表れ得ない文章がある。
そんな完成された文章に追記が入ると、リアルタイムで読んでいた人のためのものになってしまうような気がして、なんだかもったいないような気がしてしまうのだ。いつか誰かが辿り着いたとき、ただその文章に良さを感じて読み進めると、一応のオチや締めがついている。もう本人は見ていないという事実だけが、閲覧者に流れ来る。
一度完成された文章に関連付けるものとして、トラックバックがあった。近藤さんの独自解釈によって本来の目的は変容し、ある場所ではコメント機能になり、ある場所では呼び出し機能になった。
近藤さんのサービスセンスは好きだが、技術理解に関しては何かと異論を唱えたくなる。彼にとって技術は手段であり、我々にとっては目的である。トラックバックというシンプルな技術仕様は、 Web 的には大変よくできたものだった。 SPAM 耐性が低いのは一旦置いておこう。
本来、リンクする側からしかアプローチできないけれど、そのエントリに言及している記事はみんな読みたい。言及側から言及したことを知らせられればリンクできるのでは、というものがトラックバックだった。そしてその頃の感覚として、他人の記事にわざわざ言及するには、一定の価値ある資料とするべきであるという雰囲気があった。そしてそんなにコストを掛けるのであれば、自分の blog の記事にしたいというのは自然なことである。
トラバが言及になったから変わったとは言わない。ここは他エントリに起因する記事があったり、全記事を読むブクマカが居たりすることで成り立っている、特殊な環境だ。そこで使われるトラックバック機能は既に本来の意味から遠ざかっていたので、名前をそれらしいものにした方が良い。正直、外部トラックバックを受け付けなくした時点でスレッド型 BBS のようなものにした方が良かったと思うが、既に開発者がいないラボサービスにそこまでのコストは掛けられなかったのだろう。
現在でもたまにある改修は、新人に「はてな」を弄っていることを自覚させるための儀式なのかもしれない。
まとまらなかった！ PV があるうちは存続させてもいい程度なのだと思っていたけれど、ちょいちょい改修が入る（しかもエンバグする）。
あるフリーランスのプログラマーにバグ修正をやってもらってた。
フリーランス君はそんなふうに自分が仕事ができないのをなぜか他人のせいにしていた。
責任をなすりつける相手は顧客窓口を担当していたSEさんだった。
SEさんはバグ修正の優先度や修正スケジュールも決めていてフリーランス君に修正期限を指示していたのが気にくわなかったのだろう。
フリーランス君はSEさんに向かって「だったらSEさんがバグ修正すればいいでしょう!!」と逆ギレしたこともある。
遠くの席からそれを聞いていた僕はSEさんが反論する前に「それはフリーランス君の仕事でしょう!!」と大声を上げた。
そんな逆ギレを許していたらチームが無茶苦茶になってしまうから。
また、会議の時にフリーランス君が「元々のコードが悪いからそもそもバグ修正は無理なんですよ」と発言したこともあった。
その元々のコードは昔、SEさんが書いたもので要するに自分が仕事ができないのはSEさんのせいだと言いたいわけだ。
SEさんが「元々のコードが具体的にどう悪いのか説明してください。」と反論したら黙ったけど。
僕はそのやりとりを聞いてもうフリーランス君は切ろう、と決め後任のプログラマー探しを始めた。
そんな中、SEさんが顧客とメールで交渉しているメールスレッドを見て真っ青になった。
メールスレッドにフリーランス君が割って入って意味不明の主張をしていたからだ。
これには顧客が「窓口はSEさんのはずなのになぜアンタが割り込むのか!?」と強い言葉でフリーランス君に注意していた。
フリーランス君は顧客に注意されて意気消沈していたので「余計なことをせずに自分の仕事に集中してください」と言うに留めた。
しかし、しばらくしてフリーランス君はうちの会社に来なくなった。
フリーランス君とうちと直接契約してたわけじゃなく、ある会社の社員としてうちに来ていた。
その会社の社長に連絡を取ってもらっても、もう仕事を続けるのは難しいの一点張りとのことだった。
仕事を放り出してバックレたフリーランス君のケツ拭き作業が始まった。
そのケツ拭き作業の1つとして、チームメンバーへのヒアリングもした。
するとフリーランス君は他の協力会社の人達に「SEさんは言い方が優しくないから一緒に仕事ができない」と陰口を言ってまわっていたこともわかった。
「はあ?! 言い方が優しくないから一緒に仕事ができない?!」
頭がクラクラした。
そこまで腐っていたのか・・・、なぜもっと早くフリーランス君を切らなかったんだろうと激しく後悔した。
ケツ拭き作業が落ち着いてから、フリーランス君を仲介した会社の社長と話をした。
社長の口から出たのはなんと「おたくのSEさんの言い方が優しくないからフリーランス君が潰された」という耳を疑う内容だった。
「言い方が優しくない」
つまり、フリーランス君は仕事のバックレはSEさんのせいだと社長に言い訳したのだ。
その腐った言い訳を右から左に口にするだけの社長に僕は言った。
「すみませんでした、これから御社の社員には優しい言葉で接するように気をつけますよ。」
社長の顔色が変わった。自分の間違いに気がついたんだろうけどもう遅い。
https://anond.hatelabo.jp/20180609124213
不具合修正だけでアップデートするの嫌だったのでなにかないかと思っていたところ
自分がスターつけたブコメが一目でわかるよう色や印がつくと、自分が支持した意見や参考になった意見が一覧にできて、考えや参照情報が整理しやすくなると思う。あと、自己を客観視しやすい。賛同してくれる人いる？
それをそのまま実装した形です。
どこにマークするかはいろいろ試した結果、AddStarボタンの枠線に落ち着きました。目に付きやすいし同じブコメに意図せず複数回★付けるのを防ぐ意味で。色は黄色や青だと馴染んでしまうので赤です。
★自体にもマークするのはちょっとやりすぎかなぁと。うっかりデマにつられてしまって★消したいけど100個も200個も★付いてて探すの大変！ということはあるかもしれませんが。レアケースでしょう。
ちなみにinner_starというのは「★17★」みたいなやつです。HatenaStar.jsでそのように命名されてます。
使っているうちにこまごま見つかった不具合をちまちまと潰し、潰してはエンバグして、また潰し、とやってなんとか一段落しました。
不具合5は特に酷く、★フィルタ作成時に「色情報が入っていてそのままでは使えない」からこそaltでなくhrefから取得することにしたにもかかわらず、それをすっかり忘れてエンバグしてしまうのだから情けないこと頻り。忘れるのはわかりきっているので通常は当たり前でない処理にはコメントを入れて未来の自分に注意を促すわけです。今回は忘れることを忘れてしまってコメントを入れなかったのが敗因ですね。
mobile版含め落ち着いたので次は環境固有の不具合…と言いたいところですが報告のあったアドオンの組み合わせバグはどうしようもないかもしれないなと正直思ってます。まだ何も調べてませんが。うまく直れば「同一ユーザーの★をまとめる機能」と合わせて1.1.0をリリースしたい気持ち。お気持ちの表明。
或る趣味界隈で有名な大学教授が作ったオープンソースのプロジェクトがあって、ほとんど9割方完成されてたので（というか特段改めて更新する必要性も無いくらいの状態というか）、みんな便利に使ってたのだけど、その中になんかやけに意識高い人がいて、そのプロジェクトに少しだけ手を加えちゃった。
その人、ダウンロードされていく様を見て「自分が作ったソフトが普及するのは気持ちいい」「自分はこのプロジェクトに一番貢献している」って言ってた。
UI関係の変更だったのだけど、使ってみたらどこを弄ったのか知らないけどUI以外のところでエンバグが起こっているし、UIの変更っていっても今までのを使っていても別に問題は無い程度で特段便利ってわけでもなかった。
タイトルを見ると派生物っぽく正規のプロジェクト名のとなりに「z」とか書いてあったので、確かに派生した部分はその人が関与してるんだけど、「作った」って書いてあるとなんかモニョる。
駄目なプログラマはとにかく人に親切でない。この程度のデバッグならと思えるようなこともしない。金銭的な面だけじゃなくて、「ずっと担当しているプログラムに対してこの程度の手間なのに」と驚くようなことすら断ったり。
これはおそらく、デバッグをして見つかる不具合修正の費用対効果を計算できず、自分のメンツを重視するからだと思う。とあるプログラマにお願いを断られたこと（だいたいプログラマ個人の作業として30分もかからないこと）で、私は落胆し、数万円くらいのバイトを紹介するのをやめたことがある。数万円は曲がりなりにも派遣でプログラミングをしているプログラマにしてはたいしたことがない数字かもしれないが、それでも30分くらいの手間で、数万円のバイトを紹介してもらえるなら、悪くない投資のはずだが。
駄目なプログラマはとにかく無駄遣いをする。プリミティブな定数で済むところでも、かまわずにオブジェクトを生成する。メモリ少ないのにいいのか、と私が思うようなことでも、無駄なものに考えなしにメモリを使う。
駄目なプログラマはメモリを使わない。無駄遣いはするが、メモリは使わない。
うまくいえないが、メモリを使う勘所を意識していないのではないか。キャッシュを作ってメモリ上に保持すべき所で毎回 DB にアクセスし、効率的なキャッシュで DB アクセスを減らして高速化を行う事に気が回らない。
いわゆる memchached もそうだが、実績のあるライブラリなどを利用するための準備には時間とお金を惜しむ。そのことでより開発が楽になることを知らないからだ。
駄目なプログラマは周りを大切にしない。エンバグばかりする代わりに、同僚のテストは手伝わないし、私のようなプログラマにバグのパッチを送ったりは決してしない。
これは、その行為を無駄遣いだと思ってるのかな、と思ってたのだけど、そこまで合理的ではない。ただ周りの好きな人間を大切にしなくてもかまわないという気持ちのようだ。
駄目なプログラマは勉強をしない。とにかく本を読まない。講演を聴かない。人から教えてもらわない。
勉強したことが無駄にならないことをわかっていないからかもしれない。
駄目なプログラマは書くより語る。末端で参加しただけのプロジェクトの自慢話をしたりはしょっちゅうだ。そして自分のプログラムを書こうとしない。
プログラムを書いて学ぶメリットより、自分の話をするメリットのほうがでかいと思っているわけだ。ペラペラ自分の話ばっかりする駄目なプログラマは多い。
駄目なプログラマは挑戦をしない。やったことない言語や、苦手なことをあえてやってみようとしない。たとえば、勉強会なんかにいかない人たちだが、たまたまいったら流行っている言語をやってみようなどということはない。普通の人が面倒になって見てるだけだったりするのに加わるだけで、積極的に挑戦をしようと思わないことが多い。
失敗するリスクの低さと、経験のリターンの大きさを知らないのだろう。
駄目なプログラマは短期的にポジティブ、長期的にネガティブである。よく駄目なプログラマはネガティブな人が多いと言われるが、実際には、そうでもない。短期的には楽観的だったり不安に思わなかったりすることが多い。避けられるバグをなるべく避けようとする気持ちが少ない。
一方で、将来的に自分がどうなるか、などに関しては驚くほどネガティブである。長期的に悲観になっても無駄だということを知らない。逆に、短期的に「まあいいか」と楽観的になると、のちのちバグが発覚するのを知らないので、目の前のことに対しては真剣に考えない。
私が知っていることをまとめてみたが、実際にまとめてみると驚くほどシンプルである。だがこれを全部できてる人はなかなかいない。
駄目なプログラマになりたいと思っている人は、マネしてみるといいことがあるかもしれない。
※「貧乏人に大量に触れて初めて気づいた8の共通点」http://anond.hatelabo.jp/20110825204218 のプログラマ版です。
「素性の良い言語」に求められる性質は色々あるけど、一つは、モジュール同士を疎結合に保つための機能が備わっていることが挙げられる。つまり、「理解していない人」がエンバグしても、その影響範囲を最小限に留められるということ。これが、機能追加やデバッグ時にどれだけありがたい性質であるかは、多くのプログラマに同意してもらえると思う。
大規模なコードになるほど、一人の開発者から見てブラックボックスになる部分が増えるのは避けられないこ。Javaの言語機能を適切に使えば、手に負えないバグを埋め込むことを回避しやすくなる。
最近、中国人と仕事をする機会があって、文化の違いというかいろいろ見つけたことがあるので増田に書いてみる。
とにかく手を動かすことについては早い。割とボリュームのある（日本人の目で見て５人チーム１週間程度）仕様変更も、１日とか２日でリリースしてくる。
ここで注意したいのは、彼らはリリースしてくると言うところ。何度も目を疑ったのだけど、デバッグということをしてこない。
エンバグも日常的に起こる。デバグＡを済ませたらエンバグして、そのバグを直したらバグＡが再び出てくるというような。もちろん、バグ報告したあと直してくる速度もめちゃくちゃ速い。
しかし、手を動かしてくれないときは、とことん動かしてくれない。何度指示をしても「わかりました」という返事をきいても、指示がきちんと反映してくれない。この差はなんなんだ。
お金儲けに関しては天才的。常にいろいろなビジネス展開を考えていて、話をしてみるとあらゆるビジネスというか、商売のネタを披露してくれる。よくそこまで考えられるなーって思う。
彼らの特徴としては、確実に儲ける方法が好きというところ。リスクを取りたがらない。たとえば、売れるかどうかわからないけど、売れるとぼろもうけする物と、すでに売れている物の模倣をすることだったら、迷わず模倣を選ぶ。確実に儲かるから。
ビジネスに対する考え方は至ってシンプル。なので、いらなくなった人は問答無用で切られる。本当にあっさりしてて、さっきまで隣で談笑してた人が数時間後に解雇されてたなんて事もザラにある。
仕事をしていてリソースが不足してきたとき、日本だと現状で解決できないかを考え、その結果として効率化といった手法をとることがある。しかし彼らは「人を増やせばいい」の一択。中国にある本社の社員数は、半年で４倍になったという。
ただし、首切りは頻繁に行われるので、人の入れ替えはあり得ないほど激しい。誰でもできる仕事は、かわりはいくらでもいるということだ。
食べながら話をするというのも、ごく普通にありふれた風景。ランチミーティングなどになったら、クチャラーのオンパレードであの音が嫌いな人はたぶん卒倒するかも。１ヶ月もすれば慣れるけど。
もっとあるかなと思ったけど、まとめたらこんな感じになってしまった。
本当は詳しくいろいろ書きたいのだけど、所属などがばれてしまうといろいろ面倒なので今回はこの辺で。
