アプレッソに入社してました
本記事は、Appresso Advent Calendar の 7日目の記事です。
はじめまして。株式会社アプレッソ 開発部の野村です。
2017年8月にアプレッソに入社してました。
入社エントリをまだ書いていなかったので、この機会に書かせていただきます!
なにをやってきたか
新卒でソフトウェアベンダーに入社し、BtoBのWebサービス開発に携わっていました。 開発のほかにも、運用、サポート、営業支援と多岐にわたる業務を経験しました。 開発言語は Ruby on Rails で、それ以来 Ruby が好きです。
その後、教育系会社のエンジニアとして、受託案件のシステム・サービス開発に従事し、海外の開発ベンダーとのサービス開発などをしていました。
入社してやっていること
DataSpiderServista の開発チームに加わり、クライアントの開発や次バージョンに向けた開発をしています。
また、10月から初めた New Feature Showcase のとりまとめをしています。
New Feature Showcase とは、毎週「動くもの」を発表してドヤァ!とする場です。
もともとDataSpiderServistaチームはスクラムで開発していて、スプリントレビューで社内に新機能などをお披露目する機会がありました。
ですが、他チームの成果や、個々人で温めている機能改善案、ツールといった「動くもの」を披露する場は多くはありませんでした。
このような「動くもの」を共有して、技術の共有や製品の発展に役立てよう!というウィークリーイベントです。
アプレッソに入社して感じていること
入社前から先進的な取り組みをしている会社だと思っていましたが、入社後もそのイメージは変わらず、柔軟なところが多いです。
例えば、11月に溜池山王にオフィスが移転したのですが、以前よりも通勤ラッシュに悩む人が増えていました。そこで、出退社時間をずらしたシフト勤務の導入が発議され、すぐに実運用に向けて動き始めていました。 このようなフットワークの軽さは、Advent Calendar 5日目の元開発部長佐々木さんの記事にある「Growth Mindset」や「ムダの排除」といった考え方に起因していると感じました。
今後やっていきたいこと
アプレッソでは1年半前からスクラムを取り入れています。私自身は1社目でもスクラムを経験していて、その効果に可能性を感じていました。
スクラムによる開発を突き詰めて、アプレッソのスクラムを形作っていきたいと思っています。
また、「アプレッソ」を多くの人に知ってもらいたいなと思っています。
勉強会、Meetup、ボードゲーム会など企画できたら嬉しいです。
APIStudy#5 開催報告
こんにちは。技術部對馬です。
去る2月21日に、APIStudy#5が開催されました。
前回の#4 の様子はこちらからご覧ください。
今回はゲストに乗り換え検索アプリ「駅すぱあと」でおなじみの株式会社ヴァル研究所さんを迎え、APIについて語り合いましたので、その様子をご報告します。
第1部 LTタイム
まずは恒例LTからです!
なんと今回はヴァル研さん含め3名が登壇してくださいました!
ヴァル研究所 丸山さん
最初は、ヴァル研究所テクニカルエヴァンジェリストである丸山さんから。
ヴァル研・駅すぱあとのご紹介をしていただいたあとに(運営脇野とヴァル研究所は同い年!)、こんな駅すぱあとWebServiceAPIは嫌だ!をテーマにAPIへの思いをぶつけていただきました。
- APIKeyが紙で届く。コピーさせてくださいよぉ
- 自動発行されない
- パスが直感的ではない
- パラメータ多すぎ
- JSONが扱いづらい…
そして最後に恐ろしい画面が…!
道理で感情がこもっていたわけですね…。 そして#5開催日翌日(2月22日)が駅すぱあとの誕生日でした。惜しかった!おめでとうございました!
MOONGIFT 中津川さん
中津川さんはニフティクラウドのmobile backend エヴァンジェリストで、今回はmobile backendのお話でした!
そして、SNSで以下を呟いてもらうことが本日の目標。
#NCMBすごーい
(出たな、サーバルちゃん…!)
というのは冗談で本当はこっち↓
アプリ作っていてサーバーを建てなければいけないときに、まるっとカバーできるのがニフティクラウドです。
しかしそのAPIに4つの問題があるので、そちらを紹介していただきました。
- APIのバージョニング問題。 いつバージョンを切り替えるのが問題。
- セキュリティ問題。 妥当性チェックのときに、APIをコールしないと正しいかわからず、ハードルが上がる。
- 動的に変化するパス。 データストアでは勝手にクラス名をいじって保存場所を変更できる。 …が、美しくない!
- ドメイン問題。 4つもAPIのドメインがあって管理が大変。
ヴァル研究所 伊藤さん
そして最後は、伊藤さんから「WebAPIでダブルバッファリング」について。
データのチェック処理で完了までには時間がかかるので集計途中のデータを確認したく、WebブラウザからAPIで引っ張っていました。これをバッチで並行に処理していきます。
しかしそのうちどんどん処理時間が長くなり、タイムアウトが発生してしまうようになってきます。
そこでちょっと前のデータを予め集計し公開を繰り返すようにし、リクエストとデータ更新がぶつからないように変数を分けておく必要があったと、つまりダブルバッファリングが必要だったいうお話でした。
切り替えイメージに、またしてもサーバルちゃん!!いや、これはサーバル!
すごーい!けもフレはやっぱり人気なんだね!
そして、レスポンスに時間がかかるWebAPIはどう処理するべきなのか、議論したいとのことでした。
第2部
さて、続いてはお待ちかねのディスカッションタイムです!
今回のテーマは…
- レスポンスがかかる場合の方法
- APIのサポートが増加した場合の対応
- こんな最悪の状況いやだね!愚痴り隊
- 複数のAPIをバラバラで使う場合の方法
そしてグループに別れ、発散発散!
共有タイム
レスポンスがかかる場合の方法
レスポンスの許容範囲どのくらいか、というのはバッチとリアルタイムによってきます。
バッチの場合は、単位が営業日単位。
リアルタイムでは、厳しいところだと200ミリsec以内。
UXも結構大事!
レスポンスを早くするためには、リアルタイムでDBにアクセスに行かないのが1つのベストプラクティス!
あとは、お客さんの許容範囲を知ることが大事。
そしてその概念を営業に植え付けとかないと「遅いって言われてる!!!」って慌てちゃうので、認識をもたせましょう。
APIのサポートが増加した場合の対応
サポート大変だよね問題。
- 伝言ゲームが大変。
- 質問が「エラーが起きたんですけど…」
- 同じ人から何回も…
サポートの仕方はサイボウズさんがよくできているそうです! それは、コミュニティのユーザーさんが質問に答えてくれるエコシステム。 核となる人が必要なので、その人たちを見つけて意識付けをし、構築していきました。所謂エヴァンジェリストのような方々です。 見つけ方は、kintoneを作ったときに関わった人やTwitterによく書いてくれている人を…、ロックオン! kintoneのことが好きな人に、協力いただいているそうです!
またサンプルコードを充実させるのもよいプラクティス。 Azure API マネージドはいろんな言語でサンプルコードがあるから便利かも。 AIも使えるぞ!!!! あとは、問い合わせ自体を営業にやらせて鍛えるという案も。
営業さん!!狙われています!!!
こんな最悪の状況いやだね!愚痴り隊
再現ができないエラー、エラーメッセージの原因がいまいちわからないあるある!
エラー時のレスポンスコードが200でその中に理由が入ってて意外とわからない…。
エラー時のレスポンス出力コーディングまちまち…。などのエラーに関するあるあるから、 仕様がバラバラなどの仕様あるあるまで、たくさん発散していました。
ドキュメントが間違っている!!
パスワードつきのExcelファイルはいけてない!!!!!
…などなど、最後の方は滾っていましたね…。
複数のAPIをバラバラで使う場合の方法
いろんなAPIをまとめて使って、レスポンスや結果を返すことについて。
「分散処理してマージ」を繰り返すというのが実際にあったケースで挙げられました。
あと、A社B社C社のAPIを使いたいがレスポンスがそれぞれどのくらいで来るかわからない場合、どう処理するのか?の結果が以下2つ。
- 時系列で処理するように実装していく
- 処理ができた順番にレスポンスを返す
WebAPIには遅延がかならずあるので、そこの処理が重要になってくるという結論になりました。
人によってAPIの捉え方が違うし、APIへの関わり方によっても違ってくるので、いろんな立場の人とAPIについて話していけると面白い!
おわりに
LTでまさかサーバルネタがかぶるとは思いませんでした…。
そして今回も皆さん、十分に発散できたのではないかと思います!
いろんな思いを発散することができる!それがAPIStudy!(なのかもしれない)
今回のグラフィックレコーディング
完成したグラレコがこちら!
今回も素晴らしくきれいにまとまってますね♪
… ま た い た !
\サーバルだよ!/
なんだかんだで今回のMVPかもしれない…
そして
今回は開催報告が遅くなってしまって申し訳ないです…。
その為!!!!!
次回開催が定員オーバー!
なんということでしょう!
これも皆さんが楽しそうにAPIトークをしていただいているおかげです…。
次回はさくらインターネットさんで開催します。
そしてなんと!この度#6開催の増枠が決定!(2017/03/15情報更新) 40名まで定員を増やしました!
(APIに飢えている)けものはいても、のけものはいない♪
Welcome to ようこそAPIStudyパーク!
宜しくお願いします。
ペアプログラミングしていてもレビューは必要か?
こんにちは、開発部の野口です。
この記事では、私が所属していたスクラムチームでペアプログラミングが始まって、コードレビューがどう変わっていったかというストーリーをお話しします。
目次
- 目次
- ペアプログラミングが始まる
- GitHub:Enterprise 上でのレビュー
- ペアプログラミングしているとレビューが楽になる
- ペアプログラミングしていてもレビューは必要か
- 「ペアプログラミングしている」という事実から「コードレビューが必要か」はわからない
- まとめ : プラクティスの効果には常に意識的でありたい
ペアプログラミングが始まる
私が所属する DataSpider Servista の開発チームでは、昨年の夏から、スクラムフレームワークにのっとって開発を行っています。
人数の多い *1 チームでスクラムをやっていると、自然とペアプログラミングが始まります。
ただでさえ短いスプリント(一週間)のなかで、仕掛り作業を増やしても効果的でないからです。
たとえば、6 名のプログラマが「せーの」でそれぞれにタスクを取ると、6 つのストーリー *2 に並行着手することになります。
すぐに終わるものもあれば、時間がかかるものもあるでしょう。
さて、計画やふりかえりの時間を除くと 4 日間しかない作業期間において、最も時間がかかるストーリーに着手した人が、次の日風邪で休んだらどうなるでしょう?(答 : おしまい)
こういった問題を防ぐため *3、チームは自然とペアプログラミングをするようになりました。
私は 2017 年の 1 月末までチームにいたのですが、その頃には、計画の日を除いて、毎日 4 ~ 5 時間ほどをペアプログラミングに費やしていました。
GitHub:Enterprise 上でのレビュー
本題に入る前に、少しだけアプレッソでのレビューのスタイルについて説明しておきます。
アプレッソでは、svn を使用していた頃の「コミッター(レビュイー)の横にレビュアーがついてコードをウォークスルーし、レビューが完了したらコミットする」スタイルを経て、現在は、GitHub:Enterprise の Pull Request 上でレビューをするスタイルを取っています。
Pull Request の導入によって、以下のような利点が生まれました。
- 非同期でレビューできる
- レビューの経緯がコメントとして残る
一方で、以下のような課題も生まれました。
- いつレビュー(マージ)してもらえるのか不明瞭になりやすい
- 大きめの Pull Request について、ゼロベースでコードを見ると、仕様(意図)の理解から始めるのでレビュアーの負担が大きい
このような課題は、「適宜声をかける」「Design Doc をつける」「必要なときにはレビュイーを呼んで説明してもらう(一緒にコードを見る)」等の運用でカバーしていました。
ペアプログラミングしているとレビューが楽になる
さて、一方で、スクラムチームではペアプログラミングが始まっています。
厳密に計測はしていませんが、ここ 2 ~ 3 ヶ月は、チーム内で書かれたコードの 8 ~ 9 割程度はペアプログラミングによるコードではないかと思います。
とはいえ、ペアプログラミングはただ自然発生的に始まっただけだったので、従来通り Pull Request 上でのコードレビューは行っていました。
ペアの誰かがレビューする
コードレビューの原則は、「コードを書いた人以外がレビューする」です。
ところが、ペアプログラミングが本格化してきたある時期、チームの中から「ペアの中で Pull Request のレビューもまかなったほうが効率的では?」という意見が出ました。
当然、「しかし、それではレビューにならないのでは?」という意見も出ます。
そこで出た折衷案が、「1 つのストーリー(→ Pull Request)にレビュアーを 2 人つけ、ペアの中でも、書いたコードのドライバーではなかった人が必ず(相互に)レビューする」でした。 *4
ペアの中で Pull Request のレビューをまかなうと効率的
実際にやってみると、とても「効率的」です。
ペアで書いたのだから、よく知っているコードです。とてもスムーズにレビューを進めることができます。
個人的には、「(はじめは)よくわからない、コードの塊をレビューする」とき特有のストレスがなくなっただけでも嬉しいと思います。
しかし……、そもそも、ペアで書いたコードにレビューは必要なのでしょうか?
あるいは逆に、「ペアの中で Pull Request のレビューもまかなう」ことが、「本当にレビューになっている」のでしょうか?
ペアプログラミングしていてもレビューは必要か
本題の「ペアプログラミングしていてもレビューは必要か」にたどり着きました。
いま、2 つの問いが生まれています。
- 「すべてペアで書いたコード」を、あらためてレビューすることが必要か?
- 「ペアの中で相互にレビューする」ことは、Pull Request のレビューとして十分か?
「すべてペアで書いたコード」を、あらためてレビューすることが必要か
ペアプログラミングは「継続的なコードレビュー」とも言われます。
だとしたら、「すべてのコードをペアで」書けば、コードレビューは不要になるのでは?
実際のところ、8 ~ 9 割のコードをペアで書いてみての感覚としては、「やはり必要」です。
ペアは自信を持って速く進む
ペアプログラミングの効果の一つとして、「必要なことに集中(フォーカス)できる」ということがあげられます。
ナビゲータは、大きな問題を塊で考えずに、一つひとつのタスクに集中するようにドライバーに促します。
結果として、テンポよく実装を進めていくことができるのですが、ときには、「イマイチな実装」で「とにかく進んだ」あと、その部分がなんとなくそのままになってしまうことがあります。
もちろん、理想はナビゲータが注意深くコントロールすること、あるいは「レッド→グリーン→リファクタリング」のサイクルを厳密に守ることなのですが、私たちのチームは、「完全」にはなりきれていません。
ペアによって「今必要なこと」に集中し、自信を持ってぐんぐん実装を進められることは、ペアプログラミングの大きなメリットです。
一方で、それをコントロールしきれず、細かい問題の処理が漏れることがあります。
ここで、私たちのチームでは、ペアで書いたコードも改めてレビューすることで、ペアで漏れた部分をレビューでカバーする、というやり方が機能しています。
分断された知識をレビューで拾い集める
また、これは私たちのチーム特有の部分かもしれないのですが、一つのストーリー(→ Pull Request)に対して、複数のペアでローテーションしながら開発を行っています。
コードの知識を偏在させず、「誰でも、どのコードも触れる」状態を目指してのことです。
具体的には、だいたい 1 件の Pull Request に対して 2 ~ 3 名(2 ~ 3 アカウント)のコミットが含まれます。つまり、3 ~ 4 名が関わります。
多いときは、5 名にのぼることもあります。
▲比較的関係者の多い Pull Request の例 *5
ペアは原則として 1 人ずつ交代(1 人が抜け、1 人が残る)するようにしてはいますが、どうしても知識が分断されてしまう部分があります。
たとえば、ストーリーに対して最初にコードを書いた人が「あとでやろう」と思っていたちょっとしたリファクタリングが、入れ替わりの中で忘れられ、コードの重複が最後まで残ってしまったりします。
こういった問題も、マージ前のコードレビューによって回収することができます。
コードの重複は、見ればすぐにわかります。
「ペアで書いたから」と思っていきなりマージしてしまうと重複がそのままマージされてしまいますが、少しだけ時間をかけて Pull Request 全体を見渡すことで、このタイプの「ペアとペアの間に落ちた問題」も拾い集めることができます。
他には、「ボトムアップでテストを書いてはきたが、最終的にカバレッジが足りているかどうか」みたいなことも、最終的なレビューのタイミングで確かめることができます。
ペアプログラミングをしていても、コードレビューを設けると、このように Pull Request の全体像を見渡すいいタイミングになります。
「ペアの中で相互にレビューする」ことは、Pull Request のレビューとして十分か
このように、経験から、コードの大半をペアプログラミングで書いていても、コードレビューは有用だと感じています。
では、逆に、今採用している「ペアの中で Pull Request のレビューもまかなう」方法は、本当にコードレビューとして十分機能しているのでしょうか?
コードへの愛着と批判的なコードレビュー
ペアでコードを書いていると、ドライバーではなくナビゲータであっても、自然とコードに愛着がわきます。
よく「一度書いたコードを捨てるのは難しい」と言われますが、それはペアの片割れであっても同じことです。
コードレビューの際に、「私たちが書いたコード」という意識をまったく持たないことは不可能だと思います。
かつて、「誰かが書いたコード」を「別の誰か」がレビューしていた頃は、かなり、批判的にレビューを行っていました。
まずビルドしての動作確認を行いながら、コーディング規約もきっちりと頭に入れておき、綿密に一行一行を確認し、また動作確認を入念に行い……。
こうして、何十件もの指摘を積み上げることも少なくありませんでした。*6
このように批判的にレビューすることで得られていた綿密さは、失われてしまったのでしょうか?
数値化できていないので、主観的な感覚ですが、失われている部分もある、と思います。
別の言い方をすると、ペアプログラミングを行いながらも、あえてコードに一切関わらなかった人が批判的なレビューを加えることで、よりコードの品質が高まる可能性がある、と思います。
圧倒的なコードの共同所有
ところで、先ほど「私たちが書いたコード」というフレーズが出ました。
ペアをローテーションしながら、コードレビューも複数名が入り混じって行っていると、コードはまさに「私たちが書いたコード」としか言いようのないものになっていきます。
XP のプラクティスの一つに「コードの共同所有」がありますが、この状態は言うなれば「圧倒的なコードの共同所有」と言えます。
ある意味、「時間差のあるモブプログラミング *7」とも言えるかもしれません。
複数の頭脳があわさって、一つの(とても賢い)頭脳となってコードを書いている状態です。
このとき、「そのコードに直接関わらなかった人による批判的なレビュー」をあえて追加投入する必要があるか? と考えてみます。
真に「共同所有 = 一つの頭脳」の状態になっていれば、コードに関わる人が単純に 3~4 名から 4 ~ 5 名に(1 名)増えただけ、ということにもなりえます。もはや、別段、批判的でもありません。
この場合、「どちらでもいい」ということになりそうです。純粋に「今よりも目の数を増やした方がいいか(→ ちょっとだけ賢くした方がいいか)どうか」で考えるわけです。
一方、本当に「一つの頭脳」にはなりきっておらず、「直接関わった人」と「直接関わらなかった人」とで多少なりとも視点の違いが出るようなら、そこには摩擦が生まれます。
この場合、「その摩擦が効果的な摩擦か」が判断基準になりそうです。
それが主にコーディングスタイルの問題に分類されるような摩擦なら、おそらく非同期のコードレビューよりも、ペア作業の中ですり合わせて解決していくほうが、効率的でしょう。
一方、「視点が異なることによって、バグを見つけ出す」ような摩擦なら、「別の人がレビューする」価値はあるといえます。
「ペアプログラミングしている」という事実から「コードレビューが必要か」はわからない
こうして考えてみると、一つだけはっきりとわかることがあります。
それは、「完全な共同所有かどうか」も、「効果的な摩擦が生まれるかどうか」も、「ペアプログラミングしている」という事実だけでは判断できないということです。
どのようなスキルと性格を持ったメンバーが、どのような特性を持ったプロダクトに対して、どのようにペアプログラミングをしているか。
そういったさまざまな要素によって、チームの状態が変わってくるはずです。
これは「どのようなタイプのコードレビュー *8 が最も効果的か」という議論にも似ているのかもしれません。
大量のサンプルを集めれば、おそらく一般的な傾向は見出だせるのだろうと思います。そういったデータが手に入れば、自分の状況と照らし合わせて、大いに参考にできます。
しかし、「ペアプログラミングしていてもレビューは必要か」という問いに一般的で簡潔な結論を出すことは難しそうです。
まとめ : プラクティスの効果には常に意識的でありたい
スクラムチームでのコードレビューの変遷から「ペアプログラミングしていてもレビューは必要か」について考えてきましたが、明確な結論は出ませんでした。
あえて言うなら、正しく「状況による」というのが答になりそうです。
現在私たちのチームでは、チーム固有の状況から、「ペアの中で相互にレビューする」ことが機能しています。
しかし、これも将来変わっていくかもしれません。
よって、この記事の結論は、「プラクティスの効果には常に意識的でありたい」ということになります。
ペアプログラミングしていてもレビューは必要か? と問い続け、可能ならばデータも集めることで、必要な場合には行い、不要な場合には行わず、行う場合のやり方もより効果的にしていくことができるでしょう。
関連エントリ
まだスクラムを始めていなかった 1 年前には、こんなことを考えていました。
こういったスタイルの背景となっているスクラムの実践についてはこちらをご覧ください。
appresso.hatenablog.com appresso.hatenablog.com
*1:プログラマ 6 名、テスター 4 名ほど。最適な人数(7±2 名)をやや超過しています……。
*2:正確にはストーリーとは限らず、Product Backlog Item(PBI)です。ですが、この記事では、通りがよい「ストーリー」という用語を使います。
*3:正確には、もっと色々な理由があります。たとえば、Sprint Backlog にも優先順位があり、上から順に終わらせていくというルールにしています。その場合、たとえば 6 つ同時に着手すると、いくつものストーリーが半端なまま完了できない可能性も出てきますが、上から順に 1 つずつ集中して終わらせていくと、少なくとも半分以上は確実に終わらせられます。実際、はじめの頃は、完了した PBI がたったの 1 件、というスプリントもありましたが、数ヶ月すると、完了できないものがあったとしても、一番優先度の低い 1 件だけ、といった状態になっていました。
*4:ペアプログラミングのスタイルによっては、ドライバーとナビゲータはとても頻繁に交代するので、「ドライバーではなかった人」という表現は正確さを欠くかもしれません。ここで意図しているのは、「(直接)自分が書いたコードを自分だけがレビューしておしまいにする」ことがないようにする、ということです。2 人で交代しながらコードを書くとして、2 人がそれぞれに(やや冗長性を持って)コードをレビューすることで、「ある人が直接書いたコード」を「他の人がレビューする」ことのカバレッジは 100% になる、はずです
*5:participants のうち一人は QA エンジニア
*6:当時は Pull Request そのもののサイズが大きかったこともありますが
*7:https://www.youtube.com/watch?v=dVqUcNKVbYg
*8:ウォークスルー、机上チェック、公式なインスペクション等
kintone Café 関東女子会 Vol.1 開催報告
こんにちは。またしても技術部 對馬です。
1月28日にkintone Café 関東女子会 Vol.1が開催されましたので、そのご報告をさせていただきます。
kintone Caféとは
まずkintone Café についてですが、これは「業務アプリ開発プラットフォームであるkintoneのユーザーコミュニティ」であり、全国各地に支部を設けユーザーが自発的に勉強会を開催しています。
詳細は公式サイトをご覧ください。
関東女子会支部設立
そして今回新たに「関東女子会」という支部を発足しました。
私はこの支部の運営をすることになりました。
立ち上げの詳細はまた機会があったら書こうと思いますが、関東女子会の目的として「女性が活発になれる勉強会」をあげ、ハードルが低く参加者全員が気軽に発言できるようにしています。
女子会の活動はクローバにまとめてありますので、こちらも見てみてください。
またクローバPAGE 利用事例に関東女子会を取り上げていただきました!
記念すべき第1回開催
第1回目ということもあり、内容はkintoneの紹介をメインにしました。
kintone紹介 (サイボウズ 李さん)
kintone活用事例 (アプレッソ 對馬)(It’s me !)
kintone活用事例 (サイボウズ 三宅さん)
kintoneデモ (ジョイゾー 四宮さん)
女子会ではみんなでわいわいしながらkintoneについて話していきたいと思ったので、
当日はお菓子やドリンクを用意しました。
食べながら飲みながらセッションを聞いてくれたらなぁと思っていたのですが、
お話が始まると参加者の皆さんは真剣な表情で前を向いて聞いていました。
もっとゆるい感じでいいのに…と思う反面、
実際どのお話も興味深く真剣に聞きたくなる内容でした。
▲李さんからのわかりやすい製品紹介
▲私も活用事例を紹介しました
弊社ではハンズオンセミナーの委託企業さんとの情報共有に活用していたり、
ハッカソンでの環境管理に活用したりしています。
活用の中でも、アプリの開発のしやすさがkintoneの魅力だと感じたので、そのご紹介をしました。
▲三宅さんからサイボウズ社内での活用事例
▲四宮さんからは質問疑問をその場で解決!な相談コーナー
▲関西女子会運営の池上さんからJAWS Daysのお知らせ
そしてASCIIさんに「今回の開催と立ち上げについて」を取り上げていただきました! こちらも併せてご覧ください。
さいごに
参加者の皆さんに聞いたところ、やはり他の勉強会は「内容が難しそう」というような理由で参加してこなかったという意見がありました。
「男性がいると発言がしにくい」などもあり、そうなると親しみやすい「女子会」という括りも必要なのかなと思います。
また、発表者でも「今日は気楽に発表できます!」と言っていた方もいて、確かに心なしか運営もしやすかったので、参加者にとっても運営にとっても「活発に自分の意見を言える場所」となることが実感しました。
考えなければいけないことは多々ありますが、定期的に開催することをまずは目標に、頑張っていこうと思います。
Vol.2も近々開催予定ですので、みなさん宜しくお願いします!
APIStudy#4 開催報告
皆さんこんにちは。 技術部 對馬です。
APIのベストプラクティスを考える会「APIStudy」の第4回が開催されました。
今回もとても濃い内容となりましたのでご報告します。
前回の第3回開催報告はこちら。
去る1月24日に開催された第4回は、株式会社フロムスクラッチさんのオフィスにお邪魔しました。
また今回も市川さんにグラフィックレコーディングをしていただきました。
どんな仕上がりになるのか!楽しみです。(すっかりファンになりました私です)
第1部
フロムスクラッチさんLT
まずはフロムスクラッチの井戸端さんからAPI連携開発における共通化についてお話がありました。
マーケティングプラットフォームであるB→Dashでは、データ取得のため様々なサービスとAPIで連携をしています。
しかし連携するサービスごとにAPIの仕様が異なり、ひとつひとつ開発をしていたが辛いので、昨年、共通化できる部分はマスタを作成し、サービス固有のところだけを開発できるように取り組んだそうです。
共通化することで、「新しい連携においてもマスタの追加だけで良くなった」「開発しやすくなった」「外部にも頼みやすくなった」とたくさんの嬉しいことがあったとおっしゃっていました。
有志LT
今回は初めて会場企業さん以外の方にもLTをしていただきました!
株式会社KUFU 芹澤さんから「RESTfulなAPIにおけるファイルアップロード」についてです。
SmartHRという労務管理ソフトウェアの開発をされていて、前職含めてWeb API関連のお仕事ばかりで、API漬けの人生を送られている芹澤さん。
そんな中で、ファイルの入力についてのベストプラクティス模索し、今回はその調査結果をご紹介していただきました。
インプットの方法について。
インプットは以下2つが主流パターン
- multipart/formdata
スタンダードな規格なので便利!
- Base64
ファイルのデータをエンコードして文字列型として扱う。
データの保存方式について。
- リソース紐付けパターン
特定アトリビュートに対してファイルデータを直接送る方法。
- 汎用ファイルアップロードパターン
ファイルアップロードのエンドポイントを作ってファイルを送る方法。
それぞれ2つの方法を、APIの性質やファイルの用途で適切に組み合わせることがベストプラクティス!だそうです!!
質問タイム
LT発表者に対して質問をする時間。
質問というより全体のディスカッションタイムみたいになっています。
活発に意見が飛び交っていて、チーム分けの前のこの時点でもう楽しそうです。
第2部
チームに分かれて好きなテーマをもとに話し合います。
今回のテーマは以下3つです。
- APIの有効無効の通知、取り扱い
- パラレルで叩くAPIの設計思想
- エラーコード(発生原因による切り分け)
ディスカッション・発表
皆さん熱く討論をしています。
少人数でのディスカッションなので、じっくり話すことができます。
APIの有効無効の通知、取り扱い
企業にとって通知は面倒なので、だったら作ればいいじゃない!ということで kintoneのWebhookを利用して通知する機能を新たに開発すればいいという提案をされていました。
ディスカッションで新機能を提案しているのは新しいですね…。
ちなみに5月リリースだとか…?技術者はAPI Study参加者だとか…? 楽しみですね。
パラレルで叩くAPIの設計思想
APIによっていろんなものをとってこようとしたときに、何か処理が発生してしまいます。
そして複数APIを誰がハンドリングするのかという問題がありますが、 これは、クライアント側でだときれいではないのでサーバー側で一枚ファサードみたいなもの、APIの前にAPIを作ってそこで全て処理していくと綺麗にいくのではないか、という結果になりました。
しかし、となると「サーバーサイドでなんでもかんでもやることになる問題」も気にしなければならないど、バランスの良い設計について話し合うにはもう少し時間が必要のようです。
ただ、ファサード入れることでアプリからアプリを解析されたときにエンドポイントがバレて攻撃を受けるリスクを少し低減されるようになると良いと、メリットもあることをお話いただきました。
エラーコード(発生原因による切り分け)
エラーコードだけでもなく200番台の話も。
AWS S3で分割アップロードするときは、とりあえず200を返すらしいです。
AWSがそうなら長いものには巻かれましょう!
また、複数返したいのなら207でカプセル化してボディで詳細とかもありではないかという意見も。
そして、ステータスコードにはいろいろなものがあるらしく…、
418 I’m a teapot (ティーポットです)
451 Unavailable For Legal Reasons 法的理由により利用不可能
402 Payment Required お金払ってないからあなたは使えない!
「402はすごい使ってみたかったから使いました!」by松本さん
今後のステータスコード発掘に期待です。
最後に
まずは今回のグラフィックレコーディング!
やはり素敵ですね。
1部と2部、今回はかなり濃厚な内容でしたが、見事まとまっています。
ここは私の感想ですが、 APIStudyは回を重ねるごとに内容の濃さが比例して増しているような気がしています。
それが私はとてもうれしいです。開催報告は大変ですが。
そして!
APIStudy #5 の申込みがすでに始まっています!
そしてもうたくさんの方にお申込みを頂いておりますありがとうございます!!!
じっくりAPIについて語りたい方は、ぜひお越しください。
以下connpassページからどうぞ。
API愛が濃ければ濃いほど喜ばれる、そんな勉強会です。
皆さん、宜しくお願いします。
APIStudy#3 開催報告
こんにちは、アプレッソ技術部對馬です。
またしてもエンジニアブログにお邪魔して、開催報告させていただきますお邪魔します。
毎月順調に開催されているAPIStudyは、12月20日に第3回目を迎えました。
第2回の開催報告はこちらからご覧いただけます。
第3回では弥生会計の弥生さんにオフィスをお借りしました。
今回はなんと、ホワイトボードにグラフィックレコーディングを行いました!
担当は市川さんです! ありがとうございます!
どんな仕上がりになるのでしょうか。 写真を本記事のまとめに掲載しますので、楽しみにしてください!
余談:運営挨拶
毎度、写真を撮ると目が閉じているので「今回は目をしっかり開けて話します」と、はじまる前にフラグを立ててしまったAPIStudy運営である脇野。 フラグ回収おめでとうございます。
第1部:弥生さんLTタイム
まずは弥生さんによるLT「デスクトップ製品とのマスタデータ同期の苦悩」です。
APIエコノミー YAYOI SMART CONNECTについて。
SMART CONNECTでは弥生シリーズに様々なデータを取り込め、弥生だけでは実現できないところをカバーし、会計処理をシンプルにしていくことができます。
また弥生会計にはデスクトップとオンラインがあり、双方のデータ同期が必要です。
その仕組みには何万回もテストを要するが、地道なテストの積み重ねが品質につながるのだとお話しいただきました。
そんな弥生さんの切なる願いがこちらです。
(NOT 弥生会計株式会社 YES 弥生株式会社)
ディスカッションタイム
今回は以下4つのグループが作成されました。
- セキュリティ・例外処理について
- 社内用APIならではの手抜き、問題点
- バージョンアップしたら長く使うAPIのライフサイクルについて
- フェーズごとのテストの考え方
皆さん話したいグループに入り、レッツ発散!
共有タイム
ディスカッションした内容を最後は全体に発散してもらいます。
セキュリティ・例外処理について
メンバーの3名のうち2名がサービス基盤をリプレイス中で、その話などをされていました。
侵入テストの際は『ホワイトハッカー』がよいらしく、実際に利用された方も。
見落とし箇所に気づくことができ、安心ができるようです。
社内用APIならではの手抜き、問題点
プロダクトは逆三角形の系図で表されます。
手抜きと呼ばれる社内用APIには「スピードアップ」、「エンジニアの裁量が上がる」というメリットがある、という結果になっています。
APIのライフサイクルについて
長く使うAPIは正しいの?という問題提起に対して、ディスカッションした結果
「長く使うではなく成長に合わせてAPIもバージョンアップしていくべきじゃないか」とまとめていました。
フェーズごとのテストの考え方
APIどうこうより、弥生さんのテストはどう行われたかについて話し合っていました。
ユニットで品質を担保できるか、そこでどれだけの認識齟齬をなくしていくかをターゲットにしてテストをしていたそうです。
最後に
悩みを話したり、共通の話題を見つけ盛り上がったりと、今回もにぎやかなワークショップとなりました。
そして!グラフィックレコーディングは最終的にこうなりました!
第1部
第2部
これをその場で書いているなんて驚きですよね。
まるで魔法のようです!
このグラフィックレコーディングがわかりやすすぎて、こちらを載せるだけで今回の開催報告は済んだのでは…と震えています。
そして!!!
な、な、なんと既に第4回の開催が決定!
次回はフロムスクラッチさんにお邪魔します!
お申込みお待ちしております。
ではまた来月! 皆様、良いお年を&良いAPI設計を。
DataSpiderがクラウドサービスに! 遂に発表されたクラウド型データインテグレーションサービス「DataSpider Cloud」について開発者が語る
2016年12月8日に発表されたクラウド型データインテグレーションサービス「DataSpider Cloud」。2017年1月22日から提供が開始される本サービスは、豊富なデータ連携機能と高いユーザビリティを誇るデータ連携ツール「DataSpider Servista」が100%クラウドネイティブなiPaaSとして手軽に利用できるもので、今後の大きな活用の広がりが期待できる。
DataSpider Cloudは、DataSpider Servista(以下DataSpider)が持つ多彩なデータ連携機能が利用できるのはもちろん、クラウドサービス向けにチューンナップされたインストールレスNativeクライアント「Studio」を搭載。その軽快な操作性を活かしてデータ連携処理の効率的な開発が可能だ。
また、クラウドサービスとして運用するためのさまざまな運用機能も本サービス向けに開発されており、簡単にさまざまな設定や運用処理を行うことができる。
本サービスの開発を担当したのが、株式会社アプレッソと株式会社テラスカイの共同開発チームだ。DataSpiderの開発ベンダーである株式会社アプレッソ、そして先駆的なクラウド型データ連携サービス「SkyOnDemand」を展開してきたクラウドiPaaSリーダーの株式会社テラスカイ。フロントエンド、バックエンド、クラウド、データ連携など双方が持つ多様な分野の技術を持ち寄り、相互作用することによって本サービスの開発が行われた。
開発者から見たDataSpider Cloudとはどのようなサービスなのか? どのように開発が行われたのか? そして今後のDataSpider Cloudはどのような進化が待っているのか? アプレッソ・テラスカイの共同開発チームの開発者に話を聞いてみた。
取材・文:dstn編集部
(※) 本記事はアプレッソ Advent Calendar 2016 - Qiita 18日目の記事です
DataSpiderの「手触りの良さ」を「進化させる」、その思いで開発をした
まず、遂に発表されたDataSpider Cloudとはどのような製品なのだろうか? アプレッソ開発チームの細見氏はこのように語る。
「 DataSpiderの現在の最新バージョン4.0をベースに、テラスカイ社の「SkyOnDemand」を組み合わせて拡張した汎用的なクラウドサービスです。DataSpiderはExcelファイルやデータベースなどオンプレミスのシステムのデータ連携はもちろん、近年はAmazon Web Services(AWS)やセールスフォース、kintone、Azure、Googleなど様々なクラウドサービスとの連携アダプタ・トリガー機能も多く搭載しました。
その多種多様な連携機能をクラウド・サービスとして手軽に利用できるようにしたのがDataSpider Cloudです」(アプレッソ 細見氏)
▲DataSpiderに搭載された豊富なアダプタ・トリガー群で、ノンコーディングでさまざまなアプリケーションやデータベース、ファイルなど簡単に連携が可能だ
もともとDataSpiderは「On Cloud」への対応として、ブラウザ上で利用できる開発クライアントStudio for Webという機能があった。DataSpider CloudではStudio for Webをベースに、操作性をさらに高めたインストールレスなNativeクライアントのStudioが利用できるようになっている。
「従来のStudio for WebはSilverlightで実装されていました。ただしブラウザ上で動作させるために機能的な制限があり、またSilverlightのサポート終了も近づいているということも考慮して、DataSpider Cloudでは新しいプラットフォームでよりユーザービリティの高いクライアントを提供したいという思いがありました。
HTML5などさまざまな技術を検討した結果、WindowsのWPF(Windows Presentation Foundation)を採用したインストールレスのネイティブ・クライアントとして提供することにしました。」(アプレッソ 清水氏)
▲DataSpider Cloudに搭載されたインストールレスNativeクライアントのStudio(画面は開発中のものです)
さらにクライアントの刷新に加えて、「クラウドプラットフォーム」でより使いやすくするためのさまざまな改善が行われていると、アプレッソ開発チームの細見氏は語る。
「例えばDataSpiderのログはシステムを運用していくための重要な情報ですが、DataSpider Servistaではすべてのログを見るためにはOSのファイルシステムにアクセスする必要がありました。DataSpider Cloudではログを確認するための作業がStudio上ですべて行えます。またダウンロード後すぐにディレクトリやファイルを開くことができるようにし、一連のステップがストレス無く行えるようにしています。
DataSpider Cloudでは、従来のDataSpider Servistaにあった「手触りの良さ」を決して損なうことなく、「進化させる」という意気込みで開発しました」(アプレッソ 細見氏)
DataSpider Cloudの運用のために一から開発されたシンプルでモダンな管理画面。その操作性を体験してほしい
DataSpiderは企業内で使用されることを想定したパッケージ・ソフトウェアであるため、そのままではクラウド・サービスとしてリリースすることは不可能だ。テラスカイ社は先駆的に展開していたiPaaSサービス「SkyOnDemand」で培った技術を活かしつつ、さらにDataSpider Cloud向けに新機能を開発したとのころだ。テラスカイ開発チームの荒木氏は以下のように語る。
「テラスカイの開発チームではSkyOnDemandのクラウド・プラットフォームをベースに、DataSpider Cloud向けにさまざまな拡張や改修を行いました。Amazon EC2の仮想インスタンスの構築を始め、新しいクライアントの配布システムの設計・実装や、ユーザーが個別にパッチを当てる機能の実装などクラウドサービスとしてユーザーが必要になる機能をさまざまに実装しました。
より手軽に利用できるようになったDataSpiderを、ぜひこれまで以上に活用してほしいです」(テラスカイ 荒木氏)
パッケージ・ソフトウェアとクラウドサービスが大きく異なるのが、「バージョンアップ」の際の動作だ。パッケージ・ソフトウェアではユーザーが自身のオペレーションによってバージョンアップ作業を行うのが通例であるが、クラウドサービスでは一般的に自動的にバージョンアップがなされる。
ミッション・クリティカルなシステムの場合、この自動的なバージョンアップが動作に影響を与え、予期しない処理結果となってしまう可能性がある。これに対してもDataSpider Cloudは「プレリリース」という機能で対応しているとテラスカイの中山氏は言う。
「自動的なバージョンアップは、ユーザーが自身でバージョンアップ作業をすることなく最新機能が自動的に適用されるというメリットがある反面、未検証の新機能が適用されてしまうという懸念があります。SkyOnDemandから用意されていた「プレリリース機能」は、バージョンアップ適用後の動作をバージョンアップ前に検証できる機能です。これにより、十分に検証を行った上で新しいバージョンのDataSpider Cloudを適用することができます。」(テラスカイ 中山氏)
またクラウドサービスとして運用するために開発された管理画面は、DataSpider Cloudのためにテラスカイ開発チームが一から開発した新機能とのことだ。
▲連携サーバーやネットワーク・アクセスの管理ができる管理画面。通信量の確認など利用状況の確認も可能だ(画面は開発中のものです)
「DataSpiderをクラウドサービスとして運用するためには、連携サーバーやネットワーク・アクセスをより容易に管理することができるようにする必要がありました。そのために、我々のチームではStudioとは別に、管理画面を一から開発しました。とてもシンプルでモダンな作りを意識した画面設計となっていると思うので、ぜひ操作性を試していただきたいです」(テラスカイ 荒木氏)
データ連携のアプレッソとクラウドのテラスカイ。双方の相乗効果が製品に結実した
「データ連携」のアプレッソと「クラウド」のテラスカイという異なるバックグラウンド技術を持つ2社。この2つの開発チームの共同作業はどのように行われたのであろうか? アプレッソ開発チームの細見氏によると、「ミーティングを定期的に行い方向性を確認して進めていきました。技術情報を素早い共有はSlackで、課題管理をCybozu Liveで行いました」とのことだ。
ではそれぞれの担当はどのようなものだったのか? アプレッソ開発チームの細見氏はこのように言う。
「テラスカイ開発チームにはインフラ全般を担当していただきました。SkyOnDemandなどで培ったクラウドサービスの運用ノウハウは我々には無いものであり、絶大な信頼を持ってお任せしました。実際に、その深い知識には感服しましたね。またシステム・インテグレーターとしての手順を尽くした開発の進行は素晴らしいと感じました。
我々のアプレッソ開発チームは安心してDataSpiderエンジンの改良に全力投球することができました。このような明確な役割分けを行うことができたので、スピーディに開発を行うことができたと思います。」(アプレッソ 細見氏)
このような流れで開発されたDataSpider Cloud。2つのチームが相互に刺激し合い、苦労しながらも良い相互作用が発揮されて開発が進んだようだ。テラスカイの荒木氏はこのように語った。
「苦労もありましたが、学ぶこともとても多い開発でしたね。アプレッソ開発チームのアイディアの創出、それを検証・実現まで素早くやってしまうフットワークの軽さには感心しました。
開発作業の中でデータ連携のアプレッソとクラウドのテラスカイという2つのノウハウを持ち寄り、相乗的な効果を得ることができ、それがDataSpider Cloudという製品に結実していると思います」(テラスカイ 荒木氏)
「使い勝手の良い」クラウドサービスとは? 開発チームが挑んだ難問
DataSpiderとSkyOnDemandというベースとなる製品があったとはいえ、「クラウドサービス」をリリースするというのは当然のことながら容易なことではないはずである。具体的にどのような課題があり、どのように克服していったのかは、開発者としては非常に興味深いところである。
まずはテラスカイの中山氏に聞いてみた。
「DataSpiderエンジンとクラウド基盤という明確な役割分担は非常に効率的ではあったんですが、やはりそこで問題になるのはシステム統合。予め準備をしてきたとはいえ、プロジェクトの終盤に統合を行うことになり、問題解決のスピード感が求められました。
しかし共同開発チームの得意な技術分野からアイディアを出し合い、我々だけでは実現できなかったアプローチでスピーディに解決することが無事できてほっとしました。共同開発の強みが活きたところですね。」(テラスカイ 中山氏)
また、前述したバージョンアップ前の「プレリリース機能」は特に今回の開発をするあたってはハイライトとなったようだ。
「SkyOnDemandでも同様の機能は用意していたのですが、DataSpider Cloudでは基盤の再設計から行ったためその仕組みがそのままでは適用できず、対応方法に悩みました。しかし我々はこのような機能はクラウドサービスに一般的なものであり、ユーザーに信頼していただくクラウド・サービスの使い勝手としては必須だと考えています。苦労はしましたが、DataSpider Cloud上で問題なく機能を利用できるように無事対応できました。」(テラスカイ 荒木氏)
アプレッソ側では、DataSpider Cloud向けにプラットフォームを刷新したStudioの実装がやはり最大の焦点となった模様だ。特に「SilverlightとWPFの違いを1つ1つ対応していくのが大変でした」とアプレッソの清水氏は言う。
「同じC#のコードではあるんですが、大きなところから小さなところまでさまざまな挙動や見た目の違いがありました。例えばリンクボタンやフォームなどのコントロール・コンポーネントを自作し直したり、画像がなぜか大きくなったり・・・。ドキュメントに無い動作もあったりして、嵌ってしまうことも多くありましたね。1つ1つ検証しながら潰していきました。大変な作業ではありましたが、その結果より使いやすく、これからも長く使えるクライアントに仕上がったと思います。」(アプレッソ 清水氏)
また、データ連携処理の開発効率に直結するクライアントだけに、「使い勝手」に大きなこだわりをもって開発を行っていたようだ。
「従来のStudio for Webに比べ、大きくユーザビリティは向上していると思います。まずサクサクと動く軽快な動作感を感じていただけると思います。またさまざまなキーボード・ショートカットが使えるようになり、Ctr+Sで保存、F1キーでヘルプ画面表示など、スピーディな一連の操作が可能です。その他にもさまざまな工夫がしているので、ぜひその使い勝手を体験していただきたいですね。」 (アプレッソ 細見氏)
双方の開発者の言葉に「使い勝手」というキーワードが共通していることが見てとれる。いかにユーザーに「良い使い勝手」という価値を届けるか。アプレッソとテラスカイの開発者はその難問に挑み、試行錯誤の結果辿り着いた解が、DataSpider Cloudにあるようだ。
DataSpider Cloudの未来、「クラウドサービスのあるべき姿」への進化へ向けて
いよいよ提供日の2017年1月22日が近づいてきたDataSpider Cloud。現在の心境について聞いてみると、テラスカイの荒木氏は「大きな達成感がありますね」と笑顔で語る。
「もともとSkyOnDemandはDataSpiderのOEMだったんですが、その機能がDataSpiderの一部になるということは私にとってとても感慨深いです。テラスカイは創業時より「クラウド専業」を掲げて事業を展開してきたんですが、それが正しかったことが裏付けられるようで、とても嬉しいです。」(テラスカイ荒木氏)
その一方で、今回のリリースでは対応できなかった機能に関してアイディアが溢れているようだ。テラスカイの中山氏はこう語ってくれた。
「現在はご利用申し込みから実際のご利用までに少しお時間をいただいてしまうことがあります。これをもっと自動的に素早く提供できるようにしたいです。また、SkyOnDemandでは出来なかった機動的なアップデートや、独自アダプタの提供などやりたいことは沢山あります。 クラウドサービスのあるべき姿に進化させたいですね。」(テラスカイ 中山氏)
アプレッソ細見氏も、Studioがブラウザの制約から開放されたスタンドアロンのクライアントになったことで、「一定のユーザビリティ向上は果たせた」としながらも、さらなる「手触りの良さ」の向上について意欲を燃やす。
「まずは"できなかったことをできるようにする"ということを優先して今回のプロジェクトは開発を行いました。まだまだ自分としては、「クラウドサービス」だから提供できる価値へむけて進化すべきところが多くあると思っています。また、Undo/Redoなどクライアント・アプリケーションとして必要な機能の搭載がまだ不完全であり、そのような「手触りの良さ」を継続して取り組んでいきたいと考えています。
ロードマップではv1.1では多言語対応・Thunderbus(オンプレミス連携)対応、さらにv2.0も計画されています。今後も足を止めることなく加速して、DataSpider Cloudを立派なサービスに育てていきたいという思いがあります。」(アプレッソ細見氏)
▲DataSpider Cloudのロードマップ。v1.1、そしてv2.0に向けてさまざまな新機能が計画されている
DataSpiderをこれまで活用してきた人にも、これから使用してみたい人にもDataSpider Cloudのメリットは大きい
DataSpider Cloudは、2017年1月22日にリリースされ、提供が開始される。開発者にユーザーに使っていただくリリース日は、不安とともに大きな楽しみであるはずである。どのようなユーザーに使っていただきたいかについて聞いてみた。
「データ連携ツールの導入をご検討されていて、自社でサーバー管理をすることが難しい方には、クラウドサービスの利点を活かしてぜひDataSpider Cloudをご使用いただければと思っています。DataSpider Cloudなら導入の手間なくどのような製品かを体験することも出来ます。
また既にDataSpiderを導入されている方でも、バージョンアップ作業が自動的に出来たり、コンピューティングリソースの拡張により規模に応じた利用プランでご利用ができたりと、大きなメリットがあると思います。」(テラスカイ 荒木氏)
「DataSpiderというデータ連携基盤がクラウドサービスになったことにより、すべてクラウド上でデータ連携処理を完結させることが可能になりました。特にデータがクラウド上にある場合は、オンプレミスにデータ連携基盤を置くことなく100%クラウドで管理できるということは大きなメリットだと思います。ぜひこれまでDataSpiderを活用してきたユーザーにもそのインパクトを体験してだきたいですね。
また、これから購入を検討していただいている方にも、DataSpiderの使い心地をすぐに体感していただくことができるので、ぜひオススメしたいです」(アプレッソ 細見氏)
▲DataSpider Cloudが提供する価値として、「Fully-managed」・「Ease of use」・「Elastic」が挙げられている
DataSpider Cloudというこの新しいクラウド型インテグレーションサービスは、「データインテグレーションにアジリティを」というキャッチコピーの通り、「アジリティ=敏捷性」が1つのテーマになっている。これまでDataSpiderを活用してデータ連携をしていた方にも、これから使用しようという方にも、その「アジリティ」は絶大な効果をもたらすようだ。
いよいよ2017年1月22日に世に解き放たれるDataSpider Cloud。ぜひその「アジリティ」を体感してみてほしい。
(※) 本記事はアプレッソ Advent Calendar 2016 - Qiita 18日目の記事です