Transcript

• 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記事化
• 10. 渋谷駅から半径1km圏内、運営期間限定で実施。 プロジェクトは検討期間を含めてほぼ1ヶ月。 Paciriiとは 「欲しい商品を30分で、  あなたに代わってお届けするサービス」
• 11. 開発の前にまずやったのは、 サービス検証
• 12. チラシを作って
• 13. チラシを配る
• 14. 電話で受注・お届け
• 15. あれっ、、、 Webエンジニアとしてやることなし
• 16. 「エンジニアとして入ったのに、何やってんだろう…」
• 17. Paciriiの実験では、ビラと電話で十分機能しました。 しかし腹の中では、戦略に基づいた必要最低限の実装で十分である 事実と、エンジニアとしてモノを作りたい気持ちとの間で大きな 藤がありました。
• 18. しかしプロである以上、好きなモノを作るという視点は捨て、 目標に対して最短の選択を取るべきです。 そして、もっとちゃんと本当に作るべきことに考えを巡らしていれ ば、もっと作るものをフォーカスできたはずです。
• 19. 学んだこと サービスが前に進むのなら、 時には開発を止めて雑務でもこなすべき
• 20. そして、ジリジリ減る残された時間
• 21. 理想と現実の間で、溜まるフラストレーション
• 22. そしてようやく、Web開発にシフト
• 23. 必要な機能を洗い出すため、 検証サイト(MVP: Minimum Viable Product)を作る
• 24. 省力化のため、 Google Formを使った即席フォーム
• 25. 受注管理シートは GoogleDocsの仕掛けをそのまま利用。 オーダーフォームが送信されると GoogleSpreadsheetに書き込まれ、 受注管理シートとして使える。
• 26. 商品マスタは用意すべきかか、 どんな注文が来るのか、 住所入力は簡単にできないか、 オーダーから納品まで、どのように管理するか、、。 考えることはたくさんあったが、
• 27. まずリリースして使ってもらい、 ユーザーが何を望んでいるかを知りたかった。
• 28. 検証用に作ったものが、バズる 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 左から
• 29. 跳ねるアクセス数、約15,000訪問まで到達
• 30. オーダーが管理シートに反映されるまで2時間の遅延。
• 31. 急ごしらえの限界で、 お客様にも影響してしまった。
• 32. twitter経由でもありがたいご指摘
• 33. 急いで改修しなくては。
• 34. もはや時間の猶予は、 まったくない・・・
• 35. ピンチ
• 36. さかのぼること、 その2週間前。 Gerry Lauzon  Longines pocket watch
• 37. 部署に配属された、そのころ
• 38. 上司「行ってこい」 自分「忙しすぎて無理ですｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ」 上司「だから行ってこい」 自分「わかりました＞＜」
• 39. AWSエヴァンジェリスト 堀内 康弘氏(現マネーフォワード技術顧問) のハンズオンに参加。 http://bit.ly/awsho-vpc-mt-v8より
• 40. http://bit.ly/awsho-vpc-mt-v8 マルチAPPサーバー、
 Master-SlaveDBでの
 システム構築を、 手を動かしながら学ぶ。
• 41. 感銘をうけたのは「クラウドデザインパターン」 クラウド(Amazon)を利用してシステムを構築する際に起こる、 典型的な問題を解決するための設計ノウハウをまとめたもの。
• 42. http://bit.ly/awsho-vpc-mt-v8 アクセス数が多くても耐えら れるよう、複数のWebサーバー に処理を分散する 「Multi-Serverパターン」
• 43. http://bit.ly/awsho-vpc-mt-v8 データベースに障害がおきても システムが落ちないよう サーバーを常時複製し、 なおかつ別のデータセンタに 配置する 「DB Replicationパターン」 「Multi-Datacenterパターン」
• 44. それぞれ数クリックで、 サーバーの堅牢性が増す。
• 45. さっそく開発に取り入れてみる。
• 46. AWSなら簡単にできた・・・
• 47. 目からウロコ。 忙しい時期だったが、 行って本当に良かった。 ※「AWS体験ハンズオン」で検索すると、 現在も参加可能なセミナーが見つかります
• 48. 学んだこと 忙しくてもセミナーや勉強会は継続的に行こう。 難しいと思っていたことも、 一流の人の話を聞くと 一瞬で理解できることがある。
• 49. その後、急ごしらえだった アプリも改修し、リリース。
• 50. どうにかサービスを回したが、 継続的なビジネスに育てるまでは至らず、 反省点も・・・
• 51. 「聞けばよかったこと」はたくさん 自分で解決しなくては、という責任感からついつい考え込んでしまい 結果的に聞いたほうが早かった事が多々ありました。 自分で考えることや調べることは大切ですが、 目標に最短の選択を検討するべきです。
• 52. 「聞けばよかったこと」はたくさん 自分はまだ未熟な故、回り道をしても新たな発見が沢山あり、とても 魅力的に見えてしまいます。
 
 予め期間を区切り、それを超えるような事があれば、
 予め検討した代替手段に切り替えるべきです。
• 53. 要件がコロコロ変わるのにうんざり 今回の様な小さく始める新規事業は、要件がコロコロ変わっていきま す。それは誰のせいでもなく、その都度検証するべきことに忠実にあ れば、必然的にそうなると思います。 その度に変更点が多く、うんざりすることが多々ありました。
• 54. 要件がコロコロ変わるのにうんざり しかしそのように感じる時は、プログラムを複雑に作りこんでしまっ ていたり、汎用性が低くて変更に弱い場合も多かったです。 対処法としては企画側と密に連携を取り、出来るだけ要件変更の先読 みをするべきです。そしてコードもシンプルに、綺麗に書くことで汎用 性を高める必要があると感じました。
• 55. 必要以上の実装はただの自己満足 これもやったらユーザーは楽になる、あの実装はどんなWebサイトで もやっているんだし、当然実装しよう。 最悪です。ただの自己満足です。他のタスクと優先度やインパクトを 比べずに、「∼の為になる」などと考えるのはただの自己満足です。 もっとインパクトの大きい事があれば、そちらをやるべきでした。
• 56. 学んだこと 自分がクリエイターだからこそ、 作らないことも選択肢のひとつに。
• 57. GoogleAnalytics型の ユーザー行動分析ツールを開発した時の話 2014/04 2014/07 2014/10 2015/01 2015/04 入社・配属 ユーザー行動解析ツール Livesense Analyticsの開発 社内分析基盤システム全般の開発・運用・改善 新卒研修 Paciriiの開発 Livesense Analyticsの Blog記事化
• 58. LivesenseAnalyticsとは、GoogleAnalyticsと同じ ウェブビーコン型 のアクセス解析ツール。 サイトに埋め込まれたJavaScriptが CookieにユーザーIDや訪問回数などの情報を保存した上で、 サーバー側に送信し、行動履歴を蓄積する。
• 59. 先輩の作ったプロトタイプがあったとはいえ、 実働メンバーは、自分一人。 各ウェブサイトへの埋め込み、 自社のメディアデータとの連携や、 JavaScriptからバックエンドの開発まで。 いままでで一番規模が大きい開発。
• 60. はじめてちゃんとスケジュールをひいてみた
• 61. 「先輩の作ったプロトタイプもあるし、 要件定義は3日ぐらいかな、、、」 などと余裕を持って積み上げ、 それっぽくなった 伏線
• 62. そしてプロジェクト開始
• 63. ここにスケジュールがあるじゃろ？ ( ＾ω＾) [=]
• 64. やってみると ( ＾ω＾)
• 65. こうじゃ… ( ＾ω＾) [=================]   ｼﾞｬｰﾝ
• 66. 3日のタスクに、 日かかる。 9
• 67. 77回 指摘&修正回数
• 68. やったことのない仕事だったため 「隠れたやるべきこと」を見積もりきれず、 想定外の仕事量になってしまった。
• 69. 反省。。
• 70. 「ソフトウェア見積もりの主目的は、(中略) 達成可能な程度に実現的なものかを 判断するためである。」 言い訳すると、 見積りのプロも、ちゃんとは見積もれないって言ってる(́・ω・｀) ースティーブ・マコネル、『ソフトウェア見積もりー人月の暗黙知を解き明かす』
• 71. その後、改善のため取り入れたこと: プランニングポーカー 1ポイント＝およそ半日として 複数人が「いっせーの」で同時に見積もる。 数字が離れているときは話し合って、 「隠れたやるべきこと」がないか議論。 聞きにくさを減らすため、 毎週のミーティングに組み入れる
• 72. まだうまく見積もれないが、 見積もりのブレ幅は減った。 最初の見積もりを一緒にやってもらうことで、 周りに相談もしやすくなった。
• 73. 学んだこと 工数見積もりは難しい。 周りのアドバイスをうまく取り入れ、 「隠れたやるべきこと」を見つけよう
• 74. ではなぜ、要件定義に時間がかかってしまったのか。
• 75. Livesense Analyticsの仕事は、 先輩がプロトタイプを作っていた、引き継ぎ。
• 76. 要件なんて、もう自明だと思っていた。
• 77. 先輩から引き継いだ資料を元に、 ざっくりしたドキュメントを整形。 サイトに組み込んでもらうため、 処理の流れを中心に記述。 その上で、導入してもらう ジョブセンスのエンジニアに相談。
• 78. 「そもそもまず要件を最初に明確にしましょう。このシステムで何を達 成すればいいのか、わからない。」「Howしか書いてないから、What が明確じゃないので書かれてる内容の妥当性が不透明です。」「ジョブ センスでは別のユーザー行動解析ツールいれてるけど、それでも課題の 全ては解決できないということ？」「GoogleAnalyticsのプロ版が高いっ て費用のことが書かれてるけど、君の給料がもうちょっと高かったらそっ ちでいいわけ？」「列挙されてる必要事項の粒度がばらついてて、メディ ア側でどんな協力すればいいのかわかりにくい」「取得データの利用シー ンがよくわかんないんだけど」「これシステムの可用性ってどれくらい なんですか？落ちたらメディアも巻き添えで止まっちゃうの？それだと困 るんだけど」「それじゃ、ジョブセンスに入れられません。」
• 79. 「それじゃ、ジョブセンスに入れられません。」
• 80. 「ちゃんと、考えたの？」
• 81. （そんなこと、先輩のドキュメントには書いてなかったとは言えない・・・）
• 82. 学んだこと 言われたことをやるだけでは 責任は満たされない
• 83. 77回の そして、 指摘&修正
• 84. テクニカルな部分だけではなく、 背景や課題、そして目的をまとめ、 なぜこのシステムが必要なのかを 記した。
• 85. 今回の経験では、 そのシステムが必要とされる理由を考え自分の言葉で記すことで、 コードでは表せないシステムの目的に初めて気づくことができました。 しっかりとした目的を持つことで なにが重要かを自分で判断できるようになります。 工数削減や創意工夫を凝らす際にとても有用ですし、 なにより言われたことをやるだけの「やらされ仕事」ではなくなります。 今では必ず開発前に実施するようにしています。
• 86. 学んだこと 引き継ぎ仕事であっても、 なぜやるのかを自分の言葉で明らかにして、 自分事にするべき
• 87. Google Analyticsよりも使いやすいアクセスログ サンプリング無しの生データ LAデータの1行は、ユーザーのPV単位になっています。なのでユーザー のPV、セッション単位の分析など、Google Analyticsで行っている ような分析は基本的に出来ます。 Google Analyticsと比べたLAのメリットは、サンプリングされてい ない生のデータをSQLで扱えることです。 メディアと同じ会員・案件・応募ID LAはリブセンスのメディアに最適化された分析基盤です。 Cookie上に保存された会員IDや、URLに含まれた案件・応募IDなどを 自動で取得し、アクセスログと紐付けています。 例えばとあるジョブセンスの会員が応募完了ページに行くと、LA上の レコードには応募IDと案件IDと会員IDが埋め込まれています。 そしてこの反省をふまえて、使う人目線でのドキュメントを書くように。
• 88. その後、現場のエンジニアにも コードレビューをしていただきながら どうにか無事リリース
• 89. 参考になった本： プログラミング言語 Ruby 業務と並行してインターン生を教えるのですが、 その際自分がちゃんと分かっていないと
 教えられないという使命に駆られ、読みきりました。 472ページあるのですが、
 数あるRuby本のなかでも精緻。 エンジニアとして使える技術という文脈でも、
 何回も読みなおしています。
• 90. AWSについてなんとなく知識がついたけど、
 Livesense Analyticsの設計を考える時にいくつも サービスの組み合わせが発生し、選択を迫られた 時に助かった本。 汎用性の高いパターンやベストプラクティスも載っ ているし、そこからAWS側の設計思想的な部分も 読み解ける（と思いました）。 参考になった本： Amazon Web Services クラウドデザインパターン 設計ガイド
• 91. Livesense Analyticsの成果を、 Blog記事にしましょう、と言われて 2014/04 2014/07 2014/10 2015/01 2015/04 入社・配属 ユーザー行動解析ツール Livesense Analyticsの開発 社内分析基盤システム全般の開発・運用・改善 新卒研修 Paciriiの開発 Livesense Analyticsの Blog記事化
• 92. marketing.livesense.co.jp facebook.com/LivesenseDigitalMarketing 社内で運営しているマーケティングブログ
• 93. もちろんブログ書くよね？ は、はい書きます＞＜ 得意ではないが二つ返事
• 94. 記事を書いてみた
• 95. 67 行の文章に、 箇所の修正。 62 ※文章構成を直してもらって、だいぶマシになった後半戦での話です。
• 96. 「週明け火曜」が、 2ヶ月かかるとはおもっていなかった。
• 97. 反省点は、、 うーん、、 なんか全然ダメ。 すみませんごめんなさい！ で、出直してきます＞＜
• 98. はやく終わらせたい一心での、平謝り。
• 99. 平謝りしたものの、 何をどう直したらいいんだろう・・
• 100. そして、 理由がわからないので見当違いの修正をしてしまう。 前より悪くなってる・・・。 どうしてこうなった・・・（呆 すみませんごめんなさい！ で、出直してきます＞＜ 以降、無限ループ
• 101. その場で細かく聞いて、 後で悩んで手が止まる要素をなくせばよかった。
• 102. うーん、、 なんか全然ダメ。 どこがまずいですか？ その理由はなんでですか？ ではこう直したらOK?
• 103. とにかく問題が何なのかを考えるように なった本。これを読んで、わからないと きは質問をし、まず問題を明らかにする 癖を付けました。 安宅和人『イシューからはじめよ』 参考になった本
• 104. 学んだこと こっぴどく怒られた時こそ逃げちゃダメ。 細かく理由を聞こう
• 105. 一年を振り返って
• 106. 入社当初は、今まで見てきた職人たちにへのあこがれから、 漠然といいものを作りたいという思いがありました。 しかし、初めて経験する仕事として、 難題を乗り越える為にもがく日々。 覚えることに謀殺される毎日で、 当初の思いは頭の片隅へと追いやられていきました。
• 107. そんなプロダクトも完成し運用段階になると、 未熟さ故の設計崩壊や、頻発する障害が目立つようになります。 にも関わらず利用者は増え、 止めることの出来ないシステムに。 本当にいいモノって、こんなものじゃないはず。 そんな時、新卒研修後に師匠から言われた言葉を思い出しました。
• 108. 自分の作ったものを本当に良いプロダクトにするには、 まさにこれが足りていませんでした。 それを今、周りの経験者から学び、 本当のプロを目指していきたいと考えています。 エンジニアは「ミスが許されない職種」。
 自分の慣れている技術以外の物は避けるべきであり、
 エンジニアにとって「使える技術」とは トラブルに対処出来る技術を指す。
• 109. 小林寛和(ひろかず) (株)リブセンス 基盤事業本部 - Analyticsグループ 文学部(人間科学専攻)出身 新卒2年目 Vim ギター, ダーツ