you88blog

とあるPMの開発日記

Menu Close

Month: 3月 2018

【1週間ブートキャンプ】文系職が夏休みを使ってプログラミングを覚えた話

去年の夏の話なのでかなり前だが夏休みを使ってプログラミングを覚えようと思って一週間ぐらいでプログラミングの基礎を一気に身につけられないかと勉強方法を模索した。rubyとrailsを一から勉強してどれくらい身につけられるかみたいなタイムアタックをしたくて夏休みを捧げてみた。効率性を重視したやり方を見つけられたと思うので文系職で自分でwebサービスを作ってみたいと思っている人に読んでもらいたい。ちなみにこの勉強のあと日曜大工的に毎週プログラミングしていてfirebaseとrails、vue.jsでチャット作ったり、今はtwitterで趣味友達を募集できるサービスの開発をしてたりします。

個人開発者の人とも仲良くなりたいので気軽にフォローしてください。

twitter.com/you8802

動機

僕はちなみに今までいくつかのプロダクトのディレクターやったりプロダクトマネージャーをしたりしています。現在は広告プロダクトを見ていてこういったものを作っています。

inside.pixiv.blog/yattyo/3420

もともと受託をやってたり、起業して自分でもプロダクト立ち上げたりしてて、マークアップはがっつりやってたのとwordpressやphpもエンジニアと一緒にちょっとしたものならやってたのですがちゃんと体系的に学んでいないような状態でした。それがなんで今さら勉強しようかと思ったかというと

  • 自分で小さくサービス作れたら色んなPDCAを回せるなと思った
  • ディレクション能力も上げたい
  • 単純にプログラミングに興味あった

上記の理由で一番はまあ自分でサービスまた作りたいなという興味本位。次が現在のチームが技術的な難易度が高いチームでディレクションするにあたって技術的なことを理解しないと厳しかったから。ディレクターの仕事はエンジニアの働きやすい環境を提供することも入っているので彼らが技術的なことを説明するコストをこちらが勉強することで削減できるかなと。これはプログラミング以外にも言えることだけどコミュニケーションコストは片方に同じ知識がないと飛躍的に上がる。これを説明する側がかぶることが多い。しかし、実際には説明される側の方が人数的には少ない場合のほうがおおかったりする。説明される側1人が知識を身に付けることで説明する側複数人のコストが減ることを考えるとディレクター、マネージャーが知識を身に着けて理解力を身につけるのはチーム全体でコスト効率がいい。

個人的に思う文系職のプログラミング挫折ポイント

環境構築

最初プログラミング勉強しよう!と思ったらまず環境構築をすると思うのだが死ぬほどつまらないのと面倒なのでここで大分モチベを削られる気がする。今回は環境構築をしなくてもプログラミングを始められるprogateでまず勉強をはじめて回避したのとその後、環境構築する際は同僚に助けてもらった。

全体像がわからなくなる

細かい記法にばかり目がいって結局なんの機能作っているのかよく分からなくなる。一通り書いてみたがなんでこう書いたのか分からんというのもモチベをさくし、結局身につかない。

勉強に使ったサービス・本

  • progate
  • qiita
  • dotinstall
  • パーフェクトruby
  • teratail

感動したポイント

progate

2-3年前に勉強した際と大きく違うのはprogateが有るかないかと言っていいくらい感動した。まず環境構築無しでいきなりプログラミングを勉強できる点がいいし、間違った際の指摘が本当に細かい。相当パターン別に文言用意していると思う。

qiita

qiitaがいいのが間違いを指摘し合う文化が有る所で全く知らない人から指摘が来る。しかもなんで間違えてんねんって感じではなく本当に教えるみたいなテンションで来て滅茶苦茶ユーザーがあったかい。

teratail

これも本当にびっくりしたが質問してほぼ100%当日中にいい感じの回答が来る。ツールの設定など特殊なパターンなど資料に載ってなさそうな細かいつまりに対応する際には重宝する。

勉強方法

webサービスを作るための段階

プログラミングを覚えてwebサービスを覚えるまでには下記の段階が大まかにあるのかなと考えている。それぞれ能力と身につけ方が違う。

  • 言語、フレームワークをひたすら覚える
  • 機能をどう実装したら良いか学ぶ
  • 実装段階でわからないことの調査

言語、フレームワークをひたすら覚える

まずは言語、フレームワークを覚えるために

  • progateで勉強
  • dotinstallで同じ箇所勉強
  • qiitaに全体像をまとめる
  • よう分からん所はteratailで質問

言語、フレームワークの覚え方はいろいろあると思うけど個人的には上記が一番覚えやすかった。環境構築は面倒なのでprogateで最初勉強するのがとっつきやすくていいかと。

忘却曲線と戦う

とにかく人は忘れる生き物なのでどう定着させるかが重要だと思った。でも本何回も読むのもだるいのでprogateを何周もすることに。毎日progateやって計4周ぐらいした。(公文式方式)

ただprogateは本当にさわりなのでdotinstallで補強しつつ、重要な部分はパーフェクトrubyを読んだほうがいい。

(星の横にあるのがやった回数)

木を見て森を見る

個人的に今回めっちゃ当たった勉強法はqiitaに都度都度まとめるでまとめると全体像を把握できるし、親切な人が間違い指摘してくれたりするので非常にいい。プログラミングは記法などに目が行きがちだが値をどこで入力してどこに溜めてどうやって出力するかを意識するといいかも。

機能をどう実装したら良いか学ぶ

実際に言語やフレームワークを覚えても実際に機能を開発するのは実は難しい。ログイン機能を作ろうとなったときどういう組み合わせで作れば良いのかパッとはわからない。techpitというサービスがこの作り方を教えてくれるのでおすすめ。

https://www.techpit.jp/

実装段階でわからないことの調査

実装してたらわからないことは必ずでる。開発の3−4割ぐらいは正直調査だと思う。この調査のやり方も重要で基本的には

  • 英語でもちゃんとドキュメントを読む
  • ググり力
  • teratailの活用
  • バグのモニタリング方法の勉強

あたりが重要。

やってよかったこと

やっぱりエンジニアとのコミュニケーションがより密になった気がする。ただ気をつけないといけないのが彼らの方がプロだということ。なにか彼らの決めたことに対して意見するための技術ではなく、彼らがビジネス職、文系職に説明するときのコストを減らすための技術であってやんややんや言うのはダメ。ちゃんと技術に関しての決定は彼らに委ねる。なぜなら彼らはプロだから。

もう一つは趣味ができたこと。日曜大工は材料費がかかるがwebサービスは材料費がかからない。

https://github.com/you88

この辺でチャット作ったりしている。

https://qiita.com/you88

ココにも逐一記事をあげてて非常に面白い。最近はvue.jsやAWSを頑張っている。物を作るのも楽しいし、プロダグラミング自体、パズルのようで面白い。今公開できるサービスを作り中なので自分のサービスの広げかたも研究できるようにしたい。

事業会社の開発チームの動かし方を考えてみた

受託もやって事業会社での開発もやってといろんな形態で色んなプロダクトの開発をやってきて最近色んな知見が溜まってきた気がしたのでちょっと整理してみる。開発チームを動かす上でメンバーに対してどう接するべきかなあなどなど。

全体最適をしらない者に部分最適は難しい

全体最適、つまりプロダクトをどうすべきか分からないとエンジニアも部分最適化をできない。例えばエンジニアが実装するなかでこの条件どうしようとかDBの設計をどう拡張をもたせるかなど部分部分で細かい判断が必要だがそれは全体としてどうなるかが分かっていないと判断できない。そしてそういった局所的な判断がプロダクトの質を高めていく。

この全体最適をちゃんと理解してもらうのはプロダクトマネージャーやディレクターの役割であり、責任になる。

何回言っても伝わらないは当たり前

ただそういった方針や全体の動きは何度言ってもなかなか伝わらないものだ。正直2,3回とかのレベルでも伝わらないことはあるし、すぐに忘れる。これは当たり前なんだなあと最近思うようになってきた。何回も同じテンションで説明し続けられる、プロダクトの思想を伝えることができるという精神性は意外と重要なスキルなんじゃないかなと思う。あいついつも同じこと言ってんな。しつけえぐらいがちょうどいい。

経営者マインドが!プロダクトマネージャーマインドがねえも当たり前

よくメンバーに経営者マインドが足りないとかプロダクトマネージャーのような全体感を持ってくれないと嘆く人を見るがそれは当たり前でじゃあ君はエンジニアのマインドを持っているかと聞いてみたい。別にどの職種でも言えることだが他人の職種のマインドを100%持つなんて不可能でそれは経営者やプロダクトマネージャーだけの悩みではない。また当事者意識を持とうと言っても当事者に100%なるのはできない。お互いが互いを理解するように努力するのが大切。

常に不安がちょうど良さそう

互いに100%理解するのが難しいと分かっていれば常に不安になって相手の観察を怠らないと思う。そしてマネージャー、ディレクターなどメンバーを調整する役割を持つ職種はそれぐらいの気持ちでいるのがちょうどいいんじゃないかなあと思う。自分のチームのメンバーは皆楽しく仕事をしています!とまじで言い切ってしまう人よりこいつらにちゃんと俺の考え伝わっているかな?楽しく仕事できているかなと不安で常に改善策を考えるマネージャーの方がチームに取っていいんじゃないかなと思うのです。

事業会社はどう広告を考えれば良いのか?-広告はプロダクトの一部-

プロダクトを見る人間が広告をどう考えたら良さそうか、どこまで知っていたほうが良いか、手法の選択する際に意識することなんかを個人的な偏見を存分に入れて考えてみた。なんでまとめようかと思ったかというと田端さんのこのtweetをみてホンマにそうだなと思ったからである。

僕もマーケティングは専門性が高いのにもかかわらず、日本では総合職が片手間にやることも少なくなく、ノウハウの蓄積に失敗しているところが多いなと思っている。なので逆に事業会社が最低ここは把握したほうが良いんじゃないか、こういう捉え方をしたほうが良いんじゃないかというのをまとめてみた。

広告はプロダクトの一部

広告はユーザーにプロダクトが接する最初の面なのでこことプロダクトは一貫した体験になるように設計しないといけない。ユーザーは

広告

(LP)

プロダクト

(購入や課金などのCV)

の順で体験するが広告で付いたイメージが一致していないと最後まで到達しない可能性が高い。どんなユーザーを連れてくるか?どんなイメージをもたせるかはユーザー体験の一部である。

自社にノウハウは溜まっているのか?

決して代理店を否定するわけではないが日本の事業会社では広告を代理店にまかせ過ぎな事業者が多いように感じる。上記のようにユーザー体験に大きく影響をあたえるところなのでユーザー体験を向上させるなら広告もその一部として見直していかないといけないし、ノウハウを溜めないといけない。代理店などは広告手法のプロではあるがサービスのユーザー体験などは事業会社側が把握しているべきだ。どんなクリエイティブでどうイメージさせるかをちゃんとコントロールしているか考え直してみるといいかもしれない。

プロダクトマネージャーが把握したほうがいいと思う広告手法の分類

プロダクトマネージャー(事業会社側)が最低限下記を把握して代理店と一緒に広告手法を話せると良さそうというのをまとめてみた。ちなみに分類は個人的に勝手にやったもので一般的なものではない。

pull型とpush型

pull型
SEOなどユーザーを待ってとってくる手法。ユーザーの行動の先においておくものなので基本的にはニーズが顕在化されているユーザーで継続率は高い。

push型
twitterなどユーザーにこちらからpushでプロダクトを押していくのがpush型。潜在的にニーズがあるであろうユーザーを見極めるのが大切。

具体的な広告手法

pull型

  • SEO
  • ASO
  • リスティング
    • 検索結果に広告出すやつ。検索キーワードでセグメントができ、ユーザーの層ではなく、ユーザーのニーズでセグメントできる。ぶっちゃけかなりユーザーのニーズが顕在化されているのでかなり優秀。

push型

  • UAC
  • twitter
  • facebook
    • push型は潜在的にニーズを持っているだろうユーザーをデモグラや背景で読まないといけないがfacebookはそのデモグラが最も正確な媒体と言って良い。push型において最強だと思う。

© 2019 you88blog. All rights reserved.

Theme by Anders Norén.