アーカイブ

  1. トップページ
  2. アーカイブ
  3. 書籍・刊行物
  4. ソフトウェア開発データ白書
  5. 「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答

「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答

規模について 工数について 信頼性について 生産性について テストについて バグ数について 基本統計量について 見積りについて アーキテクチャについて 開発対象プラットフォームについて 外部委託について 回帰式について 信頼区間について 図表の転用について 業種編について 設計書のページ数について その他
  • 「ソフトウェア開発データ白書」を、以下「データ白書」と略します。
  • 章節番号、ページ等は、データ白書2018-2019版を基準とします。

規模について

  1. Q1.「改良開発」におけるSLOC規模は、改良元の全SLOC数か？もしくは、改良した部分だけのSLOC数か？

    A1.

    データ白書の「改良開発」におけるSLOC規模は、母体の規模を含みません。
    次のように改良した部分だけのSLOC数になります。「改良開発において新規に追加した部分、変更した部分及び削除した部分を合計した規模」が改良開発の規模になります。付録A.4 「導出指標の名称と定義」の「実効SLOC実績値」に説明されています。

  2. Q2.データ白書の元となるデータを各社から収集する際、規模の考え方についてどのような基準で実施しているか？

    A2.

    SLOC/FP規模に関しましては母体規模、追加・新規規模、変更規模、削除規模に関してデータ収集しています。また、母体に関しまして、選択肢として開発規模に（含む/含まない/不明）を設けており、改良開発の場合、母体を「含まない」場合のみ、改良規模として扱う旨、説明しています。（収集項目につきましては、付録B収集フォームをご参照ください。）

  3. Q3.プログラム言語の他に定義体ファイル（xml,txtなど）やSQLなどが利用されていた場合は、プログラムと定義体・ジョブを合算し、全体の規模として考えてよいか？

    A3.

    テストの対象と思われますので、規模として含めるほうが妥当だと考えます。この場合、対象毎に、規模と、テスト項目、不良数等を分けて管理されたほうが今後のテスト密度の妥当性などの参考データとして、活用が可能と思われます。

  4. Q4.「SLOC：コメント行及び空行を含まないコード行数（SLOC）を使用する。」の意味を確認したい。(「コード行数」が示すものは、テキストファイルとしての行数の理解で合っているか？)（括弧だけの行や保守性を上げるために本来不要な改行を入れた行も1行として数える想定なのか？この測り方によって社内のPJでは2～3倍の差が出てくるが）

    A4.

    付録A　データ項目定義に記載しております。ご参照ください。
    物理行数、論理行数、言語による定義の違い等ありますが、どのように定義するかは各社で取り方が異なります。統一はできないため、各社の方針に任せております。しかし、大体は物理行になっているようです。
    なお、空行やコメント行の率は5％刻みですので、結果それほど精緻な表現になっていません。

工数について

  1. Q1.生産性の実績値を収集する場合の工数として直接的な「アプリ開発」以外の工数はどこまで含めるべきか？また、データ白書のデータはどこまでを含んでいるのか？（例えば基盤構築工数(H/W調達・設置、M/Wインストール）、処理方式設計工数、PMO工数など。）

    A1.

    「どの範囲の工数までを含めるべきか」については、何の生産性を見ようとするかという目的によって変わるので、一概に申し上げられません。データ白書では、開発にフォーカスしており、開発5工程（基本設計、詳細設計、製作、結合テストおよび総合テスト（ベンダ確認））の工数を用いて生産性を見ています。（現状、基本設計より前の要件定義等や、総合テスト（ベンダ確認）より後の作業については含まれません。）ご質問の方式設計については、基本設計に含まれます。プロジェクト管理、PMOおよび品質保証に関する工数については、開発の中に含めて計上されるケースや管理として外出しにして計上されるケースがあるようですが、いずれにしろ基本的には各工程の全体工数に含まれます。基盤構築については、テスト用インフラ構築をテストに含めるなど、基本的には含まれているはずです。ただし、前のプロジェクトで構築した環境を受け継いで利用するプロジェクトでは計上されないなど、プロジェクトによって差があると見ています。

  2. Q2.データ白書内のFPやLOCの生産性には間接費用も含まれているのか？

    A2.

    プロジェクトに関する費用は含まれるが、間接部門の人件費など一般管理費と呼ばれるような間接費は含まれていないという認識です。プロジェクトに関する費用とは、具体的にはデータ白書付録A.2「データ項目定義」記載のある、（9）工数（コスト）のうち、社内実績工数の（C）その他に記載のある、テスト環境構築、インフラ構築、運用構築、移行、業務支援、コンサルティングなどに該当する作業です。また、それ以外としては、付録A.4「導出指標の名称と定義」にあるように工程別では工程配分不可分があります。

  3. Q3.「（人時への変換は1人月＝160時間を代用）」はどのような意味であり、どこに反映されているものなのか。

    A3.

    1人月あたりの工数を人時で表す場合、特に指定がなければ1人月＝160人時とすることを示しています。160人時の根拠は、8時間/日＊20日/月です。また、人月の値は、人月単位での値を示す場合に使用しています。

  4. Q4.「SLOC／人時」を「人月／KLOC（1人月＝120h）」と比較するとした場合、この値をどのように換算すればよいか？

    A4.

    値をA[SLOC/人時] とすると
    A[SLOC/人時] ☓ 120[人時/人月]÷1000[SLOC/KSLOC]＝ 120A/1000［KSLOC/人月]　逆数をとって
    1000/120A[人月/KSLOC]となります。
    単位系で考えるとわかりやすいと思います。

信頼性について

  1. Q1.「主要開発言語別不具合数の基本統計量(新規開発)」の単位は件/KSLOCか？

    A1.

    「主開発言語別発生不具合数の基本統計量(新規開発)」は、（規模で正規化していない）発生不具合数に関する基本統計量です。その単位は「件」であり、1KSLOC当たりの発生不具合件数（「件／KSLOC」)ではありません。1KSLOC当たりの発生不具合件数（「件／KSLOC」)については、 「主開発言語別SLOC発生不具合密度の基本統計量(新規開発)」をご覧ください。

生産性について

  1. Q1.データ白書上で、新規開発と改良開発の生産性を同一式としているのはなぜか？

    A1.

    データ白書では新規開発、改良開発共通に、
    SLOC生産性　＝　実効SLOC実績値÷実績工数（開発5工程）
    　　　　　　　　実効SLOC実績値には、母体規模を含めない。
    で導出しています。
    新規開発と改良開発の生産性を同一メトリクスとしているのは、主に今までの統計情報と連続性を保ちたいことと、モデル化が悩ましいことからです。現行メトリクスでは改良開発の方が新規開発のSLOC生産性よりも低く出る傾向があります。これは、一般にテストにおいて母体のリグレッションテストを実施していることから、分母の実績工数に母体のリグレッションテストの工数が加算されることなどによる影響と考えています。

    一方改良開発の見積り工数の妥当性評価において、現行の統計情報を参考にするのはラフ過ぎないか、他により良いメトリクスがあるのではないかという問題は、弊方でも認識しており今後の検討課題としています。
    また、改良開発に限らず、パッケージやOSSを利用した流用開発、再構築、ネットワーク基盤開発などの開発スタイルが近年増えているトレンドを踏まえると、現行SLOC生産性のメトリクスでは見積り工数や計画生産性の妥当性評価に適合しないケースがますます増えて来ていると存じます。これらのことから、新しい開発スタイルを含めたスコープで、生産性のメトリクスを改良することが今後の検討課題と認識しています。

  2. Q2.改良開発の生産性について、生産性算出式の分母である「実績工数（開発5工程）」から母体にかかる作業工数（デグレード試験等）を減算するというアプローチはIPA内部での検討対象になっているか？

    A2.

    改良開発において、下記の新規開発部分以外にかかる作業工数を減算するアプローチは、現在検討対象にはしていません。実際に生ずる可能性の高い作業なので、減算するよりもどう勘案するかの方が検討課題と考えています。

    なお、現状では、作業工数をこれらのような要素別には収集していませんので、現行データから分析するのは無理な状況です。

    • 母体のレグレッションテスト
    • 母体の調査作業（仕様、品質レベルの把握等）
    • 母体の品質向上作業（母体の品質が良くない場合）など

    なお、現状では、作業工数をこれらのような要素別には収集していませんので、現行データから分析するのは無理な状況です。

  3. Q3.生産性の評価をする際、あくまでプログラムの修正規模をベースとする方法は、データ白書の活用方法として適切か？

    A3.

    改良開発の場合、流用部分の試験工数や、変更部分の難易度を踏まえた生産性を考慮すると、単純に、改良規模（追加・新規＋変更＋削除規模）で評価すると、新規開発に比べ、生産性も、信頼性も低く評価されてしまうと言うのは事実です。しかし、統一された考え方がない現状では、上記を踏まえた値として評価するのも、一つのデータの捉え方であると考えます。
    なお、本件につきましては、IPA 社会基盤センター内でも議論中であり、対策を検討中です。例と致しましては、母体規模、新規規模、変更規模、削除規模と工数の関係を重回帰分析してどのような傾向が見られるかなど、分析予定です。

  4. Q4.試験工程の生産性を評価する際、プログラムの修正箇所以外の規模を考慮しようとした場合、データ白書で参考にできる記載箇所はあるか？

    A4.

    母体部分の試験工数として考えた場合、標準的な試験工数は一つの目安となると考えます。但し、母体部分の場合、いわゆるリグレッション試験となりますので、通常（新規開発部）よりも不具合対策工数が少なくなる分、工数は少なくなると想定されます。

  5. Q5.工程別生産性の最も低い中央値が、トータル生産性 の中央値より大きくなるのは何故か？また、生産性の評価に用いる場合、一般的にはどちらの数字を用いるのがベターか？

    A5.
    1. それぞれの生産性の計算は、
      工程別の生産性　＝　全体のFP/各工程の工数　　トータルの生産性＝　全体のFP/トータル工数となります。
      ここで、各工程の工数＜トータル工数ですので通常は、工程別の生産性 ＞トータルの生産性となります。
    2. まずは、全体としての生産性評価をしたうえで、各工程別での評価をすることをおすすめします。なお、この際、生産性＝FP/工数であることから、各工程の生産性の差は結局は、各工程の工数の差であることに留意して、各プロジェクトの特性によって生じる各工程の工数差を考慮した評価が必要と考えます。

  6. Q6.「工程別分析の章」で集計されている生産性の元となるデータと「生産性分析の章」で集計されている生産性の元となるデータは、同一のデータを集計しているのか？

    A6.

    「工程別分析の章」の工程別の生産性と「生産性の分析の章」の生産性はサンプル集合が異なります。
    「工程別分析の章」では、工程間の比較を行う必要があることから、層別定義に「開発5工程のフェーズ有無がすべて○」という条件を付けています。
    これは、開発5工程のすべてに工数が記入されていることを意味します。
    一方、「生産性の分析の章」では、層別定義に「開発5工程のそろっているもの」という条件を付けています。これは、開発5工程のすべてに工数が記入されている必要はなく、例えば基本設計工数と詳細設計工数をまとめて詳細設計工程に計上するようなケースを許容しています。具体的には、「開発5工程のフェーズ有無が○又は⇒ 」を意味しています。開発5工程が存在していて、その合計工数を算出できればSLOC生産性等を導出できることと、できるだけサンプル数を多く確保したいという趣旨で、このようなゆるい条件を設定しています。

テストについて

  1. Q1.総合テストとは、単体テスト・結合テスト・ユーザ確認テストを除くシステムテスト分類（FT・SD・CT・RT・PT・VT・DR・DT）が集計されているという理解でよいか？

    A1.

    各略語の意味と定義が不明のため、直接の回答にはなりませんが、所謂システムテストのうち、ベンダ側主体で実施するテストを総合テスト（ベンダ確認）と呼んでいます。

  2. Q2.同じテストを端末やテスト用IDなどの条件を変えて実行する場合、テストケース数は、テストを実行した数と考えればよいか？

    A2.

    端末や条件を変えて確認することの意味を考えれば「テストを実行した数」と考えるのが妥当です。

  3. Q3.データ白書のユニットテストについての考え方を教えてほしい。

    A3.
    1. ユニットテストの実施工程について
      データ白書の付録A.1「工程の呼称とSLCPマッピング」にあるように、ユニットテストは製作工程に含まれています。
    2. ユニットテストの統計情報について
      ユニットテストのテスト項目数、テスト密度、バグ密度等も、結合テストや総合テストと同様にデータ収集・分析するのが望ましいと考えます。ただし、データ白書の現状では、製作工程におけるユニットテスト（モジュールテスト等）においては、テスト項目数やバグ数をどのようにカウントするのかという標準化の問題があることと、データ収集・報告できる企業が少ないという認識から、データ収集・分析できていません。なお、各企業内においては、標準化・ルール化が可能でしょうから、データ収集・分析することをお勧めします。

  4. Q4.総合テストの実施範囲については、性能・障害時等の非機能要件に関するテスト、及び外部システムとの接続テスト、改良開発時の母体機能のノンデグレード確認テストの範囲と考えてよいか？

    A4.

    総合テストの実施範囲については、何かを除外することは規定していません。性能等の非機能要件に関するテスト、外部システムとの接続テスト、母体のリグレッションテストも含まれます。

  5. Q5.改修SLOCと直接関連性がないように思われる総合やデグレード試験のテストケース数やバグ数も含まれているか？

    A5.

    改修開発での作業には、総合試験や、デグレード試験が含まれるため、開発データにはそれらの工数、テストケース数、不良数も含まれます。 よって、改修開発は、新規開発と比べ、通常、変更規模あたりの生産性や、品質が（一見）悪くなる傾向にあります。

バグ数について

  1. Q1.検出バグ数（現象）、（原因）の各定義はどうなっているか？参考数値として使う場合に、どちらを使えば良いか？

    A1.

    「現象数」は運用時やテスト実施時において想定と異なる形で発現した事象（不具合現象）の件数をいい、「原因数」は不具合現象を引き起こしたソフトウェアの誤り（不具合原因）箇所の件数です。通常、試験工程において不具合が検出された場合、まず、不具合の現象毎に記録し、その後不良の原因を分析して必要な対策をとるという流れになると考えます。この場合、一つの原因から様々な現象が発生する場合や、逆に様々な原因が重なって、ある現象が発生する場合があります。そこで不具合を管理する場合は、「現象別」での管理（カウント）と「原因別」での管理（カウント）の2種類が考えられます。そのため、「検出バグ数」として、それらを区別して管理（カウント）しています。どちらの値を参考値とするかは、御社での不具合のカウント方法（現象別、原因別）に依存します。因みに、不具合は、本来は「原因別」で管理されるべきであると考えます。よって、データ白書では、「原因数」がある場合は、「原因数」を優先して使用しています。

基本統計量について

  1. Q1.工程ごとの中央値の欄を全て合計しても1．0（100％）にならないのはなぜか？

    A1.

    工程ごとの平均値合計は、必ず1になりますが、中央値の合計は必ずしも1にはなりません。中央値は、あくまでも真ん中の値であり、それぞれの工程の真ん中の値を足してもかならずしも1になるとは限りません。

  2. Q2.データ白書内に記載している基本統計量「平均値」および「標準偏差」は、外れ値を含めた値という認識で合っているか？

    A2.

    はい、全データが対象です。

  3. Q3.データ白書の平均値算出について、例えば、SLOC 検出バグ密度（件／KSLOC）の平均を求める場合、以下の2つの指標値から求めるやり方があるがデータ白書ではどのやり方か？ （1）各SLOC 検出バグ密度を平均 （2）各SLOCの合計とバグ件数の合計から算出 弊社では社内実績の平均を出す場合、通常（2）を使用しているが、一般的なやり方はどちらか？

    A3.

    データ白書では、1）のやり方を採用しています。
    一般的にはどうかという観点では、単に平均値を求めたいだけであれば、目的や考え方によって1）（単純平均又は相加平均に相当）2）（加重平均に相当）の両方がありうると思います。
    上記のSLOC 検出バグ密度の場合、2）は規模の重みを付けた加重平均に相当するので、規模の大きなプロジェクトのSLOC検出バグ密度に寄った平均値になります。　平均値に重みを反映した方が良いかどうかは、分析の目的によると考えられます。

    データ白書では、次のことを重視しており、特に平均値を代表値として重視している訳ではありませんので、素直に単純平均（相加平均）を採用しています。

    • 各メトリクス／指標について、代表値を知りたいだけでなく分布の姿も見たい（基本統計量の表、箱ひげ図、散布図などによって）。また、その分布に対して影響を与える変動要因を探りたい。
    • 基本統計量の中で、代表値として重視しているのは中央値です。平均値は、基本統計量の一つにすぎません。（多くのメトリクス／指標の分布は右裾広がりの分布になっており、標準偏差が大きく正規分布とは程遠いものになっています。平均値は右裾の方の大きな値に強く影響されるので、代表値としては適当ではありません。）

見積りについて

  1. Q1.自社のアプリケーション開発の見積り工数の妥当性を評価するためのデータ白書の利用方法や考え方、注意点などについて教えてほしい。

    A1.

    IPA 社会基盤センターでは、データ白書や個々の企業が持つ内部ベンチマーク（*1）情報を活用した「定量的管理による信頼性向上のヒントや具体的な改善事例集、または品質マネジメントのための具体的なベンチマーキング（*2）方法の手引き」として、「統計指標に基づく品質マネジメント実践集」を作成し、公開しています。
    その中で、「プロジェクト計画の妥当性評価」として、見積りへの適用例を解説しています。詳しくは、下記ページをご参照ください。

    1. （*1）
      ベンチマーク：「特定のITプロジェクトのパフォーマンスが、組織内外のITプロジェクトと比較して どのレベルに位置するかを評価するため、比較対象として利用する組織内外の参照情報」
    2. （*2）
      ベンチマーキング：「良い成績を収めているプロジェクト群と比較し、それらのやり方（開発プロセス、マネジメント・プロセス、組織の特性等）を参考にして、自組織の業務改善及び組織の改善を進めること。」

アーキテクチャについて

  1. Q1.アーキテクチャについて、定義が記載されている資料はあるか？

    A1.

    定義が記載されている資料は、ありませんがそれぞれの定義は以下の通りです。

    a.スタンドアロン

    通信機能を介して他の機器や通信ネットワークと接続せずに、孤立した状態で使用するシステム。（他のソフトウェアの機能に依存せず、単体で実行・利用可能であるシステム。）

    b.メインフレーム

    企業の基幹業務システムなどに用いられる大型のコンピュータシステム上で稼働するシステム。

    c.2階層クライアント／サーバー

    クライアントとサーバーで分散して処理をするシステム。（クライアントが直接DBハンドリングする）

    d.3階層クライアント／サーバー

    ライアントとサーバーで分散して処理をするシステム。（DBサーバー経由でDBをハンドリングする）

    e.イントラネット／インターネット

    TCPの上位にHTTPプロトコルを採用している方式であり、WEBブラウザを端末に搭載しているシステム。

開発対象プラットフォームについて

  1. Q1.開発対象プラットフォームの選択肢について、Windows7・Windows8・WindowsServer2008の場合、それぞれ、b：WindowsNT/2000/XP系、c：Windows Server2003で分類してよいか？それとも、s：その他OSとしたほうがよいのか？

    A1.

    開発プラットフォームの区分に関しましては、データ白書2018-2019版から以下の区分となっています。「a：Windows（PC系）、b:Windows（サーバ系）、c：UNIX系、d:Linux系、e:BSD系、f:メインフレーム系、z:その他」 よって、Windows7、Windows8は、a:Windows（PC系）、WindowsServer2008は、b:Windows（サーバ系）となります。

外部委託について

  1. Q1.「外部委託」とありますが、下記のどの開発形態が当てはまるのでしょうか？(1)自社オフィスにて他社社員が開発(2)他社オフィスにて他社社員が開発(3)その他準委任で自社要員として作業している場合は、外部委託では無いということか？

    A1.

    外部委託とは、外部に開発を委託しているケースです。委任、請負契約などで開発の仕事を委託しているケースです。 仕事内容でなく、自社要員として派遣されているケースは含みません。社内、社外など作業場所は関係ありません。（契約で取り決めている開発場所となります。） "ユーザ側の一員（自社要員）として活動している場合は、対象外です。要件定義、基本設計など準委任契約でベンダ側のプロジェクトの一員として活動している場合は対象となります。

回帰式について

  1. Q1.開発5工程の工期は、どのように算出すればよいか？

    A1.

    データ白書では、工期は工数の0.32乗に比例する傾向があり、中央値はその回帰式で算出できます。「工期は工数の3乗根に比例する傾向が見られる」という趣旨については、次のようにご理解ください。

    • 回帰式の0.32乗という値は、サンプルデータに依存するものであり、サンプルデータの追加等によって揺らぐ可能性が高い。
    • 3乗根（立方根）は1/3乗（0.33333...）なので、「0.32乗に比例する」の概数として「3乗根（立方根）に比例する」と理解すれば、サンプルデータによる揺らぎや他の調査レポートとの細かな違いを気にしなくて済む。また、覚えやすいし計算しやすい。

    当データ白書の回帰式をご参考にされる場合、まず3.4節「回帰式利用上の注意事項」をご覧頂きたいと存じます。

信頼区間について

  1. Q1.データ白書にある50%や95%の信頼区間とはどういうものか？

    A1.

    データ白書では、予測値の50%及び95％の信頼区間（＝予測区間）になっています。
    実測値から求めた平均値（推測値に対応する回帰直線上の値）の信頼区間ではありません。
    この信頼区間の詳細については、SEC journal 第28号（2012年3月30日発行）に掲載の「エンタプライズ系ソフトウェアプロジェクトにおける層別生産性とその信頼区間」で紹介しております。

図表の転用について

  1. Q1.データ白書掲載の図表データの転載について条件を知りたい。

    A1.

    データ白書に掲載されている図表を、書籍出版や、他社提案、論文などに引用される場合は、下記の条件を厳守いただきご活用ください。ご参考までにどういう活用方法をされるのかご連絡いただければありがたいです。

    E-mail：
    ikc-infoアットマークipa.go.jp
    • オリジナルの内容を改変しない。
    • 転載元を明示する。
    • 「再転載不可」、「引用不可」とする。

    詳細は使用条件をご確認ください。

    使用条件

    PDFデータ版について

    1. 本資料の著作権は、独立行政法人情報処理推進機構が保有しています。
    2. 本資料は著作権法による保護を受けており、本資料の使用者は、本資料の全部又は、一部を項番3に定める場合を除き、独立行政法人情報処理推進機構の許諾なく無断で改変、公衆送信、販売、出版、翻訳/翻案することは営利目的、非営利目的に関わらず禁じられています。
    3. 独立行政法人情報処理推進機構は、本資料の使用者が、以下の著作権表示を明記することを条件として、（1）及び、（2）の行為を行うことを許諾します。
      著作権表示：「Copyright ○○○○（発行年） IPA」
      （1）本資料の全部又は、一部を複製すること。
      （2）本ページに記載されている使用条件を配布先に遵守させることを条件に本資料の複製物を無償で再配布すること。
    4. 独立行政法人情報処理推進機構は、本資料が第三者の著作権、特許権、実用新案権等の知的財産権 に抵触しないことを一切保証するものではなく、また、本資料の内容に誤りがあった場合でも一切責任を負いかねます。
    5. 独立行政法人情報処理推進機構は、本ページで記載された許諾内容を除き、独立行政法人情報処理推進機構又は、第三者の著作権、特許権、実用新案権等の知的財産権に基づくいかなる権利を許諾するものではありません。
    6. 独立行政法人情報処理推進機構は、本資料のシステム開発への利用、開発されたシステムの使用及び、当該システムの使用不能等により生じるいかなる損害についても、なんら責任を負うものではありません。
    7. 本資料を海外へ持ち出す場合及び、非居住者に提供する場合には、「外国為替及び、外国貿易法」の規制及び、米国輸出管理規則等外国の輸出関連法規を確認の上、必要な手続きを行ってください。
    8. 本使用条件の解釈は日本国法に準拠するものとし、本資料の利用に関して法的紛争が生じた場合は、東京地方裁判所を唯一の合意管轄裁判所とします。
    9. 本資料へのお問い合わせについては、独立行政法人情報処理推進機構 社会基盤センターまでご連絡ください。

    グラフデータについて

    1. 本グラフデータの著作権は、独立行政法人情報処理推進機構が保有しています。
    2. 独立行政法人情報処理推進機構は、以下の著作権表示を明記することを条件として、「本グラフデータの全部又は一部を複製、改変、公衆送信、又は翻訳/翻案し、第三者に有償又は無償で再配布すること」を許諾します。
      著作権表示：「Copyright ○○○○（発行年） IPA」
      なお、複製し再配布する場合は本使用条件を添付し、本使用条件に記載されている条件を配布先に遵守させてください。改変又は翻訳/翻案した場合は、新しく使用条件を設定することが可能ですが、「改変又は翻訳/翻案を行ったこと、(可能な限り)どの部分にどのような改変又は翻訳/翻案を行ったかの概略、当該図表等についての責任主体は利用者にある旨」を付記し、著作者人格権を行使しない旨の宣言条項を必ず含めてください。
    3. 独立行政法人情報処理推進機構は、本グラフデータが第三者の著作権、特許権、実用新案権等の知的財産権に抵触しないことを一切保証するものではなく、また、本グラフデータの内容に誤りがあった場合でも一切責任を負いかねます。
    4. 独立行政法人情報処理推進機構は、本ページで記載された許諾内容を除き、独立行政法人情報処理推進機構又は第三者の著作権、特許権、実用新案権等の知的財産権に基づくいかなる権利を許諾するものではありません
    5. 独立行政法人情報処理推進機構は、本グラフデータのシステム開発への利用、開発されたシステムの使用、及び当該システムの使用不能等により生じるいかなる損害についても、なんら責任を負うものではありません。
    6. 本グラフデータを海外へ持ち出す場合及び非居住者に提供する場合には、「外国為替及び外国貿易法」の規制及び米国輸出管理規則等外国の輸出関連法規などを確認のうえ、必要な手続きを行って下さい。
    7. 本使用条件の解釈は日本国法に準拠するものとし、本グラフデータの利用に関して法的紛争が生じた場合は、東京地方裁判所を唯一の合意管轄裁判所とします。
    8. 本グラフデータへのお問い合わせについては、独立行政法人情報処理推進機構 社会基盤センターまでご連絡ください。

業種編について

  1. Q1.業務用アプリケーション開発（デスクトップアプリ、Webアプリ、サーバーアプリ等） はどの業種に該当しますか？

    A1.

    データ白書での「業種分類」は、開発するソフトウェアが対象とする業種の分類です。よって、質問の「業務用アプリケーション」 が、どの業種向けのアプリケーションかに依存します。

  2. Q2.「業種」の分類は何を根拠としていますか？

    A2.

    「日本標準産業分類（平成14年3月改訂）(総務省）」に基づいています。
    データ白書2018-2019 P360 付録A.3［業種の分類］をご参照ください。

  3. Q3.組込みのファームウエア開発は、どの業種になりますか？

    A3.

    データ白書はエンタプライズ系のソフト開発を対象としています。よって、ファームウェア開発は対象外となります。
    なお、組み込み系ソフトに関しましては、「組込みソフトウェア開発データ白書2017」を発行しておりますので、下記ページをご参照ください。

設計書のページ数について

  1. Q1.設計書のページ数はどのように数えているのですか？

    A1.

    特に規定しておらず、データ提供会社の判断に委ねています。

  2. Q2.改良開発のときの設計書のページ数はどのように数えているのですか？

    A2.

    SLOC や FP のような開発規模とは異なり、ページ数は差分量の計測をしていません。 つまり新規開発のときと同様に、設計書の全ページ数を計測しています。

その他

  1. Q1.「データ白書掲載のグラフデータ」とは何を指しているか？　（グラフを描画する為の生データのことではないと思っているが）

    A1.

    グラフデータは、利用者の方々がグラフを再現するためのデータです。次のように生データそのものではありません。

    • 多くのデータは導出指標値に変換されたものです。
    • グラフごとにそのグラフを再現するために必要十分なサブセットデータを提供しています。（フルセットデータではありません。）

  2. Q2.複数条件の分類を組み合わせた分析を実施したい場合、データの提供もしくはIPA側での分析を実施していただくことは可能か？

    A2.

    データ白書のデータは提供いただいている企業と機密保持契約を締結しており、残念ながらデータのご提供はできないのが実情です。また、皆様からの個別要望に対し、問い合わせをお受けすることは出来ますが、新たなデータ分析については対応しておりません。誠に申し訳ございませんが、現段階では、上記理由によりご要望にお応えできないことをご理解いただきますようお願いいたします。なお、お寄せいただいた要望の中で、標準的なデータ白書の分析結果として取り入れた方がよいものは、次回のデータ白書への取り込みを検討していきたいと考えております。オンデマンド的な分析の実施については、現状実施しておらず、内部で検討中です。

  3. Q3.「ソフトウェア開発データ白書2018-2019」の最新版はあるのか？ （2020年10月現在）

    A3.

    「ソフトウェア開発データ白書」は、名称を「ソフトウェア開発分析データ集」に変更して、以下で最新の版を公開しております。