見出し画像

リモートワークが更に良くなるPairstorming（ペアワークのすごいやつ）が素晴らしいよ

INVITRO

こんにちわ！INVITROの中の人(山本か小蔵の重ね合わせ状態）です。前回の「リモートワークをペアワークで行うと良い」記事は読んでいただけましたか？本稿、一応続きの記事ですのでペアワークって何？となった方は一読をおすすめいたします。

What’s ペアストーミング

チームやワークを行う人が定義したワークフロー(タスクと時間と完了条件の流れ）とともに、画面共有等で情報共有しながらペアワークをすすめる実践型のワークメソッドです。

INVITROとしてこういうのをやろうとしている

プレイング・マネージャーとなりがちな読者諸兄姉のみなさんは一度はこのように思われた経験があるのではないでしょうか。
「俺（私）が二人いればなあ..」
「俺（私）だけできても事業がスケールしないし大変」

実案件で「制作を行いながらPMも行う手前、チームのケイパビリティまで視野に入れてプロジェクトを遂行するのは至難の業」であるというリソースマネジメント上の課題に苛まれておられる方もそれなりにいるのかなと想像しております。そうでなくても、「大変にスキルフルな頼みの綱のあの人が退職してしまうと現場持たなくなりそう ガクガク」みたいなことはありがちなのではないでしょうか。

そこで弊社としては上記のような課題を一掃すべく、「効率的にアウトカムを達成できるチームを創出できるフレームワークを作りたい」と願っており、 PairstormingAPPとしてフレームワーク自体をプロトタイピングしながら日々のワーク・開発を行っています。

画像1

現在開発検証中


Pairstormingのメリット

・Workflowと呼ばれるプロセスを作成することで、やることが計画でき作業見積もりができます。
・やりたいこと(仕事)が俯瞰して考えられるようになります。
・仕事の仕方自体をチームで評価でき、次はもっとよくなる (スクラムのスプリントの文脈を継承しWorkflow自体をアップデートする）
・何が優先だっけを常に確認しながら(クロスチェック的な意味で）できるのがかなりよい。
・例えるなら時間制限とアジェンダがあり、速攻で終わるMTGのような生産性。
・ワークすること自体が知識共有となる。

ペアストーミングのやりかた

画像2

まずは通常のペアワークのやり方を説明します。
・二人一組または三人一組となり、zoomなどの画面共有できるツールを使い画面共有を行います。
・画面共有している側がドライバーです。
・画面を見ているほうがナビゲーターです。
・ナビゲーターの人はドライバー側に作業指示を行います例えば「shift ⌘ Fしてシンボルライブラリを開き、navigationからheaderのnoramalをドロップして」「overridesの項目からiconが２つのものを選ぶ」「VS Codeで変数にカーソルを合わせ、F12で定義にとんで使用箇所がオーバーレイで出るよ」などの具合です 。
基本的に会話しながら、なぜそのようなオペレーションなのかや、指示される側はこっちの方法のほうが早いよなど議論しながら進みます。その過程でお互いの経験や知識がうまく浸透していき最適なワーク方法へと進化していくところが主眼です。また、通常考える作業、批評する作業、オペレーションは同時に行っているようで、迷いや思考停止などによって進んでいないことがあり、そういうロスを無くす目的も強いです。

次にゲームストーミングのやり方を説明します
・現在やろうとしているワークを作業工程としてブレイクダウンしていきます。
・一つの工程が何分なのか時間を定義します。
・最終的に欲しいアウトプットを得られるような作業工程になります。

・ゲームストーミングは各工程をinput-process-outputという形で定義し、前の工程で行った結果が必ず次の工程のinputとなるような定義をします。それによって現在の工程がなんのためにどういうことをやればいいのかという理解の助けになります。逆に言うと次の工程のためにならないことをその時には我慢するのも必要となってきます。直感的には大きな枠組みを理解しながらすすめることが大切ですが、「一つのことに集中して時間内に良い結果を得る」のが重要です。

ペアワークとゲームストーミングを合体させます。
ゲームストーミングのプロセスのことを、ペアストーミングでは「ワークフロー」と呼んでいます。
ワークフローの最小単位であるタスクを誰がやるかをアサインしていきます。
画面共有を交代しながら行うため、頻繁にファイル共有（dropboxなりgitなり）でチェンジするよりはひとかたまりのワークをつづけて同じ役割で続けたほうが煩雑にはならないようです。

このように予め用意したワークフローをペアワークしながら進めていくのがペアストーミングの形式です。なんでこんな形式になったかというのは次項に記しますね。

---

ペアストーミングは如何にしてなったか

時代に合わせて段階的にいいとこ取りをしながらワーク方法を発展させた結果、ペアストーミングが誕生した。

Pomodoro期
10年くらい前にPomodoroテクニックを用いて日々のタスクをこなしていくと気乗りしなくても案件が片付いて行くことを経験。基本的にタイマーを用いて時間を区切り作業をすることで生産性が上がった。

Gamestorming期
9年くらい前にLogical ThinkingとDesign Thinkingを一緒にインストールするワークショップを行っており、そのさいにO’Reillyから出ていGamestormingという本に出会い、

画像3

ゲームストーミング from O'reilly

ワークショップのプロセスをinput-process-outputで記述し、時間管理するフレームワークを導入。ゲームストーミングを実行するための(懐かしの)jQuery webアプリを開発し、画面共有しながらコンピュータの処理のように定義されたタスクを順次実行していけるようにした。

余談: プログラミングなどで実行している処理がそれ自身を呼び出すリカーシブコールがかっこいいみたいに思っていた頃で、Gamestormingを行うとGamestormingが生産できる再帰的ワークショップを設計した。ワークショップ参加者が独自のスキルをフレームワーク化し、Gamestorming化するという内容。再帰的プロセスは非常に功率がいいので、Pairstormingのワークフローを作成する際も同じやりかたで行っています。
余談２:再帰処理を最もわかりやすく示した例は次のものだろう。”今日ミルクを配達して明日もこのメモを読むこと。”（天才スマリヤンのパラドックス人生より）

Pairwork期
某スクラムおじさんのやっているワークショップがパートナー先で行われた際に、Joy incの本とXPのペアプログラミングの手法を紹介してもらい、次の日からペアワークをはじめる。
意外とうまくいったため、さらなる拡張をもとめた結果、門が開かれる。

そしてPairstormingへ…
3年くらい前のある日 アクティブリスニングを使ってUXインタヴューを行うスキル習得ワークショップの設計を行っていた。一人のファシリテーターが15名に2時間以内でアクティブリスニングやUXインタヴューの技術を教えるのは限界がありこれを解決する必要があった。

・15人全員がアクティブリスニングを行う、聴く側の体験をしなくてはいけない。
・ファシリテーターが全てのインタヴューを見ることができない
→ ３人一組のチームでぐるぐるロールチェンジしながらやるペアストーミングを設計。
聞かれる側/聞く側/記録者＋フィードする人の役割をそれぞれに与え、単位時間毎に役割を交代しながら、トライアルし、できたこととできなかったことを切り分けながらチームで学習の実行に成功した。

---

現在ではソフトウェアでワークフローを定義し、2人/３人のチームで毎日の仕事を設計、実行しながらワークフローとフレームワーク自体を最適化・アップデートしています。

次回はサービス全体をEpic Storyで記述するサービスデザインの手法かUXとデザインの関係についてあたりを書きたいと思います。



この記事が気に入ったらサポートをしてみませんか？