フロントエンドエンジニアリング設計（FEED）：プロジェクト計画のステップバイステップガイド

設計エンジニアリングへの方法論的アプローチ

設計エンジニアリングは、綿密な詳細と方法論的プロセスでアプローチすべきです。すべての可能な解決策と問題の一般的理解を十分に検討せずに早期開発に突入すると、上流工程の開発とプロジェクトコストの問題を招きます。フロントエンドエンジニアリング設計（FEED）は、技術要件に焦点を当てたアプローチです。プロジェクト提案の主要コストを認識することを目的としています。本記事では、このプロセスが次のプロジェクトをどう支援し、潜在的リスクをどう評価するかをステップバイステップで解説します。

---

FEEDの概要

フロントエンドエンジニアリング設計は、問題/製品開発の特性把握に基づきます。これは必ずしも問題ではなく、概念的アイデアや発明の可能性でもあります。目標仕様を持つ一連の目的があり、現在FEEDプロセスには以下の8つのカテゴリがあります：

1. 初期問題の把握
2. 設計パラメータ
3. チーム管理
4. 市場評価とベンチマーキング
5. ユーザーニーズ評価
6. 製品探索
7. 開発計画
8. 目標仕様

このプロセスは設計レビューを通じて評価され、適切に実施されたか確認されます。その後、ソリューション開発段階に進み、最終的にクリティカル設計レビューが実施されます。これらの段階を通じて、設計プロセスと検証は継続的にレビューされ、設計が反省的かつよく計画されたプロセスであることを示します。

設計における考慮事項

設計者はしばしば問題開発を見落とし、後に本来解決すべき問題/課題に対応できない特定の概念的解決策に固執しがちです。この時点でさえ、新しい設計と提案を検討する代わりに、欠陥を解消するためにソリューションを再設計しようとする場合があります。初心者の設計者は、問題開発よりもソリューション開発に焦点を当てる傾向があることがわかっています。

投資収益率（ROI）の向上

研究によると、FEEDを使用する人はプロジェクトを期限内に完了する傾向があります。つまり、設計プロセスでROIが向上します。ワシントンD.C.所在の国立研究評議会は、製品開発と製造コストの少なくとも70%が設計初期段階で決定されると推定しています。

FEEDの活用方法

FEEDは様々な方法で活用できますが、ここでは企業が基準として使用できる標準的なアプローチを扱います。

1. チーム管理

• a. 同僚がタスク優先度に基づく作業スケジュールを作成
• b. 作業分解と各メンバーへのタスク割り当て
• c. 作業者にプロジェクトリスクを評価させる
• d. ドキュメント共有用の共通アクセス可能なファイリング場所を作成
• e. 個別アサインメントの開発報告のための週次進捗ログ

良いプロジェクト計画は、構造化されたスケジュールを効果的に作成・実装するために不可欠です。プロジェクトをタイムリーなスケジュールで遂行するには、チームがプロジェクトの成果物と、それらに割り当てる適切な時間を最大限の精度で見積もる必要があります。予期せぬ遅延と問題を、各成果物の全体スケジュール決定時に組み込む必要があります。部品表（BOM）はプロジェクトを始動させるために必要で、コスト見積もりのために早期に構築すべきです。各チームメンバーは、自分のプロジェクトに何が必要かを詳細に述べなければなりません。必要材料を理解することは不可欠であり、この時点で他の可能性のあるアイテムを予測しておくと、将来の時間を節約でき、プロジェクトの進捗を妨げません。BOMに記載されていない予期せぬアイテムが必ず発生し、製品にとって最良のオプションを決定する際に注意深く扱う必要があり、切迫した状況下での意思決定を避ける必要があります。週次進捗ログは必須ではありませんが、特にリーダーが各メンバーのプロジェクト状況を把握する際にチームにとって有益です。簡潔で要点を絞った週次ブリーフィングは、リーダーがプロジェクトの進捗と遅延原因を把握する洞察を与えます。これにより、リーダーが各メンバーを追いかけて進捗を話し合う手間が省けます。プロジェクトのエラーを最小化することは理想的で、適切に対処しないと遅延と一時的なプロジェクト停止を招きます。エラーがプロジェクト中に消費する総時間は完了時にのみわかります。残念ながら、どの成果物が最も時間とコストを消費したかの理解が得られます。これは類似の将来プロジェクトの視点を提供します。実際の結果と初期タイムラインを比較し、進捗を妨げた状況を見ることで、十分に検討されていなかったアイテムやタスクが明らかになります。予期せぬ出来事は将来プロジェクトのベンチマークとなり、同様の過ちを繰り返さないようにします。

2. プロジェクト計画

進行フローを視覚的に評価する構造化設計プロセス。通常、スケジュールを通じて割り当てられたタスクに基づいてフローチャートを作成します。

3. 初期分析と設計考慮

管理活動完了後、作業者に問題の初期分析を検討させ、問題ステートメントと初期設計考慮事項を記した予備ドキュメントを作成させます。問題ステートメントはFEEDプロセスの進行に伴い進化し、完了時にはソリューション開発段階で問題が完全に特定されます。初期分析は、クライアントとステークホルダーに関する問題ステートメントの疑問にも対応します。この段階では最初の設計考慮事項も対応します。考慮事項には問題ステートメント、設計目的、そして後者が持続可能性、耐久性、保守性などによってどう影響されるかが含まれます。すべては製品探索段階で徹底的に検討されます。

4. ベンチマーキングと市場評価

この段階では、チームが市場で入手可能な最高の製品、使用技術、市場シェアを阻害する可能性のある技術についてデータと技術トレンドを収集すべきです。ここで利用可能なトレンドと今後のトレンドへのアクセスが、自社製品開発のベンチマークとなります。市場規模を見ることで、積極的に存在する潜在的買い手と売り手の視点が得られ、ビジネスが市場参入前に準備できる数値的・定量的指標が得られます。技術トレンドを観察することで、自社製品タイプが他技術と比較してどうであるかを把握できます。これは類似技術の観察や、類似能力を持つ技術のトレンド観察のようなシンプルなものかもしれません。これは製品が市場参入前にどう機能するかを予測するために必要です。規制環境は、あらゆる製品が何らかの形で遵守しなければならない形式的要件です。これらは、特定カテゴリに分類される製品に既存機関が課す規制です。自動車の排ガス規制や、洗浄化学薬品に使用される溶剤の規制などが例です。すべては会社の製品とそれが属するカテゴリに依存します。市場参入が予定されている場合、地方政府が定めた基準を遵守しなければなりません。製品を市場に投入する前に潜在的競合を調査することは常に良いことです。マーケティング戦略の観察、顧客ロイヤルティの評価、コスト比較は、会社が取るべき最良のアプローチを理解するのに役立ちます。効果的なアプローチは競合に良い闘争を提供し、会社の存在を認識させます。市場構造は製品リリース前に評価するのが良く、類似または密接に関連する製品を持つ競合に関する必要情報を提供します。これは市場に存在する企業、その数、市場シェアの分配も記述します。トレンド調査は将来の市場トレンドを予測するために必要です。会社は自社製品が現在および将来どうなるかを理解する必要があります。市場寿命の短い製品は、近い将来にほとんどリターンを生みません。これは顧客の注目を短期間で集められない製品を生産する時間と金の無駄です。

5. ユーザー/顧客ニーズ評価

製品設計の現在および将来のすべてのユーザーに関する考慮事項に対応する必要があります。ここでは、製品がどう使用され、誰が使用するかについてアンケートと調査を通じて情報収集を行います。これはユーザー行動評価に役立ちます。

6. 製品探索

この段階は、機能分析、設計考慮、リスク評価、計画、使用システムの視点を通じて製品探索を理解することを目的とします。マインドマッピングなどのツールを使用し、プロジェクト全体の概念的表現として行えます。機能分析では、製品の機能要件とユーザーに必要な要件を検討します。この時点で、製品とコンポーネントの統合、または製品のシステムへの統合を考慮に入れます。この段階では、製品開発、サプライチェーン、設計、テスト、製造のための技術が存在するかも検討します。市場、顧客ニーズ、機能性をよりよく理解した今、設計の第2反復で主要目的を扱います。意図しない結果、未知要素、その他の不確実性の考慮に加え、生産段階前に発生する可能性のある問題へのより良い先見性を提供します。

7. 開発計画

ここでは収集したすべての情報と材料をまとめ、設計のためのミッションステートメントを開発します。ミッションステートメントは、設計レビューの開始に続くソリューション開発への入力を提供します。この段階の主目的は、ユーザーニーズを変換し、製造可能な予測可能なパフォーマンス向けに設計することです。

8. クリティカル設計レビュー

初期設計レビューは、メンバーがこれまでに完了したことをレビューし、不足しているものや新たな展開を反省する、よく文書化されたチームミーティングであるべきです。クリティカル設計レビューも同じ目標を達成しますが、ソリューション開発プロセスを伴います。これは問題理解と複数のソリューション開発に努力を集中させるために使用されます。プロセスコストが低いこの段階で最も重要な決定を議論するのに最適な時期です。生産前の早期計画で複数のオプションがあり、コスト、製造ニーズ、労働考慮に基づいて各ソリューションのメリットを効果的に評価できます。プロジェクト進行中にソリューションを選択すると、将来の遅延と問題を招く可能性があります。問題開発により多くの時間を費やすことは、ROIを向上させ、創造的設計プロセスをより効果的にします。

---

問題ステートメント開発と考慮事項に余分な時間をかけることで、エンジニアリング設計における不満足な結果の可能性を排除できます。無駄な時間が減り、生産コスト増大を回避できます。