昨日同僚と部内発表会に向けた資料をネタに話をしていました。
内容は何かしらをリファクタリングして、楽になったんだぜという資料。
そのときに話をしていて、暗黙知が
・大変だから、リファクタリングをして、楽にした
ってのはわかるけど、大変ってなんだろうってふと考えたわけです。
どんな状況なのか
置かれている状況は、プロジェクトや組織の数に対して、
担当者は一人しかいないという点です。
プロジェクトの視点からみたら、担当者はどう見えるかというと、
多少の軽いお願いくらいやって当たり前と思っているので、ちょっと不明点があると
〇〇のことやってください。教えてください。プロセス回してください
など自分たちでできないなというものだったり、そっちでやるべきでしょって思うやつは飛んでくるわけです。
担当者の視点で見ると、毎日のほうに同じ質問がきたり、同じプロセスを回したり、同じことをPJの担当者別に話をしたり、ちょっと違う同じことを繰り返しやっています。
なぜ相手は頼むのか
同僚と話をしていて、なぜこんなにもPJ側の人間とコミュニケーションが必要なのか。これはいったい何が影響でこのような事態になっているのかを議論しました。
理由は、Aという機能を構成するコンポーネントにPJ側が責務と思っているパーツが含まれていること。
そのパーツはPJごとにメンテしているが、PJ側で判断ができないので
コミュニケーションという手段を使って、不安を取り除く行為を行うのです
逆に言うと、PJ側が判断しなくてはいけないものを減らせば減らすほど、コミュニケーション減り結果的に担当者は楽になるという話に落ち着きました。
ダメな行動の気づき
私の今のポジションもまったく同じことが起きています。そして、過去の先輩はこれをどう表現したかというと、
忙しい
回らない
大変だ
以外のアクションは起こしていません。
これは自分も含め言語化できていない証拠でした。
そして昨日気づいたこの問題の本質は
コンウェイの法則にもあるのだが、
ソフトウェア構造と組織は非常に相関が存在する。
そして、この問題の本質は
パーツごとに、ころころと変わる組織に対して、
ソフトウェア構造がマッチングしないため、常に不確実性が高い状態が続いている
PJやメンバーの不安をリーダーが様々な人とコミュニケーションを重ね、
相手との信頼関係を気づき、PJにとっての壁を乗り越えることが、
まさにリーダーの仕事だった。と私は考えています。
したがって、忙しい、大変だ、回らないなどどうでもよく、
組織とソフト構造がまったく異なるゆえに、
コミュニケーションによるエンジニアリングが
必要な状態に陥っていると理解できました。
まとめ
自分の仕事がなぜ忙しいか。
それはPJの数分発生するソフトウェア構造と組織構造間の違いによって
発生する不確実性を高い状態から低くするために、
コミュニケーションという手段で解決しているから！
ん
ん
ん
答えは？
ってなるかどうかは、今後周りにも話してみようかなと思います。
だって忘年会も多いしね。
