iCD に基づいたソフトウェア開発者が持つ役割ごとの開発能力評価の試み
山田悠斗

土居真之 肥後芳樹 柗本真佑 楠本真二
大阪大学 大学院情報科学研究科{y-yuto, m-doi, higo, shinsuke, kusumoto}@ist.osaka-u.ac.jp
塚本貴弘 折方孝夫 藤原永年
三菱電機コントロールソフトウェア株式会社{tsukamoto.takahiro, orikata.takao, fujiwara.nagatoshi}@zp.mitsubishielectric.co.jp
要旨

測りたいという要望がある．この要望を満たすためには，開発者が持つ役割ごとの開発能力を，統一された評価基

IT 企業のソフトウェア開発現場や経営層では，開発者準によってできる限り客観的に評価することが望ましい．の役割ごとの開発能力を適切に評価したいという要望が開発者の開発能力を評価するためのツールとしては，i存在している．i コンピテンシディクショナリ (iCD) は開コンピテンシディクショナリ (iCD) [4] というものがあ発者が行うタスクを列挙し，各タスク遂行力の評価方法

る．しかし，iCD を用いた開発能力評価にはいくつかのを提供するものであるが，項目数が多すぎることや，開課題が存在している．1 つは，あらゆる業種を網羅して発者ごとに診断基準が変動する可能性があることなど，いるために評価項目数が多すぎることである．さらに，いくつかの課題が存在している．本研究では，iCD の項

iCD は開発者自身が評価することを想定しているもので目数を削減し，開発者の知識や経験の有無を問う質問事あるため，開発者ごとに診断基準が変動する恐れがある

項を作成することで，診断基準の変動を抑制する改良をという課題も存在する．

実施する．iCD のタスク項目数を効果的に削減する手法

本研究では，iCD を用いた開発能力評価について，開と，タスク遂行力の評価基準に基づいた質問事項の作成

発者ごとの診断基準の変動を抑制するような改良を実施

方法を説明し，今後の試みについて紹介する．

する．iCD の項目数を削減し，開発者の知識や経験の有無を問う質問事項を作成することで，診断基準の変動を抑制する．さらに，改良された評価方法を用いて，ある

1. はじめに企業 (以降，A 社) を対象とした役割ごとの開発能力評価の実施を試みる．

ソフトウェア開発業界における開発プロジェクト失敗の要因には，開発方法や技術だけでなく開発者の能力や性格も関係するとされている [1] ．そこで，開発者の持つ能力や特性を正確に評価することや，開発者に必要と以降，2. では研究の背景となる諸用語について述べる．3. では iCD の改良方法について述べる．4. では実環境における iCD 改良版の適用計画について述べる．5.
では今回の実施内容と今後の課題をまとめる．

なる能力を調査することを目的とする研究が盛んに行われている [2, 3] ．
また，一般に IT 企業の開発現場では，開発者の適性を判断して開発チームにおける役割を決定するために，開発者の役割ごとの開発能力を評価する方法が必要とされている．さらに，経営層としても自社に適した規模のプロジェクトを請け負うために，組織全体の開発能力を

2. 準備
本章では研究の背景や諸用語について簡単に述べる．

2.1. 関連研究

個人の持つタスク遂行力や必要なスキルを判定する方法も提供しており，開発者の開発能力を分析する研究でも開発者の持つ能力や特性の評価に関連する研究はこれ利用されている [7] ．

までも盛んに行われている．文献 [1] では，ソフトウェ

iCD はタスクを定義・列挙しているタスクディクショ

アエンジニアに必要となる知識や能力，行動を特定し，ナリと，スキルを定義・列挙しているスキルディクショ

それらの重要度をエンジニアの役割ごとに記入できるよナリによって構成されている．各タスクの遂行に必要とうなフレームワークを提供している．文献 [2] では，プなるスキルが連係表によって紐づけされている．今回はロジェクトマネージャに必要となる基本能力を特定し，開発者の開発能力を評価することを目的としているため，それらの基本能力を高めるために必要な能力や姿勢を提タスクディクショナリに着目する．

示している．また，文献 [3] では，石油業界での建設プロジェクトに関して，プロジェクトマネジメントチームの問題解決力を測るために，チーム全体の能力を数値として測定する手法が提案されている．しかし，開発者個人の素養や能力を評価するための確実な手法というのは

2.3.2

タスクディクショナリの構成

タスクディクショナリの構成を表 1 に示す．タスクディクショナリには以下の項目が存在している．

未だに提案されておらず，実環境で評価を行うには，各企業や団体に合わせた独自の評価手法が必要となる．

タスク大分類タスクディクショナリの最も上の階層に位置し，開2.2. ISO/IEC 15504
ISO/IEC 15504 [5] とは，国際標準化機構 (ISO) と国際電気標準会議 (IEC) が策定した，ソフトウェア開発を中心としたプロセスアセスメントモデルの共通の枠組みを提供したものである．SPICE (Software Process Improvement

発業務の種別や開発分野による分類が行われる．
タスク中分類
タスク大分類で示した各業務や分野における大まかな作業内容が列挙されている．
タスク小分類 (タスク)and Capability dEtermination) とも呼ばれている．プロセ

各タスク中分類の作業のより詳細な内容が列挙され

ス診断モデルなどの枠組みのみを提供しており，完結している．以降は，この項目を単に「タスク」と呼ぶ．

た方法論は提供していないため，利用する際は各自の環境に合わせたモデルを作成する必要がある．

また，それぞれのタスクごとに評価項目というものがまた，SPICE を母体とした車載ソフトウェア開発プ存在する．これは各タスクの遂行力を診断するための評

ロセスの共通フレームワークを提供している A-SPICE

価基準である．例えば，タスク「プログラミング」が持(Automotive SPICE) [6] というものがある．エンジニア

つ評価項目の一部を表 2 に示す．

リングプロセスを詳細に具体化していることが特徴であり，各プロセスの作業成果物等を規定している．車載ソ
フトウェアだけでなく，様々なソフトウェア開発分野においても参考にすることができる．

2.3.3 iCD を用いた評価事例
iCD を用いた実例として，ある企業では，タスクベースの診断を行うことにより，マーケティングやプロジェ

2.3. i コンピテンシディクショナリ (iCD)

クトマネジメントといった職種ごとのレベルを評価して2.3.1 iCD の構成

人ひとりの各業務の遂行力を把握することができ，現状いる [8] ．スキルではなくタスクに着目することで，一iCD [4] は IT ビジネスにおける開発者が行うべきタス
ク (業務) と，それを遂行するために必要となるスキル(能力) を列挙した項目群である．企業が行う全ての業務を明確化することによって現状の把握や課題の発見を促し，企業成長に貢献することを目的としている．また，の能力の認識や自身に必要な能力の発見につなげることができる．

タスク大分類

表 1. タスクディクショナリの構成
タスク中分類
タスク小分類 (タスク)

評価項目(49 項目)(194 項目)(622 項目)(2438 項目)

アプリケーション

ソフトウェア詳細設計

ソフトウェアコンポーネント設計

・・・

システム開発(機能分割・構造化)
入出力詳細設計・・・・・・・・・

ソフトウェアコード作成・ プログラム構造設計
単体テスト

・・・

(モジュール分割・モジュール設計)
単体テスト仕様作成

・・・・・・・・・

表 2. タスクが持つ評価項目の例
タスク

評価項目

プログラミング

コーディング規約，命名規則，レビュー記録，バージョン管理などの開発標準を遵守してコーディングを行う
設計書 (詳細設計書，プログラム仕様書) に基づいたコーディングを行う
作成するプログラムの機能を理解し，API や再利用，代替プログラムを活用する
・・
・

2.3.4 iCD を用いた評価の課題
開発者がタスクディクショナリの評価項目に書かれている内容を診断することで，自身の各タスクの遂行力，すなわち開発能力を評価することができる．iCD は，各評価項目を 5 段階のレベルで診断する方法を例として提供している．5 段階の診断基準を表 3 に示す．

3. iCD の改良
本章では，iCD を用いた開発能力の評価方法を改良する方針と，それを実現する方法について述べる．

3.1. 改良の方針

しかし，この診断方法では L2 と L3 の線引きが難しく，まずはじめに，複数のタスクを担当する開発の能力を回答する開発者によって診断基準が変動してしまう可能評価するために，タスクディクショナリにおけるタスク性がある．さらに，タスクディクショナリは様々な業種と評価項目の整理を行う．続いて，診断基準が変動するに対応するために 622 項目のタスクと 2438 項目の評価可能性があるという課題を解決するために，開発者が評項目を持っており，開発者へのチェックシートとして利価項目を診断するための新たな質問事項を作成する．こ用するには項目数が多すぎる．そのため，タスクディクのとき，作成する質問事項は回答する開発者の知識や経ショナリを利用する企業や用途に沿って，項目を整理す

験に基づいた 2 択の質問にする．これによって開発者自る必要がある．また，前述した評価事例では職種，また身による判断を行いやすくし，開発者ごとの診断基準のはタスクごとのレベルを評価するために iCD が用いら変動を抑制する効果が期待できる．例えば，「機能要件のれているが，様々な役割を持つ開発者の能力を総合的に定義」という評価項目に対しては以下のような 3 つの質診断するために用いることは難しい．

問事項を作成する．
レベル 1: 機能要件に関する知識を持っているか
レベル 2: 機能要件の定義を実施した経験があるか

診断レベル表 3. 評価項目の診断基準
診断基準

L0

知識，経験なし

L1

トレーニングを受けた程度の知識あり

L2

サポートがあれば実施できる，またはその経験あり

L3

独力で実施できる，またはその経験あり

L4

他者を指導できる，またはその経験あり

レベル 3: 機能要件の定義を実施した際に，他者からの評価を受けているかの作業が含まれている場合がある．そのようなタスクを作業ごとに分割することで，1 つのタスクに 1 つの作業内容が含まれるようにし，タスク内容の粒度を揃える．

レベルの高いの質問事項に当てはまるほど，「機能要件の定義」の評価が高いと診断される．このような質問事項を，各評価項目ごとに作成する．

例えば「要求事項の調査と分析」というタスクの場合は，「要求事項の調査」と「要求事項の分析」というタスクに分割される．

3.2. タスクと評価項目の整理
3.2.3
まず，タスク単位ではなく，複数のタスクを 1 人の開発者が実施するという前提で，タスクと評価項目の整理を行う．

評価項目の整理

上記の作業によって，役割ごとにまとめられた新たなタスク群が作成されたので，続いて各タスクの評価項目の整理を行う．まず，評価項目の内容をより理解しやすいものにするために，「〇〇の××」 (例：機能要件の定

3.2.1

各役割へのタスクの分類

本稿では，典型的なウォーターフォール型の開発，すなわち，要件分析，設計，実装，テストを実施する役割として，「ソフトウェア要件分析者」「ソフトウェア方式設計者」「詳細設計者」「コーダー (実装者)」「単体テスト担当者」「ソフトウェアテスト担当者」の 6 種類を考える．そこで，タスク大分類やタスク中分類によって業種ごとに分類されているタスクを，それぞれの役割ごとに分類し直す．
そのために，タスク大分類やタスク中分類の間に存在している，重複または類似した名前や内容のタスクを 1つのタスクとしてまとめる．これによって，それぞれのタスクがタスク大分類・中分類に依らないものとなるので，まとめられたタスクを役割ごとに分類し直すことが可能となる．

義) のような文章にまとめることで簡略化する．
また，タスクごとの評価項目数のばらつきを抑えるた
めに，評価項目が 4 項目以上のタスクについては 3 項目になるよう選定する．評価項目を選定する際は，タスク名に合致していることと，タスクの成果物を作成する作業となっていることを選定基準としている．

3.3. 質問パターンの作成整理した評価項目ごとに，それを診断するための質問事項を作成していく．しかし，評価項目には様々な内容があり，それらに対して効率良く質問事項を作成する必要がある．そこで，いくつかの質問事項のパターンを作成し，各評価項目をより適当なパターンに割り当てるようにする．今回は，以下の 5 種類の質問パターンを作成した．各質問パターンが与える質問事項に関しては，括弧書きの部分が評価項目の内容により変更される部分で3.2.2

タスクの分割あり，レベルの高い質問事項に当てはまるほど，評価が高いと診断される．

それぞれのタスクは内容の粒度にばらつきがあり，「要求事項の調査と分析」というタスクのように，2 つ以上用語パターン

作業対象への知識があれば，その作業を遂行できるもの．以下の 3 つの質問事項を与える．
レベル 1: (作業対象) に関する知識を持っているか
レベル 2: (作業) を実施した経験があるか

評価項目1-1

2/4

評価項目1-2

1/3

評価項目1-3

4/4

評価項目2-1・・・・・・・・・

レベル 3: (作業) を実施した際に他者からの評価をB
役割A

タスク2CD7 / 11 (64%)

受けているか
作業パターン

タスク1

E0

D

20

C

40

B60

A

80100(%)

作業遂行するために，作業対象への知識だけでなく，作業を遂行するための具体的な手順を理解する必要

図 1. 質問事項への回答結果に基づいた開発能力測があるもの．以下の 4 つの質問事項を与える．

定の例

レベル 1: (作業) の手順に関する知識を持っているか
レベル 2: (作業) を実施した経験があるか

レベル 2: (ツール・技術) を利用した経験があるか

レベル 3: (作業) を実施した際に他者からの評価をレベル 3: (利用方法) に関して他者への指導を行っ受けているかているか

レベル 4: (作業) に関して他者への指導を行っているか
業務パターン

3.4. iCD 評価項目の質問パターンへの割り当て
各評価項目を，作成した質問パターンのいずれかに割作業を遂行するのに専門的な知識や手順を必要としり当てる．まずは，それぞれの質問パターンに適した作ないもの．以下の 2 つの質問事項を与える．

業に関連する単語を設定する．設定した単語の一覧を表

レベル 1: (作業) を実施した経験があるか
レベル 2: (作業) を実施した際に，他者からの評価を受けているか評価パターン
成果物への確認事項に対する自己評価や他人への評価に関係するもの．以下の 3 つの質問事項を与える．
レベル 1: (確認事項) に関する自己評価を行っているか
レベル 2: (確認事項) に関して他者からの評価を受けているか
レベル 3: (確認事項) に関して他者への評価を行っ4 に示す．簡略化した評価項目の後半部分と設定した単語を照らし合わせることで，評価項目を質問パターンへ割り当てる．例えば「機能要件の定義」という評価項目の場合は，表 4 より用語パターンの中に「定義」という単語が含まれているので，用語パターンへと割り当てられる．
ただし，この方法によって用語パターンに割り当てられた評価項目の中には，作業対象がソフトウェア業界では一般に知られているものであるため，用語パターンへ割り当てるのは不適切と判断される項目が存在した．このような評価項目は例外とし，作業パターンへ割り当てる．例外処置をとる作業対象は，カスタマイズ，パッケージ，モジュール，ネットワーク機器，テストツールの 5種類である．ているか
指導パターン
ツールや技術の利用方法の指導に関係するもの．以下の 3 つの質問事項を与える．
レベル 1: (利用方法) に関する知識を持っているか

3.5. 開発能力ランクの測定作成した質問事項への回答結果に基づいて，タスクごと，ならびに役割ごとの開発能力ランクを測定する．測定の例を図 1 に示す．

表 4. 各質問パターンに適した作業に関連する単語
用語パターン

優先付け

定義作成

分類

抽出

分界選択

列挙

決定

検討

分割

詳細化

統一

割り当て導入手配

取り組み遵守

活用

判断

編成

準備

分析

把握

対応付け設計設計見積もり

確保

共有化

構築

対処

設置

設定

テスト

チューニング

開発

実装

検証

管理

コーディング向上

コードレビュー

結合統合計画業務パターン

責任分担

記録

報告

整理

評価パターン

評価

レビュー

確認

見直し

指導パターン

指導

作業パターン

まず，質問事項への回答結果から，各評価項目のスコ4.1. タスクの追加

アを測定する．自身に当てはまると回答された質問事項のうち，最も高いレベルの数値が評価項目のスコアとな

A 社では，開発プロセスを把握する際に A-SPICE をる．いずれの質問事項にも当てはまらない場合は，スコ参考にしている．役割ごとに分類したタスクを A-SPICE

アは 0 となる．図 1 の例では，評価項目 1-1, 1-2, 1-3 のと照らし合わせた結果，A-SPICE に記載されているいく

スコアが 2/4, 1/3, 4/4 と測定されている．

つかの作業が不足していることが判明した．そこで，不続いて，タスクごとの開発能力ランクを測定する．各タスクに割り当てられている評価項目のスコア合計値の足している A-SPICE 中の作業を新たなタスクとして追加する．

得点率を用いてランクを測定する．得点率が 0〜20%の場
合はランク E，21〜40%の場合はランク D，41〜60%の場合はランク C，61〜80%の場合はランク B，81〜100%の場合はランク A と測定される．図 1 の例では，評価
項目 1-1, 1-2, 1-3 が割り当てられているタスク 1 に関して，得点率が 64%となるので，ランク B と測定される．
最後に，役割ごとの開発能力ランクを測定する．各役割に含まれるタスクのランクを，E を 0 点，A を 4 点として点数化する．そして先程と同様にして，タスクランク合計値の得点率に基づいて 5 段階のランク付けを行う．
図 1 の例では，タスク 1, 2 が割り当てられている役割 Aに関して，タスクのランクの得点率が 50%となるので，ランク C と測定される．

4. iCD 改良版を用いた開発能力評価の実施計画
本章では，A 社の開発者を対象として iCD 改良版を適用するための準備や実施環境，実施結果が得られた際の評価方法について述べる．

4.2. 調査シートの作成
調査を行うために，作成した質問事項を列挙したチェックシートを作成する．実際に提供するチェックシートの構成を図 2 に示す．チェックシートの各項目に関して最上段の内容が当てはまるものにチェックマークを入れることで，自動的に役割ごとの開発ランクやタスクごとの開発ランクが測定されるようにする．また，チェックシー
トとは別に，シートのクオリティや評価を実施する意義を確認するためのアンケートシートを作成する．

4.3. 実施環境
A 社の開発者を対象として，チェックシートの適用を行う．対象とする開発者は，ある開発グループに属する新人，中堅，熟練開発者 2 名ずつの計 6 名である．それぞれの知識や経験に基づいて，自身でチェックシートに回答してもらう．チェックシートへ回答したもらった後に，アンケートシートへの回答も行ってもらう．

知識を持っている

自己評価を行って 実施経験がある
他者からの評価を 他者への評価・いる
受けている
指導を行っている
ソフトウェア要件分析者既存Webサイト
既存Webサイト
既存Webサイト
既存Webサイトの分析手順の分析の分析の分析
既存Webサイト
既存Webサイト
既存Webサイト
既存Webサイトの利用傾向のの利用傾向のの利用傾向のの利用傾向の把握手順
把握
把握
把握
・・・
ソフトウェア方式設計者
開発手法の開発手法の開発手法の選択基準
選択選択・・・

図 2. チェックシートの構成

4.4. 実施結果の評価

6. 謝辞

開発者のチェックシートへの回答結果に基づいて，各

本研究は一部，日本学術振興会科学研究費補助金基盤開発者のタスクごと，役割ごとの開発能力ランクを測定研究（S）（課題番号：25220003）の支援を受けている．

する．チェックシートの回答から得られた測定結果と，対象となる開発者の上司の方による開発能力ランクの評価

参考文献を比較することで，測定結果の整合性を確認する．また，新人，中堅，熟練開発者の開発能力ランクの差異なども[1] José Gamaliel Rivera-Ibarra, Josefina Rodrı́guez-

確認することで，チェックシートの有効性を調査する．

Jacobo, and Miguel Angel Serrano-Vargas. Competency framework for software engineers. In Software

5. おわりにEngineering Education and Training (CSEE&T), 2010
23rd IEEE Conference on, pp. 33–40. IEEE, 2010.

本稿では，開発者の役割ごとの開発能力評価を実施するために，iCD による開発能力評価の改良を行った．iCDを用いた際の診断基準の変動を抑制するために，iCD の項目数を削減し，開発者の知識や経験の有無といった自身で判断しやすい質問事項を作成した．また，iCD 改良版を実環境へ適用する際の計画を提示した．

[2] Lawrence Peters.

A Knowledge & Competencies

Checklist for Software Project Management Success. In
SEKE, pp. 241–243, 2014.
[3] Mahsa Taghi Zadeh, Reza Dehghan, Janaka Y Ruwanpura, and George Jergeas.

An index to assess

今後の展望としては，計画として提示した A 社への

project management competencies in managing designiCD 改良版の適用が考えられる．iCD 改良版による開発

changes. International Journal of Construction Engi-

者への評価結果と，現場の上司の方による評価を比較す

neering and Management, Vol. 5, No. 1, pp. 11–24,

ることで，結果の考察や今後の課題の発見を行う．また，

2016.

今回の開発能力評価と性格診断テストを併用することで，タスクとスキルの両方の面から開発者の能力を測ることも今後の研究として考えられる．

[4] iCD オフィシャルサイト. https://icd.ipa.go.jp/icd/.
[5] ISO/IEC 15504-5:2006 Information technology Process Assessment Part 5: An exemplar Process Assessment Model.
[6] Automotive SPICE. http://www.automotivespice.com/.

[7] 大月美佳, 掛下哲郎ほか. i コンピテンシ・ディクショ
ナリを活用した J07 および情報処理技術者試験と職種のマッチング分析ツール. 研究報告コンピュータと教育 (CE), Vol. 2015, No. 19, pp. 1–8, 2015.

[8] 石川拓夫. 2 万人のレベル診断〜日立の IT 人財強化の取り組み〜. HRDI セミナー「デジタル革命への挑
戦 〜iCD 活用，更なるその先へ〜」. 独立行政法人
情報処理推進機構 (IPA), 2017.