チームコミュニケーションの課題はBurning Needsなのか？
インタビューを繰り返して見えてきたのは、「プロダクト開発に関する課題のほとんどが、チームコミュニケーションにあるのではないか」ということだった。例えば、以下のようなものに思い当たる節はないだろうか。
- 要求・要件の認識のズレによる手戻りや不具合の多発
- 成果物への期待値の認識のズレによるチームの不和
- 情報やナレッジの分散・属人化、頻繁な人材流動によるナレッジの散逸
- プロジェクトマネジメントの機能不全、あるいはプロジェクトマネージャーの業務過多
- コンウェイの法則に引きずられたアーキテクチャと、縦割りのコミュニケーションによる弊害
- ビジネスサイドと開発サイドの対立、古参と新人の対立
……など。
とはいえ、「これがBurning Needsであるとは言い切れない」と考えた田中氏は、さらに掘り下げて聞いてみることにした。すると、「『Notion』を使って解決しようとしている」と答えた人が多くいたのだ。
プロジェクト管理やナレッジマネジメントツールは他にも数多く存在するが、なぜNotionなのか。その理由について田中氏は、「Notionは『All-in-one workspace』をうたっており、分散した情報を集約してコミュニケーションの問題を解決できるからだろう」と分析した。
一方で、Notionの活用がうまくいっていない組織も少なくない。その理由として、「ストック／フロー情報の分類が難しい」「ナレッジを集約するための設計が難しい」「目先の業務に追われて、優先順位が上がらない」といったものが挙げられる。要するに、コミュニケーションを改善するためのコミュニケーションにコストがかかっており、“服を買いに行く服がない”状態に陥っていると考えられる。
Slackの会話をナレッジにするにはコストがかかるのは容易に想像が付くだろう。フロー情報（メールやチャットのように一時的なやりとりの情報）とストック情報（ドキュメントのように後から参照しやすいように整理された情報）は性質に大きな違いがあり、フロー情報をストック情報に移行するには大きなコストがかかる。またストック情報とフロー情報の両方の性質を持った中間的な情報（GitHubやチケット管理ツールに集まる個々のタスク情報・議事録やインタビューの書き起こし・意思決定の歴史的背景や目的・思いなど）のボリュームが大きく、処理の仕方に頭を悩ませることになる。
「これらの課題を解決するのは、人間には難しい。それならば技術の力で解決すれば、売れるプロダクトになるのではないか」と考えているという田中氏は、今後も継続してインタビューを行うとともに、生成AIを使った技術検証を進めている最中だ。
「インタビュイーやパイロットユーザーを絶賛募集しているので、興味のある方は、ぜひお声がけいただきたい」と語り、田中氏はセッションを締めくくった。なお、本稿の読者に対しても問い合わせページから応募を受け付けているという。
