連載ALM（3）ソフトウェアの利用者として開発に参画する

  • ゆもつよ｜

現代のソフトウェア開発の特徴

本連載の初回でソフトウェア品質の相対性について言及し、また、前回では目的と手段の階層構造とサイロ化の現象について説明しました。これら2回の連載を通じて筆者が伝えたかったポイントの1つは、目的をどのレベルでとらえるかによって開発したソフトウェアの品質に対する判断基準が変わってくるということです。

またもう1つのポイントとして、階層構造の下位のレベルがサイロになってしまうと開発の本来目的を見失い、結果として、ビジネス価値の高いソフトウェアを仕上げる作業が遅れるとも述べました。実のところ、この問題は現代のソフトウェア開発に特徴的に見られている問題でもあります。

現代のソフトウェア開発では、ゼロからすべてを作るケースはほとんどなく、大抵は、何年も（ときには何十年も）前に開発したシステムを拡張、新たなビジネス・ニーズに対応させています。また、「アプリケーションの近代化」と呼ばれるシステム刷新を行うにしても、購入したミドルウェアを用いたり、出来合いのサービスを利用したりしています。

　このアプローチでは、基本的に足りないパーツだけを作れば良いことから、新規に記述すべきソースコードの量が減り、短期間かつ少ない工数でソフトウェア開発が行えるように見えます。しかしその反面、短期間での開発を行うようアサインされた開発者は、全体を理解する時間が取れないまま、パーツを開発しなければならなくなります。つまり、全体がはっきり見えない中で、全体の一部として機能するソフトウェアを迅速に開発する必要に迫られるということです。

適切な情報収集と整理が成功のカギを握る

全体が見えないと人は不安になり、その不安を払拭するために無暗に動き回ろうとします。例えば、今まで訪れたことのない街に一人で放り出された自分を想像してみてください。そのようなとき、おそらくあなたは手元にある情報を頼りにしながら、とにかく移動を始めるでしょう。また、移動する中で、出発地点からどれだけ進んだのかを何らかの手がかりを基に判断しようとするに違いありません。

しかし、いくら動いたところで、今いる場所が目標地点からどの程度離れているかが分からなければ、精神的な不安は払拭されません。

このような状況の中で求められるのは、適切な情報を収集したり、整理された情報を閲覧したりすることで、自分の位置を確認することにほかならないのです。

情報収集の要諦はテストとレビュー

ソフトウェア開発に話を戻すと、手元にある情報を頼りに動くことは、すなわち、利用者側（発注元）に提示した仕様に合わせてコーディングを行うことと等しいと言えるでしょう。また、コーディング作業を終えて、開発者自身がプログラムの動作確認を行うことは、自分の実装作業がどの程度進んだかを判断する指標となります。

そして、自分の今いる場所が到達地点からどの程度離れているかは、ソフトウェア開発で言えば、「そのソフトウェアが本来提供すべき価値をどの程度達成しているか」を判断すことを意味し、それを見定める方法としては、レビューあるいはテストという手法が挙げられます。言い換えれば、レビューやテストをうまく行うことが、ソフトウェア開発における適切な情報の収集につながるというわけです。

一からすべてを作るのではなく、現行ソフトウェアのバージョンアップ開発を行う場合でも、開発コストが思ったように減らないのは、実は適切な情報収集が行えていないことに起因している場合が少なくありません。具体的には、全体が見えない不安から本来必要のないところまでテストを行ってしまったり、テストするポイントを見極め切れない中でテスト漏れを生じさせ、のちの重大な品質トラブルを引き起こしたりといった具合です。このような状況に陥ると、当然、開発コストはかさんでいきます。また、そのコストを下げるためにオフショア開発を行ったとしても、真の問題解決にはつながりません。そのため、オフショア開発を行っても一向にコストが下がらないという問題に直面することになるのです。

ソフトウェアの利用側に情報を集約させる

もちろん、闇雲に情報を集めても、情報の錯綜と混乱を招くだけです。そこで重要になるのが、情報を整理して閲覧できるようにすることです。

そのための具体的な方法としては、テスト結果の集計をリアルタイムに行うことや集計した情報をグラフ化して見せることなどが挙げられるでしょう。ただし、何でもグラフにすればいいわけではありません。作成されたグラフを基に、意思決定者が何らかの判断を下せるようでなければ意味を成さないのです。

ソフトウェア開発においては、ソフトウェアの価値を享受する利用者が最終的な意思決定者とならなくてはなりません。したがって、利用者がソフトウェアの価値到達度を自ら判定できるよう、積極的に情報収集を行い、閲覧と価値判断が可能なかたちに整理しておくことが大切です。換言すれば、テストやレビューの結果を利用者の元に集約し、全体像を俯瞰しながら価値判断が下せるようにする必要があるということです。また、そうすることが開発コストの無駄な増大を防ぐポイントとなります。

　以上、今回はソフトウェア開発で利用者が関与するポイントとして、テストやレビューの情報を利用者が自ら集約し判断を行うべきであることを論じました。次回は、利用者による判断に役立つ具体的なテストのやり方について解説する予定です。

※　これは2011年にCIOオンラインにて「【HP特別連載コラム】探求！ビジネス成長とIT革新

　シリーズ3：ビジネス成果をもたらすソフトウェアを開発するために（3）」として連載したものを転載したものです。

カテゴリ: