A1. クラメソの請求を支える技術 〜40歳中年エンジニアの生存戦略〜

1. A1. クラメソの請求を⽀える技術
〜40歳中年エンジニアの⽣存戦略〜
2017/07/01
IT推進室 植⽊和樹
1

2. 2⽬次
請求システム 刷新の背景
新システムのポイント
まとめ

3. 3本セッションの成分
Lambda
かわいいよ
90%
エモい
10%
話題

4. 4⾃⼰紹介
名前:植⽊ 和樹（うえき かずき）
年齢:40歳
出⾝:新潟県妙⾼市
ITサービスマネージャー
IT推進室室⻑
AWS事業部オペレーショングループ⻑
オペレーション部⻑
@czkuk

5. 5２０年のエンジニア歴
年齢 職歴
1997年（20歳） ポケベル販売＋インターネットカフェ＋パソコンスクール
すごく暇だったのでFreeBSDを覚える
３ヶ⽉で東京の会社になぜか就職 Perlを覚える
なぜかシステムエンジニアに
LAMP + bind+ qmail + OCN エコノミー
2001年（24歳） ２回⽬の転職 東京に疲れ新潟に嫁を探しに帰る
2003年（26歳） ３回⽬の転職するも半年で退職し２ヶ⽉の無職⽣活
４回⽬の転職 Javaエンジニアに Oracleも⾊々いじる
2008年（31歳） リーマンショック 退職ラッシュ
なんかいろいろなサーバーの⼦守をすることに
2013年（36歳） ５回⽬の転職 Twitterの求⼈をみてクラスメソッドに転職
2017年（40歳） イマココ

6. 6
刷新の背景

7. 7刷新の背景
1000件超の構築・運⽤から得た、急成⻑ビジネスを⽀えるデータ分析基盤と AWS インフラ環
境の事例（17:00〜）｜AWS Summit Tokyo 2017

8. 8刷新の背景
毎⽉300枚 営業・営業事務が専念
つらい

9. 9携帯電話に似た請求モデル
請求書
AWS利⽤費（従量課⾦）
監視（従量）
運⽤（固定）
請求書
構築（ワンショット）
コンサル（タイマテ）

10. 10旧 請求システム

11. 11旧 請求システム

12. 12新 請求システム

13. 13リリースまでのスケジュール
2015年12⽉ 2016年1⽉ 2⽉ 3⽉ 4⽉ 5⽉ 6⽉ 7⽉
CRM評価・請求モデル検討 開発 ★リリース

14. 14
ポイント

15. 15新システムのポイント
データの⼀元管理
API & OAuth 2.0
Serverless
Salesforce

16. 16
データの⼀元管理

17. 17新 請求システム

18. 18データの⼀元管理によって解消されたこと
⭕️ 曖昧な業務フロー
⭕️ 契約情報の散在（データが紐付かない）
⭕️ 複数マスター（顧客名のぶれ、請求先部署）
⭕️ 台帳ごとのデータの⾷い違い（開始⽇、契約数）
⭕️ 「このお客様どのサービス契約してましたっけ？」

19. 19
API & OAuth 2.0

20. 20API, OAuth 2.0
• 主にデータの繋ぎこみだけ
• Python simple_salesforce
• MFクラウド請求CSVフォーマット変更を機にAPIへ
• OAuth 2.0 はクライアントでの利⽤は簡単

21. 21【宣伝】OAuth 2.0 ってな〜に？
A-2 基礎からの OAuth 2.0
〜 認証と認可の概念、認可コードとアクセストークンの意味 〜

22. 22Problem: Salesforce 24時間API呼び出し上限
１００％になると
APIが呼べなくなる
↓
業務が⽌まる

23. 23Solved: S3 ETag

24. 24
Serverless

25. 25とある運⽤担当者の訴え
「絶対にサーバーは管理したくないでござる」

26. 26新 請求システム
ココ
ココ

27. 27Problem: 処理に時間がかかる
Task timed out after 300.00 seconds

28. 28Solved: SQS Worker Queue
http://dev.classmethod.jp/cloud/aws/lambda-sqs-asynchronous-distributed-processing/

29. 29Solved: SQS Worker Queue
http://dev.classmethod.jp/cloud/aws/lambda-sqs-asynchronous-distributed-processing/

30. 30Lambdaログ監視
http://dev.classmethod.jp/cloud/aws/notify-error-cloudwatch-logs-with-lambda/
ログレベル毎に通知
先を変えられる
logs2sns2.yml
がオススメ！

31. 31AWS Managed Services
AWS⽉額利⽤費
$ 17

32. 32
Salesforce

33. 33Salesforceについて
• Salesforce初経験
• 複雑な請求モデル
• 請求締め処理部分はパートナー会社さんに依頼
• 画⾯まわりを内製
• よくできてる（テスト、カバレッジ、リリース）
• Trailheadで⾃習

34. 34外製？内製？
• バッチなど仕様が固めやすい部分は外製
• 画⾯などトライ ＆ エラー 部分は内製
• すべて内製すると製品毎に担当者を抱え込む
• 過度なカスタマイズはしない
• 業務をパッケージにあわせる

35. 35刷新後
• 半⽉かかってた請求業務が数時間に
• ⼯数：８０⼈⽇ → １２⼈⽇
• 営業への契約確認 → ほぼゼロ
• 契約内容 ＝ 請求
• マーケ施策強化
• 「しがないOL」がJavaプログラマーへ転向

36. 36
請求システムについての説明
= 終 =

37. 37新請求システムの印象はどうでした？
意外と単純と思いませんでしたか？

38. 38
おっさんの昔話

39. 39Programmer?
An Ordinary Engineer

40. 40プログラマーって？
たぶんこういう本が好きな⼈

41. 41糊付けエンジニア
HTTPのリクエストを受け取って
DBに格納して
条件指定して取り出して
テキスト整形してレスポンスを返す
⾼度なアルゴリズムとかデータ構造とか出てこない
⼊⼒＋出⼒＋条件分岐＋繰り返し
プログラムの基礎のみ

42. 42プログラミングの⼤衆化

43. 43Programming Interface
糊付け
フレーム
ワーク
認証
クラウド
OS
DB
ミドル
ウェア
ライブ
ラリ
ツール
それぞれ
専⾨的知識

44. なんでもできる⼈なんていない
44

45. 45フルスタック？フルフェーズ？
マーケ 営業 開発・構築 保守運⽤ 請求・会計
ビジネス戦略
⼈事・労務
各分野の専⾨家を
「エンジニア」としてサポート

46. 46４０歳の⽣存戦略
半径５メートル

47. 47まとめ
プログラムが書けるようになろう
API, OAuth 2.0 は覚えて損なし
コードレビューしてもらおう
社内各部の⼥性と仲良くなれました
パーツの組み合わせでシステムは作れる

48. 48