Disculpa, pero esta entrada está disponible sólo en 日本語 y English.
雑談の仕方 どうやったら雑談できるのか
どうやったら雑談できるのか。 雑談力を上げるセミナーに行ってきました。 数人での雑談を前提に、どのようにすれば雑談できるようになるのか、聞いてきたことをアウトプットします。
話のできない人の共通点
話ができない人には共通点があるそうです。
他人 の話を聴いていない- 評価をやけに気にする
- 沈黙が嫌い
どうしよう！？ っていう戸惑いが出てくるんですね。 言い換えるならば、 自分がどうするのかということにフォーカスしています。 つまるところ «何を話せばいいのか» というのが最大の課題になっているのではないでしょうか。 私もそのひとりなのですが。
何を話せばいいのか
話すことが決まってしまえばあとは楽なんですが、話すことが決まらないからこそつらいんです。 そんな課題を解決するためには、考え方を変えましょう。
知りたいことを聴く
相手について「もっと知りたい」と思うことを聴きましょう。 自分が話さなくてもいいんです。 これで、話のスタートができますね。
トップ営業マンと言われる人たちに共通していえるのも、知りたいことを聴いているということです。 知りたいことを聴くと 他の人が知らないことも知ることができるようになり、 営業成績につながっていくそうです。
雑談の聴き方
さて、話のスタートはできるようになりましたが、どうやって聴けばいいんでしょうか。 聴き方 にもコツがあります。
- 相手がどんなことを考えているか、想像しながら聴く。
- 他人のいいところを見つけるつもりで聴く。
この中に「相手の言っていることを正確に聞き取る」なんてことは入っていません。 言葉や文字ではないんですね。 私は過去に営業部の課長から「言っていることをそのまま聴くんじゃなくて、相手の意図することは何かを考えて聴け」と言われたことがあります。
雑談をする上でまず大切なのは、「相手がどんなことを考えているか、想像しながら聴く」ことです。 相手と同じ視点に立つことで、相手の言っていることも理解しやすくなり、共感しやすくなるんですね。
また、いいところを見つける習慣をつけておけば、挨拶として使うこともできるようになるのでおすすめです。
相手の話に興味が持てない時は、自分にもメリットのある話だと思って聴くのがいいそうです。
行動で雑談を楽しくする
雑談を更に面白くする方法があります。 雑談といっても文字で書かれた文章とは違って、その場で表現されるわけですから、視覚的な要素も重要になってきます。 方法を2つ紹介します。
相手が見たい顔をする
相手が見たい顔ってどんな顔でしょう。 それは笑顔です。 あたりまえですけれど、今一度考えてみましょう。 挨拶するとき、話をするとき、相手が笑顔だったら話しやすくなりませんか？ こちらが笑顔でいることで相手も話しやすくなり、円滑に話ができるようになります。
聴いていることをアピールする
これは講師から聞いた話ですが、過去にディズニーのキャストをしていた人のリアクションは «そこまでやる！？» と思うほどのオーバーリアクションだったそうです。 でもやりすぎってことはないそうです。 特にパーティーの席や合コンなどではそこまでやらないと埋もれてしまいますね。
こういったことは反応心理学として研究もされています。
以上、セミナーの内容をまとめてみました。
テスト駆動開発の基本とメリット
同僚の勧めで Test-Driven Development By Example を読むことにしました。 書いたのはあの Kent Beck です。 日本語のものもあるのですが、そちらは絶版になっているので買うなら中古です。
この本では具体例が示されていて、どのようにテストができていき どのようにコードができていくのかがよくわかります。 まだ最初のほうしか読んでいませんが、他人(Kent Beck)のテストの書き方がわかるので、自分のやり方を見直すよい機会になります。
Test Driven の基本
Preface のところに Test Driven の基本ルールが書いてあります。
- 自動テストに失敗するまで新しいコードを書かない。
- 重複は排除する。
テストで失敗するまでコードを書いてはいけません。 これに関連して よくはまる落とし穴に、「テストコードのテストコードを書く必要はないのか」というのがあります。 これについて 同僚は次のような説明をしてくれました。
自動テストがないときはどうやってテストしていましたか？ (PHPの場合) var_dump などでテストをしていたと思います。 テストコードのテストコードというのは、 その var_dump と 目視 のテストを書くってことと同じことなんですよ。 テストコードそのものの正しさは開発者が担保するようにして進めるんです。
わかったようなわからないような説明かもしれませんが、要するにそんなこと言っていたらきりがないからテストコードは開発者のチェックとコードの間に入れる保険なんだと思います。 またテストコードのバグについてはじゃんじゃん直していいそうです。
そして Kent Beck はコードの書き方について重要な方針を書いています。
自分の書いたコードのテストは自分で書こう
これ重要ですね。 この本をバイブルってことにしておけば、自分で書いたコードのテストは自分で書いてくれって言えますからね。 Red / Green / Refactor の順でやろうと思ったら自分で書くしかないんですけどね。
テスト駆動・自動テストのメリット
開発現場では往々にして「自動テストなんてやって意味あるのか」「時間がかかるだけじゃないのか」という議論が勃発します。 地位の高い人がそういうことを言い出すとどうしようもなくなったりします。 モチベーションにも繋がるところなので 自動テストのメリットを再確認しましょう。 本書では social implications として4つのことが書かれているのですが、それを仕事上のメリットとして書くと次のようになります。
- 汚いコードの密度が減り、品質保証は受け身の仕事じゃなくて能動的な仕事になる。
- 自分でコードを書くことが品質保証に繋がるので、問い合わせを受けてから手を動かすようなものではなくなります。
- ドッキリするようなコードに遭遇することが減り、マネージャの見積もり精度が上がる。
- 開発者のみならずマネージャにとっても嬉しいことが起こります。
- 技術的な会話の議題が明確になり、同僚との協力作業の効率が高まる。
- 開発者の能力にもよると思いますが、書籍上ではそういうことが書かれています。
- 汚いコードの密度が減り、新機能の追加されたリリース可能なコードが毎日増えて顧客との関係が向上する。
- 毎日というのは言い過ぎかもしれませんが、バグを見落とすことが少なくなるので新規機能の追加に集中できるようになります。
特に2番目は重要ポイントですね、 テストドリブンとは関係なさそうな人にもメリットがもたらされるので。 どれも理想論に見えますが、テストドリブンの目指すところは上記のメリットです。
この本を読んで今以上にテストドリブンに力を入れていこうと思いました。 中にはテストを書かない人もいるのですが、具体的な進め方も書いてある本なので 他人への説明も楽にできると思っています。