タグ

ブックマーク / blog.kentarok.org (35)

  • リリースの高速化はWebサービス企業にとって最重要である - Kentaro Kuribayashi's blog

    インターネットを眺めていたら、リリースの高速化自体を目的化するのではなく、ビジネス成果によって成否を判断するべきだという主張があったので、思うところを書いておく。起点は他社さんにおける議論だが、そこは問題ではなくて、もし自分の関わるところでそういう議論が起こったら、自社の技術に対してそれなりのポジションにおいて関係する人間としてどのように考えるべきだろうかという視点で述べる。 リリースあるいはリリースの高速化自体を目的化するのではなく、その結果としてのビジネス的成果が大事だということは、マネジメントにとっては当たり前なわけで、いちいちいうまでもないことだろう。そもそも、サービスが圧倒的に成長し続けていれば、リリース頻度 = 成果になるはずだ。現状そうでないのであれば、成長速度が遅いということになる。エンジニア技術を尽くしてリリース速度を向上させたにも関わらずそれが成果に結びつかないとした

    リリースの高速化はWebサービス企業にとって最重要である - Kentaro Kuribayashi's blog
    ikosin
    ikosin 2014/05/29
  • リーダーシップを発揮するのは誰か?それはどのようにして可能となるのか? - delirious thoughts

    一般に「リーダーシップがあるひとをリーダーと目する」と考えられているのとは反対に、公式組織上の役職はリーダーシップを不要にする。正確には、リーダーシップがあるから役職につくのではなく、役職がリーダーシップを根拠付けるのである。 そもそも、いちいちの案件についてリーダーシップを発揮しなければ仕事が進まないようでは、組織は回らない。そのため、役職を設置し、その役についている者に周囲が自動的に付き従うことを、役職者もそのフォロワーも期待することを公式化するのである。ここまではルーマンのいう通り。 しかし、現代のビジネス環境は、公式化された期待が頻繁に揺り動かされ、充分に機能できないほどの不確実性がある。もちろん、組織もそれに対応してあれこれと変化しているわけだが、それとともに、従来のリーダーシップをさらに広く取り、役職 = 管理者 = マネジャーとは別の非公式的要素として、さらには、誰もがそれを

    リーダーシップを発揮するのは誰か?それはどのようにして可能となるのか? - delirious thoughts
    ikosin
    ikosin 2014/03/16
    金井先生の書籍は、リーダーシップ論研究の展開がまとまっているので、この手の議論をする時は是非目を通して欲しい。特性理論で止まってる人は特に。
  • A/Bテストでいちばん大切なこと - Kentaro Kuribayashi's blog

    「A/Bテスト」が、Webサービスの最適化技法として人口に膾炙して久しい昨今ですが、それでもなお、個々の施策実行時にはいろいろと迷うことがあります。たとえば: 有用なテスト結果を得るためにパターンをどのような基準で用意すればよいのか テスト結果の統計的有意性をどのように検定すればよいのか 個々の改善がそれぞれによかったとしても、それらが局所最適に陥らないためにはどうしたらよいのか といったあたりが挙げられます。(2)については純粋に技術的な問題なので、ここでは議論しません。問題にしたいのは(1)および(3)についてです。ひとまず、いまのところ僕が思う一番大切なことをひとつだけ述べておきましょう。それは: 「それに対してなんらかの肯定的/否定的意見のあるパターンをテストする」 ということです。どういうことか。 視野狭窄的なA/Bテスト A/Bテスト、あるいは同様の最適化技法については、かつて

    A/Bテストでいちばん大切なこと - Kentaro Kuribayashi's blog
  • 「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's blog

    JAWS DAYS 2014のImmutable Infrastructure(以下、II)に関するトラックに呼ばれたので、話をしてきました。Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装についてや最近のImmutable Infrastructureに関する議論(Orchestration編)というエントリを書いていたからということでしょう。 ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライド

    「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's blog
  • Growth Hack(グロースハック)における3点の特色について - Kentaro Kuribayashi's blog

    昨年(2012年)半ば頃からGrowth Hackという言葉が流行し始め、海外はもとより、日においても先日Onlab [Growth] Hackers Conference 2013というイベントが開催されるなど、ますますの盛り上がりを見せています。稿では、Growth Hackの何が新しい(あるいは新しくない)のかについて述べます。 Growth Hackが流行りかどうかはともかくとして、Growth Hackが目的とするところには、自分自身問題意識を抱いていることもあって、すこし調べてみているところです。 「Growth Hackとは何か?」要するに、できるだけ多くのユーザを獲得するための取り組みという意味ととらえて間違いはありませんが、内外の文献を元にもう少し整理すると、特に、以下の3点の特色を持ちます。 いわゆるビッグデータドリブンであること AARRRフレームワーク、特に"R

    Growth Hack(グロースハック)における3点の特色について - Kentaro Kuribayashi's blog
  • 情報共有の必要性について

    エントリは、社内向けに書いた記事を公開するものです。 なぜ情報共有するのか みなさんご存知の通り、コーポレートサイトにて、以下のように謳われています。 意見やアイデアは、ミーティング、社内SNS、メールなどで積極的に発言しましょう。不採用かもしれないと思っても、他のアイデアと合わさることで新しいものになることがあります。そのために、すべてのアイデアに耳を傾けると同時に、頭に浮かんだことをどんどん外に出しましょう。 また、インターネットで表現し続ける、コミュニケーションし続けることを楽しんで、自分たちが一番のユーザーであることを心掛けましょう。 大切にしてほしいこと | 採用情報 | 株式会社paperboy&co. このことからもわかる通り、様々なことに関してアウトプットを行い、広く共有することは、我々みなに求められていることです。 組織面からの理由 他にも理由があります。それは、我々が

    情報共有の必要性について
    ikosin
    ikosin 2014/02/11
  • ぶつかり稽古 2014年初場所 #cross2014 - Kentaro Kuribayashi's blog

    CROSS 2014で行われたコードレビューCROSS 〜ぶつかり稽古 2014初場所〜 | CROSS 2014というイベント(パネルディスカッション)でモデレータをつとめました。「#ぶつかり稽古」という事件についてで書いた、エンジニアによる「知的エンターテインメント」であるところの「ぶつかり稽古」の格普及を図る第二弾のイベントです。 前回はペアプロでしたが、今回はセッションオーナの@studio3104さんのご意向により、コードレビューの実践、および、パネルディスカッションという形を採りました。1時間という時間では、なかなか深い議論をするのは難しいところだとは思いますが、各社での具体的なコードレビューのやりかたや考え方について、ある程度筋道のたった議論ができ、今後の参考にしていただけるような内容になったのではないでしょうか。@studio3104さんはじめ、親方とその弟子たち(パネラ

    ぶつかり稽古 2014年初場所 #cross2014 - Kentaro Kuribayashi's blog
  • 最近のImmutable Infrastructureに関する議論(Orchestration編) - Kentaro Kuribayashi's blog

    この分野について議論する際には、インフラ系技術の流れ - Gosuke Miyashitaで紹介されている Bootstrapping Configuration Orchestration という整理を前提に議論すると、どのレイヤについて話しているのかごちゃごちゃにならなくてよいと思う。ただ、 上記は階層を成す概念なのだけど、それぞれが必ずしも排他的ではなく、重なる部分が多々ある(たとえば、(1)に該当するDockerやPackerにも(2)の要素が含まれている等) Orchestrationというネーミングがいまやミスリーディング(な面がある) ということもあって、一部に混乱をきたしている。ここでは、特に(2)について、時系列を追って論ずる。 時系列の整理 インフラ系技術の流れ - Gosuke Miyashitaによる整理 Rebuild: 25: Immutable Infrast

    最近のImmutable Infrastructureに関する議論(Orchestration編) - Kentaro Kuribayashi's blog
  • 「#ぶつかり稽古」という事件について - Kentaro Kuribayashi's blog

    去る11月23日、あるイベントが開催された。「秋のエンジニアぶつかり稽古 2013」という。何を目的にしたイベントなのか誰も(主催者側ですらも)わからないまま始まったこのイベントは、しかし、最後までその目的が明らかにならないままに、なぜか大成功の余韻だけはしっかり残して終わった、異常な「事件」と呼ぶ他ないものとなった。 事の発端 そもそもの始まりからして意味不明だったのである。発端はこれだ。 @__kan こんにちは、ペパボです。YAPC::ASIA参加者スペシャル特典にご応募いただき、ありがとうございます ! @kentaro とのぶつかりげいこをぜひ開催したく思います。ご都合のよろしい日をいくつかご連絡下さい! pic.twitter.com/uoj2uExHBU— ペパボ(paperboy&co.) (@pepabo) October 2, 2013 2ヶ月ほど前、YAPC::Asi

    「#ぶつかり稽古」という事件について - Kentaro Kuribayashi's blog
  • Webサービスにおける費用対効果 - Kentaro Kuribayashi's blog

    コードを書いたり機能を追加したりせずにお客さんが増えたり儲かったりするなら、その方がいいことは自明である。コードや機能が増えることはシステムの複雑性を増加させるため、当初の開発工数という意味におけるコストだけでなく、将来にわたってコストが増えるということ。 コードや機能が増えることによるコストは、やればやるだけ増えることもまた自明である。コードの一行一行、機能のひとつひとつが、将来の開発者に対する負担となる。一方で、一般にWebサービスにおけるベネフィットは、なにかやればその分儲かるというものではないため、費用対効果がよくわからないことが多い。単にひたすら作っているだけだと、コストばかりが増えていくということになりがち。 ではどうするか。できるだけコストをかけないでベネフィットを増やす必要がある。しかし、コードを書いたり機能を追加したりすると、上述の通り、コストが増加することは避けようがな

    Webサービスにおける費用対効果 - Kentaro Kuribayashi's blog
  • 『入門Puppet - Automate Your Infrastructure』という電子書籍を出版しました - Kentaro Kuribayashi's blog

    Chefとならんでよく利用されているサーバの構成管理フレームワークであるPuppetについて、『入門Puppet - Automate Your Infrastructure』というを出版しました。 入門Puppet - Automate Your Infrastructure【電子書籍】栗林健太郎 達人出版会 発行日: 2013-05-08 対応フォーマット: PDF, EPUB 詳細を見る 入門Puppet - Automate Your Infrastructure 作者: 栗林健太郎発売日: 2013/04/29メディア: Kindle版この商品を含むブログ (1件) を見る id:naoyaさんの許諾をいただいた上で、『入門Chef Solo - Infrastructure as Code』の姉妹(兄弟?)のような体裁の、コンパクトな電子書籍です。表紙は、naoya同様「

    『入門Puppet - Automate Your Infrastructure』という電子書籍を出版しました - Kentaro Kuribayashi's blog
  • 書評『スマートフォンのためのUIデザイン』 - Kentaro Kuribayashi's blog

    tikedaさんより、新著『スマートフォンのためのUIデザイン』をご恵投いただきました。ありがとうございます。結論からいうと、名著、英語でいうと、"Epic, just epic"って感じ。必読です。 スマートフォンのためのUIデザイン ユーザー体験に大切なルールとパターン 作者: 池田拓司出版社/メーカー: ソフトバンククリエイティブ発売日: 2013/03/30メディア: 大型 クリック: 117回この商品を含むブログ (2件) を見る 書は、スマートフォン用のアプリ・ウェブサイトのパタンを分類・整理した上で、網羅的に紹介するです。かつての類書に『iPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン』というがあって、これはこれで素晴しいのですが、書はカタログに徹したことで、さらに価値を高めていると感じました。 そもそもデザインにとって、パタン化は伝統的な営み

    書評『スマートフォンのためのUIデザイン』 - Kentaro Kuribayashi's blog
  • 「開発者のためのリーン・スタートアップ」「リーン・キャンバス入門」の資料を公開します - Kentaro Kuribayashi's blog

    隣席のるびりすと氏(@hsbt)と僕とで、この半月ほど、東京・福岡で合計3回にわたって勉強会ツアーをやっていました(その他のこともたくさんやっていたので、それだけではもちろんないのですが)。今日でそれもひと通り終わったので、どのようなことをやっていたのかについて、ここで公開したいと思います。 我々の話はどの回も以下の順番で行われており、いわば三題噺みたいな構成となってます。 リーンスタートアップ インセプションデッキ Scrum それは、我々が議論している模様を撮った以下に掲げた写真に見られるように、開発プロセスというものが階層的な構造を持っているからです。 www.instagram.com ここでは、その最初の話「開発者のためのリーン・スタートアップ」および「リーン・キャンバス入門」のスライドを紹介します。 開発者のためのリーン・スタートアップ 僕は技術者です。また、技術者としてさらな

  • 株式会社paperboy&co.に入社しました - Kentaro Kuribayashi's blog

    日5/1付けで株式会社paperboy&co.に入社しました。「技術基盤整備エンジニア」として、paperboy&co.全サービスに関わる技術基盤の整備に携わることになります。 株式会社paperboy&co.は、そのミッションに 「便利でリーズナブルなサービスを運営し、より多くの人に情報発信する喜びを提供してまいります。また、ユーザーの自己表現を支援するために、表現者のクリエイティビティを最大に引き出せる、最高の環境を創造してまいります。 とあるように、これまで一貫して、ネットを用いて何事か世の中にもたらしていきたいというひとりひとりの人々に向けて、事業を展開してきました。僕も、同じようにネットを用いていろいろなことをやってきた者として、今後もそのような人々とともに、ネットサービスによって世の中をよりよくしたいと考えます。 というわけでみなさま、今後ともどうぞよろしくお願いいたします。

    株式会社paperboy&co.に入社しました - Kentaro Kuribayashi's blog
  • 株式会社はてなを退職しました - Kentaro Kuribayashi's blog

    日4/18は、2008年の5/1より4年間奉職した株式会社はてなの最終出社日でした。正式な退社日は今月末日になります。 思えば、入社する前は、僕は奄美大島という田舎で市役所の職員をしていて、Webとはまったく関係ない、なんというかまあ、とにかくいまとはまったく別の仕事をしていました(具体的には、生活保護の担当をしていて、毎日いろんな問題のあるひとびととおしゃべりなどするという仕事をしていました)。それが、京都という、それまで住んでいたところからするとはるかに都会の、さらにはITベンチャという、まさに地理的、環境的に、あらゆる面で正反対の仕事をすることになって、人生なにが起こるかわからないものです。 大学の頃までは、インターネットになどまるで興味がなく、親のおさがりのMacを所持してはいたもののネットにつなぐことなく、単にレポートや小説などを書くためのワープロとしてしか使っていませんでした

    株式会社はてなを退職しました - Kentaro Kuribayashi's blog