わすれっぽいきみえ

みらいのじぶんにやさしくしてやる

『第16回 Scrum Masters Night!』に参加した

smn.connpass.com

に参加してきた。スクラム関連の本は読んでたけど、これを実践・導入するのにはあまりにも知見がなさすぎたので勉強会で実践している先輩方からもっと話を聞いてこようと思った。

一旦参加者全員が話したいことをバーっと付箋に書いてホワイトボードに貼り付けて、自分が話したいテーマが書かれた付箋に1人2つまでシールを貼っていく。シールが多かった順に上から6つ選び、その中のどれかを自分で選んで、テーブル席で各自議論するという形式だった。

で、私が選んだテーマは『チームの生産性を上げるには?』。
生産性を上げるためにどんなことをスクラムでやってけばいいんだとか生産性が上がるってどういう状態なんだとかがよくわかんないなと思ったので、そのテーマの議論に参加することにした。

そのテーブル席ではファシリテーターの方が「『課題感』、『対策案』を付箋で各自出せるだけ出してみましょうか?」と言って開始したので、実際に付箋に書かれて出されたものを以下にざっと書く。

テーマ: チームの生産性を上げるには?

課題感

  • チームが成熟してくるとプロジェクト開始当初とストーリーポイントの内容が変わってくるはずだけど、その違いはどう測る?
    • どのタイミングでストーリーポイントの見直しを行うべきか
  • そもそも生産性って何?
    • ベロシティ/コスト = 生産性?
    • 生産性 = スピード?
    • ベロシティが上がったら生産性も上がったと言えるの?開発スピードが上がることだけが生産性向上と言えるの?
    • 数字にならない(なってない)ところで生産性が上がってたりもするのでは
    • 部署全体でKPIを改善すると言ってるけど、どんなKPIを設定すればいいの?
  • そもそも『生産性を上げましょう』ということがチームの命題となっている?

対策案

  • 生産性向上のKPIになりえるもの
    • story pointが特定スプリント内で計画的に消費されてく状態
    • デプロイ回数(頻度の方が正しそう)
    • pull request差し戻し回数
    • dev環境upから本番環境upまでのリードタイム
    • スクラムに充てる時間
      • 開発を進めたいのであってスクラム自体に時間を大量に充てるのは間違ってる
      • ある実働時間のうち、どのくらいの時間をスクラムに充てるのかは指標になりえる
  • 収益とコストとベロシティの関係を見える化する
  • スターマップの充実

目的

  • ベロシティ計測は計画性の担保
  • モチベーションアップ
  • ステークホルダーへの説明の材料

解あり?

  • 生産性を上げるために課題となっていることは何?
  • ベロシティ計測のツールに何を使ってる?

結論

  • そもそも生産性を上げるなら、生産性が上がった状態というのを定義してあげる必要があって、定義する役目はPOが負っている。POは生産性を上げるための定義をした上でチームと合意を取る必要がある
  • ベロシティは上げるものではなくて安定させるもの。ベロシティがずっと上がり続ける状態はそもそも異常な状態で、ベロシティは今の我々の実力で何がどのくらいの時間で終われるのかを示すための指標。その指標がブレブレだと見積もりが破綻していることを表してるので、まずは安定させることを第一に考える。
    • そのうえで成熟したチームになるとベロシティを測るために使用していたストーリーポイントの中身がプロジェクト開始時期よりも濃いものになっているはずで、ここは定期的に見直していく必要がある
  • トーリーポイントが振られてないチケットが存在すること自体は問題ではなくて、チームのベロシティを計測するのに値するチケットをスプリントに入れることが重要。もし混乱するのであれば、異なるスプリントを作るなりしてチケットをベロシティ計測のものと分離するのも一つの方法。
    • ただしその方法を取ると本来ユーザーに価値を届けるために進めているスプリントがチーム開発のやりやすさを優先させたスプリントに変容してしまう可能性があって、運用に注意が必要になる。
    • 勉強会が始まる前に社内の先輩とちょっと話した感じでは、ある期間にやろうとしていることを同一スプリント内で回す必要はないよねという話は出ていた。(単に見せ方の問題も含まれてるかも)
  • 一個のチケットに振られたストーリーポイントが異常に大きい場合はタスクを細分化するための調査チケットを別に切る運用をしている
    • これはすでにうちのチームでもやってる
    • あるチームでは8ポイント以上、あるチームでは5ポイント以上だと細分化が必要という感覚値らしい。この辺も結構うちのチームでの実感値と近かった。

大体こんな感じでお話が進んだ。

社内チームでやってきたことは間違ってなかったんだな!と思う瞬間があったのは良かった。一方で本当に悲しいことに、ここで議論する以前の問題がチーム開発で発生しているなーと思う部分もあった。

またこの日の勉強会で、アメリカではスクラム開発で戦闘機を半年で作るらしいことを聞いた。戦闘機を開発するプロセスをちゃんと知らないので内心それが本当に早いのか遅いのかよくわからないけど、なんかすごい気持ちにはなった。戦闘機を作るプロセスに必要なものがある程度わかっていて、熟練のスクラムマスターとかがいたら半年ってそんなに変な数字じゃない気がするけど、新しく研究開発した戦闘機を半年で作るって話なら相当に早い気がする。背景が知りたい。

f:id:kimikimi714:20170613004614j:plain

Qiitaの記事を地味に更新した

qiita.com

ブログってやっぱフローなので、ストックしていきたいものを更新するのにはあんまり向かない気がしてる。 古い記事もたまに気になったら編集したりするけど、やっぱ何か一つのことについて継続的にためてくならQiita便利っぽい。

Qiitaのタイトルから期待するほどのワンライナーないので、もうちょっとちゃんと充実させていきたい。

PPUG #2 - PayPal実装・運用編 - に参加してきた

ppug.connpass.com

↑に行ってきたので、そのときのメモを上げる。

freeeにおけるPayPal課金の実装事例 by Yuichiro Ebihara, freee株式会社

遅刻したのでほぼ聞けませんでした><;

  • 決済手段が増えたことによるコストは?
    • システムの運用はそんなに困らない
    • 経理的な面が大きい。手段増えて、何をどれで決済したのか計算するのが大変っぽい。

PayPal取引履歴の読み方と仕訳方法 by Satoshi Motoyama, kumajoi

  • PayPal売掛金をどう扱うかについて
    • ユーザーが買った日ベース?入金日ベース?
  • PayPalAPIを使って取引履歴を取り込むことが可能
  • 基本的にはクレカ決済と同じ(入金日ベース)
  • PayPalには異議保留というのがある
    • 資金が一時的にPayPalに保留される
  • 取引履歴の例
    • 支払い
    • chargeback
    • 異議解決による保留のキャンセル、異議調査のための残高保留
    • …ちょっと見ただけで20項目もある
  • 取引履歴はダウンロード可能(対象残高にする)
    • タイムゾーンはPDT
    • 手数料も記載される
    • レポート→会計概要→月別とかも選べる
  • 売上日はいつ?
    • デジタルや現金主義の場合 入金日 = 売上日
    • PayPalにあるお金をどう扱うか
      • PayPal自体を銀行の一つにするという考え方
      • PayPalにあるうちは売掛金扱いにするという考え方
      • → 銀行口座の一つとしたほうが良さそう
    • chargebackは基本的にPayPalが負ってくれる
      • ユーザーから異議申し立てがある
      • shopからPayPalに一旦お金が戻される
        • PayPalが異議を認めた場合、shopにお金を戻さない
        • PayPalが異議を却下した場合、shopにお金が戻る
      • shopが自主的にお金を戻す場合とPayPalが強制的に戻す場合で変わる
  • 為替レートはその日の終値?TTM(好評な価値)?1ヶ月終わったあとに月中平均でTTM?
    • PayPalだと一旦PayPal口座にはずっとユーロならユーロで持っておけるので、持っておいて決算のときだけ為替計算をするのが妥当だと思う
    • レポーティングするときだけ為替の計算をするのが良いと思う
    • 一応PayPalAPIとしてFXの値を出すAPIがあったりする。しかしFXの計算をするAPIはとても限定的な利用しかできないらしく、またFXのレートに何を使っているのかPayPalは公式として公開していない。なのでサポートに聞いてもAPIを叩くのもかなり手間だし、お支払のタイミングで計算するのがいいのでは、と教えてもらった
  • PayPal特有の表現があり、難しい

新しい実装方法 Braintree SDKについて by Junichi Okamura, PayPal

  • braintreeとは
    • payment gatewayPayPalの中のサービスの一つ(PayPalの子会社)
    • braintreeのアカウントなしで実装可能
    • プロダクトとしてはPayPalとは別
    • 日本ではbraintreeがまだ使えない
  • PayPalとPayment Gatewayの違い
    • PayPal = digital wallet
    • Braintree = Payment Gateway (収納代行)
  • Braintree
    • checkout(都度決済)
    • recurring payment(定期支払)
      • ちょっと待てよ…。もうRESTful API使っとるんだが…。初めからこれ使ったら良かったやんけ…。
    • 従量課金(vault)
    • マーケットプレイス用決済
    • payout(送金)
  • SDKの種類

demo: https://github.com/benzookapi/VZeroNodeDemo

懇親会

  • これまで行った勉強会の中ではだいぶ小ぶりな感じだった。
  • 電話の話は面白かった(なんとなくまだサービスのローンチが終わってなさそうなので詳細は伏す)
  • PayPalの勉強会に凸版印刷の方が来てるのが面白かった。
    • 何故かweb系の人しか来ないと思い込んでた。
    • 認証チップを作るのもやってるらしくて、そこにPayPalをつなぎこんでみる話とか聞けた
  • Braintreeめっちゃ便利そう話聞けた。
    • もうちょっとまともにAPIを読む必要がある
    • リファレンストランザクションという機能をPayPal自体が持ってるが、これはとても古い。一方braintreeの中にリファレンストランザクションの機能があるので、今後はそれを使うと良いとのこと。

以上です。

ここ最近ずっとPayPalAPIとかstripeのAPIとかAvalaraのAPIとかの仕様を読んでたんだけど、ここらへんの仕様の話ってみんなどのくらい興味あるんだろう?
需要があるならそのうち書いてもいいなと思ってる。