nDiki : リスク
2018年6月7日 (木)
プロダクトの遅延コストの算出方法を考える
WSJF (重み付けされた最短の作業から着手)という手法を使い始めるにあたり遅延コストを算出方法を見直し中。
エッセンシャル スクラムでは遅延コストの出し方をいくつか紹介しています。その中の1つ「アジャイルソフトウェア要求」で提案している3つ要素の和として決める方法をまずは使おうと思っています。
アジャイルソフトウェア要求では「フィーチャーの優先順位付け」と「エピックの優先順位付け」のところでそのやり方が出てきますが、今はポートフォリオプランニングレベルで考えているのでエピックの方が考え方として近そう。
プロダクトについて
- ビジネス価値(BV): 収益・シェア・コスト削減・顧客の囲い込み向上についての相対的な価値。
- 時間価値(TV): 時間が経つとどの程度価値が下がるかの相対的な価値。大きい値は価値が急速に低下することを表し、小さい値は安定していることを表す。
- リスク低減/チャンス利用(RRV): 将来のプロダクトのリスクを低減する価値があるか、他のビジネスチャンスを活かす価値があるかの値。
をフィボナッチ数列の値で相対的に見積もります(アジャイルソフトウェア要求だと 1, 3, 5, 8, 13, 20, 40, 100 という等級を例として出しています)。
そして3つを足した
[ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]
を遅延コスト(CoD)とします。
正直なところ「金額」と「金額変化度合い」とをごっちゃに足しちゃう気持ち悪さがあってちょっとすっきりしない感じはあります。あと3要素それぞれで相対で決めていくとすると、特定の要素が大きめになって遅延コストを支配する可能性も出ちゃいそうだなと。
とりあえずやってまた考えるという感じかな。
2018年7月27日 (金)
プロジェクトでみんなをバスに乗せるために書いておく項目リスト
みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。
項目名を整理して決めておくと楽なのでちょっと書き出してみました。
コンセプトシート
比較的軽量にまとめる時。
- タイトル
- 概要 (What)
- 目標 (Goals)
- 背景と目的 (Why)
プロダクトプラン
プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。
- プロダクト名
- プロダクトビジョン
- 概要レベルのプロダクトバックログ
- プロダクトロードマップ
ポートフォリオバックログアイテム
ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。
プロダクトバックログアイテム
スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。
- プロダクトバックログアイテム名
- ユーザーストーリー(誰・概要と目標・背景と目的)
- 満足条件(あれば成果物を含む)
- サイズ
- レビュー方法
タスクチケット
ちょっとしたタスク。
- タスク名
- 概要
- (opt) 背景と目的 (概要で自明でない場合)
- (opt) 成果物/アクション (概要で自明でない場合)
- 完了条件
- 期日
プロジェクト憲章
- プロジェクト名
- 概要
- 目標
- 背景と目的
- 成果物
- 完了条件
- スコープ(含むもの・含まないもの)
- (opt) 依存するプロジェクト制約条件
- (opt) リスク
- (opt) スケジュール・期限
- (opt) 予算
- (opt) メンバ
備考
他には以下のような形式もあります。
- One Pager
- インセプションデッキ
- 製品要求仕様書 (PRD: Product Requirements Document)
- リーンキャンバス
[ プロジェクトマネジメント ]
2018年8月23日 (木)
違反投稿分類自動化と学習データを作れなくなる問題
ユーザー投稿ができるネットサービスの多くは違反投稿の対応が必須である。ここ数年機械学習を用いてテキストや画像を分類する環境が整ってきたため、違反投稿の判別にも適用が進んできている。人の負担が減ることはとても良いことだと思っているのだが、自動化を進めることで違反投稿対応スタッフを過度に削減することになるリスクも心の奥で感じている。
人力チェックから自動化へと切り替えるタイミングでは、教育されたスタッフによって分類された良質な学習データが使える。だが自動化のあとにスタッフを削減しすぎてしまうと、組織として違反投稿かどうかの判断する力が弱くなってしまい、将来判断基準を変更したり新しい基準での学習データを用意したりすることが難しくなってしまう。ノウハウが失われてしまうリスクが隠れているのである。
[ opinion ]
2019年2月15日 (金)
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% ルール
- 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 史と概論を語る前半。途中退室。
2019年8月13日 (火)
母の白内障の手術の説明を聞きに病院付き添い【日記】
今月下旬に予定している母の白内障の手術の説明が今日あるので、有給休暇を取り病院に付き添って一緒に話を聞いてきた。
午前中に銀座テラス → ソニーストア銀座で α6300 の清掃・点検サービスを依頼 → 銀座ロフトの「フジカラーのお店」(レトロなフォトスポットではなくなっていた) → 東京ミッドタウン日比谷のパークビューガーデンと銀座をぶらぶら。
そういえば以前から行きたいと思っていたムーショップはこの4月1日に「アルケミスト」に店名を変更したらしいので行きたいところリストから外した。
去年末に行ったら強風で閉鎖されていたパークビューガーデンは、日比谷公園・皇居周辺と眼前に緑が広がり空も開けている結構いいスポットでびっくり。写真を撮るにはちょっとガラスが邪魔だけれど、ここ気分転換にいいところだね。
銀座をぶらぶらしたあとは実家に寄り、母・妹と一緒に病院へ行って白内障の手術の説明を受けてきた。菌が入ると失明の恐れがあると言われて母が怯えたけど、それ以外は大きなリスクの説明はなかったので術後に気をつければという感じみたいだ(水晶体を取り除いた後の状況次第では1回では終わらない場合があるという説明はあった)。
右目は予定通り8月下旬に、左目は再発している逆さまつげの診察次第で予定通りか延期か決めるというスケジュールで。
帰りに病院のセブン-イレブンで就寝中にかける術後の保護メガネを買って実家に帰宅。
次回は手術立ち会いだ。
2019年9月30日 (月)
今日のさえずり: 近くのローソンに行ってフリスク ネオ買ってdポイント消費してきた。
2019年09月30日
- 07:59 空が絨毯のよう。 #渋谷 RICOH GR III #GR #GRIII #GR3 https://t.co/0EJoL64YBd
- 09:37 今週はやることいっぱいあるゾウ。 2019年9月30日 #朝の渋谷 DSC-RX0 #RX0 https://t.co/plYcB4oIc6
- 09:40 @yoshimot0 今日1日で 5GB 使おう。
- 17:45 鳩散歩。 #金王八幡宮 RICOH GR III #GR #GRIII #GR3 https://t.co/9inbP39oSq
- 22:05 『小説 天気の子』 p.112 に mixi が出てきてちょっと嬉しくなった。 http://bit.ly/2nRjbSp #天気の子 #天気の子展 https://t.co/cw8TstX3eZ
- 22:45 賑やかなような寂しげなような。 #金王八幡宮 RICOH GR III #GR #GRIII #GR3 https://t.co/IhY0ZSlqUF
- 22:50 2019年9月30日が失効日のdポイント(期間・用途限定)が310ポイントあることに今気付く。
- 23:25 @youclick0113 dショッピングなるほど! ローソン行っちゃいました!
- 23:31 近くのローソンに行ってフリスク ネオ買ってdポイント消費してきた。
2020年3月1日 (日)
家族で KeePass を使う
妻 KeePass を始める
妻がパスワード管理に困り始めていたのでパスワード管理ツールを勧めたところ、使いたいとのこと。今日使い方を説明しながら環境を整えてみた。選択したのは自分も長年使っている KeePass ファミリで、 MacBook Pro では KeePassXC を、スマートフォンでは Keepass2Android を使ってもらうことにした。
使い勝手を考えると 1Password や Bitwarden などが良いのかもしれないけれど、クラウド型のものは自分に何かあったあとに使い続けるのが難しくなる可能性がある(アカウント管理や支払いついて理解して対応するコストがかかるとか、サービス終了のリスクがあるとか)ので避けた。
パスワードデータベースファイルの同期は Google ドライブで。念の為自分の Google アカウントにも共有しておいてもらい、自分の MacBook Pro (の Time Machine) にもバックアップが取られるようにした。
今後家族でアカウント情報を共有する
自分1人だけで管理している家族にかかわるアカウントを共有したいと常々思っていた。今回妻が KeePass を使えるようになったので、家族関連パスワードデータベースファイルを作って今後共有していこうと考えている。
複数のパスワードデータベースファイルをまとめて開く
そうすると扱うパスワードデータベースファイルが複数になるので個別にアンロックが必要になり手間が増える。なにか便利な機能がないかなと思って調べたところ KeePassXC と Keepass2Android どちらも子データベースを自動的に開く機能が用意されていた。本家 KeePass 用プラグイン KeeAutoExec 互換機能っぽい。
メインのパスワードデータベースファイルの中に AutoOpen グループを作成しその中に「URL に子データベースのパス」「パスワードに子データベースのパスワード」をそれぞれ入力したエントリを作っておくと、そのデータベースファイルを開いた際に自動的に子データベースファイルもアンロックして開いてくれるのだ。これは便利!
自分の KeePass パスワードデータベースも Google ドライブに
今まで自分は Dropbox にパスワードデータベースファイルを置いていたけれど、これを機に Google ドライブに変更。同じストレージサービスにしておいた方がパスワードデータベースファイル間の相対パスがシンプルになるからというのがその理由。
Google ドライブなら「選択したアイテムを別のフォルダに追加 (Shift+Z)」を使って1つのフォルダにパスワードデータベースファイルを集めることができるので、全部ファイル名指定だけで済ませられて良いのだ。
2020年3月13日 (金)
ビックカメラで HDD を破壊してもらった
家に不要になった HDD が4台ある。廃棄したいと思いつつ、外付け接続用にケーブルか何かを買い中身を読み取れない形で消去するという作業が面倒で古いものは数年放置されている。そろそろ何とかしたい。
ビックカメラ HDD破壊サービス
量販店で有料で目の前で破壊してくれるサービスをやっているところがあるので利用してみることにした。渋谷に店舗があるところだと、ビックカメラも「HDD破壊サービス」を店頭でやっているとサイトにあったので、試しに1台もってビックカメラ渋谷東口店 5F サービスサポートに行ってみた。カウンターに HDD 破壊についての掲示があったので無駄足にならずに済みそうだ。
一番長かったのは順番待ちで、順番が来てしまえばあっという間。
HDD を見せて HDD 破壊希望を伝え、確認書類を読んで署名したらスタッフの方がカウンター奥にある機械で破壊してくれる。HDD を機械に入れボタンを押して穿孔という作業を向きを変えながら4回繰り返して終了。バリバリといった音も聞こえてこず静かであっけない。
穿孔状態を確認の上、 HDD は破片が出てくるからと袋に入れて返却してくれた(けっこうボロボロと細かい破片が出てくる)。あとは料金(1台1,020円)を払っておしまい。
もう少し安いと嬉しいけれど、破壊装置代の回収と人件費を考えるとまあこれぐらにはなるのかな。自分で物理破壊する手間と怪我のリスクなどを考えるとアリである。一気に何台も依頼すると結構な出費に感じてしまうので、不要になったタイミングでこまめに利用したい。
About Me
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker