個々のエンジニア、チーム、組織のどれを優先するか

アジャイル界隈のカンファレンスのテーマの変遷を思い出すと興味深い。誤解やツッコミをしたくなるだろうが乱暴に書けば、開発方法論（vsウォーターフォール）→実践（ビジネスで使え）→チーム→組織→プロダクト（事業＋開発）と変遷していると（浅い理解であるのだろうが）感じている。

開発方法論は2013年くらいまでで、2013年あたりから実践せよと境目が変わってきた。そこから5年程度で普通になった。普通とは、自社のソリューションビジネスや製品開発をしているSIerにとっては日常と言う意味で、である。エンジニアのリソースを売る人売りSIerとは一線を画す。

ここ最近、チームビルディングやプロダクト開発における組織の在り方の講演テーマやスライドをみると、関心が変遷する中で人的リソースの括り、つまり、エンジニア個人、チーム、組織と活動単位で捉えたときに、それぞれの課題と解決がコンフリクトを起こし、どうしたら良いかという投げかけを見かけるようになった。

具体的には心理的安全性をチームの中で確保しようとするとき、活動単位はチーム内での事象に対する課題設定と解決になる。そこで議論されるのはチーム優先である。とこで心理的安全性は見方、視点を変えれば個人のパフォーマンスを最大限に発揮することが根底にあると考えている。それをチームベースで話しすぎると個人のパフォーマンスはスポイルされる懸念があると考えている。

なお、このエンジニア個人とチームのコンフリクトに対する投げかけ、気づきはまだとても少ない。

自分の捉え方はまだこれだと整理できているとは思わない。エンジニア個人、チーム、組織という活動単位を分けることは活動単位での課題を取り扱う上では便利であるからどうぞご自由に程度であるがそうして分けたときにコンフリクトを起こして困る的な感じで言われると、その分けて考えられていること自体に疑問を保たれれば良いのではないかと思ってしまうのである。

活動単位は、エンジニア個人、チーム、組織である。その組織も事業というビジネスの上に構築されるロールである。ロールはミッションを分掌する。結局、組織がビジネスで生き残るためにどうすればいいかの話であるから、困ったときにはビジネス、事業で捉えなおせば良いのだと思っている。

エンジニア個人とチームがコンフリクトするとき、どちらを優先しなければならないかと迷ったらビジネスとして成果を得られる方を選べば良いのである。その判断にバイアスを掛けるのがコーポレートとしての行動規範や価値観を意思決定すれば良いのである。

エンジニア個人のパフォーマンスとチーム内での心理的安全性とを折り合いをつけたければ、組織としての意思決定で優先される価値観を適用することで結果は得られる。そこでエンジニア個人にパフォーマンスの制御を要求することになったとしてもそれは組織の共通した価値観に基づくものであるから組織として、ビジネス上の判断として方向性は一致しているのである。

端的に言えば、組織文化で判断すれば良いのである。