はじめに
自分が今の会社に入ってWebエンジニアになってから早7年目という節目に入っているのですが、入社してから「Working Out Loud（大声作業）」という考え方を大事に仕事をしています。
自分のポジションとしては
- エンジニア → エンジニアリングマネージャー → エンジニア
という、いわゆる作業者・管理者を行き来する少し特殊なキャリアを踏んでいるのですが、
良い機会なので、両方の観点から書き連ねてみようと思います。
3行要約
Working Out Loud（WOL）の考え方 : 自身の作業や思考を可視化・共有し、チーム全体の相乗効果を高める方法です。
実践することのメリット : 自身の作業の気づきにつながり、上司や同僚への相談のハードルを下げることにも繋げることができます。
実践するべき人 : 全員が知って損はない情報ですが、ジョインしたての新人さんに特にオススメです。
Working Out Loud (大声作業)とは
スタディサプリさんの記事が非常にわかりやすいです。
Working Out Loudでの実現したいことを引用すると下記の通り
Working Out Loud（コラボレーションによる成果の達成）= Observable Work（作業の可視化）+ Narrating Your Work（作業の共有）
少々難しい表現になっているのですがつまるところ
- 自分の作業内容や思考の過程を他の人から見える場所に積極的にアウトプット（＝可視化）することで、チームにとってよりよい相乗効果を得るための考え方
という表現ができそうです。
やることは単純明快で
関係者が見えるところで自分の作業・思考の過程をとにかくアウトプットする。
これだけです。
自分は何故やっているのか？ WOLで得られるメリット
自分がWOLをしていて主にメリットと感じたのは下記の3つの観点です。
- 思考整理と実績から気付きを得る
- 作業ログをきっかけに相談のハードルを下げられる
- メンバーの自立作業の可能性を引き上げられる
思考整理と実績から気付きを得る
文字に起こすことで自然と自分の作業を振り返ることになるので、
自然と思考と実績を整理することができます。
作業や検証がどん詰まりした際に過去の内容を振り返ってみると、
実はTypoしていたことに気付いたり、検証の漏れに気付いたりなど
新しい発見に繋げることができます。
揮発性の高い情報（単発系のスクリプトの実行のログであったり、実行当初のデータベースやJSONの出力値など）
もセットで残せると後々の気付きに繋がりやすいです。
作業ログをきっかけに相談のハードルを下げられる
こちらは 作業者（エンジニア/プログラマ）視点での感想です。
作業内容が可視化されていることで上司やチームにHELPを求める際の説明資料としても効力を発揮します。
HELPを求められた側はそのログを見れば当事者が何をしたのかおおよそ把握ができますし、当事者も口頭での説明は最小限にすることができます。
つまり、相談するための準備が減るのでハードルを下げられます。
また偶然目に留めてくださった方がたまたま知っていた場合、ぽろっと助言を頂けることもあります。
もちろん直接聞けるのがベストですが、こういったおこぼれに預かれるのもWOLをしているときのメリットですね。
特にジョインしたての新人にこそWOLはオススメです。
なぜなら新人は業務知識・技術知識共により多くの情報を必要がある状況にあるからです。情報のやり取りの加速のキッカケになるWOLは非常に効果的です。
メンバーの自立作業の可能性を引き上げられる
こちらは マネージャー視点での感想です。
WOLは コラボレーションによる成果の達成 を目的として、 作業の可視化 と 作業の共有 の行うことを示しています。
報告・共有などは体形立てられ結論ベースの記述になることが多いですが、
作業者の視点だと「解決までの過程の方が大事」というケースも多いです。
このようなケースで作業ログが残っていると、
指示する側は「このスレッドに当時の検証過程が残っているから参考にして欲しい」という追加情報が出せますし、
作業者の視点でも解決のための情報をより多く手に入れることができます。
「当時の思考・作業内容を残しておく」であれば、ただ内容を書き連ねるだけなので、チームに対する負荷もそこまで掛けずにトライできることもポイント高いです。
アウトプットに意欲があるメンバーがいれば、どんどん促しましょう。
WOLがチーム内に広まるとアウトプットに対する障壁が下がり、
チームが情報に辿り着けるチャンスが増えていきます。
つまり、メンバーが自立して作業できる可能性を引き上げる好循環に入ることができるのです。
今の自分はいちエンジニアでありマネージャー職からは降りているのでチーム運営という責任は役割上負ってはおりませんが、
チームにとって好回転した経験や率先垂範の意を含めて、今もWOLを続けています。
興味が出てきたそんなあなたへ。やるときのポイント
思ったこと、やったことをそのまま書き連ねる
とにもかくにも「思考したこと、作業したことを書くこと」を第一優先としましょう。
社会人の基本として「報告は体系立てて整理してから」と言われますが、
WOLはあくまでも「思考および作業のログ（＝可視化）」であり報告ではありません。
作業内容をまとめる場面が出てくる時がありますが、それは報告する時にまとめる形で全然間に合います。
なので、体系立てて書くことの優先度は下げてしまって問題ないのです。
あれこれ考える前に、とにかくアウトプットしましょう。
さすれば道は開かれます。
報告・共有する場合は簡潔なサマリを添えて
作業していて詰まった際、上司や同僚にヘルプを求める場合、
WOLで書き連ねたスレッドをそのまま投げるのはやめましょう。
前述の通り体系立てて書くことの優先度が下がっている文章のため、
事前情報なく渡されると読む方は割としんどいことが多いです。
箇条書きでいいので内容を簡単にまとめた上で参考資料としてWOLを添える形にするだけでも読む側の理解は非常にスムーズになります。
出来る限り関係者が見える場所で
WOLはチームへの共有にも強く重きを置いている考え方なので、
関係者が見えるチャンネルやルームでやることを積極的に推奨します。
最初は少し恥ずかしいかもしれませんが、直ぐに慣れます。
一方でとにかく情報量が増えるやり方でもあるので、
チャンネルが必要以上に荒れないように配慮しましょう。
（Slackでやるならスレッド形式でおこなう等）
心配であれば、実施方法をチームと合意形成してしまうのが確実です。
最後に
いかがだったでしょうか。自分が大切にしている Working Out Loud という考え方のお話でした。
特に前準備もいらず直ぐに始められる考え方なので、興味がある方はぜひトライしてみてください。情報の取れ方が大きく変わると思います！