見出し画像

異なるチームのメンバーでモブプロをやってみて感じたこと

こんにちは、チームKです。今回は「異なるチームのメンバーでモブプロをやってみて感じたこと」についてお話したいと思います。
まずはメンバーの自己紹介です。

メンバー自己紹介

せっきー ... 入社13年目。法人様向けの鉄道/バスのサービスを主に担当。
ちずやま … 入社5年目。アプリ開発を担当。よく古地図を眺めてまち歩きをする。
ぱんだ… 入社13年目。バックエンド開発を担当。最近毎日1時間歩いています。
つけめん … 入社4年目。Web開発を担当。サウナと温泉が好き。
おむすび ... 入社7年目。公共交通(主にバス)のデータ整備を担当。

モブプロをやることになった経緯

このチームK、実は普段一緒に仕事をしていない、経験年数も異なるメンバーの集まりです。ナビタイムジャパンにはそんなプロジェクトを横断したグループが複数あり、その中の一つとして活動しています。バックグラウンドの異なる我々が、コミュニケーションの促進のために、お互いに話をしながら業務の経験も活かすことのできるモブプロをやってみようということになりました。

モブプロテーマ

今回、テーマとして選んだのは「アプリリリース完了の連絡をSlackワークフローで実現する」です。

テーマ選定理由

別のプロジェクトのメンバーで集まっての作業となるため、テーマは技術的なハードルが低いものを選定した方が良いだろう、という話になりました。

ちずやまのプロジェクトでは、これまでメールで行っていたリリース連絡を、Slackに移行していきたいと考えていました。

モブプロでSlackのワークフローで通知を行うようにできれば、実際の業務で役に立つ上に、技術的なハードルが低いという選定基準も満たし、他のプロジェクトでも活用する機会が多いのではないかと考え、そちらをテーマにすることに決定しました。

実際のモブプロの流れ

今回はオフラインで、全員が同じ部屋に集まって実施しました。まず最初に役割分担を決めます。

ドライバーは今回作成するワークフローを必要としているが作成経験のない「ちずやま」、メインのナビゲーターはワークフローの作成経験のある「おむすび」と「つけめん」が担当します。「せっきー」と「ぱんだ」はサポート役を担当しました。

ドライバーはワークフローを作成した経験がなかったため、どのように作成すればよいかわかりません。

ナビゲーター「チャンネルを開いて、左下のプラスボタンを押してください」
ナビゲーター「『ワークフロービルダーを開く』を押してください」

ナビゲーターは次々に指示を出していきます。

一緒にモブプロに参加し、ドライバーと同じくワークフローを作成した経験のないメンバーからは、

参加者「『ワークフロービルダーを開く』と『ワークフローを作成する』は何が違うのでしょうか?」

ワークフローと絞り込みをすると出てくる2つの文言

のような質問が出ました。このように、他のメンバーの疑問に対しても、その回答をその場で共有できるのはモブプロのメリットだと感じました。

フォーム作成の入力項目で「短い回答」と「長い回答」という選択肢が出てきました。質問の回答の種類を選択するものですが、

ナビゲーター「『短い回答』は1行で済むもの、『長い回答』は複数行になるようなものです」
ナビゲーター「バージョンは1行で済むので『短い回答』を選びましょう」

と初見では迷いそうなポイントも、ナビゲーターが的確に指示することで、ワークフローの作成はスムーズに進みました。

質問のタイプを選択する画面

開始して10分くらいで最初のテスト投稿ができました。

ここからは「投稿先のチャンネルを毎回入力するのではなく固定するには?」「複数のチャンネルに同時に投稿するには?」など、要件を満たすように設定をブラッシュアップしていきます。

モブを開始して20分ほどで要件を満たすワークフローが完成しました。

テスト投稿のワークフロー
この後更に内容をブラッシュアップし
無事に本格運用することができました

やってみての感想

モブプロを実際に実施したあとにすぐに振り返りをしました。そこでは各メンバーから感想や感じたこと疑問点などが数多くあがりましたので、厳選してご紹介したいと思います。

良かった点

● 周りの人も疑問に思ったことを発言できると、疑問や課題を共有できて良いと思う。

● 対面だと言葉が出てこなくても身振り手振りで伝えられる。リモートだと少し効率が落ちるかもしれない。

● あれ、これ、の言葉だったが、対面なので相手に伝わった。

● 共同で1つの成果物を作成したという一体感ができた。(気がする)

気になった点や疑問点

●モブの人数について一番最適な人数は何人だろう?

●今回のワークフローは前に少しやった記憶がある程度だったが、サポート役もわかっている人の方が良い。もっと難しいお題の場合は詰まってしまう場合があるかも?

● 今回は一般的な通知の実現だったので比較的ラクだった。

● 仕様が一部の人しかわからないなど、より複雑になったときに伝え方が難しくなってきそう。作業者は身を持って理解できたが、立ち会った人が理解できたかは気になった。

ほかにもたくさんの意見がありましたが、いくつか厳選してピックアップしてみました。

気になった点・疑問点について聞いてみた

前述であげられた主な疑問点について、モブプロ経験があるメンバーにヒアリングしてみました。

Q1. モブをやるときの最適な人数は?

●3~6人くらいが適切かなと感じます。モブプロではコードレビューも兼ねて行うことがあるので、影響の大きな修正や設計方針などに関する場合はチーム全員で実施すると情報の共有もできて良いと思います。

●コードの修正などの時は2~3人、仕様や作業フローの検討などが必要なときはブレストも兼ねて人数多めにして4人ほどでやっていました。

Q2.仕様が一部の人しかわからないなど、複雑で難しい場合どうするのか

●立ち会ったメンバー内でわからないときは、Slackで他にわかりそうな人に質問をしたり、わかる人をその場に連れてきて見てもらうこともありました。

●すぐにその場でわからない場合は、後日の宿題として調査したり朝会などの場で情報共有をしたりしていました。

●仕様が一部の人しかわからないような状況を作らないために、全員で共有できるようにするのがモブのメリットだと思います。

モブプロの人数については2~6人ほどで、影響範囲の大きさや目的によって適切な人数が変わってきそうです。
また、複雑な仕様の場合に、メンバーの力を借りて疑問点をなるべく早く解決したり、情報共有をする手段としてモブプロを行うのが良いと思いました。
今後モブプロを行う際の参考になれば幸いです。

まとめ

今回は異なるチームのメンバー同士でモブプロをやってみて感じたことについてお話ししました。

モブプロを行うことで、課題の解決や知識の共有ができる・1人で作業するよりも効率がアップする、などナビゲーターとドライバーのどちらにもメリットがあると感じました。
また、モブプロをする中でコミュニケーションを多く取ることができ、共同で1つの成果物を作成することで一体感もできました。

チームに新しいメンバーが入ってきた時などに、コミュニケーションを取る目的でモブプロを行ってみても良いのではと思いました。

最後までご覧いただきありがとうございました。