文学部卒・新卒未経験エンジニアが、1年間でGoogleAnalytics型のユーザー行動分析ツールを開発するまでに得た学びとは。

1. 「作らないことも選択肢に」
「なぜやるのかを自分の言葉で」
未経験エンジニアが社会人1年目で
学んだ
Hirokazu Kobayashi,
Livesense Inc.

2. 自分がソフトウェアエンジニアを志した理由は、
大学時代に自営業を営む父が倒れたことがきっかけだった。

3. これまでちゃらんぽらんにやってきた自分は、
職人肌でクリエイター気質の父に、
そして3代続いている家業に、
こんなときに、何もできないことに気づいた。
自分が何をすれば、未来に亘って貢献できるのか。
そう考えた時に、ソフトウェアエンジニアに可能性を感じた。

4. 誰もが知っていて、
本当に技術の高いモノ。
そこに自分の職人魂を込めたい。
本田宗一郎夢を力に―私の履歴書

5. 幸い父は大事に至らず無事だった。
家業も平穏を取り戻した。
そして自分は、今働いている会社の門を叩いた。
新卒募集を行っていなかったので、中途の応募フォームから応募。
一度お祈りされたが、行動力で入社に至った。

6. 1.サービスが前に進むのなら、
時には開発を止めて雑務でもこなすべき
2.忙しくてもセミナーや勉強会は継続的に行こう。
難しいと思っていたことも一流の人の話を聞くと一瞬で
理解できることがある。
3.自分がクリエイターだからこそ、
作らないことも選択肢のひとつに。
そして、この一年で学んだこと。

7. 4.工数見積もりは難しい。
周りのアドバイスをうまく取り入れ、
「隠れたやるべきこと」を見つけよう
5.引き継ぎ仕事であっても、
なぜやるのかを自分の言葉で明らかにして、
自分事にするべき
6.こっぴどく怒られた時こそ逃げちゃダメ。
細かく理由を聞こう

8. 一年間の経験から、その教訓を振り返る
2014/04
2014/07
2014/10
2015/01
2015/04
入社・配属
ユーザー行動解析ツール
Livesense Analyticsの開発
社内分析基盤システム全般の開発・運用・改善
新卒研修
Paciriiの開発
Livesense Analyticsの
Blog記事化

9. 新卒研修として、Paciriiというサービスを作った時の話
2014/04
2014/07
2014/10
2015/01
2015/04
入社・配属
ユーザー行動解析ツール
Livesense Analyticsの開発
社内分析基盤システム全般の開発・運用・改善
新卒研修
Paciriiの開発
Livesense Analyticsの
Blog記事化

11. 渋谷駅から半径1km圏内、運営期間限定で実施。
プロジェクトは検討期間を含めてほぼ1ヶ月。
Paciriiとは
「欲しい商品を30分で、
あなたに代わってお届けするサービス」

12. 開発の前にまずやったのは、
サービス検証

13. チラシを作って

14. チラシを配る

15. 電話で受注・お届け

16. あれっ、、、
Webエンジニアとしてやることなし

17. 「エンジニアとして入ったのに、何やってんだろう…」

18. Paciriiの実験では、ビラと電話で十分機能しました。
しかし腹の中では、戦略に基づいた必要最低限の実装で十分である
事実と、エンジニアとしてモノを作りたい気持ちとの間で大きな
藤がありました。

19. しかしプロである以上、好きなモノを作るという視点は捨て、
目標に対して最短の選択を取るべきです。
そして、もっとちゃんと本当に作るべきことに考えを巡らしていれ
ば、もっと作るものをフォーカスできたはずです。

20. 学んだこと
サービスが前に進むのなら、
時には開発を止めて雑務でもこなすべき

21. そして、ジリジリ減る残された時間

22. 理想と現実の間で、溜まるフラストレーション

23. そしてようやく、Web開発にシフト

24. 必要な機能を洗い出すため、
検証サイト(MVP: Minimum Viable Product)を作る

25. 省力化のため、
Google Formを使った即席フォーム

26. 受注管理シートは
GoogleDocsの仕掛けをそのまま利用。
オーダーフォームが送信されると
GoogleSpreadsheetに書き込まれ、
受注管理シートとして使える。

27. 商品マスタは用意すべきかか、
どんな注文が来るのか、
住所入力は簡単にできないか、
オーダーから納品まで、どのように管理するか、、。
考えることはたくさんあったが、

28. まずリリースして使ってもらい、
ユーザーが何を望んでいるかを知りたかった。

29. 検証用に作ったものが、バズる
http://narumi.blog.jp/archives/5729818.html
http://attrip.jp/128261/
http://r25.yahoo.co.jp/fushigi/jikenbo_detail/?id=20140430-00035994-r25
http://www.asuka-xp.com/pacirii.html
左から

30. 跳ねるアクセス数、約15,000訪問まで到達

31. オーダーが管理シートに反映されるまで2時間の遅延。

32. 急ごしらえの限界で、
お客様にも影響してしまった。

33. twitter経由でもありがたいご指摘

34. 急いで改修しなくては。

35. もはや時間の猶予は、
まったくない・・・

36. ピンチ

37. さかのぼること、
その2週間前。
Gerry Lauzon Longines pocket watch

38. 部署に配属された、そのころ

39. 上司「行ってこい」
自分「忙しすぎて無理ですｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ」
上司「だから行ってこい」
自分「わかりました＞＜」

40. AWSエヴァンジェリスト
堀内 康弘氏(現マネーフォワード技術顧問)
のハンズオンに参加。
http://bit.ly/awsho-vpc-mt-v8より

41. http://bit.ly/awsho-vpc-mt-v8
マルチAPPサーバー、
Master-SlaveDBでの
システム構築を、
手を動かしながら学ぶ。

42. 感銘をうけたのは「クラウドデザインパターン」
クラウド(Amazon)を利用してシステムを構築する際に起こる、
典型的な問題を解決するための設計ノウハウをまとめたもの。

43. http://bit.ly/awsho-vpc-mt-v8
アクセス数が多くても耐えら
れるよう、複数のWebサーバー
に処理を分散する
「Multi-Serverパターン」

44. http://bit.ly/awsho-vpc-mt-v8
データベースに障害がおきても
システムが落ちないよう
サーバーを常時複製し、
なおかつ別のデータセンタに
配置する
「DB Replicationパターン」
「Multi-Datacenterパターン」

45. それぞれ数クリックで、
サーバーの堅牢性が増す。

46. さっそく開発に取り入れてみる。

47. AWSなら簡単にできた・・・

48. 目からウロコ。
忙しい時期だったが、
行って本当に良かった。
※「AWS体験ハンズオン」で検索すると、
現在も参加可能なセミナーが見つかります

49. 学んだこと
忙しくてもセミナーや勉強会は継続的に行こう。
難しいと思っていたことも、
一流の人の話を聞くと
一瞬で理解できることがある。

50. その後、急ごしらえだった
アプリも改修し、リリース。

51. どうにかサービスを回したが、
継続的なビジネスに育てるまでは至らず、
反省点も・・・

52. 「聞けばよかったこと」はたくさん
自分で解決しなくては、という責任感からついつい考え込んでしまい
結果的に聞いたほうが早かった事が多々ありました。
自分で考えることや調べることは大切ですが、
目標に最短の選択を検討するべきです。

53. 「聞けばよかったこと」はたくさん
自分はまだ未熟な故、回り道をしても新たな発見が沢山あり、とても
魅力的に見えてしまいます。
予め期間を区切り、それを超えるような事があれば、
予め検討した代替手段に切り替えるべきです。

54. 要件がコロコロ変わるのにうんざり
今回の様な小さく始める新規事業は、要件がコロコロ変わっていきま
す。それは誰のせいでもなく、その都度検証するべきことに忠実にあ
れば、必然的にそうなると思います。
その度に変更点が多く、うんざりすることが多々ありました。

55. 要件がコロコロ変わるのにうんざり
しかしそのように感じる時は、プログラムを複雑に作りこんでしまっ
ていたり、汎用性が低くて変更に弱い場合も多かったです。
対処法としては企画側と密に連携を取り、出来るだけ要件変更の先読
みをするべきです。そしてコードもシンプルに、綺麗に書くことで汎用
性を高める必要があると感じました。

56. 必要以上の実装はただの自己満足
これもやったらユーザーは楽になる、あの実装はどんなWebサイトで
もやっているんだし、当然実装しよう。
最悪です。ただの自己満足です。他のタスクと優先度やインパクトを
比べずに、「∼の為になる」などと考えるのはただの自己満足です。
もっとインパクトの大きい事があれば、そちらをやるべきでした。

57. 学んだこと
自分がクリエイターだからこそ、
作らないことも選択肢のひとつに。

58. GoogleAnalytics型の
ユーザー行動分析ツールを開発した時の話
2014/04
2014/07
2014/10
2015/01
2015/04
入社・配属
ユーザー行動解析ツール
Livesense Analyticsの開発
社内分析基盤システム全般の開発・運用・改善
新卒研修
Paciriiの開発
Livesense Analyticsの
Blog記事化

60. LivesenseAnalyticsとは、GoogleAnalyticsと同じ
ウェブビーコン型 のアクセス解析ツール。
サイトに埋め込まれたJavaScriptが
CookieにユーザーIDや訪問回数などの情報を保存した上で、
サーバー側に送信し、行動履歴を蓄積する。

61. 先輩の作ったプロトタイプがあったとはいえ、
実働メンバーは、自分一人。
各ウェブサイトへの埋め込み、
自社のメディアデータとの連携や、
JavaScriptからバックエンドの開発まで。
いままでで一番規模が大きい開発。

62. はじめてちゃんとスケジュールをひいてみた

64. 「先輩の作ったプロトタイプもあるし、
要件定義は3日ぐらいかな、、、」
などと余裕を持って積み上げ、
それっぽくなった
伏線

65. そしてプロジェクト開始

66. ここにスケジュールがあるじゃろ？
( ＾ω＾)
[=]

67. やってみると
( ＾ω＾)

68. こうじゃ…
( ＾ω＾)
[=================]
ｼﾞｬｰﾝ

69. 3日のタスクに、
日かかる。
9

70. 77回
指摘&修正回数

71. やったことのない仕事だったため
「隠れたやるべきこと」を見積もりきれず、
想定外の仕事量になってしまった。

72. 反省。。

73. 「ソフトウェア見積もりの主目的は、(中略)
達成可能な程度に実現的なものかを
判断するためである。」
言い訳すると、
見積りのプロも、ちゃんとは見積もれないって言ってる(́・ω・｀)
ースティーブ・マコネル、『ソフトウェア見積もりー人月の暗黙知を解き明かす』

74. その後、改善のため取り入れたこと:
プランニングポーカー
1ポイント＝およそ半日として
複数人が「いっせーの」で同時に見積もる。
数字が離れているときは話し合って、
「隠れたやるべきこと」がないか議論。
聞きにくさを減らすため、
毎週のミーティングに組み入れる

75. まだうまく見積もれないが、
見積もりのブレ幅は減った。
最初の見積もりを一緒にやってもらうことで、
周りに相談もしやすくなった。

76. 学んだこと
工数見積もりは難しい。
周りのアドバイスをうまく取り入れ、
「隠れたやるべきこと」を見つけよう

77. ではなぜ、要件定義に時間がかかってしまったのか。

78. Livesense Analyticsの仕事は、
先輩がプロトタイプを作っていた、引き継ぎ。

79. 要件なんて、もう自明だと思っていた。

80. 先輩から引き継いだ資料を元に、
ざっくりしたドキュメントを整形。
サイトに組み込んでもらうため、
処理の流れを中心に記述。
その上で、導入してもらう
ジョブセンスのエンジニアに相談。

82. 「そもそもまず要件を最初に明確にしましょう。このシステムで何を達
成すればいいのか、わからない。」「Howしか書いてないから、What
が明確じゃないので書かれてる内容の妥当性が不透明です。」「ジョブ
センスでは別のユーザー行動解析ツールいれてるけど、それでも課題の
全ては解決できないということ？」「GoogleAnalyticsのプロ版が高いっ
て費用のことが書かれてるけど、君の給料がもうちょっと高かったらそっ
ちでいいわけ？」「列挙されてる必要事項の粒度がばらついてて、メディ
ア側でどんな協力すればいいのかわかりにくい」「取得データの利用シー
ンがよくわかんないんだけど」「これシステムの可用性ってどれくらい
なんですか？落ちたらメディアも巻き添えで止まっちゃうの？それだと困
るんだけど」「それじゃ、ジョブセンスに入れられません。」

83. 「それじゃ、ジョブセンスに入れられません。」

84. 「ちゃんと、考えたの？」

85. （そんなこと、先輩のドキュメントには書いてなかったとは言えない・・・）

86. 学んだこと
言われたことをやるだけでは
責任は満たされない

87. 77回の
そして、
指摘&修正

88. テクニカルな部分だけではなく、
背景や課題、そして目的をまとめ、
なぜこのシステムが必要なのかを
記した。

89. 今回の経験では、
そのシステムが必要とされる理由を考え自分の言葉で記すことで、
コードでは表せないシステムの目的に初めて気づくことができました。
しっかりとした目的を持つことで
なにが重要かを自分で判断できるようになります。
工数削減や創意工夫を凝らす際にとても有用ですし、
なにより言われたことをやるだけの「やらされ仕事」ではなくなります。
今では必ず開発前に実施するようにしています。

90. 学んだこと
引き継ぎ仕事であっても、
なぜやるのかを自分の言葉で明らかにして、
自分事にするべき

91. Google Analyticsよりも使いやすいアクセスログ
サンプリング無しの生データ
LAデータの1行は、ユーザーのPV単位になっています。なのでユーザー
のPV、セッション単位の分析など、Google Analyticsで行っている
ような分析は基本的に出来ます。
Google Analyticsと比べたLAのメリットは、サンプリングされてい
ない生のデータをSQLで扱えることです。
メディアと同じ会員・案件・応募ID
LAはリブセンスのメディアに最適化された分析基盤です。
Cookie上に保存された会員IDや、URLに含まれた案件・応募IDなどを
自動で取得し、アクセスログと紐付けています。
例えばとあるジョブセンスの会員が応募完了ページに行くと、LA上の
レコードには応募IDと案件IDと会員IDが埋め込まれています。
そしてこの反省をふまえて、使う人目線でのドキュメントを書くように。

92. その後、現場のエンジニアにも
コードレビューをしていただきながら
どうにか無事リリース

93. 参考になった本：
プログラミング言語 Ruby
業務と並行してインターン生を教えるのですが、
その際自分がちゃんと分かっていないと
教えられないという使命に駆られ、読みきりました。
472ページあるのですが、
数あるRuby本のなかでも精緻。
エンジニアとして使える技術という文脈でも、
何回も読みなおしています。

94. AWSについてなんとなく知識がついたけど、
Livesense Analyticsの設計を考える時にいくつも
サービスの組み合わせが発生し、選択を迫られた
時に助かった本。
汎用性の高いパターンやベストプラクティスも載っ
ているし、そこからAWS側の設計思想的な部分も
読み解ける（と思いました）。
参考になった本：
Amazon Web Services クラウドデザインパターン 設計ガイド

95. Livesense Analyticsの成果を、
Blog記事にしましょう、と言われて
2014/04
2014/07
2014/10
2015/01
2015/04
入社・配属
ユーザー行動解析ツール
Livesense Analyticsの開発
社内分析基盤システム全般の開発・運用・改善
新卒研修
Paciriiの開発
Livesense Analyticsの
Blog記事化

97. marketing.livesense.co.jp facebook.com/LivesenseDigitalMarketing
社内で運営しているマーケティングブログ

98. もちろんブログ書くよね？
は、はい書きます＞＜
得意ではないが二つ返事

101. 記事を書いてみた

104. 67 行の文章に、
箇所の修正。
62
※文章構成を直してもらって、だいぶマシになった後半戦での話です。

105. 「週明け火曜」が、
2ヶ月かかるとはおもっていなかった。

106. 反省点は、、
うーん、、
なんか全然ダメ。
すみませんごめんなさい！
で、出直してきます＞＜

107. はやく終わらせたい一心での、平謝り。

108. 平謝りしたものの、
何をどう直したらいいんだろう・・

109. そして、
理由がわからないので見当違いの修正をしてしまう。
前より悪くなってる・・・。
どうしてこうなった・・・（呆
すみませんごめんなさい！
で、出直してきます＞＜
以降、無限ループ

110. その場で細かく聞いて、
後で悩んで手が止まる要素をなくせばよかった。

111. うーん、、
なんか全然ダメ。
どこがまずいですか？
その理由はなんでですか？
ではこう直したらOK?

112. とにかく問題が何なのかを考えるように
なった本。これを読んで、わからないと
きは質問をし、まず問題を明らかにする
癖を付けました。
安宅和人『イシューからはじめよ』
参考になった本

113. 学んだこと
こっぴどく怒られた時こそ逃げちゃダメ。
細かく理由を聞こう

114. 一年を振り返って

115. 入社当初は、今まで見てきた職人たちにへのあこがれから、
漠然といいものを作りたいという思いがありました。
しかし、初めて経験する仕事として、
難題を乗り越える為にもがく日々。
覚えることに謀殺される毎日で、
当初の思いは頭の片隅へと追いやられていきました。

116. そんなプロダクトも完成し運用段階になると、
未熟さ故の設計崩壊や、頻発する障害が目立つようになります。
にも関わらず利用者は増え、
止めることの出来ないシステムに。
本当にいいモノって、こんなものじゃないはず。
そんな時、新卒研修後に師匠から言われた言葉を思い出しました。

117. 自分の作ったものを本当に良いプロダクトにするには、
まさにこれが足りていませんでした。
それを今、周りの経験者から学び、
本当のプロを目指していきたいと考えています。
エンジニアは「ミスが許されない職種」。
自分の慣れている技術以外の物は避けるべきであり、
エンジニアにとって「使える技術」とは
トラブルに対処出来る技術を指す。

118. 小林寛和(ひろかず)
(株)リブセンス
基盤事業本部 - Analyticsグループ
文学部(人間科学専攻)出身
新卒2年目
Vim
ギター, ダーツ