社内横断組織は、体制の位置付けと専任化で貢献した方が良い

ざっと読みつつ、少し前に受けた相談のことを思い出したのでした。

その相談とは、

「組織の中での推進部門が推進部門として独立している場合の貢献度合いの評価が難しい」

というものでした。もう少しその相談のことを説明すると、全社であるテーマについて推進することになり体制を作る場合、どこに置くのが体制を設けたことに対する組織への貢献になるか、というものです。

具体的には、あるテーマの推進部門をCEOやCTOなどの役員の直下に置くか、事業部門の中に置くのとどちらが良いのか、というものです。

同じじゃないかと思ったエンジニアは残念。実際に両方の位置付けで働いてみると良いですよ。全然違いますから。

話を最初に戻して、引用元のエントリは、
・CTOの不在
・品質問題
・技術広報の不足
の３点が挙げられています。個人的には問題の本質の取り違えとアプローチが適用した組織にフィットしなかったと思うのです。

CTOの不在はCTO不在が問題ではない

これは課題の説明で書かれている認識のとおり、見えている課題はエンジニアのアサインが決まらないというものです。

ではCTOの不在がその問題の本質かといえば、違うと思うのです。

本質は、エンジニアのアサインを決める会議体の開催主旨の曖昧さに全てがあると思います。会議体を仕切りなおす必要があったのです。

対処としては、

・エンジニアのアサインを判断する権限を持つ役員若しくは所轄部門長の出席
・会議目的の明示と意思決定

の２点が改善方法だと思います。極端な言い方をすればCEOが毎回出て意思決定すれば済むのです。

品質問題はレビューで解決しない

品質問題はその事象毎に原因が違うので、品質が悪いからといっていきなりレビューを展開しても効果が得られるか確証はありません。

様々な品質問題があったかもしれませんが、一旦は、次のようにアプローチするのが良いと思います。現実的に解決したければ。

・今、起きている品質問題を集めること
・会社の存続に関わる品質問題かを評価すること
・優先順位の高い品質問題プロジェクトから潰すこと

とてもベージックですが、事業に影響を及ぼさない品質問題を抱えたプロジェクトにリソースを割いている余裕はないはずです。

ソフトウェア開発での品質問題は、組織の文化に根ざしているものが多いのでまずは改めて何に問題があるかを知り、対処方法を確立することが重要です。

実際に解決すれば、それがその組織のプラクティスになるのです。それがたまたま技術レビューかもしれませんがそれは対処できた実績のあるものですから効果が得られる可能性が高いです。

ただ、品質問題は作業プロセスが脆弱で品質問題を産む構造になっていることが多いです。品質問題を起こすべくして起こしているといっても良いです。

横断組織がよかったのか

結論から言えば、CEO直下の組織として配置し、経営上の問題だと認識したプロジェクトに対して権限を持つ組織がよかったのでしょう。

CTO不在の問題の本質は、アサインの意識決定ですからそれをCEOが最終判断すれば良いわけで、CEO直下の会議体に変更することで解決です。いやいや、CEO多忙ですといっているならデレゲートするかアサイン問題は経営に直結しないとCEOが認めていると認識すればいいだけです。

品質問題は、やはり、組織上の配置をやり直し、少数専任のチームで対応した方が良いでしょう。これも事業上の問題であると判断するならです。

このように体制化することで責任範囲が明確になります。冒頭の相談された貢献の可視化もしやすくなります。

まあ、全てにおいて兼務は諸悪を産むのですけれど。