ブロックチェーン活用技術「mijin」のホームページ解説を読み解く（その１）
あけましておめでとうございます。今年のこちらはより一層技術（IT業界）ネタに絞って書いていこうと思いますのでよろしくお願いします（たまにセンシティブウェブネタとかはこっちに書くかも）。
さて、今年の個人的トレンドはこの「mijin」。ブロックチェーン技術が一般的な金融機関で活用されることには否定的な見解（例えばこれ）もありますし、最初に住信SBIネット銀行の話を聞いた時は「え？何に使うの」って思ったことは否めませんが、そんなことばかり言っていると色々取り残されてしまいそうなのでまずこいつらが何をしようとしているのか、というところは押さえていきたいですね。
ということで、非常に個人的スタディではありますが、mijinのホームページに書かれていることを読み解いていきたいと思います。
mijinとは？
そもそも、ブロックチェーン技術をBitCoinのような分散型の電子マネープラットフォームじゃない使い方をすることの目的はなんなのでしょうか。
mijinの名は、忍者の武器である「微塵」に由来します。3本の鎖に分銅がついたこの武器は、敵を「微塵」に打ち砕くことからそう名付けられました。
mijin | ブロックチェーン構築プラットフォーム
mijinは、既存のデータ管理インフラの常識とコスト構造を打ち砕きます。
ここに示されているように、目指すゴールはコスト削減のようです。ブロックチェーン技術は分散システムであり、ゼロダウンタイムシステムであるという特徴を活かすということでしょう。しかし、BitCoinに見る限り、このシステムはパブリックなネットワーク上で多くの計算機が膨大なCPUコストを消費した結果で維持されているように見えます。果たしてこれがコスト構造をどう打ち砕くのか。
プライベートブロックチェーン技術
mijinの特徴は、特定のネットワークに閉じたブロックチェーンの構築です。
ビットコインを代表とする、誰もがノードとして参加できるように公開されているブロックチェーンは「パブリック」であると言えます。それに対して、mijinはあなたが管理するネットワーク上で、指定したノードだけが参加することができる「プライベート」なブロックチェーン（Permissioned Blockchain）を構築するためのプラットフォームです。
http://mijin.io/about-mijin#
まあそれは原理上難しいことではないですよね。多分肝はブロックチェーンが必要とする計算量をプライベート上で確保することだと思うのですが、まだそこの話は読み取れません。というところで別の解説記事を引用。
加えて、ノード間のコンセンサス（同意）機構について、ノードの計算資源に依存した「proof of work」は採用せず、コイン保有量などに依存する「proof of stake」を採用する。プライベート型で利用する限りは、ビットコインのようなパブリック型チェーンと比べて悪意あるノードが入り込む余地が少なく、悪意あるノードを排除するため大量の計算資源を消費するproof of workは必要ないとの判断である。
［2］国内発ブロックチェーン「mijin」「Orb」の特徴を知る | 日経 xTECH（クロステック）
ふむふむ。つまり、参加するノード自体が信頼できる以上、信頼を担保するための膨大な計算量は必要ない仕組みで構築可能ということか。技術的な是非はともかく、理屈は通っているようですね。これはmijin（と元になったOSSであるNEM）の大きな特徴でしょう。
mijinの特徴
じゃあ、mijinそのものの特徴は何と喧伝されているのかを見てみましょう。
mijinで構築されたブロックチェーンは、以下のような特徴を兼ねそろえます。
http://mijin.io/about-mijin#
「消えない」
ブロックチェーン上に記録されたデータは、全てのノードを停止するまでは消えることがありません。
「改ざんできない」
公開鍵暗号技術にて署名されたデータは、第三者によって改ざんすることができません。
「ゼロダウンタイム」
ブロックチェーンでは、既存の「クライアント・サーバー」方式では不可能な「ゼロダウンタイム」を実現します。
ミッションクリティカルなトランザクションシステムにおけるパーマネントなデータ（あえてうざい言い方）に慣れ親しんでいる僕からすると「すべてのノードを停止するまで消えない」は「消える」に見えてしまいます。ブロックチェーンそのものはいわゆる「全取引履歴のデータベース」と言っても良いのでブロックチェーンが消えないかぎりはすべての取引履歴がそこにある＝資産の把握ができるということにはなります。なので、「全てのノードが停止することはない」ことが大前提です（これは物理的な分散化が必要ということ）。
また、「改ざんできない」という点についてはプライベート型であるという前提であれば若干微妙な気がします。「proof of stake」を採用するのはノードが信頼できるからであるため、署名されたデータが改ざんされないことは当たり前として、悪意のあるブロックチェーンが入り込むことはそもそも想定していないんじゃなかろうかと。既に認められたブロックチェーンを後から改ざんできないという意味であればわかる。とはいえ、完全にオープンでないシステムに悪意のある少量のシステムが紛れても大丈夫、くらいではありそうです。
そして「ゼロダウンタイム」こそがここで重要になる特徴ですね。前の2点についてはトランザクションシステムとしては絶対必要な機能要件的なものですが、ゼロダウンタイムというのは非機能の話であり、ミッションクリティカルなシステムのコストセンターであると言えます。必要数のノードがあれば機能するブロックチェーン技術においては、個々のサーバーの生き死にはあまり問題ではない＝サーバーが死んでも短期的には影響ないということをゼロダウンタイムと呼ぶのは妥当かとは思います。
さて、ここまでの話でだいたい見えてきたのはmijinが目指しているのは当然ながら「中央集権的な管理を必要としないシステム」「主体的に止めることを選択できないシステム」ではないということです。あくまでブロックチェーンという技術を応用して、管理されたシステムの中で高速化、インフラコストの効率化を図っていきましょうということですね。
mijinのやりたいことがだいたい見えてきたところで次回に続く。
広まる「FinTech」は誰を儲けさせるのか
ベニスの商人を例に出すまでもなく、金貸しというのは因果な商売であり、「固い職業」とみなされる銀行員ですら金を貸してもらう側からすると悪の権化に近いものであり、半沢直樹を読むまでもなく職業としての誇りだけが原動力な人が集まっているというのは幻想なわけですが、そう言った「悪い人たちが作り上げたシステム」を民衆の手に戻す的なニュアンスが「FinTech」を語る人たちから醸しだされることがよくあるようにも見える昨今です。
当然なんですけど、世界を変えるボランティアとして清廉な人々が集まってサービスを提供する、というわけではないので、こういう考え方は色々な部分を見誤る原因になりえます。善悪という話は置いとくとして、効率的か否かという話をすると確かに既存のシステムの非効率性を改善していくための技術を応用していくものとしてFinTechを捉えていくといいのではないかと考えています。
という意味ではやっぱり「無料」「匿名」キーワードは地雷が隠れていると思わざるを得なくて、結局誰が何をどう収益化するのか、というところをきっちりウォッチしていないといかんのだろうな、と思うわけです。
BitCoinは先行者利益＆犯罪者ネットワークというところから始まって一通り成熟したところでなんとか社会の枠にはまるかどうかという所まで来ているようなもので、綱渡りを渡りきった感はあります（途中で何人か転落死しているけど…）。
決済サービス系のFinTechとデータ利用系のFinTechは根本的なカテゴリーが違うと思っているんですが、最近良く持ち上げられるのがMoneyFowardというところにこのワードの難しさがあるんだなあと思っていますが、ようやく最近ビットチェーンをシステムに応用するとかそういうのが本格的に見え始めたんだけど、これも本質的にはトランザクションシステムの形であって「Fin」の部分は本当に必要なの？と今のところ思っていたりもします。
融資系の話は難しくて、信用評価ってのはいかに幻想を打ち破るかという話だったりもするので、「行けそうに見える」だけの砂上の楼閣案件に素人が投資することを避け得るのか的な部分もあって結局リスクを広く薄く負担しましょうテクノロジーなだけなんじゃないかと思ったりもしますが、それで救われる人もいるんだろうな、というところが難しいわけで。
いずれにしても、サービスを考える側の人たちはともかくとして、利用する側の人たちは「信用とリスク」というのを自分で考えるか他人（主に金融機関や国）に委ねるのかという問題だ、という部分についてはよく考えて欲しいものです。
障害が出ると問題だという風潮
わかっている人はわかっているんだけど、特に新規システムの製造・テストにおいてはその開発プロセスのさなかで障害が出るのはアタリマエのことだ（とは言え、いつも比較される建築業のそれとは比べ物にならないパーツの精度はなんとかしたいものだが）。だから障害が出たら速やかに原因を調査し、問題を解消し、類似の問題がないかを調査して復旧する必要がある。あるんだけど、普段厳しい現場で保守ばっかりやっていると障害が出ることにある種の恐怖を覚えていて、結果として障害を出来るだけ隠蔽しようとするような風潮があったりする。
もちろん、上位者はそんなこと思ってなかったりするんだけど、下っ端から上がっていく途中の人たちが「なんで起きるんだ！！」みたいな態度をとると萎縮する。いやだって新規開発で障害でないとかないしー。
確かに、品質が悪い結果として障害が多発することもある。だから障害報告して怒られるってこともよくある。でもさ、もう成果物そこにあるわけじゃん。これ最終的には本番に行くわけじゃん。品質が悪ければ悪いほど早いタイミングで障害潰しておかないと大変なことになるわけじゃない。そこに対してなんで尻込みする必要あるのよ。
そりゃね、今まで何やってたんだって思われるってのはあるかもしれないよ。でも、たいていの失敗システムってのはこういう場面で障害の存在を隠蔽したり、隠蔽とまでは行かなくても誤魔化してみたりとかで正確な品質が分析できず、改善できない結果として起きるんだよね。障害は出て嬉しいものでは決してないけれども、出たことを可能な限り早く直視して対応していくことだけがシステムを完成に導くんだけどなあ。
システムの全容をどこまで把握すべきか
巨大なシステムやってて一番思うことは、「隣のプログラムが何やっているかすら知ろうとしない技術者が9割」ということです。これは愚痴です。役割分担が細かいのは良いんですが、仕様すらきっちり確認しようとしない。仕様ってのはそれがわかってないと作れないレベルのI/F仕様だったりするんだけど、誰がどこでどうその項目を設定するの？ということについて興味がなさすぎる。リーダークラスの人が知っててその人に聞けばいいや的な。
で、もうちょっと上のところに行くと、今度はI/Fしている隣のシステムの仕様はやっぱり興味ない。もちろん、I/F仕様どおりにデータが来れば問題ないんだけどさ、データのパターンとかそういう話ってざっくりとした仕様くらいは理解した上で、懸念される問題（あっては困るパターンとかが実際に発生しないかとか）をやり取りするのがシステム屋の仕事だと思うんだよね。
んで、そういうのを寄せ集めて作った巨大システムの仕様をなんとなくでも全体的に説明できる人って何人いるの？というともうホント数えるほどしかいないんだよね。
で、まともな人がこの話を聞くと、「いや、でも、適切な形でシステムが疎結合している場合、I/Fさえ擦り合っていればシステムって上手くいくよね」と思うわけですよ若干理想的な姿見ているとはしても。でもね、問題になっている仕様ってはシステム全体の基本アーキテクチャの話であって、そりゃ個別の業務（I/Fからすると項目設定仕様）についてはきちんと疎になっておりますよ。でも障害発生時の動き方であるとか、データ不整合が発生した時の後続影響とかそういうシステム全体が整合するための根本的な思想の部分が共有できてない結果として、正常な処理から一歩でも外れた時に起きる事故が大変な状態になるわけで…
障害は起こすものではなく起きるもの
読んだ。僕らの技術領域とはちょっと違う話だとは思うけど、基本は変わらないと思うので私見。
プロダクトチームの評価は、インフラチームやセキュリティチームに比べると、非常に分かりやすいです。 ダウンロード数、アクティブユーザ数、売上など、実際に起きたことを評価に使えます。
一方で、インフラチームやセキュリティチームの評価はディフェンダーの評価と同じように注意する必要があります。 ディフェンダーが良い状況判断でタックルをしなくても済ませているように、 この領域で良いエンジニアは重大な障害が起きる前に良い状況判断で障害の芽を摘み取っているのかもしれないわけです。
良いディフェンダーはタックルをしないし、良いエンジニアは障害対応をしない · takus's blog
障害の作りこみってプロダクトチーム側にも相当あると思うんですが（シュートすげー多いけど枠に行かないとか？）それはさておき、良いエンジニアは障害を起こさないと言うのは一つの真実ではあって、それでもなお起きるのが障害だと思うんですよね。なので障害を「解決する」能力はもちろん必要だし、障害が「起きないようにする」能力がそれによって磨かれていった結果障害起きねーなら不要みたいな評価をされるかというところが問題ですよね。この喩え話だと。
ただ、障害の芽を「摘み取っている」ならばその活動は具体的な行動に出るだろうし、そもそも障害が起きない堅牢なシステムを設計時にバチッと出来るかというと特にこういう話であれば急にアクセスが伸びて云々みたいな話は予想を超えた場合はやっぱりアドホックな「対応」になってくるだろうし、いずれにしても行動評価が出来る範疇なんじゃないかと思いますし、完璧（比喩）な設計を出来るエンジニアはそのスキルを次のプロダクトのインフラを作る仕事に回すべきだと思いますしね。
客先常駐はガンガン減らしていっておりますが
会社違えば認識違う、ということでツッコミ入れとく。
といっても、言及先が間違っているという話ではなく、色んな職場があるよって話
顧客先に常駐する、ってことは、顧客内のオフィスにおいてあなたの一挙手一頭足が全部見られているってこと。厳しいお客さんだとあくびや眠そうにしただけでクレームが入る。
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ
そういやよく「お疲れですね（ちょっと皮肉」って言われてましたけどクレーム入ったことないですね。客にもよるんだろうけど、目に見えて役に立っているとね。
自社の有給休暇を取得しようとしたら、「また休むんですか」とクレーム。
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ
これはない。労務管理は客先側も厳しい（もちろん客の会社の話でこっちには関係ないけど）から理解はある。もちろん客にもよ（ｒ
自社では服装自由だけど、顧客内ではスーツネクタイ着用。携帯電話もセキュリティ上取り上げられて勤務終了までロッカーへ。もうまるで奴隷のような不自由さです。
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ
こないだまでスーパークールビズでした。冬場はスーツでもいいし。あと携帯電話は一応セキュリティーフロア内では使わないルールではありますが、これは客先常駐だからじゃなくて、客先がそもそもセキュリティー的に厳しいことに客も我々も合わせているだけであって。
顧客側と外注側の一部の上位メンバーしか情報は共有されず、末端で働いていたらプログラミングや詳細設計など、細かい作業は回ってくるが、それは何のために必要なのか、なぜその設計になるのか、このモジュールはどんな業務にどう使われるのか？などはどうしても共有される順番が遅くなるか、まったくされないか、となります。
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ
はいプロジェクトがクソです。
少なくとも一部の上位メンバーには情報共有されているのであれば「客先常駐と持ち帰りの情報格差」は確実に埋まっています。そこから先がうまんねーのはプロジェクトの問題でしょ。
こうなると、誰のためにどういう立場で働いているのか、よくわからなくなってくるんですね。
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ
これはある。若者は特に。年取ってこれ言っている人はビジネスしたくないだけ。
といった具合に、上記で書いた通り常駐業務だと会社は確実に儲かるけど、社員側は心を確実にすり減らしやすいのです。
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ
これも嘘で、会社が確実に儲かるかどうかは契約による。客先常駐ってのは契約形態ではなくて契約の付加条項であって、委託であっても作業場所が客先ってことは（主にセキュリティーと打ち合わせの都合で）よくある。むしろ委託の客先常駐のほうがトラブっても追加の金も人も出なくて人が死ぬ。
事実、かるびの会社でも、自社で自社アプリや持ち帰りでの受託開発業務をやっている社員は、彼らが社内業務をやっているうちは、ここ5年程度見事に一人もやめていません。
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ
自社でも辞める奴は辞めるよ。辞める理由の一つに客先常駐だからということがあるのは否めないけど、だからと言って客先常駐じゃなければ辞めないなんてのはおかしい。
総体的にみて客先常駐での上手いプロジェクトの進め方がわかんねーだけなんじゃないかと思ったりしますけどね。あるいは会社の立場が弱すぎるか。
で、タイトルなんですが、そうは言っても客先常駐ってしないで済めばそれが一番なんですよね。社内の連携とかも取りづらくなるし、要員の配置の柔軟性も微妙。だからうちの会社もどんどん客先常駐の仕事を「自社にいながら客先常駐に準ずる」形にしようとしているし（実際かなりそうなっているし）。でも、一方で客先に常駐していると「直接関係ない（でも次のビジネスに繋がる）」情報が結構入ってきて（隣の会議室や喫煙室からとかｗ）、誰も居ないことは結構な機会損失になったりすることもあるのでビジネス的には全く客先にいなくなるのも結構問題なのでウェブ会議で済むことをわざわざ出向いて行ったりもします。客と雑談できねーってのも結構ダメなのよね。逆に客の文句を大声で言って発散してもバレないというメリットは有りますｗ
というわけで、客先常駐かどうかに関わらず、プロジェクトは強い心で健全に回すことに力を注ぎましょう。
客先常駐「が」悪いのかという問題ですよ
意図しない方向で盛り上がったので補足しておくことにします。
といっても、言及先が間違っているという話ではなく、色んな職場があるよって話
客先常駐はガンガン減らしていっておりますが - novtan別館
とか言いつつ主語の大きい部分については見解の相違じゃなくて単なる間違いだと思って批判はしております。でも大上段から全否定してないよね？
コメントから。
わたし 2015/11/07 13:35
冒頭に見解の違いと言っておきながら、嘘だのクソだのけなす論調はなんなのでしょうかね。
見解の違いじゃすまない部分だから。
su 2015/11/07 16:50
ブコメでも散々突っ込まれてるけどNOVTANってこんなバカだっけ。
流石に直接コメントするならもう少し具体的に書いてよ。
ブコメから。基本的に敬称略。批判っぽいのを拾ったつもりですが言及していない中で「俺も批判している！取り上げろ！」という物好きな方がいらっしゃったら教えて下さい。
id:onehiro
当たり客先を前提に話しても意味ない。はずれ引いた時に会社がどう対応してくれるか？が問題。はずれからすぐ撤退してくれるか、この人みたいに「そんなわけない。お前がうまくやれてないだけ」説教で終わるか
「そんなわけない」とは言っていない。僕の「ケースバイケースとは言えない」というレベルでの批判は以下三点のみ。
- PJT内で情報共有されないのはPJTがクソ（ただしPJTが糞な原因は必ずしもPJTの構成員のせいではないという点に関してはid:dbfireball氏のコメントの通り）
- 常駐業務だと会社が「確実に」儲かるというのは嘘。儲からないケースも有る
- 客先常駐じゃないとあたかも辞めないような書きっぷりだが実際には客先常駐じゃなくても人は普通に辞めていくので証拠としてはオカシイ
あとのところは客にもよるって書いているわけで…
で、当たり客先を前提にしても意味ないというのはハズレ客だった時にどうするかのソリューションの話だと思うし、業界として客先常駐止めようぜみたいなエントリの批判に対するコメントとしてはちょっと方向が違うんじゃないかと思いますが。会社がどう対応してくれるかはもちろん重大な問題だし、その点で言うと僕自身は前向きに会社を変えていこうとしている最中なわけですみんなも頑張れ（無理ならどうするかって話はまた別の話…
id:abcd0035 「違うとこもあるよ」って、そりゃそうでしょうに…元記事もすべての客先常駐がそうだとは言ってないでしょ
批判というか反対意見の部分だけみたらそうですね。でも元記事は客先常駐をこの世から葬り去りたい（とまでは言ってないか…）わけで、そういう点では上手くやったらメリットも有るぜ、という話ではあります。
id:brav0 元のエントリーは事実を語ってるのにこのエントリーは何故か真実を語ろうとするべく一つ一つに審議を下してる。意味あるのかね？
主語が大きいと事実が真実を語ってるみたいになっちゃうんですよ。そういう意味では元記事のほうが真実を語ろうとしていて僕は事実で反証を試みている部分があるだけです。で、別に事実を否定しているのではなくて、必ずしもそうではない（普遍的な真実ではない）と言っているだけですね。
id:taretareta 減らしてるねぇ。派遣法の改正で常駐は減らさざるを得ないんだから、さも会社の判断で減らしたように言うのもねぇ。
派遣法の改定で減るのは派遣の要件を満たさなくなる会社の要員の話であって、派遣じゃない客先のオフィスで一緒に仕事をしている「だけ」の業務または作業委託は別に減らないよ
id:xkxkxk 言いたいことは分かるが一個一個引用して揚げ足りするほどの内容とは思えない。なんか狂気を感じる。
取るに足らない内容のエントリはまあ世にあふれていると思いますが狂気に当てられなくなければ近づかないことをオススメします。
id:tea2ka 否定しないと自分が保てない人っているよね。 具体的に改善が出来る立場権限の人じゃないと何言っても変わらない？
これは難しいところで、そこに改善の気風があるかどうかとか、それこそ会社の文化とかそういったものに左右されがちです。客先常駐を単純に悪いと捉えるのは悪手だと僕は考えていますが、そこから脱却する手段が客先常駐を辞めるしか無いように見えるところもあるとは思います。
id:nacon 自分で目に見えて役に立ってるとか思ってる人ほど無能な事が多い
本当に多いの？
id:TTEST 引用しながら反論だけねぇ。自分は安全地帯から一方的に殴りつけて新たしい事を何も生み出してないクソ記事じゃねーか。
クソ記事はブコメしないほうが良いと思いますよ。
id:minaka_saikyo やはり美味しいところだけ摘んで否定しているというコメントが多いですね。俺もそう思った
冒頭述べたとおり、これ絶対違わね？というところをピックアップしているのでそりゃそうなりますね。
id:tdkn 不快感しか感じない記事
お目汚し失礼しました。NGリストにでも入れておくと良いと思います。
id:wasai プロジェクト次第だと思うけどなぁ。ちなみに自分の周りには元記事と同じ環境が多いですわ
思ってた以上にそういう環境が多いのは反響を見るとそうなんだろうなあと思いますわ。
id:ruka98 「マシ」以上の環境でしか業務経験ないんだろうなあ、という感想。ホワイト企業で勤めてる人がブラックの実情にピンとこないのと似てる
むしろトラブって家にも帰れないってプロジェクトって自社持ち帰り受託開発のほうが多かったんだよなあ…
id:white_rose 何の必要があってわざわざこんな記事を書くのかがわからない。そりゃ運良くホワイトな職場環境もあるでしょうけど。
客先常駐にもメリットはあるので、客先常駐という形態を改善するとしたら今僕がいる「運の良い」状態をスタンダードにするのも一つの策なんじゃないかなーとか思って書いているわけです。
id:misomico 会社的には必要な案件かもしれないが、常駐当事者はメンタル的・キャリア的に死ぬ。
死んでる人何人も見てきているから否定はしないけどね。
id:Lumin 元記事に対してなんの反論にもなっていない記事。１つ１つ論っているわりに現場によるとか言ってしまったらおしまいでしょ
冒頭述べたとおり、主語大きいですよってことについては否定できていると思うけど。
id:sinya77 プロジェクトは強い心で健全に回すことに力を注ぎましょう -> 今折れそう。やっぱ強い心が必要なんだね。
批判じゃないけど気になったので。もちろん強い心はいるんだけど、周囲の環境も合わせて総合的に考えた時に「やっぱ無理ｗｗｗ」な現場は少なからずありますし、無理なことは無理なので度を超えて無理しないことが大事だと思いますよ。
id:manaplus なんで言及しているのかわからん 中身空っぽだし
ブログ書くのに理由はいらないんだよ
で、改めて言っておくと、クソな客先常駐案件は撲滅したい、これは別に問題ない話。一方で、まともな客先常駐案件なんかは下手に持ち帰りにして客の目が行き届かなくなるととたんにプロジェクトが緩んで結果的に事故るなんてこともありがちな話。特にコミュニケーションの観点で言えばちょっと隣の島行って話しかければよかった確認とかが電話しなきゃならなくなって何回かけても捕まんねーまーいっか後でみたいなことから始まるコミュニケーションエラーが案外バカにできなかったりもします。まあ客がクソならどっちだろうが変わんないんだろうけど。
いずれにせよ、常駐案件はそういうメリットが必要じゃないとか十分別のやり方でカバーできるって場合は減らしたほうが良いとは思っていますし実際にそういう動きでここ2年位活動しています。
