GUIにおけるアイコンとは、プロダクトを触れるユーザーに対して、機能や動作を抽象化してシンプルかつ直感的に伝達させる、文字情報に頼らない記号です。

基本的に、記号が内包する意味には受け手によって解釈の余地があるような状態であってはなりません。しかし、ユーザーに対して、シンプルに正しい意味を伝えることが出来るという前提さえ踏まえれば、それを成すスタイリングは作り手やプロダクトによって様々な表現が可能な余地が残されています。

つまり、アイコンは、記号としての機能性に加えて、装飾としての役割も抱く、プロダクトGUIにおけるスタイリング定義の標本となり得るということです。

1. 前段

「Ameba」デザインシステム「Spindle」のデザインリードを担当している本田と申します。

以前、「CyberAgent Developers Blog」にて、「Spindle」の文脈で「『Ameba』15年の負債を払拭するカラーパレットのメソッド」という文章を執筆させていただきました。今回述べる内容はその続編という形になります。

また、先日5/28に開催されたイベント「CA BASE NEXT」においても、「Ameba」デザインシステムの文脈で本記事で解説するアイコンのロジックについても概要をお話しており(登壇動画「Amebaデザインシステム『Spindle』一貫性構築のための理論」)、本文書はその内容をより詳細に説明したものとなっております。

それ故、前述のブログや、登壇をご覧になった方には部分的に再掲内容となってしまいますが、まず「Ameba」というサービスについての概要を説明させて頂きたいと思います。

2. 「Ameba」について

「Ameba」は2021年に17年を迎える歴史あるサービスです。

プロダクトはPCブラウザ、SPブラウザ、ネイティブアプリと各種を運用しており、

「Ameba」の開発者はその歴史の長さに伴い、様々な負債や把握しきれない過去の形跡と向き合う必要がありました。

さらに、「Ameba」として目指すべきプロダクト像や指針が曖昧で、「Ameba」としてより良いもの、より「Amebaらしいプロダクト」にするためには何を成せばいいのか、という部分が曖昧模糊たる状況と化していました。

そこで開発が開始されたのが「Ameba」のデザインシステム「Spindle」です。

デザインシステムとはプロダクトの指針を定義し、一つの方向性にチームの意識や目的を集約するためのガイドラインの集合体を指します。

「Spindle」で「Ameba」は新たにビジョン、ミッション、コンセプト等を再定義していて、その中で自分は「Spindle」のデザインリードとして、定義された「Ameba像」を踏まえつつ、「Ameba」のプロダクトデザイン的側面における指針の定義とアウトプットに2020年から勤しむ事になりました。

今回取り上げたアイコンについての定義は、「Spindle」として「色」の定義の次に自分が執り行った、「Ameba」デザインシステムスタイリング定義第二弾となります。

3. 「Amebaらしい」アイコンとは何か

「Ameba」では、デザインシステムが作られる以前から、すでに200個程のアイコンが備わっており、各所UIに適用されていました。

Iconのデザインシステム開発にあたって、まずは「Spindle」開発以前に「Ameba」ですでに運用されていたアイコンについての現状と実態を把握する必要がありました。

開発ライン上でのIconの利用調査をした結果、「Ameba」の既存アイコンは、記号としての役割は基本的には満たしているようでしたが、大きく分けて3つの課題を持っていると考えられる状態にありました。

形状の一貫性と再現性

アイコンの形状は、過去に作られたアイコンの形を踏襲することを繰り返し、その数を増やしているように見受けられましたが、その実具体的なルールなどは特に存在せず、それが「Ameba」らしいアイコンであるか否かは新しいアイコンを制作する度にその製作者が独自に判断しているようでした。

「Ameba」でアイコンを制作するのは「Amebaデザイン室」と呼ばれるデザイナーチームですが、その規模は人数にして10名前後、各自の造形に対する意識を暗黙で統合するのには少々難しい人数規模となっています。

「Ameba」らしいアイコンの言語化も特に無く、再現性がなく、結果的に再解釈を生み続ける状態になり、一貫性が欠如することとなっていました。

命名規則

アイコンの命名は重要で、命名に規則がないと、検索性が悪化したり、一つのモチーフに対して複数の意味づけが行われる時に矛盾が発生したり、スタイリングの差分が作られる度に新しいルールのsuffixがつくようになるなど、その弊害は枚挙に暇がありません。

「Ameba」のアイコンの命名規則は概ね破綻こそしていないようでしたが、少しばかり矛盾を抱えているところがありました。

命名規則整備は効率的かつ道理の通ったデータアセットをもたらし、結果としてチームに対しての一貫性意識の構築にも繋がるので、是非整理したいところです。

ファイル形式

既存「Ameba」アイコンは全てアイコンフォント形式で作成されていました。

アイコンフォントは画像ではなく、フォントとして作られており、文字列としてHTMLやCSSでの加工が可能なアイコン形式です。

メリットも多くあるこの系式ですが、同時に多くの問題点もあります。

一つはアクセシビリティ上の問題。

アイコンフォントは元はフォントなので、a,b,cといった文字列に対応してそれぞれアイコンが設定されます。つまり、代替テキストを適用する、もしくは装飾的なアイコンをスクリーンリーダーで無視させるような追加の記述をしないと、スクリーンリーダーで閲覧したときに不自然な文字列がそのまま読み上げられてしまう恐れがあります。「Ameba」ではこの問題が頻繁に起こっていました。

また、アイコンフォントは一つのフォントファイルとして組み込まれており、ページを読み込む際に全てのアイコンを読み込む事になってしまいます。フォントを全て読み込むまで、個別のアイコンも表示することができません。「Ameba」のアイコンは200を超える種類があり、その中の使われていないアイコンも含めて全てのアイコンを読み込むのはパフォーマンス上よろしく無いと言えます。

さらに、アイコンフォントはフォントなので、読み込みに失敗したり、ユーザー側でフォント設定をカスタマイズしているとフォントの表示に失敗し、いわゆる「豆腐」が出現してしまう恐れもあります。

もし、これらが画像として実装していれば、読み込み失敗時には代替テキストを表示するフォールバックがブラウザにはあるので、仮にアイコンのみのボタンで画像が読み込めなくても、ボタンの内容がわからなくなる事態は避けられます。

さらにもう一点、デザイナー的観点から、「Figma」などのデザインモックツール上でのアイコンフォントの扱いの難しさもかなり気になるところでした。アイコンフォントはその要素のサイズがテキストボックスとなるわけで、それは縦に長い長方形をなし、かつwidthとheightに小数点以下の端数が出てしまうことも多く、これでは例えば4nを基準としたグリッドレイアウトを作ろうとしてもIconからの相対的な座標を組めることができません。「Ameba」では、アイコンフォントを使っている間は正方形Frame内にフォントを配置してからレイアウトに組み込むという処理を行ってデザインデータを制作していました。

一方で、SVGにもいくつかデメリットがあるのですが、それらは解消されつつある傾向にあると考えています。

例えば、容量に関しては、しっかりパスの総数を各アイコンで最適化することで、アイコンフォントに対して著しく増量してしまうことはありません。

また、SVGを利用するとアイコンがイメージファイルになることで通常のテキストと異なる実装になり、テキストのようなズーム操作にSVGは追従できないことも問題点としてあげられる事がありますが、これもCSS3で「rem」でのサイズ指定が可能になったことで払拭されました。

以上よりアイコンフォントからSVGへの移行も今回狙うべきスコープの一つとなりました。

以上の

形状の一貫性と再現性
命名規則
ファイル形式

の3点の各種項目における課題感を払拭するために、「Spindle」としての理想的なアイコン指針を考え始めることになりました。

4. 塗りと線のルール

では早速アイコンの形状のアップデートについて述べていきたいと思います。

まずアイコンとして考えた定義は、塗と線の扱いです。

アイコンの造形としてこれら2パターンをどう使い分けるのか、ということに対して、「Ameba」では今まで、その時々で造形として理想的なのがどちらか、という発想でスタイルを選択されていました。

これも概ね間違いではないように思えるのですが、「Spindle」では、原則アイコンは塗りと線の両方を用意する、というルールに統一しました。

なぜかと言うと、これには、アクセシビリティ的な観点から決定的な根拠があるからです。

ウェブのコンテンツを障害のある人に使いやすいようにするためのウェブアクセシビリティに関するガイドラインである、「WCAG2.0」の達成基準1.4.1には、

1.4.1 色の使用: 色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていない。 (レベル A)

と書かれています。色覚異常の利用者にとって、色の違いだけが判別の手段となった場合に操作不能な状態、状況を判別できない状態に陥らせてしまうことを回避するためです。

これはアイコンを用いたスイッチ状のアクションにおいても同じことが言え、例えばアプリケーションなどで用いられるボトムナビゲーションの選択状態を示すアイコンなどにおいて、形状が同じでアイコンの色のみが変わってしまうような仕様であった場合、色覚異常の利用者にとって判別が著しく難しくなります。

これを回避するために、塗のアイコンと、線のアイコンを使い分ける必要があります。塗のアイコンをActive、線のアイコンをInactiveの時に利用するように定義し、切り替えた時にアイコンの形状も変化させられるように統一すれば、色以外の情報で選択状態/非選択状態が判別できるようになるわけです。

ちなみに塗りを想定するのが難しいアイコンというのもいくつか存在するのですが、これらに関しては、線自体を太くすることで差異を作るようにしています。

ただ、全てのアイコンに塗と線を作っていければいいか、というと実は例外も存在します。

それは、円の中にアイコンがあるようなケースです。

例えば、以下のケースで全てにFillとOutlineを作ろうとすると、これだけの展開になってしまいます。

これだけのアイコン使い分ける意義は無いと言えます。特に後者2つは造形としても不自然なので消してしまいます。

「Ameba」としては、円の中にアイコンを収める時は、アイコンの形状はFillの方のみを使う、というルールで無駄なアイコンの制作を抑制するようにしました。

5. 「Amebaらしい」形状

ではいよいよ、「Amebaらしい」形状というところを考えていきます。

アイコンの形状を考えるにあたって、「Ameba」として一貫性を持ったスタイリングを構築するためには、そもそも「Amebaらしい」形状とはなんぞや、というところから向き合わなければなりません。

この見解を得るために、まず「Amebaらしい」アイコン、次期「Ameba」のアイコンの形状としてふさわしいもの、というお題で「Ameba」デザイナー各位に「Pinterest」などのツールを利用して他社事例等を募集しました。

数々の事例から分析した結果、「Ameba」デザイナーの共通認識として、「Amebaらしい」形状の特徴は大まかに以下のようで、

親しみやすい、角丸。
線が太く、メリハリがある。
モチーフを精緻に描画するよりは適度に省略する。

あたりをイメージしているようでした。

では、この条件に合致する形状を定めなければなりません。

ここからの作業として、とにかく手を動かして様々なパターンを試行しました。例えば、「Ameba」のロゴとしても使用されている「CyberAgent」のキャラクター、「アベマくん」の体の一部の曲線を造形に落とし込むなど(これは形状のルールへの変換が難しく諦めました)。そんな試行錯誤の中で目をつけたのが「Ameba」のロゴでも使用されているサービスフォントです。

「Ameba」のロゴに使用されている書体は「Ameba Sans」というフォントで、英数字全てが用意されており、全体的に見ても、「Amebaらしさ」を象徴するような形状となっていますし、「Ameba」を想起するイメージとして成立しています。

自分は、「Ameba Sans」の形状がそのままアイコンの形状に代入できるのではと考えました。

そもそもスタイリングの定義というものは、一人がこれだというものを突き詰めて考えるのももちろん良いのですが、再現性や属人化の回避を考えると、根拠が明文化できるものの方がよりよいと考えています。

デザインシステムのキーは共感と納得です。いくら定義を刷新しても、それに納得が得られず形骸化、もしくは当事者が首を傾げながらのルール遵守という形で浸透してしまうと、当然プロダクト全体に説得力が生まれず、例外事例が多く発生し、最終的に別のメンバーで作り直しが行われるという結末になりかねません。

何故その定義になったのかという根拠がはっきりしていることはデザインシステムにとって大きな推進力になります。

「Ameba Sans」という「Ameba」として揺るぎない浸透を見せているスタイリングをアイコンの造形の根拠にする事は、かなり道理の通ったもののように思いました。

というわけで、早速「Ameba Sans」の形状を分析していきます。

6. 「Ameba Sans」の形状分析と、曲率定義

文字は、線分や点を組み合わせて形作られた記号の一種です。

線分で考えうるパラメータは、線の太さ、直線、曲線、線分の交差の処理あたりです。

つまり、線の太さ、曲率、交差時の処理の3要素の相関を分析してルール化すれば概ね似たような雰囲気をもった形状が作れるはずです。

「Ameba Sans」は形状としては一貫性があるように見えますが、それぞれよしなに曲率がチューニングされていました。なので、「D」と「B」などの、形状に共通項を持つテキストを分析しました。

では「D」を用いて具体的な分析過程をここに再現してみます。

まず、線の太さを2pxと定義し、「Ameba Sans」の「D」の軸線(中心を通る線)をなぞります。

なぜ軸線なのかというと、アイコンを作成、運用するのが「Adobe」社の「Illustrator」というソフトウェアであり、「Illustrator」ではオープンパスに対して線の位置が内側、外側へ指定できないから、というのが大きい理由です。

次になぞった形に対して「D」の左上の、線分が垂直に交差する部分の曲線(これを曲線αとします)と、右部分の、大きく弧を描く部分(これを曲線βとします)の曲率を測ってみます。

ちなみにこの曲線αと曲線β、実は解釈が決定的に違います。「Ameba Sans」以外のsanserif体の「D」の形を見れば分かるのですが、曲線αは本来2本の辺が接した頂点であり、曲げを意識された形状ではありません。一方曲線βは1本の線を曲げようとして描かれた弧です。同じ曲線処理でも、かたや頂点、かたや線分に対して処理がかかっているのです。

これは、「Illustrator」で言うと、曲線αは、アピアランスの線のプロパティ内にある、頂点に角丸を付ける処理を指し、曲線βはコーナープロパティで曲げを作るイメージです。

実測の結果、曲線αと曲線βの曲率半径は軸線に対してそれぞれ1pxと3pxと分かりました。

ちなみに、曲率半径とは、曲線を円で近似した時の、曲率円の半径のことを指し、曲率半径が大きければ大きいほど曲率は大きく、曲率半径が小さければ小さいほど曲率は小さくなります。

今回は、この結果から、曲線αの曲率半径1pxを「Ameba」における角丸の処理とし、曲線βの曲率をニュートラルな曲率として定義しました。

ただ、曲線αの角丸に関しては、どの角度で交わっても角丸なので曲率半径の値は一律1pxでよいのですが、曲線βに関して、上記はあくまで90°で線が交わっている時の曲率であり、30°などの鋭角に対して同じような曲率を一律適用すると造形としてあまりにも丸みを帯びてしまい、モチーフが分からなくなってしまう恐れがあります。

角度が小さくなればなるほど、曲率が小さくなるような定義を作る必要があります。

今回はその理想的な値を作るために方程式を導き出しました。

その式がr=sin(θ/2)×√2×3/2Xです。

では、この方程式にたどり着くまでの過程を以下に記述していきます。

まず、線分の交点から、対象の角度が90°の時の曲率半径を先の太さxの3/2倍と定義し、三角比を用いて軸線の交点から曲率円の中心までの距離を求めます。

次に、任意の角度θの1/2を含む直角三角形の三角比を利用して、θで交差する線分にふさわしい曲率半径を算出する、という算段です。

(ちなみにこれは鋭角のみに適用できる式でして、鈍角に対しては3/2x*√2*cos(90-θ/2)という式で対応が可能です。)

ただ、この計算式を理解し、巧みに操るのは当然のことながら敷居が高そうに見え、現場への浸透の難易度が高いと考えられます。

なので、これを少し単純化することにしました。

行うことは簡単で、結局の所「Amebaらしい」形状を再現するためには必ずしも厳密な値が必要なわけではないので、近似値が取れるようにします。

角度のパターンを3種類にわけ、それぞれに対応する曲率半径をセットでガイドライン化します。だいたい角度が60°ぐらいになっていたら、角丸に2pxの値を代入してみるといった具合で判断できるようにしました。

ただ、やはりこの抽象化したルールのみだと、どうしても感覚的にしっくりこない形状などはあり、

例えば星など、角度が独特な形状に関しては、前述で定義した式に当てはめて具体的な曲率半径を適用するようにしています。

以上で、線の太さと、角度を変数とした「Amebaらしい」曲率をルール化できました。

このルールを策定することによって、必然的にアイコンの造形においてパスを用いた自由曲線での有機的な描画を全面的に脱却することになりました。元々、有機的なラインは再現性に乏しく、パスの扱いの練度によって、造形に差が出てしまうところでもあり、これを脱却できることはデザインシステムにおいてはプラスとなります。

7. 線の太さのルール

角丸が決まったら、次はそもそも線の太さをどうするかについて考える必要があります。

アイコンの造形を考えた時、どのアイコンも線の太さを一定にすることができれば、それはとても素晴らしいことですが、残念ながらそうはいきません。

アイコンの中でもより細かい描写が必要になってしまうアイコンに関しては、線の太さを調整して、全体の印象を変えないようにしつつ、線を小さな正方形に押し込む必要があります。

ということで定義したのが以下のルールです。

この図でわかるように、アイコン全体として情報量が少ないものに関しては線を太く、情報量が多いものに関しては細い線を用いるようにしました。

また、先程の方程式で先の太さを変数にしていたのはこれが理由で、線の太さが変わると曲率半径も変わり、線の太さによって丸みの印象があまり変わらないようにしています。

8. 命名規則を決める

さて、次は2つ目の課題であった、アイコンの命名規則を決めていきます。

アイコンの名称は、デザイナー、エンジニアがアイコンを配置する時にそれぞれツールでLibrary化されたアイコンから必要なものを探し当てる時の手がかりとなります。

アイコンの命名においてよく遭遇するのが、アイコンに機能名をあてがってしまうケースです。例えば、ブログを書くアクションを示唆するアイコンとして、ペンのアイコンを利用するとします。

そして、このペンのアイコンに対して、「blog」と名付けたとします。

時が経ち、別のデザイナーが、この項目は編集可能なことを示唆するために、ペンのアイコンを使おうと考えたとします。すると、ペンという意匠は「blog」に対応してしまっているので、後手のデザイナーは、致し方なく「blog」アイコンを編集可能な意味で使うか、もう一つペンのアイコンを作り「edit」と名前を付けるか、全く別の編集アイコンを考え始めるしか手立てがなくなってしまいました。

この問題を解消するためには、命名規則を改める必要があります。

アイコンの命名にはそのオブジェクト、モチーフを表す単語をそのまま入れればこれらの問題は解消されます。

例えばペンのアイコンだったらそのまま、「pen」。

バツマークのアイコンは、「close」や、「ng」ではなく、「cross」と名付けます。

これによって仮に意味性が異なるものに対して最適な意匠が重複していても、問題なく同じアイコンを使うことができます。

次に、前項で述べた、塗と線のアイコンの命名についても考慮したポイントがあります。

これは、単純に、それぞれ「Fill / Outline」と名付ければ良いように思えますが、できるだけ名前は複雑化させたくはないものです。前項で述べたように、「Ameba」としては、「Ameba Sans」を模したこともあり、アイコンは「Outline」をスタンダードとしたかったので、「Outline」はsuffixをつけず、「Fill」を線アイコンの差分として定義することにしました。

また、アイコンには他にもさまざまなパターン分けが存在します。

例えば、「add」や「done」、「slash」など、元のアイコンに対してstateが変化したことを示唆する、Optionalなアイコンの存在です。これらをsuffixの何処につけるかも問題です。

例えば、通知アイコンとしてよく使う「Bellのアイコン」に対して、「_slash」や「_done」のようなオプションがあるとします。

ではこれの名付けパターンを列挙してみましょう。(「_done」と「_slash」が両立するようなアイコンは、本当は今の所存在していないんですが例として含めています)

bell

bell_circle

bell_circle_slash

bell_circle_done

bell_slash

bell_slash_circle

bell_done

bell_done_circle

bell_circle_fill

bell_circle_slash_fill

bell_circle_done_fill

bell_slash_fill

bell_slash_circle_fill

bell_done_fill

bell_done_circle_fill

bell_fill

bell_fill_circle

bell_fill_circle_slash

bell_fill_circle_done

bell_fill_slash

bell_fill_slash_circle

bell_fill_done

bell_fill_done_circle

シンプルにすべて組み合わせてみましたが、以上のように、名付け親によってこれだけ表記の揺れが出てしまう可能性があることを示しています。このように名付けが散漫としてしまうと、アイコンを一覧で検索するときも並びがバラバラになってしまって、検索性が悪化し業務効率が悪化してしまう事は必至です。

なのでここにも法則性を設けます。「Spindle」では以下のようにルールを設けてみました。

左にモチーフ名があるのは確定しているので、名前の前にある方がモチーフや意味を表し、後ろにある方がスタイリングそのものについて示すように並び替えてみました。

これによって頭から順に読むことでそのアイコン意図がつかめるようにしています。

例えば「bell_done_circle_fill」だったら、

左から順番に「ベル(通知)が完了したことを示したものを円で囲んで塗りにしたアイコン」と読むことができます。

9. Library化

最後にアイコンの管理と運用の方法をご紹介します。

大きな流れを図にすると以下のようになります。

アイコンが必要になったら、

まず、「Illustrator」でアイコンを作成します。この時、アイコンの形が成立するまでの過程をアウトライン化せずに段階的に全て残すようにしています。

これを行うことによって、どういうロジックでこのアイコンが形作られたのかが明白になり、

途中でバックアップを取っているようなものなので、後からのアイコンの調整が容易になる。
アイコンをレビューする時に、造形に不思議な点があった時に、過程からミスを発掘することができる。
似たようなアイコンを複数作成する時に、過去のデータを参考にすることができる。

など、複数の利点があります。

「Illustrator」でアイコンを作成したら、複合パス化し、「Ameba」でUIの制作を行っているツール、「Figma」に作ったIcon Master Fileにペーストします。

この時複合パス化をしてから「Figma」にペーストすることによって、「Figma」上でも一つのベクターファイルとして認識されるので、

ベクターに対するtintを単色で管理できる。
svg書き出し時に不要なデータが入らないのでデータ容量が抑えられる。

などの恩恵が受けられます。

次に「Figma」のIcon Master ファイルをPublishし、Library化します。

その後、実装に取り込むため、「Spindle」レポジトリの「GitHub Actions」からweb hook経由で「Figma」のIconファイルに追加されたデータをSVG Fileとして取得し、マージのプルリクエストを作成する仕組みです。

これらの作業によって作成したIconを実装に取り込んでいます。

以上が「Ameba」デザインシステム「Spindle」における、アイコン制作フロー作成の一部始終となっています。

10. リプレイス

アイコンの作成作業はほぼ終了しました。しかし、ここから一番大変な作業が待っています。それは、既存のアイコンを全て作り変え、「Ameba」に使用されているアイコンを全て置き換えることです。

「Ameba」で過去に作られていたアイコンは200個以上、しかもそれが15年に登る歳月の中サービスのあらゆるところに埋め込まれていて、しかもそれがアイコンフォントだというのですから、その苦労は想像に難くないでしょう。

この途方もない作業は、一人や二人での限られたメンバーでの作業では不可能と感じたので、「Spindle」運用メンバー以外も含めた「Ameba」のデザイナー、エンジニアの総力戦でアイコンの作成とリプレイスを行うことにしました。特に、200個のアイコンのリデザインに関しては7人ほどの「Ameba」デザイナー全員で一気に作成を行い、一月ほどで無事新しい仕様に統一することができました。

実装上の置換は、元がアイコンフォントであることから、単純な置き換えではレイアウトに崩れが発生してしまうため、ページごとにリプレイスの実装を行いつつ、一つ一つデザイナーが確認しながら地道に変換を行っており、今なお粛々と作業が続けられております。

11. まとめ

以上で、本ブログ冒頭で触れた、アイコンの課題は概ね払拭されました。

結果、できたアイコンのうちいくつか代表的なものをBefore Afterとして以下にまとめてみました。

アイコンの設計というものは、一貫性、再現性、拡張性、利便性などデザインシステムを考える上で大事な要素が詰まっているように考えています。「Spindle」では色に続いて第二弾のスタイルガイドラインとなったのがアイコンガイドだったわけですが、この順番で定義を行ったことに関しては正解だったと捉えています。

冒頭で、「アイコンは、記号としての機能性に加えて、装飾としての役割も抱きつつ、プロダクトGUIにおけるスタイリング定義の標本となり得る」と述べましたが、アイコンが「Ameba」サービスにおける「Amebaらしさ」を伝えるための触媒となることを目指して、引き続き既存アイコンのリプレイスをしつつ、一貫性を持ったプロダクトにアップデートしていく所存です。