LOCで開発生産性を計測できるわけがないこれだけの理由

LOC (lines of code)の略でソフトウェアプログラムのソースコードをカウントしたものであることは良く知られていることです。誰が思いついたのかわからないけれど、誰かがソフトウエア開発なんだからソフトウェアのdeliverableであるプログラムがどれだけ作成する能力があるのか、第三者にも理解しやすい定量的な数値の指標として扱おうと思いついたときに、前提、考慮を忘れたことがLOCの不幸の始まりなのではないか、と思う事を書いてみます。


LOCは開発生産性であるとするためにおいたであろう前提
LOCを生産性の指標にしようと考えた人は、とても善人であったと思うのです。なぜなら、ソフトウェア開発に関わるエンジニアは、「必要とされるソフトウェアプログラムしか書かない」と思わざる得ないからです。


エンジニアはウンコードを書かない
ソフトウェアプログラム、ソースコードは、一人ひとりのエンジニアの灰色の脳細胞がインプットとなる設計仕様を理解し、アルゴリズムを引用し、業務処理を当てはめ、プログラムとして作成していきます。これは何を示唆しているかというと、一人ひとりのエンジニアの力量、スキルレベルは最良とは言わないけれど、「そのプログラムを作成するに必要な技術レベルを持っている」ということです。


言い換えると、「ウンコードは間違っても書いたりしない。」を暗黙で要求しているんです。


エンジニアはみんなイケているプログラマ
さて、そんなことがあるのか、って話です。開発生産性をLOCで求める場合、補正係数にプログラマの技術レベルを示す係数を持つ場合があります。どのようなものかと言えば、プログラムを書くエンジニアの技術レベルで生産性が左右されるのだから、高い技術レベルを持つエンジニアとスキルレベルの低いエンジニアには同じ単位時間でアウトプットできるソースコードの量が違うだろうから、補正で±の較差をつけよう、というものです。


ちなみに、ソフトウェアのバグは開発生産性には影響しません。ソフトウェアのバグは品質管理でとやかく謂れ、追及されますから。それはそれでまた別の指標値を設定し、ソフトウェアプログラムのソースコードを評価することになります。


話を戻して、現実には、高い技術レベルのエンジニアと経験の少ないスキルレベルの低いエンジニアを混成してチームを作るので、プロジェクトチームのメンバが大規模になればなるほど「1」に近似すると見做されるので実用性が無いように思えるのでそうした補正係数が項目にあっても「1」のままに放置されます。


みんなイケてるエンジニアなんだからチームもね!
その補正係数をその係数の意味合いから正しく利用するなら、編成したプロジェクトチーム全体のスキルレベルと過去の類似したプロジェクトチーム、若しくは、見積もりやプロジェクト計画で必要とする技術レベルと現実のプロジェクトチームを比較して差異を定量化し、その較差を補正係数に当てはめることが必要です。この結果により、スケジュールや人数の加減など調整する必要が出てくるからです。


WBSを設定したんだから全部一から作ってね!
エンジニアのスキルレベルの件のほか、プログラムを書くエンジニアは既存のコードをコピペして使いまわしたりしないという前提もあったでしょう。これは、必要な機能のプログラムを書くというWBSを定義をした時点でエンジニアは必要なプログラムを一から作るという前提を無意識においたのだろうと思います。


コピペするなよ
勿論、共通サブルーチンは別として。出なければソフトウェアのソースコードはコピペして業務処理の違う部分だけを修正するというやり方は安易に想定されるためにコピペして重複したソースコードの部分の扱いについてはなんらか手立てを打っていたと思われるからです。実際にはそうした係数は見当たらないので、それを考慮することで複雑化することを嫌いネグったか、ソフトウェアを開発するエンジニアの良心に期待していたのかもしれません。


全部コードをスクラッチで書くんだよな?
このほか、ソフトウェアのソースコードは全てエンジニアが書くという前提もあったと思われます。というか、後人である私たちが楽をするために開発したフレームワークなどの開発支援ツールが吐き出すコードも想定していなかったことの一つですし、所謂、プログラム言語の世代間による開発生産性の難易度も補正係数として必要な項目ですが言語により開発生産性の較差を定量的に知ることは相当の検証を得ないと当てすっぽと同じレベルになってしまうでしょう。


補正項目多過ぎなので諦めてエンジニア全員イイ人っていうことで……
結局、LOCが開発生産性として有効であるためには、開発するソフトウェアの規模の諸元の数字が計画時で明らかになっている必要があるということです。機能仕様の難易度、開発量、エンジニアの技術レベルの係数、言語の係数、コピペの係数、ウンコード係数……。


他にもあるでしょう。結局、ソフトウェアの開発生産性には様々な前提や制限事項を踏まえて全部エンジニアが性善説ですてきなプログラムしか書かないという前提を置かなければ成り立たないのです。