先週、コラボレーションを生む場づくりとファシリテーションについて話す機会がありました。その中で「人以外のものがファシリテーターになることもある」という話題が出たので、それについて考えてみたいと思います。
私はプロダクト開発の現場で、職能や関心が異なる人々が「同じプロダクトを作る」という共通の目的のもとに集まる場面を何度も見てきました。興味深いのは、プロダクトという共通の「モノ」があることで、自然と関係性が生まれ、コラボレーションが起きることです。これは、プロダクト自体がファシリテーションしていると言うことができるのでしょうか。
GitHubが育てるエンジニアとしての成長
例えば、新しいチームでGitHubを使い始めたときのことを考えてみます。GitHubはソースコードのバージョン管理と共同開発を支援するプラットフォームで、世界中の開発チームが利用しています。
間違ったブランチにコードをpushしてしまう、巨大なプルリクエスト（PR）を作って誰もレビューしたがらない、コンフリクトの解決に四苦八苦する——こうした「失敗」は、GitHubを使い始めた誰もが通る道だと思います。
しかし、これらの失敗を重ねる中で、チームは少しずつ成長していきます。適切な粒度でコミットを作る技術、レビュアーが理解しやすいPRの書き方、効率的なブランチ戦略——これらは「GitHubの使い方」に習熟することでありつつ、エンジニアとしての作法や思考法を学ぶプロセスでした。
興味深いのは、メンバーそれぞれが独自のスタイルを確立していくことです。丁寧なコードレビューで知られるメンバー、CI/CDの設定に長けたメンバー、ドキュメント整備に情熱を注ぐメンバー——同じGitHubというツールを使いながら、それぞれが異なるアイデンティティを形成していきます。
この変化が可能なのは、チームの文化によるところが大きいと思います。「なぜこんな大きなPRを作ったの？」という問いが、批判ではなく学習の機会として扱われる環境。初心者の「間違った」使い方を見守り、アドバイスする先輩たち。失敗を恥じることなく、むしろ成長の糧として共有する雰囲気があったからだと考えます。
コミット履歴も「作品」である
ここで気づいたのは、GitHubのコミット履歴やPRの記録が、単なる作業ログではなく、チームの成長の軌跡として機能していることでした。通常、私たちは「作品」というと完成したコードや動くアプリケーションを思い浮かべます。しかし、試行錯誤の跡が残るコミット履歴、議論が交わされたPRのコメント、リファクタリングの変遷——これらもまた、チームが共に見て、語り、学ぶための「作品」なのです。
新しいメンバーがチームに加わったとき、過去のPRを見ることで、チームがどのような議論を重ね、どのような判断基準で意思決定をしてきたかを学ぶことができます。「なぜこの設計を選んだのか」「このコンフリクトをどう解決したのか」——すべてが可視化され、後から振り返ることができる。
本来ならファシリテーターが議論のポイントを整理し、学習の機会を設定する必要があったところを、GitHubがその役割を代替している。PRという仕組みが自然と対話を生み、コードレビューという文化が学び合いの場を作り出しているのです。
失敗が許されない空間の息苦しさ
しかし、プロダクトがあれば自動的に学習が起きるわけではありません。
例えばパブリックなSNSでは、技術的には誰でも自由に投稿できる設計ですが、実際には「失敗」が許されない空間になっています。間違った情報を投稿すれば批判され、不用意な発言はスクリーンショットとして永遠に残される。プロダクトの設計自体は中立的でも、そこに集う人々の視線が「失敗を許さない場」を作り出しているのです。
GitHubでも同様のことが起こり得ます。オープンソースプロジェクトで初心者が投稿したPRに対して、建設的でない批判が集中することがあります。同じGitHubというプロダクトでも、それを「初心者を排除する場」として使うのか、「共に成長する場」として使うのかで、全く異なる結果を生みます。
私は趣味でジャグリングをするのですが、練習ではボールを落とすことは日常茶飯事です。むしろ、失敗なくして上達はありません。新しい技に挑戦して失敗し、その失敗から学び、少しずつ上達していく。初心者は堂々と失敗し、経験者はその失敗を見てアドバイスをする。もし、観客のいるステージの上でしか練習できなかったら、上達しないだけでなく嫌になって辞めてしまうかもしれません。
さらに上達するにつれて、それぞれが独自のスタイルや得意技を持つようになります。同じジャグリングでも、その人なりの「こだわり」が生まれるのです。これは、失敗が許容される環境だからこそ、自由な探究が可能になった結果だと思います。
学習を起こすプロダクトと場の条件
これらの観察から、学習を起こすにはプロダクトの設計、場の文化、そして使い手の姿勢の3つが揃う必要があると考えています。
プロダクトの設計条件
失敗可能な余地の設計 プロダクトの使い方に「正解」だけでなく、試行錯誤の余地があること。GitHubでブランチ戦略を模索したり、PRの粒度を調整したりする中で、チームに最適な使い方を見つけていく。
熟達への道筋 使い始めと熟練後で、できることの幅が広がる設計。基本的なgit操作から、高度なワークフローの構築まで、使い手の成長に応じて新しい価値を提供できる。
試行錯誤の蓄積 コミット履歴、PRの議論、イシューのやり取り——成功だけでなく、すべての試行錯誤を記録し、後から振り返れるようにすること。
場と文化の条件
心理的安全性の確保 「なぜこんな大きなPRを？」という問いが、批判ではなく学習の機会として扱われる文化。失敗を恥とせず、成長の糧として共有できる雰囲気。
適切なスコープ プライベートリポジトリはチーム内で、社内OSSは会社内で機能します。文脈を共有し、同じ目標に向かう人々の範囲で活動すること。
対話の習慣 コードレビューやチーム振り返りの機会。「こんな使い方を発見した」「この失敗から学んだ」という対話が自然に生まれる場。
使い手の条件
実験的な姿勢 「とりあえず試してみる」という態度。完璧なコミットメッセージを求めすぎず、まずはpushしてフィードバックをもらう。
共有への意欲 自分の試行錯誤を独り占めせず、チームの資産として共有する姿勢。ベテランは初心者のPRを丁寧にレビューし、初心者は質問を恐れない。
個性の発揮 チームの慣習に従うだけでなく、自分なりのワークフローやツールの使い方を追求する意欲。
失敗を資産に変える
プロダクト開発において、私たちはつい「ユーザーの成功体験」ばかりを設計しがちです。しかし、本当の学習は失敗から生まれます。初心者の拙いコミットも、議論を呼んだPRも、すべてがチームの貴重な学習資産となるはずです。
そのため、プロダクトを設計する際には以下の3点について検討することが重要だと言えそうです。
- 使い手がどのように「失敗」できるか、その失敗をどう安全に体験できるか
- どんな試行錯誤のログを蓄積し、対話のきっかけとなる「作品」にできるか
- 習熟を通じて、使い手にどんなアイデンティティの変容をもたらせるか
一方で、プロダクトがファシリテーターになれるとはいえ、場を作るのはあくまで人の役割です。心理的安全性を確保し、適切なスコープを設定し、対話と振り返りの文化を醸成する——これらがなければ、どんなに優れたプロダクトも学習を促すツールにはなりません。
最初の問い「プロダクト自体がファシリテーションしていると言うことができるのでしょうか」に対して、記事を書きながら考えた結論は、プロダクトがファシリテーターというよりは、プロダクトが人や組織のファシリテーションを支えることができる、ということです。人や組織の成長に伴走できるプロダクトが、私の考える良いプロダクトなのかもしれません。