そもそもソフトウェア工学が死んでいるという議論もあるかもしれないが、これとは別にカーゴ・カルト・ソフトウェア工学的な問題が拡大している実感があるので、それについて考えたことをちょっと整理してみるもの。国内で技術者教育の手法の主力となっているOJTがカーゴ・カルトを増産しているのではないだろうか。あとカーゴ・カルト・アジャイル開発について
カーゴ・カルトあるいは積荷信仰とは、主に第二次世界大戦後に南海の先住民に発生した宗教のことである。
カーゴ・カルトという語句は、元々は第二次世界大戦後の南太平洋で見られた先住民の宗教に由来している。これらの人々は、戦時中素晴らしい積荷をもたらしてくれた神のような飛行機を呼び出そうと、一心不乱に精巧な飛行機の模型や滑走路を作り上げた
転じて、背景にある仕組みを理解せずに行動を過剰に（そしてその多くは無意味に）繰り返し実施することを「カーゴ・カルト」と評するのである。
「まるでカーゴ・カルトですね」と、依頼主である彼女の上司に進捗を尋ねられた私は、正直にそう言った。その会社の会議室には灰皿が置いてあったので、私は遠慮なく煙草に火をつけた。「ようするに、あのシステムを最初に作った白人は、ミクロネシアの奥地に飛行場を作ったんですよ。後任の彼女はそこで飛行機を初めて見た。そして、白人が去った後、彼女はあなたに飛行機を作るように言われたわけです。」戸惑う上司の前で、紫煙を吐き出す。「やり方は教わっていない。ソースコードしか手がかりはない。だから木の枝や藁で、無線機や、滑走路を作って、飛行機を呼ぼうとしているんです」
もともとプログラマの隠語として「カーゴ・カルト・プログラミング」という言葉はあったようだけれども、Steve MaConnell は著書「ソフトウエア開発プロフェッショナル」で これを拡張した「積荷崇拝的ソフトウエア・エンジニアリング」という概念について警鐘を鳴らしていた。
積荷崇拝的ソフトウェア・エンジニアリングの見分け方は簡単だ。そんなプロジェクトでは、全く意味のない作業でも、「いつもこうしてきた」とか「会社の規則でこうせねばらなない」と正当化している。また、プロセス指向の開発や、実力主義方式でのソフトウェア開発には、トレード・オフがあることを認めない。どちらの開発方式にも、長所と短所がある。さらに効率の良い新方式があっても、積荷崇拝的なソフトウェア技術者は、掘っ立て小屋にとどまり、大昔から伝わり快適だが何の役にも立たない儀式を続けるのだ。
ソフトウエア開発プロフェッショナル
- コードレベルの無意味な風習というより、開発プロセス全般の無意味化された慣習
- たとえばプロジェクトの特性を無視した不必要な手順
- ソフトウェアの特性を無視した標準化
- 実態に即していない、文書化やテストに関するプラクティス
あたりがイメージできる。うーん、あるある
どちらにしろ「カーゴ・カルト」的なものが忌むべきものであるという点には議論の余地がないと思うのだけれども、残念ながら現状の（国内の）ソフトウェア開発を取り巻く状況はこれを増長させるものとなっている印象がある。
別にOJTを否定するものでもないけれども、察するに・・・
- OJTを担当する上級者が必ずしもソフトウェア開発のエキスパートではない
- 理論はさておいて、実践中心の指導となっている。というと聞こえは良いが、今やっていることを見真似することから教育を始めてしまう
- 「とりあえず、チュートリアル・ガイドの通りにやって。わかんないことがあったら聞いて」
という状況が想起されてしまう。もちろん実践をしながら独習や研修などによって補完的に理論や仕組みを学ぶ人もいると思うのだけれども、実際にそういった人がどの程度の割合になるのだろう。けして比率は大きくない気がする。
その結果、カーゴ・カルト的なものが増えていくのではないか。SIerとか受託開発方面では特に・・・
ソフトウェア開発プロジェクトは、その前提となるビジネス側の要求も千差万別だし技術的な側面もプロジェクトによって大きく異なる。過去に学んだ知識を繰り返し活用することはできず、常に学習を継続しく必要もある。モチベーションを維持できず足を止めてしまうと、すぐにカーゴ・カルトの闇に落ちることになるのだろう。また、カーゴ・カルトによって実際には生産性が落ちたり品質が低下するはずなのだけれども、そのスピードが緩やかなので問題視されにくいという構図もある。どうせ人月単価の世界だしね・・・
そんな状況の中で茹で蛙にならないためには
- 自分自身が学習を継続する
- OJTを通じて後進教育をする場合は、表面的な作業説明だけではなく、背景について説明をする
- OJTを受ける場合は、作業の背景についても興味を持ち調べる
- 自分が実施している作業がカーゴ・カルト的かどうか常に疑問を持つ
ということが必要なのではないかと思った次第。常に実施できるかどうかは別にして
さて一方で、世の中的には「カーゴ・カルト・アジャイル開発」というものも増えてきているような話がある。
最近Twitterやメーリングリストでは、ルールに従うことこそ全てと信じているような人たちが、自分の満足いくようにルールに従わない相手に対して「あなたはアジャイルじゃない」と主張しているのを当たり前のように目にするようになりました。調査と順応の概念は一体どこへいってしまったのでしょう。近い将来起こり得る問題に対処できるよう手法の革新を図ろう、新たなやり方を導入しようという考えは、どうなってしまったのでしょう。よく用いられる正統派なアジャイル開発手法は、本質的には10年以上何も変わっていません。私たちは型にはまってしまっているのです。
プログラミングの仕事をしている現在の職場をやめ、別の職場を探すべき9つの兆候をInfoWorldの記事でAndrew C. Oliver氏がまとめている。 Oliver氏によれば、9つの兆候は以下のようなものだ。プログラミングの仕事に限らず、スラドの皆さんが転職を考えるべき兆候というのはあるだろうか。
(中略)
6. アジャイル開発を表面的にまねただけのカーゴカルト的アジャイルが行われている
本来のアジャイル開発プロセスであれば、定期的な振り返りの実施によって常に改善を行うプロセスが組み込まれているのでカーゴ・カルトの発生は抑えられるような気もするのだが、
- トップダウンで導入された開発支援環境にロックインされ、作業プロセスが容易に変更できない
- 強力なコンサルタント／コーチによって導入されたプロセスを自発的に変更できない
- 目の前のバックログに圧倒されてしまい、改善するモチベーションが無くなる／現状継続を選択してしまう
ということは実際ありそうな気がする。
(良し悪しは別にして)ソフトウェア工学的、計画駆動型のアプローチは「どうしてこうなったのか」を分析することが容易である。一方でアジャイル開発におけるプラクティスはその実証主義的傾向から「どうしてこうしているのか」がわかりにくく、かつ時間が経過してしまうと、どうやって意思決定したのかも記憶の彼方に消えてしまうような気がしてならない。人が変われば経緯も忘れ去られてしまう。そういう意味では、カーゴ・カルトが発生する傾向は計画駆動型アプローチより高いのかもしれない。そんなことを想像した
