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

わすれっぽいきみえ

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

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とかの仕様を読んでたんだけど、ここらへんの仕様の話ってみんなどのくらい興味あるんだろう?
需要があるならそのうち書いてもいいなと思ってる。

転職活動の準備について

実は去年転職した。まだ1年経ってないが、去年の今ごろ自分はどんなことしてたっけ、何を考えてたっけと思ったので、そのときのメモを振り返ったら結構本気で転職活動していたので、そのことについて書く。

準備していたこと

2015年の5月ごろ割と精神的にクる内容の話が仕事とプライベート両方でほぼ同時に発生したのと、もともと3年経ったら他の会社を見てみたいなと入社時点から思っていたのとで、具体的にどのタイミングでどういう感じで転職活動するか計画を立てた。計画を立てて書ききったのは手元にあるメモの日付を見る限り2015年6月30日。計画と言っても大体以下のようなざっくりと逆算した計画だった。

  • 来年(つまり2016年)6月に退職する
  • そのためには最低でも5月には転職先に採用されておく必要がある
  • そのためには3、4月の時点で具体的な転職先とその条件を決めておく必要がある

実際のスケジュールは6月に最終面接通って、7月から有給消化に入り、8月から今の会社で働き始めた。『来年5月、転職先を決める』と当時はっきりと書いていて、おぉすげぇな(こなみ)と思った。

転職の条件

転職の条件は私個人の重要情報なので詳細は書かないけども例えば以下のようなものをリスト化した。

  • いくらほしいか
  • どういう職種がいいか
  • どういう業界がいいか
  • 職場環境に求める条件は何か
  • 普段仕事する上で何を大事だと思って仕事をしているのか
  • どんな仕事が好きか
  • 今の職場への不満は何か
    • それは転職したら改善されるような内容なのか、転職先で似たような問題にぶつかったらどうするのか
    • 転職せずに今いるところで地道にやってく方が結果いいということはないか
    • 転職をせずに転属をするという方法もあるがその選択肢は自分の中でアリなのかナシなのか

よくあるリストだと個人的にも思うけど意外とやらない人多いんじゃないかな。
なお人によって、このリストの内容は全然違うものになると思う。

私が面接官だったら何ができていてほしいか

もし自分が会社の人材採用に関わることがあったら何ができてて、どういう話ができる人に来て欲しいかを考えてリスト化した。もちろん自分の年齢、性別、これまでの職歴、やってきた仕事が履歴書として相手に渡るので、それを面接官として読みつつどういう内容を転職希望者に聞きたいかという前提条件はとても重要で、自分が送ろうとしている履歴書も合わせて考えることになる。
実際の面接で面接官が全然思ってたのと違う内容を訊いてくるような会社ならたぶん自分に合ってないのと、面接時の質問リストを用意できるのとで書いておいた。

あと転職希望者として面接官に聞きたい内容もまとめておいた方がいい。面接が終わって時間があったらだいたい「質問はありませんか?」と訊かれる。私が聞いたことをざっくり書くと、今そのサービスでどんな技術を使ってるのか、他のサービスと何らか連携させていったり将来的にやりたいことは何か、私が希望しているサービス以外で〇〇というサービスも実は気になってるんだがそれはどんな風なことを今後やってくのか、とかとか。

今問題だと思っていることと今後どうなりたいかとそのためにやること

かなり本気で書いていて、自分でいうのも何だが若干引いた。正直転職はしてみないと新しく行こうとしている環境がどういう環境かわからないし自分で上に書いていた『転職せずに今いるところで地道にやってく方が結果いいということはないか』という可能性を探るためにも現職での問題 について掘り下げて書いていた。自分自身、チーム、部署、会社全部書いてて、今読み起こしてみてもおぉすげぇな(こなみ。二度目)と思った。

当時の実際のモチベーション

実際の転職活動を始めるきっかけになったのは転職エージェントからメールが届いたためで、このブログを読んだらしい人からの連絡だった。転職サイトそのものは見てはいたものの自分の中でそんなに希望が高いわけじゃないなーと思っていて、転職エージェントからの話もどこまで面白いものが聞けるんだろうかと疑問に思っていた。

とりあえず転職活動自体をやったことがなかったので友人たちにどんなものかしらとあれこれ聞いたりしていて、「面接受けて受かっても、自分の中でやっぱりダメだと思ったら蹴ってしまえばいいのだし、とりあえず受けて進んでみないとわからないのでは。進んでみても相手の会社がやっぱきみきみさんいらないですって思ったら向こうから断ってくるわけだし、それも含めていい経験なんじゃないの。まぁくれぐれも変な人にはひっかからないでください」というありがたいお言葉をいただいたので、よくわからないけど中の人とまず話してみようというつもりで受けてたら最終まで通ってしまった。すごい。

2015年に転職の条件とか書き出したのは今すぐに転職するためではなく本当に嫌な気分をそらしたかったのもあって書いた感じで、いうほど本気じゃなかった。けどもその時書いたリストが結果的に自分を助けることになった。

結果と今

結果受かったから今の会社で働かせていただいてるわけなんだが、当時のことを振り返ると熱量が若干減ってないか?と反省した。今になって「なんで私受かったんだろうか…」と思ったんだが、メモ見返しつつ面接で聞かれたこととか思い出したらまぁダメな答え方だったと思う部分もあったけど、これだけ準備して落ちたら仕方ないなとある程度納得もするし、実際納得できるように準備してたんだなと分かった。メモはあくまでも自分用なので見せられないけど、本当に本気だったんだな、この人とw

思わず当時提出したレジュメに今までにやってきたことを追記して、私本当に成長してるんだろうか?と確かめたりしてる。本当に棚卸し重要。

いい意味で正直に面接を受けてたのが良かったみたいだったが、これがいつでも通用するとは思えないし誰にでも使えるすごいテクニックってわけでもないので、自分としても何とも言えない部分が多分にある。ただはじめた理由は「嫌な気分をそらすため」だったとはいえ、リストを準備しておいたというのは大変役に立ったので、そこだけは他のいろんな転職希望の方にもおすすめしたい。

個人的に以下の本は良かった。私がこの記事で書いたことよりずっと役に立つことが書かれてるので、さらっと読んでみるといいと思う。

会社は2年で辞めていい (幻冬舎新書)

会社は2年で辞めていい (幻冬舎新書)

ちなみに

この記事を書いたからって今転職考えてないです!!!

プロジェクトの成功条件・失敗条件について考える

この4月からプロジェクトマネージャーのお仕事が降ってきた。
正確には3月から準備していて、いろんな引き継ぎとか覚えることとかで忙しかった。

そんな中で早速正直失敗だなと思えるプロジェクトにぶち当たったので、これはチームメンバーでちゃんと振り返って次のプロジェクトでは同じ轍を踏まずに済むようにしたいねと話したんだが、よく考えてみると何でもって成功・失敗を判断してるんだろう?と自分でも思ったので試しに書き下してみる。

プロジェクトを進めてる途中の基準

期日

最初はいつを締め切りにしていたかとかユーザー、ステークホルダーのニーズに依存するが以下かなと思ってる。

  • 前倒しできた
  • ちょうどに終わった
  • ちょっと過ぎた
  • 大幅に過ぎた
  • そもそも終わらなかったので中止した

機能

多ければいいの?減らすことは悪いことなの?という問題もあるけどひとまず

  • 当初考えていたより多くの機能をリリースできた
  • 過不足なくリリースできた
  • 少し減らした
  • 大幅に減らした
  • そもそも仕様が破綻した

人数

途中で人が増えたり減ったりすることもあるので、一律で言えるものではないけどとりあえず

  • 多すぎた
  • ちょうど良かった
  • 少なかった

チームワーク

  • とても協力できていた
  • 協力できていた
  • あまり協力できてなかった
  • 全然協力できてなかった

フェーズの切り方

  • ちょうど良かった
  • 細かすぎた
  • 大雑把すぎた
  • 切ってなかった
  • どこで切ればいいかわからなかった

終了条件

  • 何ができていれば終わりか明確だった
  • なんとなく終わりがわかった
  • 何が何だかさっぱりだった

プロジェクトが終わってから

ユーザーインパク

お金、ユーザーからの意見などいろんな軸があるかもしれないけど

  • とても良かった
  • まぁまぁ
  • あまり良くなかった
  • やらないほうがマシだった

コード

コードを書くプロジェクトとは限らないから、人によってはドキュメントとかに置き換えればいいかな

  • 見通しが良い
  • ちょっと読み込む必要がある
  • 意味がわからない

だいたいこんな感じに分かれるんじゃないかなと思ってる。
足りない軸もあるかもしれないが、それって全部のプロジェクトに共通して言えることなのかは疑問。

書いてて思ったけど、ちょっと考えただけでもこれだけの軸があるので、部分的に良い悪いがきっとあるはずで、良いところは次も続けたいけど悪いところこそ積極的に共有していくべきかなと思う。悪いところも治そうとしすぎて返ってより悪くすることがあるから程度問題は難しいんだが。

様々なご意見お待ちしています。