ソーシャルメディアにおける他人との関係性がコンテンツ価値に影響を与える
ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。
以前に HBFav を作ったときこんなことを書きました。
Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。
4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。
ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。
この機能についての自分の感想は以下のようなものでした。
もうすこし補足します*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 で「何を言ったか」より「誰が言ったか」の方が重要なことと同じように、何がブックマークされたかということより「誰がブックマークしたか」と言うことの方がずっと重要です。
まあ、キュレーションだなんだという話が何年も前から話題になっていますから、別にとくに新しい話ではなく、2016 年の昨今においては多くの方が実感されていることであろう、と思います。
この観点から言って、Twitter に自分が求めるのは「Twitter 全体で今どんなニュースが盛り上がっているのか」ではなく、「自分とフォロワーとの関係性の中で価値があるものは何か」というところです。ですので、先の機能については個人的にはあまり必要ないなと感じました。実際、掲載されているニュースはいずれもほぼ関心がありません。
話は変わりここ数日、Kaizen Platform の PM が読んでいたのを見かけて『 ぼくらの仮説が世界をつくる』という書籍を読んでいます。(あいつが読んでたから俺も読んでる。これも、人間関係がコンテンツ価値に影響を与えてる一例ですね) 『ドラゴン桜』や『宇宙兄弟』の編集を手がけた佐渡島庸平氏の本でなかなかに面白い本なのですが、以下のような節がありました。
なぜ人は「練り込まれたプロの文章」よりも「友だちのくだらない投稿」のほうがおもしろいと思うのか?
(中略)
つまり「美味しさ」というものは絶対値があるわけではなくて、「関係性」の中できまるのではないか。同じように作品の「おもしろさ」というものも絶対値ではなく、関係性の中で決まるのではないか、という結論に至りました。
SNS で流れてくるコンテンツは何を食べたとかどこにいったとか、それ単体ではあんまりそれそのものはおもしろくない (というか全然おもしろくない) のについつい見てしまうのはなぜなのか、という問いから出発して答えはやはり「関係性」らしい。ああ、自分とまったく同じこと考えてる人いたわーと思って、何度も頷きました。
よくよく考えると、コンテンツが自分に届くときは知人経由にしろメディア経由にしろ、何かしらのチャネルを介して届いてくるわけで、自分にとっては、独立でそれが届くことはないんですけど。自分の予想では、従来の媒体からではなくソーシャルメディアから届いた場合の方が個人によっては、コンテンツの価値が高まる (あるいは下がる) 度合いが強く、結果それがコンテンツの取捨選択基準を大きく左右するし、内容を読み取るにあたってもソーシャルな関係性の文脈が当人に対して強く反映される、と思います。
例えば昨今よく目にする NewsPicks というサービスがあります。このサービスも、Web上のユーザーのコメントを記事と一緒に届けることで同様のことを狙っていますよね。
正直にいうと自分はこの NewsPicks があまり好きじゃないです。コメント欄が自分の苦手な Facebook 的な雰囲気に満ちあふれているので、触れるとお腹いっぱいになる。
好きではないけど、こんな形でソーシャルな関係性が与える文脈を取り込むメディアは時代の変化に合ったアプローチを取っているとは思いますし、以前も述べたように、Facebook/Twitter (あるいは LINE) などのソーシャルメディアがコンテンツを届けるインフラとして重要なインフラであり続ける、そしてその影響力は今後益々大きくなる･･･ということは事実としてあるでしょう。ニュースなどの情報ソースがインターネットやスマートフォンにシフトしていけばいくほどその勢いは増していくのは間違いない。好むと好まざるに関わらず。
すなわちソーシャルメディアの本質は、そこにいるユーザー同士のソーシャルな関係性が、そこで扱われるコンテンツに強い価値基準や文脈を与える、ということだと思うのです。
プロダクトマネージャーについて
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。
プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。
プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。
プロダクトマネージャーは新しいユニコーンか?
昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･いわゆるユニコーンのように映っているのではないかと思います。それは良くないですね。
願わくば昨今の議論が「だからプロダクトマネージャーがない自分のとこは駄目なんだ」という結論の補強のためにではなく、「どうしたらプロダクトマネジメントの機能を組織に作る事ができるか」とか「プロダクトマネジメントのスコープを明確にすることでよりよい製品開発ができるのかどうか」という前進のための糧になれば良いなと思っています。
その前提で、プロダクトマネージャーなるものが幻なのかどうかについて。
インターネット分野のソフトウェア産業、特に自社開発の Web サービス / SaaS などの製品開発分野において、国内では、プロダクトマネージャーという職種はまだあまり形式化されていません。一方、海の向こうでは状況が異なり、プロダクトマネージャーという職業がソフトウェアエンジニアやデザイナーと同列で存在しています。つまり幻ではありません。
それは以下のような書籍が発行されていることからもその様子が伺えます。
- 世界で闘うプロダクトマネジャーになるための本 トップIT企業のPMとして就職する方法
- Inspired: 顧客の心を捉える製品の創り方
- Making It Right: Product Management For A Startup World
一番目の「世界で闘う〜」は、前半がプロダクトマネージャーとはどういう職業なのかについて体系的に述べつつ 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 で、アーキテクトとして「できるやつ」に任せるべきでしょう。大きな建造物を建てる時に最初の基礎工事が重要になるように、大きなシステムを作る場合は根幹を支える基本アーキテクチャがその下地として重要になります。ソフトウェア設計においてこのときアーキテクチャに求められるのは一貫性です。システム全体に跨がるアーキテクチャに一貫性をもった設計を行うには、経験的に、大人数で合議制で決めるのではなく少ない人数で取り組むべきだということは多くの人が賛同する事柄ではないでしょうか。
また、オープンソースソフトウェアにおいても優しい終身の独裁者 という言葉で語られるように、優れたプロジェクトには決まって特定のリーダーがいて、ソフトウェアのデザインやプロジェクトの意志決定において独裁的な役割を果たしているとも言われます。
･･･要するに、よい物を作りたかったらそのデザインはできるやつに任せるべき･･･という単純な理由なんです。合議制では良いものは作れない。
従って開発組織においても、製品開発の責任者を曖昧にするのではなく、できるやつにデザインや意志決定を任せたほうがいい、つまり「健全な意志決定の偏り」があったほうがいい･･･それを制度として実現するなら「プロダクトマネージャー」という役割を明確化することだろうというのが自分なりの結論です。
プロダクトマネージャーはもともといた
そんな理由から、組織内で誰に製品ロードマップや企画やデザインを託すのかという話になっていくのですが、よくよく考えると企業の創業期にはだいたい創業メンバー･･･典型的には創業者がその役割を果たしていることが少なくないということに気がつきます。
ソフトウェア開発のスタートアップにおいては、プロダクトのアイデアが全くないという状態でスタートアップが始まることは希 (そういうスタートアップもあるはあるけどだいたいポシャる) で、そのアイデアは創業者が持っていることが多いでしょう。また、昨今は創業メンバーにエンジニアやデザイナーを含めて回せ･･･というのがセオリーになっていることからもわかるとおり、創業期にはそのアイデアをもった創業者とそれを実現するエンジニアやデザイナーが小さな机の上でああでもないこうでもないと言いながら最初の製品を作り込んでいくわけです。そしてその作った製品で事業を興せるものなのかどうか、実際にユーザーに使わせてみて、その結果を見ながら会社や製品の方向性を定めていく･･･そんなプロセスを否が応でも経ることになります。
この創業者というのは、改めてみるとプロダクトマネージャーそのものですよね。(そしてこのプロダクトマネージャーである創業者自身がエンジニアで、一緒に開発しているなんてことも珍しくないです。)
つまりスタートアップが会社として成長するためには、まともなプロダクトが必要不可欠であり、まともなプロダクトができあがってくる背景には暗黙のうちに組織にプロダクトマネージャーに相当する人間がいて、創業者がだいたいそれだったりする、ということです。
しかし組織がその後成長してくると、創業メンバーというのは往々にしてその役割が変化し、製品開発から組織運営や会社経営の方にフォーカスせざるを得ないという状況に遭遇します。その組織の拡大期に、製品開発組織の構造化に自覚的でなかった組織は、「誰にプロダクトを任せるか」という視点を欠いて、プロダクトマネージャーに相当する機能を失ってしまうか、その役割を薄めてしまう･･･ということが起こります。
自分が主張したいのは、組織の中でその「健全な意志決定の偏り」を取り戻すために、プロダクトマネジメントの機能を組織内に作ってそれを実現すればいいじゃないということなのです。
プロダクトマネージャーを見つける?
重要なことは「プロダクトマネージャという職種を作る」ということ、それ自体ではありません。「健全な意志決定の偏り」を実現することです。従って、たとえプロダクトマネージャーなるポジションがない会社でもそれが実態として実現されているならそれで構わないでしょう。
先に述べたとおり、小さな企業では「そうしなければ回らない」という必然的な背景からプロダクトマネージャーに相当する人間がそこにはいるものです。一方で、大きな会社ではそれが失われていることも多い。失われているなら、作りましょう、そういう話ですね。
プロダクトマネージャーを育てるとか見つけるのは大変という議論があります。自分もそう思います。プロダクトマネージャーはサービスや製品の責任者であり、その人の意志決定如何によって製品が劇的に良くなることもある一方で、劇的に悪くなることもまたあるという両刃の剣です。それが「できる」という人間を外から探してくるのは、まあ骨の折れる仕事というか、それに成功さえすればある意味その会社は勝ったみたいなところがあります。それぐらいいないというか、大変なんですよね。
一方で、実現したいのは、やはり偏らせだということは忘れたくないですね。今いる組織の中にも「この人に任せればうまくいく」という人間はそれ相応にいたりするものではないでしょうか。その人に偏らせればよいというのも一考に値しそうです。同じ開発プロジェクトでも、あの人がいるなら安心してみてられるというのであれば、その「あの人」はプロダクトマネージャーになれる可能性は高いです。プロダクトマネージャーにはエンジニアリングやデザインのバックグラウンドが求められることが多いので、相関的に開発組織の中から見つかることも多いですが、案外セールスの中にプロダクトに熱い情熱と深い顧客理解を持ったメンバーがいるなんてことも珍しくはなく、実際自分はセールス出身のメンバーがその後プロダクトマネージャーになって華開く、なんて場面を目の前でみたこともあります。
その上で、じゃあプロダクトマネージャーって、どういうことをその責務とするの･･･という議論が先に紹介した書籍などに詳細に記されているということもお忘れなく。どういうことが上手な人が、プロダクトマネージャーに向いているのか。そのヒントがそこにあるでしょう。単に意志決定を偏らせれば良いわけではないですからね。あくまで、できるやつに偏らせるということが大切です。(たびたび記しているように、相応にエンジニアリングのバックグラウンドが求められるなどはそれなりに意外なポイントだったりすると思います。)
プロダクトマネジメントの機能を組織の中でどう作っていくか、という議論はまだまだ始まったばかりという気もしますが、一方で実現したいことはもっとシンプルに「いい物を作るために誰に任せたらいいか」ということだと思います。そう考えれば、そんなに夢物語のようなことでもないような気がしてきませんか?
HBFav 2.8.1 をリリース : iPhone 6 解像度対応と認証再要求問題の修正 / はてなブックマークへの要望
昨日のことになりますが HBFav 2.8.1 をリリースしました。主な変更は
の 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 が欲しい
ところで、以前にもすこし書きましたが、はてなブックマークを昨今の文脈で捉え直してみます。
- Instagram が写真を軸にしたソーシャルネットワーク
- Twitter が 140 文字テキストを軸にした
- Vimeo が動画を軸にした
- LINE がプライベートメッセージを軸にした
- Swarm が位置情報を軸にした･･･
といくなら、はてなブックマークは URL (Webの記事) を軸にしたソーシャルネットワークです。
それがソーシャルネットワークだとするなら、その中心価値となるソーシャルグラフを操作できる API が解放されていることは応用可能性という点でも、外部の開発者 (外部ネットワーク) がソーシャルグラフを太らせてくれるという意味でも、中の人外の人双方にとってとても有意義なことだと思います。
よろしくお願いします。
「リーン」について : 「何を作るか」よりも「何を作らない」か
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。
書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。
仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す･･･というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─ そういう主張でもある。
ちなみに自分としてはリーン・スタートアップ信奉者でもなんでもない。
Peter Thiel のリーン・スタートアップ批判?
一方最近、元 PayPal の創業者である Peter Thiel が書いた「ゼロ・トゥ・ワン」という書籍を読んだ。(以下 Zero to One) この本はリーン・スタートアップ的な考え方を手厳しく批判している･･･という点で注目を浴びている。なんとなく書籍のタイトルから言わんとすることは想像できるが、実際のところは本編ではリーン的なやり方についての批判はあまり見られない。というか、アイデアを実現するにあたって細かく刻んでいって変化に適応しやすくするべき、というような観点についてはほぼリーンの考え方それに近いことを述べてる。
唯一彼がリーン・スタートアップを批判したとすれば、Peter Thiel はスケールがでかいことが好きなので「小さいプロダクト作って顧客からフィードバックループを集めるとかそんなことじゃ、例えば宇宙輸送とかテスラの電気自動車とか代替エネルギーとか、そういう未来は描けないじゃないか」というような、"ビジョン" とかその辺をどう考えるかというところである。そこに関して異論はない。
ただ、Zero to One の中で彼はリーンのことを
それはすなわち「計画しない」ことである。ビジネスの先行きは誰にもわからない。計画を立てるのは傲慢であり柔軟性に欠ける。むしろ、試行錯誤を繰り返し、先の見えない実験として起業を扱うべきだ
とそんな主張だと解釈しているようだった。これは瀧本哲史が書いている序文 (この序文ははっきり言ってひどい) にも
リーン・スタートアップでは、事前にあまり計画せずに、少しずつ改善することを重視するが、ティールはそうしたスタートアップは結局は成功しにくいと考える
と言う一文があるし、彼らはリーンは「計画をあまりしないこと」だと思っている節がある。
ここに関して、自分の実感とはちょっと違うなと思ったのでブログに書いてみようと思った次第である。前振り終わり。
リーンについて
自分が思うに、リーン・スタートアップやそれに続く「リーン何々」というのはその時のその人のおかれている状況によって結構捉え方が違うものだろうなと思っている。
- 大企業などでしっかりとした事業計画をを作って物事を進めなければという立場の人には「そんなに計画作りに労力を割きすぎても思った通りにはいかないから適当なところで切り上げたほうがいい」という主張に聞こえるし
- スタートアップとかで無鉄砲にあれもこれも作ったりしている立場の人には「事前にコンセプトをはっきりさせるとか、仮説を立てるとかユーザーと向き合うとかそういうことにもう少し時間を使った方がいい」という主張に聞こえる
そんな感じの印象を持っている。
特に自分は、後者の、スタートアップが当初の勢いに任せてあれもこれも作りまくった結果それが原因で失敗する･･･たとえば製品が無駄に複雑になったり、余計な仕事を増やしてしまって本来やるべきことにフォーカスできなくなってしまう、そういう場面を多く見てきたし、例に漏れず自分もその罠にはまったことがある。だからリーンという考え方が "「何を作るか」よりも「何を作らないか」" という選択をするときの一つの考え方にはなるのかもな、と思っていた。
2013 年の年末頃に開催された Exciting Coding! 2013 というイベントで、Qiita を作っている Increments の id:yaotti が講演の中でまさにそういう話をしていた。
起業当時に作ったプログラミングの Q&A サイトが Qiita に変わっていくまでの過程、ある意味失敗を通じて彼はやはり「何を作らないか」が大事だという考え方に至って、そのためにリーン・スタートアップの文脈で言うところの MVP (Minimum Viable Product) によってアイデアを作る前に検証できたらそれが一番良いかもしれない･･･と述べていた。起業のプロセスを通じてこういう考え方に至るまでの実体験を淡々と話す彼の様子を見ていて感銘を受けたのをよく覚えている。
このあたりのコンテキストが自分にはあったので、リーンが「計画をあまりしないこと」というのは自分の実感とはだいぶかけ離れている。むしろある程度計画を立てることによって「やらないこと」をはっきりさせるための方法論という風にも見えている。
問題をどう解決するかよりも、何が問題かを見極める
ところでまた最近別に「イシューからはじめよ」という本も読んだ。(後半の方法論の所は自分にはちょっと眠たかったけれども) なかなか良いことが書いてた。曰く価値の高い仕事 ─ 著者はそれをバリューの高い仕事と呼んでる ─ を成し遂げたかったら「どんな風にその仕事をこなすか」ということよりも「どんな問題 (イシュー) を解決するか」ということ、つまり問題の見極めこそがとても重要だということを論じている。
これ、言われてみれば当たり前のことなんだけれども、人間なぜか問題の見極めよりも、プロセスにばかりやたらと拘ってしまうところがある。このブログを読んでいただいている方の文脈で言えば、たとえばスクラムとか、テスト駆動開発とか Github で云々とか、そういうプロセス、道具を良くしていけば優れたソフトウェアが作れるとか、そんな風に勘違いしてしまったことが一度は誰でもあるんじゃないだろうか。自分もあった。
でも実際には、優れた製品を作るにはその製品がちゃんとユーザーの問題を解決しているかどうか、それを知るということが最も重要であり、どんなにプロセスばかりを良くしたってその領域には到達できない。(もちろん、良いプロセスは大事なので両方できるのが一番良い)
例えば、ソフトウェア開発の組織においてこの図でいうところの横軸には気を遣わず、タテ軸ばかりを頑張ったとする。すると、ユーザーの問題は全然解決されないけどやたらと物を作る速度ははやい、そんなチームができあがる。
みんな一度は触ったことがあるはず。やたらと機能がてんこもりでカタログスペック上は何でもできる魔法の製品だが、いざ触って見るとこれっぽっちも問題を解決してくれない･･･そんなプロダクト。具体名を書くといろいろ燃えそうなので、まあそれはモザイクにした。その逆をうまくできれば Qiita とか Slack とか、我々が好きなソフトウェアがちゃんと作れる。
で、ソフトウェア開発の方法論とこのイシュー云々の話を結びつけるなら、スクラム、継続デリバリー、Github 云々といった最近の開発手法の話は「イシューからはじめよ」の絵でいうところのタテ軸を伸ばす方法論で、リーンは横軸をどう考えるかというための処方箋であるという風に捉えられる･･･と思った。
起業もそうだしソフトウェア開発もそうだし、いや、仕事延いては人生など諸全般において、問題を正しく見極めるということはとても重要なことである。その時に闇雲に物事を進めるよりは「何をやらないか」というコンセプト決めとかそういうことを少しやるだけで物事はずっとよくなるし、逆にそればっかりをやっているなら、もう少し柔軟にやってみたら? というのがリーン的な考え方だろうと、自分は思っている。
ビジョンも必要だよ
一方、途中に書いた Peter Thiel が述べているような「どうせやるなら大きく賭けろ」みたいな話もそれはその通りかもなとも思ってて(それは最近読んだ Erik Shmidt が書いた 「How Google Works 」にも同じことが書かれてた)、なんだかんだでユーザーがびっくりするような物を作るにはそういうビジョンというか思い込みみたいなものに賭けるという側面も絶対になければならないと思ってる。
それらをすべて机の上に載せると、情熱とかビジョンとかそういうものに突き動かされて未来思考で物を作るということと、現実的にはここまでに述べたような問題を正しく見極めること、どちらか一方じゃなくてバランス良くそれをやってくのが最善である。
･･･以上、幾つか本を読んだ割には月並みな結論に達してしまった、という話であった。終わり。
エンジニアにとって良い組織とは何かを知りたい?
「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが･･･」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。
How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント
posted with amazlet at 14.10.18
小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
posted with amazlet at 14.10.18
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
posted with amazlet at 14.10.18
この3つを読んで何も感じることがないようなら、あなたにはエンジニアにとって良いなにがしを構築する素養はないと思うし、本なんて読んでられるかというのには、その程度のことにも時間を割けないならそもそも諦めろとしか言えない。
日本語で読める IT名文書 三選
pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。
伽藍、バザール、ノウアスフィア、おなべ(3)
artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。
Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した
- http://anond.hatelabo.jp/20111018190933 (前編)
- http://anond.hatelabo.jp/20111018192953 (中編)
- http://anond.hatelabo.jp/20111018193022 (後編)
Rebuild.fm とかでも何回か話してる記事。元Amazon で Google+ の中の人が「俺たちプラットフォーム作ってる言ってるけど、全然だめだよ! お前ら Amazon の SOA とか見ろよ!」と憤って社内にメールしたら流出しちゃいました、という文書。
ベゾスからトップダウンで「SOAしないやつはクビな」とか言ってできあがったシステムがその後のアレになりましたとか、むちゃくちゃ面白い。
射撃しつつ前進
メールみてWebみて昼飯くってメールみてWebみて･･･ってやってたら夕方になってようやくエディタ立ち上げる、みたいなくだりがあるあるすぎて面白い。本編よりそこが面白い。
ハッカーと画家
例えば、大学で私は、コンピュータに手を触れる前に 紙の上でプログラムを完全に理解しなければならないと教わった。 でも私はそういうふうにはプログラムできなかった。 私が好んだやりかたは、紙の前ではなく、コンピュータの前に座って プログラミングすることだった。もっと悪いことに、 辛抱強く全てのプログラムを書き上げて正しいことを確認するなんてことは せずに、私はめちゃくちゃなコードをおっぴろげて、 それを次第に形にしてゆくのだった。 私が教わったのは、デバッグとは書き間違いや見逃しをつかまえる 最終段階の工程だということだったが、 実際に私がやっていたのは、プログラミングそのものがデバッグという具合だった。
随分長い間、私はそのことを後ろめたく思っていたものだ。 ちょうど、小学校で教わった鉛筆の持ち方と違う持ち方をしていることを 後ろめたく思っていたのと同じように。 他のものを創る人々、画家や建築家がどうやっているかを見れば、 私は自分のやっていることにちゃんと名前がついていると気づいていただろう。 スケッチだ。 私が言えるのは、大学で教わったプログラミングのやりかたは全部間違っていた ということだ。 作家や画家や建築家が、創りながら作品を理解してゆくのと同じで、 プログラマはプログラムを書きながら理解してゆくべきなんだ。
最高の一節。
あれ、3といいつつ4になってた･･･
HBFav 2.7.1 をリリース。iOS 8 に対応しました
審査に時間がかかってしまいましたが、無事 HBFav 2.7.1 をリリースできました。
これで iOS 8 にするとクラッシュする問題が解消されました。
ただし、iOS 8 でプッシュ通知を受け取ろうと設定しようとしたとき正しく設定できない問題が見つかったため、急遽修正しまして 2.7.2 の審査待ちです。デバッグの過程で既存のプロビジョニングファイルをいろいろいじったせいで、もしかすれば既存のバージョンもプッシュ通知が届かなくなっているかもしれません、申し訳ないです。プッシュが届かなくなっているもしくは iOS 8 でプッシュが来ないかたは 2.7.2 のリリースをお待ち下さい。
このところ HBFav の開発にあまり時間が取れず、バージョンアップの割に目新しい機能はほとんどありませんが、今後ともよろしくお願いします。
