nDiki : ポイント

ポイント

2016年8月17日 (水)

偏愛マップを交換して会話する時のポイント

naney:29002854286

偏愛力 〜人付き合いがうまくいくコミュニケーションの基本50〜」を読んで「偏愛マップを作る時のポイント」をピックアップしてみました。

偏愛マップをができたらそれを交換してのコミュニケーションです。初対面の人が集まる会などでは5分〜10分程度でシャッフルしながら2人1組で会話していくと良いとのことです。

ランダムに2人1組になってもらい、つくったばかりの偏愛マップを見せ合って5分〜10分話し、すぐにシャッフル(組み換え)。このシャッフルを何回も繰り返していきます。 p.160

本書では「偏愛を交換し会う10のルール」が上げられていますが、その中でもポイントは以下ではないかと感じました。

  • 聞き役に回る
  • 相手の偏愛を否定しない
  • メモをしながら話す

聞き役に回る

会話の時に聞き役に回りましょうというのはよく言われていることです。ただ偏愛マップを使っているといつも以上に話したくてウズウズしてしまいがち。実際自分も普段以上に話したくなってしまいました。かなり意識する必要がありそうです。

偏愛マップコミュニケーションでは一つだけ、絶対に気をつけなければいけないことがあります。自分が偏愛について話す中心になってはいけない! できるだけ聞き役になるということ。 p.165

「しゃべる」と「聞く」は五分五分ぐらいがちょうどいい分量配分。 p.184

相手の偏愛マップとの共通点を見出して盛り上がるだけでなく、共通していないけれど関心をもったものについて話題を振ってみるというのも重要ですね。

相手の偏愛マップを見たとき、自分もそれを偏愛しているというものよりも、これまであまり興味を持ったことがないことに目を止めて、質問を投げかける。 p.165

相手の偏愛を否定しない

「人の意見を否定しない。」というのを読書会をする際のルールにしていると、猫町倶楽部の代表の方に去年教えてもらいました。以来自分たちでオフ会を開催する際にもそういうルールにするようにしています。

偏愛ですから自分と異なる考えだなと思うこともあるでしょうが、否定せず一つの考え方として尊重することが良いコミュニケーションにつながります。

相手の偏愛を絶対に否定しないこと。自分の偏愛しているもの以外は全否定では自分がすごく狭くなってしまいます。 p.168

一つの偏愛を際立たせるために対極にあるものを否定する。しばしばやりがちなことですがこれもNGです。 p.170

否定のエネルギーで自分の偏愛を際立たせるのは愚策中の愚策と心得ましょう。 p.171

相手はいい気持ちになって好きなことを話しているのだから、聞くほうが余裕を持って、少々ズレていても相手の話しを楽しみながら聞いていく。 p.199

メモしながら話す

比較的普通の人よりはメモる派だと思っている私ですが、そうはいっても普段の会話ではノートを出しそびれたりしてしまいます。しかしやはりメモすることは重要ですね。再認識です。

偏愛を核に話していくとつい話しに熱中してしまうもので、要点を押さえるためにもとくに盛り上がったところ、相手の熱がひときわ高まったところですかさずメモ。 p.175

メモを取っていないと、相手がいい気分になり、盛り上がっているところなのに、「実は、私も◯◯が異常なくらい好きでしてね」などと口をはさんでしまったりしがちです。 p.175

こうしてみると偏愛トークに限らずどれも一般の会話にも当てはまるポイントですね。

スポンサード リンク
[ 8月17日全て ]

2016年8月22日 (月)

ミニリッツパーティーとか【日記】

naney:28640506814

台風の日でした。東京アメッシュの赤いのが通過した頃合いを見計らいつつ、いつもより早めに家を出て会社に向かったのですが、そうしたら台風も本気を出してきました。しかしながらそれでもピークは避けられたようで、後から会社に到着した人に比べたらマシな濡れ具合。早めに来れば、早めに乾く。これがポイントです。

午後は自分たちでトッピングするミニリッツパーティーをしました。普通にクリームチーズとかが一番。フルーツの缶詰など水っぽいものはちょっとかなという感じです。

[ 8月22日全て ]

2016年9月2日 (金)

今日のさえずり: ホントに面白くないから「黒塗りの高級車」を NG ワードに設定した

2016年09月02日

[ 9月2日全て ]

2016年9月10日 (土)

今年はドラゴンやコマ花火もやった

naney:29595707255

今日から3連休。予定や天気を理由に8月中にはやれなかった花火を9月第2土曜日の今日にようやくやることができました。今年はドラゴンや地面で回るコマ花火も買って昨年よりプチグレードアップ。夏の終わりを楽しみました。

イトーヨーカドーで買った手持ち花火はどれもなかなか着火せず。保管してあった部屋の湿度が高かったのかな。乾燥剤を一緒に入れておいた方が良かったかもしれません。

今回はバケツロウソクも用意したのですが、倒れないものの消えやすさは変わらず特段良いというものでもなかったです。もうちょっと小さいキャンドルで十分でした。今回は風防無しだったのですが、やはりあった方がいいですね。それから多目的ライターのガス切れに怯えたので次回はもう2本以上用意することにします。

バケツは100円ショップかどこかで買った金物のがあったのでばっちりでした。

ではまた来年。

ということで次回用ポイントまとめ。

  • ドラゴン・回転花火は楽しいので手持ち花火以外に買っておく。
  • 多目的ライターは複数用意する(ライター待ちやガス切れ対策)。
  • ロウソクは平べったいものが便利。
  • 風防を用意する。セットに入っていなければ空き缶の底を抜くなどして作る。
  • 水バケツを用意する。なければ2Lペットボトルを切って用意する。
  • 花火を留めているテープは事前に剥がしておく。
  • LED ランタン・LED フラッシュライトを持参する。
  • ムヒを持っていく。(NEW)
[ 9月10日全て ]

2016年10月8日 (土)

雨でイベントが延期になったので iPad Pro 注文【日記】

9.7インチiPad Pro Wi-Fi 32GB スペースグレイ MLMN2J/A

今日の予定は雨の予報ということで朝の時点で明後日に延期決定。ちょっとほっとしました。

ちょっと心に余裕ができたので iPad の新調の話を進めたり。サイズと今後の寿命を考えて「9.7インチiPad Pro Wi-Fi 32GB スペースグレイ MLMN2J/A」で決心。2011年に買っiPad 2 も気がつけばよく5年頑張ったなと。ポイント還元率の低い Apple 製品なのでヨドバシ・ドット・コムでゴールドポイントを全額ツッコミました。

家族共用にするので Apple ID は私のメインのとは分けるつもり。新しく Apple ID を作成してファミリー共有の登録案内を送っておくところまでやっておきました。

明日届くのが楽しみです。

[ 10月8日全て ]

2016年11月23日 (水)

文化芸術鑑賞会とクリスマスツリー【日記】

naney:31269366826

オペラ・ミュージカル・落語・吹奏楽と盛りだくさんの文化芸術鑑賞会を観に行ってきました。 生の落語を見るのは初めて。見方を簡単に説明してからのお噺だったのでポイントを押さえつつ楽しむことができました。

それから午前中にクリスマスツリーを飾り付け。もうすぐ12月。明日は東京も天気予報

[ 11月23日全て ]

2016年11月29日 (火)

第6回エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会6回目。今日は第6章 プロダクトバックログ

プロダクトバックログは、優先順位の高いものほど詳細度を上げて分割していく一方で優先度の低いものはざっくりとで良いというのがポイント。現実的で良いなと思います。2回から3回分程度のストーリーを準備完了状態で抱えておくのが経験的に良いとのことでした。

一方プロダクトバックログはリストなのでこの分解ツリーが見える化されていません。このあたりがちょっと扱いにくいなと感じることはあります。アウトライナーのような形でツリーで整理しつつ、その中でプロダクトバックログアイテムとなるところのみビューとして抽出して順序付けるものがあるといいのになと思うことはあります。

グルーミング(プロダクトバックログリファインメント)については

プロダクトバックログのグルーミングは、プロダクトオーナー主導で行う共同作業だ。

と書かれていてこれは「おっと」と感じたました。関係者でのグルーミングはおざなりにしていたなと。ここは PO の責任範囲だとあらためて把握。なおグルーミングはいつ行ってもいいとありました。

開発チームは、各スプリントの作業時間の最大1割程度までをグルーミング用に確保すべきだ。

とあり結構たっぷりだよなと思うわけですが、考えてみるといわゆるウォーターフォール開発でも初期の工程に時間をかけているわけですし、特別多い割合でも無いのかなと。

複数チームでプロダクトバックログをどうするかについては、1つのプロダクトバックログからビューでチーム別のプロダクトバックログを用意するのが良いとありました。理想的には確かにそうだと思いますが、そこまでやるとすると結構ヘビー級のツールが必要になって気がしてそちらの学習・運用コストが馬鹿にならないのではという印象を受けました。

何事もできるだけシンプルにしていきたいですね。

[ 11月29日全て ]

2016年12月2日 (金)

年末恒例のモバイル*サンクスチャージ【日記】

オートチャージ・定期券代・切符代でたまるビックカメラSuicaカードのビューサンクスポイントの毎年恒例の Suica チャージ「「モバイル*サンクスチャージ」を申し込みました。今年も去年同様3,000円分でした。

今日のさえずり: 「モバイル*サンクスチャージ」申し込み。年末恒例。今年も3,000円分。

2016年12月02日

[ 12月2日全て ]

2016年12月6日 (火)

第7回エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会7回目。今日は第7章 見積もりとベロシティ。

プロダクトバックログ見積もり

プロダクトバックログアイテム(PBI)の見積もりプロダクトバックログリファインメント(グルーミング)で行うアクティビティです。この時プロダクトオーナーやスクラムマスターは「実際に見積もる作業」には関わらないのがポイント

見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。

でなるほどと思いました。見積もられたサイズよりも、見積もるという過程を重視しているんですね。

ストーリーポイント

PBI の見積もり単位としてストーリーポイントと理想日を紹介しています。ストリーポイントはあくまで相対値なのでそのチーム内でしか使えない値です。プランニングポーカーのところで

多くのチームでは、1回のスプリントでこなせる最大のサイズを13で表している。

としているので、これが一つの目安でしょうか。それからストーリーポイントはベロシティと対にならないとあまり意味をなさないですね。

理想日の方はいわゆる人日。

ベロシティ

ベロシティで計測するのはあくまでも生産量であり(デリバリーしたもののサイズ)であり、成果(デリバリーしたももの価値)ではない。

ここは当たり前な感じではありますが誤解してはいけないところ。

計測で出てくるベロシティは見積もりの(精度ではなく)正確性によってかなり揺らぎがあると思うのですが、このあたりはチームが学んでいくことで安定していくものなのでしょうか。ベロシティに幅を持たせて表すと良いとありますが、どれぐらいの幅に収まっていくのか興味があります。

それからベロシティが上がるかという話がありました。ストーリーポイントとしては相対値なので上がらないはずですよね。アウトプットの絶対量は増えていくと思いますけれど。

[ 12月6日全て ]

2016年12月13日 (火)

第8回エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。

スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。

技術的負債

技術的負債。当初は

意図的に手抜きをしてすばやく仕上げるという意味

技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。

からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。

技術的負債ですが

大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。

ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。

ただ

技術的負債の経済的意味についての適切な認識

については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。

技術者レベルでの技術的負債の可視化

  • 方法1: 障害管理システムに記録する
  • 方法2: 技術的負債を表すプロダクトバックログアイテムを作る
  • 方法3: 技術的負債バックログを作る

サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。

技術的負債の返済

  • 作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。
  • スプリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。

あたりがポイント

「技術的負債返済スプリント」だとか「リファクタリングプリント」などといった言葉がチーム内で出てきたら、危険信号だ。

ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。

また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。

[ 12月13日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィの SNS の企画開発を行うグループでマネージャー・プロダクトオーナーをしています。CS 向上・ユーザーサポート・健全化などにも取り組んでいます。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.08206s / load averages: 0.35, 0.47, 0.47
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker