失敗学
/yuiseki/失敗学
いい記事
失敗からフィードバックを得てシステムを修復する方法が色々書かれている
人間のやる気や根性に頼っても失敗が改善されることはない
人間のやる気を出す事、までをシステムに組み込むことは可能だとも思うshokai.icon
最近感じているのは、
失敗はすぐ報告する
失敗の分析はすぐやる
システムエラーの修復もすぐやる
再発防止策の検討もすぐやる
再発防止策の100%の実施完了がちょっと遅れるのは許容した方が良いかな、と思っているshokai.icon
策のうちのいくつかはすぐできる。なのですぐやる
しかし理想を全て列挙すると、即日実施はできない物も出てくる
即日実施はできなくても、アイディアだけ書き出しておくと、それが別の失敗の防止にも役立つ事に気づける
一石二鳥
意義深い物に見えてきて、やる気が出る
エラー修復という活動も、失敗する可能性をもっている
効果的だが実施が大変な、根本的な失敗防止策は特にそうだと思う
人間の気合や集中力によらない防止策はシステムなので、その実装も気合でやると失敗する
ちょっとブレーキかけたほうがいい
どうするか
やる気を出すテクニックを使って、やり方と意義がクリアになるまで熟成させる
例
Scrapboxで新規projectを作った時、ユーザーのブラウザ言語環境毎に「はじめに」あるいは「Get started」というページが生成される
これは/templateからコピーされている
失敗
これの英語版の「Get started」がしばらく生成されていなかった
そして、その事にずっと気づかなかったshokai.icon
原因
別のスタッフがGet Startedというテンプレートページのタイトルを変更していた為だった
失敗の原因
そもそもタイトル変更したらダメ、という事がわからない
どういう仕組みで/templateからページがコピーされているのか、コード読まないとわからない
shokai.iconがいろんな所で「タイトル変更が自由、なんでも順不同」と言っているので、普通に考えてテンプレートのタイトルも変えても大丈夫に見える
テンプレートのコピーに失敗している事が、shokai.iconにエラー通知されていなかった
普通にScrapboxを使っているとなかなか気づかない機能だった
ブラウザの言語環境を英語にしないと再現できない
新規projectを作った時にしか動かない機能である
開発者が使わない機能は質が下がる
エラーが起きている事に苦情が来ない
過去に「Get started」を生成した事がある人しか、生成されなかった事に気づかないので、文句を誰も言わない
再発防止策
すぐできるもの
templateのコピーのしくみを説明する、文書化しておく
開発に使っているブラウザのうち、いくつかの言語設定を英語にしておく
ゆっくり実装しているもの
すぐ直すべきエラーを全て通知して、確実に読めるしくみ
これは改めて色々検討し直すと、他の問題にも使える事がわかった
HTTPリクエストに紐付いたエラーの通知は、Heroku + Logentries + Slackでかなりしっかりできる
HTTPリクエストに紐付かない、例えばSocket.IO等のエラーや、batch処理のエラーがきちんとできてない
失敗を共有するのは重要
失敗した人が責められない、等
すぐ分析してエラー修復する
しかしエラー修復行為自体がさらなる失敗につながる可能性もあるので、あせらずやる
例えば、上のエラー通知は、テキトーにやると滅茶苦茶うるさくて逆に誰も見なくなってしまうかもしれない