栞/#creating
- 2014年9月
「Airbnbのブライアン・チェスキーCEOが、「100万人が割と好むモノよりも、100人が愛するモノを作る方が良い」と言う名言を残している。」
- 2014年8月
「上述の記事 では、マイクロサービスの特徴が九つほど上げられています。 サービスによるコンポーネント化：ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。 ビジネスケイパビリティに基づく組織化：役割ごとにチームが構成されるのではなく、複数の役割が混在したチームがひとつのサービスを構築する。（コンウェイの法則！） プロジェクトではなくプロダクト：コンポーネントは期限のあるプロジェクトとして開発されるではなく、継続的なプロダクトとして提供される。 スマートエンドポイント、ダムパイプ：サービス間のメッセージは、HTTP経由でAPI呼び出しされるか、RabbitMQやZeroMQといった軽量メッセージングシステムによる通信で交換される。 分散ガバナンス：サービスごとに言語やデータベースなどは統一されず、個別に適切なものが選択される。 分散データ管理：サービスごとにデータを持ち、統合されていない。 インフラストラクチャ自動化：継続的デリバリが実現され、自動テスト、自動デプロイなどが採用されている。 障害設計：構成されるサービスの障害に耐性を持つように設計されている。 進化的設計：各サービスごとに変更が行なわれ、漸進的に設計がされる。」
「1チーム1アプリケーションになるように、マイクロサービスにアプリケーションを分割することです。 アプリケーションが単機能であり、それに関わっている開発者も数名という状況であれば、マイグレーションはうまく機能することが分かっています。」
「エンジニアは「Webサービスは(言語・ライブラリ・関連しているサービスの影響などで)メンテナンスしないと壊れる。」などと思っているのに対して、非エンジニアはなんとなく「ほっとけば動いてそう。」と思ってる気がします。 なので、最近は「メンテナンス大変なんですよー」じゃなくて「ほっとくと壊れるんですよー」とかよく言ってます。なにか他にもっと気の利いた言い方あります？」
「使ってもらうのではなく、使う」
「“この店は美味しい”。行列ができている理由は、ただそれだけである。」
「メールを書いたり、チャットしたりということが、理由も無くできなくなることが人にはあるのですよね。だから、もっと簡単に、もっとシンプルにお互いが気持ちを伝えることができればコミュニーションのフラストレーションを減らせるんじゃないかと」「Slidropであらためて学んだことは、“今、既にあるサービスを良くした”くらいではダメだということ。Decologで似たサービスが後から沢山出てきてそれをよく知っていたはずだったのに、同じ失敗をしてしまったのですね。当たり前ですが、ユーザーにサービスを使ってもらうためには、もっとエポックである必要があります」
「サービスを大きくする必要がなければ、自分の手に収まる範囲で、自分の想定するターゲットにフォーカスすることができる。より多くのユーザを集めるために、自分が必要だと思う以上の機能を盛り込んだり、デザインで登録を促したり、自分が想像できない層まで無理やりターゲットを広げる必要もない。サービス自体を完全にコントロールすることができる。」
「自分が「エコシステム」の中のどういう位置にいて、何と協力して何と戦うのか、そういう自己認識がないと、これから何を勉強したらいいか、何を勉強させたらいいか考えようがない。」
「１つは、技術者が成長する視点を「そのサービスに関わっているからこそ得られる経験である」という部分を意識していくこと。会社に技術を売る実装屋ではなく、お客様に優れたユーザ体験を提供する「Webサービス」を作っているんだ、という自覚を持っていただく。 もう１つは「どんな言語トレンドでもどんとこい」という自信をつけていくこと。技術的興味を維持することは大切だし、また、技術的に置いて行かれる不安感を解消するためにも、仕組みが必要だと思っている。」
「人やシステム同士のコミュニケーションであることを意識し、情報がどう伝わるか、どう理解されるか？について、こだわることこそが「良いWeb開発者の定義」だと思っているし、僕はそうなって欲しいと思っている。」
「結果、1位「直接会って話す（38.8％）」、2位「匿名のソーシャルメディアやメッセンジャーアプリ（18.4％）」、3位「実名のソーシャルメディアやメッセンジャーアプリ（6.6％）」というトップ3となりました。なるほど、同じソーシャルメディアやメッセンジャーアプリでも、匿名は実名より10ポイント以上も勝っているのだな……。」