品質とセキュリティの向上のために、 ソフトウェア開発のリーダーが 知っておくべき5つの指針

品質とセキュリティの向上のために、 ソフトウェア開発のリーダーが 知っておくべき5つの指針 高価値なアプリケーションを提供するために ソフトウェア開発チームのリーダーは、常にさまざまな課題に直面しながら、適切に対処して いくことが求められます。このことは昔も今も変わることはありません。しかし、かつてはシン プルだったソフトウェアの構築も、多様なプロセス手法やインフラに関する多くの選択肢が 登場したことに加え、スタッフのスキル不足やステークホルダーのニーズへの対応といった これまでにない複雑な要素が絡み合うことで、現在は混沌とした状況になりつつあります。

品質とセキュリティの向上のために、ソフトウェア開発のリーダーが知っておくべき5つの指針 高価値なアプリケーションを提供するために ソフトウェア開発チームのリーダーは、常にさまざまな課題に直面しながら、適切に対処していくことが求められま す。このことは昔も今も変わることはありません。しかし、かつてはシンプルだったソフトウェアの構築も、多様なプロ セス手法やインフラに関する多くの選択肢が登場したことに加え、スタッフのスキル不足やステークホルダーのニー ズへの対応といったこれまでにない複雑な要素が絡み合うことで、現在は混沌とした状況になりつつあります。 こうした状況は開発チームにとってますます大きなプレッシャーとなり、チームのメンバーの誰もが納期に追われ、 要件や仕様の準拠に悩まされるだけでなく、自らのスキル不足にも直面しています。これらすべての課題に効果的に 対処することが、開発リーダーに求められる重要な役割の1つです。多くのプロジェクトを成功に導いた経験のあるリ ーダーは、決して自らが最も優れたプログラマーやテスターになろうとはしません。彼らは常に最終的な成果や組織 への影響を最大化するための方法を模索しながら、それを実践しています。そうすることによって、高品質でセキュア なコードをチームのメンバーの誰もが提供できる体制を維持しているのです。 とはいえ、ソフトウェアの開発・提供においては、多くの側面で障害の発生が避けられません。これらを克服して高価 値なアプリケーションを提供するためには、チームはまず、以下に示す5つの指針に従って取り組みを進めることが 重要です。 1．要件・仕様へ準拠 2．非効率的なプロセスの排除 3．致命的なバグの解決 4．チームの成長のサポート 5．データドリブンな意思決定 要件・仕様への準拠 要件や仕様を正確に把握することなくプログラミングを進めることは、いわば売れない製品にバグを付け加えるよう なものです。リーダーは常に目標を正確に把握したうえで、それに向けた対策を講じ、確実に実践していく必要があり ます。これはチームの内部に限定した要件であれば簡単に対処できますが、そうではなく組織のソフトウェアプロセ ス部門が規定したコードに関するセキュリティルールや、顧客の仕様、規格／規制など、外部の要件や仕様に対応し なければならない場合には特に困難です。 たとえば、組み込みソフトの場合、顧客が最も頻繁に指定する規格はMISRAのコーディングセキュリティガイドライン です。これにはセキュリティエラーによるリスク軽減を目的としたプログラミングのルールが定義されていますが、他 の業界標準と同様にこれらのガイドラインは曖昧な点もあり、開発者を混乱させます。こうした規格に準拠したコード のテスト作業は、コードを一から作成する場合と同等の労力を要することも珍しくありません。 特定の要件に対する準拠の有無を検証するには、自動テストが効果的です。事前に定義したテストを定期的に実行 すれば、テストケースの調査やその作成に要する初期費用を削減することができます。また、ヒューマンエラーの原 因を取り除くことで一貫性と再現性が確保されるようになります。 MISRA規格においても、自動テストのための 静的解析ツールの利用が推奨されています。 “定められたルールに準拠していることをテストするための手段は常に必要です。その最適な手段と言えるのが、市販の静的解析ツールの活用であり、組織はこ れらのツールを少なくとも1つは利用することが推奨されます」”*1 *1 MISRA C規格、セクション4.3.1 roguewave.com 2

品質とセキュリティの向上のために、ソフトウェア開発のリーダーが知っておくべき5つの指針 内製のツールではなく市販のツールを利用する最大のメリットは、チームのメンバーがテストに必要な知識の獲得 や、テストの実行に余計なコストや労力をかけずに済むようになることです。市販のツールを利用することで、チーム はより高価値なアプリケーションの開発に注力できるようになります。 非効率なプロセスの排除 アーキテクチャの設計から実装に至るまで、高度にクリエイティブなプロセスであるソフトウェア開発において、開発 チームはスピーディな製造ラインというよりも、むしろフレキシブルに編成されたスポーツチームのように機能しま す。個々のメンバーはいわば優れたアスリートであり、そこで求められるリーダーの役割は、リリースの期限や製品の 仕様を満たすために、メンバーのアイデア、スキルなどの価値を活かし、彼らの担当する領域を最適化することです。 しかし現実に目を向ければ、効率化は非常に難しい課題です。Forrester Research社の調査では、チームが費やす 時間の68パーセント以上は、開発フェーズでやむを得ず発生する待ち時間であることが明らかになっています（図1 参照）。開発者はテストが完了するまで待機し、テスターはITリソースが解放されるのを待ち、そしてITチームは開発 チームのニーズの合意が得られるまで待つことになります。 - 改善するべきバリューストリーム： LT： リードタイム アプリケーション納期 PT： プロセスタイム ビジネス - 改善率： LTで75％ %CA： 完了正確率 - 期待される効果： 製品化までの時間 VA： 付加価値のついたプロセスタイム 顧客要求 NVA： 付加価値なし（無駄） アイデアの提出 ビジネスとしてアイデアを議論 要求書作成 設計指定 開発・統合 ビルド アカウントチーム ビジネスアナリスト/ ビジネスアナリスト 開発者 開発者 開発者 ビジネスパートナー LT：2日 LT：3日 LT：5日 LT：30日 LT：30日 LT：3日 PT：1日 PT：3時間 PT：5日 PT：7日 PT：20日 PT：1時間 %CA：80 %CA：90 %CA：100 %CA：80 %CA：90 %CA：100 試験（TCoE） ステージ デプロイ リードタイムが123日でOps プロセスタイムが39日、 ということは、 テスター Ops Ops 顧客に価値を提供 84日は何もしていなかったと いうことになります.... LT：40日 LT：5日 LT：5日 総LT：123日 妨げているのは何でしょう？ PT：5日 PT：2時間 PT：2時間 総PT：39日 %CA：60 %CA：100 %CA：90 総サイクルタイム：60％ 図1：無駄を視覚的に識別するためのバリューストリームを定義して、顧客価値にフォーカスする*2 *2「 ソフトウェアデリバリーを加速してデジタル変革を推進」 Forrester、2017年3月 roguewave.com 3

品質とセキュリティの向上のために、ソフトウェア開発のリーダーが知っておくべき5つの指針 各フェーズにおいても、さまざまな障害があります。顧客要件の認識不足が招く手動テストへの依存、あるいは自動 デプロイツールの欠如は、チームの俊敏性の低下やコスト肥大を招く大きな障害となります。そして、これらは最終 的にリリースの遅延、品質の低下、またセキュリティホールの放置といった大きな代償にもつながりかねません。 チームは、次の3つの対策を実践することにより、無駄を減らして生産性を向上させることができます。 1. 明確な計画に基づいて実行する。混乱や事前の調整が不十分だったことによる時間の浪費を無くすこと で、チームは自らのアイデアを確実に実行に移せるようになります。たとえば、確立されたコーディングガ イドラインを使えば、曖昧さや不統一性を回避できます。 2. デバッグおよびテストの負荷を軽減する。 コードの修正にかかる時間を減らすことができれば、組織の 価値を高めるための取り組みにより多くの時間を費やせます。ここで効果を発揮するのが、自動テスト ツールです。 3. 可能な限り迅速にコードをビルドし、統合する。変更を小さく、モジュール化すれば、リリースへの新機能 の追加あるいは機能を削除する際に、チーム全体への影響を最小限に抑えることができます。 優先順位が明確で、自動化により迅速に対応できるプロセスやツールを使うことが、これらの目標を達成するための 最も効率的な手段と言えます。 “優れた業績を達成できるIT企業は、そうでない企業と比較して、障害に見舞われる確率は60分の1、また障害から回復するスピードも168倍です。さらに、リード タイムは200分の1と短く、デプロイの頻度も30倍です”*3 致命的なバグの解決 どの問題やバグから対処すべきかを判断するよりも、複雑で総合的なテストフレームワークの構築に、より多くの時 間や労力が費やされています。それが開発者が机上で実施する単体テストであれ、変更管理委員会のミーティング への参加であれ、問題となるのは「開発者の1日の時間の中で、どれくらいの時間をバグの発見や修正にあてるべき か？」ということです。 本来、開発者はバグのトリアージや優先順位付けではなく、高品質でセキュアなコードの設計・構築に集中すべきで あり、開発リーダーや製品管理者はバグのランク付けにとらわれ過ぎてはいけません。また、ランク付けに関する多く の意思決定がそうであるように、エンドユーザーの品質が「交渉」によって左右されることも避けるべきです。致命的 なバグに対する唯一の解決策は修正することであり、そのためには致命的なバグを発見・修正するための時間を設 けることが重要になります。 *3「 2015年版 DevOpsの現状」 Puppet Labs, 2015年 roguewave.com 4

品質とセキュリティの向上のために、ソフトウェア開発のリーダーが知っておくべき5つの指針 開発者がバグのトリアージに費やす時間を軽減すると同時に、ソリューションへ注力する時間を確保するためには、 どのようにすれば良いでしょうか？ その最も一般的な方法を以下に示します。 1. ユーザーエクスペリエンスの確保に致命的な影響をもたらすバグを修正する。このレベルのバグがある 場合には、ユーザーはタスクを実行することができず、不具合が報告される可能性が高まります。 2. すべてのセキュリティバグに対応する。ユーザーのデータが関係している場合、予期せぬ損害賠償や責 任から組織を守るためには、それらのデータをバグにさらさないことが重要です。 3. 最も発生頻度の高いバグを特定する。これらのバグは顧客満足度やセンチメントに大きな影響をもたら し、リリース後に余儀なくされるバグの切り分けやデバッグ、修正といった計画外のコストを発生させる 原因となります。 これらの基準に従って分類・優先順位付けを行う手法やツールを導入し、バグのトリアージに費やす時間やフラスト レーションを排除するには、長期的な取り組みが求められます。 チームの成長のサポート ユーザーの要求が高まるにつれて機能や複雑さが増大し、結果としてリリースにより多くの時間を要するようにな る―。これはソフトウェア開発リーダーなら誰もが認識していることです。この問題に対処するためには、どこかの時 点でより多くの人的リソースやツールを投入して、品質やセキュリティ面での目標を維持しながらもデリバリーを加 速させる必要があります。 この課題に関して、最も注目を集めているキーワードが「DevOps」、すなわち継続的インテグレーション（CI）です。こ れはチームのメンバーが1日の中で何度も頻繁に新しいコードを統合する開発手法で、各統合を行う際は自動化さ れたビルドおよびテストプロセスを実行して、できる限り早い段階で欠陥を特定し、ステータスのレポーティングを行 います。 CIの価値は、手作業に依存したテストを回避して、各統合で可能な限り多くの問題を検出することによって最大化さ れます。自動化にフォーカスすれば、テストの幅広さや深さ、再現性を向上させると同時に、開発者は機能の強化に 注力できるようになります。また、手作業に依存したテストに関しては、次のような点も指摘されています。 “人手の介在は、ヒューマンエラーや再現不能なプロセスの原因となります。これにより俊敏性が最も低下する2つの領域がテストとデプロイであり、その場合、 継続的なインテグレーションとデリバリーを迅速に行うことができません。また、手 動のテストは欠陥や計画外の作業を発生させる原因にもなります *4 つまり、これは開発・テストのインフラは実際のCIプロセスに合わせて拡張できなければ”ならないことを意味します。 チームの作業負担を軽減するためには、新しいCIエージェントにデプロイするビルドツールおよびテストツールの選 択が容易に行える必要があります。また、他の開発者に起因する欠陥を除外して、特定のコード変更に関する欠陥の みを担当の開発者に戻すことのできるソリューションが望ましいと言えます。 *4 DevOpsにありがちな11のボトルネック, Mike Kavis, Forbes, 2014年12月18日 roguewave.com 5

品質とセキュリティの向上のために、ソフトウェア開発のリーダーが知っておくべき5つの指針 データドリブンな意思決定 ソフトウェア開発のリーダーの役割とは、将来の目標や課題を継続的に議論・検討し、その意思決定を行っていくこ とにあります。計画から実行まで、議論の末にデータドリブンな意思決定を行うことが、競争力の強化をはじめ、前述 の指針に照らして実際のパフォーマンスを判定する際のカギとなります。 MITデジタルビジネスセンターが行ったIT組織の研究結果は次のようなものでした。 “サンプル調査の結果、データドリブンな意思決定を行う企業は、平均的な企業よりも生産性が4％、利益は6％高いことが分かりました *5 データドリブンな意思決定プロセスを推進するためには、情報の収集・処理・”利用の3つのステップが求められます。 ここでは、曖昧なデータからいかにして明確な情報を引き出すことができるかがカギとなります。 データドリブンに基づく効率的な意思決定においては、雑多な情報に惑わされることなく、下記の領域にフォーカス する必要があります。 1. プロジェクトの目標に直結する指標のみに集中する。たとえそれがMISRA規格の準拠に関するものであ っても、あるいは自動テスト中に発見したセキュリティの脆弱性の数の追跡であっても、それ以外への 注力は時間の浪費につながります。 2. 生データをフィルタリングし、類似の項目をグループ化する。 共通のパターンを見いだすことは、傾向を 特定して将来の動作を予測する数多くの統計手法や予測ツールの中から最適なものを選択する際に 役立ちます。 3. 緊急時においても、冷静かつ時間的に十分な余裕をもった意思決定を行うためのしきい値を設定す る。 これらのしきい値は、データの種類によって左右されます。たとえば、特定のソフトウェアモジュール のレビューしたとき、このモジュールでのバグの解決はビルド間で解決した5つの問題よりも価値がある ため、結果的に開発者がコードストリームに侵入することを防いだ欠陥の数となります。 加速化は時間を要する 上記で紹介した5つの指針は、あくまでスタート地点にすぎません。品質とセキュリティを確保して、迅速なリリースを 実現するためには、調査、選択、実行を継続していく必要があります。その際に重要となるのは、開発者がより多くの 時間をコーディングに投じられるようにするツールと手法を導入することであり、これによって優れた意思決定とリリ ース時のコスト削減を推進できるようになります。 ローグウェーブのKlocworkが、高品質かつ迅速なソフトウェアデリバリーを実現する方法についての詳細は、ローグ ウェーブソフトウェアのホームページをご確認ください。 Rogue Wave helps thousands of global enterprise customers tackle the hardest and most complex issues in building, connecting, and securing applications. Since 1989, our platforms, tools, components, and support have been used across financial services, technology, healthcare, government, entertainment, and manufacturing, to deliver value and reduce risk. From API management, web and mobile, embeddable analytics, static and dynamic analysis to open source support, we have the software essentials to innovate with confidence. roguewave.com © 2017 Rogue Wave Software, Inc. All rights reserved. *5「 ITに強い企業の特徴」 Andrew McAfee、Erik Brynjolfsson、『ウォールストリートジャーナル』、2011年4月25日 roguewave.com 6