読者です 読者をやめる 読者になる 読者になる

笑顔を創りたいWeb屋の日常

某事業会社勤務のWebディレクター。つまり「なかのひと」やってます。Web業界からひょんなことで専門学校の先生に。そしてまたWeb現場に戻ったWebディレクターのブログ。情報デザインやWebの勉強をしています。

中小企業や個人経営規模相手のWebディレクションで気をつけている15のこと。

【スポンサーリンク】

あくまで”僕が”です。そこ大変重要ですw

僕もまだまだ勉強中で、これが全て正しいと思えるほど見極めていません。

他にもあるだろうし、もっと大事なものもあるかもしれません。

それは各々考えてもらって(もしよろしければ教えていただいてw)、とりあえず同タイプの仕事している人の叩き台にでもになればなと思って挙げてみた次第です。

 

というのもですね、僕はWeb屋としてみるとなんか物凄く変な経歴・経験をしている人なのですねw まあ、Web業界って割と他業界から来る人たくさんいますけどね。僕は印刷会社→大手Web制作会社→専門学校教員(正規職員)→弱小ITベンチャーなので、なかなかこういう奴はいないと思いますw 教員とか普通はできませんからね。で、こうやっていろいろな企業をさすらっているおかげでw ひとつの企業にいる人ほどその企業のことはわかりませんが、逆に比較する対象が広いのでそれぞれの立ち位置や考え方、得手不得手なんかがたぶん同世代の人より見えている気がします。

 

そういう見地から、クライアントと応対するときに重要なことって言うのが僕はどうやら同業者とちょっと違う、雑種な知識なんだなと最近思い始めて、それをまとめてみようかなと思った次第です。で、特に思うのが、今まで経験したことのなかった中小企業や個人経営規模のクライアントとの折衝の難しさ・・・。リテラシーの高い大企業相手も大変ですが、こちらはこちらで難しいですほんとに。特に、今の会社はWeb事業を再構築しているところで僕が呼ばれたので、1~10まで全て僕が判断して動かなければいけません。ワークフローもなければ、見積り一つ(Web制作用のは)ない状態です。スケジュールも、工程管理用の資料も、議事録フォーマットもないという・・・。僕は今までそういうものが当たり前に既にある組織に居てきたので、しんどかったですね。でも、そのおかげで勉強になったこともたくさんあります。

 



 

というわけで、前置きが長くてすみません。

最近、僕なりに意識してきた中小企業や個人経営規模相手のWebディレクションで僕が気をつけていることをまとめてみました。あ、ちなみに具体的なワークフローの話ではありません。その手の話は業界の超有名な会社さんとかが書籍にして出しているのでそちらを参考になさった方が早いと思いますw

※あくまで発展途上ですからね・・・

※大手さん向けではないです。大手制作会社の方はもっと緻密にやってると思いますし。

※とりあえずサイトの種類は限定してません。ECでもコーポレートでもまんべんなく・・・。

 

【1】 ヒアリングシートを事前に出す

出しましょう。RT:(誰)

僕は初回訪問のための連絡を入れたあとにすぐ送ってます。

パートナーの制作会社のディレクターと打ち合わせに行くと、これをしていない人がいて僕はびっくりします。

中小企業や個人商店規模の方は基本的にWebサイトの事など詳しくありません。ビジュアルや目新しい機能以外には「こういうことをしようと思う」なんて持ってる人はいません。「とりあえずつくる」とか「そろそろ必要だと思ったから」っていう程度の方はたくさんいます。そういう方は、そもそもWeb制作会社に何を伝えればいいのかというところから真っ白です。

現場でならしまくってる(謎)デザイナーさんやディレクターさんは自身のヒアリングテクニックに自信を持っていて、シートなんかいらないと思っている人もいるみたいですが、問題はそういうことではないです。ヒアリング以前に、相手側の方にその場で聞かれてもわからないことがたくさんあります。何を聞かれて何を答えるかもわからないから、当日までに準備をすることもできません。何の準備もしていない状態で質問されても・・・となります。

 

また、ヒアリングシートの内容自体が、実はこちら側の考え方の紹介になります。質問をするということは、こちらが何を知りたいのか=何を考えているのかを伝えることですから。その辺のヒアリングシートの効能については、過去エントリ「クライアントヒアリングに対するヒアリングシートの重要性。」を読んでみてください。

 

ヒアリングシートの内容については?というのは、後に少し触れます。

 

 

 

【2】 前日までにアジェンダを送る

ヒアリングシートと同じ意味もあるんですけどね。

上記の通り、相手は僕らWeb屋の素性など全く知りません。(むしろちょっとウサン臭い)

だから、「打ち合わせ」と言われても「いったい何を話してくれるのだろうか・・・」と思っています。一部はヒアリングシートが解決してくれるものですが、当日の具体的な打合せ内容などはわかりません。当日何を話して、何を決めるためにWeb制作会社の奴はウチまでくるんだ?ということをきちんと教えてあげないと、とりあえず出会う前までは間違いなく「よくわかんない業界のパソコンに強い奴が御用聞きに来る」としか思ってくれません。それを少しでも緩和しないと、後がきついです。

 

 

 

 

【3】 手ぶらで打ち合わせに行かない!

自分のメモ帳とか、貰っているメールの出力だけしか持ってこないフリーランスのデザイナーさんとか、良くない!w

相手が熟知していて何でもほいほい言ってくれるならいいですけど、基本はそれすらわからない方々ですから。ラーメン屋に入れば「とりあえずラーメン選べばいいんでしょ」って誰でもわかりますが、ジンバブエ料理って言われても、何をどう頼んでいいのかすらわかりません。なので、相手が頭にあること(というか実はあるんだけど意識できてないこと)を引っ張り出していく必要があります。だから、そのためには当然、どんなビジネスをしていてどんな競合がいるのかを聞いておき、それについて喋ってもらわなければこちらもわかりません。(そのためにもヒアリングシートはできれば前々日ぐらいまでには返答してもらうのが良い)

 

なので、競合他社を事前に調べておく、同じ業界の有名企業サイトを見ておく、他の事例になりそうなものを見ておく、それら全てを出力して持って行くということが重要だと思います。目で見えるようにして「競合ですとここでしたね」「こういうサイトもあります」という風にアプローチしないと、相手は何を答えて良いのかわからず、思考が進みません。相手の思考を活性化し、会話を引き出すためにも目に見える、手に触れられる状態のものを用意すべきと思います。(サイトの出力だけじゃないですよ。事例集とか、レイアウトサンプルとかいろいろあると思います。それこを相手によって変えるべきと思います)

 

 

 

 

【4】 ワークフローを必ず「対面」で「資料」をもとに説明する

中小企業や個人経営規模のクライアントはWeb制作のことなど(ry

「どういう風に勧めて、どういうときに何を決めて、どうやって公開するの?」ということは全くわかりません。

 

先が全く見えない状態では不安になるのも当然ですし、いつ何を決めて何を提出すればよいのかわからないと、逆に決めるべき時にそれが決められなくて変更したくなるのもある程度仕方のない話です。何を創るのかわからない状態で料理の手順だけその都度その都度教えられているようなものです。ですから、キックオフ~公開まで、そしてその後の流れなど、制作の流れを相手がわかるように伝えなければ、相手は納得して任せてくれません。そして、ここは絶対に資料で、絵で伝えるべきです。口頭でも伝えられますが、基本的に僕らWeb屋の言うことは「何を言ってるんだかよくわからない」と思われているので、噛み砕いて話しても相手にかなり集中力を要します。そうすると、口頭で聞いてもその時の吸収力には限界があるし、時が経つに連れほぼ必ずぬけます。かならず、フローの図や文章などを持って説明し、後で見返せるようにしておかなければすっかり忘れてしまい、こちらが後で痛い目を見ることになります。(まあ、こちら云々以前にいつでも見れた方がクライアントのためにも良いですしね)

 

また、この時に工程の戻りができないこと、その理由もきちんと明記しておくと手戻りを要求された時のリスク回避にもなります。

ワークフローの資料はクライアントの種別によって変わるようなものではないはずなので(仮にフローをショートカットするにしても、ベースとなるのは同じはずですよね)、一つあれば事足りるはずです。初めに一から創るのは大変ですが、一度作ってしまえばずっと使えるので、初めに頑張って作ってしまうと良いと思います。

 

 

 

【5】 「とりあえず一旦インターネットの話は忘れてください」と言う

相手にもよりますが、相手に意欲があればあるほどこの言葉を言います。

そもそもWebサイトのあるべき設計というものがビジュアルデザインやUI設計から始まるべきではないですし、エイヤッ!と進めるにしてもビジネスの根拠を聞かないことには何も始まりません。どんなビジネスをしていて、お客様はどういう方で、競合はどこで、優位性や弱点はどこにあり、どういう雰囲気を持っているのかなど、まずはビジネスの話から聞きます(ウサン臭い奴が来たと思っている相手の口を饒舌にする目的もありますw)

 

ただ、そこから大規模な調査や仮説立案での提案は僕はしていません。(ま、ユーザタスクフローぐらいは考えますが)

当然のように、時間と、何よりも予算が無いからです。慈善事業なら是非にも大規模な調査をして戦略策定書でも出してあげたいところですが、それをするほどの予算は相手にはありません。また、相手がその調査や仮説の重要性を理解するのも非常に手間と時間がかかります(大企業の経営企画部や広報とは全く違うタイプの方々ですから)。つまりオーバースペックだと思います。その辺は過去エントリ「最高のWebサイトを創る必要などない。」を読んでみてください。

 

では、なぜにビジネスの話から始めるかというと、根拠を持たせて覆らせないためです。

経験則ですが、Webサイトにヤル気があればあるほど、ビジュアルや機能を気にします。そして、それは時々刻々と変わります。要するにネットの世界の流行や美的センスの流行なので変わるのが自然です。そういうクライアント相手に「どんなデザインが良いでしょう?」というスタンスで望むと、デザインの修正が多くなったり、修正を重ねてみたら当初と真逆か、もっと悪くて一周して元に戻ってることがありますw それを避けるためには、常にビジネスを起点に考えてもらうことです。バナーの配置場所や数にしても、コロコロと変わる人はたくさんいますが、「いつ、どんな時にキャンペーンや催しをやるのか」ということビジネスそのもの話がが本来先にあるべきで、その頻度や質によってバナーの設置場所や大きさは決まるはずです。そして、それはポンポンと変わるものではないはずです。(はず・・・)

 

ですから、僕のヒアリングシートも基本的にはビジネスのことを中心に聞くようなものにしてあります。相手によって画面レイアウトやテーマカラー、参考サイトなどを盛り込むこともありますけど、あくまで中心はビジネスの話です。

 

 

 

 

【6】 「ユーザ」という言葉は使わない

なぜなら、「ユーザ」とは「PCの前に座ってネットしてる”だけの”人」だと思われてしまうから。

いや、実際のところそれは間違いではないのですが、その人は列記としたお客様です。

Webサイトという店舗や事務所に来ていただいた、丁重にもてなすべき、大事な大事なお客様です。これを理解しないと、ビジネス起点の話も頭に入れてもらえません。「PCの前にいる人をどうやって釣るか」という煽るようなことばかり考えてしまうものです。ですから「御社のWebサイトに来るユーザはお客様です」ということを理解してもらうために、そもそも「ユーザ」という言葉を使わずに、僕は「お客様」と言うようにしています。詳しくは過去エントリ「「ユーザ」という言葉はなるべく使わないようにする。」にて。

 

 

 

 

 

【7】 Web、ビジネス理論の場合は「いいえ」と言わない

例えば「最近のWebではFlashがいいんだよね」とか「こういうサイトが良いサイトだよね」と、クライアントから言ってくれることがあります。それが正しいのであれば全く問題はないのですが、得てして全く違う業界の、全く違う規模の企業のサイトを見て言っていることがあったり、むしろそれはもう古い・・・というようなことも往々にしてあります。僕は以前、物凄いニッチな業界の企業のサイトを創るときに「敢えて情報を載せないで、これはなんだ?って興味をひかせて問い合わせさせるべきだと思うんだよね」と言われたことがあります(っていうか多いです)。必ずしも全ての情報を晒すべきとは言いませんが、そもそもその商品を全く知らないような人がターゲットになるのに、それでは問い合わせは来ませんよね。でも、否定は出来る限り避けます。「なるほど、確かにそういう方法もありますね。例えば~・・・そうした場合に、御社の場合は~」などと、否定せずに伝えたいことを伝えるようにしています。

 

基本的にウサン臭い若僧だと思われているので、そんな輩から正論だろうがなんだろうが否定されると相手の立場がありません。信用してもらえなくなります。「結局あいつら主導で進んで俺の意見は入ってない」と思われることは絶対に避けなければいけないですよね。なので、否定は出来る限り避けます。ただ、スケジュールや納期など否定しなければいけないものはきちんと否定するべきと思います。それはまた別の話ですね。

 

 

 

【8】 壮大な話はさせる・広げる・先延ばしにするw

ビジネスの話をすると陥りやすいのがこういうところですw

相手が自分のビジネスを語りだしてくれて饒舌になるのは良いのですが、そうするとあれもこれもとやりたいことが増えます。どう考えてもそこまでやって、仮に費用を出してくれても投資回収が不可能なものもあります。しかしだからと言って無理なものだからとその話をストップさせてしまうと結局クライアントは(´・ω・`)ショボーンとなってしまい、納得のものができなかった!となってしまいます。ので、そういう話は思う存分してもらうべきだと思っています。当然、あまりに夢のような話は規模が合わないことを伝えるべきですが、代替手段は大概あるものです。それを提供して、やろうと思っていた目的を損なわないように拡げていきます。

 

当たり前ですが安易に「できます」とは言いません。「できます」というとそれは今回の公開に合わせて「できる」となるので、「お時間はかかりますが~技術的には~」と付け加えます。そうしてビジネスに対して広がった話は、とりあえず大きなサイズなので、そこから公開日と予算に合わせて機能を厳選すればよい話です。そして、外した機能やコンテンツは、公開後にじっくりとサイトの動きをみながら進めて完成させればいいと思いますし、そう伝えます。相手も予算があるので、「いきなり全部できないと公開できない」ということは避けたいはずなので、ある程度は納得してくれます。(ダメな方もいますが・・・・)

 

 

 

 

 

【9】 スケジュールは必ず公開までひく

ワークフローと似たような話なのですが、結構これをやらない人がいて驚きます。

デザインをスタートしたらデザイン案提出日を伝え、デザイン案を提出したらその時に修正返答の期限を切ったりと、タスクごとにその場でその都度納期や期限を決めてやる方法は、僕はどうかなぁと思います。確かにそれであれば柔軟に対応できますが、柔軟な分公開日は全く読めません。相手にしてみれば突然デザインを出されて「○日までにと言われても・・・」となったり、クライアントの中には「お金払って頼んでるんだから自分は何もしなくて良い」と思っている方もいるので、堂々と出張に行かれたりしてwつかまらなかったりします。

 

仮に、常に捕まったとしてもこのやり方では公開までのスケジュールが見えないので、突然「いったいいつになったら公開するんだ!」と怒られてしまうこともあります。ですから、必ず公開日までの両者のタスクを出来る限り細かく洗い出し、「いつまでに誰が何をどのようにいくつやるのか」を日付け、時間ベースに落としこんで共有すべきと僕は思います。また、そうすることで、相手も「なるほど、オーダメイドだからこちらも動かなければいけないのか」「ふむふむ○日と○日は予定を空けておかなければいけないわけだ」と理解してもらえます。

 

 

 

【10】 すべての資料には必ず確認期限をつける

デザインやテストアップの期限は当たり前に切るのですが、僕はスケジュールも議事録も原稿管理も全て期限は必要だと思います。というより、スケジュール、議事録、コンテンツプラン全てメールで渡したとしても相手がずいぶん後になって「俺はこれで良いとは言ってない!」と言われたらアウトです。資料は全て「これでいい」という回答をもらって初めて「共有」ですから、そのためにもまずは期限を切るべきと考えます。最悪、期限までに連絡がなく音沙汰が無い場合に備え、「○日までにお返事をください。いただけない場合にはこちらを確定とします」とお伝えすることもあります。「スケジュール提出」や「作成」というスケジュール確定前ののスケジュールはどうするんだという卵が先か鶏が先かみたいなものもあるのですがw そこは直近の予定としてメールベースの段取りでも良いのかなと思います。

 

 

 

【11】 最終決定者を「確認」「共有」する

これは大事でございます(何)

だいたい、きちんと組み立てて管理して進めても覆る時は、社長の一声です(笑)

これは、そもそも合意を取り共有をして進めるという時の対象者を誤っているんだと思います。

であれば、本来ならば打ち合わせや確認には必ず社長を同席いただいて進めるのが本筋です。しかし、基本的にウサン臭い下請け業者だと思われている、思っている社長さんだと、まずそう簡単には会ってくれません。「担当者レベルでやれ」という話がほとんどです。でも、サイトができる頃にはヌッと顔を出して、口までもたくさん出していただいてしまいます(泣)。こういうクライアントに備え、僕はキックオフの時に必ず担当者の方に確認をします。「意思決定者はどなたですか?」と。しかしここで終えてはいけません。大概担当者は、この案件をハンドリングする人の事を聞かれていると思って「私です(キリッ」と答えます。それを鵜呑みにすると、鶴の一声が待っていますw

 

なので、付け加えて「御社のオーナー様はご確認なさらないのでしょうか?」と聞きます。すると質問の意図を理解して「ああ、社長も見ます。最後に見ると思います」という回答が来るので、すかさず・・・

「必ず都度確認をとって進めますが、確認を取るということは後から変更が難しいということです。」

「基本的にこのフローを遡ると工数が嵩み別途費用をいただくこととなります。」

「フローの終わりごとには必ず最終決定者の方の確認もお願いします」

(このためにもワークフローはきちんと説明すべき)

と伝えます。

 

そうすれば担当者も理解して動いてくれますし、こうしないとスケジュールも担当者の方のみおさえれば良いと思われて、意味をなさなくなります。ただ、それでも覆ることはあります。担当者自体が社長とのコンセンサスが取れず、社長が言いたい放題の会社ですね。そういう会社は、もうお手上げですので、諦めます(笑)「赤字になるので、公開後はそっと手を引こう・・・」と決意しますw

 

 

 

 

【12】 アウトプットの種類・量を明確にする

Webサイトを作るからと言って、提出するのはWebサイトだけではないと思います。

いや、「Webサイト」にせよ「公開用HTMLデータ一式」なのか、「デザインデータまで」渡すのかは違うと思います。もちろん、サイト自体のページ数も違いますよね。だから、見積もりによくある「一式」というのは僕はあまり良くないと思ってます。見積りとしてのユーザビリティが悪い。どれにいくらかかるかというのを把握してもらうのも当然大切ですが、その中で取捨選択を相手ができないのであれば見積りの意味が無いと思います。メールに金額書いても同じですから(法律的にはダメでしょうけど)。最終的に納品するのは何を、どれくらいで渡すのか、明確にしておくべきだと思います。納品物に限らず、デザイン提出時や、その他プロジェクト管理用の資料にしても同じですけどね。

 

 

 

 

 

【13】 貸しは「作って」「伝える」

作業的に簡単にできること、余裕が出てできそうなことは、他のお仕事に影響しない程度ならやった方が良いと思います。というか、それをすることによるバックが大きいというか。ボタンをもう一つつけてあげるとか(どんな時だ?w)、類似のバナーやナビゲーションなら他のページも一緒に対応してあげるとか。そして、それは、きちんと伝えるべきだと思います。日本人というのはどうも自分を売る、こちらの恩を伝えることを嫌いますが(恩着せがましいってね)、やってあげたことはこちらの善意ですから、善意でやったことは正直に伝えた方が相手のためにもなると思います。もちろん、善意で、サービスでやったのですから普段はやらないこと、費用がかかるということを伝えることが大事ですよね。いつもそれができると思われたら相手もこちらも損をしますから。これを少しずつでも積み重ねると、仮にこちらがミスをした時でも笑顔で許してくれたりしますw あとはできないことはできないと伝えた時、納得してもらいやすくなります。

 

 

 

 

 

【14】 全ての報連相はメールにする(≠メール”で”する)

電話で話したこと、打ち合わせで話したことなど「不可視」なものは絶対に「可視化」するべきです!だって人間は忘れっぽいからー!w これは、僕はどんなに小さな事でもするべきと思います。これにはもちろん「履歴を残す」というリスクヘッジがありますが、それだけではないですね。相手がきちんと可視化した情報を受け取る、ということが大事だと思っています。

 

口頭で伝えたことというのは、実は結構曖昧だったりすることもあり、言葉に、テキストにしてみると「ん?あれ?これ話し合ったが、○○が決まってないじゃん?」ということに気づきやすくなります。打ち合わせの予定などは、僕は電話を切ったらすぐにメールにして送ります。日付や曜日違いはあまりないですが、14時と午後4時はよく間違います(笑)そして、間違う可能性があるからこそ、例えばクライアントは電話で受けても「えーっと・・・あれ?打ち合わせって16時であってたっけ・・・」となることもあります。人間ですから。メールを送っておけばあとで見返せますし、自分のメモではなく相手から来たメールなので安心して信じることができますよね。

 

ちなみに、議事録はこれの最たる例ですね。

打ち合わせのあとは基本的に出すべきと思いますが、”議事録”と銘打って流すほどのものではない時は僕はメールで済ますこともあります。

 

 

 

 

 

【15】 常にたくさんのWebサイトを研究する

大企業相手の場合はWebのリテラシーが高いので、むしろマーケティング系や広告の話になりやすいですが、中小企業や個人経営規模の場合は、Webサイトに明るくありません。ので、売れているサイトも、売れている理由も知りません。それぐらいわからない中で、有名じゃない制作会社に依頼してくれています(っても、大手制作会社のこともきっとご存知ないですけど)。何がどう売れて、どうしてそうなっているのかということを、きちんと伝えないと信用してもらえません。デザインやHTML/CSSなどの技術以前の問題です。相手は、僕らを「Webなら何でも知ってる人」と思っています。わからないことはわからないでしょうがないことですけども、基本的にはレスポンス良く、的確に、情報豊富に答えられないと簡単に不信感を持たれてしまいます。

 

その時、やはり重要なのはいかにたくさんのサイトを知っていて、事例を持っていて、根拠を語れるかどうかという引き出しの多さが必要になります。だから、ただただWebサイト眺めてたってダメで、サイトデザイン、UI、一つのボタン、一つのラベリングまで「どうしてこういう風になっているのだろう」ということを考えながら見ないと蓄積がないと思います。逆に、それを蓄積していけば、クライアントが質問してくれたときに大概の事は答えられます。むしろ、少なくともクライアントとの折衝だけならHTMLやjsの最新技術なんかよりずっと、身近な隣のサイトのデザインの理由、ボタン配置の理由、グラデーションの理由を語り、自身にとって適切不適切を語ってくれる方が信頼を得やすいと思います。

 

これは僕もまだまだ足りないなと思うんですけどね・・・・。日々勉強ですね。

 

 

 

 

 

 

 

 

 

 

以上です。

うわー長い。

ドバーッと書いたらスゴイ長い。

10個のつもりだったのに15個になっちゃったし・・・・。

っていうわけでリスト化。

 

【1】 ヒアリングシートを事前に出す

 

【2】 前日までにアジェンダを送る

 

【3】 手ぶらで打ち合わせに行かない!

 

【4】 ワークフローを必ず「対面」で「資料」をもとに説明する

 

【5】 「とりあえず一旦インターネットの話は忘れてください」と言う

 

【6】 「ユーザ」という言葉は使わない

 

【7】 Web、ビジネス理論の場合は「いいえ」と言わない

 

【8】 壮大な話はさせる・広げる・先延ばしにするw

 

【9】 スケジュールは必ず公開までひく

 

【10】 すべての資料には必ず確認期限をつける

 

【11】 最終決定者を「確認」「共有」する

 

【12】 アウトプットの種類・量を明確にする

 

【13】 貸しは「作って」「伝える」

 

【14】 全ての報連相はメールにする(≠メール”で”する)

 

【15】 常にたくさんのWebサイトを研究する

 

 

 

他にもまだあるかもしれませんし、もっと重要なものもあるかもしれません(二回目)

「当たり前のことばっかじゃん」っていう方もきっと居ると思いますが、まあ、当たり前のことを入れないと今度は「当たり前のことが入ってない」と言われるので・・・w それと、大手制作会社さんはもっともっと緻密にやっていると思います。同じようにできたら最高なのですが、そこまでやってると予算が守れない・・・。限られた予算の中で、相手の理解度に合わせていかにディレクションするかというテーマです。

 

これをやれば間違いない!というわけではありません。

ダメなときはダメですw

でも、初めてのタイプのクライアントで僕も失敗を繰り返してきて、一つずつこういうことを意識したら確実に変わったのも事実なので、やっていないのならやった方が良いとは思います。

 

 

ま、ご参考までに、ですね。

 

【関連するエントリ】

Web屋&元教員が思う 複数の内定を取るための新卒就職活動 18カ条。