勘違いとは？
|
勘違い発見の哲人Ｎ氏から、久々に新ネタを入手したので、本日ここに謹んでご披露申し上げる次第。 「冬の富良野にも注目してほしいですねえ。美しい『サンピラー現象』や『ダイヤモンド・ダクト』は必見ですよ」。 時と場合によっては政治問題へと発展しかねない、きわめて危険きわまりない勘違い、ライオンズクラブ会員Ｈ氏の作品であります。 うっかりすると聞き過ごしてしまいそうな、びみょーな勘違いなのでありまして、「耳に残る」と「目に焼き付く」 のいわばハイブリット言語。 「捐」の字が「損」によく似てるために起きてしまった勘違い。勘違いというより、無・・・・・、いや、やめておきましょう。 うろ覚えの言葉をうろ覚えのままうっかり使って、仲間の失笑を買うなんてことは誰でも一度や二度は経験があるもの。 が、一度や二度ならいいものを、こりずに連発してしまうニクメナイ人も世の中には存在するわけで。 実は我が町にも、度重なるうろ覚え言語で周囲を氷漬けにし、事情通から密かに「勘違いの鉄人」として畏れられている「伝説の勘違イスト」が存在しているのであります。 彼のすごさは、舌端から発せられる言語が、どう見てもあきらかな勘違いであるにもかかわらず、そのアバンギャルドな感性と、実にもうお茶目としかいいようのないナイスな人柄でもって周囲をうならせ、反撃の余地すら与えぬままねじり倒してしまうところにあるのであります。 以下に記すのは我々の仲間内の会話の中で本当にあった（と伝えられる=伝道者はこのひと）フラノの「伝説の勘違い語録」である。 ［解説］ ウソのようなはなしだが「大ドンブリ」といって議員さんが指さしたのはなんと「オードブル」であった。 信じられないでしょうが、以下に列挙する秀逸な勘違いは、神に誓ってS氏ただ一人の舌端から発せられたものであり、いっさいの脚色がなされていないことを申し添えておきます。 が、「重箱」という高級なものではなく、あえて「弁当箱」という庶民的なものを使って表現したところに、彼の類い希なる感性が見て取れるのであります。 「弁当箱の隅」のほうが、いかにも細かいところをチクチクほじくっているせこい感じが出ていて、表現としてはこちらのほうが上なのではないかとさえ思うのであります。 一見すると「な〜んのこっちゃ」という感じでありますが、実はこの言葉には「二兎を追うもの一兎も得ず」と言う意味が言外に秘められているわけで、「二足の草鞋をはけば、二兎を追うもの-になってしまうんだよ」という尊い教えが暗喩された奥深い表現になっているのであります。 どう考えても聞き違いのような気がするが、確かに言ったと某センパイは主張する。本当だとすると、これは見事な造語といえる。 「セックス琢磨」-一生懸命がんばろうとする気合いがぐいぐい伝わってくる、力感あふれることばではないですか。 ［解説］ 赤ちゃんにプレゼントするのでもなければ、寝たきりのお年寄りへのプレゼントでもない。うら若き女性に対するプレゼントなのである。 「まったくあいつときたら、いつもNさんにくっついて歩いて、まるでNさんのいそぎんちゃくだもなあ」 が、いそぎんちゃくをくっつけて歩いているという絵づらはなかなかシュールだし、すっとぼけた感じで私は大好きです。 「なんでこんな寒い時期にウエットスーツを？？」と思っていたら、な〜んだ、彼が本当に欲しかったのは、スエットの上下なのでした。 でも 「破竹の勢い」より、こちらのほうが、けものたちが一斉にどっと走り出している様がイメージできて、見たこともない「破竹」よりずっとわかりやすいと私は思う。 「ウワサは恐いよなー。隠そうったってすぐみんなに知れ渡ってしまうモンなー。やっぱり、人の口に角は立てられないよなー」 「八戸港争奪！ 輝け！地引き網による、すけそうだら漁獲高ナンバーワン！」ってな沿岸漁業的シーンが浮かんできますね。 いつも曖昧なままに言葉を記憶するのではなく、しっかり辞書で確かめてから覚えるくせをつけるよう心がけたいものです。 もちろん彼が云いたかったのは「俺たちに限界などない」という勇ましい思いではなく、「もうこんなアホなこと意味がないからやめようよ」という後ろ向きの思いなのであります。 もしかすると、S氏、「メリットシャンプー」のことも「リミットシャンプー」と思いこんでたりして。 ね？なかなかでしょう？ 実は他にもまだまだ沢山のネタがあって、それだけで一冊の本ができそうなくらいなのでありますが、本人の名誉のために、今日はこのくらいで許してあげます。（もう充分だって） それにしてもこれだけの珠玉の勘違いが、ただ一人某氏の舌端から発せられたなんて信じられます？しかも、勘違いの中身がすごい。オリジナル言語を超えるするどい語感と豊かな想像力。勘違いと片づけてしまうにはあまりにも惜しい、巧妙にして絶妙なる造語感覚。いや、これはもうほとんど「天才」といっても過言ではないのであります。 |
[ 107] 爆笑！勘違い語録
[引用サイト] http://www.furano.ne.jp/saladhouse/html/kanchigai.html
|
特に技術的な内容の勘違いは、自分一人ではなかなか気づかないもので、 あるとき先輩に指摘してもらったり、別件のことを詳しく調べてたりするときにふと発見することが多いでしょう。 本記事では、そのような自分一人では気づきにくい技術的な内容の勘違いを、オブジェクトの広場編集員の実体験に基づいて集めてみました。 オブジェクト指向に関係する技術的な内容の勘違いとして、大きく 「オブジェクト指向開発における勘違い」、「UML の表記における勘違い」の 2 つに分類しています。 また、番外編として「日常生活における勘違い」も集めてみました。技術的な内容に疲れたときにでもお楽しみください。 なお、取り上げた勘違いの中には、まだ勘違いしているところもあるかと思います。もし、その点をお気づきになられた方はオブジェクトの広場編集部 oosquare-editor@ogis-ri.co.jp UML の表記法を覚えてから、クラス図やユースケース図を描くことでモデリングが全て完成するような気になっていました。確かに、複雑なドメインや要求を図示化することで、情報が整理されとてもわかりやすくなります。しかし、図は概要をつかむのには良いのですが、図だけでは表しきれない情報や、テキストで書いた方が簡単にかつ正確に表せる情報もあることに、最近気がついてきました。 例えば、ユースケース図は、システムに参加するアクターと機能要求の一覧を概観するには良いのですが、実際にアクターがシステムにどう関わるかを記述したテキストの方が、実は重要だとよく言われます。 また、クラス図も登場する概念の整理に大いに役立ちますが、クラスの定義や重要な制約を書き忘れると思わぬ誤解を生んでしまうことがあります。図で表しきれない重要な情報はテキストで補足することも大切なんですね。実は UML の仕様にも、図の描き方だけでなく、OCL (Object Constraint Language) というテキスト形式の言語も定義されています。 図とテキストを上手に使って、これからもわかりやすく正確なモデルを作る努力を続けていきたいと思います。 UML や RUP を学び始めた頃は、要求といえばユースケースモデルやユースケース記述が重要で、パフォーマンス要求やユーザビリティなどの機能外要求はおまけぐらいの感覚でした。実際のプロジェクトではユースケースと同じくらいかそれ以上に機能外要求は重要だ、ということを少ししてから気づきました。 なぜ誤解に陥ったかというと、ユースケースを重視し、機能外要求を軽視している UML と RUP だけを基準にしてソフトウェア開発を行ったからです。 UML では機能外要求を定義することができません。なぜなら、みなさんもご存知のように UML には要求をとらえる概念として、ユースケースしかないからです。これは明らかに UML の仕様の不備です。そして、残念ながら UML 2.0 でも改善される様子はありません。Usecase の上位概念として Requirement を追加すればよかったのに、と悔やまれる毎日です。 RUP は、機能外要求を定義することはできるものの、ユースケースと比べて、明らかに軽視されている傾向にあります。RUP は、ユースケース駆動というコンセプトから分かるように、ユースケースをもとに計画を立て、開発を進めるプロセスとなっています。機能外要求を記述する「補足仕様書」はありますが、機能外要求をどう記述したらよいか、機能外要求がプロセスをどのように駆動するのかあいまいです。 一つ目として、機能外要求をテストできるため、ソフトウェアがお客様と合意した要求を満たしていることを保障できることが挙げられます。あいまいに機能外要求を定義し、お客様と合意が取れていないまま開発が進んでしまうと、受け入れテストの段階になって、「こんなもんじゃ使えない！作り直せ！」とお客様から言われてしまうかもしれません。 二つ目として、ソフトウェアアーキテクチャの開発の目的が明確になることが挙げられます。機能外要求は、すべてのユースケース（または、大部分のユースケース）に共通して適用される要求か、ユースケースにまったく依存しない要求です。どちらの場合にもソフトウェアアーキテクチャが機能外要求を達成するための基盤になります。 機能外要求を識別するフレームワークとしては、FURPS や ISO9126 の品質特性がありますが、私は ISO9126 を好んで使っています。ISO9126 の方が機能外要求を詳細に分類しており、また抜け漏れがないからです。 ある企業で販売店と顧客、従業員の情報を管理したいとします。同一人物がある販売店の従業員であったり、複数の販売店の顧客である場合を想定します。まずはこんなクラス図が描けました。 ところで、モデリングに慣れてくると、「顧客も従業員も人の役割に過ぎないよなぁ。どちらも同じ属性を持っているし。」と考えて、以下のようなクラス図を描きたくなったりしませんか? 実際、同一人物なら、名前も住所も電話番号も同じはずですよね。とてもすっきりしたモデルになりました。 ところがところが、実際の開発でこのモデルを使おうとするとうまくいかないんですね。顧客情報の登録依頼、変更依頼は各販売店が受付けて管理します。上のモデルではどこか1つの販売店で例えば住所の変更を行うと、顧客や他の販売店の知らないところで、他の販売店の顧客情報も書き換わってしまいます。顧客との間に情報の一括管理を行うという契約があるなら問題ありませんが、個人情報の管理に厳しくなってきた昨今では充分注意する必要がありそうです。 また、ある顧客とある顧客が同一人物かどうかの判定は実は難しいことが多く、同一人物と思っていたら実は別の人だったり、その逆の場合もあったりするようです。年金手帳も二重交付されるくらいですから。 ということで結局、あまりきれいではありませんが、以下のように販売店ごとに顧客、従業員の属性を管理するモデルにする場合が多くなってしまいます。 モデリングでは、単に現実世界を忠実に再現するだけではなく、その情報を認識し必要としている人の視点も考慮しないといけません。いや、「われ思う、ゆえにわれあり」とデカルトが言うように、本当は現実世界の私も認識している私がいるからこそ存在するのかもしれませんね。 システムそのものの状態をモデリングしたいと思うことはありませんか。例えばシステムの運用に関係した状態（開局中、閉局中など）やその遷移が複雑な場合には、これを整理するためにモデリングする必要があります。このような場合には、システムの最上位のパッケージ（例えば、jp::co::ogis_ri::xxxsystem パッケージ）に状態を定義しステートチャート図を作成していました。しかし、これは UML の仕様からすると誤った使い方で、正しくはパッケージの下位概念であるサブシステムを使うことが正しいようです。 UML の仕様では、分類子（ Classifier ：クラスやコンポーネントの上位概念）と振る舞い特性（ BehavioralFeature ： 操作やメソッドの上位概念）にしか 状態機械（ StateMachine ：状態や状態遷移を定義する概念）を定義できないことになっています。パッケージ（ Package ）は分類子でも振る舞い特性でもないため、状態機械を定義できません。 サブシステム（ Subsystem ）は分類子の下位概念でもあるため、ありがたいことに状態機械を定義できます。 そもそも、パッケージとは UML のモデル要素をグルーピングする仕組みであり、状態を定義するための仕組みではありません。 それに対し、サブシステムはパッケージと分類子、両方の特徴を併せ持つ万能選手で、クラスやパッケージなどのモデル要素をグルーピングする仕組みに加えて、クラスやコンポーネントと同じように操作も状態も定義できれば、インタフェースを実装することもできます。 みなさんも、システムそのものについてモデリングしたい場合は（状態に限らず！）、サブシステムを使ってはいかがでしょうか。 ただし、UML 2.0 では、サブシステムがコンポーネントのステレオタイプの一つとして扱われるようなので、いずれ UML 2.0 が普及したあかつきにはコンポーネントをメインに使うようになるでしょう。 オブジェクト指向について習い始めたとき、クラスとインスタンス、オブジェクトという3つの言葉の使い方に翻弄されたことを覚えています。 原因は教科書によって、インスタンスのことをオブジェクトと書いていたり、クラスのことをオブジェクトと書いていたりすることがあったからです。どちらかというと、インスタンスとオブジェクトが同義語として説明している教科書が私が読んだ書物の中では多数を占めていたため、 という関係が正しい関係だと思っていました。実際は、オブジェクト指向ではクラスとインスタンスを含めてオブジェクトというのが正解らしいです。 ただし、インスタンスのことをオブジェクトと言ってもだいたいの相手には伝わるので「オブジェクトはインスタンスである」としていいのでしょう。 一方 Java のインターフェースは、抽象メソッド だけでなく 定数フィールド も持てます。 UML から Java コードへ単純にマッピングをしている限りは気付かない、小さな違いです。 通常の業務範囲では、この違いに悩まされることは少ないと思いますが、UML と Java は必ずしも綺麗に対応するものではないことを、しみじみ実感できる一例ではないでしょうか。 既に Java の可視性を知っていた私は、UML でも同様の概念がある、と聞いた時点で「ああ、Java と同じなんだな。」と勝手に決め付けてしまって、それ以上先の説明を真剣に聞かなかったのです。 それから月日が経過すること 3 年。つい最近になって先輩から、protected に関しては スコープが異なることを教えて頂きました。 Java の場合、「自分とそのサブクラス、および同一パッケージからアクセス可能」と定義されていますが、UML では、「自分とそのサブクラスからのみアクセス可能」だったのです。幸い、これまでのところ、この勘違いで災いを招いたことはありませんでしたが、新しいことを学ぶ時には真摯に取り組まねばならないな、と改めて思いしらされました。 実は、拡張関係は振る舞いの拡張を表現する場合、汎化はユースケースのバリエーションを表現する場合に使うものだった。 私は、ユースケースの拡張関係（extend）はユースケースの汎化と置き換えて使えるものだと思っていました。 オブジェクトの広場で記事を書く人は、記事をテキストで書いてから HTML 化を行い、レビューと修正を繰り返します。 記事の作成を支援するシステムとなると、簡単なタグと本文を打ち込むことでテキストを HTML に変換してくれるツールや、スペルチェックなどを行ってくれるツールなどが考えられます。 図 1 では、「オブジェクトの広場の記事を作成する」というユースケースに対して、「記事のスペルチェックを行う」という拡張ユースケースを定義しています。 図には表れていませんが、「オブジェクトの広場の記事を作成する」ユースケースに「記事の修正作業」という拡張点を定義します。 その拡張点に対して「記事のスペルチェックを行う」ユースケースの振る舞いを挿入してやることで、記事を書く人は、記事の修正作業を行う段階になると、「記事のスペルチェックを行う」ユースケースを利用することができます。 もう一つは、基底ユースケースを中断してユーザーが利用するサービスがたくさんある場合（「記事のスペルチェックを行う」というようなユースケースが複数考えられる場合）です。 拡張関係に対し、汎化関係は特定の形式や技術などに特化されたユースケースが複数存在する場合に使われます。 図 2 では、「目的地に移動する」するという目的に対して「車」「自転車」というバリエーションがあることを示しています。 ここまで、拡張と汎化の違いを見てきましたが、拡張関係は振る舞いを拡張したい場合、汎化関係はユースケースのバリエーションを表現したい場合に使用することがわかりました。 すでにお気づきの方もいるかもしれませんが、Java の extends を連想して拡張関係（extend）を継承と考えてしまったというわけです。 アリスター・コーバーン著『ユースケース実践ガイド―効果的なユースケースの書き方』（翔泳社、2001年） ジェームズ・ランボー, グラディ・ブーチ, イヴァー・ヤコブソン著『UML リファレンスマニュアル』（ピアソンエデュケーション、2002年） クラス名は違えど、図 1 や 図 2 のようなクラスを今までに描いたことはありませんか？ 図 1 のクラス A は、インタフェースであることを表しています。インタフェースであることを示すために、クラス名の上部に≪interface≫というステレオタイプを付けています。 図 2 のクラス B は、画面や外部インタフェース等に該当するバウンダリクラスであることを表しています。バウンダリクラスであることを示すために、クラス名の上部に ≪boundary≫ というステレオタイプを付けています。 厳密に言えば、この説明には誤りがあります。誤りの部分は、1 の「 ≪interface≫というステレオタイプを付けている」のところです。なぜなら、UML の仕様書 [1] に即すると、≪interface≫ は、ステレオタイプではなく、「キーワード」と呼ばれるからです。 UML を学びはじめた方は、≪ ≫ (ギュメと呼ばれる) を使って表記できるものは、すべてステレオタイプであると思っている方がほとんどでしょう。私自身もそうでした。しかし、UML の仕様書では、ギュメは、ステレオタイプとキーワードを表すのに使用されるようです。 ・・・すいません。私自身はその違いを正確に説明することができません。というのは、次のような理由があるからです。 UML の仕様書において、キーワードとステレオタイプに関係する用語として以下の用語が存在するが、それらが厳密に定義されない ただ、キーワードとステレオタイプの本質的な違いがわからないからといって、キーワードとステレオタイプを区別するための方法がないわけではありません。UML の仕様書の付録 A に掲載されている UML 標準要素(UML Standard Elements) を利用すれば区別することは可能です。これは、UML 標準要素に掲載されているものをステレオタイプとし、掲載されていないものをキーワードとして区別する方法 です。この方法で判断すると、UML 仕様書内においては（私が確認した範囲では)矛盾が発生していないので、UML の仕様書に沿って適切に区別することができるでしょう。 さて、私自身が何故このような勘違いをしていたかの原因を考えると、私が参照していた多くの UML の書籍に、ステレオタイプの説明として≪interface≫ が取り上げられていたことが大きいと思います。近くにある UML の書籍を手に取って、索引から ≪interface≫ か、ステレオタイプかのどちらかを調べてみてください。おそらく、ステレオタイプの説明として、≪interface≫ もちろん UML の書籍の中には、キーワードとスレテオタイプとを区別している書籍がないわけではありません。私が把握している範囲では、以下の書籍は区別しています。 しかし、これらの書籍の中でも微妙にキーワードとステレオタイプに該当するものが異なっているので、最終的には UML 仕様書 [1]を確認した方がよいですね。 ちなみに、私は、≪interface≫ はキーワードと呼ぶべきだと思っているわけではなく、今後もステレオタイプと呼んだ方が良いと思っています。キーワードとステレオタイプの違いを知っても利用者がモデ 『UML リファレンスマニュアル』（著者：ジェームス・ランボー氏、ほか／発行：ピアソン・エデュケーション） 図 1 と 図 2 は、それぞれ状態図の状態 （State）、アクティビティ図のアクション状態 (Action State) を表していますが、それぞれ表記が違うことを知ってましたか？ 私は、状態とアクション状態はどのダイアグラムに描くかの違いだけで、両方とも同じ「丸み付き四角形」で表記するものだと思っていました。 しかし、UML 1.5 の仕様書[1]では違うようです。UML の仕様書では以下のように定義されています。 UML モデリングツールによっては、状態とアクション状態を同じ形で書けたりするので、それが混乱のもとになっているのかもしれませんね。 ちなみに、アクション状態はアクティビティとも言われたりしますが、その呼び方は UML の仕様書には準拠していません。 みなさんは、アクティビティ図を記述する際にオブジェクトフローを定義したことはありませんか。オブジェクトフローとはアクション状態やサブアクティビティ状態のインプットやアウトプットとなるオブジェクトやその状態を定義するモデル要素です。私がこのモデル要素を知った当初は、オブジェクトという名がついているために、オブジェクト名と下線を記述する必要があると思っていました。実際に、一部のモデリングツールではオブジェクト名を記述できるようになっています。しかし、これは勘違いでした。 UML のノーテーションガイドでは、オブジェクトフローにはクラス名と状態名だけを記述するように示してあります。また、UML のメタモデルでは、オブジェクトフローは分類子（ Classifer ：クラスやコンポーネントの上位概念 ）としか関連づいていませんでした。 ちなみに、UML 1.5 では破線矢印と四角形の名称が明確になっていませんでしたが、UML 2.0 ではそこが明確になっています。 UML 2.0 では実線矢印（破線矢印は廃止された）のことをオブジェクトフローと呼び、四角形のことをオブジェクトノードと呼ぶようです。 C 言語のプリプロセッサや、Perl のコメントを記述するときなどに使う "#" 記号ですが、私は最近まで、これを音楽記号の♯（シャープ）だと思っていました。よく見れば、線の角度が違います。 "#" 記号は、番号記号（number sign）といって、通常は、数字を示すために使われます。日本でよく使う、"No." と同じ意味ですね。 音楽記号のシャープに似ていることから、誤読として広まったようです。"#" を「井桁（いげた）」と読む人も多いと思いますが、これは正しい呼び方です。 ちなみに、プッシュホンのボタンに印字してあるのは番号記号なので、「シャープ」と読むのは間違いということになります。でも、音声案内などで、「番号を入力したあと、シャープを押してください」といわれること、よくあります。 ブログとは日記風ウェブサイトの総称で、新しい情報発信のメディアとして注目されています。 HTMLの書き方を知らなくても簡単に内容を更新できたり、またその日記を見た人が簡単にコメントを書き込んだりできる環境が用意されているのが特徴です。 ブログを見ていると、一日分の日記の下に「トラックバックURL」が記述されているものがあります。 私は最初、特定の日の日記にリンクするためのURLだと思っていたのですが（ブログは日々更新されトップページがよくいれかわるため）、 つまり、ブログAで書かれたトラックバックURLを別のブログBで記述することで、Aに対して強制的にBへのリンクを張らせることができるのです。 Bさんは参考にしたブログAのトラックバックURLを「トラックバック先URL」に指定し、日記を登録する トラックバックURLの対象となるブログAの日記の末尾にブログBの日記の概略がコメントとして追加される（ブログB内へのリンクを含む）。 B側としては「あなたの書いた記事についてここでコメントしていますよ。」とブログA側にお知らせでき、ブログA側としては他のどのブログがこの日記を参照しているかわかることになります。 勿論、お互いのブログサービスがこの機構をサポートしていなければならないのですが、リンク「させる」というのが新しいと思いました。 実際に特許関連の業務（申請、審査、審判など）を行っているのは、特許庁で東京特許許可局ではありません。そもそも東京特許許可局なんていう局は存在しません。 特許庁では、特許を“許可”するという表現は使っていないので、東京特許許可局という言葉は、早口言葉のためにできた言葉のようです。 『イケメン』というなんとも奇妙な言葉がテレビでも聞かれるようになって久しいですが、この言葉、私はてっきりうまいラーメン屋や讃岐うどんブームに乗っかって生まれた言葉、すなわち『イケ麺』 → 『イケてる麺』 → 『おいしい麺』を指す言葉だと思っていました。 なので、テレビなんかで「この人はイケメンだ」みたいに人に対して使っているのを聞くと、「ふ〜ん、この人の作る麺はそんなにうまいのかぁ」なんて思っていました。しかしこれはとんだ勘違いだったようです。 実際は、顔立ちの良い人に対して言う言葉で、『イケ面』 → 『イケてる面』 → 『かっこ良い顔』という意味だそうです。なお、主に男性に対して『かっこ良い』という意味で使うことから『イケmen』 → 『イケてる男性』 → 『かっこ良い男性』という意味もあるそうです。 ただし、『イケメン』という言葉が『かっこ良い男性』という意味であると、広辞苑に書かれているわけではありません（新語辞典には書かれていたりしますが・・・）。なので今のところは『イケメン』をどのように解釈し、どのように使おうが個人の自由だというわけです。 『イケメン』という言葉が妙に引っかかる、もしくは神経を逆撫でするという方（少なくとも私はそうなんですが）、『イケメン』はおいしい麺に巡り合った時に使うことにしませんか？ 『気のおけない仲』とは、余計な気を置かなくても良いという意味で、「遠慮しなくてもいい間柄。気遣いしなくてもいい間柄」を表す言葉だそうです。逆に『気のおける仲』とは、気を置かなくてはならないという意味で、「遠慮する間柄。気使いする間柄」を表す言葉だそうです。 私は、『気のおけない仲』を、「ある程度、気持ちを抑えて付き合わなければならない間柄」だと勘違いし、『気のおける仲』を、「素直に気持ちを出せる間柄」だと勘違いしていました。 ややもするとまったく正反対の意味で使ってしまうこのような言葉は、日本語には意外と多いものです。言葉の意味を正確に理解して使うようにしたいですね。 |
[ 108] オブジェクトの広場編集員が贈る勘違い集
[引用サイト] http://www.ogis-ri.co.jp/otc/hiroba/others/special/misunderstanding2004.html
