エンジニアこそ「言語化筋」を鍛えよう、というお話

4月に発表した「言語化筋トレ」のスライドが、おかげさまでご好評をいただいています。
※ 「言語化筋」「言語化筋トレ」は造語です。以下、「言語化力」「言語化力トレーニング」と読み替えてお楽しみください:)

EMOasisというEM向けのイベントで、

• ビジネスインパクトを最大化するためにEMが磨くとよいスキルは「翻訳」

• そのためには「言語化筋」を鍛えるべし

というような話をしました。ただ、「言語化筋」はマネージャーに限らずみんなの役に立つものなんじゃないかと思っている今日このごろでして、補足のようなエントリを書くことにしてみました。

「言語化筋」が大事なワケ

私たちは日頃から言語を介してコミュニケーションしているので、自分のこと、周りのことをなんとな〜くわかった気になっているものです。でも改めて、例えば以下のような質問を受けたとき、サラッと答えられる人はそう多くないのかも、とも思います。

• 今の仕事に満足していますか？それはなぜ？

• 今の仕事をもっとよいものにするために、自分やチームにとって必要なインプットやアクションは？

• あなたのプロダクトを利用する人はどんな人で、どんなところに特に魅力を感じてくれている？

あるいは、人からの受け売りの言葉ならすぐに出てくるかもしれません。「営業のトークスクリプトにこう書いてあったな」とか、「代表がnoteでこうやって発信していたな」とか。それを「自分はこう思う」に変換しようとすると、思いの外骨が折れるものです。

「別にぱっと答えられなくても日々の仕事は円滑に回せるじゃんね」と思われる方も多いと思います。実際にそう……なんですが、「改めて言葉にしてみる」をやらない期間が長いと、段々と自分の心の機微にも鈍感になっていってしまうんですよね。なので放っておくと「気づいたら会社の状況が変わっていた」とか「気づいたら今の仕事を全然楽しめなくなってしまった」、果ては「なんでこうなっちゃったんだろう……転職しようかな」となっちゃう。

転職活動自体は強制的に内省を促されるもの（面接で転職のきっかけを聞かれてたじろいだ経験のある方も多いと思います。ご多分に漏れず、かつての私もです）なので、機会を活かすこと自体は悪くないのですが、せっかく慣れた環境があるなら、辞めたい気持ちが湧いてくる前に対処できたほうが健全ですよね。

もっとも身近な言語化筋トレ、それが振り返り

「内省のアウトプットってどうやったらいいの」と質問もらった気がするのでどこかでnote書きますhttps://t.co/lg4BYnhnmk

— あらたま｜LayerX Inc. (@ar_tama) August 11, 2024

スライドではなんだか小難しい言い回しをしてしまったのですが、要するに振り返りを通じて「自分の感じていること」を言語化しましょう、それが一番身近かつお手軽に始められる筋トレです、ということが言いたかったのでした。

「事実」と「感情」を分けて振り返る

これは万人に共通して言えることだと思うのですが、「振り返りするぞ！」だと何から始めていいかがわからず途方に暮れるものです。なので、「フォーマットに沿って書き出して眺める」というように、形式化してしまいましょう。例えば以下のような感じで…

1. この1週間で起きたできごとを書く

2. この1週間で自分がやったことを書く

3. 1と2に対して、自分がどう感じたかを書く

4. 1~3を使って、次の1週間でやってみること・やめてみることを書く

漫然と振り返りをしようとすると、事実と感情が混ざってしまいがち。まずは起こったこと・やったことなど事実を洗い出してから、自分の感情を並べて書くのがおすすめです。あるいは、強烈に抱いた感情があれば、それを起点に事実を書き出していくのもよいですね。

日記的に自分向けに書き溜めておくのもよいですが、せっかくなのでマネージャーとも共有できるとよさそうです。細かい単位での振り返りがあればあるほど、会社の向かう先と自分の描きたいキャリア（たとえそれが「言語化」されていなかったとしても！）のすり合わせがやりやすくなるはず。

余談ですが、仕事だけでなくプライベートについても振り返ってみると、それはそれで違った発見があり面白いものです。自分を構成しているのは仕事だけではないので、意外に相互に影響を与え合っているのがわかるだけでも、「自分という、わかりそうでよくわからないもの」と付き合うヒントになったりします。おすすめ。

言語化筋は、エンジニアリングにも活きてくる

開発にまつわるプラクティスのひとつに、「ADR」というものがあります。Architecture Decision Recordの略で、主に設計や技術的方針の決定に利用した材料や文脈のスナップショットを記録する活動のことを指します。

技術的な意思決定は常に様々なトレードオフと隣り合わせ、かつ決定に際しいくつかの選択肢があることがほとんどのはず。コードに残るのは最終的に選ばれた結果の集積のみなので、文脈を記しておくことはエンジニアにとってとても大事な活動だと、私は考えています。

LayerX バクラクにおけるADRについての説明資料

意思決定が「なんとなく」で行われてしまうと、その方針を見直すべきタイミングも観点もわからなくなってしまいます。そしてこの「文脈」「選択肢」「決定の理由」を客観性を持って書き出すという作業もまた、言語化筋を用いて行われるものなのだと思います。

大きな、あるいは複雑な意思決定は観点を集めるだけでも一苦労ですが、だからこそ必要と私たちは考えて続けています。実際にADRがあったからこそ見直せた方針もありますし、新メンバーのオンボーディング資料代わりにもなったりと、メリットのほうが大きい実感があります。

難産だったVue→React移行のADR。カンファレンスで皆さんにチラ見せしました。

レッツ筋トレ！

「なんとなく感じていること」をまずは無理やりにでも言葉にして、そこから磨き込んでいく、というプロセスは存外大変ですが、続けるうちに慣れるものです（なので筋トレと称しています）。ぜひ皆さんもトライしてみてくださいね！