読者です 読者をやめる 読者になる 読者になる

Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

kintone Café 関東女子会 Vol.1 開催報告

こんにちは。またしても技術部 對馬です。

1月28日にkintone Café 関東女子会 Vol.1が開催されましたので、そのご報告をさせていただきます。

kintone Caféとは

まずkintone Café についてですが、これは「業務アプリ開発プラットフォームであるkintoneのユーザーコミュニティ」であり、全国各地に支部を設けユーザーが自発的に勉強会を開催しています。

詳細は公式サイトをご覧ください。

kintonecafe.com

関東女子会支部設立

そして今回新たに「関東女子会」という支部を発足しました。

私はこの支部の運営をすることになりました。

立ち上げの詳細はまた機会があったら書こうと思いますが、関東女子会の目的として「女性が活発になれる勉強会」をあげ、ハードルが低く参加者全員が気軽に発言できるようにしています。

女子会の活動はクローバにまとめてありますので、こちらも見てみてください。

kintonecafegirls.qloba.com

またクローバPAGE 利用事例に関東女子会を取り上げていただきました!

company.qloba.com

記念すべき第1回開催

f:id:ytsushima:20170207153742j:plain 第1回目ということもあり、内容はkintoneの紹介をメインにしました。

  • kintone紹介 (サイボウズ 李さん)

  • kintone活用事例 (アプレッソ 對馬)(It’s me !)

  • kintone活用事例 (サイボウズ 三宅さん)

  • kintoneデモ (ジョイゾー 四宮さん)

女子会ではみんなでわいわいしながらkintoneについて話していきたいと思ったので、

当日はお菓子やドリンクを用意しました。

f:id:ytsushima:20170207150438j:plain

食べながら飲みながらセッションを聞いてくれたらなぁと思っていたのですが、

お話が始まると参加者の皆さんは真剣な表情で前を向いて聞いていました。

f:id:ytsushima:20170207154259j:plain

もっとゆるい感じでいいのに…と思う反面、

実際どのお話も興味深く真剣に聞きたくなる内容でした。


f:id:ytsushima:20170207151416j:plain ▲李さんからのわかりやすい製品紹介

f:id:ytsushima:20170207151934j:plain ▲私も活用事例を紹介しました

弊社ではハンズオンセミナーの委託企業さんとの情報共有に活用していたり、

ハッカソンでの環境管理に活用したりしています。

活用の中でも、アプリの開発のしやすさがkintoneの魅力だと感じたので、そのご紹介をしました。


f:id:ytsushima:20170207152051j:plain ▲三宅さんからサイボウズ社内での活用事例

f:id:ytsushima:20170207152202j:plain ▲四宮さんからは質問疑問をその場で解決!な相談コーナー

f:id:ytsushima:20170207152507j:plain ▲関西女子会運営の池上さんからJAWS Daysのお知らせ

そしてASCIIさんに「今回の開催と立ち上げについて」を取り上げていただきました! こちらも併せてご覧ください。

ascii.jp

さいごに

f:id:ytsushima:20170207153119j:plain

参加者の皆さんに聞いたところ、やはり他の勉強会は「内容が難しそう」というような理由で参加してこなかったという意見がありました。

「男性がいると発言がしにくい」などもあり、そうなると親しみやすい「女子会」という括りも必要なのかなと思います。

また、発表者でも「今日は気楽に発表できます!」と言っていた方もいて、確かに心なしか運営もしやすかったので、参加者にとっても運営にとっても「活発に自分の意見を言える場所」となることが実感しました。

考えなければいけないことは多々ありますが、定期的に開催することをまずは目標に、頑張っていこうと思います。

Vol.2も近々開催予定ですので、みなさん宜しくお願いします!

APIStudy#4 開催報告

皆さんこんにちは。 技術部 對馬です。

APIのベストプラクティスを考える会「APIStudy」の第4回が開催されました。

今回もとても濃い内容となりましたのでご報告します。

前回の第3回開催報告はこちら。

appresso.hatenablog.com

去る1月24日に開催された第4回は、株式会社フロムスクラッチさんのオフィスにお邪魔しました。 f:id:ytsushima:20170203172810j:plain

また今回も市川さんにグラフィックレコーディングをしていただきました。

どんな仕上がりになるのか!楽しみです。(すっかりファンになりました私です) f:id:ytsushima:20170203172740j:plain

第1部

フロムスクラッチさんLT

まずはフロムスクラッチの井戸端さんからAPI連携開発における共通化についてお話がありました。 f:id:ytsushima:20170203172837j:plain

マーケティングプラットフォームであるB→Dashでは、データ取得のため様々なサービスとAPIで連携をしています。

しかし連携するサービスごとにAPIの仕様が異なり、ひとつひとつ開発をしていたが辛いので、昨年、共通化できる部分はマスタを作成し、サービス固有のところだけを開発できるように取り組んだそうです。

f:id:ytsushima:20170203173147j:plain

共通化することで、「新しい連携においてもマスタの追加だけで良くなった」「開発しやすくなった」「外部にも頼みやすくなった」とたくさんの嬉しいことがあったとおっしゃっていました。

有志LT

今回は初めて会場企業さん以外の方にもLTをしていただきました!

株式会社KUFU 芹澤さんから「RESTfulなAPIにおけるファイルアップロード」についてです。

f:id:ytsushima:20170203173259j:plain

SmartHRという労務管理ソフトウェアの開発をされていて、前職含めてWeb API関連のお仕事ばかりで、API漬けの人生を送られている芹澤さん。

そんな中で、ファイルの入力についてのベストプラクティス模索し、今回はその調査結果をご紹介していただきました。

インプットの方法について。

インプットは以下2つが主流パターン

  • multipart/formdata

  スタンダードな規格なので便利!

  • Base64

  ファイルのデータをエンコードして文字列型として扱う。

データの保存方式について。

  • リソース紐付けパターン

  特定アトリビュートに対してファイルデータを直接送る方法。

  • 汎用ファイルアップロードパターン

  ファイルアップロードのエンドポイントを作ってファイルを送る方法。

f:id:ytsushima:20170203173427j:plain

それぞれ2つの方法を、APIの性質やファイルの用途で適切に組み合わせることがベストプラクティス!だそうです!!

質問タイム

LT発表者に対して質問をする時間。

質問というより全体のディスカッションタイムみたいになっています。

f:id:ytsushima:20170203173517j:plain 活発に意見が飛び交っていて、チーム分けの前のこの時点でもう楽しそうです。

第2部

チームに分かれて好きなテーマをもとに話し合います。

今回のテーマは以下3つです。

  • APIの有効無効の通知、取り扱い
  • パラレルで叩くAPIの設計思想
  • エラーコード(発生原因による切り分け)

ディスカッション・発表

f:id:ytsushima:20170203173811j:plain

皆さん熱く討論をしています。

少人数でのディスカッションなので、じっくり話すことができます。

f:id:ytsushima:20170203173629j:plain

APIの有効無効の通知、取り扱い

f:id:ytsushima:20170203173843j:plain 企業にとって通知は面倒なので、だったら作ればいいじゃない!ということで kintoneのWebhookを利用して通知する機能を新たに開発すればいいという提案をされていました。

ディスカッションで新機能を提案しているのは新しいですね…。

ちなみに5月リリースだとか…?技術者はAPI Study参加者だとか…? 楽しみですね。

パラレルで叩くAPIの設計思想

f:id:ytsushima:20170203173919j:plain

APIによっていろんなものをとってこようとしたときに、何か処理が発生してしまいます。

そして複数APIを誰がハンドリングするのかという問題がありますが、 これは、クライアント側でだときれいではないのでサーバー側で一枚ファサードみたいなもの、APIの前にAPIを作ってそこで全て処理していくと綺麗にいくのではないか、という結果になりました。

しかし、となると「サーバーサイドでなんでもかんでもやることになる問題」も気にしなければならないど、バランスの良い設計について話し合うにはもう少し時間が必要のようです。

ただ、ファサード入れることでアプリからアプリを解析されたときにエンドポイントがバレて攻撃を受けるリスクを少し低減されるようになると良いと、メリットもあることをお話いただきました。

エラーコード(発生原因による切り分け)

f:id:ytsushima:20170203174240j:plain エラーコードだけでもなく200番台の話も。

AWS S3で分割アップロードするときは、とりあえず200を返すらしいです。

AWSがそうなら長いものには巻かれましょう!

また、複数返したいのなら207でカプセル化してボディで詳細とかもありではないかという意見も。

そして、ステータスコードにはいろいろなものがあるらしく…、

418  I’m a teapot (ティーポットです)

451  Unavailable For Legal Reasons 法的理由により利用不可能

402  Payment Required お金払ってないからあなたは使えない!

「402はすごい使ってみたかったから使いました!」by松本さん

今後のステータスコード発掘に期待です。

最後に

まずは今回のグラフィックレコーディング!

f:id:ytsushima:20170203174419j:plain やはり素敵ですね。

1部と2部、今回はかなり濃厚な内容でしたが、見事まとまっています。

ここは私の感想ですが、 APIStudyは回を重ねるごとに内容の濃さが比例して増しているような気がしています。

それが私はとてもうれしいです。開催報告は大変ですが。

そして!

APIStudy #5 の申込みがすでに始まっています!

そしてもうたくさんの方にお申込みを頂いておりますありがとうございます!!!

じっくりAPIについて語りたい方は、ぜひお越しください。

以下connpassページからどうぞ。

apistudy.connpass.com

API愛が濃ければ濃いほど喜ばれる、そんな勉強会です。

皆さん、宜しくお願いします。

APIStudy#3 開催報告

こんにちは、アプレッソ技術部對馬です。

またしてもエンジニアブログにお邪魔して、開催報告させていただきますお邪魔します。

毎月順調に開催されているAPIStudyは、12月20日に第3回目を迎えました。

第2回の開催報告はこちらからご覧いただけます。

appresso.hatenablog.com

第3回では弥生会計の弥生さんにオフィスをお借りしました。 f:id:ytsushima:20161222171253j:plain

今回はなんと、ホワイトボードにグラフィックレコーディングを行いました!

担当は市川さんです! ありがとうございます! f:id:ytsushima:20161222171334j:plain

どんな仕上がりになるのでしょうか。 写真を本記事のまとめに掲載しますので、楽しみにしてください!

余談:運営挨拶

毎度、写真を撮ると目が閉じているので「今回は目をしっかり開けて話します」と、はじまる前にフラグを立ててしまったAPIStudy運営である脇野。 f:id:ytsushima:20161222174357j:plain フラグ回収おめでとうございます。

第1部:弥生さんLTタイム

まずは弥生さんによるLT「デスクトップ製品とのマスタデータ同期の苦悩」です。

f:id:ytsushima:20161222173427j:plain

APIエコノミー YAYOI SMART CONNECTについて。

SMART CONNECTでは弥生シリーズに様々なデータを取り込め、弥生だけでは実現できないところをカバーし、会計処理をシンプルにしていくことができます。

f:id:ytsushima:20161222173455j:plain

また弥生会計にはデスクトップとオンラインがあり、双方のデータ同期が必要です。

その仕組みには何万回もテストを要するが、地道なテストの積み重ねが品質につながるのだとお話しいただきました。


そんな弥生さんの切なる願いがこちらです。 f:id:ytsushima:20161222173532j:plain(NOT 弥生会計株式会社 YES 弥生株式会社)

ディスカッションタイム

今回は以下4つのグループが作成されました。

  • セキュリティ・例外処理について
  • 社内用APIならではの手抜き、問題点
  • バージョンアップしたら長く使うAPIのライフサイクルについて
  • フェーズごとのテストの考え方

f:id:ytsushima:20161222174549j:plain

皆さん話したいグループに入り、レッツ発散!

共有タイム

ディスカッションした内容を最後は全体に発散してもらいます。

セキュリティ・例外処理について

f:id:ytsushima:20161222174716j:plain

メンバーの3名のうち2名がサービス基盤をリプレイス中で、その話などをされていました。

侵入テストの際は『ホワイトハッカー』がよいらしく、実際に利用された方も。

見落とし箇所に気づくことができ、安心ができるようです。

社内用APIならではの手抜き、問題点

f:id:ytsushima:20161222175241j:plain

プロダクトは逆三角形の系図で表されます。

f:id:ytsushima:20161222175051j:plain

手抜きと呼ばれる社内用APIには「スピードアップ」、「エンジニアの裁量が上がる」というメリットがある、という結果になっています。

APIのライフサイクルについて

f:id:ytsushima:20161222175312j:plain

長く使うAPIは正しいの?という問題提起に対して、ディスカッションした結果

「長く使うではなく成長に合わせてAPIもバージョンアップしていくべきじゃないか」とまとめていました。

フェーズごとのテストの考え方

f:id:ytsushima:20161222175349j:plain

APIどうこうより、弥生さんのテストはどう行われたかについて話し合っていました。

ユニットで品質を担保できるか、そこでどれだけの認識齟齬をなくしていくかをターゲットにしてテストをしていたそうです。

最後に

f:id:ytsushima:20161222175800j:plain

悩みを話したり、共通の話題を見つけ盛り上がったりと、今回もにぎやかなワークショップとなりました。

そして!グラフィックレコーディングは最終的にこうなりました!

第1部 f:id:ytsushima:20161222175437j:plain

第2部 f:id:ytsushima:20161222175517j:plain

これをその場で書いているなんて驚きですよね。

まるで魔法のようです!

このグラフィックレコーディングがわかりやすすぎて、こちらを載せるだけで今回の開催報告は済んだのでは…と震えています。

そして!!!

な、な、なんと既に第4回の開催が決定!

次回はフロムスクラッチさんにお邪魔します!

apistudy.connpass.com

お申込みお待ちしております。

ではまた来月! 皆様、良いお年を&良いAPI設計を。

DataSpiderがクラウドサービスに! 遂に発表されたクラウド型データインテグレーションサービス「DataSpider Cloud」について開発者が語る

DataSpider

f:id:tokita93:20161215165617p:plain

2016年12月8日に発表されたクラウド型データインテグレーションサービス「DataSpider Cloud」。2017年1月22日から提供が開始される本サービスは、豊富なデータ連携機能と高いユーザビリティを誇るデータ連携ツール「DataSpider Servista」が100%クラウドネイティブなiPaaSとして手軽に利用できるもので、今後の大きな活用の広がりが期待できる。

DataSpider Cloudは、DataSpider Servista(以下DataSpider)が持つ多彩なデータ連携機能が利用できるのはもちろん、クラウドサービス向けにチューンナップされたインストールレスNativeクライアント「Studio」を搭載。その軽快な操作性を活かしてデータ連携処理の効率的な開発が可能だ。

また、クラウドサービスとして運用するためのさまざまな運用機能も本サービス向けに開発されており、簡単にさまざまな設定や運用処理を行うことができる。

本サービスの開発を担当したのが、株式会社アプレッソと株式会社テラスカイの共同開発チームだ。DataSpiderの開発ベンダーである株式会社アプレッソ、そして先駆的なクラウド型データ連携サービス「SkyOnDemand」を展開してきたクラウドiPaaSリーダーの株式会社テラスカイ。フロントエンド、バックエンド、クラウド、データ連携など双方が持つ多様な分野の技術を持ち寄り、相互作用することによって本サービスの開発が行われた。

f:id:tokita93:20161215164750p:plain

開発者から見た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です」(アプレッソ 細見氏)

f:id:tokita93:20161216113854p:plain ▲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)を採用したインストールレスのネイティブ・クライアントとして提供することにしました。」(アプレッソ 清水氏)

f:id:tokita93:20161215173459p:plain ▲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のためにテラスカイ開発チームが一から開発した新機能とのことだ。

f:id:tokita93:20161216113052p:plain ▲連携サーバーやネットワーク・アクセスの管理ができる管理画面。通信量の確認など利用状況の確認も可能だ(画面は開発中のものです)

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を立派なサービスに育てていきたいという思いがあります。」(アプレッソ細見氏)

f:id:tokita93:20161216152252p:plain ▲DataSpider Cloudのロードマップ。v1.1、そしてv2.0に向けてさまざまな新機能が計画されている

DataSpiderをこれまで活用してきた人にも、これから使用してみたい人にもDataSpider Cloudのメリットは大きい

DataSpider Cloudは、2017年1月22日にリリースされ、提供が開始される。開発者にユーザーに使っていただくリリース日は、不安とともに大きな楽しみであるはずである。どのようなユーザーに使っていただきたいかについて聞いてみた。

データ連携ツールの導入をご検討されていて、自社でサーバー管理をすることが難しい方には、クラウドサービスの利点を活かしてぜひDataSpider Cloudをご使用いただければと思っています。DataSpider Cloudなら導入の手間なくどのような製品かを体験することも出来ます。

また既にDataSpiderを導入されている方でも、バージョンアップ作業が自動的に出来たり、コンピューティングリソースの拡張により規模に応じた利用プランでご利用ができたりと、大きなメリットがあると思います。」(テラスカイ 荒木氏)

DataSpiderというデータ連携基盤がクラウドサービスになったことにより、すべてクラウド上でデータ連携処理を完結させることが可能になりました。特にデータがクラウド上にある場合は、オンプレミスにデータ連携基盤を置くことなく100%クラウドで管理できるということは大きなメリットだと思います。ぜひこれまでDataSpiderを活用してきたユーザーにもそのインパクトを体験してだきたいですね。

また、これから購入を検討していただいている方にも、DataSpiderの使い心地をすぐに体感していただくことができるので、ぜひオススメしたいです」(アプレッソ 細見氏)

f:id:tokita93:20161216152510p:plain ▲DataSpider Cloudが提供する価値として、「Fully-managed」・「Ease of use」・「Elastic」が挙げられている

DataSpider Cloudというこの新しいクラウド型インテグレーションサービスは、「データインテグレーションにアジリティを」というキャッチコピーの通り、「アジリティ=敏捷性」が1つのテーマになっている。これまでDataSpiderを活用してデータ連携をしていた方にも、これから使用しようという方にも、その「アジリティ」は絶大な効果をもたらすようだ。

いよいよ2017年1月22日に世に解き放たれるDataSpider Cloud。ぜひその「アジリティ」を体感してみてほしい。

(※) 本記事はアプレッソ Advent Calendar 2016 - Qiita 18日目の記事です

CSPO 研修を受けてわたしたちのスクラムについて思うこと

開発

アプレッソ開発部の佐々木です。

開発部のマネージャーをやりながら、アプレッソの主力プロダクトである DataSpider Servista のプロダクトオーナーを担当しています。

本記事は、Appresso Advent Calendar の 15 日目の記事です。

qiita.com

先月、Odd-e Japan の認定スクラムプロダクトオーナー研修を受講してきました。

研修は 3 日間で行われ、スクラムの概要やスクラムにおけるプロダクトオーナーの役割、然るべき振る舞いなどを学んできました。この研修の中で、DataSpider Servista の開発チームが実践しているスクラムに対して多くの気づきがあり、この記事ではその気づきを紹介していきたいと思います。

アプレッソが現在実践しているスクラムについては、Appresso Advent Calendar の 2 日目3 日目で詳しく紹介されていますので、そちらを読んでいただければと思います。

目次

スクラムにおけるプロダクトオーナーの役割

スクラムにおけるプロダクトオーナーは、プロダクトのビジョンを明確にし、チームの ROI を最大化させることに責任を持つ役割になります。

プロダクトのビジョンは、市場に対してプロダクトが目指す方向性のことで、その方向性をチームに示すためにプロダクトオーナーは首尾一貫した決断力と確かな情報収集力が必要だと思います。

チームの ROI はプロダクトのビジョンに従ってチームが具現化した価値とそれにかけたコストの割合のことで、その割合を最大化することがプロダクトオーナーの責任です。

プロダクトバックログ

プロダクトバックログとは、プロダクトの要件を一覧で見える化したものです。 プロダクトバックログはプロダクトオーナーとチームの持ち物ですが、プロダクトバックログアイテムを書いてそれぞれのアイテムに優先順位を付けるのはプロダクトオーナーの仕事です。

INVESTなプロダクトバックログアイテム

プロダクトバックログアイテムを書く上で意識していることが「INVEST」です。INVESTとは、良いとされるプロダクトバックログアイテムの特徴を表した以下の単語の頭文字です。

  • Independent (依存しない)
  • Negotiable (交渉可能)
  • Valuable (価値がある)
  • Estimatable (見積り可能)
  • Sized Right/Small (手頃なサイズ / 十分小さいサイズ)
  • Testable (テスト可能)

Independent

プロダクトバックログアイテムそれぞれが単独で成立している、つまり他のプロダクトバックログアイテムとの依存関係が排除されているということです。プロダクトバックログアイテムに依存関係があるとチームの見積りが難しくなるだけでなく、作業効率にも悪影響を及ぼします。

Negotiable

プロダクトバックログアイテムの内容に対してチームが交渉可能なことで、プロダクトオーナーが決めたことが絶対ではないということです。交渉の余地がないとチームにとって自由で柔軟な発想がしづらくなるでしょう。

Valuable

プロダクトがターゲットにしている市場に対して受け入れられること、つまりビジネス価値があるということです。プロダクトオーナーの妄想でビジネス価値の無いプロダクトバックログアイテムを作ることは、チームの成果を台無しにしてしまう裏切り行為と言えるでしょう。

Estimatable

プロダクトバックログアイテムの内容が見積り可能ということです。見積りが難しい内容になっていると、スプリントプランニングの際、チームがタスクを見積ることが困難になり、それだけ見積り作業に時間が取られることになります。見積りしやすいプロダクトバックログアイテムを作ることは、チームのコスト削減の観点からも重要です。

Sized Right/Small

プロダクトバックログアイテムがチームにとって手頃なサイズ (十分小さいサイズ) になっているということです。プロダクトバックログアイテムのサイズが大きいと、見積りが難しくなるだけではなく、不確実性やリスクが多く含まれている可能性がある状態になります。この状態だとチームはスプリントプランニングに多大な労力をかけることになり、ベロシティを上げることが困難になります。

Testable

テストが可能になっているということです。テストが可能になっているということは、チームにとって自分達の作業範囲や完了基準を明確にできるという点で重要です。

Independent と Sized Right/Small の関係性

ここで、Independent を重視して依存関係を排除した結果、Sized Right/Small が十分でなくなるケースが考えられます。このような場合は、小さく分割したプロダクトバックログを後からまとめることは簡単だけど分割するのは手間がかかるので、Sized Right/Small を重視してサイズは小さくしておくことが望ましいと考えます。

プロダクトバックログアイテムを書くスピードは 1 つにつき 1 分

上記の特徴を意識してプロダクトバックログアイテムを書く場合、現状の私だと数分から長いときだと数時間程度かかることがあります。 ただし、認定スクラムプロダクトオーナー研修の中で講師の江端さんが言っていたのが

プロダクトバックログアイテムを書くスピードは 1 つにつき 1 分

ということでした。

これを聞いたときは、できるイメージがまったく浮かばず呆然としてしまいましたが、現状プロダクトバックログアイテムを書く時間がかかっている理由を考えてみると、プロダクトバックログアイテムを書く際に既存機能の動作を確認したり、アイテムのサイズが想定よりも大きくなって分割したり、曖昧な表現を修正したりと、実に試行錯誤しながらやっていました。

情報収集の大事さ

そのような状況になる大きな要因として、「情報収集が足りない」ことが考えられます。

持っている情報が足りない状態で書こうとすると時間がかかるわけで、十分に情報を持ったうえでプロダクトのビジョンが明確に整理されていれば、それを文字に起こすのはそう時間はかからないはずです。

他にも

情報収集が足りないことがチームに対して良くない影響を与えるケースも考えられます。

それは、チームからプロダクトオーナーへの質問に対しての回答が遅くなるということです。スプリントの中で、プロダクトオーナーはチームから質問を受けることが良くあります。その際、プロダクトオーナーが持っている情報が不十分だと、誤った回答をしてしまう、その場で回答を探るような議論が展開されてしまう、プロダクトオーナーが持ち帰って回答までに時間を要してチームの作業が止まってしまう、というようなことが考えられます。

プロダクトオーナーはチームに対して満足のいく回答ができるよう十分な情報収集を行い、質問に対する回答までの時間を短くすることを意識する必要があります。さらにそこから発展させて、チームからの質問回数を減らしてチームが開発作業に集中できるようにすることも重要だと考えます。

プロダクトバックログはプロダクトオーナーの腕の見せどころ

プロダクトオーナーにとってプロダクトバックログとは腕の見せどころで、とにかく数多くプロダクトバックログアイテムを書くことで良くなっていくと講師の江端さんも言ってました。

チームにとって作業しやすい手頃なサイズであること、誰が読んでも同じように理解できる受け入れ条件になっていること、優先順位がつけられていること、これらの条件が揃った一貫性のあるプロダクトバックログを作ることによって、チームの ROI 最大化に貢献できると考えます。

プロダクトオーナーは誰よりも多くプロダクトを触る

プロダクトオーナーは誰よりもプロダクトを使い倒して、その良し悪しを把握している必要があると思います。

しかしながら、10年以上今のプロダクト開発に携わってきて現状プロダクトオーナーの立場である私は全てを把握できていません。その理由は、「プロダクトを触れていない」ことが大きいと思います。

スプリントの中で積極的にプロダクトを触る

スプリントを開始した当初は、プロダクトオーナーである私はプロダクトを触らずにプロダクトバックログアイテムに定義された受け入れ条件を確認していました。

プロダクトを動かさずにどうやって確認できるのか?
それは、スプリントレビューの場でチームによるデモで確認していました。

しかし、スプリントレビューは、スプリントの成果をチームが発表し、プロダクトを改善するためのフィードバックを得る場です。チームの成果が受け入れ条件を満たしているかどうかは、スプリントの中でチームが作業を完了したタイミングでやるべきです。そのタイミングでやることでチームは成果に対して素早いフィードバックを得ることができます。

スプリントレビューでチームにデモをやらせるのはプロダクトオーナーの怠慢で、スプリントレビューで本来やるべきことを阻害していることに気づきました。

プロダクトオーナーはスプリントの中でも積極的にプロダクトに触ることが重要で、その土台となるのは積極的にチームに関わっていくマインドを持つことだと思います。

「完了」の定義 (Done と Undone)

スクラムでは、作業の完了についてスクラムチーム全体で共通理解を持ち、透明性を確保するためにプロダクトのリリースまでに必要なすべての作業を一覧にして見える化します。これを「完了の定義」と言います。完了の定義は、チームが毎スプリント必ず担保する作業を「Done」、担保できない作業を「Undone」としてグループ分けします。

アプレッソのスクラムで Done に分類されているものは、例えば「コーディング規約に則っていることの確認」や「ユニットテストの作成および実施」があります。

一方、Undone に分類されているものは、「ヘルプドキュメントの作成」や「リリースノートの作成」があります。

Undone はプロジェクトが進むにつれて増えていく

Undone はいわば負債のようなもので、Undone を回収しないままプロジェクトを進めていくと Undone が増えていくことになります。

例えば、あるスプリントの中で一つの機能が実装されたとします。その機能のヘルプドキュメントを書くことはプロダクトをリリースする上では必要な作業ですが、Undone なのでスプリントの中では行いません。このような機能が毎スプリント実装されるとスプリントを重ねるごとにヘルプドキュメントの Undone が増えていくことになります。

スプリントが終わるまで Undone が回収されずに増えていくということは、つまりプロダクトのリリースに対してリスクが高まっていくことになります。

Undone は細かく回収する

Undone を増やさないためにプロダクトオーナーが打つ施策としては毎スプリントで「Undone は細かく回収する」ことになります。これは認定スクラムプロダクトオーナー研修で「呪文のように覚えろ」と言われた言葉で、今では私の耳から離れないフレーズになってます。

毎スプリント Undone を細かく回収するには Undone 自体がプロダクトバックログで管理されて、チームが見積り可能な状態になっている必要があります。Undone が残っていて、それをスプリントでどのように回収するかの責任はプロダクトオーナーにありますが、Undone を回収するのはチームです。

チームは生産性を向上させるという観点から、自律的に Undone の回収に取り組む思考が必要ですが、Undone の回収に取り組むためにも、まずはベロシティを安定させることが重要です。

プロダクトオーナーはそのようなチームの活動を支援するために、Undone をチームが扱いやすい状態で管理しておく必要があります。

終わりに

プロダクトオーナーという立場では、今回書いたことを踏まえてチームの成果を多くのお客様が価値として認めていただけるようなプロダクトを開発していきたいと思います。

一方で、開発部のマネージャーという立場では、組織の成長、プロダクトの成長の両方の軸から、プロダクトオーナーの育成や組織上の立場をどうするかなどについて、自分で何ができるか考えて行動していきたいと思います。このあたりの取り組みについては、今後記事として書いていけたらと思います。

最後に、昨日の記事にも書いてありましたが、Odd-e Japan の認定スクラムプロダクトオーナー研修はおすすめです。

re:Invent 2016 参加レポート

re:Invent

こんにちは、開発の田中です。
最近は HULFT IoT の開発や、エッジコンピューティングの研究開発なんかをやっています。

はじめに

本記事は、アプレッソ Advent Calendar 2016 7 日目の記事です。

アプレッソ Advent Calendar 2016

先週ラスベガスで開催されていた AWS re:Invent 2016 に参加しておりましたので、その参加レポートを書いておこうと思います。

re:Invent は開発者向けのイベントで、開発者の方であれば得るものも多く、非常に刺激のあるイベントです。
読んでいただいた方がぜひ行きたいと思う記事になればと思います。
(現地レポートや、まとめ記事、新サービスを網羅するような記事ではありません。)

私は昨年も参加しましたので、昨年と比較してどうかという感想も書いていきたいと思います。

2 つの Keynote

f:id:ktanaka89:20161206145632j:plain

re:Invent では 2 回の Keynote で怒涛の新サービス発表が行われます。
今年は昨年と比較してもより多くのサービスが発表されましたし、そのインパクトもいろんな意味で大きかったと思います。

私が気になったサービスをざっくりカテゴリ分けしてみました。

  • クラウドへの移行
    • AWS Snowmobile
    • AWS Snowball Edge
  • AI
    • Amazon Rekognition
    • Amazon Polly
    • Amazon LEX
  • プリミティブなサービスを補完する系
    • Amazon Lightsail
    • AWS Step Function
    • Amazon EC2 Systems Manager
    • AWS Glue
    • AWS Batch (?)
  • 開発者をサポート
    • AWS CodeBuild
    • AWS X-Ray
    • AWS Shield

特にプリミティブなサービスを補完するサービスについては、非常にインパクトがありました。
いままで AWS のパートナー各社が自力でやっていたようなサービスが AWS によって管理され、運用コストも減るとなればユーザーにとっては非常にありがたいのではないでしょうか。

AWS Glue は名前が示すとおり、糊付けを行うサービスとのことです。
ストレージとしては、S3, RDS, DynamoDB があり、DWH には RedShift があり、BI には QuickSight がある。
しかし、今までそれらを糊付けするサービスがなかったので、AWS Glue を作りました、とのことです。
実際 ETL はさまざまなパッケージベンダーが提供しているにも関わらず、なぜ AWS が自身で提供する必要があったのかという問には、ETL を実装しているユーザーはたくさんいるが、実際にそれらの製品を利用している人は少ない、とデータを示していました。
うむ。

Keynote を通してあまりにもたくさんのサービスが発表されるので、Keynote の終盤は周囲をみるとだんだんついていけなくなってる人がいたような...

また今回強調されたキーワードとしては、以下のものがあったと思います。

  • クラウドへの移行
  • パブリックセクター・金融業界での導入

全てを AWS クラウドへ持っていける/持っていきたいという意思があり、それを支えるだけのサービスは用意した、という感じです。
また、AWS クラウドは公共機関や、金融業界などのセキュリティ、運用可能性、俊敏性などあらゆる面でシビアな業界でも使用に耐えられるプラットフォームであると主張していました。
昨年の新サービスや流行りを思い出すと、AWS Lambda や AWS IoT, API Gateway, Kinesis Firehose など、クラウドの可能性を模索したり広げたりするサービスがメインであったなと思います。

ブレークアウトセッション

私は主に、IoT 関連のセッションを受けていました。

  • IOT303 - Innovation After Installation: Establishing a Digital Relationship with AWS IoT
  • IOT202 - Internet of Things (IoT) Edge and Device Services
  • IOT203 - 1-Click Enterprise Innovation with the AWS IoT Button
  • IOT205 - IoT Analytics: Insights for a Connected World
  • IOT304 - IoT and Beyond: Building IoT Solutions for Exploring the Final Frontier

IoT に関してもいくつか新サービスが発表され、その一つに AWS Greenglass があります。
ざっくりいうと、AWS Lambda がネットワークエッジに下りてきた感じです。
まだ実際に使ってみることができないし、詳しい情報も不明です。

f:id:ktanaka89:20161206151730j:plain

ネットワークが不安定な場所にいるネットワークエッジで、常に安定してデータを送ることができない状況では、エッジはエッジで自立して活動し、ネットワークが繋がったらクラウドと情報を同期する、というような使い方を想定しているようです。
どこまで通用しそうなものなのか早く試してみたいですね。

また IoT プラットフォームとしての AWS をどれだけ簡単に素早く検証してもらえるかの工夫もありました。
その一つが AWS IoT Button と AT&T の IoT Starter Kit です。
AWS IoT Button はまだ日本では使用することができませんが、Amazon Dash Button でまずはユーザーとして使うことができます。

f:id:ktanaka89:20161206151732j:plain

展示や日本人同士の交流

相変わらず展示会場は広大でした。

f:id:ktanaka89:20161206153239j:plain

昨年は日本からは私達 HULFT の展示だけだったかと思いますが、今年は SORACOM 様、スカイアーチ様、富士ソフト様、サイボウズ様、mobingi 様など、多くの企業が挑戦に来ていました。

re:Invent にはジャパンツアーで 400 人 (くらい?) が来ていて、その方々が一同に集まる懇親会が開催されます。
ラスベガスというある意味隔離された場所で、しかも re:Invent 中という限られた時間という状況だと、日本にいるよりも濃いコミュニケーションが取れると思いました。
普段お会いすることが無いような方とも話すことができますし、re:Invent に来るメリットの一つはここにあると思います。

全体感

開発者はぜひ一度は行くべきイベントだと思います。
カンファレンスの開催の仕方を見ると、この人達は世界を動かしているなと本気で思いましたし、顧客のためにあらゆる手を尽くすと感じました。
自分も同じ土俵で勝負をしてるんだなと思うと、じっとはしてられませんよね。

というわけでみなさんぜひ一度は AWS re:Invent に行きましょう!!

おまけ

宿泊したホテル「ベネチアン」。
周辺のホテルは全部巨大で、歩いていると距離感がおかしくなります。

f:id:ktanaka89:20161206150513j:plain

アメリカに来たのであればまずは肉を食わねば。

f:id:ktanaka89:20161206150343j:plain

AWS Snowmobile 。
Keynote での初登場時は何のジョークかと思いました。

f:id:ktanaka89:20161206153443j:plain

参考

前回の参加レポートはこちら

re:Invent 2015 0 日目 - AWS 訪問 & シアトルセッションレポート - Appresso Engineer Blog
re:Invent 2015 1 日目 - ウェルカムレセプション & ブース展示 - Appresso Engineer Blog
re:Invent 2015 2 日目 - 基調講演 & ブレークアウトセッション & 展示 - Appresso Engineer Blog
re:Invent 2015 3 日目 - 基調講演 & ブレークアウトセッション & 展示 - Appresso Engineer Blog

セッションの動画

www.youtube.com

JUnitを試してみる

品質マネジメント

アプレッソ品質マネジメント部の磯です。最近メインDAWをableton Live8 から Live9 へバージョンアップしようか悩んでいます(ニッチな話)。

ちょこちょことアプレッソ技術ブログにエントリを書かせていただいてますが、今回はAdventCalendarにも進出してまいりました。 5日目の記事になります。

qiita.com

ではまず自分語りから始めさせていただきましょう!!

自分語り

私はずっとQA領域でお仕事してきたわけなのですが、一口にQAといいましても現場により呼ばれかたは様々です。

  • QA
  • テスト
  • 検証

しかし、実態は同じだったり異なったり・・・。

一般的にはQAというとプロセスについて着目した活動が多い印象があります。 一方テストというとシステムテストなどのフェーズ、GUIを伴った対象を動かして得た結果から品質を確認していくといったところでしょうか。

f:id:yoiso:20161204174810p:plain

このあたりも現場によっては統合テストよりになることもあるかと思います。

ちなみにアプレッソにおける品質マネジメント部の業務としては、上記の一般的なQA/テストで行われる業務のハイブリッドとなっています。

テストの自動化

さて、今回はテストの自動化に絡んだお話をしたいと思っています。

以前より、わたしの生息するQA/テスト界隈でも自動化の波が押し寄せてきています。

Selenium Selenium - Web Browser Automation

Appnium Appium: Mobile App Automation Made Awesome.

かつては高価なプロプライエタリのソフトが主流だった中で、OSSも洗練され大きく利用されるようになってきました。

こういったものを利用することで、基本的なテストは自動化を行って、よりクリエイティブなテストは手動で行っていくということが実現できます。

また、これらはプログラマブルである以外にも、実際の操作を記録して再現するといった機能を有しています。

以前にこういったエントリを書きました。

appresso.hatenablog.com

単体テストの自動化がアジャイルな体制においての品質保証の土台として大きく貢献する、ということでした。

また、アプレッソではスクラムによる開発を行っていますが、野口からのエントリにもありましたとおり、機能横断的なチームという点では課題があります。

appresso.hatenablog.com

現状において、GUI上からのテストについては自動化を進めていますが、さらなるスピード感をもって臨機応変にQAしていくためにはさらに必要なのはなにか・・・。

そうだ! プログラミングを学んで単体テストにも手を広げていねば!と思い至りました。

(そもそも「コード書けんのかい!」というツッコミもありそうですが、職能的に書けることが必須ではないため、往々にしてそんな状態の人が多いのではないかと思われます。)

というわけで、私はそこそこおじさんなのですが、新卒社員の様にこつこつとJavaを学んでいるところなのであります。

JUnit はじめの一歩

前置きが長くなりましたが、JUnitを試してみましょう!

導入

Eclipse, IntelliJ IDEAなどメジャーなIDEにはあらかじめJUnitが付属しているため、あらためてインストールする必要はありません。

今回はEclipseを使っています。

新規メニューから「その他...」を選択するとウィザードが起動します。

f:id:yoiso:20161205012347p:plain

たしかにJUnitテストケースが作成できますね!

つかってみる

今回は以下のような(かわいらしい)コードを使って単体テストを書いてみました。

入力値が偶数/奇数をチェックするクラス(hogehoge)およびテストケース(hogehogeTest)です。

入力値が2で割りきれる場合に「偶数です」、2で割り切れない場合に「奇数です」と文字列が返されます。

(なぜかはてなのスーパーpre記法がうまく働かなかったので、gistから貼り付けています。)

これを実行してみると、Eclipseの左ペインに結果が表示されます。

f:id:yoiso:20161205013320p:plain

緑になりました!

さて・・・現状ではここまでですw

おわり

はじめの一歩というよりも、下駄箱から靴を取り出そうとしたくらいではありますが、俺たちの本当の戦いはこれからだ!マインドで日々精進していきたいと思っております!

(追記12/6: JUnitをJunitと記載していたのを修正・・むむ!)