39の技術特性を読み解く-自社課題を"人類の発明知"に接続する共通言語（Part3）

本記事は、Part 1・2で学んだ「矛盾の消去」という思想を、実際にマトリクスで引けるレベルに引き上げる実践編です。39の技術特性を6カテゴリに整理し、現場の言葉を"人類の発明知"に翻訳する共通言語として使いこなす道筋をお伝えします。

なぜ39特性を学ぶ必要があるのか

Part 2で、TRIZの4ステップの第2段階が「39特性への抽象化」であることをお伝えしました。ここを飛ばすと、過去3万件（現在では250万件以上）の特許から抽出された発明知にアクセスできません。逆に言えば、現場の生々しい悩みをこの39語のいずれかに翻訳できた瞬間、あなたの課題は「人類が過去に何度も解いてきた矛盾」の仲間入りをします。

多くの技術者はトレードオフを"調整"しますが、TRIZは"消去"を目指す――この思想を実現する鍵が、共通言語としての39特性なのです。

カテゴリ①：物理量に関する特性（No.1〜7, 12）

最も基本的な物性値のグループです。重量(静止物体/移動物体)、長さ、面積、体積、形状などが含まれます。ハードウェア開発では日常的に登場しますが、SaaS・IT領域では「データサイズ」「画面面積」「コンテナの体積=メモリ容量」といったメタファで読み替えると応用範囲が広がります。

代表例：No.1 移動物体の重量／No.2 静止物体の重量
スマートウォッチの軽量化は「移動物体の重量」の改良ですが、同時にバッテリー容量(動力)が悪化します。典型的な技術的矛盾ですね。

自社への問い：自社プロダクトで「軽く/小さく/薄くしたい」という要求は、どの物理量に対応しますか？

カテゴリ②：空間・構造に関する特性（No.7〜12）

体積、形状、物体の安定性、強度、構造の安定性などが属します。クラウドアーキテクチャで言えば「システム構成の安定性」が該当し、マイクロサービスの分割粒度問題はまさにこのカテゴリの矛盾です。

代表例：No.13 物体の安定性
サービスの可用性を高めたい(安定性↑)が、機能追加のスピード(速度)は落としたくない――これはDevOps現場の永遠の課題です。

自社への問い：あなたのシステムで「構造を変えたくない理由」は、どの安定性を守るためですか？

カテゴリ③：時間・速度・動力に関する特性（No.9, 15, 21, 25）

速度、動作時間、動力、時間の損失など、現代ITサービスが最も向き合うカテゴリです。Part 2で扱った「エッジAIの処理能力 vs 通信遅延」はこの領域の典型例でした。

代表例：No.9 速度／No.21 動力
SaaSのレスポンス高速化(速度↑)は、サーバーコスト(動力↑)とほぼ必ず衝突します。「ワークフロー単位で閾値を設ける」というPart 1で紹介した解決策は、この矛盾を"調整"ではなく"消去"した好例です。

自社への問い：自社サービスの「速くしたい処理」と「そのために犠牲になっているもの」を2行で書けますか?

カテゴリ④：エネルギー・力・温度に関する特性（No.10, 11, 14, 17〜19, 22）

力、応力、強度、温度、明るさ、エネルギー消費などが含まれます。スマホ発熱問題(Part 2)で扱った「動力21 × 温度17」はこのカテゴリの代表的な組み合わせでした。データセンターの冷却問題、エッジデバイスの省電力設計も同じ構造です。

代表例：No.17 温度／No.19 移動物体のエネルギー消費
ノートPCの薄型化と放熱の矛盾は、突き詰めると「筐体体積 × 温度」または「動力 × 温度」に帰着します。

自社への問い：エネルギーや熱に関する制約は、自社の設計判断をどこで縛っていますか?

カテゴリ⑤：損失・有害作用に関する特性（No.22〜25, 30, 31）

エネルギー損失、物質損失、情報損失、時間損失、物体が受ける有害要因、物体が発する有害要因――TRIZが特異的に重視するカテゴリです。「損失を減らす」という発想は、あらゆる業界で改善余地が大きい領域です。

代表例：No.24 情報損失
マイクロサービス間のAPIコールで発生するコンテキスト欠落は、まさに「情報損失」です。BFF(Backend for Frontend)パターンは、この損失を構造的に消去しようとする試みと解釈できます。

自社への問い：自社の業務プロセスで、最も"こぼれ落ちている"ものは何ですか?

カテゴリ⑥：システム特性（No.27〜29, 32〜39）

信頼性、測定精度、製造精度、保守性、修理容易性、適応性、装置の複雑さ、制御の複雑さ、自動化、生産性――組織やサービス運用に直結する高次の特性群です。

代表例：No.37 制御の複雑さ／No.38 自動化
MLOps領域では「自動化を進めたい(38↑)」が「制御の複雑さ(37↑)」も増大する、という矛盾が頻繁に発生します。可観測性ツールの進化は、この矛盾の消去に向けた産業規模の取り組みです。

自社への問い：自社で「自動化したいがリスクが怖い」と止まっている領域はどこですか?

39特性 早見表

使い分けガイド ── 課題タイプ別「どの特性から見るか」

タイプA：コスト削減・効率化系
→ カテゴリ⑤（損失系特性）から入ります。「どこで何が失われているか」を先に可視化すると、改良特性が自然と浮上します。クロスチェックには39.生産性を置きます。

タイプB：停滞打破・性能限界系
→ カテゴリ③(速度・動力)と⑥(27.信頼性)を同時に見ます。性能頭打ちの正体は、だいたいこの2カテゴリの衝突です。

タイプC：新規企画・次世代構想系
→ カテゴリ⑥(35.適応性、38.自動化)から逆算します。「未来あるべき姿」の特性から現状とのギャップを取ると、改良すべき特性が明確化します。

タイプD：トレードオフ・矛盾解消系
→ Part 2の4ステップに直行。改良特性と悪化特性を39特性に翻訳し、マトリクスを引きます。

自社への問い：あなたの今の課題は、A〜Dのどのタイプに最も近いですか?

まとめ

39の技術特性は、単なる用語集ではありません。現場の個別具体の悩みを「人類が過去に解いた矛盾の仲間」に接続するための共通言語です。6カテゴリで俯瞰し、課題タイプ別に入口を決めれば、抽象化の迷いは大幅に減ります。

そして思い出してください――この翻訳作業は、妥協点探しの"調整"から抜け出し、矛盾そのものを"消去"する突破口を開くための準備作業です。次回Part 4では、いよいよ40の発明原理の前半(原理1〜20)に踏み込み、翻訳された矛盾をどう"解く"のかを具体的に見ていきます。

次の行動

今取り組んでいる課題を、本記事の早見表と使い分けガイドを使って「カテゴリ → 特性番号」の形に翻訳してみてください。5分の作業で、次のPart 4を読む準備が整います。

【著者より】
39特性の習熟は、TRIZ学習の最大の壁であり、同時に最大のレバレッジポイントです。全部を暗記する必要はありません。「自社課題でよく使う5〜6個」を自分の持ち札にするところから始めてみてください。