今は画面をクリックすると猫が方向転換するだけだけど、
- 猫が歩く方向を向く
- 躍動感ある gif にする
- クリックした場所に魚を置く
- 猫がそこに寄っていく（スピードアップする）
- 到達すると食べる
- だんだん太っていく
とかやりたい。
kpt-bot を使って KPT も Slack に集約しよう
ohbarye.me
Twitter や GitHub のプロフィール欄にある「あなたの web サイト」的な箇所に登録するリンクがこのブログだったり GitHub の個人アカウントへのリンクだったり、統一感がなくて良くない！となんとなく思い立って About me page を作ってみた。
~ttp://ohbarye.me~ https://ohbarye.github.io/ へ移行しました。
GitHub - ohbarye/ohbarye.github.io: My profile 🐟 🐈 💨
とりあえずは色んなリンク置き場ぐらいの立ち位置で。
typography
デザインに対するセンス・知識・造詣ひっくるめて自分には欠けているので、とにかく typography (他人の土俵) で勝負するしかないと思った。
Google Fonts を眺めていたら Lato という良さそうなのがあったのでこれを使うことにした。
うわっ、私のサイトBootstrapくさすぎ!? たった数文字変えるだけでBootstrapのくさみが抜ける7つのCSSテクニック。などを読みつつてきとうに調整した結果…
h1, h1, a タグ並べただけだが、なんとなく"らしさ"が出た気がする。
面白み
ここからが良くないところだった。
「"シンプルで洗練されてます"感が出てるけど、これだけじゃつまらないよな…」
「凝ったデザインはしたくないけど、ランダムに図形をレンダリングするのは面白そう」
「canvas を使ってみよう」
などと思い始めてちょっとしたスクリプトを書いた結果…
ポップなドットが大量に並んで草間彌生デザインみたいになった。
動くコンテンツ、そっちに目が行ってしまって良くない。けど、<marquee> 時代のセンスなので「読み物でもないし良いかな…」ぐらいの気持ちでいる。
プログラマのページとして、何かしら動的なコンテンツがあった方が"らしい"のだろうか。それとも洗練された typography の前では何も要らないのだろうか。
いずれにせよもっと良いデザインや面白いアイディアを思いついたら更新する。
独自ドメイン
http://www.onamae.com/ で初めて取得した。GitHub pages への適用方法は以下を参考に行った。
『Inspired: 顧客の心を捉える製品の創り方』読んだ
マーティ・ケイガン の『Inspired: 顧客の心を捉える製品の創り方』を読んだ。
この本は社内の日報・ポエム置き場のようなレポジトリで CTO が紹介していて、その場で購入したのだけれどずっと kindle 内に積んだままになっていた。
うーん、これは、もっと早く読むべきだった。
内容
いわゆるプロダクト開発・マネジメントのベストプラクティス集。
Hewlett-Packard、Netscape、eBay など名だたる企業でプロダクトマネージャーとして働いてきた著者の経験だけでなく、知人友人その他あらゆる人脈から収集したテクニックがあますところなく紹介されていて、とにかく凝集度が高い。
219ページしかないらしいのだが、毎ページ進むたびにハイライトしたくなる（傍線を引きたくなる）。
顧客向け（BtoC）のソフトウェアプロダクトが中心だが、企業向け（BtoB）ソフトウェアに関するテクニックも多く紹介されている。ソフトウェアに限らない話も多い。
感想
これまでソフトウェア開発で経験してきて知っていること、わかったつもりで誤解していたこと、解決の仕方がわからなかったこと、ぼんやりと考えてはいたが言語化できていなかったことがことごとく語られていて、うーん、これは、もっと早く読むべきだった（2回目）。
現職の周囲の人々に限らず、世の中にはこれを読んで欲しい人がたくさんいる。
そして、あまりにも多くのことがこの1冊でまとめられているので個々の話題に触れていくとまったく語り終わる気がしない。
製品（プロダクト）と感情
特に印象に残った、製品と感情の関係について。同書では第34章で語られていた。
サイエンスやビジネスのバックグラウンドを持つ我々が最も真剣に向き合わなければならないので人間の感情だった、という皮肉ぽい話でぞくっとした。
人々は、ふつうは、感情的な理由で製品を買って、製品を使う。
これについては経験から思うところがあったので別の記事を今度書いてみたい。
欠点
本当に良い本なのでこれを殊更取り上げて言うほどのことなのかわからないけど、脱字が多かった。
あまりにも多く感じたので途中から見つけた脱字はすべてハイライトした。Amazon に報告すればクーポンがもらえるのだろうか。
Highlited
ハイライトした箇所の抜き出し。
Inspired: Kokyaku No Kokoro O Toraeru Seihin No Tsukurikata (Japanese Edition)
プロダクトマネージャーの主な任務としては 2つある。製品の市場性を評価することと、開発すべき製品を定義することである。
ソフトウェア開発の組織には、プロダクトマネージャーとデザイナーとエンジニアの人数について、適正な割合があることがわかっている。
ダメな製品が無駄に世に送り出されるいちばんの原因は、ほとんどの場合、会社の中でプロダクトマネージャーの役割が明確にされていないことと、プロダクトマネージャーとなる人に対する教育が不十分なことにある。
プロダクトマネージャーの役割は、エンジニアリングチームが作り上げるべき製品を詳細に定義することである。これに対して、プロダクトマーケティングの役割は、世界に対して製品を語ることである。この 2つはまったく違う仕事である。
プロダクトマネージャーの役割は、作りたい製品のプロフィールを細かいところまで決めることと、実際の顧客やユーザーとともに製品を検証することである。
担当者の肩書きや社内の組織体系がどうあれ、あらゆる優れた製品の陰には、責任を持ってその製品のプロフィールを決めた 1人の人間がいる、と私は断言する。
プロダクトマネジメントの役割が、価値のある、使いやすい、実現可能な製品を見つけ出すことにあるのに対して、プロジェクトマネジメントの役割は、製品を市場に送り出すことに尽きるからだ。
企業向けのサービスである場合は、ライバルに差をつけるいちばんの近道の 1つが、ユーザーエクスペリエンスをよくすることである。一般的に、多くの企業向けの製品では、ユーザーエクスペリエンスがかなりおろそかにされているからだ。
製品を必要最小限までそぎ落とすことに集中すること。後でもっと詳しく説明するが、ともかく、プロダクトマネージャーの仕事は、究極の製品を定義することではなく、目的を達成するために必要最小限までそぎ落とされた製品を定義することである。
開発チームと離れていればいるほど、また、言葉や文化や時差のためにコミュニケーション上の課題が大きければ大きいほど、製品仕様を決める段階でしっかり完璧に作業しておく必要性に、いっそう強く迫られることになる。プロジェクトとして最悪なのは、プロダクトマネージャーが何を作りたいのかよくわかっていない (あるいは、コロコロ考えを変える) ために、離れた所で作業しているチームがもがき苦しむことだ。
プロダクトマネージャーは、エンジニアリングチームのキャパシティ全体の 20% を空けておいて、これをエンジニアリングチームの判断で使える予備の枠として与える。エンジニアリングチームは、たとえば、コードを書き直したり、アーキテクチャーをやり直したり、コードのダメなところをリファクタリングしたり、データベースのシステムを入れ換えたり、システムのパフォーマンスを改善したり、といった作業のためにこの枠を使うことができる。つまり、「開発を中断してコードを書き直さなければだめだ」と言い出す事態を避けるために必要だと思うことであれば、何でもである。
eBay は瀕死の状態を経験してからは、二度と危機的な状況に陥ることがないような体制をしっかり整えた。問題が深刻になる前に、さっさとコードの書き直しを始めるようにしたのだ。実際のところ、eBay は、サービスが急成長する中で 3回もコードを書き直して、3回目のときはサイト全体を別のプログラミング言語とアーキテクチャーに置き換えた。彼らは、この何百万行もの膨大な量のコードを数年かけて書き直し、同時に、記録的な数の新しい機能も追加した。そして、何よりも、ユーザーに不自由な思いをさせることなく、こうした作業をやってのけたのだ。
長い時間をかけて 1つの領域に精通してしまうと、プロダクトマネジメントのもう 1つのワナに落ちてしまうことがある。それは、自分がターゲットである顧客を代弁する人間で、実際以上に自分がターゲットである顧客に近い存在だと思い込むようになるのだ。プロダクトマネージャーというものは、自分の担当する分野や顧客について自分が考えていることを、絶えず問い直さなければならない。
最近、ビジネスにおける新たな測定基準が、多くの業界で注目を集めている。ネットプロモータースコア (NPS)
特注品 (特定の顧客向けの製品のことで、だいたいは、製品の購入を確約してもらう見返りとして、特別仕様の仕事を引き受ける) に走るのはかなり危険だ。これは悪い売上の典型であり、会社がユーザーを幸せにする製品を作り出す力をダメにする。
私が仕事をした会社でいちばん多かったのは、マーケティング部門の中にプロダクトマネジメントがあるパターンだ。この組織体系でまずいのは、製品は顧客と話すことから生まれるもので、そのために顧客と話すのはマーケティング部門の仕事だ、という間違った考え方に基づいている点だ。
「どうやるかを指示してはならない。何をすべきかを指示すればいい。そうすれば、彼らの創意工夫に驚かされるだろう。」
現実には、顧客やユーザーが何かいい解決策を思いつけるわけではない。彼らには、そもそも何ができるのかなどわからないのだから、どうやって解決するかを前もって想像するのはかなり難しいだろう。
デザイナーというのは、製品開発のうんと早い段階、つまり、プロダクトマネージャーがターゲットとなる市場を把握してソリューションを考えている段階から参加してこそ、その真価を発揮できるのだ。
この会社のせ製品は、
効果的な製品の市場性評価をやるのは、それほど難しいことではない。私のやり方では、プロダクトマネージャーに、10個の基本的な質問に答えてもらうことにしている。 製品化によって具体的にどんな問題を解決するのか？ (バリュープロポジション) だれのためにこの問題を解決しようとしているのか？ (ターゲット市場) 市場の大きさは？ (市場規模) 製品化の成功をどうやって評価するのか？ (指標、収益戦略) 現在、他に競合する製品はあるか？ (競合の見通し) なぜ当社がこの製品化をやるのに最適なプレーヤーと言えるのか？ (差別化要因) なぜ今なのか？ (市場投入の時期) どうやって製品を市場に出すのか？ (市場投入戦略) 成功のために絶対に必要な要素は何か？ (ソリューションの要件) これらを前提とした上で、最終的な提案は何か？（やるかやらないか）
最善のもの実施させるよう
製品となるどうかは、
見つけられるどう
並行して 2つのバージョンで作業を進めることである。つまり、バージョン1 のエンジニアリングが始まって、プロジェクトが実行段階に入ったら、すぐにバージョン2 の発案作業も開始する。新しいアイデアを生み出す努力は決して絶やさないようにするのだ。あるバージョンがエンジニアリングの段階に入ったら、発案力は次のバージョンに振り向けよう。
製品を見つけ出す段階というのは、あっさりクリアできてしまうこともあれば、ものすごく難しい場合もある。私の経験では、市場性がありそうなところを見つけ出して評価するのはそれほど難しくはないけれど、ソリューションを見つけ出すのに困難を極めることが多い。
社員の多くは、本当はそうではないのに、自分のことを製品のターゲットであるユーザーに近い存在と考えている (あるいは、ターゲットユーザーのことを実際以上に理解しているつもりになっている)。
経営陣は開発プロジェクトのうんと早いうちからコストについて知りたがるけれど、ある程度正確な見積りをするのに必要な情報をエンジニアリングチームが手に入れるのは、開発プロジェクトのずっと後になってからだ、ということにある (なぜなら、それまでは、必要とされるソリューションについてのまともな情報がほとんどないからである)。
ターゲットとする顧客をしっかり理解することと、製品の発売までに確実なリファレンスカスタマーを確保しておくこと、この 2つの課題に取り組むために私がお勧めするのは、ユーザーモニター制度 (charter user program) を利用することだ。
モニターは、間違いなくターゲット市場からの顧客やユーザーでなければならない。よく、アーリーアダプター (初期採用者) が集まってしまった、ということになりやすいものだ。こういう人々は、本来あるべきモニターよりもずっと寛容なので、結局はアーリーアダプターしか興味を持ってくれない製品になりかねない
プロダクトマネージャーは、ユーザーとの面談、ユーザビリティテスト、ユーザーモニター制度での打合せなど、自分が担当する製品に直接関係のあるものなら何であっても出席するべきだ、
すばらしい製品を発見するために必要な洞察力を得ること、それは、ユーザーとなる人々を十分に理解できるようになって、それぞれが根底に抱えているニーズを掘り起こすことから始まる。そういう洞察力は、「このページをカスタマイズして、１人当たりの作業時間を表示したレポートを出す必要がある」とか、「ユーザーの 72% がもっと解像度の高いビデオがいい、と言っていた」、というような表面的な会話からでは得られないだろう。
ユーザーの一部には、目指すべき製品のプロフィールに仕立てていくとか、ユーザーとして示してくれる洞察力のレベルとかいった点で、他のユーザーよりもずっと優秀な人がいる。そういう人たちとは、継続的な関係を作っていこう。
顧客アンケートで得られるデータは、解決策そのものを示すものではなく、解決策にたどり着くためのインプットの一部でしかない、
どんな製品でも少しぐらいはいいところがあるもので、それを見つけるのがみなさんの仕事である。ライバルの製品のいいところや誤りを教訓にしよう。
市場調査による情報は、製品を創造するプロセスへのインプットの一部とはなるけれど、市場調査で製品の方向性を決めようとすると、問題を抱えることとなる。
何が必要のかを
アラン・クーパー (Alan Cooper) の「コンピュータは、むずかしすぎて使えない！」(山形浩生訳、原題は The Inmates are Running the Asylum)
あらゆる人々を満足させる製品にしようというのは、実によくある間違いであり、結局はだれも満足させることができない。
製品開発チームがいちばんよくやってしまう間違いとしては、自分たちを顧客と混同するというのも挙げられる。私がとにかくペルソナを気に入っているのは、よくありがちなこの問題に光を当てるのに役立つからだ。
ハイファイプロトタイプは、ここで挙げた条件に合っていることに加えて、紙ベースの仕様書と違ってテストできるところが最大のメリットだと思う。実際のターゲットユーザーの前に置いて、使い方がわかりやすいかどうか (ユーザビリティ) を確認することができるし、ユーザーが使いたいと思うかどうか (バリュー) も判定できる。プロトタイプがこの 2つのテストをパスするまでは、エンジニアに渡す意味のある製品仕様にはなっていない、ということだ。
いいプロタイプ作成
ユーザーが何を言うかではなく、何をするか、もっと注意して観察してほしい。
製品化によって解決しようとしている問題に対して興味を示してくれる人がなかなか集まらない、あるいは、どうすれば製品をわかりやすく使いやすいものにしてターゲットユーザーに価値を認めてもらえるのか、どうしてもわからない、という判断になることがあるかもしれない。そんな時は、そこで中止して、アイデアを棚上げしよう。
機能を追加することは、結果的に状況を悪くするだけで、何の改善にもならないことがあまりにも多い。
製品の改善は、新しく製品を開発する場合と同じように、何を達成しようとしているのかをよく理解するところからすべてが始まる。
一部の顧客が追加を望んでいる機能であるとか、調査結果だからとか、フォーカスグループがそう言っている、というような話ではないことを忘れないでほしい。大切なのは、製品の出来を表す数値を狙った方向に動かしてくれるのは何であるか、ということだ。
スクラムにしろ、XP (eXtreme Programming) にしろ、アジャイル開発手法には多くのメリットがあるのだけれど、そもそもカスタムソフトウェア (個別の顧客の要求に基づいて作られる特注のソフトウェア) の開発のために考案された手法
プロダクトマネージャーは、プロダクトオーナー (訳注：直訳すると、製品の発注者、すなわち、製品開発プロジェクトの施工主の意) であり、その製品の顧客を代弁する立場にある。
アジャイル開発手法というのは、もともとカスタムソフトウェアの世界で生まれたということだ。 特定の顧客のために特定の目的のソフトを作るというカスタムソフトウェアの世界では、ひどく厄介な作業を強いられてきた。その理由の 1つは、顧客は、自分では何が必要なのかをわかっていないのに、何かが必要だからということで、とりあえずカスタムソフトウェアを作る会社に発注したり、社内の IT部門に依頼を出したりするためだ。
カスタムソフトウェアを開発する会社は、トップクラスのソフトウェア開発者を採用して抱えておくことに関しては、ずっと貧乏くじを引かされてきている。
歴史的には、カスタムソフトウェアの世界ではウォーターフォールプロセスが採用されているけれど、それは、開発を委託されたアプリケーションが作られていく長いプロセスにおいて、さまざまな関係者がその進み具合を監視する方法が必要だったからである。実際、ウォーターフォール型開発手法もまた、このニーズから始まったものである。
大規模で複雑なソフトウェア開発プロジェクトですら、かなり正確なスケジュールを作ることは可能だ。ただ、これは、完全かつ正確に要求仕様と必要な技術を理解していること、そして、仕様の変更が発生しないことを前提としている。
多くの点で、ウォーターフォールプロセスは、理想的ではあるけれどおめでたいとしか言いようがない考え方を象徴している。それは、人は、すべての主要な問題を予測することができて、要求仕様を完璧に理解できる、ということだ。もしそういう状況なのであれば (普通はうんと小さいプロジェクトに限られるけれど)、ウォーターフォールを使ったアプローチは、品質の高い実装を可能にする合理的な方法となり得るだろう。
製品ソフトウェアでは、そういうことはめったに起こらない。実際にどうなるかというと、仕様の変更のために製品は計画より遅れて発売され、いったん現実のユーザーがそのソフトを目にして使い始めると、問題を修正するために、費用と時間をかけて追加のリリースをやらなければならなくなる。
プロダクトマネージャーなって、
どんなベンチャー企業であっても、すべては正しい製品から始まるということを認識する必要がある。だから、順番として最初にやるべきことは、50万ドルやらの創業資金を使い果たしてしまう前に、何が正しい製品であるのかをまず理解することなのである。
大きい会社でのイノベーションを可能とするかどうかを左右する最大の要因は、企業文化と上司の 2つである。
多くの場合、最高のアイデアというのは下から上がってくるものだ。20%ルールのすごいところは、数多くのアイデアを試すことができることにある。自分がアイデアを思い付いたという自負心があるので、そのアイデアはより強い熱意と創造力で追求されるのである。
スカンクワークス (skunk works) というのはずいぶん古い業界用語で、もともとは秘密の軍事プロジェクトを指す言葉だった。今では、社内の官僚主義に邪魔されないように、他の人に気づかれないようにしながら、必要であれば個人の時間も使ってアイデアを追いかける、という意味で使われる。
正式な業務きちんと
覚えておいてほしいのは、イノベーションがまったく新しい問題を解決してくれることはめったにない、ということだ。ほとんどの場合、イノベーションとは、今ある問題を新しいやり方で解決することなのである。人々が今のソリューションに手を焼いているのを観察するのは、イノベーションのチャンスを浮かび上がらせるには最高の方法なのである。
いっしょこのアイデア
私の友人であるデービット・ウェイデン (David Weiden) の言葉は、大企業で働く多くの人がどんな状況に置かれていてどんなチャンスに恵まれているかを的確に言い表している。「多くの人は、暗闇の中をさまよい、 暗い暗いと文句ばかり言っていて、どこにスイッチがあるのを知ろうとしない。」
他のどのハードウェア企業とも違って、アップルは、ハードウェアの役割はソフトウェアを支えることであり、その逆ではない、ということを理解している。
もしアップルが技術系の会社として何か秘伝のソースを持っているとすれば、それは、こういうことだと思う。消費者が製品を欲しくなるとき、製品を手に入れるとき、製品に惚れ込むときに感情が果たす役割というものを、アップルは他のだれよりもよく理解しているのだ。アップルは、どうやって消費者の感情に語りかける製品を作るかを心得ている。
特別仕様の何が悪いのだろうか？ 製品を作る会社は、顧客の要求をあるべき製品要求と取り違えることで、まず間違いなく道を踏み外す。
なぜ顧客を当てにすることができないかを説明してきた。その理由をここでおさらいしよう。第一に、顧客にとっては、実際にそのものを目にするまでは、自分が何を必要としているのかを理解するのはとても難しい。第二に、顧客は、どんな技術が可能であるかを知らない。第三に、共通のテーマを確認するために顧客同士が交流することはめったにない。
次なる新しい目玉は何か、と思いを巡らせるのは、いつだって楽しいことだけれど、その目玉は、まったくの新しいものというよりは、むしろ、古いものの新たな生まれ変わりである。何が違うのかというと、新しく生まれ変わった製品は、以前の製品よりもずっといい、ずっと速い、あるいは、ずっと安いので、その製品ジャンルに変革を迫ることになるのだ。
ユーザーを手こずらせる製品がある限り、他のだれかがそれを改良するチャンスがある。
可能なことはいつも変化している。今日実現できないからといって、明日もムリとは限らない。
今日のアプリケーションは、明日のインフラである。この世界のビジネスは、そうやって成り立っている。
いいビジネスチャンスが完全になくなってしまうなんて、あり得ない。
人々は、ふつうは、感情的な理由で製品を買って、製品を使う。優秀なマーケティング担当者は、このことを理解しているし、優秀な製品開発担当者は、製品を人々の感情に訴えかけるようにしようとする。
感情というレンズを通して見れば、ユーザーや顧客が製品やサービスのことを、さらには潜在的な競争相手のことをどう見ているのかという視点にもっと近づいて、物事を見ることができるようになってくる。顧客は、他にはどこに行けばこういう欲求を満足させることができるのか？ こういう感情により直接的に訴えかけるには、ビジュアルデザインはどうすればいいか？ こういう感情にわかりやすく訴えかけることを邪魔している機能は何なのか？
ベンチャー企業がキャズムに陥ってしまう理由の 1つは、状況を見誤るから、つまり、「合理性より感性タイプ」と「テクノロジー大好きタイプ」を混同してしまうからなのです。
プロダクトマネージャーには何を探し求めるように指導していますか？ J：怒り、憤慨、不満を探せ、と。ぼくらが嫌いになってしまうようなありとあらゆるもの、電話会社、銀行、消費者金融会社、税務署の職員、官僚、航空会社、医療機関などを見れば、こういうものはみんなイノベーションの絶好のチャンスです。なぜなら、消費者の潜在的な不満がものすごく高いからです。
ぼくたちが問うのは、「どんな感情が行動を駆り立てるのか？」ということです。そして、こういう感情を、製品の機能やそのほかのすべてのものに利用する方法を探します。それぞれのプロジェクトでは、どんな基本的な感情に訴えるのか、そして、ユーザーの苦しみがどれほど深刻なのかを評価します。
ぼくが使うテクニックに、「フレッシュマンテスト」と呼んでいるものがあります。高校に入った最初の日を思い出してください。その日、人生のどんな日よりも、人間の弱さという感情を強く感じたでしょう。自分がちっぽけで、すっかり委縮してしまって、前の学校での実績はすっかり洗い流され、自分は何者でもない。そう、自分が何者でもない、ということを思い知るんです。 すべての人間が日々感じているこうした感情、たとえば、孤独、不安、怖れ、不満、怒りなど、あの高校一年生の時に感じたような気持ち、こうしたもののどれか 1つでもうまく利用できれば、そのプロジェクトは正しい方向に向かっていくでしょう。
多くの製品開発チームは、製品やサイトにとってビジュアルデザインが本当に重要だ、とは感じていない。そういうチームは、大切なのは機能やバリュープロポジション (顧客に提供する価値) であって、きれいな色、フォント、アイコン、レイアウトのようなものは、ムダでうわべだけのくだらないことだ、と主張する。私は、この考え方にはまったく賛成できない。私は、数多くの製品を見るにつけて、ワクワクするような製品では感情が一定の役割を果たしていて、その感情を生み出すのに直接影響を与えているのはビジュアルデザインだ、とますます強く確信するようになっている。
個人向けインターネットサービスでは、ユーザビリティは避けて通れない。個人向けインターネットサービスというのは、ユーザーエクスペリエンスに尽きるからだ。ターゲットユーザーにとって使い方がわかり
ユーザビリティでは、パフォーマンスも大きな要素であることも覚えておこう。ウェブページを読み込むのに時間がかかりすぎると、ユーザーは壊れていると思うか、嫌な思いをしたということでどこか別のサービスに行ってしまうだろう。
個人向けのサービスを提供している会社が出くわすサプライズの中でも、最大の (そしていちばん不愉快な) ものの 1つが、顧客サポートに関することだ。最高のサービスを提供している会社ですら、従来からの顧客サポートでは、たちまち破綻まで追い込まれる可能性がある。
顧客サポートの費用をなんとしても最小限に抑えるような製品を設計して構築する以外、選択の余地はない。
いい製品であれば、ユーザーは、自分の経験を友だちや家族や同僚と共有したいと思うだろう。それこそが、製品を提供する側が望んでいることだ。これはいちばん強力なマーケティング手法だ
すべての会社は顧客に依存しているけれど、個人向けインターネットサービスを提供している会社にとっては、このユーザーコミュニティがいっそうの影響力と重みを帯びてくる。
たくさんの顧客に会って、その声に耳を傾けることは絶対にやるべきだ。ただ、顧客に製品要求を決める能力があると期待してはいけない。
npm run eject で create-react-app はアプリケーションの長寿を保証する
create-react-app すごい。React アプリを開発する環境構築が圧倒的に楽になった。
開発も素早く始められて build も一瞬で出来るように用意されている。Rails なんかもこうやって参入障壁を下げていくことで広まったのかなと思う。
npm run eject
まだ始めてみたばかりで諸々見ている最中なのだが、用意されている npm コマンドの中に一つだけよくわからない npm run eject というのがあったので調べた。
TL;DR
npm run eject は create-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 start や npm run build のようなコマンドは引き続き動作する。これらはコピーされたスクリプトなのでカスタマイズが可能になる。
注: これは片方向操作であり、 いったん eject したらもう戻れない！
eject を使用する必要はない。キュレーションされた機能セットは、小規模から中規模の開発に適しており、この機能 (eject) を使用する必要はない。 "
npm run eject 試す
実際に何が起きるか試してみる。
$ create-react-app hello $ cd hello $ npm run eject # and answer `y`
実行前後の Diff
長いので特に解説しないが、特に pakage.json を見ることで使われているツールが見て取れる。
GitHub Issue Reader の Jasper を1週間使っての所感
Jasper 使い始めた - valid,invalid で書いたとおり、GitHub の通知管理を Gmail から Jasper へ乗り換えてみた。
一週間使っての所感とかメモ。
所感
- 初日は Gmail と Jasper を両方見て両方の未読を消化したくなってしまった
- 自分のアクティビティも通知されてドキッとする
- GitHub のメール通知では
Include your own updatesをオフにしている
- GitHub のメール通知では
- GitHub のメール通知（コメント単位）よりもアクティビティの粒度が細かい（Assignee や Label の変更も含まれる）
- たまに通知を開くと何も起きていない？と思ったりするのでここを改善したい
- built in browser 含む3カラムをフル画面で表示している
- 各 issue / PR といったアイテムを開くのが遅い
- built in browser にしろその他のブラウザにしろ、毎回ページをロードするので Gmail でメールを開封していくのよりはどうしても遅くなってしまう
- unread のアクティビティにスクロールしてくれ、かつ未読のコメントに付けてくれるのでどこまで読んだか / どこから読めばよいかが圧倒的にわかりやすい
- 覚えることは多くないので公式ドキュメントはあまり見ていない（良いことだと思う）
- team へのメンションを
mention:username/teamnameのように書いていて通知されないなーと思った時だけ見た（team:username/teamnaseが正しかった）
- team へのメンションを
改善要望
Include your own updatesをオフにしたい- 通知するアクティビティを絞りこめるようにしたい
- 開封をより高速に行える
- [minor] クラウドで同期？今のところ必要ない
うまいやり方があれば教えて欲しいです。
「Jasper か Slack を見ておけば通知を見逃すことはない」というところまであっさり近づけたので、（無料のクーポンで手に入れたものの）有料で買っても良かったと思う。
Jasper 使い始めた
Node 学園祭2016 で 100% OFF のクーポンコードをもらったので Jasper 使い始めてみた。
これまで
Gmail の Fileter / Label 機能で頑張ってきた。
各種サービスからの通知や Google Calendar の invitation など、GitHub の notification 以外から受け取るメールも大量にあるので「Gmail か Slack を見ておけば通知を見逃すことはない」という状況を作り、スイッチングコストを下げてきた。
上記の理由により確認すべきプラットフォームが増えるのは正直よくないことなのだが、よりリッチな通知管理が無料で出来るならと思って試してみる。
GitHub から来る通知以外でそれほど緊急度の高いメールを受け取る機会もほぼないので、純粋に「Jasper か Slack を見ておけば通知を見逃すことはない」ということになってほしい。
Jasper について
少し触ってみたところ、かなりサクサク動く。また、わかってはいたが Gmail よりも見やすいし、より細かい設定もできる。デスクトップアプリ作りたくなってくる…。
技術的なところで言うと
- Electron
- GitHub に polling するところで async/await を使いまくっている
- アプリ内のデータの保存には SQLite
Mac ぽいデザインにするために Photon を使っている
という話を聞いてなるほど〜と思っていたが blog にも詳しく書いてあった。
今日のところはセットアップだけ、明日からどう通知管理が変わるだろうか。
