実務ではよく PDCA (Plan-Do-Check-Action) のようなサイクルでソフトウェア開発を改善していきますね．しかし，たとえば P 一つとっても，その計画を採用するときに，ただのKKD(勘，経験，度胸)だけを根拠にしていませんか？ その計画に客観的な裏付けはありますか？
たとえば，あるソフトウェアを開発するのに用いる技法を選ぶときのことを考えてみましょう．できるだけ最善に近づけるためにはどうしますか？ たとえば世の中にどのような技法があるのか，今までに技法を実践した前例がないかを網羅的に調べますよね？ 大々的に採用する前に，試験的なプロジェクトで効果を実証してみたりしませんか？ そもそも自分たちがどんな課題に直面しているのか，今までのソフトウェア開発活動をふりかえることもするでしょう．
ソフトウェア工学の実践研究では，実はこのような活動を次のように科学的・工学的に行っています．
- 問題定義: 今までのソフトウェア開発をふりかえって，何が課題かを定義する
- サーベイ: 課題に関連する研究や事例，技法などを網羅的に調査する
- 解決アプローチの検討: 既にある解決法を再利用しながら必要に応じて新たな解決法を追加提案する
- 検証: 実際のソフトウェア開発に解決アプローチを適用してみて効果を実測する
このやり方をきちんと身に付けると，実務でも大いに役に立つはずです．博士論文を書くことは，このやり方を身につけるトレーニングになります．
