エンジニア目線で読んだ「すごい言語化」
はじめに
✅すべて個人的の感想と見解です
✅全ての引用の出典はすごい言語化/小暮太一(著)です。
✅この記事はアフィリエイト目的ではないため、リンクは掲載しておりません。ご購入の際は、ご自身で検索するか、書店にてお求めください。
この本を購入しようと思った理由は、自分の考えを言葉にすることをこれまで直感に頼って行ってきたためです。
そのため、書籍を通じて学ぶことを一度試みようと思いました。
本書についての感想を、現役のフリーランスエンジニアとしての視点も入れて述べてみます。
自分が気になった箇所
目標に対しての言語化
目標を作ることが難しいのではなく、それを「明確にすること」が難しいんです。
本書では「できるビジネスパーソン」で例えていますが、エンジニア界隈で割と聞く単語にしてみると「つよつよエンジニア」が該当するのかなと思います。
SNS上でも「つよつよエンジニアになりたい」みたいな目標を掲げている方々を見ることがありますが、果たしてつよつよエンジニアとは一体何なんでしょう？？
インフラからフロント/バックエンド全て一人でできる人？？
PC本体のことにも詳しい人？？
大手企業でリーダー的立場で活躍してる人？？
凄いエンジニアになりたいのかな？って意図は見えますが、目標としては曖昧でどうすればなれるか、どういう行動すれば良いのか分からないですよね。
自分の目標に対して明確に言語化をしなければ、実現するためのロードマップを考えることが困難になるということです。
目標を掲げる自体は簡単だけど、実現するための目標を明確に掲げられているかと言うことを考えなければいけませんね。
言語化とは
言語化とは、「自分の頭の中にあるものを、言葉に置き換えて、「誰か」に理解してもらうこと」です。
エンジニアはリモートワークが珍しくない業種です。
特にそこで必要になるのは「テキストコミュニケーション」で、自分の思考を文字にして相手に理解してもらうスキルです。
相手に伝えたい事を自分勝手に言語化しても相手に伝わらないと意味がないし、言語化出来てるとは思いません。
エンジニア業は他業種の人たちから見ると、家で一人でパソコン触ってあまり他人とコミュニケーションを取らないイメージがあるかもしれませんが、実はプログラミング以外にも様々な業務がありコミュニケーション能力(思考の言語化)は必要なんですよね。
このnoteを書いている今現在も自分感想を自分のためにダラダラ書いてるのではなく、自分が学んだことや考えを記事を読んでいる誰かに理解してもらうことを意識しながら書いてます。(絶賛練習中)
言語化とは、どう伝えるかではなく、何を伝えるか
伝える側は「どう(How)を気にしていますが、相手は「なに(What)」を考えています。
わからないのは「何」なんです。
確かに自分もどうやったら伝わるのだろうかって考えすぎていて、何を伝えるべき(伝えたい)なのかをおろそかにしている場面があったかもと思いました。
例えばあるWebサービスを売るとしたら、
「どんな風に伝えるかを先行するのではなくて、何を伝えれば売れるのかをまず考える」
こういった感じでしょうか。
技術力が進歩して複雑なデザインやかっこいいWebサイトも増えてきていますが、果たしてそのデザインは何のために作ったのか。
見た目は綺麗だけど何を伝えたいサイトなのか全然わからない。
自分は割とこういう経験があります笑
伝える材料やモノを明確化してから方法を考える。
当たり前に思うかもしれないけど、割と方法先行しちゃってる人も多いのかなと思いました。
言語化のための思考
「今回は、こういうことを相手に感じてもらいたい。
となれば、相手に伝えるべきことは〇〇だな」
と、自分の視点を定めなければいけない。
例えば、自分がエンジニア転職活動中と仮定してみましょうか。
相手(企業)に感じてもらいたいこと＝ゴールは
「自分が相手にとって欲しい人材だと思ってもらう」
こんなところでしょうか？？
次に相手に伝えるべきことは
「相手の企業カルチャーや求めてる人物像に対して、自分がどうマッチしているのか」
「自分が転職した際に相手にどういうメリットがあるのか」
を考えました。
さらに次のステップでは
言葉にすべきポイントに正しく焦点が当たってたとしても、それを「相手に伝わる言葉」にできていなければいけません。
「なぜそれを」、「なぜ今」、「なぜ私から」
・なぜそれ(自分)が相手に必要なのか
・なぜ今、相手は自分が必要なのか(ここはちょっと例には合わないかも)
・なぜ自分を採用するのが良いのか、何が出来るのか
これらを押さえておくと良いのかなと感じました。
価値を言語化する
「価値」って何なんだろうか？？
自分はこういうスキルがあるからこれだけの価値があると思っていても、相手からしたら違うかもしれない。
「Figmaでのデザインから開発やサイト公開まで自分で出来ます！」
「AWSに関して知識豊富です！」
というのは市場価値があったとしても、例えば自社サービスで組み込み系のロボット開発している企業からすると、自分が思っている価値がないのかもしれない。
大事なのは、相手がどういうエンジニアに価値があると思っているのかを汲み取って自分の強みを伝えることかなと思いました。
書いてて思ったのは、これって難しいなっと(笑)
ただ、転職時にとりあえずスキルシート(経歴書)を用意して自分のアピールポイントだけをテンプレのようにどの企業にも話すのではなく、意識するだけでも変わってくるんじゃないかなと思いました。
定義をすれば、言葉が特定される
定義するとは、必要条件をあげること、と捉えなおしてみます。
凄腕エンジニアとは？を考えた時に、例えば「プログラミング能力が高い人」と答えたとします。
この場合に「プログラミング能力が高い」が定義されていません。
単に「プログラミング能力が高い人」と答えても相手の定義と自分の定義が食い違っていたり、そもそも曖昧すぎて相手に伝わりません。
なので、自分が思う「プログラミング能力が高い」を言語化するために、定義することが必要です。
「プログラミング能力が高い」を一言でいうのは難しいので、どんな要素があれば満たされるのかを頭で考えてみることが必要になります。
・実装スピードが速い
・無駄に同じ事を書かずにパーツ化出来る
・DBやサーバーの負荷を考えて実装できる
例えばこんな感じでしょうか。
大事なのは正しく「プログラミング能力が高い」事を定義するというよりかは、自分が考える定義を相手に伝える事です。
定義と具体例は違う
上記の例で言うと、
・〇〇さんみたいにプログラミング能力が高い人
・某IT企業でバリバリ開発してる人
みたいに、具体例を出すと少しはイメージができるかもしれませんが、これらは定義されていないので結局伝わる情報はあまり変わらないですね。
具体例を出すと何か伝えた感を得てしまいがちですが、ちゃんと定義して言語化することが必要だと思いました。
欲しいものが手に入らない時は、定義を見直す
成果が出ないのは、能力や知識が足りないのではなく、目指すゴールの定義が曖昧、もしくは間違っている
自分はプログラミングコミュニティを運営している関係もあって、転職に関する話題を多く聞くことがあります。
そんな中、例えば転職理由の中に
・給与UPしたい
・自分が成長出来る環境に行きたい
・キャリアアップしたい
などを目にします。
エンジニアにかかわらず転職理由としてはよくありますし、特に問題ないようにも思います。
ただ、これらの定義をもう少し噛み砕いて考えておかないと結果的に意味のない転職になる可能性があります。
・給与UP
=>現状年収〇〇万円なので年収〇〇円にしたい。それが転職時なのか数年後に見込めるところなのかも加味する。
・自分が成長できる環境に行きたい
=>成長したいのはスキル面なのか社会的な面なのか。どんな環境であれば自分が成長出来るのかを定義しないと何を求めてるのかを分からない。
・キャリアアップしたい
=>キャリアと言っても人それぞれ思うところは違ってくるので、自分の市場価値を上げたいのか、希望のポジションに立ちたいのかなど考える必要がある。
自分が何を求めているのかを改めて具体的に考えることで、ゴールがまた変わってくるかもしれない。
本当に転職することで解決することなのか、それとも今の環境でも望めることなのかが見えてきそうです。
第二次アドバイスを示す
第二次アドバイスを示すとは、「よく言われている正論を聞いてもできない人に対して行う「じゃあこうしよう」という追加アドバイスのこと
経験年数が重なるにつれて後輩が出来たり、リーダー的ポジションに立つことが増えてきますよね。
正論をただぶつけるだけであったり、Webで調べたらよく出てくるアドバイスをそのまま言ってもあまり伝わらない場面に出くわします。
なんなら、「そんなことは分かってる」と質問者に思われてしまうかもしれない。
アドバイスというのは、世間的に的確に正しいことをいうだけではなく、その人の立場や環境を考えて自分なりの解答を言語化することが必要だと感じた。
それがここでいう「第二次アドバイス」になるんじゃないかなっと。
自分の感覚を言語化する
自分の感情のはずなのに自分で言葉にできず、「なんて言ったらいいだろうなぁ」で止まってしまいます。
感覚ってある種で言葉に出来ない(するのが難しい)ものをいうので、言語化はとても難しいと感じる。
「自分のことなのに何で分からないの？？」
こんな言葉を言われたり言ったりしたことはないでしょうか？？
人は95%の感覚を認識していないとも言われています。
自分の考えや思考を全て言語化するのは無理に近いし、それは必要ないんじゃないかなと思います。
例えば、あるサービスをより良くするための会議で「あなたの考えを教えて」と言われた時に、今思ってる事をどう伝える(思考を言葉に変換する)ことより先に「何を伝えたいのか」を考える必要があるかと。
具体的な方法や考えを下記に記します。
意味のある「一部分」に焦点を当てる方法
「どう思った？」ではなく、「この件に関して教えたいことは？」と自分に問い直します。
誰かにポートフォリオ(作品)をみて感想を求められた時に、
・デザインが綺麗だと思った。
・便利だと思った。
これだけでは何か物足りないなと。
そんな時に、焦点を変えて他の誰かにこのサービスを教えたいことという捉え方をしてみます。
・老若男女どの層がみても見やすいデザインになっていて、とても操作性に優れていると感じた。
・今までネット検索して解決したり、そもそも検索に引っかからないことが、このポートフォリを使用することで早く欲しい情報を手に入れることが出来るようになった。
など、単純に思ったことだけを考えるのではなく、「教えたいこと」を意識するとより良い感想の言語化ができた。
「切り口を変える」ではなく、「教えたい人」を変える
必要なのは、「切り口」や「新しい目の付け所」ではなく、いろいろな人からの目線で物事を見ることです。
人それぞれ知識量も違えば、年齢や生きてきた環境も違います。
同じ説明をするにも、
・幼稚園児
・お年寄り
・ビジネスマン
に対して用いる言葉や表現も変わってきますよね。
例えば、システムエンジニアの仕事内容を説明する時に、同業者であれば
「今はPHPでECサイトの新規開発をしています」
で良いかもしれないが、プログラミング言語やECサイトという言葉が伝わらない人に上記の説明をしてもやってる内容自体はあってるかもしれないが、伝え方としては間違っているよなと。
テーマは何でも良いので、あるテーマを色々な人相手にいうパターンを考えて話すことで、自分の感覚を相手に合わせて言語化するトレーニングになるんじゃないかと思いました。
まとめ
仕事においてもプライベートにおいても相手に自分を伝えたいのであれば、言語化というのは重要だと改めて実感しました。
日常の会話はもちろん、noteや技術記事の執筆にも役立てることがあったので満足しています。
・自分の思ってる事をなかなか言葉に出来ない
・思考を整理して伝えることが苦手だ
・コミュニケーション能力を向上させたい
こんな方々にオススメできる書籍だなと思いました。