意思決定はエンジニアリングの不可欠な部分です. それは、データベース、メッセージ列、またはCSVライブラリを選択することを意味するかもしれません. 複数のオプションが実行可能ですが、コミットオフが異なる場合、あなたはフィールドを狭めるための実践的な方法が必要です. 目標は、迅速に、論理的に、効果的に決定することです. 役に立つ戦略は このアプローチは、選択が明確になるまで、選択肢を体系的に縮小するのに役立ちます。目標は、あらゆる選択肢を徹底的に分析することなく、問題の「形」、解決空間の粗末な形状をどのように迅速に得ることができるかを示すことです。 Elimination by Aspects (EBA) 側面による排除とは? Elimination by Aspects は、心理学者 Amos Tversky によって 1972 年に導入された決定のヒューリスティックです。 コアアイデアは、一度に 1 つの基準 (側面) を適用することによって、選択肢のリストを徐々に削除することです. 次に次の基準に移行し、管理可能なショートリストまたは単一の勝者さえ残るまで。 Key characteristics of EBA: これは反復的で非補償的プロセスであり、これは、他の要因でどれほど優れているかにかかわらず、1つの重要な基準が失敗するオプションが欠けていることを意味します。 あなたは効果的に、すべての側面について一連のYes / No決定を下し、すべてを一度に比べるのではなく。 例:EBAで草刈り機を購入する プロセスを説明するには、まず非ソフトウェアの例を用いてみましょう:草刈り機を購入します。 モーターの種類:それは乗り物、ロボット、またはポッシングモーターですか? Yard Size: あなたが切る必要がある領域はどのくらいですか? 地形:急な斜面(15°以上)で切る必要がありますか? パワー&メンテナンス:ガスエンジンパワーまたは電気(バッテリー/ケーブル)を好むか?そしてどのくらいのメンテナンスで大丈夫ですか? 予算範囲:あなたの予算の上限は何ですか? これらの側面を順次適用することで、選択肢を数千から数カ所に切り下げることができます。基本的に、最も結果的な質問を最初に質問します(フィールドを最も分割するもの)。EBAは、プロセスの早期に情報を最大限に獲得する側面を選択するときに最適です。 ChatGPT Thinking/Pro または Gemini 2.5 Pro (ウェブ検索が有効) がかなり良い EBA スタイルの質問を生成したことを発見しました。 例: EBA で CSV Parser ライブラリを選択 次に、EBA をソフトウェアエンジニアリングの決定に適用しましょう. プロジェクトのための CSV 解析ライブラリを選択する必要があると仮定します. Here is how an elimination-by-aspects strategy might look: Do a broad search filtered by your programming language to list all CSV parser libraries that could be relevant. This is your initial pool. Start with the Universe of Options: Immediately discard any libraries that look obviously unsuitable for production use. Suitability for Production: Apply a few must-have sanity criteria to the remaining list: Basic Viability Check: The library should at least compile/build or install cleanly. Compilation/Installation: While not a perfect metric, check if the library has at least a minimal level of adoption, for instance, a few hundred stars on GitHub or a decent number of weekly downloads on NPM/PyPI. Popularity/Community Usage: If there’s no README or documentation, that’s a huge red flag. Documentation: If it’s been out for a while, then there is more time for people to report the package being malicious, etc. When was the package published, was it yesterday? With a shorter list in hand, introduce more specific criteria based on your project’s needs: Feature and Performance Requirements: Do you need to parse very large CSV files or do streaming? Performance: Identify required features (e.g., does it handle quoted fields correctly? Can it parse into custom data types or handle different delimiters? Does it also support writing CSV, if you need that?). Features: Consider how the library handles malformed data or edge cases (like newline characters within fields, missing values, etc.). Robustness: Does the library drag in huge external dependencies or native modules? Dependencies: Is the library actively maintained? Maintenance: By this point, you’ve likely narrowed it down to a handful (or even a single) candidate that meets all your aspects. Final Selection: 「csv」とタグ付けされた200 npmjs ライブラリに、すべての 200 個の readmes を Gemini 2.5 Pro チャットに付加することによって、側面による除去を適用しました。 「csv」とタグ付けされた200 npmjs ライブラリに、すべての 200 個の readmes を Gemini 2.5 Pro チャットに付加することによって、側面による除去を適用しました。 「サーバー側のユーザーダウンロードではなく、ブラウザベースのユーザーダウンロード」のさらなる改良により、選択肢が30に減少しました。この繰り返しのプロセスにより、望ましい機能に基づいてますます特定のフィルタリングが可能になりました。 あなたが200のリードメスをダウンロードすることを望まない場合(私はあなたを責めません)、私はジェミニのために使用したプロンプトは、「npmjs.orgでcsvパッサーライブラリを選択するためにあなたの質問に対する私の答えに基づいて私が使用すべきライブラリを教えてください」と、それから私にインタビューし、私の答えに基づいて私のためにライブラリを選択しました。 テクノロジー決定におけるEBAの利用の利点 ソフトウェアエンジニアリングの意思決定における除去側面の使用は、いくつかの利点を提供します: Overwhelmを減らす:一度に1つの基準に焦点を当てることによって、すべての選択肢のすべての要因を同時に重ねることの精神的燃焼を避けることができます。 必須要件が満たされていることを確保する: EBAは、あなたの非交渉可能な要件を最前線で特定し、優先することを強制します。 透明で防御可能なプロセス: EBAの段階的な性質は、あなたの意思決定プロセスを透明にします。 偏見を減らし、客観性を促進する:特定のオプションに恋に落ちる前に基準を決めることは、馴染みあるいは「明るい新しい」テクノロジへの膝の偏見を軽減することができます。 見守るための警告と制限 決断テクニックは完璧ではないので、アプローチによる除去を使用する際には、以下の警告を心に留めてください。 Non-Compensatory = No Trade-Offs: EBA が非賠償的であるため、選択された基準の 1 つに失敗した場合、異なる優れたオプションが投げ捨てられます。 順序の問題: 基準を適用する順序は結果に影響を及ぼす可能性があります. 通常、最も優先的な側面から始めるのは賢明ですが、本質的に「Xがなければ、他の何も重要ではありません」と主張します。 明確で測定可能な基準が必要です: EBA は、あなたの側面が明確に定義されている場合に最適です. たとえば、スケーラビリティを「10k リクエスト/秒以上に対処しなければならない」またはセキュリティを「過去 1 年間に重要なコンプライアンス レポートがないようにしなければならない」と定義します。 ユニークな優勝者を生み出さない:時には、側面のリストを通過し、まだバージョンまたはいくつかの実行可能な候補者で終わる場合があります。 Wrapping Up 側面による削除は、ソフトウェアエンジニアの意思決定ツールボックスの便利なツールです. あなたがテクノロジーやデザインの選択肢の恐ろしいリストに直面するたびに、側面で考えてください:あなたの必須のものを見つけて、それらの箱をチェックしないオプションを削除し始める。 急速に変化するテクノロジーの世界では、毎週新しいライブラリやフレームワークが登場するため、このアプローチは、あなたとあなたのチームが分析の麻痺を避け、自信を持って意思決定を下すのに役立ちます。 最終的には、側面による排除は完璧な選択を保証するものではありません(いかなる方法もできない)、しかし、それはあなたのニーズを満たす良い選択に到達するための合理的で繰り返しのプロセスを提供します。
