ソフト開発監査ではソフトの設計・実装力の良否を４番目に判定する（後半）
開発技術・設計と実装の能力はレビューチェックリスト、ソースコード解析ツール、自動テストも確認する
前の記事では、ソフト開発監査の対象としてソフト設計・実装に関する技術力を確認する時に、技術エキスパートチームや開発プロセス改善チームの有無と技術情報やバグ情報の共有の仕組みについての確認点について紹介しました。この記事では残る３つの確認点の設計レビューやコードレビューのチェックリスト、ソースコードの静的/動的解析ツール、自動テストについて確認のポイントを紹介します。
設計レビューやコードレビューにチェックリストを使っているか
ソフトの開発作業の成果物、英語でいうとアウトプットは、設計書やソースコードです。そして、これらの成果物の品質を確保するために重要な作業が、設計書のレビューやソースコードのコードレビューです。ソフトの設計や実装は担当するエンジニアの力量に大きく左右されるので、レビューをしないと成果物の品質を一定に保つ事ができません。このあたりも、工場で量産される製品の品質管理とは大きく異なる面です。
皆さんの会社でも、設計レビューやこーどレビューは頻繁に行われていると思います。レビューの方法は、会議形式であったり資料を回覧する形式であったりと色々でしょうし、レビューをする人も同僚だったりチームリーダだったりと、採用しているレビューの方式によって様々です。
ところで、レビューをする人達（レビューアー）は、どんな観点で設計書やソースコードを見て問題点を洗い出しているのでしょうか？ ソフトの設計や実装はソフトエンジニアの頭の中で行われる事なので、エンジニアが何を元にしてどんな判断から今の設計書やコードを書き出したのかを詳しく知る事はできません。
実はレビューの指摘についてもそれと同じで、レビューを行っている人（レビューアー）は設計書やソースコードを見ながら、自分の経験と知識に照らし合わせ問題点を洗い出しているのですが、何を元にどんな判断から指摘しているのかは、知る事はできません。
そのために、レビューアーによって指摘の内容が大きく変わる事もよく有ります。レビューアーによって指摘が異なる事は様々な視点でレビューされているという面では良いのですが、一方でレビューアーの人数が少ないと、指摘に漏れが起きるリスクもあります。
そこで設計レビューやコードレビューを行う時には、こんな点に注意してレビューを行いましょうというレビューのチェックリストを作っている会社も多くあります。チェックリストの形式は様々ですが、ソフトの設計技術領域やテストの技術領域を分類して、各々の分類毎にレビューを行う時の注意点をチェックリストとして整備されている事が多いです。そして、設計レビューやコードレビュ－を行う時にはレビューアーは事前にこのチェックリストを参照して、今回はどんな点に注意してレビューを行うのか方針を決めてからレビューを行います。
このように、レビューのチェックリストを作成してレビューアーで共有する事で、レビューする時の確認項目の漏れを減らしたり、レビューで何を注意すべきかというノウハウを蓄積したりと効果が期待できます。ですので、レビューのチェックリストとしてどんな物を持っているのかは、ソフト開発監査の大切なポイントの一つです。
ソースコードの静的・動的解説ルーツの状況
ソースコードに対するコードレビューとは、実装者とは異なるソフトエンジニアによるソースコードの品質の確認です。これは、新規に実装したり修正したりしたソースコードについては不用意なバグの混入を防ぐ事について効果があります。コードレビューは効果はあるのですが、ソフトア開発のベースラインとして流用するソースコードや購入してきたソースコード、採用したOSS等に対して、全てコードレビューを実施して品質を確認する事は、膨大な工数が掛かるので現実的ではありません。
では、これらのソースコードについてはどうやって品質を確認しましょうか？ 最近のソフト開発は大規模化するに従って、新規に開発や修正するソースコードの全体に対する比率はどんどん小さくなっています。逆に、ベースラインとして他から持ち込まれるソースコードの比率がどんどん大きくなり、このベースラインのソースコードの品質が良くないと、良い品質のソフトを作る事はできません。
そんな時には、ソースコードの静的/動的な解析ツールを使って、できる範囲で品質確認を進めるしか手はありません。静的/動的解析ツールは、それぞれ得意とする技術領域がありますので、ソフトエンジニアによるコードレビューほど網羅的な確認は難しいのですが、確認の速度はその弱点を補ってくれます。静的/動的解析ツールで問題の指摘が多かった部分に絞り込んで、ソフトエンジニアによるコードレビューを行うという使い方もあります。
ソースコードの静的/動的解析ツールは、大規模化した現在のソフト開発では、うまく使いこなす事がとても大切なのですが、良いツールは結構な値段がします。 一つのソフトウエア開発プロジェクトでは、静的/動的解析ツールのライセンスを購入するのは難しい場合も多いので、会社としてあるいは組織として解析ツールを導入して運用するような仕組みが整っているかどうかも、組織としてのソフト開発能力を判定する一つ指標となります。
自動テストの仕組みと利用方法
設計と実装が終わったソースコードは実行イメージへと Build されて、いよいよテストの段階となります。テストについても色々な視点から見る必要があるのですが、組織としての開発技術力という観点からは、自動テストに対する取組がどうなっているかを確認する事も、重要な視点の１つです。
テストの方法としては、作成したテスト項目に従って人手でテストを実施していく人手によるテストと、何等かのテストツールやテスト用スクリプトを使って、自動でテストを実施していく自動テストに分ける事ができます。
手動テストと自動テストはどちらが優れているという訳ではなく、それぞれにメリット・デメリットがあるのでうまく使い分ける必要があります。どんなメリットデメリットがあるかというと、ちょっと乱暴ですが、手動テストはバグを見つける事が得意だけど手間が掛かるテスト、自動テストはバグが無い事を確認できるが新しいバグを見つけるのは苦手だけと手間が少ないテスト、と言えます。
ソフトのライフサイクルを考えると、開発初期ではテスト対象のソフトそのものが機能追加や不具合修正でどんどん変わっていくので、手動テストのほうが作業効率や良いです。あるていど新規機能の開発が収束してバグ修正版のリリースが多くなってくると、バグ修正による二次不具合の確認が主体になってくるので、自動テストのほうが作業効率が良くなってきます。
このように、ソフトのライフサイクルを見て、手動テストと自動テストの適切な比率が変わるのですが、そのような変化に柔軟に対応できるためには、自動テストを使う仕組みや利用方法についての方針やノウハウの蓄積が必要です。このような部分も、組織としてのソフト開発能力を判定する時の１つの指標です。
次はソフトウエア開発監査の方法という視点で紹介します
ここまでの記事では、ソフトの開発監査の対象について、開発プロセス、テスト技術、要件把握技術、設計・実装技術の４つの視点から監査の概要について紹介してきましたが、いかがでしたでしょうか。ソフト開発監査はグータラ親父が勝手に作っている方法なのでなかなか判り難い部分もあると思います。次の記事では、ソフト開発監査の概要について、監査の方法という視点で、もう少し紹介を続けます。