valid,invalid

関心を持てる事柄について

2016年の振り返り -罪と罰-

総じて

明確な目標無く漫然と過ごしてしまった印象がある。

昨日、友人との忘年会で「お前にとっての2016年を5文字で言うと?」という雑なフリに対して「罪と罰、だな…」と雑に返してみたけどあながち間違っていなかったかもしれない。

これまで怠惰に過ごした結果(罪)としての体重増加に対し、ジム通い(罰)で贖っているのだから…。


仕事

2015年末 ~ 2016年4月まではスタディサプリのリリースでかなり忙しかった。忙しさを言い訳にはできないがそれ以外ほとんど目に入っていなかったような気がする。

それが片付いてからの開放感とふわっとした気持ちを引きずってしまっているうちにまた年度末が近づいてきて忙しくなり…というサイクルに巻き込まれた。教育サービスをやっている以上このサイクルは不可避だと思う。関わりはじめて2年目なのでそろそろ慣れていきたい。

スタイル

あまり大きく変わっていない。

11月から部分的に KanbanFlow - Lean project management. Simplified. とか、付随するポモドーロタイマーとか使い始めた。でも厳密にはやっていない。

後述する不健康具合から集中力が欠けたと感じた時にスイッチを入れるために Slack と Jasper をオフにするのは良くやるようになった。


技術

ずっと Ruby on Rails と Backbone.js を仕事で触っていた他だと、ES6 とか React.js + Redux 構成のフロントエンド領域を申し訳程度に学んだ。これは2017年から仕事でも使う機会があるのでわりと打算的なところもある。

もうちょっと違うパラダイムや考え方の言語をやってみたいというのはなんとなく思った。

その他、対外的なアウトプットとしてどっか勉強会で一回登壇したいと思っていて【RMP×Quipper】Food&Drink meetup #4に出た。

また、GitHub で 10 stars 集める程度には承認される何かは作りたいな〜とゆるふわに考えていたが進捗ダメでした。 https://github.com/ohbarye/kpt-bot が最も近いが届かず。未達だが来年の目標は20とかにしたい。

開発環境

ソフトウェア

Sierra にアップデートしたけど大きな問題がなかった。

シェルを bash から zsh (Prezto) にしてかなり良い感じ。ただ、powerline 用に入れた Ricty フォントの一部 (太字の ij ) がぶっ壊れているのが気になるのでそのうち直す。

f:id:ohbarye:20170101210717p:plain

RubyMine は機能を覚えてもさらに深い奥があって、相変わらず使いこなせているのかどうかわからない感じ。最近なんとなくターミナルも RubyMine 内で開くようになった。これは大きいディスプレイで作業している時は良いが 13 inch のラップトップだけだとだいぶキツイ。

ハードウェア

これまでハードウェアに全く凝ってこなかったしラップトップ一台で高い生産性が発揮できるほうが格好いいと思ってきた。だが、「他の方法を試してもいないのになぜそれが最適と思う?」という疑念を抱かされるちょっとしたきっかけがあって以下のキーボードとマウスを導入してみた。

Kensington SlimBlade Trackball

これは同僚推しの品。 普段から Macbook のトラックパッドを触りまくっていたので本当に代替になるのかと思っていたが1日で慣れてしまった。

Web ブラウジングGitHub で diff 見ながらのレビューの時に結構助かっている感じがある。

TrackballWorks ソフトウェアによるカスタマイズはほとんど行っていないが、マウスの移動速度だけはかなり速くしている。

MiSTEL BAROCCO MD600 分離式 メカニカルキーボード 英語配列 62キー CHERRY 茶軸

腱鞘炎と肩こり対策のつもりで買ってみたがこれが良かった。打鍵時の姿勢が変わって、背筋を伸ばして肩甲骨を寄せた姿勢で長時間タイピングできるようになった。肩こりは完治はしていないが悪化の一途に歯止めがかかっている感じがある。

また、茶軸のスコスコした打鍵感は自分にはかなり合っているようで、今のところ気持ちよくコーディングができている。

キーマクロは今のところ使いどころがあまり無い。


英語

進捗ダメでした。どうなりたいかを全く設定していなかった。

仕事で定常的にやり取りする英語(読み書き)はわりと定型化されているのでだいぶ前に能力が頭打ちになっている感がある。ある程度通じるレベルのブロークンな読み書きを脱して新しい表現を取り入れようと例文集の DUO をぱらぱらと読んで使ってみたりもしたが、定着した表現は30個もないぐらい。

リスニング・スピーキングにいたってはもっと厳しい。ぽつぽつとシャドウイングとかやっていたけどあんまり続いていない。 仕事で喋ったのは数える程度で、夏にロンドンの開発者が来てくれて2ヶ月ほど滞在していた時は毎日卓球したりたまに飲みに行ったりしたが、かなり手加減してもらっているのでぎりぎり話せている感があった。

とはいえ、全く伸びていない感じではないっぽくて、忘年会で日本語が流暢なアメリカ人と練習がてら英語で話してみたら意外といけたような気がする。宗教や移民、結婚といった common だけど deep に話せる話題で会話できてほんの少し自信がついた。


文化活動

Hip Hop

1月に Straight Outta Compton を観てから Hip Hop を少し好きになった。思想・思潮・変遷が俺が知るどの音楽よりも面白いし、知った上で聞くと不思議と "深み" を感じる。グルメな人が食材じゃなくて情報を食べてるのと同じ感じがするが、とにかく良いと感じるのだから仕方がない。

あとグローバルカンパニーの一員として、英語の歌やラップの一つもできないのは恥ずかしい(去年フィリピンの開発者が来てくれた忘年会で日本語のラップをやってしまったことをずっと後悔している)と思って N.W.A. の "F**k the Police" という曲を練習した。とりあえず2週間ぐらいかけて Ice Cube パートの歌詞もリズムも全て覚えたところで力尽きた。

Netflix

Hulu やめて Netflix に切り替えた。

Hip Hop 絡みでいうとオリジナルドラマの Get Down と Hip Hop Evolution がかなり良かった。前者は Hip Hop 黎明期のフィクションで、1970年頃のニューヨークやサウス・ブロンクスの事情とそこでなぜ Hip Hop が生まれたのかが見えてくる。対して後者はドキュメンタリーで、70s ~ 90s の Hip Hop の変遷と各時代の重要人物、アメリカ東西での差異などがわかる。たびたび挿入される各年代の有名曲から色々掘り下げて聞いていけるのも楽しい。特に Funky 4 + 1 の "That's The Joint" は仕事中も無限ループして聞いていたりする。

"SF ブラックコメディ" みたいに紹介された Black Mirror は世にも奇妙な物語みたいな感じで一話完結モノで良さそうだったのに数話観て「あまり合わないな」と思った。だが、その矢先、シーズン3の第4話である『サン・ジュニペロ』が Reddit で絶賛されているのを見て気になったので観てみたら非常に良かった。こういうのが観たかったんだよ…という感じ。なので最近は「このためだけでも Netflix に登録した価値があった」と言って人に勧めまくっている。

Hulu

Hulu やめた、と書いたけど正確に言うと「観たいコンテンツがなくなって解約したんだけど Walking Dead シーズン7が放映されて一時再契約した。で、終わったらまた解約した」。

映画

あまり観なかった。

インド映画の『PK』は宗教問題をコメディに昇華できていて良かった。主演アーミル・カーンのアンシャンレジームぶっ壊し系演技は過剰、ゆえに好きなんだけど、インドのような込み入った宗教事情がある国でこれを上演して本当に大丈夫か?と思った。「どの宗教をも貶める意図はない」と映画の前置きにもあったが、どう前置いてもそう受け取ってしまうことこそが盲信なのでは…。

アニメーションだと『君の名は』と『この世界の片隅に』を観た。

ゲーム

PS4 を買ってまず『The Last of Us』をプレイした。肝心のストーリーは一本道で若干の消化不良感はあったけど PS2 でゲーム体験が止まっている身からしたら全体的に「凄いよォ…」という印象。

しばらくして『ペルソナ5』をプレイした。とにかく良かったしサントラが欲しい。

『トリコ』とか『FF15』も気になったけど『ペルソナ5』より楽しめる気がしないので今のところ見送っている。

その他

観劇、落語、読書その他では特筆すべきことがぱっと思い浮かばないレベル。

音楽だと5月に来日した Victor Wooten のライブが凄かったのと、SUMMER SONIC で観た Pentatonix が良かったな〜ぐらい。

あと12月になんとなく思い立ってギターとベースを久しぶりに弾いて宅録の仕方を思い出したりしていた。グリスしただけで指がめちゃ痛くなった。


健康

冒頭に書いたように、2015年後半から2016年中盤まで結構不健康だった。

5月ぐらいに78kgぐらいで体重が高止まりしていた。自分の場合、1 ~ 3年周期で10kgぐらい増減するので気にしてなかったが、年々体重 Max 時の体調が悪くなってきたので見直したくなった。特に食後の胃やお腹の張りが気持ち悪くて午後の仕事の集中力に欠いたりした。

また、肩こりや背中・腰の痛みも結構あって辛かった。これらは60分2,980円のマッサージは何回か行ったが根本解決にならなかった。

ジム

というわけで8月末頃からジムに通うことにした。もう敬遠できない…。

区営のスポーツセンターなので会員費はなく、1回250円。最低週2回、多くて4回は行って筋トレ・有酸素運動・ストレッチをする。すぐ飽きるかと思ったのだが結構ハマっている。成果が数字ですぐフィードバックされるので「前回より重い重量を持ち上げられた」「前回より長く走れた」という実感が簡単に得られる。

筋トレ

1回の通ジムで、何らかのトレーニング x N 回(e.g. 腕立て15回、腹筋20回とか)を1セットとして20セットは必ずやる。だいたい、その倍の40セットやる。

本気で筋トレやっている人に比べたら全くもって俄でライトな内容なのであまり自慢することは無いのだが、オフラインのコミュニケーションでは「筋トレやってる」と宣言して、自分を追い込もうとしている。

最初はプロテインを飲まずに特茶を飲んでいたけど効果を最大化したいと思うようになり、近所のスーパーで売っているZABAS のミルクプロテインを飲むようになった。430ccで100kcal、タンパク質15g ぐらいで少なくとも特茶よりは良さそう。「プロテインは不味い」というイメージがあったけどこれは飲むヨーグルトみたいでむしろおいしい。来年はもっと本格的なやつを買う。

そういえば年越し忘年会直後に公園で5年ぶりぐらいに懸垂に挑戦してみたら数回できた。5年前は1回もできなかったので結構感動した。が、そのあと首と肩を痛めて元日から寝起きが悪かった…。

減量

「減量と筋肉の増強を同時に行うのは難しい」と『SOFT SKILLS』に書いてあったし、本当はどっちかに絞ったほうが良いのだと思う。しかし自分のモチベーションが保てるようにとりあえず全身の筋肉増強しつつ体重も減れば良いかなという感じ。

上記の筋トレ20セット後に10 ~ 20分のウォーキング or サイクリングで汗をかきつつ筋肉の回復を待って、また筋トレに戻って…を繰り返している。

ちなみに体重の方の成果は、現在 72.2kg で - 5.7kg / 3ヶ月なのでそれなりに出ていると思う。ベルトの穴は2つ縮まった。


あとはちょっとした映像作成したり香川や京都に旅行に行ったり VR を体験したり引っ越したりした。2017年も引っ越したい。

ohbarye.me with a cat eating fishes

ohbarye.me with a walking cat - valid,invalid の続き (?)。

http://ohbarye.me

f:id:ohbarye:20161231003822g:plain

というわけで、

  • クリックした場所に魚を置く
  • 猫がそこに寄っていく(スピードアップする)
  • 到達すると食べる
  • だんだん太っていく

ようになりました。

あとは

  • 猫が歩く方向を向く
  • 躍動感ある gif にする

ようにしたいけど今の自分の感じだと gif 作るのに物凄い時間を要しそう。

ES5 で書いているのが途中で辛くなってきて ES6 で書き直してみたけどどうせなら ES7 でも良かったと書いていて思った。

ohbarye.me with a walking cat

http://ohbarye.me

me

今は画面をクリックすると猫が方向転換するだけだけど、

  • 猫が歩く方向を向く
  • 躍動感ある gif にする
  • クリックした場所に魚を置く
  • 猫がそこに寄っていく(スピードアップする)
  • 到達すると食べる
  • だんだん太っていく

とかやりたい。

kpt-bot を使って KPT も Slack に集約しよう

ES6 の勉強がてら kpt-bot という Slack bot を作ってみたので

github.com

kpt-bot を使って KPT も Slack に集約しよう」という記事を Qiita に投稿した。

qiita.com


Node.js、JavaScript というだけで web フロントエンドと地続き間があるから書けなくはないけど、いまいち仲良くなりきれていない感があるのでもう少しいろいろ作って遊んでみたいんだよな…。Electron の機運か。

ohbarye.me

TwitterGitHub のプロフィール欄にある「あなたの web サイト」的な箇所に登録するリンクがこのブログだったり GitHub の個人アカウントへのリンクだったり、統一感がなくて良くない!となんとなく思い立って About me page を作ってみた。

http://ohbarye.me

GitHub - ohbarye/me: My profile

とりあえずは色んなリンク置き場ぐらいの立ち位置で。

typography

デザインに対するセンス・知識・造詣ひっくるめて自分には欠けているので、とにかく typography (他人の土俵) で勝負するしかないと思った。

Google Fonts を眺めていたら Lato という良さそうなのがあったのでこれを使うことにした。

うわっ、私のサイトBootstrapくさすぎ!? たった数文字変えるだけでBootstrapのくさみが抜ける7つのCSSテクニック。などを読みつつてきとうに調整した結果…

f:id:ohbarye:20161204132705p:plain

h1, h1, a タグ並べただけだが、なんとなく"らしさ"が出た気がする。

面白み

ここからが良くないところだった。

「"シンプルで洗練されてます"感が出てるけど、これだけじゃつまらないよな…」

「凝ったデザインはしたくないけど、ランダムに図形をレンダリングするのは面白そう」

canvas を使ってみよう」

などと思い始めてちょっとしたスクリプトを書いた結果…

f:id:ohbarye:20161204184420g:plain

ポップなドットが大量に並んで草間彌生デザインみたいになった。

動くコンテンツ、そっちに目が行ってしまって良くない。けど、<marquee> 時代のセンスなので「読み物でもないし良いかな…」ぐらいの気持ちでいる。

プログラマのページとして、何かしら動的なコンテンツがあった方が"らしい"のだろうか。それとも洗練された typography の前では何も要らないのだろうか。

いずれにせよもっと良いデザインや面白いアイディアを思いついたら更新する。

独自ドメイン

http://www.onamae.com/ で初めて取得した。GitHub pages への適用方法は以下を参考に行った。

『Inspired: 顧客の心を捉える製品の創り方』読んだ

マーティ・ケイガン の『Inspired: 顧客の心を捉える製品の創り方』を読んだ。

この本は社内の日報・ポエム置き場のようなレポジトリで CTO が紹介していて、その場で購入したのだけれどずっと kindle 内に積んだままになっていた。

うーん、これは、もっと早く読むべきだった。

内容

いわゆるプロダクト開発・マネジメントのベストプラクティス集。

Hewlett-Packard、NetscapeeBay など名だたる企業でプロダクトマネージャーとして働いてきた著者の経験だけでなく、知人友人その他あらゆる人脈から収集したテクニックがあますところなく紹介されていて、とにかく凝集度が高い。

219ページしかないらしいのだが、毎ページ進むたびにハイライトしたくなる(傍線を引きたくなる)。

顧客向け(BtoC)のソフトウェアプロダクトが中心だが、企業向け(BtoB)ソフトウェアに関するテクニックも多く紹介されている。ソフトウェアに限らない話も多い。

感想

これまでソフトウェア開発で経験してきて知っていること、わかったつもりで誤解していたこと、解決の仕方がわからなかったこと、ぼんやりと考えてはいたが言語化できていなかったことがことごとく語られていて、うーん、これは、もっと早く読むべきだった(2回目)。

現職の周囲の人々に限らず、世の中にはこれを読んで欲しい人がたくさんいる。

そして、あまりにも多くのことがこの1冊でまとめられているので個々の話題に触れていくとまったく語り終わる気がしない。

製品(プロダクト)と感情

特に印象に残った、製品と感情の関係について。同書では第34章で語られていた。

サイエンスやビジネスのバックグラウンドを持つ我々が最も真剣に向き合わなければならないので人間の感情だった、という皮肉ぽい話でぞくっとした。

人々は、ふつうは、感情的な理由で製品を買って、製品を使う。

これについては経験から思うところがあったので別の記事を今度書いてみたい。

欠点

本当に良い本なのでこれを殊更取り上げて言うほどのことなのかわからないけど、脱字が多かった。

あまりにも多く感じたので途中から見つけた脱字はすべてハイライトした。Amazon に報告すればクーポンがもらえるのだろうか。

Highlited

ハイライトした箇所の抜き出し。

Inspired: Kokyaku No Kokoro O Toraeru Seihin No Tsukurikata (Japanese Edition)
by Marty Cagan

プロダクトマネージャーの主な任務としては 2つある。製品の市場性を評価することと、開発すべき製品を定義することである。

Read more at location 179


ソフトウェア開発の組織には、プロダクトマネージャーとデザイナーとエンジニアの人数について、適正な割合があることがわかっている。

Read more at location 240


ダメな製品が無駄に世に送り出されるいちばんの原因は、ほとんどの場合、会社の中でプロダクトマネージャーの役割が明確にされていないことと、プロダクトマネージャーとなる人に対する教育が不十分なことにある。

Read more at location 259


プロダクトマネージャーの役割は、エンジニアリングチームが作り上げるべき製品を詳細に定義することである。これに対して、プロダクトマーケティングの役割は、世界に対して製品を語ることである。この 2つはまったく違う仕事である。

Read more at location 264


プロダクトマネージャーの役割は、作りたい製品のプロフィールを細かいところまで決めることと、実際の顧客やユーザーとともに製品を検証することである。

Read more at location 327


担当者の肩書きや社内の組織体系がどうあれ、あらゆる優れた製品の陰には、責任を持ってその製品のプロフィールを決めた 1人の人間がいる、と私は断言する。

Read more at location 340


プロダクトマネジメントの役割が、価値のある、使いやすい、実現可能な製品を見つけ出すことにあるのに対して、プロジェクトマネジメントの役割は、製品を市場に送り出すことに尽きるからだ。

Read more at location 385


企業向けのサービスである場合は、ライバルに差をつけるいちばんの近道の 1つが、ユーザーエクスペリエンスをよくすることである。一般的に、多くの企業向けの製品では、ユーザーエクスペリエンスがかなりおろそかにされているからだ。

Read more at location 483


製品を必要最小限までそぎ落とすことに集中すること。後でもっと詳しく説明するが、ともかく、プロダクトマネージャーの仕事は、究極の製品を定義することではなく、目的を達成するために必要最小限までそぎ落とされた製品を定義することである。

Read more at location 544


開発チームと離れていればいるほど、また、言葉や文化や時差のためにコミュニケーション上の課題が大きければ大きいほど、製品仕様を決める段階でしっかり完璧に作業しておく必要性に、いっそう強く迫られることになる。プロジェクトとして最悪なのは、プロダクトマネージャーが何を作りたいのかよくわかっていない (あるいは、コロコロ考えを変える) ために、離れた所で作業しているチームがもがき苦しむことだ。

Read more at location 573


プロダクトマネージャーは、エンジニアリングチームのキャパシティ全体の 20% を空けておいて、これをエンジニアリングチームの判断で使える予備の枠として与える。エンジニアリングチームは、たとえば、コードを書き直したり、アーキテクチャーをやり直したり、コードのダメなところをリファクタリングしたり、データベースのシステムを入れ換えたり、システムのパフォーマンスを改善したり、といった作業のためにこの枠を使うことができる。つまり、「開発を中断してコードを書き直さなければだめだ」と言い出す事態を避けるために必要だと思うことであれば、何でもである。

Read more at location 674


eBay は瀕死の状態を経験してからは、二度と危機的な状況に陥ることがないような体制をしっかり整えた。問題が深刻になる前に、さっさとコードの書き直しを始めるようにしたのだ。実際のところ、eBay は、サービスが急成長する中で 3回もコードを書き直して、3回目のときはサイト全体を別のプログラミング言語アーキテクチャーに置き換えた。彼らは、この何百万行もの膨大な量のコードを数年かけて書き直し、同時に、記録的な数の新しい機能も追加した。そして、何よりも、ユーザーに不自由な思いをさせることなく、こうした作業をやってのけたのだ。

Read more at location 697


長い時間をかけて 1つの領域に精通してしまうと、プロダクトマネジメントのもう 1つのワナに落ちてしまうことがある。それは、自分がターゲットである顧客を代弁する人間で、実際以上に自分がターゲットである顧客に近い存在だと思い込むようになるのだ。プロダクトマネージャーというものは、自分の担当する分野や顧客について自分が考えていることを、絶えず問い直さなければならない。

Read more at location 925


最近、ビジネスにおける新たな測定基準が、多くの業界で注目を集めている。ネットプロモータースコア (NPS)

Read more at location 1077


特注品 (特定の顧客向けの製品のことで、だいたいは、製品の購入を確約してもらう見返りとして、特別仕様の仕事を引き受ける) に走るのはかなり危険だ。これは悪い売上の典型であり、会社がユーザーを幸せにする製品を作り出す力をダメにする。

Read more at location 1103


私が仕事をした会社でいちばん多かったのは、マーケティング部門の中にプロダクトマネジメントがあるパターンだ。この組織体系でまずいのは、製品は顧客と話すことから生まれるもので、そのために顧客と話すのはマーケティング部門の仕事だ、という間違った考え方に基づいている点だ。

Read more at location 1114


「どうやるかを指示してはならない。何をすべきかを指示すればいい。そうすれば、彼らの創意工夫に驚かされるだろう。」

Read more at location 1159


現実には、顧客やユーザーが何かいい解決策を思いつけるわけではない。彼らには、そもそも何ができるのかなどわからないのだから、どうやって解決するかを前もって想像するのはかなり難しいだろう。

Read more at location 1168


デザイナーというのは、製品開発のうんと早い段階、つまり、プロダクトマネージャーがターゲットとなる市場を把握してソリューションを考えている段階から参加してこそ、その真価を発揮できるのだ。

Read more at location 1179


この会社のせ製品は、

Read more at location 1247


効果的な製品の市場性評価をやるのは、それほど難しいことではない。私のやり方では、プロダクトマネージャーに、10個の基本的な質問に答えてもらうことにしている。 製品化によって具体的にどんな問題を解決するのか? (バリュープロポジション) だれのためにこの問題を解決しようとしているのか? (ターゲット市場) 市場の大きさは? (市場規模) 製品化の成功をどうやって評価するのか? (指標、収益戦略) 現在、他に競合する製品はあるか? (競合の見通し) なぜ当社がこの製品化をやるのに最適なプレーヤーと言えるのか? (差別化要因) なぜ今なのか? (市場投入の時期) どうやって製品を市場に出すのか? (市場投入戦略) 成功のために絶対に必要な要素は何か? (ソリューションの要件) これらを前提とした上で、最終的な提案は何か?(やるかやらないか)

Read more at location 1392


最善のもの実施させるよう

Read more at location 1447


製品となるどうかは、

Read more at location 1519


見つけられるどう

Read more at location 1520


並行して 2つのバージョンで作業を進めることである。つまり、バージョン1 のエンジニアリングが始まって、プロジェクトが実行段階に入ったら、すぐにバージョン2 の発案作業も開始する。新しいアイデアを生み出す努力は決して絶やさないようにするのだ。あるバージョンがエンジニアリングの段階に入ったら、発案力は次のバージョンに振り向けよう。

Read more at location 1542


製品を見つけ出す段階というのは、あっさりクリアできてしまうこともあれば、ものすごく難しい場合もある。私の経験では、市場性がありそうなところを見つけ出して評価するのはそれほど難しくはないけれど、ソリューションを見つけ出すのに困難を極めることが多い。

Read more at location 1585


社員の多くは、本当はそうではないのに、自分のことを製品のターゲットであるユーザーに近い存在と考えている (あるいは、ターゲットユーザーのことを実際以上に理解しているつもりになっている)。

Read more at location 1675


経営陣は開発プロジェクトのうんと早いうちからコストについて知りたがるけれど、ある程度正確な見積りをするのに必要な情報をエンジニアリングチームが手に入れるのは、開発プロジェクトのずっと後になってからだ、ということにある (なぜなら、それまでは、必要とされるソリューションについてのまともな情報がほとんどないからである)。

Read more at location 1791


ターゲットとする顧客をしっかり理解することと、製品の発売までに確実なリファレンスカスタマーを確保しておくこと、この 2つの課題に取り組むために私がお勧めするのは、ユーザーモニター制度 (charter user program) を利用することだ。

Read more at location 1846


モニターは、間違いなくターゲット市場からの顧客やユーザーでなければならない。よく、アーリーアダプター (初期採用者) が集まってしまった、ということになりやすいものだ。こういう人々は、本来あるべきモニターよりもずっと寛容なので、結局はアーリーアダプターしか興味を持ってくれない製品になりかねない

Read more at location 1887


プロダクトマネージャーは、ユーザーとの面談、ユーザビリティテスト、ユーザーモニター制度での打合せなど、自分が担当する製品に直接関係のあるものなら何であっても出席するべきだ、

Read more at location 1943


すばらしい製品を発見するために必要な洞察力を得ること、それは、ユーザーとなる人々を十分に理解できるようになって、それぞれが根底に抱えているニーズを掘り起こすことから始まる。そういう洞察力は、「このページをカスタマイズして、1人当たりの作業時間を表示したレポートを出す必要がある」とか、「ユーザーの 72% がもっと解像度の高いビデオがいい、と言っていた」、というような表面的な会話からでは得られないだろう。

Read more at location 1945


ユーザーの一部には、目指すべき製品のプロフィールに仕立てていくとか、ユーザーとして示してくれる洞察力のレベルとかいった点で、他のユーザーよりもずっと優秀な人がいる。そういう人たちとは、継続的な関係を作っていこう。

Read more at location 1957


顧客アンケートで得られるデータは、解決策そのものを示すものではなく、解決策にたどり着くためのインプットの一部でしかない、

Read more at location 1986


どんな製品でも少しぐらいはいいところがあるもので、それを見つけるのがみなさんの仕事である。ライバルの製品のいいところや誤りを教訓にしよう。

Read more at location 2019


市場調査による情報は、製品を創造するプロセスへのインプットの一部とはなるけれど、市場調査で製品の方向性を決めようとすると、問題を抱えることとなる。

Read more at location 2028


何が必要のかを

Read more at location 2053


アラン・クーパー (Alan Cooper) の「コンピュータは、むずかしすぎて使えない!」(山形浩生訳、原題は The Inmates are Running the Asylum)

Read more at location 2080


あらゆる人々を満足させる製品にしようというのは、実によくある間違いであり、結局はだれも満足させることができない。

Read more at location 2114


製品開発チームがいちばんよくやってしまう間違いとしては、自分たちを顧客と混同するというのも挙げられる。私がとにかくペルソナを気に入っているのは、よくありがちなこの問題に光を当てるのに役立つからだ。

Read more at location 2116


ハイファイプロトタイプは、ここで挙げた条件に合っていることに加えて、紙ベースの仕様書と違ってテストできるところが最大のメリットだと思う。実際のターゲットユーザーの前に置いて、使い方がわかりやすいかどうか (ユーザビリティ) を確認することができるし、ユーザーが使いたいと思うかどうか (バリュー) も判定できる。プロトタイプがこの 2つのテストをパスするまでは、エンジニアに渡す意味のある製品仕様にはなっていない、ということだ。

Read more at location 2208


いいプロタイプ作成

Read more at location 2440


ユーザーが何を言うかではなく、何をするか、もっと注意して観察してほしい。

Read more at location 2618


製品化によって解決しようとしている問題に対して興味を示してくれる人がなかなか集まらない、あるいは、どうすれば製品をわかりやすく使いやすいものにしてターゲットユーザーに価値を認めてもらえるのか、どうしてもわからない、という判断になることがあるかもしれない。そんな時は、そこで中止して、アイデアを棚上げしよう。

Read more at location 2663


機能を追加することは、結果的に状況を悪くするだけで、何の改善にもならないことがあまりにも多い。

Read more at location 2691


製品の改善は、新しく製品を開発する場合と同じように、何を達成しようとしているのかをよく理解するところからすべてが始まる。

Read more at location 2693


一部の顧客が追加を望んでいる機能であるとか、調査結果だからとか、フォーカスグループがそう言っている、というような話ではないことを忘れないでほしい。大切なのは、製品の出来を表す数値を狙った方向に動かしてくれるのは何であるか、ということだ。

Read more at location 2715


スクラムにしろ、XP (eXtreme Programming) にしろ、アジャイル開発手法には多くのメリットがあるのだけれど、そもそもカスタムソフトウェア (個別の顧客の要求に基づいて作られる特注のソフトウェア) の開発のために考案された手法

Read more at location 2836


プロダクトマネージャーは、プロダクトオーナー (訳注:直訳すると、製品の発注者、すなわち、製品開発プロジェクトの施工主の意) であり、その製品の顧客を代弁する立場にある。

Read more at location 2843


アジャイル開発手法というのは、もともとカスタムソフトウェアの世界で生まれたということだ。 特定の顧客のために特定の目的のソフトを作るというカスタムソフトウェアの世界では、ひどく厄介な作業を強いられてきた。その理由の 1つは、顧客は、自分では何が必要なのかをわかっていないのに、何かが必要だからということで、とりあえずカスタムソフトウェアを作る会社に発注したり、社内の IT部門に依頼を出したりするためだ。

Read more at location 2928


カスタムソフトウェアを開発する会社は、トップクラスのソフトウェア開発者を採用して抱えておくことに関しては、ずっと貧乏くじを引かされてきている。

Read more at location 2936


歴史的には、カスタムソフトウェアの世界ではウォーターフォールプロセスが採用されているけれど、それは、開発を委託されたアプリケーションが作られていく長いプロセスにおいて、さまざまな関係者がその進み具合を監視する方法が必要だったからである。実際、ウォーターフォール型開発手法もまた、このニーズから始まったものである。

Read more at location 2957


大規模で複雑なソフトウェア開発プロジェクトですら、かなり正確なスケジュールを作ることは可能だ。ただ、これは、完全かつ正確に要求仕様と必要な技術を理解していること、そして、仕様の変更が発生しないことを前提としている。

Read more at location 3014


多くの点で、ウォーターフォールプロセスは、理想的ではあるけれどおめでたいとしか言いようがない考え方を象徴している。それは、人は、すべての主要な問題を予測することができて、要求仕様を完璧に理解できる、ということだ。もしそういう状況なのであれば (普通はうんと小さいプロジェクトに限られるけれど)、ウォーターフォールを使ったアプローチは、品質の高い実装を可能にする合理的な方法となり得るだろう。

Read more at location 3051


製品ソフトウェアでは、そういうことはめったに起こらない。実際にどうなるかというと、仕様の変更のために製品は計画より遅れて発売され、いったん現実のユーザーがそのソフトを目にして使い始めると、問題を修正するために、費用と時間をかけて追加のリリースをやらなければならなくなる。

Read more at location 3055


プロダクトマネージャーなって、

Read more at location 3073


どんなベンチャー企業であっても、すべては正しい製品から始まるということを認識する必要がある。だから、順番として最初にやるべきことは、50万ドルやらの創業資金を使い果たしてしまう前に、何が正しい製品であるのかをまず理解することなのである。

Read more at location 3107


大きい会社でのイノベーションを可能とするかどうかを左右する最大の要因は、企業文化と上司の 2つである。

Read more at location 3127


多くの場合、最高のアイデアというのは下から上がってくるものだ。20%ルールのすごいところは、数多くのアイデアを試すことができることにある。自分がアイデアを思い付いたという自負心があるので、そのアイデアはより強い熱意と創造力で追求されるのである。

Read more at location 3139


スカンクワークス (skunk works) というのはずいぶん古い業界用語で、もともとは秘密の軍事プロジェクトを指す言葉だった。今では、社内の官僚主義に邪魔されないように、他の人に気づかれないようにしながら、必要であれば個人の時間も使ってアイデアを追いかける、という意味で使われる。

Read more at location 3146


正式な業務きちんと

Read more at location 3151


覚えておいてほしいのは、イノベーションがまったく新しい問題を解決してくれることはめったにない、ということだ。ほとんどの場合、イノベーションとは、今ある問題を新しいやり方で解決することなのである。人々が今のソリューションに手を焼いているのを観察するのは、イノベーションのチャンスを浮かび上がらせるには最高の方法なのである。

Read more at location 3172


いっしょこのアイデア

Read more at location 3249


私の友人であるデービット・ウェイデン (David Weiden) の言葉は、大企業で働く多くの人がどんな状況に置かれていてどんなチャンスに恵まれているかを的確に言い表している。「多くの人は、暗闇の中をさまよい、 暗い暗いと文句ばかり言っていて、どこにスイッチがあるのを知ろうとしない。」

Read more at location 3309


他のどのハードウェア企業とも違って、アップルは、ハードウェアの役割はソフトウェアを支えることであり、その逆ではない、ということを理解している。

Read more at location 3328


もしアップルが技術系の会社として何か秘伝のソースを持っているとすれば、それは、こういうことだと思う。消費者が製品を欲しくなるとき、製品を手に入れるとき、製品に惚れ込むときに感情が果たす役割というものを、アップルは他のだれよりもよく理解しているのだ。アップルは、どうやって消費者の感情に語りかける製品を作るかを心得ている。

Read more at location 3347


特別仕様の何が悪いのだろうか? 製品を作る会社は、顧客の要求をあるべき製品要求と取り違えることで、まず間違いなく道を踏み外す。

Read more at location 3372


なぜ顧客を当てにすることができないかを説明してきた。その理由をここでおさらいしよう。第一に、顧客にとっては、実際にそのものを目にするまでは、自分が何を必要としているのかを理解するのはとても難しい。第二に、顧客は、どんな技術が可能であるかを知らない。第三に、共通のテーマを確認するために顧客同士が交流することはめったにない。

Read more at location 3375


次なる新しい目玉は何か、と思いを巡らせるのは、いつだって楽しいことだけれど、その目玉は、まったくの新しいものというよりは、むしろ、古いものの新たな生まれ変わりである。何が違うのかというと、新しく生まれ変わった製品は、以前の製品よりもずっといい、ずっと速い、あるいは、ずっと安いので、その製品ジャンルに変革を迫ることになるのだ。

Read more at location 3440


ユーザーを手こずらせる製品がある限り、他のだれかがそれを改良するチャンスがある。

Read more at location 3466


可能なことはいつも変化している。今日実現できないからといって、明日もムリとは限らない。

Read more at location 3468


今日のアプリケーションは、明日のインフラである。この世界のビジネスは、そうやって成り立っている。

Read more at location 3469


いいビジネスチャンスが完全になくなってしまうなんて、あり得ない。

Read more at location 3474


人々は、ふつうは、感情的な理由で製品を買って、製品を使う。優秀なマーケティング担当者は、このことを理解しているし、優秀な製品開発担当者は、製品を人々の感情に訴えかけるようにしようとする。

Read more at location 3479


感情というレンズを通して見れば、ユーザーや顧客が製品やサービスのことを、さらには潜在的な競争相手のことをどう見ているのかという視点にもっと近づいて、物事を見ることができるようになってくる。顧客は、他にはどこに行けばこういう欲求を満足させることができるのか? こういう感情により直接的に訴えかけるには、ビジュアルデザインはどうすればいいか? こういう感情にわかりやすく訴えかけることを邪魔している機能は何なのか?

Read more at location 3488


ベンチャー企業キャズムに陥ってしまう理由の 1つは、状況を見誤るから、つまり、「合理性より感性タイプ」と「テクノロジー大好きタイプ」を混同してしまうからなのです。

Read more at location 3574


プロダクトマネージャーには何を探し求めるように指導していますか? J:怒り、憤慨、不満を探せ、と。ぼくらが嫌いになってしまうようなありとあらゆるもの、電話会社、銀行、消費者金融会社、税務署の職員、官僚、航空会社、医療機関などを見れば、こういうものはみんなイノベーションの絶好のチャンスです。なぜなら、消費者の潜在的な不満がものすごく高いからです。

Read more at location 3587


ぼくたちが問うのは、「どんな感情が行動を駆り立てるのか?」ということです。そして、こういう感情を、製品の機能やそのほかのすべてのものに利用する方法を探します。それぞれのプロジェクトでは、どんな基本的な感情に訴えるのか、そして、ユーザーの苦しみがどれほど深刻なのかを評価します。

Read more at location 3618


ぼくが使うテクニックに、「フレッシュマンテスト」と呼んでいるものがあります。高校に入った最初の日を思い出してください。その日、人生のどんな日よりも、人間の弱さという感情を強く感じたでしょう。自分がちっぽけで、すっかり委縮してしまって、前の学校での実績はすっかり洗い流され、自分は何者でもない。そう、自分が何者でもない、ということを思い知るんです。 すべての人間が日々感じているこうした感情、たとえば、孤独、不安、怖れ、不満、怒りなど、あの高校一年生の時に感じたような気持ち、こうしたもののどれか 1つでもうまく利用できれば、そのプロジェクトは正しい方向に向かっていくでしょう。

Read more at location 3621


多くの製品開発チームは、製品やサイトにとってビジュアルデザインが本当に重要だ、とは感じていない。そういうチームは、大切なのは機能やバリュープロポジション (顧客に提供する価値) であって、きれいな色、フォント、アイコン、レイアウトのようなものは、ムダでうわべだけのくだらないことだ、と主張する。私は、この考え方にはまったく賛成できない。私は、数多くの製品を見るにつけて、ワクワクするような製品では感情が一定の役割を果たしていて、その感情を生み出すのに直接影響を与えているのはビジュアルデザインだ、とますます強く確信するようになっている。

Read more at location 3648


個人向けインターネットサービスでは、ユーザビリティは避けて通れない。個人向けインターネットサービスというのは、ユーザーエクスペリエンスに尽きるからだ。ターゲットユーザーにとって使い方がわかり

Read more at location 3676


ユーザビリティでは、パフォーマンスも大きな要素であることも覚えておこう。ウェブページを読み込むのに時間がかかりすぎると、ユーザーは壊れていると思うか、嫌な思いをしたということでどこか別のサービスに行ってしまうだろう。

Read more at location 3680


個人向けのサービスを提供している会社が出くわすサプライズの中でも、最大の (そしていちばん不愉快な) ものの 1つが、顧客サポートに関することだ。最高のサービスを提供している会社ですら、従来からの顧客サポートでは、たちまち破綻まで追い込まれる可能性がある。

Read more at location 3704


顧客サポートの費用をなんとしても最小限に抑えるような製品を設計して構築する以外、選択の余地はない。

Read more at location 3708


いい製品であれば、ユーザーは、自分の経験を友だちや家族や同僚と共有したいと思うだろう。それこそが、製品を提供する側が望んでいることだ。これはいちばん強力なマーケティング手法だ

Read more at location 3719


すべての会社は顧客に依存しているけれど、個人向けインターネットサービスを提供している会社にとっては、このユーザーコミュニティがいっそうの影響力と重みを帯びてくる。

Read more at location 3744


たくさんの顧客に会って、その声に耳を傾けることは絶対にやるべきだ。ただ、顧客に製品要求を決める能力があると期待してはいけない。

Read more at location 3808

npm run eject で create-react-app はアプリケーションの長寿を保証する

create-react-app すごい。React アプリを開発する環境構築が圧倒的に楽になった。

開発も素早く始められて build も一瞬で出来るように用意されている。Rails なんかもこうやって参入障壁を下げていくことで広まったのかなと思う。

npm run eject

まだ始めてみたばかりで諸々見ている最中なのだが、用意されている npm コマンドの中に一つだけよくわからない npm run eject というのがあったので調べた。

TL;DR

npm run ejectcreate-react-app の裏側で react-script を介して使われている諸々のツール・スクリプトをコピーしたり、依存関係を package.json に書き込んだりして、自分で用意したのと同じ状態にするコマンド。実行以降、好きにカスタマイズし放題となる。

これがいつでも出来るのでロックインを回避できる、create-react-app が死んでもアプリケーション側で自前でこれらのツールを制御することが出来る。

つまり、create-react-app はこのツールよりも、アプリケーションの方が長いライフサイクルを持てることを保証するということ。

多くのユーザーから使われるツールになるためにここまで考えているのは純粋に凄いと思う。

公式

You can “eject” to a custom setup at any time. Run a single command, and all the configuration and build dependencies will be moved directly into your project, so you can pick up right where you left off. https://github.com/facebookincubator/create-react-app#philosophy

"カスタマイズ用にいつでも「取り出す (eject) 」ことができる。 単一のコマンド ( npm run eject ) を実行するだけで、すべての構成とビルドの依存関係がプロジェクトに直接移動されるため、中断した箇所からすぐに再開できる。"

If you’re a power user and you aren’t happy with the default configuration, you can “eject” from the tool and use it as a boilerplate generator.

Running npm run eject copies all the configuration files and the transitive dependencies (Webpack, Babel, ESLint, etc) right into your project so you have full control over them. Commands like npm start and npm run build will still work, but they will point to the copied scripts so you can tweak them. At this point, you’re on your own.

Note: this is a one-way operation. Once you eject, you can’t go back!

You don’t have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. https://github.com/facebookincubator/create-react-app#converting-to-a-custom-setup

"もし「パワーユーザー」としてデフォルト設定に満足できない場合は、ツールから「取り出し」てボイラープレートジェネレータとして使用できる。

npm run eject を実行すると、すべての設定ファイルと依存関係(Webpack、Babel、ESLint etc.)がプロジェクトに完全にコピーされるので、完全に制御できます。npm startnpm run build のようなコマンドは引き続き動作する。これらはコピーされたスクリプトなのでカスタマイズが可能になる。

注: これは片方向操作であり、 いったん eject したらもう戻れない!

eject を使用する必要はない。キュレーションされた機能セットは、小規模から中規模の開発に適しており、この機能 (eject) を使用する必要はない。 "

npm run eject 試す

実際に何が起きるか試してみる。

$ create-react-app hello
$ cd hello
$ npm run eject # and answer `y`

実行前後の Diff

長いので特に解説しないが、特に pakage.json を見ることで使われているツールが見て取れる。

gist.github.com