「しなの」の語源 ２
以前、「信濃（しなの）」の語源の話をしていて、途中で終わってしまった回がありましたが、本日はその続きを書きます。
前回、「しな」と言う語が付く地名は全国的に散在し、その多くは河岸段丘の地形が見られると言う話をしました。
（このブログを書いた後にもまた、友人のS君から、「東京の品川の語源も河岸段丘じゃないか？」と言う指摘を受けました。品川は目黒川の下流域の名称ですが、周囲の開発の関係で、元の地形が確認しづらくなっておりますが、その可能性は非常に高いと思います。）
ところが、不思議なことに、「しな」地名が集中する信濃では、河岸段丘と「しな」地名はほとんど一致しません。
ここで注意しなければならないのは、その地名がいつ命名されたか、という点で、例えば、「望月の駒」で有名な望月町のそばに、かつて浅科村と言う村がありましたが、この村の周囲に河岸段丘が見られないと言っても、語源的な議論には役立ちません。
というのも、浅科村は、浅間山と蓼科山の中間にあることから昭和３０年代に命名された新地名であって、少なくとも千年以上前から存在する他の「しな」地名とは、区別する必要があります。
そこで、文献などで可能な限り古くから存在する事が確実な、「しな」地名を洗い出しましょう。
次をクリックすると、長野県内で、少なくとも平安時代から存在が明らかな「しな」地名を示した地図がポップアップします。（延喜式や三代実録などからピックアップ）
「しな」地名地図
図中で青色で示した地名が、古代から存在する事が確実な「しな｣地名で、長野県内でも特定の東西に広がる帯状の地域に集中している事が分かります。
実は、この帯状の地域には、この図で示した「しな｣地名以外にもたくさん「しな｣が付く地名や神社が集中して存在するのですが、現存の文献では時代が確認できないため割愛しています。
さて、これらの地域に共通するものは何でしょうか？
好奇心に駆られて、今から十年ほど前に、この辺りを旅行がてら調べた事があります。
（次回に、続く・・・）
リアルタイムUMLの応用講座
このコースは、前回紹介した「UML2を使用したリアルタイム・ソフトウェア設計講座の後続篇、上級版になります。
応用編のため、オブジェクト指向やUMLの基本的な使い方が前提知識として要求されます。
既に、UML設計の経験はあるが、UMLの使用法をより向上させたい設計者や、UML使用上の実践的な技法を学びたい人が対象になります。
リアルタイムUMLの応用講座 アジェンダ
システム要件の分析と定式化
ー シナリオとユースケース
ー システムスコープと、直接的・間接的アクター
ー アクター・システム間の相互作用を図的にモデリング
システムとソフトウェアの要件を定義
ー システム・ユースケース・モデル
ー システム相互作用モデル
ー システム・スコープ・モデル
ー システム動的モデル
ー ソフトウェア・ユースケース・モデル
巨大システムの設計
ー サブシステム・モデルの開発
ー パッケージとコンポーネント
ー 現実世界とのインタフェース； デバイスとソフトウェア間の相互作用
理念的なオブジェクト・モデルの開発
ー 理念的な環境下でのオブジェクトの関係、コミュニケーションと制御
仕様モデルの開発
ー 理念的モデルと実装モデルのミスマッチ
ー コンポジット構造、ポートと提供／要求インタフェース
並列処理システムとタスク・ベースの設計
ー 抽象的なソフトウェア設計の問題点
ー マルチタスキングの根本
実装モデル ー タスク・ベースの設計
ー 仕様モデルを実装モデルへマッピング
ー タスク間コミュニケーションの課題
実装モデル ー 実践的なシーケンシャル・モデル
ー シーケンシャルなコードで、オブジェクトの振舞の集まりを制御 ー 制御オブジェクト
ー アクティビティ図を用いたアルゴリズム（プロセス）の指定方法
コードの問題
ー 論理的／物理的モデル
ー ソフトウェア ー 構築と成果物
ー ソフトウェアの構造化とパッケージング
ー モデルの実装
分散／多重コンピュータのシステム
ー リアルタイムシステムのための多重コンピュータ・アーキテクチャ
ー ソフトウェアをハードウェアへマッピングする上での基準
ー 実践的な設計技法
事例研究
ー 統合アプリケーションの設計
以前このブログにも登場したことのある友人のS君が、座間から筆者を訪ねてやって来ました。
S君はかなり博識で話題豊富な人ですが、今回は「裁判員制度」で盛り上がりました。
そもそも裁判の判決を下す際に専門の裁判官以外に外部の人間を入れて判断させる制度は、先進国ではかなり幅広く受け入れられている制度で、国によって大きく２つの系統に分けることが可能です。
一つは陪審員制度で、一般人が一個の裁判に関し有罪無罪だけを判断するもので、アメリカやイギリスで取り入れられており（英米法）、もう一つは参審員制度と呼ばれ、一定の任期間に複数の裁判に関し裁判官とともに、有罪無罪だけでなく量刑も判断するもので、こちらは、任期内の複数の裁判を量刑も含めて担当し、いわばセミプロ的な人が、合議制の裁判に参加する形で、フランスやドイツなどで採用されています（大陸法系）。
日本の裁判員制度は、この２つの折衷案的なもので、一般人が参加するという点では陪審員制度と似ており、有罪無罪だけではなく量刑も判断するという点では参審員制に似ています。
従って従来、司法に民主的コントロールを取り入れることに遅れていた日本が、ここでは、一般人に有罪無罪だけでなく量刑も判断させるという極めて先進的な制度を取り入れることになります。
民主主義国家として古代より最も名高いギリシャでは、政治だけでなく、裁判も極めて民主的にやっており、なんと数百人の自由民が多数決で判決を下していたそうです。
そして、その制度の悪例（？）として名高いソクラテスのケースでは、「若者のをそそのかした」と言う罪で訴えられた際、その数百人の裁判官に対して悪態をつき喧嘩を売ってしまって、怒り狂った裁判官たちから死刑の判決を得てしまったそうです。
（その当時の例から見ても、ひたすら恭順の姿勢を見せていたら無罪放免になったかもしれず、とても死刑になるような罪ではありませんでした。）
また、その後も、ソクラテス自身、いくらでも逃げようとしたら簡単に逃げきれるにも関わらず、友人の忠告も聞かず、毒杯を仰いで死んでしまいます。有名な「悪法もまた法なり」という言葉はこの時のセリフと伝えられています。（ソクラテスはかなり意地っ張りな性格の奴だったと、筆者は睨んでおります。）
このギリシャ時代の制度から比べると、さすがに現代の制度はかなり洗練されてきています。
陪審員制度の根底にはカント流の哲学があると言われ、人間の知性のうち、悟性（物事そのものを把握する能力）は（他の知的能力、理性とか判断力とか言ったものに比べ）どんな人にもかなり平等に割り当てられていると信じられています。
また統計的に見ても、陪審員が裁判官よりも感情的あるいは非論理的判断をするとは証明されておらず、むしろ逆にアメリカなどでは裁判官よりも陪審員制度の方が信頼されています。
（陪審員の方がより慎重な判断をする傾向があり、裁判官の方が、検事や時の権力側に近い判断を下す傾向がある、と言われています。）
さて、日本の裁判員制度ですが、歴史的試行錯誤や哲学的バックグラウンドが全く無い代わりに、運用によっては司法制度に極めて強力な民主的コントロールが提供される可能性を秘めています。
しかしながら、S君も筆者も、その「運用によっては」という部分で、その効果に悲観的です。
現在の検察審査会も「運用によっては」かなり民主的なコントロールが可能な制度でありますが、残念ながらそのように「運用」されていません。
裁判員制度も、単なる形骸的なものにならないよう、制度の改善を模索しながら、前に進んで行くしかないでしょう。
UML2を使用したリアルタイム・ソフトウェア設計講座
ジム・クーリング博士によると、設計講座においていわゆる設計ツールを使用して演習すると、受講者は皆ツールの使い方の方に注意が行ってしまい、肝心の設計の方が疎かになる傾向があるため、彼の開発したトレーニング・コースはすべてツールを使わずに設計図（モデル図）は手で描く事になっています。
注意すべき点として、初学者は往々にして、設計ツールが使えると言うことと、設計が出来ると言うことを混同してしまう傾向があります。
受講者は、様々なソフトウェアの開発ツールの使用経験があると思いますが、ことUMLツールに関して言えば、どのツールも（もちろん機能の過不足はありますが）深いレベルで似通っており、学ぶよりも慣れの方が有効であり、短い演習時間をツールに慣れるために使うのは、時間の無駄と言えます。
さて、このコースの中身の解説は、「組み込みプレス」の次の号に投稿しましたので、そちらを参照頂くとして、ここでは、コースのアジェンダを紹介いたします。
UML2を使用したリアルタイム・ソフトウェア設計講座 アジェンダ
リアルタイム・システム設計入門
ー リアルタイム・システムの概要
ー インクリメンタル設計プロセス
ソフトウェア・マシン ー 基礎
ー モジュラー構造化の基礎と実践
ー プログラム設計における図法のテクニック ー UMLアクティビティ図
オブジェクト指向設計の概念
ー オブジェクトのコラボレーションの集まりとしての設計システム
ー クラス、オブジェクトとそれらの特徴
ー 設計・構築の鍵となる課題： ソフトウェア・テンプレート、カプセル化、インタフェース、情報隠蔽、継承と集約
クラスとオブジェクトのモデリングの基本
ー 設計テンプレート、 カプセル化、インタフェース、情報隠蔽
ー クラス・オブジェクトの汎化特化間系： 継承
動的振る舞いのモデリング
ー システムとオブジェクトの動きを定義するための状態図
ー UMLステート・マシン図の概念、文法、セマンティクス
理念的なオブジェクト・モデルの開発
ー 理想環境下における、オブジェクトの関係、コミュニケーションおよび制御
ー シナリオ、シーケンス図とコミュニケーション図
ー 責務に基づく設計テクニック
ー 実世界とのインタフェース
実践的な逐次（プロシージャ型）オブジェクト・モデル
ー 逐次的コードで、オブジェクト群の振る舞いを制御： コーディネータ・オブジェクト
ー アクティビティ図を用いて、アルゴリズム（もしくはプロセス的な）操作を指定
小型システムのための仕様モデルの開発
ー 仕様モデルの役割
ー 並列処理、非並列処理の構造 ー アクティブ・オブジェクトとパッシブ・オブジェクト
ー オブジェクト構造の仕様化 ー フラットなオブジェクト構造
並列処理システムとタスクに基づく設計
ー 抽象的なソフトウェア設計に伴う問題
ー マルチタスキング設計の基本
小型システムのための実装（タスキング）モデルの開発
ー 仕様モデルからタスキング・モデルへのマッピング
中規模システムの開発
ー コンポジット構造、ポート、インタフェース入門
ー コンポジット構造のための仕様モデルの生成
ー 実装（タスキング）モデルの仕様化
大規模システムの開発
ー 鍵となる構成ブロック ー パッケージとコンポーネント
ー サブシステム構造の設計
ー 実装モデリング
多重コンピュータ・システム
ー リアルタイム・システムのための多重コンピュータ構造
ー ソフトウェアをハードウェアにマッピングするための基準
ー 実践的な設計テクニック
ユースケース分析
ー 用件を構成し表現するためのユースケース
ー シナリオとユースケース
ー システム・スコープと直接的、間接的なアクター
ー アクターとシステム間のインタフェースを図的にモデリング
事例研究
ー コンピュータ制御の測定器の組み込みソフトウェアを題材
先日、久しぶりに一橋の学士会館に行って来ました。
昔、友人の結婚式で何度か足を運んだ事がありましたが、ここしばらくは全く縁がなく、場所をすっかり忘れてしまっており、地図なしにはたどり着けないほどになっていました。
そして、何気なく会館の関係者の方とお話ししている中で、この地が、漱石ゆかりの場所であった事を初めて知りました。
現在、筆者の自宅がある町から、長い坂道を下って行った所に、明治の文豪、夏目漱石の生家跡があります。そして、ここに越して来たばかりの頃は、散歩がてらに、漱石が歩いたであろう道筋をたどったりしていました。（この近辺は、江戸末期の道筋が結構残っています。）
その結果、筆者も、漱石を通して江戸や昔の東京の歴史に興味が涌いてくるようになりました。
漱石は、明治維新の頃、今の早稲田大学のすぐそばで生まれ、当時出来たばかりの東京大学予備門（後の旧制一高）へ入学し、帝大（今の東京大学）へ進んだ事は有名ですが、その当時、予備門や帝大がどこにあったかは、あまり知られていません。
筆者も、漠然と今の本郷にあったのだろうと言う位にしか考えていませんでしたが、実は、漱石が予備門の学生だった頃の東大は、今の学士会館の場所あたりにあったそうです。
この近辺から神保町、駿河台にかけて大学が多く、神田に古本屋が集まり日本一の学生街が形成されたのも、それがきっかけだったそうです。
SysMLを使ったシステム工学 講座
前回に引き続き、ジム・クーリング博士のトレーニングコースを見て行きたいと思います。
本日は、「SysMLを使ったシステム工学 講座」を、ご紹介します。
システム工学／要求工学の重要性
現在のシステム設計において、要件フェーズはますます重要性となって来ており、昨今では要件を分析しまとめるための工学、要求工学と呼ばれる分野が急速に発達してきました。
この要件フェーズは、一つの方法論、一つの視点からだけではなく、複数の方法論、視点を組み合わせて用いる事が重要である事が知られて来ています。
ジム・クーリング博士の本には、要件分析と仕様化の手法として、「ビューポイント法」、「ユースケース法」、「プロトタイピング法】等が取り上げられていますが、これらに加えて、ここ数年の間に急激に普及して来た手法があり、それがSysMLです。
このSysMLの普及速度は、かつてのUMLの普及速度を遥かに凌駕しており、本格的な登場からまだ３〜４年ほどしか経っていないのにも関わらず、システム設計の事実上の主流になっており、急激にデファクト・スタンダード化して来ています。
SysMLとは ?
読者は、UMLが第２版（UML2.0)になって、UMLが単にソフトウェアの表記法ではなく、極めて強力な汎用モデリング言語になった事はご存知だと思います。
実は、SysMLは、UMLの一種であり（サブセット）、特に「システム」を記述するために（プロファイリング機能を用いて）拡張されたものなのです。
システム・エンジニアリングあるいはシステム工学と言う分野は、コンピュータの誕生以前から存在し、飛行機や自動車と言ったシステム製品を、個々の部品や技術要素の観点からではなく、システム全体としての動きや品質にフォーカスを当てています。
勿論、この分野でも従来から様々な表記上の工夫はなされていましたが、不統一で一貫性に問題があり（メタモデル化されていない）、また分野ごとにバラバラでした（標準化されていなかった）。
UML2.0の登場とともに、システム・エンジニアたちは、待ってましたとばかりに、SysMLを標準化し、本格的に使い始めました。（既存のUMLツールが使用できるのも、メリットの一つです。）
ソフトウェア工学とシステム工学
ソフトウェアを設計する上でソフトウェア工学（もしくはソフトウェア・エンジニアリング）の知識が有益である事は論を待ちませんが、システム工学（システム・エンジニアリング）を学ぶ事は、ある意味もっと重要な事なのです。（全体と技術要素の関係）
下に、本コースのアウトラインをまとめました。
コース概要
システム工学入門
ー システム工学とは？
ー システム工学の概念
ー 「揺りかごから墓場まで」のための工学
ー System V-model
UML2.0とSysMLの違い
ー UML2.0のサブセットとしてのSysML
ー UML2.0の拡張
要求分析
ー ”従来の方法” 対 ”ビューポイント法”
ー 要件図
☆ 従来の要件をモデリング
ー ユースケース・モデル
☆ ユースケース・レベル
☆ ゴール指向ユースケース
☆ ユースケース記述
ー システム・コンテキスト・モデル
ー システム・モード・モデル
システム構造の定義
ー パッケージ図
ー ブロック定義図
☆ システムの論理構造の定義
ー 内部ブロック図
☆ 内部アーキテクチャの定義
☆ 構造化クラス（UML2.0)との比較
ー ポートとフロー
☆ 標準ポート
☆ アトミック・フロー・ポートと項目フロー
☆ ノンーアトミック・フロー・ポートとフロー仕様
☆ インタフェース
システム動的モデリング
ー シーケンス図
ー アクティビティ図
ー ステート図
システムのパフォーマンス分析
— 制約のモデリング
☆ パラメトリック・モデル
☆ システム要素に数学モデルを割り当てる
標準
ー IEEE-1471-2000
— ARP-4754
システム工学のためのPragma+プロセス
ー すべてを統合する
旅の途中に訪れた土地の名前の謂われについて関心を持った経験は、どなたにもあると思います。
筆者自身も、地名の語源にはかなり惹き込まれるものを感じます。
「信濃（しなの）」というのもそんな地名の一つで、かつて現地まで行って筆者なりに実地調査をして来たほどです。（わざわざ出かけて行ったのは、世の地名語源辞典の類いを見ても、今ひとつ納得できる見解がなかったせいです。）
「長野県」の地図を広げると、更級（さらしな）とか仁科（にしな）とか言った語尾に「しな」がつく地名が多い事に気づきます。
そして、もう少し見て行くと、その語尾に「しな」が付く地名の分布は、決して長野県中に散在しているわけではなく、特定のエリアに集中している事が分かります。
西は、安曇野北部の仁科から始まり、更級郡、埴科郡を通り佐久へ抜ける東西にのびる帯状の地域に集中しており、長野県北部や、諏訪より南側には殆ど存在しません。
中でも集中しているのが、太古の信濃国造の本拠と思われる現在の千曲市近辺で、「しな」地名に加えて、佐良志奈（さらしな）神社や波閇科（はべしな）神社と言った延喜式にも登場する古社も存在し、「しなの」の謎を解く鍵もこの辺にありそうです。
さて、この東西に延びた帯状地帯ですが、実は長野県内にとどまらず、さらに東側の群馬県へも延びており、多古碑で有名な群馬県吉井町には辛科（からしな）神社という古社があり、さらには、尾瀬の玄関口である沼田市には、片品川という川が流れています。
そして、古代この帯状に延びた地域に暮らしていた人たちは、何らかの共通の事象現象を見て「しな」と呼ぶ言語感覚を共有していたのではないかという仮説が思い浮かびます。
さて、この語尾が「しな」で終わる地名は、全国的にポツポツと、先に述べた帯状地帯ほど集中はしてはいませんが、ところどころに存在します。
有名なところでは、京都の山科（やましな）もその一つです。
そもそも、「しな」という言葉の意味の一つは棚とか段状になったものを示すもので、そこから転じて、上品とか下品と言った等級を表す意味になり、漢字で「品」、「級」、「階」、「科」という字が当てられて行くようになりました。
そして、京都の山科の語源ですが、これはこの地を流れる川の両岸に発達した階段状の地形、河岸段丘だと言われています。（山科は、昔は、「山階」とも書かれていました。）
そこで今度は、先ほど挙げた群馬県の片品川と辛科神社付近の地形を見てみましょう。（次のリストをクリックすると、グーグルマップへ飛びます。）
片品川付近の航空写真：
辛科神社付近の航空写真：
どうでしょうか？ 見事なほどの河岸段丘の地形です（分かりづらい場合は、航空写真の尺度を変えてみてください）。
と言うわけで、「しなの」の謎も一件落着したかに思えます。が、しかし、残念ながら、そう簡単には事は終わりませんでした。
実は、長野県内の「しな」で終わる地名の多くには、近辺に河岸段丘がないのです。
（長くなったのでここで中断し、後編はまた）
ソフトウエア設計のトレーニング法 １
前回までのOCRESブログでは、ジム・クーリング博士の書かれた「組込みシステムのためのソフトウエアエンジニアリング」にそって、ソフトウエア工学の学習法を解説してきました。
ソフトウェア工学の最終の目的は、最終的には良質なソフトウェアを作る事にあり、様々な人が、技術者の教育方法を研究しています。
そして、この分野も他の工学分野と同様に、エンジニア教育は、本や座学だけでは不十分で、演習やケーススタディを取り入れなければダメであるというのが、共通の見解です。
そこで、このOCRESブログでは、ジム・クーリング博士が開発されたトレーニング・プログラムを順次、紹介したいと思います。
下の図は、そのトレーニング・プログラムの全体像、コースマップです。
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の基礎的な分野から出題されます。
上級編では、さらに分散システムや、スケジューリング・ポリシーの問題も出題されます。
恐らく多くの人がそうだと思いますが、海外に住んでいる時と、国内に住んでいる時とでは、音楽や読書の趣味が多少変化します。
筆者もそんな一人で、例えば、アメリカに住んでいると，かえって日本的な本が読みたくなります。
筆者は、なぜか昔から太宰治氏の書くものが苦手で殆ど読まなかったのですが、カリフォルニアに住んでいた頃のある日、立ち寄ったヤオハン（日系のスーパーマーケット）の書棚で彼の「津軽」を手に取って以降、彼の小説をむさぼるように読み耽るようになりました（少し大げさです）。
しばらくは、太宰治の本が書店から消えてしまったほどです（これは事実です。海外の書店なので、きっと日本の書籍が補充されるのが遅かったからなのでしょう）。
そんなに熱中した太宰治ですが、不思議な事に、日本に帰って来たら、また全く読まなくなってしまいました。
これと似た様な現象が，音楽にも現れました。元々日本にいる時は、さほど演歌を好んで聴くタイプではなかったのですが、アメリカでは、車には必ず演歌のカセットテープを積んで走るようになりました。
特に気に入っていたのが石川さゆりさんの「津軽海峡冬景色」で、この曲を聴きながら、カリフォルニアの青い海や空の下をドライブしていると、ミスマッチな両者の情景が微妙に絡み合い、心地よい爽やかな風となって、心を通り抜けて行きました。
さて、多くの人がカリフォルニアと聞いて連想する曲の一つとして、イーグルスの「ホテル カリフォルニア」が挙げられると思います。
この歌は、もちろん曲の素晴らしさもありますが、ミステリアスで暗示的な歌詞も、多くの聞き手の心に残る要因となっています。
中でも有名なフレーズは、主人公がホテルのキャプテンにワインを持ってくるように頼んだところ，キャプテンは、「1969年以降、そのような酒はこちらにはご用意しておりません、」と断わった場面で、このフレーズは曲の発表以来，様々な形に解釈されて来ています。
有名な所では、酒を意味する「スピリッツ」と精神を意味する「スピリッツ」を引っ掛けて、「１９６９年以降、そのような精神（スピリッツ）はこちらにはご用意しておりません、」と、ロック業界の頽廃を皮肉っているのだという説がありますが、他にも、１９６９年は人類が初めて月着陸をした年であり、またベトナム戦争の最中であった事から、６０年代のアメリカの繁栄と７０年代の興廃期の境を象徴している、という説もあります。
1969年とは？
さて、このブログの読者層は、上記の様なありふれた説に満足されるレベルでは無いでしょう。
1969年には、きっと、もっとミステリアスで深い意味が込められていると洞察される方々が多いと思います。
実は，1969年は、OCRES的には非常に重要な年、ソフトウェア工学とコンピュータ・サイエンスが分離した年、別の言い方をすると，ソフトウェア作りが工学分野として認知された年なのです（なぜ，イーグルスが，この事を知っていたかはミステリーです）。
分離したと言っても、もちろん関係が無くなった訳ではなく、今でも密接な関係にあり、明確な境界線を引く事は出来ません。また、システム工学とも密接な関係があります。
密接に関わり合っている例として、コンピュータ言語を取り上げてみましょう。
コンピュータ言語
コンピュータ・サイエンス系の学生が、筆者の学生の頃（恐らく今でも）やっていた演習の一つに、言語作りーーコンパイラ製作の演習があります。
オートマトンや言語理論を一通り習った後、学生が自分で言語を好きな様に設計して、自分が作った言語の処理系（コンパイラ等）を製作する訳ですが、筆者も学生時代やらされました。
言語の設計そのものは結構楽しく、自由度も高くて好きなように定義できるのですが、あまり複雑な言語体系を作って仕舞うと、その処理系（コンパイラやインタプリタ等）を作るのが大変になるので、当時の学生の常として極めてシンプルな言語体系を設計して楽をしようとする傾向がありましたが、あまりシンプルにしてしまうと何も出来ない言語系になったり、あるいはFORTRANのような機械語のニーモニックの様な言語になってしまって面白みが無くなって仕舞うので、演習担当の助手たちは最低限必要な条件を、演習の最初の頃に提示していました。
当時コンピュータが大嫌いだった筆者も、仕方なく何か適当に言語を定義して（リカーシブ・コール出来る事が必須だった様な気がしますが、かなり記憶が曖昧）、ハノイの塔かアッカーマン関数か何かを計算させていました。
文脈自由言語であれば、当時既にあったyaccなどのツールを使って構文解析部分などサッサと作れるのですが、それも、使用が禁止されていて様な気がします。
また中には、自分の設計した言語で、自分自身のコンパイラを書く、いわゆるコンパイラーコンパイラに挑戦した偉い人もいたと思いますが、うまく行ったかどうかは、全く憶えていません。
しかし、後から翻って考えてみると、この言語の設計製作の演習は、結構有益でした。
もちろん、実社会に出ると、実際に言語処理系を作る事は、そういう部署にでも行かない限りは、まずやりませんが、言語そのものは、直接的もしくは間接的に，様々な形で常に付合って行く事になります（UMLも言語体系の一つです。）
当時、システム記述言語（OSや組込み系を記述する言語）として最もポピュラーだったのがC言語でしたが、当時の学生としては、不満が多く（それは、今の学生がC言語に対して持つ不満と殆ど同じだと思います）、さっさと進化して、D言語やE言語が出来て、２１世紀当たりだと当然、Z言語か、ひょっとしたら自然言語でシステム記述が出来るのではないかと想像していましたが、残念ながら、２１世紀に入って１０年近くたった今でも、相変わらずC言語が主流であるとは、当時は想像もしていませんでした。
さて、言語設計が有意義だというのは、つまり、それが「設計」だったからです。
設計というのは、トレードオフを決定する場です。例えば、言語を出来るだけ精密にしようとして数学式の様な言語にすると、プログラミングの生産性が落ちたり、習得に時間がかかったりして不人気となり誰も使わない言語になったりします。また、生産性を上げようとして簡略な表現法を取ると、可読性が落ちてプログラミング品質が劣化したりします。あるいは、品質を上げようとして、プログラミングの自由度を減らし可読性の高い表現方法を採用すると、今度は生産性が落ちたりして不人気になったりします。
設計は、通常唯一解が存在せず、設計者の個性と市場の間のバランスの上に成り立っています。
こうして、言語の使用者（プログラマ）の観点だけではなく、言語の設計者の観点から言語を眺めるのは、学生にとって非常に良い機会だと思います。
そして、設計法や開発論などに代表される方法論（Methodology)を考えるという事は、徐々にサイエンスから工学（エンジニアリング）の分野に足を突っ込んでいく事を意味します。
方法論というのは、原理法則とは異なり、絶対的なものではなく、例えばオブジェクト指向設計論に則らなくてもシステムは出来ますし、また大抵の場合、適用分野の向き不向きが存在します。
あくまでも、合目的的な思考です。
ところで、組込み系の１つの主要なシステム記述言語がC言語だとしたら、C++言語はどうでしょうか？
答えは"YES、 but.."と少し口ごもった感じになるでしょう。勿論、主流言語の一つである事は間違いありませんが、実は、評判が手放しで良いという訳ではなく、バグを呼び込みやすい言語、使用する上で、注意を要する言語として知られています。
C++言語でプログラミングしたからと言って、オブジェクト指向分析設計をしたとは言えない事は，皆さんご存知だと思いますが、逆も真であり、オブジェクト分析設計をしたからと言って必ずしもオブジェクト指向言語でコーディングする必要はありません。
実装言語を何にするかは、対象エリアの特徴を考え慎重に決定する必要があります。
C++言語が要注意と言われる理由の一つはメモリーの使い方であり、例えば，メモリーサイズの小さなシステムでは、C++の動的なメモリーのアロケーションが問題となったり、また、リアルタイム系では、イベント発生から、メモリーをアロケーションしてオブジェクト生成が終わるまでに要する時間が嫌われたりします。（このような，現象をさけるために、C++系の組込みシステムでは、シングルトン等を使用し、初期化の際にメモリーを割り振ってしまう事が，よく行われます。）
C++言語のもう一つの問題は、コーディングの自由度の高さです。
先ほど、C++で書かれているからと行って必ずしもオブジェクト指向分析設計をしているとは言えないと言いましたが、中にはそれを遥かに超えて、オブジェクト指向プログラミングでさえない場合もあります。
表現するとすれば、「バレンシア風 スパゲッティ・プログラム オブジェクト指向香味添え」という様な、一見高級そうな複雑な味わいのプログラムが結構存在します。
勿論，こう言った事は経験の浅いプログラマが犯しやすく、経験を積むに従って無くなって行く問題ですが、プログラミングの現場は，多くの場合、多数派の経験の浅いプログラマと少数の熟練者という形で構成されやすく、それだけ熟練者の負担が重くなって，全体の生産性や品質を下げやすくなってしまいます。
というわけで、言語の設計と言うのは、言語を考える上で非常に有意義です。
先ほど上げましたyaccやlexと言った構文解析ツールも使えますので、コンピュータ・サイエンス系以外の方でも、サンデー・プログラミングで挑戦可能な域にあると思います。
ただ、風変わりな言語体系を作り、その誰にも理解不能な言語を使って自分だけの世界（システム）を構築するという事は、一歩間違えると漆黒のオタク空間へ吸い込まれてしまい元に戻れなくなってしまう事を意味しますので、耐性が無い方は控えた方が良いでしょう（冗談です）。
最近は、以前ご紹介したOCRESの試験範囲にも指定されている書籍を発行する事もあり、組込み系・リアルタイム系のソフトウエア工学の話をする事が多くなりました。
そこで、今回のブログでは，それらの対話を通じて非常に良く聞かれる事，２点に付いて書いてみたいと思います。言うなれば、ブログ版FAQ（Frequently Asked Questions)です。
欧米のエンジニアは、ソフトウエア工学をいつどこで、どのように学ぶのか？
最も正確な解答は、「欧米と一言で言っても、国によって様々であり，アメリカと言っても産業や企業ごとに異なる」です・・・と言っても、恐らく大部分の人にとっては、正確過ぎて反って、期待した答になっていないと思いますので、私見も交え、大雑把な図を描いてみたいと思います。
まず第一に、IT系と組込み・リアルタイム系では、様子が少し異なります。
IT系エンジニアは、学校でコンピュータ・サイエンス系のトレーニングを一通り受けてきた人が多いのに対し、組込み・リアルタイム系エンジニアは、むしろ、電子工学や機械工学、化学と言ったコンピュータ・サイエンス以外の分野の専門教育を受けて来た人たちが多数を占めます。
従って、学校でのコンピュータ教育は、言語教育までと言った人が主流となり、ソフトウェア工学のトレーニングは、主に企業内教育の場で行われる事になります。
また、ITと異なり、ハードウェアとソフトウエアの独立性が低く、ハードウェアの設計者であってもソフトウェア側の事情を知らないとシステム設計が出来ない場合が多く(ハードのソフト化）、システム工学と合わせてソフトウェア工学のトレーニングを行います。（現実的には、分野によっては、システム設計の主導権をソフトウェア側が握っており、そういった場合は，ソフトウェア工学を通じてシステム工学を学ぶ事になります。）
そして、企業教育の特徴は、グループによる事例研究や演習を短期間（通例２〜４日間）に集中して行う点であり、学校教育のように、週２時間で半年間という様なパターンは皆無に近いと思います。（ ただし、E-ラーニング等で、知識教育を補助的に組み合わせるケースは非常に多い。）
システム品質について
システム品質の話をする場合、時々、NASAの惑星探査ロケットが、かつて、メートル法とフィート法を間違えて距離を測定し、惑星に接近するつもりが，激突してしまった事例を取り上げる事があるのですが、人によって受け取り方が違い、筆者の意図する向きとは正反対の方向に解釈される場合もあるので（恐らく，筆者の言葉足らずのせいでしょう）、ここで、改めてお断りしておきたいと思います。
この話をする時の反応は大きく２つに分かれ、一つは、「メートルとフィートの換算方法は小学生でも知っており、なんで何人もの博士号を持つ技術者たちがチェックしたと言うのに、事前に分からなかったのか？ 注意不足にもほどがある。」というものです。
この問題は、例えて言うと、ビット列「 0100 」を一方のソフトは4メートルと解釈し、もう一方は４フィートと解釈する様な現象で、解釈が異なる、つまり意味を取り違えてしまうバグで、意味論的エラー（セマンティック・エラー）と呼ばれる問題です。
実は，このようなバグはソースコード・レビューのようなテスト以外の手法で取り去るのは非常に困難である事が知られています。
また、遠い宇宙空間で走る予定のソフトを地上でテストするのも大きな課題です。（たとえ地上でテストしても、宇宙空間で同じように走る保証がない等）
関係者に取っては、「まさか」に属する種類の間違いですが、残念ながら、このような間違いは人間の注意力では解決されず、よりシステマティックなアプローチが必要である事が専門家の間では常識になっています。
システム工学の進歩も，このような品質問題を解決するために進歩してきました。
最近の飛行機は、昔に比べて数段安全になってきましたが、これは決して、昔に比べて、関係者の注意力が増して来たからではなく、墜落する原因のいくつかが解って来て、それに対してシステム的な対処がなされた事に大きく起因します。
従って、こういった問題で重要な事は、エラーを起こした人間の責任を追及する事ではなく、なぜ、エラーが発生するのか，なぜ防げないのかと言った点を調査する事にあり、それに対しシステマティックな解決策を取る事にあります。（当事者は、説明する責任は当然ながらあります。）
昨今のUMLをはじめとするソフトェア設計手法やテスト手法の発達もシステマティックな解決策の一つです。
最近、重篤な状況下の患者に対し非常に難しい処方を施した医師が、結果的に患者が死亡した責任を問われて逮捕されるニュースが流れましたが、システム屋の目には非常に奇異な事件に感じます。
もちろん、刑罰もシステマティックな手法の一つですが、故意の犯罪に対しては、ある程度限定的に有効だと知られている手法ですが、過失に対する抑止効果は極めて疑問です。（そもそも、リスキーな処方をとる事自身が過失だとする意見に対し、疑問がありますが。）
むしろ、システム的、組織的な問題に対し、何らシステム的、組織的解決をはかろうとしない事自身を問題視すべきでしょう。
随分前ですが、本ブログで、組込みのためのソフトウェア工学教科書の翻訳者を募集した事がありました。
その後かなりの紆余曲折がありましたが、いよいよ来月７月に（株）アイ・テックより、「第一巻、基礎編」が出版される事になりました。邦題は、「組込みシステムのためのソフトウェアエンジニアリング（基礎編）」です。
本書は、ジム・クーリング氏の世界的名著「 Software Engineering for Realtime Systems」 のパート１に当たり、非常に基本的な分野がカバーされております。
本書の出版に当たり、２時間ほどの無料セミナーを、（株）日立情報制御ソリューションズ様のご好意により施設をお借りして実施する事になりました。 （ 詳しくは、UTI社のホームページ（ http://www.umlcert.org ）を、ご参照ください。）
また、書店の店頭に並ぶのは、店舗や地域によってかなりばらつくと思われますが（恐らく８月以降？）、上記ホームページでセミナー申し込みと同時に購入予約をし、セミナー会場で受け取る事も可能です。
また、さらに本書をソフトウェア工学のテキストとしてご活用頂く事をご検討頂きたく、本書籍を教科書とした演習中心の標準的な演習セミナーを開催致します。
Aコース： 分析中心 ２日間
Bコース： 設計中心 ２日間
両コースとも、題材を組込み分野から取り、基礎的なオブジェクト指向分析設計をテーマとしますが、オブジェクト指向以外の他の手法も比較検討と補完の為に使用致します。
企業、学校等で、組込み系のソフトウェア工学の適切な教科書を検討されておられる担当者の方がおられましたら、ぜひご参加をご検討ください。（前提資格として、UMLの簡単な読み書きが出来るレベルを想定しております。（OCUPファンダメンタル取得レベル相当））
このセミナーの申し込みも、上記UTIのホームページから行える予定ですので，一度覗いてみてください。
UTIでは、合わせて、
C: OCUPインターミディエート対策講座
D: OCRES インターミディエート対策講座
E: OCRESインターミディエート水準の設計講座
の各コースも予定しております。
先日、H社で社員教育を担当されているW氏とお話をしている際、たまたま話題が、「企業が、大学に対し学生にどう言う教育をして欲しいか」、と言う内容になりました。彼はあまり多くを挙げませんでしたが，筆者の印象に残った点が１つあり、それは学生の作文能力でした。
彼は，毎年今の時期になると、新入社員が送ってくるレポート類に丹念に赤ペンを入れて返しているそうでが、なかなか大変な作業量だそうです。
筆者自身の学生時代や新入社員時代を思い出しても、あまり人の作文能力に関し大きな事は言えませんが、筆者自身の反省も踏まえ、なおかつ、OCRESの勉強にもなるような話題を一つ試みたいと思います。
多くの企業は、ホワイトカラーで入社してくる社員に対し、文章の作成能力を求めますが、これは、決して美文や名文を作成する事を要求しているのではなく、報告書や設計書など、ある程度客観性を持った簡潔で読みやすい文章を要求しています。
ところが、新入社員の方は、往々にして主観と客観がごっちゃになったレポートを作成して来て、読み手を当惑させたりします。これは、語学教育が文学中心な事や、新聞などの影響もあると思いますが、一つ大きな問題として、学生に対し、情報教育がほとんどなされていない事が問題の根底にあると思います。
筆者自身の経験ですが、メタモデリングの話をしていると、往々にして，なぜメタモデルなどを使う必要があるのか？という質問に遭遇します。メタモデルは、基本的に言語の設計図であり、そんなのはモデリングに関係ないじゃないか？という素朴な疑問が生まれるのは当然です。
このモデリング言語とモデルの関係ですが、例えて言うと、数学理論と数学記号の関係に似ています。
ニュートンの公式、F = M Aは、高校時代に習うので多くの方はご存知だと思いますが、このぐらいであれば、数式を使わなくとも自然言語を使ってこの理論を表現する事は可能でしょう。
しかしながら、この公式を使って推論を行ったり、実際の数値計算を行ったりする上で、数式を使わずに自然言語だけで表現するとなると、極めて煩雑になり、間違いの入る余地が大きくなります。また，数学理論が高度になればなるほど、数学の表現法を追加してやる必要が出てきます。さらに、UMLは数式とは異なり、単なる表記法ではなく，モデリング言語であり，言語自身がモデル化されています・・・・。と、ここまでいうと半分くらいの人は分かった気になり、残りの半分は、分かった様な分からない様な気になって，共に沈黙してしまいます。
今回は、いきなりQoSなどという抽象的なメタモデルを持ち出さず、誰もが日々行っているコミュニケーションをメタモデル化して、メタモデルの有用性とコミュニケーション理論の両方を学びましょう。
コミュニケーション理論のメタモデル
下の図は、弊社のPM教育で使っているメッセージの送信者ー受信者モデルを表した図です。
この図は、メッセージの送信者は情報を媒体（音声や文字情報など）に合わせてエンコーディングし、受信者は媒体から情報をデコーディングして情報を取り出す為に、エンコーディング、デコーディングの際に情報の変形が発生し、媒体上にはノイズが入る可能性がと言う事を示していますが、実はこの図そのものがメタモデル的表現なのです。
この図をUMLを使って表現して見ましょう。
下がメタモデル図の一例です。図中は省略してありますが、四角形はすべてメタクラスを表します。
メタクラス図
次が実際のクラス図例です。
と、ここまで書いてスペースが無くなってしまいました。
おおよそ意味は見て取れると思います。
詳しいメタモデルの説明は、次回の「組込みプレス」のOCRES講座に投稿しますので、ご興味のある方はそちらを参照してみてください。
筆者が中学生の頃、父の友人で、地方で温泉旅館を経営する方から招待を受け、家族で温泉旅行に行った事があります。
着いてみると、それは近代風の立派な建物で、ホテルと伝統的な和風旅館の形式を合わせた様なところでした。 その立派な旅館の一番良い部屋に家族で泊めてもらい、翌日は彼自身が運転する車で、周りの観光地へ案内してくれました。
そして、いくつかの名所を回った後、夕方頃になって帰路に着こうとしたとき、彼は、思い出したように、確かこの奥にあったはずだと言いながら、車を脇道へ入れ一本道をしばらく走らせて行きました。
一本道がどのくらいあったかは、全く思い出せませんが、着いた場所は、海の傍の丘の上にある一種の戦争博物館でした。
戦争博物館と言っても、中学生の男の子が喜びそうな戦車や戦闘機が置いてある訳ではなく、穴の空いた錆びた鉄兜や、ぼろぼろになった背嚢やもんぺ等が展示してあるだけでした。
筆者は、内心かなり退屈を感じながらも、一生懸命説明をしてくれる父の友人と一緒に、展示物の間を巡っていました。
筆者は仕方なく聞いているという風で、彼の話の中で憶えている事は、唯一、彼自身、戦争中は予科練に行って飛行機乗りになる訓練を受けていて、その訓練の最中に戦争が終わった、という事ぐらいです。
そして、ガラスケースの中を指差しながら説明する彼の声が、あるときから急に変わってしまった事に気がつきました。
振り返ると、彼は涙をぽろぽろ流しながら、嗚咽を堪えるように説明を続けていました。
筆者は、同情するというよりも、むしろ驚きました。というのも、彼は、中学生にとっては刺激的過ぎる下ねたジョークで、泊まり客たちを笑わせており、筆者は、彼を品のないただの中年オヤジぐらいにしか見ていなかったのです。
ガラスケースの中には、特攻隊員たちが残した手紙やはがきが展示してありました。戦後３０年近くたってもなお涙ぐむほど、彼の心の傷は深かったのかも知れません。
特攻は、今の時代では狂気の沙汰としか思えませんが、彼らは決して狂気に駆られて死地に赴いたのではない事は、残された手紙類が証明しています。
ある少年兵が飛び立つ前に最後に家族に宛てた手紙の末尾が、「母さん、長生きしてください。」とあったのは、その出来事からさらに３０年以上たった今でも憶えています。
一般資源モデリング
OCRESの主要なトピックスとして、各種のUMLプロファイルがあります。これらの目的の話から入って往きましょう。
近年、オブジェクト指向開発がポピュラーになりツールがどんどんと高度化されるに従って、システム開発の時間配分が随分と変わってきました。
かつては、最も長い時間をかけていたコーディングのフェーズが非常に短くなり、場合によっては設計フェーズに付随する付属的な活動と見なせるほど、コーディング単体にかける時間割合そのものが短くなりました。
逆に割合が増えているのが設計フェーズ、特に分析にかけるワークロードが相対的に重要な位置を占めるようになってきました。
一言で組込み系、リアルタイム系と言っても、様々な分野があり、時計から、航空機、ロケット等、個々の分野に特化した分析方法があります。
ところが逆に、これらの多彩な分析方法に、一貫して共通してみられる分析過程が存在します。
図 GRM1-1は、その活動をユースケース表現したものです。
図中のモデラーは、システムの設計を行う人で、モデルを構築し分析し実装する人です。 そして、分析方法の提供者は、モデラーの分析過程をサポートする人で、分析方法を提供し、分析のために必要な資源モデルを提供しますが、UMLのプロファイルは、スケジューラビリティ分析および性能分析のためのフレームワークを提供し、モデラーをサポートします。
OCRESブログでは、本日から数回にわたり、品質モデルについて議論したいと思います。
品質は、単に組込み系、リアルタイム系だけの問題ではなく、IT系とも共通する問題です。
OCRESで取り上げる品質モデルも、単に組込み系を対象にしたものではなく、IT系とも共通するものです。
QoS サービス品質
品質は、戦後日本のお家芸の分野であり、その製品品質は世界をリードしており、わざわざ改めて学ぶ必要はなさそうです。しかしながら、その日本の世界最高峰の品質に関し一点気がかりな所があり、それがサービス品質（QoS）の概念です。
QoSは、システムが複雑巨大になるに従って重大な問題になって行きます。
一例として、行政サービスを考えてみましょう。日本の個人レベルでのサービス精神は、世界に誇れるものがあります。
ところが、窓口の人はそれなりに一生懸命にやってくれていても、結果的に行政サービス全体としては必ずしも満足いくものではないケースがあります。
また、悪名高い年金サービスですが、国民に対するサービス品質は極めて悪いと言わざるをえず、これは、個々人の担当者の資質の問題を遥かに超えて、明らかにシステムレベル（ITシステムだけではなく、組織機構全体としてのシステム）の問題です。
また、行政サービスだけではなく、民間のマネジメントのサービス品質も重要な問題です。資料によっては、日本のホワイトカラーの生産性は、先進国中で最低の水準にあると報告されています。
システムレベルでのQoS、あるいはシステム工学の面白い点は、例えば、最高の構成要素や部品を使って作られたシステムが最悪のサービスしか提供できなかったり、逆に、構成要素、部品はたいした事がないのに、総合的に最高のパフォーマンスを提供するシステムが出来上がったりする所です。
（ちなみに、システム・エンジニアという言葉は、日本では最近はITエンジニアの一職種を示す言葉として用いられていますが、海外では、本来の広範な意味、すなわち広義のシステム工学に従事する者と言う意味で使われることが多く、ロケット工学等も広義のシステム工学の一つです。）
QoS、サービス品質、という言葉は、世間一般で言われる品質と言う意味よりも、より広範な要素を含み、自然発生的に存在するものではなく、人間が積極的に定義し、評価し管理して行かなければならない概念です。
今月になって、アメリカ次期大統領選がヒートアップして来て、アメリカ人たちはかなり盛り上がっております。
傍目には、非常に楽しそうであり、知り合いのアメリカ人に、ストレートに、「楽しそうだな？」と聞いてみた所、ちょっと渋い表情になり、「楽しいんではなく、これ以外にアメリカの将来に期待できる事がないからだ」と呻いていました。
この発言に、果たして、日本人として同情すべきか、あるいは、羨むべきかは意見の分かれる所でしょうが、１つ言える事は、アメリカの組織は、それが政府や会社であろうと、あるいは、もっと小さなセクションであろうと、トップが変わると、がらりと内容も変わる事ができる点です。
管見では、イギリスの組織もそういう傾向があり、それに対し、日本は言うまでもなく、フランス・ドイツの組織もなかなかトップの言う事を聞きません。
ドイツやフランスでは、意思決定は、ある程度、組織的コンセンサスを経て行われる傾向があるのに対し、歴史的に最も早く議会制民主主義が発達した国、イギリスは、かえって、トップの独断的決断を尊重する傾向があるようです。
従って、英米系の組織では、トップの決断にそった移行が素早く行われる事が特長的で、周りも、しばらくの間は、変化を静観する傾向があります。そして、この特長が、素早い変化が要求される分野やタイミングには、英米型組織の強みとなっているようです。
しかしながら、組織が巨大化してくると、英米型組織でも、変化が素早く行えなくなってきており、俊敏さ（アジリティ）をいかに維持し、高めるかは、大きな課題になってきています。
日本においても、アジリティは重要な課題ですが、英米系で議論される方法論に加え、文化的障壁も考える必要があります。
かつて、第二次大戦後の最初の首相、吉田茂氏は、きわめてワンマンであったという悪評がありますが、その基準でいくと、アメリカの大統領を含め、大部分のアメリカ型の組織のトップは、大ワンマンになります。
また、ワンマンという言葉が、悪い意味になるのも、かなり文化的判断が入っています。果たして、吉田茂氏が、あの当時、ワンマン以外の方法で、難局を乗り切れたかどうかは、かなり疑問です。
現在、日本型組織、特に官僚組織は、かなり時代遅れなものになってきてるのは、誰の目にも明らかになってきていますが（ただし、当事者である役人たちの目は除いた方が良いかもしれませんが）、おそらく、方法論だけの議論では不十分でしょう。文化的側面にメスを入れ、この分野での議論を行う必要がありそうです。
アジリティと組込み系開発
組込み系開発は、要求される品質水準も高い上に、頻繁な更改を必要とする局面が多く、メンテナンスの品質と言う問題は、多くの企業にとり、非常に頭の痛い問題です。
組織によっては、大部分のエンジニアが、メンテナンス作業に張り付き、新しい技術の研究開発が全く行えなくなったり、また、ソースコードを担当別に分けた結果、担当者以外には誰も分からないものになってしまっているといった事態は、けっして珍しいことではありません。
また、変更を直接ソースコードに行う事も、それほど珍しくありません。
設計図を用いたメンテナンス
あえてオブジェクト指向とかUMLとか言う言葉出さなくても、歴史的には、こういった問題は設計図を用いたアプローチ、つまりモデルを用いた方法で、かなり状況が改善される事が知られていました。
オブジェクト指向という言葉がない時代から、ソフトウエア・アーキテクチャという言葉は存在し、その頃から、設計者たちは、図形や表を用いてソフトウエアの構造を設計していました。
そして、メンテナンスの際も、設計図にあたりながら、問題が、設計上のバグなのか、コーディング上のバグなのかを峻別し、前者であれば、設計変更を行う形で問題をフィックスして行きました。一見、回りくどいやり方ですが、最終的には、この方法が品質的にもコスト的にも最前である事が、知られてきています。
そして、フィックスしたコードのテストも、設計図を元に行います。今はやりの、モデル・ドリブン・テストの原型が、オブジェクト指向以前からありました。
設計図を利用しないテストでは、テストそのものがブラックボックス型になりやすく、テスト・カバレッジが悪い傾向があります。
また、リリースアップ等の場合も、直接ソースをいじるのではなく、設計図を書いて行う方が、最終的には、素早く安全に行える事が知られていました。
オブジェクト指向／UML化
オブジェクト指向以前のソフトウエア設計図を用いた方法でも、いきなりソースコードのみをメンテナンスするよりは、一定の効果が得られますが、問題も残っています。
一つは、設計者ごとに書き方がバラバラで、他の人が非常に読みにくい事で、これはメンテナンスをチームで行う上での大きな障害となっていました。また、２つ目は、設計方法にばらつきがあり、ソフトウエアの強度の水準の維持が難しい事です。
また、書き方がバラバラなために、設計ツールがなく、必要なら自分で作らなければなりませんでした。
９０年代以降、欧米の開発現場で、オブジェクト指向が急速に受け入れられてきた背景には、この種の問題に解決策を提供する事が明白になってきた事が、挙げられます。
UMLを使う事により、モデリングおよび表記法が統一され、また、自分で開発ツールを作らなくても、市販のツールを利用する事ができます。
そして、オブジェクト指向設計のアプローチにより、モジュラー構造やコンポーネント構造が半ば自然にとられ、ソフトウエア強度が上がり、品質も格段にあがる事が、明白になってきました。
そして、企業の生命線であるアジリティも、品質を確保した上で、向上する事が、広く認められるようになってきました。
