ノンプログラマー向けイベントを開催してみて
去る 1/20 にヤフーさん、サイボウズさんと共催で「カフェで学ぶ、3つのサービスを一度に体験！ノンプログラマー向けハンズオン」というイベントを開催しました。
開催に至った経緯
サイボウズさんとは以前から仕事でも親しくさせていただいていましたが、ヤフーさんとは Mashup Awards をキッカケにこのところお会いすることが多くありました。名古屋のハッカソン時にお話を持ちかけたところ「是非やりましょう！」と快諾いただいたため、まずはやってみましょう、ということで第1回を開催させていただきました。
今回、私がこだわったポイントの一つに「ノンプログラマー向け」というのがありました。ここ2年 Mashup Awards をはじめとするいくつかのハッカソンイベントや kintone Café のようなイベントに参加しているのですが、参加者の多くの人がエンジニアでありもっとより多くの知識や情報を得るべきである営業やマーケの人が圧倒的に少ないと感じていました。
自分自身が営業でありながらイベント参加で得たものが凄く多いため、これを世の中の多くの人に感じて欲しいという思いもあり「ノンプログラマー向け」というのをタイトルにも入れて開催してみました。
イベントの様子
今回の会場は「スタートアップカフェ大阪」です。関西大学梅田キャンパスと同じビルにあり、各線梅田駅から5分以内とアクセスも抜群です！
会場の広さとスタッフの人数を考慮して 20人を定員としていたのですが、あっという間に満席になっていました。申込みを管理してくださったスタートアップカフェの方に聞いたところ、キャンセルがでてもすぐに埋まってしまっていたそうで、「ノンプログラマー向け」というキーワードが良かったのか、他の要因だったのかは要調査です。
まずは皆さんの緊張をほぐすためにアイスブレイクということで、配ったカードを使った自己紹介で参加者の皆さん同士で打ち解けていただきます。（写真は説明をする寸劇の図）
皆さん打ち解けていただいて席替えも終わったところで、早速ハンズオンが始まります。
kintone ハンズオン
最初はサイボウズ 竹内さんより kintone のハンズオンです。
ドラッグ＆ドロップでアプリができることに皆さん感動されていました。更に、kintone を導入したいと思っていた方も参加されており、操作の簡単さを知っていただけた良い機会になったと思います。
DataSpiderハンズオン
続いて、私からは DataSpider のハンズオンです。（写真は無いので資料を）
今回の最終ゴールは Instagram のいいね！数を取得して、kintone を使ってグラフ表示するということです。DataSpider は myThings から受け取ったデータを kintone が受け入れられる形式に変換して渡してあげるというところです。
DataSpider の機能としては比較的難しい（と思われる）部類の REST アダプタや HTTP トリガー を使うのですが、今回は対象の方が非プログラマーということもあり、全てを設定していただくのではなく雛形を予め作っておき、穴埋め式で設定していただくことにしました。
とはいえ、やはり用語が少し小難しいところもあって多少苦労される方もいらっしゃって、少し時間オーバーしてしまいました。
myThings ハンズオン
最後はヤフーの清土さんから myThings (Developers) のハンズオンです。
まずは簡単に体験していただくために、LOHACO ダッシュボタン なるものを作成してみます。 その後、DataSpider を呼び出して、最終的に kintone でのグラフ表示までを確認します。
myThings はガイドが出てくるのが凄く好評だったように思います。
まとめ
ハンズオン終了後は、30分ほど雑談＆質問タイムです。
参加者の方にお話を伺ってみると、「kintone を導入したいと思っていたけど触る機会が無いのでありがたかった」という声や「普段はインフラばっかりやっているので、アプリを気軽に体験できると思ってきた」というご意見があり、当初の目的を少しは達成できたのかなと思っています。
一方で申込みがすぐ満席になった割に当日の出席率が低く、金曜日の19時～22時というのは少し考え直したほうが良いかななど反省点も残ります。
とはいえ、今までと違ったスキームで新しい層にアプローチするというチャレンジができ、ある程度の成果もあったのでまずは良かったかな、と思っています。次の企画を練るのが楽しみです。
ノンプログラミングで作る LINE Bot
ご存じの方も多くいらっしゃると思いますが、LINE Bot Awards というイベントが開催されます。 botawards.line.me
弊社アプレッソも API 提供パートナーとして協賛させていただくことになりました。
「LINE Bot を作ってみたいけど、プログラムが書けない・・・」そんな方のために、DataSpider を使ってノンプログラミングで LINE Bot を作る方法をお届けします。
事前準備
LINE Bot を作るためには、大まかに言うと以下の作業が必要です。
LINE Developers で Bot 用アカウントを作る
Access Token を取得する
User ID を取得する
エンドポイントを指定する
Bot アプリケーションを開発する
1～3 の作業は先輩である脇野さんが以前書いてくれたので↓の記事を参考にしてください。 ちなみに、脇野さんが使ったのは「Push Message API」というプッシュ型でメッセージを送信する API です。単純に自動返信してくれる Bot を作るだけではなく、プッシュ通知を活用してスケジュールによる配信の仕組みも作ると更に面白いものになるかもしれませんね。 qiita.com
今回はノンプログラミングで Bot を作るということで、4～5 を DataSpider を使って作っていこうと思います。
Webhook の設定
LINE Bot は LINE developers で指定したエンドポイントあてに Webhook でメッセージが送信され、それに対して Reply Message API を使って返信をします。DataSpider では HTTP トリガーを使ってエンドポイントを作成します。
では、まずはじめに HTTP トリガーででメッセージを受信する仕組みを作ってみましょう。作るスクリプトは以下の通りです。
XML 変数（入力変数）を作成し、受信したデータを XML出力でファイルに書き出します。 では、このスクリプトをサービス化し、HTTP トリガーの設定しましょう。
続いて、HTTP トリガーで発行された URL を LINE developers の Webhook の URL に指定します。
これで設定は完了です。では早速自分のスマホからメッセージを送ってみましょう。 まだ Reply の設定をしていないので特に返事は帰ってきませんが、XML 出力の設定をしていたので XML ファイルが出力されているはずです。 出力された XML ファイルを開いてみるとこんな形で出力されています。
実際に送られてきている情報は json 形式なのですが DataSpider では内部的に XML に変換しており上記のように出力されています。このうち重要な部分3箇所にわかりやすいように赤線を入れました。上から順に
「repleyToken（返信時に使う）」
「userId（送信者ごとに振られる一意のID）」
「text (実際にユーザーから送信されたメッセージ)」
です。これらは後ほど使います。
ここまでで、ユーザーが送信したメッセージを DataSpider が受け取っていることが確認できました。
Reply Message API の設定
それでは、続いて Bot の応答（Reply Message API）の設定の行います。
先程受信することはできましたが、どうやって返事を出せばよいのでしょうか？
LINE の API Referenceを確認してみます。
これを読み解くと・・・
といった感じでしょうか。
次に進む前に json の部分のみテキストにして保存しておきます。（ここでは linereply.json というファイル名で保存したと想定します）
では、REST アダプタを使ってこれらの設定を行っていきましょう。それでは、DataSpider のスクリプトキャンバスに RESTアダプタ（POST）とMapping アイコンを配置しましょう。
まず、REST アダプタから設定します。 接続先（グローバルリソース）では接続先 URL の指定をします。
続いて、[ヘッダ設定]でリクエストヘッダの設定をします。（{ENTER_ACCESS_TOKEN}は自分のアクセストークンに置き換えてください）
その後、[リクエスト設定]でデータの入力元として先程保存した json ファイル（linereply.json）を指定します。これは実際の入力データを指定している訳ではなく、入力データのスキーマ情報を指定しているイメージでお考えください。
ここまで来たら REST アダプタは完了して閉じ、続いて Mapping アイコンを開きます。
先程[リクエスト設定]で json ファイルを読み込んだことにより、「出力先」にスキーマ情報が定義されていることを確認します。
続いて、「入力元」で仮スキーマの作成を行い、「スキーマの読み込み」で Webhook の設定 の時に出力された XML ファイルを指定します。 これにより、「入力元」「出力先」それぞれのスキーマの定義が行われました。
上記の状態になったことを確認後、出力先スキーマに対して以下の作業を行います。
スキーマ定義の下の方の element を削除します。
「object」「array」「text」と書いている箇所については、「単一行文字列定数」アイコンにてそれぞれ「object」「array」「text」と入力し、下図の通り出力スキーマにリンクを張ります。
「メッセージ」と書いている箇所は、「単一行文字列定数」アイコンにて送信したいメッセージの中身を指定します。
replyToken は入力元から直接出力先にリンクを張ります。
ここまで設定を行ったものが下の画像です。
あとはお作法通り、[Start]から[End]までプロセスフローを繋げて完成です。
試してみよう！
では、早速自分のスマホを使ってメッセージを送ってみましょう！
う～ん・・・ 当たり前ですが、1つしか返事のパターンを設定していないので何を言っても「こんにちは」しか返ってきませんね。これでは Bot とは言えません・・・
少なくとも条件分岐を入れて送った内容によって返答が変わるようにしたいですが、長くなってきたのでそれはまた次回にお届けしたいと思います。
ソフトウェア営業に技術力が必要な3つの理由
本記事は アプレッソAdvent Calendar 第9日目の記事にするつもりで書いていたものです。
当初はこちらを公開する予定でしたが、他に書きたいことができてしまったのでお蔵入りとなっていたものです。 せっかく書いたものですし、世の中の多くの営業マンに対して発信したいことでもあったので公開させていただくことにしました。
営業に求められるスキル
ソフトウェア業界の営業にとって大切なスキルはどういったものでしょうか？
「コミュニケーション力」「業務知識」「提案力」など、人によって答えは異なると思いますし、正解は1つではないと思います。
今回はその中でも「技術力」についてお話したいと思います。
※決して「技術力」が一番大事だと思っているわけではありません。
「営業には技術力は必要ない！」「営業は技術を持ったエンジニアをアサインしたり段取りすることが仕事」とおっしゃる方もいらっしゃるとは思います。
私もデモや製品紹介のために技術力が必要だと言っている訳ではありません。 （それぐらいはメーカーの営業ならできて当然です）
では、なぜ私が技術力が必要だと思うのか？ 理由は大きく3点あると思っています。順にお話したいと思います。
製品を作る
まず 1つめの理由は「製品を作るため」です。
製品の機能を理解しお客様の課題に対する解決策を提案する、これは営業として当然できないといけないことです。
では、お客様の求めることが自社の製品ではできない場合、どうしたら良いでしょうか。 私が SIer の営業であればスクラッチ開発で補う、商社の営業であれば解決できる商品を探してきて提供する、それで良いと思います。
しかし、私はソフトウェアメーカーの営業です。したがって、「お客様の求めるものを正しく把握し、開発にフィードバックする」というのがとても重要な仕事です。
お客様が「こんな機能が欲しい！」と言ってる場合、営業は「その機能があると何故嬉しいのか？」「他の機能では何故いけないのか？」を正しく把握し、開発に伝える必要があります。 （このあたりの話は去年土岐さんが書いてくれましたので、詳しくは触れません）
これができないと有名な↓の風刺画のようなことになります。
ということで、「製品を作る」ためには営業が技術を理解していることはとても重要になります。
社内を牽制する
2点目は「社内を牽制する」ということです。 こう書いてしまうととても感じが悪いですが、営業・開発間にかぎらず常に社内で刺激し合える関係というのが健全な組織だと思います。
ソフトウェアメーカーで仕事をしていると、当然のことですがそのソフトウェアに関しては自分たちが一番詳しくなります。そのため、お客様が自身の意図した通りにソフトウェアが動かない、と言ってきた場合には「お客様の使い方が理解できていないからだ」などとお客様の言っていることを疑いがちです。（もちろん、そういうケースもあります）
営業は社内ではお客様に一番近い場所にいます。そのため、お客様の状況を一番正しく把握できている可能性が高いです。
しかし、技術的なことが全くわからないと、お客様の言うことを社内へ、社内の開発・技術メンバーの言うことをお客様へ、そのまま伝えることしかできないため、伝言ゲームとなり結果として認識の齟齬が生まれ得ます。
ここで営業が技術的なことを理解できていると、
- お客様の言ってる情報は正しいのか？
- 社内の開発・技術が言っていることはお客様への回答になっているのか？
を精査できるためトラブルを未然に防ぎ、早期の問題解決に繋がります。
先程書いたように 開発=>営業 の間でも同じことが言えると思っています。営業が行っている活動が適切なのか、もっと良い販売方法・提案方法があるのではないか、というのを開発側が助言できる組織はとても強くなると思います。
顧客の課題を発見する
最後になりますが、これが一番大きな理由になります。 「お客様自身が気づいていない課題を発見する」という点が一番重要だと思います。
1番目の話とも通じる部分はありますが、「データ連携をしたいです」と言っているお客様に DataSpider を買ってもらうことは簡単です。 （「簡単ならもっと売り上げ伸ばせ」とか言わないでください・・・）
営業の本当の価値は「こんなところがデータ連携できるとこんなに便利になるのか」「言われてみればこんなことで無駄に時間を取られていたんだ」という、お客様自身が気づいていなかった課題に気づき、気づかせてあげることにあると思います。
これをやるためには、お客様の業務を良く理解することも当然必要ですし、その課題を解決するための方法についての知識が不可欠になります。
最後に・・・
今年はハッカソンやハンズオンなど多くのエンジニア向けのイベントに参加しました。
「技術より営業の方が楽しいと思って営業をやっているのになんでこんなにイベントに出てるんだろう？」「技術的な知識が深まるとなんでこんなに楽しいんだろう？」と思い、振り返りながら書いてみました。
偉そうなことをたくさん書いてしまいましたが、アプレッソの営業はこんな気持ちで日々活動しているんだ、ということを知っていただけますと幸いです。
DataSpider を使った教育について考える
本記事は アプレッソ Advent Calendar 第9日目の記事です。 qiita.com アプレッソで東海・関西の営業を担当させていただいている築山と申します。
実は全く違う内容で 3週間ほど前に書き上げていたのですが、自分の出番を待つ間に別のことを書きたくなったので、以前に書いたネタはお蔵入りとなりました。 お蔵入りしたネタ「ソフトウェア営業に技術力が必要な3つの理由」は今回の内容よりずっとエモいものですので、別の機会にご紹介できればと思います。
何故このテーマ？
最近「教育のために DataSpider を使ったら面白いのでは？」と思うことがよくあります。
色々なきっかけがあるのですが、大きなきっかけはハッカソンで中学生が DataSpider を使って開発をしてくれたことです。 このハッカソンでは、お父さんに連れられて参加していた中学1年生の子（仮称：Nちゃん）が DataSpider を利用することで、作品の最重要とも言える機能の開発に携わることができました。
ハッカソンの様子は当時のブログ（前編・後編）をご覧ください。
また、もう1つは先輩の言葉によって気づかされたことですが、「自分がクラウドサービスや Web API など DataSpider の周辺知識を深められたのは、自主学習によるものではなく DataSpider が教えてくれたんだ」ということに気づくことができたためです。
この2つの出来事により、「DataSpider と 教育」ということについて考えさせられたのが予定を変更してこのテーマを選択した理由です。
それでは、それぞれ具体的にお話させていただこうと思います。
DataSpider が教えてくれたこと
～Nちゃんの場合～
まずは 1つ目の「ハッカソンで中学生が使ってくれた」という話です。
中学1年生の Nちゃんはハッカソン自体は何度も参加しているベテランなのですが、これまではお父さんのお手伝い的な意味合いが強かったそうです。
それが今回「DataSpider を使ってみたい」と声をかけて貰い、実質作業時間2日のハッカソンで 1.デバイスから HTTP で JSON 形式のデータを受け取る 2.kintone にデータを格納する 3.雑談対話 API を用いて会話文を生成する 4.Gmail で通知する 5.Twitter でつぶやく ということを実装することができました。
＜構成図＞
この過程において Nちゃんには
Web API
変数
条件分岐 を理解してもらうことができました。（多分）
コードを書きながら上記5機能を実装し、更にこれらを1日の間に学習することはとても難しいと思います。しかし、DataSpider を使えばアイコン操作だけで実現できるので、コードを書くことと切り離してこれらを理解することができます。
～営業 築山の場合～
では、続いて私の場合です。
去年、今年と Mashup Awards を含めいくつかのハッカソンイベントで DataSpider を使って開発することのサポートをさせていただいた結果、これまで苦手だと思って敬遠してきたWeb API に関する理解を深めることができました。（まだまだ勉強不足ですが）
これはたくさんのイベントでサポートしたからだと思っていたのですが、ハッカソン中にいただいた先輩からの一言により 「自分は DataSpider に育てられたんだ」ということに気付かされました。
＜先輩のコメント＞
API の仕様書には細かく書かれているわけではないので、「その仕様書がどういう意味を持つのか」を考えるためにアダプタの機能を知っておくことはとても重要です！ 「HTTP の仕様としてこうあるべき」がアダプタの設定（画面設計）に現れているんだよ。
これを聞いて「まさにその通りだな」と思いました。 上記は REST アダプタを使ってマルチパートのデータを POST するときの方法を質問したときのやりとりだったのですが、つい5日ほど前にも似たような話がありました。
Code for Osaka リサイクルハッカソンのサポートに行った際「Kinesis に投げられたデータをリアルタイムに受け取って DB にクエリを投げる」という要件があり、そこで DataSpider を使ってもらうことになりました。しかし、私自身 Kinesis を触ったことが無く、また Kinesis というのがどんなサービスであるかしっかり理解できていませんでした。
AWS Kinesis のページも読んでみましたが・・・・
Amazon Kinesis Streams を使用して、データレコードの大量のストリームをリアルタイムで収集し、処理します。「Amazon Kinesis Streams application」と呼ばれるデータ処理アプリケーションを作成します。一般的な Amazon Kinesis Streams application は、データを Amazon Kinesis stream からデータレコードとして読み込みます。これらのアプリケーションは Amazon Kinesis Client Library を使用することも、Amazon EC2 インスタンスで実行することもできます。処理されたレコードは、ダッシュボードに送信してアラートの生成や、料金設定と広告戦略の動的変更に使用できます。また、他のさまざまな AWS サービスにデータを送信できます。
分かる人には分かるんでしょうが、私みたいな凡人には何のことかさっぱりわかりません。
しかし、Kinesis トリガーの設定画面を見ながら Kinesis 側の設定をされている方と話をすると「ストリーム」というのはデータベースで言うテーブルのようなものなんだ、様々なアプリケーションがデータを読んだときにそのアプリケーションを識別するためにストリーム内で一意となる「アプリケーション名」というものが必要なんだ、ということが簡単にわかりました。
＜AWS Kinesis トリガー設定画面＞
このように私自身も DataSpider で連携する周辺の様々な技術について、製品を通して学ぶことができています。
～東急ハンズ様の場合～
ここまで自分がすごい発見をしたかのように書いてきたのですが、実は既に DataSpider を教育に用いていただいているお客様が既にいらっしゃいます。
皆さんも一度は足を運んだことがあるであろう「東急ハンズ様」です。 www.appresso.com
東急ハンズ様では、「現場にとって使いやすいシステムを作り上げるには、店舗の実状に詳しい社員がシステムを企画することが重要だ」という方針のもとに、店舗スタッフを経験した社員の問題意識と改善意欲によって様々な社内システムの企画が立案されています。
そのため、プログラミング経験の無い方が IT 企画に携わることが多いのですが、DataSpider を使うことで社内のデータの流れを把握することができるということで、社員の方へのプログラミングの教材としても役立てていただいています。
～まだまだあります～
これまでに紹介した以外にも DataSpider の機能を知ることで短期間で身につけられることがたくさんあると思います。
WSDL の存在により、Webサービス の開発を効率化できるということを Web サービスアダプタの画面から知ることができます。
メールアダプタにより、メールのメッセージを分解すると「From」「To」「件名」「本文」「添付ファイル」などに分割されることを学べます。
スクリプトのトランザクション設定画面では、一言にトランザクションと言ってもいくつかの種類があり、処理の内容によって考慮する必要があることを教えてくれます。
まだまだいくらでも挙げられそうですが、このまま行くと50種類以上の全アダプタを紹介することになりそうなのでこれぐらいにしておきます。
これからのこと
ご紹介してきたように多くのシーンで DataSpider を教育に活用することができますし、これからももっと活用できると思います。
私はエンジニア~プリセールス~営業 というキャリアを踏んできましたが、元々この業界に飛び込んだのは「教育」に携わる仕事がしたいと思ったためでした。 就職活動をしている時期には業界を問わず教育関連の仕事を探していて、「Microsoft 関連の教育事業を手がけている」というのが新卒で入社した会社を選んだ理由でした。
その会社は入社前に教育事業からは撤退していた（早く言ってよ・・・）ため、教育の仕事に携わることは無いまま既に13年経ち2度の転職を経て今の仕事をしているわけですが、「今からでも DataSpider という製品を通じて"教育"ということに携わる機会は幾らでもあるじゃないか！」ということに改めて気付かされました。
これは「学校や新人教育などの教育現場でプログラミング教育のためのツールとして DataSpider を採用してもらう」ということもありますし、「購入いただいたお客様が自身のスキルを高めるために DataSpider をもっと活用していただきたい」という気持ちもあります。
更には私自身が DataSpider を通じてもっと成長していきたいと思いますので、製品を育てつつその製品とともに育っていきたいと思います。
明日は文中に出てきた先輩のターンです。
