生産性を語るときには、 品質が前提になっている
…というのが製造業での常識なんだけど、 ソフトウェア業界にはその常識は無いのかもしれない、 という話。
「生産性」 というのは、 モノを作り出すとき、 投入したインプットと出来上がったアウトプットの比です。
インプットとして労働時間だけを見るときは、 労働生産性と言います。
たとえば、 ある工場で 10人が働いていて、 10時間で 1,000個の製品を作って出荷したとすると、 労働生産性は 1,000[個] ÷ ( 10[人] × 10[時間] ) = 10 [個/人時]
あるいは、 この製品 1個の出荷額に含まれる付加価値分が 100円だったとして ( 1,000[個] × 100[円/個] ) ÷ ( 10[人] × 10[時間] ) = 1,000 [円/人時]
といったように計算します。
一見すると、 品質なんてまったく関係していない、 単純な計算式です。
しかし、 この式の裏には、 製造業ではまったくあたりまえの常識が隠れているのです。
それは、
不良品は出荷できない
ということ。
その工場での不良率が 0.5% だったすると、 上の計算をしたときに実際に作ったのは 1,005個です。 そのうちの 5個は不良品で出荷できなかったので、 計算式に乗るのは 1,000個、 というわけです。
※ なお、 不良品かどうか判定するための検査 ( テスト ) に掛かる作業時間や、 不良品を処理するための作業時間も、 分母に含めます。
このように、 不良品、 つまり、 一定の品質基準に達しなかったモノはアウトプットとみなさない、 というのが生産性を計算するときの大前提になっています。
極端な話、 作ったものすべてが不良品だったら、 生産性はゼロです。
ひるがえって、 ソフトウェア業界には、 この常識があるでしょうか?
一定の品質をクリアしているかどうかの判別をしなければ、 生産性なんて求められない、 ということを。
ついでに。
ソフトウェア業界では、 どのように生産性を計算するべきでしょう?
・ 単位時間あたりに書いたコード行数 ?
そのコードがそのまま全て出荷できるモノであれば、 生産性と言ってもよいでしょう。
しかし、 実態は…?
バグが見つかって修正したのなら、 その時間も加算しなければおかしな話です。
※ 工場でも、 検査でハネられたモノを修正して、 あらためて検査を通して出荷することはあります。 その作業者の労働時間も、 とうぜん計算式の分母に入ります。
ヘタをすると、 そのコードはまるでダメで、 作り直しになるかもしれません。 そのときは、 1日に 1,000行書いていようが、 生産性はゼロになっちゃいますね。
※ なお、 ソフトウェアの 「量」 としてコード行数を見るのは、 時代遅れと思われるかもしれません。 しかし、 ソースコードに対する品質基準を持ち込めば、 話は違ってきます。 重複のあるソースや、 ムダに複雑なコードは品質基準をクリアできませんから。
・ 単位時間当たりの完成した機能 ?
コンストラクション、 旧来の言い方をするなら内部設計~結合テストまでの作業についてならば、 これを生産性と考えてよいと思います。 結合テストをクリアする品質を達成できていない部分は、 当然ながらアウトプットとしてはカウントできません。
機能の 「量」 をどう測るのか、 ってのが問題ですが。 いまのところ FP ( ファンクションポイント ) が最もブレが少ないようなので、 それを使うかなぁ、 ってところですね。
※ コンストラクションは、 「これこれの機能を作ってくれ」 → 「完成しました、 どうぞお納めください」 という範囲ですので、 作るべきソフトウェアの機能 (アウトプット) は確定しています。 対して、 要件開発 ( 要件定義~外部設計 ) は、 アウトプットをどう測るかがとても困難です。
・ 単位時間当たりの売上 ?
経営者はこの数字を気にしますし、 そうでなければいけないでしょう。
ただし、 この生産性が低いからといって、 いきなりコンストラクションの現場に 「なんとかせい!」 と言うのは間違っています。
コンストラクションで単位時間当たりに完成させられる機能量が低いのか、 あるいは、 機能量あたりの売上が低いのかを、 まず見極めねばなりません。
現場で向上させられるのは、 前者だけなのですから。
・ 派遣プログラマへの支払い給与に対する売上 ?
給与というインプットを投入すると、 派遣契約売上というアウトプットが得られる、 という考え方。
一見、 アウトプット÷インプットで、 生産性を計算してるようですが…
これは、 売値÷仕入れ値 であり、 粗利率を見ているのと同じです。
生産性とは関係ありません。 なにより、 アウトプットとみなしている売上に結びついていなければならないはずの、 生産したモノを認識していないのですから。
・ 見積り時間に対する実績時間 ?
はぁ!? なにそれ?
これを生産性といって憚らないところがあるんですが…
これは予実比 ( 予定と実績の比率 ) を見てるだけで、 いわばどれだけ見積りの精度があったかという指標ですね。
| 固定リンク
「プログラミング」カテゴリの記事
- 【.NET / Win8.1 ストアアプリ】 HttpClient で TLS 1.1 / 1.2 に対応するには(2018.06.17)
- 【VS2017 15.7pv2】 XAML のランタイム ツールに 「ヒートマップ」 が増えた(2018.03.28)
- 【.NET Core】 プロジェクトを作ると 「project.assets.json が見つかりません」 エラー(2018.02.10)
- 【#UWP】 CompactOverlay モード: Picture in Picture というか、「最前面に表示」するウィンドウを作る(2017.08.16)
- 【#UWP】 ビットマップの表示色を変える (Win2D.uwp 経由で Direct2D を使う)(2017.08.23)
「-プログラミング ( 開発プロセス )」カテゴリの記事
- [岡崎図書館サイバー冤罪事件] MDIS って CMMI 認定を受けてる優秀なソフトウェア開発会社なんでしょ?(2010.09.26)
- [本] ソフトウェア見積りのすべて 第2版(2009.06.11)
- Lab Managment ~ VSTS 2010 の "1 Click Deploy"(2009.05.29)
- [わんくま同盟 名古屋勉強会] 第7回 (2009/04/11) の資料(2009.04.11)
- [わんくま同盟 名古屋勉強会] 第7回 (4/11) ~ 見積りの話をしてみよう(2009.03.10)
コメント