Hatena::ブログ(Diary)

naoyaのはてなダイアリー

July 25, 2017

A さんの件について

以下、A さんとします。

A さんとは 2015年終わりくらいから徐々に、本格的な交際関係に発展していきました。それまでも A さんとは体の関係はありましたが、都度の関係性で、まだ交際関係にはありませんでした。当時 A さんが何度かプライベートのことで落ち込み、死にたいということも含めて私に相談することがあり、それをケアするようになってから関係が深くなっていったように思います。彼女は非常に知性的で、私の仕事の話もよく理解してくれることに魅力を感じていました。

しかし既婚者であり離婚は考えてはいなかった私は、彼女の人生に責任を取ることができないとわかっていました。それにも関わらず関係を深めてしまったことが、最終的に A さんを大きく傷つける結果を招きました。本当に申し訳ないことをしました。

私は A さんに好意を持っていたものの離婚は考えていなかったため、A さんから自分たちの関係は何なのかを質問されるようになっても、よくはぐらかしていました。2016年 2月頃、その私の態度に悲しんだ A さんがリストカットを行ったため、私は慌てて、私たちは交際関係にあると伝えました。自分が精神面で支えてあげなければいけない、そう思って交際することにしました。今思えば、この頃自分がそれ以上踏み込むことをしなければ、A さんをここまで傷つけることにはならなかったのではないかと思います。

婚姻関係にありながら A さんと交際する中、私は A さんにお酒の席や LINE などで、家庭の悩みや愚痴を打ち明ける機会が増えました。その愚痴には誇張も多数含まれています。今回 A さんが書かれたブログには、その打ち明け話を元にした妻の姿も記載されていますが、それらは実際の妻とは異なります。私は、私が原因でうまくいってない家庭の悩みを妻のせいにして、それを A さんに伝えてしまっていました。その話が膨らんで、妻の虚像の元になってしまっています。妻はクレジットカードのブラックリストにも入っていませんし、浪費癖もありません。自分で働いてコツコツと貯めたお金を開業資金に、最近起業したばかりです。私の放言が A さんに妻を悪く思わせてしまっただけでなく、起業したばかりの妻のパブリックイメージも大きく傷つけることになってしまいました。自分自身の失敗をきちんと見つめることができず他責にしてしまう、私の人間としての未熟さが出てしまったと思います。

A さんと私が以前から体の関係があったことは先に記したとおりです。当初は A さんも私も双方で避妊をしていました。そのうち、Aさんが避妊しているので私の方は避妊をせずに性交渉をするようになりました。A さんはちょうど私と関係が深まったころに、Aさんの避妊を止めました。私はそれを知りながら、かつ妊娠の可能性もわかっていながら避妊なしでの性交渉に及びました。何度か避妊をしたいと A さんに伝えたこともあったのですが、日頃 A さんの申し出を否定すると A さんがリストカットに走ったり、ネットに私のことを公にすると迫ることがあり、それが怖かったこともあって結局は避妊せずに性交渉を続けてしまいまいした。

2016年9月ころ、A さんは妊娠して中絶をしました。この妊娠と中絶の事実を私はその後もしばらく知りませんでした。A さんは私を制裁するためにブログを以前から用意していて、喧嘩になるとそのブログを公開すると私に迫るようになっていたのですが、後の 2016 年12月に、会食で私が A さんの LINE に応答せずにいたことで私がいなくなると恐怖した A さんがブログを公開しました。それを読んだことで妊娠と中絶のことも知りました。本当にブログを公開されたことは怖かったですが、それ以上に、妊娠と中絶のことにとても驚き、後悔の念でいっぱいになりました。A さんに謝罪をし、二度と同じことを起こしてはならないと考えそれからしばらくは、性交渉をもつことをやめ、A さんと会う際はお茶や食事のみに留めるようにしました。

しばらくして、再び A さんと性交渉に及ぶ機会になった際、私は避妊したい意思を申し出ました。しかし A さんは、再び子供を妊娠して次は中絶せずに生むことを決心していたため喧嘩になりました。このとき妥協案として、せめていつまでか時期を決めてほしいと問われたので、私は A さんが就職する 4月までは少なくとも避妊しようと打診しました。この会話が A さんにとっては 4月になったらまた子供を作ろうと約束した、という認識になったようです。約束できないなら約束できないで、はっきり NO と述べれば良かったものを、ここでもまた相手の反応を恐れて曖昧な返事をしてしまう私の悪い癖が出てしまいました。

この当時には、私は A さんとの関係を今後どうしていくか悩んでいました。A さんのことを支えたい気持ちはありつつ、離婚することは考えていない。その中途半端な態度が A さんを傷つけ、A さんに私を制裁したいという感情を抱かせて喧嘩になってしまう。これの繰り返しでした。

やや話は前後しますが同じ頃、2016年10月に、私と A さんが外で会っているところを盗撮した数十枚の写真が妻の元に届きました。その送付先は、すでに退職済みであった妻の元職場でした。元同僚が中身をみて驚き妻に転送したようでした。妻は狼狽していました。予想外のこと驚き、怖くなった私は、この件をきっかけに区の相談所などに相談をはじめました。その勧めで、警察に相談することになりました。

警察では、A さんとの関係解消をするに伴う制裁が怖いなら、警察に彼女を連れてきてその場で警察官立ち会いのもと話をすれば良い、とアドバイスされました。これが後に、私が彼女を警察に連れて行く動機になりました。

A さんをすぐに警察につれて行かなかったのは、私の中でも本当にそれをしていいのかと、ずっと躊躇があったからです。被害届を私が出すことで、警察は警告を含め動くことができると言われましたが、それをしたときに何が起こるか想像すると怖くて、すぐには決心できませんでした。結果、警察に相談したにもかかわらず軟着陸できないものかと、ずるずると関係を続けました。

2016年の年末には、A さんから指輪を買ってほしいとせがまれました。それまで A さんには、生活費と称してほぼ毎月、いくばくかのお金を渡していました。12月はそのお金はいらないから、それを指輪に回してほしいとお願いされました。このとき買った指輪を、A さんは婚約指輪だと認識したようでした。これは最近、初めて知ったことでした。離婚はしないことは何度も伝えていたつもりでしたが、やはり日頃の私の曖昧な態度が、A さんにそう誤解させてしまったのだと思います。

2017年1月頃になると、A さんとの会話はよくトラブルになることが多くなりました。それでもなお、私は自分の意思をはっきりと A さんに伝えることができず、A さんはそれに傷つき関係性は悪化していました。そのうち A さんは私だけでなく妻にも関心を持つようになり、妻を殺害するなどの発言をするようになってしまいました。

状況を危惧して、私と A さんはふたりでカウンセリングを受けることにしました。カウンセラーは A さんが探してくれました。カウンセラーの先生に出会ったことで、非常に安堵して、1 on 1 のカウンセリングで号泣してしまったのを今でもよく思い出します。

しかし、このカウンセリングをもってしても、関係性自体はそれほど改善しませんでした。

A さんとの LINE や電話でのやりとりが昼夜問わず頻繁に交わされるようになり、仕事だけでなく、頭痛や吐き気、不眠などの鬱症状が出始めるなど私の体調にも影響が出てきました。体調が優れないときにやりとりをすると、A さんに優しくすることができずに喧嘩になる。悪循環でした。

避妊をしないという約束をした4月も近づき、それまでにはなんとかしないとと思っている中、心身共に限界を感じたため、2017年2月に、六本木の麻布警察署の向かいのレストランで A さんに関係を解消したい意思を伝えました。もしそこで、何かあった場合は、警察に場所を移動するために選んだ場所でした。結局この日は、警察には行きませんでした。

話し合いが別れたい、別れたくないと平行線になるとどうしても、A さんは「じゃあブログに公開して死ぬ」、私は「それだと警察に行くしかないじゃないか」という言い合いになりました。そこで私から「じゃあ、一切そういうことはしないと約束する代わりに 1,000万円を慰謝料として用意する」という提案もしました。しかしそれも実現には至りませんでした。結局、その 2/13 日から一週間ほど後に A さんが看護師試験を控えている、それを乗り越えるためにも、その日は結論は保留することにしました。

私は以前から、A さんが看護師になることを楽しみにしていました。A さんは大学卒業後、自分でお店を経営したり、たくさんのバイトをしたりとで非常に苦労してきたあと、3年間学費も自分で出して看護学校に通い、就職先の病院も決まりようやく看護師になるという道が見えてきたところでした。その道を卒業間近のいま駄目にしてしまうことは、全く望んでいませんでした。

このとき判断は保留にする、別れるとは言わない代わりに、私から、じゃあこれから先、脅迫行為は一切しないで欲しいと本人に約束してもらいました。

この約束の甲斐もあって、それまで毎日のようにあったいざこざが無くなって、A さんとは仲良く会話ができるようになりました。それからの一ヶ月は、多少の喧嘩はありましたが以前ほどは深刻ではなく過ごすことができました。

しかし、A さんが看護学校の卒業式を終えた翌日、仕事中の私に LINE が来てまた以前と同じようないざこざが始まってしまいました。その間、一ヶ月間が経っていたためか、なかなかその会話は良い方向へ向かわず、ネットへの公開や妻の殺害など脅迫行為もまだ始まってしまいました。限界でした。私は意を決して、再度 A さんに関係解消を伝えようと A さんの自宅へ向かいました。

自宅へ着くなり、A さんには関係解消の意思を伝えました。予想通り、揉めました。私はこれ以上私を脅迫するなら警察に行こうと伝え、A さんは別れたくない、別れるなら死ぬという言い合いになりました。そして A さんが窓から飛び降り自殺を図ろうとしたため、私は A さんを力任せで無理矢理窓から引きはがし、そのままマンションのエレベータまで引っ張りだしました。近所に交番があることは知っていたため、なんとかすれば交番の人たちに気づいてもらえるだろうと言う意図がありました。このとき力づくで A さんを引っ張ったことで、怪我をさせてしまいました。

交番の方々が駆けつけ、事情を説明すると私と A さんは警察署に移動することになり、その警察署内で、A さんには私に二度と近づいてはならいという接近禁止警告がなされました。署内で最後に A さんに直接、これまでの謝罪の意思を伝えて、朝方その場をあとにしました。

その直後から、A さんは私のことを書いたブログを公開し Twitter にも交際中の写真などをアップロードしはじめました。それらは警察からの警告などもあってすぐに取り下げられ、今回ほど騒ぎにはならずに済みましたが、私にはとてもそれが怖かった。

いま思えば、私のやり方は非常に良くなかったと思っています。後に A さんも、もっとちゃんと話し合いたかった、突然警察に連れて行かれて何が何だかわからなかったと言っていました。私は、自分は脅迫されているという恐怖心と被害者意識が非常に強くなっていたため、A さんとじっくり話すということよりも、関係を解消するということに焦ったんだと思います。そして、私はそもそも既婚者であったり、A さんの申し出に曖昧な返事しかしてこず状況を悪化させたり、妊娠と中絶の件であったり、そして妻を深く傷つけていることなど自分にたくさん取り返しのつかない非があることも内心わかっていました。しかし、自分は脅迫されていた、こうするしか方法がなかったという被害者意識に逃げ込み、それら自分の非を認めることができていませんでした。

きちんと自分の非を認め、A さんに謝罪をし、A さんからの制裁を恐れることなく誠意をもって向き合っていればもっと違った結果になったかもしれません。

それから先は、双方弁護士を通じて会話をするようになりました。

弁護士を交えての話し合いは、当初は比較的穏やかに進んでいました。私も徐々に反省できるようになり、謝罪の意思がありました。しかし、時間が経ってくると、A さんから弁護士を交えずに会話したい、もっと早くに会いたい。また元の関係に戻りたい、子供を作る約束を守ってほしい、それができないならネットですべてを公にするなど、Twitter 上での脅迫が始まってしまいました。途中、私の性行為中の画像が公開されたりということもありました。

ネット上での緊張したやりとりが続いたことで、私もだんだんと態度を硬直化させてしまい、結果、芽生えていた謝罪意識が、ここでまた被害者意識に反転していまいました。慰謝料を払う意思もありましたが、どんどん「何でこんな目に遭っているのに・・・」という気持ちと共に、薄れていきました。面会は本来自分の侵した罪の償いのためでもあったのですが、暴露などが何度か続くうち、私にとっては、被害を最小に抑えるという目的にいつのまにか変わっていました。

6月、7月と二度弁護士同席のもとでの面会がありましたが、そこでは謝罪するではなく、言い合いになってしまいました。

こうしてなかなか終着点が見えない中、A さんが意を決して、ブログの公開に踏み切ったのが先週水曜日です。A さんから見ると、なかなか自分の非を認めない、謝罪もない、あげくお金も払おうとしない私の対応が許せなかったんだと思います。

今回こうして騒ぎになったことで、私も一人で自分自身を見つめ直すことになりました。責任をとれるわけでもなく A さんとの関係性を深めてしまったことがそもそもの私の間違いですが、より大きかったのは被害者意識を盾に、自分の間違いを認めることから逃げてしまったことです。A さんはそれによって傷つけられたのではないかと思います。また同じ自分の未熟さが、同時に妻をも傷つけました。

今回こうして、あえて公のブログに書いたのは、私自身の間違いをきちんと公の場で認めること。そしてそれをもって、A さんに謝罪すること。妻に謝罪することです。

読んでくださった方に一点だけお願いがあります。ここに私が書いたことは A さんがブログに書かれたことと、矛盾していることも多数あるとは思います。しかし、A さんがブログにかかれたことは A さんにとっては事実だったんだと思っています。事実そう思わせてしまったことは、私に非があります。ですので、もしこのブログを読んでそう思ったとしても A さんを責めることはしないでください。これだけはお願いします。

A さんには今後、直接面会しその場で改めて謝罪をしたいと思っています。しかし、A さんは今、今回捨て身でブログ公開に踏み切ったため自分が表に出ると逮捕されしまうことを危惧されています。私は、私の過ちを認めるつもりです。A さんを今回のことで刑事告訴することは考えていません。これもまた公の場で宣言することで、A さんにそれを信じていただきたい、そういう気持ちです。お金も約束通りお支払いしようと準備しています。

自分の浅はかさ、未熟さにより A さんを深く傷つけてしまったことを非常に後悔し、反省しています。また妻にも申し訳ないことをしました。会社の同僚や、私をこれまで信頼していた周りのみなさんをも裏切ることになりました。大変、申し訳ありませんでした。

February 04, 2016

ソーシャルメディアにおける他人との関係性がコンテンツ価値に影響を与える

ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。

以前に HBFav を作ったときこんなことを書きました。

Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。

HBFav というはてなブックマーク iPhone アプリを作りました - naoyaのはてなダイアリー

4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。

ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。

f:id:naoya:20160204113224p:image:w320

この機能についての自分の感想は以下のようなものでした。

もうすこし補足します*1

Facebook や Twitter のようなソーシャルメディアで伝搬してくるコンテンツの価値は、そのコンテンツそのもの単独で決まるのではなく、「誰がそのコンテンツをピックアップしたのか」という要素がその価値における大きな部分を占めると思っています。

例えば、技術に関するコンテンツの場合でも、ソフトウェアテストに関する記事を @t_wada さんが面白いと言ってシェアしているものと、そうではない人がシェアしている場合では、「僕にとっては」そのコンテンツの価値が変わってきます。

なぜ「僕にとっては」なのか。それには、僕から見た場合に t_wada さんはソフトウェア開発におけるテストやリファクタリングという文脈のおいての第一人者だから。「この分野に関しては t_wada さんが言うならそうなんだろうな」という信頼があるからです。これは僕という人間と、t_wada さんとの関係性によって決まります。つまりソーシャルな関係性が、コンテンツに新しい文脈を与えているとみなすことができます。

敢えて t_wada さんのように、界隈で著名な方を例に挙げましたがその対象は別に著名な方である必要はありません。例えば職場に、とある技術にとても明るいけど一般にはあまり名は知られてない同僚がいたとする。その同僚が、その技術についての記事をシェアしているならやはり「僕にとっては」その記事の価値が、それ単独で存在した場合とは変わってきます。

逆に、たとえ t_wada さんだとしても、そうですね・・・別に何でもいいのですが、例えば食に関する URL を流していたとしても「僕と t_wada さんの関係性」が、そのコンテンツに与える影響は少ないです。これは別に t_wada さんが食に詳しくないということではなく、たとえ t_wada さんが食に詳しかろうがそうでなかろうが、僕と t_wada さんの関係性において食の面での繋がりは薄いので、そういう結果になる・・・ということです。

繰り返しになりますが、コンテンツの価値というのはそれ単独で決まるのではなく、それはそのコンテンツに触れるきっかけになった人や媒体と自分との関係性が大きく作用する、ということです。

これは以前にも同様のことを述べました。

タイムラインあるいはアクティビティフィード、という観点から見ると、Twitter で「何を言ったか」より「誰が言ったか」の方が重要なことと同じように、何がブックマークされたかということより「誰がブックマークしたか」と言うことの方がずっと重要です。

HBFav というはてなブックマーク iPhone アプリを作りました - naoyaのはてなダイアリー

まあ、キュレーションだなんだという話が何年も前から話題になっていますから、別にとくに新しい話ではなく、2016 年の昨今においては多くの方が実感されていることであろう、と思います。

この観点から言って、Twitter に自分が求めるのは「Twitter 全体で今どんなニュースが盛り上がっているのか」ではなく、「自分とフォロワーとの関係性の中で価値があるものは何か」というところです。ですので、先の機能については個人的にはあまり必要ないなと感じました。実際、掲載されているニュースはいずれもほぼ関心がありません。

話は変わりここ数日、Kaizen Platform の PM が読んでいたのを見かけて『 ぼくらの仮説が世界をつくる』という書籍を読んでいます。(あいつが読んでたから俺も読んでる。これも、人間関係がコンテンツ価値に影響を与えてる一例ですね) 『ドラゴン桜』や『宇宙兄弟』の編集を手がけた佐渡島庸平氏の本でなかなかに面白い本なのですが、以下のような節がありました。

なぜ人は「練り込まれたプロの文章」よりも「友だちのくだらない投稿」のほうがおもしろいと思うのか?

(中略)

つまり「美味しさ」というものは絶対値があるわけではなくて、「関係性」の中できまるのではないか。同じように作品の「おもしろさ」というものも絶対値ではなく、関係性の中で決まるのではないか、という結論に至りました。

SNS で流れてくるコンテンツは何を食べたとかどこにいったとか、それ単体ではあんまりそれそのものはおもしろくない (というか全然おもしろくない) のについつい見てしまうのはなぜなのか、という問いから出発して答えはやはり「関係性」らしい。ああ、自分とまったく同じこと考えてる人いたわーと思って、何度も頷きました。

よくよく考えると、コンテンツが自分に届くときは知人経由にしろメディア経由にしろ、何かしらのチャネルを介して届いてくるわけで、自分にとっては、独立でそれが届くことはないんですけど。自分の予想では、従来の媒体からではなくソーシャルメディアから届いた場合の方が個人によっては、コンテンツの価値が高まる (あるいは下がる) 度合いが強く、結果それがコンテンツの取捨選択基準を大きく左右するし、内容を読み取るにあたってもソーシャルな関係性の文脈が当人に対して強く反映される、と思います。

例えば昨今よく目にする NewsPicks というサービスがあります。このサービスも、Web上のユーザーのコメントを記事と一緒に届けることで同様のことを狙っていますよね。

正直にいうと自分はこの NewsPicks があまり好きじゃないです。コメント欄が自分の苦手な Facebook 的な雰囲気に満ちあふれているので、触れるとお腹いっぱいになる。

好きではないけど、こんな形でソーシャルな関係性が与える文脈を取り込むメディアは時代の変化に合ったアプローチを取っているとは思いますし、以前も述べたように、Facebook/Twitter (あるいは LINE) などのソーシャルメディアがコンテンツを届けるインフラとして重要なインフラであり続ける、そしてその影響力は今後益々大きくなる・・・ということは事実としてあるでしょう。ニュースなどの情報ソースがインターネットやスマートフォンにシフトしていけばいくほどその勢いは増していくのは間違いない。好むと好まざるに関わらず。

すなわちソーシャルメディアの本質は、そこにいるユーザー同士のソーシャルな関係性が、そこで扱われるコンテンツに強い価値基準や文脈を与える、ということだと思うのです。

*1:別にこの記事の主張は Twitter アプリの出来についてが主題ではなく、たまたま考えるきっかけになった良い材料だっただけです、悪しからず。個人的に要らないと思ってるだけで万人にとって、ではないです。エクスキューズめんどくさい!

October 26, 2015

プロダクトマネージャーについて

Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。

プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。

プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。

プロダクトマネージャーは新しいユニコーンか?

昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの・・・いわゆるユニコーンのように映っているのではないかと思います。それは良くないですね。

願わくば昨今の議論が「だからプロダクトマネージャーがない自分のとこは駄目なんだ」という結論の補強のためにではなく、「どうしたらプロダクトマネジメントの機能を組織に作る事ができるか」とか「プロダクトマネジメントのスコープを明確にすることでよりよい製品開発ができるのかどうか」という前進のための糧になれば良いなと思っています。

その前提で、プロダクトマネージャーなるものが幻なのかどうかについて。

インターネット分野のソフトウェア産業、特に自社開発の Web サービス / SaaS などの製品開発分野において、国内では、プロダクトマネージャーという職種はまだあまり形式化されていません。一方、海の向こうでは状況が異なり、プロダクトマネージャーという職業がソフトウェアエンジニアやデザイナーと同列で存在しています。つまり幻ではありません。

それは以下のような書籍が発行されていることからもその様子が伺えます。

一番目の「世界で闘う〜」は、前半がプロダクトマネージャーとはどういう職業なのかについて体系的に述べつつ Apple、Google、Facebook、Amazon、Microsoft などの実例からそれぞれの企業ごとの差を浮き彫りにするという内容です。後半は、面接対策です。つまり、プロダクトマネージャーというポジションが明確に存在していて、それになるにはどうしたらいいのかが述べられています。

二つ目と三つ目は、実際にプロダクトマネージャーとしてのキャリアを積んできた著者が、具体的にその仕事内容とそれをうまくやるノウハウを記した書籍です。Inspired の方は元 eBay のプロダクトマネージャーです。Making It Right の方は未読なのでわかりません。

プロダクトマネージャーはどういう責務を果たすのかについてはそれぞれの本を読むほうが良いと思いますが、「世界で闘う〜」には「プロジェクトが完了して成功を収めるまで、全体を見ていく責任があります」と記されています。また「プロジェクトマネージャー」でも「プログラムマネージャー」でもないと、はっきりと書かれています。

プロダクトマネージャーは、ユーザーの理解とロードマップの企画や提案、製品の企画、ユーザー体験のデザイン、リリースされる製品の品質確保までトータルにマネジメントする役割です。要するに「その製品はあいつが作った」「こいつが考えた」というその人に相当します。(プロジェクトマネージャーやプログラムマネージャーは、プロダクトマネージャーに比較すると、限定というか専門特化された役割の職種という位置づけになります。)

プロダクトマネージャーはいわゆる世間で言うところの「企画職」のようにも見えますが、彼らの役割は企画を立ててあとは開発に任せて終わり・・・ではなく、その後の開発プロセスが回ってる間の開発の支援や開発中の意志決定、製品の品質確保、リリース、その後の改善の企画までをトータルに見ていくので実態としては少し異なるでしょう。

実際、プロダクトマネージャーはエンジニアに寄り添って彼らと一体になって製品を作っていく側面が強いので、「世界で闘う〜」の書籍に登場する企業のほとんどが、プロダクトマネージャーにプログラマーとしてのバックグラウンドを求めています。Google ではコンピューターサイエンスを専攻してきたかどうか、Facebook に至ってはプロダクトマネージャーの採用面接でコーディング試験があるとかなんとか。

もとい、プロダクトマネージャーとはこういう職種で、特に海外ではその職種要件やモデルについてはだいぶ明確化されています。

国内でのこの分野ではあまりそこまで明確になっていない、最近になって議論されはじめたのでは・・・というのが私の実感です。(「この分野」と枕詞を置いたのは、id:antipop さんによると、我々が議論しているプロダクトマネージャーに相当する職業は特に自動車産業の分野における主査制度の中に見て取れるなどの事情からです。参考1, 参考2)

一方、私の古巣の話になってしまうのですが、株式会社はてなでは私が在籍していた当時は「ディレクター」という肩書きで、各サービスのサービス開発責任者は明確に定められており、開発において企画やロードマップ策定も含めたリーダーシップを発揮することを求められていました。これはプロダクトマネージャーに相当する役割であると思います。自分もいくつかのサービスのディレクターを担当したことがありました。

また、グリーではゲーム開発の責任者には "PM" という肩書きがついており、主にエンジニア組織のメンバーがその役割に就くことが慣習になっていました。(PM は記憶が定かであれば "Product" の P だったと思います) グリーの PM は製品の企画責任だけでなく事業責任も負っていました。

それから、これは伝聞ですが、任天堂ではゲーム開発の現場でエンジニアやデザイナーの経験を積んだ人が、その後ディレクターとなってゲーム開発の責任者に就き、ゲームの企画やデザインをその人が考える・・・というキャリアパスがあるということでした。

昨今技術顧問を務めている Kaizen Platform, Inc. には明確にプロダクトマネージャーのポジションがあります。

というわけで、国内ではまだ体系化されていないことはあっても、プロダクトマネージャーに相当する職業がないわけではない・・・ということもわかります。

やはりアメリカという国は役割の明確化と組織のシステム化が非常に得意な国ですから、プロダクトマネージャーも例に漏れずその姿が明確になっている感じですね。日本は、曖昧模糊とした中から徐々に役割が定まっていくみたいなところがありますから、こちらも例に漏れずといった状況でしょうか。

プロダクトマネージャーがなぜ必要か?

ここからが本題です。前振り長くてすみません。

昨今自分が「プロダクトマネージャーが〜」とたびたび発言しているのには、当然ですがそれが必要だと思っているからそう発言しているわけですが、ではなぜプロダクトマネージャーが必要なのでしょうか?

細かく理由をいろいろと並べることもできるのですが、これに関してはシンプルに考えれば良いです。それはより良い製品やサービスを作るためには「健全な意志決定の偏らせ」、つまりある種の独裁制が必要だと思っているからです。

このブログを読んでくださっている方々にはソフトウェアエンジニアの方が多いでしょう。エンジニアの方々なら、言わんとしていることは実感としてわかっていただけるのではないかと思います。

例えば大きなシステムを作るとき、その根幹のアーキテクチャや設計を、その場にいる十数人で合議制で決めるべきか。答えは NO で、アーキテクトとして「できるやつ」に任せるべきでしょう。大きな建造物を建てる時に最初の基礎工事が重要になるように、大きなシステムを作る場合は根幹を支える基本アーキテクチャがその下地として重要になります。ソフトウェア設計においてこのときアーキテクチャに求められるのは一貫性です。システム全体に跨がるアーキテクチャに一貫性をもった設計を行うには、経験的に、大人数で合議制で決めるのではなく少ない人数で取り組むべきだということは多くの人が賛同する事柄ではないでしょうか。

また、オープンソースソフトウェアにおいても優しい終身の独裁者 という言葉で語られるように、優れたプロジェクトには決まって特定のリーダーがいて、ソフトウェアのデザインやプロジェクトの意志決定において独裁的な役割を果たしているとも言われます。

・・・要するに、よい物を作りたかったらそのデザインはできるやつに任せるべき・・・という単純な理由なんです。合議制では良いものは作れない。

従って開発組織においても、製品開発の責任者を曖昧にするのではなく、できるやつにデザインや意志決定を任せたほうがいい、つまり「健全な意志決定の偏り」があったほうがいい・・・それを制度として実現するなら「プロダクトマネージャー」という役割を明確化することだろうというのが自分なりの結論です。

プロダクトマネージャーはもともといた

そんな理由から、組織内で誰に製品ロードマップや企画やデザインを託すのかという話になっていくのですが、よくよく考えると企業の創業期にはだいたい創業メンバー・・・典型的には創業者がその役割を果たしていることが少なくないということに気がつきます。

ソフトウェア開発のスタートアップにおいては、プロダクトのアイデアが全くないという状態でスタートアップが始まることは希 (そういうスタートアップもあるはあるけどだいたいポシャる) で、そのアイデアは創業者が持っていることが多いでしょう。また、昨今は創業メンバーにエンジニアやデザイナーを含めて回せ・・・というのがセオリーになっていることからもわかるとおり、創業期にはそのアイデアをもった創業者とそれを実現するエンジニアやデザイナーが小さな机の上でああでもないこうでもないと言いながら最初の製品を作り込んでいくわけです。そしてその作った製品で事業を興せるものなのかどうか、実際にユーザーに使わせてみて、その結果を見ながら会社や製品の方向性を定めていく・・・そんなプロセスを否が応でも経ることになります。

この創業者というのは、改めてみるとプロダクトマネージャーそのものですよね。(そしてこのプロダクトマネージャーである創業者自身がエンジニアで、一緒に開発しているなんてことも珍しくないです。)

つまりスタートアップが会社として成長するためには、まともなプロダクトが必要不可欠であり、まともなプロダクトができあがってくる背景には暗黙のうちに組織にプロダクトマネージャーに相当する人間がいて、創業者がだいたいそれだったりする、ということです。

しかし組織がその後成長してくると、創業メンバーというのは往々にしてその役割が変化し、製品開発から組織運営や会社経営の方にフォーカスせざるを得ないという状況に遭遇します。その組織の拡大期に、製品開発組織の構造化に自覚的でなかった組織は、「誰にプロダクトを任せるか」という視点を欠いて、プロダクトマネージャーに相当する機能を失ってしまうか、その役割を薄めてしまう・・・ということが起こります。

自分が主張したいのは、組織の中でその「健全な意志決定の偏り」を取り戻すために、プロダクトマネジメントの機能を組織内に作ってそれを実現すればいいじゃないということなのです。

プロダクトマネージャーを見つける?

重要なことは「プロダクトマネージャという職種を作る」ということ、それ自体ではありません。「健全な意志決定の偏り」を実現することです。従って、たとえプロダクトマネージャーなるポジションがない会社でもそれが実態として実現されているならそれで構わないでしょう。

先に述べたとおり、小さな企業では「そうしなければ回らない」という必然的な背景からプロダクトマネージャーに相当する人間がそこにはいるものです。一方で、大きな会社ではそれが失われていることも多い。失われているなら、作りましょう、そういう話ですね。

プロダクトマネージャーを育てるとか見つけるのは大変という議論があります。自分もそう思います。プロダクトマネージャーはサービスや製品の責任者であり、その人の意志決定如何によって製品が劇的に良くなることもある一方で、劇的に悪くなることもまたあるという両刃の剣です。それが「できる」という人間を外から探してくるのは、まあ骨の折れる仕事というか、それに成功さえすればある意味その会社は勝ったみたいなところがあります。それぐらいいないというか、大変なんですよね。

一方で、実現したいのは、やはり偏らせだということは忘れたくないですね。今いる組織の中にも「この人に任せればうまくいく」という人間はそれ相応にいたりするものではないでしょうか。その人に偏らせればよいというのも一考に値しそうです。同じ開発プロジェクトでも、あの人がいるなら安心してみてられるというのであれば、その「あの人」はプロダクトマネージャーになれる可能性は高いです。プロダクトマネージャーにはエンジニアリングやデザインのバックグラウンドが求められることが多いので、相関的に開発組織の中から見つかることも多いですが、案外セールスの中にプロダクトに熱い情熱と深い顧客理解を持ったメンバーがいるなんてことも珍しくはなく、実際自分はセールス出身のメンバーがその後プロダクトマネージャーになって華開く、なんて場面を目の前でみたこともあります。

その上で、じゃあプロダクトマネージャーって、どういうことをその責務とするの・・・という議論が先に紹介した書籍などに詳細に記されているということもお忘れなく。どういうことが上手な人が、プロダクトマネージャーに向いているのか。そのヒントがそこにあるでしょう。単に意志決定を偏らせれば良いわけではないですからね。あくまで、できるやつに偏らせるということが大切です。(たびたび記しているように、相応にエンジニアリングのバックグラウンドが求められるなどはそれなりに意外なポイントだったりすると思います。)

プロダクトマネジメントの機能を組織の中でどう作っていくか、という議論はまだまだ始まったばかりという気もしますが、一方で実現したいことはもっとシンプルに「いい物を作るために誰に任せたらいいか」ということだと思います。そう考えれば、そんなに夢物語のようなことでもないような気がしてきませんか?

追記

Product Manager の役割についてよく書かれている記事を教えてもらいました。参考にどうぞ。

November 22, 2014

HBFav 2.8.1 をリリース : iPhone 6 解像度対応と認証再要求問題の修正 / はてなブックマークへの要望

昨日のことになりますが HBFav 2.8.1 をリリースしました。主な変更は

  • iPhone 6 解像度対応
  • はてなブックマーク追加時に認証を再度要求されてしまう問題の修正

の 2 点です。

これまでは折角画面サイズが大きくなった iPhone 6 や 6 Plus で HBFav を使っても解像度は iPhone 5s のころのサイズのままで、引き延ばされて表示されていました。結果的に文字がぼやけるなどの状態でしたが、今回改めて iPhone 6 と 6 Plus 解像度に対応したことで見た目もくっきり、一画面に収まる情報量も増えました。

不具合の修正は、長らく続いていた、一度認証したのにしばらくするとまた認証を要求されてしまう問題の修正です。自分の手元ではなかなかこの問題が再現せず、原因が特定できずに困っていましたがようやくそれがわかって修正できました。いろいろとご不便おかけしましたが辛抱強くつきあってくださったみなさまありがとうございました。

ちなみに不具合修正までの経緯は https://github.com/naoya/HBFav2/issues/112 この Issue にあります。Watson1978 さんが、どうもアプリがバックグラウンド処理中にクラッシュすると認証問題が顕在化するらしい、ということを発見してくれたところから霧が晴れて、yashigani さんから iOS の KeyChain の仕様上そういうことが起こるかも、ということを教えていただき解決に至りました。ありがとうございました。

実は iPhone 6 対応の方も、いろいろコードの修正必要なのかなと思ったところ Watson1978 さんの Pull Request を merge したところそれ以上の修正も必要なく動いてしまった、という。本当はもっとレイアウト崩れなどが起きると踏んでたのですが、実際には案外相対記述でレイアウトの実装ができてた。

対応にあたっては新しい解像度のスプラッシュ画像が必要でした。それはオリジナルのものやロゴを作ってくれた ugtkbtk が作ってくれました。

というわけで、割かし嬉しい更新項目二つですがみなさんの協力によって実現されています。感謝感謝です。

はてなブックマークへの要望

話は変わって HBFav の機能追加にあたってはてなブックマークへの要望です。前にここに要望を書いたら RSS フィードの仕様まわりでいくつか実装されたことがあった (要望したからとは関係ない可能性も高いけど) ので、改めて書きます。気長に待ってます。

  • お気に入り追加 / リスト / 削除の API が欲しい
    • アプリの中からユーザーを follow / unfollow できるとアプリの幅が拡がるので是非ほしい
    • 当然、認証が要求されるので可能ならはてなブックマークSDKに、SDK レベルの API として実装されて、SDK の認証要求によって認証周りが共通化されるのが希望 (そうじゃないと、アプリ本体と SDK とで二回認証が要求されることになる)
  • 非表示ユーザーの API が欲しい
    • 非表示ユーザーへの追加 / リスト / 削除の API が欲しい
    • これも公式アプリで実現されてるので API がある?
  • マイホットエントリー取得の API が欲しい
    • (公式アプリにあるということは API はあるようだけど)
    • これも認証周りについては上記に同じ

ところで、以前にもすこし書きましたが、はてなブックマークを昨今の文脈で捉え直してみます。

  • Instagram が写真を軸にしたソーシャルネットワーク
  • Twitter が 140 文字テキストを軸にした
  • Vimeo が動画を軸にした
  • LINE がプライベートメッセージを軸にした
  • Swarm が位置情報を軸にした・・・

といくなら、はてなブックマークは URL (Webの記事) を軸にしたソーシャルネットワークです。

それがソーシャルネットワークだとするなら、その中心価値となるソーシャルグラフを操作できる API が解放されていることは応用可能性という点でも、外部の開発者 (外部ネットワーク) がソーシャルグラフを太らせてくれるという意味でも、中の人外の人双方にとってとても有意義なことだと思います。

よろしくお願いします。

October 28, 2014

「リーン」について : 「何を作るか」よりも「何を作らない」か

2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。

書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。

仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す・・・というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─ そういう主張でもある。

ちなみに自分としてはリーン・スタートアップ信奉者でもなんでもない。

Peter Thiel のリーン・スタートアップ批判?

一方最近、元 PayPal の創業者である Peter Thiel が書いた「ゼロ・トゥ・ワン」という書籍を読んだ。(以下 Zero to One) この本はリーン・スタートアップ的な考え方を手厳しく批判している・・・という点で注目を浴びている。なんとなく書籍のタイトルから言わんとすることは想像できるが、実際のところは本編ではリーン的なやり方についての批判はあまり見られない。というか、アイデアを実現するにあたって細かく刻んでいって変化に適応しやすくするべき、というような観点についてはほぼリーンの考え方それに近いことを述べてる。

唯一彼がリーン・スタートアップを批判したとすれば、Peter Thiel はスケールがでかいことが好きなので「小さいプロダクト作って顧客からフィードバックループを集めるとかそんなことじゃ、例えば宇宙輸送とかテスラの電気自動車とか代替エネルギーとか、そういう未来は描けないじゃないか」というような、"ビジョン" とかその辺をどう考えるかというところである。そこに関して異論はない。

ただ、Zero to One の中で彼はリーンのことを

それはすなわち「計画しない」ことである。ビジネスの先行きは誰にもわからない。計画を立てるのは傲慢であり柔軟性に欠ける。むしろ、試行錯誤を繰り返し、先の見えない実験として起業を扱うべきだ

とそんな主張だと解釈しているようだった。これは瀧本哲史が書いている序文 (この序文ははっきり言ってひどい) にも

リーン・スタートアップでは、事前にあまり計画せずに、少しずつ改善することを重視するが、ティールはそうしたスタートアップは結局は成功しにくいと考える

と言う一文があるし、彼らはリーンは「計画をあまりしないこと」だと思っている節がある。

ここに関して、自分の実感とはちょっと違うなと思ったのでブログに書いてみようと思った次第である。前振り終わり。

リーンについて

自分が思うに、リーン・スタートアップやそれに続く「リーン何々」というのはその時のその人のおかれている状況によって結構捉え方が違うものだろうなと思っている。

  • 大企業などでしっかりとした事業計画をを作って物事を進めなければという立場の人には「そんなに計画作りに労力を割きすぎても思った通りにはいかないから適当なところで切り上げたほうがいい」という主張に聞こえるし
  • スタートアップとかで無鉄砲にあれもこれも作ったりしている立場の人には「事前にコンセプトをはっきりさせるとか、仮説を立てるとかユーザーと向き合うとかそういうことにもう少し時間を使った方がいい」という主張に聞こえる

そんな感じの印象を持っている。

特に自分は、後者の、スタートアップが当初の勢いに任せてあれもこれも作りまくった結果それが原因で失敗する・・・たとえば製品が無駄に複雑になったり、余計な仕事を増やしてしまって本来やるべきことにフォーカスできなくなってしまう、そういう場面を多く見てきたし、例に漏れず自分もその罠にはまったことがある。だからリーンという考え方が "「何を作るか」よりも「何を作らないか」" という選択をするときの一つの考え方にはなるのかもな、と思っていた。

2013 年の年末頃に開催された Exciting Coding! 2013 というイベントで、Qiita を作っている Increments の id:yaotti が講演の中でまさにそういう話をしていた。

f:id:naoya:20141028125307p:image:w640

起業当時に作ったプログラミングの Q&A サイトが Qiita に変わっていくまでの過程、ある意味失敗を通じて彼はやはり「何を作らないか」が大事だという考え方に至って、そのためにリーン・スタートアップの文脈で言うところの MVP (Minimum Viable Product) によってアイデアを作る前に検証できたらそれが一番良いかもしれない・・・と述べていた。起業のプロセスを通じてこういう考え方に至るまでの実体験を淡々と話す彼の様子を見ていて感銘を受けたのをよく覚えている。

このあたりのコンテキストが自分にはあったので、リーンが「計画をあまりしないこと」というのは自分の実感とはだいぶかけ離れている。むしろある程度計画を立てることによって「やらないこと」をはっきりさせるための方法論という風にも見えている。

問題をどう解決するかよりも、何が問題かを見極める

ところでまた最近別に「イシューからはじめよ」という本も読んだ。(後半の方法論の所は自分にはちょっと眠たかったけれども) なかなか良いことが書いてた。曰く価値の高い仕事 ─ 著者はそれをバリューの高い仕事と呼んでる ─ を成し遂げたかったら「どんな風にその仕事をこなすか」ということよりも「どんな問題 (イシュー) を解決するか」ということ、つまり問題の見極めこそがとても重要だということを論じている。

f:id:naoya:20141028125305p:image:w640

これ、言われてみれば当たり前のことなんだけれども、人間なぜか問題の見極めよりも、プロセスにばかりやたらと拘ってしまうところがある。このブログを読んでいただいている方の文脈で言えば、たとえばスクラムとか、テスト駆動開発とか Github で云々とか、そういうプロセス、道具を良くしていけば優れたソフトウェアが作れるとか、そんな風に勘違いしてしまったことが一度は誰でもあるんじゃないだろうか。自分もあった。

でも実際には、優れた製品を作るにはその製品がちゃんとユーザーの問題を解決しているかどうか、それを知るということが最も重要であり、どんなにプロセスばかりを良くしたってその領域には到達できない。(もちろん、良いプロセスは大事なので両方できるのが一番良い)

例えば、ソフトウェア開発の組織においてこの図でいうところの横軸には気を遣わず、タテ軸ばかりを頑張ったとする。すると、ユーザーの問題は全然解決されないけどやたらと物を作る速度ははやい、そんなチームができあがる。

f:id:naoya:20141028125306p:image:w640

みんな一度は触ったことがあるはず。やたらと機能がてんこもりでカタログスペック上は何でもできる魔法の製品だが、いざ触って見るとこれっぽっちも問題を解決してくれない・・・そんなプロダクト。具体名を書くといろいろ燃えそうなので、まあそれはモザイクにした。その逆をうまくできれば Qiita とか Slack とか、我々が好きなソフトウェアがちゃんと作れる。

で、ソフトウェア開発の方法論とこのイシュー云々の話を結びつけるなら、スクラム、継続デリバリー、Github 云々といった最近の開発手法の話は「イシューからはじめよ」の絵でいうところのタテ軸を伸ばす方法論で、リーンは横軸をどう考えるかというための処方箋であるという風に捉えられる・・・と思った。

起業もそうだしソフトウェア開発もそうだし、いや、仕事延いては人生など諸全般において、問題を正しく見極めるということはとても重要なことである。その時に闇雲に物事を進めるよりは「何をやらないか」というコンセプト決めとかそういうことを少しやるだけで物事はずっとよくなるし、逆にそればっかりをやっているなら、もう少し柔軟にやってみたら? というのがリーン的な考え方だろうと、自分は思っている。

ビジョンも必要だよ

一方、途中に書いた Peter Thiel が述べているような「どうせやるなら大きく賭けろ」みたいな話もそれはその通りかもなとも思ってて(それは最近読んだ Erik Shmidt が書いた 「How Google Works 」にも同じことが書かれてた)、なんだかんだでユーザーがびっくりするような物を作るにはそういうビジョンというか思い込みみたいなものに賭けるという側面も絶対になければならないと思ってる。

それらをすべて机の上に載せると、情熱とかビジョンとかそういうものに突き動かされて未来思考で物を作るということと、現実的にはここまでに述べたような問題を正しく見極めること、どちらか一方じゃなくてバランス良くそれをやってくのが最善である。

・・・以上、幾つか本を読んだ割には月並みな結論に達してしまった、という話であった。終わり。

Connection: close