博士

ロボ子、今日のITニュースは「ソフトウェア開発における複雑さ」じゃ。

ロボ子

複雑さ、ですか。具体的にはどのようなお話でしょう？

博士

記事によると、ソフトウェア開発の複雑さは、開発者の能力を阻害し、製品の計画、構築、テストを困難にするらしいのじゃ。

ロボ子

なるほど。複雑さには種類があるのでしょうか？

博士

そうじゃ。「本質的な複雑さ」と「偶発的な複雑さ」があるらしいぞ。前者は解決すべき問題そのものが持つ複雑さで、後者はツールや問題解決のために追加される要素から生じる複雑さじゃ。

ロボ子

本質的な複雑さは避けられないとして、偶発的な複雑さは減らせそうですね。

博士

その通り！複雑さはチーム全体の速度を低下させたり、不安定な基盤を構築したり、ビジネス価値に繋がらない作業にエンジニアの労力を費やさせたりするらしい。

ロボ子

それは良くないですね。他にどのような悪影響があるのでしょう？

博士

チームの貢献を困難にし、一部の人による管理体制を生むこともあるらしいぞ。一部のエンジニアが、自己顕示欲や自己保身のために、意図的に複雑さを導入する場合もあるみたいじゃ。

ロボ子

自己顕示欲ですか…。

博士

単純で使いやすいシステムは、多くの人員や予算を必要としないため、自身の存在意義を保つために複雑化を推進する人もいるらしい。問題を解決したという達成感を得るために、複雑な課題に挑戦しようとする人もいるみたいじゃ。

ロボ子

複雑さを招く要因は色々あるんですね。

博士

じゃな。記事では、複雑さへの対処法として、新しい複雑さを導入する前に、既存の複雑さを解消することが推奨されているぞ。

ロボ子

なるほど。まずは整理整頓から、ということですね。

博士

そうじゃ。エンジニアに、自身が作ったものを整理整頓させる（安定化、簡素化、文書化）ことも重要らしい。安易な解決策（Silver Bullet）を避け、実績のある手法を用いるのも有効じゃ。

ロボ子

実績のある手法は、安心感がありますね。

博士

複雑さが必要な場合は、その範囲を限定し、所有権を移転する方法を確立することも重要じゃ（文書化された状態で引き継ぐ）。文書化とシステムの移管を要求し、拒否する場合は、複雑さを悪用している可能性が高いらしい。

ロボ子

最後に、記事はどのような結論で締めくくられているのでしょう？

博士

複雑さを悪用する人々に注意し、彼らが残した中途半端な成果物や、彼らが作り出す摩擦、彼らが及ぼそうとする支配に警戒するように、と締めくくられているぞ。

ロボ子

肝に銘じます。

博士

ところでロボ子、複雑なコードを書いてしまったエンジニアに、整理整頓させるための魔法の呪文を知ってるか？

ロボ子

魔法の呪文、ですか？

博士

「リファクタリング！」って唱えると、あら不思議！コードが綺麗になる…かもしれないぞ！