UML の表記法を覚えてから、クラス図やユースケース図を描くことでモデリングが全て完成するような気になっていました。確かに、複雑なドメインや要求を図示化することで、情報が整理されとてもわかりやすくなります。しかし、図は概要をつかむのには良いのですが、図だけでは表しきれない情報や、テキストで書いた方が簡単にかつ正確に表せる情報もあることに、最近気がついてきました。
　例えば、ユースケース図は、システムに参加するアクターと機能要求の一覧を概観するには良いのですが、実際にアクターがシステムにどう関わるかを記述したテキストの方が、実は重要だとよく言われます。

　また、クラス図も登場する概念の整理に大いに役立ちますが、クラスの定義や重要な制約を書き忘れると思わぬ誤解を生んでしまうことがあります。図で表しきれない重要な情報はテキストで補足することも大切なんですね。実は UML の仕様にも、図の描き方だけでなく、OCL (Object Constraint Language) というテキスト形式の言語も定義されています。

　図とテキストを上手に使って、これからもわかりやすく正確なモデルを作る努力を続けていきたいと思います。

参考資料

1. 『ユースケース実践ガイド』（著者：アリスター・コーバーン氏／発行：翔泳社）
2. 『UML によるビジネスモデリング』（著者：エリクソン氏、ペンカー氏／発行：SOFTBANK）
3. 『UML 仕様書』（著者：Object Management Group／発行：ASCII）

　UML や RUP を学び始めた頃は、要求といえばユースケースモデルやユースケース記述が重要で、パフォーマンス要求やユーザビリティなどの機能外要求はおまけぐらいの感覚でした。実際のプロジェクトではユースケースと同じくらいかそれ以上に機能外要求は重要だ、ということを少ししてから気づきました。

　なぜ誤解に陥ったかというと、ユースケースを重視し、機能外要求を軽視している UML と RUP だけを基準にしてソフトウェア開発を行ったからです。
　UML　では機能外要求を定義することができません。なぜなら、みなさんもご存知のように UML には要求をとらえる概念として、ユースケースしかないからです。これは明らかに UML の仕様の不備です。そして、残念ながら UML 2.0 でも改善される様子はありません。Usecase の上位概念として Requirement を追加すればよかったのに、と悔やまれる毎日です。
　RUP は、機能外要求を定義することはできるものの、ユースケースと比べて、明らかに軽視されている傾向にあります。RUP は、ユースケース駆動というコンセプトから分かるように、ユースケースをもとに計画を立て、開発を進めるプロセスとなっています。機能外要求を記述する「補足仕様書」はありますが、機能外要求をどう記述したらよいか、機能外要求がプロセスをどのように駆動するのかあいまいです。

　では、機能外要求をちゃんと定義すると何がうれしいのでしょうか。
　一つ目として、機能外要求をテストできるため、ソフトウェアがお客様と合意した要求を満たしていることを保障できることが挙げられます。あいまいに機能外要求を定義し、お客様と合意が取れていないまま開発が進んでしまうと、受け入れテストの段階になって、「こんなもんじゃ使えない！作り直せ！」とお客様から言われてしまうかもしれません。
　二つ目として、ソフトウェアアーキテクチャの開発の目的が明確になることが挙げられます。機能外要求は、すべてのユースケース（または、大部分のユースケース）に共通して適用される要求か、ユースケースにまったく依存しない要求です。どちらの場合にもソフトウェアアーキテクチャが機能外要求を達成するための基盤になります。

　機能外要求を識別するフレームワークとしては、FURPS や ISO9126 の品質特性がありますが、私は ISO9126 を好んで使っています。ISO9126 の方が機能外要求を詳細に分類しており、また抜け漏れがないからです。

FURPS

• Functionality
• Usability
• Reliability
• Performance
• Supportability

ISO9126 の品質特性

利用時の品質

• 有効性
• 生産性
• 安全性
• 満足度

外部品質／内部品質

• 機能性（適切性、正確さ、相互運用性、セキュリティ、機能性関連適法性）
• 信頼性（成熟度、障害許容力、復元力、信頼性関連適法性）
• 使用性（理解のしやすさ、学習のしやすさ、魅力、使用性関連適法性）
• 効率性（時間挙動、資源の活用度、効率性関連適法性）
• 保守性（分析のしやすさ、可変性、安定性、試験容易性、保守性関連適法性）
• 可搬性（順応性、インストールのしやすさ、共存力、置換性、可搬性関連適法性）

参考資料

1. 『Practical Software Metrics for Project Management and Process Improvement』（著者：Robert Grady／発行：Prentice-Hall）
2. "ISO/IEC 9126 Software engineering - Product quality -"

　ある企業で販売店と顧客、従業員の情報を管理したいとします。同一人物がある販売店の従業員であったり、複数の販売店の顧客である場合を想定します。まずはこんなクラス図が描けました。

　ところで、モデリングに慣れてくると、「顧客も従業員も人の役割に過ぎないよなぁ。どちらも同じ属性を持っているし。」と考えて、以下のようなクラス図を描きたくなったりしませんか? 実際、同一人物なら、名前も住所も電話番号も同じはずですよね。とてもすっきりしたモデルになりました。

　ところがところが、実際の開発でこのモデルを使おうとするとうまくいかないんですね。顧客情報の登録依頼、変更依頼は各販売店が受付けて管理します。上のモデルではどこか1つの販売店で例えば住所の変更を行うと、顧客や他の販売店の知らないところで、他の販売店の顧客情報も書き換わってしまいます。顧客との間に情報の一括管理を行うという契約があるなら問題ありませんが、個人情報の管理に厳しくなってきた昨今では充分注意する必要がありそうです。
　また、ある顧客とある顧客が同一人物かどうかの判定は実は難しいことが多く、同一人物と思っていたら実は別の人だったり、その逆の場合もあったりするようです。年金手帳も二重交付されるくらいですから。
　ということで結局、あまりきれいではありませんが、以下のように販売店ごとに顧客、従業員の属性を管理するモデルにする場合が多くなってしまいます。

　モデリングでは、単に現実世界を忠実に再現するだけではなく、その情報を認識し必要としている人の視点も考慮しないといけません。いや、「われ思う、ゆえにわれあり」とデカルトが言うように、本当は現実世界の私も認識している私がいるからこそ存在するのかもしれませんね。

　システムそのものの状態をモデリングしたいと思うことはありませんか。例えばシステムの運用に関係した状態（開局中、閉局中など）やその遷移が複雑な場合には、これを整理するためにモデリングする必要があります。このような場合には、システムの最上位のパッケージ（例えば、jp::co::ogis_ri::xxxsystem パッケージ）に状態を定義しステートチャート図を作成していました。しかし、これは UML の仕様からすると誤った使い方で、正しくはパッケージの下位概念であるサブシステムを使うことが正しいようです。

　UML の仕様では、分類子（ Classifier ：クラスやコンポーネントの上位概念）と振る舞い特性（ BehavioralFeature ： 操作やメソッドの上位概念）にしか 状態機械（ StateMachine ：状態や状態遷移を定義する概念）を定義できないことになっています。パッケージ（ Package ）は分類子でも振る舞い特性でもないため、状態機械を定義できません。

　サブシステム（ Subsystem ）は分類子の下位概念でもあるため、ありがたいことに状態機械を定義できます。

　そもそも、パッケージとは UML のモデル要素をグルーピングする仕組みであり、状態を定義するための仕組みではありません。
　それに対し、サブシステムはパッケージと分類子、両方の特徴を併せ持つ万能選手で、クラスやパッケージなどのモデル要素をグルーピングする仕組みに加えて、クラスやコンポーネントと同じように操作も状態も定義できれば、インタフェースを実装することもできます。

　みなさんも、システムそのものについてモデリングしたい場合は（状態に限らず！）、サブシステムを使ってはいかがでしょうか。

　ただし、UML 2.0 では、サブシステムがコンポーネントのステレオタイプの一つとして扱われるようなので、いずれ UML 2.0 が普及したあかつきにはコンポーネントをメインに使うようになるでしょう。

参考資料

1. 『OMG Unified Modeling Language Specification Version 1.5』（formal/03-03-01)
2. 『UML 仕様書』（著者：Object Management Group 著／発行：ASCII）

オブジェクト指向について習い始めたとき、クラスとインスタンス、オブジェクトという3つの言葉の使い方に翻弄されたことを覚えています。

原因は教科書によって、インスタンスのことをオブジェクトと書いていたり、クラスのことをオブジェクトと書いていたりすることがあったからです。どちらかというと、インスタンスとオブジェクトが同義語として説明している教科書が私が読んだ書物の中では多数を占めていたため、

という関係が正しい関係だと思っていました。実際は、オブジェクト指向ではクラスとインスタンスを含めてオブジェクトというのが正解らしいです。

ただし、インスタンスのことをオブジェクトと言ってもだいたいの相手には伝わるので「オブジェクトはインスタンスである」としていいのでしょう。

参考URL

• @IT 連載：【改訂版】初歩のUML　第1回

UML のインターフェースは 操作 を持つだけであり、属性 は持てません。
一方 Java のインターフェースは、抽象メソッド だけでなく 定数フィールド も持てます。

UML から Java コードへ単純にマッピングをしている限りは気付かない、小さな違いです。
通常の業務範囲では、この違いに悩まされることは少ないと思いますが、UML と Java は必ずしも綺麗に対応するものではないことを、しみじみ実感できる一例ではないでしょうか。

ちなみに、修飾子を付けなくても、暗黙的に public static final となります。

// 以下、サンプルコード（TestInterface.java）
public interface TestInterface {

  int attributeA = 10;
  // 修飾子を付けなくても、自動的に public static final になる。
  // final なので、初期化しておかないとコンパイルエラー。
}

参考資料

1. 『OMG Unified Modeling Language Specification Version 1.5』（formal/03-03-01)
2. 『Java Language Specification Second Edition』

UML と Java の可視性は、以下のように一対一の対応関係にあるものと思い込んでいました。

既に Java の可視性を知っていた私は、UML でも同様の概念がある、と聞いた時点で「ああ、Java と同じなんだな。」と勝手に決め付けてしまって、それ以上先の説明を真剣に聞かなかったのです。

それから月日が経過すること 3 年。つい最近になって先輩から、protected に関しては スコープが異なることを教えて頂きました。

Java の場合、「自分とそのサブクラス、および同一パッケージからアクセス可能」と定義されていますが、UML では、「自分とそのサブクラスからのみアクセス可能」だったのです。幸い、これまでのところ、この勘違いで災いを招いたことはありませんでしたが、新しいことを学ぶ時には真摯に取り組まねばならないな、と改めて思いしらされました。

ユースケースの拡張関係と汎化関係の使い分けについて悩んだことはありませんか？

私は、ユースケースの拡張関係（extend）はユースケースの汎化と置き換えて使えるものだと思っていました。 実際には、両者には違った意味があります。これから、両者の違いを見ていきます。

まずは、拡張関係について説明します。 オブジェクトの広場の記事の作成を支援するシステムをイメージして、図 1 を参照してください。 オブジェクトの広場で記事を書く人は、記事をテキストで書いてから HTML 化を行い、レビューと修正を繰り返します。 記事の作成を支援するシステムとなると、簡単なタグと本文を打ち込むことでテキストを HTML に変換してくれるツールや、スペルチェックなどを行ってくれるツールなどが考えられます。
図 1 では、「オブジェクトの広場の記事を作成する」というユースケースに対して、「記事のスペルチェックを行う」という拡張ユースケースを定義しています。 ユースケースの拡張関係は「あるユースケースに別のユースケースの振る舞いを挿入する」場合に使います。 挿入する際の目印として、振る舞いを挿入される側に拡張点というものを宣言します。
記事を書く人は、記事を修正する段階に入ったらスペルチェックを行います。 図には表れていませんが、「オブジェクトの広場の記事を作成する」ユースケースに「記事の修正作業」という拡張点を定義します。 その拡張点に対して「記事のスペルチェックを行う」ユースケースの振る舞いを挿入してやることで、記事を書く人は、記事の修正作業を行う段階になると、「記事のスペルチェックを行う」ユースケースを利用することができます。

このように、拡張関係は振る舞いを「拡張」するために使われます。 拡張関係は乱用するとユースケース図がわかりにくくなります。 参考文献[1]では次の二つの場合以外では拡張関係を使用しないことを推奨しています。 一つは、既に確定されて変更できない場合。 もう一つは、基底ユースケースを中断してユーザーが利用するサービスがたくさんある場合（「記事のスペルチェックを行う」というようなユースケースが複数考えられる場合）です。

図 1 拡張の例

次に汎化関係です。 拡張関係に対し、汎化関係は特定の形式や技術などに特化されたユースケースが複数存在する場合に使われます。 図 2 では、「目的地に移動する」するという目的に対して「車」「自転車」というバリエーションがあることを示しています。

図 2 汎化の例

ここまで、拡張と汎化の違いを見てきましたが、拡張関係は振る舞いを拡張したい場合、汎化関係はユースケースのバリエーションを表現したい場合に使用することがわかりました。 さて、なぜこのような勘違いをしたのでしょうか。 両者は明らかに違うシーンで使われているので、なぜ勘違いしたのか首をかしげる方も多いと思います。 すでにお気づきの方もいるかもしれませんが、Java の extends を連想して拡張関係（extend）を継承と考えてしまったというわけです。

参考資料

1. アリスター・コーバーン著『ユースケース実践ガイド―効果的なユースケースの書き方』（翔泳社、2001年）
2. ジェームズ・ランボー, グラディ・ブーチ, イヴァー・ヤコブソン著『UML リファレンスマニュアル』（ピアソンエデュケーション、2002年）

クラス名は違えど、図 1 や 図 2 のようなクラスを今までに描いたことはありませんか？
また、そのときに、以下のような説明をしたことはありませんか？

図 1 インタフェース	図 2 バウンダリクラス

1. 図 1 のクラス A は、インタフェースであることを表しています。インタフェースであることを示すために、クラス名の上部に≪interface≫というステレオタイプを付けています。
2. 図 2 のクラス B は、画面や外部インタフェース等に該当するバウンダリクラスであることを表しています。バウンダリクラスであることを示すために、クラス名の上部に ≪boundary≫ というステレオタイプを付けています。

厳密に言えば、この説明には誤りがあります。誤りの部分は、1 の「 ≪interface≫というステレオタイプを付けている」のところです。なぜなら、UML の仕様書 [1] に即すると、≪interface≫ は、ステレオタイプではなく、「キーワード」と呼ばれるからです。

UML を学びはじめた方は、≪ ≫ (ギュメと呼ばれる) を使って表記できるものは、すべてステレオタイプであると思っている方がほとんどでしょう。私自身もそうでした。しかし、UML の仕様書では、ギュメは、ステレオタイプとキーワードを表すのに使用されるようです。

では、キーワードとステレオタイプの違いは何でしょうか？

・・・すいません。私自身はその違いを正確に説明することができません。というのは、次のような理由があるからです。

• UML の仕様書において、キーワードとステレオタイプに関係する用語として以下の用語が存在するが、それらが厳密に定義されない
  • キーワード文字列
  • ステレオタイプキーワード
  • ステレオタイプ名
• UML の仕様書内において上記の用語の使い方に一貫性がない

ただ、キーワードとステレオタイプの本質的な違いがわからないからといって、キーワードとステレオタイプを区別するための方法がないわけではありません。UML の仕様書の付録 A に掲載されている UML 標準要素(UML Standard Elements) を利用すれば区別することは可能です。これは、UML 標準要素に掲載されているものをステレオタイプとし、掲載されていないものをキーワードとして区別する方法 です。この方法で判断すると、UML 仕様書内においては（私が確認した範囲では)矛盾が発生していないので、UML の仕様書に沿って適切に区別することができるでしょう。

≪interface≫ 以外のキーワードとしては、何があるのでしょうか？ 以下に挙げてみました。キーワードという概念を私自身が知る前は、 これらすべてをステレオタイプと呼んでいました。

• ユースケース間の依存関係に付与される ≪include≫ と ≪extend≫
• 列挙型であることを表す ≪enumeration≫
• アクターを表す ≪actor≫
• クラス間の依存関係に付与される ≪bind≫ と ≪use≫
• などなど

さて、私自身が何故このような勘違いをしていたかの原因を考えると、私が参照していた多くの UML の書籍に、ステレオタイプの説明として≪interface≫ が取り上げられていたことが大きいと思います。近くにある UML の書籍を手に取って、索引から ≪interface≫ か、ステレオタイプかのどちらかを調べてみてください。おそらく、ステレオタイプの説明として、≪interface≫ が取り上げられていることでしょう。

もちろん UML の書籍の中には、キーワードとスレテオタイプとを区別している書籍がないわけではありません。私が把握している範囲では、以下の書籍は区別しています。

• UML リファレンスマニュアル [2]
• UML ユーザガイド [3]
• UML 仕様書 [4] (仕様書の翻訳だから当然ですね・・)

しかし、これらの書籍の中でも微妙にキーワードとステレオタイプに該当するものが異なっているので、最終的には UML 仕様書 [1]を確認した方がよいですね。

ちなみに、私は、≪interface≫ はキーワードと呼ぶべきだと思っているわけではなく、今後もステレオタイプと呼んだ方が良いと思っています。キーワードとステレオタイプの違いを知っても利用者がモデ リングする分には影響しないからです。また、使い分けると混乱のも とにもなりかねません。ただ、UML の仕様書に則して解説するときは、 キーワードとステレオタイプは使い分けてほしいとは思っています。

参考資料

1. 『OMG Unified Modeling Language Specification Version 1.5』（formal/03-03-01)
2. 『UML リファレンスマニュアル』（著者：ジェームス・ランボー氏、ほか／発行：ピアソン・エデュケーション）
3. 『UML ユーザガイド』（著者：グラディ・ブーチ氏／発行：ピアソン・エデュケーション）
4. 『UML 仕様書』（著者：Object Management Group 著／発行：ASCII）

図 1 と 図 2 は、それぞれ状態図の状態 （State）、アクティビティ図のアクション状態 (Action State) を表していますが、それぞれ表記が違うことを知ってましたか？

図 1 状態図の状態	図 2 アクティビティ図のアクション状態

私は、状態とアクション状態はどのダイアグラムに描くかの違いだけで、両方とも同じ「丸み付き四角形」で表記するものだと思っていました。
しかし、UML 1.5 の仕様書[1]では違うようです。UML の仕様書では以下のように定義されています。

• 状態 (State) : 丸み付き四角形 (a rectangle with rounded corners)
• アクション状態 (Action State) : 上下が直線で両端が円弧 (shape with straight top and bottom and with convex arcs on the two sides)

UML モデリングツールによっては、状態とアクション状態を同じ形で書けたりするので、それが混乱のもとになっているのかもしれませんね。
ちなみに、アクション状態はアクティビティとも言われたりしますが、その呼び方は UML の仕様書には準拠していません。

参考資料

1. 『OMG Unified Modeling Language Specification Version 1.5』（formal/03-03-01)
2. UMTP モデリング用語集

　みなさんは、アクティビティ図を記述する際にオブジェクトフローを定義したことはありませんか。オブジェクトフローとはアクション状態やサブアクティビティ状態のインプットやアウトプットとなるオブジェクトやその状態を定義するモデル要素です。私がこのモデル要素を知った当初は、オブジェクトという名がついているために、オブジェクト名と下線を記述する必要があると思っていました。実際に、一部のモデリングツールではオブジェクト名を記述できるようになっています。しかし、これは勘違いでした。

　UML のノーテーションガイドでは、オブジェクトフローにはクラス名と状態名だけを記述するように示してあります。また、UML のメタモデルでは、オブジェクトフローは分類子（ Classifer ：クラスやコンポーネントの上位概念 ）としか関連づいていませんでした。

　ちなみに、UML 1.5 では破線矢印と四角形の名称が明確になっていませんでしたが、UML 2.0 ではそこが明確になっています。
　UML 2.0 では実線矢印（破線矢印は廃止された）のことをオブジェクトフローと呼び、四角形のことをオブジェクトノードと呼ぶようです。

参考資料

1. 『OMG Unified Modeling Language Specification Version 1.5』（formal/03-03-01)
2. 『UML 2.0 Superstructure Specification』（ptc/03-08-02)
3. 『UML 仕様書』（著者：Object Management Group 著／発行：ASCII）

C 言語のプリプロセッサや、Perl のコメントを記述するときなどに使う "#" 記号ですが、私は最近まで、これを音楽記号の♯（シャープ）だと思っていました。よく見れば、線の角度が違います。

"#" 記号は、番号記号（number sign）といって、通常は、数字を示すために使われます。日本でよく使う、"No." と同じ意味ですね。
音楽記号のシャープに似ていることから、誤読として広まったようです。"#" を「井桁（いげた）」と読む人も多いと思いますが、これは正しい呼び方です。
また、アメリカでは、質量を表すポンドにも使われるそうです。

左がシャープ記号、右が番号記号

ちなみに、プッシュホンのボタンに印字してあるのは番号記号なので、「シャープ」と読むのは間違いということになります。
でも、音声案内などで、「番号を入力したあと、シャープを押してください」といわれること、よくあります。

最近TVCMなどで一気に有名になった感のあるブログ。
ブログとは日記風ウェブサイトの総称で、新しい情報発信のメディアとして注目されています。 HTMLの書き方を知らなくても簡単に内容を更新できたり、またその日記を見た人が簡単にコメントを書き込んだりできる環境が用意されているのが特徴です。

ブログを見ていると、一日分の日記の下に「トラックバックURL」が記述されているものがあります。 私は最初、特定の日の日記にリンクするためのURLだと思っていたのですが（ブログは日々更新されトップページがよくいれかわるため）、 それは勘違いでした。実際にはいわば「逆リンク」のようなものでした。

つまり、ブログAで書かれたトラックバックURLを別のブログBで記述することで、Aに対して強制的にBへのリンクを張らせることができるのです。

正確には、

1. Bさん(ブログBの作者)はブログAを参考にして日記を書く
2. Bさんは参考にしたブログAのトラックバックURLを「トラックバック先URL」に指定し、日記を登録する
3. トラックバックURLの対象となるブログAの日記の末尾にブログBの日記の概略がコメントとして追加される（ブログB内へのリンクを含む）。

となります。

B側としては「あなたの書いた記事についてここでコメントしていますよ。」とブログA側にお知らせでき、ブログA側としては他のどのブログがこの日記を参照しているかわかることになります。

勿論、お互いのブログサービスがこの機構をサポートしていなければならないのですが、リンク「させる」というのが新しいと思いました。

参考URL

• IT用語辞典 e-words:トラックバック
• IT用語辞典 e-words:ブログ

実際に特許関連の業務（申請、審査、審判など）を行っているのは、特許庁で東京特許許可局ではありません。そもそも東京特許許可局なんていう局は存在しません。

特許庁では、特許を“許可”するという表現は使っていないので、東京特許許可局という言葉は、早口言葉のためにできた言葉のようです。

ちなみに特許庁のホームページ https://www.jpo.go.jp/ はなぜか英語です。

『イケメン』というなんとも奇妙な言葉がテレビでも聞かれるようになって久しいですが、この言葉、私はてっきりうまいラーメン屋や讃岐うどんブームに乗っかって生まれた言葉、すなわち『イケ麺』 → 『イケてる麺』 → 『おいしい麺』を指す言葉だと思っていました。

なので、テレビなんかで「この人はイケメンだ」みたいに人に対して使っているのを聞くと、「ふ〜ん、この人の作る麺はそんなにうまいのかぁ」なんて思っていました。しかしこれはとんだ勘違いだったようです。

実際は、顔立ちの良い人に対して言う言葉で、『イケ面』 → 『イケてる面』 → 『かっこ良い顔』という意味だそうです。なお、主に男性に対して『かっこ良い』という意味で使うことから『イケmen』 → 『イケてる男性』 → 『かっこ良い男性』という意味もあるそうです。

ただし、『イケメン』という言葉が『かっこ良い男性』という意味であると、広辞苑に書かれているわけではありません（新語辞典には書かれていたりしますが・・・）。なので今のところは『イケメン』をどのように解釈し、どのように使おうが個人の自由だというわけです。

『イケメン』という言葉が妙に引っかかる、もしくは神経を逆撫でするという方（少なくとも私はそうなんですが）、『イケメン』はおいしい麺に巡り合った時に使うことにしませんか？

『気のおけない仲』とは、余計な気を置かなくても良いという意味で、「遠慮しなくてもいい間柄。気遣いしなくてもいい間柄」を表す言葉だそうです。逆に『気のおける仲』とは、気を置かなくてはならないという意味で、「遠慮する間柄。気使いする間柄」を表す言葉だそうです。

私は、『気のおけない仲』を、「ある程度、気持ちを抑えて付き合わなければならない間柄」だと勘違いし、『気のおける仲』を、「素直に気持ちを出せる間柄」だと勘違いしていました。

ややもするとまったく正反対の意味で使ってしまうこのような言葉は、日本語には意外と多いものです。言葉の意味を正確に理解して使うようにしたいですね。