突然ですが、
どんな分野においても、問題には「現象」と「原因」が存在します。
「現象」は、特定のTPOにおけるスナップショットであり、
「原因」は、そのスナップショットを構築する要素です。
そして、時に「原因」は「現象」として観察することができます。
現象）進捗が悪い
↓
原因）予定した工数を確保できていない
現象）工数を確保できない
↓
原因）飛び抜けて朝寝坊なプログラマがいる
現象）プログラマが朝寝坊だ
↓
原因）自己管理ができず、夜遅くまでモンハンに興じているらしい
現象）モンハンにハマってしまう
↓
原因）モンハンはとても面白い
現象）モンハンは面白い
↓
原因）パーティーで狩りができる
おっと、どうやら原因分析の方向を間違えたようです。
パーティーで狩りできる機能を削除することが
プロジェクトの進捗を回復するための手段ではないでしょう。
現象）プログラマが朝寝坊だ
↓
原因）自己管理ができず、夜遅くまでモンハンに興じているらしい
現象）自己管理ができない
↓
原因）フルフレックスが甘えを生んでいるらしい
フルフレックス制度を撤廃すれば、
進捗が回復する見込みはあるでしょう。
（一方で、失うものもあるかも知れませんが）
このように、問題には「現象」と、それを構成するいくつかの「原因」があり、
それを適切にドリルダウンしていくためには、スキルが求められます。
さて、話をJavaに戻しましょう。
いわゆるトラシューツールができるのは、
いわゆる「現象」の確認であり、最終的な「原因」を教えてくれません。
だからこそ、トラシューツールを使うのは難しいのです。
具体例を挙げてみましょう。
まずは成功例から。
なんか遅い
↓（CPUモニタ）
CPU使用率が高い
↓（プロファイラ）
○○メソッドのCPU使用率が高い
↓（ソースコードを見る）
異常なループを発見！
↓（ソースコードを直した）
遅くなくなった！
一方で、スキルが足りなければ失敗することもあります。
なんか遅い
↓（CPUモニタ）
CPU使用率は低い
↓（プロファイラ）
○○メソッドに時間が掛かっているらしい
↓（ソースコードを見る）
怪しい所は見つけられない・・・
↓（ソースコードを直せない）
遅いまま・・・
実は、○○メソッドには過剰なsleepがあったのですが
解析者のスキルが足りないがために、ソースを見ても問題は見つかりませんでした。
また、解析ツールも、sleepの長さまでは教えてくれませんでした。
改めて言いますが、問題には「現象」と「原因」があり、
本当の「解決策」に至るには「原因のドリルダウン」が必要です。
この「原因のドリルダウン」には、スキルが求められるのです。
