タダでソフト開発の生産性と品質を上げる方法（1）：意外に使える無料のソースコード測定ツール「SourceMonitor」：山浦恒央の“くみこみ”な話（91）（1/3 ページ）

「“くみこみ”な話」の新シリーズが開幕。テーマは「タダでソフト開発の生産性と品質を上げる方法」です。第1回は、ソースコードを簡単に分析し、計測するフリーツール「SourceMonitor」を紹介します。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

1．はじめに

　2000年以降^（＊1）、ソフトウェアの開発規模が急激に増大し、開発エンジニアへの負担が増加し続けています。この問題を解決するべく、エンジニアの作業を支援するツールが注目を浴びています。世の中には、無料でダウンロードできて使えるツールがたくさんあります。その中には、よくできているものも少なくありません。今シリーズでは、「無料で使えて、意外に役に立つソフトウェア開発ツール」を取り上げます。

＊1）「2000年代」ではなく、「2000年その年」であることにご注意ください。ソフトウェア産業が生まれて以来、新規開発のソースコード行数は、毎年、右肩上がりで急増しました。唯一の例外が1999年です。1998年に比べ、新規開発量は大きく減り、代わりに保守が爆発的に増えました。

　この保守とは、悪名高い「西暦2000年問題（略称Y2K：Year of 2 Kilo）」対策です。Y2K対策が必要なのはCOBOLで書いたプログラムが大部分ですが、COBOLを知っているプログラマーは、白いカラスや、正直な政治家より少なかったので、1999年4月に採用された新人が新入社員教育では、「石器時代の言語」とやゆされていたCOBOLを仕込まれ、即席でY2K保守要員になったりしました。1999年11月になって、「当社のY2K対策をお願いします」と駆け込む「勇者」もいました。

　Y2Kの「本番」は意外に静かでした。1999年12月31日23時50分に鉄道、航空機、船舶、金融システムその他の稼働を止め、2000年1月1日0時を過ぎてから再立ち上げしたのですが、大きな不具合は報告されていません。

　結局、Y2Kでの最大の不具合は、「プログラムの保守体制がきちんと整っていなかった」ことに尽きると思います。1999年に新規開発へ投資できなかったこと、及び、スマートフォンなどの組み込み系製品が急激に普及したため、2000年からプログラムの新規開発が爆発的に増えました。

2．新ツール導入への拒否反応

※写真はイメージです

　ツールに関し、世界中のソフトウェア開発エンジニアに「共通する癖」があります。エンジニアは、「新しもの好き」なので、誰かが新しいツールを仕入れてくると、みんな使いたがります。しかしこれは新しいオモチャみたいなもので、飽きると、昔から使っていたツールへ戻るのです。エンジニアは、「保守的な新しもの好き」であり、新しいツールには、興味はあるものの、「現在のソフトウェア開発プロセスを変えたくない」との拒否反応もあるため、使ってもらうのは大変です。

　あらゆる業界に共通する作業で、ツールの発達により急激に変化したものが少なくありません。典型は、ドキュメント作成業務でしょう。世の中のうまい物が全て砂糖と脂でできているように、あらゆる業界の文書はWordとExcelで作っています。ツールを使用すると、作業負担を軽減できます。

　ソフトウェア業界でも、仕様書はWordで作成し、Excelでテスト項目を作る組織が大半です。個別にテスト自動生成ツールや静的解析ツールなど、効率よく開発できるツールを購入するところもあります。ソフトウェア開発で支援ツールを導入する利点は、以下の3つでしょう。

1. 生産性が向上する
2. ミスをしにくい。ミスをしても、見つけやすい
3. 同じ物を同じ品質で作ることができる

　支援ツールの導入で作業の一部が自動化できるため、生産性が向上し、かつミスが減ります。これは、工場の生産設備に似ており、機材の使用方法を知っていれば、少し訓練するだけで、誰でも同じ物を同じ品質、同じ時間で大量生産が可能になります。

　こんな絶大な利点があるのに、なぜ支援ツールを使わないのでしょうか。よくある問題点は、以下の通りです。

1. ツールのコストが掛かる
2. 全自動化はできない
3. 使いこなすには時間がかかる
4. 変化することへ拒否感がある

　タダでツールが入手できるわけではありません。どんな組織でも、他者のソフトウェアを使用する場合、ライセンス料を払っています。例えば、開発ドキュメントの作成で使用するWordやExcelは、何らかの形でライセンス料を払っています。アメリカ人のエンジニアがよく言う「タダで飯は食えない（There's no free lunch）」です。

　開発支援ツールで全作業が自動化できるわけではありません。テスト自動生成ツールを例にすると、テスト入力は自動生成できても、テスト仕様書や報告書の全てを自動化はできません。その場合、複数のツールを組み合わせることになります。逆に、全て自動化している組織があれば、何かの作業が欠落している危険性があります。

　ツールを使いこなすには、時間と手間がかかります。ツールの効果が大きいほど、習熟には時間がかかります。制御指向のプログラミング言語から、オブジェクト指向へ移行したときの大混乱を思い出してください。WordやExcelでも、数年に1回程度のアップグレード時に、一部ではありますが、使い方を再習得する必要があります。

　変化への拒否感は、エンジニアなら誰でも感じることです。せっかく、最適のプロセスを編み出して適用しているのに、その一部を新しいものに変えるのは面倒ですね。ちなみに、ソフトウェア開発プロセスの成熟度を計測するCMMIでは、最高位のレベル5の定義は、「既に確立した開発プロセスを変える仕組みがある」です（CMMIに関しては、本コラム第2回『組み込みの「懐石料理」でインドの「スパイス」を上手く使う方法（その2）：幻の白いカラスを追い求め、僕らはインドにたどり着く』を参照してください）。開発プロセスを動的に最適化することは、非常に高度な技なのです。

　上記から、ツール導入のポイントは、コストをなるべくかけず、きちんと学習時間を確保して（あるいは、学習しなくても使えるツールを導入し）、適用範囲を守って正しく使用することです。その結果、作業の効率化が期待できます。

　「コストを掛けない」ためには、オープンソースソフトウェアがおススメです。フリーウェアの機運が高まり、フリーツールが多く出回るようになりました。フリーソフトは、性能は市販ツールに劣りますが、機能が絞り込まれており使いやすいことも少なくありません^（＊2）。世の中には、優れたフリーツールなのに、多忙なエンジニアの目に留まらない物が多いようです。これでは、「作った側」と「使う側」の両方がもったいない。本シリーズでは、忙しいエンジニアを対象に、優秀な無料ツールを選び、「目の前に置いておきますので、あとは食べるだけですよ」の状態で提示します。

＊2）出張先の米国で、暇つぶしに家電製品量販店に入って、米国製の冷蔵庫や扇風機を見ていると、いろいろな違いを感じます。痛感するのが、日本の家電品に比べ、米国製は圧倒的に「機能の数」が少ないことです。扇風機は、「on」と「off」だけのものも少なくありません。日本製だと、風量を10段階に調節でき、タイマー、首ふり角度の調整、ゆらぎ風（自然の風のように強弱がある）、チャイルドロックなど、何でもできます。できないのは、ご飯を炊くことぐらいでしょう。

　購入して1週間は、面白がっていろいろな機能を試すのですが、1カ月もすれば毎回使うパターンは決まり、最後は「単に風を送る」という基本機能に落ち着くのです。多機能化が顕著なのが、「シャワートイレ」で、ボタンが3ダースも付いているものもあり、ジェット戦闘機の操縦席に座っている気分です。どれを押せばどうなるのか、さっぱり分かりません。日本語表示が読めない海外の観光客は、下手なボタンを押すと、007のカスタムメイドのスポーツカーみたいに、座席が射出されるのではと怖くなりそうです。

　使いこなせないほどの機能を搭載しないと、日本の消費者は製品に魅力を感じないようです。ソフトウェア製品も同様ですね。ほとんど使わない機能を備えると、開発コストと期間が大きく増えますし、大規模化するとバグも急増します。そろそろ、「基本機能だけ」のあっさりしたソフトウェア開発に回帰する時期ではないでしょうか？