第6章 コミュニケーション

ケータイのメールじゃないんだから、 何も考えずにただだらだら書き連ねるといったことはやめましょう。 ちゃんとした文を書き、単語の先頭はちゃんと大文字にして、 適切に段落分けをするようにしなければなりません。 これは、メールだけでなくその他のちゃんとした文書においても最も重要なことです。 IRC のようなその場限りのやりとりの場合は、 あまりそんなことを気にする必要はありません。 略語を使いまくったりしても大丈夫です。 しかし、正式な掲示板上などにはそんな習慣を持ち込まないでください。 メールやマニュアル、バグ報告などのように後に残ることが前提の文書については、 標準的な文法やスペルで書く必要があります。 また、きちんと構成されていなければなりません。 これは決して「とりあえず長いものには巻かれておけ」 とかいう類の話ではありません。ここで挙げた規則は、 単なるしきたりといったものではないのです。 文書を読みやすくするために進めてきた結果がこれなので、 できるだけそれを尊重するようにしましょう。 読みやすく書くようにする理由は、 他人が理解しやすくなるからというだけではありません。 そうすることで、あなたが「他人としっかりコミュニケートするつもりのある人だ」 と認められるようになるからという面もあります。

メールを書く際には、 オープンソース開発者の間で暗黙の了解となっている決まりごとがいくつかあります。

メールではプレーンテキストのみを使用し、 HTML やリッチテキストといった形式は避けましょう。 テキストにのみ対応したメールソフトでは、 他の形式のメールがうまく見えないことがあります。 また、半角 72 文字程度で改行を入れるようにしましょう。 1 行が 80 文字を超えてはいけません。 これ (80 文字) は、端末の画面上で 1 行に表示できる桁数の標準値です。 これより広い幅の端末を使っている人もいるでしょうが、 これより狭いものを使っている人はいません。 80 文字ぎりぎりではなくもう少し余裕を持って改行しておくことで、 返信時に引用符を追加しても改行位置を気にする必要がなくなります。

実際に改行すること。 メーラーによっては、メールの作成時にはいかにも改行しているように見せていても、 実際のメールでは改行されていないといったものもあります。 そのまま送信すると、あなたの意図したところに改行が入っていない状態の メールが送信されることになります。受け取った側の画面によっては、 改行の位置がおかしくなってしまうことでしょう。 もしあなたがそのようなメーラーを使っているのなら、 メール作成時に実際の改行を見せるような設定項目がないか探してみましょう。

画面の出力やコードの一部、その他フォーマット済みのテキストを記述する場合は、 はっきりとわかるように位置をずらしておきましょう。 どこからどこまでが地の文でどこからどこまでが引用なのかを明確にしておくことが大切です (本書を執筆しはじめた当初は、こんなことを説明するつもりはありませんでした。 しかしさまざまなオープンソース関連のメーリングリストを見ていくうちに、 さまざまな種類のテキストを区別せずごちゃごちゃにしている人があまりにも多いことに気づきました。 それはそれは非常に読みづらいものでした。 そのおかげで彼らの投稿の内容をつかみにくくなるだけでなく、 率直に言って彼らはちょっとだらしない人たちだなと感じました)。

他人のメールを引用して返信する際は、 適切な場所に返信内容を書くようにしましょう。 必要なら、いくつかの場所に分けて書くことになってもかまいません。 また、不要な部分は引用しないようにしましょう。 もしその投稿全体に対して一言コメントしたいのなら、 投稿の先頭 (つまり、あなたの返信を書いた後に メールの引用が続く形式) にそれを記述します。 それ以外の場合は、まず関連する箇所を引用したうえで、 その後に返信を書きます。

メールの件名はよく考えてつけるようにしましょう。 これは、メールの中でもっとも重要なものとなります。 というのも、プロジェクトの他のメンバーは そのメールを読むかどうかを件名で判断することになるからです。 いまどきのメールソフトは、関連するメッセージをスレッドにまとめる機能を持っています。 スレッドにまとめるための基準は、 件名が同じというだけではなくその他のヘッダの内容も使用します (このヘッダの内容は、表示されないこともあります)。 もしひとつのスレッド内で話題が変わるときは、 返信の際に件名を適切に変更することもできます (変更すべきです)。 その他のヘッダの内容によってスレッドの構成はそのまま保持されますが、 件名を変えておくと、そこで話題が変わったことがわかりやすくなります。 また、本当に新しい話題を始めたい場合は、新しいメールとして送信するようにします。 既存のメールに「返信」して件名だけを変えるというのではいけません。 さもないと、あなたの出したメールがスレッドに紛れ込んでしまいます。 これによる損失は、単に時間を浪費してしまうことだけではありません。 「コミュニケーションツールをうまく使いこなせる人」 というあなたの評判も落ちてしまいます。

きれいに体裁を整えたメールは読者の気を引くことでしょう。 しかし、実際に読んでもらうには中身が大切です。 「これさえ守れば中身のある内容を書ける」というようなルールはもちろんありません。 しかし、それに近づくための原則ならいくつかあげることができます。

読む人のことを考えて書くようにしましょう。 活発に活動しているオープンソースプロジェクトには、 さまざまな情報が付きまとっています。メールの読み手が、 それらの情報をすべて知っているものと期待してはいけません。 実際のところ、彼らはそんな情報など知ろうともしないこともあるものです。 可能な限り、読み手にとって便利な情報を提供するようにしましょう。 たとえば、ほんの数分時間を使うだけで、 メーリングリストのアーカイブで特定のスレッドを表す URL を調べることができます。 それを示すことで、読み手が同じことをする手間を省くことができるでしょう。 さらに 5 分から 10 分ほど余計に時間を割けば、 複雑になったスレッドの簡単なまとめを作成することもできるでしょう。 これは、あなたの投稿の背景にある話の流れを伝えるのに役立ちます。 こんな風に考えてみましょう。プロジェクトがうまくいけばいくほど、 メーリングリストや掲示板の書き手に対する読み手の比率が高くなります。 あなたの投稿する内容が n 人に読まれているとすると、 あなたがちょっと時間を使って作業をするだけで n 人ぶんの同じ時間を節約できるようになるわけです。n が大きくなればなるほど、この価値は向上します。 そしてあなたがそうしているのを見れば、他の人たちも同じようにしてくれるようになるでしょう。 その結果、プロジェクト全体の効率が向上することになります。n 人が苦労するのと一人が苦労するのとどちらがいいかといえば、後者でしょう。

物事を誇張しないようにしましょう。 オンラインの投稿では、話が大げさになりがちです。 たとえばバグを報告する人は、開発者たちの気を引くように わざと大げさに話すこともあります。ちょっと気になる点が見つかったときに 「この深刻な問題のおかげで、私 (そして友人や同僚や親戚一同) はまともにこのソフトウェアを使うことができない」 といった具合に報告するわけです。 しかし、この問題はユーザーからの報告に限ったことではありません。 プログラマーたちだって、技術的な議論をしているときに同じようなことをしています。 特に、どちらが正しいかという問題より 各自の好みにかかわるような問題を扱う際にその傾向があります。

もう少し控えめな言いかたにしたほうが、実際の気持ちは伝わりやすくなります。

誇大表現を完全になくすことは不可能でしょうし、また一般にそうする必要もありません。 他の誤解に比べると、誇大表現が及ぼす被害はそれほどでもありません。 主に書き手側が損をするだけのことです。 読み手側はそれを補正して読めるので、単に書き手が少し信頼性を失うというだけだからです。 プロジェクトにおけるあなたの影響力を考えると、 不要な誇大表現は避けるようにしておくべきです。 そうすると、あえてキツめに表現する必要が生じた場合に 周りの人たちにそれを受け入れてもらいやすくなります。

よく見直すようにしましょう。 ある程度以上の量の文章を書いた場合は、完成した文章を実際に送信する前に もう一度頭から読み直すようにします。作文の授業でも同じことを教わったかと思いますが、 これはオンラインの議論でも特に重要です。オンラインの議論は断続的なものになる傾向があるので (メッセージを書いている途中で過去のメールを読み直したり、何かのウェブページを確認したり、 何らかのコマンドを実行してデバッグ出力を取り込んだり、……)、ついつい論旨を見失いがちです。 断続的に書き上げたあとで一切チェックせずに送信したメッセージは、 読み手にもそのように受け取られてしまいがちです。 これは書き手にとってもうれしいことではありません。 きちんと時間をとって、書いた内容を見直すようにしましょう。 投稿内容がきちんとまとまっていればいるほど、 あなたのメッセージを読んでもらいやすくなるでしょう。

繰り返しメッセージを作成しているうちに、 おそらく自分の文面がかなり素っ気ないものになっていくことに気づくことでしょう。 これはほとんどの技術系フォーラムでありがちな話ですし、それ自体には特に問題はありません。 一般社会でのコミュニケーションではありえないような素っ気無いやり取りが、 フリーソフトウェアのハッカーたちの間ではごく普通なのです。以下に引用するのは、 とあるコンテンツ管理ソフトのメーリングリストにかつて私が投稿したときに 受け取った返信です。

どんな問題が発生したのか、もうちょっと詳しく正確に説明してくれませんか？

それから。

お使いの Slash のバージョンは何ですか？
元の投稿からはそれを読み取ることができませんでした。

apache/mod_perl のソースをビルドした手順を正確に教えてください。

slashcode.com に投稿された Apache 2.0 のパッチを試してみましたか？

  Shane

まさに簡潔そのものです！ 挨拶もなければ署名は自分の名前だけ。 そしてメッセージの本文はと言えば 一連の質問事項を可能な限り簡潔に並べただけ。 唯一あった質問以外の文はといえば、私の元の投稿に対する間接的な批判でした。 しかし、私は Shane のメールを見て気を悪くすることはありませんでした。 彼の素っ気ない返答を見ても「ああ、忙しい人なんだろうな」 というくらいのことしか思わなかったのです。 彼は私の投稿を無視することもできたのに、あえて質問を返してきたのです。 つまりこれは、彼が私の問題を解決するために時間を割いてくれているということを意味します。

すべての読み手がこのように好意的に受け取ることができるでしょうか？ 必ずしもそうではないでしょう。それはその人や状況によります。 たとえば、ある人が自分の犯した間違い (おそらく彼女はバグを書いてしまったのでしょう) について説明する投稿をしたとしましょう。 これまでの経験から、あなたは彼女が気の小さい人であることを知っています。 こんな場合は、もちろん簡潔な返信を書くこともできますが 少しは彼女の気持ちを気にかけるようにしたほうがいいでしょう。 あなたの返信の大部分は、簡潔に技術者の視点で見た分析になるかもしれません。 かなり素っ気ないものになることもあるでしょう。そんな場合でも 「簡潔に書いているのは決して君を冷ややかな目で見ているからではないんだよ」 とわかるようなことを最後に何か示しておきましょう。 たとえば、バグを修正するためのアドバイスをひととおり忠告した後の締めの言葉として 「じゃ、がんばってね。<あなたの名前>より」といったことを書いておけば、 決してあなたに悪気があるわけじゃないことが伝わります。 あるいは、意図的に絵文字を使ってみたりして 相手に安心感を与えるという作戦も効果的です。

参加者がどう感じるかについていちいち気にするのを変に感じるかもしれません。 でも、ぶっちゃけた話、人の感情というものは生産性に大きな影響を及ぼします。 感情は他の意味でも重要ですが、あえて実益の範囲に的を絞ったとしても、 不満を感じている人はよいソフトウェアを書くことができないといえるでしょう。 しかし、電子メディアには多くの制約があるので、 人が何を感じているのかを知る手がかりを常に得られるとは限りません。 そこで、a) こんな場合に普通の人はどんなふうに感じるだろうか？ b) 過去のやりとりから、この人はどんな人物だと考えられるだろうか？ といった内容をもとに経験から推測する必要がでてきます。 中にはもっと突き放した態度で、単純に額面通りの対応をすることを好む人もいます。 つまり、彼女が自分で「私、こう思うんです」と言わない限りは 決してそれに対する対応をしないというものです。 個人的にはこの方法はおすすめできません。それにはいくつかの理由があります。 まず、現実の世界ではみんなそんなことはしないでしょう？ 何でオンラインだとそうなるんですか？ もうひとつ。たいていのやりとりは公開の場所で行われるので、 たいていの人はプライベートな場所に比べて自分の感情を抑えがちになります。 もう少し正確に言うと、他人に対する感情 (感謝や怒りなど) は表現してもかまわないと考えているようですが、内心 (不安やプライドなど) は知られたくないようです。しかし、大半の人たちは 周囲の人が自分のことをよくわかってくれていると感じていればよい仕事をしてくれます。 ちょっとしたことを気にかけるだけで、状況をうまく判断できるようになります。 そして、今以上に人をやる気にさせることができるようになるのです。

もちろん、「プロジェクトのカウンセラーになれ」 「皆がうまくやっていけるよう常に手助けしてやれ」 と言いたいわけではありません。 しかし、皆がどのように振舞っているかを注意深く気にしていれば、 実際に面と向かって会ったことのない人でも どんな人なのかがなんとなくわかるようになるでしょう。 そして、自分が何か書くときの口調に気を使うようにすれば、 あなたに対する周りの印象は驚くほどよくなります。 これは、プロジェクト全体にとってもよいことです。

オープンソース文化の特性のひとつに、 何が失礼で何が失礼でないかということに関する独特の基準があります。 以下で説明する内容は、ソフトウェア開発やソフトウェア全般に特有のものではありません (数学や自然科学、工学にかかわっている人たちならおなじみのものでしょう)。 しかし、フリーソフトウェアの世界は人材の出入りが頻繁に行われ、 新しい人たちが常に流入してきます。 こういう考え方になじみのない人たちが流入してくることも大いにありえるでしょう。

まずは、失礼では ない ことについて説明します。

技術的な批評については、 たとえそれが直接的で歯に衣着せぬものであっても失礼にはあたりません。 実際のところ、逆にそれはほめ言葉ともとれるかもしれません。 批評するということは、 それが時間をかけて真剣に議論する価値があるものだと暗に認めているわけです。 そして、それがうまく成長すると、批判よりも賞賛のほうが多くなってくるわけです (もちろん、その批評が個人攻撃に成り下がってしまったり その他の明らかに失礼な内容になってしまうこともありえます)。

ぶっきらぼうで素っ気ない質問、たとえば先ほど引用した Shane のメールのような質問は失礼にはあたりません。 状況によってはちょっと非情に見えたり馬鹿にしているように感じられるような質問であっても、 それは真剣になされたものであり、 必要な情報をできるだけ手早く引き出したいという以外に隠された意図はありません。 サポートセンターの有名な質問である「コンピュータのコンセントはちゃんとささっていますか？」 というのは典型的な例です。サポート係の人は、 ただ単にコンセントがささっているかどうかを知りたいだけです。 仕事を始めたばかりのころはこの質問の前にいちいち丁寧な前置き ("すみませんが、いくつかの可能性を排除するために少々質問させていただいてよろしいでしょうか？ 中には基本的すぎるものもありますが、我慢してくださいね……") をしていたのでしょうが、それにも疲れてきたのでしょう。 今や、彼女は単刀直入に「ささっているのかいないのか」を聞くだけになっています。 フリーソフトウェアのメーリングリストでも、同様の質問が散々行われています。 これは決して相手を侮辱しているのではありません。 最も明らかな (そしておそらく最もありがちな) 可能性をできるだけ早い段階で排除しておきたいというだけのものなのです。 それをよくわかっている人は、文句も言わずにその質問に従い、 よりよい結果を得ることになります。 しかし、もし文句を言う人がいてもそれをけなしてはいけません。 これは、単なる文化の相違であり、どちらが悪いとかいうものではありません。 あなたの質問 (あるいは批評) には隠れた意味はまったくないということを説明してあげましょう。 単に情報を効率的に取得したかった (あるいは伝えたかった) だけであり、 それ以上でも以下でもないと言えばいいのです。

では、何が失礼にあたるのでしょう？

先ほど、技術的な批評をすることは一種のほめ言葉にあたると言いました。 その観点から言うと、真剣な批評をしないということは一種の侮辱になるかもしれません。 これは、誰かの作業 (何らかの提案やコードの変更、バグの報告など) を単に無視することを言っているのではありません。 あとできちんと返事をすると約束したのでない限り、 何も反応しなくても一向に問題はありません。 周りの人も、単に何か言うだけの時間がなかったんだとみなしてくれるでしょう。 しかし、もし何か反応を返すのなら、決して手抜きをしてはいけません。 時間をかけてしっかり分析し、必要なら適切なサンプルを用意し、 過去ログのアーカイブから関連する議論を探すといった作業を欠かさないようにしましょう。 そんなことをしている時間はないが、でも一言だけいっておきたいという場合は、 メッセージの中に釈明をいれておきましょう ("これ、たしかバグとして報告されていたはずなんだけど、 今ちょっと探しているヒマがないんだ。ごめんね" といった具合に)。 大事なのは、文化的な基準があることを認識することです。 その基準は守ること。そしてもし守れない事情があるときは、 守れないことを認識していると知らせること。 いずれにせよ、基準が大切です。 この基準を守れなかった上にその理由も説明していないとなると、その話題 (そして関係者たち) に対して十分に時間をかけるだけの価値がないと考えているように思われてしまいます。 怠け者であると思われるよりも、 単に時間がないだけなんだということを率直に説明しておくほうがいいでしょう。

もちろんこれ以外にも失礼にあたることは多々あるでしょう。 しかしその多くはフリーソフトウェア開発に限ったものではありません。 一般常識の範囲で判断できるはずです。 もしまだご覧になっていないのなら、 2章さあ始めましょう の 「炎上を阻止する」 も参照してください。

人間の脳には、表情を認知するための領域があります。 通称は "fusiform face area" です。 その機能の大半は先天的なものであり、後から身につけるものではありません。 個々の人物を見分けるという技能は生き延びるためにきわめて重要なものなので、 専用の特別なハードウェアが発達してきたということだったのです。

インターネットを使用した共同作業は、心理学的にはちょっと奇妙なものといえるでしょう。 だって、緊密な連携をとっている相手のことを、 自然で直感的な方法では決して認識できないのですから。 たとえばどんな顔なのかもわからなければどんな声なのかもわからない、 そしてどんな背格好なのかもわからないといった具合です。 これを補うには、特定の スクリーンネーム を決めてあらゆる場所でそれを使用するように心がけましょう。 メールアドレスの先頭 (@ 記号より前) の部分や IRC のユーザー名、 リポジトリのコミッター名、バグ追跡システムのユーザー名などなど、 すべての場所でこのスクリーンネームを使用するようにします。 この名前が、オンラインでのあなたの "顔" となります。 短い文字列で、実際の顔と同じ働きをさせるわけです。 残念ながら私たちの脳にはこれに直接反応するハードウェアは内蔵されていないわけですが。

スクリーンネームは、あなたの実名から直感的に得られるものにしましょう (たとえば私は "kfogel" にしています)。メールヘッダなど、 場合によっては実名を実際に表記することもあるでしょう。

From: "Karl Fogel" <kfogel@whateverdomain.com>

実際のところ、この例には 2 つの内容が存在します。 先ほど説明したように、スクリーンネームは実名と直感的に対応します。 しかし、実名は 実際の名前です。 つまり、これは次のような何らかの作り上げた名称とは異なります。

From: "Wonder Hacker" <wonderhacker@whateverdomain.com>

The New Yorker の 1993 年 7 月 5 日号に掲載された Paul Steiner の有名な漫画で、ある犬がコンピュータ端末にログインするというものがあります。 影の声がこう言います。"インターネット上では、誰も君が犬だなんて思わないだろう" この手のことを考える人たちの頭の中にはきっと「オンライン上での立場をよりよくしたい」 「オンライン上で有名になりたい」といった気持ちがあるのでしょう。 "Wonder Hacker" と名乗っておけば周りの人たちに 本当に 凄腕のハッカー (wonderful hacker) だと信じてもらえると思っているようです。 だけど事実は事実。たとえ誰も気づかなかったとしても、 君が犬であることには変わりありません。 オンラインで仮想人格を作り上げたところで、読者を感動させることはできません。 周りの人たちは、あなたのことを単なる夢想家かあるいは臆病者とみなすでしょう。 周囲とのやりとりには実名を使うようにしましょう。 もし何らかの理由で匿名でいたい場合は、 いかにも本名っぽいハンドルを作成してそれを使用するようにしましょう。

オンラインで一貫した "顔" を使用し続けることに加えて、 あなたをより認識してもらいやすくする方法がいくつかあります。 もしあなたが何らかの肩書き ("医師"、"教授"、"監督" など) を持っているのなら、 あまりそれを見せびらかさないようにしましょう。 また、直接それに関する話題になったときは別にして、 肩書きについて言及することも避けましょう。 ハッカー界、そして特にフリーソフトウェア文化においては、 肩書きに頼る人は排他的な臆病者とみなされます。 たとえばメールの最後に書く署名の一部として肩書きが登場するくらいなら問題ありません。 ただ、議論の際に自分の立場をよくするためにその肩書きを使うのは避けましょう。 間違いなくそれは裏目に出ます。 あなただって、肩書きなんかじゃなくあなた自身を認めてもらいたいでしょう？

メールの署名欄について補足します。 できるだけ小さくて上品なものにしておきましょう。 何なら署名なんてなくってもかまいません。 あらゆるメールの末尾に法的な注意書きをでかでかと掲載するようなことは避けましょう。 特に、フリーソフトウェアプロジェクトへの参加と両立しない意見を述べるようなときに、 これは致命的です。たとえば、私が参加している ある公開メーリングリストの参加者の中には、 すべての投稿の末尾にこんな様式の文書をつけてくる人がいます。

重要な通知:

あなたが誤ってこのメールを受け取ってしまったり、我々のメールに関する
免責条項の声明や監視ポリシーを読みたい場合は、以下の声明文を読むか、
このメールの送信者と連絡を取って下さい。

このメールでのやりとりは Deloitte & Touche LLP から発信されたもの
です。Deloitte & Touche LLP は 登録番号 OC303675 でイングランドと
ウェールズ地方に登録された有限事業組合です。組合のメンバーの名前は以下
の住所で閲覧可能です。Stonecutter Court,1 Stonecutter Street, London
 EC4A 4TR, United Kingdom. ここは組合の主たる営業所であり、登録済みの
事務所です。Deloitte & Touche LLP は、金融サービス機構(FSA) が認証
し、管轄しています。

このメールと添付された内容は秘密のものであり、閲覧に特別な許可が必要な
場合があります。これは送信者が意図した受信者のみが利用できます。仮にあ
なたがそうした人でない場合、このメールに含まれているやりとりや情報を開
示したり、コピーしたり、利用したりすることは強く禁じられており、違法行
為です。あなたが仮にこのメールを誤って受け取ったのであれば、"間違って受
けとりました" というタイトルをつけて IT.SECURITY.UK@deloitte.co.uk に返
送するとともに、このメールとそのコピーを破棄してください。

電子メールによるやりとりは、盗聴されたり、破損したり、改竄されたり、配
送の途中で失われたり、配送が遅延したり、中身が不完全な場合があったり、
コンピューターウイルスが含まれることがあるので、エラーがなく安全である
という保証がありません。私たちはこのような事態やそれが引き起こした結果
生じる不利益を受け入れることは出来ません。電子メールで私たちと連絡をと
りあう方々は、全員がこのリスクを受け入れているとみなされます。

私たちの顧客と連絡を取る場合、このメールと添付される内容に含まれるいか
なる意見やアドバイスも、Deloitte & Touche LLP 顧客契約書で示されて
いる諸条件によって制約を受けます。

私たちのビジネスに関係ない意見やアドバイス、その他の情報がこのメールに
記されている場合、それは私たちが発信したものでも、認めたものでもありま
せん。

たまに出てきてちょっと質問するだけという人がこんなことをするのだったら、 馬鹿らしいとは感じるかもしれませんがそれほどの害はないでしょう。 しかし、もしこの人物が本格的にプロジェクトに参加したいと言い出したらどうしましょう？ この法的文書がきっと問題になってくるでしょうね。 ここには、少なくともふたつの危険信号があります。 まず、この人物は自分のツールを完全にコントロールできるわけではないということ。 もしかしたら、社内のメールサーバが強制的にこのメッセージをメールに付加しており、 それを迂回する手段がないのかもしれません。そしてもうひとつは、 彼の所属する組織はフリーソフトウェア活動に関する理解がほとんど (あるいはまったく) ないということ。 もちろんこの組織はメーリングリストへの投稿を明確に禁止しているわけではありませんが、 彼の投稿は明らかに歓迎されざるものでしょう。 まるで、機密情報が外部にもれるリスクの回避が最優先されているようです。

「外向けのメールには必ずこういった文書をつけておけ」 というような決まりのある会社で働いている方は、 無料のメールアカウントを取得してそのアドレスでプロジェクトに参加することを検討しましょう。 無料のメールアカウントは、たとえば gmail.google.com や www.hotmail.com、そして www.yahoo.com などで取得できます。