PerfData

制約条件の理論

Webパフォーマンスチューニングで不可欠なTOC(制約条件の理論)を学ぼう

2023年4月17日
著者: 竹洞 陽一郎

はじめに

Webパフォーマンスチューニングは、ユーザー体験やビジネス成果に直接影響する重要な要素です。
この記事では、Webパフォーマンスチューニングをデジタルサプライチェーンマネジメントと捉え、処理のリードタイムと歩留まりを意識したパフォーマンスチューニングが大事であるという観点から、欠かせないTOC(Theory of Constraints: 制約条件の理論)について解説します。

制約条件の理論(TOC: Theory of Constraints)とは

Theory of Constraints(制約条件の理論)は、イスラエルの物理学者であり経営コンサルタントのエリヤフ・ゴールドラット氏によって開発された経営哲学で、組織やプロセスのパフォーマンスを改善するための方法論です。
制約条件の理論の中心的な考え方は、システム全体のパフォーマンスは最も制約の強い要素(ボトルネック)によって決まるというものです。

制約条件の理論では、システムの最適化に5つのステップが提案されています。

1. 制約を特定する
システム内で最も制約が強い要素を見つけ出します。
この要素がシステム全体のパフォーマンスを決定しているからです。
2. 制約を最大限に活用する
制約要素の効率や生産性を向上させるために、リソースやプロセスを最適化します。
3. 他のステップを制約に従わせる
システム内の他の要素やプロセスが制約要素をサポートするように調整します。
制約要素以外の部分での最適化は、システム全体のパフォーマンス向上に寄与しません。
4. 制約を緩和または除去する
制約要素を改善するための投資や変更を実施します。
これにより、制約要素がシステム全体のパフォーマンスを低下させる影響を減らすことができます。
5. 制約が移動した場合、ステップ1に戻る
制約要素が改善された結果、別の要素が新たな制約となる場合があります。
その場合、再びステップ1からプロセスを繰り返します。

制約条件の理論は、生産、プロジェクト管理、サプライチェーン、ソフトウェア開発など、さまざまな分野で適用されており、効果的な改善策とされています。

「ザ・ゴール」とは

エリヤフ・ゴールドラット氏がTOC(Theory of Constraints: 制約条件の理論)を紹介するための教育的な著作として、1984年に出版した小説です。
この小説は、製造業の工場長であるアレックス・ロゴが、会社の経営上の問題を解決するために、TOCを使って製造プロセスの最適化を行うというストーリーで構成されています。
「ザ・ゴール」では、アレックスが製造プロセスにおける制約を見つけ出し、制約を解消することでプロセス全体の効率性を向上させる過程が描かれています。

「ザ・ゴール」は、TOCを理解するための入門書として高い評価を得ており、ビジネスにおけるプロセス最適化に関心のある読者には必読の書と言えます。
TOCを用いた製造業の改善事例が多数含まれているため、製造業に従事する人々に特に役立つ書籍ですが、ITにもその考え方を取り入れることが可能です。

「日本で出版されると、世界経済が破綻してしまう」と言われて、2001年まで翻訳が許可されませんでした。
まだ日本経済が強かった1990年代の話です。

私は読書魔なので、当時2001年5月17日の初版を買って読んだのですが、とても衝撃的でした。
私は、この「ザ・ゴール」と、これに続くシリーズを読んで、TOCの基礎と応用を学び、仕事に活かすことが出来ました。
システムパフォーマンスチューニングをすんなりとできるようになったのも、この本のお陰です。

リードタイム、歩留まり、制約

制約条件の理論(Theory of Constraints, TOC)において、「リードタイム」(Lead Time)、「歩留まり」(Yield)、「制約」(Constraint)は、それぞれプロセスの異なる側面を表しています。
これらの概念が相互に影響し合い、システム全体のパフォーマンスに影響を与えます。

リードタイム(Lead Time)
リードタイムは、あるプロセスが開始されてから完了するまでにかかる時間を指します。
制約条件の理論において、リードタイムは、制約を特定し、改善することで短縮される可能性があります。
制約の存在により、システム内の一部のプロセスが遅れることがあり、全体のリードタイムが長くなることがあります。
歩留まり(Yield)
歩留まりは、生産プロセスにおいて、出来上がり品のうち正常品の割合を示します。
制約条件の理論では、制約を改善することで、歩留まりの向上が期待できます。
制約が存在するプロセスでは、不良品の発生やリワークが増加し、歩留まりが低下することがあります。
制約(Constraint)
制約は、システム内で最も制約が強い要素で、システム全体のパフォーマンスに影響を与えるボトルネックを指します。
制約条件の理論では、制約の特定、改善、および管理を通じて、リードタイムの短縮や歩留まりの向上を目指します。

リードタイム、歩留まり、制約は、互いに密接に関連しています。
制約が改善されると、リードタイムが短縮され、歩留まりが向上することがあります。
逆に、制約が存在する場合、リードタイムが長くなり、歩留まりが低下することがあります。

制約条件の理論を用いて、これらの要素をバランスよく改善することで、組織やプロセスのパフォーマンスを向上させることができます。

ハイキングを通じて制約条件の理論を学ぶ

「ザ・ゴール」では、第4章「ハイキング」を通じて制約条件の理論が示されています。
物語の主人公アレックスは、息子デイブのボーイスカウトの泊りがけのハイキングに参加します。
15人の子どもたちは、狭い道を一列に並んで歩く16kmの道のりを進み、「悪魔の峡谷」と呼ばれる目的地を目指します。

最初に指示を出さずに歩かせると、隊列がすぐに長くなってしまいます。
そこでアレックスは、適度なペースで歩くようにロンという子に指示を出し、隊列の先頭を歩かせて隊列の伸びを抑えます。
しかし、隊列の前半はスムーズに進むものの、後半の部分が遅れて続いてしまいます。
原因は、隊列の途中にいる体型が大きいハービーが息を切らし、隊列のペースについていけないためでした。

この状況からわかるのは、隊列の長さが一連の処理の時間を示し、その長さの制約要因はハービーだということです。

ハービーを先頭にした場合はどうでしょうか?
ハービーのペースで進むので、隊列が長く伸びることはありません。
ただし、「悪魔の峡谷」にたどり着く時刻が遅れることになります。

このエピソードは、制約条件の理論の重要性を理解する上で非常に示唆に富んでおり、ボトルネックや制約要因を把握し、適切な対応を取ることで効率的な結果を生み出すことができることを示しています。

Webパフォーマンスにおける制約条件の理論の適用

ハイキングで一列に並んで進む様子は、コンピュータ処理における順次処理と似ています。
Webページがリクエストされてから表示されるまでの一連の処理は、依存関係があり、追い越すことはできません。

以前の記事「HTML文書構造から学ぶフロントエンドのパフォーマンスチューニング」で紹介したレンダリング処理の図をおさらいのために、再度掲載し、この流れに沿ってブラウザ上での順次処理を追ってみましょう。

モダンなHTML Living Standardの仕様に基づいた書き方で実現するシンプルなレンダリング処理
  1. URLを入力する
  2. DNSで名前解決をしてIPアドレスを得る
  3. 目的地のIPアドレスまでの経路を確定し、TCP 3way handshakesで接続を確立する
  4. SSL handshakesを行う
  5. HTTP GET/POSTリクエストを送る
  6. Webサーバ/CDNからHTMLを送出するまで待機する
  7. HTMLが送出されて、読み込まれる
  8. HTMLをWebブラウザが解釈を開始する
    • Preload ScannerがShallow Parseを行い、CSSやJavaScript、画像のリクエストを出す
    • それと同時にHTML Parserが、HTMLを解釈してDOMツリーの構築を始める。
  9. DOMツリーを構築し終えたところで、DOMContentLoadedが発火する
  10. defer属性が付与されたJavaScriptが実行される
  11. レンダリングツリーを構築する
    • 出来上がったDOMツリーに、CSSを解釈して出来上がったCSS Object Modelツリーを適用する
    • 画像をレンダリングツリーの中にアタッチする
  12. レイアウト
  13. 描画
  14. window.onloadの発火

この14のステップを、ハイキングの隊列の子どもたちと考えてみてください。
あなたのWebページの処理において、「ハービー」はどこにいますか?
先頭の方にいれば表示開始までに時間がかかるでしょうし、後尾にいれば表示完了までに時間がかかるでしょう。

「ボトルネック」という言葉はよく使われますが、Webパフォーマンスにおいて「ボトルネック」とは、単にダウンロード時間が長い箇所を指す言葉ではありません。
以上のように依存関係を持つ一連のプロセスの中で、制約要因となって、そこの処理時間で全体の処理時間が決まってしまう箇所を「ボトルネック」と呼びます。

誤解されているボトルネックと対策

画像
画像は、現在のHTML Living Standardの仕様においては、ボトルネックにはなりません。
それは、画像の読込は、decoding="async"によって、この一連の順次処理から外すことができるからです。
HTMLのレンダリング処理などの時間を利用して、ダウンロードが並列処理できるので、制約要因になりません。
また、HTMLのパース処理で画像の読込の箇所が止めることが無くなり、処理時間を短縮できます。
ですから、画像を汚くしてまで極端に画像の圧縮を行う必要はありません。
しかし、JavaScriptの処理と依存関係を持たせてしまうと、decoding="async"は無効化されるので、注意が必要です。
CSS、JavaScript
CSSやJavaScriptも、読込においては、ボトルネックにはなりません。
ですからminifyする必要もないですし、圧縮する必要もありません。
インラインでCSSやJavaScriptを書くと、HTMLのパース処理を都度中断させてしまい、そこを遅延させて制約要因にしてしまいます。

まとめ

Webパフォーマンスの向上は、ユーザーエクスペリエンスの改善に直接関連し、ビジネス成功にも寄与します。
Webページの表示プロセスを把握し、制約条件の理論を適用してボトルネックを特定することが重要です。
ボトルネックは、処理の依存関係において制約要因となる箇所であり、これを特定することで効果的なパフォーマンスチューニングが実現可能です。

画像やCSS、JavaScriptはダウンロードに関して、ボトルネックになることはほとんどありません。
ただし、それらの読込や処理方法、他の処理との依存関係がある場合は遅延の要因となります。

ぜひ、「ザ・ゴール」を読んで、TOCの考え方を学んでみてください。
パフォーマンスチューニングへのアプローチが大きく変わることでしょう。