プライベートチャンネルやDMに頼っているとリーダーは生まれにくい
いろいろな会社を経験しましたが、だいたい、Slack の使い方として
パブリックチャンネルばかりの会社、プライベートチャンネル（もしくはDM）ばかりの会社におおむね二分されます。
パブリック・プライベートが半々という会社は少なく、どちらかに寄っていく傾向にあると感じています。
今日はそこについて考察していきます。
1. 何も方針を出さないとDM率が上がる
会社として明確な Slack の運用指針を作らない場合、
DMが作られる方にどんどん寄っていきます。
これにはいくつかの理由があります。
- 1-1. メール文化に慣れていたので、やり取りは個人に対してするものという認識でいる
- 1-2. 「こんなことチャンネルに書いていいのかな？」「みんなが見るところに書いていいの」という恐れ
- 1-3. その話題をするべきチャンネルが見つからない
1-1. メール文化に慣れていた
そもそも Slack の文化に慣れていないパターンです。
Slack はチャットベースで気楽なやり取りをしつつ、オープンに情報交換をおこなうことで
社内の部署間のコミュニケーションを円滑にする目的や、
他部署でなにがおこなわれているかの情報を拾いやすくすることで部署間の連携を強くし、
連係ミスによる失敗を少なくし、かつ業務のスピードアップを図る目的があります。
ベンチャーを何度も経験している人などは Slack のこの目的を理解しているため、
説明しなくてもたいていの人がパブリックチャンネルでバンバン書いてくれますが、
世の中まだまだそうでない人の方が多いです。
よって、最初はパブリックチャンネルでのやり取りが多かった会社だとしても、
社員が50名を超えてくるあたりで
新しく入ってくるメンバーがそういうのに疎かったりすると、しだいに DM が多くなっていきます。
これを解決するには、
- 社内の Slack 利用規定を作成する
- また、規定の中でどういうメリットがあってその規定なのかを述べる
- 入社メンバーにみっちり定期的に説明する
以上のことが必要になります。
1-2. パブリックに書くことの恐れ
人間は大部分の人が心配性で自意識過剰です。もちろん私も。
メールやLINEの返信が相手から返ってこないと、「なにか私が悪いこと言ってしまったんじゃないのかな…」と不安になりがちです。
そのような恐れを持つ人が多いので、
「この書き込みは誰かを傷つけないか」とか「なにか書いたことが誤解されるんじゃないかな」とか不安を持ちます。
そんなに一人一人のメッセージを気にしてるほど暇な人や、悪意を持った書き込みと捉える心の狭い人は会社に入社させていませんので、
それは杞憂であることが多いのですが、やはり不安に思う人が多いのは事実です。
これを解決するには、
- まずは書いてもらう（社内の Slack 利用規定に従ってもらう）。そして、パブリックチャンネルで書くことが怖くないとだんだん慣れて気付いてもらう
- 誰かのコメントが強く注目されないくらいに、チャンネルが常ににぎわっている
これらのことがおこなわれていると良いでしょう。
1-3. 話題をするべきチャンネルが見つからない
これは２通りあります。
1-3a. 単純にチャンネルがない場合
『単純にチャンネルがない場合』は単純で、チャンネルを作ってもらえばいいです。
ただ、ここで規定がしっかりないと、上の 1-1. , 1-2. で説明した理由により
プライベートチャンネルが作られてしまう傾向に陥りやすいので注意です。
あとでもう一度書きますが、プライベートチャンネルはパブリックチャンネルに後から変更できないので、
「ここパブリックチャンネルで良くね？」って気付いてからの変更がしにくいです。
『顧客情報を扱わない限りはパブリックチャンネル』などと、基本はパブリックチャンネルである旨の規定があるといいと思います。
1-3b. チームのチャンネルで書いていいことなのかわからない
『チームのチャンネルで書いていいことなのかわからない』ということもよく起こります。
例えば、「チームメンバー数名での飲み会の写真をチームのチャンネルに上げていいか？」とか、
「○○さん個人あての相談をチームチャンネルに書いていいのか」とか。
チームリーダーからしてみれば、どちらもチームチャンネルに書いてOKです。
いえ、「まだ仕事中のメンバーがいるかもしれない中で、チームのチャンネルに上げるのはいかがなものか。雑談チャンネルに上げるべきだ」という考えのリーダーもいるかもしれませんが、
個人的には、チームチャンネルであれこれ雑に書きやすい空間作りのために、なんでも書いてOKな雰囲気でありたいです。
後者の「○○さん個人あての相談をチームチャンネルに書いていいのか」という考えでチームメンバーにDMされるのはマジで困るやつで、
チームメンバーが知らぬうちにタスクを抱えていた、ってなるので本当にやめてほしいですね……。
というわけで、
「チームの話題やチームメンバーへの相談はチームチャンネルでしてもらって、それで困ることが起きてきたなら新規チャンネルを立ち上げる。DMはおこなわない」
の方針が Slack 利用規定としてあるといいと思います。
2. なぜ DM がダメか
2-1. 通知が飛ぶ
Slack で通知を飛ばしていいのは緊急のときだけです。
とりわけエンジニアは、Slack の通知が飛んで来たら「障害が起きた？！」ということを念頭に置き、あせって Slack を開きます。
ですのでグループDMなんかが作られて話が続くとけっこう地獄で、
イラッとするだけでなく大事な通知を見落としてしまいかねませんから、
グループDMで会話が続くものであれば、プライベートチャンネルにした方がマシです。
実は Slack には「Convert to a private channel...」という機能もあります。
2-2. あとからメンバーの追加が出来ない
グループDMをしてる途中で「これ、○○さんも知っていた方がいいよね？」ってなったときに
DMの場合は途中からメンバーを追加することができません。
また、グループDMのメンバー数には限界があります。
上で書いた「Convert to a private channel...」の機能を使えば、
会話の内容をチャンネル化してからメンバーの追加がおこなえますので、現在はあまり大きな問題ではなくなりました。
（……が、グループDMを使っているような人は上の機能を知らないので、結果的に「○○さんも知っていた方がいいよね？」の○○さんには伝わらないことの方が多いです）
3. なぜ DM やプライベートチャンネルがダメか
3-1. 情報が拾えない
最初の 1-1. で書いたように Slack の大きな利点は、
オープンに情報交換をおこなうことで社内の部署間のコミュニケーションを円滑にする目的や、
他部署でなにがおこなわれているかの情報を拾いやすくすることで部署間の連携を強くし、
連係ミスによる失敗を少なくし、かつ業務のスピードアップを図る目的にあります。
DMやプライベートチャンネルで情報のやり取りをおこなうのは、
これと正反対のことが起こるデメリットを持っています。
他部署や他プロジェクトでおこなわれていることがわからないし、
部署間で重複することをやって無駄が生じることなどが起こるわけですね。
また、現在働いている人はもちろん、より大きく影響を受けるのは新入社員（特に中途雇用）です。
開かれていない情報は、新入社員のオンボーディングのスピードを大きく下げる効果があります。
優秀な社員であれば、過去の Slack の流れを見ることで、
今走っているプロジェクトの生まれた背景、各部署にどんな人間がいるか、社内の人間関係やパワーバランス、を教えることもなく理解してくれ、
自分がどうプロジェクトを回していけばいいのかをだいたいは理解してくれて、すぐに力を発揮してくれます。
プライベートチャンネルや DM での会話が多いと、これらの情報は拾えず、
誰かが教えてくれるまではわかりません。（それにたいてい、これらを教えてくれる人はいません）
また、本来その新入社員の人が知っておくべき情報のあるプライベートチャンネルに招待されていないことがわかって、
入社１ヵ月してからようやく招待されるなんてことがあります。
3-2. マネジメント層が新たに生まれにくい
チーム内での情報の格差は、新たなマネージャーを生みにくい環境を作ります。
優秀な人材は、情報が充分に与えられればそれ相応の判断ができます。
チームリーダーと同じ分だけ情報が与えられていれば、最大、チームリーダー相応の判断ができます。
そういう判断を出来る人を、マネージャーは次のチームリーダーにするべく育てていけばいいわけです。
一方で、情報の非対称性があって、
チームリーダーが知ってる情報をメンバーが知らないのであれば、その情報量の差が大きいほどに、判断は稚拙なものになります。
その稚拙さをもって「こいつは稚拙な判断しかできないな」となってしまうのなら本当に理不尽な話です。
次のマネジメント層を育てるために、情報はできるだけチームリーダー含めたチーム内でフラットにし、
その上で「あなたがリーダーだったらどうするか」をメンバーには 1 on 1 などで問いかけ考えさせる癖をつけさせると良いでしょう。
メンバー全員がリーダー候補になると、チームはとても上手く回ります。
（参考: フォロワーシップとリーダーシップの違いや関係性とは？ ）
3-3. 個人の仕事量が大きくなることがある
1-3b. でも書きましたが、プライベートチャンネルやDMでタスクを依頼されていることは
周りからはわかりません。
DMでのタスクの依頼が常態化すると悲惨で、
Aさんに仕事を依頼するBさん、Aさんに仕事を依頼するCさん、Aさんに仕事を依頼するDさん、が発生したときに、
Aさんは3名それぞれとチャットをすることで時間を取られるし、
そのようなタスクが発生していることを知らないEさんがAさんに仕事を依頼して……とさらにタスクが発生してAさんがパンクします。
チームが形成されていなかったり、チームがあっても 1on1 や KPT などのチーム行事の成熟度が足りていない場合、
こういった問題にはなかなか気付きにくいです。
チームチャンネルでの相談に一元化されていれば、
Aさんがわからない質問やAさんが忙しいときに他のチームメンバーが答えてくれたり、
B/C/D/Eさんからしたら、明らかにAさんに仕事が集中してることはわかるので、
レスが遅くてもイライラしませんし、Aさん以外のチームメンバーに相談した方がいいという可能性にも気付くことでしょう。
正当な人事評価や退職リスク防止のために、個々人の仕事量が見えなくなる状態を作ることは避けましょう。
3-4. 「この情報を○○さんに伝えていいですか？」の確認タスクが増える
情報をオープンにするかプライベートにするかの基準が決まっていない場合、
この確認タスクが増えます。
DMやプライベートチャンネルを使うことが当たり前になっている組織ではこの確認タスクが多いです。
しかも、その決定権を持っているのが誰かわからず、最終的にはマネージャーが社長に確認し……までのフローをたどります。
ベンチャーでこの遅さは致命的ですし、なにより、「自分で決めて判断する」というベンチャー企業にとって必要な精神が損なわれ、
「誰かに決めてもらうまで待つ」という精神が社員に蔓延します。
3-5. あとからパブリックチャンネルに出来ない
上記の問題を鑑みて、「じゃあパブリックチャンネルにしよう！」と思っても、
Slack の仕様上プライベートチャンネルをパブリックチャンネルにすることはできません。
つまりプライベートチャンネル時代のメッセージを残したままパブリックチャンネルにすることができないので、
移行後、過去のメッセージを探すことに苦労するようになってしまいます。
改革には痛みが伴うとは言いますが、なかなかの痛みです。反対の声も多く出るでしょう。
いったんプライベートチャンネルで作ってしまうとこのような苦労が生まれるので、
「とりあえずプライベートチャンネルで作る」でなく、
「とりあえずパブリックチャンネルで作る」 という習慣を早い段階で根付かせておく必要があります。
4. 結局のところ
パブリックチャンネルでのオープンなやり取りが前提となるよう、
Slack 利用規定を従業員（Slack参加者）が2桁になり始めたころまでには作り、
業務委託など含む Slack 参加者全員には自社の規定をしっかり案内し、
利用規定が運用されているか管理したり、相談を受けるための人を1人は決めて置き、その相談用のチャンネルも用意しておく。
このようなことが肝要です。
遅くなればなるほどエネルギーが必要な作業になりますので、
創業後は、技術顧問や、ベンチャー慣れしているエンジニアなどに早めに策定してもらうと良いでしょう。
利用規定の参考:
【採用、そして評価制度】scouty x HRBrain の勉強会に参加してきました！
きたぞ！！！ #scouty_hrbrain pic.twitter.com/Cm8UN6sMld
— ハトネコエ (@nekonenene) 2019年3月15日
というわけで、scouty さん*1と HRBrain さん共催の、こちらのイベントに参加してきました！
【scouty × HRBrain】HRTechベンチャーが語る自社採用、目標・評価管理の成功と失敗
今最高にイケてる（ハトネコエ視点） HR Tech 企業2社のゴールデンタッグです。最高ですね。
会場はいっぱいになるかなと思いましたが意外と参加者は少なかったです。15人くらいかな。
しかし、 sli.do で質問を受け付けていたら、
かなり多くの質問が集まって、すべての質問に答えきれないくらい盛り上がっていました！
sli.do で質問を受け付ける勉強会、他にも何個か参加したことありますが、
そんなに質問って集まらないんですよね。
質問が集まりすぎて、予定していたタイムテーブルと大きく変わって
19:50〜21:10 までずっと質疑応答の時間みたいになっていました(笑) 楽しかったです。
1. 登壇者紹介
モデレーターは HRBrain の大森さんが担当してくださいました。イケメンですね。
話の流れを意識しつつ、うまく質問をどんどん拾っていってくださいました。
うお、めっちゃぶれてる。ごめんなさい。
スピーカーは左から scouty の千田(ちだ)さん、 HRBrain の中野さんでした。
2. リファーラル採用の話
2-1. 「全員が採用担当」の意識作り
まずは採用の話。
scouty さんは 40% がリファーラル、40% が自社サービスである scouty を使用しての採用とのこと。
scouty さん自身も scouty を活用しているんですね(笑)
scouty さんも HRBrain さんも共通して意識しているのは、
人事が頑張って採用するというよりは、 全員が採用しようというマインド とのこと。
これは以前書いた採用失敗談の記事の『4-2. リファーラル意識の薄まり』の逆ですね。
では、そのために何をしているかと言うと、
scouty さんの場合は、良い会社にするのがまず一つ目に取り組むべきところである、とのこと。
「良い会社」の定義は glassdoor の評価軸が参考になるとのこと。
- 友人に勧めたくなる
- 経営者が信頼できる
- 事業の将来性に期待できる
の3軸ですね。
もう少し詳しいところは、千田さんの書いたリファーラル採用に関する記事の
『メンバーロイヤリティ（動機づけ軸）』のところをお読みください。
「友情」が崩れないことを大切にするため、
リファーラルでの候補者の選考には紹介者を一切関与させないことを明言する、などと心揺さぶられることが書かれています。
「全員が採用担当」のマインド形成として、他には「全員でやるぞ」って上の人（経営者）がみんなに言う、っていうのもありました。
すごく素朴なやり方のようで、私はこういうのは大切だと思っていて、経営者はみんなにどうしてほしいかを常に発信できると良いと思っています。
それによって、何が期待されているかを社員は知ることができるし、経営者のなってほしくないネガティブな企業文化になってしまうことを避ける効果もあると思います。大事です。
scouty さんは月の売上が一定数を超えると全員の給与が上がるという制度を設けており、
採用がその人の給与を上げることにつながる（紹介した人が採用されることによって事業が伸び、結果としてみんなの給与が上がる）ということが伝わるといい。というモチベーション作りもおこなっているようです。
中野さん「リファーラル報酬というのが最近は一般的になったので
とりあえずで導入してしまう企業も多いけれど、
まず、どう嬉しくなるかなどが社員に伝わるよう、動機付けの設計をするのが大事」
ちなみに scouty さんはリファーラル報酬を設定していないそう。意外！
「友人がいい会社（scouty）に入って幸せになってもらいたい」というモチベーションで行動してもらえるようにしているとのこと。
2-2. リファーラル採用に関する質問
Q. エンジニアって、どういうモチベーションで誰かを採用するんだろう？
私の書いた質問です。
「どういうモチベーションでリファーラルするんだろう？」って文章が正しかったですね……。
大森さん「エンジニアは常に人手が足りていないので、良いエンジニアを入れることでもっとプロダクトを成長させたい！ というモチベーションを持っていると思います」
Q. リファラルとか全員で採用活動ってなったら、そもそも「人事部」の存在って本当に必要なのか？
肝心の登壇者の回答を覚えていないんですが、この質問おもしろいなあ、と思って取り上げました。
私としては、そもそも人事の活動は採用だけでないってところがあるし、
「採用」に絞ってみても、中長期的な採用計画を全員が考えられるかと言うとそこは専門がいた方がいいし、
採用者の受け入れをどうするか、とか、リファーラル文化の浸透とか、採用イベントの企画とか、Wantedlyなど媒体の運用とか、
やれることは多いので、ある程度の規模の会社ならやはり人事は必要かな、と思います。
Q. リファラルとその他採用で、パフォーマンスや定着の違いはありますか？
これもおもしろい質問ですね。
リファーラル採用での候補者は「事業ビジョン」でなく「人」で会社を選んでしまっているので、定着が悪いのではないか？ とか、
リファーラルだと選考基準が甘くなってしまうのではないか？ という懸念からの質問だと思います。
千田さん「リファーラル採用での候補者も、選考のプロセス自体は変えていなく同じ基準なので、パフォーマンスや定着については変わらない感触です」
3. 評価制度の話
3-1. 1on1 のあり方
HRBrain さんでは、自社サービスの HRBrain を用いて、 1on1 管理をおこなっているそう。
1on1 の際に、1on1 をする両者がメモを取る仕組みになっていて、そのメモはお互いが見られる。
これによって、話したことの受け取り方の違いが発生している場合に気付ける効果がある。
会場からの質問では、「1on1 で話した内容が記録として残るのは、1on1 の心理的安全性が下がりません？」というものが出たが、
いちおうこのメモは、1on1 の両者間と、あとは役員陣のみしか見られないものになっているそう。
個人的には、社内で共有されると思うと
けっこう 1on1 で話すことを自分の中で制限しちゃうかもなぁとは思いました。
「メモに残してもらいたくない内容は『ここはオフレコで』と言う」とか明文化されてると少しやりやすいかもしれません。
メモを残すこと自体は良いと思うので、気持ちよくおこなえるための合意形成が大事になってきますね。
1on1 は頻度を多くやって、被評価者に短いタームでフィードバックを返せることが大事で、
仮に成績が悪いとしたら、「これ出来ていないよね」を早めに伝えることで、
期末時の査定が被評価者から見て「なぜか低い！」という驚き（ネガティブサプライズ）を起こさない効果がある。という話がありました。
1on1 についてはちょうど先月記事を書いていますので、そちらも見てもらえると嬉しいです！
3-2. マネージャーのあり方
中野さん「自分が頑張るより、自分と同じくらい出来る人を2人作れたほうがよっぽど素晴らしいよね？ ってのを昔から考えています」
育成に先行投資をしよう、という話がありました。
1on1 はそのための1つの活動ですね。
しかし育成で難しいのは定性的評価、つまり、何が出来る状態なら育成完了したと言えるかの部分。
HRBrain の中野さんは、育成の完了状態を「自走できる状態」とし、
「上司に確認せずとも、上司がやってほしいと思っていることを勝手に自分でやれる状態」と定義しています。
たしかにこの「自分で判断できる状態」になるまでってけっこう時間かかりますけど、
それが出来ると一気に業務がスピードアップしますよね。育成大事ですね。
HRBrain のおもしろい点として、目標を共有する設定にも出来るそう。
成果を出す人というのは得てして、やるべきことが明確化されているため目標設定が上手い。
というのが中野さんの話で、目標設定を共有することで、
上手い目標設定を見ることができたり、マネージャーに将来的になりたい人がマネージャーがどういう視点で考えているのか見られたり、
学びの効果を得られると話していました。
なるほど、現在うちのチームで目標設定を共有しているのは
「他の人がどういう目標を立てているのか知って、全員が目標達成をできるよう支え合ってほしい」という願いでしたが、
そういう効果も望めるというのは考えていないところでした。良さそうです！
全社的に目標設定を共有したくなりました。
3-3. 10段階評価
HRBrain さんでは事業目標の達成度と、会社のバリューの体現の2軸を 5:5 の配分で評価しているそう。
昔は5段階での評価でしたが、5段階だと被評価者が4点をつけたときに評価者が3点とは付けにくい気持ちになる（20%違うので）問題があったため、
ざっくり5つに分けた評価基準をさらに2分割した10段階評価にすることで、点数を付けやすくしたそう。
このスライドには載っていませんが、
「チームにポジティブな影響を与えるほど体現している」や「体現している」の具体例がそれぞれ数個示されていると、
点数付けはよりおこないやすそうですね。
点数付けは被評価者も評価者も頭を悩ませるポイントですので、
基準は詳しければ詳しいほど良さそうです。
4. ふりかえって
聞いたことのなかった考え方もありましたし、質問がたくさん飛んでとてもいい会でした。
質問がありすぎて、スライドが用意されていたのですが、ほとんど使われませんでした(笑)
途中途中で参考資料として使われたこのスライド、
おもしろい情報も載っているので「公開してほしいな〜」と聞いてみたら、
後日メールで案内されるそうです。わーい！
届いたらここにも貼り付けようと思います。
さて、connpass での応募時にも書いた、とても気になっていた疑問がありました。
Q. 人事自体の目標管理ってどうすればいいですか？（採用人数をKPIにしてしまいがちだけれど……）
これに対しての中野さんの回答は、
「人事は組織のパフォーマンスアップのために人を適材適所にあてるのが一つの仕事。
だから例えば、適材適所にあてるための施策を作る、というのは一つの目標設定になりうるのでは」という話でした。
なるほど、と思いつつも、じゃあその施策の良し悪しはどう判断するのか？ とか、施策を作るだけ（アウトプットが見えるものだけ）が人事の仕事なのか？ とか、
定性的で納得感ある評価をおこなう観点では、まだまだ考えられるところはありそうです。
千田さんがめちゃくちゃ回答に窮していましたけど、実際これは、そうとう難しい問題なんだなあと思います。
もしかすると、総務や人事といった、業務範囲が多岐に及ぶ業種の評価に
目標設定（MBOやOKR）を使うというのがふさわしくない可能性もあります。
必要な業務スキルを書き出しておいて、評価時はそれらのマスター度をスコアにする成長評価とか、
360度評価を使うとか、そういう考えも全然あると思います。
『制度をリリースしたあと、社員からどんなポジティブ・ネガティブな声が出て、それをどう軌道修正をしていくかの方が大切』と、
『デキる人事はどう動くのか？ 人事のプロが語る、強い組織のつくり方』の記事でも触れられていますし、
評価制度に正解がないことは常に意識しつつ、
現場にとって今なにが最良か考えながら、評価制度をプロダクトのごとく常にアップデートさせていきたいですね！！
*1:2019年春より、社名およびサービス名が「scouty」から「LAPRAS」に変わります https://thebridge.jp/2019/03/scouty-is-gonna-be-a-lapras
1on1 で何を話すか？
マネジメント系の記事を書くのってけっこう久しぶりなんですね。
【過去の】
- https://hatone-hr.hateblo.jp/entry/yamenai-saiyou
- https://hatone-hr.hateblo.jp/entry/what-needs-engineer-manager
- https://hatone-hr.hateblo.jp/entry/engineer-managers-log
私としてはリーダーをやってもらいたい方がいたので、
2月にリーダーのポジションはその信頼できる人に託し、
あとは困ったことがないか時々聞く隠居の身となったのですが、
1年やったまとめとして書いておきます。
でも基本的には、『ヤフーの1on1』を読むのが一番わかりやすいです(笑)
たまに読み直さないと忘れてしまうのですが、ここには大事なことが多く書かれています。
ヤフーの１ｏｎ１―――部下を成長させるコミュニケーションの技法
- 作者: 本間浩輔
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/04/28
- メディア: Kindle版
- この商品を含むブログを見る
以下は、私個人の考えを多く出しています。
『ヤフーの1on1』では 1on1 の目的を「部下の成長のため」と定義づけているので、
のっけから異なっています。
1. 1on1 はどうしてやるのか？
一言で言うと お悩み相談室 です。
お仕事に集中できるように、障害は私が取り除くよ！ というわけですね。
マネージャーってチームに対しては奉仕種族でいるのがいいですね、たぶん。テケリ・リ、テケリ・リ。
でも、大事な問題があります。
あなたは悩みを相談するのに値する人なのでしょうか？
この問題を解決するために、あなたは「赤の他人」から
「信頼できる仕事仲間」にまでステップアップしなければいけません。
2. 日常会話をしよう
すごく簡単ですね。
「週末どうしてた？」みたいな。
これすら相手が言いよどむようなら、相手からの信用はまだ得られていないので、
お悩み相談どころではありません。
もっと相手のことを知って仲良くなりましょう。
と言ってもそれがけっこう難しかったり。
専門の書籍に頼りましょう……。（下記の本は読んだことありませんが評判良さそう）
- 作者: 岩崎一郎
- 出版社/メーカー: クロスメディア・パブリッシング（インプレス）
- 発売日: 2012/02/14
- メディア: Kindle版
- この商品を含むブログを見る
3. 相手の話をよく聞こう
会話に割り込むのやめましょう！
たまにそういう人いるので最初に……(笑)
1on1 に限りませんが、相手が永遠にとめどなく喋り続ける人でもない限り、
相手の言葉を切って話し出すのはやめましょう。
「人の話を聞かない人」という印象を相手に与えます。
相手がひと通り話し終わったあとに一呼吸置いて「なるほど…」と返すくらいが、
1on1 の会話としてはちょうどいいくらいです。
また、あなたが何か質問して相手が答えを考えるときも待ちましょう。
30秒くらい無言の時間になることもありますが、放送事故とかはないので、
口を挟まないように気をつけ、ゆっくり相手に考えてもらうようにしましょう。
1on1 の場では、障害解決のために相手の問題解決能力を高めるのも大事なので、
熟考の機会を阻害してはいけません。
問題解決のために熟考する習慣を作るのは、相手にゆくゆくはリーダーを任せるためにも大事です。
（全員がリーダーになり得るようなチームになっておくのが大事ですからね！）
4. 自分の悩みを相談しよう
悩みを相談するというのは、「あなたを信頼していますよ」という気持ちの表れです。
あまり悪い気がするものではありません。
ですので、こちらからも悩みを相談しましょう。
特にチーム作りに関する話などがいいです。
これは上の話とつながっていて、相手にゆくゆくはリーダーを任せるために、
「あなたがリーダーだったらどうするか？」という趣旨の質問を投げかけられるからです。
例えば、「今期のマイルストーンにこのタスクを含めるか迷っている」だとか「チームみんなの給与を上げるにはどうすればいいんだろうね？」とか、
リーダーになったら考えるようなことを投げかけてみてください。
相手も一生懸命考えてくれ、視野になかったアドバイスをくれるので、
お互いの成長のためにもこれは有意義です。
5. 相手の顔を見よう
メモを取るのに夢中になって、話してる相手の顔を見ない人がたま〜にいますが、
これは「何も話を聞いてくれない」印象を強く出してしまうので避けたほうがいいです。
とはいえ、メモを取らなかったばかりに 1on1 の内容を全て忘れるようでも
それこそ何も話を聞いてないのと一緒になってしまいますので、
メモは 1on1 のあとにササッとまとめるか、「1回ちょっとまとめていいかな」と相手に断ってPCに打ち込むなどするといいと思います。
6. 相手の悩みには必ずアクションをとろう
相手が今困っていることや悩んでいることを相談してくれたとしましょう。
それだけの信頼は得られているということです。幸せものですね。
ことの大きさによっては相手に「相談してくれてありがとうございます」と言ったほうがいいですね。
さて、せっかく悩みを話してくれたのなら、
相手に「結局この人は何も解決してくれない」と落胆させないよう、
出来るだけの行動をする必要があります。
行動する前にはまず、問題の本質を知らないといけないので相手の話を深く掘り下げましょう。
ここは『ヤフーの1on1』の第１章を読むのが一番よくわかりますのでそちらに譲ります。
問題に対するアプローチが見えてきたら、「じゃあこうしましょう」という話になると思います。
それは、相手だけで解決できる問題かもしれませんし、
あなたが別の人に話しかけないと解決できない問題かもしれません。
あなたの行動を必要とする解決法であるなら、あなたはすぐに行動し、
そしてそのアクションをすぐに逐一、相手に報告しましょう。
解決に至るかまではわかりませんが、その行動が、
相手の次の悩み相談のしやすさにつながるので、大切にしてください。
7. その他の話
上では「悩み相談」の部分にフォーカスしすぎましたが、
今後のキャリアをどうしたいか はそれとは別に話しておいたほうがいいですね。
相手の今後の成長のためにも、マネジメントのためにも。（タスクの割り当てとか、長く会社にいる予定かの予測のためなど）
「まだわからない」って答えの人も多いと思いますが、それならそれでいいと思います。
そんなにすぐ見つかるものでもないので、
1on1 で適当な決め方して相手の視野を狭める必要はなくて、
「今はどういうことしたいか？」の漠然とした希望があるかだけ聞ければ充分だと思います。
あと、1on1 に関する記事で「1on1 はタスクの確認をするところじゃない」なんて書かれ方をしているところがあって、
まあ、それももっともなんですが、今やってるタスクの話から悩みの話がふっと湧いてくることもあるので、
特に日常会話が思いつかなければタスクの話とかしていてもいいと思います。
8. 1on1 の場所
「会議室が取れない問題」というのがあります。
でも、本当に会議室でやらないといけないのでしょうか……？
私の場合、1on1 を受ける側だったとき、
会議室でやると圧迫された雰囲気を感じて話しにくかったことがあります。
1on1 は話しやすいことが一番ですので、必ず会議室という必要もないと思います。
たまには会議室以外の、あまり他の社員に話を聞かれないような場所で話してみるのもいいかもしれません。
Yahoo! の場合ですと、喫茶店での 1on1 は経費で落ちるそうです。
2杯のコーヒーで1000円くらいですから、あらかじめ経理と相談してその方向で行けるか検討してみるのもいいですね。
9. おわりに
というわけで、1年のリーダー経験を踏まえてわかってきた 1on1 の話でした。
やっとわかってきて言語化できたのはよかったんですが、
最初に書いたようにリーダーを託したのでもう 1on1 をしないという問題が……(笑)
くだらない話が好きすぎて、
日常会話で 30 分を終わらせていることも多い私ですが、
ここで書いたことをもう少し意識すると良いんじゃないかなと思いました！
悩みを相談するのに値する人でいたいですね。
