プログラミングの生産性

プログラミング生産性(ソフトウェア生産性または開発生産性とも呼ばれる) は、個々のプログラマーまたは開発チームがソフトウェア システムを構築および進化させる能力の度合いを表します。生産性は、伝統的に、作成されたソフトウェアの量とそれに費やされたコストの比率を指します。ここでの微妙な点は、ソフトウェアの量を定義する適切な方法を見つけることです。

生産性は、製造、組織心理学、産業工学、戦略管理、財務、会計、マーケティング、経済学など、さまざまな分野で研究されている重要なトピックです。分析のレベルには、個人、グループ、部門、組織、国家レベルが含まれます。^[1]この多様性のため、1 世紀以上にわたって研究が行われてきましたが、生産性とその影響要因の明確な定義はありません。ソフトウェア エンジニアリングと同様に、生産性の実際の構成要素に関する共通の合意が欠如していることが、生産性に関する実証的な議論の大きな障害であると認識されています。^[2]次の定義は、用語に関する最良のコンセンサスを示しています。^[3]

生産性の定義については一般的に合意されたものはありませんが、生産性は出力と入力の比率を表すという点では合意があるようです。

生産性 = 出力 / 入力

しかし、さまざまな分野にわたって、異なる概念、特に入力と出力の測定単位が異なります。製造業では通常、生産されたユニット数と消費されたユニット数の間に単純な関係を使用します。^[4] 非製造業では通常、出力と入力を比較できるように工数または同様の単​​位を使用します。

基本的な合意事項の一つは、生産性の意味とそれを測定する手段は、評価対象となる状況によって異なるということである。製造業の場合、考えられる状況は以下のとおりである。^[3]

• 個々の機械または製造システム。
• 製造機能、例えば組み立てなど。
• 単一の製品または関連製品グループの製造プロセス。
• 工場;そして
• 同社の工場システム全体

古典的な生産プロセスについて言えば、生産性の直接的な指標は単純です。つまり、指定された品質の製品がどのくらいのコストで何ユニット生産されたかということです。知的労働の場合、生産性ははるかに複雑です。著者、科学者、エンジニアの生産性をどのように測定するのでしょうか?知識労働(手作業ではなく)の重要性が高まっているため、^[5]多くの研究者が製造業以外の状況に適用できる生産性測定手段の開発を試みました。知識労働の性質は手作業とは根本的に異なるため、単純な出力/入力比以外の要素、たとえば品質、適時性、自律性、プロジェクトの成功、顧客満足度、革新性を考慮する必要があることは一般に認められています。ただし、どちらの分野の研究コミュニティも、生産性測定に広く適用可能で受け入れられる手段をまだ確立できていません。^[1]プログラミング生産性のより具体的な領域についても同じことが言えます。

収益性と業績は密接に関連しており、実際には混同されることが多い。しかし、収益性は通常、収益とコストの比率として定義されるため、

収益性 = 収益 / コスト

収益性はパフォーマンスよりも範囲が広く、つまり収益性に影響を与える要因の数は生産性に影響を与える要因の数よりも多いのです。特に、コストや価格のインフレなどの外部条件により、生産性が変化しなくても収益性が変化することがあります。さらに、生産性と収益性の相互依存性は通常遅れて現れます。つまり、生産性の向上がすぐに収益性に反映されることはめったになく、長期的に実現される可能性が高くなります。

パフォーマンスという用語は、生産性や収益性よりもさらに広義で、企業の成功に影響を与える多数の要因を網羅しています。したがって、バランスト スコアカードなどのよく知られたパフォーマンス管理ツールには、生産性が中心的ではあるが唯一の要素ではない要因として含まれています。その他の関連要因としては、たとえば、顧客や利害関係者の企業に対する認識などがあります。

効率と有効性は、それ自体が混同されることが多く、さらに効率が生産性と混同されることも多いため、さらに混乱を招く用語です。効率と有効性の違いは、効率は物事を正しく行うこと、有効性は正しいことを行うことと、非公式に説明されるのが一般的です。他にも多くの定義がありますが、^[3]効率はリソースの利用を指し、主に生産性比率の必要な入力に影響を与えるという点では一定の合意があります。一方、有効性は、通常、顧客に直接影響を与えるため、主に生産性比率の出力に影響を与えます。有効性は、「望ましい出力に到達する能力」と定義できます。

一般的に、効率は有効性よりも、例えば利用率によって定量化するのがかなり簡単だと考えられています。

タンゲンは「欠陥のない製品が生産量を増やすという事実以外、品質の向上は生産性の概念に含めるべきではない」と述べている。^[3] しかし、ソフトウェア以外の分野、特に製造分野の古典的な文献のほとんどは、生産性比率における生産量の品質の役割について明示的に議論していない。^[6]製造以外の分野からの最近の研究は、知識、オフィス、またはホワイトカラーの仕事に重点が置かれており、品質に関する品質の役割について議論することが増えている。^{[5] [1] [7] [8] [9]}

ドラッカーは、知識労働者の生産性を評価する上で品質の重要性を強調している。「したがって、知識労働の生産性は、まず品質の獲得を目指す必要がある。最低品質ではなく、最高品質ではないにしても最適な品質である。そうして初めて、「仕事の量、量は何か」と問うことができる。」^[5]

サーリは生産性に関する拡張された公式で品質の重要性を捉えている。^[8]

総生産性 = (出力品質と量)/(入力品質と量)

しかし、生産性の決定に品質を含めるというこれらの取り組みは、まだ運用可能な概念には至っていないようです。現在のところ、「出力の品質と量」と「入力の品質と量」という曖昧な用語を定量化する方法はもちろん、比率を計算する方法も不明です。

ソフトウェア開発では、商品の製造よりも物事が複雑になります。ソフトウェア開発はエンジニアリング プロセスです。

ボームは、ソフトウェア生産性の分野に体系的にアプローチした最初の研究者の一人です。彼のコスト見積もりモデルCOCOMO (現在は COCOMO II ^[10] ) は、標準的なソフトウェアエンジニアリングの知識です。このモデルでは、必要な信頼性やアナリストの能力など、生産性に影響を与える一連の要因を定義しています。これらの要因は、他の同様の生産性アプローチで広く再利用されています。モデルの残りの部分は、機能ポイントと、最終的にはソースコード行(LOC) に基づいています。生産性の尺度としての LOC の限界はよく知られています。

ジョーンズはソフトウェア生産性に関する一連の本の著者です。いくつかの理論的考察に加えて、彼の主な貢献は、生産性分析に関連する大量のデータを体系的に提供し、統合することです。少なくとも2冊の本^{[11] [12]}で、彼はいくつかの生産性要因を示していますが、プロジェクトごとに異なる一連の要因が影響することを指摘しています。これらの要因は、生産性評価や業界平均との比較の基礎となる可能性があります。

以下はそのようなリストの 1 つです。

過去のデータからソフトウェア プロジェクトへの定量化された影響が判明した 20 の要因は次のとおりです。

• 使用されるプログラミング言語
• プログラムサイズ
• プログラマーと設計担当者の経験
• 要件の新規性
• プログラムとそのデータの複雑さ
• 構造化プログラミング手法の使用
• プログラムクラスまたは配布方法
• アプリケーション領域のプログラムタイプ
• ツールと環境条件
• 既存のプログラムやシステムの強化
• 既存のプログラムやシステムの維持
• 既存のモジュールと標準設計の再利用
• プログラムジェネレータ
• 第四世代言語
• 開発場所の地理的分離
• 欠陥の可能性と除去方法
• 既存のドキュメント
• 主な開発が始まる前のプロトタイプ作成
• プロジェクトチームと組織構造
• 職員の士気と報酬^[12]

ファンクション ポイントは、1977 年に Albrecht によって、LOC よりも優れたソフトウェアのサイズ測定方法として提案されました。これはソフトウェアの仕様に基づいており、コード自体ではなく機能のサイズを測定することを目的としています。その理由は、コードのサイズは機能のサイズだけでなくプログラマーの能力にも左右されるからです。つまり、優れたプログラマーは同じ機能に対してより少ないコードを作成します。ファンクション ポイントは、主に国際ファンクション ポイント ユーザー グループ (IFPUG) の主導により、長年にわたって何度か再設計されてきました。このグループは 1,200 社を超える企業がメンバーとして参加する大規模なグループであり、この測定方法がかなり広く受け入れられていることを示しています。ただし、多くの分野では、ビジネス情報システムにのみ適用できると考えられているため、実用化には至っていません。

何人かの研究者は、経済主導型または価値ベースのソフトウェアエンジニアリングを、将来のソフトウェアエンジニアリング研究の重要なパラダイムとして提案しました。BoehmとHuangは、ソフトウェアプロジェクトのコストを追跡するだけでなく、実際に得られた価値、つまり顧客にとっての価値も重要であると指摘しています。^[13]彼らは、ソフトウェアビジネスケースを作成し、それを最新の状態に保つことが重要であると説明しています。本質的に、価値ベースのソフトウェアエンジニアリングは、主に金銭単位で測定される顧客価値に焦点を当てています。

de MarcoとListerによる有名な書籍「Peopleware: Productive Projects and Teams」^[14]は、人的要因の重要性をより広い読者の注目を集めました。彼らは、多くのソフトウェアプロジェクトでチームの生産性に影響を与える良い管理方法と悪い管理方法の経験を収集しました。彼らと他の人たちは、これらがソフトウェアエンジニアリングの決定的な問題であることを示しましたが、それらを逸話的にしか説明できませんでした。

個人やチームのプログラミング生産性に影響を与える要因はおそらく多数あります。たとえば、使用されるソフトウェア開発プロセスは、チームの有効性と効率に影響を与える可能性があります。

ソフトウェアプログラマーの性格は使用されるコーディングスタイルに影響を与え、それがプログラマーの生産性に影響を与えます。^[15]

2007年、xkcdコミックはバルマーピークの概念を広めた。これは、プログラマーが適度に酔うと高い生産性状態に達するというものである。バルマーピークは、元マイクロソフトCEOのスティーブ・バルマーにちなんで名付けられており、^[16]ヨハン・バルマーにちなんで名付けられた水素スペクトル線のバルマー系列にちなんだものと思われる。^[17]

• Cocomo II によるソフトウェアコスト見積もり、Barry W. Boehm他著、Prentice Hall、2000 年。ISBN 978-0-13-026692-7。 
• 『半分の時間で製品を開発する: 新しいルールと新しいツール』、Preston G. Smith と Donald G. Reinertsen、Wiley、1997 年。ISBN 978-0-471-29252-4。 
• プログラミングの生産性、Capers Jones、Mcgraw-Hill、1986年。ISBN 978-0-07-032811-2。 
• ソフトウェアコストの見積もり、Capers Jones、McGraw-Hill、2007年。ISBN 978-0-07-148300-1。