UTIの関係者であるAさんと先日会話していたときに、最近の少子化と大学の生き残りが話題になり、同じく関係者である某大学のB教授を交え話が盛り上がりました。
最近の大学は、少子化の問題に加え、学生の指向が昔と変わり、国内の大学だけではなく海外の大学も視野に入れて志望校を選択するようになり、単に国内だけの競争ではなく、海外との競争にも曝されるようになってきたそうです。
Aさんの親戚の息子さんは、難関のハーバード大学とMITの両方に合格し、どちらに行くか迷った結果、奨学金の多いハーバードを選んだそうです。（授業は、単位交換制度があるので、どちらも受ける事が可能です。）
また、筆者の高校時代の友人の娘さんが今年の四月に大学に入学したのですが、彼女の選んだコースは、在学中に海外の大学に留学し、そこでの単位取得が必須となっているそうです。
ちなみに、彼女が入学した大学は、筆者の自宅の近所にあり、時々、書店に行った際に前を通ったりするのですが、この大学は、筆者が学生の頃は、殆どスラム街のような汚さでしたが、今では見違えるほど奇麗になり、外国人の学生も結構見かけます。学生のニーズに合わせて、大学も変身して来ているようです。
さて、海外留学でいつも話題になるのが授業料の高さですが、特にハーバード大学等の有名私立大学の授業料はベラボーなものがあり、年間４００万円に加えて寮費（全寮制です）が１００万円ほどかかり、普通のサラリーマンの家庭に取っては大きな負担となります。（知人に、ハーバード出身で、今は企業内弁護士をしているアメリカ人がいますが、彼にとっても、子弟に自分が受けたのと同じレベルの教育を施す事は、大変だと言っています。）
日米のサラリーマンの給与の比較ですが、為替相場にもよりますが、金額的にそんなに大きな差があるとは思えません。（もちろん、超高級取りは青天井ですので、比較対象から省きます。）
ただ、アメリカの方が、生活費一般、特に食材費が安いので、単純な比較は難しいのですが、感覚的に日米の家計の内訳で見ると、日本では住宅費が非常に高い分だけ、アメリカでは子弟の大学授業料が非常に高いという風な印象を受けます。
さて、アメリカでは、大学教授だけでなく、いわゆる専門家のサービス全般（プロフェッショナル・サービス）が、日本の感覚では高く感じます。（逆に言うと、日本では、プロフェッショルサービスと普通のサービスとの金額差が小さいとも言えます。）
アメリカの会社の中では、職種によってプロフェッショナル職位とノン・プロフェッショナル職位が明確に分かれている事が多く、両者の処遇はかなり異なります。
何を持ってプロフェッショナル職位とするかは、会社によってかなり異なりますが、大学(院）を出たからといって自動的にプロフェッショナルとして扱われない事は確かです。
そして、ソフトウェア技術者、特にプログラマは、歴史的に言って微妙な位置にあり、かつてはハードに近いオペレーティング・システムを書くプログラマはプロフェッショナルとして扱い、アプリケーション・プログラマはノン・プロフェッショナル扱いでした。ちなみに、上流行程を扱うSEはプロフェッショナルでした。
そして、アプリケーション・プログラマがプロフェッショナルとして扱われ始めたのは、奇しくもUML等が出て来てオブジェクト指向開発が登場して来たあたり、具体的には９０年代中盤あたりからです。（ご存知の通り、オブジェクト指向開発では、上流行程と下流行程という概念が希薄になり、両者を明確に区分するのが困難なうえ、往々にして同じ人間が両方に関わっています。）
プロフェッショナル職位の人間は、多くの場合個室が与えられ、あまり雑用に煩わされる事なく（本人でないとできない事を除き、マネージャや事務係（Admin)の人がやってくれます）、専門分野に集中できますし、会社もそれを望んでいます。
また、専門家として処遇されるので、必要なトレーニングや外部セミナー等も受講できます。（反対にノン・プロフェッショナルは、本人の希望に関係なく会社が指定したトレーニングのみを受けるだけです。）
また、昔はアメリカでも給与を上げるためにはライン・マネージャになるしかなかったのですが（筆者が若い頃勤めていたIT大手もそうでした）、最近では、人事施策として、専門家として偉くなる道を選ぶ事ができるようにした会社が増えてきました（ハイテク企業ほどその傾向が高い。）
昨今の日本の技術者の状況を見ると、このような比較も、脳裏に浮かんだりします。
ソフトウェア工学 傾向と対策 その３
下の図は、「組込みシステムのためのソフトウェアエンジニアリング 上級編」（現時点では未刊）の目次を示しています。
図中の青色部分は、OCRES上級で出題範囲として指定されているところで、黄色の枠内は、OCRES上級試験で直接的な前提知識が記述されている場所を示しています。
第１１章のソースコードの分析とテストは、内容としては非常に面白い分野ですが、OCRESは、基本的に分析と設計に重心を置いた試験ですので、設問の対象外となっています。
なお余談ですが、この分野で今流行りのモデル・ドリブン・テスト（モデル駆動型テスト）を中心対象にした試験プログラムを作ったらどうかという提案が、かなり以前から出ていますが、現在のところまだ具体化していません。
管見では、モデル駆動型テストは、まだ市場に完全に定着したアプローチとは言えず、何をもってモデル駆動型テストのエキスパートとして認証されるべきかについても百家争鳴であり、時期尚早な観があると思います。
（一言で言うと、まだリサーチの段階）
ただ注意すべき点は、モデル駆動型テストを行うにあたって、第11章の知識が無駄になるわけではなく、基本的な前提知識となりますので、学習しておく必要があります。
第12章の開発ツールの分野も、第11章と同じ理由で設問の対象になっていません。
ただ内容的には、極めて組込みシステムらしい分野であり、一例を挙げると、IT系ではオシロスコープを持ち込んでデバッッグするような事は普通考えられませんが、組込み系リアルタイム系では極めて日常的な光景です。
第13章が上図中で黄色に囲っているわけは、この章の内容が、OCRES試験分野であるUMLプロファイルを理解する前提条件となっているからです。
特に、OCRES上級の試験対象である「リスク・メタモデル」や「フォールトトレランス・メタモデル」とは、直接的な関係があり、理解しておく必要があります。
第14章は、OCRES上級試験の直接の試験対象になります。
またさらに、UMLプロファイルの「性能メタモデル」を理解する上での前提知識分野となります。
最終章のドキュメンテーションは試験対象とはなっていませんが、その一つの理由は、分析設計と同じくこの分野が、知識分野ではなくプラクティスの問題であるからです。
文書化の本質的な理屈は極めて簡単であり、問題は、その理屈に従って実際上の処理をするかどうかの問題です。
なお昨今では、この文書化も、モデル中心、つまり設計図中心である事を最後に申し添えておきます。
昨日はバブルの頃の話を書きましたが、それで思い出した事があります。
知人のF氏から聞いた話ですが、F氏の親戚で、東京都港区に住んでいた一家のおとぎ話の物語です。
その家族の家は、住所だけ聞くと全国的に超有名な高級住宅地にありましたが、実態は、表通りから一歩入った崖下の日の当らない場所であり、湧き水のせいで真夏の日照りが続く日でも地面が濡れているような状態だったそうです。
土地の形も変則的で、細長く曲がった狭い家しか建てられず（１階部分が変形6畳、２階が3畳半程度）、また湿気のせいで家の柱の下の部分が腐りかけ、F氏曰く「親戚でさえ近寄りたくない家」だったそうです。
また、どうもその辺りは昔は墓地かなんかだったらしく、近所の道普請の際に人骨がたくさん出てきた、という話も伝わり、家の住人も何となく陰気な雰囲気があったそうです。
というわけで、その当時、日本中を闊歩していた地上げ屋も、さすがに、ここだけは近寄らない、というような場所でしたが、バブルも末期のある日、２人の紳士が、土地を売って欲しいと、この一家を訪ねて来ました。
何でも、崖上の表通りに面した酒屋が土地を売る事に決めたらしく、その裏手にあった土地も、表通りと同じ相場でまとめて買い上げてマンションを建てたいという話でした。
一家は、もともと気に入って住んでいた訳ではないので、すぐに売る事に決めたそうです。（当時売り渋っている間に、バブルが弾けてしまったという話が山ほどありましたので、極めて幸運で賢明な決定でした。）
結果的に言うとベストのタイミングで売り抜けたことになり、間もなく、バブルが弾け、それまでは、どんな土地でも高値がついていたのに、条件が悪い土地から順に大暴落が始まっていったそうです。
この一家は、その後、堅実に商売を続け、今では豪邸に住んでいて、F氏曰く、「親戚中で一番貧乏だった家が、まるで憑き物が落ちたように明るくなり、一番の金持ちになった、」のだそうです。
My Fair Lady．．．
ソフトウェア工学 傾向と対策 その２
前回に引き続き、「組込みシステムのためのソフトウェアエンジニアリング 中級編」（現在はまだ未刊）の内容に従って解説して行きます。
まず、第６章のリアルタイムOSの実際的側面ですが、上の図中の赤インクで示されているようにOCRES中級の出題範囲とされていますが、現実には出題傾向が、第５章とかぶり、OCRES中級だけであれば、【基礎編」の内容の理解で十分でしょう。（ページ数で見ても、第５章の方が６章の３倍近くあり、内容的に５章の方が本質的な問題を議論しており、問題が作り易い。）
第７章、第８章、第１０章は、分析や設計の方法論の分野ですので、OCRESは試験対象としていません。
方法論に関しては、座学ではなく、事例研究や演習で、実際に手を動かして学習すべきである、というのがOCRESのスタンスです。
この分野は、知っているという事だけでは全く意味をなさず、実際に手が動く事が重要です。
「傾向と対策シリーズ」の最後に、本書で紹介されている方法論に則った演習コースの例を提示して、勉強法を解説したいと思います。
第９章はコーディングにまつわる問題を議論していますが、これはOCRES上級編の試験対象に指定されています。
9.2 のコーディングやパッケージングの問題は、実装上、分析や設計と同等以上に重要な問題です。
また、9.3-9.4で議論されるコンピュータ言語は、設計者やアーキテクトが必ず身に付けておかねばならない知識分野です。
筆者は、団塊の世代と団塊ジュニアの世代のちょうど中間点、人口分布で言うと、２つの人口のピークの谷間で、最も出生数が少なかった世代に位置します。そして、社会人に成って以降は、同年輩の人間と話をするよりも、この２つのピークの世代との接触の方が、会社の内外を問わず、圧倒的に頻度が高くなってしまうのは一種の宿命のようなものなのでしょう。
まず新入社員の時の初めての上司が、大体、この「課長 島耕作」を代表とする熱血的な団塊の世代でしたし、管理職になって初めて迎えた新入社員が、どことなく愁いを帯びた団塊ジュニアの世代でした。
そして、この団塊ジュニアの世代が新入社員だった頃は、暗い瞳で、よくバブルの頃の事を訊かれました。
その当時の彼らにとっては、就職する前に蜃気楼のように消えてしまった幻の桃源郷のように感じていたのかもしれません。
しかし、筆者の場合、バブル時代を思い返しても、あまり好い思いをした記憶がありません。
確かに、当時、筆者の勤めていた企業でも、タクシーチケットがバンバン使えましたが（国土交通省ほどではないですが）、残念ながら肝心のタクシーが繁華街から払底していて全く捕まらず、仕方がないので、六本木や赤坂から、自宅のあった世田谷まで何回も歩いて帰った事があります。
また、その当時の取引先の会社の重役さんで、有名な千葉リーヒルズに豪邸を建てた方がおられましたが、バブルが終わるとあっと言う間に彼の会社もなくなり、当人の消息も分からなくなってしまいました。
ごく一部の幸運な例外を除き、バブルの時代に羽振りが良かった人ほど、バブル崩壊後の揺り戻しがきつかったようで、バブル時代たいした事がなかった人（筆者を含む）は、崩壊の影響もたいした事がなく、その後も生き延びています。
ソフトウェア工学 傾向と対策 その１
次の表は、先日発行の「組込みシステムのためのソフトウェアエンジニアリング（基礎編）」の目次を抜粋したもので、OCRESの試験範囲を色で示しています。（OCRES中級は赤、上級は青色）
なお、OCRESの試験範囲をこの書籍で示しているのは、本書をあくまで指標として使っているだけなので、ほかの書籍や授業、トレーニング・コースで勉強しても全く問題ありません。
ただ、学習範囲の過不足を確認する上で、一度目を通しておいた方が安全である事は確かです。
さて、第１章と第２章は概論にあたる部分ですので、既に組込み系の経験がある人は、読み飛ばしても問題はありません。しかし、他の分野から参入される方は、一通り読んでおいた方が良いでしょう。
第３章は要件分析、第４章はソフトウェア設計に当てられていますが、ここにOCRESの試験の性格が如実に現れており、ビューポイント法やユースケース法、あるいはオブジェクト指向設計等の方法論の部分が完全に試験範囲から外れています。
実は、OCRESでは、このような方法論に属する分野はペーパー試験に向かないエリア、あるいは、設問を作る事が無意味なエリアと考えられております。
実際、学校や企業では、方法論に属する分野は、事例研究や演習等、実際に手を動かして学習する分野であり、方法論の知識をがどの程度持っているかを聞くこと事態に意味がなく、実際のアウトプットそのものを評価すべきである、という考え方が圧倒的です。
また、事例研究や演習の場でも、こじんまりまとまった解答よりも、ユニークなアプローチや面白い考え方を提示した方が高得点が得られる傾向があります。
従って、OCRES試験の特長は、方法論は無用と考えているのではなく、ペーパー試験には向かない分野と考えている、という点にご注意ください。
また、方法論で、もう一点注意しておかなければならない点があります。
現在、組込み系IT系を問わず、オブジェクト指向分析設計は、ソフトウェア開発の中心的な役割を演じていますが、これは決して他の方法論、例えばデーターフローや機能設計等、のアプローチを完全に駆逐した事を意味している訳ではありません。
方法論というのは、一般的に言って、常に一長一短があり、設計者、アーキテクトは、それぞれの特徴を知りながら、使い分けや、時には併用が必要になって来ます。
OCRES試験の上級編で、「4.4 ソフトウェア設計の機能的構造化」の節を試験範囲として指定していますが、これはヨードン法の系列に属する機能構造設計法につながる前提知識の分野です。
これは、OCRESが、いわゆるオブジェクト指向型開発だけで十分とは考えていない事を表しています。
演習や事例研究に関しては、この「傾向と対策シリーズ」の最後で、具体的なコース体系を提示しながら解説したいと思います。
さて、最後の第５章は、リアルタイムOSに関する知識から出題されます。
歴史的に言って、リアルタイム系組込み系システムは、単なるアプリケーション開発ではなく、アプリケーション付きOSの開発と言った方が適切なほどOSと密接な関係があります。
使用するOSもIT系と比べると決してファンシーな機能がついている訳ではなく、スケジューラがOSについてなかったり、あるいは、機能が不十分であったりして、スケジューラそのものを自分で書かなければならなかったり、また、排他制御を（OS任せにすると遅いので）アプリケーションで解決しなければならなかったりします。
第５章の出題は、こういったリアルタイムOSの基礎的な分野から出題されます。
上級編では、さらに分散システムや、スケジューリング・ポリシーの問題も出題されます。
