モノタロウでスマホアプリを担当しているuw_shioです。 今回は増員をしていった結果、各自がそれぞれ頑張るようなチームとなってしまった状況から、ペアワークをきっかけに、ペアプロ、モブプロが文化となってチームとしてワークできるようになったお話をします。
組織の規模が拡大していく過程において、属人化された業務を個人単位で行う働き方から組織としてワークする形へのシフトは避けて通れない道となります。そんな時に悩みの種となりやすいのが、業務の属人化やメンバーの育成ではないでしょうか。 部下や後輩に新しい業務を引き継ごうとしても時間がかかり上手くいかない、そんな経験ありませんか？私は過去に何度もありました。 例えば、アフリカーンスなど未知の言語を習得するというタスクをアサインされたとしたら、何から始めて良いか分からず漠然とした不安を感じるのではないでしょうか。新しいこと、とりわけ新しい業務に対しては先入観から実際の難易度よりも難しく感じてしまう傾向があり、心理的なハードルが一番のボトルネックとなりえます。そんな心理的ハードルがペア（モブ）プロによって激的に下がった事例をご紹介します。
組織の規模が拡大し業務が属人化している、後輩やチームメンバーに引継ぎがうまくいかない時の打開策にいかがでしょうか。
モノタロウにおけるスマホアプリ開発の歴史
モノタロウにはPCサイト、スマホサイトの他に、Android向けとiOS向けにそれぞれのスマホアプリが存在しています。
どちらのOS向けのアプリも数年前まで開発を外注にお任せする形で長い間１～２名で保守運営を続けてきました。当時は担当者がWebサイトの改修を行い、Nativeのコード（Objective-C、Android java…)の検収も行っていたため、統括的にみられることが当たり前でした。
ここ数年でスマホアプリの売上規模も大きくなり、アプリリニューアルを行い（言語も変更）、チームメンバーも増え、両OSのアプリとも外注から内製化へとシフトしました。
開発言語毎に担当者が分かれたことで生じた課題
モノタロウのスマホアプリ担当はNativeだけでなく、Webサイトも併せて改修を行う機会が多く、ご覧の通り扱う開発言語が必然的に多くなります。
せっかく人が増えたのに、各自がそれぞれ頑張るグループとなっただけで、チームとしてワークできていない状態に陥ってしまいました。
業務を平準化したいがうまくいかない
メンバーの担当領域が言語の壁でサイロ化してしまった。そんな状況を打破すべく、 ”属人性を下げたい” と考えるようになり、まずはメンバーに担当領域外の「簡単なお仕事」をアサインし業務範囲を拡げようと試みました。結果、予想以上に作業に時間がかかり、苦悩するメンバーの姿を見ることになりました。自分自身も ”もしかしてメンバーの苦手意識を植え付けてしまったのでは？” という懸念と罪悪感が残る結果となりました。
はじめての「簡単なお仕事」は簡単ではない
とあるサービスの導入時にデータを取得するタスクが発生しました。
- BigQueryは初見だとどこから操作していいのか分からない。 projectがない、SQLはどこへ？など
- BigQueryはSQLが特殊。 標準？レガシー？
- モノタロウのデータ構成を知らないとSQLは書けない。
- SQLを正しく絞らないと利用料金が高額になる。 トライアンドエラーに制限とプレッシャー
など、メンバーの立場に立った場合に、困りそうな、押さえるべきポイントは沢山あることに気がつき、ここは ”説明するよりもペアワークでタスクを実施する方が安全だ” と考え、ペアワークで実施してみました。
その結果、2時間程でさくっと終わらせることができました。
ペアワークでメンバーの業務範囲が拡がったことを実感した体験でした。
言語をシャッフルしてペア（モブ）プロを実施
この成功体験からふと思いつきます。”もしかして言語の壁もペアプロだったら敷居が低くなるのでは？” 正直、アプリ業界で言語をシャッフルというのはなかなか耳にしない試みではありますが、せっかくなのでとりあえずやってみて都度改善することにしました。
まずペアプロの基本的なやり方はネット上の情報を参考にしました。今回は言語をシャッフルするというレアケースであるため、基本的なやり方に以下の基準を追加で設けました。
- 各自の得意言語はそのまま。 得意言語に関してはナビゲーターを行う。 *1
- 対象：簡単な案件。 目安として、2時間程度で説明＋実装が終わる。
未知の試みであったため、まず一度実施してみて、すぐに振り返りを行いました。
メンバーからの感想はポジティブで ”今後も継続すること” はすぐに決まったのですが、継続にはもちろん改善が必要となりました。
ルールを追加して計画的に実施
メンバーからヒアリングして “困ったこと” は以下のような内容でした。
- ペアプロで実施したい案件が他にも複数存在している。
- 次回がいつ開催されるか分からない。
- ペアプロ実施と案件リリースのタイミング調整が複雑。
- ナビゲータ側の準備が必要となるため、対象案件を早めに決めて欲しい。
メンバーがペアプロを効果的に捉えており、継続していく上で改善したいことにフォーカスされていることが分かります。これに対する改善として、以下のルールを追加しました。
- ペアプロ（もしくはモブプロ）を隔週で定期開催する。
- 予定表を作成して対象案件を管理する。
- 対象案件は常に２つ先まで決めておく。
ペア（モブ）プロを定期的に実施し予定表で対象案件を管理することで、リリースタイミングや、メンバー間で得られる内容に応じて対象案件に優先順位をつけることができるようになりました。 また定期的に開催されることでペアプロが文化として浸透し、より規模の小さな案件や困りごとはメンバー間で気軽に３０分ペアプロ（もしくはペアワーク）をするという空気感が生まれました。
まとめ
こうしてペア（モブ）プロを定期開催するようになって約半年が経ちました。
チームメンバーから定例ペア（モブ）プロに対する感想をヒアリングしてみました。
- IDEやChromeなどの開発ツールの実用的な使い方を知られたことが一番良かった。
- 作業自体というより知見、情報、設計イメージの共有の方が有用。
- 言語自体を学ぶのには時間が短い。
- 次にやってみたい対象：開発環境が壊れたときのペアワーク
チームメンバーの意見からも、はじめての業務を実施する人にとっては ”ツールの使い方や前提知識” という部分が実作業のボトルネックになっており、担当者の考える ”簡単な作業” が経験のない人には ”簡単ではない理由” が読み取れます。そして “知見、情報” が期待されていることからも、教える側も ”業務を整理し、より深く理解する” 必要があり、“はじめての業務はペア（モブ）プロで一緒に行った方がお互いにとって良い” ことが分かります。ただしペア（モブ）プロだけでは開発言語自体を学ぶには不十分であるため、あくまでも ”最初のハードルを下げるとっかかり” と考えてもらった方がよさそうです。
またスケジュールを先まで用意することで事前準備が行いやすくなり、定例イベントにすることで徐々に ”チームの文化として浸透” していきます。今回は異なる言語を対象としたことで、対象となる案件の幅が広がり、なんなら ”プログラミングに限らない” という雰囲気まで出てきました。*2 ペア（モブ）プロが文化となったことで、メンバーがこれまで ”難易度が高いと思って手を付けなかった分野” にチャレンジすることの心理的ハードルがかなり下がり “やってみたい新しいこと” として積極的に取り込もうとする姿勢が見えるようになりました。
各個人でのワークからチームとしてのワークに進化したと実感しています。
チームでワークする為に “垣根を超えた定例ペア（モブ）プロ” お勧めです。 以上、uw_shio でした。
