はじめに
この記事は言語化コミュニティAdventCalendar2021の20日目の記事です。
言語化という言葉をエンジニアになってからよく使うようになりました。
私は主に、煩雑で抽象的な言葉を具体的でわかりやすい言葉にまとめる際に使います。
また、ドキュメントにまとめる行為も言語化とセットで行うように心がけています。
普段、言語化をどのようなシチュエーションで意識しているか、
どのような恩恵があるかを簡単にまとめようと思います。
完全に主観で書いたポエムなので、特にリファレンスとかはないです。
「なんかそういうデータがあるんですか？」という指摘はご容赦ください。
ドキュメント化の恩恵
まずはドキュメント化の恩恵を感じる場面を簡単な説明と共に書いていきます。
再参照コスト軽減
再参照コストとは一度調べたもの、理解したものを再度調べ直すような手間のことです。
(私が勝手にそう呼んでいます)
Qiitaの記事やZennを書くようになって、再参照コストが減ったと実感することが多いです。
GitHubのReadMeにも同様にいろいろとメモするようになりました。
ドキュメント化することにそれなりの時間はかかりますが、
以後の再参照コストを考えるとかなりの効率化に繋がります。
仕事においてもこれは有効であると実感しています。
GoogleドキュメントやNotionなどにまとめておき、
社内メンバーに対して閲覧可能な状態にしておくと、いつかきっと役に立つ時がきます。
思考の整理
思考を言語化するプロセスでバラバラだった思考が整理されます。
言語化が進まないときは思考がまとまっていないサインなので、
言語化する価値が大いにあります。
言語化のプロセスで、
"理解できていないこと"や"理解に誤りであったこと"などが発見できます。
また、整理した思考をドキュメント化することで自分の思考を他の人と共有することが可能になります。
その際、ドキュメント化した内容が本質とズレている場合であっても
"どこがどう違うのか"、"どの思考の過程で誤りがあったのか"などがハッキリし、
問題解決がスムーズになります。
心理的安全性の担保
ドキュメントは**「今週の進捗はいかが？」と問われた際の進捗内容の証明書**になります。
私はXRエンジニアとして、
新規デバイスの性能調査や新しい機能・SDKの検証などを過去に行ってきました。
そういった新しいものというのは、情報が少なく、
なかなかうまく動作させられないことがあります。
新しい技術には一定の調査期間が必要で、できることとできないことの切り分けを行うために
トライ＆エラーを繰り返す必要があります。しかし、他人からはそのトライ＆エラーは見えません。
「見せられる進捗ないの？」と言われる隙がある状況は心理的に安全とは言い難いです。
そこで、トライ＆エラーの部分をドキュメント化することで、
進捗内容の証明書としてドキュメントを提示できます。
加えて、そういったトライ＆エラーの情報は再参照コストの軽減にも繋がります。
さらに自分では解決できなかった躓きポイントを他の誰かの知見で解決できることがあります。
Zennのスクラップの機能などがこれに該当します。
トライ＆エラーの情報は実はとても貴重です。
記事として公開するとマサカリが飛んでくるような内容も、
このスクラップ機能のおかげで一気にハードルが下がります。
Zennのスクラップは本当に素晴らしい機能だと思います。
その他、積極的に言語化(ドキュメント化)したいこと
次に積極的に言語化(ドキュメント化)することでその後の生産性を高める事柄についてメモします。
かなり初歩的なことを書きますが重要なことです。
目的
目的が言語化されているとものごとを理解する速度が上がります。
2つの例に沿って説明します。
・プロジェクトの目的
・ミーティングの目的
プロジェクトの目的
プロジェクトにおいて成し遂げたい目的を正しく理解することで開発の速度が上がります。
もっと細かい粒度で言うと、機能レベル、デザインレベル、ロジックレベルで目的は存在し、
それぞれの目的がツリー上になってプロジェクトの目的へと繋がります。
いずれの目的もはき違えると、間違ったものを作ってしまうことになりかねません。
そうなると、手戻りが発生して計画通りにプロジェクトが進まなかったり、
有名な下記の図のように"顧客が本当にほしかったもの"とのズレが生じたプロダクトになったりします。
【引用元】：Tree Swing Cartoon Pictures
プロジェクトや細かい機能単位での目的の理解に時間をかけることが、
結果的に開発速度を上げることに繋がります。
ミーティングの目的
私もそうなのですが、みなさんも毎週何かしらのミーティングに参加しているかと思います。
ミーティングの冒頭でそのミーティングを行う目的を言語化して共有することで、
その後の話への理解度が上がり、適切な内容の発言をすることができます。
もちろん、定例のような目的がそうそう変わることのない会議の場合、
毎回説明する必要は無いと思います。
その場合、下記のような手段が有効だと思います。
・オンボーディング期間に時間を取って説明する
・社内の誰もがアクセスできる場所にドキュメント化して保存する
経緯
"目的の設定に至るまで"の経緯です。
本当に目的が正しいかどうかの指標としての役割を果たします。
どういった背景で目的が設定されているかを把握しておかないと、
そもそもやる必要の無いことやズレた施策を気付かないまま進めてしまうことになりかねません。
また、経緯を参照することで優先度がはっきりします。
小さい機能単位の目的だけなく、組織として成し遂げたい大きな目的(会社の方針など)も
その決定までの経緯がしっかりと言語化されていれば全員の足並みを揃えやすい状況を作り出せます。
おわりに
基本的なことですが、忘れがちなので言語化しました。
普段ポエムを書かないのでこのような場を設けていただいたことに感謝します。ありがとうございます。