Mobile menu
製造技術者
ホーム 製造技術者

製造技術者

In PCB design, a Manufacturing Engineer is a highly skilled professional who is responsible for designing, implementing, and reviewing procedures involved in the manufacturing process. They research automation techniques to maximize production efficiency or plan factory workflows to optimize how products are made across multiple departments. Manufacturing Engineers are experts at finding a balance between reducing costs, maximizing quality, and ensuring that procedures meet safety and environmental requirements.

Manufacturing Engineers in PCB design may also be referred to by other job titles, such as Manufacturing Assembly Engineer, Manufacturing Process Engineer, Manufacturing Manager, or CAM Engineer. These titles reflect the diverse range of skills and expertise required for success in this role, from process optimization and automation to supply chain management and regulatory compliance. Overall, Manufacturing Engineers play a critical role in the PCB design industry, ensuring that products are manufactured with the highest level of efficiency, quality, and safety.

Altium Designer Explore Free Trials Manufacturing Package Viewer
Filter
見つかりました
Sort by
役割
ソフトウェア
コンテンツタイプ
フィルターをクリア
PCB設計者のためのコストのかかる遅延を避けるための重要なヒント コストのかかる遅延を避ける：PCBデザイナーのための重要なヒント 1 min Blog PCB設計者 技術マネージャー 製造技術者 PCB設計者 PCB設計者 技術マネージャー 技術マネージャー 製造技術者 製造技術者 PCB設計の注文を製造業者に保留されたことによるフラストレーションを経験したことはありますか？これは、特に新しいフレキシブル回路やリジッドフレックス設計において、多くのPCB設計者が直面する一般的な問題です。注文が行われると、スムーズな生産プロセスを期待していたものが、しばしばエンジニアリングに関する質問や明確化が必要であるために予期せぬ保留によってすぐに中断されることがあります。これらの保留は些細な不便ではなく、プロジェクトのタイムラインに重大な遅延をもたらし、スケジュールの乱れ、コストの増加、クライアントやステークホルダーとの関係に負担をかける可能性があります。 PCB製造の遅延は、しばしば予防可能であり、提出されたデータパッケージの問題から生じます。欠落している情報や不完全な情報、矛盾、見落とされた詳細が頻繁に生産を妨げ、保留を引き起こします。これらの一般的なエラーを事前に特定し、対処することで、プロセスを合理化し、PCBプロジェクトの成功率を向上させることができます。 ドキュメント：多くの遅延の根源 新しい設計の60％以上が、製造業者が工具設定とプロセスフローを整えている際に「保留」になることはよくあることです。この割合は、 フレックス回路とリジッドフレックス回路の設計ではさらに高くなることがあります。良いニュースですか？これらの問題のほとんどは予防可能です。注文を提出する前に、ドキュメントパッケージ全体と購入注文の要件を慎重に確認してください。すべてが含まれており、正確であることを再確認してください。 注目すべき主要領域 ドリルチャート：ドリルチャートは、PCBに必要な 特定のサイズ、数量、および穴の位置を概説します。ドリルチャートと提供されたドリルファイルの間の不一致は、プロジェクトが保留にされる最も一般的な理由の一つです。この不一致は、製造図面と実際の設計データが一致していないことを示しており、製造業者がプロセスを停止して説明を求めることを促します。これは、CAM（コンピュータ支援製造）プロセスを最初から遅らせ、不必要にプロジェクトのタイムラインを延長することがあります。 スタックアップ：スタックアップ情報は、PCB内の各層の配置、使用される材料、およびそれらの厚さを詳細に説明します。正確なスタックアップデータは、正しいインピーダンスを達成し、ボードが期待通りに機能することを保証するために不可欠です。 インピーダンス表： インピーダンス制御は高速回路にとって重要であり、インピーダンス表の誤りは、要求された電気的性能を満たさないボードを引き起こす可能性があります。指定されたインピーダンス値が実際の設計と一致していること、および必要な計算がすべて正しいことを確認することが重要です。ここでの不一致は、電気的仕様を満たさない製品につながり、再作業や、さらに悪いことに、完全な再設計を必要とする可能性があります。 PCBの寸法：PCBの全体的な寸法、エッジの許容差、および重要な特徴の位置は、正確に文書化されなければなりません。図面と実際の設計データとの間のいかなる逸脱も、製造中に重大な問題を引き起こす可能性があります。たとえば、寸法が正しくない場合、PCBが意図されたエンクロージャに適切に収まらなかったり、他のコンポーネントと正しく整列しなかったりする可能性があり、これはコストのかかる修正やスクラップボードにつながる可能性があります。 製造図面を提出する前に、すべての注記、寸法、および詳細を徹底的に確認し、最新の設計改訂との正確性と一致を確保してください。データセットが完全であることを確認し、回路層、ドリルファイル、はんだマスク、レジェンド、ネットリスト、アレイ指示、および図面が含まれ、正しい改訂と一致していることを確認してください。一般的な間違いとして、更新された回路層を使用しながら古いドリルファイルを提出することがあり、これは大幅な遅延を引き起こす可能性があります。一貫性と完全性を二重に確認することで、コストのかかる後退を避け、製造プロセスを合理化することができます。 例：NFP内のアニュラーリングとドリルから銅までの距離 特徴のサイズが品質、コスト、および納期に影響を与える一般的な例は、アニュラーリングのサイズとドリルから銅までの距離であり、特に 非機能パッド（NFP）に関連しています。柔軟な材料は硬いものよりも扱いが難しく、内層の登録を維持することがより困難になります。可能な限り、これらの課題に対応するために、フレックス層に大きなアニュラーリングを設計してください。複数の積層サイクルが必要な設計の場合、最初のサイクル後にアニュラーリングを増やすことで信頼性を向上させることができます。 さらに、トレースを配置する際には、非機能パッドを取り除く誘惑に抵抗してください。これらのパッドは、ドリルと導体の間の安全な後退距離として機能します。それらを取り除くと、PCBの信頼性が損なわれ、IPC設計ガイドラインに違反する可能性があります。 非機能パッドを取り除いた場合に何が起こり得るかの例をここに示します： 設計仕様：ドリルから銅まで.008インチ。 許容される接触：.005インチの環状リングがドリルから銅までを.003インチにすることを許可する前にエッチングバック。 記事を読む
エンジニアリングにOEMデータを戻す ループを閉じる：OEMが欠陥データをPCB設計および製造チームに効果的にフィードバックする方法 1 min Blog 技術マネージャー 製造技術者 技術マネージャー 技術マネージャー 製造技術者 製造技術者 電子機器の生産において、オリジナル機器メーカー（OEM）は電子部品の品質と信頼性にとって不可欠です。高い基準を維持する上での重要な側面の一つが、特にプリント基板（PCB）の設計と製造に携わるエンジニアリングチームに対して、不良データを効果的に伝達することです。この記事では、OEMがループを閉じ、エンジニアリングチームとの双方向のコミュニケーションチャネルを育むためのプロセスステップ、成功条件、および重要な洞察について詳しく説明します。 1. 不良データフィードバックの重要性 不良データフィードバックは、製造プロセスの継続的な改善に不可欠です。不良データを分析することで、エンジニアリングチームはパターン、根本原因、および改善のための領域を特定することができます。このフィードバックループは、いくつかの理由で重要です： 製品品質の向上：定期的なフィードバックは、設計上の問題を見つけて修正するのに役立ち、より良い製品を生み出します。品質管理を密接にフォローすることで、コストを抑え、廃棄物を減らし、不良品による評判の損失や法的問題を防ぐことができます。 コスト削減：欠陥の早期発見と修正は、再作業、廃棄物、保証請求に関連するコストを大幅に削減することができます。品質管理プログラムは、コストと納期に大きな影響を与えることができます。適切な品質管理がなければ、工場はより多くの廃棄物を生産し、追加の取り扱いと再作業から生じる労働コストが増加します。 市場投入までの時間の加速：効率的なフィードバックメカニズムは、設計および製造プロセスを合理化し、新製品を市場に投入するまでの時間を短縮することができます。品質欠陥メトリックは、企業が品質でどれだけうまくやっているかを測定するための鍵です。良いメトリックは、製品がどれだけ頻繁に、そしてどれだけひどく失敗するかを企業に示し、どこに焦点を当てて改善するか、資源を賢く使う方法を決定するのに役立ちます。 欠陥検出における ディープラーニングの使用が注目を集めています。この技術は、製品の欠陥をカテゴリーに分類することができ、超音波検査、フィルタリング、マシンビジョンなど、欠陥検出に使用される他の技術での応用が、 最高99.4%という高い精度で有望な結果を示しています。ただし、この新興分野での成功率には幅があり（低い場合で88%の精度）、これは先進技術が製造における欠陥データフィードバックの効果を高めるために活用されている例です。 2. 欠陥データフィードバックプロセスのステップ 欠陥データをエンジニアリングチームにフィードバックするプロセスには、いくつかの重要なステップが含まれます： a. データ収集 検査とテスト：欠陥は、製造中および製造後の厳格な検査とテストプロセスを通じて特定されます。これには、デジタルキャリパー、自動検査システム、その他の統計的プロセス制御（SPC）ツールの使用が含まれる場合があります。例えば、ツールモニタリングでは、OEMは最初に初期欠陥のないクリーンなウェハーをチェックします。その後、特定の機械を通して再度チェックします。その機械によって引き起こされた新しい欠陥が見つかった場合があります。 データログ記録：製品の問題は慎重に記録され、問題が何であるか、どこにあるか、どれほど深刻であるかが注記されます。この情報は、顧客からのフィードバック、品質チェック、または製造プロセスの記録から得られることがあります。 b. データ分析 原因分析：エンジニアリングチームは欠陥データを分析して、問題の根本原因を特定します。これには、ヒストグラム、管理図、パレート図などのツールを使用して、分析のためのトレンドを明らかにする作業が含まれます。 記事を読む
組み立てのヒントとコツ 1 min Blog PCB設計者 製造技術者 プロダクションマネージャー PCB設計者 PCB設計者 製造技術者 製造技術者 プロダクションマネージャー プロダクションマネージャー PCB組み立ての技術を習得しましょう。手作業での組み立てに適した専門家のヒントやテクニックを用いて、ステンシルの選択からリフロー工程まで、プロトタイピングでも量産でも、効率的な検証のための組み立てワークフローを最適化します。 記事を読む
進化する卓越性ブログカバー ミニチュア化とウルトラHDIテクノロジーのための組み立てプロセスの再定義 1 min Blog 製造技術者 製造技術者 製造技術者 電子アセンブリで先を行くためには、革新を受け入れ、標準プロセスを再定義することが必要です。7年前、SMTAテストボードは、電子機器のミニチュア化という加速するトレンドに対処するための画期的なはんだペーストテストツールとして導入されました。私たちはこのテストボードを刷新し、向上させる旅に出ます。そして、"Evolving Excellence"の物語の一部である各章を含む、近日公開される電子書籍にご期待ください。 なぜウルトラHDIに移行するのか？ 進化の必要性は否定できません。電子部品の風景は変わり、ミニチュア化は前例のないレベルに達しました。この再設計プロセスに飛び込むにあたり、注目されるのはウルトラハイデンシティインターコネクト（UHDI）技術です。この最先端のアプローチは、現在の業界トレンドと電子製造の将来の要求を予測しています。 ウルトラHDIは、PCB設計、製造、および組み立てにおいて可能な限りの境界を押し広げるパラダイムシフトを提示します。電子デバイスが小型化し、より高い性能を求める需要が高まる中、従来の方法ではもはや十分ではありません。ウルトラHDIへの移行は単なるアップグレードではなく、より細かいピッチ、より狭いスペース、および高度な組み立て技術に対応する戦略的な動きです。 電子書籍は、ミニチュア化とウルトラHDIをSMTAはんだペーストテストツールに取り入れる旅を記録します。概念から実現まで、各章はこの変革的なプロセスを定義する課題、ブレークスルー、および革新を明らかにします。 主要な貢献者に会う Altium 365の革新：Altium 365は、このプロジェクトの開発協力をサポートしています。完成したら、ボードはAltium 365 Embedded Viewerで参照設計として機能します。電子部品テストの革新の限界を押し広げるにあたり、 Altium 365電子開発プラットフォームの相乗効果を探ります。超ミニチュア化された部品の設計プロセスを最新の機能がどのように強化するかを目の当たりにしてください。 Shea Engineeringの専門知識：35年以上にわたり新しい組み立てプロセスのためのテストおよびテストボードを設計してきたChrys Sheaが率いる Shea Engineeringのエンジニアリングの素晴らしさに没頭してください。機械、材料、またはプロセスの最良および最悪の特性を明らかにする効率的な評価に多数のテストをシームレスに統合するために採用された戦略を学びます。 記事を読む
アジャイル・ハードウェア開発 カバー写真 原則が健全である理由、しかし戦術は再考が必要である 1 min Blog シミュレーションエンジニア 機械エンジニア プロジェクトリーダー（マネージャー） +7 シミュレーションエンジニア シミュレーションエンジニア 機械エンジニア 機械エンジニア プロジェクトリーダー（マネージャー） プロジェクトリーダー（マネージャー） テスト技術者 テスト技術者 技術マネージャー 技術マネージャー 私たちの「アジャイルを解明する」シリーズの最終回では、ハードウェア開発がアジャイル手法と交差する複雑な風景をナビゲートします。アジャイルの基本原則は確かな基盤を提供しますが、 電子ハードウェアのユニークな課題に適用される場合、戦術の再評価が不可欠になります。探求の旅で、アジャイルの共通の要素と儀式を解き明かし、それらを具体的な製品開発の文脈で変革する方法を探ります。 アジャイルマインドセットを採用し、一貫して育むことから始める ハードウェア開発における日々のソフトウェアアジャイル実践を強力な利点に高めるための戦術的調整に深く潜る前に、アジャイルマインドセットの基本的な原則をまず受け入れることが重要です。良いスタート地点は、 アジャイル宣言の意図を考慮し、ハードウェア開発のニーズに合わせて言語を修正することかもしれません。以下の表は、ハードウェア開発のための一つの潜在的な宣言を提供します。 各マニフェストの意図の簡単な要約は、 「協力して反復的な開発と学習のアプローチを用い、顧客が本当に価値を見出すものを発見し、提供しましょう。」となるでしょう。もちろん、これはほぼすべてのプロジェクトにとって理にかなっており、チームが日々の開発戦術に没頭する中で、これらの基本的な原則を念頭に置くことが重要です。 方向性計画の重要な役割 アジャイルの反復的な性質は、時に初期計画が後回しにされ、とにかく始めることに重点が置かれるような印象を与えることがあります。しかし、物理的および電子製品の設計と開発の複雑なプロセスをナビゲートするためには、ある程度の事前計画が不可欠です。徹底的な事前計画ではなく、反復的な学習と実行を通じてチームを開発の旅に導くロードマップと考えてください。 アジャイルハードウェア開発の初期計画には、明確な目標の設定、マイルストーンの定義、そして熟考されたプロトタイピングと フィードバック戦略を通じたリスク評価の軽減が含まれます。これにより、チームはアジャイルの適応性と成功したハードウェア開発に必要な構造化された計画の間のバランスを取ることができます。 ユーザーストーリーと作業項目の分離 このシリーズの前の記事で議論したように、 アジャイル「専門家」はしばしば、ハードウェアチームにタスクを定義するためにバックログをユーザーストーリーで埋めるよう促します。ハードウェアのユーザーストーリーを考えてみましょう。新しいフォークリフトの開発を計画していると仮定します。次のようなユーザーストーリーを書きます： "ユーザーとして、素材をすぐに取り出せるようにしたいので、在庫の移動にかかる時間を節約できます。" ハードウェア開発者は何をすべきか知っていますか？おそらく知りません。解決すべき問題の側面が多すぎます。実装には、フォークリフトの速度、フォークアタッチメントの精度、インテリジェントな在庫感知、在庫の向き、その他多くの要因が関わるかもしれません。これらのユーザーストーリーは、具体的な機能やタスクではなく、 製品要件や作業項目というよりも、顧客の目標になるべきです。 ユーザーストーリーは、アジャイルなハードウェア設計フローにおいて、顧客のニーズに焦点を当て、顧客が達成しようとしている結果を明確にするための場所があります。しかし、物理製品のユーザーストーリーは直接的に機能、属性、またはタスクに翻訳できないため、それらはタスクバックログを開発するための出発点となり、バックログアイテム自体にはなりません。 実証可能な進捗と成功のためのプロトタイピング戦略 計算されたプロトタイピングは、ハードウェア開発における要であり、その重要性は過大評価できません。アジャイルの伝道師は、迅速なソフトウェアリリースの美徳を説きますが、ハードウェアの領域では、 記事を読む
アジャイル・ハードウェア開発に関する一般的な誤解のカバーフォト 多くのアジャイル「グル」がハードウェア開発について誤解していること 1 min Blog シミュレーションエンジニア 機械エンジニア プロジェクトリーダー（マネージャー） +7 シミュレーションエンジニア シミュレーションエンジニア 機械エンジニア 機械エンジニア プロジェクトリーダー（マネージャー） プロジェクトリーダー（マネージャー） テスト技術者 テスト技術者 技術マネージャー 技術マネージャー アジャイル手法は、ソフトウェア開発の世界に根ざしており、技術業界において変革的な力として称賛されています。しかし、ハードウェアおよび電子機器の開発に進出するにつれて、アジャイル原則の見かけ上スムーズな適応は、課題と誤解の迷宮に直面します。この3部構成の探求の第1回目では、 ハードウェアとソフトウェア開発の違いから生じるアジャイルの課題を分析しました。この記事では、アジャイル「専門家」によって広められた神話を検証します。 電子ハードウェア開発におけるアジャイルの複雑さに踏み込む前に、アジャイルのコーチやコンサルタントを非難することが私たちの意図ではないことを明確にすることが重要です。私たちは、彼らの善意と、顧客がアジャイル手法の利点を享受するための熱意を認識し、評価しています。批判が生じることもありますが、それはハードウェアの微妙な違いを十分に理解していないことから来るものであり、批判することが目的ではありませんが、アジャイル原則を効果的に適応させ、ハードウェア開発の特定の要求を満たすことが目的です。私たちの焦点は、このユニークな文脈でその利点を活用するためにアジャイル戦術を調整し、アプローチを変更しつつも原則を保持することです。 神話＃1：柔軟で適応し続ける必要があります アジャイルの専門家は、反復的な実行、フィードバックループ、そしてソフトウェアのデジタル領域で栄えている迅速な適応性の長所を正しく賞賛しています。しかし、これらの原則をハードウェアや電子機器の具体的な風景に移行することは、純粋なデジタルスペクトラムにはない複雑さの層を導入します。物理的な解決策は、そのソフトウェアの対応物とは異なり、「完成」する必要があります。部品を注文し、金型を製造し、厳格な製造ニーズを満たすためです。アジャイルの絶え間ない変化への呼びかけは、ゲームの遅い段階でさえ小さな変更が必要な場合、ハードウェアの容赦ない性質と衝突します。 これに対応して、ハードウェア開発にアジャイルを適用するには、パラダイムシフトが必要です。それは絶え間ない変更についてではなく、 プロトタイピングと、時間、予算、リソースの制約内で価値を最大化することを目指す、迅速な学習と実行サイクルに基づく、情報に基づいた戦略的な適応についてです。アジャイルの機敏さと物理製品の最終性の要求との間のダンスは、より良心的なイテレーション計画と、プロジェクト全体を通じてリスク削減への深いコミットメントを必要とします。 神話＃2：毎スプリントで動作するプロトタイプを開発する必要があります アジャイルの純粋主義者がよく唱える、2〜3週間ごとに完全に機能するプロトタイプを開発する 「スプリント」はアジャイルであるための普遍的な「必須」項目とされていますが、このアプローチの実用性は、ハードウェアおよび電子機器の開発（および予算）の現実に直面して崩れます。何かを構築し、進捗を示し、この結果を使用して貴重な技術的および商業的フィードバックを得て、次のイテレーションに役立てるという考え方は正しいです。しかし、各ハードウェアプロジェクトは、独自の目標、依存関係、リードタイムの制約、必要なイノベーションの領域、およびリスクを持つ独立したエンティティです。そして、各プロジェクトは、プロトタイピングと学習に対する独自のアプローチを受けるに値します。 アジャイルなハードウェア製品開発を真に受け入れるためには、チームはワンサイズフィットオールの考え方を捨てる必要があります。代わりに、プロジェクトのニーズを慎重に検討し、創造的で学習とプロトタイピングの戦略を導き出すために協力する必要があります。"プロトタイプ"は、予備的なパンフレットから、スティーブ・ジョブズの有名な「ポケットに1000曲を入れる」iPodモックアップのような泡のモックアップ、部分的または完全に機能するプロトタイプまで、あらゆる実証可能な成果物であることを認識することが重要です。 神話＃3：バックログにストーリーを追加して、ただ始める アジャイル手法の固有の強みは、従来のウォーターフォールアプローチよりもプロジェクトをはるかに迅速に開始できる能力にあります。実際、アジャイルハードウェア電子プロジェクトにおいては、概念の特定から開発の開始までの期間が大幅に短縮されていることがわかっています。この期間は、従来の段階的アプローチの下では多くの場合、数ヶ月または数年に及ぶことがありましたが、アジャイル方法では数週間または数日にまで短縮されています。もちろん、この劇的な結果の一部は、私たちが「開発の開始」と定義する方法にあります。 ソフトウェアにとって、これは簡単です。アジャイルの専門家は、ソフトウェア機能を定義するためのユーザーストーリーの作成、それらをバックログに優先順位付けし、スプリントを開始することを推奨しています。しかし、ハードウェアでは、少なくともプロジェクトを正しい方向に導くために、アーキテクチャ、重要な望ましい属性、制約、およびその他の要因の理解を伴う最低限の事前計画が必要です。この事前の努力は、「動作するソフトウェアが進捗の主要な尺度である」と「開発の遅い段階でさえ、変更される 要件を歓迎する」というアジャイルの原則と明らかに衝突するように見えるかもしれません。 和解は、製品開発の前段階に一般的に理解されているアジャイルの戦術を適応させることによってバランスを見つけることにあります。ハードウェアのアジャイルプロジェクト管理は、プロジェクトの戦略的意図に沿って迅速に開始し、従来のアプローチよりもはるかに多くの未知数を受け入れることを可能にします。その後、チームはアジャイルの反復学習を使用して最適な解決策を定義し、スケジュールとリソースの制約内で製品価値を高める戦略的変更に対して開かれた心を持って協力することができます。 神話＃4：すべての作業項目をユーザーストーリーとして定義する 多くのアジャイルの専門家が唱える重要な指示の一つは、すべての開発作業をユーザーストーリーとして定義すべきだということです。このアドバイスは、システムコンポーネント、インターフェース、他のエンジニアなども「ユーザー」として扱うべきだと続けています。このアドバイスにより、ほとんどの電子機器およびハードウェア開発者は頭を悩ませ、遵守に苦労しています。 ソフトウェアチームがアジャイルの実践をすんなりと採用している主な理由の一つは、顧客のニーズを伝統的な要件文書や詳細なユースケースで文書化することが非常に無駄であり、チームにほとんど価値を加えなかったからです。なぜユーザーが何をしようとしているのかを宣言し、その機能を文書化するためにユーザーストーリーを書き、それを開発タスクとして扱わないのでしょうか？これは自己文書化するだけでなく、これらのストーリーが一貫して優先され、顧客との検証が行われれば、変化に対応し価値を最適化するための完璧なクローズドループシステムを持つことになります。素晴らしいですね！ ハードウェア開発のためにユーザーストーリーを直接作業項目として書き、それらを価値ある顧客の成果に追跡するこの試みは、多くのハードウェアチームにとってアジャイルの限界点であることがよくあります。ハードウェアを定義することは、ソフトウェアを定義することとは異なります。従来の製品要件文書（PRD）や機能仕様は、ハードウェア開発者にとって安心感を提供するだけでなく、彼らの作業を分解して提供するために必要な詳細を提供します。開発者に「処理ユニットとして、クリーンな入力を保証するために電圧調整が必要です...」のようなユーザーストーリーを書かせることは、ユーザーストーリーを通じて顧客価値を捉える目的を無効にし、ソフトウェア開発者がアジャイル原則で取り除こうとした非価値の無駄を追加します。 記事を読む
アジャイル・ハードウェア開発ブログシリーズのカバー ハードウェア開発がただ…異なる5つの方法 1 min Blog 機械エンジニア プロジェクトリーダー（マネージャー） シミュレーションエンジニア +7 機械エンジニア 機械エンジニア プロジェクトリーダー（マネージャー） プロジェクトリーダー（マネージャー） シミュレーションエンジニア シミュレーションエンジニア テスト技術者 テスト技術者 技術マネージャー 技術マネージャー 電子ハードウェア開発におけるアジャイル手法の実装に伴う独自の課題と戦略を探求します。アジャイルフレームワーク内でのハードウェアとソフトウェア開発の主な違いを理解します。 記事を読む