nDiki : 用語
用語 - term
2017年1月29日 (日)
nNote 始めました
永続的に残しておくほどではないちょっとしたノートを置いておくスペースとして nNote を始めることにしました。
nDiki と同じく自作の DiKicker を使用しています。
Medium であったり note であったりその他の Blog サービスであったりと「何か」を書いて公開しておけるサービスを触ってみるたびに「この nDiki とは別に書くとしたら何だろう? 何を書きたいんだろう?」と考えを巡らせていました。
この nDiki は長く続けてきた中で
- 永続的に残すことを前提にきちんとした URL (記事 ID) にする。
- 誤読されないように、ある程度自分なりに推敲する。
- AutomaticLink のために正確な用語で書く。
- フィードが拾われて消費されることを前提に、きちんと書けてから公開する。
といった縛りが自分の中にできてきているので、もっと自由なスペースが自分は欲しいのではと思えてきました。
- 必要が無くなったら 404 を恐れずさくっと消して良い。
- まだ自分としてこうだという結論に至っていない考えだったり何かの断片だったりを書いて良い。
- 最初から用語の正確性を追わなくて良い。
- 頻繁に更新して良い。
そういったノートを書き留めておく場所が欲しいんだなと。
そのためのサービス・プラットフォームで何がいいかと考えると、やはりテキストファイルでさっと新規作成・再編集をしてサーバに同期して公開・更新できるものがいいなぁという結論に至って、結局欲しいと思って自作して使っているこれ (DiKicker) じゃないですかと。日付有りノート中心になってしまいますが、まあいいかなと。
ということでさくっと設定だけ増やして nNote を立てるに至りました。
[ ノート・日記はテキストファイルに ]
2017年12月14日 (木)
チームで使う共通の言語を持つ
ストラテジーグループという新しい3人チームでプロセス作りをしています。
3人のうち2人は「エッセンシャル スクラム」を読んでいて例えば「経済的フィルター」と言えばアレのことねとなるのですが、もう1人には今は通じません。「エッセンシャル スクラム」を読んでいないのが悪い、あるいは「エッセンシャル スクラム」用語で話す2人が悪いという話ではなく、同じ言語を共有していると楽だし誤解が無くていいよねという話になりました。
アジャイルサムライでは
11.4 プロジェクトで使う言葉を共有する (pp.228-229)
で説明されていますね(原著だと Create and Share a Common Domain Language)。
そういえば以前部署で「エッセンシャル スクラムを読む会」を続けているうちに例えば PBI で話が通じるようになったりして楽になったなと感じました。
プロセスについてでもプロダクトについてでも、共通の言語をもつ(作る)というのは大切だなとあらためて感じた次第です。
[ opinion ] [ Naney の行動原則 ]
2018年1月30日 (火)
2018年8月14日 (火)
mixi 関連用語 #nNote
- アレックス
- 足あと
- イイネ！
- 数友
- 株式会社ミクシィ
- 管理人 (コミュニティの)
- このURLのページは存在しません
- こんにちはこんにちは！！
- サンシャイン牧場
- データがありません
- ナリミク
- マイミクシィ
- mikly
- mixiアプリ
- mixi運営事務局
- mixiゲーム
- mixiコミュニティ
- mixiコラボ スマゲー
- mixiコレクション (ミクコレ)
- mixiサポートフォーラム
- mixi Touch
- mixiチェック
- mixiチェックイン
- mixi伝言板
- mixi動画
- mixi同級生
- mixi同僚ネットワーク
- mixiフォト
- mixiフォトブック
- mixiプレミアム
- mixiページ
- mixiページアプリ
- mixiボイス(つぶやき)
- mixi訪問者
- mixi日記
- mixiニュース
- mixiモバイル
- mixiメッセージ
- mixiモール
- mixiレビュー
- レイモンド
2018年9月26日 (水)
2018年09月26日(水)の #nNote
用語
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」での訳語
- 未処理項目 = backlog
- キュー = queue
2019年5月30日 (木)
OKR #nNote
四半期 OKR サイクル
- 期初4〜6週間前: [幹部] 組織 OKR 検討開始 (第1四半期 OKR 設定時は年間計画も)。(↓組織 OKR 設定)
- 期初2週間前: [幹部] 組織 OKR 完成・共有。
- 期初: [チーム] チーム OKR 完成・共有。
- 期初1週間後: [コントリビューター] コントリビューター OKR 完成・共有。
- 期中: [コントリビューター] コントリビューターが進捗を測定・共有・定期的にマネージャーに報告・評価。
- 期末前: [コントリビューター] OKR 採点・評価。
組織 OKR 設定
- ミッション・ビジョン・戦略をもとに目標をピックアップする。
- 圧倒的に事業に価値をもたらす3〜5個の目標を選ぶ。
- OKR にふさわしい目標の形にする。 (↓チェックリスト)
- それぞれ主要な結果を設定する。 (↓チェックリスト)
- スプレッドシートに入力する。
決めるにあたり「紙に書いて発表する」などの方法を活用する。
四半期 OKR 設定チェックリスト
- [ ] 3〜5項目程度である。
- [ ] トップダウン目標とボトムアップ目標が半々ぐらいである(組織の階層を飛び越えてよい)。
- [ ] コミットする目標(100%達成する)と野心的目標が区別できている。
- [ ] 通常業務を含んでいない。
- [ ] やることリスト・To Do リストになっていない。
- [ ] 斬新的 OKR ではなく飛躍的 OKR である。
目標(O)設定チェックリスト
- [ ] 「何を」達成すべきかが書かれている。到達点や状態を示す表現になっている。
- [ ] 重要である。達成によって事業に価値をもたらす。
- [ ] 野心的である(困難で達成できない可能性もある)。「続ける」「維持する」「継続する」は NG。 (野心的 OKR の場合)
- [ ] 現実的である。成功の可能性がある。
- [ ] 達成されたか曖昧さなく客観的に評価できる。
- [ ] 簡潔である。1行に収まっている。
数値目標を含んでも良い。
主要な結果(KR)設定チェックリスト
- [ ] 目標を「どのように」達成すべきかが書かれている。行動ではなく成果が書かれている。「相談」「支援」「分析」「参加」「評価」は行動なので NG。
- [ ] 1つの目標(O)に対し3つ程度である(5つ以下である)。
- [ ] 曖昧さがなく、測定可能である。
- [ ] すべての主要な結果(KR)を完了すれば目標が達成される。
- [ ] 質的な「主要な結果」が含まれている。
- [ ] 量的な「主要な結果」が含まれている。
OKR 用語
- 野心的 OKR (Aspirational OKRs)
- コミットする OKR (Committed OKRs)
- 組織の OKR (organizational OKRs)
- チームの OKR (team OKRs)
- 個人の OKR (individual OKRs)
- ウィン・セッション (wins session)
参考
- Measure What Matters
- OKR(オーケーアール) 及川卓也氏監修。
- 原題: Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results
Web ページ
[ OKR ノート ]
2019年11月12日 (火)
プロダクトマネージャーカンファレンス 2019 1日目 #pmconfjp
今日から2日間ベルサール渋谷ファーストでプロダクトマネージャーカンファレンス 2019。
去年に引き続きの参加である。
今日のキーワードは「feature team ではなく真の product team を」「プロダクトビジョン」「信頼(trust)」。
以下タイトルは公式サイト掲載のものより。
10:00 - 10:10 [MainRoom] Welcome Talk
横道稔氏。
10:15 - 11:05 [MainRoom] ORDINARY PEOPLE, EXTRAORDINARY RESULTS
Silicon Valley Product Group Partner and Founder / Inspired 著者 Marty Cagan 氏
与えられた機能を作るだけの feature team ではなく、真の product team を作り信頼し、プロダクトマネージャーは本当のプロダクトマネージャーの仕事をしようという話。
feature team をそのまま product team に成長させて信頼していくことができるのか、それとも優れたメンバで優れた product team を作っているからこそ信頼できるのか。
- Product Discovery が重要。
- feature team (残念) と真の product team
- なぜ empowered product team にしないか → チームを信頼していないから。そういうチームの PM は本当の PM の仕事をしていない。
- リーダーシップの役割
- Product Vision (チームが同じ方向を向く。働く魅力になる。3〜5年/10年)
- Product Strategy(Plan)
- Product Principles
- Product Priorities
- Product Evangelism
- マネジメントの役割
- 人のマネジメントはプロダクトマネージャー(PM)の役割ではない。
- Staffing (強い人材を雇用する)
- Coaching (能力を押し上げる)
- Objectives
- 信頼
- 革新はエンジニアから生まれる。真の product team が重要。
- feature team から移行するには PM は自分の真の仕事をする。成果に責任をもつ。
11:15 - 12:00 [MainRoom] Special Session
TransferWise Head of Product Kaarel Kuddu 氏
- speed
- customer focus
- autonomous teams
- 決定権をもつチーム。
- Autonomy = responsibility
前のセッションに続きここでも、能力の高いメンバによる顧客のことを理解し考えて決定し実行できる優れたチームに決定権と成果に対する説明責任を与え信頼するという話が印象に残った。
ここでいっている責任をもつというものが何か指しているかが気になるところ。
13:00 - 13:30 [MainRoom] LINEにおけるお金とユーザーのジレンマ
LINE株式会社執行役員 二木 祥平 氏
「LINE公式アカウント」「LINE Ads Platform」が現在の担当プロダクトの二木氏のセッション。 「LINE(株式会社)では」 PM が何をしているかをふわっとまとめた話。ロジカルな構造や用語使いなどでしっくりこないところがあるけれど、生の声という意味で興味深く聞けた。
13:50 - 14:10 [MainRoom] PMにおけるストーリーテリング
freee株式会社 執行役員 プロダクトマネージャー 岡田 悠 氏
バックログの縮小均衡 → プロダクトビジョンが必要 → プロダクトビジョンが機能しなかった → ストーリーテリング。
「静的なビジョンを、動的なストーリーへ深堀ること」
セッション自体がストーリーがあるかのようで惹き込まれて響いててきてさすがだなと感じた。
「シャープに本質だけを抜き出した表現にしようとする」あるいは「そもそも事実を書き並べる以上の文章をなかなか書けない」のでつい端的な文章で済ませがちだけれど、やはり人を動かすにはストーリーも大切だなと思うことができた。
14:20 - 14:40 [MainRoom] “失敗事例で学ぶ” 失敗しないプロダクトマネジメント - PMの必須スキルと、自走する組織のつくりかた -
エン・ジャパン株式会社 デジタルプロダクト開発本部 部長 / プロダクトマネージャー 岡田 康豊 氏
スキルを明確化・指標化することで改善が動き出すというのは、プロダクトと同じで PM に馴染みやすいのかも。
今回のセッションの事例ではかなりガッツりやっているので、業務の中でどれだけのウェイトをかけてメンバが取り組んでいるのかが気になるところ。
14:50 - 15:20 [MainRoom] コミュニティマネジメント: プロダクトの開発と展開をコミュニティが加速させる
東京大学 FoundX ディレクター 馬田 隆明 氏
ボリュームある発表で浅く広くエッセンスを列挙したセッション。30分じゃもったいない量だ。実経験ではなく、世の中で論じられているものをまとめた馬田氏らしい内容。ユーザーコミュニティのり活用について整理されていて、概論についての理解のリフレッシュの良い機会になった。
大きくなったコミュニティのサブグループ化は過去やってみたりしてきたけれど、やっぱりいいやり方らしい。
コミュニティのオンボーディングは、企業内でもそのまま使えるのでリストとして見えるところに書き出しておきたい。
コミュニティを育てることでエンゲージメントと継続率を高めるというのは自サービスでも意識している点。優先度がなかなか上げられないけれども継続はしていきたいところだ。
15:30 - 16:00 [MainRoom] 企業が求めるプロダクトマネージャーとその人材戦略
パネルセッション。PM の需要・募集・市場・オンボーディングについて。
16:10 - 16:40 [MainRoom] 発明、ドッグフーディング、プロダクトマネジメント
Nota Inc.CTO 増井 俊之 氏
増井氏流の発想・発明ベースのプロダクト開発の紹介。自分が使いたいから作り、問題があればすぐ直す。
プロダクトマネジメントはほぼ関係なかったけれどウィットに富んだ参考になるセッションだった。
16:50 - 17:35 [MainRoom] Keynote Session
Zoom Video Communications, Inc Chief Information Officer Harry D. Moseley 氏
30分 Zoom の宣伝。ちょっとだけ PM の話があってまた Zoom の宣伝。
2020年11月8日 (日)
用語統一のために Alfred のスニペット機能を使う
文章を書く時に「名称は正式表記で書く」「用語は統一する」ことにささやかながらこだわっている。初めて書く名称は Web などで正式表記を調べ、初めて書く用語は用語集などに当たるようにしている。過去に書いたことのあるものはファイルを全文検索して確認しそれに合わせる。
初めての語を調べるのに時間がかかるのは仕方ないとして、都度過去のファイルを全文検索するのに結構時間を費やしているのはもったいない。
事あるごとに用語リスト管理ツールとして使えるものがないか探してきているのだけれど、 Mac と Android デバイスで安全に同期して使えるものという条件では見当たらなかった(IM の辞書しかりクリップボードマネージャーしかりノートアプリしかり)。
Android デバイスでの同期はいったん諦めて Mac だけでも効率化したい。
ということで Alfred のスニペット機能(Snippets)を使ってみることにした。クリップボード履歴機能(Clipboard History)の呼び出しと使い分けるのが面倒かなと思って使ってこなかったのだけれど、調べてみると
といい感じに連携できるようになっていた。
過去に書いたことのあるものをファイル全文検索で確認したらコピーし、その後すぐにクリップボード履歴からスニペット登録すれば3回目からはさっと書けるようになるね。
クリップボード履歴が「設定期間経過すると消える」「Mac 間で同期できない」のに対し、スニペットは「登録削除はユーザー管理」「Mac 間で同期される」ので、いい感じに育てていけそうだ。エクスポートは独自形式のみなので依存しすぎずうまく活用していきたい。
[ Mac アプリケーション ]
About Me
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
About nDiki
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
Other Notes
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。
※内容は個人的見解であり所属組織とは関係ありません。
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker