ワークフローサンプル: 販促イベント

ラベル 販促イベント の投稿を表示しています。すべての投稿を表示

ラベル 販促イベント の投稿を表示しています。すべての投稿を表示

前回、「イベント参加者アンケートに回答期限を設定」では、サービス工程を利用して『7日後に締め切り』をセットしました。アンケートに期限を設けることで、未回答であった場合にも、業務プロセスが滞留し続けることを防ぐことができます。

[イベント受付フロー-アンケート（期限セット）]

『7日後』の設定には、データ設定式を利用しています。
「#now.addDays(7)」と書くことで、「回答期限設定」工程にトークンが到着した時点（#now）から『7日後』を「回答期限（日付）」にセットすることができます。

＜「回答期限設定」設定画面＞

日付日時を表すデータ設定式には、他にも、

・2時間30分後：#now.addHours(2).addMinutes(30)
・月末：#now.getLastTimeInMonth()
・翌月5日：#today.getFirstTimeInMonth().addDays(4)

といったものがあります。
（他のデータ項目でも「データ設定式」を利用可能です。詳細は「M227: 業務データの結合や四則演算が自動実行されるように設定する」を参照）

続きを読む »

前回は、「少人数セミナー」といったイベント受付を行うためのワークフローに、イベント開催後にアンケートを行うための仕組みを追加しました。参加者にアンケート回答してもらい、イベントの感想やフィードバックをもらうことで、次のイベントをより良いものに変えていくヒントになります。

ただ、前回のワークフローでは「アンケート回答されるまで待ち続ける」必要がありました。全ての参加者がすぐにアンケートに回答してくれたら、業務もスムーズに進みますが、残念ながらそういう訳にもいきません。（自分も含めて）アンケートに回答しないときもありますよね。。。

ということで、今回は、「アンケート回答に期限を設ける」ようにワークフローを改良します。期限を過ぎても回答がない場合、案件は自動的に終了するようになっています。

[イベント受付フロー-アンケート（期限セット）]

続きを読む »

前回は、「少人数セミナー」といったイベント受付を行うためのワークフローを紹介しました。

担当者によるメール対応を卒業し、受け付けの仕組みをワークフロー化しておくことが、A. データ管理、B. フロー改善、の視点からも望まれます。

イベントが無事に開催された後には、参加者にイベントの感想やフィードバックを聞きたいものです。参加者の声を聞き、次のイベントに反映することで、「イベント開催業務」自体もカイゼンしていくことができます。そのイベントが、セミナーであれば、セミナー内容の見直しにも繋がりますね。

「イベントアンケート」収集用のワークフローを準備して、回答用URL（フォーム開始）をイベント参加者に一括でメール連絡する方法もありますが、今回は、「イベント受付フロー」の後工程にて、アンケートの入力を待ち受ける方法（フォーム待ち受け）を紹介します。

[イベント受付フロー-アンケート]

続きを読む »

イベントやセミナーの参加受付、どうしてますか？

申込件数が100人、500人、1000人の想定なら「自動処理システム」を必死に考えるのが良いでしょう。

一方で、10人、20人、50人と言った規模ならどうでしょうか？？？

例えば「少人数セミナー」などのイベント受付。。。
イベント用のメールアドレスを設定し、受付業務は≪担当者によるメール対応≫とするのが手っ取り早いかもしれません。それはそれで良い面もあります。何事にしても素早く行動に移すコト、とても大切です。

しかし、「繰り返し開催されるイベント」になる様なら、どこかのタイミングで≪担当者によるメール対応≫は卒業すべきかも知れません。すなわち、その業務について「担当者しか知らない」と言う状況をやめ、キッチリと（できるだけ半自動的に）【記録】される様にしておきたいものです。

A. データ管理
B. フロー改善

２つ視点を踏まえてワークフロー化しておけば、受付担当者の【交代引き継ぎ】も容易になります。受付担当要員の【増員】の際にも協調的な対応が素早く実現できるようになるでしょう。そして、仮に「１年に１度」のイベントであったとしても「去年どうしたっけ？」と言う状況に陥らなくなります。

[イベント受付フロー-公開フォーム]

続きを読む »

業務：アイコン作成やポスター制作など

新しい業務プロセス定義で、社内からの「依頼」を一元的に管理できるようになった。

マーケティング部でのデザイン案件、製品開発部でのデザイン案件、営業部でのデザイン案件、、、そんな依頼を「チーム」として効率よく対処できるようになった。また、デザイナ同士がお互いの制作物に興味を持つようになり、各デザイナのスキルアップにも寄与していると思う。

※参照：「第574話：プロセス改善物語（SaaSベンダー編１）」、「第575話：プロセス改善物語（SaaSベンダー編２）」

課題：納品スケジュールが守れないケースも

ただ、それでも、「納期」に間に合わなくなるケースが発生している。

たとえば、「急ぎの依頼」が入ると「通常の依頼」があおりを受けてしまうのだ。特に「新サービスのリリース」「新しいキャンペーンの準備」といった大きなプロジェクトが動きはじめると、様々な「急ぎの依頼」が発生する。結果として「締切に融通が利く通常の案件達」が納期に間に合わなくなってしまう。

外部リソースを活用するなどしてでも「制作スケジュールを守れるデザインチーム」でありたい。

[デザイン依頼対応プロセス]

続きを読む »

業務：デザイン制作

社内から次々と「依頼」が舞い込んでくるデザインチーム。
デザイン制作の「依頼フォーム」（ワークフローの開始工程）を整備したことで、以前より安定して依頼をこなせるようになってきた。（参照：「第574話：プロセス改善物語（SaaSベンダー編１）」）
自動開始イベント（メッセージ開始イベント）も用意したので、『デザイン依頼対応プロセス』が「サブプロセス」として利用されるケースも増えてきた。つまり販売部門や製造部門の業務プロセス図（メインプロセス）に「呼び出しイベント」と「待ち受けイベント」が配置かれ、業務プロセス間の連携が API POST 通信によって自動化されるようになった。（←要は「依頼案件タイトル」や「依頼仕事の作業詳細」といったデータでプロセスが開始され、作業完了と同時に「デザイン報告テキスト」と「成果物ファイル」といったデータが戻される）
さらに「サブプロセス」を呼び出すメインプロセスのサンプルも社内提示したので、今後、様々な部門におけるデザイン業務が『デザイン依頼対応プロセス』に集約されていくハズだ。

課題：スキルアップしない

デザイナごとに「担当案件の数」や「担当総額」が可視化されるようになった。また、ベテランデザイン達が「窓口担当者」として「作業担当者」の作業進捗をコントロールするようになったので、若手デザイナが「ノーチェック納品」（誰もチェックしない納品）してしまうことも無くなった。しかし、デザインは本来、「品質」こそが命だ。この業務プロセスのままでは、社内の満足度が下がっていくような気がする。もう少し、チーム全体として実力を伸ばしていけるような業務プロセスにならないものだろうか？　せっかく「デザイン依頼対応プロセス」として独立性を高めているのだから、単に数をこなすためだけの業務プロセスではなく、スキルアップにつながる仕組みを考えたい。

[デザイン依頼]

[デザイン依頼対応プロセス（レビューあり）]

続きを読む »

業務：デザイン業務

デザインチームの業務は多岐に及ぶ。

たとえば、「SaaS製品内のアイコン」の変更や追加といった小さな案件もあれば、「新しいSaaS機能」のインターフェース開発といった大きな案件もある。
ただ…、それ以外にも、セールスチームが書いた「導入事例記事」をWeb掲載するという案件が発生したり、さらにそれをチラシ制作するという案件が発生したりする。はたまた、マーケチームの「展示会」企画にあわせて、Webコンテンツを制作案件が発生したり、ポスター制作したり…。

つまるところ、全社から「手伝ってラブコールを受け続けるチーム」と言っても良い。

課題：受け身な案件の効率化

確かにデザインチームが愛されていることは事実だ。
しかし、直接部門である「製品開発部門」や「営業販売部門」が日ごろ主体的に動いているのと比べると、やっていることは地味と言わざるを得ない。たとえて言えば、小売店にある「ラッピングコーナー」みたいなものか？　日々、社内のアウトプットに対して「お化粧」をし続けるのだ。そして、気がつけば「受け身の姿勢」がしみついてしまう。

これがもし建築の世界であれば、、、むしろ「意匠系」が主体的に動き、エンジニア集団である「構造系」や「環境系」が受け身になるところなのに。。。と、ボヤいたところで「社内からのラブコール」が無くなる訳ではない。まずはこの「受け身仕事」を手際よくこなすことを考えたい。（経理担当だって、人事担当だって、情シス担当だって、、、「受け身仕事」を華麗にサバいているのだから…）

[デザイン依頼対応プロセス]

続きを読む »

「カタログ郵送、、、意外とミスが多いんデス」

公開Webフォームで受け付けた「資料請求」には素早く対応したいものだ。しかし、お客様に入力していただいた『住所』や『会社名』を間違えるとサムイ。。。たとえば「Word送付状」にコピペする時に、参照すべきレコードが一件ずれてしまい、

ウチ、そんな社名じゃないよ
ウチに、そんな社員はいないよ

などというクレームにつながれば、場合によっては「個人情報漏洩事件」とすら言われる可能性がある。

以下の業務プロセス定義は、『受付担当者』が

入力途中で送信してしまった様な未完成な住所だったりしないか？
イタズラ目的のデタラメ住所になってないか？
省略表記や無用なスペースなどが混ざっていないか？

などをチェックした後に「送付状PDF」は自動生成され、『郵送担当者』はそのPDFを印刷して資料を封入流れとなっている。そこに人手は介在しない。

秀逸な点は、この業務において「リスト」が作られることもない点だ。情報漏洩リスクは極めて低くなる。そして封入作業が完了し次第、「会社名」や「電話番号」などのデータは自動的にクラウド型データベースに追加される。（一目瞭然ではあるが、「あわせて見積も欲しい」などの書き込みがあった場合に『営業担当者』に依頼する流れも想定されている）

[資料請求対応業務]

続きを読む »

『発生源』が社外にあるワークフローは、「改善プロジェクト」を進めやすい。

(a) 社内トリガー（社内開始）
(b) 社外トリガー（社外開始）

つまるところ、(a)社内トリガーの業務は、「社内に閉じたワークフロー」なのだ。

たとえば、『社員』に始まる休暇申請フローであったり、『部下』に始まる稟議フローであったり。。。そんな場合、ついつい「急いで改修しなくてもイイかな？」「運用でカバーできるさ！？」などという雰囲気になってしまいガチだ。

しかし、(b)外部トリガーの業務フローは、そうはならない。

たとえば『お客様』の依頼に始まる資料送付フローであったり、『仕入元』からの請求に始まる調達代金送金フローであったり。。。それらは会社の評判に直結するのだ。つまりメンバー内で「少しでも早くミスなく完了するプロセスに改善したい！」といったモチベーションを共有しやすいのだ。

以下のワークフローは、「イベント参加費」の入金確認フローだ。

クレジットカードや銀行振込など、イベント参加者からの入金を事務局がが確認できれば、「領収書PDF」を自動的に参加者にメール送信するプロセスだ。

一刻も早く、「参加エントリ、ありがとうございました」を伝えたい
ヌケモレなく入金（＝着金）を確認したい

という意気込みが感じられる。

[入金確認フロー]

続きを読む »

業務で『住所データ』を入力する機会は少なくない。

代金請求プロセスにおいて「請求書の郵送先を入力する工程」
アンケート集計プロセスにおいて「回答データを入力する工程」
エレベータ保守プロセスにおいて「点検した地点を入力する工程」

などなど、、、様々な部門が、様々な日常業務の中で『住所データ』を入力している。

以下のワークフロー定義は、「回収した名刺／アンケート紙」をデータ化する業務プロセスだ。展示会やイベントの終了後などに、大量に獲得された名刺やアンケート紙が、順次データ化される。

この入力画面には「住所の部分入力」によって住所候補が自動的に列挙される仕組みが実装されている。

非常に秀逸な点は、その絞り込み検索において『大口事業所を含む郵便番号データ』（約15万件）が参照されている点だ。つまり、役所の名前や大企業の名称の一部を入力するだけで、その「郵便番号」「住所」「法人名」の全項目を補完入力できる。

※ 日本郵便株式会社は、配達物数の多い大口事業所に対して、専用の郵便番号（個別番号）を割り当てている。

ちなみに「大津市役所」と入力すれば

「大津市役所」に並んで
「泉大津市役所」

も補完候補として表示される。

[個人情報のデータ化フロー]

続きを読む »

例えば「自社の説明」を書く、というケースでは、

短文でアッサリ書く / 長文でキッチリ書く
現在のプロパティを書く / これまでの経緯を書く

など色々なパターンがある。

あるいは「製品の説明」を書く、というケースでは、

コンセプトを書く / 詳細機能を書く
初見者に向けて書く / 既知者に対して書く

など状況に応じて書き方が変わる。

たしかに、一部のベテラン社員達であれば、あっという間に「作文」できるのかも知れない。しかし、多くの新卒社員や転職入社社員にしてみれば、その作文は非常に時間のかかる作業となる。

以下の業務プロセスは、『再利用しやすい文章』（テンプレート文）を登録し、同時に「改善コメント」を受け付けられるワークフローだ。ワークフローと言うより、ナレッジデータベースと言った方が良いかも知れない。事務効率を改善できるだけでなく、社内における共通認識が醸成される。（登録者自身にとっても、後学のためのメモになる）

発信系(日常): 製品紹介文、技術紹介文、ビジネス紹介文
発信系(非日常): 障害告知文、緊急対応告知文、質問文
返信系: 問い合わせ御礼、クレーム謝罪文、セールスお断り文

[テンプレート文の登録とレビュー]

続きを読む »

2014年も残すところ、あと数日。。。

今年も読者の皆さんに支えられ、何とか「毎週投稿」を実現する事ができました。このエントリーで2014年の52本目、通算で411本目（※）の業務プロセス提案になります。 Wokflow Sample 読者の皆様、、、特に「××なプロセスを書いてみて」とリクエストを下さった皆様(!)に、、、また投稿に対して「とっても参考になった」などのコメントや感想を下さった皆様(!!)に、この場を借りて御礼申し上げマス。

※ 2014年＝51本、2013年＝52本、2012年＝53本、2011年＝186本、2010年＝68本
※ 各記事に添付の業務サンプル [QAR] は１つ２つ、と言うコトで通算のサンプル数は約700本位になっています？？

振り返れば、、、特に当ブログの開設当初は、内外から「3日坊主」がウワサされていたモノです。まぁ確かに、中には大したことない業務プロセス提案も混ざってはいるのですが、、、いや、これからも、細く(?)、永く(!)、シブトく(!?!)、続けていこうと思っております。今後とも「叱咤激励」および「忌憚のないフィードバック」につき、宜しくお願いします。

◆2014年に、最も読まれた日本語記事

◆2014年に、最も読まれた英語記事（に対応する日本語記事）

Improving Your Accounts Payable Process in Steps (2011-05-13)

（買掛金プロセスを少しずつ改善する）

Reporting Each Client Visit Right After Returning to the Office (2011-02-15)

（往訪直後に「１件ずつ」の往訪報告フロー）

Visualization of Testing Process in Software Development (2010-12-20)

（ソフトウェア開発におけるテストフローを可視化する）

Workflow Across The Enterprise, From Quotation To Payment Confirmation (2011-06-05)

（企業をまたぐワークフロー、見積から入金確認まで）

Is Complaint Management Perfect for Training New Employees? (2011-04-01)

（クレーム対応は新人育成に最適？）

さて、、、
以下2014年最後のエントリーは、非常にシンプルな「Blog エントリー業務フロー」の御紹介です。

[Blog エントリ業務]

続きを読む »

「メールを送信する家電」と言えば、2001年登場の「賢い給湯ポット」だ。（通信の仕組みが特殊だけど）

離れて暮らす年老いた両親をさりげなく見守る電気ポットは、日本ではちょっとした人気商品だ。今や「おでかけボタン」なるものまで装備され、「給湯した時刻」や「電源を入れた時刻」だけでなく「帰宅や外出の時刻」までもメール本文にシタタメテ、毎日送信してくれる。（ちなみに「i-POT」と言う製品名だが、アップル社の製品ではナイぞ）

そして2014年、見渡せばメールを送信する安価な機器が沢山ある。。。（色んなモノがインターネットにつながった、と言ってもイイ）中でもスキャナとウェブカメラは、かなり成熟した「データ入力装置」と言えるだろう。今や3万円程度だ。非常に投資対効果の高い業務改善ツールと呼べるかも知れない。

以下の業務プロセス定義は、紙アンケートの集計フローだ。

フランチャイズ飲食の来店アンケートや生命保険の契約者アンケートなど、回収アンケート用紙が各店舗でスキャナにかけられると本部でテキスト化作業が始まる、と言う仕組みだ。つまり、本部ワークフローは「スキャナから届いたメール」がトリガーとなって起動され、担当者はスキャン画像（PDF,JPG）をモニタで確認しながら人力でデータ化するのだ。なんと言っても、データ化の進捗がリアルタイムで把握できるようになるのが素晴らしい。それでいてデータ作業者の実績集計もラクラクだ。

ちなみにこのサンプルは、データ入力作業の「二者入力」（二重入力／ダブルエントリー）にも対応している。もちろんクラウド型ワークフローなら、テレワーカの活用やBPOサービス会社への委託も検討されることになるだろう。

[アンケート集計フロー]

続きを読む »

商品カタログ、
製品マニュアル、
取扱説明書。。。

この「ペーパレス」な御時世(!!?)、、、情報は『データ』(PDF)で流通させるべきだ。「紙資源」もモッタイナイし、「本棚スペース」も埋まってしまう。

しかし、一方で『紙の冊子』にも長所はある。情報種類によって、アクセス頻度によって、読者状況によって、『紙の冊子』の方が都合が良いケースは少なくない。

見やすい。（←高解像度）
書き込みやすい。（←鉛筆でも）
そしてコンピュータに依存しない。（←電源イラズ）

しばしば比較される「情報を探し出す」と言う ≪機能≫ も、コンピュータの検索とは違った "不思議な方法" で素早く見つけ出せるケースだってある。（手垢、折り目、情報のレイアウト、ニオイ…？）

以下のビジネスプロセスは、マニュアル冊子（紙の冊子）を郵送する業務（郵送サービス）を定義している。希望者が Web サイトで「住所」や「宛名」などの情報をエントリすると、ワークフローが自動開始される仕組みだ。エントリフォームは、既存の Web サイトに埋め込む方式になっている。（「Web 資料請求」への対応業務）

[冊子郵送サービス]

続きを読む »

申込件数が100人、500人、1000人の想定なら「自動処理システム」を必死に考える。
しかし一方、10人、20人、50人と言った規模なら？？？

イベント参加証を PDF で送る（ワークフローの自動化） (ワークフローサンプル 2014-03-17)

例えば「少人数セミナー」などのイベント受付。。。

イベント用のメールアドレスを設定し、受付業務は≪担当者によるメール対応≫とするのが手っ取り早い。それはそれで良い。何事にしても素早く行動に移すコト、とても大切。

しかし、「繰り返し開催されるイベント」になる様なら、どこかのタイミングで≪担当者によるメール対応≫は卒業すべきかも知れない。すなわち、その業務について「担当者しか知らない」と言う状況をやめ、キッチリと（できるだけ半自動的に）【記録】される様にしておきたい。

A. データ管理
B. フロー改善

２つ視点を踏まえてワークフロー化しておけば、受付担当者の【交代引き継ぎ】も容易になる。受付担当要員の【増員】の際にも協調的な対応が素早く実現できるだろう。そして、仮に「１年に１度」のイベントであったとしても「去年どうしたっけ？」と言う状況に陥らない。

[イベント受付フロー-公開フォーム]

続きを読む »

（電話口）「他社宛の請求書が届いたんですケド・・・」

コレ、、、かなり、、、サムイ。。。

まぁ、多くの会社で1度や2度は経験している事とは思う(?!?)が、果たしてコレ、「事務担当者の気合が足りない！」と言う類の問題なのだろうか？

あなた自身が作業する姿を想像しよう。もし「業務に必要な書類をその都度 Excel や Word で作成する」と言う前提があるなら、おそらく100枚に１枚くらいはミスする。仮にダブルチェック体制（←さいはつぼーし策）を施したとても、1000枚に１枚くらいはミスが発生するだろう。つまる所、ミスの発生は「時間の問題」なのだ。

以下のワークフローは、イベント受付の対応業務だ。『イベント参加証 PDF』の作成工程と『領収書 PDF』の作成工程が自動化され、各書類の送付がメール添付によって自動化されている。（入金確認作業は人手）

[イベント受付フロー]

続きを読む »

紙のアンケートは、「データ入力」が大変だ。

とは言うものの、、、「Expo 展示会」や「住宅展示場」などでは、紙とペンを渡すのが現実的だ。翌日、その膨大な「アンケート用紙の束」と向き合う。手分けしてエクセルに入力していくのだ。（良くある話）。出来上がったエクセルファイルは、円グラフが足され、棒グラフが足され、会議で報告される。。。。（おわり？）

やはり「見込顧客」に対するアプローチ業務は標準化しておきたい。（フォロー計画）

手順が規定され得るのなら、エクセル等（データ指向システム）に入力するのでは無く、ワークフロー（プロセス指向システム）に入力する方が良い。（Excelエクスポートはイツでもできる）
以下のワークフローでは、１件１件の「見込顧客」がフローの中で「処理」される。つまり、入力された見込顧客データは、営業担当の誰かが引き受け「電話でのアポ取り」で往訪すべきかどうかが確認されるのだ。そして、往訪すべき案件であれば「往訪等を行い商談化」のアプローチで商談になるかを確認する。

リアルタイムで商談化の進捗を確認できる。
と同時に、アンケートに書かれたデータに「商談になったか」と言う情報が加わる。スバラシイ。

[見込顧客アンケート]

続きを読む »

企業の「公式ブログ」は珍しいモノではなくなった。。。
いやむしろ「ホームページ」と同様、"あって当然のモノ"になりつつある、のかも知れない。言うまでもない話だが、企業の最新情報を広報する道具として非常に便利だ。場合によっては顧客とのコミュニケーションの場にもなる。

この記事も『ワークフローサンプル』と言うブログ形式をとっている。。。
クエステトラ社としても『Questetra Blog』と言うブログを運営している。。。
（ん？ Google 社の公式ブログって、ハテサテ？、何種類あるのだろう？？？）

以下のワークフロー定義『公式ブログ公開フロー』は、（プロセス図を見れば一目瞭然だが）、レビューを受けた草稿が、自動的に Blog システム側にエントリーされる仕組みだ。この例の様に「人的なレビュー工程」や「機械的な自動連携」と言った様々な工夫を通して、記事の正確性や読み易さを担保して行きたいものだ。

[公式ブログ公開フロー]

続きを読む »

意思決定には、「1つの案に対して可否を決定」するパターンもあれば、「複数の案から選択」すると言うパターンもある。

日本独自の伝統的なビジネス習慣である『稟議書』は、「1つの案」に対して可否を決定するワークフローだ。（恐ろしく大人数の…、そして紙が真っ赤に染まる程の…、印影が押される）

一方、以下のワークフロー定義は、「複数の案」から選択する選定ワークフローの例だ。
この例では上流工程にて「候補地」と各候補地の利点や課題についての考察が列挙され、下流工程で「開催地」が決定される。「セミナー開催地の選定」と言った真面目な業務から、「社員旅行の行先決定」と言ったユルイ業務まで、様々な選定で活用できるだろう。

当然の話だが、最終決定を選択する選択肢は案件毎に異なる。すなわち、下流工程の選択インターフェースを「セレクトボックス(選択型)」で表示したくても、各案件毎に選択肢が変わる。この様な場合、上流工程で入力された「複数行の文字列型」の各行を「下流工程の選択肢」として表示させると言う技を使う。例えば、上流工程で『候補地』(文字列型複数行)に

東京
マドリード
イスタンブール

と言う3行テキストが入力されれば、下流工程の『開催地』セレクトボックス(orラジオボタン)に「東京/マドリード/イスタンブール」が一覧されると言う仕組みだ。

[セミナー開催地選定フロー]

続きを読む »

業務プロセスの中で「乱数」を使うケースは、、、あまりナイ。

強いて言えば、内部統制視点で「レビュー者の固定化」を防いだり、当選者を決める「厳正な抽選における当選者番号の決定」で自動化させたり、…するくらいだろうか？

以下のワークフローサンプルは、社内で「しりとり」ができる業務プロセス定義だ。全くもって実用性はないが、クエステトラのブログで紹介したところ「アーカイブを見てみたい」との稀有な意見もあったので、改めて当サイトのコンテンツとして紹介しておく。（もちろんアーカイブも無料ダウンロード可能）

この例では「しりとり」のやり取り相手（回答者）が「乱数」で選択される。分岐ゲートウェイの直前で「乱数」を発生させ、その乱数に従って分岐ゲートウェイの経路が選択される仕組みだ。（自動分岐）

[しりとりフロー]

続きを読む »

登録: 投稿 ( Atom )