Creo の舞台裏 : Creo 1.0 のスプリント レビューからのレポート

以前の記事で、PTC が Creo の開発に使用している社内プロセスである “スクラム” について説明しました。スクラムは、PTC の研究開発チームに、プロジェクト管理を成功に導く進歩的なアプローチを提供してくれました。しかし、研究所の外、つまりリリースされたソフトウェアを使用する方々にとって、それは重要なことでしょうか。

Creo の製品開発担当バイス プレジデントであるマイケル・フロマー (Michael Pfrommer) は、スクラムによってリリースの有用性と信頼性が保証されるので、Creo ユーザーにも大きなメリットがあると述べています。ここで紹介するインタビューの続きでは、Creo に対して実施しているテストについて、また PTC がリリース時期をどのように決めているかについて、フロマーは詳細に説明しています。

GH : 「PTC では、ソフトウェア開発時に “品質をつくりこむ”」というフレーズをよく耳にしますが、それはどのような意味でしょうか?
フロマー : PTC では、ソフトウェア開発者が機能を設計開発する際に 品質をつくりこむ” ことを奨励しています。要件が明確になっていること、設計がチームによるレビューと承認を受けること、ソフトウェア開発のメイン ストリームに反映する前に開発者がコード変更をローカルの開発環境で事前にテストすることを徹底するために、初期段階で時間を費やしています。設計とコーディングの段階での品質のつくりこみを推進するのが本当の狙いです。

GH : 以前に、各開発期間中、つまり “スプリント” 中に、出荷候補となる製品を構築しているとうかがいました。それは、スプリント中に追加したものがすべて正しく動作することを確認してから、次の一連の新機能や修正の作業に進む、ということですね。各スプリントで行うテストについてご説明いただけませんか?
フロマー : そのとおりです。各スプリントが機能すること、そしてそれがテストされることが重要です。ですから、開発開始からわずか数週間後にはコードのテストを行います。機能を追加または更新するたびに個別のチェックを行います。

GH : 無作為にですか、系統的にですか?
フロマー : 戦略的にです。ほとんどのテスト サイクルは、大まかに 5 つのステップで構成されます。

  1. 合意。まず、何をテストするのか、つまりテスト プランについて合意を得ます。通常、これは製品の要件、定義、受け入れ基準に基づいて策定されます。
  2. テストの文書化。このステップでは、テスト、テスト ケース、合格条件を文書化し、可能な場合は自動テストを構築します。
  3. テストの実行。
  4. テスト結果を報告、追跡、管理します。
  5. 失敗したテストを特定し、それらに優先順位を付けます。

GH : 数多くのテストを自動化しているのですか?
フロマー : そうです。すべての品質エンジニアが、自動テストの開発と、スプリントのあらゆる側面をテストするテスト スイートの構築を継続的に行っており、その数は増える一方です。Creo の場合は、リリースの公開前に 100 万以上の自動テストを実施します。

GH : それほどの数のテスト結果をどのように消化しているのですか?
フロマー : 各テストについて、合格 (テストを実行し、結果を分析、結果は正しかった)、失敗 (テストを実行したが、結果は正しくなかった)、または失敗 OK (テストを実行、結果を分析、実際のテストの更新が必要) のいずれかの結果が出されます。各スプリントで実行したすべてのテストの結果を総合すると、各スプリントの品質を客観的に把握できます。

GH : 多数のスプリントが完了すると、リリース候補が得られるというわけですね?
フロマー : そうです。プロダクト オーナーは、製品要件が満たされていることをスプリントの完了によって確認し、そのバージョンのコードをリリース候補としてノミネートします。

GH : すべてのスプリントがリリース候補とみなされるわけではないのは、なぜですか?
フロマー : それには複数の要因が関係します。プロダクト オーナーは、ソフトウェアが顧客に価値を提供するのに十分な完成度に達しているかどうかを判断する必要があります。リリースが早すぎれば、製品はニーズを満たしません。リリースが遅すぎれば、顧客が別のソリューションを見つけて、PTC にとってのチャンスが失われるかもしれません。また、市場がどのように展開してきたか、ビジネスがどのように展開してきたかも考慮する必要があります。顧客のニーズをより適切に満たすために役立つテクノロジまたは製品を獲得したかもしれません。パートナーが同じ領域のソリューションを開発したかもしれません。最後に、リリース候補をノミネートするたびに、より広範な段階的テストに入り、より多くの人々が関与するようになる、と考えます。より広範なテストには、より多くの社内スタッフ、ソフトウェア パートナー、顧客が参加します。かなりの労力を要するので、これを行うのは、そのリリースが大きな影響を及ぼすことが確実である場合だけにしたいですが…。

GH : その、より広範な段階的テストの手順について説明していただけませんか?
フロマー : リリース候補については、完全な製品全体に対して以下を行います。

  • 機能的品質にとどまらず、さらに多くの側面を検討します。たとえば、パフォーマンス、信頼性、ユーザビリティ、スケーラビリティ、サービス性、互換性などです。
  • 開発者の構築環境以外のさまざまなマシンとプラットフォームで、リリース候補を使用してテストします。
  • さらに多くの手動テストを行います。たとえば、世界中のテスト担当者と共有できる、ソフトウェアのベータ版をリリースします。
  • 弊社のほかの製品との互換性をテストします。
  • 異なるすべての言語、サポートされているすべての言語構成をテストします。
  • 各パートナーが自社製品について弊社の最新リリースへの対応を証明できるように、リリース候補をソフトウェア パートナーおよびハードウェア パートナーにリリースします。
  • このすべてを追跡し、重要な問題を報告、追跡、管理、解決します。

GH : より広範なテストが、スプリント テストと同じく重要なのですね。
フロマー : そのとおりです。両方重要です。スクラムには大きく 3 つのメリットがあります。第 1 のメリットは、開発の全段階を通じた製品の安定性にあります。各リリースを、お客様が期待を持ち、心待ちにしていただけるものにしたいと考えており、スプリントごとに製品の進化が急速に進むのを感じています。スクラムは透明性が高く段階的なアプローチなので、数週間おきにすぐさま成果を確認し、お客様にご覧いただくことができます。第 2 のメリットは、プロジェクトの進行中に開発の優先順位を変更できることです。Creo を構成する新しいテクノロジを開発する際には、スクラムのおかげで、予期しない問題にも対応することができました。事前に周到な準備を行う従来型の手法では、これらの問題に容易に対応することはできなかったでしょう。第 3 のメリットは、スプリントを終えるたびにリリース候補となる成果物を得ることができる点です。

GH : PTC は、製品開発全体のうち、テスト段階にどれだけの重点を置いているのでしょうか?
フロマー : 自動テストは 100 万以上存在します。弊社の製品開発能力全体のうち 20 % はテストが占めています。Creo 1.0 の場合は、手動テストに 20 万時間以上を費やしました。お客様、ソフトウェアおよびハードウェアのパートナー、その他の外部関係者によって行われる数千時間分は、これには含まれません。

GH : それだけの自動テストが行われていて、手動テストがなくなる日は来るのでしょうか。
フロマー : いいえ、そのような日は想像できません。問題は、さまざまな方法で低減できます。たとえば、アプリという概念を利用すれば、コードの行数が減って、複雑さが緩和されるでしょう。しかし、常にテストは行います。非常にとっぴな欠陥やあまりにもあからさま欠陥をソフトウェアで発見するために、必ずや生身の人間の力が必要になります。次回以降の「Creo の舞台裏」の記事では、Creo 1.0 の実態について取り上げます。ぜひご期待ください。

この投稿の“カテゴリー”: Creo の舞台裏 、タグ: , , 。ブックマークは追加ブックマークにはパーマリンクをどうぞ。. コメントもしくはトラックバックをどうぞ: トラックバック URL.

コメントを投稿

あなたのメールは 絶対に 公開されたり共有されたりしません。 *マークは入力必須項目です。

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

次の HTML タグと属性が使用できます: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong>