企業は、オフィススペースの変更から、より優れたツールの取得やソースコードのクリーンアップまで、さまざまな方法で開発者の生産性を最大化するのに役立ちます。しかし、どの決定が最大の影響を与えるでしょうか？ソフトウェア開発と産業/組織心理学に関する文献を利用して、生産性に関連する要因を特定し、3社の622人の開発者にインタビューしました。私たちは、言及された要因と、人々自身が自分の生産性をどのように評価するかに興味を持っていました。私たちの調査結果は、自尊心が技術的でない要因によって最も影響を受けることを示唆しています：仕事での熱意、仲間による新しいアイデアのサポート、そしてあなたの生産性に関する有用なフィードバックの取得。他のナレッジワーカーと比較して、ソフトウェア開発者による生産性の評価は、さまざまなタスクとリモートで作業する能力に大きく依存します。

1.はじめに

開発者の生産性を向上させることが重要です。定義上、タスクを完了すると、新しい機能や新しいチェックの導入など、他の便利なタスクに自由な時間を費やすことができます。しかし、開発者の生産性を高めるのに何が役立ちますか？



企業は、生産性を最大化するためにどの要素を操作するかについての実践的なガイダンスを必要としています。たとえば、開発者はより良いツールやアプローチを探すために時間を費やす必要がありますか、それとも日中は通知をオフにする必要がありますか？リーダーは、コードの複雑さを軽減するためにリファクタリングに投資する必要がありますか、それとも開発者により多くの自律性を与える必要がありますか？上司はより良い開発ツールまたはより快適なオフィスに投資する必要がありますか？理想的な世界では、生産性を上げるためにさまざまな要素に投資しますが、時間とお金が限られているため、選択する必要があります。



この記事は、これまでのソフトウェア開発者の生産性予測に関する最も広範な研究に関するものです。セクション3.1で説明したように、生産性は客観的に（たとえば、1か月あたりのコード行数で）または主観的に（開発者自身が推定したように）測定できます。どちらのアプローチも好ましくありませんが、次の3つの質問に答えるために、主観的な判断でトピックを幅広くカバーしようとしました。

1. 開発者が生産性を評価する方法を最もよく予測する要因は何ですか？
2. これらの要因は会社ごとにどのように変化しますか？
3. 特に、他のナレッジワーカーと比較して、開発者による生産性の評価を予測するものは何ですか？

最初の質問に答えるために、私たちは大手ソフトウェア会社で調査を実施しました。



得られた結果をどの程度一般化できるかを理解するのに役立つ2番目の質問に答えるために、異なる業界の2つの企業で調査を実施しました。



開発者と他の専門家との違いを理解するのに役立つ3番目の質問に答えるために、他の職業の代表者を対象に調査を実施し、開発者の調査で得られた結果と比較しました。



私たちの結果は、私たちが調査した企業では、生産性に対する自尊心は、職場での熱意、新しいアイデアに対する仲間のサポート、および生産性に関する有益なフィードバックに強く影響されていることを示しています。他のナレッジワーカーと比較して、ソフトウェア開発者の生産性の評価は、さまざまなタスクとリモートで作業する能力に大きく依存しています。企業は、調査結果を使用して、生産性関連のイニシアチブに優先順位を付けることができます（セクション4.7）。



セクション2では、調査した企業について説明します。セクション3では、調査方法について説明します。セクション4では、得られた結果について説明および分析します。セクション5では、このトピックに関する他の作業について説明します。

2.調査した企業

2.1。グーグル

Googleには、世界中に約40の開発オフィスがあり、数万人の開発者を雇用しています。会社はチーム内の緊密なコラボレーションを重視しており、オフィスは通常、チームメンバーを近づけるためのオープンプランです。同社は比較的若く（1990年代後半に設立された）、組織構造はかなりフラットであり、開発者は多くの自律性を持っています。昇進プロセスには同僚からのフィードバックが含まれ、開発者は前進するために管理職に移行する必要はありません。開発者は自分で時間を計画し、カレンダーは企業ネットワークに表示されます。 Googleは、通常チーム全体に適用されるアジャイル開発プロセス（Agileなど）を使用します。



Googleはオープン性を重視しています。ほとんどの開発者は、共通のモノリシックコードベースで作業しており、他の人のプロジェクトのコードに変更を加えることをお勧めします。同社には、テストとコードレビューの強い文化があります。リポジトリに送信されたコードは、通常はテストを使用して、別の開発者によってレビューされます。ほとんどの場合、頻繁にリリースされ、修正を比較的簡単に展開できるサーバー側のコードを記述します。開発ツールキットは大部分が統合されており（エディターを除く）、分析ツールや継続的な統合ツール、リリース用のインフラストラクチャなど、内部で構築されています。

2.2。ABB

ABBには世界中に10万人以上の従業員がいます。エンジニアリングコングロマリットとして、同社はさまざまな職業を採用しています。業界固有の視覚言語とテキスト言語を使用して産業システムを構築する、約4,000人の一般的なソフトウェア開発者と10,000人を超えるアプリケーション開発者がいます。大規模なITインフラストラクチャを運用するために、同社はスクリプト作成や簡素化されたプログラミングを担当する重要な従業員を維持しています。



ABBは多くの中小企業を買収しましたが、ソフトウェア開発プロセスの統合を担当する中央組織があります。したがって、部門間の違いにもかかわらず、ほとんどのツールとアプローチは一貫しています。同じことがほとんどのキャリアパスにも当てはまります。ジュニアからシニアの開発者までの技術者、およびグループリーダーから部門リーダーおよび中央管理者までのエグゼクティブです。

2.3。ナショナルインスツルメンツ

NationalInstrumentsは1970年代に設立されました。ソフトウェア開発は、主に4つの国際的な研究開発センターに集中しています。従業員のカレンダーは会社全体に表示され、誰でも他の従業員との約束をすることができます。



仕事の責任は開発プロセスを促進します。開発者はプロジェクトを個別に選択することはできませんが、特定のタスクや機能を引き受けることはできます。ほとんどは、特定の所有者を持つさまざまな論理部分を持つ、共通のモノリシックコードベースで動作します。入力したコードは「所有者」の承認が必要です。コードは技術リーダーによって分析されることが望ましい。このポリシーはオプションですが、多くの人がそれに従います。



開発者は、ツールの選択に多くの自由を持っています。すぐにメリットがない限り、一般的なツールはありません。たとえば、IDEの選択は、タスクに大きく依存します。利用可能なカスタムビルドおよびテストツールがいくつかあります。会社のさまざまな部門が、ソースコードの管理と分析のためにさまざまなシステムを標準化しています。ソフトウェアアップデートは、まれな重要なパッチを除いて、通常、四半期ごとまたは年ごとにリリースされます。



表1.調査した3社のプロファイル：

3.方法論

私たちの目標は、ソフトウェア開発者の生産性を予測できる要因を見つけることです。これを行うために、一連の質問、一連の生産性要因、および一連の人口統計変数を含む調査を実施しました。

3.1生産性の評価

まず、生産性の測定方法について説明します。 RamírezとNembhardは、機能点分析、自己評価、ピア評価、結果と努力の比例、および専門的な時間の使用を含む、文献に記載されているパフォーマンス測定技術の分類を提案しました[2]。これらの手法は、客観的（たとえば、1週間に何行のコードが記述されるか）と主観的（たとえば、自己評価やピアレビュー）に分けることができます。



どちらの手法も推奨されません。どちらのカテゴリにも欠点があります。客観的な測定には柔軟性と遊び心が欠けています。 1週間あたりのコード行数を見てみましょう。生産的な開発者は、見つけにくいバグの1行の修正を書くことができます。また、非生産的な開発者は、行数を簡単に増やすことができます。一方、主観的な測定は、認知の偏りのために不正確になる可能性があります。ピアの評価を取得する：彼らは生産的な開発者を嫌う可能性があるため、ピアが客観性を求めて努力しても、評価が低下します。



ソフトウェア開発者の生産性を分析したMeyerが率いる研究者チーム[3]のように、私たちは研究の質問を生産性の主観的な尺度として使用しました。主な理由は2つあります。まず、RamirezとNembhardtが指摘しているように、研究は「[知識労働者]の生産性を測定するための簡単で一般的な方法」です。第二に、調査はさまざまな役割の開発者からの回答を提供し、回答者がパフォーマンススコアにさまざまな情報を追加できるようにします。



図：1.調査方法：





回答者に、この声明にどの程度同意するかを尋ねました。

私は定期的に高い生産性を達成しています。

それで、私たちは生産性をできるだけ広く測定したかったのです。最初に質問に対して8つのオプションを作成し、次に5人のGoogle開発者とフレーズの解釈について非公式に話し合うことで、それらを上記に減らしました（図1、左下）。 3つの理由から、質問に「高」と「定期的に」という単語を追加しました。まず、人々が自分自身を比較できる状態を捉えたかったのです。第二に、回答者の回答が上限に達することによる影響を回避するために、この状態を高くしたかったのです。第三に、回答者に生産性の2つの特定の尺度である強度と頻度に焦点を当ててもらいたいと考えました。将来的には、研究者は、強度と頻度を2つの別々の問題に分割することにより、より詳細な測定を適用できるようになります。



Googleの3人の幹部に、「生産性に関する声明に回答する際に何を考慮しましたか」と尋ねるチームに送信するよう依頼して、テストを行いました。 23人の開発者から回答がありました（図1、中央下）。回答者の考慮事項が生産性の価値に関する私たちの期待と一致したため、このオプションは私たちの目的に受け入れられると見なされました。これらの考慮事項には、ワークフローの問題、作業の結果、ゾーンまたはフロー内にいること、幸福、達成された目標、プログラミングの効率、進捗状況、および無駄の最小化が含まれていました。この論文ではこれらの反応を分析しませんでしたが、この研究には、以前の研究[2]、[4]、[5]から得られた生産性の4つの追加の洗練された測定が含まれていました。



自尊心を文脈化するための客観的なデータを追加するために、生産性の2つの便利な指標を選択し、Googleでそれらを相互に関連付けました。最初の客観的な尺度は、開発者が1週間に変更したコードの行数でした。これは、人気がありますが挑戦的な生産性の尺度です[6]、[7]。 2番目の測定値は、開発者が単位時間あたりにメインのGoogleコードベースに対して行った変更の数でした。これは、Vasilescuが率いるチームが使用する毎月のプルリクエストとほぼ同等です[8]。生産性を評価するために、Googleでの同様の調査への回答を使用しました（n = 3344の回答）。回答に参加者IDが含まれていなかったため、この分析に調査のデータを使用できませんでした。生産性の客観的な尺度を比較することができます。その研究では、同様の質問がなされました：「あなたは仕事で非常に生産的であるとどのくらいの頻度で感じますか？」参加者は、「ほとんどまたはまったくない」、「時々」、「約半分の時間」、「ほとんどの場合」、「常にまたはほとんど常に」と答えることができました。次に、自己申告のパフォーマンスを順序従属変数（それぞれ1、2、3、4、および5にコード化）として線形回帰を作成しました。線形回帰は、生産性評価間の距離が等しいことを前提としています。質問で使用されている言葉を考えると、この仮定は正当であると考えます。順序付きロジスティック回帰の場合、この仮定は必要ありません。ここでこの手法を適用すると、信頼できる結果が得られます。同じ係数が線形で重要です。と注文モデルで。



両方とも正に歪んでいるため、独立変数として対数客観的尺度を使用します。制御のために、ジョブコード（たとえば、ソフトウェアエンジニア、リサーチエンジニアなど）をカテゴリ変数として使用し、ランク（ジュニア、ミドル、シニアなど）を数値（たとえば、ソフトウェアの場合は3）として使用しました。 Googleのエントリーレベルのエンジニア）。ジョブコードは、各線形モデルの2つのワーカーロールで統計的に有意でした。全部で3つのモデルがありました。2つは客観的測定の1つで、もう1つは両方の客観的測定です。





図：2：2つの客観的尺度に基づいて主観的なパフォーマンス推定値を予測するモデル。nsは、p> 0.05の統計的に重要でない係数を意味し、**はp <0.01を意味し、***はp <0.001を意味します。モデルの完全な説明は、補足資料に記載されています。



コンテキスト化の結果を図に示します。 2.各モデルは、負の評価で統計的に有意なレベルを示しています。これは、次のように解釈されます。ランクの高い開発者は、生産性がわずかに低いと評価する傾向があります。これはランク管理の強力な議論です（セクション3.7）。最初の2つのモデルは、生産性の客観的測定と主観的測定の間の重要な正の関係を示しています。つまり、記述されるコードの行数や変更が多いほど、開発者は自分自身を生産性が高いと見なします。結果として得られた最初の2つのモデルの組み合わせモデルと推定値は、行われた変更の数が、書き込まれた行の数よりも生産性のより重要な指標であることを示唆しています。しかしなお、すべてのモデルのパラメータR ²説明された分散の割合を表す、はかなり低く、各モデルで3％未満です。



一般に、得られた結果は、コードの行数と行われた変更が開発者の生産性の評価に影響を与えるが、それほど大きくはないことを示しています。

3.2。生産性要因

次に、調査の過程で、他の作品で生産性に関連すると考えられる要因について参加者に質問しました。4つのソースから質問を収集しました（図1、左中央）。これらの情報源は、私たちの知る限り、プログラマーや他の知識労働者の研究における個々の生産性要因の最も包括的な概要を表しているために採用されています。



最初のソースパルバリンが率いるチームが作成したツールで、ナレッジワーカーの生産性指標を確認します[4]。SmartWoWと呼ばれるこのツールは、4つの企業で使用されており、物理的、仮想的、社会的なワークスペース、個人的な作業慣行、および職場での幸福の側面をカバーしています。現在の開発者の用語をより適切に反映し、アメリカの英語によりよく一致するように、いくつかの質問を変更しました。たとえば、SmartWoWは次のように質問します。

私はしばしば、途切れることのない集中力を必要とするタスクを実行するためにテレワークを行います。

私たちは言い換えました：

私はしばしば、途切れることのない集中を必要とするタスクを実行するためにリモートで作業します。

SmartWoWから、最初に38の質問を選択して調査しました。



2番目の情報源は、知識労働者の生産性に対する作業環境の特性の影響に関するHernausとMikulićによるレビューです[9]。彼らの実証済みの研究は、以前の生産性研究を反映しています。労働環境設計質問票[10]、診断労働環境研究[11]、グループコラボレーションの評価[12]「タスクの性質」の評価[13]。質問を短く一貫性のあるものに変更しました。同じ目的で、個人の生産性をほとんど考慮せずにワーキンググループに専念している仕事[12]から直接質問を受けました。



3番目のソース-ソフトウェア開発における生産性要因のWagnerとRuheの構造化されたレビュー[14]。他の情報源とは異なり、この作品は科学界によって徹底的にレビューされておらず、独自の経験的研究は含まれていません。しかし、私たちの知る限り、これはプログラミング生産性研究の最も包括的な調査です。 WagnerとRouetによって策定された要素は、技術的要素と定量化不可能な要素に分けられ、環境、企業文化、プロジェクト、製品および開発環境、機能、経験の要素がさらに強調されます。



4番目のソースMeyerが率いるチームが率いるMicrosoft開発者調査です。それから、目標設定、作業会議、休憩など、生産的な就業日の5つの主な理由を収集しました[15]。



また、以前の作品では適切に考慮されていなかったが、Googleのコンテキストでは重要であることが判明した3つの要素を追加しました。1つは、SmartWoWの未発表の前身であるナレッジワーカー[16]の生産性評価です。私たちはそれを次のように適応させました：

私に提供された情報（バグレポート、ユーザースクリプトなど）は正確です。

2番目の要素は、作業環境設計質問票から取得され、次のように適合されます。

仕事の生産性について有益なフィードバックを得ることができます。

そして、ABB環境で重要な3番目の要素を作成しました。

ソフトウェアをテストするには、特定のハードウェアに直接アクセスする必要があります。

まず、127の要素を選びました。回答者が大きな疲労なしに答えることができるような数の質問にそれらを減らすために[17]、図の中央に示されている基準を使用しました。1：

1. 重複を削除しました。たとえば、SmartWoW [4]およびMeyeret al。[15]では、目標設定は生産性の重要な要素と見なされています。
2. 同様の要因が組み合わさった。たとえば、HernausとMikulichは、生産性を向上させるワークグループ間の相互作用のさまざまな側面について説明していますが、それらを1つの要素に減らしました[9]。
3. 明らかな有用性のある要因が優先されました。たとえば、SmartWoW [4]には次のような要素があります。

従業員はお互いのカレンダーを見る機会があります。

Googleでは、これはどこにでも当てはまり、変更される可能性は低いため、この要素の有用性は低くなります。



これらの基準を共同で繰り返し適用しました。最初に、研究で使用するためのすべての候補質問の大きなポスターが印刷されました。次に、オフィスの横にGoogleのポスターを貼っています。次に、私たち一人一人が上記の基準に基づいて質問を独自に分析しました。ポスターは数週間ぶら下がっていましたが、定期的にリストを補足して改訂しました。最後に、質問の最終リストが作成されました。



私たちの研究には、ステートメントの形で48の要素が含まれていました（図4、左の列）。回答者は、これらの声明に対する同意の程度を、「まったくそう思わない」から「非常にそう思う」までの5段階で示しました。要因は、方法論、焦点、経験、仕事、機会、人、プロジェクト、ソフトウェア、およびコンテキストに関連するブロックにグループ化できます。また、回答者が見逃したと感じた要因について、自由回答形式の質問を1つ行いました。私たちの研究からの完全な質問票は補足資料で提供されます。





図：3：研究からの質問の例。

3.3。人口統計

図1に示すように、いくつかの人口統計学的要因について質問しました。

• 床。
• ポジション。
• ランク。

以前の作品の著者は、性別はソフトウェア開発者の生産性の要因、たとえばデバッグの成功と関連していることを示唆しています[18]。したがって、この研究には、性別についての任意の質問がありました（男性、女性、答えることを拒否する、私自身）。質問に回答しなかった回答者は、「回答を拒否する」グループに割り当てられました（Google n = 26 [6％]、ABB n = 4 [3％]、National Instruments n = 5 [6％]）。このデータをカテゴリとして扱いました。



役職については、人事部からグーグルの先輩を採用しました。これはABBとNationalInstrumentsでは不可能だったため、オプションの質問を調査に追加しました。 ABBでは、回答がない場合（n = 4 [3％]）、12年の経験があり、これは収集されたデータの平均です。 National Instrumentsでは、同じ理由で9年かかりました（n = 1 [1％]）。たとえば、利用可能なデータに基づいて欠落値を予測するために置換を使用することは、より困難になる可能性があります[19]。不足しているランク情報は、位置と性別に基づいてかなり正確に入力できるとしましょう。ただし、人口統計学的要因は私たちにとって最も重要ではなく、管理のための情報を伴うだけであったため、平均的な統計値のみに置き換えました。このデータを数値として処理しました。



ランクに関しては、Googleで参加者にレベルを数値で示すように依頼しました。欠落している回答（n = 26 [6％]）は、最も一般的な値を参照しました。



ABBでは、寄稿者はオプションで「ジュニアまたはシニアソフトウェア開発者」を示すことができますが、多くは「異なる」タイトルを示します。答えに次の単語が含まれている場合：

• 古い
• リーディング
• マネージャー
• 建築家
• 研究者
• メイン
• 科学者

それから私達はそのような答えを「上級」のものに言及しました。残りは「ジュニア」と呼ばれていました。欠落している回答（n = 4 [3％]）は、最も一般的な意味である「シニア」に起因します。



National Instrumentsにはオプションがありました：

• チャレンジャー
• スタッフ
• 古い
• プリンシパルアーキテクト/エンジニア
• チーフアーキテクト/エンジニア
• 名誉あるエンジニア
• 参加者
• その他

唯一の「その他」はインターンであり、私たちはそれを「応募者」に移しました。欠落している回答（n = 3 [4％]）は、最も一般的な意味である「シニア」に起因します。



すべての企業のランクを番号でコード化しています。

3.4。非開発者との比較

次に、開発者が生産性をどのように評価するかを正確に予測できるものに関心がありました。たとえば、生産性は仕事を休むことによって影響を受けると想定しましたが、それはどの知識労働者にも言えることです。したがって、自然な疑問が生じます。これは、開発者の生産性に特別な方法で何らかの影響を及ぼしますか？



この質問に答えるために、私たちはソフトウェア開発者に匹敵する職業を選びました。まず、Googleでの位置に基づいて選択しようとしました。いくつかのポジションは彼らが知識労働者であると示しましたが、最も一般的で、私たちの意見では、適切な非開発者の最も信頼できる指標は、ポジションに「アナリスト」という言葉が存在することでした。 Googleのアナリストを、3社すべての開発者と比較するのではなく、Googleのアナリストと開発者を比較することにしました。これにより、会社の特性を制御できるようになると判断しました（たとえば、突然Googleの従業員が他の会社の従業員よりも統計的に中断に対して敏感になった場合）。



次に、アナリスト向けに調査を調整しました。「ソフトウェア要件が頻繁に変更される」など、ソフトウェア開発に明確に関連する質問を削除しました。特にアナリスト向けに他の質問を作り直しました。たとえば、「私は最高のツールとテクニックを使用してソフトウェアを開発する」のではなく、「最高のツールとアプローチを使用して仕事をする」と書きました。



生産性スコアは、開発者と同じ方法で測定されました。性別、地位、ランクの評価についても同じことが言えます。調査は一般的に明確であり、いくつかのマイナーな調整を行ったと述べた5人のアナリストの便利なサンプルで、調査の「分析」バージョンをテストしました。私たちはそれらを受け入れ、非開発者の本格的な調査を実施しました。

3.5。制御質問

むやみに出された回答を除外するために、調査開始の約70％後に、注意力に関する質問を挿入しました[20]。「これに答えてください。私はむしろ同意しません。」この質問に対するそのような回答が含まれていないフォームは考慮していません。

3.6。回答のシェア

グーグルでは、ソフトウェア開発の役割を持つ人材の中から、1,000人のランダムなフルタイム従業員を選びました。彼らから436の記入済みフォームを受け取りました。つまり、回答率は44％であり、開発者の間での研究の非常に高い指標です[21]。セキュリティに関する質問に対する回答が間違っているフォームを削除した後（n = 29 [7％]）、407の回答が残っていました。



ナレッジワーカーの調査では、役職に「アナリスト」という単語が含まれる200人のランダムなフルタイムのGoogle従業員を選択しました。私たちのターゲットはソフトウェア開発者だったので、あまり多くのアナリストを調査しないことにしました。 94人（47％）が私たちの質問に答えました。セキュリティに関する質問に誤って回答した質問票を削除した後（n = 6 [6％]）、88人が残った。



ABBでランダムに選ばれた約2,200人のソフトウェア開発者にアンケートを送信し、176件の回答を受け取りました。これは8％であり、そのような研究の下限です[21]。間違った質問票を削除した後（n = 39 [22％]）、137が残った。



最後に、National Instrumentsの約350のソフトウェア開発者に質問票を送信し、91の回答（26％）を受け取った。間違った質問票を削除した後（n = 13 [14％]）、78人が残った。

3.7。分析

各企業の各要因について、その要因を独立変数として使用し（たとえば、「プロジェクトの締め切りが厳しい」）、生産性の見積もりを従属変数として使用して、個別の線形回帰モデルを適用しました。プライバシー保護のため、会社ごとに別々のモデルを実行し、異なる会社の生データが混ざらないようにしました。付随変数の影響を減らすために、既存の人口統計変数を各回帰モデルに追加しました。結果の解釈では、生産性係数比の3つの側面に焦点を当てました。

• 評価。人口統計学的定数を維持しながら、各要因の影響の程度を示します。値が大きいほど、影響が大きくなります。
• . . , .
• . p < 0,05. 48 , p -, [22].

結果の解釈では、実際的な重要性が低くても十分な大きさのデータセットから抽出できるため、影響の程度（評価）に重点を置き、統計的有意性には重点を置きませんでした。以下に示すように、統計的に有意な結果がGoogleで最も頻繁に見つかり、回答率が最も高かった。とりわけ、回答率が低かったNationalInstrumentsで。この違いは、主に統計力によるものだと感じました。統計的に有意な結果に自信を持っていただくことをお勧めします。



コンテキストを提供するために、人口統計学的要因がパフォーマンス評価とどのように相関するかも分析しました。これを行うために、人口統計変数を独立変数として、生産性の推定値を従属変数として、各企業に対して複数の線形回帰を実行しました。次に、結果のモデルの全体的な予測値と、各説明変数の影響を分析しました。

3.8。因果関係について

私たちの方法論では、生産性の要因とそれ自体の生産性の評価との関係を評価できますが、本質的には、生産性の変化に対する各要因の影響の程度に関心があります。要因と生産性の間に因果関係があると信じるのはどれほど正しいですか？



正確さは、主に前の研究における因果関係の証拠の強さに依存します。そして、この力はさまざまな要因によって異なります。たとえば、Guzzoが率いるチームは、評価とフィードバックに関する26の記事のメタ分析を実施しました。その結果は、フィードバックが職場の生産性を向上させるという優れた証拠を提供します[23]。ただし、調査した各要因の証拠の強さを判断するには、多くの作業が必要であり、この記事の範囲を超えています。



要約すると、私たちの研究では因果関係を確立することはできませんが、以前の研究に基づいて、これらの要因が生産性に影響を与えると確信できますが、結果を慎重に解釈してください。

4.結果

まず、人口統計学的特性を制御する際の、生産性のすべての要因とそれらの生産性の評価との関係について説明します。これらのデータは、各調査の回答に回答するために使用され、その後、結果について説明されます。次に、人口統計学的特性とパフォーマンス測定の関係について説明します。最後に、影響とリスクについて説明しましょう。

4.1。生産性要因

図では 図4は、セクション3.7で説明した分析結果を示しています。最初の列は、ステートメントの形で参加者に提案された要素を示しています。続いて、分析の完了後に割り当てた因子ラベル（F1、F2など）が続きます。データが不足しているということは、これらの要因が開発者に固有であり、アナリストに提案されていないことを意味します（たとえば、F10）。



図：4：48の要因と、開発者とアナリストが3つの企業で自分の生産性を評価する方法との関係：

次の3つの列は、3社のデータとGoogleアナリストのデータです。これらの各列は、2つのサブ列に分割されています。



サブカラムの見積もり（スコア）には、因子とその生産性の推定値との関連の強さを定量化する回帰係数が含まれています。数値が大きいほど、関連付けが強くなります。たとえば、Googleの最初の列では、見積もりは0.414です。この場合、これは、仕事への熱意に関する声明（F1）との一致が高まる各ポイントについて、モデルは、人口統計変数の制御により、回答者の生産性評価が0.414ポイント増加すると予測することを意味します。評価はマイナスになる可能性があります。たとえば、3つの会社すべてで、チームのスタッフの離職率が高いほど（F48）、生産性の見積もりは低くなります。各スコアの横には、スコアを明確に反映するインジケーターがあります。



スコアは、要因のより高い評価を意味するのではなく、要因と生産性の評価の間のより高い相関を意味することに注意してください。たとえば、National Instruments（F1）は、他社よりも高い熱意を示しています。これは、開発者がより熱心であることを意味するものではありません。この会社では、彼は彼らの生産性の評価を予測する上でより強力な要素です。協力の条件で禁止されているため、評価自体は提供していません。完全なコンテキストがないと、評価が誤って解釈される可能性があります。たとえば、ある会社の開発者は別の会社の開発者よりも自分の仕事にあまり熱心ではないと報告した場合、その別の会社で働いていない方が良いという印象を受けるかもしれません。



2番目のサブ列エラー（エラー）には、各要素のモデルの標準エラーが含まれます。値が小さいほど良いです。直感的には、値が低いほど、要因が変化したときにモデルがそのパフォーマンスをより確実に予測することを示しているようです。全体的なエラー値は、特に多数の回答者がいるGoogleでは、要因ごとにかなり安定しています。



アスタリスク（*）は、この係数がモデルで統計的に有意であることを示します。たとえば、仕事への熱意（F1）は3社すべてで統計的に有意ですが、会議の準備（F17）はGoogleでのみ有意です。



次の列には、括弧内に標準偏差（σ）が付いた3社すべての平均（μ）スコアが含まれています。）。最初の指標は平均スコアの値を明確に示し、2番目の指標は標準偏差の値を示します。たとえば、職場での熱意の平均スコア（F1）は0.43で、標準偏差は0.051でした。表は平均評価でソートされています。



最後の列には、Googleでのソフトウェア開発者とアナリストの評価の違いが含まれています。正の値は開発者の評価が高いことを意味し、負の値はアナリストの評価が高いことを意味します。たとえば、熱意（F1）の観点から、アナリストの評価は開発者よりもわずかに低くなっています。

4.2。開発者が生産性を評価する方法を最もよく予測する要因は何ですか？

最も強力な予測因子は、絶対平均スコアが最も高いステートメントです。最も弱い予測因子は、絶対平均スコアが最も低いものです。言い換えれば、図の表の上部にある要因。4が最良の予測因子です。結果に最も信頼できる要因を理解するために、3社すべてで統計的に有意な結果を強調しました。

• 仕事への熱意（F1）
• 新しいアイデアのピアサポート（F2）
• 仕事の成果に関する有益なフィードバック（F11）

ディスカッション。最初の10の生産性要因は技術的ではないことに注意してください。私たちの推定では、ソフトウェア開発者による研究のほとんどが技術的側面に焦点を合わせていることを考えると、これは驚くべきことです。したがって、人的要因への積極的な方向転換は、業界に対する研究者の影響力の大幅な増加につながる可能性があります。たとえば、次の質問への回答は特に有益です。

• ソフトウェア開発者が自分の仕事に熱心になっている理由は何ですか？熱意の違いを説明するものは何ですか？どのような介入が熱意を高めることができますか？この記事は、幸福[24]と動機[25]に関する研究を補足することができます。
• ? , ? ?
• , ? ? ?

もう1つの重要な機能は、COCOMOIIの研究ラインからの要因のランク付けです。業界のソフトウェアプロジェクトの実証的研究の過程で得られ、83のプロジェクトの数値分析によって検証されたこれらの要因[26]は、もともとソフトウェア開発のコストを見積もるために策定されました。たとえば、COCOMO IIの生産性要因には、ベースプラットフォームの変動性や製品の複雑さが含まれます。私たちの研究で考慮されたCOCOMOIIの要因（F5、F10、F14、F16、F24、F26、F28、F32、F33、F34、F36、F38、F39、F43、F44、F46、F47、F48）が低くなったことは不思議です値。それらは生産性の悪化を予測することを可能にすると考えられます。予測因子の上半分（F1 – F24）には、COCOMO IIが5つだけ含まれ、下半分には14の因子が含まれていました。 2つの異なる解釈を提供できます。最初：COCOMO IIにはいくつかの重要な生産性要因が欠けており、作業アプローチの自律性のサポートなど、調査した要因の多くが社内に導入された場合、COCOMOIIの将来の反復はより予測可能になる可能性があります。別の解釈：COCOMO IIは、現在のタスク（プロジェクトレベルでの生産性の固定[6]、[27]、[28]、[29]、[30]、[31]）に適合していますが、個々の開発者レベルでの生産性の固定にはあまり適していません。この解釈は、私たちの結果の重要性と新規性を強調しています。COCOMO IIは、現在のタスク（プロジェクトレベルでの生産性の修正[6]、[27]、[28]、[29]、[30]、[31]）に適合していますが、個々の開発者レベルでの生産性の修正にはあまり適していません。この解釈は、私たちの結果の重要性と新規性を強調しています。COCOMO IIは、現在のタスク（プロジェクトレベルでの生産性の固定[6]、[27]、[28]、[29]、[30]、[31]）に適合していますが、個々の開発者レベルでの生産性の固定にはあまり適していません。この解釈は、私たちの結果の重要性と新規性を強調しています。



さらに、すべてのCOCOMO II要因は比較的低く、3社すべての生産性の統計的に重要でない予測要因でした。例えば：

• 私のソフトウェアは多くの処理能力を必要とします（F39）。
• 私のソフトウェアには大きなデータストア（F43）が必要です。
• 私のソフトウェアプラットフォーム（開発環境、ソフトウェア、ハードウェアスタックなど）は急速に変化しています（F46）。

1つの説明：COCOMO IIの作成とテストから20年間で、プラットフォームの生産性の多様性は低下しました。現在、標準化されたオペレーティングシステムは、ハードウェアの変更による生産性の損失から開発者を保護している可能性があります（たとえば、モバイル開発におけるAndroid）。同様に、クラウドプラットフォームは、プロセスのスケーリングとストレージのニーズによる生産性の損失から開発者を保護できます。言うまでもなく、最新のフレームワークとクラウドプラットフォームは使いやすいです。また、COCOMO IIの作成により、大量のデータと少量のデータを処理する際の生産性の違いがなくなった可能性があります。

4.3。これらの要因は会社ごとにどのように異なりますか？

この質問に答えるために、3社の見積もりの​​標準偏差を見ることができます。変動が最も少ない、つまり企業全体で最も安定した値を持つ3つの要因は次のとおりです：

1. 焦点を合わせるためにテレワークを使用する（F40）。
2. 作業パフォーマンスに関する有用なフィードバック（F4）。
3. 新しいアイデアのピアサポート（F2）。

これらの要因の安定性は、一般化の良い候補になると信じています。他の企業は、これらの要因について同様の結果を見る可能性があります。



そして、これが最大の変動性を持つ3つの要因、つまり、企業全体で最大の価値の広がりを持つ3つの要因です：

1. 最高のツールとアプローチを使用する（F15）。
2. コードの再利用（F25）。
3. 着信情報の精度（F6）。

ディスカッション。最も変動の少ない3つの要素（F40、F4、F2）には共通の特徴があります。これらはテクノロジーではなく、社会と環境に関係しています。おそらくこれは、開発者がどこで働いていても、リモート作業、フィードバック、新しいアイデアに対するピアサポートの影響を等しく受けていることを示唆しています。これらの3つの要素を変更することが、最大の影響であることがわかる場合があります。



ファクターF15、F25、F6が会社によって大きく異なるのはなぜですか？それぞれについて、これらの企業について私たちが知っていることに基づいて、可能な説明があります。



最高のツールとアプローチ（F15）を使用することは、Googleのパフォーマンススコアと最も強く関連していますが、NationalInstrumentsとはあまり関連していません。考えられる説明：Googleのコードベースははるかに大きいです。したがって、より優れたツールとアプローチを使用して、より大きなコードベースを効率的にナビゲートおよび理解することは、生産性に大きな影響を及ぼします。また、National Instrumentsでは、コードベースが小さく明確であるため、生産性はツールに依存しません。



コードの再利用（F25）は、Googleのパフォーマンススコアと強く関連していますが、ABBとはあまり関連していません。考えられる説明：Googleを使用すると、コードの再利用が簡単になります。コードベースはモノリシックであり、すべての開発者は社内のほぼすべてのコード行を調べることができるため、再利用に多くの労力を必要としません。また、ABBには、アクセスする必要のあるリポジトリがたくさんあります。そしてこの会社では、（再利用による）生産性の向上は（適切なコードを見つけて取得することによる）生産性の低下によって相殺することができます。



情報精度（F6）は、National Instrumentsのパフォーマンススコアと強く関連していますが、ABBとはあまり関連していません。考えられる説明：ABBの開発者は、不正確な情報の影響からより隔離されています。特に、ABBでは、いくつかのレベルのサポートチームが、顧客からバグに関する正しい情報を入手することに専念しています。開発者が不正確な情報を受け取った場合、データを洗練するタスクをサポートチームに委任する必要があるため、生産性が低下する可能性があります。

4.4。特に他のナレッジワーカーと比較して、開発者の生産性の評価を予測することを可能にするものは何ですか？

この質問に答えるには、図の最後の列に目を向けてください。4.最大評価間のいくつかの関係を見ると、アナリストによる生産性の評価は、以下とより強く関連していることがわかります。

• チームメイトの前向きな認識（F7）。
• 労働時間の編成における自律性（F4）。

一方、開発者による生産性の評価は、以下に強く関連しています。

• 作業内でさまざまなタスクを実行する（F13）。
• 職場の外で効果的に働く（F30）。

ディスカッション。全体として、結果は、開発者が他のナレッジワーカーと多少類似しており、多少異なることを示しています。たとえば、開発者の生産性は仕事への熱意によって最もよく予測され、アナリストもほとんど同じです。企業は、調査結果を使用して、開発者固有の生産性イニシアチブまたはより広範なイニシアチブを選択できると考えています。



GoogleのUnifiedDevelopment Toolkitは、タスクの多様性の増加が、アナリストではなく開発者の生産性評価の向上に関連している理由を説明している可能性があります。タスクの多様性は、両方のグループの退屈さを減らし、生産性を高めることができますが、Googleの統一された開発ツールは、開発者が異なるタスクに同じツールを使用できることを意味します。また、アナリストはタスクごとに異なるツールを使用する必要がある場合があります。これにより、コンテキスト切り替えの認知的労力が増加します。



不在時の作業は、職場から離れた場所での作業効率の向上が、アナリストよりも開発者の生産性の向上に強く関連している理由を説明している可能性があります。プログラミング中は分析作業中よりも作業を中断する方が有害であると考えています。



ParninとRugaberは、中断後に仕事に戻ることは開発者にとって頻繁で永続的な問題であり[32]、問題の仕事に戻るのに役立つより良いツールが必要になることを発見しました[33]。

4.5。その他の生産性要因

質問の最後に、回答者は、彼らの意見では、生産性に影響を与える追加の要因を示すことができます。ほとんどの場合、これらの追加は、48の要素の説明と同じかそれ以上に洗練されたものでした。そのような追加は破棄しましたが、必要に応じて、新しい要素を作成しました。補足資料には、新しい要素の説明と、最初に提案した要素の更新された説明が含まれています。将来の研究者は、プロジェクトに取り組むための新しい混合チームの質問を持っているか、ファクターF15、F16、およびF19のより具体的な質問の内訳を洗練または提案する可能性があります。

4.6。人口統計

GoogleとNationalInstrumentsでは、一般的な人口統計モデルも個々のコンパニオン変数も、パフォーマンススコアの統計的に有意な予測因子ではありませんでした。



ABBのために、人口統計モデルが（有意であることが判明したF = 3 、 406 、DF =（5 、 131）、P <0.007）。性別も統計的に有意な要因であることが判明しました（p = 0.007）。女性は男性より0.83ポイント高い生産性を推定しています。他の性別（「その他」）の参加者は、男性よりも1.6ポイント高いスコアを示しました（p = 0.03）。位置（p= 0.04）、会社は毎年、パフォーマンスの見積もりを0.02ポイント上げました。私たちが知る限り、ABBと他の2つの会社の違いは、これらの人口統計学的要因がABBでのみ重要であると予測された理由を説明していません。

4.7。実際および研究におけるアプリケーション

結果を実際に使用するにはどうすればよいですか？イニシアチブの優先順位付けに使用できる生産性を予測する上で最も重要な要素のランク付けされたリストを提供しました。イニシアチブの例は、以前の研究論文に記載されています。



たとえば、職場での熱意を高めるために、MarkosとSrideviは、テクノロジーと対人コミュニケーションに関するワークショップを通じて、労働者が専門的に成長するのを支援することを提案しました[34]。また、研究者たちは、良い仕事に対する感謝の実践を導入することを提案しました。たとえば、ABBは、構造化コードをナビゲートするためのツールと手法を実装した開発者に対する一般の評価を実験しています[35]。



新しいアイデアへの支持を高めるために、ブラウンとデュギッドはベストプラクティスを共有するための公式および非公式の方法を提案しました[36]。 Googleでは、一方向の知識の普及はトイレテストイニシアチブを通じて行われます。開発者はテストや別の分野に関する短いニュース記事を書き、これらのメモは会社全体のトイレに投稿されます。



仕事の生産性に関するフィードバックの質を向上させるために、ロンドンとスミザーは、判断力がなく、行動に基づいており、解釈可能で、結果指向のフィードバックに焦点を当てることを提案しています[37]。 Googleでは、このようなフィードバックは無害な事後分析を通じて取得できます。サービスの低下などの重要なネガティブなイベントの後、エンジニアは特定の従業員を非難することなく、問題の根本原因に影響を与えたアクションに関するレポートを共同で作成します。



私たちの仕事に基づいて、将来の研究にはいくつかの方向性があります。



まず、ここで説明する各生産性要因の証拠の影響とコンテキストを特徴付ける記事の体系的なレビューは、因果関係を作成することにより、作業の使いやすさを向上させます。それらが弱い場合、原因を確立するために一連の実験を行うことにより、適用性を改善することができます。



次に、セクション4.5および4.6で述べたように、将来の研究者は、回答者が提案した追加の要因を使用して、開発者の生産性に対する性別およびその他の人口統計学的要因の影響を調べることができます。



第三に、ソフトウェア開発に対する生産性調査の影響は、経験的調査と三角測量によって検証された多次元のメトリックとツールのセットを使用して改善できます。



第4に、研究者が生産性に影響を与える要因を変更するコストを計算できれば、企業はより賢明な投資決定を下すことができます。

4.8。リスク

この研究の結果を解釈する際には、その有効性に対するいくつかのリスクを考慮する必要があります。



4.8.1。データの信頼性に対するリスク



まず、生産性の評価という1つの測定についてのみ説明しました。 Facebookで使用されているアプローチである1日あたりに記述されたコードの行数など、客観的な測定を含む他の側面があります[38]。セクション3.1で指摘したように、すべての生産性指標には、独自の生産性の測定を含む欠陥があります。たとえば、開発者は生産性の評価に軽薄すぎたり、社会の偏見のために評価を人為的に過大評価したりする可能性があります[39]。これらの欠点にもかかわらず、Zelenskiが率いるチームは、この記事でも使用されているパフォーマンス評価[40]の有効性を議論するために以前の作業に基づいています。



次に、開発者の生産性の全範囲をカバーすることはほとんどできない単一の質問で生産性を測定しました。たとえば、質問は頻度と強度に焦点を当てていますが、品質は考慮していません。また、回答者に特定の時間枠に回答を限定するよう依頼しなかったため、過去1週間の経験に基づいて回答する参加者もいれば、過去1年間の経験を評価する参加者もいます。振り返ってみると、研究は一定の時間間隔で実施する必要があります。



第三に、質問の数が限られているため、以前の作業で調査された要素のみに依存しました。選択した48の質問は、生産性に関連する行動のすべての側面を網羅しているとは限りません。または、選択した要素が一般的すぎる場合もあります。たとえば、振り返ってみると、ツールをメソッドから分離すると、最良の「ツールとアプローチ」（F14）に関連する要素がより強力になる可能性があります。



4.8.2。信頼性に対する内部リスク



第4に、セクション3.8で述べたように、要因と生産性の間の因果関係を確立するために以前の作業を利用しましたが、関係の証拠の強さは異なる場合があります。一部の要因は、他の要因を介して間接的にのみ生産性の評価に影響を与えるか、またはそれらの接続は一般的に反対の方向を向いていることが判明する場合があります。たとえば、生産性の主な要因である仕事への熱意の高まり（F1）は、実際には生産性の向上が原因である可能性があります。



4.8.3。信頼性に対する外部リスク



第5に、3つのかなり異なる企業を調査しましたが、他のタイプの企業、他の組織、および他のタイプのナレッジワーカーとの一般化は限られています。このホワイトペーパーでは、非開発者の代表としてアナリストを選択しましたが、このカテゴリには、医師、建築家、弁護士など、いくつかのタイプのナレッジワーカーが含まれます。信頼性に対するもう1つのリスクは、回答の欠如による偏見です。質問に回答した人は自分で選択しました。



第6に、生産性の各要素を個別に分析しましたが、多くの要素が相互に付随する可能性があります。これは分析の問題ではありませんが、結果の適用可能性です。要因が相互に依存している場合、一方を変更すると他方に悪影響を与える可能性があります。



4.8.4。建設的な



信頼性へのリスク第7に、この調査を作成する際に、回答者が分析方法を認識し、正直に回答しない可能性があることを懸念しました。生産性の問題をその要因から分離することでこの可能性を減らすように努めましたが、回答者は分析方法について結論を出すことができた可能性があります。



最後に、アナリスト向けに調査を調整するためにいくつかの質問を言い換えました。これにより、質問の意味が望ましくない形で変わる可能性があります。その結果、開発者とアナリストの違いは、職業ではなく質問の違いから生じた可能性があります。

5.関連作業

多くの研究者は、ソフトウェア開発者のために個々の生産性要因を研究してきました。たとえば、MoserとNierstraszは、36のソフトウェア開発プロジェクトを分析し、開発者の生産性の向上に対するオブジェクト指向テクノロジーの潜在的な影響を調査しました[41]。



もう1つの例は、DeMarcoとListerによる、35の組織からの166人のプログラマーが1日のプログラミング演習を行っている研究です。著者らは、職場と組織が生産性に関連していることを発見しました[42]。



3番目の例は、16人の開発者によるKerstenとMurphyによる実験室実験です。ツールを使用してタスクに集中した人は、他の人よりもはるかに生産的であることが判明しました[43]。



さらに、ワーグナーとルーエの体系的な分析は、個々の要因と生産性の関係についての良いアイデアを提供します[14]。 Mayerが率いるチームは、生産性要因の概要に関するさらに最近の分析を提供しました[3]。一般に、私たちの仕事は、個々の要因のこれらの研究に基づいており、それらの多様性についてより広範な研究が行われています。



Petersenの体系的なレビューによると、7つの論文がソフトウェア開発者の生産性を予測する要因を定量化しています[44]。各作業では、予測に数値法が使用されます。通常、これは回帰であり、これは私たちの研究でも使用されています。最も一般的な要因はプロジェクトの規模に関連しており、7つの要因のうち6つは、COCOMO IIの生産性ドライバーに基づいて明示的に定式化されています（[6]、[27]、[28]、[29]、[30]、[31]）。 Petersenの研究で最も複雑な予測モデルは、16の要因を使用します[6]。



私たちの仕事には2つの大きな違いがあります。まず、これまでの作品と比較して、より多くの要因を推定し（48）、その多様性はより広い。産業および組織の心理学に基づいて要因を選択しました。第二に、分析の対象が異なります。以前の研究者は、プロジェクトのフレームワークで生産性を予測できるものを研究し、人々の個人的な生産性に関心を持っていました。



ソフトウェア開発に加えて、以前の研究では、他の職業、特に産業心理学および組織心理学の分野での生産性を予測する要因を比較しました。そのような研究は企業レベルの生産性[45]と製造などの物理的労働[46]に焦点を合わせてきましたが、最も近い焦点は知識労働者の生産性にあります。つまり、通常はコンピューターを使用して、仕事で知識や情報を積極的に使用する人々[47]。そのような職業の要因の比較は、2つの主要な作品で提示されます。 1つ目は、パルワリンが主導するチームスタディで、以前のスタディで生産性と比較した38の要因を調べています。これらの要素には、物理​​的、仮想的、社会的なワークスペースが含まれます。個人的な作業アプローチと職場での幸福[4]。 2つ目は、HernausとMikulichによる512人の知識労働者の研究です。著者らは、3つのカテゴリーに分けられた14の要因を研究しました[9]。研究の準備では、これらの両方の作業に依存しました（セクション3.2）。



ただし、ナレッジワーカーの生産性要因を比較する研究では、ソフトウェア開発者は注目されていません。これには2つの主な理由があります。まず、得られた全体的な結果が開発者にどの程度予測されるかは不明です。第二に、そのような研究は通常、ソフトウェアの再利用やコードベースの複雑さなどの開発者固有の要因から抽象化されます[48]。したがって、開発者の生産性を予測することを可能にする要因を理解する上で、文献にはギャップがあります。このギャップを埋めることは実用的です。生産性を向上させるために、3社に3つの研究チームを編成しました。この知識のギャップを埋めることは、チームが調査し、企業が開発者の生産性に投資するのに役立ちます。

6.結論

開発者の生産性に影響を与える要因はたくさんありますが、組織は生産性の向上に集中するためのリソースが限られています。さまざまな要因をランク付けして比較するために、3つの企業で調査を作成して実施しました。開発者とリーダーは、私たちの調査結果を使用して、取り組みに優先順位を付けることができます。簡単に言うと、以前の論文では、ソフトウェア開発者の生産性を向上させる多くの方法が提案されており、それらの方法に優先順位を付ける方法を提案しました。

質問のブロック

開発者の生産性を高めるものは何ですか？

この1ページの匿名の調査には、15分かかり、開発者の生産性に影響を与えるものをよりよく理解するのに役立ちます。率直かつ正直に答えてください。



調査では、あなた、あなたのプロジェクト、およびあなたのソフトウェアについて質問します。覚えておいてください：



私のソフトウェアとは、製品やインフラストラクチャなど、ABBで開発するコアソフトウェアを指します。別のプログラムで作業している場合は、メインのプログラムでのみ回答してください。



私のプロジェクトは、ソフトウェアを作成するチームに属しています。 ABBの他のソフトウェア開発者に関する関連する質問に答えてください。



いくつかの質問は、潜在的にデリケートなトピックに触れています。誰もあなたの肩越しに覗くことができないように回答を記入し、質問票に記入した後、ブラウザの履歴とCookieをクリアしてください。



次のステートメントであなたの同意を評価してください。





これらの質問は、生産性に影響を与える可能性のある要因の包括的な評価を提供するように設計されています。私たちは何かが欠けていますか？



性別（オプション）



あなたの肩書きは何ですか？（オプション）



ABBに参加したのは何年ですか？

追加資料

回答者が指摘した生産性要因

このセクションでは、回答者が自由回答形式の質問への回答で説明した要因をリストします。最初に、いくつかの新しい要因について説明し、次に、調査ですでに利用可能な要因に関連する要因について説明します。回答者のコメントを、私たちの要素を使用したコードで補足しました。ここでは、人々の答えについて話し合ったり評価したりすることはありません。また、私たちの要因に関する既存の説明を補足することもありません。

新しい要因

コメントでは、私たちの研究に反映されていない4つのトピックが提起されました。6つの回答により、混合プロジェクトチームのトピック、特にマネージャーと開発者の比率が取り上げられました。プロジェクトに十分な数の従業員がいること。そして、経営陣が製品の強力な所有権を維持できるかどうか。ある回答者は、ソフトウェアの種類（サーバー、クライアント、モバイルなど）の生産性への影響を指摘しました。別の人は、睡眠時間数などの生理学的要因の影響に注目しました。別の人は、個人の成長の機会について言及しました。

利用可能な要因

F1。 5人の回答者が職場での熱意に関連する要因について言及しました。2人は仕事の動機と認識について言及しました。1人はモラル、もう1人は気のめいるオフィスビルです。



F3。回答者のうち4人は、作業方法の選択における自律性に関連する要因を指摘しました。 1つはチームレベルでの自律性、もう1つは優れたオープンソースシステムの使用を禁止するポリシー、3つ目はチームでの特定の手法の使用を制限する会社で採用された優先事項について言及しました。



F4。ある回答者は、昇進の必要性によって決定される優先順位に限定されている労働時間のスケジュールの自律性を指摘しました。



F5。 3人の回答者はリーダーシップ能力に言及した。 1つは一貫した戦略によるリーダーシップ、2つ目は経営陣から受け継がれた相反する優先順位、3つ目は従業員の生産性の管理について言及しました。



F6。 8人の回答者が正確な情報を提供したと述べた。 3つは、ドキュメント（およびその他のチャネル）を介したチーム間のコミュニケーションについて言及し、2つは、チームの目標と計画の明確な定義について言及しました。



F7。 2人の回答者は、チームとチームの結束に照らして、同僚に対して前向きな気持ちを示しました。



F8。ある回答者は、仕事をする上での自律性を指摘しました。会社の方針は、どのリソースを使用できるかを規定しています。



F9。ある回答者は、チームメートの個人的な習慣が社会的規範に反していることを示す紛争解決に言及しました。



F10。 4人の回答者が開発者の能力に注目した。 1つはコードを理解することの難しさ、もう1つは主題分野の知識、3つ目はテストに対する態度の深刻さについて言及しました。



F11。ある回答者は、仕事の生産性に関するフィードバックを指摘しました。同僚や経営陣からの認識の獲得、昇進です。



F12。ある回答者は、「私の頭脳から出荷された製品への」ソフトウェア実装の複雑さを指摘しました。



F13。 2人の回答者は、さまざまなタスク、特にチームに代わってタスクを傍受することとコンテキストの切り替えに注目しました。



F14 4人の回答者が、要件とアーキテクチャの担当者を有能であると評価しました。 1つは問題への不十分な注意、もう1つはアーキテクチャドキュメントの読みやすさ、3つ目はプロジェクト計画の品質、4つ目は「要件の開発における適切なサポート」の存在について言及しました。



F15。 32人の回答者が最良のツールとアプローチを使用していると報告しました。 12は、ツールのパフォーマンス、特にビルドとテストでの速度と遅延の問題について言及しました。 5人が利用可能な機能について言及し、3人が互換性と移行の問題について言及し、2人が利用可能な最高のツールでさえニーズを満たさない可能性があると述べました。ツールとアプローチに関する他のコメントでは、ツールによって提供される自動化のレベルについて言及しています。専用のデバッガーとシミュレーター。アジャイルアプローチ;不安定なテストと関連ツール。リモートでうまく機能するツール。プログラミング言語の選択;古いツール。ツールの個人的な好みを会社で採用されているものから分離する。



F16。 19人の回答者は、人々の間で知識が適切に伝達されていると述べました。 9人が他のチームとのコミュニケーションの難しさについて言及しました。3つはチーム間で目標を合意し、1つは大規模なチーム内で目標を合意し、もう1つはチーム間で合意に達します。 2人は、国際チームまたはタイムゾーンチームで作業を調整することの難しさを指摘しました。別の2人は、他のチームの文書に依存する必要性について言及しました。 2人がコードレビューの期間についてコメントしました。他の2人は、チームメートの作業施設の認識について言及しました。 1つは適切な人物の検索について言及し、もう1つは相互作用の遅れ、3つ目は対象分野のエンジニアと専門家の間のコミュニケーションについて言及しました。最後に、それを明確にすることの重要性について言及しました特定の状況でどの通信チャネルを使用するのが適しているか。



F18。 2人の回答者は、会議を開催するためのアプローチに言及し、1人は、会議の有効性は会議室の利用可能性に依存すると述べました。



F19。 24人の回答者は、仕事の中断と気晴らしに気づきました。 10人は騒がしい環境について言及し、7人はオープンオフィスが生産性を低下させることを示しました。マルチタスクとコンテキスト切り替えに関する4つの問題について言及しました。別の4人は、主な仕事または面接などの「オプションの」タスクに集中する必要があると報告しました。 2人は、仕事に出入りするときに集中するのが難しいと述べました。



F25。ある回答者は、コードの再利用について指摘し、2〜3行のAPIは、重複の削減への貢献を最小限に抑えて複雑さを増すと指摘しました。



F26。ある回答者は、ソフトウェアプラットフォームの経験についてコメントし、開発者がプロ​​ジェクトを切り替えると問題が悪化することを示しました。



F27。 3人の回答者は、ソフトウェアアーキテクチャとリスク削減に言及しました。ある人は、「製品アーキテクチャがどれほどよく知られているか、それがどのように相互接続されているか、そしてそれが彼らの役割を知っていて集中できる人々、彼らの責任と制限を知っている人々、そして彼らが所有するものをどのようにサポートするか」を指摘しました。別の人は、アーキテクチャは、モジュール性を通じて、ソフトウェアコンポーネント間の交換を容易にすることができると述べました。 3つ目は、アーキテクチャが組織の構造と一致している必要があることを示唆しました。



F32。 4人の回答者がコンテキスト切り替えの必要性について言及しました。 2人は、プロジェクト間を移動するときに切り替えが必要であると述べました。コンテキストスイッチの必要性は、スイッチの喜びとは異なると説明されました。別の人は、「生産性プロジェクト」自体が生産性を低下させる可能性があると述べました。



F34。 5人の回答者は締め切りが厳しいと述べた。 1つは、これが技術的債務の増加に寄与することを指摘し、もう1つは、そのような期限がリソースの浪費につながる可能性があることを指摘しました。



F42。 3人の回答者がソフトウェアの制限に言及しました。 2つはプライバシー制限を指摘し、1つは重大なセキュリティ制限を指摘しました。



F44。11人の回答者がソフトウェアの複雑さを指摘しました。2つはレガシーコードの特定の複雑さについて言及し、2つは技術的負債について言及し、それぞれがバージョン管理、ソフトウェアメンテナンス、および



コードの理解について言及しました。

Coefficients:
Estimate     Std. Error     t value     Pr(>|t|)
(Intercept)             2.786969     0.111805     24.927     < 0.0000000000000002 ***
log(lines_changed + 1)     0.045189     0.009296     4.861         0.00000122 ***
level                 -0.050649     0.015833     -3.199     0.00139 **
job_codeENG_TYPE2         0.194108     0.172096     1.128         0.25944
job_codeENG_TYPE3         0.034189     0.076718     0.446         0.65589
job_codeENG_TYPE4         -0.185930     0.084484     -2.201     0.02782 *
job_codeENG_TYPE5         -0.375294     0.085896     -4.369     0.00001285 ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.8882 on 3388 degrees of freedom
Multiple R-squared: 0.01874, Adjusted R-squared: 0.017
F-statistic: 10.78 on 6 and 3388 DF, p-value: 0.000000000006508

図：5：モデル1：完全な線形回帰の結果

Coefficients:
Estimate     Std. Error     t value     Pr(>|t|)
(Intercept)                 2.74335     0.09706     28.265     < 0.0000000000000002
log(changelists_created + 1)     0.11220     0.01608     6.977         0.00000000000362
level                     -0.04999     0.01574     -3.176     0.00151
job_codeENG_TYPE2             0.27044     0.17209     1.571         0.11616
job_codeENG_TYPE3             0.02451     0.07644     0.321         0.74847
job_codeENG_TYPE4             -0.21640     0.08411     -2.573     0.01013
job_codeENG_TYPE5             -0.40194     0.08559     -4.696     0.00000275538534
(Intercept)                 ***
log(changelists_created + 1)     ***
level                     **
job_codeENG_TYPE2
job_codeENG_TYPE3
job_codeENG_TYPE4             *
job_codeENG_TYPE5             ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.885 on 3388 degrees of freedom
Multiple R-squared: 0.02589, Adjusted R-squared: 0.02416
F-statistic: 15.01 on 6 and 3388 DF, p-value: < 0.00000000000000022

図：6：モデル2：完全な線形回帰の結果

Coefficients:
Estimate     Std. Error     t value     Pr(>|t|)
(Intercept)                 2.79676     0.11141     25.102     < 0.0000000000000002
log(lines_changed + 1)         -0.01462     0.01498     -0.976     0.32897
log(changelists_created + 1)     0.13215     0.02600     5.082         0.000000394
level                     -0.05099     0.01578     -3.233     0.00124
job_codeENG_TYPE2             0.27767     0.17226     1.612         0.10706
job_codeENG_TYPE3             0.02226     0.07647     0.291         0.77102
job_codeENG_TYPE4             -0.22446     0.08452     -2.656     0.00795
job_codeENG_TYPE5             -0.40819     0.08583     -4.756     0.000002057
(Intercept)                 ***
log(lines_changed + 1)
log(changelists_created + 1)     ***
level                     **
job_codeENG_TYPE2
job_codeENG_TYPE3
job_codeENG_TYPE4             **
job_codeENG_TYPE5             ***
---
Signif. codes: 0 `***` 0.001 `**` 0.01 `*` 0.05 `.` 0.1 ` ` 1
Residual standard error: 0.885 on 3387 degrees of freedom
Multiple R-squared: 0.02616, Adjusted R-squared: 0.02415
F-statistic: 13 on 7 and 3387 DF, p-value: < 0.00000000000000022

図：7：モデル3：完全な線形回帰の結果。