本記事は、Part 3で翻訳した39特性の矛盾を、いよいよ"解く"段階に進むための実践編です。アルトシュラーが3万件(現在では250万件以上)の特許から抽出した40の発明原理のうち、前半20原理を現代IT・サービス業の事例とともに解説します。
なぜ40の発明原理なのか
Part 1で「TRIZは矛盾を消去する」、Part 2で「4ステップで解く」、Part 3で「39特性で翻訳する」ことを学んできました。しかし翻訳しただけでは矛盾は解けません。マトリクスが指し示す発明原理を"発想のレンズ"として使いこなせて初めて、突破口が開きます。
40原理は一見バラバラに見えますが、「分ける」「変える」「逆にする」「事前に仕込む」といった根源的な思考パターンの集合体です。多くの技術者はトレードオフを調整しますが、TRIZは消去する――その消去のボキャブラリーが40原理なのです。
グループ1:分離・分割系(原理1〜4)
原理1:分割
対象を独立した部分に分ける、分解しやすくする。モノリシックなアプリケーションをマイクロサービスに分割するのは、この原理の現代的応用そのものです。
原理2:分離・抽出
邪魔な部分や必要な部分だけを取り出す。Part 2のスマホ発熱例で、CPU処理の一部をクラウド/エッジに分離した発想がこれに該当します。
原理3:局所的性質
対象の各部分に異なる機能を持たせる。SaaSで「ワークフロー単位にレイテンシ閾値を設定する」(Part 1)は、全体を均一に扱わず部分ごとに最適化する好例です。
原理4:非対称性
対称的な形を非対称にする。A/Bテストで片側だけに新機能を出すこと、カナリアリリース、地理的に非対称なCDN配置はすべてこの原理の応用です。
自社への問い:自社プロダクトで「一律に扱っている対象」を、部分ごとに分けて最適化できる余地はありますか?
グループ2:結合・汎用化系(原理5〜7)
原理5:併合
同種/関連する操作をまとめる。バッチ処理、GraphQLの複数クエリ統合、ストリーム処理でのウィンドウ集約などが典型例です。
原理6:汎用性
1つの対象に複数の機能を持たせる。スマホが電話・カメラ・財布・鍵を兼ねたのは原理6の究極形ですね。
原理7:入れ子
対象を別の対象の中に入れる。Dockerコンテナ、仮想化、Kubernetes Podの入れ子構造は、この原理がインフラ設計の基盤になっている証拠です。
自社への問い:別々に管理している機能やデータを1つに統合することで、同時に複数の矛盾が消える領域はありませんか?
グループ3:事前対策系(原理8〜11)
原理8:つり合い
重さや偏りを別の力で打ち消す。負荷分散、オートスケーリング、カオスエンジニアリングによる事前耐性テストがこの系統です。
原理9:先取反作用
害が起こる前に反作用を加えておく。回復可能なトランザクション設計、冪等性の事前設計、blue-greenデプロイでのフォールバック準備などが該当します。
原理10:先取作用
必要な作用を事前に完了させておく。キャッシュ先読み、静的サイト生成(SSG)、事前コンパイルは原理10そのものです。Part 1で紹介した「ローカル評価やキャッシュ先読みで高速性と正確性を両立する」アプローチはまさにこれですね。
原理11:事前保護
信頼性の低い部分を事前に守る。サーキットブレーカー、レートリミット、WAF(Web Application Firewall)は事前保護の現代版です。
自社への問い:現在"事後対応"で回している業務のうち、"事前仕込み"に移せるものはどれですか?
グループ4:逆転・変形系(原理12〜17)
原理13:逆転
通常とは逆の行動をとる。「サーバーがクライアントに問い合わせる」のではなく「クライアントがサーバーに購読(Subscribe)する」に逆転したPub/Subモデル、"Pushではなく Pullで同期する"Gitの設計思想などが典型です。
原理14:曲面化
直線を曲線に変える。UIデザインで角丸が標準化したのは見た目だけの話ではなく、認知負荷の低減という機能的理由があります。
原理15:ダイナミック性
対象を動的に変化可能にする。Feature Flag、動的スケーリング、アダプティブビットレート配信(Netflix等)はすべてダイナミック性の応用です。静的設計から動的設計への移行は、現代ITの大きな潮流そのものです。
原理16:部分的・過剰作用
100%が難しければ90%や110%でよしとする。eventual consistency(結果整合性)は、厳密な整合性を諦めることで可用性を消去的に獲得する典型例です。
原理17:他次元への移行
1次元から2次元/3次元へ。平面ラック配置から垂直統合アーキテクチャへ、タスクの直列実行から並列実行への移行はこの原理です。
自社への問い:自社で"当たり前"になっている方向性を、逆転または次元変更したらどうなるでしょうか?
グループ5:動的化・周期化系(原理18〜20)
原理18:機械的振動
振動や揺らぎを加える。Chaos Monkeyによる意図的障害注入、ジッター付きリトライは"揺らぎが安定を生む"という逆説的な応用です。
原理19:周期的作用
連続作用を周期的作用に変える。ポーリングをイベント駆動に切り替える、cronによる定期バッチ、ハートビート監視などが該当します。
原理20:有益作用の継続
有益な作用を休みなく続ける。ゼロダウンタイムデプロイ、ローリングアップデート、常時CI/CDパイプラインはこの原理の実装です。
自社への問い:自社で「止めないと更新できない」と諦めているプロセスはありませんか?
使い分けガイド ── 前編20原理をどう引き出すか
パターンA:「一律処理」の詰まり
全体を同じルールで扱うことに無理が出ている → 分離・分割系(1-4)から着手。「どこを分ければ矛盾が消えるか」を問います。
パターンB:「バラバラ運用」の非効率
個別管理のコストが膨らんでいる → 結合・汎用化系(5-7)。複数の別管理を1つに統合できないかを探ります。
パターンC:「事後対応疲れ」
トラブル対応に追われている → 事前対策系(8-11)。"先に仕込む"への発想転換です。
パターンD:「常識の壁」
業界慣習や社内慣行で思考停止している → 逆転・変形系(13,15,17)。方向を逆にする、動的化する、次元を変える。
パターンE:「完璧主義の硬直」
100%を目指して前に進めない → 原理16。90%や結果整合性で突破口が開くことがあります。
パターンF:「ダウンタイム前提の運用」
→ 動的化・周期化系(18-20)で"止めない設計"へ。
自社への問い:今の詰まりは、A〜Fのどれに最も近いでしょうか?
まとめ
前編20原理は、分離、結合、事前対策、逆転、動的化という5つの思考方向を提供します。重要なのは、原理を暗記することではなく「自社の詰まりパターン → 原理群」のマッピングを持つことです。マトリクスが示す原理番号を見たとき、その原理が"どんな消去のレンズか"を即座に取り出せる状態を目指しましょう。
次回Part 5では、後半20原理(原理21〜40)に加え、シリーズ全体を貫く実践フロー――矛盾の言語化から発明原理の適用、二次的問題への対処まで――を総まとめします。いよいよシリーズの終着点です。
次の行動
本記事の20原理の中から、「自社の現在の詰まりに最も効きそうな原理」を3つ選び、付箋に書いてデスクに貼ってみてください。1週間後、その原理のレンズで課題を見直すと、これまで見えなかった選択肢が浮かび上がります。
---
【著者より】
40原理を初めて学んだとき、私は「そんな都合のいい引き出しがあるのか」と半信半疑でした。しかし9年使い続けた今、確信しています――これは引き出しではなく、発明者たちが残してくれた"諦めないための地図"です。後編でお会いしましょう。