内藤 裕二/ 8月 23, 2021/ アジャイル開発・スクラム, 試験・セミナー

おはようございます。内藤です。

今年の札幌は例年にない猛暑が続きましたが、一転して気温が落ちてきました。
寝室の布団も日によって布団を切り替えるために、薄手のタオルケットに毛布にと、だいぶ混雑する今日この頃です。

この度、弊社伊藤さんのご紹介にて、8/19(木)に、モブプロのプロフェッショナルである及部敬雄さんにモブプログラミングについて伺う機会を頂きました。

一度社内で試しにモブプログラミングをやってみたのですが、経験者が少ない事もあり、

  • 本当にこのやり方であっているのか
  • そもそも何のためにモブプロをやるのか

といった部分がもやもやとしており、結果としてうまく定着できていませんでした。
今回、プロのお話を伺うことにより、この辺りを明確化できたら良いな、と思っておりました。

・・・のですが、実際のお話はモブプロの枠を超えて、

  • コミュニケーションとは何なのか
  • 仕事とは何なのか

についてまで、深く考えさせられるお話でした。

お話の概要

Meetでつなぎつつ、MURALとご用意いただいた資料を見ながらのお話でした。

現状についてみんなで考えてみる

まずはみんなで現状について付箋に書き出してみます

  • 良いチームとは?
    • コミュニケーションがとれる
    • 上下関係がないフラット
    • 楽しんで動ける
    • いつも一歩先を目指している
    • こわくない
  • いまのチームのよいところは?
    • 呼びかけたらみんな参加してくれる
    • 投げたらボールが返ってくる
    • トラブルがあっても攻撃的にならない
    • 割とみんな楽しそう
  • チームの生産性を下げている要因は?
    • ナレッジの格差
    • 確認の甘さ
    • コミュニケーションのタイムラグ
    • 定期的に勉強する時間が取れているか?
    • 忙しいときは本当に忙しく疲弊
  • いまのチームで「ここが変わるともっといいのに」と思うところは?
    • より相手を信頼する
    • もっと頼る
    • できないことよりできることに目を向ける
    • 別動隊でも交流を
    • 感謝する
  • モブプログラミングのイメージは?
    • 交代時間を守らないと独占状態になってしまう
    • すごく疲れる
    • スピード感の違い気になる…
    • 暗黙知が共有できる
    • 他人のやり方など勉強になる

及部さんのスライドを見ながらお話を伺う

現状認識をまとめたところで、及部さんのまとめてくださったスライドを見ながらお話を伺います
スライド自体に膨大な情報が集積されていて、抜粋しながらのお話だったのですが、かなり気づきを得られるワードが満載でした

作業の分割(ブランチ)には、必ず集約(マージ)が必要になる

  • Outputは増えるが、OutComeは増えている?
  • 作業集約時間を考えると、はたして作業を分割した方が「速い」のか?

「作業を分割すると集約の作業が必要になり、その分割と集約の専門職がプロジェクトリーダ」というお話は、なかなか盲点でした
モブワークは多人数でひとつの仕事をこなすので、生産性が悪いと言われがちだが、ここで述べている生産性は「OutPut≒生産する量」であって、「OutCome≒生産する価値」ではない
複数人でタスクを分割した際に、分割後の集約まで含めると、果たして「OutCome」は分割した方が多くなるのだろうか、というのは、大変心に刺さりました

モブ≒友達の家に集まってゲーム

  • みんなで集まって問題をフルボッコする

モブプログラミングやアイデア出しをみんなで集まると、良い意味で仕事っぽくない雰囲気になります
わいわいとみんなで問題に向き合う作業は、正直、かなり楽しいです
ただし、モブワークとタスク分割はどちらか一方が優れているというものではなくて、得意・不得意がある

レビューする→レビューがある

定常的にモブプログラミングを実施すれば、レビューを「する」のではなく、レビューがその場に「ある」状態になるとのこと
能動的に実施するものは心理的に負担が大きかったり、締め切り等の外圧で精度が落ちがちですが、モブならば常にレビューをしている状態が維持できる、というのは、納得です

モブをやってうまくいかないチームが、なぜ個人で作業していてうまくいくと思うのか

モブワークをやるとチームの空気が悪くなることがある、とのお話から
これは、そもそもチームの問題が顕在化したのであって、モブワークによってチームの問題が発生したわけではないのではないか、との問いかけは、かなり本質をついていると思いました

及部さんに質問

お話を伺った後で、自由に質問させていただける時間をとって頂きました

  • 及部さんが普段の業務で、(モブでなく)あえてタスク分割をしている作業はありますか?
  • オンラインモブプロのコツを知りたいです

など、かなり活発に質問が出ていました

MURALが付箋でいっぱい

全体的な感想

及部さんには、一時間半という長い時間の中で、大変貴重なお話をしていただきまして、ありがとうございました!
ご紹介いただいた伊藤さんにも、大感謝です!
また、今回も弊社社員は全員参加してくれたのが、何よりもうれしかったです

参加した皆さんの感想をまとめます。

  • 特にささった言葉は以下です。
    • 分担作業が効率がいいという思い込み
    • 生産性が上がらない原因の多くはコミュニケーションの問題
    • モブをやってうまくいかないチームが、なぜ個人で作業していてうまくいくと思うのか
    • モブプロは究極の1個流し
  • Unlean(学び直し)という言葉も出てきましたが、実験と会話の繰り返しより良いやり方を模索し続けることが「チームにおけるよいコミュニケーション」なんだと思いました。
    この辺は洋さんも「『定点観測して、それについて会話して、また試す』を繰り返す」と同じことを言ってましたね。
    一辺倒にコミュニケーションだ!生産性だ!というのではなく、チームの成長状態(参考:タックマンモデル)に合わせたコミュニケーション方法を取ること、生産性を高めることで自分達の増やしたいものは何か?とチームで合意することが大切だと思いました。
    及部さんはほんとに経験値の固まりですごい!

  • 漠然とモブプロは敷居が高いと勝手に思い込んでましたが
    むしろプロジェクトやチームのはじめにモブプロで軌道に乗ってから
    少しずつ単位を減らしたり適材適所でモブプロを取り入れたりすることで
    もっと有効に活用できそうだなと思いました。
    特に
    「モブでやってうまくいかないチームがパラバラでやってうまくいくの?」
    「チームの生産性が上がらない理由って上げてみるとコミュニケーションの問題が多い」
    などとても聞いていてはっとさせられる内容が多かったです。
    分担作業が効率が良いと思い込んでモブプロを継続的に実施しないと
    絶対に気づけない視点ばかりだったので聞いていて自分たちでも少しずつ取り入れていきたいと感じました。

  • モブプロというよりチームとして成長するためのお話に感じました。
    • リモートでもよりリアルに近づけるためのシームレスな対策を徹底している。
    • 手を動かすより、話すことの方が大事にしているようさえ感じた。
      それだけコミュニケーションが重要なんだと。(ここ刺さった)
    • 一人で学ぶのではなく共有することで、より発展した話にはなりやすい。確かに。。
  • モブプロについて、ただ多人数で集まるというイメージもありましたが、
    お話を聴いていくうちに、明確にチーム内でのコミュニケーションロスのコストにへの対策として考えられていたのだと理解しました。
    また、様々な開発プロセスは「どう分担するか」を前提に考えられている、というのは今までない発想でハッとさせられました。
    ソフトウェア開発はそもそもモブプロの方が向いている作業が多い、というのも確かに、
    と思う内容で、すぐにでも試したいと思わせるとても身になるお話でした。

  • 「作業は分担したほうが効率が良い」という先入観にとらわれていたことに気づきました。
    実際にモブプロを実行した方々の声で挙がるやりにくさや問題点の原因が、
    コミュニケーション不足に繋がることが多い、という話からも、
    実は「分担したほうが効率が良い」のではなく、
    「一緒に作業してコミュニケーションを円滑に行うのが難しいから、分担したほうが効率が良い」ということだったんだな、と感じました。
    (それくらい、コミュニケーションを円滑に行う、というのが難しいのだな、とも。)
    また、分業してレビューする際に、「処理として間違ってないけど、ここ違う書き方してほしかった」とか
    「聞いてくれたらもっと簡単な書き方あったのに」なんて思っても、
    多忙な時期だと飲み込んでOK出してしまう、っていう経験はあるあるだな~と思ったのですが、
    一緒に作業すると、仕様把握・実装・レビューができていて、
    しかも分業するよりも多くの人の目に触れて機能が属人化しなくなる、というのが大きなメリットだなと感じました。
    お話にもあったとおり、全ての場面でモブプロが最適解というわけではないと思うので、
    作業内容やチームのフェーズに合った方法を選んでいきたいと思います。

私の感想は・・・

「ほしいのはoutput or outcome?」のお話がはっとしました。
創業間もないころにアジャイル札幌の皆さんと紙粘土動物園のワークショップで、一番最初にボール回しで話されていた内容だな、と。。。
レビューについても、完成形をレビューするよりも作業途中のレビューの方が指摘の敷居が低いのも納得です。
進捗・スキルアップ・情報共有と、いろんな分野で問題が起きているように感じていましたが、及部さんのお話にあったように、すべてコミュニケーションの問題であったと気づきました。
プロジェクト規模が大小織り交ぜた状態で、どのようにモブプロ(の精神)を取り入れるか、真剣に検討してみようと思います。

その後のお話

実は、翌週以降のプロジェクトでちょうど設計・実装を行うプロジェクトがあったので、モブプログラミングをやってみることになっています
その辺のお話もどこかでかけたら良いなぁ・・・