「エンピリカルソフトウェア工学」セミナー

PM event

「エンピリカルソフトウェア工学」のセミナーに行ってきた。
http://www.mpuf.org/pm/es080723.htm


エンピリカルソフトウェア工学とは、プロジェクトのモニタリングのための手法だ。
プロジェクトの計画〜実行プロセスの間、プロジェクトはモニタされ、必要に応じてコントロールされていかねばならないが、プロジェクトの様々なデータを定量的に分析して可視化（見える化）し、プロジェクトの状況をモニタリングするのだ。

なお、エンピリカルとは、「experimental」と「experienced」の造語。


プロジェクトの「見える化」という観点では、定性的な分析と定量的な分析の両方の説明があった。エンピリカルソフトウェア工学とは、このうち、定量的な部分のみを指すのかもしれないが、私の興味は定量的に分析することではなく、プロジェクトを「モニタリング」することにあったので、以降、両方について記述する。
＃「定量的な見える化」が「エンピリカル」だという説明があったわけではなく、後で用語を改めて調べたらそう書いてあったのだ。セミナ中は意識せずに聞いていた。


なお、印象としては、定性的な分析は、プロジェクトのどこかのタイミング（プロジェクト立て直しとか、見直しとか）で診断する目的に使用し、定量的な分析は、プロジェクトの計画〜実行期間中継続的なモニタリングに使用するようだ。


プロジェクトの定量分析（ススメ、および収集したデータの解釈の例）はIPA−SECで無料会員登録すれば、ダウンロードできる。

定性的な見える化

俯瞰図

いろいろなものを俯瞰した図を作りましょうね、という話。例えば、

  • 体制図的なもの
  • システム構成図的なもの
  • スケジュール俯瞰図（いわゆるマスタスケジュール）
  • 要員遷移俯瞰図（いわゆる山積み表）

＃システム構成図がプロダクト系でなく、プロジェクト系の図だという考えには賛成しかねるけど。

チェックシートやヒアリングシートによる診断

チェックシートやヒアリングシートにより、プロジェクトの状況を診断しましょうね、という話。
これは、頻繁に実施するものではなく、プロジェクトが「やばい」と感じたときとか、火消しの到着時などに実施するものだと思う。
PMBOKの９つの知識エリア＋拡張項目（技術、顧客、組織、基本動作？？？、モティベーション、課題管理）ごとに得点化し、レーダチャートなどで表現する例が上がってた。
＃拡張項目はPMBOKの知識エリアに含まれているものもあり、挙げ方にはちょっと疑問ありだけど、特にフォーカスしたいエリアだったんでしょう。きっと。

スキル診断

プロジェクトチームのスキルプロファイルを見える化しましょうね、という話。
ITSS的な観点で（組み込みはETSSとか、違う名前らしいよ）スキル診断を行い、プロジェクトチームのスキルプロファイルを作成する。
スキルレベル１の人には同数のスキルレベル３の人がOJTとしてつく必要があり、スキルレベル３の人が少ないとうまくいかないね、とか、
「技術大事」といった話がでた。

組み込み系のプロジェクトマネジメントはエンタープライズ系（業務系）のマネジメントに対して進んでいるのか、スキルプロファイルを適正に保つのは組み込みは常識、エンタープライズは価格優先で怪しからんらしいっす。それ以上は偏見に満ちた話が多く、書けません。

定量的な見える化

今日のセミナの山場で、みんな楽しみにしてた時間。
IPA−SECのEPAツールのアウトプットを使用した解釈のデモ。

EPAツールについて

EPAツールは、IPAが作った（？）ツールで、構成管理ツール、メール、バグ管理ツールより情報を自動収集して、さまざまなVIEWで見える化してくれる。
分析結果はEclipse上で見れるらしい。

メトリクスの例

メトリクスの例を少しだけ挙げる

  • 累積障害件数（プロジェクト別）
    • 発生
    • 累積
    • 滞留
  • ソースコードの行数
  • メールの件数
解釈

「見えた」ものを人が解釈する。
メトリクスを時系列に並べて解釈したり、いろいろなメトリクスを重ね合わせて解釈したりする。
また、複数のグラフ（AプロジェクトとBプロジェクトとか、ＡさんとＢさんとか）並べて比較して解釈することもできる。

その他

EPMツールとMS Projectが連携することもできるらしい。
EPMツールは、IPA−SECのサイトから申し込めば、使えるらしいよ。多分無償。


「見える化」結果の利用法

  • プロジェクトマネジメントへリアルタイムにフィードバックしてコントロール
  • プロセス改善へのフィードバック
  • トレーサビリティの確保（うーん、繋がるのか？）


１、２番目はどちらも、「見えた」こと自体がフィードバックに役だつわけではない。
「見えた」ものをもとに「評価」し、対策をたてた上でフィードバックする。
つまり、PDCAサイクルをまわす必要があるよなーという当たり前のことを当たり前に考えた。
３番目は、つながりっぷりが今考えると納得できてないので、ノーコメント。（聞いてる時は納得してたんだがorz）


感想

  • プロジェクトのモニタリングには、定性的な分析と定量的な分析の両方が必要そう。
  • 定量的な分析はデータの収集に手間がかかるので、リアルタイムにモニタリングするためには、自動化ツールが必須。
  • 定性的な「見える化」結果であれ、定量的な「見える化」結果であれ、それを解釈するのはノウハウを持った人である。過度な期待はできない。
  • 「見えた」こと自体はあまり役にたたない。PDCAサイクルをまわしてやっと活かせる。

ほか

ちらりと紹介された「CCFinderX」という、コードクローン分析ツールがとても気になったので、時間があれば調べてみる。
コードの重複を検出するツールだということだ。
コードの重複はメンテナビりティをスコっと下げるので、必要最小限にしたいよね。