Working out Loud, Working in Progress

デジタルツールで組織をKaizen　シリーズ vol. 1

![04ce1c8a-eb91-82fd-bc74-94d05ef4c099.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/8585/6a7e500f-463e-1fd5-4855-5afed4733089.png)


## はじめに

こんにちは、@shootaです。
デジタルツールでのコミュニケーションの理想像について、フルリモートで培った経験や知見をまとめていこうと思い立ちました。今回はvol. 1ということで、「うまく働くひとたちのチャットコミュニケーション」について、ひとつ書こうと思います。


## :thinking: まず考えてみよう

仕事をするときに、同じ場所にいる場合とそうでない場合の違いについてまずは考えてみましょう。同じ場所にいないとき、何が失われるでしょうか。「話合いで得られる情報や知見」はもちろんですが、実は無意識に受け取っている情報の多くを気づかぬうちに失っています。
たとえば、

- 相手がいま作業をしている・いないという視覚情報
- 相手の作業に求められる集中度
- お互いの音声をつかったニュアンスの伝達
- 表情や雰囲気から読み取れる情報
    - あせりや疑問、我慢などのストレス状態
    - 体調、ねむけ、疲れなどの身体的状態
    - 作業に向かう手順やその思考の順序・癖

これらは個人それぞれのなかで刻一刻と変化するものである割に、メンバーが互いに協力して仕事をするうえでクリティカルなものではありません。それゆえリモートではこのようなことを発信することが少なくなり、失われがちになります。しかしながら、このような情報の不足はちょっとしたすれ違いやタイミングの悪さを生み、ときに協力すること自体が面倒になったり、おおきな手戻りを発生させることもあります。

## :mega: Working out Loud, Working in Progress 

このような事態を回避するために、**「作業は完了する前に公開すること」**という考え方が古くから（おおよそ6年くらい前から？）、徐々に浸透するようになってきました。いわゆる "Working in Progress (WIP)"と呼ばれているものです。しかし、WIPには欠陥がありました。WIPは「作業の対象物」を公開・共有する手法なので、対象物がどういう経緯や考えから生まれたかを、受け手が想像したり検証したりする必要があったのです。

そこで近年、 **"Working out Loud (WOL) "** という仕事の方法が注目されています。
かんたんに言うと、WOLは作業の開始から終わりまで、自身のアクションを言葉で発信しつづけながら作業する方法です。作業の開始、詰まったとき、疑問、勘違い、立てた仮説、検証方法や結果、ケアレスミスなど、自分が作業中にみたものを他者に届くようにずっと発信し続けるのです。**ただ発信するのではなく、他者に届く場所で、というのが大事です。**

---

元は海外で書籍化されたものですが、Quipper社のブログが日本語でよく説明されているので、こちらを読んでいただけると良いかと思います。 [Working Out Loud 大声作業（しなさい）、チームメンバー同士でのトレーニング文化の醸成](https://quipper.hatenablog.com/entry/2018/11/14/working-out-loud)
一応、本家サイトもご紹介します。[WORKING OUT LOUD
](https://workingoutloud.com/)

ブログの方でも様々なメリットが挙げられていますが、最も高い効果を期待できるのは「自分の作業が見える形になること」、「最も早い段階で他者の助言を受けられる可能性が生まれること」です。ちょっとなにかで行き詰まったときに、これまでした作業を書き出したりしただけで自己解決した経験はないでしょうか。WOLではその状態を常に維持して作業を進めることができます。これに加えた副次的な効果として、メンバーの言語化能力が急激にレベルアップすることも期待できます。

## やってみよう

ここからは経験からえられたWOLの実行例をご紹介したいと思います。どんなことを発信するかを参考にして、ぜひチームでやってみてください。実際に自分がやっている様子も合わせて添付しておきます。だいじなことは、「書いた内容に返答やリアクションを期待しない」ということです。書くことそのものに大きな意味があります。もちろん、助けられるとおもったらリアクションしてもいいでしょう。

### :point_right: 作業の開始宣言を書く

<img width="470" alt="338aebdc-322f-24ec-0497-e46514206068.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/8585/2c6062c0-93fd-7390-c1f8-ab9ec67afedb.png">

- いま、誰がどの作業をどこから始めるかわかる (When / Who / Whatが伝わる)
- タスクの優先度に間違いがないか、チーム内で無意識に確認される。
- :dog:  「〇〇のほうが優先だけど、そっちは完了しました？」などのコミュニケーションが生まれる。

### :point_right: 手が止まったときに、止まった原因を書く

![ecf1b6a0-88f0-6cf9-aeda-8a68df48bd43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/8585/56233e87-4ad0-3968-2a59-393af894593f.png)


- あなたが詰まった場所はみんなも高確率で詰まる。
- 詰まりやすい場所が可視化されて蓄積されると、改善するポイントが見えてくる(ちいさなKPTになる)


### :point_right: 疑問がでたら深く考えずにすぐに書く
<img width="380" alt="fd5cec58-8e8d-7faf-8079-20cb9de53d78.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/8585/2444cc44-fa1f-f141-844b-4cf3b5dc1dc9.png">

*このスクショの場合では、チームで設計漏れがあることに気づけました*

- 実は勘違いだったり、他者の伝え漏れがあったりする
- 誰かにその疑問が拾われなくても、書いているうちに自己解決することが多分にある
- 「分かりづらい」、「迷いやすい」は事故や失敗の温床なので、マネージャーや担当者はそれをすくい取ることができる

### :point_right: これから検証しようとする内容と方法を書く
<img width="413" alt="551e11b2-ee43-7f72-31c4-aa069391881b.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/8585/a6b4cede-47e4-9237-97f9-3b515b585cdf.png">

- 問題がまだ解決していないことがわかる
- 他人の検証方法が周りからすると実は大きな知見になったりする
- 違う検証方法で同じ結果が得られると結論の確度が高まる


## おわりに

コミュニケーションはチームワークの基礎体力ですが、なかなかレベルを高めることができない組織力のひとつでもあります。すべてのチームにプラスになれる手法は難しいですが、騙されたと思ってWorking out Loudでワイワイガヤガヤと思考をたれ流しにしながら、「チームでひとつの仕事」をしてみてはいかがでしょうか。