APIStudy#5 開催報告

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

去る2月21日に、APIStudy#5が開催されました。

前回の#4 の様子はこちらからご覧ください。

appresso.hatenablog.com

今回はゲストに乗り換え検索アプリ「駅すぱあと」でおなじみの株式会社ヴァル研究所さんを迎え、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トークをしていただいているおかげです…。

次回はさくらインターネットさんで開催します。

apistudy.connpass.com

そしてなんと！この度#6開催の増枠が決定！(2017/03/15情報更新) 40名まで定員を増やしました！

(APIに飢えている)けものはいても、のけものはいない♪

Welcome to ようこそAPIStudyパーク！

宜しくお願いします。

ペアプログラミングしていてもレビューは必要か？

こんにちは、開発部の野口です。

この記事では、私が所属していたスクラムチームでペアプログラミングが始まって、コードレビューがどう変わっていったかというストーリーをお話しします。

目次

ペアプログラミングが始まる

私が所属する 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 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のユーザーコミュニティ」であり、全国各地に支部を設けユーザーが自発的に勉強会を開催しています。

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

kintonecafe.com

関東女子会支部設立

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

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

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

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

kintonecafegirls.qloba.com

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

company.qloba.com

記念すべき第1回開催

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

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

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

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

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

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

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

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

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

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

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

▲李さんからのわかりやすい製品紹介

▲私も活用事例を紹介しました

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

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

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

▲三宅さんからサイボウズ社内での活用事例

▲四宮さんからは質問疑問をその場で解決！な相談コーナー

▲関西女子会運営の池上さんからJAWS Daysのお知らせ

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

ascii.jp

さいごに

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

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

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

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

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

APIStudy#4 開催報告

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

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

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

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

appresso.hatenablog.com

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

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

どんな仕上がりになるのか！楽しみです。(すっかりファンになりました私です)

第1部

フロムスクラッチさんLT

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

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

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

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

有志LT

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

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

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

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

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

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

• 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ページからどうぞ。

apistudy.connpass.com

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

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

APIStudy#3 開催報告

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

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

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

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

appresso.hatenablog.com

第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回の開催が決定！

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

apistudy.connpass.com

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

ではまた来月！ 皆様、良いお年を＆良い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日目の記事です

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 の認定スクラムプロダクトオーナー研修はおすすめです。