最近の大学は、少子化の問題に加え、学生の指向が昔と変わり、国内の大学だけではなく海外の大学も視野に入れて志望校を選択するようになり、単に国内だけの競争ではなく、海外との競争にも曝されるようになってきたそうです。
Aさんの親戚の息子さんは、難関のハーバード大学とMITの両方に合格し、どちらに行くか迷った結果、奨学金の多いハーバードを選んだそうです。（授業は、単位交換制度があるので、どちらも受ける事が可能です。）
また、筆者の高校時代の友人の娘さんが今年の四月に大学に入学したのですが、彼女の選んだコースは、在学中に海外の大学に留学し、そこでの単位取得が必須となっているそうです。
ちなみに、彼女が入学した大学は、筆者の自宅の近所にあり、時々、書店に行った際に前を通ったりするのですが、この大学は、筆者が学生の頃は、殆どスラム街のような汚さでしたが、今では見違えるほど奇麗になり、外国人の学生も結構見かけます。学生のニーズに合わせて、大学も変身して来ているようです。
さて、海外留学でいつも話題になるのが授業料の高さですが、特にハーバード大学等の有名私立大学の授業料はベラボーなものがあり、年間４００万円に加えて寮費（全寮制です）が１００万円ほどかかり、普通のサラリーマンの家庭に取っては大きな負担となります。（知人に、ハーバード出身で、今は企業内弁護士をしているアメリカ人がいますが、彼にとっても、子弟に自分が受けたのと同じレベルの教育を施す事は、大変だと言っています。）
日米のサラリーマンの給与の比較ですが、為替相場にもよりますが、金額的にそんなに大きな差があるとは思えません。（もちろん、超高級取りは青天井ですので、比較対象から省きます。）
ただ、アメリカの方が、生活費一般、特に食材費が安いので、単純な比較は難しいのですが、感覚的に日米の家計の内訳で見ると、日本では住宅費が非常に高い分だけ、アメリカでは子弟の大学授業料が非常に高いという風な印象を受けます。
さて、アメリカでは、大学教授だけでなく、いわゆる専門家のサービス全般（プロフェッショナル・サービス）が、日本の感覚では高く感じます。（逆に言うと、日本では、プロフェッショルサービスと普通のサービスとの金額差が小さいとも言えます。）
アメリカの会社の中では、職種によってプロフェッショナル職位とノン・プロフェッショナル職位が明確に分かれている事が多く、両者の処遇はかなり異なります。
何を持ってプロフェッショナル職位とするかは、会社によってかなり異なりますが、大学(院）を出たからといって自動的にプロフェッショナルとして扱われない事は確かです。
そして、ソフトウェア技術者、特にプログラマは、歴史的に言って微妙な位置にあり、かつてはハードに近いオペレーティング・システムを書くプログラマはプロフェッショナルとして扱い、アプリケーション・プログラマはノン・プロフェッショナル扱いでした。ちなみに、上流行程を扱うSEはプロフェッショナルでした。
そして、アプリケーション・プログラマがプロフェッショナルとして扱われ始めたのは、奇しくもUML等が出て来てオブジェクト指向開発が登場して来たあたり、具体的には９０年代中盤あたりからです。（ご存知の通り、オブジェクト指向開発では、上流行程と下流行程という概念が希薄になり、両者を明確に区分するのが困難なうえ、往々にして同じ人間が両方に関わっています。）
プロフェッショナル職位の人間は、多くの場合個室が与えられ、あまり雑用に煩わされる事なく（本人でないとできない事を除き、マネージャや事務係（Admin)の人がやってくれます）、専門分野に集中できますし、会社もそれを望んでいます。
また、専門家として処遇されるので、必要なトレーニングや外部セミナー等も受講できます。（反対にノン・プロフェッショナルは、本人の希望に関係なく会社が指定したトレーニングのみを受けるだけです。）
また、昔はアメリカでも給与を上げるためにはライン・マネージャになるしかなかったのですが（筆者が若い頃勤めていたIT大手もそうでした）、最近では、人事施策として、専門家として偉くなる道を選ぶ事ができるようにした会社が増えてきました（ハイテク企業ほどその傾向が高い。）
昨今の日本の技術者の状況を見ると、このような比較も、脳裏に浮かんだりします。
ソフトウェア工学 傾向と対策 その３
下の図は、「組込みシステムのためのソフトウェアエンジニアリング 上級編」（現時点では未刊）の目次を示しています。
図中の青色部分は、OCRES上級で出題範囲として指定されているところで、黄色の枠内は、OCRES上級試験で直接的な前提知識が記述されている場所を示しています。
第１１章のソースコードの分析とテストは、内容としては非常に面白い分野ですが、OCRESは、基本的に分析と設計に重心を置いた試験ですので、設問の対象外となっています。
なお余談ですが、この分野で今流行りのモデル・ドリブン・テスト（モデル駆動型テスト）を中心対象にした試験プログラムを作ったらどうかという提案が、かなり以前から出ていますが、現在のところまだ具体化していません。
管見では、モデル駆動型テストは、まだ市場に完全に定着したアプローチとは言えず、何をもってモデル駆動型テストのエキスパートとして認証されるべきかについても百家争鳴であり、時期尚早な観があると思います。
（一言で言うと、まだリサーチの段階）
ただ注意すべき点は、モデル駆動型テストを行うにあたって、第11章の知識が無駄になるわけではなく、基本的な前提知識となりますので、学習しておく必要があります。
第12章の開発ツールの分野も、第11章と同じ理由で設問の対象になっていません。
ただ内容的には、極めて組込みシステムらしい分野であり、一例を挙げると、IT系ではオシロスコープを持ち込んでデバッッグするような事は普通考えられませんが、組込み系リアルタイム系では極めて日常的な光景です。
第13章が上図中で黄色に囲っているわけは、この章の内容が、OCRES試験分野であるUMLプロファイルを理解する前提条件となっているからです。
特に、OCRES上級の試験対象である「リスク・メタモデル」や「フォールトトレランス・メタモデル」とは、直接的な関係があり、理解しておく必要があります。
第14章は、OCRES上級試験の直接の試験対象になります。
またさらに、UMLプロファイルの「性能メタモデル」を理解する上での前提知識分野となります。
最終章のドキュメンテーションは試験対象とはなっていませんが、その一つの理由は、分析設計と同じくこの分野が、知識分野ではなくプラクティスの問題であるからです。
文書化の本質的な理屈は極めて簡単であり、問題は、その理屈に従って実際上の処理をするかどうかの問題です。
なお昨今では、この文書化も、モデル中心、つまり設計図中心である事を最後に申し添えておきます。
