栞/#creating
「上述の記事 では、マイクロサービスの特徴が九つほど上げられています。 サービスによるコンポーネント化：ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。 ビジネスケイパビリティに基づく組織化：役割ごとにチームが構成されるのではなく、複数の役割が混在したチームがひとつのサービスを構築する。（コンウェイの法則！） プロジェクトではなくプロダクト：コンポーネントは期限のあるプロジェクトとして開発されるではなく、継続的なプロダクトとして提供される。 スマートエンドポイント、ダムパイプ：サービス間のメッセージは、HTTP経由でAPI呼び出しされるか、RabbitMQやZeroMQといった軽量メッセージングシステムによる通信で交換される。 分散ガバナンス：サービスごとに言語やデータベースなどは統一されず、個別に適切なものが選択される。 分散データ管理：サービスごとにデータを持ち、統合されていない。 インフラストラクチャ自動化：継続的デリバリが実現され、自動テスト、自動デプロイなどが採用されている。 障害設計：構成されるサービスの障害に耐性を持つように設計されている。 進化的設計：各サービスごとに変更が行なわれ、漸進的に設計がされる。」
「1チーム1アプリケーションになるように、マイクロサービスにアプリケーションを分割することです。 アプリケーションが単機能であり、それに関わっている開発者も数名という状況であれば、マイグレーションはうまく機能することが分かっています。」
「エンジニアは「Webサービスは(言語・ライブラリ・関連しているサービスの影響などで)メンテナンスしないと壊れる。」などと思っているのに対して、非エンジニアはなんとなく「ほっとけば動いてそう。」と思ってる気がします。 なので、最近は「メンテナンス大変なんですよー」じゃなくて「ほっとくと壊れるんですよー」とかよく言ってます。なにか他にもっと気の利いた言い方あります？」
「使ってもらうのではなく、使う」
「“この店は美味しい”。行列ができている理由は、ただそれだけである。」
「メールを書いたり、チャットしたりということが、理由も無くできなくなることが人にはあるのですよね。だから、もっと簡単に、もっとシンプルにお互いが気持ちを伝えることができればコミュニーションのフラストレーションを減らせるんじゃないかと」「Slidropであらためて学んだことは、“今、既にあるサービスを良くした”くらいではダメだということ。Decologで似たサービスが後から沢山出てきてそれをよく知っていたはずだったのに、同じ失敗をしてしまったのですね。当たり前ですが、ユーザーにサービスを使ってもらうためには、もっとエポックである必要があります」
「サービスを大きくする必要がなければ、自分の手に収まる範囲で、自分の想定するターゲットにフォーカスすることができる。より多くのユーザを集めるために、自分が必要だと思う以上の機能を盛り込んだり、デザインで登録を促したり、自分が想像できない層まで無理やりターゲットを広げる必要もない。サービス自体を完全にコントロールすることができる。」
「自分が「エコシステム」の中のどういう位置にいて、何と協力して何と戦うのか、そういう自己認識がないと、これから何を勉強したらいいか、何を勉強させたらいいか考えようがない。」
「１つは、技術者が成長する視点を「そのサービスに関わっているからこそ得られる経験である」という部分を意識していくこと。会社に技術を売る実装屋ではなく、お客様に優れたユーザ体験を提供する「Webサービス」を作っているんだ、という自覚を持っていただく。 もう１つは「どんな言語トレンドでもどんとこい」という自信をつけていくこと。技術的興味を維持することは大切だし、また、技術的に置いて行かれる不安感を解消するためにも、仕組みが必要だと思っている。」
「人やシステム同士のコミュニケーションであることを意識し、情報がどう伝わるか、どう理解されるか？について、こだわることこそが「良いWeb開発者の定義」だと思っているし、僕はそうなって欲しいと思っている。」
「結果、1位「直接会って話す（38.8％）」、2位「匿名のソーシャルメディアやメッセンジャーアプリ（18.4％）」、3位「実名のソーシャルメディアやメッセンジャーアプリ（6.6％）」というトップ3となりました。なるほど、同じソーシャルメディアやメッセンジャーアプリでも、匿名は実名より10ポイント以上も勝っているのだな……。」
http://gigazine.net/news/20140813-storemapper-bootstrapped-to-50000-dollars/
「課題自体がほとんど答えにもなっているというか、この課題に答えれば必然的に面白くなるというか……。そういう「枠組みの設計」が実は一番大事なんだと学びました。だから僕はよく、クリエイティビティーって何？ と聞かれると「課題を見つける力」って答えるんです。前提になる枠組みが適切なら、答えも絶対面白くなる。それが究極の創造力かなというのがあって。」
「しかし、自ら会社を立ち上げ、コミュニティを作ることで、彼らは高い独立意識を持つようになった。そしてソフトウェアの品質は急速に向上し始めた。」「しかもだ。日本で起業するということは、社会的に不安定で、失敗の代償も大きい。その結果、あえてスタートアップに挑む日本のエンジニアは、他のエンジニアより自信を持っているし、スキルも高い傾向にある。そして会社を成功させるために、惜しみない努力をする。」
「新たな技術というのは、10個のうち、1個成功すればいいという程度。何度も失敗しまくった結果、初めて成果につながる。イチローは4割を狙えるが、我々はそんなのは不可能。まずは、1割バッターを目指そうという気持ちでがんばっている」「いまは、数字よりも、社内の志気を高めるという点での効果が出ているといえそうだ。」
- プロダクトの成長に最も重要な6つの心得 / 【今まで本当にありがとうございました！】growth hack japanを退職します。 | グロースハックジャパン | growth hack japan
「グロースハックという言葉が一人歩きし、一部に誤った理解が広がってしまったことも事実。」「顧客が価値を見出せないプロダクトにいくら小手先の施策を講じても無駄」
「どこに理由があるにせよ、人を集めることができない創業者って論外な状態です。」
「価値がスポイルされるのは、作っている人間が最初に気づくはずだ。だからドッグフーディングできるものは可能な限りドッグフーディングした方がよい。」
「それは7割方ものごとができあがると、ゴールに向かって進んでいくところです。「ここは勝てる」となった時にアクセルをかけるということをやってのけるし、ダメだとなった時にはすぐに軌道修正もする。」「勝つためには誰より早く挑戦して、誰より早く失敗して、誰より早く復活する」