ソフトウェアの開発プロジェクトでは、品質の確保および開発プロセスの進捗確認を目的としてソフトウェアレビューが実施されます。しかし、システムの規模が大きくなったりチームメンバーの数が多くなったりすると、その分レビューにかかる負担も増えてしまいます。特に短期間の開発プロセスにおいては、開発やテストに十分な時間を割くためにもソフトウェアレビューの効率化は不可欠です。
そこで今回は、ソフトウェアレビューとは何かを解説した上で、ソフトウェアレビューにかかる時間と手間を削減するために、押さえるべきポイントや効率化の手法をご紹介します。
- もくじ
1.ソフトウェアレビューとは
ソフトウェアレビューとは、開発プロセスにおいて開発者が作成した成果物を、上司・同僚・有識者などの関係者が確認し、技術面や品質などの観点からチェック・承認・問題指摘を行う工程です。多くの開発プロセスにおいて行われるソフトウェアレビューは、「マネジメントレビュー」と「成果物レビュー」の2つに分けられます。
・マネジメントレビュー:内部統制やクライアントとの契約上発生する、開発プロセスの管理の一環として行われる取り組み
・成果物レビュー:開発中の不具合や改善点を開発プロセスの早期に見つけるための品質向上のための取り組み
その他、新人の教育目的のレビューやノウハウ蓄積・共有のためのレビュー、採用する技術を評価・決定するためのレビューなど、レビューの目的に応じて形式はさまざまです。
また、社内やチーム内で決めたルールに則って行われるレビューもあれば、草の根の取り組みとして非公式に行われるレビューもあります。
2.ソフトウェアレビューの必要性
場合にもよりますが、ソフトウェアレビューは主に品質向上と内部統制を目的としています。クライアントとの契約上必要な場合は、規定通りのレビュー実施は避けられません。
品質向上の手法としては、ソフトウェアテストを実施することが一般的です。しかし、ソフトウェアの不具合や欠陥は工程の早い段階で検出する方が少ない修正コストで済むため、テスト工程に移る前や開発途中に修正されることが理想です。
開発者やテスト担当者以外の目が入ることで、コーディングやテスト設計に関する属人性の高いミスを予防できます。開発現場は人材の流動性も高く、メンバーの経験値もばらつきがあるため、レビューを通じてチームのノウハウ・経験値をシェアできれば育成スピード向上にもつながるでしょう。
このように、ソフトウェアレビューは、適切に実施すれば品質担保にかかるコスト削減と品質向上に大いに貢献できる手法だと言えます。
3.ソフトウェアレビューは時間と手間がかかる
ソフトウェアレビューは品質向上貢献できるというメリットがありますが、手間と時間がかかるというデメリットもあります。例えば、以下3つのような問題点が挙げられます。
3-1 関係者の日程調整
レビュー参加者の日程調整は非常に負担がかかります。特に内部統制のためのレビューでマネージャーや開発責任者を参加させる場合はなおさらです。レビュー会議開催に伴うコストを抑えるためには、会議の内容や時間の使い方を十分に検討する必要があります。
3-2 レビュー目的の認識齟齬
レビューを取り入れることは良い取り組みですが、レビューの目的が適切に設定・共有されない場合があります。この場合、参加者もどんな説明や指摘をして良いか分からず、時間が伸びたり実施回数が増えたりしてしまいます。
3-3 非効率な非公式レビューの実施
非公式のレビューを自主的に行う開発者もいるでしょう。しかし、参加者がどんな内容についてレビューしてもらうか意識していなければ、単なる雑談になってしまい、期待する効果が得られないことも考えられます。
4.ソフトウェアレビューを効率化する方法
先ほど述べたように、ソフトウェアレビューは手間と時間がかかる点が頭の痛いところです。ソフトウェアレビューを効率化する方法には、欠陥検出の効率化と欠陥指摘の効率化の2つが挙げられます。ここからは、それぞれのポイントを踏まえご説明します。
4-1 「欠陥検出」を効率化するポイント
「欠陥検出」とは、ソフトウェアの問題やリスクを、レビューを通じて見つけ出すことを指します。
欠陥検出を効率化するためのポイントは主に以下の2点です。
|
まず工夫できるのは、レビューごとに目的と役割を決め、できる限り重複なく広範囲の確認を行うということです。
開発プロセスにおいて、通常レビューは参加者や規模、実施フェーズを変えて複数回行います。それぞれのレビューの位置付けや実施目的を最初に設定することにより、レビュアー間の確認内容や箇所の重複をなくすことが可能です。開発フェーズに応じたレビュー目的の設定と、レビュアーの専門分野や経験に特化した役割分担をすれば、大幅な不具合の検出率向上が期待できます。
また、検出シナリオを工夫することも有効です。
検出シナリオとは、レビューで何をどのように確認するか記述したものです。例えば開発現場では、新規開発や通常の修正を行う際に、起こりうる問題を検出するための確認事項をドキュメントや内部ルールとして共有している場合があります。これが検出シナリオに当たるとも言えます。
効率の良い検出シナリオにするためには、修正の影響範囲の調査方法や、確認するフロー自体を省略する、もしくは検出シナリオにおいて確認すべき箇所を省略することが効果的です。
例えば、検出シナリオに「新規開発の時には通常システムのパフォーマンスを検証する」と定めていても、修正対象の機能の利用シーンがきわめて限られる場合は、パフォーマンス不備を検出することにそれほどメリットがない可能性があります。このような場合には、パフォーマンスについてはテストでもソフトウェアレビューでも取り上げないという選択肢も考えられます。
ただし、検出シナリオが面倒だから省略する、といった判断は避けるべきです。あくまで「メリットとコストを勘案した優先度」に基づいて判断するようにしましょう。
4-2 「欠陥指摘」の効率化するポイント
「欠陥指摘」とは、レビュー会議の中でレビュアーが問題や疑問を指摘することを指します。欠陥検出とは異なり、レビューの形式や進め方に焦点を当てた概念です。
欠陥指摘を効率化するためのポイントは主に以下の2点です。
|
まずレビュー時間を有効活用する方法として、メールやチャット、資料共有による事前レビューが挙げられます。レビュー全体をテキストベースで行う方法もあれば、内容説明・共有の時間を削減するために資料を事前配布する方法もあります。普段の会議と同様ですが、レビュー会議で行うべき内容を精査することが最優先事項となります。
また、説明資料のフォーマットの統一も効果的です。各自が内容を理解するためにどの部分を読めば良いかすぐに分かり、レビュー会議に関係ない指摘をする必要はなくなります。レビュー対象となるレビュイーの書類の作成しやすさも重要ではありますが、レビュー資料は参加者との共通認識を最も取りやすい形に統一されることが理想です。
レビューの場では、レビュイーとレビュアー、またレビュアー同士が協力して問題検出と参加者内での共有、解決策の提示が求められます。ソフトウェアレビューがお互いの粗探しや、解決に結びつかない意見の交換に終始してしまうと、根本的な課題の解決にはつながりません。問題点と併せて解決案の議論を行ったり、有識者の意見を取り入れたりして、建設的なレビューが行われるようにしましょう。
まとめ
今回は、ソフトウェアレビューの必要性と効率化ついてご紹介しました。一般的にソフトウェアレビューは「内部統制」「品質向上」の取り組みとして実施されますが、レビュイー・レビュアー双方にとって時間と手間がかかる工程です。しかし、レビューの目的を適切に設定し、参加者の役割や議論するトピックを優先度の応じて絞り込むことで、レビューの効率化が期待できます。
限られた工数と開発期間を有効利用し、ソフトウェアレビューのメリットを最大限発揮できるような開発プロセスになるよう、ぜひ工夫してみてください。