多くのアジャイル「グル」がハードウェア開発について誤解していること

アジャイル手法は、ソフトウェア開発の世界に根ざしており、技術業界において変革的な力として称賛されています。しかし、ハードウェアおよび電子機器の開発に進出するにつれて、アジャイル原則の見かけ上スムーズな適応は、課題と誤解の迷宮に直面します。この3部構成の探求の第1回目では、ハードウェアとソフトウェア開発の違いから生じるアジャイルの課題を分析しました。この記事では、アジャイル「専門家」によって広められた神話を検証します。

電子ハードウェア開発におけるアジャイルの複雑さに踏み込む前に、アジャイルのコーチやコンサルタントを非難することが私たちの意図ではないことを明確にすることが重要です。私たちは、彼らの善意と、顧客がアジャイル手法の利点を享受するための熱意を認識し、評価しています。批判が生じることもありますが、それはハードウェアの微妙な違いを十分に理解していないことから来るものであり、批判することが目的ではありませんが、アジャイル原則を効果的に適応させ、ハードウェア開発の特定の要求を満たすことが目的です。私たちの焦点は、このユニークな文脈でその利点を活用するためにアジャイル戦術を調整し、アプローチを変更しつつも原則を保持することです。

神話＃1：柔軟で適応し続ける必要があります アジャイルの専門家は、反復的な実行、フィードバックループ、そしてソフトウェアのデジタル領域で栄えている迅速な適応性の長所を正しく賞賛しています。しかし、これらの原則をハードウェアや電子機器の具体的な風景に移行することは、純粋なデジタルスペクトラムにはない複雑さの層を導入します。物理的な解決策は、そのソフトウェアの対応物とは異なり、「完成」する必要があります。部品を注文し、金型を製造し、厳格な製造ニーズを満たすためです。アジャイルの絶え間ない変化への呼びかけは、ゲームの遅い段階でさえ小さな変更が必要な場合、ハードウェアの容赦ない性質と衝突します。

これに対応して、ハードウェア開発にアジャイルを適用するには、パラダイムシフトが必要です。それは絶え間ない変更についてではなく、プロトタイピングと、時間、予算、リソースの制約内で価値を最大化することを目指す、迅速な学習と実行サイクルに基づく、情報に基づいた戦略的な適応についてです。アジャイルの機敏さと物理製品の最終性の要求との間のダンスは、より良心的なイテレーション計画と、プロジェクト全体を通じてリスク削減への深いコミットメントを必要とします。

神話＃2：毎スプリントで動作するプロトタイプを開発する必要があります

アジャイルの純粋主義者がよく唱える、2〜3週間ごとに完全に機能するプロトタイプを開発する「スプリント」はアジャイルであるための普遍的な「必須」項目とされていますが、このアプローチの実用性は、ハードウェアおよび電子機器の開発（および予算）の現実に直面して崩れます。何かを構築し、進捗を示し、この結果を使用して貴重な技術的および商業的フィードバックを得て、次のイテレーションに役立てるという考え方は正しいです。しかし、各ハードウェアプロジェクトは、独自の目標、依存関係、リードタイムの制約、必要なイノベーションの領域、およびリスクを持つ独立したエンティティです。そして、各プロジェクトは、プロトタイピングと学習に対する独自のアプローチを受けるに値します。

アジャイルなハードウェア製品開発を真に受け入れるためには、チームはワンサイズフィットオールの考え方を捨てる必要があります。代わりに、プロジェクトのニーズを慎重に検討し、創造的で学習とプロトタイピングの戦略を導き出すために協力する必要があります。"プロトタイプ"は、予備的なパンフレットから、スティーブ・ジョブズの有名な「ポケットに1000曲を入れる」iPodモックアップのような泡のモックアップ、部分的または完全に機能するプロトタイプまで、あらゆる実証可能な成果物であることを認識することが重要です。

神話＃3：バックログにストーリーを追加して、ただ始める

アジャイル手法の固有の強みは、従来のウォーターフォールアプローチよりもプロジェクトをはるかに迅速に開始できる能力にあります。実際、アジャイルハードウェア電子プロジェクトにおいては、概念の特定から開発の開始までの期間が大幅に短縮されていることがわかっています。この期間は、従来の段階的アプローチの下では多くの場合、数ヶ月または数年に及ぶことがありましたが、アジャイル方法では数週間または数日にまで短縮されています。もちろん、この劇的な結果の一部は、私たちが「開発の開始」と定義する方法にあります。

ソフトウェアにとって、これは簡単です。アジャイルの専門家は、ソフトウェア機能を定義するためのユーザーストーリーの作成、それらをバックログに優先順位付けし、スプリントを開始することを推奨しています。しかし、ハードウェアでは、少なくともプロジェクトを正しい方向に導くために、アーキテクチャ、重要な望ましい属性、制約、およびその他の要因の理解を伴う最低限の事前計画が必要です。この事前の努力は、「動作するソフトウェアが進捗の主要な尺度である」と「開発の遅い段階でさえ、変更される要件を歓迎する」というアジャイルの原則と明らかに衝突するように見えるかもしれません。

和解は、製品開発の前段階に一般的に理解されているアジャイルの戦術を適応させることによってバランスを見つけることにあります。ハードウェアのアジャイルプロジェクト管理は、プロジェクトの戦略的意図に沿って迅速に開始し、従来のアプローチよりもはるかに多くの未知数を受け入れることを可能にします。その後、チームはアジャイルの反復学習を使用して最適な解決策を定義し、スケジュールとリソースの制約内で製品価値を高める戦略的変更に対して開かれた心を持って協力することができます。

神話＃4：すべての作業項目をユーザーストーリーとして定義する

多くのアジャイルの専門家が唱える重要な指示の一つは、すべての開発作業をユーザーストーリーとして定義すべきだということです。このアドバイスは、システムコンポーネント、インターフェース、他のエンジニアなども「ユーザー」として扱うべきだと続けています。このアドバイスにより、ほとんどの電子機器およびハードウェア開発者は頭を悩ませ、遵守に苦労しています。

ソフトウェアチームがアジャイルの実践をすんなりと採用している主な理由の一つは、顧客のニーズを伝統的な要件文書や詳細なユースケースで文書化することが非常に無駄であり、チームにほとんど価値を加えなかったからです。なぜユーザーが何をしようとしているのかを宣言し、その機能を文書化するためにユーザーストーリーを書き、それを開発タスクとして扱わないのでしょうか？これは自己文書化するだけでなく、これらのストーリーが一貫して優先され、顧客との検証が行われれば、変化に対応し価値を最適化するための完璧なクローズドループシステムを持つことになります。素晴らしいですね！

ハードウェア開発のためにユーザーストーリーを直接作業項目として書き、それらを価値ある顧客の成果に追跡するこの試みは、多くのハードウェアチームにとってアジャイルの限界点であることがよくあります。ハードウェアを定義することは、ソフトウェアを定義することとは異なります。従来の製品要件文書（PRD）や機能仕様は、ハードウェア開発者にとって安心感を提供するだけでなく、彼らの作業を分解して提供するために必要な詳細を提供します。開発者に「処理ユニットとして、クリーンな入力を保証するために電圧調整が必要です...」のようなユーザーストーリーを書かせることは、ユーザーストーリーを通じて顧客価値を捉える目的を無効にし、ソフトウェア開発者がアジャイル原則で取り除こうとした非価値の無駄を追加します。

ソフトウェアのためのアジャイルにおける初期の思想リーダーであるマイク・コーンが定義するように：「ユーザーストーリーは、その人の視点から語られた機能の短くシンプルな説明です。」ここでのキーワードは「人」です。ハードウェアチームにとってアジャイルは、ユーザーストーリーを書くことから大きな価値を得ることができますが、作業項目を定義するのではなく、人々からの顧客ニーズを捉えるためにそれらを使用する必要があります。これらのストーリーは、ハードウェア開発者にとって意味のある技術を使って、望ましい成果を満たす製品属性と関連する作業項目に翻訳されなければなりません。

神話＃5：専任のチームメンバーが必要です

Vitality ChicagoのLinkedInの投票によると、アジャイル実践者の54%が専任のスクラムまたはアジャイルチーム（専任のチームメンバーを意味する）がアジャイルの基本ルールであると言っています。専任チームについてはアジャイルマニフェストには言及されていませんが、アジャイルの専門家たちはしばしばこれをルールとして扱い、プロジェクトに100%集中するチームメンバーがいれば多くの利点があると主張するのは難しいことではありません。約束を果たさない言い訳が少なくなり、成功を妨げるものがなくなり、誰も「今週はこの他のプロジェクトが優先です！」と言わなくなるでしょう。

しかし、ハードウェア開発環境で働いたことがあるなら、専任のチームメンバーを持つことがどれほどの贅沢かを知っているでしょう。ほとんどの組織がそれを贅沢としか思えない理由は、ハードウェア開発の性質上、アーキテクト、リードデザイナー、その他の主題専門家（SME）が複数のプロジェクトで必要とされることが多いからです。会社には、その専門知識が必要なときに呼び出される無線周波数の専門家が1人いたり、重要な時期に必要とされるレイアウトのスペシャリストがいたりするかもしれません。ハードウェア開発チームはアジャイルメソッドを採用し活用することができますが、専任のチームメンバーを持つことは通常選択肢にはありません。したがって、アジャイルを長期的に成功させるためには、アジャイルをサポートするリソース管理アプローチが重要です。

#神話 6: アジャイルは定義された役割、儀式、セレモニー、および語彙の合計である

ある会社で、2つのチームが並行して働いています：従来のウォーターフォール方式を使用するハードウェアチームと、スクラム方式を使用するソフトウェアチームです。ハードウェア開発者が会議室のそばを通りかかると、ソフトウェア開発者たちが円を作って集まっているのを見て、「さて、スタンドアップミーティングへようこそ。前回のスプリントでは、ユーザーストーリーポイントの見積もりと受け入れ基準に苦労しました。私たちのスクラムマスターが最新のバーンアップを共有し、バックログのグルーミングにおける問題を解決するためにレトロスペクティブを促進しました。これにより、速度を上げることができます。変更に対する私たちの感情をフィスト・トゥ・ファイブで表しましょう。」と聞こえてきます。さまざまな拳と指の配置がすぐに上がります。

ハードウェア開発者は、興味をそそられる一方で、この奇妙な儀式と馴染みのない用語の多さに少し戸惑いを感じずにはいられませんでした。彼は、これらのアジャイル手法がどのようにして自分の具体的なハードウェア開発の世界に適用可能なのか疑問に思い、「自分はカルトに迷い込んだのか？！」と自問自答します。

しばしば、アジャイルの専門家たちは、ソフトウェアのためのアジャイルの言語や文化に深く浸っているため、ハードウェアチームも真に「アジャイルである」ためには、同じ儀式、役割、ツール、言語を採用しなければならないと信じています。皮肉なことに、アジャイル宣言の最初の原則は、「プロセスやツールよりも個人と対話」と述べています。これを踏まえ、「プロセス、ツール、儀式、そして教義よりも個人と対話」とさらに言い換えることができると思います。言語の合意、会議形式、アジャイルなマインドセットと体系的な働き方を構築するための特定の活動はすべて成功に不可欠ですが、ソフトウェアのためのスクラムやアジャイルの特定の儀式や語彙を採用することは必要ありません。ハードウェアチームは、アジャイルの各要素、儀式、役割の目的と意図を見極め、それぞれがどのように最も彼らのニーズに合うかを決定する必要があります。

アジャイル・ハードウェアのギャップを埋める

ハードウェアと電子機器の開発努力にアジャイルアプローチが適しているかどうかを考える際、よく意図されたアジャイルの専門家によって広められる従来の「知恵」は、物理製品開発に必要なより微妙で適応的なアプローチを導くには不十分なことが多いです。ハードウェアでの成功したアジャイル実装への道のりは、柔軟性、事前準備、反復計画、そして可能な限り最も価値のある解決策に最短時間で収束するための良心的なアプローチの思慮深い組み合わせを含みます。

3部構成のシリーズの最終回では、電子ハードウェア開発のための変更されたアジャイルの利点をさらに活用する方法について深く掘り下げます。これは、アジャイル方法論の核心原則を守りながら行います。このトピックについてもっと詳しく探求したいですか？ウェビナーを視聴する！