要件エンジニアリング: 手押し車と要件に共通するもの

統合型要件エンジニアリング - 検証/妥当性確認と組み合わせた要件管理の価値

Lifecycle Insightsの電子ブック 「製品開発のジレンマ: 製品要件を満たし、納期を守るために、製品開発リーダーがとるべき5つの戦略」をお読みください。

私は大学の工学部で学ぶかたわら、ゼネラル・エレクトリック (GE) で設計エンジニアリングのインターンシップを行いました。ほとんどの会社と同様に、初日には新人向けのオリエンテーションがありました。オリエンテーションの資料には、GEの創設者トーマス・エジソンについての有名な物語とともにGEイズムが書かれていました。電球の開発実験に何千回も失敗しつつも、「私は失敗したわけではなく、うまくいかない方法を1万通り見つけたのだ」「天才とは1%のひらめきと99%の努力である」など、ご存じの言葉です。本の後ろには現地のGEイズムが書かれ、工場建設時の逸話が載っていました。

土を満載した手押し車で毎日建設現場を出ていく労働者の話です。出口にいる警備員は彼を呼び止め、何を盗もうとしているのかと土の中を探りました。何も見つからなかったので、彼を通しました。こうして、労働者は毎日土を満載した手押し車を押して出ていきました。工事の最終日に警備員はようやく、何を盗んでいるのかと尋ねました。  彼の答えは、「手押し車」。

テキストベースの要件と要件ドキュメントに費やす時間を考えてみると、われわれは要件の内容物とその入れ物との優先順位を間違えやすいといえます。私は、さまざまな企業を訪問した際に、エンジニアに彼らの製品が何であるかを尋ねて、現場の混乱や成熟の度合を測定しようとしています。紙の束を掘り出したり、大量のPDF版要件ドキュメントを見せてくれたりした場合は、エンジニアが内容物ではなく手押し車に焦点を当てていることがわかります。

私がハイテク業界にいた頃、仕事をする人数よりも、やるべき仕事の方が多いことに経営陣が気づいたことが、全員の生産性を高めるための大きな推進力につながりました。これは特に、ライフサイクルのフロントエンドで、下流のすべての人が使用する要件を定義する人々を対象としていました (彼らは、プロジェクトを成功させるための重要な最初のステップは、正しい要件の作成だと認識していました)。 会社の現状を確認し、改善点を知るために、彼らはフロントエンドの人々の時間と動きの調査を依頼しました。その結果、次のようなことがわかりました。

• 50%の時間は、ドキュメントの作成と維持管理に費やされていました

• 25%の時間は、さまざまなドキュメントやプレゼンテーションなど、異なる場所に同じ情報を再入力することに費やされていました

• 30%の時間は、そのアイデアを他の人に伝える (多くの場合、同じ会議を何度も繰り返す) ことに使われていました

• 14%の時間は、ドキュメントを正しく印刷するためにコンピューターを設定することに費やされていました

合計すると100%以上になります (仕事をこなすために週40時間以上働いていたからです)。

マイケル・ハマーとジェームズ・チャンピーの著書『Reengineering the Corporation』 (1993年頃) を覚えている人は、ビジネス・プロセスを記録し、それらのプロセスに費やされた時間と労力を測定し、それを顧客にとっての価値と比較したバリュー・マッピング・プロセスを思い出すでしょう。顧客が価値を見出さないものに時間を費やしているところがあれば、それは開発プロセスから排除する候補となります。リエンジニアリングの価値原則を要件に適用した場合、要件の仕様やドキュメントは、それらに費やした工数を考えると、顧客にとって非常に価値があるものでなければなりません。ただし、私たちの分析では、誰も読んでおらず、印刷したそばから情報が古くなっています。また、これだけの時間を費やしたのだから、ドキュメントが承認されれば、プロジェクトのすべてが問題ないと考える傾向が見られます。では、なぜ私たちは価値が疑わしいものに、これほど多くの時間を費やすのでしょうか？

そのほとんどは、給料を受け取るため、コンプライアンスを証明するため、顧客とやり取りするため、といった理由です。

手押し車の例えで言うと、入れ物ではなく内容物に焦点を当て、必要に応じて構成および適用される、個々の要件の管理を開始できるとしたらどう変わるでしょうか。フロントエンドの生産性を大幅に向上させることができ (つまり、リーン方式でいうバッチがいっぱいになるのを待つ無駄ですが、ここではすべての要件が収集されるまでドキュメント全体のレビューや承認を待つという無駄をなくす)、要件を開発プロセスに結び付けることで、要件の主要な価値を獲得でき、製品がすべての過程で要件の影響を受けます。これを統合型要件と呼んでいます。

統合型要件の一例として、要件をその下流の検証および妥当性確認プロセスに接続することが挙げられます (結局のところ、よい要件の定義の1つは「検証可能」であることです)。

では、このようなプロセスの生産性向上を想像してみてください。要件はテストケースと関連付けて定義されます。 テストケースは要件への準拠を検証するために再利用され、テスト・ドキュメントの代わりにテストケースが個別に管理されます。要件とそのパラメーターは、どのマイルストーンに対してどの要件を検証する必要があるかを通知するプログラム計画に関連付けされています。テストと検証の実行は監視され、証拠が収集され、要件に関連付けられます (要件から検証および証拠までが可視化されます)。経験や、問題、見逃しは、プロセスのフロントエンドにフィードバックされ、既存のプログラムを次のサイクルの出発点として使用します (そのすべての経験が取り込まれます)。

一度で導入するのは手に余ると思えるかもしれませんが、その過程に価値があります。

例えば、要件に関連付けたテストケースだけでも価値がありますが、私たちの経験から、次のようなことは珍しくないことがわかりました。

• テストケースの30%は、検証すべきソースや要件がないテストクリープです。30%のテストが不要だということです。

• 要件の25%は未検証であり、要件に関連付けられたテストケースがありません。正しい対象をテストしていないのです。

手押し車を捨て去ると言うのは簡単ですが、会社の文化のなかでは難しいです。特に、顧客がドキュメントの成果物を期待している場合はなおさらです。われわれは顧客のためにドキュメントを生成しますが、個々の要件を構成・管理し、さまざまなプログラムで何度も再利用することに焦点を当てており、要件についてリーン方式で考えています (ドキュメント内の多数の要件が承認されるのを待つ反リーン方式ではなく、個々の要件ごとに承認されるリーン方式)。そして、個々の要件から、その行先、検証の方法と時期、履歴、理論的根拠、問題などを次回のために可視化し、各サイクルで再利用したり改善したりできます。

Lifecycle Insightsの電子ブック 「製品開発のジレンマ: 製品要件を満たし、納期を守るために、製品開発リーダーがとるべき5つの戦略」をお読みください。

要件の詳細については、 ブログ記事をご覧ください。クラウド版のTeamcenter Xを使い始めて、要件を含む製品情報とプロセスを迅速かつコスト効率よく管理する方法をご紹介します。