management担当サービスの品質を担保するというのが仕事の1つなので、不具合の分析などを行うことはよくある。ここでいう分析とは以下のことを指してる不具合がいつからいつまで発生していたかなぜ発生したかどのような対応をおこなったのかユーザにどのような案内をしたのか(ソーシャルゲームなので)どのようなお詫び(アイテム補填)をしたのかどうやったら再発しないようにするかこの辺の分析はある程度の経験やスキルが必要だと思っている。長文で書くよりも箇条書きにしようとか、時系列で書くとかという感じでやっているので、まぁ得意不得意を補完してていいかなーとは思える。今回のメインは「なぜ不具合が発生したか」というところ。基本全員日々の作業に追われているし、嫌な過去は見たくないものなのであまり調べたがらない。みんな不都合な過去をなかったことにしたいからソシャゲやってる会社はダメだと叩かれるが、ある程度エンジニア(特にSIer)をやっていると「なぜを3回繰り返せ」というありがたい教えを聞かされるはずだ。自分は新卒2年目で叩きこまれた。Web業界にきてだいぶ年数が経つが、若い時に叩きこまれたことは習慣(悪いものは呪いという)のようになるので癖で調べてしまう。チームが必要以上に不具合に敏感になりすぎてる気がする。敏感になりすぎている人と鈍感なままな人がいるというのが正確な表現もちろん不具合はないほうがいい。不具合を起こして誰も幸せにならないからだ。みんな可能なかぎりゼロにすることを心がけてる。作ってる人みんなで触ってみてる場も儲けてるし、QAテストも時間かけてる。ユーザへの影響がほとんどないものはさっさと直せばいいし、そこをいちいち分析しても大した答えは出てこないと思う。変に敏感になり過ぎててなんか硬直してる(動きが遅い)組織になってきてる気がする。拡張機能とRubyMineプラグインとか転職しました。CodeDeployで遊んでみた会社でCodeDeployを使ってたけど、使ったことなかったので遊ん...2015-11-15ロードス島戦記に学ぶ技術的負債の返し方1年前にいたプロジェクトに戻ってきて3週間ほど経過しました。10twitterはてなブログをはじめよう!hs_hachiさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。