話しをきく
(この記事は Sansan Advent Calendar 2016 - Qiita 8日目の記事です。
技術系の記事にはさまれてますが全然違うことを書きます。)
みなさん、コミュニケーションは得意ですか?私は苦手です!
しかし、苦手意識というのは人を成長させるもので、私も昔よりはコミュニケーションが上手くなっている実感があります。エンジニアにとってコミュニケーション力は生命線。今回は対面でのコミュニケーションにおいて、特に「話をきく」側として、自分がどんなことを実践しているかを振り返ってみました。
「話をきく」ということ
まず、話をきく目的を整理しましょう。
場には話し手と聞き手がいるので、双方にメリットがあるはずです。まず聞き手にとっては「話し手から新しい情報を授かること」があるでしょう。一方、話し手にとっては「聞き手と会話することで新たな気付きを得ること」があると思います。ラバーダッキングという言葉もありますね。あるいは、単に「楽しむこと」もあるでしょう。
ということで、聞き手として上記の目的に寄与するためには、
- いかに話し手から情報を得るか
- いかに話し手に新たな気付きを与えるか
- いかに会話を楽しむか
が大事だと言ってよいでしょう。ここからは、私が実践していることが、それぞれ上記をどう達成しているかをみていきます。
相づち
なるべくバリエーションが豊富になるようにしています。そのほうがより会話が盛り上がる気がします。定番は「はい」「ええ」「うんうん」「なるほど」あたり。これらは、話を順方向に進ませるものです。話のスピードを上げたいときは、この相づちのスピードもテンションも上がります。オウム返しも有効とよくいいますが、場合によっては「その表現であってる?」ってニュアンスになりかねないので、万能ではないと個人的には思います。
一方で話を別の方向にもっていきたい、あるいはその場に立ち止まりたい場合があります。そのときは「ん?」と疑問を表明したり、「えーと」と、「自分の解釈を確認しようとしている」意を表明したりします。または「んー……」のように、「理解しようとしているが、別の表現で説明してもらいたい」ことを匂わせることもあります。
これらは、このように文章で読むと「いや、そんな回りくどいことせずに言葉で伝えろよ!」という思いにもなるでしょうが、会話をしている間はそこに論理があるわけではなくて、そのときのモヤモヤした気持ちをいま言語かするとこのように表せる、ということです。また、「んー……」といって相手からリアクションがなければ「別の表現で説明するとどうなりますか」と聞きます。つまり、相づちで相手がこちらの (形になっていない) 意思を汲み取ってくれたら儲けものくらいの感覚です。
どうやら (私にとって) 相づちは「いかに話し手から情報を得るか」を重視しているようですね。 +α の要素として、会話が盛り上がることで「いかに会話を楽しむか」にも関わってきそうです。
うなづき
話し手が一人で聞き手が複数人の場合に多用します。一人が全体に向かって話すというのは不安なものです。そういうときに「聞いてます、理解しています」とサインを出す人がいたら話し手は安心しますよね。
ただし、あまり回数が多いのも話し手にプレッシャーを与えるのではないかと思っています。うなづきは、話が順方向に進むのを期待していることの表明です (だと僕は思っています) 。なので、例えば「現在こんなタスクをやっています」という話をしているときに「でも実は結構遅れてて……」という話を切出しづらくなるんじゃないかな、という仮説を最近たてています。
また、話し手が明確に同意を求めている場合、例えば「~と思います。よいでしょうか?」と聞き手に投げかけている場合は、うなづきよりも声に出したほうが良さそうです。
こうしてみると、うなづきは上述の目的にイマイチはまらないですね。一対多を想定しているので一方向のコミュニケーションが前提になっているからでしょうか?一対一におけるうなづきについても、考えてみる余地があります。
質問
質問はコミュニケーションにおいて大変重要だと思っています。先に目的の話になりますが、質問は聞き手の理解に繋がるのは当然のこと、話し手も質問されてみて初めて気づくことも沢山あるでしょう。
質問にもいろいろ観点があります。「話し手が伝えたつもりでいるかどうか」「いまの話に沿っているかどうか」「聞き手が実は答えを知っているかどうか」「オープンかクローズか」などなど。……ここまで書いてみましたが話が広がりすぎるのでやめときます。
どんな質問をするか、については、あまり深く考えていません。まだギリ若手の部類に入るので非常識な質問をしても良いと思っています。
一対一のときは、タイミングを重要視しています。あまり頻繁だとスムーズさが失われますし、最後にまとめて、だと途中の会話が無駄になったりします。話が行き詰まりそうなポイントに差し込むのが理想かなと思います。
質問については↓の本が面白かったので載せておきます。
笑い
基本的に、笑えるタイミングがあったら笑うようにしています。周りの人からは「よく笑うよね」と言われます。やっぱり笑いは場を和ませる効果がある。エンジニア同士でも、「こんなバグがある!」ってときに「マジかよ……」となるか「マジかよwww」となるかで違いますよね。
プレゼンなんかの場合は、「ここで笑ってほしいんだろうけど、イマイチ笑いづらい」ポイントで積極的に笑うようにしています (スベったらそれはそれで面白いパターンもあるのでそういうときは避けますが) 。こういうケースって結構あって、面白さは聞き手に伝わってるんだけどオチが先にスライドに出てるとか、笑うタイミングがわかりづらいっていう状況ですね。一人が笑うと話し手も安心するし、他の聞き手も笑いやすくなる。
ただし、あえて笑わないようにすることもあります。最近たてている仮説ですが、笑っている瞬間、人は頭を使っていないのでは?という考えが背景にあります。振り返ってみると、とくに周りに人がみんな笑っているときは笑わないようにしている気がします (飲み会とかは別ですが) 。もしかすると、「みんなが笑っている間に頭を使うと、みんなが気づいていないことを指摘できる」ということを経験的に知っているのかもしれません (文章にするとめちゃめちゃ気持ち悪いですね) 。これについては今後むきあっていきます。
以上、きわめて内省的な記事でしたが、最後まで読んでくださってありがとうございました。あなたはコミュニケーションでどんなことを実践していますか?
HttpClient と using
C# の REST クライアントといえば HttpClient
。コイツは IDisposable
の実装なので、例えばこんな感じで using
したくなる。
public class MyClient { public async Task<string> Get(string url) { using(var client = new HttpClient()) { var response = await client.GetAsync(url); switch(response.StatusCode) { // ステータスで処理分けたり } return await response.Content.ReadAsStringAsync(); } } }
しかし…… HttpClient
は Dispose
されてもコネクションが残ってしまうようだ。そしたら using
はバッドプラクティスだ。
http://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
スレッドセーフらしいので、こんな実装で回避できる。
public class MyClient { private static readonly HttpClient _client = new HttpClient(); public async Task<string> Get(string url) { var response = await _client.GetAsync(url); // 中略 return await response.Content.ReadAsStringAsync(); } }
もう一歩進むと、どうやらコネクションプールの管理は HttpClientHandler
がやってるらしい。コイツを static readonly
にして、HttpClient
のコンストラクタに渡せば、堂々と using
できる。第2引数は、HttpClient
が Dispose
されたときに HttpClientHandler
も一緒に Dispose
するかどうか。使いまわすなら false
。
public class MyClient { private static readonly HttpClientHandler _handler = new HttpClientHandler(); public async Task<string> Get(string url) { using(var client = new HttpClient(_handler, false) { var response = await client.GetAsync(url); // 中略 return await response.Content.ReadAsStringAsync(); } } }
非同期周りもハマりやすい HttpClient
、なかなか曲者だ。
MemoryCache でアプリケーション内キャッシュ
System.Runtime.Caching.Cache を使うと、アプリケーション単位にデータをキャッシュさせることができる。
Web サーバー起動時にデータを読み込んで永続化させたい時などに便利だ。
string GetContent() { var cache = MemoryCache.Default; var content = cache["content"] as string; if(content != null) { return content; } // キャッシュされてなかったら元データを取得してキャッシュする var policy = new CacheItemPolicy { absoluteExpiration = DateTimeOffset.Now.AddSeconds(100); }; return cache.AddOrGetExisting("content", ReadContent(), policy); } string ReadContent() { // DB とかファイルから読み込んで返す ... }
CacheItemPolicy
キャッシュ エントリーの有効期限などを保持する。
特に指定しない場合はキャッシュは削除されない。
削除された、または更新されたときのデリゲートを指定することもできる。
AddOrGetExisting
上記の例では content というキーでキャッシュを保存している。
このメソッドは、このキーで値を書き込みにいくが、すでに書き込まれていたらその値をそのままとってくる、というものだ。
Atomicity を担保するためのメソッド。マルチスレッドじゃなかったら Set でよい。
ConcurrentDictionary の GetOrAdd みたいなもんかと思ったがちょっと違った。
SI から Web に転職して半年が経った
ので、「よくある SI への不満」に対して、現状がどうなっているかを考える。 私は、 SI が嫌で嫌で辞めた……というクチではないので、そういう人たちの為になるかどうかは自信がない。
最新の技術、開発環境が利用できない
- 最新の技術ガンガン使っていこう!という会社じゃない。
- 私は、技術については新しいものに興味がないので不満はない。入社前からそのつもりだったので、ギャップもない。
- 開発環境については、 GitHub とか Slack とか、いわゆるモダンな環境で開発できてる。
- とはいえ、ツールの運用どうするん?とかの話はある。そのうえで、課題が挙がる度に改善できてるので、良い環境だと思う。
- 技術的負債との戦いは避けられない。
コード書けない
- 書いてる。
- コードレビューしあえる環境はマジで素晴らしい。
エクセルがクソ
- クソだけどたまに使う。
- テストケース作ったりするときはやっぱり便利。
- エクセルで設計書作ったり、はさすがにしない。
- ドキュメントはもっと残してもいいと思う。
ウォーターフォール(のような何か)がクソ / 客の言いなりになっちゃう
- 企画をするチームが開発チームと別にあるので、ウォーターフロー的ではある。
- 最近スクラムに移行してきた。
- 企画チームに意見をぶつけることはできるので言いなりとまではいかない。
- やってるサービスの性質から、エンジニアがユーザ視点をもちづらいので、企画は専門のチームに任せることで妥当な気がしている。
- 「納期は絶対!」って感じはない
- 間に合わなくなっても後からコントロールできる。
- とはいえプライドの高いエンジニアが多いので、メチャメチャ残業してる人もいる。
ユーザとの距離が遠くてやりがいがない
- B to B のサービスなので直で意見を聞ける機会はそんな多くない。
- 営業とかの人の話を聞いて補完してる。
- 営業の人たちのアツさはなかなか SI では味わえないんじゃないだろうか。
いわゆる「木こりのジレンマ」
- 社内勉強会とかもそこそこやってる
- 社外勉強会に行く人もそこそこいる
- 技術書読んでる人もそこそこいる
- けど思ってたより少ない。前職よりは多い。
エンジニアとコミュニケーション
前職で学生と面談するとき、次の質問が非常に多かった。
「エンジニア(SE)にはコミュニケーション能力が求められると言われるが、何故か?」
答えやすい回答としては「プロジェクトはチームで進めるものだから」がある。私も就職活動中にいろんなエンジニア(や人事の方)に上記の質問をしたところ、このように回答いただいたことが多かった。
だが、この回答は本質ではない気がしている。
もちろん、チームで物事を成すために、それぞれの人間性を掴む、空気を読む、気を遣う、という能力も円滑なプロジェクト推進の助けにはなる。しかし、私が質問した皆様も、それ以上に開発特有の何かを感じているはずだ。
開発は、具体化だ。曖昧な要件から、具体の塊であるシステムを生み出す。その架け橋となるのが人間同士のコミュニケーションだ。すなわち、コミュニケーションは曖昧性を取り除いていく役割を担っているわけだ。ここで必要となる能力は、「他者との関わりの中で曖昧性を明らかにする、その曖昧性を取り除く手段を考案し共有する」能力、等となろう。前述の「空気を読む」といった能力とはむしろ真逆だ。「空気を読む」とは、曖昧性をあえて残したうえで他者と共感することだからだ(これらの能力を使い分ける必要があるのも難しいところかもしれない)。
つまり、冒頭の問いに対する答えとして、私は「曖昧性のないコミュニケーションが求められるから」と言いたい。
CodeIQ感謝祭 春のエンジニアまつり
【Jason Danielson氏登壇決定!】第3回CodeIQ感謝祭「春のエンジニアまつり」 #codeiq39 : ATND
行ってきた。
講演者も懇親会も豪華。この規模のイベントを来場者無料でできるのがスゴイ。 どうやってスポンサーに営業かけてるんだろうな。 求人でマッチングしやすいのはあるだろうけど。
以下、Markdown を垂れ流します。 パネルディスカッションは話に熱中してメモとってなかった。。 日本dis感が強すぎた感はあった。
及川さん 情報共有から始めるチーム開発とキャリア戦略
情報共有の歴史
- 情報+人間がどう思っているか=知識、知恵
- 共有フォルダーだけでは知識を共有できなかった
- SECIモデル 形式化と共有
- 業務効率化→知識共有と協調作業
- CSCW グループウェア
- メディア的な共有 図面とかリアルタイム
- 電子メールでのワークフロー、これに合わせて人間が動きましょう
- そしてLotus Notesへ
- 今も研究はされてるよ 学会もやってるよ
情報共有と組織
- ツール使ってるけど情報共有すすんでるの?
- 情報漏えいへの不安
- メリットへの疑問
- システム、ルール、文化から決まる
- システム、ルールだけで縛ると破られる
- 画面を写真とったり
- システム、ルールだけで縛ると破られる
- 文化をどうするか
- Google: Share everything you can
- 社内での履歴書を書いてく
- コード
- 週報
- Slack
- ツールは人が好きな様に使われる
- そしてリモートワーク
- 通路での立ち話、Slackに書くのも面倒だよね
- メンタルモデル、メインオフィスがあってそこに個人がぶらさがるのでなく、全部がそれぞれにぶら下がるようになってないといけない
キャリア
- 中から外へ!
- 社内だけじゃなくて社外
- アウトプットから考える(持ってるものをアウトプット、ではなく)
澤さん プレゼンの話
- プレゼンは三層構造
- ビジョン: Why なんのため?
- 核: What なにをつたえる?
- 話術: How どうやって?
- 人に何か伝えるのはすべてプレゼンだよ
- ビジョンとスコープ
- ビジョン:理想の形、変更不可 決めるまで時間かけよう、チームだったら共有しよう
- プレゼンが終わったら、聴衆にどうなっていてほしい?
- 行動してもらわないと意味が無いよね → 未来が描かれてないといけない
- 報告と連絡は過去、相談は未来。相談(時間と空間を共有)もっとしっかりやろうよ。
- スコープ:各タスク、変更可能
- ビジョン:理想の形、変更不可 決めるまで時間かけよう、チームだったら共有しよう
- 核:聴衆が他の人に説明するときに1文で説明できるもの
- 言語化のプロセス
- 他の人に教えたくなるか?
- 伝言ゲームで内容が変わらないものこそ強い
- シンプルに!
- 数字は強調しよう
- 詳細は別の資料にしよう(読ませる!)
- アクションを言語化
- 誰が何をいつまでに
- 当事者意識。
- スライドテク
- 1枚にテーマ1つ、説明3つ
- アニメーションは視点誘導のためだけに使う
- 画面は意外と広い
- 書き過ぎない
- 文字を際立たせる(色で囲ったり)
- キーワードで画像検索するとイメージ広まるよ
- Photo AC
- 「最後に」スライド
- 印象付け、時間調整、途中参加の人も安心
- 話術
- 口癖を意識しよう
- 「簡単に」だけだったら同じ言葉だけだと薄くなる
- 腹筋を意識
- そうしないと姿勢が崩れる
- 均等に顔を見よう(じゃないと目が泳いでるように見える)
- アイスブレイク
- ちょっとずれた表現を使う
- おおげさにいう
- 部分的話しことば
- ユーザーの話ならそのユーザーの話し言葉で
- スライド飛ばすときは1ページずつ送ると余裕がなく見える
- ちょっとずれた表現を使う
- 話す速度よりゆっくり歩く(慌ただしさがなくなる)
- 聴衆は見方だよ!
Jason Danielson
- やりたいことやれよ
- なんかやるんだったらなんでやるのか考えろよ
2015年に読んだ本から再読したいものを5冊挙げる
40冊ちょいから5冊選んだ。観点は「再読したい」なので、「面白かった」「勉強になった」とは少しずれる。
熊とワルツを - リスクを愉しむプロジェクト管理
リスク管理。なんでリスク管理やらないといけないの?という話から、方法論の導入まで。結果的にうまくいったプロジェクトは正しくない!「やればできる」はクソ!意識づけが大事。次はもっと実践的な本にも手を着けたい。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
言わずもがな。トイレとかに置いてパラパラめくりたい。
CODE COMPLETE 第2版 下 完全なプログラミングを目指して
上巻よりエモい!パフォーマンスチューニングやデバッグの話からマネジメントの話まで。Amazonレビューをみると「上巻とは切り離せない」とかあるがそんなことはなく、別物としてもよいだろう。あとやっぱり内容が古いし定価が高いんで、盲目的に「プログラマは全員読むべき」ってのは正しくないように思う。
仕事は楽しいかね?
目標をもつのが必ずしも正しいわけじゃない。ぼんやりとした考えをより強固にしてくれた本。迷ったら読む。
小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
自己啓発に最適。なんなら1ページごとはがして部屋/職場のいろんなとこに張っとくのがいいんじゃないか。
今年読んだ本はエモい側に寄りすぎた感がある。。堅い本も買ったけど半分くらいで挫折したものも多い。細く長くでいくか、時間とって読み上げるか……