nDiki : コミュニケーション

コミュニケーション - communication

2016年3月31日 (木)

MS本部企画開発部解散

CS 部門および情報セキュリティ部門によるMS本部が発足し、合わせて CS に関する企画開発を担当するメンバが企画開発部として集結したのが昨年の1月1日でした。

それから今日までの1年3カ月ではシステム面での取り組み加えて、直接コミュニケーションによるカスタマーロイヤルティ向上の取り組みにも新たにチャレンジしてまいりました。1スタッフとして直接ユーザーの方とやりとりをする中ではユーザーの声を肌で感じることの大切さを実感しました。またそういったやり取りによってユーザーの方にもサービスにより愛着をもってもらえるということも体感しました。もちろんシステム企画開発面でもディレクター・エンジニアが主体的に考えながらより良いものを作り続けてまいりました。

またこの間、部合宿を通じてメンバ全員で CS について集中的に議論することで価値観を共有し、相互理解を深められることができました。本当にイケてる仲間たちです。

そんな企画開発部ですが明日4月1日からはさらなる成果を出すべく、メンバがそれぞれ事業別に分かれて活動していくことになりました。今までの経験を生かしつつ、しかしながらそれに固執しすぎることなく引き続きユーザーファーストの思いを持ってそれぞれの業務に取り組んでいければ良いなと思っています。

今までありがとうございました。そして引き続きよろしくお願いいたします。

スポンサード リンク
[ 3月31日全て ]

2016年5月17日 (火)

Google Spaces とかシンクルとか【日記】

このあいだリリースされた Google Spaces を入れてみました。グループチャット的なサービスです。スペースへの招待は招待リンク (URL) を伝えるタイプなので、ゆるい半クローズドなタイプですね。 Google 上の機能やコンテンツとの親和性や検索は強そうですが、コミュニケーション設計的には目新しいところは無い印象です。ちなみに1ユーザーにつき作成できる Space は100個まで。

また、今日はシンクルも入れてみました。アプリをインストールしたらプロフィール設定をほとんどせずに使えたり、比較的軽いトークが中心だったりすることころはアンサーっぽいなと感じました。サービス内で中の人が「出会わない系」明言しています。状況に応じて ID 交換投稿を削除している様子。暇つぶしのポジションかな。

[ 5月17日全て ]

2016年6月22日 (水)

2016年度新体制での初の本部懇親会

naney:27913104985

今日は2016年度新体制になっての初の本部懇親会でした。会場は渋谷にある J-POP CAFE の Glasis。

今回は4月に新しく入社して仮配属された4人で企画から運営までをしてくれました。

エントランスに mixi 旧ロゴ・新ロゴが額装されていたり、ホールにスローガンの横断幕がかかっていたりと限られたリソースの中できちんと空間作りがされていました。音楽も場を盛り上げてくれました。メンバ間のコミュニケーションを引き出すゲームをバランスよく組み込んでいたのも素晴らしいですね。ルールを小出しにして進めていくなどゲームの完成度も高かったです。

通常業務を進めながらの準備は大変だったと思います。お疲れさまでした。

[ 6月22日全て ]

2016年8月13日 (土)

偏愛マップ作りにトライしたけれど1日ではまとまらなかった

偏愛マップ - キラいな人がいなくなる コミュニケーション・メソッド

齋藤孝氏が考案した「偏愛マップ」がオフ会などのイベントでの自己紹介にとても良さそうです。自分が大好きなものを書きだした「偏愛マップ」を作り、会話相手と互いのマップを交換して共通点や関心の湧いたキーワードについて会話すると盛り上がることができるというものです。

どんな感じか実際にやってみたくなりました。「偏愛マップ作り」と「偏愛マップを使った会話」の2つのステップのうち、まずは偏愛マップ作りをこの連休でやってみることにしました。

お気に入りを集める

まずは自分が偏愛しているものを集めるところから。気がついた時に整理するでもなく書きだしていた断片的なお気に入りリストがあるのでそれをベースに書き出し始めました。

リストに書き出してあったものは20代ぐらいまでに好きになったものが多いですね。やはり感受性の高い頃に出会ったものの印象が強烈です。逆に最近のものが偏愛にあまり上がってこないことが「そうだよな……」とちょっとショックでした。もっと普段からわくわくするものを意識して見つけていきたいなと。

以前挙げていたけれども「今はそうでもないかな」というものも結構ありました。ツール的なものにそういうものが多いですね。例えば ThinkPad とか。一方作品的なものは一度好きになったらそう変わらないものだということにもあらためて気が付きました。

「本棚を整理しようとしても、取り出した本を読み始めてしまって全然片付かない」パターンと同様、お気に入り書き出すのは楽しく苦しく、そしていくらでも時間がかけられるもの。日記を見返して偏愛自分探しをしたりしていましたが今日のところはいったんキリのいいところで止めました。

偏愛マップを作る

絵心が無いですし、何度も修正したくなると思うので手書きではなく PC 上で偏愛マップを作っていくことにします。

偏愛しているものを iThoughtsXマインドマップ風に書き出していっていたので、レイアウトしてそのまま1枚にまとめようと思ったのですが、放射状だとどうにもまとまらない感じです。偏愛マップ自体は形式自由なのでもちろんマインドマップ的なのもアリなのですが、好きなカテゴリ別に箇条書きにして四角で囲む形がいちばんうまく詰め込めるように個人的に感じました。

スペースに合わせて取捨する段階で「実は他人目線でウケ狙い的に上げていて偏愛じゃなかった」といったものに気がついたら捨てるとすっきりします。一方、偏愛ランキングが低いものをスペースの関係で落としていくのはとても心苦しいですね。苦しいです。

偏愛マップではキーワードで列挙していくので基本良いと思うのですが、コミュニケーションツールとして使うには一言ずつ程度説明を添えておくとニッチなものについては良さそうです。

結局今日の時点では公開するほど満足なレベルには仕上がらなかったので、ここに載せるのはお預けにしました。

もしイベント偏愛マップを書くなら?

自分にとって最高の偏愛モノを思い浮かべて書き出すのは、性格にもよりますが結構な時間がかかるということがわかりました。もしイベント偏愛マップを書いてもらうとしたら、きちんとタイムキーパーをおいて進行しその時間でできる範囲で仕上げてもらうよう誘導する必要があるかと思います。

偏愛マップやカテゴリのサンプルを用意しておいて、初めての人がスムーズに取りかかれるようにする必要もありそうです。

[ 8月13日全て ]

2016年8月16日 (火)

偏愛マップを作る時のポイント

naney:29002854286

偏愛について書かれた齋藤孝氏の「偏愛力 〜人付き合いがうまくいくコミュニケーションの基本50〜」を図書館でぱらぱらっと見たら面白そうだったので早速買って読んでみました。

本書の中で「最高のコミュニケーションツールだと自賛 (p.142)」されている偏愛マップの作り方について書かれていたので、なるほどと思うポイントをピックアップしてみました。

自分が本当に偏愛しているものを書きましょう

他人にどう思われるかを気にしたり恥ずかしがったりせずに、本当に偏愛しているものを書くということが大切です。

「偏愛」とは何かを特別に好きになること。 p.3

「こんなものを好きだといったらキラわれる」は絶対に思い過ごしです。 p.100

偏愛マップは人に見せることが大前提ですが、それを意識して、かっこいい「好き」だけを書こうなどと変なバイアスをつけないこと。 p.143

偏愛しているものをできるだけ具体的に書きましょう

偏愛はできるだけ具体的に書くのが良いとのこと。固有名詞などで書くのが良いですね。実際に私が偏愛マップを使って会話してみた時も、相手の偏愛マップにあるキーワードが具体的なものの方が興味をもって質問できました。

偏愛しているものはできるだけ細かく書くこと。 p.143

書き出せない時は昔好きだったものなどを思い出してみましょう

まず最初のとっかかりとしては、やはり昔好きだったものなどが良いようです。子供の頃に好きになったものなどはやは強いですね。

昔好きだったという人やこと、ものを書いてもいいでしょう。 p.144

偏愛するものがなかなか思い出せないときには、特別に好きな食べ物とか、子どものころに手に入れたもので今も捨てられないでもっているもの、はまったアイドルとか漫画など手近なところから偏愛しているものを思い出していく(後略) p.144

あとはワークショップなどでみんなでやる場合は、サンプルとなるカテゴリのリストがあるととりかかかりやすいようです。

形式は気にせず書きやすいように自由に書きましょう

基本形式は自由です。カテゴリ別に箇条書きにしていくタイプや、マインドマップのように放射状に広げていくタイプなどが多いようです。「偏愛マップ」で Google 画像検索してみるといろいろな方の偏愛マップを見ることができるので、気に入ったものを真似るのも手です。

限られた時間で書きその場で交換して会話するような場合は、綺麗さにこだわらない方が良いかと思います。

読めさえすればどんどん書きなぐる感じでかまいません。 p.145

またじっくり時間をかけて偏愛マップアップデートしていくようなケースでは、偏愛しているものについて順位付けをするのも面白いです。自分が本当に本当に好きなんだなぁというのが見えてきます。逆にこれは好きだけれど偏愛ではないなというのも見えてきたりします。

ときどきランキング付けをやっていると、自分が偏愛しているものが具体的にわかってきて、あやふやだった自分像が明解になってきます。 p.117

ワークショップなどで偏愛マップ作りについて説明する場合には上記のようなポイントを伝えるとスムーズに取り組めるのではと思います。

偏愛マップを交換して共通点や関心の湧いたキーワードについて会話する際のポイントについても本書で説明されていたので、それについても別途まとめておきたいと思います。

[ 8月16日全て ]

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月18日 (木)

偏愛力 〜人付き合いがうまくいくコミュニケーションの基本50〜

偏愛力 〜人付き合いがうまくいくコミュニケーションの基本50〜

偏愛力 〜人付き合いがうまくいくコミュニケーションの基本50〜」を読みました。これは使えるなと思いあとで活用できるように

について先にまとめてみました。

本書では上記のテクニカルな部分に先立って、まず「偏愛」について詳しく述べられています。「偏愛は『自分らしさ』、アイデンティティをつくり上げるもの (p.21)」で「『好きなもの』が多いほど、その人の世界は豊かなものになる (p.24)」と本書では偏愛することの大切が語られていました。

いやぁ、この本を読むとどんどん偏愛したくなってきます。


[ 読書ノート ] [ 偏愛マップ ]

[ 8月18日全て ]

2016年11月21日 (月)

one-on-one ミーティングをやめようかなぁ

one-on-one ミーティングというと

  • コーチング
  • 信頼関係構築
  • プロジェクト状況の確認・相談

あたりが目的かと思います。特に「コーチング」の時間にすることが大切と書かれている記事を良くみかけます。

実際のところは、話題のきっかけとしてまずプロジェクトの話をしているうちにそれで終わってしまうことも結構多かったりします。

もしプロジェクトの状況の確認や課題の相談がメインなら、週次・あるいは隔週の one-on-one ミーティングが無い方が、早め早めのコミュニケーションにつながりよりスピーディーに物事が進むのではないかと思うわけです。そういう意味では one-on-one ミーティングをやめた方が良いんじゃないかと。

本当ははきちんとコーチングの場にしていくのがベストだとは思いますけどね。

[ 11月21日全て ]

2017年1月17日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会11回目。今日は第11章 開発チーム。

ここまでの章で様々な視点でスクラムの説明がされてきたので、開発チームの章は比較的おさらないな感じで読めました。

開発チームのスキル

開発チームは設計・開発・統合・テストなど必要な作業を全て行うので、必要なスキルをチームは全て備えている必要があります。

このために

マネージャーは、今いる人たちでT型スキルのチームを作るべきである。

マネージャーは、学習や実験の時間がうまく作れるように、チームメンバーを支援する必要がある。

と書かれています。他のメンバと互いに専門分野を教え合いながらできる仕事を増やしていくのがまずは近道でしょうか。ただこの方法だと浅く広く学習は進むと思うのですが、 T 型の縦の部分、専門分野の部分を深めていくのは(機能別のチームで学び合うのに比べて)難しくなるのではと感じました。

「専門分野については個人で学ぶ方法を獲得していて自力で学べるのでは」という意見が勉強会では出ました。

開発チームの構成

チーム構成の話では小さいチームの方が

としています。一方

  • チームのもつスキル
  • 議論の多様性
  • 学習

などを考えるとある程度の人数も必要でこのあたりのバランスが重要そうです。本章では

一般的には5〜9人のチームが最適とされている。

ビジネス価値を迅速に届けるスイートスポットは5〜7人のチームである。

と述べられていました。そういう意味では今の私のいるところのスクラムチームは人数がちょっと少なすぎるかなと感じました。

掛け持ち

掛け持ちに対する問題は承知しているものの、現実的にせざるを得ない場合が発生します。

複数のプロダクト(またはプロジェクト)や複数のチームに関わると生産性が低下する

3つ以上のプロジェクトの仕事を同時に行うのは経済的ではない

とありこれに従うとすると仕方なく兼務にするにしても2つまでにすべきということですね。そういった状況が発生するのは

多くの組織では、同時に開始するプロジェクトが多すぎる

ということで組織体制の工夫以前にプロジェクトの見直しをすべきなのでしょう。

チームの寿命

長寿のチームはできたてのグループよりも生産性が高い

については完全同意。今までもチーム殺しをしないように意識はしてきました。特にスクラムではチームとして見積もりやベロシティの履歴が蓄積されることで正確性が向上していくところがあるので、チームを維持していくことがより大切に感じられます。

[ 1月17日全て ]

2017年2月16日 (木)

Developers Summit 2017 1日目 #devsumi

rimage:/nDiki/2017/02/16/2017-02-16-093430-nDiki-1200x900.jpg

今日から2日間目黒雅叙園でデブサミです。今年で来るのも3回目。例年通り一般参加者はテーブル無しのぎゅうぎゅう席なので1日いるとちょっと大変です。今年はノート PC を持っていきました。開けたのは半分ぐらい。

10:00~10:45 【16-E-1】 Web フロントエンドの変遷とこれから

株式会社サイバーエージェント 佐藤歩(@ahomu)氏 泉水翔吾(@1000ch)氏

@1000ch 氏

200x 前期からのタイムラインを浅く解説。

  • Progressive Web App (プログレッシブ ウェブアプリ)・Service Worker を使ってオフライン環境での動作。
  • Extensible Web
@ahomu 氏

Web フロントエンドに期待される変化と適応。一般論的な展開でした。

11:05~11:50 【16-A-2】 Yahoo!ブラウザーアプリのプロダクトマネージャーが考えていること

ヤフー株式会社 里山南人氏

プロダクトマネジメントについて3点。最初の2点は自身も見直したいなと思いながら聞いてました。

市場環境の分析と戦略化
  • 競合を明確にした上で差別化
    • 4C 分析 機能・流通チャネル
根拠に基づくアプリの成長手法
  • 健康状態のチェック(KGIKPI)
    • KPI ツリーと対応する施策
    • 継続利用: 定着しそうな機能を重視
  • 定期的な観察と分析
組織連携・組織貢献
  • 安定市場でのリソース(エンジニア)確保は難しい。
    • エンジニアが取られていく。
    • グロース施策 (東京)
    • 基本的品質改善(ベトナム)
  • All Yahoo! JAPAN フラグシップ戦略

13:05~13:50 【16-B-3】 パネルディスカッション「エンジニアが創るプロダクトの未来 ~エンジニアからプロダクトマネージャーへ~」

ソニーモバイルコミュニケーションズ株式会社 高橋りさ(@hatarakuboysmom)氏 株式会社ビズリーチ 鈴木康弘(@yappy727)氏 株式会社サイバーエージェント 横道稔(@ykmc09_dev)氏 グロースエクスパートナーズ株式会社 関満徳(@fullvirtue)氏

エンジニアからプロダクトマネージャーになった人によるパネルディスカッション。きちんと事前に準備がされて、パネラー同士のからみもある良いパネルディスカッションでした。

プロダクトマネージャーになることでコードを書く時間は無くなったけれど、自分で SQL クエリを発行してデータを取ったりできるのはやはりエンジニアリング経験の強みとのことでした。「プロダクト」マネージャーですが、どなたも強いチームを作るために費やしている時間の割合が多いということがうかがえました。

今週読み始めInspired: 顧客の心を捉える製品の創り方」が何度か引き合いに出されていました。やはり必読書のようですね。

14:10~14:55 【16-B-4】 MicrosoftのAI開発機能/サービス

日本マイクロソフト株式会社 佐藤直生(@satonaoki)氏

AI 界隈のおさらいをしたあと、Microsoft の取り組みなどを紹介。エバンジェリストらしいちょっとセールスぽいセッションでした。

解約・離反対策として、解約・離反しそうな人を予測発見するというさらっと出た事例が面白そうでした。ぜひそういうのをもっと聞きたかったです。

15:15~16:00 【16-B-5】 AI礼賛時代にエンジニアはいかにしてサバイブすべきか

株式会社ブレインパッド 下田倫大(@rindai87)氏

下田氏のセッションということでチョイス。そういえばふわっとしたタイトルだったので最初は何を話すのかなぁと思って聞いてました。公募セッションだったのでキャッチーなタイトルにしたとのことです。

内容としては昨今の「人工知能やりたまえプレッシャー」のなか機械学習にどう取り組んでいくかという話と、機械学習に携わっていくエンジニアのスキル・キャリアパスにはどのようなものがあるのかでした。

実務に裏打ちされた惹きつけられるセッションでした。機械学習(や人工知能)がらみの新事業に入るエンジニアも聞いておくと良かったんじゃないかなと感じました。

16:20~17:05 【16-C-6】 事業成長にコミットするエンジニア組織への道のり

株式会社リクルートライフスタイル 小川健太郎氏

「社員エンジニア」急増に合わせた組織と文化を作ってきましたという話。抽象化された説明の部分が多くてそこは「まあそうですよねー」なので、時々でてくる具体的な点を注意して聞いてました。かなりぼやかされた発表でしたが、いろいろ試行錯誤されたんだろうというのは伝わってきました。変えてこれているのは実際すごいなと。

17:25~18:10 【16-A-7】 ザ・黒帯 ~ Yahoo! JAPANのエンジニアの働き方とキャリアを語る

ヤフー株式会社 楠正憲(@masanork)氏 伊藤宏幸(@hageyahhoo)氏 倉林雅(@kura_lab)氏 里山南人氏 CodeZine編集部 斉木氏

パネラー同士のからみはあまりない進行スタイル。

黒帯制度がらみ中心とした Yahoo! JAPAN の中の話。Yahoo! JAPAN 独自の話の中、パネラーの方がそれぞれどのような立場・思いで仕事をされているのかというのが少しですが伝わってきました。

それとは別に始めの方で @masanork 氏が PDCA を回す内製プロダクトと受託開発プロダクトとの差が大きくなってきた時代という話をされていたのが印象的でした。

[ 2月16日全て ]

About Me

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

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

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

月別インデックス
Process Time: 0.083601s / load averages: 0.64, 0.69, 0.67
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker