問題には「現象」と「原因」がある。

突然ですが、
どんな分野においても、問題には「現象」と「原因」が存在します。

「現象」は、特定のTPOにおけるスナップショットであり、
「原因」は、そのスナップショットを構築する要素です。
そして、時に「原因」は「現象」として観察することができます。

現象）進捗が悪い
　　　　　↓
原因）予定した工数を確保できていない

現象）工数を確保できない
　　　　　↓
原因）飛び抜けて朝寝坊なプログラマがいる

現象）プログラマが朝寝坊だ
　　　　　↓
原因）自己管理ができず、夜遅くまでモンハンに興じているらしい

現象）モンハンにハマってしまう
　　　　　↓
原因）モンハンはとても面白い

現象）モンハンは面白い
　　　　　↓
原因）パーティーで狩りができる

おっと、どうやら原因分析の方向を間違えたようです。
パーティーで狩りできる機能を削除することが
プロジェクトの進捗を回復するための手段ではないでしょう。

現象）プログラマが朝寝坊だ
　　　　　↓
原因）自己管理ができず、夜遅くまでモンハンに興じているらしい

現象）自己管理ができない
　　　　　↓
原因）フルフレックスが甘えを生んでいるらしい

フルフレックス制度を撤廃すれば、
進捗が回復する見込みはあるでしょう。
（一方で、失うものもあるかも知れませんが）

このように、問題には「現象」と、それを構成するいくつかの「原因」があり、
それを適切にドリルダウンしていくためには、スキルが求められます。

さて、話をJavaに戻しましょう。

いわゆるトラシューツールができるのは、
いわゆる「現象」の確認であり、最終的な「原因」を教えてくれません。
だからこそ、トラシューツールを使うのは難しいのです。

具体例を挙げてみましょう。
まずは成功例から。

なんか遅い
　　↓（CPUモニタ）
CPU使用率が高い
　　↓（プロファイラ）
○○メソッドのCPU使用率が高い
　　↓（ソースコードを見る）
異常なループを発見！
　　↓（ソースコードを直した）
遅くなくなった！

一方で、スキルが足りなければ失敗することもあります。

なんか遅い
　　↓（CPUモニタ）
CPU使用率は低い
　　↓（プロファイラ）
○○メソッドに時間が掛かっているらしい
　　↓（ソースコードを見る）
怪しい所は見つけられない・・・
　　↓（ソースコードを直せない）
遅いまま・・・

実は、○○メソッドには過剰なsleepがあったのですが
解析者のスキルが足りないがために、ソースを見ても問題は見つかりませんでした。
また、解析ツールも、sleepの長さまでは教えてくれませんでした。

改めて言いますが、問題には「現象」と「原因」があり、
本当の「解決策」に至るには「原因のドリルダウン」が必要です。
この「原因のドリルダウン」には、スキルが求められるのです。