2017/06/10
ソフトウェアメトリクスは誰のもの？
偉人と凡人の別は一言にして尽くすべきのみ。かれは人生を簡単にする者なり。これは人生を複雑にする者なり。高山樗牛
ソフトウェア開発の現場では、成果物やプロセスの評価、見積もりのために様々なメトリクスを収集します。メトリクスと一口でいっても、プロダクトメトリクスから、プロセスメトリクス、リソースメトリクスなど様々ありますが、主要なものでは、生産性を示す指標としてソースコード行数をかかった工数でわった
こういったメトリクスメトリクスを測るということ自体は、プロダクトやプロセスを客観的に眺めるために有用ではあるのですが、その特性を理解しておかないと間違った指標として使われることがあります。
ソースコード行数という脆い足場
ソフトウェア開発の現場でよく使われるKSTEP/人月ですが、なんとなく高い方が良いと思われがちかもしれません。果たしてそうでしょうか？実装されたソースコードが同じであれば確かにその通りなのですが、差分開発なのか新規開発なのか、GUIアプリケーションなのか、デバイスドライバなのか、あるいはアルゴリズム実装なのかなど、その特性によって同じ難易度であってもソースコードの開発規模(新規コード or 修正コード)は大きく変わります。さらには、同じ機能実装であっても、プログラマのスキルによって、コードサイズは大きく変わります。例えば、優れたプログラマであれば数百行程度のロジックであっても、スキルの低いプログラマではその何倍もの可読性や効率の悪いコードを書くことがあります。これら両方が1ヶ月かかって開発したコードであったときに、後者の方が生産性が高いというのはありませんよね。つまり、ソースコード行数を基準値にしたメトリクスというのは、絶対的な指標としてはなかなか使いにくいパラメータです。特に、生産性の場合、優れたプログラマほど、少ないコード量を少ない期間でしあげることになるので、スキルの低いプログラマが冗長なコードを長時間かけて書いた時と同じような指標になってしまいます。欠陥密度(欠陥数/ソースコード行数)も同じような課題があります。コメントは多い方がいいのか?
それでも、バグや開発工数は少ないに越したことはないとはいえますが、コメントとなるとそもそも多い方がいいのか少ない方がいいのかというところから意見が別れるところです。現場によっては、不要なコメントが山のように入っているコードがありますが、こういうコメントは害悪でしかありません。コメントないと分からないような実装になっているか、あるいは、無意味なコメントか。このあたりは随分前の投稿にも書きましたが、個人的には、基本的には極力書かない(書かずともわかる)というスタンスにすべきと思いますので、コメント率は少なめ(20%以下くらい)になるのが良いと思います。この辺の話はよく議論のタネになりますが、どちらの意見にも共通するのは、ソースコードを読む人が必要な情報が必要十分な形で伝わるようにするのが大事という点かと思います。メトリクスをとっても意味はない?
ソースコード行数をはじめとして、ソフトウェアメトリクスというのはその基準値そのものがあいまいであったり、単純な量だけでは評価できないという性質をもっています。なので、異なる種類のプロジェクトを比べて、どっちが良いとか悪いとか、あるいは、絶対的な目標値を設定するということには使えません。この辺が正しく理解されず、間違った運用(いろんなプロジェクトを十把一絡げにして目標値を決めるとか、全く別のプロジェクトの成果をベースに見積もりをするとか)がされるのは非常に危険です。では、全く約に立たないかというとそうでもありません。同じようなスキルのメンバーが同じようなソフトウェアを作るのであれば、実績としてのメトリクスを使った見積もりは有効でしょうし、メトリクスをベースに品質を評価(予測)することもできるでしょう。また、別々のプロジェクトが単純比較はできなくても、メトリクス値からプロジェクトの中で何が怒っているのかを予測することもできます。例えば、スキルの低いメンバーと高いメンバーで生産性(KSTEP/人月)がかわらないのであれば、スキルの低いメンバーのソースコードが冗長という可能性が高いのかもしれません。コメント率が著しく低い傾向があったら、いくつかファイルを見ることで、本当に優れたコードでコメントが最小限なのか、単にコメントも何もないわかりにくいコードなのかをチェックするきっかけになります。
このように、単純にメトリクスの数値を絶対的な指標として盲信するのではなく、その裏にある背景(コード品質や担当者のスキル)を把握するツールとして利用することで、メトリクスの価値が発揮されます。
 |
 |
 |
コメント