ソースコードQA：それはもはや開発者だけのものではありません
公開: 2022-03-1120年前、私が自動車業界で働いていたとき、ある工場のディレクターはよく「車を作る日は1日ありますが、お客様には車を検査する生涯があります」と言っていました。 品質が最も重要でした。 実際、自動車や建設業界などのより成熟したセクターでは、品質保証は製品開発プロセスに体系的に統合されている重要な考慮事項です。 これは確かに保険会社からの圧力によって引き起こされていますが、工場長が指摘したように、結果として得られる製品の寿命によっても決定されます。
ただし、ソフトウェアに関しては、ライフサイクルの短縮と継続的なアップグレードにより、ソースコードの整合性が見過ごされ、新機能、高度な機能、および市場投入のスピードが優先されることがよくあります。 製品管理者は、ソースコードの品質保証の優先順位を下げるか、開発者に任せて処理することがよくありますが、それは製品の運命を決定する上で最も重要な要素の1つです。 製品開発の強固な基盤を構築し、リスクを排除することを懸念する製品マネージャーにとって、ソースコードの品質の体系的な評価を定義および実装することが不可欠です。
「品質」の定義
ソースコードのQAプロセスを適切に評価して制定する方法を検討する前に、ソフトウェア開発のコンテキストで「品質」が何を意味するかを判断することが重要です。 これは複雑で多面的な問題ですが、簡単にするために、品質とは、消費者の満足度を損なったり、開発会社のビジネスモデルを危険にさらしたりすることなく、製品の価値提案をサポートするソースコードを指すと言えます。
言い換えれば、高品質のソースコードは、製品の機能仕様を正確に実装し、非機能要件を満たし、消費者の満足を保証し、セキュリティと法的リスクを最小限に抑え、手頃な価格で維持および拡張できます。
ソフトウェアがどれほど広く迅速に配布されているかを考えると、ソフトウェアの欠陥の影響は重大なものになる可能性があります。 バグやコードの複雑さなどの問題は、製品の採用を妨げ、ソフトウェア資産管理（SAM）のコストを増加させることで企業の収益を損なう可能性があります。一方、セキュリティ違反やライセンスコンプライアンス違反は、企業の評判に影響を与え、法的な懸念を引き起こす可能性があります。 ソフトウェアの欠陥が壊滅的な結果をもたらさない場合でも、それらには否定できないコストがかかります。 2018年のレポートで、ソフトウェア会社Tricentisは、314社からの606のソフトウェア障害が、前年の1.7兆ドルの収益損失を占めていることを発見しました。 発表されたばかりの2020年のレポートでは、CISQは、米国の低品質ソフトウェアのコストを2.08兆ドルと見積もっており、技術的負債によって発生する将来のコストはさらに1.31兆ドルと推定されています。 これらの数値は、以前の介入で軽減できます。 製品設計中に問題を解決するための平均コストは、テスト中に同じ問題を解決するよりも大幅に低くなります。これは、展開後に問題を解決するよりも指数関数的に低くなります。
ホットポテトの取り扱い
リスクはあるものの、ソフトウェア開発における品質保証は断片的に扱われ、他の業界で採用されているプロアクティブなアプローチではなく、リアクティブなアプローチが特徴です。 ソースコードの品質の所有権は、さまざまな機能の共同責任と見なされるべき場合に争われます。 製品マネージャーは品質をオーバーヘッドではなく影響力のある機能と見なす必要があり、経営幹部は品質状態に注意を払い、それに投資する必要があります。エンジニアリング部門はコードクリーニングを「ホットポテト」として扱うことに抵抗する必要があります。
これらの委任の課題をさらに複雑にしているのは、既存の方法論とツールが全体としてコード品質の問題に対処できないという事実です。 継続的インテグレーション/継続的デリバリーの方法論を使用すると、低品質のコードの影響が軽減されますが、CI / CDが徹底的で全体的な品質分析に基づいていない限り、ほとんどの危険を効果的に予測して対処することはできません。 QAテスト、アプリケーションセキュリティ、およびライセンスコンプライアンスを担当するチームは、問題の一部のみを解決し、非機能要件または機能要件の一部のみを評価するように設計されたツールを使用して、サイロで作業します。
プロダクトマネージャーの役割を検討する
ソースコードの品質は、製品設計中およびソフトウェア開発ライフサイクル全体を通じて製品マネージャーが直面する多くのジレンマに影響を及ぼします。 技術的債務は重いオーバーヘッドです。 低品質のコードベースで機能を追加および変更することは、より困難で費用がかかります。既存のコードの複雑さをサポートするには、新製品の開発に費やす可能性のある時間とリソースの多大な投資が必要です。 製品マネージャーは、リスクと市場投入のスピードのバランスを継続的に取っているため、次のような質問を検討する必要があります。
- OSS（オープンソースソフトウェア）ライブラリを使用する必要がありますか、それとも機能を最初から構築する必要がありますか？ 選択したライブラリに関連付けられているライセンスと潜在的な責任は何ですか？
- どの技術スタックが最も安全ですか？ どちらが高速で低コストの開発サイクルを保証しますか？
- アプリの構成可能性（高いコスト/時間遅延）を優先する必要がありますか、それともカスタマイズされたバージョン（高いメンテナンスコスト/スケーラビリティの欠如）を実装する必要がありますか？
- 高いコード品質を維持し、リスクを最小限に抑え、エンジニアリングコストを低く抑えながら、新しく取得したデジタル製品を統合することはどの程度実現可能でしょうか。
これらの質問への回答は、ビジネスの成果と製品マネージャー自身の評判に深刻な影響を与える可能性がありますが、多くの場合、厳密な調査や確かな指標ではなく、直感や過去の経験に基づいて決定が下されます。 徹底したソフトウェア品質評価プロセスは、意思決定に必要なデータを提供するだけでなく、利害関係者を調整し、信頼を構築し、優先順位が明確で合意された透明性の文化に貢献します。
7ステップのプロセスの実装
完全なソースコード品質評価プロセスにより、より大きな問題のいくつかの孤立した症状ではなく、品質決定の完全なセットを考慮した診断が行われます。 以下に示す7段階の方法は、プロセス改善に関するCISQの推奨事項に沿ったものであり、次の目的を促進することを目的としています。
- 根本原因に近い問題を見つけ、測定し、修正します。
- 全体的な品質測定に基づいて、ソフトウェアの品質改善に賢く投資します。
- 測定の完全なセットを分析し、最良で最も費用効果の高い改善を特定することにより、問題に取り組みます。
- 所有権、保守、およびライセンス/セキュリティ規制の調整のコストを含む、ソフトウェア製品の完全なコストを考慮してください。
- SDLC全体でコード品質を監視して、不愉快な驚きを防ぎます。
1.製品からコードへのマッピング：製品の機能をコードベースまでさかのぼって追跡することは明らかな最初のステップのように思えるかもしれませんが、開発の複雑さが増す速度を考えると、必ずしも単純ではありません。 状況によっては、製品のコードが複数のリポジトリに分割されている場合もあれば、複数の製品が同じリポジトリを共有している場合もあります。 さらに評価を行う前に、製品のコードの特定の部分を収容するさまざまな場所を特定する必要があります。
2.技術スタック分析：このステップでは、使用されるさまざまなプログラミング言語と開発ツール、ファイルあたりのコメントの割合、自動生成されたコードの割合、平均開発コストなどが考慮されます。
推奨ツール：cloc
代替案：東経、scc、sloccount
3.バージョン分析：コードベースのすべてのバージョンを識別し、類似性を計算することを含む監査のこの部分の結果に基づいて、バージョンをマージし、重複を排除することができます。 この手順は、バグスポット（ホットスポット）分析と組み合わせることができます。バグスポット（ホットスポット）分析では、最も頻繁に改訂され、メンテナンスコストが高くなる傾向があるコードのトリッキーな部分を特定します。
推奨ツール：cloc、scc、sloccount
4.自動コードレビュー：この検査では、コードの欠陥、プログラミング慣行違反、およびハードコードされたトークン、長いメソッド、重複などの危険な要素を調査します。 このプロセス用に選択されるツールは、上記の技術スタックとバージョン分析の結果によって異なります。
推奨ツール：SonarQube、Codacy
代替案：RIPS、Veracode、Micro Focus、Parasoft、その他多数。 もう1つのオプションは、ユニバーサルコード検索ソリューションであるSourcegraphです。
5.静的セキュリティ分析：このステップは、静的アプリケーションセキュリティテスト（SAST）とも呼ばれ、潜在的なアプリケーションセキュリティの脆弱性を調査および特定します。 利用可能なツールの大部分は、OWASPやSANSなどの組織によって特定された頻繁に発生するセキュリティ上の懸念に対してコードをスキャンします。
推奨ツール：WhiteSource、Snyk、Coverity
代替案：SonarQube、Reshift、Kiuwan、Veracode
6.ソフトウェアコンポーネント分析（SCA）/ライセンスコンプライアンス分析：このレビューでは、コードに直接または間接的にリンクされているオープンソースライブラリ、これらの各ライブラリを保護するライセンス、およびこれらの各ライセンスに関連付けられている権限を特定します。
推奨ツール：Snyk、WhiteSource、Black Duck
代替案：FOSSA、Sonatype、その他
7.ビジネスリスク分析：この最終的な測定では、ソースコードの品質ステータスがビジネスに与える影響を完全に理解するために、前の手順で収集した情報を統合します。 分析の結果、製品マネージャー、プロジェクトマネージャー、エンジニアリングチーム、Cスイートの幹部などの利害関係者に、リスクを評価し、十分な情報に基づいて製品を決定するために必要な詳細を提供する包括的なレポートが作成されます。
この評価プロセスの前のステップは、幅広いオープンソースおよび商用製品を介して自動化および促進できますが、完全な7ステップのプロセスまたはその結果の集約をサポートする既存のツールはありません。 このデータのコンパイルは退屈で時間のかかる作業であるため、無計画に実行されるか、完全にスキップされ、開発プロセスを危険にさらす可能性があります。 これは、徹底的なソフトウェア検査プロセスがしばしば崩壊するポイントであり、この最後のステップは、おそらく評価プロセスで最も重要なステップになります。
適切なツールの選択
ソフトウェアの品質は製品に影響を与え、したがってビジネスの成果に影響を与えますが、ツールの選択は通常、開発部門に委任され、開発者以外の人が結果を解釈するのは難しい場合があります。 製品マネージャーは、透過的でアクセス可能なQAプロセスを保証するツールの選択に積極的に関与する必要があります。 評価のさまざまなステップに対応する特定のツールが上記で提案されていますが、ツールの選択プロセスで考慮すべき一般的な考慮事項がいくつかあります。
- サポートされている技術スタック：利用可能な製品の大部分は、開発ツールの小さなセットのみをサポートしており、部分的または誤解を招くレポートになる可能性があることに注意してください。
- インストールの簡素化：インストールプロセスが複雑なスクリプトに基づいているツールは、多大なエンジニアリング投資を必要とする場合があります。
- レポート：主要な問題を特定し、修正の推奨事項を提供する、詳細で適切に構造化されたレポートをエクスポートするツールを優先する必要があります。
- 統合：使用されている他の開発および管理ツールと簡単に統合できるように、ツールをスクリーニングする必要があります。
- 価格：ツールに包括的な価格表が付属することはめったにないため、関連する投資を慎重に検討することが重要です。 さまざまな価格設定モデルでは、通常、チームの人数、コードサイズ、関連する開発ツールなどが考慮されます。
- 展開：オンプレミスとクラウドの展開を比較検討するときは、セキュリティなどの要素を考慮してください。 たとえば、評価対象の製品が機密データまたは機密データを処理する場合、オンプレミスツールおよびブラインド監査アプローチ（FOSSID）を使用するツールが望ましい場合があります。
それを続ける
リスクが特定され、系統的に分析されると、製品マネージャーは優先順位付けと欠陥のトリアージに関してより正確に思慮深い決定を下すことができます。 チームを再編成し、最も緊急または一般的な問題に対処するためにリソースを割り当てることができます。 リスクの高いライセンス違反のような「ショーストッパー」は、重大度の低い欠陥よりも優先され、コードベースのサイズと複雑さの軽減に寄与するアクティビティに重点が置かれます。
ただし、これは1回限りのプロセスではありません。 ソフトウェア品質の測定と監視は、SDLC全体で継続的に行う必要があります。 完全な7段階の評価を定期的に実施し、各分析の直後に品質改善の取り組みを開始する必要があります。 新しいリスクポイントの特定が早ければ早いほど、救済策は安価になり、フォールアウトはより制限されます。 ソースコードの品質評価を製品開発プロセスの中心にすることで、チームに焦点を合わせ、利害関係者を調整し、リスクを軽減し、製品に成功の最高のチャンスを与えます。これがすべての製品マネージャーのビジネスです。