SIRIUS xWeb solutionパフォーマンスの問題は起こるもので、それを避ける為の王道というものはございませんと言うことです。やはりプロジェクトの初期の段階から開発したアプリケーションに対してそれなりのパフォーマンスの観点をもって問題が無いのかどうかを見極めていかなければいけませんということを口をすっぱくして申し上げているのですが、お客様がプロトタイプを開発してそれを実際に負荷テストなりパフォーマンス分析なりをちゃんとやりましょうと申しあげております。そういった過程で問題がプロジェクトの早期の段階で見つかればアプリケーションの問題であっても対応できます。ただしよくあるのは、サービスインはもうすぐという直前の時期にストレステストやパフォパフォーマンス分析なりをちゃんとやりましょうと申しあげております。そういった過程で問題がプロジェクトの早期の段階で見つかればアプリケーションの問題であっても対応できます。ただしよくあるのは、サービスインはもうすぐという直前の時期にストレステストやパフォーマンス分析をお願いされてよく出かけていくのですが、負荷をかけていくとCPUを80-90%使っているべきところが20-30%くらいしか使われていなくてこれでは当初お客様と合意したパフォーマンス条件に合致しないので問題となると言うようなことがあります。そういわれてもアプリケーションをこの時期に直せません。このケースでは、原因をコードレビューですとかいろいろなツールによってJavaのシンクロナイゼーションのやりすぎだと言うことが結果的にはわかったのですが、アプリケーションに手を入れるのはいやです。インフラで何とかしてくれという話で、クラスタリングなどの手法を使って何とかぎりぎりパフォーマンス条件を合致させてサービスインにこぎつけたのですが、やってはいけないんです。やはり、もっと早いタイミングでパフォーマンス条件を満たしているかのテストをするべきです。先ほどのように直前に言われても条件を満たす効果的なチューニングはできないという事例としての教訓があります。
どこのJavaを使ったプロジェクトも同じようなもんなんだという確信。じゃあ何が悪いのだろうか。
プロジェクトマネジメントの見地から考えると理想的なスケジュール、waterfall型で出戻りが発生しない、要件定義終了後は要件は変更されない（見直されない）のがいいはず。でも実際web系はそんなことなくって臨機応変、たとえそれが上司の気まぐれか、ユーザーの嗜好の変化か、業界のトレンド変化かに対応していかなくてはいけないのです。
そもそも開発に時間がかかることが問題では。ポッと思いついて、それがちゃっちゃと具現化されて、スケーラブルな構造でアクセスが多くなってもインフラだけで対応できるとか。いやアクセスが多くなるなら「満員御礼」でいいのでは？
そんな考えかたじゃダメですか？