00:04
はい、皆さんお疲れ様です。夕方の5時半になりました。
DevRel Radioのですね、今日は76回目ですね、やっていきたいと思うんですけれども、
今日はですね、ちょっと急遽、録画配信になっております。
私がですね、この放送が流れている時間は、多分電車に乗っているのかな、だと思うので、
すいません、今日はですね、スタジオの方には入れませんので、ご注意をいただきたいと思います。
はい、ということでですね、本当はですね、ライブで、やっぱりこのライブの方が面白いなというのはありまして、
できるだけライブではやっていきたいんですけれども、今日はですね、ちょっとたまたま用事が重なっちゃったので、
これだったらもう、録画の方が早いかなというところで、録画配信に切り替えております。
はい、ということでですね、今日のメインテーマが、私の一冊技術書編というところなんですけれども、
すでにですね、今3件メッセージはいただいていてですね、申し訳ないんですけれども、
これから投稿されてもですね、ラジオの中で取り上げることができないので、その点だけご了承ください。
はい、ぜひですね、何かこう、皆さんに伝えたい私の技術書があるという方はですね、
ハッシュタグ、シャープデブレルJPつけたりとか、あとYouTubeのコメントとか、
Facebookのコメントなどでつぶやいていただけるとありがたいです。
はい、一応ですね、私も多分この配信を聞いてるんじゃないかなと思うんですけれども、
気がつけばですね、コメントぐらいはしたいかなと思います。
はい、まずですね、このデブレルラジオの紹介をしたいと思います。
デブレルラジオはですね、デブレルミートアップイン東京が提供しているネットラジオで、
今日76回っていうこともあるんで、大体1年半ぐらいですかね、やっているネットラジオになります。
デブレルミートアップはですね、デベロッパーリレーションズっていう開発者向けのマーケティングに関して、
情報交換を行うコミュニティとなっていて、例えばエヴァンジェリストとかアドボケイトとか、
あとコミュニティマネージャーとかですね、あと普通のいわゆるマーケターの方とか、
そういった方々が主な参加メンバーとなっているコミュニティになります。
公式サイトはですね、デブレル.東京っていうサイトがありまして、
そこでイベントの情報とか、あとスラックに参加もできますので、
ぜひですね、デブレルに興味を持ったという方はですね、そちらの方から参加いただけると嬉しいです。
最近多分、もうそろそろ700人になるんじゃないかなと思うんですよね。
03:08
今何人だろうな。688人ですね。
688人の方々に参加していただいているスラックがあります。
いつもはイベントはコンパスの方でやってるんですけれども、コンパスの方もですね、
こないだ2000人超えたんですよね、メンバーが。
今2097人の方々がですね、累計で参加いただいているといったコミュニティになっておりますので、
デブレルに興味があるという方はですね、ぜひご参加いただきたいと思います。
Twitterがありまして、アットマークデブレル東京ですね。
ハッシュタグはシャープデブレルJPとなっております。
Facebookもデブレル東京ですね。
あと今この配信はYouTubeでやっているので、いずれかの好きな形でですね、フォローとかいいねとかいただけると嬉しいです。
ということでですね、まず最初のご案内はそんなところで、
まずはですね、今日のメインテーマの私の一冊に関しては最後の方で取り上げていきたいなと思います。
まずですね、最初は最近のデブレル界隈のニュースというのを取り上げてですね、
いこうと思うんですけれども、まずはこちらからかな。
こちらはギガジンさんの記事で、Googleのサービス修了壁が発動と、
今度はIoTデバイス管理サービス、クラウドIoTコアという風に書かれています。
この何でしょうね、思いっきり言われちゃってますね。
Googleのサービス修了壁という風に書かれているんですけれども、
一般ユーザー向けに関してはしょうがない部分もあるかなと。
無料サービスで提供していたりする部分もあるんで、
その意味で継続性に関しては若干疑問視される部分もあるかなと思うんですけど、
今回のこのクラウドIoTコアですね、
こちらはGoogleクラウドのドメイン以下で提供しているサービスなのに
修了するっていうのがなかなかきついなという気がしますね。
いわゆるIoTデバイスの管理サービスらしいんですけれども、
IoTデバイスのモニタリング機能やメッセージの双方向通信機能を提供していましたと。
これAWSでいうところのグリーングラスでしたっけね。
多分それに類するようなサービスだと思うんですけれども、
2023年8月26日をもって修了するという風に書かれてますね。
そうですね、あまりよくはないかなと思うんですけれども、
06:01
レディットの方でいろいろ書かれているみたいなんですけれども、
AzureやAWSの利用者は一言目にはGoogleはサービスを突然シャットダウンしがちと指摘しますと。
Googleが自らの信頼性を高めたいのなら突然のシャットダウンは避けるべきですと。
少なくともGoogleには大量のIoTデバイスを管理する代替サービスへの
シンプルな移行方法を示してほしいものですと。
個人的にはGoogleクラウドプラットフォームを愛していますが、
このようなことがあると同僚にお勧めしにくくなりますといった
Googleのサービス修了を非難する投稿が集まっていますという風に書かれてますね。
これはもうほんとまさにその通りですね。
やっぱりこういうことがあるとなかなか踏み出しづらいというかですね、
自信を持ってGoogleクラウドを使っていこうという気にならなくなると思うんですよね。
SIRとかでもしお客さん向けにこのGoogleクラウドIoTコアを提供していたりすると
お客さんにもその説明しなきゃいけないし、
それで移行にかかるコストって誰が面倒見るんだみたいな話になったりする可能性もあるわけで、
なかなか自信を持って使いづらくなるなという気がしますね。
どうするんでしょうね。
他のサービスとかにも結構波及すると思うんですよね。
どのサービスやっててもGoogleクラウドはIoTコアみたいに突然やめちゃうんでしょうみたいな感じで言われると
全体として損するような気がするんですよね。
それだけにサービス提供するってなったら
継続性の部分とかをきちんと押し測りながらやっていかないといけないなと思うんですけど
Googleはどうもこの悪い癖がありますよね。
その点AWSはこういうふうに突然やめるみたいな話を聞いたことが
私は個人的には聞いたことがないんで
その意味で安心して使えるのかなという気はしますね。
マイクロソフトとかもそうですよね。
Appleもどっちかというと突然やめる癖があるんで
なかなか油断できないかなという気はするんですけれども
特にDevRelは開発者向けのサービスっていうところがあるので
一回開発してシステムにクラウドサービスを組み込んじゃって
安定稼働してる限りはあまり手を加えないというか
ノータッチで簡単なメンテナンスだけで済ませるかなと思うんですけれども
それだけにこういう突然のシャックダウンとかがあると
それの乗せ替え作業だったりとか
既存のデータどうするのとかいう問題が出てくると思うんで
結構これは開発者にとっては大きな裏切りなのかなという気がしますね。
09:07
そんなGoogleのサービス修了壁が発動と
今度はIoTデバイス管理サービス クラウドIoTコアという記事が上がっております。
続いてですね。
こちらはサイルというのは
これは多分メディアか何かの会社のサイトかな
B2Bマーケティングを提供しているみたいな会社さんなんですけれども
そちらの記事でですね
分かる伝わる記事を作るための 編集執筆ガイドラインという記事が上がっております。
どうすればユーザーにとって分かりやすく 読みやすい記事を届けられるのか
オンドメディアやコラムの記事制作 編集担当者の多くが課題を抱えています。
この記事の中ではですね
スキリやノウハウがなくても 短期で記事の質は改善できますと
最低限のポイントを抑えるだけでも分かる 伝わる記事になりますというふうに書かれてますね。
一応編集執筆ガイドラインサンプルっていうのが ダウンロードできるようになってますね。
文章力を高めるチェックシートっていうのもあってですね。
こちらではレベル1 文章基礎力 過読性を満たす基礎力があるかどうかっていう判定ができたり
またレベル2が文章表現力 段落ごとの表現力があるか。
最後は文章構成力 文章全体の構成力があるかというふうになってますね。
文章基礎力 可能性を満たす基礎力があるか。
文章表現力 段落ごとの表現力があるか。
文章構成力 文章全体の構成力があるか。
これ二つに分ける意味あんまあんのかなっていう気もしますけれども
なんか書いてあること ただ漢字だけにしたら
同じような字になりそうな気もするんですけれども
そんな感じですね。レベル1 レベル2 レベル3で分けられるとかですね。
あとは水溶的な簡単な話とかが書いてありますね。
技術者に限らずですよね。
オンラインにはテキストコンテンツが一番多いので
そこでより過読性を高めるとか
より読者の方がスムーズに頭に入ってくるように書くとかですね。
12:05
そのあたりって結構大事なことかなという気はしますね。
くくりとか太字とかあと記号とかですね。
そんなあたりの使い方というところが書いてありますので
気になる方はぜひサイルさんのサイトからですね。
記事の大体上の方ですね。
執筆編集ガイドラインサンプルっていうのがダウンロードできますので
ぜひそちらをご覧いただければと思います。
続いてですね。
次がこれも面白いですね。
こちらはZTNETさんの記事なんですけれども
技術者が習得すべき5つのソフトスキルというのが挙がっております。
まだ私この記事きちんと読んでないんですけれども
いわゆるプログラミングとかネットワークとかデータベースとか
そういうテクニカルなスキルではなく
いわゆるコミュニケーション力とかですね。
そういったソフトスキルの部分に関して書いてありますと。
まずですね。
必要なのはまず1個目。
適応力。
適応力は
学びに対するアジリティや新しいスキルを素早く身につける能力の方が
強く求められていると。
プライベートな時間に生涯にわたって学び続けることで
学びに対するアジリティや適応力を養うことができる。
IT関係のポッドキャストやニュースを聞いたり読んだりすることや
新しいスキルを身につけることを楽しむべきだというところで
いわゆるIT業界に限らないですけど
エンジニアの業界で新しい技術がどんどん入ってきたりとか
トレンドが変化していく中で
そこにいかに早くキャッチアップしていくかというところになるかなと思いますね。
続いてが協調性ですね。
これはいろいろ苦労されるエンジニアの方も多いのかなという風には思うんですけれども
一緒にブレインストーミングを行いアイディアを共有し
励まし合う能力があれば大規模なプロジェクトも実現可能になると。
協調性は不確定要素が多く
チームでの取り組みが重要なソフトウェアエンジニアリングや
ゲーム開発の職場では特に重要なスキルだという風に書いてありますね。
15:02
協調性を高めるには
プライベートな時間に他の人と力を合わせてプロジェクトに取り組むよう
努めることが効果的だろうという風に書いてありますね。
先ほどの適応力もそうでしたけど
プライベートな時間をいかに潰すかという感じが見受けられますけれども
協調性ですね、二つ目は。
そして三つ目ですね。三つ目がコミュニケーション能力という風に書いてありますね。
これも結構苦労される方も多いのかなという気はするんですけれども
自分の考えや提案を聞き手が理解できるように伝える能力も必要になるという風に書いてありますね。
文章や言葉で強力なコミュニケーションを行うスキルがコミュニケーション能力になると。
なので別にいわゆる話し言葉で話す中でコミュニケーションを取るだけではなくてですね
テキストを使った文章とかによるコミュニケーションというところも含めた能力という風に書いてありますね。
ついついエンジニアに限った話ではないと思うんですけれども
テキストでコミュニケーションしようと思うと長大な文章を送りがちになったりするんですけれども
コミュニケーションと基本的に短いセンテンスのやり取りが基本になっていると思うので
テキストの場合もそんな長大な文章を送りつけるっていうのはなるべく避けた方がいいかなって個人的には思いますね。
誤解をさせちゃいけないと思って1から10まで全部説明する文章を作って一気に送りつけたりするんですけれども
そもそも1が理解できていない状態で10まで送りつけられても結構困惑するだけっていうところがあってですね
なるべくその短いコミュニケーションを通じて相手の理解度を上々に高めながら
最終的な結論に持っていくっていうところが大事なのかなって思うんですけど
エンジニアに限らないですけどそういう一気に送りつけるテキストコミュニケーションを取る方もいるんで
苦労するだろうなって思ったりしますね。
続いて4つ目ですね。4つ目、リーダーシップですね。
リーダーシップはITの分野でキャリアアップするには必要不可欠なソフトスキルだと
上級のエンジニアや開発者やマネージャーは良きリーダーでなければならないと。
そしてリーダーシップを養うには会議での発言を増やすとともに
会社の意思決定の背景にある対極的な状況判断について
考えるようにすると良いだろうというふうに書かれてますね。
18:09
もうちょっと対極的な目で、俯瞰的な目で見るということですかね。
リーダーシップの能力を身につけたければ
創造力を発揮することが必要な難しいプロジェクトに挑戦するようにすべきだと。
また地元の大学が設けているリーダーシップに関するビジネスクラスに参加したり
組織のリーダーシップに関する資格や修士号を獲得することを目指すのも良いだろうと書かれていますね。
そして最後ですね。最後5つ目。何だと思いますかね。
ここに書かれているのが自発性となってますね。
自発性は日常的にタスクリストを作成し、それを達成していくことで身につけることができると。
自分のペースできちんと締め切りを守って仕事をしていくということですね。
いわゆる完全にリモートワークであることが最近は多いと。
そういった仕事では在宅勤務の自由を享受できますけれども、自由度が大きすぎると遅れを取ってしまう可能性があると。
仕事のペースを維持して締め切りを守れるようにするには自発性が必要だというふうに書かれてますね。
ということでまとめるとですね。全部でソフトスキルはまず1つ目、適応力ですね。
2つ目が協調性。3つ目がコミュニケーション能力。4つ目がリーダーシップ。最後が5つ目、自発性というふうに書かれております。
このあたりのソフトスキルは確かに大事なのがありますよね。
年齢とかによってその人の立場とかも違ってくるんで、どういった能力が求められるかっていうのはそれぞれ違うと思うんですけれども。
なかなか1年目、2年目とかだと難しいものもあるかもしれないですし、最近の若いエンジニアはとても優秀な人が多いので、このあたりもきちんと備えている人も多いかもしれないですね。
もし今後のキャリアパスとかで悩んでいる方がいらっしゃったら、こういったソフトスキルに取り組んでみてもいいんじゃないでしょうかというところになります。
続いて前の記事からなんですけれども、こちらは株式会社プラハ、CEO兼エンジニアの松原さんの記事になります。
21:16
100名以上のメンターをやってみえた、めちゃくちゃ伸びる人の共通点と書かれています。
このプラハっていう会社ではプログラミングブートキャンプを提供していて、これまで100名ぐらいの方が参加して、その中で伸びる方の共通点が見えてきたというふうに書かれてますね。
簡単に言うと全部で6つに絞られている。
めっちゃ伸びる人は分からないことを言葉にするのが上手。
2つ目が情報を鵜呑みにしない。
3つ目が人当たりがいい。
4つ目が学習量が半端ない。
最後5つでしたね。
最後5つ目が好奇心にあふれているというふうに書いてあります。
めっちゃ伸びる人ほど自分が理解できていないことを具体的に言葉にするのが大変上手ですと書いてありますね。
これはぐさっときますね。
本当に分からない方からすると何が分からないのか分からない状態になったりするのでなかなか難しいところがあるかなと思うんですけれども
個人的にこれ聞いてちょっと思うのは
数学とかの勉強で
私が高生だったんですけど
高生の1年生ぐらいの時の数学の勉強ってそんな難しくないと思うんですね。
私の時代はそうだったんですね。あんま難しくなくて。
2年生もそんな難しくないですよね。
3年ぐらいから突然ガッてレベル上がるんですよね。
そこからこれ理解できないって思うとですね
結構何が分からないのか分からない状態になってしまって
よくよく考えると1年生2年生の時に
もうなんとなく分かってるからと思って真面目にやってこなかったことっていうのが
3年とかになってそこを基礎として上積みが来るんですよね。
分からないってなった時に何が原因で分からないのかが分からないので
結構1年生ぐらいまで遡って勉強してきちんと基礎を抑えながら
改めて勉強してようやく追いついたみたいな経験がありますね。
分からないのが分からない状態になってしまうと
本当もっと前の段階まで戻って学び直すっていうところが大事かなって思いますね。
24:08
2つ目が情報を鵜呑みにしないとなってますね。
めっちゃ伸びる人ほど情報を鵜呑みにせず自分が納得するまで疑い続けるので
身につけた知識が深く反映されづらいように感じますというふうに書かれてますね。
ネットでいろいろ情報が手に入っちゃうんでね
それをコピペコピペでやっているとついついそれが正しい方法だって思っちゃうんですけど
意外とそれ以外の方法もあったりとか
実は自分で手を動かすと何でそれがそうなっているのかみたいな根本的な原因も分かってくるんで
そうすると理解度が高まるというのは確かにその通りかなと思いますね。
続いて人当たりが良いと
めっちゃ伸びる人ほど人当たりが良く技術的な議論をする仲間が周りにいると
そうですね。技術的な議論をする仲間って皆さんどうですかね。そんないるんですかね。
上司というか先輩とかがいれば違うと思いますし
あとはコミュニティですよね。周りにいるっていうよりはコミュニティのスラックとか
ディスコードとかに入るとそこで話をするみたいな感じな気がしますね。
あんまり社内でそんな技術の会話をすごく活発にできる人がいるっていうのは
かなり恵まれた環境なのかなという気はしますかね。
人当たりが良い
そういう人とコミュニケーションがスムーズな人って確かに伸びる要因なのかなと思ったりはしますかね。
続いてめっちゃ伸びる人は学習量が半端ないと
1日の大半を学習に費やしている人は伸びないはずないよねという納得感のある共通点ですと
伸びる人は掃除で学習時間がずば抜けていますと
平日の仕事終わりに毎日2、3時間は勉強して週末も必ずコードを書いて
1日の大半を学習に費やしているというふうに書かれてますね。
そうですね。このあたりね。さっきのZDNetの記事もあったんですけど
プライベートを学習時間に費やしているから伸びるというのは
なかなか難しいのかなという気がしますかね。
27:02
個人的には好きでやってるからっていうところが大きいと思うんですよね。
新しい言語を覚えたいとか
自分でソフトウェアを作ってみたいとか
そういうのも結局純粋な興味から来てるんで
勉強してるって言われると結構違和感があるんですよね。
あと最後ですね。好奇心にあふれていると
自分が没頭する時間を自分で絶えず作り出せる人というふうに書かれてますね。
これはそうですよね。開発者は好奇心がないと
なかなか継続的に学び続けるのは難しいかなという気はしますかね。
別に他の職種がじゃあ好奇心なくてもいいかと言われると
そうではないと思うんですけれども
何にしても好きなものこそ上手なれという言葉があるんで
やっぱりまず好奇心ありきかなという気はしますかね。
その意味では技術別に好きじゃないとか
プログラミング別に好きじゃないんだけど
会社から言われたからプログラマーやってますみたいなのは
なかなかお互い不幸だなっていう印象はありますかね。
その今挙げた5つですね。
わからないことを上手にする。
わからないことを言葉にするのが上手。
情報を鵜呑みにしない。
人当たりがいい。
学習量が半端ない。
あと好奇心にあふれているというのはですね。
この伸びるエンジニアの共通点というふうに書かれてますね。
このサービス、ここの会社さんがやってるサービスは
中級エンジニアを育成するプログラミングブートキャンプって書いてありますね。
中級エンジニアって何ですかね。
多分初級エンジニアはただコードが書ける人で
中級エンジニアは自走できるITエンジニアなのかな。
学ぶと自己解決力、実践的知識、コミュニケーション力が手に入ると。
答えを与えるのではなく答えの探し方を教える場であると。
実務経験2年未満、独学では物足りない、
汎用的な知識が学びたい、仲間と切磋琢磨したい
みたいな人に向いているみたいに書いてありますね。
いわゆる何でしたっけ。
30:00
実務経験がないエンジニアを雇って失敗した話みたいなのが
確か先週ちょっと話した覚えがあるんですよね。
未経験エンジニアを採用して失敗した話か。
多分このプラハさんがやっているサービスっていうのは
中級エンジニアなので経験がゼロっていうわけではないですけれども
2年ぐらいやっているともしかしたら壁に当たるところがあって
そこからキャリアアップするための方法として
やってもらうみたいな感じなんですかね。
この辺りキャリアパスの問題は難しいですね。
何が正解か本当によくわからないですね。
続いてなんですけれども
どれがいいかな。
エンジニアブログの話ですね。
こちらはLibSenseさんのエンジニアブログで
エンジニアブログ書き続けるのはしんどい俺たちに送る小話という記事が上がっております。
そうですねブログの執筆って難しいよね。
皆さんは継続的にブログ記事などのアウトプットってできていますか。
私はできていませんっていうふうに書いてありますね。
なかなか継続性っていうところでみんな困っていて
むしろみんなが困っているのは
継続してエンジニアブログを盛り上げていく方法ではないでしょうかというふうに書いてあります。
そもそも難しい理由というところで2つあって
1つ目これ挙げちゃうとどうしようもないんですけど
そもそもテーマネタが出てこないというところですね。
なかなかこれも難しいところではあるんですけど
ある会社さんからすると日々業務の中で疑問を感じたりとか
学びあるよねそういうテーマがそもそも浮かばないってことは
あなたは仕事してるんですかみたいな
そういう煽り系の意見とかもあったりするんですけれども
やっぱりここ一番肝かなっていう気はしますかね。
そもそもテーマネタが出てこないということですね。
それを解決する手段としてはですね
まず1つ目がテーマネタは忘れないうちにメモしておくと
やっぱりメモ大事ですよね。メモは本当に大事。
33:02
2個目が社内ウィキの内容で社外公開できるものは記事にしてしまうと。
3つ目がアイデアをみんなで出すということですね。
そうですねアイデアをみんなで出すのも大事ですよね。
大抵編集体制とかになっているところもやっぱりそのコンテンツ会議をやって
そこでネタを作っていったりとかしますんで
みんなで考えるっていうのは大事なことかなと思いますね。
2つ目の課題が各モチベーションが続かないということですね。
ないわけじゃないですね。結構そこが違うんですね。
別にモチベーションないわけじゃなくて続かないっていうことですね。
この記事を読んでくれているエンジニアの何人かは
画面の前でうなずいてくれているんじゃないでしょうか。
ほんとうなずいちゃいますね。
それをカバーする方法というところで2つ上がってますね。
まず1つ目チームとチーム目標を作るということですね。
こちらはどういう目標なのかな。
チームとして記事の投稿数やブログの各種指標について
目標を定めて活動を行っていますというふうに書いてありますね。
続いて2つ目が毎日少ない時間でも書くということですね。
書く習慣という書籍があるんですけれども
そちらで紹介されていた方法で
文章を書くモチベーションが上がらないのは
文章を書くことが習慣になっていないからだと指摘しています。
従ってまずは毎日ほんのわずかな時間5分程度でもいいので
執筆作業に使うというアクションを紹介していますということですね。
そうですね。
そういう時間を会社で無理やり作ってもいいのかもしれないですね。
ミーティングではないですけれども
毎日15分間をその時間からその時間は
部員全員必ずブログ執筆しなきゃいけないみたいな感じの時間を
作ってもいいかもしれないですね。
例えば課題もあってですね。
朝の時間はチャットの返信や相談への対処など
緊急度の高いものに時間を使ってしまい
結局執筆できないとか
突発的なトラブル対応やミーティングでできないとか
日を跨いで書くので
その時の気分や調子に乗って文体が変わってしまう
などといったことも発生しているということですね。
でも定期スケジュールに入れるタイミングの工夫とか
というふうに書いてあるので
36:01
こういう強制的に時間を作っていくっていうのは
とても良さそうな気がしますね。
参考になる部分があれば
ぜひ皆さんも真似てみてはいいんじゃないでしょうか。
リブセンスさんのエンジニアブログ
エンジニアブログ書き続けるのはしんどい
俺たちに送る小話というふうに書かれてます。
続いてですね
これは聞いたの記事ですね。
聞いたの記事からなんですけれども
何を言っているのかわからないと言われないための
伝え方のノウハウというのが出ています。
これ確かに伝え方ノウハウありますよね。
本当に何言ってんだかわからない人いますよね。
もしかしたら私もそうかもしれないんで
注意はしたいと思うんですけれども
この記事の中ではですね
コミュニケーション能力の苦手意識は
ノウハウで解決するということですね。
コミュニケーション能力が向上すると
生産性向上にもつながるというふうに書かれてます。
あとは人に物事を伝えることの大前提としてですね。
一つ目、相手の立場になって考えると。
わかりやすく表現するというのは
あくまでも手段でしかないということですね。
常にゴールは相手が理解した状態になるというところに
置く必要があるよと書いてあります。
伝え方の基本ですね。
まず世の中の非常に多くの人が
聞かれたことに答えるということと
事実と解釈を分けて話すことができていないそうです
というふうに書いてありますね。
質問に答えるときには
聞かれたことにシンプルに答えると。
ここに例文があるんですけれども
例えばタスクは終わりましたかという質問に対して
今おにゃられで止まってまして
解決したら今日中に終わると思いますと答えるのが
質問に答えていない状態ですと。
相手が知りたいのはタスクが終わったか終わっていないかなので
はい、終わりました。
またはいいえ、終わっていませんと答えますと
いうふうに書いていますね。
このときに人間の心情として
いいえと答えてしまったがために
相手にネガティブな印象を持たれるみたいなのが
怖いみたいに思っていたりすると
どうしても先に言い訳が来てしまうというのは
あるのかなという気はしますね。
はい、なのでなんでしたっけ
39:03
なんとか安心性でしたっけ
そういうネガティブなことを言っても大丈夫なんだっていう
そういう空間づくりとか
そういう環境が整っているかどうかで
こういう答え方っていうのも変わってくるかなっていう気はしますかね。
はい、そして事実と解釈は分けて話すというところで
事実と解釈は明確に分けて話します。
事実が明らかでなく解釈しか話せない場合
それは事実が分かっていないという事実を示します。
まず事実は分かっていません。
ただこれは私の解釈ですが丸々だと見ています。
事実については別途裏取りしますという風に
そうすれば事実を知らないから事実を話さないのか
事実を知っているが話していないだけなのかが区別がつきますと
いう風に書いておりますね。
このあたりもサンプルを見れば多分分かりやすいのかなという気はしますね。
相手の頭にフォーマットを作ると
そのフォーマットはprep4 sds4 crf4などがありますと
いう風に書いておりますね。
ここはちょっと後で調べてみようかな。
まず冒頭でこれからどんな話をするのかを示すと
主題から外れる話は後回しにすると
自分が話したいことではなくて
相手が知りたいことを話すと
ワンセンテンスワンメッセージを守ると
報告はアクションプランとセットで行うと
曖昧な質問には意図を想定して答えるという風に書いてありますね。
最後の曖昧な質問にはあんまり勝手に想像すると
実は違う場合もあったりするので
もう一回ボールを打ち返したほうがいいのかなという気はしますかね。
それで相手の質問を具体的にしてもらうと
こちらもそれに合わせた答えがしやすいのかなという気はしますかね。
伝え方のテクニック17個ありますね。
結構多いのでパッパッパッといくと
タスクを分解する。
フィット&ギャップで同じ違うを使い分ける。
フィット&ギャップで同じ違うを分ける。
感覚はスコアで伝える。
あるものでないもので説明する。
表形式にして他にはないのをなくす。
キャラクター化して論理関係を示す。
42:03
キーワードを分解する。
キーワードを拡大する。
質問に答えるとで始める。
結論から言うとで始める。
原則と例外を重み付けする。
非合理を明示する。
比較表現の基準を示す。
正しさの基準を示す。
で、俺は何をすればいいの?に答える。
怖いから始める。
結果的にどうなって欲しいかから始める。
などなどが書いてありますね。
そうですね。
結局こういうのってあれなんですよね。
相手と自分が同じぐらいの知識レベルがあるっていう前提に
立っているのかなっていう気がしていて
簡潔に言ってもなかなか伝わらない人って結構
多いような気がするんですよね。
そうすると1個の説明だけでは通じなくて
別な説明、別な説明をやって
その中の1個ぐらいが
それだったら理解できるみたいな感じになったりすることも
あったりするんで
なかなか共通認識をつけるっていうところが
会社だったらいいんですけど
対お客さんぐらいだと
なかなか相手と立場が違うと
あまり簡潔に言いすぎるのも
良くないのかなって思うときもあったりしますね。
そんな記事がですね。
こちらはQiitaの何を言っているのかわからないと
言われないための伝え方のノウハウという記事が上がっております。
それではですね。
今日のメインテーマの方に入っていこうかなと思うんですけれども
今日のメインテーマはですね。
私の一冊技術書編ですね。
3件ご意見はいただいているんですけれども
1個目のご意見はですね。
単純に本のタイトルだけ書いてあるっていう感じで
これは取り上げるのは難しいですね。
コメントもいただけると嬉しいですね。
ではですね。
まず一冊目なんですけれども
DevRelName.Johnnymanさんからですね。
いつもありがとうございます。
コメントが
データの見える化に関する技術で印象に残った本をご紹介します。
行動経済学の本。人は悪魔に熱狂するを書かれた
松本健太郎さんのグラフを作る前に読む本。
一瞬で伝わる表現はどのように生まれたのかです。
データの見える化に取り組むときに知っておくと
良いグラフの長所短所に加えその成り立ちを学べます。
45:00
今でこそビジネスの現場にBIが浸透し
データビジュアライゼーションの考え方や技術の本は多いですが
5年前は珍しくそれで買ったと思います。
おまけですとデータ分析で言えば西内博文さんの
統計学は最強の学問であるはデータを扱うベースの考え方を
シルエで印象に残った本ですといただいております。
この行動経済学の本は私も読みましたね。
人は悪魔に熱狂するって
多分ほぼ一番最初ぐらいに行動経済学で読んだ本の気がしますね。
その方の書かれたグラフを作る前に読む本
一瞬で伝わる表現はどのように生まれたのかという本ですね。
グラフって結構いろいろあっても
いわゆるグラフとチャートの違いはうまく説明できないんですけど
グラフっていうと単純に棒グラフ円グラフとか
折れ線グラフとかそんな感じなんですけど
チャートっていうともうちょっと込み入った感じの
ドローイングをするかなっていう気がするんですけど
そういうチャートとグラフって本当多種多様にあるんで
その扱うデータによってどのグラフを使うと
分かりやすいかっていうのは結構考えるポイントが
多いのかなっていう気はするんですよね。
そういった意味でグラフの長所短所に加えて
その成り立ちを学ぶっていうのは結構大事なことかな
っていう気はしますよね。
単純に折れ線グラフにすればいいとか
単純に棒グラフにすればいいとかではなく
その棒グラフにしても横にする場合もあるし
累積にする場合もあるし
折れ線にしても単純に線だけでいい場合もあれば
エリアにした方が塗りつぶした方が分かりやすいとかですね
いう場合もあったりすると思うんで
個人的にちょっと思うのは2Dと3Dはぶっちゃけてどうでもいいと思うんですよね
3Dにするとかっこいいみたいな感じの風潮が昔あって
いろんなところで3Dのグラフ見たんですけど
3Dにすると視覚的にインパクトがある割には
あまり実際のデータの方に目が向きづらいのかなっていう気がするんで
データの表示の2D、3Dはあんまこだわらなくてもいいのかなって思ったりしますね
それ以外、そもそもどのグラフを選ぶのかっていうのは当然
48:02
きちんと考えた方がいいかなと思いますね
ではですね、続いて2件目
デブレルネーム西から来た馬面の男さんですね
いつもありがとうございます
書籍でおすすめはデブレルお悩み解決通知です
ありがとうございます
自社のエンジニア採用活動を本押しを入れてやるようになり
何度か見返しています
この書籍の7章にデブレルは採用にもつながりますかという説があり
開発者向け製品やサービスを作っていなくても
開発者を雇用したい企業にとってデブレルの考え方は有効で
行うべきといった趣旨が書かれており
自分の活動の拠り所にさせていただいていますと
普段業務でやっているエンジニア採用活動も
本書を通じてデブレルの観点で見ていけば
社外のエンジニアとの関係強化やマーケティングにつながり
とても新鮮に感じます
執筆陣の皆様ありがとうございます
今なお有益な情報に感謝ですといただいております
こちら大変ありがたいですね
ありがとうございます
デブレルお悩み解決室はいつ書いたんだろう
いつ書いたんだこの本は
もしかしたら西から来た馬面の男さんの
言われているのは同人版の方かもしれないですね
デブレルお悩み解決室ですね
商業出版の方はデブレルQ&Aという本になるんですけれども
そちらはいつだこれ
2019年11月ですね
約3年ぐらい前に書いた本ということですね
今なお役立てていただいているのは非常にありがたいことですね
確かいくつぐらいだったかな
60ぐらいとかですかね
質問を考えてそれぞれに対して
複数の方がコメントしていくみたいな
そういう感じの本になってますね
結局デブレルって一言で言っても
一つの正解があるわけではなくて
ある人にとっては
ある企業にとってはこういうデブレルがあるし
ある企業にとっては別なデブレルがあったりする場合もあるんで
そういったのをオムニバスでいろんな人が回答するという形で
書籍を作っていますね
なので西から来た馬面の男さんに役立つ答えもあれば
もしかしたらこれはなーって答えもあるかもしれないですけれども
51:01
全体を通じて役立てていただければありがたいなというところですね
人事に関係したところで
開発者を雇用したいところもですね
デブレルをやっていくべきっていうのは
私もそう思いますし
開発者を雇用することによって
自社とか自社のサービスが成長するんであればですね
そういう企業はデブレルをやっていくべきかなとは思いますね
あんまりこう昨今のITエンジニア不足とかもあったりするんで
開発者をないがしろにするような会社っていうのは
なかなか成長が難しくなっていくんじゃないかなと思いますね
そういった意味でも
開発者との良好な関係性を築いて
それを保ち続けるっていうのは大事なことかなと思いますね
デブレルお悩み解決室とか
あと商業出版の方のデブレルQ&Aとかですね
他にもいろんなデブレルに関する質問に答えていたりしますので
もし気になる方がいらっしゃったらですね
読んでみていただきたいなと思います
Kindle Unlimitedに入っている場合は無料で読めるらしいですね
普通のKindle版だったとしても880円らしいですね
なんかさっきチラッと見たら
メルカリでも売ってるっぽいんだよな
メルカリで600円で売ってますね
600円で買うんだったら
普通に買ってもあんま変わんないような気もするんですけれども
売られてますね
ブースで売ってるのも980円か
これブースの倉庫から発送されるのかな
いやそんなわけないよな
これ今買われても困るような気がするんだけどな
売ってていいんだろうか
整理したほうがいいような気がしてきたな
多分在庫ない気がするんですよね
ePubだよかったよかった
これは大丈夫ですね
ブースでも書籍売られてますので
ぜひそちらでも購入検討いただけるとうれしいです
DevRel Q&Aの方は
港川愛さんに表紙を書いてもらっている本なんで
そこでちょっとリッチな感じの表紙になっております
54:05
というところで最後ですね
イベントのご案内をしていこうと思います
まず一つ目が明日ですね
明日DevRel Japan Conference 2022が
8月の頭にやったんですけれども
それの報告会をですね
開催いたしますと
渋谷の宮下パークビルの地下1階という会場で
やる予定になっておりますので
もしですねそのカンファレンスの裏側知りたいとかですね
そのカンファレンスのために
ご意見いただけるという方はですね
ぜひ参加いただけると嬉しいです
あともう一個はですね
来月の頭ですね
来月の第1水曜日9月の7日が
DevRel Meetup in Tokyoの78回目となっております
テーマはですね
商業技術書出版を学ぼうというところで
まずお一人目がババアさんですね
ババアさん社名がクロステックファイブさんですね
今クロステックファイブさんに勤めていらっしゃって
昔は違う場所でやられていて
その時は場所とかイベントでお借りしていたんですけれども
そのババアさんからですね
お話しいただくのと
あと伊藤純一さんですね
ソニックガーデンの方なんですけれども
先日Rubyの書籍ですね
改訂版を出されたというところもあって
それのお話とかお聞きしますと
あと3本目がですね
商営者の山本さんですね
エンジニア本大賞っていうのを
商営者さんで毎年やられてるんですけれども
その辺りを含めつつ
技術書のトレンド変化みたいなものを
お聞きしようと思っております
基本的にこちらはですね
オフラインのみの開催で進めていますので
もし参加したい方がいらっしゃったらですね
ぜひ
場所が
今回上野なんですよね
ちょっと変わった場所でやってみようと思って
上野になっております
落語サロンっていうところでやりますので
なんかちょっと講座とかもあってね
話せるようになっているという感じの
変わった場所になっておりますので
ぜひご参加いただけると嬉しいです
9月7日夜やりますので
ぜひご参加ください
というところでですね
本日のDevRelラジオ76回目は
終了していこうかなと思います
今日はですね
57:00
ちょっと急遽
録画配信という形になりましたけれども
おそらく来週は
普通のライブ配信になるかと思いますので
また来週皆さんお会いしましょう
ではまた引き続き
お仕事頑張ってください
さよなら
