要件定義は聞き力、伝える力、心構え。そのための、7つのものさしについて。
はじめに
要件定義は、人をわかって、人にわかってもらう営みの事を言う。
そもそも自分のことも分からないのに、
こんなに真逆の事を簡単に１つの単語にまとめないで欲しいと思う。
例えばワインを作って美味しいワインだと思ってもらう作り手のことを、ワイナリーと呼び、
ワインが美味しいかそうでないかをわかる人のことを、ソムリエ（あるいはソムリエール）と呼ぶ。
両方を兼ねる人もいるだろうが、それぞれが独立した立派な仕事である。
少なくとも、「ワインの仕事」と乱暴にまとめる事は馴染まないだろう。
要件定義という言葉において、
人をわかる力は聞く力で、人に分かってもらうのは伝える力だ。
新入社員研修で、この２つをまとめて「人間力研修」とプログラムを提出したら、多分上司とかに怒られたり諭されたりするだろう。
分けましょうと。
なので、要件定義力を伸ばすためには、聞き力と伝える力の２つを分けて考えた方がいい。
そして、結論としてはこの２つでは足りない。
どうしても、「心構え」という3つ目の要素が欠かせないと、僕は感じている。
その心構えとは、
人間は”神様ではないので”、完璧では無いのに、
あなたには完璧が求められるという矛盾を理解した上で、顧客にとって本当に必要なものを作る。
ということである。
この後に続く文書は、心構え、聞き力、伝える力、心構えの順番で構成される。
長い話になる。大体２万字位ある。
心構えは、端的に言えばメテオフォール開発と王権神授説と、いつものロープタイヤブランコの話である。
極力分かりやすいように説明したいが、どこまで行ってもマインドの話なので合う合わないがあるだろう。
適当につまみ食いして頂きたい。
聞き力は、そもそも受動的な行為なので出来てる、出来ていないが非常に評価しずらい。
そのため、この文章では聞き力が欠如している時に起きる、3つの代表的な事象を切り口として話をすすめる。
その3つとは、機能の目的化、運用イメージの欠如、作業イメージの欠如である。
伝える力は、UI、機能、データの3つの話だ。
言い換えると見た目、ふるまい、記録である。
そして、ふるまいとはUX、運用継続、あったらいいなの3段階で構成される。
意識しなければならない3つの観点と、それをどのように伝えるべきかの方法を、ツールも含めてざっくりと記載する。
ツールの優劣ではなく、何を伝えるのに向いているのかを書く。今後登場するツールにも応用は効くと思う。
この文章は、BPRという単語が流行り始めた頃に、「システム職経験がない人でも、要件定義が分かる、出来るようになるノウハウをまとめて下さい」という耳を疑うような要請を受けて、発注側の社内SEの私が、社内のクローズドWiki（Kibela）に書いた文章を再構成したものだ。
この原文を読んだ色々な人に、「これ多分、公開したほうがいいですよ」と後押しをしてもらった。
そういった毛色の文章なので、社名が特定出来る情報や、エピソードなどの具体的な事例を除き、それに合わせて文章を加筆・再構成している。
そのため、文章の途中において原文準拠で急に敬語になる事をご了承頂きたい。
また、7つのものさしについては、
予め参考文献をネタばらししておくと、
以下の3冊の本が原典としてあり、
僕はそれを利用した上で、注釈をしてご紹介しているに過ぎない。
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
Design rule index―デザイン、新・100の法則
Design Rule Index 要点で学ぶ、デザインの法則150
それぞれ2006年、2004年、2015年の再編版なので、
2020年現在の最新の何かについて語る訳ではない。
その時々に受け取って、今でも自分の中で変わらない大切な事をお伝えしたいと思っている。
非常におこがましい例えだが、この3冊を孫子の兵法書とすると、この文章は曹操が註釈を入れた魏武帝註や、太公望が授業形式で孫子の兵法書を解説した六韜と同じような関係性である。
ただし、僕は英霊召喚されそうな1800年以上前の英雄達と比べると、明らかに民草でモブいキャラなので、僕が言っていることに一理を感じるのであれば、原典にあたる事を強く、強くお勧めする。
特に、100と150は「デザイン」というワーディングからデザイナー畑の人にしか膾炙されていないように思うので、割と未開の金脈だとは思う。
それでは、後書きでお会いしましょう。
心構え
昨今登場したメテオフォール開発理論に置いて、その構造の主役は神様であるとして理論が展開されています。
筆者はこの理論が大好きですが、
この後、神様は神様ではなくなるのです。
実は、「お客様は神様です」というワーディング自体は、サービス業では割と普遍的な表現です。
そして、「お客様は神様である」というのは、随分前に異論が唱えられています。
もう何十年も前に、「お客様は神様では無い」と、あるサービス業の飲食店が宣言をしている事をご存知でしょうか？
恐らくご存知ないと思いますが、ジョナサン憲章の事です。
ジョナサン憲章 第1条より
１．お客様は神様ではなく王様です。王様は人間ですから間違えもあります。でも常に自分が正しいと思っています。お客様は王様です
ジョナサンというは、ファミレスのジョナサンで相違ありません。
筆者はタンドリーチキン&メキシカンピラフが好きです。とみにマヨネーズが美味しいです。
さて、すかいらーくグループの事は詳しくは分からないのですが、そのグループの1ブランドであるジョナサンで働く従業員は、少なくとも僕が291号店でバイトしていた20年前の時点で、ジョナサン憲章を規律としていました。
西洋の歴史的な文脈においては、権力者は神や神の血脈者だから権力者である訳ではなく、
神から権力を与えられた人間であるとする、王権神授説が存在しています。
ジョナサン憲章を創案した人も、きっと同じような流れの構造に気がついて、このように宣言をしたのでしょう。マグナカルタと言ってもいいかも知れません。
メテオフォール開発理論の登場によって、神が発見されて眼前に現れたのであれば、
IT業界においても王様の発見は時間の問題かも知れません。
そして、人間は神ではなく、王様である。
そのことを前提にした文章は、結構沢山あります。
例えば、ほぼ日の糸井さんの場合。
ほぼ日の岩田前任天堂社長が糸井さんから聞いたお話の引用
引用元→https://www.1101.com/iwata/2007-09-11.html
「ものをつくる人」と「お客さん」は、王様と奴隷の関係にある。
でも、王様は「ものをつくる人」じゃない。
「お客さん」のほうが王様。
で、「ものをつくる側」は奴隷の役。
王様は「もういらない」って言うことも、
「つまらない」って言うことも
「わからない」って言うことも
自由にできる、超わがままな立場で、
その超わがままな王様に、
どうしたら喜んでもらえるかな、
まえのものは飽きちゃってるけど、
つぎはこうしたら喜んでもらえないかな、
ということを、奴隷の側は考える。
「その『考える奴隷の仕事』の
おもしろさをわかりなさい」
そして、この業界ではお馴染みの以下の図を改めてご紹介します。
正直な所、システム開発を志す者で、時間が許されるのであれば、私の散文より羽生章洋さんの三部作を読んだ方がよっぽど良いような気もするんで、
この図について言及された部分を引用したいと思います。
はじめよう！プロセス設計（著：羽生章洋） Ｐ.138より引用
インターネット上においてIT業界の「あるある」ネタを揶揄するジョークとして、大木にぶら下がった三枚板の変則的なブランコを顧客が求めていたのだけど、実際に欲しかったものはタイヤをぶら下げる程度のものでよかった、というものがあります。
これを聞いてたいていの人は多少の苦しさを感じつつも大笑いするわけですが、実は笑いごとではないとも感じます。
顧客が自分の思い・願いを適切に表現できないのは、1つにはボキャブラリーの問題があります。もう1つは「自分の思いを適切に表現するスキル」が不足しているというのもあります。これらはエンジニアリング側で解決すべき・できる課題であるにもかかわらず、相手の言葉の表だけを鵜呑みにして作り手側の都合やエゴを優先させてしまっているがゆえの問題であるとも言えます。
ディレクターであるあなたの王様とは、
端的にいうと、希望や要望をあなたに言ってくる人、つまりは広義の顧客です。
それが上の人だったり、現場の部署だったり、エンドユーザーそのものだったり、ユーザーアンケートを取りまとめた内勤部署だったり、様々なのですが、
その希望や要望が完全な状態で上がってくることはありません。
* 目的と機能が一致していない
* 作業が練り込まれていない
* 実装後の運用が練り込まれていない
* 目的や機能をきちんと言語化出来ていない
* 局所的な部分最適である
などなど、その容態は様々ですが、
顧客は神様ではないので、完璧ではありません。
ジョナサン憲章は、顧客が完璧ではない事を皮肉として表現しつつ、それでも覚悟を決めて、王様に相応しいサービスを提供するプライドを表明しています。
糸井重里氏も同じ事を言っていますが、
奴隷という言葉をあえて使う事で、
その面白さを対比的に軽やかに表現しています。
これらは、埋めがたい非対称性をただ嘆くのではなく、
それでも前を向く事に決めた強い人達の、強い言葉です。
顧客が本当に必要だったものの図は、
表面的にはあるあるネタのジョークなのですが、
ここまで長い間、人口に膾炙されるという事は、
いつの世でも琴線に触れている普遍性があると考える方が最早、妥当性があります。
僕たちがどんなに、「じゃぁロープとタイヤで、ブランコ用意しなきゃね」と自虐的に卑下したとしても、
僕たちはまだ存在していない、「顧客が本当に必要なもの」を提供したいんです。
そうでない限り、少なくとも15年以上も１枚のネタ画像が出回り続けるという事象の説明が出来ません。
そして、ディレクターであるあなたは、社内の作りたい人と社外の作ってくれる人の間に立つわけですから、
社内では「ものを作る側」として振る舞い、社外に対しては「王様」として振る舞うという事になります。
だから、ものを作る側として、王様の話をしっかり聞かなければならないし、
王様として、ものを作る側にはしっかりと頼むことをしなければなりません。
よくよく考えると、割と恐ろしい構造ではあるのですが、今はそういう物だとして話を進めましょう。
それでは、「しっかり」ってなんですか？という事を、ここから聞き力と伝える力の２つに分けて説明をしていきます。
この記事を読む人の対象想定
・社内の要望や要求から、新しい機能や改善案を考える人
・開発会社に何らかのアウトプットの作成を依頼する人
自分ではシステムを開発しないけど、社内の要望や要求に従って、外部のリソースを使ってそれを実現する、
Web制作的にはWebディレクターと呼ばれたり、社内SEと呼ばれる人向けを想定しています。
聞き力
要件定義は、相手の話をきいて、理解する所から始まります。
しかし聞き力というのは、そもそも受動的な行為なので、出来ているか出来ていないかが判別が難しい力です。
勿論、復唱したり要約したりとアウトプットを出す事で判別は可能なのですが、「その時に顧客が言っていない事を聞く力」の醸成にはつながりません。
しっかりと聞けていない状況というのは、
以下の3パターンに分類されます。
・機能の目的化
・運用イメージの欠如
・作業イメージの欠如
それぞれ、
・使われない
・祭りになる or 飾り物になる
・高い、時間かかる
というような事態が発生します。
順番に説明していきます。
機能の目的化(使われない時)
例えばあなたは社内の王様から、「東京からローマまで行きたいので、船を作ってくれ」と頼まれたとします。
「分かりました、どんな船にしましょうか？」とはじめてしまうのが、機能の目的化です。
何故、ツアーの船ではなくて、船を作る必要があるのか、
何故、飛行機ではダメなのかを聞くのが、
ものを作る側である、ディレクターには求められます。
通常、ローマまで行く事が普通は目的で、
船は手段、つまり機能です。
もし、「ローマまで自分の船で船旅を楽しみたいんだよね」という事を王様に確認出来れば、
目的は「自分の船で船旅を楽しむ」ことになります。
それを快適かつ安全に、そもそも何人で、、、みたいな機能要件に入るのであれば、
「どんな船にしましょうか？」という話に進む事に意味があります。
これは、がんばりましょう。
しかし、王様は単純に飛行機という近代文明の利器を知らないだけかも知れません。
ローマという場所で大事な商取引があり、一刻も早く現地に到着しなければならない王様だとしたら、
きっと成田空港や旅行サイトの存在を教えて貰えれば、喜びながら貴方の元を去っていくでしょう。
しかしそのためには、成田空港のことや、飛行機のことや、
もし王様がやんごとなき崇高な身分の御方だったとしたら、
ホンダがプライベートジェットを販売しているみたいな事を勉強して知っている必要があります。
あなたが飛行機の事を知らなければ、話は簡単です。船を作る事になります。
そして、往々にして飛行機の存在を王様が知るのは時間の問題だったりして、「やっぱり飛行機！飛行機がいい!」と王様は言い出します。
さて、この王様に、飛行機作ります？
テレビ電話とかで解決するかも知れませんけど・・・。
運用イメージの欠如(祭りになる or 飾り物になる時)
例えば、今度は社内の人から「美味しい目玉焼きを作ってくれ」と頼まれたので、
ディレクターであるあなたは、外部の開発会社に「美味しい目玉焼き」を発注したとします。
外部の開発会社から、無事に美味しい目玉焼きが納品されたので、社内の人にお知らせするわけですけど、
食器がない事にその時に気がつき、
「食器がないと食べられないだろ常識的に考えて」、「いやいやでも食器もつけるなんて話聞いてないですよ」みたいな話に発展する、
みたいなケースが、運用イメージの欠如に該当します。
先程の船の例で言えば、
「自分の船で船旅をするために、船を作る」のが目的だとしたら、
誰が乗るのか、どこで乗るのか、そこまでどうやって移動するのか、そもそも操船出来るのか、というような、
作った船を前にして、王様がハッピーになるまでのプロセスを想定している必要があります。
想定していないと、船は使われないまま、朽ちます。
もやもやした王様とずっと微妙な関係にもなることでしょう。
あるいは、船ぬ造りは気に入って頂けた場合、もう王様側では綿密なスケジュールが組まれていて、そのスケジュールを守らないと死罪になるなら、祭りと形容するしかない「てんやわんや」が発生します。
(あ、受注側が見積もりに載せないこともあるラインでもあります。)
考えが足りなかった場合、
その仕事の第2ラウンドがはじまりますが、第2ラウンドで終わるかどうかは、やはりハッピーになるまでのプロセスをどれくらい掴めているかです。
掴めきれていないなら、「いや、実はそもそも」みたいな切り出しから第3ラウンドがはじまります。
使う人の立場になって考えるというのは、使う人のプロセスを理解すると同義です。
使う人が、作るものをどのように使うのか、一連の流れに生活感があるか（なんか無理目なことをしていたり、乾坤一擲なことを前提にしていないか）を想像出来なければ、多分プロセスは掴めていません。
プロセスの理解は頭ではなく、足を使うのがコツです。
何度も何度も王様の所に足を運んで、話を聞いてください。
大体その時に、説明されていない事を王様や側近がやっているのを目撃したりもします。
話を聞いても王様が何言ってるか分かんない事も往々にしてあるんですけど、
分かる人には分かる世界でもあるので、
分かり方が足りてない自分に原因があると決めて、自分を改善してしまうのが、ある意味楽です。
後述しますが、こういう時はロゼッタストーンしかありませんので、自分と相手がわかる、別の事例に例えて説明すると、理想との誤差の検出がしやすいです。
作業イメージの欠如(高い、時間かかる時)
今回も社内の王様から「船を作って」と言われたので、外部の開発会社に造船を依頼する訳ですけど、
ディレクターのあなたは船を作ったことがないので、
自分が要求している船を作るのが、どれくらい大変なのかが分かりません。
そんなの作ったことないんだから仕方ないし、作れないから外注してる訳なんですけども、
ディレクターが必要な「経験値」や、判断基準の軸となる「ものさし」を全く持っていない場合、いろいろな問題が発生します。
造船よりも身近な目玉焼きで例えると、こんな感じです。
・ 目玉焼きを1つ外注したら、開発会社から10万円請求された（けど、作り方がわからないので高いか安いか判断つかない）
・目玉焼きの要件として、白身の直径、黄身の直径、黄身の硬度、温度などを事細かに指定しすぎる（作ったことがないので、失敗しないようにドキュメントがすんごく過剰になり、開発会社が困る）
・「東京ドーム全員分の目玉焼きを10分以内に提供する」というような、無謀なオーダーをしてしまう（けど、作ったことがないので、それがどれくらい大変なのかわからない）
・普通の目玉焼きなのに、すごく感動して絶賛してしまう。もしくは逆に面罵したりする（自分に作れないから）
・ 目玉焼きを発注したのに、スクランブルエッグが納品され、思っていたのと違うと言っても、これしか出来ないと言い張られて納得してしまう
というような事が、まぁ、発生します。
自分が理解していないものを作ってもらうとなると、
こういった問題は不可避です。
精度を上げるには、２つの方法があります。
とにかく発注経験を積んで「以前はそんな事なかったぞ・・・？」という判断基準を積み上げる方法と、
自分でも作ってみたり、作り方を学ぶ方法があります。
おススメなのは、両方ですが、時間がかかります。
時間がない時は、経験豊富そうな人に確認をお願いしましょう。
周りにそういう人がいなくて、自分にも精度が足りない場合は、
あなたの問題では無くて会社の問題なので、
会社のお金を使って精度を上げる訓練と思って、色々やるのが良いでしょう。
また、同じ事を外部の会社にお願いしているはずなのに、私がお願いしてもやってくれないのに、他の人がお願いすると何故かやってくれる、というような時は作業イメージの欠如に該当します。
汎用的な技術の土台か、運用しているものの知識のどちらかが不足しています。
聞き力の"ものさし"
プログラムを勉強したりして、システムの事が分かったり出来るようになると、
船を作ってくれと言われれば、実力を証明したくもなるんですが、初手のそれが悪手なのは上述の通りです。
自分のやりたい事や気持ちはともかく、
今、何が本当に必要なのかを自己点検する時や、回答、提案をする時に、私が使っている物差し、考え方を以下に記載します。
①目的→機能→作業
利用頻度：★★★★★
アート・オブ・プロジェクトマネジメントから引用。
本当に、これだけ覚えていればいいレベルで、別格に必須です。
聞く力も、伝える力も、これを押さえていれば大丈夫です。
散々と船の話をしましたが、東京からローマまで自分の船で移動すると言う話は、
目的:ローマに行く
機能:船を作る、旅をする
作業:予算調達、材料調達、それらのスケジューリング、人材の確保・・・
と言う感じになります。
ここで重要なのは、作業は機能に従い、機能は目的に従うという上位関係があり、
目的を果たせない機能、
機能を実現しない作業があった場合、
本来必要とするものが必ず出来ず、ヘンテコなものが生み出されるという法則がある事です。
特に、目的→機能が大概ズレます。
機能から考えて、目的にまっすぐ繋がらない場合、
大概説明されていない重要な目的が隠されています。
慣れないうちは、
目的と機能に矛盾がないかを常に確認しましょう。
機能を実現する作業に、矛盾や過不足がないかを確認しましょう。
自分だけで確認するのが不安なら、他の人に確認してもらいましょう。
②スケーリングの誤解
利用頻度：★★★★☆
Design rule index―デザイン、新・100の法則 から引用。
例えば飲み会をやる事を想定した時、
自宅で友達と数人で飲むなら、Lineやメールでいいのですが、
1000人超の会社の全員で飲み会、ではなく、会社行事をやるとなると、Lineやメールは目的を達成する機能としてかなり懐疑的になります。
それでもLINEでやるなら、1000人のいるLineグループを作成する、1000行近くに及ぶ「了解しました」「承知しました」の返答、未回答者の特定のために画面を必死に擦る作業、1000台の携帯が震え続ける事象などが発生します。
重要なのは、
数が変わるだけで、上手く行っていたものが途端に上手くいかなくなることと、
何人からLineが機能しなくなるかは誰にも分からないという、2点です。
システムの利用者、表示するデータ、ページ数、項目数、組織の課の数など、
普通は成長に伴って、色々なものが増えていきます。
あと1つ選択肢や項目が増えた時のことや、データ量が100倍になった時の事を考えましょう。
「とりあえず今なんとかなればいいや」は、問題の先送りです。
必ずしも悪いことではありませんが、先送りして良い問題なのか、リスクとリターンをしっかりと検討して下さい。
あかんやつを先送りしたリスクは誰かが負いますが、誰かというのは、あなたか同僚のことです。
③ごみ入れごみ出し
利用頻度：★★★★☆
ごみを入れても、取り出す時に綺麗になっていることはないので、
取り出す時には当然ごみしか出ないですよ、
世の中は因果応報なのです、という話です。
Design Rule Index 要点で学ぶ、デザインの法則150 より引用。法則は100にもあるけど図が違う。
かなり含蓄のある言葉なのですが、
狭義の意味では、誤入力を防ぐ仕組みを入れないと、データは汚くなるので使い物にならない、という意味です。
また、使い方を考えていないとゴミになったりもします。
例えば、クライアントの状態を
「現在取引があり、この間クレームを受けた。」「評価はされているけども、現スポから落ちスポに。」
みたいなテキストで管理しようとするのは、ゴミを入れる事になります。
理由として、これも運用を想像すればわかるのですが、
現在取引のある顧客リストだけ欲しかったり、
クレームを受けた企業のリストだけ欲しかったり、
ステータスが取引停止なのに評価が高い、
ステータスが取引中なのにクレームがあった、
みたいな集計行動をしたいはずなんですが、
データ投入が適当なので、規則性のないテキストからしか出てこなくて処理が必要になります。
こういった、欲しいものがすぐ出てこない状態は「ごみ入れごみ出し」と揶揄します。
ですので、データを使う時の事を考えて、
ステータス、クレーム、評価値、というような感じで項目を分け、
あとで探しやすいようにデータを綺麗にする、というような事が基本となります。
そして最も広義な使い方として、
王様がものを作る人にゴミを渡すと、ものを作る人はゴミをつくります。
そうならないように、発注側の人は一緒に頑張りましょう。
④フレキシビリティとユーザビリティの二律背反性
利用頻度：★★★☆☆
Design rule index―デザイン、新・100の法則より引用。
150の方は十徳ナイフで何でも出来ることは、何にも出来ない事を説明している。
「とにかくなんでも分かりやすければ良い」というのは、フレキシビリティを無条件に犠牲にしても良いということなので、
「上昇」「下降」「進む」のボタンしかない飛行機に喜んで搭乗する、と言っているのと同義です。
熟練者や専門性が高い人には、それに相応しいインターフェイスがあります。
「とにかく分かりやすく」しか言わない王様は、
王様自身の業務に対する自己肯定感が低すぎる場合もあるので、王様が疲れている場合は、業務の価値や専門性を解いて、誉め殺すのが有効な事も結構多いです。
(なので、所属人数を聞いてきて、それは大変ですね、少しでもお手伝いさせて下さいとSIerの営業とかがいうのはよくある殺し文句ですから、浅いのは真に受けない方がいいです。)
自分の作るサービスを使う人に相応しいインターフェイスを提供出来ているかを考えてみましょう。
⑤『アイデアというのは複数の問題をいっぺんに解決すること』
任天堂の宮本茂さんの言葉を流行らせた岩田聡さんから引用
やったほうがいいことは常に増えていきます。
しかし、通常、リソースや時間的な問題で、
やったほうがいいことは、やれることよりも常に多いので、
やったほうがいいことを愚直にやり続けると、人は倒れていきます。
そういう時は、今まで出来ていた事を単純に拡大したり増やしたりしても、
やったほうがいいことは減りません。
だから、少なくとも、一石二鳥を狙う事を考えよう、というのが狭義の考え方です。
「そもそも論」で、その作業が発生しないようにしたり、
前工程から見直したり、目的を考え直したりと、
全体を俯瞰してポイントになる部分というのが、必ずあるはず、
というのが広義の考え方です。
うまくまとめる事が難しいので、詳しくは以下を読んで下さい。
https://www.1101.com/iwata/2007-08-31.html
伝える力
ここまで、心構えやものさしなど、主に王様から言われた事をインプットをする時の事を想定してあれこれと書いてきました。
実際問題、正しいインプットをしないことには、正しいアウトプットをすることは絶対出来ないので、そこは忘れないにして下さい。
そしてここからは、王様として、ものを作る人にはどのように伝えればいいかを記載します。
ポイントになるのは、UI、機能、データの3つを説明するということです。
それぞれ見た目、ふるまい、記録と置き換えても良いですが、
作りたいものを説明する時は、この3つの観点を覚えておくと良いと思います。
UI（見た目）
ここでは、あなたの会社のオフィスに設置されているであろう、自動販売機を例にして説明します。
上記の画像のようなジャパニーズトラディッショナルな自動販売機には、概ね以下のようなUIが設定されています。
* 商品を選択するための、ボタン
* コインを投入するための、硬貨入れ
* お札を投入するための、お札入れ
* おつりを出すための、おつり返却口
* 商品を出すための、商品取り出し口
ここで重要なのは、目的と機能が必ずセットになっているということです。
押しても何もしないボタンや、商品を選ぶボタンが無い、ということはありえない事がわかります。
また、一般的に目的が増えると機能が増えるので、自動販売機はごちゃごちゃします。
例として、
・購入者にランダムでおまけをつけるために、スロットを表示する
・電子マネー決済に対応するため、ICカードリーダーを搭載する
などです。
また、機能の節約も重要です。
目的の数と機能の数は一致している必要はありません。
WEB画面の領域（特にファーストビュー）が有限であるように、自動販売機の筐体もスペースは限られているので、
おつりの返却口は、おつりを返却する目的と、自動販売機が硬貨と認識できなかったものを返却する目的、2つの目的が設定されています。
目的が似ているなら、機能を一本化する、そもそも新しい機能を作らず省エネするのはとても重要です。
返却口が2つあったらどっちからお金が出てくるかぱっと分からないですもんね。
とりあえず自動販売機で上記の説明をしましたが、そもそも自動販売機を知らない人に、
* 商品を選択するための、ボタン
* コインを投入するための、硬貨入れ
* お札を投入するための、お札入れ
* おつりを出すための、おつり返却口
* 商品を出すための、商品取り出し口
という説明をして、あなたが脳裏に描く自動販売機を、ものをつくる人が完璧にトレースするのは、多分無理です。
要素の並びについては、図説をするのが良いでしょう。
ただし、ランディングページや何らかのTOPページなど、クリエイティブ要素が強いものは、
この図説に色味や雰囲気など、いわゆるトーンアンドマナー（トンマナとか言います）を無理に乗せる必要はありません。
こだわりがなければ、トンマナの説明として、自分がイメージしているものの画像やURLを参考資料として添付すると良いと思います。
機能（ふるまい）
機能というのは、大きく分けると3つの段階があります。
1.UX（大筋）
1つは、ユーザーが自動販売機を使って飲み物を手に取るまでのストーリーを説明するもの、
いわゆるUX（ユーザーエクスペリエンス）のことで、「ユーザーが普通に使った時の手順と、ユーザーが得られること」の説明です。
自動販売機の場合、
「ユーザーがお金を自動販売機に入れて、欲しい商品の下にあるボタンを押すと、すぐに商品が取り出し口から出てくる」というものです。
つまり、「これが出来ないんじゃ、これを作る意味がない」ということを伝える必要があります。
これを漏れなく正確に伝えないと、作ってもらうもののバランスがおかしくなります。
例えば、「すぐに商品が取り出し口から出てくる」という事を大筋で伝えず「商品が得られる」みたいな曖昧な書き方だった場合、「ユーザーが押し間違える事もあるので、60秒ボタンを押したら商品が出てくるようにしました。気が利いてますよね？」みたいな事が起こりえます。
もしくは、その後自宅の住所を入力することで選択した商品を配送してくれる自動販売機が爆誕するかも知れません。
それはそれで空港とかでは重宝されうる新サービスになるなら、作り手的に全くありえない話ではないという事になってしまいます。
今回は何のためにつくるのか、目的を説明することが重要です。
2.運用上で必須の機能
自動販売機の基本的なUXは、「ユーザーがお金を自動販売機に入れて、欲しい商品の下にあるボタンを押すと、すぐに商品が取り出し口から出てくる」というものでした。
平時に、お金を入れなくても商品が出てくるのも結構まずいですが、
お金を入れたけど商品が出ない場合、商取引の根幹を揺るがす、結構な大問題です。
全ての自動販売機には、そういったケースをケアして、運営者の電話番号が貼られています。
また、自動販売機は商品が購入されてどんどん減っていくので、
新しい商品を補充出来る機能がないと、意味が分かりませんし、
著しく補充がしにくかったりすると、非常に運用がしにくくなります。
小銭が無くておつりが出ない時、商品がなくなった時、異物が混入していた時など、
ずっと運用していれば発生するだろう事態を想像して、
「こういう時はこうする」というものが、運用上で必要な機能です。
自動販売機にも買う人と補充する人がいるように、
システムも単純に使う人、権限や部署の違いで少し違った使い方をする人、運用をする人など、色々な使われ方をします。
その機能を提供する人で、どういう人に影響があり、どういった機能を提供するべきなのかを想像するようにしましょう。
3.あったら便利
先程、自動販売機のボタンは「商品を選択する」機能があると書きましたが、
* 商品に設定された金額以上の金額が自動販売機に投入された時、光る。
* 上記の状態でボタンを押すと、音がなる。
* 売り切れている場合、それを伝えるために売り切れマークが表示される
といった機能があります。
光る、音がなる、売り切れなどは、それぞれの機能が故障していたとしても恐らく目的は達成出来ます。
また、自動販売機は災害時は（どうやって災害を検知しているかまでは知らないのですけど）水分補給の拠点として、
商品が無料で排出されるような機能が存在します。
なので、極論としては無くてもいいのですが、
「こういうユーザーがやってきたらどうしよう」「こういう場合はどうしよう」「こうしたら親切なんじゃないか」といった、親切心のようなものがないと、なかなか思いつかないと思います。
こういった細部、ディテールは凝りはじめると時間とお金を結構浪費する一方、
差別化する時には結構効果的だったりはします。
また、競合がみんな実装していると、ない事が違和感になってやはり差別化されてしまうので、必須になります。
大切なのはさじ加減です。
余談：今までに存在しない機能の良し悪し
こういう自販機のことです。
この自販機、acureという会社が製造する、その名も「次世代自販機」と呼ばれるもので、
物理的なボタンがなく、サイネージ領域とUIが一体化しているのが特徴です。
ユーザーの顔を認識して商品をレコメンドしたりと先進的な機能もあり、
2011年には[GOOD DESIGN AWARD](http://www.g-mark.org/award/describe/38157)も受賞していたりします。
一方で、（私も含めて）この先進的なコンセプト機に初めて触れたユーザーの一般的と思われる反応は以下の通りです。
[東京で遭遇したタッチパネル式自販機の使い方がわからず困惑した](https://webmist.info/touch-vending/)
どこで読んだかは忘れたのですが、（確か「売れるデザインのしくみ」だったかな）
唯一無二の商品を除いて、ユーザーに選択肢があるサービスが複数ある中で、その複数のサービスと全く違う形態で機能を提供すると、「これは何て先進的なんだ、これを必ず使うぞ」と思うユーザーはごく少数で、
「なんか他のと違いすぎて使いづらいなぁ、普通のを使おう」と思うユーザーが多数となります。
ものすごく暑い夏に、あなたの親しい人が脱水症状で苦しんでいたとして、
あなたの目の前に次世代自販機と普通の自販機が並んでいたら、どちらでポカリを買うかを考えてみて下さい。
ユーザーに選択肢があるサービスが、突拍子もない形態のもの提供するのは危険です。
もし、あなたが「今までに誰もみたことのないもの」を作ろうとしていたら、セg・・・ではなく、次世代自販機の事を思い出して下さい。
10年先を見通せても、明日のことが分からないなら、意味がないのです。
データ（記録）
UI、機能と触れてきましたが、最後の要素となるがデータで、正直なところ、「静的と動的の違い」が説明出来る程度の、
システムの基本的な知見がないとピンと来ないかも知れません。
動的を「その時々で出力するものが違うので、出力するものを事前に決められない」ものだとすると、自動販売機の中にある、商品の在庫数、販売数は動的と言えます。
念の為に補足しておくと、「その時々で出力するものが違う」というのは、
コーラの商品ボタンを押下した時にコーヒーが出てくるランダム性のことを指すのではありません。（それは、ただの嫌がらせです）
どちらかというと、お客さんが自動販売機の前に立った時、
自動販売機内のある商品の在庫は他のお客さんの購入状況とかで変動しているので、
商品選択ボタンに「売り切れ」と表示するかどうかは、
ユーザーが自動販売機の前に立って、その時の在庫数を「動的に」確認しないと分からない、というような意味です。
自動販売機で静的な要素というと、例えば余白に掲示されたポスターやおすすめのポップ、ユーザーサポートへの問い合わせ情報とかですかね。
どのようなユーザーが来て、自動販売機がどのような状態でも、その情報出力は変わらないので、これは動的ではなく、静的と言えます。
という訳で、ある商品の在庫数が動的なものだとすると、その在庫数というのはデータです。
データというのは、登録、読み込み、更新、削除が出来ます。
それぞれ、
Create
Read
Update
Delete
なので、頭文字を取ってCRUD（クルード）、それを視覚化したものをCRUD図と言ったりしまして、
これをチェックすれば、
ある機能の、データに対してのアプローチが網羅的にチェック出来ると言われています。
急に横文字使いやがって何言ってるだこいつ、
と思われるかも知れないので、自動販売機でCRUD図を書いてみようと思います。
UXのCRUD図
まず、ユーザーが自動販売機の前に立った時、
商品の在庫をチェックしておいて、在庫が0だったら売り切れを表示する必要があるので、
という感じになります。
次に、ユーザーはお金を投入すると、商品の金額以上であるかをチェックする必要があるので、
という感じになります。とりあえずこれで、
売切れ管理をする機能は、別に価格表を参照したり操作したりしないし、
投入金額をチェックするのと、売切れを管理するのは別なんだなぁ、みたいな事がわかります。
次に、ボタンを押すと商品が出てきます。
商品が出ると、当然在庫数が減りますので、
こんな感じになります。
しかし、自販機の販売データをマーケティング部的な部署に迅速に提供しなくてはならないとなると、
いちいち在庫数と価格表から計算するのは面倒なので、売上データも販売成立時点で計算して記録するとします。
そうすると、
こんな感じになります。
ちなみに、200円で150円の飲み物を購入していた場合、お客さんには50円のおつりを計算しておく必要がありそうです。
しかし、200円という数字は売上データではないので、一時的に預かったことを記録しておく必要があります。
ということは、投入金額チェック機能で、一時預かり金額データを作成したり、硬貨が投入される度に金額を更新してしまうのが筋が良さそうです。
そうすると、こんな感じになります。
購入ボタンを押すと精算されるので、50円のおつりを返却しますが、
一時預かり金額データが残っていると、次のお客さんの時に会計がおかしくなりますので、
一時預かり金額データは購入機能が精算をしたら、削除しちゃって良さそうです。
・・・という感じで、自動販売機の実現するために必要なデータに、
どういう機能が必要で、どのようにデータにアプローチしてもらうかをまとめる事が出来そうです。
運用側のCRUD図
さて、運用側では、
* 商品を補充しなければいけない
* 消費税が変わると恐らく自動販売機の価格を変えなければいけない
* 新しい商品を追加し、イケてない商品を取り扱わないようにしなければならない
みたいな事が発生しますが、それぞれの機能をCRUD図で説明するとどうなるかは、(書くの面倒なので)自分で考えてみましょう。
実際のところ
ここまで散々とCRUD図の説明をしてきましたが、概念の説明のためで、私は実務的に書いたことはありません。
実務的にはDB（データベース）のテーブル構成とER図を頭に叩き込んで、Select文をたくさん叩いて体で覚えてしまうのが、考える上でも伝える上でも、話が早いです。
しかし、システム職でない人に、ER図やDBのダンプデータを要求されると、システム職としてはそれはそれで提供に不安を感じるのは否めないので、入手難易度は高めかも知れません。
入手出来ない場合は、データに対する要望を整理して述べるに留めましょう。
ツール毎の向き不向き
ここまで、王様としてものを作る人に伝えなければならない事として、
UI、機能、データの話をしてきましたが、当然ながらアウトプットをしない限りはあなたの脳内にしか存在しないものなので、何らかの形にして相手に伝達をする必要があります。
あなたは会社に勤めていて、机には、電話機とパソコンがおいてあるかと思います。
ここではアウトプットをするための手段をツールとして、その使い所を説明します。
会議
多くは会議室や打ち合わせスペースで、指定した時間に来訪してもらって、
顔を突き合わせて会話をするという形態をとります。
しかし、上述したUIをその場で書き出して伝えたり、機能要件をその場で書いたり、データについて考えるのは、
あなたが本来机の前で練らなければならないことで、考え事を1からするために、キックオフや顔合わせと称して、
開発会社を気軽に呼ぶべきではありません。
少なくとも、あなたの考えたUI、機能、データを事前に共有するべきで、開発会社には「ものを作る側としては、こう思うんですよね。」と気持ちを伝えたり、
もしくは「ざっと確認したのですが、大事なところを質問させてもらっていいでしょうか」という回答を期待しましょう。
事前に共有したにも関わらず、「とりあえずお話を聞かせて頂けますか」と言ってくる企業は、少し株を下げましょう。
開発会社やサービス提供ベンダーが、商材の営業のためにやってくる場合を除いて、
王様とものを作る人の間での会議は、
どちらかというとプロジェクト管理上の進捗を定期的に確認する場で、懸念事項を払拭するための議論をするべきです。
もしくは、あまりにも話が噛み合わない場合はお互いの認識をあわせるために会議をしましょう。
ビデオ会議
一般的な回線網想定ですが、通話対象者と普段からよく話している、親しい、とかなら補完が出来るので、有効です。
あまり話した事のない人や、面識のない人は、言外のニュアンスが拾えないのであんまり実用的ではありません。
ボーダーラインは、つながった時に、繋がった人に手を振れるかどうかかな、と思っています。
電話
緊急時を除いて、電話だけでコミュニケーションをするのはやめたほうがいいです。
もし電話で相談をしながらどこまでが出来て、どこまでが出来ないかを探るなら、
決まったことを電話を切る前にどこかに記録し、結論を確認してから電話を切りましょう。
「こういう画面ではこういう機能が必要で、んで、●●を押した時にはあーなってこうなってですね」みたいな事を、口頭で伝えるのは辞めておいたほうがいいでしょう。
受けた側は、それを文章に起こす作業を始めた時点で大体90%くらいは忘れているので、時間の無駄です。
テキスト
最も編集コストが安く、見返すことも簡単なので、基本となる伝達方法です。
何をすると何がおきて欲しいのか、という時系列や条件、懸案事項などを伝えるのは、これが一番適しています。
これをRedmineなどのBTS上で書くことで、質疑を繰り返すのが基本になると思います。
しかし、テキストは情景の描写を読み手の想像力に委ねます。
具体的には、位置関係や形状、色味などを伝えるのには全く向いていません。
(宣伝:Redmineがどうにも好きになれない人や、そもそも好き嫌いとかそういうものか？という人は、是非こちらもご一読下さい)
エクセル
要素が複数横にならんでいたり、帳票形式でデータが整列していたり、というのは、
Webではとても良くある表現方法なので、エクセルで項目の並びや項目名項目や要素を追加する場所を伝えるのはとても効果的です。
また、図形機能が簡単に使えるので、
全く新しい画面の、大まかなレイアウトイメージを伝える用途にも使えますが、
この場合は紙とペンでワイヤーをざっくり書いて、PDF化したものを送るほうが早かったりします。
もちろん、画面キャプチャを印刷して、それに赤ペンを入れてスキャンするのも有効です。
ただし、エクセルも紙も、解像度や文字の大きさの問題から、
Web画面のタイトな要素数をデザインする時にはちょっと向いていません。
折角並べた要素が入り切らなかったりするんで、徒労に終わったりします。
そういう場合は、ワイヤーフレームを作成する事に特化したものを使いましょう。例えば、caccoとか、figma とか。
かなり前に何処かで読んだ記事なのですが、システムエンジニアに、一本だけしかソフトが使えないとしたら何を使うかを聞くと、
ほぼ全ての人が「エクセル」と回答するそうです。
(図形描画が改善されれば、今ならGoogleスプレッドシートと即答なのですけども。。)
計算、ドキュメント、図説、データ処理など、なんでも出来るので、何にでも使えるのですが、
使い方は人によって違うツールでもあり、フォーマットは実質無限にあるということなので、
実は閲覧性や検索性があまり高くはないという事には注意が必要です。
Kibela
KibelaはWikiとブログをクローズドに公開するためのサービスなのですが、
このKibelaでも記載をしている通り、簡単な帳票であればわざわざエクセルを開く必要はないです。
また、ちょっとした概念図のような画像の取扱も得意です。
PlantUMLを利用すれば、
というような図を、
```
{plantuml}
王様->ものを作る人:頼む
ものを作る人->ものを作る人:悩む
ものを作る人->開発会社:説明する
開発会社->開発会社:悩む
```
これだけのテキストで作成することが出来ます。
そんなの何がなんだかわからないよ、という人は、
例えばこういうサービスを使うのもありでしょう。https://www.websequencediagrams.com/
Kibelaも全く万能ではないんですけど、UIの細かい説明以外、大概の事には使えるツールですので、おすすめです。
UML（ゆーえむえる）について
システム開発者が作るプログラムは書き方が同じなのに、
どうしてシステム開発者に伝える情報や図式が人それぞれでマチマチなんだろう、統一しちゃえばいいのに、
という事を誰かが（多分）思いついて、
人、もの、情報などのオブジェクトの関係性を説明する時の共有の書き方として提唱され、普及したものです。
要件を説明するためにはとても便利な考え方なので、一度位は触れてみるのも良いでしょう。
PhotoShopなどの画像加工ソフト
単純にキャプチャした画像を説明用に切り貼りしたりする時には便利です。
最近はフリーでも画像加工ソフトがあるので、何か習熟しておくと良いと思いますが、本職でもない限りは執着優先度は極めて低いです。
通常「〇〇っぽいイメージ」を相手に伝えるのは、
○○っぽいものを作ったり表現するより、
○○を渡す方が早いので、
画像を自分で作って伝える、というのは、1から覚えてまでやることでは全くありません。
伝える力のものさし
王様としてのふるまいとしてUI、機能、データの3軸で説明をしてきました。
何となく、伝えなければいけないことや、やり方のイメージが湧いてくれば嬉しいのですが、
ここでは聞く力と同様、伝える力のものさしをお伝えします。
⑥ロゼッタストーン
Design Rule Index 要点で学ぶ、デザインの法則150 より引用。100には未収録。
シャンポリオンがエジプト古代文字のヒエログリフを解明する際に手掛かりとしたのがロゼッタストーンで、この記事のショルダー記事に掲載した、3種類の言語で同じ事が書かれた石です。
イギリス、ロンドンは大英博物館で展示されています。(展示物はレプリカであることも有名ですね。)
今まで、王様としてのふるまいを説明する例えとして、自動販売機を採用しましたが、
例示の題材としてガンダムを採択し、
シャアザクの角のUIは通信機能を強化するための機能を実現している、
みたいな例示をしても、一部の人を除いて全く意味が分からないと思います。
自動販売機は、ある程度皆さんが知っているので、皆さんの記憶や経験の力を借りることで説明がしやすいのですが、
ガンダムのような一部の人しか知らない人は、その力は一部の人にしか使えません。
という訳で、相手の知っているものに例えて、相手の知識を借りて説明をする、
もしくは、自分が理解出来ない時に相手と自分が知っている別の事に例えて理解を試みる必殺技が、ロゼッタストーンです。
これは、愛と友情のツープラトン系の必殺技なので、
相手の事を理解し、自分も色々な事を知っている必要があります。
教養や雑学など、全ての知識が武器になり、その量で成功率が決まります。
例え話が上手い人、というのは、相手の事を何となく推測した上で、相手のイメージの力を借りて、説明をしているはずです。
初対面の人や、非技術者の方とロゼッタストーンをやる場合、個人的にはスポーツ、特にサッカーなどは技が掛かりやすく、重宝しています。
自分が説明しようとしていることを、相手がどれくらい想像出来るかを想像して伝えるようにしましょう。
その会社の在籍年数、ものをつくってきた年数、王様側の会社の文化・業務・用語の理解度など、
当然ながら均一ではありえませんので、「自分の言うことをなんでも分かってくれる」と思わないほうが健全です。
作る側が納得できるまで、王様は説明しなければなりませんが、
王様は自分が説明したいように説明するのではなく、
作る側が、作る時に迷わなくて良い状態になるまで、説明をする必要があります。
もし、作る側があまり作ることに慣れていないなら、図説や解説など、必要なものを渡す必要がありますし、
もし、作る側が百戦錬磨なら、辿々しい言葉でもきっと何かを作ってくれます。
ただ、じゃぁ作る側が百戦錬磨だと良いのかというと、頼んでないものを作ったり、要件を丸めにかかったり、そういった類の苦労はありますし、逆に慣れてないが故に超丁寧に確認してくれて、欲しいものを作ってくれると言うこともあるので、良し悪しはなんとも言えないところです。
相手の力量は常に意識しましょう。
彼我の戦力差の認識が何よりも重要で、認識にズレがあると、大体二度手間になります。
⑦推敲
このものさしは、引用ではありません。私説です。
そもそも文章を書くというのは、とても不思議な事です。
Twitterの140文字でも、日記でもなんでも、簡易なメモでも、まじりっけ無しの自分が書くのに、文字を1文字も削除編集せずに書き終える事は、殆どないかと思います。
短い文章ですら、
こうかな？ああかな？こういう言い回しや順番の方がいいのかな？と手直しをするという事は、
自分が何を書きたいのか、書いている時には自分にも完璧に分からないという事です。
自分や、自分のアウトプットが完璧ならば、1文字も間違わずに文章が書けるはずです。
そんな人は、まずいません。
むしろ、日記の類は「自分が何を知りたいのか知りたくて書く」ような感覚です。
自分の事ですら言語化がスムーズに出来ないのに、
他人の事はスムーズに言語化出来る道理は、ありません。
自分の考えを書いた文章も、
他人に聞いた話から書いた文章も、
沢山の推敲をする必要があります。
特に、目的→機能→とすすんで、あれ？この作業必要じゃない？と思う事、指摘される事は沢山ありますし、だったら、この機能の方がいいんじゃない？と思いつく事も、沢山あります。
沢山、読み返して、見返して、
自分なら絶対こうするを押し付けずに、
この人は本当は何がしたいのか？を、妥協せずに考え、言葉にして、その人が見たかった少し先の未来を一緒に見て、次にバトンを託すこと。
私は、それが要件定義の面白さだと思います。
本文は以上です。
ここまでの長文にお付き合い頂き、ありがとうございました。
後書き(ポエム)
心構えとして、一つ語っていない事がある。
要件定義は、上達すれば上達するほど、気分的には凄く損をする構造になっている、という話だ。
もしワインだったら、世界一美味しいワインを作れたら、自分はそのワインを飲むことが出来る。
でも要件定義の場合はそれが叶わない。
もし、「自分が世界一の理解力を持つ人」だったとしたら、自分が説明して分かってもらう人は、必ず自分より理解力が劣ることになる。
そして、「自分が世界一説明が上手」だったとしたら、自分に説明をしてくる人たちはもれなく自分より説明が下手ということになる。
構造的には教師と生徒の関係のようなものだ。
しかし、僕らが聞いたり話したりする人は職場の仲間や関係者で、場合によっては先輩だったり偉い人だったりする事もよくある話で、年収給与という単語が脳裏に浮かぶと、心情的には、かなり納得しにくい場面もあるだろう。
「うわー、下手だなこの人。なんでもっと頑張らないのだろう」と、暗い気持ちが湧き上がって、口から出てしまいそうになる時もある。
にも関わらず、逆に、自分より理解力がある人に説明をしたり、自分より説明力がある人の話を聞くのは、どうだろうか。
習熟度が低い時は、隠れてしまいたくなるほどの「成長せよ」という要請に取り囲まれる事になる。
悔しいだろうし、自分なんていなくてもいいような気がするものだ。
また一方で、聞き力も伝える力も整ったら、いよいよ本当の事を伝えなければならない事になる。
本当の事は、明るい話だけではない。
その無謀さや矛盾を説明し、面倒くさがられたり、嫌がられたり、ノリが悪い奴だと誹りを受けたとしても、それは多分うまくいかないとか、現実的ではないとか、誰かのご機嫌を損ねるような事を言わなければいけない時が必ずある。
誰かの壁になるというのは、人によっては感情労働である。自分に不利益がありそうなら尚更だ。
こういう時は、職業倫理が欲しいと思う。
例えば看護師は、ナイチンゲール誓詞を心構えとする。
医師の場合、ヒポクラテスの誓いを心構えとする。
必ず死ぬ命を救うという、矛盾と戦うために編み出された職業倫理の結晶だ。
そういうのが、この業界にはない。
だから、割と気持ち一本で戦っている訳で、辛い。
けども、誇らしいような気もする。
だって、それって開拓者って事だよな、と無邪気に思う。
最後に、僕が支えにしている２つのものに触れたい。一つは、岩田聡さん。
もう一つは、しんがりという小説で知った、聖書の一節。
「患難が忍耐を生み出し、忍耐が練られた品性を生み出し、練られた品性が希望を生み出す」
要件定義は、最初から最後まで、どこまで行っても人間力が試されているような気がする。
だからか、要件定義の最中、ちょっと生きている実感を感じる事がある。
そういう仕事と、そういう生き方を、僕はしたかったんだと思う。
この記事が気に入ったらサポートをしてみませんか？