ソフトウェア生産性は単なる指標であって契約で使われるものにはならない

on


ソフトウェア生産性
ソフトウェア開発のプロジェクトでは、しばしば、ソフトウェア生産性といキーワードが出てくる。ソフトウェア生産性はコーディング{する|した}ソフトウェアコードを費やした作業時間で割ったものです。


ソフトウェア生産性=動くソフトウェアコード数/作業時間


そのソフトウェア生産性には影響する因子があって、それぞれが揺らぐために精度を求めるには厳しすぎる。たとえば、


  • コード定義　コードの定義が必要。命令実行文だけにするのか、改行した命令文は1ステップで数えるのか...。
  • 言語係数　第三世代、第四世代の言語、各種スクリプトなど、言語による係数の必要性。
  • エンジニア係数　エンジニアの一時間当たりのコーディング量。経験の浅いエンジニアとベテランのエンジニアの経験値差に由来するもの。
  • 作業時間の妥当性　コーディング時間のみをメトリクスとするか。また、コーディングに費やす作業時間の計測の実現可能性。


作ったコードを計測するだけでも考慮しなければならなそうなことがいろいろあるのね。それを計測者が第三者として一人ひとりのエンジニアのコーディングを計測することは現実的でなさそうだ。一人ひとりのエンジニアが計測すればいいじゃない？と思う貴方。それ、計測ルールを作っても、どれだけのエンジニアがそのとおりにやってくれるか想像してみて。
＃まったく無理なの？と聞かれれば、こうすればできるかなーと思いつくことはあるけれど、大変そうだなーって。


ソフトウェア生産性の使われ方
その大変そうなソフトウェア生産性は何に使うかっていうと、

  • 見積もり時
  • 品質管理での管理対象の数量
  • 納入時の出来高
  • 保守時の維持作業の基礎数量


ですね。
で、見積もり時に使う、ですが、先のいろいろ考慮しなければならないことを考慮した上で、いくつかのメトリクスを採取することが幸いにもできたという前提で考えても結構精度の高いソフトウェア生産性として使うのはどうかなと思うわけです。


見積もりで使うには
何がどうかな？と言うと、そもそも見積もり時に契約後の要件定義でこれから具体的に要件を伺うのに、その前にRFPなり要求仕様なりから見積もる規模にどれだけ信頼性があるのかな？と言うことです。

言い換えれば、不確かな因子にソフトウェア生産性を掛けても不確かな数値が積みあがるだけではないか、と言うことです。さらに、メトリクスを採取したプロジェクトとエンジニアが同じである保証はないからエンジニアが違えばソフトウェア生産性は左右されるし、たとえ同じエンジニアでも同つの言語でソフトウェアを作るなら習熟しているから生産性は向上している可能性は高いと言うことです。チームを構成するエンジニアの経験層の分布によってもソフトウェア生産性は揺すられてしまう。

エンジニアの習熟度は実際のプロジェクトでのリスクにもなる可能性を秘めていて、プロジェクトが5人より10人、10人より50人とか規模が大きくなるなら構成するエンジニアの経験による揺らぎは限りなく1に収斂するけれど、5人などの小さなチームなら深刻な問題になるので注意が必要です。


方便のソフトウェア生産性
見積もり時に使用するソフトウェア生産性は、実は営業的な方便でしかなく、そこには、その企業の価値がないことを暗に示しているに過ぎないのではないかと疑わざる得ない...。なぜなら、競合するコンペティタがいる場合、当の企業が売り込む価値が見いだせないから費用対効果でしか訴求できないので、

「価格に対して、これだけソフトウェアを作り出せますよ。」


という安易なロジックで営業を掛けるしかないのです。具体的に何を作るかも決まっていないし、必要な情報は、契約後に担当者から要件を聴き取りしないとわからないのに、です。
これは、二つの危険性が秘められていて、ソフトウェアを作る方は、リファクタリングや適切なアルゴリズムを考慮しないで“動く”ソフトウェアを作ることも否定できず、顧客は、必要のないソフトウェアをただ生産性が高いなら作らせてしまい、作らなければ支払う必要のないソフトウェアの維持費用を破棄するま“余計に支払う”ことを自ら進むということがあるのです。

そう考えると、発注側の顧客は必要なソフトウェアだけ作って欲しいし、受託するSIerは必要な業務で使われるソフトウェアだけを作りたい。その世界が成り立つときにソフトウェア生産性は単なる指標であって契約で使われるものにはならない、と言うことです。