「面談以降のプロセス(面談･設計･構築など)」に関して構築者が疑問に思いそうな事をまとめました。
なおこのページは以下の2つの「構築者向け説明ページ」からのみ来られるようになっています。
面談以降のプロセスはどちらも同じなので共通ページで対応する事にしました。
主に「求人媒体の募集文から来た方」を前提とした内容になっています。
(そのため募集文以外のルートで来た方には少々違和感があるかもしれませんがご容赦を)
面談の手順や方法がイメージできない…
1回目はZoomなどを使った「WEB面談」がオススメです。
(どの面談ツールを使うかは依頼主と相談して決めるといいでしょう)
なおWEB面談の実施が決定した後はまとめ記事や設計案を念入りに読んでおいて下さい。
これらの記事に設置してある「詳細リンク先の記事」も読んでおく事を推奨します。
直接現場を見ておくべきか？
設計案にあるLINEの中には(依頼主の事業の)現場を見なくても構築できるモノもあります。
そういうLINEなら2～3回WEB面談をしてから設計･構築に入ってOKです。
逆に(設計･構築に入る前に)一度は現場を見ておくべきLINEもあります。
その場合は1回目のWEB面談の後に現場を見に来た方がいいでしょう。
☆その他のルールについて
これ以外のルール(連絡手段･契約方法など)については特に言う事はありません。
面談以降のプロセスは基本的に全て構築者と事業者が相談して決めて頂くモノになります。
ここに関しては以下のようなサイトを参考にした方がいいでしょう。
まとめ
まずはWEB面談から始めましょう。
それ以外については全て構築者･事業者双方が相談した上でお決め下さい。
このブログでは面談以降についての細かいルールの説明は実施しません。
設計案のLINEを構築できる自信がない…
設計案を読んで「自分には荷が重い」「構築する自信がない…」と尻込みした人もいるかもしれません。
しかしそれでも一度は面談してみる事をオススメします。
WEB面談なら交通費も掛かりませんのでコストは一切掛かりません。
設計案は「叩き台」に過ぎない！
LINE構築の前にはまず設計図の作成が必要になります。
しかし設計図は「設計案に忠実」に作成する必要はありません。
設計案はあくまで設計図を作成するための「叩き台」に過ぎないからです。
参照(内部)「『人手不足解消LINE』を構築するための『設計案』とは？」←直接「設計案」の箇所に飛べます
設計案に忠実かどうかよりも「その事業者にキチンと合う」LINEを構築する方が重要になります。
そのため設計案だけを見て尻込みをするのはナンセンスです。
話してみないと分からない事も多い
また「その事業者に合うLINEがどのようなモノなのか」は(その事業者と)直接話してみなければ分かりません。
当初に想定していたよりコンパクトでシンプルなLINEの方がその事業者に合う可能性もあります。
(そういうケースでは構築難易度があまり高くならない)
このように設計案を読んだ時点で想定していたより構築難易度が下がる事も十分考えられるワケです。
現場を見る事も必要
そして設計案のLINEの中には直接現場を見てから構築を始めるべきモノもあります。
そういうLINEについては現場を見てからでないと構築難易度なんて判断できません。
まとめ
設計案を読んだだけで尻込みして面談にすら進まないのはあまりにもったいない話です。
LINEの構築難易度というモノは、事業者と色々話をした後(場合によっては直接現場を見た後)でなければ判断できません。
そのため少しでも興味があるのなら、自信が無くても面談だけは実施してみる事を推奨します。
契約をするかしないかはその後に決めても遅くはありません。
どのくらいの規模のLINEを構築すべきか？
WEB面談で事業者の話を聞いて直接現場を見たとしても「どの位の規模のLINEを構築すべきか」の判断は難しいと思います。
そんな時は「小規模なLINEから始める」のがベストです。
これはビジネスでよく使われる「スモールスタート」の考え方になります。
要は「必要最小限の機能のみを備えたLINE」をまずサッサと構築してしまうというワケです。
スモールスタート
このブログで紹介しているLINEの構築では、いずれも「スモールスタート」を推奨しています。
コレは必要な機能のみを備えた「小規模なLINE」の設計図をまず作成して、比較的短期間で完成させて運用を始めるやり方です。
そして運用状況を見ながら必要な機能をドンドン追加していく方法になります。
つまり「小さく始めてから徐々に大きくしていく」が、人手不足解消LINEの最もオススメな構築パターンというワケです。
最初は「エントリーモデル」から始めるべき理由
パソコンやスマホにも機能を絞った初心者向けモデル(エントリーモデル)があります。
スマホなら最初はエントリーモデルから入って、物足りなくなってから高性能モデルに機種変更するのが定石です。
スマホ初心者が高性能モデルを購入しても恐らく使いこなせないでしょう。
LINEもこれと同じで最初から多くの機能を付けても(事業者は)使いこなせない可能性が高いです。
LINEは完成後にいくらでも増改築ができます。
そのため最初から大規模なLINEを構築する事は推奨しません。
「自分のスキルでも構築可能」なレベルに調整
またその事業者に必要な機能であっても「自分のスキルでは実装が難しい」機能なら除外した方がいいでしょう。
実装される機能は少なくなりますがその分価格(構築報酬)を下げれば問題ありません。
設計図は「自分のスキルでも構築できる」レベルに調整しましょう。
構築の成功確率を上げるには「ムリをしない」事も大切です。
まとめ
設計案にあるLINEの構築では「スモールスタート」が大原則です。
LINEは完成後も修正･増改築ができますので、最初から大規模なLINEを構築しないようにしましょう。
シンプルなLINEを迅速に完成させて短期間で運用を始めるやり方を推奨します。
構築は一人で進めるべきか？(それともチームを組むべきか？)
一般的にLINE構築はチームで進める事もあるでしょう。
しかし「このブログで紹介しているLINE」に限っては一人での構築を強くオススメします。
むしろチームでの構築は全く推奨できません。
いずれも一人で構築可能
このブログで紹介しているのはいずれもシンプルなLINEなので一人でも構築は進められます。
それに(前の質問で言及した通り)最初は小さなLINEから始めるのがベターです。
「一人では完成できないような大規模LINE」の構築自体がオススメできません。
「一人では構築できない」はあり得ない
そもそも「自分一人でも構築できる」レベルに調整すれば「一人では構築できない」という状況は起こり得ません。
一人で進める自信が無い場合は「一人でも構築できるレベル」のLINEの設計図を作成すればいいだけです。
チームのデメリット
チームを組むと(意見の食い違いや衝突など)人間関係の問題が生じます。
そのため「チームを組まなければ進められない大規模なプロジェクト」以外は、一人で仕事を進めた方が合理的であると私は考えます。
初期段階での豊富なアイデアはむしろジャマ
「チームで仕事した方が豊富なアイデアが手に入る」と言いたい人もいるでしょう。
しかし「小さなLINEの構築」に豊富なアイデアは必要ありません。
それどころか(豊富なアイデアは)「初期段階からLINEをムダに大きくしてしまう」リスクをはらんでいます。
(不要な機能をゴテゴテ付けたムダに大規模なLINEのイメージ)
チームのメリットが逆に「デメリットに転化」してしまうというワケです。
まとめ
このブログで紹介しているLINEは理論上「必ず一人で構築できる」ハズです。
最初はチームの力に頼らず自分一人の力で構築できるようになりましょう。
事業者とはどう協力し合うべきか？
LINEはその事業者にキチンと合ったモノを構築する事が大切です。
そのためには構築者と事業者が協力してLINE構築を進めていく必要があります。
とは言えあまり念入りにやるのはオススメしません。
ヒアリングはザックリでOK！
LINEの設計に関しては「ヒアリング」が欠かせませんが、ザックリとした質問をいくつかするだけで十分です。
(回答フォームではどんな事を聞きますか？外国語表記はどの言語を選びますか？など)
このような方法では事業者の要望が十分反映されないかもしれません。
しかし「スモールスタート」のLINE構築ならそれで十分です。
☆完璧主義はNG！
逆に十分にヒアリングしてキッチリ作り込むのはオススメできません。
LINEは完成してからでも修正･増改築ができます。
最初は(ザックリとヒアリングした上で)シンプルなLINEを迅速に完成させた方が合理的です。
初期段階で「完璧主義」に陥ってしまうといつまで経ってもLINEを導入できません。
構築前ではヒアリングの効果が薄い
そもそもLINE構築前の時点では念入りなヒアリング自体が実施できないでしょう。
(まとめ記事や設計案を読んだ後とは言え)事業者はLINEについてほとんど何も知らないからです。
LINEについて具体的なイメージができない状態では的確な意見など期待できません。
しかし実際にLINEの運用を開始した後なら話は別です。
事業者はLINEがどんなモノなのかを実際に見ているので的確な意見が期待できます。
この点においてもLINE構築前に念入りなヒアリングを行うのは効果が薄いと言えるでしょう。
まとめ
スモールスタートでLINEを構築するならザックリとした協力だけで十分です。
大まかなヒアリングで大体の方向性を聞いたら迅速に完成させましょう。
文章作成における協力についても教えて！
文章作成においても構築者と事業者の協力は重要になります。
こちらもザックリとした協力で十分です。
事業者の意向を聞いた上で構築者が文章を作成して、仕上げ段階ですり合わせるやり方がいいでしょう。
参照(内部)「構築者と協力してLINE文章を作成するメリット2選｜人手不足解消の基本③」←直接「協力」の箇所に飛べます
☆労働環境改善に関する注意点
「労働環境改善のための文章」を作成する際は一定の注意が必要になります。
参照(内部)「LINEを用いた労働環境の改善法｜人手不足解消の基本②」
参照(内部)「構築者と協力してLINE文章を作成するメリット2選｜人手不足解消の基本③」
事業者の意向を尊重し過ぎると「改善効果が望めない文章」になる可能性が高いからです。
労働環境を根本的に改善するには(その事業者が抱える)お客さんに対して、かなり厳しい事を言わなければならないケースもあります。
(過剰サービスは全て廃止する･強硬なカスハラ対策を実施するなど)
しかし(その事業者に)「お客さんとのトラブルを避けたい心理」が働いてしまうと強く言えなくなってしまいます。
そういう状況で事業者の意向を尊重してしまうと文章が弱腰になる事は目に見えています。
(これでは労働環境改善の効果が期待できない)
そうならないためには構築者が強気にリードしてあげる必要があると私は考えます。
尻込みしている事業者を説得しながら文章作成を進めていきましょう。
事業者の意向は常に尊重すればいいというワケではありません。
まとめ
文章作成でも事業者との協力は重要になります。
しかし労働環境改善のための文章作成では構築者が強気でリードするやり方がベターです。
事業者の意向を尊重するよりも労働環境を根本的に改善する事を優先して下さい。
遠方の事業者にはどう対応すべき？
「案件の内容には興味あるが遠方の事業者なので現場を直接見るのは厳しい…」
このようなケースも確実に出て来るハズです(構築者が東京在住で事業者が大阪在住など)。
現場を直接見なくても構築できるLINEなら問題は無いでしょう。
しかしこのブログには「現場を直接見なければ適切な設計ができない」タイプのLINEもあります。
そういう場合は移動距離がネックになってせっかくの案件が受注できなくなる事も考えられます。
話していく内に「突破口」が見える！
しかしこういうケースでもWEB面談だけは実施した方がいいでしょう。
話を進めていくと「意外な突破口」が見えて来る事もあるからです。
そもそも「現場を見る必要があるかどうか」は事業者ごとに判断する必要があります。
画一的に「○○業向けLINEは現場視察が不可欠」と早合点する事はオススメしません。
宿泊業の例
例えば「(このブログの)宿泊業向けLINE」については「(基本的に)現場を見ておく必要がある」と設計案に記載しています。
しかし宿泊施設の規模･種類･形態などによっては現場を見ずに構築する事も可能です。
いざ(WEB面談で)話してみると「ここの宿泊施設では現場を見なくてもLINEを構築できそうだな…」と気付けるケースもあるかもしれません。
LINEをシンプルにする
ちなみにLINEは作り込もうとすればする程「現場を見ておく必要性」が上がります。
そのためシンプルなLINEであれば現場を見なくても十分構築可能です。
(宿泊業向けLINEの設計案でも「シンプルなモノなら現場を見なくてもOK」と記載)
つまり敢えてLINEをシンプルにする事で「現場を見なくても構築できる」ように設計する事ができます。
「スモールスタート」の方針ともマッチ
そもそもこのページではしつこいほど「スモールスタート」を推奨しています。
そのため最初は「現場を見る必要のない」くらいの小規模なLINEを構築する方がいいでしょう。
まとめ
遠方の事業者というだけで(興味のある案件を)諦めるのはオススメできません。
(事業者から)話を聞いてみると実は「現場を見ずに構築できるケース」だったという事もあり得ます。
また敢えてLINEをシンプル化する事で「現場を見ておく必要性」を下げる事も可能です。
早合点せずにまずはWEB面談だけでも実施しましょう。
設計案にはどこまで沿うべきか？
既に述べた通り設計案は「叩き台」に過ぎません。
そのためLINE構築は設計案に忠実に進める必要は特にないとも言えます。
マッチング後は自由に決めてOK！
そもそもこのブログ(及び設計案)の主な目的は「事業者と構築者のマッチング」です。
参照(内部)「『人手不足解消LINE』を構築するための『設計案』とは？」←直接「マッチング」の箇所に飛べます
両者を引き合わせて世の中の案件数を増やすためにこのブログを考案しました。
そのためマッチングが終わった後にアレコレ細かく指示するような事はしません。
基本的には構築者･事業者双方の意思に全て委ねられます。
ある程度は設計案に沿った方が無難
とは言え事業者は設計案を見て「こういうLINEを導入したい」と思ったハズです。
そのため原則的には「設計案にある程度沿った」構築をオススメします。
設計案に沿わないやり方は「その設計案がその事業者に全く合わない」といった例外ケースに限定した方がいいでしょう。
設計案に沿わないやり方とは？
「設計案に書いていない機能を大幅に追加する」などが考えられます。
ただしこれはスキルに自信のある構築者向けの例外的な方法です。
そのため私の方から積極的に推奨はできません。
スキルに自信のない場合は「案件の辞退」を考えた方がいいでしょう。
☆責任の所在についての注意点
ここまで読んだ方ならお分かりかと思いますが「設計案の良し悪しを判断する」のは構築者の責任になります。
そのため仮にLINE構築が上手く行かなかった場合であっても「設計案が悪かったからこうなった」といったクレームはご遠慮願います。
①どこまで設計案に沿うべきか？
②自分のスキルでそのLINEを構築する事はできるのか？
③そもそもこの設計案はこの事業者に本当に合っているのか？
こういった判断は全て構築者の判断･責任の下でやって頂く必要がございます。
仮に設計案の質が悪いと思われた場合は、案件を辞退するなどのご判断をお願いします。
☆まとめ
設計案はあくまで叩き台でありマッチングツールです。
決して「この通りにLINEを構築して下さい」と指示するモノではありません。
設計案をどのように利用するかは基本的に構築者の意思に委ねられます。
そのため「設計案に欠陥があったからLINE構築が上手く行かなかった」といった類のクレームは一切受け付けておりません。
その点だけはどうかご理解頂けますようお願い申し上げます。
その他
構築者向けQ&Aは以上となります。
ここに記載されている事項以外については、基本的に全て構築者･事業者双方の相談により決めて頂くモノとなります。
それでもご不明な点があるのなら「問い合わせフォーム」からお願いします(現在開設中)。
なお価格(構築報酬)に関するご質問については受け付けておりません(現在考案中)。
このページは以上になります。
以下のいずれかのページにお戻り下さい。