nDiki : リスク

ノートン セキュリティ プレミアムを MacBook Pro と Windows 7 BOX と Xperia Z5 に

使っている Norton Internet Security の有効期間が切れたので先日注文して届いていたノートン セキュリティ プレミアムのプロダクトキーを入力して延長しました。

OS X と Windows

MacBook Pro での Norton Internet Security はとりあえず最近暴走していません(以前暴走気味だったので一時期アンインストールしていた)。Windows 7 BOX は引き続きという感じ。OS X 用だと要求されないノートン アカウントの入力を要求されるのがちょっと面倒です。

Android

また今回は初めて Android アプリのノートン モバイルセキュリティを使ってみることにしました。

今はドコモ あんしんスキャンを使っているのですが「最新の状態でご利用いただけない可能性があります。」という日に何度も出てうざくて仕方がないアプリなのです。

通知から先に進むと「バックグラウンドでの接続を許可するため、タップして次の画面で「はい」を押してください。」 となり「電池の最適化を無視しますか?」というダイアログが出るのですが、ここで無視しても、また何度も通知がくるのです。 Android デバイスでのアプリの更新頻度やリスクを考えるとそんなにバッテリを使われなくないのですがそれが許されないアプリです。

さてノートン モバイルセキュリティを入れてみたところアプリアドバイザーが

• Instagram (バックグラウンドデータの使用状況が高レベル)
• QRコードスキャナー (バックグラウンドでのバッテリ消費量が高レベル)

を高危険度として、また

• LINE (バックグラウンドデータの使用状況が中レベル)
• Amazon (バックグラウンドデータの使用状況が中レベル)
• Remember The Milk (共有される個人データ)

中危険度としてレポートしてきました。

共有される個人データの項目以外は、セキュリティとは直接関係ない感じ。機能のデラックス感の演出な気はします。でも参考にはなりますね。 Instagram はあまり使っていないのにフォローを勧める通知が定期的に出てうざいと思っていたのでこれを機会にサブ端末に移してもいいかな。QRコードスキャナーはちょっと意外。これもめったに使わないので考えた方が良さそうです。

今日のさえずり: 個人的には「ガーランド」といえば「メガゾーン23」なんですけどね

2017年01月18日

• 21:00 「リスクや間違いを快く受け入れる」 / “「検討」は無駄である - リスクや間違いを快く受け入れる第２の習慣 - メソッド屋のブログ” http://bit.ly/2jrDF0c
• 21:02 個人的には「ガーランド」といえば「メガゾーン23」なんですけどね。

今日のさえずり: ちょっと遠回りの道の方がウンコリスクが小さいことに気がついた

2017年06月23日

• 09:20 日曜日から始めた(ラジオじゃない)ラジオ体操6日間続いている。
• 21:05 RT @nanohanakoya: オーダーいただいたポシェットが完成しました(*^^*) ファスナー部分にかぶせをつけ、肩ベルトは長さが調整できるショルダーベルトにしました。 お世話になっている方のお孫さんへのプレゼントだそうです。気に入っていただけますように❤️ https…
• 21:36 ちょっと遠回りの道の方がウンコリスクが小さいことに気がついた。

今日のさえずり: ニポポと言えば「北海道連鎖殺人 オホーツクに消ゆ」

2017年07月12日

• 05:01 情報に接触する機会について。 / “ノイズをすべて取り除こうとするのではなく、興味ある情報を受け取れないリスクを恐れよ。 - まなめはうす” http://bit.ly/2u7Hk8l
• 05:02 RT @nanohanakoya: 【★販売中★】レッスンバッグ～お花たちのおしゃべり～、minneにて販売中です(*^^*)お花がいっぱいの可愛らしいデザインにのバッグです。 http://minne.com/items/9495246 http://minne.com/items/10018183 ht…
• 09:28 宇治市の今の気温を通知してくれる Google。
• 09:45 後ろの人と赤 T シャツかぶった。
• 10:46 ニポポと言えば「北海道連鎖殺人 オホーツクに消ゆ」
• 17:33 炊飯器が壊れたらしい。アイロン → 扇風機 → 炊飯器という流れ。
• 19:49 炊飯器を見にきてる。 (@ ビックカメラ 渋谷東口店 in 渋谷区, 東京都) https://www.swarmapp.com/c/eJvIGnKnX1E
• 19:59 炊飯器、地味に高いぞ。
• 20:25 RT @tokudamasashi: もう10数年前から言っているけど、【PR】ではなく【AD】か【広告】にして欲しいんやけどね
• 21:50 Fire HD 8 届いていたのでセットアップ中。

WSJF (重み付けされた最短の作業から着手)という手法を使い始める

昨年11月から始めたポートフォリオプランニングでは、いったん各プロダクトについて

• 遅延コスト: 小・中・大・最大
• 期間: S・M・L・XL

とざっくりと見積もって優先順位決めをしていました。ライフサイクル収益最大化観点で「遅延コストが大きいもの」「期間が短いもの」優先として優先順位を決めていくことになるのですが、これだと両方異なる場合は単純に比較ができません。プランニングチームが慣れてきたので、そろそろ WSJF (Weighted Shortest Job First 重み付けされた最短の作業から着手)で考えていくことにしました。

「アジャイルソフトウェア要求」を参考に遅延コストと期間はフィボナッチ数による相対評価にすることにして、既存の見積もり記号にえいやと数値を割り当てて

 WSFJ値 = 遅延コスト/期間

を計算できるようにしてみました。

• 記号とフィボナッチ数のマッピングが「えいや」という感じ。
• 遅延コストの3要素「ユーザー - ビジネス価値」「時間価値」「リスク削減/機会可能性価値」を理解しきっていなくてうまく分解できていない。

という状態なので学習しながらリファインメントしていく感じにします(遅延コストの3要素毎にそれぞれ相対評価していくのはちょっと大変そうではあります)。

プランニングチームメンバからは「そこに時間をかけても」という声も出ましたが「見積もりの話し合い過程での気付き」と「社内政治の排除(記事)」と得られるメリットが大きいので、うまく取り入れていきたいなと思ってます。

プロダクトの遅延コストの算出方法を考える

WSJF (重み付けされた最短の作業から着手)という手法を使い始めるにあたり遅延コストを算出方法を見直し中。

エッセンシャル スクラムでは遅延コストの出し方をいくつか紹介しています。その中の1つ「アジャイルソフトウェア要求」で提案している3つ要素の和として決める方法をまずは使おうと思っています。

アジャイルソフトウェア要求では「フィーチャーの優先順位付け」と「エピックの優先順位付け」のところでそのやり方が出てきますが、今はポートフォリオプランニングレベルで考えているのでエピックの方が考え方として近そう。

プロダクトについて

• ビジネス価値(BV): 収益・シェア・コスト削減・顧客の囲い込み向上についての相対的な価値。
• 時間価値(TV): 時間が経つとどの程度価値が下がるかの相対的な価値。大きい値は価値が急速に低下することを表し、小さい値は安定していることを表す。
• リスク低減/チャンス利用(RRV): 将来のプロダクトのリスクを低減する価値があるか、他のビジネスチャンスを活かす価値があるかの値。

をフィボナッチ数列の値で相対的に見積もります(アジャイルソフトウェア要求だと 1, 3, 5, 8, 13, 20, 40, 100 という等級を例として出しています)。

そして3つを足した

 [ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]

を遅延コスト(CoD)とします。

正直なところ「金額」と「金額変化度合い」とをごっちゃに足しちゃう気持ち悪さがあってちょっとすっきりしない感じはあります。あと3要素それぞれで相対で決めていくとすると、特定の要素が大きめになって遅延コストを支配する可能性も出ちゃいそうだなと。

とりあえずやってまた考えるという感じかな。

• アジャイルソフトウェア要求

プロジェクトでみんなをバスに乗せるために書いておく項目リスト

みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。

項目名を整理して決めておくと楽なのでちょっと書き出してみました。

コンセプトシート

比較的軽量にまとめる時。

• タイトル
• 概要 (What)
• 目標 (Goals)
• 背景と目的 (Why)

プロダクトプラン

プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトビジョン
  • 概要
  • 目標
  • 背景と目的
  • 成果物
  • 完了条件
  • スコープ(含むの・含まないもの)
  • (opt) 依存するプロジェクト・制約条件
  • (opt) リスク
  • (opt) 予算
  • (opt) メンバ
• 概要レベルのプロダクトバックログ
• プロダクトロードマップ

ポートフォリオバックログアイテム

ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトプラン
• 期間
• 遅延コスト(ビジネス価値・時間価値・リスク軽減/チャンスと利用)
• WSJF

プロダクトバックログアイテム

スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。

• プロダクトバックログアイテム名
• ユーザーストーリー(誰・概要と目標・背景と目的)
• 満足条件(あれば成果物を含む)
• サイズ
• レビュー方法

タスクチケット

ちょっとしたタスク。

• タスク名
• 概要
• (opt) 背景と目的 (概要で自明でない場合)
• (opt) 成果物/アクション (概要で自明でない場合)
• 完了条件
• 期日

プロジェクト憲章

• プロジェクト名
• 概要
• 目標
• 背景と目的
• 成果物
• 完了条件
• スコープ(含むもの・含まないもの)
• (opt) 依存するプロジェクト制約条件
• (opt) リスク
• (opt) スケジュール・期限
• (opt) 予算
• (opt) メンバ

備考

他には以下のような形式もあります。

• One Pager
• インセプションデッキ
• 製品要求仕様書 (PRD: Product Requirements Document)
• リーンキャンバス

[ プロジェクトマネジメント ]

違反投稿分類自動化と学習データを作れなくなる問題

ユーザー投稿ができるネットサービスの多くは違反投稿の対応が必須である。ここ数年機械学習を用いてテキストや画像を分類する環境が整ってきたため、違反投稿の判別にも適用が進んできている。人の負担が減ることはとても良いことだと思っているのだが、自動化を進めることで違反投稿対応スタッフを過度に削減することになるリスクも心の奥で感じている。

人力チェックから自動化へと切り替えるタイミングでは、教育されたスタッフによって分類された良質な学習データが使える。だが自動化のあとにスタッフを削減しすぎてしまうと、組織として違反投稿かどうかの判断する力が弱くなってしまい、将来判断基準を変更したり新しい基準での学習データを用意したりすることが難しくなってしまう。ノウハウが失われてしまうリスクが隠れているのである。

[ opinion ]

Developers Summit 2019 2日目 #devsumi

昨日に続き本日も Developers Summit 2019 参加。今日は寒い一日だったのか、途中窓の外に雪が舞う時間もあった。

昨日参加証の読み取り率が低かったので受付で再発行していただいた。

今日はコーヒー確保できず。今度来る時はやはり何か買ってこよう。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【15-D-1】 プロダクトマネージャーという生き方

楽天株式会社 熊谷亘太郎氏

プロダクトマネージャー・カンファレンス 2018 1日目でもトークをお伺いした熊谷氏。今回も発表の骨子は同じだったので、今回は復習となった。

メモ

• 楽天トラベルでのプロダクトマネージャーと開発マネージャーの担当領域
  • 技術仕様やリスクマネジメント、組織関連はなどは開発マネージャー側。
• Positive (問題は解決できるという態度)

Enjoy your work!

11:05～11:50 【15-B-2】 メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと

ヤフー株式会社 山本学(@yamamoto_manabu)氏

Developers Summit 2016 1日目 で myThings の話をされていた山本氏。今回はマネージャーについて知ってもらいたいという内容で、マネージャー予備軍が響く層であろうという感じのセッション。

12:10～12:40 【15-E-3】 Entertainment x Tech～多くのアーティストとファンを繋ぐ技術と組織～

エイベックス株式会社 山田真一氏

• 年約250の新規アーティストサイト、現時点で約500を運営。クラウドシフトはステークホルダーが多く順番に。
• 予期しないバーストトラフィック
• アーキテクチャは社内アーキテクトで、開発は外部パートナーがエイベックスとしての理想の姿。

アウトソーシング中心での体制構築についての取り組みのセッション。「研修に行かせる」「身に付けさせる」のような表現をみると、トップダウンが強めの雰囲気なのかな?

13:05～13:50 【15-A-4】 3周年に突入するAbemaTVの挑戦と苦悩

株式会社サイバーエージェント 山中勇成(@toriimiyukki)氏

GCP 含めバックエンドで使っているものを順番に紹介していくセッション。浅く全部紹介する感じなので全体的に知りたかった人向けのセッションだ。

14:10～14:55 【15-B-5】 Site Reliability Engineering at Google

グーグル・クラウド・ジャパン合同会社 中井悦司(@enakai00)氏

流れるようなトークに酔いしれてしまうセッション。

• 50% ルール
  • 50% 以下で運用業務、50%以上をシステム安定化に関わるプロジェクト活動にあてる。
  • SRE(優秀なソフトウェアエンジニア)が Burnout して退職することを避ける。
• Toil の削減
• 生涯対応では問題解決を最優先。「他人を頼ること」をスキル不足と認識しない文化。
• Postmortem (障害ふりかえり)は Google ドキュメントを使っている。全エンジニアに共有されている。

(Google の) SRE についてちょっとではあるが理解が進んだ。目的がすべて明確で、それに対して合理的に取り組んでいるかのようで改めてすごいなと。

15:15～16:00 【15-A-6】 プロダクトをGrowthさせるデータ駆動戦略の基礎知識～DMM.comにおけるユーザーレビュー基盤のKPIツリー公開～

合同会社DMM.com 石垣雅人(@i35_267)氏

データ駆動戦略で成長させていくという話。今回はユーザーレビュー機能に関して。

既にあるものを少しずつ伸ばしていくことにフォーカスしている状況なら、施策に対する予測がしやすいので良いよねというところ。

16:20～17:05 【15-E-7】 セキュアな環境でDevOpsを実現する厳選ツール

マクニカネットワークス株式会社 根本竜也氏 株式会社セガゲームス 上田展生氏

前半は厳選ツール = GitHub Enterprise (GHE) (上田氏)。3年前はまだ Subversion を使っていた。そこから GHE と CircleCI Enterprise を導入していったという話。ゲーム会社だけれど Web 企業とは距離感のある企業風土を感じた。

根本氏は商材紹介。営業っぽい感じになってきたので退室。

17:25～18:10 【15-A-8】 エンジニア人生と定年退職、人生100年時代のエンジニアの生き方

東京大学大学院 よしおかひろたか(@hyoshiok)氏

よしおか氏視点を交えつつ IT 史と概論を語る前半。途中退室。

自分用に週次事業報告を作っておくことにする

もう少しスマートに月次事業報告をまとめられるようにしたいなと思い、自分用にメモレベルでやったこと・今後やること・課題とリスクなどを毎週まとめておくことにした。

今までは月末月初にデイリーノートなどからまとめていたけれど、週次でまとめておいた方が抜けなくふりかえられて良いかなと。