祈祷連歌

「結局はヤル気が重要？」（OO百韻）

◇ ◀ ▲ ▶

結局挫折したはてなダイアリに書きかけた結局はヤル気が重要？の続き。 とりあえずはこっちに引越し。

こんなニュースがあった。

日本ＩＢＭは、企業活動全般を業務（プロジェクト）単位で細分化し、
収益性などを厳密に管理するソフトの販売を始めた。（中略）企業活動を
プロジェクトの集合体と見なし、各事業の厳密な収益管理を通じて経営資源の
適切な配分を目指す「エンタープライズ・プロジェクト・マネジメント（ＥＰＭ）」と
呼ぶ経営手法を支援する。 
『日本ＩＢＭ、プロジェクトの収益性などを管理するソフト』

どのように実現しているのか興味があるところだ。恐らく、従業員に細かな「行動記録のデータベースへの入力」を強いるものなのではないだろうかと想像する。この想像があっていると前提しての考えだが、大きな会社でなければ導入するのは難しいのではないかとも思う。ITやその隣接業界ではなにか新しいモノを導入するのにあまり抵抗はない傾向にと思うが、それ以外の業界では下手すると強烈な抵抗をうけてしまうことが少なくない。

会社の経営をしている知人などから、たまに社内システムの導入にからんだ相談を受けることがたまにある。業種としては、出版、教育、映像、小売、税理、といったところで、コンピューターリテラシーのレベルは、言っちゃ悪いけど平均未満の業種ではないかと思う。そういうところには、昔ながらのやりかたでやっている人が多い。すると、別にITに限らず、とにかく「新しいものにはとにかく抵抗する」というスタンスの人が必ずいる。で、そういう人はえてして、その会社での実務面で中心的な役割を果たすような職場の実力者*1であったりするので、たちが悪い。

だから、日常業務で単にＰＣを利用していますというところから更に進んでみたいという話を聞くと「運用が決め手になりますよ。金を投入してハード(＝システム)を導入しても、ソフト(＝人)がうまく働かないとうまくいきません」という感じで答える。システム／人のところをハード／ソフトというのは、相手が都合よく誤解してくれるように、わざとそういういかにもソフト屋な言いまわしで表現をするようにしている。何故かというと、うっかり肯定的なこといって、じゃあやってよ、と言われると、その人的問題を理由にしてかなりたいへんな目にあう可能性が高いからである。かといってまるっきり否定するのもなんだし。触らぬ神にたたりなし。ちょっと違うか。

そういえば、つい最近友人と「行動記録をとるソフトが欲しい」という話があった。PSPなんぞを読んでなんか触発されてしまったりすると、自分の仕事の内容の統計をとる、というのをまずやってみた人は多いと思う。私の場合はあまり続かなかった。だって、めんどうなんだもん。

一応これでもソフト屋のはしくれではあるわけなので、こういう場合はまずはソフトを作ってみたわけだ。「タイムレコーダー」と名付けた。プログラミング覚えたての初心者が習作につくるようなもので、設定ファイルの内容に従ってちっちゃなウィンドウにボタンが並ぶというものだった。ボタンを押すとその時刻が記録されるというきわめて単純な作りだ。それを作るのにおそらく１～２時間もかかっていなかったと思う。

数日後、スクリーンセイバーが動きだすとそれも記録するように改良した。うっかり操作しわすれると「１日に１８時間仕事をしてました」とかなってしまう欠点があったからだ。この改良により仕事から睡眠にシームレスに移行しても、より正確な記録になるはずだ。当時の私は仕事も生活もまったくごっちゃになっていて*2、どこからが仕事でどこからが遊びなのかが非常にあいまいであった*3。食事もキーボードの手前でとっていたし、寝床の横がパソコンの操作環境だったので、いつのまにか無意識のうちちゃんと横になって寝ていて、そして身体を起こしたらすぐパソコンという生活が日常的だった。そんなヒキこもりプログラマーが生産性を計りたいと思ったならば、うってつけのソフトであっただろう。

１週間はもたなかった。

結局のところ何かやるまえに、あるいは、別のことをやりはじめるまえにいちいちその行動記録アプリを操作しなければならないというのが一番のネックだったのだ。私の場合は仕事柄簡単にアプリを作ってつくってしまったわけだが、これは紙などによる記録であっても同じであっただろう。

これはどこに問題があったのだろうか？　とりあえず一番最初にでる答は「私がものぐさだから」である。これは間違いない。でも、はたしてそれだけだろうか。他のことでは、なにか新しいことをやりはじめて、それがちゃんと習慣化したようなことは、数えればいくらでもある。と、思う。

習慣化できた場合とできなかった場合。両者の違いはモチベーションの有無、もしくは、そのモチベーションの程度にあるのではないだろうか。いわゆる、ヤル気の問題だというわけである。だれもが当たりまえに行なうことができる事ならば、自分がその事についてなにか決定的なトラブルを抱えているということでなければ、ヤル気の有無がその成否を左右するといっても過言ではない。「『やればできるがやらない』というのは、できないのと同じ」というのは、本質的にはヤル気の問題なわけだ。まぁ、当たりまえといえば当たりまえの話だが。

それでは、行動記録ソフトを運用しつづけるには、どのようなモチベーション、ヤル気が必要になるのだろうか？　あるいは、発想を変えて、モチベーションを維持できない状況にあっても運用しつづけるようにするには、どういった要素が必要とされるのだろうか？　何かご褒美があれば良かった？

(後日に続く、もしくは途中)

注釈

1. ：私がしばしば言及する「最高実力者と最高責任者をいち早く見分けるのが、新しい現場でうまくやるコツ」のこと
2. ：今は寝るところと仕事するところが別になっているので多少はメリハリがつくようになってはいる
3. ：この部分は未だに同じ

「宴会『日本酒の会』」（OO百韻）

◇ ◀ ▲ ▶

これで２回目(リハーサルを入れると３回目？)のOOEnkai。 今回はちょっと忙しくて行けそうにないとMLで書いたら中止になってしまった。 できれば顔をだそうと思って、ぎりぎりまでスケジュール調整を試みるも、結局ダメ。 参加表明を催促されて、２日前になってやっと返事をしたら、結局人数が集まらないとかで中止もしくは延期。 自分の発言が引金になってしまったので、ちょっと罪悪感がある。 次回は参加すべし。

「MDAとGG」（OO百韻）

◇ ◀ ▲ ▶

MDAそのものはトピックとしてはまだ落とし所が明確になっておらず、セールストークばかりが先行しているように見える。これからどうなっていくのか注目すべき点はいくつかあると思うが、そのひとつに一部の研究者がGraphTransformation(GTx)の利用を積極的に考えているということがある。となれば、この点に関して言えばMDAの主役は当然GraphGrammar(GG)ということになるであろう。

はっきりとした根拠があるわけではないが、過去１０年にわたってGGをもてあそんで(もてあまして？)いた経験から感じるのは、GGをMDAで使うならば、PIM2PSMマッピングより、PIM2PIMやPSM2PSMマッピングで応用したほうが、手っ取り早くGTxっぽい感じがえられるのではないかと思う。おそらくPIM2PSMマッピングではGTｘの利用は多くが期待しているほどうまくいかないのではないだろうか。PIM2PSMマッピングではほとんどの場合マッピング同士の関係が希薄であまり「GGを利用した」という大仰さがないような単純な部分ばかりなのに、一部非常に複雑なGGに基づいたGTxが必要となるのではないかと想像する。そのためMDAにおけるGTxの利用に制限を設ける必要がでてしまい、MDAでしきりに強調する「PIMからPSMが自動的に生成される」という部分を根本から瓦解させ「結局のところ実務で使えねぇ仕組み」と失望する原因になるのではないかと危惧する。

それよりは、PIM2PSMマッピングでは、膨大な変換処理スクリプトのようなものが動き、GGベースのGTｘとはあまり関係しないような形になるのではないだろうか。GGベースのものよりは、そういったものが先に世に出てきてそれで定着するのではないだろうかと予想する。もちろんMDAの本題はGGを利用する事ではないので、それでいっこうに構わないことではある。

一方、PIMやPSMにリファクタリングを施すというような用途ではGGベースのGTｘは比較的うまくいくのではないかと思う。あと、PIMを直接実行するような場合に、Finate State Machine(FSM)としてはかなりリッチなUMLのState Machineモデルを、平たいState Definition Tableからなる単純なFSMにする場合なんかでもGGベースの変換が効くのではないだろうか。これだったら簡単そうだ。状態遷移図とシーケンス図から独自に拡張したペトリネット図へ変換し、これまた独自の(ほぼ)架空のCPUで直接動かせるようにするといった趣旨の論文を随分前に見た記憶がある。似たようなことは当然MDAでもできてしかるべきだ。このへんは面白そうなので、一度実際にやってみる価値はあるかな。

「宴会『本牧亭』」（OO百韻）

◇ ◀ ▲ ▶

前回のオフ会にでなかったので「今回は必ず！」とこころに決めて参加。 日時は６月３０日、１９時ごろから。 場所は上野一丁目の黒門小の向いにある本牧亭。

1キロ秒ほど遅れていくとすでに出来上がってました。今回は(いつも？)お酒がメインで、松田さんが秘蔵の酒を持ち込んだとのこと。酒が飲めない身には、ちょっとなめてみたけどわからん。鴨のカツとか揚げた胡麻豆腐とか、最後の猫まんまとかなかなか趣向の効いた料理が◎でした。

どこかのMLでなにやら騒ぎが起こったそうで、いるかさんがデフコン１状態で身構えてたらあっさりかわされてしまった、とか、祇園さんの最近の動向、とか、最近はDIConがはやってる、とか、MDAってどうよ、とか、そんな話をして、今回は比較的早めにおひらき。

「量の世界と質の世界」（OO百韻）

◇ ◀ ▲ ▶

一口に平均といってもさまざまなものがあるが、 抽象化のレベルを一つ上げて考えてみると その本質は非常にシンプルであり、 また普遍的な構造を持っていることがわかる。

平均というのは一般に次の式で定義される。

これは相加平均とよばれるものだが、 数学の世界ではこれ以外にも、相乗平均、調和平均などと沢山の種類の平均がある。 これらはそれぞれ意味や用途が微妙に違うわけだが、実はその本質は一つの式で表される。

もしくは、

ここで、f(x)にどんな式をもってくるかで、どの平均であるかが決まる。 いくつか代表的な平均を挙げてみよう。

の場合：相加平均

この場合、となるので、平均の式は次のようなよく見慣れたものになる。

実はこの相加平均には他のすべての種類の平均の要となる重要な役割がある。

の場合：相乗平均

なので、次のようになる。

fを展開すると、最初は一見して複雑な感じだが、log同士の足し算はlog内でのかけ算になるので、最終的には非常にシンプルな式となる。日常生活においては、この形の平均はそうとは気づかないだけで非常によく見かけるものである。 音の強さ、光の強さ、痛み、地震の震度など、 感覚的に「一つ目盛りが上がった」と思う場合は その強さを計測すると実際には数十倍であったり桁が上がっていたりする。

の場合：調和平均

なので、次のようになる。

調和平均は割合とか比率などをものさしにするような場合の平均を表している。 例えば、４km先にある倉庫まで歩いていって荷物をとってくるとしよう。 行きは時速４kmで歩いていき、帰りは荷物を担いだために時速１kmで あったとする。この場合、往復の平均速度は調和平均で計算するのが正しい。

の場合：相加平均±標準偏差

なので、次のようになる。

この式ははしょって乱暴な言い方をすれば 「平均からの差の平均」ということになるだろうか。 平均のを基点に考えれば、その値は誤差のことであり、 つまり標準偏差のことである。

ところでfはいったい何をしているのだろうか？

実はfは「質の世界のものを、量の世界に対応させる」役割をもっているのである。質の世界にあるものは、そのままでは平均という演算を施す事ができない。 そこでfによって量の世界に場所を移し、そこで平均を計算し、今度はfの逆演算によって量の世界から質の世界へ逆対応させているのである。

ちょっと話が飛躍するかもしれないが、自然科学とは全般に、 実際に計測された数値に、その意味を説明づける学問であるとも言える。 そういう意味ではその本質は量の世界と質の世界のできごとを 橋渡しする対応付けの部分にあるともいえるのではないだろうか。

「0.06パーセント」（OO百韻）

◇ ◀ ▲ ▶

OOEnkaiメーリングリストでちょっと話題になったのだが、メンバーの１７人中３人が田中さんである。

日本の苗字７０００傑によれば、田中さんは全国に133.6万人いるそうである。 だいたい１００人に一人が田中さんであると思っていいだろう。 ちなみに、１位から１０位までは順に、佐藤、鈴木、高橋、田中、渡辺、伊藤、山本、中村、小林、斎藤でこのトップ１０だけで1273.6万人おり、日本の人口のおよそ１０分の１にもなる。

OOEnkaiメーリングリストのように、１７人が集まってそのうち３人が田中さんである確率はどれぐらいになるだろうか？　これはどのぐらい珍しいことなのだろうか？　ちょっと計算してみた。

全国から１人だけ抽出してその人が田中さんである確率は１００人に一人なのだから０．０１、つまり１％である。 ２人抽出して片方が田中さんの場合だとで０．０１９８、あるいは１．９８%となる。 このように考えて、確率０．０１の集団から１７選んだ場合にどうなるか表にしてみた。式はである。

n人	確率	パーセント
0	0.842943	84.3%
1	0.144748	14.5%
2	0.011697	1.27%
3	0.000591	0.059%
4	0.000021	0.002%
5	0.000001	0.0001%

つまり、１７人中３人が１００人に一人の田中さんになるのはおよそ０．０６%であるということになる。全国から１７人を選ぶという作業を１００回やっても、そのうち８４回は田中さんなし、１５回が田中さん一人、１回が田中さん二人になる。 ３人揃う０．０６%というのは、この作業を１7００回近くやってやっと一回発生する計算になるだろうか。 このことから考えると、１７人のなかで田中さんが３人いるというのは非常にまれなことだと言っても良いと思うがどうだろうか。あるいはなにかご先祖さまの呪いがあったりとか。

もっともサンプル数が１７というのは少なすぎて、 統計的にはけっして充分とはなさそうではある。 また、本来ならこういう議論をする場合には正規分布とか検定とか 考えなくてはならないのだろうが、なにせその手のことを最後に習ったのは ２０年ぐらい前の大学生のときのことでちょっと手に余る。

「インターフェイスのメトリックス」（OO百韻）

◇ ◀ ▲ ▶

いくつかメトリックスについて簡単にまとめた「 *[生産性]実装(詳細設計)の相対的評価のためのCKメトリックス 」を読んでちょっと触発されてしまった。 この日記の主である呑舟さんはインターフェイス継承のメトリックスについて悩んでいるそうである。

一口にインターフェイスといっても意味が広いが、ここではJavaやC++、あるいはUMLなどで言われるところのインターフェイスについて考えてみる。

メトリックスに関してはインターフェイス単位で考えていたのではなかなか難しいのではないかと思う。 それより「インターフェイスとはオペレーションの集合である」とするような抽象的なレベルて割り切ってしまい、 オペレーションのメトリックスや、オペレーションの集合をベースにした束構造における元の相互関係でもってインターフェイスのメトリックスとしてしまった ほうがいいのではないだろうかと思う。 ちなみに、メトリックスとはあまり関係ないと思うが、このインターフェイスに関するセマンティックス上の割り切りは実はUMLで採られたスタンスでもある。

このような見方をした場合、インターフェイスの実装、あるいはインターフェイス継承はどうなるだろうか。 例えば、仮に今二つのインターフェイスA、Bと、それらを実装するクラスCが一つあるとする。するとこのクラスCは、インターフェイスAのオペレーションの集合とインターフェイスBのオペレーションの集合、そしてもしあればクラスC独自のオペレーションの集合の三つの集合の和集合を、クラスCのオペレーションの集合として持つことになる。 インターフェイスはオペレーションの集合であるとする観点からすると、 この和集合は、AやBとかいったように特に名前がついているわけではないが、 これもまたインターフェイスであり、強いていえばクラスC独自の 名前無しインターフェイスということになろう。

インターフェイスAとBが、どちらか一方が他方を、Javaでいうextendしたもの であったり、あるいは、両方ともに共通する別のインターフェイスをextendした ものであった場合はどうなるだろうか？　 インターフェイスはオペレーションの集合なのだから、 重複する部分については自動的にさっぴかれ、 メトリックスを計算する上では重複しては勘定されないことになる。

以前に知合いと(メトリックスについてではないが)このことを話していて このことについて意見が食い違ったことがあった。 この和集合の部分に引っかかりを感じているために、 このインターフェイスはオペレーションの集合という意見に賛成できない 人もいるようだ。 が、インターフェイスとはサービスの仕様を表していて、実装を表している のではないのだから、それはそれで良いのだと思っている。

話をメトリックスに戻すと、インターフェイス継承のメトリックスとは、 クラスが実装するオペレーションに基づいたメトリックスということになる。 もっとも単純なものは実装するオペレーションの数ということだろう。 実装するオペレーションが多いと、仕様に追加や変更があって インターフェイスに変更があったときのインパクトも多くなるということか。

単純にオペレーションの数を採用するのでなければどんなものが あるだろうか？　 インターフェイスをオペレーションの集合とするような見方では、 インターフェイス全体はオペレーションをベースにする束構造をもつ。 もっとも単純にはブール束になるであろうが、ある種のオペレーション 同士について制約があったりすると、多少は複雑な構造をもつことに なるかもしれない。束であることには違いないだろうが。 この束構造に由来する性質がメトリックスに利用できると面白いかもしれない。

しかし、束構造は半順序集合であるから、当然、比較不可能な要素がある。 これは、数値化、言い換えると全順序のものさしを当てはめて考えるのは 難しいということを暗示する。 そういう意味ではメトリックにはしずらいのかもしれない。

すぐに思いつく数値化の方法として一つ考えられるのは、 束構造中の同じ反鎖集合の元を同一視してしまうなどして、 うまく束構造を輪切りにして、 それぞれの輪切りの最大元や最小元までの距離を メトリックスとしてしまうことだろう。 ただ、オペレーション同士の制約があったりして、その束の中の 輪切りがひとつしかなくなってしまったりするとうまくいかない。 もっともそれはそれで輪切りの数がメトリックスになったりするのかも しれないが。

このようにして、それぞれのクラスは、全オペレーションをベースに する束構造中のどこに位置するかが特定できるし、そういったデータと 最大元や最小元までの距離でもってメトリックスとすることもできるだろう。

しかし、この机上の空論がどこまで使えるものなのかは全くの未知である。 このトピックについてはおいおいに追及していければと思っている。 そういえば、昔商社に勤めていた頃担当させられたHindSightは いまどうなっているのだろうか…。

「宴会『梁の家』」（OO百韻）

◇ ◀ ▲ ▶

今月のオフは１３日に新大久保の韓国料理屋『梁の家』で19時から。 オフの経緯とか参加者については小林さんの日記にちょびっと解説されている。

１９時ちょうどぐらいに行ったら、すでに小林さん以外が全員そろっていた。

韓国料理らしく食べ物は全て唐辛子尽くしで辛味が強かった。肉がいっぱい。 蟹の唐辛子漬けがちょっと臭いがきつくて残してしまった。 最初茶色い色したのが出てきてちょっとびびったが、3日ワインに漬けたという豚の焼肉がとても美味。スキヤキも独特な汁の味付けで美味かった。 が、ウーロン茶にはゴミが入っていた。

小林さんがS2をやるように説得されている話、各種少女漫画の話、 中学の問題だという幾何の問題、Junさんが行方不明の話、 ハードの限界がソフトの並列化を促進するだろうがそれは宣言的なプログラミングになるかもしれないという話、MDAの本には良い本が少ない話、など。

かなり酔っ払ってた人多数。お土産に韓国海苔。

「宴会『カサベリア・隠れ家』」（OO百韻）

◇ ◀ ▲ ▶

今回のオフは新宿歌舞伎町のスペイン料理屋カサベリアで１９時から。

前々回これなかったJunさんが、はるばるボストンから来日して参加。 来日の目的は表向きはビザの更新、実は学生の勧誘と日本酒の密輸。 以前から学生に誘われてはいたのですが、詳しく話を聞くたびに心が動く。

今回はちょっと飲み過ぎてしまって二日酔い状態。だけどみなさんは飲み過ぎ。 いかすみのお焦げご飯が美味しかった。

２３時ごろ石井さんがダウン。脈が弱くなって脂汗を流していてちょっと心配でしたが、店長曰く全然大丈夫とのこと。 看病役組と２次会組に分かれて、２次会組は隠れ家へ。 後に呼び出されたいるかさんが合流した看病役組は石井さんをタクシー送りにして 隠れ家へ。

ひがさんが２ちゃんねるで悪口を書かれて落ち込んでしまったが、 原因はどうやらいるかさんに怨みをもつ人間がやつあたりをしているのではという話とか、 木村さんはもうちょっと腹に力をこめて声をださないといけない話とか。

途中抜けた人がいるも、ほとんどは始発まで粘りました。 そういえば、FPROG時代のOOOFFでは、Junさん、小林さん、へげもんさんの３人のうち２人が揃ったときはいつも朝までやりましたね。 そのパワーはいまだ健在。

「あがる」（OO百韻）

◇ ◀ ▲ ▶

ライトニングトークが終わった。 人前で話すのが久しぶりだったためか、 あがりまくって５分のタイムオーバーになり、かなりぶざまな感じ。 マイクを奪われて最後の１ページができませんでした。

人に助言されて背広を着ていったのが敗因だったか？

お題目「ソフトウェアパターンと形式化」の資料はhttp://www.mediaware.jp/yuntanach/cs/archive/SoftwarePatternAndFormalization.pptにあります。べしゃり５分で１１ページ程なので内容はほとんど無いに等しいかもしれませんが、興味のある人はご自由に。

「My Definition of 生産性」（OO百韻）

◇ ◀ ▲ ▶

他の人の日記とかメーリングリストなどで生産性の定義がしばしば議論されている。 というわけでここでもやってみようと思う。

生産性を定義することの意味とか有用性についてはとりあえず棚上げにし、 数学的にどうなっているかを考えてみる。

まず最初に考えつくのは、生産性とはもっとも単純なところで、 利益、コスト、時間、人数の４つのパラメーターをもつ関数として 表されるだろうということである。 これはおそらく製造業における生産性の定義になっているのではないかと想像するが、 同じ人数の作業者が、同じ時間をかけ、 同じコストで同じ収益をあげた場合は、 同じ生産性であったと考えるのはそれほどおかしな話ではない。 ただし前提としてだれがやっても同じ結果が出るというものがある。 だから同じ手法でというのも上記に加えて前提になっているはずである。

ただ、利益とか収益、コストといった用語を使うと、 どうしてもお金の勘定に発想が固定されてしまう傾向にあると思うし、 商売上の儲けの多少を考えるのではなく、 ソフトウェアの開発や生産において生産性がどういうものかを考えたいので、 以下利益とコストはゲインとロスと言い換える。 つまりこの生産性関数は、ゲイン、ロス、時間、人数の４つのパラメターで表されるとする。

この関数は具体的にはどのような形をしているのだろうか。 他の条件が変わらない場合のことを考えることから始めてみよう。

まず、他の条件が変わらない場合にゲインが大きくなった場合、 生産性はどうなっているだろうか。 なぜ他の条件が変わらないのに、突然ゲインが増えるのかといったことは問わない。 何故かというと、ゲインの増減が生産性の定義においてどのような位置付けをされて いるのかを吟味したいからである。 当然、ゲインが増えたのだからそこから計算される生産性は上がったと考えるべきだろう。

次にゲインがどこまでも増えれば、生産性も増えるだろうか。 それともあるところで生産性は減少に転じるだろうか。 ゲインの増加に伴って、あるところから生産性が減少するということはないだろう。

このように考えると、ゲインに対しては生産性は単調増加であると言える。 ここで注意すべきは、別に比例するとは言えないことである。 もしかしたら、生産性には上限があり、だんだんある値に漸近するものなのかもしれない。 この段階で言えるのは、ゲインが増えれば生産性も増えるということだけである。

次に、ロスについてはどうであろうか。 ロスが増えれば生産性は下がる。考え方はゲインの逆である。 よって、ロスについてはゲインと全く逆になり、単調減少になるだろう。

時間についてはどうか。例えば時間が倍になったのに、ゲインが同じ場合、 その生産性は高いとは言えない。逆にゲインが同じ仕事を半分の時間でこなしたと したら、その生産性は高かったと言える。よって時間に対しては単調減少になる。

人数については、生産性における位置付けを考えるのは少し難しい。 人数を増やしたら生産性は上がるかといえば、経験上そうとは言えそうにはないからだ。 ただ、人手が足りないがために、同じ仕事でも時間がかかってしまうということは よくありがちな話だ。上でみた通り、時間がかかったということは生産性は低かったということになる。 いっぽう、ソフト業界は慢性的な「人手余りの人材不足」ということを 考えると、生産性に関与するのは単純な頭数ではなく、なにか人材関数とでもいう ようなものがあり、それを通した上での人数であるのではないだろうか。 つまり、生産性に関与する人数とは、単純な作業者数のことではなく、 人材関数に作業者数を与えた結果の人数ということにする。 この人材関数はおそらく人数から単純に計算できるものではなく、 方法論やプロジェクトの状態にも影響を受けるはずである。 とりあえず人数を人材関数に通したことを表すため、これを人材数と呼ぶことにする。

それでは、この人材数は生産性にどのように影響するかであるが、 安直に人材数が増えれば生産性は単調増加するということにする。 同じ条件で人数が増えれば一般に生産性は下がったと判断される。 一方、人材数はこの逆数のようなもので、 例えば頭数を減らしたのに最終的な生産性が同じなら、 それはより良い人材を得たと言える。 人材数とは人数に依存して生産性を上げる要素ということなのである。

これで、四つのパラメーターがそれぞれ生産性を単調増加させるか、あるいは 単調減少させるかがはっきりした。まとめると次の通りである。

ゲイン	単調増加
ロス	単調減少
時間	単調減少
人材数	単調増加

しかし、これだけではまだ生産性の姿は みえてこない。四つのパラメーターを組み合わせて考える必要がある。

まず、ゲインとロスの関係について考えてみよう。 ゲインが増えてもロスが増えてしまえば、生産性が上がったとは言いにくい。 つまりゲインとロスは互いに打ち消しあうと考えてもよさそうである。

ただここで、単に打ち消しあうといっても、差があるのか、比率なのか、 つまり、ゲイン－ロスなのかゲイン／ロスなのか、 あるいはもっと別の関係にあるのかという問題を解決しなければならない。 もう少し突っ込んで考えてみる必要があるが、これもなかなか悩ましい。

時間や人材数に関しては、これは明らかに比率である。 というのも、ゲインやロスと時間や人材数との差というのは、 単位が違うわけで、そのままでは差を考えることができないからだ。

難しいものをいつまでも難しく考えていてもしょうがないので、 いっそこのこと当面不都合がでるまではゲインとロスはまとめて 考えてしまうことにする。 ちょうど良いことに、ゲインという言葉には増加分という意味の他に 増加の比率という意味もある。 むしろこっちのほうが一般的かもしれない。

そういうわけで、以後ゲインとはマイナス分を打ち消しあった残りという 意味に変更する。それが差なのか比なのかはとりあえず保留するが、 収益とかコストとという文脈では差になるだろうと思う。

次のようにまとめの表を更新する。

ゲイン	単調増加
時間	単調減少
人材数	単調増加

この三つのパラメーターは、とりあえず一番単純なところで考え、 互いに比率でもって作用しあうと考えて良いだろう。 すると、結局ここで得られた生産性の定義式はもっとも単純に考えた場合には、次の通りになる。

、、をそれぞれゲイン、経過時間、方法論による係数とし、
をある状況における人数の人材数とすると、
生産性は次の式で定義される。

あくまでこれはもっとも単純に考えた場合の話であり、 今後この式をたたき台にしていろいろと改良していく必要があるのは いうまでもない。が、とりあえずはこれを「ソフトウェア祈祷師が提唱する 生産性の定義式」としたい。

この式の意味するのは、すなわち次のようになる。

なるべく人材数の高い少数精鋭メンバーを集め、
より高い係数を持つ方法論を採用し、
より少ない時間で、
より多くのゲインを求めれば、
さらに高い生産性が得られる。

極めて当たり前の話ではある。しかし、なんとなく馬鹿にされているような気もする。たかが数式の分際でここまで人間様を小ばかにしてくれるとは、どうしてくれようか。

ちなみに、方法論係数kと人材数rを無単位数とし、 ゲインgは利益を金額で表しているとすると、 pは「時間当たりの利益」になる。 これは平たくいえば時給みたいなものである。 人材数が無単位ではなくに人数分の１(ゲインを頭数で均等に分けるという意味？)だとして、 pは「技術者一人が１ヶ月にあげる生産量」と解釈すれば、 つまり人月で考える工数と考えられなくもない。 なんだかやっと古典と同じスタートラインに立っただけという感じで、 これだとゴールが全く見えない。

う～む。まじめに研究している人が見たら憤死してしまいそうな結論だなぁ…。

「My Definition of 生産性(2)」（OO百韻）

◇ ◀ ▲ ▶

前回のMy Definition of 生産性(1)では、生産性に影響を与えると考えられるパラメーターとして、 ゲイン()、経過時間()、人材数()の三つの変数と、 方法論の選択の仕方によって生産性にインパクトを 与える係数()を一つ考えた。 とりあえず第一歩として作り出した生産性()の定義式は次のようであった。

今後、この式をたたき台としてさらなる改良を加えていきたいわけだが、 その前にこの式を吟味することから始めたい。

ゲインの具体例

まず、ゲイン()であるが、そのままではかなり抽象的な要素である。 しかしこの抽象化は意図したことであり、 一言で生産性といってもかなり意味が広いため、 あえて具体性のないものを定義に使用したのである。 それでは、具体的にはどんなものをゲインに当てはめることができるだろうか。

売上や利益

売上と利益とでは意味が違うが、どちらも商売上得た金額に関係する点で同じである。これらに関してゲインがどのように定義されるか表にしてみた。

売上／費用	投入した費用に対する売上
売上－費用	最終的に得た利益
(売上－固定費用)／可変費用	上記二つを合わせたもの

製造業や経済学などでは一般に生産量や設備投資、原価計算などから計算する産出量／投入量を生産性としているようである。対投資効果とでもいうことなのだろうか。また、売上－費用、つまり利益のことでありあまり一般的ではないが、これでもってゲインとする考え方もある。これは設備投資や固定費など生産量に比例しない値を単純に投入量に含めて考えてしまうと、それで計算される生産性が感覚に一致しなくなってくるという欠点を補うため、単純に比率で考えることができないものはまずは引いてしまえという考えからくる。

機能

ソフトウェア開発においては最終成果物の機能(の数)をベースにして生産性を考えることが非常に多いようである。 しかし、しっかりと原価計算をしたうえで生産性を割だす製造業と、仕入れの概念が全く異なるサービス業としてのソフトウェア開発とでは当然ながら同じ指標を全く同じように使えるわけがない。 機能の数と金額はあまり関係ないことの方が多くためか、この違いからくるすれ違いが「ソフト開発における生産性の議論」において多くの混乱を招きよせているように見受けられる。

品質

ソフトウェア開発において、はっきりと明言しているわけではないが、要約すると品質の向上でもって生産性の向上とするケースが最近増えているように見受けられる。

前提として要求や仕様の機能を全て実現するのは当然であるとする立場をとると仮定する。その仮定において、投入する人員や時間によってそれ以上の生産性を上げるのには限界があるような場合、開発現場においてそこで比較されるものがあるとすればその筆頭には品質が挙げられる。機能は同様、納期も同様、そして開発メンバーも同様であるなら、それらは成果物のでき、つまり品質で比べられるというのはおかしな話ではない。 また、経営の観点からみても限られた資源でよりよい品質を求めるというのは競走力の確保のためにはごく当たりまえの話でもある。しかし、品質についても直接的には金額の多少に関係していないことはままあり、単純に金額ベースで考える生産量とてんびんにかけてしまうと混乱のもととなる。

品質を生産性とみなす場合には、前述の機能の数に着目するのとは対称的に、成果物の質やその機能がどれだけ高度なレベルであるかということを指して品質としている。 しかし、量を表すものと質を表すものを、それらの関連性に関する議論抜きでそのままで同じ土俵に乗せて議論することは危険である。

システムの規模

いまだLOC、ステップ数、もしくはそれらバリエーションによるシステムの比較は健在である。 OSや何かの業務システムでも、新しいバージョンが発表されると、そのニュース記事中に何百万行のコードであったかという話が載り、だれもがその数値を聞き流す。 本気で生産性の判定にLOCをを使う人間はいないはずだと皆が信じながら、 それでも記事にはなり、その数値でシステムの規模を想像する。 また、組み込み機器の開発などではもっと積極的にコードのステップ数が議論され、その結論が仕様になる。

よって、甚だ不本意ながらもLOCなどの統計情報をシステムの規模を比較する要素として認めなければならず、また生産性の議論から外すこともできない。 しかし、LOCなどからさらに踏み込んでメトリックスを考えた場合、 統計量と品質を結びつける橋渡しとして重要な役割を演じる可能性もあり、 なんらかの利用ができるかもしれない。

障害

システムの保守で生じた障害のうち回復したものをベースに考えると保守の生産性ということになる。 MTTRの合計に対して、復旧した障害の数が多くなるほど、「保守の生産性」が上がったのだと考えることは可能だろう。 また、障害発生当たりの時間間隔であるMTBFは、その値が小さければ頻繁に障害を起こしていることになり、つまりそのシステムの品質は低いことを表していると考えられなくもない。 このことから、MTBFも何らかの形でシステムの品質に関係しており、よって生産性とも関係がある。 この様に考えれば、障害の回数やその回復などは保守における生産性と密接に関係していると言える。

定数

ゲインについては考慮せず敢えて定数として扱ったり、時間や人数を機能当たりに換算して考え、単純に経過時間や人員数のみで比較するという意見もあるようである。 これは、実態としてソフトウェア開発における生産性というものが非常に漠然としており客観的な経営判断に利用するには無理がある場合が多いということが背景にあるのだと思われる。 ゲインがなにであるかはっきりしていなかったり、感覚に合わないケースが多いならば、そのような場合にはいっそのこと時間と人数だけで判断してしまったほうが合理的である。 また、このような場合には、生産性の定義式の方法論係数が重要な意味をもってくるものと思われる。

ゲインの例のまとめ

ソフトウェア開発を基点に考え、すぐに思いつくゲインの具体例はだいたいこれぐらいであろうか。 だいたいにおいて、ゲインには量的なものと質的なものの二つの要素が複雑に絡みあっていそうだということが窺える。 よってこの二つの側面の間の相互関連性、 言い換えれば全単射を見い出すことができれば、 ゲインがなにであるかということに関してかなりすっきりしたものが 得られるのではないだろうかと期待したい。 他に、開発が始まる以前から序盤にかけては量的な面が注目され、 中盤から終盤で質的な面、そして終盤以降は両方が重視されるのでは ないかと考えているが、現時点でははっきりとした根拠があるわけではない。

以上、ゲインの具体例について少し掘り下げてみた。 次回以降(続きがあれば)、ゲインの量的な側面と質的な側面の数学的なモデリングや、他の要素の具体例などについて扱ってみたい。

「オブジェクト vs インスタンス」（OO百韻）

◇ ◀ ▲ ▶

あるメーリングリストでオブジェクトとインスタンスの定義について議論されていた。 要するに「オブジェクト⊂インスタンス」なのか「インスタンス⊂オブジェクト」なのかという見解の相違が焦点だったようだ。 メーリングリストでの議論はすでに収束したようだが、この件について自分なりに考えてみた。

まず、ソフトウェアの分野では、用語としてのオブジェクトとインスタンスは、 それぞれかなり広い意味をもっているように思う。 だからどの定義によるものなのかがはっきりしていないと議論にならない。

今ここで「以後、オブジェクトとは次の文献にある定義に準拠する。」とやっても 良いのだが、そうすると議論はそこで終わってしまう。 あとはその定義をいかに上手に説明できるかどうかになってしまうだろう。 その上、その文献なり書籍なりをとり上げるのが妥当かどうかが問題になってしまい、 「オブジェクトとインスタンスの意味はなにか」という本来議論にしたかった 部分以前のところで、また新たな見解の相違が発生する。

だからここでは特定の定義を引用したりはしない。 あくまで個人の考えにおけるオブジェクトとインスタンスの関係について述べてみたい。

オブジェクト指向を、モデリングの手法のひとつとしての側面から考えてみる。 そこでは、まず第一に「分類」が重要な位置を占めている。 モデリングの対象のそれぞれを、どれとどれが同種であるか、 同種でなければどこが違うのか、といった分類作業がまず最初にあるはずだ。 これは無意識で行なわれるものから、なにか特定の方法論や決まりごとに よって行なわれるかなり幅がある。 また、どこまで細かく分類するのかもいろいろあるだろう。 が、なにをさしおいても分類されていなければ話は進まない。 そういう意味でもまず第一にあるのが分類であろうと思う。

この段階で「オブジェクトとはモデリングの対象のことである」と 定義してしまうことは可能かもしれない。 この見解を持つ人も少なからずいるであろう。 また、それは間違いではないだろうとも思う。 しかし、この段階で早合点はぜず、ここではまだオブジェクトは定義しない。

分類という作業は、表向きはグループ分けのことである。 どういう観点でグループ分けしたのかが 分類を執行する上では外せない重要なことがらある。 が、表面上は単なるグループ分けが行なわれたにすぎない。 モデリングの対象をグループ分けしたということは、 それはある種の抽象化が行なわれたということである。 グループ分けするにあたってなんらかの分類の観点にしたがって 個々の具体性を捨てさり、一つのグループとして認識するようになったわけである。 逆にそれぞれのグループは個々の具体例によって構成されているとも言える。

このように、ある観点に従ってモデリングの対象がグループ分けされると、 それは「概念」を構成しているのだ、とする立場がある。 概念などという言葉を使うと話が大げさになりすぎるような気もなきにしもあらずだが、 あまり深くは考えずにここまで述べたグループ分けのことを以後は一言で「概念」と 呼ぶことにする。

この概念だが、つぎのことがらが関係してくる。

1. その概念を識別し、他の概念から区別する手段。名前など。
2. その概念がどのような観点でできたものかを表す手段。定義など。内包。
3. その概念を構成する具体例の集まり。実例。外延。

「概念」という概念には必ずこの三つがつきまとう。 概念についてさらに語り始めると必要以上に話が大きくなっていってしまうし、 ここまでくればオブジェクトとインスタンスはなにかということを はっきりさせる材料が揃ったと思うので止めておく。

ここまでの話で、すでに「対象」とか「ことがら」といった言葉がでてきている。 これを「オブジェクト」としてしまうまえに、まずは概念の三つ目にある 具体例から考えてみる。

「具体例」は英単語に訳すと“instance”になるが、 インスタンスの正体はずばりこれである。 「インスタンスとはある概念の実例／具体例」のことでそれ以上の意味はない。 概念になにをもってくるかで、モデリングの対象が「それが何のインスタンスである」かが決まる。

次に「オブジェクト」であるが、具体的にははっきりいって定義による。 抽象的にいってよければ、 強いていえば「ある特定の概念のインスタンスがオブジェクト」であるということになるかもしれない。 定義によると言ってしまっては身もふたもないが、 そこで扱うその「ある特定の概念」をどういう範囲に制限するかで、 あるいは、特定の種類の概念(概念の概念！！)を特に強調しているか、 なにに注目しているのかなどで、 オブジェクトがどのように定義されるかが非常に違ってくるので仕方がない。

そもそも、objectという言葉は訳すとその意味の一つに「対象」というのがあり、 ソフトウェアやモデリングの文脈では「何」の対象かがはっきりしていないと、 意味が抽象的すぎているということもある。感覚的な表現だが、 オブジェクトとインスタンスは概念の概念における動と静の違いと でもいったら良いだろうか。

だから、まず、そこで扱う概念の範囲を限定しなくてはならない。 「ある特定の概念」とは何か？　 広くは「この世の全て」から、狭くは「C++のclass」までさまざま考えられる。

狭い場合から考えよう。StroustrupのC++では自己流に要約すると「C++言語で扱うもので、 ランタイムにメモリー上に領域をもったデータとして存在しうる」がオブジェクトであるとしている。 つまりこの「C++言語で扱うもので、ランタイムにメモリー上に領域をもったデータとして存在しうる」という概念の具体例がオブジェクト、 言い換えるとその概念のインスタンスがオブジェクトであると定義されている。 だから、C++のプログラミン上は「オブジェクトで表されるものの集合＝インスタンスで表されるものの集合」である。

「概念とそのインスタンス」と「特定の概念のインスタンスをオブジェクトと呼ぶ」と いうのでは、それぞれ抽象のレベルが違う。 だから上ではあえて「××で表されるものの集合」と表現した。 「××と△△」の比較と「××で表されるものの集合と△△で表されるものの集合」の比較とでは、微妙にニュアンスが違う事に注意してもらいたい。 概念そのものの比較と概念の外延の比較の違いである。 表現が長くなるので、以下「△△で表されるものの集合」を｛△△｝と表す事にする。 例えば、「オブジェクトで表されるものの集合＝インスタンスで表されるものの集合」は「｛オブジェクト｝＝｛インスタンス｝」となる。

UML1.xでは、クラシファイアが概念に相当していると思われる。 そして「クラスのインスタンス」がオブジェクトである。 つまり、クラシファイアのインスタンスのなかでも特に「クラス」の場合を強調してオブジェクトと呼んでいる。 他のクラシファイア、例えばアソシエーションのインスタンスはリンクである。 よって、UMLでは「｛オブジェクト｝⊂｛インスタンス｝」である。

一般にJavaScriptで知られるECMAScriptでは、このプログラミング言語で扱うものは すべてがオブジェクトである。 実際にはすべてがObjectというオブジェクトで、そのObjectをさらに 細かく分類したFunctionのオブジェクトが関数、という具合いになっている。 この例だと「｛オブジェクト｝⊃｛インスタンス｝」ということになるだろうか。 なんとなくオブジェクトとインスタンスの意味はこれまで述べてきたのはまったく逆になっているような気もしないではない。 また「new演算子でメモリ上に確保されたオブジェクトをインスタンスオブジェクトという」 というように、C++言語流で考えればオブジェクトへのポインターがインスタンスと いうことになっており、正式にはこれをインスタンスオブジェクトと呼んでいるようである。 ただECMA262では一般の英単語との“instance”は、 「××は△△のインスタンスである」という言い方もされており、そういう意味では、 「｛インスタンスオブジェクト｝⊂｛オブジェクト｝⊂｛インスタンス｝」ということなのかもしれない。

ここまでプログラミング言語を中心にみてきたが、概念とそのインスタンスのことを ひっくるめてオブジェクトとよび、逆にオブジェクトが概念とインスタンスに分けられる とする考え方もあるようだ。 これは「全てのものがオブジェクト」の極端なケースで、ある意味純粋オブジェクト指向 といえるだろうか。 全てのものがオブジェクトなので、そのなかにはクラスやインスタンスといったものも含まれる。 この場合だと明らかに「｛オブジェクト｝⊃｛インスタンス｝」であるだろう。

逆に、これが示唆するのは、この立場においては インスタンスになりえないなにかが存在する事を暗黙のうちに認めている。 つまり、「オブジェクト＝インスタンス＋インスタンスでないもの」であり、 ソフトウェア上はクラスがインスタンスでないものとして扱うということなのであろう。

こじつければ、これは「全てのもの」という概念を考え、よって その具体例であるオブジェクトは全てのものなのであると考えられなくもない。 しかし、その場合は「インスタンス」の意味が単なる英単語の“instance”ではなく、その分類作業で扱う概念に限定した特殊用途の“instance”であり、これまで述べてきたのとは若干違ってくる。

この件に関してはいずれ機会があったときには、メタモデルの階層とか メタモデルの線形性について書くときに少し触れるかもしれない。

これ以上は結論らしい結論にはたどりつけそうにない。 なぜならば、ここに挙げたわずかな例だけでもオブジェクトの定義はさまざまであり、それにオブジェクトとインスタンスは違う概念の概念に属し、同列に扱えるものではないからだ。 が、あえていえば 「ある概念の具体例を表すことばがインスタンス」にすぎないのであり、 「オブジェクトが何を意味するかは定義による」「ある特定の概念のインスタンスをオブジェクトと呼ぶ」ということしか言えない。 純粋オブジェクト指向の「すべてがオブジェクト。オブジェクト＝クラス＋インスタンス」という立場もいっそのことあっさりしていて魅力がある。 一方、UMLのメタモデルもクラシファイアを中心に据えた核心部分(≠表記法)では モデル要素がはっきりわかって個人的には非常に納得しやすいと思っている。

まとめると、

1. 分類という作業があり
2. 概念があり
3. 概念とは、名前、内包、外延からなり
4. 概念の具体例がインスタンスのことであり
5. オブジェクトはその定義(概念の選択にしかた)による
6. よって、ある特定の概念のインスタンスがオブジェクト

というところか。

他人とこの話題について話す場合には、オブジェクトの定義について相手の立場をちゃんと把握してから慎重いこうと思う。

「メタモデルの線形性」（OO百韻）

◇ ◀ ▲ ▶

メタモデルを考えるとき、さらにメタレベルでひとつ抽象度が上がったモデルとして メタメタモデルなるものを考えることがある。 UMLではユーザーオブジェクトのレベル(M0)とモデルのレベル(M1)、メタモデルのレベル(M2)、メタメタモデルのレベル(M3)の４階層からなる４階層メタモデル体系(Four Leyer Metamodel Architecture、FLMMA)が考えられている。 UMLでも４階層メタモデル体系が提唱され始めたころは、ごく一部のコミュニティではM4だのM5だのといった霞か雲を掴むような議論がなされていた。 最近では表だったところでは４階層メタモデル体系以外のものをあまり、 というか、ほとんど目にしない。 しかし、UMLから離れてメタモデリングそのものを議論したり、あるいはUMLのメタモデリングの問題点について議論する場合には、非常にマイナーなトピックではあるものの、そのかぎりではない。

ここに、厳密メタモデリング(strict metamodeling)という考え方がある。 この考え方に照らし合わせると、UMLに関してなにか知見が得られるかもしれない。 前半はUMLのメタモデルの線形性についての既知の問題点を説明する。 UML2.0ではその問題点を解決するためにかなり大胆な改良が加えられているが、なぜかその問題点をあまり宣伝していないために複雑怪奇な面ばかりが目立ってしまっている。 後半ではアスペクトに関するアイディアのひとつをとり上げる。

厳密メタモデリングの定義

まず、この厳密メタモデリングとは次のように定義される。

簡単にいうと、厳密メタモデリングとは、あるレベルの要素は必ずひとつ上のレベルで対応するあるひとつ要素のインスタンスになっていなくてはならない、ということである。 そして、厳密メタモデリングに基づいたメタモデルを線形メタモデルという。

モデルケース

抽象的な議論だけだと分かりにくいので、モデルケースとなるような例題を考えてみる。 線形メタモデルの説明でしばしば引合いにだされる非常に単純な例題があるので、 ここではその例題から一部を取り上げてみよう。

• あるビデオショップで商品管理を行なっている。
• ビデオを販売している。
• ビデオの『2001年宇宙の旅』が在庫にある。

次の図はこの例題のもっとも単純なモデルをUMLの４階層メタモデル体系に当てはめたものである。

UMLに関連した書籍などではよくおなじみの図である。 各レベルの要素は一つ上位のレベルの要素のインスタンスになっている。 M0からM3の階層は背景の色が緑色(M0)、明るい水色(M1)、暗い水色(M2)、そして青色(M3)で表している。

一見して、線形メタモデルになっているように見える。

しかし、M2レベルに「オブジェクト」というメタクラスのモデル要素を追加すると、 とたんにその線形性は破綻する。

UMLのメタモデルでは、オブジェクトとはクラスのインスタンス、言い換えると、 クラスの実体もしくは実例であると定義されている。 図はモデル層にある(商品としての)ビデオクラスのインスタンスとして、 (在庫のひとつとしての)『2001年』がユーザーオブジェクト層にあることを示している。 一方、『2001年』はオブジェクトなのだから、当然メタモデル層におけるオブジェクトのインスタンスでもあるはずである。 しかしこのインスタンス関係を認めてしまうと、 このメタモデリングは線形ではなくなってしまう。

なぜなら、第一にインスタンス関係は一つの階層しかまたげないはずであり、 第二にモデリングの要素は必ず一つ上の階層の一つの要素のインスタンスでなければならないという、二つが厳密メタモデリングが要請することだからである。

「よって、UMLのメタモデルは線形ではない。証明終わり。」とやってしまっても 実用上はいっこうにかまわないのだが、ここではそれではおもしろくないので、 なにがなぜUMLを非線形たらしめるのかを考えてみたい。

仮説その１：メタモデルは複数階層にまたがる

あくまでも仮説の一つとして、UMLのメタモデルは４階層メタモデル体系を 提唱しながらも、一部メタモデルの階層(M2)にない要素がメタモデルとして 定義されていると考えることができるかもしれない。

この図は、UMLが実際にはM1にある要素をメタモデルとして定義していることを表している。 図中M1’とあるところがそれで、メタモデルで定義されている「オブジェクト」は 実際には線形メタモデル中のM1にある。 つまり、UMLのメタモデルは本来M2にあるべき要素とM1にあるべき要素をいっしょくたにして定義しているということである。

この仮説は、ステレオタイプなど、モデル拡張のために用意された仕組みを説明する場合にも、似たような考えを適用できる。

ところでこの仮説によるメタモデリング体系は、線形だろうか、それとも非線形だろうか？

残念ながら非線形である。 なぜなら、『２００１年』ユーザーオブジェクトは、「ビデオ」クラスのインスタンスであると同時に「オブジェクト」メタクラスのインスタンスであり、二つの要素のインスタンスになっているために厳密メタモデリングの定義から外れてしまうからである。

まぁ、そう堅いこと言わずに、例えば「やや厳密メタモデリング」というようなものを定義すれば良いのかもしれない。 しかし、こうやって基礎となる概念を必要だからといってポンポンつくり出していてはきりがないし、こういうご都合主義は最後の手段にとっておきたい。 よって、この仮説その１は却下もしくはいまのところ保留としたい。

仮説の２:instanceOfには何種類かある

そもそも、UMLのメタモデルが非線形であることの原因のひとつに、 ユーザーレベルのオブジェクトが、モデルのインスタンスであると同時に メタモデルのインスタンスであるという具合いに二通りのインスタンス関係を 持つことがある。 ならば、つぎなる仮説としてインスタンス関係には実は複数の種類があるのだと考えるのはどうであろうか。

インスタンス関係がこれまでの図だと上下にしかないのに対して、 この図では上下のインスタンス関係と左右のインスタンス関係の ２通りが表されている。 上下方向のインスタンス関係は論理的なものとして、L0、L1、L2となっており、 左右関係のインスタンス関係は物理的なものとして、P0、P1となっている。 従来のM0からM3の階層は背景の色が緑色(M0)、明るい水色(M1)、暗い水色(M2)、そして青色(M3)で表している。

つまり、従来のインスタンス関係を更に細分化して、論理インスタンス関係と物理インスタンス関係に分けたのである。メタモデル階層の直積分解である。

インスタンス関係を２次元に拡張することで、物理インスタンス関係と論理インスタンス関係はそれぞれ必ず一つの上位要素とのインスタンス関係を表すことができる。 物理的なものと論理的なものとを別個に考えるかぎりにおいては、 どの要素も必ずひとつ上位のひとつの要素のインスタンスであると言える。 よって、この仮説のメタモデリングは線形である(と、こじつけることができる)。

それに、従来のUMLのメタモデル階層M2は、この多次元メタモデル階層の (P0、L1)と(P1、L0)、(P1、L1)にきれいに収まる。 仮説その１のように「メタモデルの要素の一部が、実はM1にもあったのだ」と いった無理を通す必要がない。

この仮説においても、メタモデリング階層の直積分解などという新たな概念を 都合よく導入してしまっている点で仮説その１と大差はない。 が、仮説その１のようにアドホックに特定の概念を追加するのよりは、 より一般的な原理として直積分解という概念に還元できるので、 (あくまで個人的な好み、および独断と偏見により)こちらのほうが優れている。

よって、この仮説その２をソフトウェア祈祷師の多次元メタモデル体系(Multi-Dimensional Metamodel Architecture、MDMMA)として採用したい。

ひとつ断わっておくが、この多次元メタモデル体系はソフトウェア祈祷師の 完全なるオリジナルというわけではない。 いろいろな説を自分なりに消化したものがこれである。 ACMのDigital Libraryあたりで"metamodeling"などのキーワードで 検索すればいくらでもみつかると思うが、 類似のものがはるか昔からいろいろな人によっていろいろな形で 提案されている。 これはブログなので出典を明確にするようなめんどうなことはしない。 あしからず。 だから、メールなどで類似性の指摘をして強談したり、リファレンスの 明記を強要するようなことは、できれば遠慮してもらえるとありがたい。

UMLのメタモデルが非線形である理由

現状のUMLのメタモデルでは、 すべてのインスタンス関係をたった一種類のinstanceOfで 済ませてしまうために、 モデル階層をひとつ飛び越したインスタンス関係を考えたり、 ユーザーオブジェクトがM1のモデル階層にある要素のインスタンスで あると同時にM2のメタモデル階層にある要素のインスタンスであるといった 必要性がでてしまっていた。 これがUMLのメタモデルが非線形である理由のひとつである。

もちろん、UMLのメタモデルが非線形であってもとりあえずのところは いっこうに困らない。 しかし、ステレオタイプやモデル拡張、パターン、アスペクト、さらには オントロジーなどの絡みを考えるにあたっていろいろと 「あっちをたたせば、こっちがたたず」のことができてしまい、 そもそも土台から改良する必要があると考える人も少なくない。

次の機会には、モデル階層の直積分解とアスペクトの関係や、 MDAのモデルウィーバーなどに触れてみたいと思う。

つづく。

追記:

追加補足

これまでで表示してきた図ですが、モデル要素間の関係は実線で表してあり、 とくにインスタンス関係については矢印で表してあります。 UMLに準拠するなら、インスタンス関係は実線の矢印ではなく、破線の矢印にすべきものだったかもしれません。 だから、例えば最後の図だと、クラスとオブジェクトの間にある線は実線で インスタンス関係は表していませんが、ビデオとクラスの間にあるのは矢印で インスタンス関係を表しています。

さらに、つづきで書こうと思ってましたが、最後の図の物理レベルP1においては論理レベルはなくなってしまい。この部分だけ先取りすると次の図にようになります。

物理レベルP1以上のどこかではメタクラス、クラス、オブジェクトを別々にする必要性はなくなってしまうところがあり、結局右側には「モデル要素」ひとつだけがあり、左側のタイプ、ビデオ、「２００１年」などのモデル要素は右側では一つの物理的モデル要素のインスタンスでかまわないということになります。 そして、おそらく今現在オントロジーの主流を締めている派の意見を反映させれば、メタクラスはクラスを特化したもの、クラスはオブジェクトを特化したものいう具合いに下向きの汎化特化関係がつくことになります。この件に関しては、サブタイピングとサブクラッシングの反変性の一面が絡んでくるものと思われ、おそらく汎化特化関係についても今回の議論と同様に何種類か考える必要がでてくるのだろうと考えています。

「我はソフト開発者」（OO百韻）

◇ ◀ ▲ ▶

ロボット工学の三原則とは次のようなもので、アイザック・アシモフのＳＦ小説“I, Robot(邦訳：我はロボット)”で提唱され、彼の後の作品群で基礎的な役割を担っているだけでなく、この分野のＳＦ小説に絶大な影響を与えた。

また、彼は後にこの三原則のさらに上位に位置するものを考案した。

三原則の中ののロボットという言葉は、ツールとかエージェント(執行者)という言葉で置き換えても十分通用する。 例えば、ロボットを家電製品とか人間で置換えたらどうなるであろうか。 文言は文意に合わせて多少変えてある。

要するに家電製品の安全性、利便性、耐久性、そして社会に対する貢献性を表しているにすぎない。

「危害や損害を加えないこと」を「幸福を追及すること」とか「社会に貢献すること」と意訳してある。 法治国家においては、建前に過ぎないにしても、どこもがこれら原則と意味として同等なものを掲げているだろう。

語句の組み合わせによっては無理があるケースも少なからずあるが、 うまく用語を選べばだいたいにおいてどんな場合にでも通用する概念で、 しかもこの原則に乗っ取って構築された社会は一種のユートピアといっても良いだろうと思う。

ただし、人間がユートピアを追及するとどうなってしまうかについては、 ２０世紀の社会主義国家がその一例を示してしまっていると思う。 あの社会体制はそこに属する全ての人間が完全な善人でなければ なりたたない。 人類がユートピアを実現するにはまだまだ未熟であることの好例であろう。

話がきなくさくなるので、強引にソフト開発に結びつけて考えてみる。

はたしてこの原則はソフト産業にも通用するものなのだろうか。 最近はやりの一部のコミュニティにどっぷりはまっているひとたちには熱烈歓迎されるスローガンなのではないだろうかと想像する。 一般論としては、第０条は別にして、どのソフト開発者も少なくとも目指していることはたしかだろう。 なぜなら、次の「三原則の否定」を全面的に認める人はまずいないだろうからである。

ほとんど例外なく、この「三原則の否定」は表向きはアンチテーゼとしてとらえられる。 しかしよくよく注意して聞いていると、部分的にはこの「三原則の否定」を主張している場合も少なからずあり、そんなときはなんとなく、経営者対労働者とか資本主義対共産主義の戦いをまのあたりにした気分になる。

しかし、個人的にはナッシュ均衡解の考え方のほうが現実的で好きだ。 これは自分が善人でないことの証拠なのかもしれないが。

果して、ソフト産業はユートピアに到達できるのだろうか。

「ニフティのフォーラムが消える…」（OO百韻）

◇ ◀ ▲ ▶

ニフティサーブのフォーラムがなくなるそうだ。

ここ２～３年は全然ごぶさたしているのだが、 無くなってしまうと聞くとなんだか感慨深いものがある。

ニフティに入会したのは９１年からだから、かれこれ１３年たつわけだ。 ずっとむかしにCompuServeもMIXもなくなってしまったし、 通信環境もずいぶんさまがわりした。

昔はニフティだとケチアクセスとか課金をいかに減らすかにない知恵を搾ったものだが、 それでもなんにもしてないような月でも最低でも２～３万は通信にかかっていたなぁ。 MIXのtelnetがポート指定で接続できたからhttpとかgopherとかは 通信ソフトに手を加えてMIXのパソコン通信の接続を経由するような 涙ぐましいことをやっていたことを思いだす。 そのMIXも無くなって久しい。

当時は常時接続なんて夢のまた夢だったなぁ。

「欠点克服停滞率」（OO百韻）

◇ ◀ ▲ ▶

「Ryo.Matsudaのほろ酔い徒然」の１１月２４日の日記「人のアサイン」に面白い話があった。

第一印象で答えれば、Ａさんのスキルの合計点は２００点なのに対して Ｂさんのスキルは高々３０点なので、Ａさんがすごすぎだとしても Ｂさんは明らかに半人前に見受けられる。 半人前の人間はベテランの下に付けるのが無難だろうということで、 Ｂさんを単独で仕事にはアサインしないというのが考えられると思う。 するとＡの仕事もＣの仕事も両方とも、Ａさん中心＋Ｂさん補佐と いうアサインメントはありがちなやり方ではないかと思う。

Ｃの仕事はどちらにアサインしても２０点とか３０点とか しかできないのだから、そういう仕事は受注しないという選択子も 十分考慮にいれるべきなのかもしれない。 実際問題としてはこれが正解だろう。 そうやってたらいまわしにされた仕事は私のようなところにまわってくるのだが。

上の答は、どちらかをどちらかに割り当てるといったデジタルな ものではなく、アサインメントが按分できることを前提にしている。 それではどのような比率に按分するのが最適解なのだろうか。

ＡさんをスキルＡを必要とする仕事に比率ｒで割り当て残りはＢさんにやらせるとし、 同時にＡさんとＢさんの余力をスキルＣを必要とする仕事に割り当てるとする。 すると、

となるから、二つの仕事の合計は単純に足してとなる。 rは０以上１以下なのだから、この合計を最大にするのはのときである。 つまり、ＡさんをスキルＡを必要とする仕事に全力投球させ、 Ｂさんにはなにもさせない(いずれは首にする)という解釈になる。

しかし、人間というものは向上するものである(逆もあるが)。 よって、各人とも仕事が終わるとスキルが上がるとしよう。 テレビゲームでいえば戦闘が終わると経験値をゲットするようなものだ。 ただＡさんのスキルＡがすでに１００点なので、 スキルが青天井だと面白くないからちょっと凝ったシステムを考えてみる。 仕事が終わって向上するスキルは１００点までの足りない分が 仕事の点数に比例して減るとしてみよう。 例えば、ＡさんをスキルＣを必要とする仕事に按分率５０％でアサインした場合、 その仕事の点数は１０点なのだから、ＡさんスキルＣの１００点までの 残り８０点のうち１０／１００が減って７２点になり、つまりＡさんの スキル２０点が２８点に向上するとする。 こうやって何回か仕事をこなしていけば、 最初は会社にとってリスクではあるが、 メンバーのスキルがだんだんと向上していくのでうれしいという ことにはならないだろうか。検証してみよう。

しかしながら、このモデルには致命的な欠陥があって、 ＢさんはいつまでたってもスキルＣを向上させることができない。 その理由は、初期条件のＢさんのスキルＣが０点であることに起因する。 よって、かなりインチキではあるが、 ＢさんのスキルＣは最初は例えば１点とか１０点とか、０点以外の 点数をもっていたのであると設問を変更させてもらおう。

まずはこのモデルのアイディアをグラフの形にしてみた。 話を単純化して、単独で仕事をしたと限定して考えた時の スキルＣの点数が向上していく様子がプロットされている。 グラフは縦軸がスキルの点数、横軸が仕事の反復回数で、上側の折れ線から順に、90、50、30、10、5、1、0.1の初期値で始まっているものである。 Ｂさんは最初スキルＣの点数が30(上から3番目の折れ線)であるが、 仕事をこなす事７回目にはほぼパーフェクトなスキルを身につけていることがわかる。 また、同様に初期値が1のほとんど素人同然の人の場合(下から2番目)だとパーフェクトなスキルを身につけるまで １０回以上の仕事をこなす必要があることがわかる。 この場合、３～４ヶ月かかる仕事なら一人前になるまで実に３年の年月が必要ということになる。 私の見聞きした範囲でほぼ素人同然の人でも１年後にはいっぱしのプロジェクトメンバーとしてそれなりの仕事を任されてしまっている現状を考えるに、 ３ヶ月で終わるような小さな仕事だと、この３年という年月はちょっと長いかもしれない。 このような極端な例はおいていくにしても、 自分を振り返って新技術には日頃から唾をつけておいていざというときのために 最低でも初期値0.5はクリアしたいところである。

ここで、人物を表すＡ、Ｂとスキルや仕事を表すＡ、Ｂ、Ｃが紛らわしいので、 人物はa、b、スキルをu、v、wと表すことにす。 またスキルと仕事はとりあえず同一視して、スキルuを必要とする仕事も 仕事uと表すことにする(実際には仕事は複数のスキルを必要とするだろう)。 まだ、n回目の仕事が終わったときのaさんのスキルuの点数をと表すことにしよう。 初期値n=0の場合がもともとの設問となる。

すると、n回目の仕事uとwの点数とは、aさんを仕事uにアサインする按分率をr(n)と すると次のようになる。

そしてこの仕事をこなした後、各人のスキルは次のようになる。 ここで、式にいちいち満点を表す１００が入ってくるのがうっとうしいので、 またもや設問を変えて、点数は０点～１００点ではなく、０～１の値をとるとする。 すると、上記の各人のスキルの式は次のようになりすっきりする。 同様にメンバーa、b、スキルu、wのそれぞれについて点数値を 列挙すると次のようになる。 これらの式に仕事の点数Jを代入すると次の式が得られる。

ちょっとめんどうだが、これらの式は次のように変型できる。 ここで、式がごちゃごちゃしてきたので、 n-1で一回前のアサインメントを表すのではなく、 プライム＇をつけることで前回を表すようにした。

まだ、ごちゃごちゃしてみずらいので、をと置き換えてみよう。 かなりすっきりとしてずいぶんきれいな式になった。

このはなにを意味するのかというと、 １つまりスキルがパーフェクトな状態から現在のスキルを引いたわけだから、 自分のスキルで今後向上する余地、 言い換えると現在の自分の欠点を表していると考えることができる(前提として、だれもがパーフェクトな存在になることを目指しているとしている。 現実はそうではなく、自分は不完全なまま少ない労力で なるべく多くをゲットしようと腐心するのが大多数であるが)。

最終的には各DをJの式に代入して仕事の点数の合計を比べられるように なれば良いのだが、その前にこの式をもう少し掘り下げてみよう。 まず両辺をでわって、右辺から右側にあるを 取り除いてみる。 本当はこの漸化式をｎについて解きたかったのだが、 難しいので断念した。 で、急遽比率を調べてみることにしたわけである。

この式は、前回の欠点に対する今回の欠点の割合を示している。 この値が０に近付くほど多くの欠点が克服され、 １に近付くほど欠点の克服が停滞してそのままになっていることを表している。 もしかしたら１を越えてしまい、欠点が増えるようなこともあるかもしれない。 これを、ちょっと長いが、欠点克服停滞率と名付けよう。 ちなみに、 １からこれを引いてを計算したならば、 それは停滞しなかった分、つまり、前回の欠点に対する克服した欠点の比率を表すので、それは欠点克服率といってもいいだろう。

実はこの欠点克服率はだいたいスキルの曲線と同じような曲線を描くということがわかっている。 なぜなら、r=0のときを考えればとなるので、どういう初期値で始めようともＤが０以上１以下である限りはnが大きくなればなるほど０に近づくからである。 欠陥Ｄがそのように解けるなら、欠点克服率はとなる。 これと上のグラフを見比べてみて欲しい。 二乗がある分だけグラフが下側に歪むが 二乗の部分以外はほぼ同じような形をしたものになるはずだ。 本来なら一般のrについて論ずるべきだが、 それを説明するには漸化式を完全に解かねばならず、 いずれパワーのありあまっているときにでも再チャレンジしてここを埋める ことにして、今回はお茶を濁す(実はこの部分が重要だったりするのだが)。

この式は一見してちょっと常識からずれた変な部分があるように見える。 例えば、aさんならこう考えるであろう。 「自分の欠点の克服の度合が、なんであんな半人前のb君の欠点に依存するんだ？」

この疑問を追及するには、まず、rと欠点克服停滞率の関係をよくみきわめなければならない。一般性を失わない範囲で、仮定としてaさんのスキルuはb君のそれより高いとしてみる。はrについてまとめると次のようになる。

aさんのスキルuの欠点克服停滞率はrが小さいほど小さくなる。 aとbのスキルに差が大きいほど、スキルの低い方を比重を大きくして アサインしたほうが、最終的にメンバー全員のスキルの延びは停滞が 少ないことを表している。 逆にスキルの差があまりない場合は、rをどう調節しても大した違いは生じない。 また、b君のスキルuの欠点克服停滞率はaさんのそれと同じになる。 各人が別個にスキルを伸ばすのではなく、 チームとしていっしょに伸びることを示唆している。 aさんとb君はスキルの向上に関して運命共同体なのである。 運命共同体、これがaさんの疑問に対する答だ。

ひとつ残念なことに、このモデルではrの次数が１次なので、 r=0のときが最適解、r=1が最悪解ということになり、 当初前提にもってきたアサインメントを按分する意味が 失われてしまっている。

最後に、いよいよJに代入して会社としてトータルで何点の仕事をこなせる ようになるかを考えてみよう。とを足してDについて表したらどうなるかみてみよう。

式の最後では、仕事の点数の総合計は前回の仕事からの欠点克服率の合計になることが判る。 意外にも簡単な式になったので、当の本人もびっくりである。 下らない計算ミスなどしていなければいいのだが…。 この式の解釈は、最初はトータルの点数は悪かったとしても、 経験を積めば積むほどそれに応じて点数も上がるということになる。 上のグラフでは単独で一つの仕事をした場合の話だったが、 チーム全体でも同様のことが起こる。

要するに、

• 欠点の多い部分にこそ戦力を投入せよ
• 直近の利益より、長期的視点にたて
• 個々のスキルはみんなで一丸になって伸ばそう
• 何度でも反復して精進することが大事
• さすれば、いつかはパーフェクトな存在になれれる

ということだ。 学校などで、「苦手科目の克服こそが勉強の王道」などとできの悪い生徒に 渇を入れる熱血教師とかが言いそうな内容である。

rの按分については、Ryo.Matsuda氏の日記だと、r=0の場合とr=1の場合が 挙げられている。r=0の場合とは、ＡさんをスキルＣの仕事に割り当て、 ＢさんをスキルＡの仕事に割り当てた場合に相当し、r=1の場合とは、 ＡさんをスキルＡの仕事に割り当てもう一方の仕事は事実上断わる というものであった。 ちなみに、仕事の点数はそれぞれ合計５０点と合計１００点になる。 だから後者のr=1のケースを採用したほうが、 会社としてはトータルでは高い点数の仕事をしたことになる。 その場合、Ａさんはいつでも１００点の仕事をし、 会社としては二つの仕事で合わせて１００点平均して５０点の 仕事を延々と行ない、 おそらく首になったであろうＢさんはいつまでたっても３０点のスキルしかもてず、 自分よりスキルの低い人ばかりのところにたどりつくまではいつまでたっても日の目をみれず転職を繰り返すというのがこのケースの解釈である。

一方、r=0のケースでは、最初は二つの仕事で合わせて５０点 平均して２５点の結果しかだせなかったが、 同じ仕事を何回も行なううちにだんだんとちょっとづつ良い点数で行なえる ようになり、十分時間をかければ合わせて２００点平均して１００点の仕事を こなせるようになる。 メンバーにスキルが低い人がいて、 たとえ点数の低い仕事しかできなかったとしても、 しばらくの間はおたがい融通しあって辛抱強く仕事をこなしていきけば、 いつかは必ずむくわれるという非常にハッピーエンドな世界が このモデルの結論である。

このモデルでは、前提として仕事をするたびに欠点が克服されるという 非常に楽天的な仮定が根底にあった。 しかも、欠点が多い人ほど克服する分が多いというきわめて乱暴な 条件でつくられたモデルである。 しかも、最も奇妙キテレツなこととして、 チームのだれかがある割合で欠点を克服しスキルを向上させると、 他のメンバー全てが同じ克服率を達成できてしまうことだろう。 向上したスキルのレベルは人それぞれだが、 仕事が終わるたびに同じ割合だけ欠点が克服されていくのだ。 これはまったくもっておかしい話に聞こえる。 現実の世界はそういう具合いに簡単なものではないので、 そういう意味でここでの結論は数字遊び以外のなにものでもないだろう。

上で欠点克服率の漸化式は一般のrについては解かなかった。 もしかすると、漸化式を完全に解き、 毎回仕事をアサインするたびにｒを変えるなどすると、 より現実的な解が得られるのかもしれない。 こういうところにもモデルが現実的でないように感じる原因がある。 また、自分のスキルが相手の欠点克服に依存するのは、 仕事が終わってスキルの点数を増加させるときに、 r=0のときなど実質上自分が関与していない仕事の場合でも 自分の経験値に加えてしまうあたりが原因にあるのだろう。 このあたりは改良の余地がたくさんある。 しかし、この単純だがあまり現実的でないこのモデルが、 社会主義的な結論に導かれたのはある意味示唆的であるとも思う。

ちなみに、十分に検算をしているとはいい難いので、 どこかで下らない計算ミスをしていて、 そのため結論が全く間違ったものである可能性もかなりある。 その場合は悪しからずご了承願いたい。

「欠点克服停滞率(改)」（OO百韻）

◇ ◀ ▲ ▶

前回の「欠点克服停滞率」では その時の都合で条件を限定したモデルを作った。 その結果は主観的に実状に即しているとは言いがたいようなものであった。 少なくとも自分的には。

そこでもう少し改良の余地はないものかと思い、 基本線は維持しながらこのモデルの前提を若干見直してみることにした。

• 人物の数は二人ではなく不特定多数に。a、bの二人からa、b、c、...へ拡張。
• 仕事の数も二人ではなく不特定多数に。u、wの二種類からu、v、w、...へ拡張。
• 一つの仕事が終わった後の経験値のフィードバックを定数ではなくす。

上記の条件で前回のモデルを一般化したらどうなるであろうか。 前回のモデルを拡張していく方向でやってみる。 まず仕事の点数であるが、仕事のアサインメントを前回のrから、 人物iを仕事jに割り当てたときの配分をとし、 人物iがもつ仕事jを必要とするスキルの点数をとすると、 次のようになる。 ちなみに、もも前回同様レンジは0から1の間である。

の合計が１なので、各仕事の点数はアサインメントの配分による 全メンバーの加重平均になっている。

を使ってもうちょっと簡略化する。

スキルは欠点の形の方が式が扱いやすいことは前回すでにわかっていたので、ついでに仕事JのDによる式の形も今のうちに計算しておこう。

同様に、スキルSは次のようになる。 ただし、前回の定数１と違い、 今回は人物iが仕事jを終えた時にそのスキルにフィードバックされる 係数としてを導入しよう。

これもDによる式に変形しておこう。 このDの式中のJに上で出しておいた式を代入する。 この漸化式を解くのが難しいのは相変わらずである。 ちなみに、この式からただちに次の欠点克服停滞率と欠点克服率が得られる。 この欠点克服停滞率を使って仕事の式を変形すると次のものが得られる。 ここで、人物を表す添え字が特定の人物aになっている。 これはある人物の欠点克服の度合いが他の人物の欠点と割り当て、 フィードバックの値などから算出され、 チーム全体で共通したものになるため このように特定の人物のデータのみから計算されるように見えるだけだからである。 要するに、仕事の評価というのはメンバーのだれの欠点をベースに算出するかによらないということである。

仕事全体では次のようになる。

前回はを1にしていたので、基本的に前回の結果と同じである。

結局、この程度の一般化ではたいした違いはないというだけのことのようだ。 rやfを工夫すればなにか出てきるかもしれないが、 どうやら欠点をと定義して、パーフェクトからのスキルの差としてしまう以上は似たり寄ったりの結果しか得られないような気がしてきた。 ちょっとがっくり。

ともあれ、これまでをまとめておこう。

最後の式は、適当に選んだある人物aについて、欠点克服率をフィードバック係数で割ったものを全てのスキルについて合計すると、それが仕事全体の評価になるという解釈ができる。

欠点が上記のように定義されていて、 スキルの向上が仕事の結果で決まるとしている限りは、 どのようにモデルを作っても、 個人のスキルの向上は他のメンバーのスキルの向上に依存してみんなでいっしょに向上して それが全員の仕事全ての評価になるということなのかもしれない。

このモデルを追求すれば、人のアサインメントに対する仕事の点数という ものから一般化して、リソースの配分における全体の評価の一般モデルに 関して漠然と何か知見が得られるかもしれないと期待していた。 しかし、具体的なrとfについて何か面白い結果がでるまではたいしたことは わからないということがわかった。 いつか気が向いたらさらに追求してみよう。

「お代は観てのお帰り？」（OO百韻）

◇ ◀ ▲ ▶

呑舟さんの日記「akonの<よっぱらい>の戯言」のセカンドオピニオンでコメントが続いたので。

経済活動は、その根本では「付加価値を生み出すこと」が基本にあるはずだと思っている。 この考えを極限まで追及すれば、経済活動は成功報酬でのみなりたつ、 逆に言いえば付加価値を生み出せなかった場合には 報酬を手にすることはできないということになる。

実際問題としては、しかし、それはさまざまな意味で非常にきつい。

一方で、これもまた極端な例だが、 もし仕事の成果ができる課程の労働行為の手間賃だけだと、 なにも成しえてないにもかかわらず賃金支払いだけが積み上がっていくということに なりかねない。

だから私は、これらの折衷案、すなわち最低限の賃金は支払われるが、 全てがうまくいったあかつきにはその付加価値に応じて成功報酬が 支払われるというのが妥当なところではないかと考える。

ちょっと話は飛ぶが、パレートの法則というのは、 おそらくこういうところでも成り立つだろうと想像する。

パレートの法則とはいわゆる２０％－８０％の法則とか、 ニッパチの原理とかで知られているものだが、 パレートの法則自体はもともとは「富の大半は一部の人に集中する」というものだ。 これは経済学以外でもさらに「質的な大多数は、量的な少数派」という具合いに一般化できる。 例えば、ソフトウェア工学で「プログラムの８割は例外処理で、実行時間の２割を占める」と いう話がまことしやかに話されているが、これなども一般化されたパレート法則の ソフトウェア工学での応用例だろう。

他に、働き蟻はどのようにサンプリングしても必ず１割がさぼりだすというのもある。 働き蟻の動きをよく観察していると、ほとんどの働き蟻はいっしょう懸命に働いて いるのだが一部の蟻は辺りをうろついているだけで全く働かずにさぼっている。 ところが、このさぼり働き蟻を排除すると、こんどはそれまでいっしょう懸命に 働いていた蟻の一部がまたさぼりだす。 つまり、特定のさぼる働き蟻がいるのではなく、どのようにサンプリングしても 一定数の働き蟻がさぼるようになっているらしいのだ。 セルラーオートマトンの研究などで、この冗長性が何を意味するのかというのは いまだ結論がでていないトピックである。 人間社会においても、なんとなくありがちな話ではあるが、 私はこれはパレートの法則の逆適用の話であろうと思っている。

話をもとに戻すと、一般化されたパレートの法則と、 一定数がさぼる働き蟻の話などを考えるに、 最低保証賃金＋成功報酬制度の場合でも、 やはりごく一部の人が成果に寄与しており、 そして別の一部は全く成果に寄与していないと いう状況が出来上がるのではないかと想像している。 こういう制度が一般化したら、一匹狼はつらいだろうなぁ。

課題とすべきなのは、最低保証賃金と成功報酬の配分であり、 またそれらの差を少なくするための方法のことなのではないだろうか。

「十を聞いて一を知る」（OO百韻）

◇ ◀ ▲ ▶

まこたんの日記の［ソフトウェア開発］ソフトウェア開発の変化（というか謎めき）を読んでふと思いだして しまったことがある。

昔私がまだ大学生だったころ、先生が

というようなことを言っているいるのを聞いて非常に感心したことを思いだした。

これをよく耳にする「一を聞いて十を知る」にもじれば「十を聞いて一知る」とでも いう感じになるだろうか。 インプットとアウトプットという言葉ではなく、聞くとか知るという言葉ではあるが、 言わんとしているのは同じである。

私は別に人になにかを教えるような立場にある人間ではないが、 まこたんの日記に触発され反省することしきりである。

「オープンソースはもっと保守性を上げるべく努力せよ」（OO百韻）

◇ ◀ ▲ ▶

私がそう言い張りたいのではない。 CACMの２００４年１０月号にそういうタイトルの記事があったのだ。 タイトルは“Open Source Software Development Should Strive for Even Greater Code Maintainability(オープンソースソフト開発はもっと保守性 が上がるように努力すべきだ)”でIoannis Samoladas、Ioannis Stamelos,、Lefteris Angelis、 Apostolos Oikonomouによる共著で５ページほどのショートアーティクルである。 この手の記事は鵜呑みにするのは危険であるが、 ちょっと気になったので日記ネタにしてみた。

著者らは、既存のソースコードの測定方法を組み合わせ、独自の保守性指標を考案し、 ５つのプロジェクトについて比較をしたのだそうだ。 これは私個人のまったくの想像だが、取りあげたプロジェクトの一つはNetscapeであった のではないかと思っている。 その調査の結果、オープンソースではソフトのバージョンアップに対して保守性指標が 改善せず、せいぜい横ばいか、あるいは緩やかに低下しているというデータを得た。 著者らにとっては不本意だったので活を入れる意味を込めてネガティブムードのタイトルになったのだろう。 非オープンソースのケースでバージョンアップに伴って明らかに指標が低下している のがあるので、それとの比較で考えればけっしてオープンソースに悲観することは ないと思うが。

保守性指標の公式が成立した過程があまり説明されていないので、 個人的にはこの記事にあまり満足していない。 この手の統計値をベースにした指標は、 客観的に検証可能な方法でその成立過程が解説されなければ、 けっこう自分の好きな結果に誘導することが難しくないからだ。 もっとも５ページほどの記事にそれを期待するのはちょっと酷な話ではあるが。

彼らの結論を簡単にまとめると

1. 保守性に関して、オープンソースは非オープンソースと同じか若干良い程度である。これはモチベーションの違いに起因すのではないだろうか。
2. オープンソースでは、コーディネーターの決定によるリリースの突然の変更があるので分析するのに注意を要する。ごく一部のコンポーネントが保守性の問題点の大部分に関与するというパレートの法則が見受けられるのが面白い。
3. オープンソースソフトの品質の低下は、非オープンソースの場合と同じ原因に起因している。
4. 引き続き研究を続ける所存である。

記事の前半、駆け足でいろいろと書かれているが、 オープンソースの短所として不完全なドキュメントとテクニカルサポートの不在を挙げている。 よく言われていることではあるが、この辺りがネックであるとだれもが認識し、 いろいろな人がいろいろな試みをしていながら、 未だ決定打となるような解決策がでていないあたりが オープンソースのネックとなっているのではないか。

個人的なオープンソースに対する感想として、 オープンソースに開発側として関わる人もユーザーとして関わる側も 哲学的な意識改革がもとめられているのではないだろうかと思っている。 今は、オープンソースに関わる人間の、 オープンソースに対するスタンスが問われている段階なのだ。

オープンソース界においては、アレキサンダーは出現した。 ガンジーはいつ出現するだろうか。

「宴会『たつ舞』」（OO百韻）

◇ ◀ ▲ ▶

2005年最初のOOEnkaiは小岩にある手打ち蕎麦屋「たつ舞」で、 予告にあったとおり鴨鍋がメインでした。

店が20時までということで17時からの開始だったのですが、 野暮用があって私は18時からの参加。 小岩の駅前の賑やかなところからはちょっとはずれたところにあり、 時間が時間だけに薄暗くてよくは分からなかったのですが、 なんとなく住宅地の中にある感じのお店でした。 18時ちょっとすぎにに行くとshinchan55さん以外は全員そろっており、 私が到着してから乾杯しなおし。 もうすでに鴨鍋はなくなっていて鴨にはありつけないだろうと 半ば覚悟していったのですが、どうやらメンツが揃うのをまってくれたようで しっかりと鴨鍋を頂く事ができました。 ただし、shinchan55さんは20時からの参加ということで鴨には間に合わなかったようです。

鴨はめったに口にしないこともあってか、 やはり何時食べてもおいしかったですが、 ちょっと肉に元気がなかったような気もなきにしもあらず。 それとも風邪で味覚が鈍感になっていたのかもしれず。

20時閉店の店に21時すぎまでねばって、皆さんは二次会へ、 私は昨日から風邪気味で頭が痛かったので失礼させて貰って帰宅。

「出でて初めて自在を得べし」（OO百韻）

◇ ◀ ▲ ▶

松尾芭蕉の残した言葉を思い出した。

ここでいう格とは基本とか基礎のこと。 基礎の範囲だけだといろいろと制限や制約に束縛されてなにかと不自由である。しかし、基礎をしっかり積み上げないと型が歪んでしまう。 まずは基礎をしっかり習得してからその枠を踏み出すことで 自分自身の型というものを発揮できるようになる。 要するに、まずは基礎の型をしっかり身につけないとダメだよ、 だけどいつまでも枠にはまっていてもダメだよ、とそういうことだ。

後世に伝わるほど、ひとつの道を極めた人の言葉だから重みがある。

自分を振り返ってみるとどうであろうか。 最近は基礎からみっちり積み上げるということがなくなってしまった。 学生のころは、先生に言われて「１００プログラミング」というのをやっていた。 これは何か新しい言語とかシステムとかに直面したときは、 まずは何も考えずに１００個のプログラムを書くというものだ。 一個一個のプログラムはべつにたいしたものでなくてもいい。 単純にひとつの機能を実際に書いて試してみるというものでいいのだ。 例えば、これからＣ言語を覚えようというのであれば、for文を使った プログラムを一つ書いてみて、printfを使ったプログラムを一つ書いてみて、 とやっていく。 Ｗｉｎ３２なら、ＡＰＩはうんざりするほどあるから１００じゃ たりないぐらいだろう。このようにやっていけば１００プログラムなんて あっというまにできて、そしてだいたいは自分の身になっている。 こうやって、大学時代に言語だったらFORTRANから始まり、COBOL、Ｐａｓｃａｌ、 Ｃ言語、Ｐｒｏｌｏｇ、Ｌｉｓｐなどやったし、ＪＣＬなんかもけっこう書いた。 みな、プログラムと呼ぶにはあまりにも単純なものばかりではあったが。

大学を卒業して仕事するようになってもしばらくはやっていたので、 なにか新しいものに直面するたびにこういうことをやるのは習い性に なっていた。 おかげで、いわゆる「勘が利く」ようになっていて、 けっこう要領よくできるようになってたと思う。

しかし、ここ５年ぐらいはどうか。ほとんどやってないじゃないか！

確かにある程度は過去の蓄積でなんとかなる分野ではあるが、 一方で毎年毎年新しい技術が出現するわけでもあり、 乏しい蓄積などあっというまに食いつぶしてしまうことだろう。 やはり１００プログラミングは必要な鍛錬だと思う。

「かつて前線にいたからよく知っているつもりなだけの今は分らない人」に ならないために、生涯プログラマを追及するために、まずは１００プログラミングを復活させるところからはじめようと思う。

「宴会『沖縄料理ふらり銀座店』」（OO百韻）

◇ ◀ ▲ ▶

今回のOOEnkaiは沖縄料理ふらり銀座店で沖縄料理。

豆腐料理ででてきたうみぶどうというのは初めて食べた。 沖縄は大学のときの先輩が住んでいるし、スキューバのアシスタントインストラクターの免許保持者としては自分としては浅からぬ縁のある地域のつもりだったのだが、こういうものを知らなかったのはちょっと間抜け。たいして種類がでたわけではなかったが、料理は全般的に可もなく不可もなく。沖縄料理にしてはちょっとぼんやりしたかんじもなきにしもあらず。

店は凝った雰囲気作りに腐心するのでせいいっぱいで、サービスにまでは手がまわってないというところか。はぶさんが大激怒。店長が呼び出されて正座して説教うけてました。にもかかわらず最後までオーダーもれが残って会計のときになってそれが指摘されてやっとでてきたというのはちょっといただけない。私も最初に灰皿を頼んだのに出てこないから自分で取りにいったぐらいだったし。

でも昨日のはぶさんはテンション高かったなぁ。m_pixyさんとずいぶんと熱く話し込んでいたようだった。私は長テーブルの逆側にいたので具体的な内容は断片的にしか分からなかったのだけど。

１１時過ぎてから店が閉まって、皆さんは２次会へ。新婚の私は１次会で失礼させてもらいました。

「メッセージは同期？非同期？」（OO百韻）

◇ ◀ ▲ ▶

もちろん、オブジェクト間のメッセージという概念には、一番抽象的なレベルでは、 同期か非同期かといった区別は存在しない。

ただ、抽象化のレベルをどんどん下がっていくと、どこかで同期メッセージと 非同期メッセージの区別が生じるところがあることは確かである。 一番底辺のマシンコードのレベルまで降りてくると、そこでは理論上は全ての メッセージがマシン語のサブルーチン呼び出しのコードにまで分解される。

このマシン語のサブルーチン呼び出し自体は同期呼び出しである。 当然ながら、上位の抽象レベルでのメッセージがそのままマシン語のサブルーチン呼び出しになっているわけではない。 しかし、最終的にはメカニズムとして同期するような仕組みにまで分解されることは確かで、だから非同期式のメッセージも同期式のサブルーチン呼び出しや割り込み機構によって実現される。

すると、非同期メッセージというのは同期メッセージによって実現できるのではないだろうか、と考えることができる。実際、マシン語のレベルにいたるまでのどこかでは全ての非同期メッセージは同期式のサブルーチン呼び出しに分解されているわけなので、少なくともこの考えは方向として間違ってはいないはずである。

抽象化のレベルの階梯を上から下がっていくと、 どこか途中で同期非同期の区別が必要となり、 さらに下がるとどこかで同期式に統一されるということになる。 この区別が必要となる条件はどのようなものなのだろうか。 同期と非同期というのは、どちらがより本質的なものなのだろうか。 単に歴史的経緯がその区別を必要なものにしてしまっているだけのような気もするが。

ここ1ヶ月ほど大量のシーケンス図を描く機会に恵まれた。 今まではシーケンス図などは、ちょっと設計を確認する場合とか、 後になってからドキュメントを書くときにちょろっと必要になる程度だったので、 あまり積極的には活用してこなかった。 しかし、最近はなるべくＭＤＡなどを意識してしまうことが多く、 シーケンス図などからコード生成させる方法などを考えてしまうので、 いきおい、シーケンス図が必要になったときにはなるべくそこに全てを記述しようと 試みることになる。

シーケンス図そのものはソフトの挙動のほんの一スナップショットを例示しているに 過ぎない。だから、それだけでコード生成に足る記述は本質的にはできない。 ソフトの動的な側面を完全に記述するには、シーケンス図に加えて、 フローチャートなりアクティビティ図なりなんらかの別の手法を組み合わせて、 挙動の抽象的な側面を補足する必要があるのだ。

つまり、ソフトの動的な側面を記述するだけでもいくつかの抽象化のレベルをまたいだ仕組みが 必要になるというわけで、シーケンス図自体でもそういうことになるだろうと思う。 すると、まず最初に思い浮かぶのがオブジェクト間のメッセージで、 その記述自体もその抽象度のレベルに合わせて何段階かあるだろうということになる。

で、思ったのが同期非同期の区別はどこまで本質的なものなのだろうかということであったわけだ。

非同期メッセージは同期式のサブルーチン呼び出しに分解できるのは上で見たとおりだ。 ある特定のＣＰＵに、あるいは、ある特定の言語の、さらにいえばあるライブラリセットの、 プラットフォーム依存の形では全てのメッセージは同期式のなにかに分解される。 逆にプラットフォーム非依存の形においては同期非同期の区別はどこまで必要なのだろうか。

非同期メッセージは同期メカニズムに分解できる。 一方、同期メッセージも非同期メカニズムに分解可能だ。 マシン語のレベルまで下がろうとすると非同期から同期へ分解されることになるが、 そこにいたるまでのプラットフォームによっては全てが非同期というのも、極端だが、考えることができる。全てが、というわけではないが、ウィンドウメッセージなどそのいい例だろう。

同期非同期がらみで、抽象化のレベルとそれらの区別の必要性の条件というのをはっきりさせないと、シーケンス図をはじめとする動的なソフトの挙動の記述からコードを生成する仕組みは、 膨大な経験則の塊になってしまうのではないかと危惧する。 より本質的な部分とより実用的な部分、この二つの観点の切り分けをはっきりさせる必要がる。 今年の１００プログラムには、ちょっと初心にもどって、このシーケンス図も含めることにしよう。