御利益宗教の危険性と標準化の落とし穴
ソフトウェア開発の特定技術への偏重について「宗教」に例えられる時があります。大抵は理論的裏付けがないとか、実証されていない、あるいは、別の技術との違いが明確でない、といった意味で使われるのだと思います。
御利益宗教の危険性
信仰なのですからそれぞれの自由でも良いかもしれません。しかし、宗教にも現世利益を求める宗教と人の成長に繋がる宗教があって、現世利益を求める宗教が国や組織の標準となると、宗教改革前のカトリックのような組織的な腐敗の危険性があります。
現世利益を求めるものはご利益宗教(ごりやくしゅうきょう)と呼ばれますが、政治的に利用されたり、 免償符 (俗にいう免罪符)やツボを売られるなど、利益に繋がる形骸化した行為のみが重視され、人間的な成長はありません。一方、倫理的な宗教は、極楽浄土や天国に行けるような心清らかな生き方をする様に促すもので、(その考え方が倫理的であれば)人を成長させます。
技術の導入はプロジェクトの成功という即物的な利益を求めるものですから、技術がきちんと実証・説明されないまま標準化されて、その行為のみ求められてしまうと御利益宗教になりがちです。
標準化の長所と短所
そもそも標準化による長所と短所を考えると
【長所】
- 全体の技術的な底上げができる
- 良いプロセスを知る事ができる
- プロジェクトごとの差分を考えれば良いので効率化できる
【短所】
- 標準の善し悪しを考えなくなってしまう(思考停止)
- 標準がゴールになって形骸化しやすい
- 標準以外のやり方に制約が付く
さらに思考停止によって以下のような問題が生じます
- 作業が必要な理由を考えない
- より良い方法を考えない
- 標準の問題を見過ごして改善されない
つまり、技術者は習熟するものの成熟しません。成長せずに硬直化してしまいます。お百度参りは、それで願いが叶うからするのではなく、それだけお参りすればあきらめがつくからとも言われています。標準が宗教化すると理由を考えずに妄信して実施するので、ある程度の失敗であればあきらめが付くのかもしれません。
どうすべきか
そもそも技術なのですから、論理的に説明するとともに、結果を定量的に実証すべきです。しかし、ソフトウェア開発は全く同じプロジェクトで比較実証できません。そこで、ある程度の実績を蓄えて統計処理したいところですが、それには時間が必要です。
そこで必要なのは論理的な説明によって宗教化を防ぐとともに、技術の背景にある価値観を理解することだと思います。宗教化を恐れずに標準化するのなら、すくなくとも技術者としてのあり方を教えて、倫理的な宗教にすべきだと思います。
たとえば、「信頼性の向上」「顧客への価値の提供」「開発者の能力を最大限に発揮する」「ムダをなくす」などの重要な価値観の理解が大切です。それらを理解した上で、実践を通じて社会貢献できれば、技術者の良心や誇りなど、道をあやまらない心得を持てるでしょう。
価値観を理解できるようなトレーニングを
かつて「信頼性の向上が生産性の向上につながる」と言われていました。これは、信頼性の問題によって保守工数が増加するからで、その後、多くの実証が行われました。
近年、信頼性以外の品質特性も重要視されるようになり、
- どのように顧客に価値を提供するか
- 開発者の能力を最大限に発揮させより良い開発をする
- 開発のムダをなくして効率化する
という事も重視されてきています。これらはビジネスの成功という形で、ある程度は証明されていますが、定量的にはなかなか実証の困難な事です(大切な事は理解していただけるでしょう)。
そのイメージは実践しないとわかりにくいものです。CMMブームの際も改善活動を組織で実践するには、理解を深めるワークショップが有効だと言われていました。価値観を身につけるには知識だけではなく、トレーニングや意見交換などの学びの場が必要でしょう。
ビジネスの失敗は組織を消滅させる危険もあり、時には組織的な強制も必要になるでしょう。しかし、それは短期的には効果があるものの、長期的には標準の形骸化をもたらし、使えない開発者を生み出します。長期的な組織の成長には、 技術者の成長が欠かせないと思います。
おわりに
人のする事には、永遠に成り立つ完全な正義というものは、まず存在しないでしょう。ソフトウェア開発の途中で暴れだす狼男に対する銀の弾丸が存在しても、フランケンシュタインやドラキュラに効くかどうかはわかりません。技術には適用範囲があり、正しく利用しないと失敗します。
しかし、現実には良さそうな技術が生まれた時は、適用範囲は明らかではありません。それぞれが工夫して利用するしかないのです。その際に重要なのは、なぜその技術が必要なのか「価値観」を理解する事です。
宗教化しやすいものは、エディターなどのアプリケーションやプロセスなどの実践的な技術です。これらは複合的な技術なので、定量的な実証がすぐには追いつきにくい分野です。技術として発展・普及させるには、開発現場の情報公開と開発者の交流がとても大切だと思います。
« SEA関西「ぐるぐるDDD/Scrum」 - モデルは実装のうずまきで洗練される - | トップページ | アジャイル開発の理解に必要な3つの視点 »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
« SEA関西「ぐるぐるDDD/Scrum」 - モデルは実装のうずまきで洗練される - | トップページ | アジャイル開発の理解に必要な3つの視点 »
コメント