  |
はてなキーワード: 不具合とは
どうにもうちのエンジニアは自分たちの仕事を定期テストの問題を解くようなものだと思っている節がある
問題文に不備があれば「せんせー！ここ間違ってます！」「なんでまちがってるんですか！ここ重要なんですけど！」「次からはちゃんとしてくださいよ！」って野次ってくる感じ
発注書のミスとか、デザインが明らかに悪いとか、そういうのはエンジニアにもわかるし、やる必要を感じればエンジニアは問題提起とかはするだろう。
一方で、エンジニアの実装のぱっと見でわからない不具合は、営業にもデザイナーにも指摘できない。
エンジニアチーム内でレビューをすり抜けたら納品後に発覚しちゃうのが実態だろう。
けっきょくエンジニア視点だと、他チームに協力しても自分たちの仕事への見返りはなく、一方的な持ち出しになるばかりなので、出し渋るのも仕方ないと思う。
もし可能ならば、
そういう協力をしてあげることで、エンジニアも他チームと優しく向き合ってくれるようになるだろう。
まあ、色々な考えがあるだろう。
だが元PMとしてシステム開発を進める上で大切な事を書かせてほしい。
俺の場合、ゲーム開発が多かったからゲーム開発の場合で書くが、
→まず受託開発の場合、クライアントの言いなりになりすぎるな。
https://agilemanifesto.org/iso/ja/manifesto.html
→プロデューサーや営業の言ってくる事をそのまま仕様にしてはならない。
その際、出来ればプロデューサーや営業に投げるのではなく、同席させてもらうように交渉した方がいい。
ちゃんと発注元の「意図」「成し遂げたいこと」「ゴール」「納期や予算」について理解した上で確認や提案を行う必要がある。
もしプロデューサーや営業がその辺を理解していなかったらその時点でそのプロジェクトは確実に「炎上への道」へ突入するという覚悟を持つ事。
→仮に3Dのゲームを作る場合、2Dアーティスト、3Dアーティスト、アニメーター、エフェクトデザイナー、サウンドデザイナーなど担当は多岐に渡る。
2Dが遅れれば3Dが遅れ、3Dが遅れればアニメータが遅れる…という感じだ。
だからアセット制作一つ取り出してみてもデータの受け渡し期限は死守しなければならないし、
「このデザインはモデル化すると破綻する」とか「このモデルだと稼働部に問題がある」など修正依頼が頻繁に発生する。
その際も先のエンジニアの性格どうたら問題と似たような事が発生しかねない。
なので、アセット制作セクションの担当者間は如何にスムーズに連携と修正が行えるかを事前に話し合っておいた方が良いと思っている。
アートディレクターがその辺の管理まで出来ると理想だが、そうでない場合はアート関連に特化したPM的な存在がいた方が良いだろう。
→基本プランナーが作成した仕様書をもとにUI設計やグラフィックデザインを行うが、
画面に表示される内容が確定していないままデザインを進めてしまうと、後々「やっぱりこの表示追加したいです」
なので、仕様担当者とUIデザイナーは密に連携を取り進めていく必要がある。
あと、プランナーが「こういうデザインにしたい」とか「こういうレイアウトにしてください」とかはあまり指示しない方が良い、
と俺は思っている。
何故なら、UI設計は綿密に計算されていて、またUIデザインの基本メソッドのようなものが確立されている部分もあるので、
それに反する提案を素人はやらない方がいい。UIデザイナーの余計な仕事を増やすだけだ。
⚫︎エンジニアセクション
→さて、いよいよ本題っぽくなってきたな。
エンジニアセクションはこれまで書いてきたセクションの制作物を実際に実装する立場にある。
いざアセットやUI素材が来たところで「これは実装できないよ！！」っていう事は発生しやすい。
なので、仮アセットやモックの時点で「この仕様で問題ないか？」「このポリゴン数で同時にX体表示させて問題ないか？」など、
数値的なものもそうだ。
この画面にはアイテムを最大XX個表示させます、とか、パラメータの上限値はXXX,XXX,XXXです、それを超えたらこういう挙動になります、とか。
あとは「必殺技発動にはxっていう値を1000溜めると発動可能になります」みたいな仕様があった場合、後から
「やっぱり1000溜まる前にバトル終了しちゃうので500にしたいです」っていう事はよくある。あるある。
なので、仕様担当者とエンジニアは「どの値が可変で、どの値が不変で、どの値をプランナーで調整出来るようにするか」
みたいな事を綿密に練っておく必要がある。
UEのブループリントをプランナーがいじるケースも多いが、マスターデータ（エクセルなど）で管理出来た方が良いと俺は思う。
上記に挙げた各セクションのリーダーは随時エンジニアチームと協働していればどちらかがどちらかを憎んだりすることは減らせると思っている。
困るのは、そういった相談無しで「仕様これです、アセットこれです、あとは実装よろ！」みたいなのが開発後半になっていきなりやって来る事だ。
まあ、そんな極端な現場はないはず、、、と信じたいところだがどうだろう。
⚫︎QA（品質管理）セクション
→実は最終フェーズを担っているのはQAセクションである事を忘れてはならない。
QAは単にバグや不具合を発見するだけでなく、UXやゲームプレイ体験の改善案も提案してくる。
例えば「この仕様だとプレイヤーはこの理由で離脱するのでこう変えた方が良い」といった提案も出てくる。
それらを考えると、開発期間の1/6はQA期間に充てるのをお勧めする。
開発期間3年なら半年、1.5年なら3ヶ月は確保したい。
ここを疎かにすると全ての開発コストが無駄になる、と言っても過言ではない。
よくオンラインゲームで「緊急メンテです、資源回収します」的な事が発生するのはみんなも経験済みだと思うが、
そういうのは大体QAが甘い。
QAが甘いのは計画に問題があり、QA期間の大幅な短縮とかが絡んでいるとしか思えない。
QA期間が短縮されるのは、もうお分かりの通り、ここまでの開発が遅延したからだ。
さて、偉そうに書いてしまったが、正解は一つではない。
プロジェクトの数だけやり方はあるし、人の数だけやり方がある。
PMとしては計画の立て方とか進捗管理とかについて書くべきなのだろうが、その辺は要望があったら書くよ。
それに俺は、前職で無能無能散々言われてクビになった”元”PMなのであまり信用しない方が良い。
今は細々と個人開発やってる。上に書いたような事を1人で全部やってる感じかな。
・他セクションに最大限のリスペクトを忘れないこと
・同じセクションメンバーも一人一人違う人間だから、実力云々ではなくリスペクトし合うこと
・相手の言い分が気に入らなかったらそれは個人の「性格」や「人格」ではなく、双方の「アウトプットの内容」に問題があった、と考えること
作ったもの：https://chromewebstore.google.com/detail/kkgiinmhapeedibidnajommhlfhhjine
自分のブログにも書いた のですが、必要そうな人に届かなそうなので、増田にも書きます。
Chrome の URL バーに はてなからの通知を表示する「はてなのお知らせ（ Hatena::Notify ）」が、Manifest v3 に未対応のため無効化されてしまったので、代替となる Chrome拡張を作りました。
これ皆さんに聞きたいんですけど、デスクトップ通知って必要ですか？
私は「はてなのお知らせ」ではなぜかデスクトップ通知が動かなくて、別にそれでも困っていなかったので実装しなかったのですが、それを必要としてる人がどのくらいいるか知りたく⋯。よければ、デスクトップを必要か否かをブコメで教えて下さると助かります。🙏
というわけで、よければお使いください。
そして不具合と思しき点やフィードバック等あれば、ブコメか Twitter の @Cside_ へ教えてくれると助かります。
Windows10のときもギリギリのときはだいぶマシになってたからよかったけど
もう今年中にWindows11に移行しなきゃならないのに不具合ばっかりなのはやばいでしょ
この手のパソコンの大先生ってなんで全てOSのせいにしたがるんだろうなｗ
WDのSSDもあたかもWindows側が悪いように言ってたけどあれどう考えてもFWのバグが顕在化しただけじゃん
まともな方法でメモリアクセスしてなかったアプリケーションを動的にパッチあてて強引に動かしたり��てたのを当然と思ってるのほんとゴミ
いままでできてたことができなくなっておまけに不具合も追加するのはアップデートとはいわんのじゃ。— さらしる (@sarasiru) March 4, 2025
Spotifyは不具合を直す気はないしチャットでの問い合わせの品質もクソだし、何よりユーザーにコストを掛けさせていることに対して決して謝罪をしない。ユーザー体験は最悪に不愉快。不具合は勿論解決しない
Spotifyをブラウザから再生したところ、1日の初回に必ず音量MAXで再生され始めるというかなり不愉快な不具合に数日悩まされる
検索しても、アプリ版ではここの設定をいじれというのは出てくるが、ブラウザからのケースについてはあまり情報なし（この点だけは近年のGoogleの悪化に原因を帰すべきかもしれない）
重い腰を上げてSpotifyのチャットサポートにアクセスする この時点ではよくある現象なのだからすぐに解決するだろうと思っていた
自動応答に何回も「アプリのキャッシュをクリアしたか」などの質問をされ「アプリじゃなくてデスクトップPCから起動してるブラウザです」と応答することを数回繰り返し、リアルタイムチャット応答の有人窓口に繋がる
まず「力になります」的な一見頼もしいことを言うが、決して「ご迷惑をお掛けしております」のような謝罪はしない まあ名前もカプリハンとか言ってるし文化が違うんだろう
近年の国際経済情勢においてプレゼンスを低下させ続ける国にしかネイティヴスピーカーがいない言語でリアルタイムチャットに応答してくれる時点でありがたいというものだ
しかし一応有人のはずなのに応答が噛み合わないこと甚だしく、UX的には機械の自動応答とそこまで違わない 噛み合わないせいでこれは生成AIによる応答ではないんだろうなとうっすら思う 翻訳にChatGPTは使ってるかもだが
噛み合わないというのは「会話のログを読んで文脈状況は把握した上で解決のために尽力するぜ！」っつって来てるのに、「アプリはAndroidですか？それともパソコン？」と聞いてくることなど
やり取りが少し進展したら「これは難しいのでチームに聞いてくる」とか言って5分待たせたり、「すみません」の一言もないまま担当者が変わったり、一応答しただけでまた次の担当者にたらい回しにされたりする
最初の一回目たらい回しくらいまでは「まあFAQにあるようなレベルではない多少レアな事象なのかもしれないが、より詳しい人に繋ぐことで解決の道を探ってるのだろう」と思えたが、徐々に白けてくる
なんでここまでみんな揃いも揃って無責任なんだよ ユーザーに謝ったらこのオペレータ職は賞与減額されるシステムか？
如何だろうか まず「1.違うインターネットを接続してみる。」（「インターネット“を”接続」、LLMではあり得ない非ネイティブの日本語ありがてえな）は私のデスクトップPCを違う回線に持っていって接続するという意味か？を聞いた
「そうです」という回答
手間が掛かりすぎるしそもそもPCを繋がせてくれるような適切な環境の当てが思いつかない 「この手順省略していいか？」って聞いたんだけど、まあ今思うと先方は直す手立てを考えているとかではなく、体の良いお引き取り口実を探していただけのように思える
「これらを全部試しても結局問題が解決しなかった時に、メール等で今回やり取りしたチャット情報を引き継いで問い合わせを継続することは可能か？」を聞く 正直絶対解決しない気がしていたので
「このチャットフォームを閉じなければ継続することができます」と言明。
「はい」
そうして、「1.違うインターネットを接続してみる。」「4.他のデバイスを試す.」以外のを全て実行して、Spotifyに再ログインした結果、音量を下げた設定は記憶されておらずMAXになっていたままだった
当たり前だが、チャットページにアクセスしても問い合わせのログには繋がらなかった 平気で嘘を付くのはモラルがヤバいのかそういうマニュアルがあったのかだけは気になってる
今はSpotify Premiumの退会を健闘しているところ Apple Musicが第一候補だけどYouTube Musicってどうなの
Amazonからポストへの配達が完了したとの連絡があった。しかし、マンションの郵便受けを確認しても何も入っていない。鍵をかざしても宅配ボックスも何も反応しない。
メールを何度確認しても配達完了となっており、いよいよ噂の誤配というものが自分の身にも起きたことに気づく。
Amazonならこういう場合の対応慣れてるんだろうなと思っていたが、案の定すぐに「配達完了になっているのに届いていない」というオプションを見つけた。
「そうだよ、これこれ」と思いオプションを選ぶと、どうもよく分からない。
再配達依頼の電話番号は見つけたので、その電話番号に試しにかけてみて自動音声の言うままに追跡番号を入れたところ、「その番号は再配達を受け付けてません」と自動音声で言われガチャ切りされた。
「確かに配達済みになってるから再配達は受け付けてないよな」とは思いつつ、電話番号載せてるのはテメェじゃねえかと、この時点でだいぶ苛立ちが募ってきた。
そこから色々探した結果、お客様サポートの「サイトの不具合」からいくと人間と話せることが分かった。難易度高すぎるだろ、魔界村か。
オペレーターには比較的早く繋がったが、ここまでくるのに1時間は経っており、自分の声が苛立っていることに気がつき、自己嫌悪を感じた。
「違うんだ、俺はあなたにじゃなくて、質の悪い配達員を安く使い倒し、オペレーターと話させまいとするAmazonという仕組みに怒っているのだ」と言いたかったが、オペレーターはまるで自分がミスしたかのように申し訳なさそうな声で謝罪してくれた。
そこからは首尾よく進み、本当に受け取っていないことを証明する必要もなく、すぐに返金の手筈が整い、その点は良くも悪くも流石Amazonだと思った。
「受け取ってないことが本当だということを確認するコストだったり、配達員を教育するコストよりは結局これが安上がりなんだろうなー」とは思うものの、大量消費のシステムに自分が食い込まれてるような居心地の悪さを感じる出来事だった。
まず政策の失敗でそもそも過剰な物不足になっていたという認識を追加してくれ。そしてその場合政府はどうせざるをえないか考えてくれ。
181兆通貨発行したらインフレになりそうだが、可能性が低いなら根拠示してほしい
そんで、181兆の国債発行ならそこまでインフレ進んでいないように思えるし、円ドル為替は円が弱いというよりドルが強くなったって印象があるわけで
2024年国債発行181兆とか言ってるがそんな事実ないし、お前の印象とか知らんのだが。
インフレになるかどうかは需給バランスの問題なんで日本の生産余力や海外からの輸入余力次第としか言えねぇよ。いちおうデフレ・ギャップとかの指数あるが俺は信用しとらん。
俺の考えは根拠はないんだけど、181兆円通貨発行したらインフレするっしょ？国債とか関係なく不具合生じるんだからできないっしょ。その代わりに国債で資金調達してるんじゃねえのってことなの
自分の考え述べるのはいいが他人の話も聞いてくれ。さっきの国会質疑の引用見直してくれ。
いや関係あるだろ
ジンバブエドルの超インフレは貨幣発行しすぎたのが原因の一つじゃないんですか
181兆通貨発行したらインフレになりそうだが、可能性が低いなら根拠示してほしい
そんで、181兆の国債発行ならそこまでインフレ進んでいないように思えるし、円ドル為替は円が弱いというよりドルが強くなったって印象があるわけで
結論として何が言いたいかっていうと、国債発行と通貨発行は明確に物が違うんだから、国債＝借金って考えるなら、通貨発行すればよくねって理論はおかしくねって俺の主張に反対できるだけの論拠を示してくれって言ってるの
俺の考えは根拠はないんだけど、181兆円通貨発行したらインフレするっしょ？国債とか関係なく不具合生じるんだからできないっしょ。その代わりに国債で資金調達してるんじゃねえのってことなの
