執筆者
M.N.
ベースとなるモブプログラミング
PHPカンファレンス2025の振り返り、第6回です。
今回は「モブワークによるSECIモデルの実践」というセッションについてです。
「モブプログラミング」という言葉自体も、「モブワーク」や「SECIモデル」という関連ワードも正直あまり馴染みがありませんでした。
プログラミング以外の作業にも広げた話、ということで興味を持って聴講しました。
モブプログラミングとは
まずベースとなるモブプログラミングの説明がありました。
モブプログラミングとは、チーム全員で1台のパソコンを使ってコーディングする手法です。
ペアプログラミングを3人以上に拡張したもの、と考えるとイメージしやすいです。
役割は2つに分かれています。
01 ドライバー
実際にPCを操作する人
02 ナビゲーター
指示を出す人
この2役を10〜15分程度で交代しながら進めていきます。
メリットとして挙げられていたのは以下のような点でした。
知識、暗黙知の共有
コード品質の向上
書き方の統一
学習機会の増加
熟練者の判断がリアルタイムで伝わる
属人化の回避
モブワークとは——コーディング以外にも広げる
モブプログラミングがコーディング特化なのに対し、モブワークは要件定義や設計など、抽象度の高い作業にも適用する考え方です。
よく出てくる反論として「リソース効率が悪い」という意見があります。
これに対してセッションでは、「フロー効率」という観点から反論していました。
◆リソース効率
各人が常に何かをやっている状態を指します。
◆フロー効率
仕事そのものがスムーズに流れているかどうかを指します。
モブワークは一見リソース効率が悪く見えますが、レビュー待ちや引き継ぎのコスト、手戻りを減らすことでフロー効率が上がる、という考え方です。
「個人 vs 問題」から「チーム vs 問題」への意識変化が起きやすい、という説明も印象的でした。
知識創造の4つのプロセス
SECIモデルとは
SECIモデルは、知識創造の4つのプロセスの頭文字を取ったフレームワークです。
モブワークと親和性が高いとして紹介されていました。
S（共同化）
暗黙知を直接共有するプロセス
E（表出化）
暗黙知を言語化するプロセス
C（連結化）
形式知同士を組み合わせるプロセス
I（内面化）
形式知を実践を通じて身につけるプロセス
このサイクルを意識的に回すことで、チームの知識が積み上がっていく、というモデルです。
各プロセスのモブワークでの実践
S：共同化（暗黙知の直接共有）
モブワークにおいては、ドライバーとナビゲーターをローテーションすることで、熟練者のやり方を直接体験できます。
「なんとなくこうやっている」という暗黙のノウハウを、言語化しなくても伝えられるのが特徴です。
雑談や交流を通じた信頼関係の構築もこのフェーズに含まれるそうです。
E：表出化（暗黙知の言語化）
「なんとなくこうした方がいい」という感覚を言葉にするプロセスです。モブワークでは、ドライバーが操作しながらリアルタイムで思考を言語化したり、セッション後に振り返りとして「なぜそうしたか」を言語化したりします。
これは前回のSOLID原則の記事でも触れた「設計意図を言語化する」という話と通じるものがあります。
C：連結化（形式知の組み合わせ）
言語化された知識同士を組み合わせるプロセスです。複数チームの知見を統合したり、異なるバックグラウンドを持つメンバーの知識を掛け合わせたりすることで、新しい知識が生まれます。
I：内面化（実践を通じた習得）
得た知識を実際に使うことで、自分のものにするプロセスです。
セッションでは、習得したタスクはソロワークに移行し、取得した知識を他者に教えることでさらに定着を促す、という段階的な進め方が紹介されていました。
振り返ってみての所感
当時のメモには「複数人で一つの機能をつくる、となるとどうしてもリソースが気になるが、『暗黙知の共有』というのは良いなと思った」と書いていました。
1年経って振り返ると、この「暗黙知の共有」という観点は、チームの成長という文脈でじわじわ重要性を感じています。
ドキュメントに書けない「この人ならこう判断する」という感覚は、一緒に作業する中でしか伝わらないものですし、それが失われると属人化が進むばかりです。
当時のメモに「完全に教えるフェーズであれば、ペアプロの導入くらいはしてみても良いかもしれない」とも書いていて、1年後の今もまだ導入できていないのが正直なところです。
小さいところからでも試してみたい、という気持ちは変わっていません。
次回は、「PHP 8.4の新機能『プロパティフック』から学ぶオブジェクト指向設計とリスコフの置換原則」についてレポートします。
