属人性は何を犠牲にした上に成り立っているのか

ソフトウェア開発はチームでの開発と同義かと思います。

しかしながら、状況によっては個々人で独立して動いたほうが効果的なときもあるでしょう。

そんな「属人性」が強くなる開発はどういったものを犠牲にして成り立っているのかを考えてみたくこの記事を書いてみました。

属人化することによって得られるメリット

まずは属人化することによる良さを考えてみたいと思います。

属人化している状態というのは、ひとつないしは特定のタスク/領域を自分ひとりで集中して作業していることになると思います。自分が持っているタスクや領域のことだけにフォーカスして把握や実装ができたり、他の物事に対して注意を払わず作業することができます。時間的な効用としては高い状態になるのかもしれません。

上の内容と似ているところですが、外部と関わる機会を最小にできるため、コミュニケーションコストや調整するコストなどを限りなく少なくすることができます。

さて本題に入っていきましょう。

属人化が進むと、個人が独立して作業する傾向が強まります。これにより、チームメンバー間の交流が減少し、知識や経験の共有機会が失われてしまいます。結果として、チーム全体の成長が妨げられる可能性があります。

新しいアイデアや効果的な手法が個人レベルにとどまり、チーム全体に波及しないケースも少なくありません。これは、組織としての学習機会を逃すことにつながります。

属人化が進んだ環境では、キーパーソンの突然の不在がプロジェクトに大きな影響を与える可能性があります。病気や退職などの予期せぬ事態が発生した場合、プロジェクトの進行が著しく遅れたり、最悪の場合、停止してしまうリスクがあります。

また、新しいメンバーへの引き継ぎも困難になり、プロジェクトの継続性が脅かされる事態も想定されます。

属人化が進むと、個人の独自のコーディングスタイルや方法論が強く反映されがちです。これにより、以下のような問題が生じる可能性があります

結果として、コードの品質や保守性が低下し、長期的なプロジェクト管理に支障をきたす可能性があります。

属人化が進むと、「従来のやり方」に固執する傾向が強まります。これは一見、効率的に見えるかもしれませんが、新しいアイデアや手法の導入を妨げる要因となります。

チーム全体の多様な視点や経験を活かすことができず、潜在的なイノベーションの機会を逃してしまう可能性があります。

属人化が進んだ環境では、特定の個人に業務が集中しがちです。これにより、以下のような問題が生じる可能性があります：

結果として、チーム全体の働き方の柔軟性が失われ、個々のメンバーの満足度や生産性に悪影響を及ぼす可能性があります。

属人化には確かに短期的なメリットも存在します。しかし、長期的な視点で見ると、チームの成長、プロジェクトの安定性、コードの品質、イノベーションの創出、そして働き方の柔軟性など、多くの重要な要素を犠牲にしていることがわかります。

短期的な集中と選択をした上で「その集中したものを分散」することまでセットでやることで真の意味で属人化して進めることの価値があるのではないでしょうか？

知識の共有、適切なドキュメンテーション、コードレビューの実施、ペアプログラミングの導入など、様々な施策を通じて属人化を緩和することで、より強固で持続可能な開発体制を構築することができるでしょう。