品質の作り込み

素早い統合された学習サイクルでインクリメンタルに構築する

─SAFeの第4原則

品質の作り込みの概要

品質の作り込みは、SAFeの4つの中心的価値の1つである。企業が新しい機能を持続可能な最短のリードタイムで納品できるか、変化の激しいビジネス環境に対応できるかは、ソリューションの品質次第である。ただし、品質の作り込みはSAFeに限ったことではない。これはリーン-アジャイルの考え方の中心的な原則であり、不良品の回収、作業のやり直し、不具合の修正が原因で生じる遅延コストを防ぐのに役立っている。アジャイル宣言も品質を重視していて、「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます」と言っている[1]。大規模システムにおける品質の作り込みの価値には疑う余地がない。これは必須である。これを実現できるよう、このページでは、ソフトウェア、ファームウェア、ハードウェアに関する品質プラクティスを紹介する。

ソフトウェアプラクティス(その多くはエクストリーム・プログラミング(XP)から取り入れたものであり、XPで説明されている)を実施することで、アジャイルソフトウェアチームは、構築するソリューションの品質が高く、変化にすぐに適応できることを保証できる。これらのプラクティスには、協調的な性質があり、頻繁な検証を重視しているため、創発的な文化が育まれ、ビジネスを成功させるうえでエンジニアリングと技能が大きな役割を果たす。

ファームウェアとハードウェアについても目的は同じだが、物理面と経済面がいくらか異なり、結果としてプラクティスも違ってくる。モデリングやシミュレーションがより重視されるし、早期の調査反復や設計の検証が増え、システムレベルの統合が頻繁に行われる。

詳細

企業が変化に対応しなければならないとき、ソフトウェアやシステムが優れた技術的基盤の上に構築されていると、変化や適応が容易である。大規模システムの場合には、これはさらに重要になる。小さな不具合や想定の誤りが積み重なって、受け入れられない結果になる可能性があるからである。高品質なシステムを作り上げることは容易な仕事ではなく、継続的な鍛錬や努力が必要であるが、その投資によって次のような多くのビジネス上の利点が得られる。

  • 顧客満足度の向上。プロダクトやサービスの欠陥密度が低ければ、顧客満足度や、安全性、投資利益率、ビジネス担当者の信任が向上する。
  • 開発組織の予測性と整合性。ソリューション品質を確実に制御できなければ、高い予測性に基づいて新しいビジネス機能を計画したり、開発ベロシティーを理解したりすることは不可能である。そうなると、ビジネス担当者からの信頼が失われ、技能に関する各人のプライドが低下し、士気が低下する。
  • 拡張性。コンポーネントが設計の意図を明確に表していて、シンプルであり、統合とテストのインフラを備えている場合、チームや機能を追加するとより多くのビジネス価値が納品される。そうでなければ、開発者やテスト担当者を追加しても、企業のペースは遅くなり、品質やリリース確約のばらつきが受け入れられないレベルまで大きくなってしまう。
  • ベロシティー、アジャイル、システムパフォーマンス。品質が高いと、保守性がよくなり、新しいビジネス機能を素早く追加できるようになる。また、パフォーマンス、拡張性、セキュリティ、信頼性といった重要な非機能要求を維持し、向上するという、チームの能力も高くなる。
  • イノベーションを起こす能力。頭のいいモチベーションの高い人と、彼らが働く環境が揃ったときに、イノベーションが発生する。品質の高さが、新しいアイデアのプロトタイプ作成、テスト、デモを容易に行える、肥沃な技術環境を作り上げる。

この後のセクションでは、ソフトウェア、ファームウェア、ハードウェアに対して品質の作り込みを行うための推奨プラクティスを紹介する。

ソフトウェア

SAFeは、何十年にもわたって進化したよりよいエンジニアリングプラクティスの上に構築されている。これは主に革新的なリーンおよびアジャイルの手法が成功したことによってもたらされたものだ。ソフトウェアエンジニアリングについて言うと、XPのプラクティスが道を切り開いてきた[2]。システムレベルの品質を保証するためにはアジャイルアーキテクチャーが大きな役割を果たすが、SAFeではその他にも、チームが最高水準の品質を達成するのに役立つ重要なリーン-アジャイルのソフトウェアエンジニアリングプラクティスを、追加で記述している。以下のセクションでは、これらのプラクティスについて概要を説明する。そのうち、継続的インテグレーションテストファーストリファクタリングの3つについては、リンク先に詳細な説明がある。

継続的インテグレーション

継続的インテグレーション(CI)は、それぞれの開発者のワークスペースにあるコードを、一日に何度か、コードの主ブランチにマージするという、ソフトウェアプラクティスである。こうすると、プログラム内の開発者全員が、常に最新版のコードを使って仕事をすることができ、エラーや、開発者間/チーム間の推測に基づく事柄が、すぐに発見される。結果として、システムレベルの統合の問題が先延ばしされるリスクや、それがシステムの品質やプログラムの予測性に及ぼす影響を、回避できる。継続的インテグレーションを行うには、ビルドサーバーや自動テストフレームワークなど、特別のインフラやツールが必要である。しかし、それよりも重要なのが、完全に統合されてテストの済んだソフトウェアだけを各個人やチームの功績とするという文化である。

SAFeでは、チームがローカルでの統合を少なくとも一日に1回は実施するが、必要に応じてシステム全体を統合して回帰テストを実行し、意図したとおりにシステムが進化していると確認することも、同じくらい重要である。最初は、それを毎日行うのは無理かもしれない。その場合には、少なくとも反復ごとに1、2回、システムレベルの完全な統合を行うことを初期目標にするのが妥当かもしれない。そうすることで、2週間ごとのシステムデモを成功させるのに必要なベースラインができあがる。

継続的インテグレーション」のページでは、このトピックについて、特にシステムレベルおよびソリューションレベルのCIについて、詳しく説明している。

テストファースト

テストファーストは、コードを実装する前に、システムの振る舞いについてチームがじっくりと検討することを推奨する考え方である。これによって、コーディングの生産性が上がり、使用適合性が向上する。また、包括的なテスト戦略も作成され、結果としてシステム要求についての理解内容が一連のテストへと変換される。これは一般に、コード自体の開発よりも先に行われる。

テストファーストの手法は、テスト駆動開発(TDD)受け入れテスト駆動開発(ATDD)に分けられる。どちらもテストの自動化によってサポートされる。この自動化は、継続的インテグレーションや、チームのベロシティー、開発の効率をサポートするのに必要である。

テスト駆動開発では、開発者はまず、自動化された単体テストを作成し、それを実行して失敗することを確認する。次に、テストに合格するために必要最小限のコードを書く。主にコードのメソッドやユニットの(技術的な)レベルに適用可能で、これによってテストが実際に存在することが保証される。また、規定されたテストケースを満たすのに必要である以上に複雑なコードを書く「金メッキ」や「フィーチャークリープ」を防止するのに役立つ。その他に、要求を自動テストとして存続させ、最新に保つのにも役立つ。

受け入れテスト駆動開発はより高度な規律である。受け入れ可能なシステムの振る舞いに関する基準がプロダクトオーナーによって作成され、それが自動受け入れテストに変換される。そのテストを繰り返し実行することで、システムが進化しても整合性を変わらず確保することができる。ATDDでは、顧客の目に見えるシステムレベルの必要な振る舞いにチームが集中することができ、明確な成功基準も設定される。

このトピックについて詳しくは、「テストファースト」のページで説明する。

リファクタリング

リファクタリングとは、「外部への振る舞いを変えることなく、内部構造を変化させて、既存コードを再構築するための、規律ある手法」[3]である。アジャイルが「事前の大量の設計」(Big Up-Front Design:BUFD)を避け、「要求の変更はたとえ開発の後期であっても歓迎」[1]するのと同じように、これは、新しいビジネス機能が必要になったら、現在のコードベースに素直に変更を受け入れることを示している。このような弾力性を保つために、チームは一連の小さいステップで常にコードをリファクタリングし、今後の開発の強固な基盤を作成する。「いつも新機能」を優先してリファクタリングをおろそかにすると、すぐに硬直した保守不可能なシステムになってしまい、最終的には経済的成果がどんどん低下する。

リファクタリングは、創発的設計の重要な要因であり、アジャイルに欠かせない必須の部分である。リファクタリングの詳しい指針は「リファクタリング」のページを参照のこと。

ペアワーク

XPの必須プラクティスであるペアプログラミングでは、ペアワークとは違って、2人のプログラマーが1台のワークステーションで作業をする。一人がコードを書き、もう一人のオブザーバーがレビューと検査をし、コーディングプロセスに付加価値を付ける。2人の役割は、ペアプログラミングのセッションの途中で交代する。コードを実際に書く前に、ペアは何をする必要があるかを話し合い、要求、設計、機能のテスト方法について認識を共有する。オブザーバーは、作業を注意深く見守り、コードの改善方法を提案したり、エラーの原因になりそうなものを指摘する。ピアレビューはリアルタイムで実施され、必ず行わなければならない。

ペアプログラミングはXPに欠かせない要素だが、物議をかもしてもいる。同じコードの作業を2人でするため、コストが増加すると信じる人がいるのである。また、人間関係や文化の課題が発生することもある。

多くの人にとって、ペアプログラミングはエクストリーム(極端)すぎる。しかし実際のところ、アジャイルチームが行うペア作業には、形式の異なるものがいくつもある。それぞれに独自の価値があり、多くは組み合わせて使うことができる。チームによっては、XPで規定されたペアプログラミングの標準を、コード開発全般に適用する。ストーリーの開発者とテスト担当者をペアにし、作業を互いにレビューしてストーリーを完成へと進めるチームもある。あるいは、もっと自然発生的なペア作業を好み、重要なコードや、レガシーコードのリファクタリング、インタフェース定義の作成、システムレベルの難しい統合の際に、開発者がペア作業をするチームもある。ペアワークは、リファクタリング、CI、テスト自動化、共同所有の優れた土台にもなる。

共同所有

共同所有では、「誰もがプロジェクトのあらゆる部分に新しいアイデアを出すことを推奨する。開発者の誰でもコードの任意の行を変更して、機能の追加や、バグの修正、設計の改善、リファクタリングを行うことができる。誰か一人が変更のボトルネックになることはない」[4]。共同所有はSAFeでは特に重要である。システムが大きいとコードベースも大きく、最初に作成した開発者がずっとチームやプログラムに残っている可能性が少ないからである。仮にその人がチームに残っていたとしても、その1人のメンバーが変更してくれるのを待つと、引継ぎと遅延が発生する。

大規模開発で共同所有を実施するには、設計でシンプルさを受け入れる、コードの構造で意図を示す、システムの振る舞いの変更に弾力的に対応できるインタフェースを作成するなど、実証された合意済みのコーディング標準をプログラム全体で使用する必要がある。

ファームウェアとハードウェア

しかし、コードだけでなく、質の悪いコンポーネントやシステムも大規模展開できない。ハードウェア要素(電子、電気、流体、光学、機械、パッケージ化、熱、その他さまざまなもの)は、「ソフト」度がずっと低く、変更が困難で費用もかかる。図1[5]に示すように、ファームウェアやハードウェアのエラーや未確認の想定事項は、時間が経つにつれて変更や再作業のコストがどんどん大きくなる。

図1.  ソフトウェア、ハードウェア、ファームウェアの相対的変更コストの変化

この後のセクションで説明するが、このように後期になるほど変更コストが増加するという性質があるため、サイバーフィジカルシステムをリーンで構築する際には、ソリューション開発に品質を作り込めるよう、いくつかのプラクティスを使用する。

早期の調査反復

参考文献[6]で取り上げられているように、新しいオートバイの路上テストを行うきわめて完全なチームがいるハーレーダビッドソンの作成時にすら、知識を早くに獲得し、後になってエラーが発見されるリスクとコストを低減するためには、設計サイクルを頻繁に実施することがシステム構築者の有用な手段となる。この点で、SAFeはファームウェアやハードウェアをソフトウェアと同じように扱っていて、反復とプログラムインクリメントのリズム(と期待される事柄)はほぼ同じである。しかし、変更コストがまだ高くなっていない早期の反復は特に重要である。リーンなシステム構築者は、反復をもっと素早く実施するために、次のような「ソフト」なツールシステムを使用する。

頻繁なシステムレベルの統合とテスト

継続的インテグレーションは、多くのソフトウェアソリューションにとって、価値のある達成可能な目標である。しかし、サイバーフィジカルシステムの場合、それを適用することも、あるいは想像することすら困難である。たいてい、金型や、機械装置、組み立て部品など、物理コンポーネントの多くは、進化させるのに時間がかかり、統合と評価を毎日行うわけにはいかないからである。しかしそれは、後になってから問題のある状況で統合を行うことの言い訳にはならない。

どちらにしても、最終的には、さまざまなすべてのコンポーネントやサブシステム(ソフトウェア、ファームウェア、ハードウェアやその他すべて)が協調して、効果的なソリューションレベルの振る舞いを提供しなければならないのである。早いほどよい。そのために、リーンなシステム構築では、サブシステムやシステムの早期からの頻繁な統合とテストを試みる。そのためには通常、開発、ステージング、テストのインフラへの投資を増やす必要がある。

設計の検証

ただし、統合とテストだけでは不十分である。まず、システムのさまざまなコンポーネントの入手可能性の依存関係があるため、統合やテストがプロセスの後期になってしまう場合がある。さらに、考え得るすべての利用シナリオや失敗のシナリオを評価できるとは限らない。これに対処するため、システム構築者は設計の検証を行って、設計がソリューションの意図を満たしていることを確認する。設計の検証には、たとえばサブシステム間の要求の仕様化と分析、最悪ケースの耐性とパフォーマンスの分析、故障モード影響解析、追跡可能性、温度や環境など配置後のシステムレベルの側面の分析など、さまざまなステップが含まれる。

これらのプラクティスの多くはソフトウェア領域でも重要だが、ソフトウェアの場合は変更コストが比較的低いため、1つの設計オプションを確約する前にそれほど多くのことを知っておく必要はない。しかしファームウェアやハードウェアの場合には、設計の検討や仕様化の作業を、ソフトウェアより多く事前に行うことが当然とみなされる。


さらに知りたい場合

[1] アジャイルソフトウェア宣言:www.AgileManifesto.org.

[2] Beck, Kent, and Cynthia Andres.Extreme Programming Explained:Embrace Change.Addison-Wesley, 2004. (邦訳:XPエクストリーム・プログラミング入門―変化を受け入れる、ピアソンエデュケーション、2005)

[3] Fowler, Martin.Refactoring.com.

[4] http://www.extremeprogramming.org/rules/collective.html.

[5] Rubin, Ken.http://www.innolution.com/blog/agile-in-a-hardware-firmware-environment-draw-the-cost-of-change-curve.

[6] Oosterwal, Dantar P. The Lean Machine:How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development.Amacom, 2010.

 

Last update:9 December 2015