はじめに
OpenAIがChatGPTをリリースし、12月にはProプランがリリースされ、ますますエンジニアとしての価値が問われる時代になってきたなあと感じています。
今回の記事はポエム的な要素も含まれています。
そんな中で、職業エンジニアが価値を出し続けるためには、なんとなくの理解ではなく、根本を理解することやその理解から仕組みを作れることが求められるようになりました。
また、ChatGPTのようなLLMを使いこなして生産性を上げるためにも、自分の作りたいもの、知りたい知識に近付くための言語化能力が求められるようになってきています。
この記事では、エンジニアの言語化能力および知識獲得のプロセスについて考察してみます。
テキストにおけるインプットとアウトプットの両軸で考えてみます。
知識の獲得
知識獲得の手段
WEBエンジニアという職業はやや特殊で、専門性のほとんどの知識はWEB上に公開されています。
それにもかかわらず、エンジニアという職業の平均年収が全職種の平均年収よりも高かったり、エンジニアを目指す人のためのプログラミングスクールが増えたりしています。
このことから、公開されている情報の中から求めている情報に辿り着く能力、および情報を自分の知識として定着させる能力は知識そのものよりも価値あるものだと言えそうです。
WEB上に公開されているプログラミングに関する知識には、以下のようなものがあります。
- Google Scholarなどの学術論文
- RFC(Request for Comments)、MDNなどの技術の標準化のための文書
- 特定のライブラリ、および言語のソースコード
- 特定のライブラリ、および言語の公式ドキュメント
- 企業が公開している技術ブログ
- Qiita、Zennなどの技術系の知識共有サービス
- teratail、Stack Overflowなどの技術系のQ&Aサービス
- 個人ブログ
この中から信頼できる情報をどのレベルまで選択し、理解できるかが知識の獲得に大きく影響します。
特にChatGPTのようなLLMを利用する場合、その回答を精査することができない状態だと成果物の品質や生産性が大きく低下します。
今後改善されるかもしれませんが、2024年時点ではLLMの回答をそのまま信じることはできません。
「生成AIは能力の高いエンジニアの能力をさらに伸ばし、そうでない場合はさほど変わらないか、かえって混乱を招き、格差を広げる」という現象が起こるので、最低限信頼できる情報源にたどり着き、内容を理解する能力が求められるようになっています。
なぜエンジニアはテキストでの知識共有が重要なのか
WEBエンジニアリング、というよりプログラミングにおけるテキストでの知識が重要な理由はプログラミングそのものがテキストであり、かつ再現性が高いからだと思います。
例えば営業など毎回相手によって結果が異なるような内容の場合は、共通項を見つけていくことはできるものの、結果の再現性が保証されるものではありません。
プログラミングでは、個人のPC環境など違いはあるものの、基本的には同じコードを書けば同じ結果が得られるので、テキストでの知識が重要になります。
また、プログラミングにおいては内容が無限に複雑化していったり、技術の詳細はどんどん細分化していくので、もはや全てを理解することは不可能になっており、個人の経験や知識は貴重な資産となります。ドキュメンテーションツールやナレッジ共有に価値があるのもこのためです。
言語化し、個人の知見をドキュメントとして残し、チームやコミュニティ全体で共有することで新人のオンボーディングがスムーズになったり、エンジニアの離職や異動による知識の損失を抑えることができます。
エンジニアは比較的流動性が高い職業なので、知見の共有によるメリットは大きいです。テキストにおけるコミュニケーションの最大のメリットは、その場に人がいなくても、いつでも、どこでも、誰でも知識を共有できることです。
言語化能力
言語化による自己理解と問題解決
言語化は他者への説明だけでなく、自己理解を深めるための重要な手段でもあります。
エンジニアリングの世界では、「ラバーダッキング」という手法が知られるほど有名な方法です。ラバーダッキングとは、問題解決のためにラバーダックに向かって抱えている問題を説明することで、自分の抱えている問題を理解できる、というものです。
人に相談する際に、話しているうちに解決策が思い浮かぶことはないでしょうか?それこそがラバーダッキングの効果です。
エンジニアが悩む問題の多くは言語化せず脳内で解決しようとすることが原因であることが多く、例えばプログラムが難しくて読めない、というケースはコードの中の難しい部分が脳内のメモリを超えてしまっていることが大半です。1行であれば理解できるのに複数行のコードを理解できない、という場合はこのケースです。
効果的な教育
エンジニアリングチームの大半はチーム内に経験豊富なエンジニアが1人以上いることが多く、新人や後輩を指導するケースがほとんどです。
この場合も先述した知見の共有が非常に効果的で、かつ同じチームなので具体例や経験談、既存のコードを例に挙げることで、新人や後輩に理解を深めることができます。
非言語化部分を考える
言語化の有効性を考察してきたものの、言語化だけでは伝わらない部分もあります。
UI/UX
ユーザーインターフェースやユーザーエクスペリエンスは言語化だけでは伝わらない部分が多いです。例えば、ボタンの配置や色、アニメーションなどは言語化だけでは伝わりにくい部分です。
これらの感覚は、その人がこれまで触れてきたものなどの経験に基づく部分が大きいため、言語化だけでは伝わりにくい部分が少なからず存在します。
エンジニアの仕事はこれらの部分を考慮しながら、ユーザーに価値を提供することが求められるため、言語化だけではなく、非言語化部分も重要な要素となる、ということを尊重することが重要です。
経験則と身体知
例えばコードレビューの際、明確な言語化より先に指摘のコメントをしたことはないでしょうか?
これらは長年の経験から得られる経験則や普段触れているコードとの差分による違和感などが影響していると思います。
「このコードの書き方はメンテナンスがしやすい」「このアーキテクチャは拡張性が高い」といった内容をエンジニアは日頃から考えていますが、これらを常に意識しているわけではありません。
一度言語化し、自分の中で理解し、感覚として身につけることで、普段のコーディングに活かしていることが多いと思います。
なので、質問されるともちろん過去一度言語化しているので回答することはできるが、常に勉強してきた内容すべてを意識しているわけではない、ということが言えると思います。
考えるより慣れろ、の進化版とも言えるかもしれません。
言語化によって達成できる限界
個人的に好きな曲の一つにポルノグラフィティの「パレット」という曲があります。
歌詞の一節を紹介します。
月は決して泣いていないし 鳥は唄を忘れてはいない 変わらずそこにあるものを歪めて見るのは失礼だ だって知っている言葉はほんのちょっとで 感じれることは それよりも多くて 無理やり 窮屈な服 着せてるみたい
言語化に関する部分としては下記の二つです。
- 存在している事象に対する感じ方は人によって違うので、解釈と事実は異なる
- 「言葉」と実際の事象の間にはギャップがあり、すべてを表現することはできない
言語化の難しさ
テキストコミュニケーションにおける難しさの最大の要因は、コミュニケーションの相手を書き手が選べないことです。
テキストでの知識共有はその場にいない、1人以上の相手に向けて行われることが多く、相手の理解度や知識レベルに合わせた説明が難しく、理解が同期的に進むわけではないので、都度発生する疑問や誤解を解消するためのコミュニケーションを取ることができません。
また、同じ単語について同じ理解をしていることを前提にコミュニケーションが行われるため、誤解が生じる可能性が高くなります。
とは言え、同期的にコミュニケーションを取れば言語化は完璧かというとそうではないと思っています。次に、伝言ゲームの例を挙げて考察してみます。
伝言ゲームから学ぶ言語化の限界
伝言ゲームは、情報が伝達される過程で内容が変化していくゲームです。このゲームが成立する背景には、言語化の幅広さと多様な解釈が可能であることが関与しています。
WEBエンジニアリングにおいても、情報の伝達にはこのような言語化の幅広さが存在し、それがコミュニケーションの柔軟性と創造的な発想を促進する役割を果たします。
言葉には多様な解釈が存在し、同じ言葉でも人によって意味が異なることがあります。伝言ゲームにおいては、この言語化の幅広さが情報の歪みを引き起こす原因となります。 WEBエンジニアリングでも、仕様や要件を伝える際に、言葉の選び方や表現方法によって解釈が異なることがあり、誤解が生じやすくなります。
これを防ぐためには、言語化の際に明確さと具体性を重視し、必要に応じて補足説明や確認を行うことが重要です。また、曖昧な表現を避け、共通の理解を持つための努力が求められます。同じ言葉でも文脈によって意味の異なる単語がプログラミングにおいては多数存在します。(ex. Modelなど)
伝言ゲームの例からもわかる通り、コミュニケーションにおいては100のものを100のまま相手に伝えることは不可能です。
100のものをできるだけそのまま相手に伝えるためには、次のようなアプローチが必要だと思います。
コミュニケーションを円滑にするためのアプローチ
はじめに、基本は言語化で共有基盤を築くことが重要だと思います。
言語化の限界も認識しつつ、それでもテキストコミュニケーションのメリットは大きいため、大部分はテキストで共有していくことが効果的です。
次に、非言語部分をカバーすることを尊重することです。言語化ではカバーできない部分はペアプログラミングやハンズオンなどで補完することが重要で、そこに対する投資を行う必要があります。
また、非言語部分のカバーとして、言語化能力を活用できる例として、メタファーや例え話を使うというものがあります。
コミュニケーションの相手が特定される場合に限りますが、目の前の事象をそのまま理解できていない相手に対して、相手の知っている事象との類似性を説明することで理解を深めることができます。
