チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

Salesforce Developers Meetup #17 LT登壇観戦レポート

こんにちは、倉谷(id:a-kura)@花粉症で目が痒い です。 皆さま、一気に暖かくなって花粉が舞い飛ぶ季節になりましたが、いかがお過ごしでしょうか? 私は、ちょうど Salesforce MVP 更新時期で Rearward されるかドキドキしています。

さて、2018年3月1日に開催された「Salesforce Developers Meetup #17」に弊社から2名がLT登壇してきました。私はその様子を観戦してきましたのでレポートさせていただきます。

山﨑 : YACD(Yet Another Chatter Desktop)横内 : Lightning Design Systemのいろはと最近のアップデート
チームスピリットからLT登壇した2名(山﨑、横内)

感想

山﨑:YACD(Yet Another Chatter Desktop)

山﨑(id:dackdive)は Summer'18 で Chatter Desktop が廃止となることを受けて、Electron で Chatter Desktop の代替アプリを作成している取り組みを発表しました。単に代替アプリを作成しているだけにとどまらず、Electron、Salesforce と Electron アプリの認証、Chatter API など様々な技術検証をしています。

www.slideshare.net

また、GitHubでリポジトリを公開していますので、ご興味のある方は覗いてみてください。Electron を利用して Salesforce 用のデスクトップアプリケーションを作成したい場合などノウハウを使いまわせると思います。

GitHub - zaki-yama/chatter-desktop: Chatter Desktop made with Electron

チームスピリット・アドベントカレンダーで同じく山﨑が投稿している下記の記事も合わせて読むとよいと思います。Platform Event を利用したリアルタイムで連携するアプリケーションを作成できるので、その他のことにも利用できそうです。

teamspirit.hatenablog.com

横内 : Lightning Design Systemのいろはと最近のアップデート

横内(id:ts-yokouchi)から Lightning Design System について話しました。 Lightning Experiece が本格的に開発に利用されるようになると、それらのデザインを統べる Lightning Design System を知らないわけにはいきません。また、これほど大規模で運用されている Design System は珍しく、Salesforce 界隈以外でもデザイナーに言及されることがあるようです。

今回は、Spring'18 の機能追加に伴い、Lightning Design System にも多くの追加や変更がありました。この発表では、それらがどういったものだったかまとめています。Activity Timeline、Brand Band、Carousel、Chat、Mapなどが追加になったそうです。

特に印象的だったことは、発表のなかで今回のアップデートの特徴として柔軟性が高くなっている点が挙げられていました。実際に、Spring'18 のリリース内容を見てもテーマカラーを設定できるようになったり、カスタマイズできる箇所が大幅に増えたりしており、同じような方向性を感じています。Spring'18 で大幅に柔軟性が上がったことで Lightning Experience への切り替えがさらに加速しそうです。

もう一つ感じたこととしては、Lightning Design System が Classicのときのデザインとは異なり、かなりの勢いで進化していくことです。これまでは、Visualforce の決められたタグを利用していればデザイン崩れなどは気にする必要がありませんでした。しかし、今後はバージョンごとにデザイン崩れを気にしていく必要があるかもしれません。このあたりは、今後も注視していきたいと思います。

Salesforce Developers Meetup #17

公式サイトでもイベントレポートが公開されています。その他に発表された方々の発表資料、イベントの様子が分かるような写真やツイートまとめなどが掲載されていますので、興味のある方はぜひご覧ください。

sfdg.tokyo

宣伝

弊社チームスピリットでは、定期的に勉強会を開催しております。下記のサービスでメンバーになってもらうと、通知を受信できるようになりますので、ぜひよろしくお願いします。

teamspirit.connpass.com

デザイナーミーツエンジニア 〜知ろうお互いを、そして考えよう〜 参加レポート

f:id:a-matsuda:20180211003622j:plain

みなさんこんにちは。PDチームの松田 (id:a-matsuda) です。

今回は、チームスピリットでプロダクトデザインを担当している横内 (id:ts_yokouchi) が発起人となり、1/31(水)に開催した勉強会「デザイナーミーツエンジニア」の様子をレポートします!

teamspirit.connpass.com

本イベントではデザイナーとエンジニアの協業に焦点をあて、様々な角度から議論を深めました。登壇側だけでなく参加者の方々も質疑応答や懇親会を通して、「コラボレーション」について存分に語り合う会になりました。記事後半には、参加者された方々に回答いただいたアンケートより、参加者のみなさんがどう協業に取り組んでいるかについてもまとめています。

おかげさまでたくさんの方に参加ご応募いただき、当日は50名強ほどの方にご参加いただきました。デザイナーとエンジニアの割合は4:5くらい(その他の職種の方もご参加いただきました)となりました。

当日のハッシュタグの様子はこちらです。

togetter.com

Lightning Talk

(発表順)

「頑張らないシステム亅吉川 雅彦さん

speakerdeck.com

まず最初のLTは、吉川さん。 課題や問題があるときには、視点を変えて、根本から変えられないか考える。そのときに重要なのは頑張って解決するのではなく、頑張らずに解決すること。 デザイナーとエンジニア間の頑張らないシステムとは?事例を交えてのお話でした。

デザイナーとエンジニアの関係性だけでなく、様々なテーマの課題や問題の解決を考えるときに、重要な考え方だと思いました!

「共有地点DOKO」たじま ちはるさん

speakerdeck.com

デザイナーとエンジニアの共有地点、DOKO?DOKO、DOKO?と私は興味津々でした。

たじまさんのお話はデザイナーとエンジニアだけでなく、ディレクターとエンジニアの関係性でも共感できる部分があります。もっと言うと開発や制作の現場だけでなく、チームで仕事をしていくときの基本のようにも感じました。

発表の中で紹介されたクリエティブブリーフ、さっそく弊社でも活用して次期製品見直しを行っています!

「チームをかえていくこと そして、泥臭さについて亅横内宏樹

speakerdeck.com

いい感じにデザイナーとエンジニアが協力し、開発の真ん中にデザインがある、そんな開発のかたちを作っていきたい。チームに変えていくために横内がチーム内で取り組んだこと、そして変わりつつあるチームは今など、熱い内容のトークでした。

一人からでも、チームに変化を及ぼせることを体現してくれた横内が、人知れず取り組んでくれていたことも知れる、興味深い内容でした!!

「エンジニアから考えるデザインチームビルディング」大木 尊紀さん

speakerdeck.com

大木さんの会社ではエンジニアとデザイナーがどのように歩み寄りを見せているのかをリアルに公開してくれました。

印象的だったのが、デザイナーとエンジニアが一緒になって、お互いがやりやすい方法を考えるということ。 結果的にデザイナーがエンジニアの開発フローやツールに乗ることを決めたそうですが、チームの皆が腹落ちしながら改善を進めて成果に繋げているところがすごいなぁと思いました!

パネルディスカッション

LT登壇者の方々(横内のぞく)と元デザイナーでエンジニアのナユさんを交え、モデレーターとして弊社の山崎 (id:dackdive) による進行でディスカッションが行われました。パネリストの方々には「さっくばらん」に喋っていただき、現場の抱える悩みを根本から語らう時間になりました。

話し合ったテーマ

募集時にあつめたアンケートから以下のテーマをいただいてディスカッションを行いました。

  • 作業分担時にこじれないために気をつけていること
  • 作業に入る前のスケジュールの立て方
  • 外部のデザイナーとの付き合い方
  • 仕様書はどのようなものを用意していますか?
  • お互いの伝え方で気をつけていること。
  • 失敗事例と改善案
  • お互いに知っていてほしいこと

印象に残った話

箇条書きになりますが、語られた話の中で私は以下のような内容が印象に残っています。

  • わからないことはわからないままにしない
  • わかっている人がわかっていない人に伝えることが自然にできるチームづくり
  • 目的やゴールをチームで共有する、デザイナーとエンジニア間だけでなく!
  • デザイナーは、どうしてそのデザインにするのかの意図や理由を明確に伝えられることが必要
  • エンジニアもデザインの観点で、デザイナーにフィードバックできないといけない。エンジニアもデザインを学ぶべき
  • デザイナーを会議に呼んでくれ!

LTの中でも繰り返し出てきた「プロジェクトおよびお互いの意図」共有するということがパネルディスカッションの全編を通じて話されていたように思います。

アンケート

当日回答をお願いしたアンケートでは、ブログへの掲載可否を記載していただきました。載せても良いと言っていただいた内容をまとめて掲載いたします。

全体の感想

大まかには以下のような感想をいただくことができました。

  • 参考になった、いろんな意見が聞けた
  • コミュニケーションの大切さを再確認した
  • お互いの考え方の違いを実感できた
    • お互いを知ることの大切さ
  • 運用に入る時の体制づくりについても聞いてみたい

協業のための取り組み

「今協業のためにとりくんでいること・これから取り組もうと思っていることはありますか?」という質問に対して、かなりのボリュームかつ内容も多岐にわたる回答をいただきました。そのまま掲載させていただきます。

コミュニケーション

  • 意識していませんが、毎月プレミアムフライデーやっています
  • エンジニアさんは、仕様決定やデザイン上のチャレンジなど「できれば巻き込まれたくないに違いない」と勝手に思い込んでいたので、これからは巻き込んでいこうかなと思いました。相談することで自分の勉強になる。という部分など、本当にそのとおりだと思うので
  • コミュニケーションや認識のすり合わせの場を設けたい。社内勉強会を行っていきたい
  • フリーランスだと自分の作業工程の前後がどうしても見えにくい(それでいて、そこをおさえておかないと良い仕事ができない)勉強会やコミュニケーションをとれる機会を利用して各工程の意見をひろうようにしている
  • お互いの歩み寄り
  • 職種の垣根をなくすこと
  • 一緒にランチをとるとか、まずは業務以外の部分で共有できるところが増やせると良いなと思います
  • エンジニアだけでなく他部署とのやりとりでデザイナーとして最大限取り組めることを考えたいと思います
  • 困っていることがないか?というふうに声をかける
  • パネルディスカッション的なミーティングや会議をしてみたいと思います
  • ツール導入の教育コストがチーム内でとれない状況があり、ツール導入時の効果を想定して話し方工夫しました
  • まずは社内のデザイナーさんとコミュニケーションを取ることから始めたいです
  • その人の立場になって、考えた上で話すこと
  • 自分のスキルをあげること、自分がいちばん下っ端だからと発言をすることに抵抗があるので、スキルを上げたいと思っていたけど今回参加して上下関係無くコミュニケーションをまず取ろうと思った

お互いのことを知る

  • 相手と相手の仕事の学習
  • デザイナーですがフロント側の勉強をはじめました。完全分業ですが知っていて損はないです
  • コーディングの勉強、実際にprotを作って実装依頼をしている

プロセス・設計・ツール

  • Atomic Designについてデザイナーに打診した
  • デザインのレビュー環境を整える
  • デザインレビューをプロダクトに関わるメンバーが気軽に参加できる環境作り
  • 意見であった「ルールをつくらない」が腑に落ちた、コミュニケーションベースで
  • Zeplinの使用
  • 現状→レビュー会、社内報などなど、特に成果を可視化することで信頼構築のフェーズ
  • 目標→ペアデザイン
  • 企画〜開発まで協働している。目的や指導のすり合わせをことあるごとに行い目指す場所を一致させている
  • マニュアル、手順書のドキュメント化、ルール化をすすめています
  • デザイナーももっとエンジニアの業務に関わっていけるような仕組みづくり。働きかけ
  • 情報共有、手順や効果などのドキュメント作成
  • すべてのレイヤーに首をつっこむ
  • 首尾一貫できる(Director → Designer → Frontend Engineer)ツール導入を検討しています

その他

  • 意欲的に今回のようなイベントに顔をだしている
  • 自分がディレクションすれば基本的に協業すると思っています
  • デザイン系の本の布教

まとめ

「みんなはどうやっているんだろう」という疑問への回答、関係性をよりよくするために一歩前進する方法など、参加した人が何か一つは持ち帰ることができる勉強会だったのではないでしょうか。

私自身は、エンジニアやデザイナーとして最前線で開発をしているわけではないのですが、チームや自分以外の周囲の人との関係性を考える上でのヒントをもらえたような気がしています。

懇親会では「他の職種との協業についても話を聞きたい」「もっと具体的なもっと具体的な役割など細かいところが聞きたい」などといった声も聞かれました。デザイナーミーツエンジニア第2弾 Deep Dive が楽しみですね!!

チームスピリットでは定期的に勉強会を実施しています。ぜひ次回も楽しみにして下さい!

teamspirit.connpass.com

【2018年度】グローバルインターンシッププログラムを開始しました!<海外大学生歓迎!日本語不問◎>

こんにちは。プロダクト開発チームの松田(id:a-matsuda)です。

プロダクト開発チームでは、
海外大学生向けのインターンシップを開始しました!

チームスピリットでは、昨年11月に、初の海外法人となる「TeamSpirit Singapore Pte. Ltd.」をシンガポールに設立し、「TeamSpirit」のグローバルでの販売活動を本格的にスタートさせました。
「TeamSpirit」を開発するプロダクト開発チームも、人種を問わず優秀なメンバーと、
もっと多様な視点を持って創造的なプロダクトを作っていくことを目指し、今回のプログラムをスタートしました。

概要

今回のグローバルインターンシッププログラムは、 企業向け業務アプリケーション分野をリードするクラウドアプリケーション「TeamSpirit」を開発している、技術力が高く経験豊富なエンジニアとともに、 実践的なプロダクト開発を経験していただけます。

  • JavaScript モダンライブラリ React / Redux を採用
  • 最先端のPaaS「Salesforce Platform」を利用
  • 単なるワークショップやトレーニングではありません!リアルなプロダクト開発、アジャイル開発を体験することができます!
  • チーム内のコミュニケーションは英語で行います、日本語スキルは不問です!

ぜひ、4週間のインターンシッププログラム in TOKYO に参加してください!

詳細&お申し込み

www.teamspirit.com

To foreign students

Join us for a 4 week internship program in TOKYO!!
TeamSpirit Global Internship Program (TSGIP), that offers the unique opportunity to gain invaluable personal and professional experience by working hand-in-hand with our experienced engineers developing the market leading cloud application, TeamSpirit.
In TSGIP, you will get hands-on experience of practical application development using JavaScript, JavaScript modern library React/Redux, and leading-edge PaaS, i.e. Salesforce Platform.
You can also experience the real world agile development, not in workshop or training!
Communication within team will be done in English (Japanese skill is not required).

www.teamspirit.com

プロダクトディベロップメントチーム解体新書!(人・趣味編)

みなさま、明けましておめでとうございます。 本年も TeamSpirit Developer Blog をよろしくお願いします!! PDチームの松田(id:a-matsuda)です。

今回は、プロダクトディベロップメントチーム(以下、PDチーム)を解体したらどうなる?という企画の後編となります。
前回の「技術・開発環境編」はいかがでしたか? 切り口は技術や開発環境でしたが、PDチーム一人一人の個性が滲み出る内容にはなっていたかと思います。
後編では、人にフォーカスし「人・趣味編」としてお届けします ♪
前回に引き続き、PDチームメンバーに、マクロミル社のセルフアンケートシステムQuestantでアンケートを行い、その結果をまとめました。

f:id:a-matsuda:20180112151122j:plain

あなたの性別を教えて!

PDチームのメンバーは、ご想像のとおり多様です!まず性別ですが、チームの1/4が女性で、そのうち半分以上が、お子さんを育てながら、仕事も両立しているママエンジニアです。まだまだ女性が少ないので、増えていくといいなと思っています!
また今回、アンケートはとっていませんが、PDチームには中国出身のメンバーも2名おり、国籍や性別を問わず、みな活躍しています!

f:id:a-matsuda:20180105215752p:plain

あなたの年齢を教えて!

30代に続いて、20代、40代がほぼ同じ割合で、非常にバランスの良い年齢構成となっています! 私たちは、"TeamSpirit"を開発しているスタートアップ企業のプロダクト開発チームなので、若手メンバーが多いイメージがあるかもしれません。
実際にはグラフの通り、若手メンバーだけでなく、経験のあるメンバーも多いので、明るく勢いはありますが、全体的には落ち着いていて相談もしやすいチームだと思います!

f:id:a-matsuda:20180105215701p:plain

あなたの血液型を教えて!

みなさん、日本人の血液型の発現率をご存知でしょうか。大まかに、A型が40%、B型が20%、O型が30%、AB型が10%だそうです。

PDチームはというと・・・みなさま、ご覧ください! 際立つのが、O型が最大勢力であることと、AB型がなんとなんと”19%”もいること。

f:id:a-matsuda:20180105215831p:plain

ちなみにみなさんご存知かもしれませんが、AB型は世界中で4%の割合しかおらず、AB型が0%の国があるくらい、AB型は極端に少ないのだそうです。
ちなみに、民族別で最もAB型が多いのは、日本のアイヌ民族で、その割合はO型17%、A型32%、B型32%、AB型18%だそう。AB型の割合が2割近いとは奇跡的なことで、世界を見ても他にはないそうです。(ちなみに私は、マイペースB型です)
このチームで奇跡が起きていること、そしてどこかの血液型に偏っていないということ、が見えてきました!全部の血液型がしっかり自分をアピールしている感じ・・というのがチームをよく表しているかも!

前職の事業内容を教えて!

がらっとかわって、前職の事業について聞いてみました。SIまたはソフトハウス出身のメンバーが約半数、自社プロダクト・サービス開発からの人は3割くらいでした。 プロダクト開発の経験がないメンバーも多いですが、すぐにチームに馴染んで、ガシガシとプロダクト開発を推進しているメンバーばかりです。前職の事業にかかわらず、TeamSpiritを通してお客様に価値を届けたいという共通した思いをもって、開発をしています。

f:id:a-matsuda:20180105224146p:plain

仕事以外の時間、何をしているか教えて!

これも興味深い、仕事以外はみな何に時間を使っているのでしょう??

f:id:a-matsuda:20180105224415p:plain

  • No.1 ”読書”が圧倒的ですね。みんなどんなジャンルの本を読んでいるのでしょうか??Slackの雑談チャネルでは、技術書はもちろん、ビジネス開発や一般的なビジネス書まで、いろんなジャンルの本が話題のぼっています。
  • No.2 ”子育て”!ママエンジニアだけでなくパパエンジニアもいますので、それを表していますね〜。みんな家でもがんばってる!!
  • No.3以降 ”映画・テレビ、音楽鑑賞”、そこに混じって、やっぱりみんな大好き”技術のキャッチアップ”や、”料理”や”筋トレ”などオフィスでも主張の激しい趣味たちがランクインしています!

主張している趣味・料理

11/29に(イイニクの日)、美味しいお肉をふるまってくれたりします。みんな、相当お腹がすいてるんでしょうね。必死にサンドイッチを作っている様子が。笑
すばらしい趣味を持ってくれて、ありがとう!

f:id:a-matsuda:20180106000209j:plain f:id:a-matsuda:20180106000224j:plain

主張している趣味・筋トレ

チームスピリットの部活動として暗黙の公認となっているヘルスケア部では、筋トレを推奨しています。チームスピリットで僕と筋トレ!(by部長) f:id:a-matsuda:20180109151524j:plain

チームスピリット社を選んだ理由を教えて!

改めて、なぜチームスピリット社だったのかを聞いてみました。

f:id:a-matsuda:20180105224312p:plain

  • なるほど、会社のビジョンや価値観、チームスピリットの一員になることによって携わる仕事に魅力を感じて入社を決めたメンバーが多いのがよくわかります。
  • 続いて、フレックスタイム制(PDチームは11:00~16:00がコアタイム)や在宅勤務制度(時短メンバー以外は週1回)など、仕事に集中できる制度も魅力に感じてくれたようです。
  • PDチームの文化(勉強会やテックランチ)に触れて、ここで働いてみたいと思ってくれたメンバーも多かったのは、チームの一員として大変嬉しい限りです!

チームスピリットでは定期的に勉強会を主催していますので、ぜひ興味のあるものがあれば、お越しください!connpassページへ

まとめ

2回に渡ってお届けしました、プロダクトディベロップメントチーム解体新書、いかがでしたでしょうか?
いつも一緒に仕事をしていても、案外知らないことがあることに気づきましたし、面白いチームメンバーに囲まれ刺激的&幸せだと再認識した、自身にとっては意味のある企画でした。
チームについては十分知り尽くしているというそこのあなた、ぜひチームの解体新書作りにチャレンジしてみてください。思わぬ発見があるかもしれませんよ!

最後に

チームスピリットでは、一緒にプロダクト開発を推進してくれるメンバーを募集しています!少しでも興味をお持ちのかた、ぜひオフィスに遊びに来てください。お待ちしています♪

エンジニア募集

QAエンジニア他募集中!

Amazon Echo から Salesforce へ繋げてみた

こんにちは。
株式会社チームスピリットの古川(id:furukawa-hisakatsu)です。

Amazonにて発売されましたスマートスピーカー「Amazon Echo」が11月に日本に上陸しました。
私自身も11月末にAmazon Echoが届きましたので試しにSalesforceに繋げてみました。

f:id:furukawa-hisakatsu:20171222194712p:plain

(可愛いやつです)

後、この記事はチームスピリット Advent Calendar 2017の21日目です。(遅刻) adventar.org

概要

今回はAmazon Echoと接続する音声サービス「Amazon Alexa」からAccount Link機能とAPI Gatewayを使用してSalesforceと接続し、
Lambdaから未承認レコードの件数の取得を行うカスタム音声サービス「Alexa Skills Kit」を作成します。
お試しまでとなりますので公開用の設定ではありません。

必要なアカウント

Alexaからのリクエスト処理をLambdaで作成

Alexaからのリクエストを受付し、Salesforceに接続、その後Alexaに件数を発言するレスポンスを返す処理を作成します。 ソースコードは下記URLから参照して下さい。

github.com

  • AWSにログインし、「Lambda」を選択し、関数の作成をクリックします。

f:id:furukawa-hisakatsu:20171222160507p:plain

  • 次に「一から作成」を選択し、名前を適当に入力し、ランタイムは「Node.js 6.10」を選択し、ロールは既存のままで選択して保存します。

f:id:furukawa-hisakatsu:20171222160634p:plain

  • 関数の詳細画面が表示されましたら、「関数コード」の「コード エントリ タイプ」に「.ZIP ファイルをアップロード」を選択し、こちらをダウンロードしてアップロードします。

f:id:furukawa-hisakatsu:20171222162847p:plain

  • 表示している関数がAlexa Skills Kitから呼び出されるトリガーを設定するため、「Designer」のサイドメニューから「Alexa Skills Kit」を選択し、「トリガーの設定」から「追加」をクリックします。

f:id:furukawa-hisakatsu:20171222163241p:plain

  • 最後に右上の「保存」をクリックし、Lambdaの設定は完了です。

f:id:furukawa-hisakatsu:20171222163308p:plain

  • 後のスキル設定で使用するため、右上の「ARN」を何処かに退避します。

f:id:furukawa-hisakatsu:20171222180221p:plain

トークン取得時のレスポンスを工夫するためAPI Gatewayを作成する

Salesforceからのアクセストークン取得を行うためにAPI Gatewayを作成します。

  • AWSにログインし、「API Gateway」を選択し、「APIの作成」をクリックします。

f:id:furukawa-hisakatsu:20171222164535p:plain

  • 「Swagger からインポート」選択し、下記コードを入力して、「インポート」をクリックします。
    (名称変更したい場合は、下記コードの「title」属性の値を変更してください。)
{
  "swagger": "2.0",
  "info": {
    "title": "SalesforceProxy"
  },
  "schemes": [
    "https"
  ],
  "paths": {
    "/": {
      "post": {
        "produces": [
          "application/json"
        ],
        "parameters": [
          {
            "name": "Content-Type",
            "in": "header",
            "required": false,
            "type": "string"
          }
        ],
        "responses": {
          "200": {
            "description": "200 response",
            "schema": {
              "$ref": "#/definitions/Empty"
            }
          }
        },
        "x-amazon-apigateway-integration": {
          "responses": {
            "default": {
              "statusCode": "200",
              "responseTemplates": {
                "application/json": "#set($params = $input.path('$'))\n{\n#foreach($paramName in $params.keySet())\n    #if($paramName == \"access_token\")\n    \"expires_in\": 3600,\n    #end\n    \"$paramName\": \"$params.get($paramName)\"\n    #if($foreach.hasNext)\n    ,\n    #end\n#end\n}\n"
              }
            }
          },
          "requestParameters": {
            "integration.request.header.Accept": "'application/json'",
            "integration.request.header.Content-Type": "method.request.header.Content-Type"
          },
          "uri": "https://login.salesforce.com/services/oauth2/token",
          "passthroughBehavior": "when_no_templates",
          "httpMethod": "POST",
          "type": "http"
        }
      }
    }
  },
  "definitions": {
    "Empty": {
      "type": "object",
      "title": "Empty Schema"
    }
  }
}

f:id:furukawa-hisakatsu:20171222170333p:plain

  • これだけではまだ使用できないため、作成に成功しましたら「アクション」をクリックして、「API のデプロイ」をクリックします。

f:id:furukawa-hisakatsu:20171222170441p:plain

  • 「デプロイされるステージ」に「[新しいステージ]」を選択しステージ名等を適当に入力して「デプロイ」をクリックします。

f:id:furukawa-hisakatsu:20171222170509p:plain

  • 成功しますとステージエディタが表示されるので、「URLの呼び出し」を何処かに退避します。(これもスキル設定で使いますよ)

f:id:furukawa-hisakatsu:20171222170914p:plain

余談

OAuth認証処理を行ったことある人は(あれ?)と思われますが、 本来、「https://login.salesforce.com/services/oauth2/token」に通信してアクセストークンを取得するのがSalesforceの認証となりますが、 Amazon AlexaのAccount Link機能でアクセストークンを取得する際、初回時は問題ないのですが、 アクセストークンが時間切れとなり再度取得が必要となった場合、 Amazon Alexaはアクセストークン取得のレスポンスに含まれている「expires_in」(有効時間)が過ぎているかを判定し再度取得する仕組みと思われます。 ですが、Salesforceからのアクセストークン取得時には「expires_in」が含まれていないため、これを含ませるためにAPI Gatewayを作成します。

Salesforceのセッション時間は設定による可変式でありますが、これを検出する手段がないため、今回は固定で1時間を指定しております。

Alexaのスキルを作成しよう

AWS側の設定が終わりました。Alexaスキルを作成しましょう!

  • Amazon Developerにログインし、「Alexa」をクリックし、「Alexa Skills Kit」の「始める」をクリックします。

f:id:furukawa-hisakatsu:20171222171221p:plain

  • Alexa スキル一覧の画面が表示されましたら、「新しいスキルを追加する」をクリックします。

f:id:furukawa-hisakatsu:20171222171812p:plain

  • スキル情報を設定する画面が表示されるため、下記設定を行い、「保存」をクリックします。
    • スキルの種別:カスタム対話モデル
    • 言語:Japanese
    • スキル名:適当に入力して下さい
    • 呼び出し名:こちらも適当に入力してください。

f:id:furukawa-hisakatsu:20171222172057p:plain

  • 「対話モデル」を選択し、「インテントスキーマ」及び「サンプル発話」に下記コードを入力し、「保存」をクリックします。

    インテントスキーマ

{
  "intents": [
    {
      "intent": "SalesforceIntent"
    }
  ]
}

f:id:furukawa-hisakatsu:20171222173646p:plain

サンプル発話

SalesforceIntent 未承認個数を教えて

f:id:furukawa-hisakatsu:20171222173708p:plain

  • 次のSalesforceの設定のため、「設定」をクリックし、「アカウントリンク」の「ユーザーにアカウントの作成や既存のアカウントへのリンクを許可しますか?」に「はい」を選択して、
    「リダイレクトURL」を何処かに退避しておきます。

f:id:furukawa-hisakatsu:20171222174755p:plain

(まだ設定しますので画面はそのまま)

Salesforceに繋ぐための設定をする

スキルの設定を一旦中断し、AlexaからSalesforceに接続するための設定をしましょう!

  • Salesforceにログインし、右上の歯車をクリックし、「設定」をクリックします。

f:id:furukawa-hisakatsu:20171222174320p:plain

  • 設定画面が開きましたら「アプリケーション」から「アプリケーションマネージャ」をクリックし、「新規接続アプリケーション」をクリックします。

f:id:furukawa-hisakatsu:20171222174500p:plain

  • 「接続アプリケーション名」や「API 参照名」、「取引先責任者 メール」を適当に設定しましょう。

f:id:furukawa-hisakatsu:20171222174914p:plain

  • 「OAuth 設定の有効化」にチェックを入れ、下記設定を行い、「保存」をクリックします。
    • コールバックURL:先程退避したリダイレクトURLを貼り付けましょう
    • 選択したOAuth範囲:「データへのアクセスと管理(api)」、「ユーザに代わっていつでも要求を実行(refresh_token, offline_access)」、「基本設定へのアクセス(id, profile, email ,address, phone)」を右に追加します。

f:id:furukawa-hisakatsu:20171222175245p:plain

  • 「次へ」をクリックし、設定完了!

f:id:furukawa-hisakatsu:20171222175319p:plain

  • 画面が切り替わりましたら「コンシューマ鍵」と「コンシューマの秘密」を退避しておきましょう。次に使いますよ!

f:id:furukawa-hisakatsu:20171222175618p:plain

AlexaとSalesforceが繋がる時です

Alexaのスキル設定を再開し、Salesforceの接続設定をしましょう!

  • Amazon Developerのスキル設定画面に戻って「設定」をクリックします。(もう開いているかもしれません)

f:id:furukawa-hisakatsu:20171222180045p:plain

  • 「サービスエンドポイントのタイプ」に「AWS Lambda の ARN (Amazonリソースネーム)」を選択し、「デフォルト」に先程退避したLambdaの「ARN」を貼り付けます。

f:id:furukawa-hisakatsu:20171222180722p:plain

  • 「アカウントリンク」から「ユーザーにアカウントの作成や既存のアカウントへのリンクを許可しますか?」に「はい」を入れ(もう入れてるかもしれません)、下記設定を行います。
    • 認証 URL:「https://login.salesforce.com/https://login.salesforce.com/services/oauth2/authorize
    • クライアント ID:退避したSalesforceの「コンシューマ鍵」
    • 認可の承諾タイプ:「Auth Code Grant」
    • アクセストークンURL:退避したAPI Gatewayの「URLの呼び出し」
    • クライアントシークレット:退避したSalesforceの「コンシューマの秘密」
    • クライアント認証スキーム:「リクエストボディの資格情報」

f:id:furukawa-hisakatsu:20171222181415p:plain

  • 最後の「プライバシーポリシー URL」は適当に入力しましょう。(本当は個人情報の取扱が記載されているURLが必要ですよ)

f:id:furukawa-hisakatsu:20171222181654p:plain

  • 「保存」をクリックして「次へ」をクリックします。
    (このあたりでエラーが起きやすいですね、エラーが起きたら手順を再確認してみましょう)

さぁテストの時間だ!

面倒な設定作業を終え、ついにAlexaの言葉を聞く時が来ました。

Amazon Echo等を持っていない方向け

なんとAmazon Echoのシミュレータがあるのでログインして許可してみましょう。

echosim.io

Salesforceの認証が必要です

まだ声を聴くのは早かったですね、Salesforceの認証をしましょう

  • お手持ちのスマートフォンにAmazon Alexaをインストールするか、もしくは http://https:/alexa.amazon.co.jp からログインします。
    (スキル開発したアカウントでログインしてください)

  • 「スキル」を選択して「有効なスキル」をクリックします。(Amazon Echo等が設定済みか上のシミュレータ連携されていないと開けないかもしれません)

f:id:furukawa-hisakatsu:20171222183300p:plain

  • 先程登録したスキルが表示されているのでクリックします。
    (表示されていなかったらログインするユーザが異なっているか、スキルの設定が途中かもしれません)

f:id:furukawa-hisakatsu:20171222183656p:plain

  • 「設定」をクリックし、「アカウントのリンク」をクリックしてSalesforceにログインします。
    (Salesforceのログイン時にこのアプリケーション許可するとウィンドウが出ると思いますが、「許可」するをクリックして下さい)

f:id:furukawa-hisakatsu:20171222183756p:plain

  • アカウントのリンクに成功しているはずです!
    (成功していなかったらスキル設定やSalesforceの設定を再確認!)

f:id:furukawa-hisakatsu:20171222184202p:plain

声を聞きましょう

youtu.be

(なかなか通じない場合は単語分割していってみるのもいいかもしれません)

締め

今回Alexaにてスキルを実装してみましたが、アカウント管理や認証処理をAlexa側に一任できるのは大きく、
わざわざユーザを特定したり、データベースを用意したりする必要もないのは魅力的であり、
開発自体もsdkが用意されていたりと特に詳しく勉強しなくても開発できるのはいいですね。

皆様も是非仕事役に立つような、あるいはちょっと役に立つような、はたまた面白いようなスキルを開発してみて下さい!

公式でのSalesforceとの接続はAlexa for Businessでなにか来るみたいですけど日本にくるのでしょうか?

入社して10ヶ月がたったので入社エントリ書く

どうも、こんにちは
腹筋しろよ(ブログ出張バージョン)

チームスピリットでデザイナーをやっていますid:ts-yokouchiです。

本記事はチームスピリット Advent Calendar 2017の14日目および転職 Advent Calendar 2017の21日目です。日付とはなんだったのか。

弊社に入社してちょうど10カ月ほどたった今、入社エントリーを書こうと思います。

自由な働き方

弊社では働き方にフォーカスしたサービスを提供しているので、もちろん働くわれわれも比較的柔軟な働き方ができます。

フレックスタイム制

弊社では11時から16時がコアタイムのフレックスタイム制が開発チームに導入されています。
8時間/1日 労働を基準に日によっては長く、またある日は短く、自由に時間を決めながら働くことができます。

入社してしばらくは8時出社の17時退社をするなどをしていました。みんなが必死に働いてる中帰宅するのは楽しいか?、めっちゃ楽しい!
ただ、今ではすっかり11時ギリギリ出社です。オフトゥンやっぱすっきやで。

日によっては10時くらいまで働くこともあれば、勉強会のお手伝いなどで17時に退社したり勤務時間はバラバラです。
コアタイム外にミーティングが組まれるようなことをもあまりないためスケジュールが組みやすいと感じています。

スタンディングデスク

f:id:ts-yokouchi:20171221131519j:plain ※僕ではなく同僚氏です。

入社してしばらくダンボールによるスタンディングを行っていた私ですが、偉い人が哀れんでくれたらしくちょっと前からフリーアドレスの席にスタンディングデスクが設置されています。

※ダンボールデスクについてはこちらの記事にまとめております。 teamspirit.hatenablog.com

オカムラ製のSwiftが全部で8脚もあります。
これは非常に良いデスクで、天板面積も広い上に昇降が電動式となっています。
疲れた座り、座り疲れたら立つという運用を行っています。

「は?スタンディングで座ったら意味なくない?」
と突っ込まれることもしばしばですが、
「勘違いしないで欲しい、私はやがて立つために座っている、意識高いシッティグをしている。
などのやりとりを行っています。

スタンディング、腰への負担も少ない上に眠気もおさえられるため本当に良きです。

リモート

だいたい週1でのリモートが推奨されていますし、時短勤務でほぼほぼフルリモートで働いてる社員の方もいます。 MTGもハングアウトを使ってリモート参加が当たり前にできる環境になってて良いと思います。

私も入社するにあたり10万くらいの椅子を買って自宅に設置し、自宅勤務への高まりを自宅に表現して、自宅への愛を深めていたのですが、最近は全くやっていません。

  • 役割的に人とのコミュケーションが重要
    • すぐ気になったことを相談しがち
  • 自宅だと昼寝する

が主な理由です。

リモートが推奨されていると言っても、前述のとおりスタンディングデスクが導入されているなどオフィスでの働きやすさもちゃんと考えてくれる会社です。 リモートが可能であっても、使うかどうかは当人達に任せられており、かつ両方の場合で働きやすいのは素晴らしいことだと思います。

チームについて

エモいことを頑張って書こうと思ったのですが、面倒になったのでやめます。恥ずかしいし。
大体チームについて感じてることはこんな感じです。

  • 常に前を向いているチーム
  • 技術が好き
  • 垣根なく意見のやり取りができる

3つ目は良いです。風通しが良い。 最初はフロントエンドエンジニアで採用された私も、いろいろあってデザイナーになりました私は今日も元気です。

まとめ(まとめない)

弊社について良い所を書き連ねるエントリーになりました。(検閲が入るので)
個人ブログなどでもうちょっとエグ味があることを裏で書きたい、会社の人は目をつぶってください。

総括するとスタンディングデスク最高なんでスタンディングデスクを信じろ。信じる人募集という感じです。
今のところ高級なスタンディングデスクがある良い会社に入ったなと思ってます!

ちなみに入社の決め手は最初に受かったからです。
勢いって大事ですよね!

お読みいただきありがとうございました!

QAエンジニアが参画する時の7つの確認リスト

この投稿はチームスピリット Advent Calendar 2017 - Adventarの20日目の記事です。

adventar.org

こんにちは、QAチームの生井(id:riririusei99)です。
今年も残すところあと少しになりましたね。

はじめに

QAエンジニアは「テスト」や「品質保証」といった幅が広いテーマに対してリードするエンジニアです。
テストの自動化、テスト設計&テストマネジメント、開発チームのテストを改善していく役割など仕事内容は会社・チームによって異なるかと思います。 そんな中でどういった働き方を期待されているのかは認識にズレがないように把握している必要がありますよね。

今回のテーマはそんなQAエンジニアがチームに参加する前に確認しておくべき項目について、 ソフトウェアテストドキュメントの国際標準であるIEEE829-2008を参考に作ってみましたという内容です。

7つの確認リスト

  1. 目的
  2. テストアイテム&スコープ
  3. アプローチ
  4. アウトプット
  5. 参加するまでのタスク
  6. 役割
  7. あってはならないこと

1.目的

ここではなぜQAエンジニアが必要なのかを思い切って確認します。
プロダクトへの課題感、期待されていることが聞けるはずです。
目的を聞くことで目指すべき品質目標や今後のテスト計画が立てやすくなります。
どんなことを聞けばいいかわからない場合は、QAエンジニアやソフトウェア品質を大枠で捉えて分解して考えてみると良いかもしれません。

2.プロダクト&スコープ

携わるプロダクトについて現段階でわかっていることを確認します。
具体的にテストして欲しいバージョンや環境、開発フェーズといったことを聞くことで必要なものが見えてきます。 その他、既に十分テストしている機能がある場合など、テストするもの/しないものをわかっている範囲で確認しておきましょう。

3.アプローチ

目的を達成するためにどのような手を打つのかスケジュール、テスト体制などをすり合わせます。
開発スプリントとテストスプリントを別々に用意しテストする場合や、スプリント期間内にテスト期間に設けるなど参加するチームによってそれぞれ変わっていく部分だと考えています。
余裕があれば目的を達成したあとの話も確認できると良いです。(現在はテストの設計がメインだが、テストの自動化にも注力したい。など)

4.アウトプット

テストなどの活動の結果として何をアウトプットとするかあらかじめ決めておきます。
具体的な内容としてテストレポートやインシデントチケットなどが挙げられます。
同時にインプットとして提供してもらえる資料などを確認することも重要です。
テスト計画書やインシデントチケットの項目など、弊社では作成した成果物をなるべく使いまわせることを意識しながら作成しています。

5.参加するまでのタスク

参加するまでに準備しなければいけないタスクを洗い出します。
テストデータの準備や環境準備など、QAエンジニアだけで解決できないものがないか確認しましょう。

6.役割

QAエンジニアしかできない仕事や、開発メンバーに協力してもらう部分を明らかにします。
具体的な例で言うと「インシデントチケットの起票はQAが行い、原因調査などは開発メンバーが行う」ことや、 「大容量テストに向けた設計をQAが行い、データの作成と実施を開発者メンバーに担当する」
といった想定される仕事の中でどの部分でだれが役割を分担するか確認しておきましょう。

7.あってはならないこと

プロダクトにおける「あってはならないこと」などは聞いておくとテストの優先順位や、品質目標を決める助けになります。
今後リスクになりそうな部分について事前に聞いておきましょう。
ここで聞いた内容は当たり前品質における観点材料やリスクベースドテストの分析材料など、様々な場所で再利用ができます。

まとめ

開発チームに参加した時によく聞かれそうな、聞いておけばよかったと思った内容をまとめてみました。
IEEE829はテスト計画書の作成に使われ、テストにおける共通認識を用意するには有用です。また今回確認したチェック項目は時間の経過とともに変わっていくこともあるので定期的に見返してみることも重要だと思います。
QAエンジニアといっても自動化が得意な人、テストのプロセス改善が得意な人などいろんなタイプがいますので、アサインした人、された人の双方の理解が深まる手助けになればうれしいです。