問題には2種類あることに気づいた。
育ってから対処する問題
1つは、実際に何か困っていることがあって、解決したい課題があるという問題。そしてそれはあるひとにとって関心が高く、かつ他のひとからもある程度理解できるような問題。
たいていの問題はこれに分類される。これは時間をかければかけるほど、勝手に問題の問題度があがってくるので、それがあがった適当なタイミングで対処すれば良い。
明らかに困っているので、やる理由も明確だし、困っている度合いによって優先度も勝手につくので楽だ。見積もりをする必要もない。
こちらを仮に育ってから対処する問題と呼ぼう。別に育って「困って」も取り返しのつかないというほどでもないので、ちょっとは大変な思いはするだろうが、適切なタイミングで摘み取れば良いのでシンプルだ。
育つ前に対処したいかもしれない問題
もう1つは、現在は実際に困っているわけではないし、それが本当に問題かどうかは確証は得られないが、いつか大きな問題になるかもしれない種類のものだ。
こちらを育つ前に対処したいかもしれない問題と呼ぼう。
なぜ育つ前に対処したいかというと、もしそれが訪れたときのダメージが非常に大きいからである。
People Management の範囲でいえば、メンバーのモチベーションの低下、精神疾患を引き起こす、コミュニケーションが困難になる、チーム内外の関係性が悪化し修復困難になる、ハードワークにより身体を壊す、など。
あるいはこれはソフトウェアアーキテクチャにも言えるかもしれない。アクセスが10倍になったときに現在のボトルネックが限界に達するとカスケード障害を起こす可能性の高いアーキテクチャ。メンバーが3人から10人になったときに保守が困難なコードベース。複雑度があがりすぎてトレーシングができずに本番障害で検知からの復旧に時間がかかってしまうかもしれないマイクロサービスたち。
みんな見えてる世界が違う
このような問題がなぜ難しいかの前に、全員が見えてる世界が違うという前提の話をしたい。
当たり前だが、全員見えてる世界が違う。興味も違う。業務内容も違うかもしれない。バックグラウンドも違う。そういった多様なメンバーの中では、ある問題を問題と思うかどうか、あるいはその問題度、深刻度の見え方も全然違う。
そのため、あるメンバーがこういった将来的には深刻な問題を引き起こすかもしれない（引き起こさないかもしれない）問題の芽に気づいても、それを組織でやっていくことを推し進めることは非常に難しい。だって他のひとにとってはおそらくそれは問題として認識されていないから。
例えば Lead や Management はチームのことをみているので、そのひとしか見えない問題もあるし、専門性をもって特定の分野に長けているメンバーはその分野に関する問題度も高いだろう。
後者の問題にどう向き合うか
この後者の問題に対してどう対処すればいいのか、今自分の中で正解が見つけられていない。
いずれにせよ、起きるかもしれない、起きないかもしれない、そもそも問題かどうかもわからない問題は、たいてい難しく、範囲が広いものだ。自分1人でやりきるのはきっと難しい。
現実的には、Retrospective といった機会を通して、各メンバーが問題と思っていることを共有して、そのうち優先度の高いもの、（今回でいう前者の問題）に対処しつつも、少しずつ視界に共有されているものを増やすしかない。
そしてその問題に思っているひとは、少しずつでもその問題を言葉にする必要がある。アカウンタビリティは必要。
やりますか、となるためには、アカウンタビリティを果たすことと、周囲になるべく近い立場でその問題を見てもらうその両方が必要である。
他者をコントロールすることは基本的にできないので、"時"を待ちながら、状況を見ながら、言葉を尽くしながら、対話によって視界を共有していくという地道なことをしないといけない。
僕は前者の問題はもちろんのこと、後者のタイプの問題もちゃんと取り組めるようなチームでありたい。
と、こうやって問題を問題として言葉にできた時点で、半分解決したようなものかもしれない。わからない。
でも、この2種類の問題があるということ、そしてそれはみんな見えてる世界が違うという前提に立つと難しいのは当たり前であること、そしてそれに対する打ち手は地道な言語化と忍耐が必要だということがわかったのでよかった。
