Folklore in Software Engineering: A Definition and Conceptual Foundations
本論文は、文献レビューと12名のスウェーデンの実務家へのインタビューを統合することにより、ソフトウェアエンジニアリングのフォークロアを定義および特性化し、非公式な物語、神話、およびヒューリスティックが、開発コミュニティ内における専門的なアイデンティティ、価値観、および集合知をどのように形成しているかを理解するための概念的枠組みを構築するものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
ソフトウェア開発チームを、単にコードを書く人々の集まりとしてではなく、デジタルな村に住む現代の部族として想像してみてください。古代の部族が、なぜ雷が鳴るのかについての物語や、豊作を祈る儀式、そして長老にしか分からないジョークを持っていたように、ソフトウェアエンジニアにも独自の文化的遺産が存在します。
「ソフトウェア工学におけるフォークロア（伝承）」と題されたこの論文は、ソフトウェアチームには「フォークロア」、すなわち、公式のマニュアルを通じてではなく、廊下での立ち話、コーヒーブレイク、オンボーディング・セッションを通じて受け継がれる物語、神話、内輪のジョーク、そして暗黙のルールが満載であると論じています。
以下は、著者たちの発見を簡単な比喩を用いて解説したものです。
1. 「ソフトウェア・フォークロア」とは何か？
フォークロアを、チームの**「明文化されていないルールブック」**と考えてください。
- 公式マニュアルは、政府の法律のようなものです。明確で、書き記されており、正確に従うことが想定されています。
- フォークロアは、「村の噂話」や「家族の伝説」のようなものです。それは、たとえ公式のルールと矛盾していても、人々が実際に信じ、実践している事柄です。
著者らは、これを**「非公式に伝達される物語やショートカット（ヒューリスティック）」**と定義しており、それらが開発者の自己認識、価値観、そして協力体制を形作っているとしています。それは、その職業における「伝承（ロア）」なのです。
2. ソフトウェア・フォークロアの3つの主要成分
研究者たちは、経験豊富なスウェーデンのソフトウェア専門家12名への調査に基づき、このフォークロアを以下の3つのカテゴリーに分類しました。
A. 神話と伝説（「作り話」）
これらは、確かなデータによる裏付けがなくても、誰もが真実だと信じている物語です。
- 「10倍の開発者（10x Developer）」の伝説： 一人の超天才プログラマーは、平均的な開発者10人分に相当するという根強い信念があります。論文では、これはプロジェクトの成否を説明するために使われる神話であることが多いものの、証明されることは稀であると指摘しています。
- 「バグのない」約束： 特定のプロセス（チェックリストなど）を完璧に守れば、ソフトウェアに魔法のようにバグが出なくなるという共通の信念です。実際にはバグは発生しますが、マネージャーにコントロール感を与えるために、この物語は存続します。
- 「新しいものはより良い」という熱狂： 最も新しいテクノロジーやフレームワークは、それが特定の課題に適しているかどうかに関わらず、単に「新しい」という理由だけで自動的に優れているという考えです。
B. 儀式と慣習（「セレモニー」）
これらは、単に「仕事を進める」以上の深い意味を持つ繰り返しの行動です。
- デイリースタンドアップ： 公式には、同期を図るための15分間のミーティングです。しかしフォークロアの観点では、それは「私は仕事をしています」と上司に見せるためのパフォーマンスになったり、チームを結束させるための社会的接着剤になったりすることがあります。
- 「トールゲート（関門）」： プロジェクトが次のフェーズに進む前にレビューを行う会議です。一部のチームでは、これを「物事がうまくいく」ための魔法の儀式のように扱い、それ以前の作業がどれほど雑であったとしても、この会議を経てソフトウェアが突然機能し始めるかのように扱います。
- スプリントにデザートの名前をつける： 一部のチームは、作業サイクルにクッキーやケーキの名前を付けます。目標を達成すれば、ご褒美が得られます。これにより、ストレスフルな締め切りが共有のゲームへと変わります。
C. アーティファクトとユーモア（「内輪のジョーク」）
これには、文化的な意味を持つミーム、ジョーク、物理的な物体が含まれます。
- ミーム： 論文では、「This is Fine」（燃え盛る部屋の中に座っている犬）のようなミームに触れています。これは、開発者が混沌とした状況にありながら、すべてが大丈夫であるふりをしていることを表現するために使用されます。
- 「散らかったデスク」： 散らかったデスクは、開発者が深い思考に没頭している証としての勲章である、という信念があります。
- 負担としてのテスト： テストは「エキサイティングな」コーディング作業に比べて、退屈で単調な雑務であるという共通のジョークです。このジョークは、テスターは開発者よりも重要度が低いという考えを強化します。
3. このフォークロアはどのように広まるのか？
論文では、この知識は教科書を通じて伝わるのではないと説明しています。それはウイルスやキャンプファイアの物語のように広がります。
- オンボーディング： 新しい人が加入するとき、彼らは単にマニュアルを読むのではありません。ベテランから「戦記（ウォー・ストーリー）」を聞くのです。
- ウォータークーラー（給湯器付近）： 物語は、コーヒー室、昼食休憩、チャットチャンネルで交換されます。
- メンターシップ： シニア開発者は、単に質問に答えるだけでなく、「20年前にそれを試したが失敗した」といった具合に、正確な理由を説明せずに後輩に教えます。
4. なぜこれが重要なのか？
著者らは、このフォークロアを無視するのではなく、研究すべきであると主張しています。
- メリット（良き側面）： フォークロアは便利なショートカットになり得ます。それは、新しい人がマニュアルを読むよりも早く、特定の会社における「本当の」やり方を学ぶ助けとなります。また、チームのアイデンティティを構築し、ユーモアを通じてストレスに対処することを可能にします。
- デメリット（悪しき側面）： フォークロアは危険を伴うこともあります。もし全員が「テストは時間の無駄だ」といった神話を信じてしまえば、製品を損なうような誤った判断を下す可能性があります。また、「一度試したがうまくいかなかった」という理由で（たとえ状況が異なっていたとしても）、チームが新しい、より優れた手法を試すことを妨げることもあります。
結論
論文は、**「ソフトウェア工学のフォークロア」とは、ソフトウェアチームがどのように運営されているかを定義する、「非公式に共有される物語、信念、および儀式の集合体」**であると結論付けています。
歴史学者が文化を理解するために神話を研究するのと同様に、ソフトウェアの研究者やマネージャーは、なぜチームがそのような決定を下すのかを理解するために、これらの「ソフトウェアの神話」を研究すべきです。これらの目に見えない物語を可視化することで、チームは（士気を高めるための良い内輪ネタのような）有益な伝統を維持しながら、（一部の人間は自然に10倍優れているという考えのような）有害な神話に異を唱えることができるのです。
要約すると： ソフトウェアは単なる論理とコードだけではありません。それは、私たちがコードについて自分自身に語る物語でもあるのです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。