スタートアップ企業に向けた特別なメリット

Altium Launchpadは、スタートアップ企業が競争の激しい環境で優位に立てるように支援するプログラムです。

詳細を見る

Altium Launchpadはスタートアップ企業向けです

ハードウェアを製造するスタートアップ企業の皆さんは、Altium Launchpadの素晴らしいメリットをお見逃しなく

今すぐ申し込む

スタートアップ企業&エレクトロニクスプロトタイパー

エレクトロニクス分野のスタートアップ企業は、できるだけ早く製品を市場に投入できるようにエレクトロニクス製品の概念実証を確立し、資金を調達することに専念しています。このエレクトロニクスプロトタイピングは、ハードウェアベースのスタートアップ企業を築く上で不可欠なステップです。これらの企業はこうしたプロトタイピングの段階を利用して、製品製造のコストを評価し、投資資金を調達し、様々なアイデアや解決先をテストして開発を加速させる方法を見つけます。

Altium Launchpadプログラム無料試用版を試す

Articles

View More Articles

アジャイル・ハードウェア開発カバー写真

原則が健全である理由、しかし戦術は再考が必要である私たちの「アジャイルを解明する」シリーズの最終回では、ハードウェア開発がアジャイル手法と交差する複雑な風景をナビゲートします。アジャイルの基本原則は確かな基盤を提供しますが、電子ハードウェアのユニークな課題に適用される場合、戦術の再評価が不可欠になります。探求の旅で、アジャイルの共通の要素と儀式を解き明かし、それらを具体的な製品開発の文脈で変革する方法を探ります。アジャイルマインドセットを採用し、一貫して育むことから始めるハードウェア開発における日々のソフトウェアアジャイル実践を強力な利点に高めるための戦術的調整に深く潜る前に、アジャイルマインドセットの基本的な原則をまず受け入れることが重要です。良いスタート地点は、アジャイル宣言の意図を考慮し、ハードウェア開発のニーズに合わせて言語を修正することかもしれません。以下の表は、ハードウェア開発のための一つの潜在的な宣言を提供します。各マニフェストの意図の簡単な要約は、「協力して反復的な開発と学習のアプローチを用い、顧客が本当に価値を見出すものを発見し、提供しましょう。」となるでしょう。もちろん、これはほぼすべてのプロジェクトにとって理にかなっており、チームが日々の開発戦術に没頭する中で、これらの基本的な原則を念頭に置くことが重要です。方向性計画の重要な役割アジャイルの反復的な性質は、時に初期計画が後回しにされ、とにかく始めることに重点が置かれるような印象を与えることがあります。しかし、物理的および電子製品の設計と開発の複雑なプロセスをナビゲートするためには、ある程度の事前計画が不可欠です。徹底的な事前計画ではなく、反復的な学習と実行を通じてチームを開発の旅に導くロードマップと考えてください。アジャイルハードウェア開発の初期計画には、明確な目標の設定、マイルストーンの定義、そして熟考されたプロトタイピングとフィードバック戦略を通じたリスク評価の軽減が含まれます。これにより、チームはアジャイルの適応性と成功したハードウェア開発に必要な構造化された計画の間のバランスを取ることができます。ユーザーストーリーと作業項目の分離このシリーズの前の記事で議論したように、アジャイル「専門家」はしばしば、ハードウェアチームにタスクを定義するためにバックログをユーザーストーリーで埋めるよう促します。ハードウェアのユーザーストーリーを考えてみましょう。新しいフォークリフトの開発を計画していると仮定します。次のようなユーザーストーリーを書きます： "ユーザーとして、素材をすぐに取り出せるようにしたいので、在庫の移動にかかる時間を節約できます。" ハードウェア開発者は何をすべきか知っていますか？おそらく知りません。解決すべき問題の側面が多すぎます。実装には、フォークリフトの速度、フォークアタッチメントの精度、インテリジェントな在庫感知、在庫の向き、その他多くの要因が関わるかもしれません。これらのユーザーストーリーは、具体的な機能やタスクではなく、製品要件や作業項目というよりも、顧客の目標になるべきです。ユーザーストーリーは、アジャイルなハードウェア設計フローにおいて、顧客のニーズに焦点を当て、顧客が達成しようとしている結果を明確にするための場所があります。しかし、物理製品のユーザーストーリーは直接的に機能、属性、またはタスクに翻訳できないため、それらはタスクバックログを開発するための出発点となり、バックログアイテム自体にはなりません。実証可能な進捗と成功のためのプロトタイピング戦略計算されたプロトタイピングは、ハードウェア開発における要であり、その重要性は過大評価できません。アジャイルの伝道師は、迅速なソフトウェアリリースの美徳を説きますが、ハードウェアの領域では、

アジャイル・ハードウェア開発ブログシリーズのカバー

ハードウェア開発がただ…異なる5つの方法電子ハードウェア開発におけるアジャイル手法の実装に伴う独自の課題と戦略を探求します。アジャイルフレームワーク内でのハードウェアとソフトウェア開発の主な違いを理解します。

十分に考慮されたシステムベースの電子機器設計

Newsletters 十分に考慮されたシステムベースの電子機器設計最近、Pegmatis社の共同創設者にして管理パートナーであるDr. Ed Becze氏に会う機会がありました。Becze氏は長く輝かしい職歴において、業界を代表する大手テクノロジー企業から小さなスタートアップ企業に至るさまざまな組織のために、非常に複雑なシステムの設計に取り組んできました。また、長年にわたり、非常に高度な技能を持つエンジニアリングチームを作り上げてきました。チームは、製品設計の着手から完成まで、あらゆる要素をカバーしています。このインタビューでは、真に包括的な設計の重要な要素と、プロジェクトを成功に導くための重要な要因について紹介します。 Judy Warner: Ed、まずお聞きしたいのですが、Pegmatisという社名にはどのような意味があるのでしょう？また、あなたの会社はどのような種類のサービスを行っているのでしょうか? Ed Becze: Pegmatisという名前は、ラテン語で「足場」という意味の単語である「Pegmata」から取ったものです。当社は熟練した研究開発企業で、製品設計の全工程を遂行する能力を1社で保有しています。当社には機械、電子、無線、ファームウェア、ソフトウェア、システムレベルでのテスト、検証の専門家が所属しており、困難で非常に複雑な製品を開発する上で必要なエンジニアリング分野の全てを網羅しています。当社はクライアントから、単なるエンジニアリングの「サービスプロバイダー」ではなく、技術開発の「パートナー」と見なされています。つまり、当社はエンジニアリングサービス以外にも多くの価値をお客様に提供しているのです。お客様が自社のビジネスと製品ソリューションとを同期できるよう支援するとともに、お客様が市場での地位を固められるよう、IPの革新と生成を支援します。当社がこのような支援を行えるのは、広範な製品を供給してきた多くの経験のおかげです。さらに、当社は技術的なギャップを埋めるために対象を絞ったサービスを提供することも、包括的な製品設計開発を担当することもできます。 Warner: 優れた製品開発プロセスの基礎となるのは何でしょうか？ Becze: まず、システムレベルの要件として、パフォーマンス、機能、規制、数量、スケジュールなどを検討します。これらの要因すべてはビジネスの必要と同期し、問題に対処するか、市場に新しいソリューションを供給する必要があります。要件の重要性を過小評価してはいけません。要件を策定するときは、お客様がその機能に料金を払いたいと思うかどうかを常に考慮し、データを基に要件策定を進めます。正当な理由がないのに、独断で要件を決定してはいけません。 PCBの設計を始めるよりずっと前の時点で、次の点について検討します。技術やスケジュールのリスクを評価し、戦略を立てられるようにします。十分な考慮の上で開発計画を作成し、早い段階で危険を軽減します。

アジャイル・ハードウェア開発に関する一般的な誤解のカバーフォト

多くのアジャイル「グル」がハードウェア開発について誤解していることアジャイル手法は、ソフトウェア開発の世界に根ざしており、技術業界において変革的な力として称賛されています。しかし、ハードウェアおよび電子機器の開発に進出するにつれて、アジャイル原則の見かけ上スムーズな適応は、課題と誤解の迷宮に直面します。この3部構成の探求の第1回目では、ハードウェアとソフトウェア開発の違いから生じるアジャイルの課題を分析しました。この記事では、アジャイル「専門家」によって広められた神話を検証します。電子ハードウェア開発におけるアジャイルの複雑さに踏み込む前に、アジャイルのコーチやコンサルタントを非難することが私たちの意図ではないことを明確にすることが重要です。私たちは、彼らの善意と、顧客がアジャイル手法の利点を享受するための熱意を認識し、評価しています。批判が生じることもありますが、それはハードウェアの微妙な違いを十分に理解していないことから来るものであり、批判することが目的ではありませんが、アジャイル原則を効果的に適応させ、ハードウェア開発の特定の要求を満たすことが目的です。私たちの焦点は、このユニークな文脈でその利点を活用するためにアジャイル戦術を調整し、アプローチを変更しつつも原則を保持することです。神話＃1：柔軟で適応し続ける必要がありますアジャイルの専門家は、反復的な実行、フィードバックループ、そしてソフトウェアのデジタル領域で栄えている迅速な適応性の長所を正しく賞賛しています。しかし、これらの原則をハードウェアや電子機器の具体的な風景に移行することは、純粋なデジタルスペクトラムにはない複雑さの層を導入します。物理的な解決策は、そのソフトウェアの対応物とは異なり、「完成」する必要があります。部品を注文し、金型を製造し、厳格な製造ニーズを満たすためです。アジャイルの絶え間ない変化への呼びかけは、ゲームの遅い段階でさえ小さな変更が必要な場合、ハードウェアの容赦ない性質と衝突します。これに対応して、ハードウェア開発にアジャイルを適用するには、パラダイムシフトが必要です。それは絶え間ない変更についてではなく、プロトタイピングと、時間、予算、リソースの制約内で価値を最大化することを目指す、迅速な学習と実行サイクルに基づく、情報に基づいた戦略的な適応についてです。アジャイルの機敏さと物理製品の最終性の要求との間のダンスは、より良心的なイテレーション計画と、プロジェクト全体を通じてリスク削減への深いコミットメントを必要とします。神話＃2：毎スプリントで動作するプロトタイプを開発する必要がありますアジャイルの純粋主義者がよく唱える、2〜3週間ごとに完全に機能するプロトタイプを開発する「スプリント」はアジャイルであるための普遍的な「必須」項目とされていますが、このアプローチの実用性は、ハードウェアおよび電子機器の開発（および予算）の現実に直面して崩れます。何かを構築し、進捗を示し、この結果を使用して貴重な技術的および商業的フィードバックを得て、次のイテレーションに役立てるという考え方は正しいです。しかし、各ハードウェアプロジェクトは、独自の目標、依存関係、リードタイムの制約、必要なイノベーションの領域、およびリスクを持つ独立したエンティティです。そして、各プロジェクトは、プロトタイピングと学習に対する独自のアプローチを受けるに値します。アジャイルなハードウェア製品開発を真に受け入れるためには、チームはワンサイズフィットオールの考え方を捨てる必要があります。代わりに、プロジェクトのニーズを慎重に検討し、創造的で学習とプロトタイピングの戦略を導き出すために協力する必要があります。"プロトタイプ"は、予備的なパンフレットから、スティーブ・ジョブズの有名な「ポケットに1000曲を入れる」iPodモックアップのような泡のモックアップ、部分的または完全に機能するプロトタイプまで、あらゆる実証可能な成果物であることを認識することが重要です。神話＃3：バックログにストーリーを追加して、ただ始めるアジャイル手法の固有の強みは、従来のウォーターフォールアプローチよりもプロジェクトをはるかに迅速に開始できる能力にあります。実際、アジャイルハードウェア電子プロジェクトにおいては、概念の特定から開発の開始までの期間が大幅に短縮されていることがわかっています。この期間は、従来の段階的アプローチの下では多くの場合、数ヶ月または数年に及ぶことがありましたが、アジャイル方法では数週間または数日にまで短縮されています。もちろん、この劇的な結果の一部は、私たちが「開発の開始」と定義する方法にあります。ソフトウェアにとって、これは簡単です。アジャイルの専門家は、ソフトウェア機能を定義するためのユーザーストーリーの作成、それらをバックログに優先順位付けし、スプリントを開始することを推奨しています。しかし、ハードウェアでは、少なくともプロジェクトを正しい方向に導くために、アーキテクチャ、重要な望ましい属性、制約、およびその他の要因の理解を伴う最低限の事前計画が必要です。この事前の努力は、「動作するソフトウェアが進捗の主要な尺度である」と「開発の遅い段階でさえ、変更される要件を歓迎する」というアジャイルの原則と明らかに衝突するように見えるかもしれません。和解は、製品開発の前段階に一般的に理解されているアジャイルの戦術を適応させることによってバランスを見つけることにあります。ハードウェアのアジャイルプロジェクト管理は、プロジェクトの戦略的意図に沿って迅速に開始し、従来のアプローチよりもはるかに多くの未知数を受け入れることを可能にします。その後、チームはアジャイルの反復学習を使用して最適な解決策を定義し、スケジュールとリソースの制約内で製品価値を高める戦略的変更に対して開かれた心を持って協力することができます。神話＃4：すべての作業項目をユーザーストーリーとして定義する多くのアジャイルの専門家が唱える重要な指示の一つは、すべての開発作業をユーザーストーリーとして定義すべきだということです。このアドバイスは、システムコンポーネント、インターフェース、他のエンジニアなども「ユーザー」として扱うべきだと続けています。このアドバイスにより、ほとんどの電子機器およびハードウェア開発者は頭を悩ませ、遵守に苦労しています。ソフトウェアチームがアジャイルの実践をすんなりと採用している主な理由の一つは、顧客のニーズを伝統的な要件文書や詳細なユースケースで文書化することが非常に無駄であり、チームにほとんど価値を加えなかったからです。なぜユーザーが何をしようとしているのかを宣言し、その機能を文書化するためにユーザーストーリーを書き、それを開発タスクとして扱わないのでしょうか？これは自己文書化するだけでなく、これらのストーリーが一貫して優先され、顧客との検証が行われれば、変化に対応し価値を最適化するための完璧なクローズドループシステムを持つことになります。素晴らしいですね！ハードウェア開発のためにユーザーストーリーを直接作業項目として書き、それらを価値ある顧客の成果に追跡するこの試みは、多くのハードウェアチームにとってアジャイルの限界点であることがよくあります。ハードウェアを定義することは、ソフトウェアを定義することとは異なります。従来の製品要件文書（PRD）や機能仕様は、ハードウェア開発者にとって安心感を提供するだけでなく、彼らの作業を分解して提供するために必要な詳細を提供します。開発者に「処理ユニットとして、クリーンな入力を保証するために電圧調整が必要です...」のようなユーザーストーリーを書かせることは、ユーザーストーリーを通じて顧客価値を捉える目的を無効にし、ソフトウェア開発者がアジャイル原則で取り除こうとした非価値の無駄を追加します。