プロダクトマネジャーが行う市場調査と製品設計について
ここ最近、弊社に新たにプロダクトマネジャー（以下PM）がJOINしたことで自分の仕事に余裕がで出てきて、考えながら仕事ができるようになりつつある。
PMの仕事の仕方として、既にある数字とこれまでの経験から解を見つけ出すのはそれほど難しくない。しかしPMの仕事には、市場に対して新しい商品の見せ方を考えたり、ポジショニングを考えながら製品を設計したりする必要があったりする。オペレーションが多いとそういったことについて深く考えることができないこともあるので、新しいPMのJOINは負荷分散や、一緒に考えることができるという意味で大変ありがたい。
Basicな市場調査
PMの行う市場調査としてまずは私の市場調査方法について書いてみる。「私の」と言っているのは、市場調査は会社によってはPMの仕事でないこともあるだろうし、PMの仕事であったとしてもやる人によってやり方が異なったりするだろうと考えているのであえてそう書いている。
市場調査初心者の私としては、まずはメジャーな分析手法「3C」で考えてみたりしている。
別にフレームワークで考える必要はないのだが、Salesと共通認識として考えられる分析手法を用いることでなぜその分類方法を採用しているかの説明が省けるというのと、ある考えを様々な確度から整理できるのは利点と考えている。
市場に関するinputをいかに増やすか
フレームワークを使って情報を整理するにしても、整理すべき情報がなければ何もできない。まずは情報（可能な限り一次ソース）を集める必要がある。ネットで検索して出てくる情報に価値のある情報はそれほど多くはない。もちろん公開されている情報から次のプロダクトへのヒントを見つけ出せることもあるかもしれない。しかし実際にはどこの会社も（当たり前だけど）競争力の源泉となる情報を公開していない。
そんな中でいかに情報を見つけ出すかと考えた時、私はまず人に会いに行くようにしている。自社内、同業者、競合問わず、とにかく人に会って話すということをしている。その中で競合の情報、業界のトレンド、自社内のプロダクトに対するSalesの認識などをinputしていき、時にはその中で他社・パートナーのプロダクトの技術検証を行い、それらと自社製品が連携することが可能かどうか、連携するとした場合どういった製品設計をして商品化していくのかを考えるよにしている。
※ここで言う製品設計とは、プロダクトに実装する機能・サービスのこと。実装上の設計の話ではない。
製品設計は誰がすべきか
ここまで来るともはや市場調査の域を超えて技術検証まで行っているわけだけど、弊社FreakOutでは私の在籍している過去2年の間、PMメンバーはわりとこうして新製品の設計を行ってきている。
PMが市場調査から製品設計まで一気にやることの利点は、市場状況に合わせた製品のアイデアをベースに設計まで一気に行えることで、エンジニアに開発を依頼しやすくなるという点があると思っている。製品化するかどうかも明確ではない技術検証をエンジニアにやってもらうのは余程のスモールチームかスタートアップでないと必ずチームから不満が出るもの。うまくいけばエンジニアは最大限の評価がもらえるが、そうならないことも多く、責任の一旦をエンジニアに担わせることになってしまう。
またケースバイケースではあるが、エンジニアにとってのスキルアップに繋がらない場合もある。そう考えると、製品設計はPMがやった方が作るべきものを明確にできるし、何より市場状況に即した製品を設計できるのではないかと考えている。
前職時代にエンジニアも製品設計に関わっていこう、という動きを開発チームとしてしたことがあるが、多分、Salesサイドからするとナンセンスにうつっていたことだろうと想像する。それはエンジニアがダメなのではなく、視点が違うの一言に尽きるのではないかと思っている。エンジニアはシステムの全てを把握しているので、どう拡張すれば自分たちの製品が成長しそうか考える。一方で、Salesサイドはクライアントがこう言ってるんだからこういう機能を作らないと売れないと言うわけだ。
PMがすべきことは、この両方の意見を聞いた上で、エンジニアの言う今のシステムを理解し、Salesの言う顧客要望を理解し、ハイブリッドな、時に角度の違うプロダクトを作ること。よくある話ではあるが、必要なのは「速い馬」ではなく「自動車」だということだ。ここを整理することこそがPMに最も求められているのではないかと思っている。
FYI: dqn.sakusakutto.jp
それを導き出すためにもPMは市場調査から製品設計まで一気にやる必要があるのではないか、と最近考えています。
PMスキルを身につけるための試行錯誤とその結果について
今年もこの季節がやってまいりました。Qiitaアドベントカレンダーです。 一年にこの時しかブログ更新できていませんが、毎年の振り返りとして続けていければなと思っています。
今年はPM業を始めてから２年目になりました。PM１年目の昨年は、PMとは何をする人か、弊社FreakOutにおいての役割とは何か、それを考えながら走り続けた一年でした。 昨年はすべてが初めてで自分の役割を整理することも十分にできていなかったように思います。今年は、自分自身PM業について向き合うという準備ができている状態でやってきたので、改めて自分が定義した課題とその結果について書いていきたいと思います。
PMとしての課題感
PM１年目のときは主に取引先ベンダー・クライアント様と弊社エンジニアの間に立って仕様調整、結合テストサポート、仕様ドキュメントの整理を中心に行っていました。それはそれで問題なく仕事できていたのですが、下記について課題感を感じてもいました。
- 売上へ貢献する機能改善
- コミュニケーション力、プレゼン力
- 新製品を提案し実現する
売上へ貢献する機能改善
課題1. については新製品開発プロジェクトだったので簡単に結果が出ないのはわかってはいました。しかし自分はPMであるにも関わらず、恥ずかしながら売上やKPIも十分に見れていないような状態でした。
その頃の自分はエンジニアのフロントとして社内外のエンジニアとのコミュニケーションが仕事の中心だったので、作った製品がどのように使われているかについてあまり考えられていない状態でした。そこで上司と相談して「より多くの営業と関わる」という目標を設定しました。なぜなら営業は売上の責任を追っていて、KPIも当然把握している。さらに顧客に最も近いところにいて、製品の改善要望も当然彼らから上がってくる。営業からの改善要望のすべてが汎用的な仕様にできるものではありませんが、彼らとのコミュニケーションから新しい製品や機能に関するヒントをもらえることを期待してのことでした。 とは言え営業との関係値がほぼ無い中、営業側から声がかかることを待っていても永遠にその機会が訪れないことはわかっていたので、数少ない親しい営業に営業組織のキーマンを紹介してもらい、一緒にランチに行くところから始めたりしていました。
その後、自分が担当した新製品について社内での問い合わせ窓口を自分にしてもらって、営業からの問い合わせがほぼすべて自分に向くようにしてもらい、積極的に営業とコミュニケーションを取るようにしました。今年はエンジニアとの仕事の時間よりも営業との仕事の時間の方が圧倒的に多かったと思います。
営業の追っている売上目標を一緒に追い、日々一緒になってKPIをウォッチして製品に問題ないか確認し続けているうちに数字に対する理解や意識が深まるようになりました。また当初の目論見どおり、営業から様々な製品改善のヒントや他社製品情報の収集も行えたことで、製品にフィードバックが行えるようになりました。それもあってか、担当していた製品は（様々な要因はあるものの）結果的に大成功し自分の人生でもかつてないほど売れました。
コミュニケーション力、プレゼン力
他人と話す能力はPMにとってあらゆるところで役にたってきます。社内外の多くの人に会って製品説明をする機会の多いPM職において、コミュニケーションが苦手というのは圧倒的に不利だと思っています。
自分は製品説明をクライアントにする際は特に問題なく話せていたかと思うのですが、例えばイベントでのネットワーキングタイムなど、自分から能動的にコミュニケーションをしていかないと何も成果を上げられないような場面において、うまく話せないこともあり課題に感じていました。また自分で資料を用意してそれについて説明するプレゼン能力、これについてもこれまでの場数が足りていないという認識がありました。
ただこの課題については、もうとにかく場数を踏むしかないと思っていて、今年は話す場、プレゼンする機会を自分から作っていくということをやりました。具体的には勉強会でのネットワーキングタイムで「名刺を○枚集める」など事前に目標を定義し毎回必ずその目標を達成するようにしました。またLTの機会のある勉強会では発表の機会をもらって話したりもしました。これをやったことで、コミュニケーションに対して物怖じしなくなり、かつ多くの取引先やクライアントと話したことでその後の仕事が格段に進めやすくなりました。
余談ですが、弊社FreakOutはSlackを使ったコミュニケーションが営業含め社内で浸透していて、対面コミュニケーションがなくても仕事が回るような体制ができています。ですが、自分は対面コミュニケーションの方が、細かい事情や自分の感情含めより多くの情報を伝えることができると思っているので、直接会って話すということを大事にしています。もちろんエンジニアに声をかける際は、彼らの集中力を乱さないように頻度とタイミングに気をつけていますが、100%チャットツールに頼りすぎないように気をつけています。
新製品を提案し実現する
これについては現在も模索しつづけているところです。製品の提案は、自分は次の項目が理解できていないとまともな提案はできないと思っています。
- 数字から導き出せること（市場調査、自社のログ、KPI）
- 数字が出せないと説得力がない。
- 業界のトレンドと競合他社の売上状況
- 市場がないのに製品を作っても売れない。
- その業界のサービス・商品・製品への深い理解。
- 浅い知識では浅い提案しかできない（既に実現されているかもしれないか、的外れになりがち）
今はできることとして、ログをサマってデータを見て、KPI進捗を確認し、営業から業界トレンド・他社情報をヒアリングして、業界の情報収集もしていくというところを地道に続けているというところです。
今年は去年に比べるとだいぶ自分の課題が浮き彫りになり、しかし地道に課題に向き合ってやってきた一年だったと思います。少しずつではありますが、もっと良い製品を世の中に出していけるように日々精進したいと思っています。
エンジニアからPO、PMと転身してきた一年の振り返り
エンジニアからPO、PMへ
自分がエンジニアからプロダクトオーナー（以下PO）、プロダクトマネージャー（以下PM）と転身してきた一年の振り返りを書いてみます。POをやっていたのは前職時代の3ヶ月。その後は現在の会社でPMとして働いています。
昨年11月中頃、自分はエンジニアリーダーからPO（正式な肩書はプロデューサー）に転身しました。それまでのキャリアを変えてエンジニア職から転身したのには色々な思いがありました。自分はこれまで、良いプロダクトを生み出せるのは技術からだけと信じていました。
転機となったのは、夜間と土日に通っていた産業技術大学院大学で単位を埋めるためだけに受講した「サービスサイエンス」という科目でした。そこではビジネスになるサービス・プロダクトをどう定義すれば良いかを学びました。大学院にはもともと情報工学やその周辺の知識を埋めるために通っていたのですが、一気にビジネスにも興味が湧くようになりました。そんな折、現在の会社に誘ってくれた前々職の先輩からPMという職があることを教えてもらい、Inspiredという書籍を紹介されました。www.amazon.co.jp
それから自分はPMという働き方自体に興味を持つようになり、日々PMになるために必要なことを技術そっちのけで学ぶようになりました。その後社内転職を果たしてPOになり、最終的には自分がPMとして働ける環境はないかと思うようになり、PMとして明確にポジションのある現在の会社に転職したのでした。
PO時代
POになった時に最初にやっていたことは、それまでの開発リーダーの延長で、主にプロジェクトマネージャーとして仕事をしていました。それ以外ではヘルプデスクのサポート、事業部（仕様は基本的にここが全てROIを出して決めていた）の提案や開発タスクをドキュメントに落としてエンジニアに展開するなどしていました。エンジニア時代にも当然部署のKPIは存在していて、自分たちもある程度意識はしていたのですが、それほど数字については理解していませんでした。
扱っていたKPIは、当時の部署は広告系でしたので、CTR（インプレッションあたりのクリック割合）と広告を通してどれだけ商品が売れたかを示す広告経由流通総額が主なKPIでした。それらの数字については大まかな理解はしていたものの、CTR一つとってもプロダクトごとの細かな数字が頭に入っておらず、自分たちの作っている主要プロダクトのCTRや広告経由流通総額、加えてそこにどれだけのコストをかけてどのように運用（システム運用ではなく広告運用）されているか、市場競争力はどの程度なのかなどについて正しい理解がありませんでした。この点については改めて思い知らされて本当に衝撃を受けました。エンジニア時代もある程度理解していると思っていたKPIを自分が正しく理解しておらず、またプロダクトの改善にどのような数字が必要で、どうすれば数字が上がるのか下がるのか、何を持ってその数字の良し悪しを評価するのかが見えていなかったのです。これにはとにかく日々数字を見てそこから自分なりの考察をするということを繰り返すことをしていましたが、それは現在も続けていたりします。
また数字の話とは別に、この頃思っていたのが、エンジニアとPOの業務内容の違いでした。エンジニアはコードと向き合う時間が多い仕事だと思っています。しかしPOは開発プロジェクト全体の状況や日々の数字のチェック、上司への報告、営業とのコミュニケーションなど、エンジニアがコードと向き合うのとは逆に、コード以外の全てと向き合う仕事であると感じました。そこにはコードの外の大海原のような世界があるのだと感じました。（もちろんコードという大海原が存在することも認識していますが）
そんな具合に始めたPO業ですが、しばらくして当時のPOの役割や責任範囲について、自分が目指していたPMとは大きくかけ離れているように感じ始めました。前述の通り、事業部が決めた仕様を開発に落とし、プロジェクトマネジメントをし、ヘルプデスクサポートをする。それが必要な仕事なのは理解していたのですが、プロダクトをマネジメントをしているということではなく、開発チームやその周辺のマネジメントに終始していると感じていました。もちろん自分の力不足や理解不足もあったと認識しています。さらに、プロダクトについて考える際、エンジニアだった自分はどうしても、どう作るか（How）から考えてしまい、なぜそれが必要なのか（Why）を考えきれていなかったと思います。また、日々数字を追っている専任の担当者が多数いる中に、エンジニア上がりの自分が入っていくことの困難さも感じていました。
これらはもちろん自分の能力や知識のなさに起因することではあったのですが、組織的にもエンジニアに近い人がPMとして責任を持って役割を果たすという組織構造にはなっていないように感じていました。そんな折、現在の会社でPMとして働いていた先輩から誘われ、未経験ながら専任のPMとして働き始めるのでした。
PM時代
入社前から言われていたのですが、現在の会社のPM職はエンジニア出身者で構成されています。そして自分たちが決めたことがプロダクトに反映されていくのです。なぜそうしているかという点を考えてみると、まずプロダクトが技術的に非常に複雑だということが挙げられると思います。また、弊社はエンジニアが中途入社するのに高いハードルを設けているため、PMはそんなレベルの高いエンジニアたちとコミュニケーションが取れる人であることが望まれているからだと考えています。正直自分は今だにビジネスの話よりも技術の話の方が分かります。
そういった技術に対する理解が求められる一方で、お客様や取引先担当者様との対話も非常に重要な仕事となっています。エンジニア時代はお客様先に出向くこともほぼなかったのですが、現在のPM職になってからは、お客様先や取引先に営業と一緒に出向いて、弊社プロダクトの説明をする機会ができました。これまで接することがほとんどなかったコードの外側の声を聴く機会が増えたのです。また、自社内においても、営業や経営企画の方たちと一緒にプロダクトの方向性、プロダクトを伸ばす方法、どうすれば利益に繋がるか、短期的な施策になっていないかなどを議論しています。そしてその結果から開発計画を立て、実行し、結果を検証していく、所謂PDCAを回すというようなことをしながら日々プロダクトを成長させる方策について考えたりもしています。
こうした技術、ビジネス両面の知識や考え方が求められるPM職に就いて思うのは、自分たちはそれこそ必要であればあらゆることをやらなければならないということ。エンジニアは作り、営業は売る。PMはそれ以外全部だと思っています。ただし、会社の利益を考えて、やるべきではないことは断固やらないと決めること。これが重要なのだろうと思っています。
先月行われたPOStudy祭りで、どなたかの発表で「PMが倒れたらプロダクトは世に出ない。だからストレスをうまく処理し、自分を守る必要がある」とおっしゃっていましたが、それは非常に正しいと思いました。それだけ重い立場だと考えて、日々しっかり仕事をしつつも根を詰め過ぎないよう、自分なりに最もパフォーマンスを出し続けられる方法を模索しながら今後もPMとしてやっていきたいと思っています。
iOSでグラフ表示
iOS始めました
このところ、仕事でメインの広告関連システム開発のディレクションとは別に、iOS開発でのディレクションも行っている。プライベートでも、週末に通っている大学院でiOSアプリの開発をしていて、大分iOSに浸かった日々を送っている。
今回はその中でグラフを表示するiOSのライブラリを使ってみたので備忘録として残しておく。
BEMSimpleLineGraph
使ったのはこれ。github.com
グラフ表示に使えるライブラリはいくつかあったものの、開発がアクティブで手軽に使えそうなものという観点でこれを選んだ。
今からどうせやるならSwiftということで、以下を参考にしながら使ってみた。d.hatena.ne.jp
また下記を参考に、cocoapodsからライブラリをインストールできるようにした。
CocoaPodsを使う | e.lab
まずはプロジェクトディレクトリのトップにPodfileを作成し、pod install実行。
$ cat Podfile pod 'BEMSimpleLineGraph' $ pod install Updating local specs repositories Analyzing dependencies Downloading dependencies Installing BEMSimpleLineGraph (4.1) Generating Pods project Integrating client project Sending stats Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.
cocoapodsでインストールしたライブラリを使うには
$ open <APP名>.xcworkspace
BEMSimpleLineGraphはObjective−Cのライブラリなので、Swiftで使う場合は連携させるためのファイル（<APP名>-Bridging-Header.h）を作成する必要がある。
最近自分が作っている万歩計アプリ（QuestWalk）でいうとこんな感じ。
QuestWalk-Bridging-Header.hという名前でヘッダファイルを作成し、BEMSimpleLineGraphView.hのimport文を記載する。
プロジェクトのBuildSettingsを開いてSwift Compiler - Code GenerationのObjective-C Bridging HeaderにBridging Headerのパスを記載。
これで使う準備は整った。
自分の場合は、CMPedometerで一週間分の歩数データを取得して、それをグラフに書き出すというのをやってみた。実装はViewControllerに下記のようにした。（一週間分の歩数データが取得できない場合は、画面に"No Data"と表示される。BEMSimpleLineGraphの仕様？）
// // QWStatusGraphViewController.swift // QuestWalk // // Created by Johnny on 11/1/15. // Copyright © 2015 SBR2015. All rights reserved. // import UIKit import Foundation import CoreMotion // BEMSimpleLineGraphDelegateとBEMSimpleLineGraphDataSourceの2つのプロトコルを追加 class QWStatusGraphViewController: UIViewController, BEMSimpleLineGraphDelegate, BEMSimpleLineGraphDataSource { // メンバー変数でないと動作しないので注意 let pedometer = CMPedometer() var weekList:Array<Float>! required init(coder aDecoder: NSCoder) { super.init(coder: aDecoder)! setup() } override init(nibName nibNameOrNil: String!, bundle nibBundleOrNil: NSBundle!) { super.init(nibName: nil, bundle: nil) setup() } convenience init() { self.init(nibName: nil, bundle: nil) } func setup() { // init の中身 getWeekData() } override func viewDidLoad() { super.viewDidLoad() // 描画の方が早いのでタイマーで遅延させる NSTimer.scheduledTimerWithTimeInterval(1, target: self, selector: "onUpdate:", userInfo: nil, repeats: false) } func onUpdate(timer:NSTimer) { // グラフのViewを作成（今回はメインビューと同じ大きさのビューを作ります） let graphView: BEMSimpleLineGraphView = BEMSimpleLineGraphView(frame: CGRectMake(0, 50, self.view.bounds.width, (self.view.bounds.height - 50))) // データソースを設定 (今回はこのクラスの中にメソッドを書くので、selfを設定) graphView.dataSource = self // delegateを設定 (今回はこのクラスの中にメソッドを書くので、selfを設定) graphView.delegate = self graphView.enableTouchReport = true graphView.enablePopUpReport = true graphView.enableYAxisLabel = true graphView.enableXAxisLabel = true graphView.enableReferenceAxisFrame = true graphView.enableReferenceXAxisLines = true graphView.enableReferenceYAxisLines = true graphView.enableBezierCurve = false graphView.widthLine = 2 graphView.colorLine = UIColor.orangeColor() graphView.colorTop = UIColor.whiteColor() graphView.colorBottom = UIColor.whiteColor() // メインビューにグラフのViewを追加 self.view.addSubview(graphView) } // Y軸の値を返すメソッドを作成 func lineGraph(graph: BEMSimpleLineGraphView, valueForPointAtIndex index: NSInteger) -> CGFloat { //何個目のX軸のポイントかはindexで取得できるので、今回はSampleData配列の中にあるindexの要素をそのまま返します return CGFloat(self.weekList[index]) } func numberOfPointsInLineGraph(graph: BEMSimpleLineGraphView) -> NSInteger { return self.weekList.count } func getWeekData() { weekList = Array<Float>() for i in 0...6 { // CMPedometerが利用できるか確認 if CMPedometer.isStepCountingAvailable() { // 今日の0時 let df = NSDateFormatter() df.locale = NSLocale(localeIdentifier: "ja_JP") df.dateFormat = "yyyy/MM/dd 00:00:00" let fromDate = df.dateFromString(df.stringFromDate(NSDate(timeIntervalSinceNow: Double(-24*60*60*(i+1))))) print("###from date### " + df.stringFromDate(NSDate(timeIntervalSinceNow: Double(-24*60*60*(i+1))))) // 現在時刻 let toDate = df.dateFromString(df.stringFromDate(NSDate(timeIntervalSinceNow: Double(-24*60*60*i)))) print("###to date### " + df.stringFromDate(NSDate(timeIntervalSinceNow: Double(-24*60*60*i)))) // 本日の成果 pedometer.queryPedometerDataFromDate(fromDate!, toDate: toDate!, withHandler: { [unowned self] data, error in dispatch_sync(dispatch_get_main_queue(), { if error != nil { print("エラー : \(error)") } else { //let lengthFormatter = NSLengthFormatter() // 歩数 let steps = data!.numberOfSteps // 距離 //let distance = data!.distance!.doubleValue print("Steps: \(steps)") // + "\n\nDistance : \(lengthFormatter.stringFromMeters(distance))" self.weekList.insert(steps.floatValue, atIndex: 0) } }) }) } else { print("Cannot use CMPedometer") } } } override func didReceiveMemoryWarning() { super.didReceiveMemoryWarning() // Dispose of any resources that can be recreated. } /* // MARK: - Navigation // In a storyboard-based application, you will often want to do a little preparation before navigation override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) { // Get the new view controller using segue.destinationViewController. // Pass the selected object to the new view controller. } */ }
結果は下記の通り。
一点、参考にしたサイトの下記の実装（X軸のラベル表示）は自分が試した際には動かなかった。よく調べきれてないが、Objective-CのライブラリをSwiftから全く同じように使うことはできないのかもしれない。
// X軸のラベルを返すメソッドを作成 func lineGraph(graph: BEMSimpleLineGraphView, labelOnXAxisForIndex index: NSInteger) -> NSString { //何個目のX軸のポイントかはindexで取得できるので、今回はSampleLabel配列の中にあるindexの要素をそのまま返します return NSString(string: SampleLabel[index]) }
また今回の実装ではCMPedometerから歩数を抽出している間に、先にViewにグラフが描画されてしまいデータが渡らない現象が起きていた。デバッグしたところ、dispatch_sync内で歩数データを配列に入れる処理がViewの描画の後になってしまっているようだった。苦肉の策としてviewDidLoadメソッド内でタイマーを設定して、Viewにグラフを描画するのを遅らせることで対応したが、もっと良い方法があるような気がしている。
この辺の同期・非同期処理の順番やiOSのライフサイクルなどは引き続き調べてみたいと思いました。
プロダクトマネージャーと健康
この二週間近くよくわからない病気（副鼻腔炎）に悩まされていた。高熱と頭痛、鼻水。症状が治まってもなかなか完治はせず、大きく仕事のパフォーマンスを落とすこととなってしまった。
今回、病気で戦線離脱を余儀なくされたことで、新しい開発プロジェクトのスタートダッシュにも影響してしまった。自分が見ていた既存のプロジェクトも同様だ。
これは何もプロダクトマネージャーに限ったことではないのだろうが、健康の維持や睡眠、ストレスのコントロールは重要だ。ことプロダクトマネージャーにおいては、プロジェクトを進め顧客をサポートする立場上、基本的に長いこと開発現場や顧客の前から消えて良いポジションではない。幸い今回は周囲の助けもあり休むことができたが、改めて今後は健康の維持というところはしっかりと意識していきたいと思った。具体的には、風邪の予防や日頃の運動、疲労やストレスのコントロール、そういったことを意識的にやっていきたい。
しかし考えてみると、プロダクトマネージャーはその仕事の性質上、心身ともに健康で強くなければつとまらないなと思った。これはプロダクトマネージャーが持つべきスキルの一つ、というには言い過ぎかもしれないが、製品について全ての責任を負う以上、意識しておかないといけないことなのかなと思った。
最近やってることなど
某大手ECサイト運営会社から広告ベンチャーに移ってきて半年。仕事では色々と縁あって、自社の広告製品とそれに関連するモバイルアプリSDKの開発ディレクションをさせていただいている。
また、主に土曜に通っている大学院でもアプリ開発をやることになり、Swiftとか触り始めてる。仕事とプライベートがアプリで繋がってきていて、コード読んだり書いたりしてたらエンジニアとしての血が騒いできた。それに実機でできるアプリ開発は作ってる感があって面白い。もちろん、バージョンごとに対応しないといけなかったりしんどい部分もあるけど、大学院卒業したら本格的にアプリ作るのやりたいかもとか思ったりもしている。もっとも、広告の仕事は面白いので転職する気も無いけど。ただアプリ方向に強くなっておきたいとは思っている。
YAPC::Asia 2014 に行ってきました。
YAPC::Asia 2014 に行ってきました。
自分にとって初めてのYAPCでしたが想像以上に楽しめました。
自分はこれまで、JavaとPHP、JavaScript、ActionScript3.0で主に仕事をしてきた人間で、あと趣味でRubyとC、学校でPythonをやってきたのですが、正直言ってPerlはそれほど積極的に使ってきませんでした。
Perlは、仕事でバッチ処理などを書くことはありましたが、オブジェクト指向で設計・開発するなどはここ一年くらいでようやくやり始めた程度のレベルです。
そんなレベルで、巷ではPerlオワコン説なんかもささやかれたりとかして、正直このままPerlに投資するのって正しい選択と言えるのだろうか、とか思っていました。ただ一方で、Perlの書きやすさや自由度がいつしか好きになり始めている自分もいて、今回初めてのYAPCへの参加を決めたのでした。
実際参加してみて思ったのは、とにかく楽しくなるようなしかけが満載でした。無料のコーヒーにかき氷、Hubで1000杯までアルコール提供などお金を払ってでも参加する価値のある内容でした。
しかしそれ以上に感じたのは、YAPCに集まった方々、Speakerの方々のお話を聞いていて、この素晴らしいハッカーの皆さんの輪の中に入りたい！ということでした。（キーノートで村瀬さんも同じようなこと言ってましたね）
また、Perlのイベントなのに他言語の発表があったり、Best Talk Awards がPHPの話だったり、とにかくイベントの懐の深さを感じました。
そして一番印象に残ったのは、@songmuさんの発表でした。
発表の中で@songmuさんは、"Perlはまだまだ戦える「それがぼくには楽しかったから」でいい" という趣旨の発言をされていて、改めて、それで良いんだ！と思えました。
さらに
- 大人の恋愛をしている
- 他者をDisるのはまだ成熟していない証
- 自分の嫁最高。
- 他人の嫁もきっとその人にとっては素晴らしいのでしょう。という境地
ということも言われていて、こんなにもPerlに深い思いをもっていながら、他の言語にも寛容であるというこの思想が本当に素晴らしいと思いました。
改めて、Perlを堂々好きなように好きなだけ続けていけば良いのだな、と思えました。決してモダンな言語とは言えないPerlですが、無いものは自分たちで作っていく、その発想で今後もPerlを楽しんでいきたいと思えました。