大事なんだけど、合意をとる「何か」はちゃんと誰かが自信と責任をもって考えてほしいんだよな。それが正しい必要はないけど、状況の整理とそれに基づいた判断の根拠くらいは。
決められないからチームに相談することが適切な場合はあるけど、状況の整理が足りなかったり、単なる責任逃れだったりすることもあるんじゃないかな。
そんなことを Inspired を読みながら考えてた。
実家から送られてきた細竹をそろそろ処理せねばと思って一気にやりました。
1ロット目の新聞紙を開けたときに土みたいなのが入っていたのですがとくに気にしないで処理をはじめたら、最初の一本の一番外側の皮をむいたら芋虫状の何か(まだ生きてる)が出現し、気持ちを落ち着けるために暫く休憩をしました。
そこで気付いたんですよ。土みたいなやつは糞だったんですね…で、量的に1匹じゃないだろうなと思って念入りに調べながら皮をむいていたのですが、結果としてもう2本ほど穴の空いたあやしいやつがあったのでそのままゴミ箱行きにしました…
2ロット目なので安定してきた様子です pic.twitter.com/ZGaagVBkHI
— けんちゃんくんさん (@kenchan) May 23, 20152ロット目はだいぶ上手に、しかも早くやれるようになったのですが、このスキルが有効なのはおそらく年1回程度なんですよね…
で、さすがに自動化されてるだと思ったらやっぱりあったので共有いたします。めっちゃやりたい。
今回は、私がまとめ資料をつくってそれを30分くらいでざーっと見ながら気になったところをコメントしていく、後半で社内のコンテキストも含めたディスカッションをする、というような形で進めてみました。
自分含めて8人のプロダクトマネージャーっぽいロールの人やそういう動きが期待されている人があつまってわいわいできたのでよかったです。
前のデザインは モバイル フレンドリー テスト でモバイルフレンドリーではないと言われ続けていたので、Githubの Primer を使ってちょっとだけデザインを変更しました。
モバイルフレンドリー認定されたので満足です。ただ、Adsenseの広告が大変残念な感じになっているのでまた後日なんとかします…
仕事でそういう話をしていて、もやもやしたので考えを整理しておく。
ヒューマンエラーをシステムや仕組みによって防ぐといっても、全てのエラーが起きないようにするのは、網羅性とコストの面から不可能ではないかと思う。
つまり、ヒューマンエラーのリスク(原因となる作業の頻度と発生した場合の影響)と、それを仕組み化するコスト(構築と維持)を正しく評価した上で、費用対効果のよいものから対応していくことになる。
このあたりは 自動化するときに考えること - HsbtDiary(2015-05-03) で述べられている考え方にも繋がる。
ただ、これとは少し違うポイントとして「普通はそういうことはやらない」とか「注意すればいい」という思考があると考えている。
そういった考え方は、そっくりそのままそれを仕組み化すべき理由になる。
これらの思考はリスクとコストを正しく評価することを放棄しているのと、それが起きてしまったときにその言葉がそっくりそのまま「発生させた人」に返ってしまうのが問題である。
つまり、その人は「普通はやらないことをやってしまう」「注意力がない」というラベルづけされるかもしれないし、そうでなくても本人は罪悪感に苛まれてしまう。(もちろんチームメンバーはフォローするだろうが、仕組み化されてないのが悪くて私はまったく悪くないと言いきれる人はそうはいないのではないと思う)
つまり、仕組み化はデータやシステムを守るだけではなくて、ヒューマンを守るという目的もあるように感じる。
ヒューマンエラーを仕組み化で防ぐことを考えるときは、リスクとコストを客観的でかつ定量的に評価するのが重要で、そこに「普通は」とか「注意すれば」といった主観的で定性的な評価を含めるべきではないのではないだろうか。
災害発生時など在宅勤務せざるおえない状況でもスムーズに業務ができるように訓練する日でした。
いつもの通勤時間の間に洗濯したり布団干したりできるのは便利なので、通勤時間短くしたい欲が高まることに。
社内のとあるPOの人から「PO力高めたいんです！手伝ってください！」と言われたので、世間一般で言われているようなPOの経験なんて微塵もない私がなぜか勉強会をセッティングすることになりました。
POStudy 〜プロダクトオーナーシップ勉強会〜 のサイトや参加者の方々のブログとかを見て、まずは Inspired日本語版 | How To Create Products Customers Love を読みましょうということで、初回の今日は「はじめに」と1章の途中までを読みました。
本書では沢山のマネージャや責任者のようなロールが紹介されるのですが、自分達の組織だとその役割は誰がやっているんだろうという疑問や、必要だと思っているけど足りてない面などが明らかになってきて、開発チームの人と話しているだけでは見えないことが見えてくるのは面白いですね。
ただ、だいぶふんわりした感じになってしまったので、次回からは章毎に担当を決めて、まとめ資料をみながらディスカッションしていくというかんじで進めていこうと思っています。
2週間前に割れたNexus5を総武線に置き忘れたところ、本日無事回収できましたので知見を共有いたします。
【悲報】俺氏のNexus5、総武線を一人旅し、中野駅でのGPSの記録を最後に消息不明
— けんちゃんくんさん (@kenchan) April 23, 2015ロックは当然のことながら、必要であれば端末の暗号化やリモートでデータを消去できる仕組みを入れておきましょう。
ロックについては、古い記事ではありますが Androidのロックパターンの解読にFBIが投了！Googleに素直にアカウントとパスワードを聞く | あんどろいどスマート という話もあるので、利便性と強度を考えるとパターンロックが無難じゃないかなと思います。
Android デバイス マネージャー にアクセスして、端末の状態を確認しましょう。ネットワークに繋っていれば現在地がわかります。
ロックと消去は実際に行うかどうかは迷うところです。とくにロックは
という一長一短の機能ですので、実際に使うかどうかは迷うところではないでしょうか。
当然ですが、ロックや消去はネットワークに繋っていないと効果がありません。デバイスマネージャに甘えずに、十分な強度のロックと暗号化はしておいたほうがいいでしょう。
また、利用しているWebサービスの2FAをかたっぱしからOFFにして、重要なアプリケーションはパスワードの変更やセッションの切断などをやっておくとよいでしょう。
もちろん、会社にも忘れずに連絡しておきましょう。
グーグル先生や教えてgoo、知恵袋などによると、犯罪や悪用の恐れから、紛失した携帯電話を直接受けとるのは多少難易度が高いようです。
私の場合は忘れたのが電車の中とわかっていたので、JRの方に何度か連絡してみましたが当日中には見付からず、翌日以降は何回か電話してみましたが落とし物センターが混んでいてまったく繋がらなくて諦めムードでした。
そんななか、事件が起こりました。
【朗報】Nexus 5発見のお知らせ
— けんちゃんくんさん (@kenchan) May 3, 2015これはどういうことかというと
というルートで、SIMがささっている携帯電話が届けられた場合はほぼ確実に契約者に連絡がくるという仕組みらしいです。(電話だったりメールだったり書面だったりするようです)
ちなみに、Nexus 5には IIJmio のSIMを差していたのですが、IIJからメールが来たので3キャリアじゃなくても大丈夫なようです。
あとは、その連絡の中に保管されている場所と受取番号が記載されているので、そこに行けばOKです。電車に忘れた場合は飯田橋にある遺失物センターに集められるようですが、13時過ぎに行ったところ5人待ちで15分くらいで終わりました。
私の場合、最初にJRに電話して見付かってないことがわかった時点で、デバイスマネージャの位置情報がとれなくなっていたのでリモートで消去を実行していました。しかし、実は電源が切れていただけで、受け取ってから電源を入れてネットワークに繋がったタイミングで、持ち主の目の前で消去が始まるという衝撃的な結末が待っていました。
目の前で初期化が始まったようすです pic.twitter.com/zmMFSW7MNx
— けんちゃんくんさん (@kenchan) May 7, 2015前回は2/14だったので3ヶ月くらい。ちょうど1年前も行っていたらしい。
今月は諸事情により通勤中の意識が極めて低い状態にあったのでvimの本を再読したり、去年セールでの価格設定ミス(?)で運よく購入できたスレイヤーズ全巻を読んだりしていた。
