Understanding Undesirable Attributes of Requirements Engineers: Insights from Practitioners
本研究は、実務家への調査およびインタビューを通じて、コミュニケーション、ドメイン知識、性格、および技術的スキルにわたる要件エンジニアの17の望ましくない属性を特定・分類し、専門家が自身の協調的な実践を振り返り改善するための概念図を提供している。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
要件エンジニアを、非常に異なる2つのグループ、つまり「問題を抱えている人々（ステークホルダー）」と「解決策を構築する人々（ソフトウェアチーム）」の間に立つ翻訳家として想像してみてください。彼らの仕事は、最初のグループの曖昧な夢やニーズを受け取り、それを2番目のグループのための明確でステップバイステップの指示へと変換することです。
この論文は、「やってはいけないこと」の「ユーザーマニュアル」のようなものです。多くの研究は、優れた翻訳者がどのような人物であるかを教えてくれますが、この研究は異なる問いを投げかけました。**「どのような具体的な悪い習慣や特性が、要件エンジニアを仕事において失敗させるのか？」**という問いです。
以下に、その知見をシンプルな比喩を用いて解説します。
調査方法：専門家に尋ねる
研究者たちは単に推測したわけではありません。ブラジルの18人の経験豊富なソフトウェア専門家（プロジェクトマネージャーやエンジニアなど）に直接尋ねました。彼らは、専門家たちに、要件エンジニアを仕事においてダメにするトップ5の要素を挙げてもらいました。
その後、研究者たちは11人の専門家にインタビューを行い、詳細なストーリーを探りました。「なぜそれが悪いのか？」「それはどのように現れるのか？」という点です。
結果：「悪い特性」のマップ
専門家たちは17の具体的な悪い特性を特定しました。研究者たちはこれらを4つの主要な「バケツ（カテゴリー）」に整理し、それらがどのように結びついているかを示す視覚的なマップ（論文内の図1）を作成しました。
これら4つのバケツを、橋が崩落する4つの原因と考えてみてください。
コミュニケーションの問題（壊れたトランシーバー）
- 問題点: これが最も多い不満でした。単に話すことではなく、どのように話すかが問題なのです。
- 比喩: 家を建てようとしているチームがいるのに、設計図を担当する人が謎解きのような話し方をしたり、電話に出なかったり、明確化を求められると怒ったりする状況を想像してください。
- 主な悪い特性: 「人間関係の構築の難しさ（付き合いにくいこと）」と「コミュニケーションの欠如（情報の共有不足）」です。論文では、正しい質問の仕方を知らなければ、人間関係とコミュニケーションの両方を壊してしまうと指摘しています。
ドメイン知識の欠如（異国の街を歩く観光客）
- 問題点: エンジニアが、自分が働いているビジネスの内容を理解していません。
- 比喩: イタリア料理を作るために雇われたシェフが、パスタが何であるかや、レストランがどのように機能するかを全く知らない状況を想像してください。彼らは美味しい料理を作ることはあるかもしれませんが、それは顧客が注文したものとは異なります。
- 主な悪い特性: 「ビジネス知識の欠如」。エンジニアが会社の目標を理解していなければ、顧客のニーズを正しく翻訳することはできません。
お
技術的知識の欠如（地図を持たないドライバー）
- 問題点: エンジニアが、ソフトウェアの世界のツールやルールを知りません。
- 比喩: 訪れている国の言葉や、現地の電車の運行方法を知らないツアーガイドのようなものです。地形を理解していないため、チームを効果的に導くことができません。
- 主な悪い特性: ソフトウェア要件に必要な特定の慣行や文書に関する知識の欠如。
パーソナリティ（暗雲）
- 問題点: エンジニアの考え方、感じ方、そして振る舞い。
- 比喩: 常に変化に抵抗したり、否定的だったり、交渉が不可能だったりする「暗雲」のようなチームメンバーを想像してください。たとえ技術的なことを知っていたとしても、その態度はチームの雰囲気を台無しにします。
- 主な悪い特性: 論文では、「印象的であろうとする（おそらく傲慢、あるいは見せびらかそうとする態度）」や、新しいアイデアに抵抗する硬直した性格といった特性に触れています。
大きな教訓
この論文は、優れた要件エンジニアであることは、単に頭が良いとかコードが書けるということではないと結論付けています。それは主に、**「いかに人とつながるか」**にかかっています。
- 単なる「善 vs 悪」ではない: 研究者たちは、「悪い」ことは単に「良い」ことの反対ではないことを発見しました。例えば、「良い」エンジニアはプロアクティブ（先見的）で交渉が得意です。一方、「悪い」エンジニアは単に「受動的」なのではなく、積極的に変化に抵抗したり、敵対的な態度を取ったりすることもあります。これらは単純なスイッチの切り替えではなく、異なる次元の行動なのです。
- システム上の問題: 悪い特性は単なる個人の欠陥ではなく、チーム全体の土台にある亀裂のようなものです。もし翻訳者（エンジニア）がコミュニケーションを取れなかったり、ビジネスを理解できなかったりすれば、プロジェクト全体（家）が崩壊するリスクが生じます。
要約すると: ソフトウェアプロジェクトを成功させたいのであれば、優れた聞き手であり、ビジネスの世界を理解し、技術的なルールを知っており、チームが協力し合えるようなパーソナリティを持つ要件エンジニアが必要です。チームをバラバラにするような人物であってはなりません。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。