プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
「リーン」について : 「何を作るか」よりも「何を作らない」か - naoyaのはてなダイアリー
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す･･･というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
BigQuery と Google の Big Data Stack 2.0 - naoyaのはてなダイアリー
先日、有志で集まって「BigQuery Analytics」という書籍の読書会をやった。その名の通り Google BigQuery について書かれた洋書。 BigQuery を最近仕事で使い始めたのだが、BigQuery が開発された背景とかアーキテクチャーとかあまり調べもせずに使い始めたので今更ながらその辺のインプットを増やして以降と思った次第。 それで、読書会の第1回目は書籍の中でも Overview に相当するところを中心に読み合わせていった。それだけでもなかなかに面白かったので少しブログにでも書いてみようかなと思う。 BigQuery の話そのものも面白いが、個人的には Google のインフラが書籍『Google を支える技術』で解説されたものが "Big Data Stack 1.0" だとして、BigQuery は Big Data Stack 2.0 の上に構築されており
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
JAWS DAYS 2014、Immutable Infrastructure について - naoyaのはてなダイアリー
何もかも投げ棄てて Dark Souls II をやりたい気持ち抑えながら JAWS DAYS 2014 で Immutable Infrastructure について話してきました。以下、資料です。(Embed できないのでリンクです) https://speakerdeck.com/naoya/immutable-infrastructure-number-jawsdays Immutable Infrastructure トラックのトップバッターだったので、そもそも Immutable Infrastructure とは何か、どのような背景でこのような概念が提唱されるに至ったのか、そして現在は。またこれから何が変わるのかみたいな、大枠の話にフォーカスして話しました。会場は Immutable Infrastructure トラックは立ち見が出てるくらい盛況で、やはりこの分野に注目が集
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき
AWS Summit Tokyo 2013 - naoyaのはてなダイアリー
一昨日、昨日と東京は品川で開催された AWS Summit Tokyo 2013 に行ってきた。 全般的な印象としてはエンタープライズトラックがたくさんあったし来場者もスーツを着た人も多くて、AWS を取り巻くステージは去年一年くらいで完全にエンタープライズ側に移行しきったんだなあ、というものだった。もちろんテクノロジートラックやコンシューマートラックもあって、技術的な実装やテクニックにフォーカスしたような話も方々でなされていたんだけど、多くの来場者の関心事は如何にしてクラウドをエンタープライズに導入するか、あるいはそれによってビジネスの課題を解決するかというところにあった、というのが肌感覚としてあった。 自分は AWS、というか IaaS はハードウェアを抽象化してソフトウェアでそれ全体を扱えるようにしたというところが本質的で、自動化、DevOps、あるいはプログラミングのための道具とし
Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー
Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル
Kindle向けに『入門Chef Solo - Infrastructure as Code』を出版しました - naoyaのはてなダイアリー
Chef のスタンドアロン版である Chef Solo の技術書を Kindle 向け電子書籍として出版しました。 入門Chef Solo - Infrastructure as Codeposted with amazlet at 13.03.17伊藤直也 (2013-03-11) 売り上げランキング: 14 Amazon.co.jpで詳細を見る がんばりました。原稿＼(^o^)／オワタ Chef Solo 本 Chef はサーバー/インフラの状態管理フレームワークです。より単純化して言うならサーバー構築の自動化ツール。コードは Ruby で書きます。ウェブアプリケーションをホストするサーバーの管理にもちろん利用できますし、チームメンバーの開発環境を同じ状態に揃える、あるいは個人の開発環境の整備を自動化する、といったことにも利用できます。 本書の内容のは、その Chef の入門書です。C
LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー
ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで･･･というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか･･･ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue
開発メモ#4 : EC2スナップショットとの差分は chef-solo で解決 - naoyaのはてなダイアリー
開発メモその4です。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で、システム構成の変更時に EC2のスナップショットからインスタンスを複製して Elastic IP で切り替えているという話をしました。 ただ、この方法はそのままでは一点問題があります。スナップショットを取ったタイミングと現時点でシステム構成に差分があった場合にどうするか、です。例えば nginx の設定をほんの少しだけ書き換えたい、とかその都度スナップショットを取っていては流石に面倒。 その手のスナップショット時点からの差分を複製されたインスタンスに簡単に適用するために、基本的なサーバー設定周りは chef-solo で管理してます。chef はサーバー構築自動化ツールで、chef-solo は chef のクライアント・サーバーを必要としないライト版、とでも
近頃の開発環境 : Mosh、z、tmux、Emacs、Perl について - naoyaのはてなダイアリー
昨日は年始の挨拶ついでに ELPA について脈絡もなく突然書きましたが、引き続き近頃の開発環境についてもだらだらと書いてみよう。 Mosh mosh というと一部の人間はひげなんとかさんが開発しているモナー的なあれを思い浮かべるかもしれないがそうではなく、mobile shell のことである。 思い切り簡略化して言うと「快適なssh」。回線が不安定な所でもエコー遅延など全く気にせず使えるし、Mac をスリープさせて復帰させたときもリモートホストにそのまま繋がりっぱなしのように見せかけてくれたりする。 詳しくはこの辺を。 mosh: MITからモバイル時代のSSH代替品 - karasuyamatenguの日記 インストールはリモートとローカル両方に必要ですが、まあ大概パッケージがあると思います。EC2 の Amazon Linux でも yum レポジトリの EPEL を有効にすれば y
RubyMotion の Diablo 3 Web API ライブラリ - naoyaのはてなダイアリー
「やったーDiablo3のiPhoneアプリできたよー（＾o＾）ﾉ」 この週末知人とハッカソンに行ってきました。何を作ろうかなと思っていところ、そういえば先日 Blizzard が Diablo3 の Web API をリリースしていたのを思い出しまして、RubyMotion で Diablo3 の API を叩くライブラリ(の基本的な部分)を作りました。 https://github.com/naoya/Motion-Diablo3 Diablo 3 の Web API http://blizzard.github.com/d3-api-docs/ Web API は素直な JSON over HTTP で Restful なそれになっていて、この辺やっぱり Blizzard はセンスが良いなと感じました。 API で取得できるのは今のところ、Battle.net に保存されたアカウント
RubyMotion - naoyaのはてなダイアリー
ちょっと前に RubyMotion を触ってみてこれは面白いなと思いブログにでも書こうかと思った矢先にドラゴンクエスト10が発売してしまい、あれよあれよといううちに一ヶ月経ってしまいました。 それはさておき「るびも」こと RubyMotion ─ いや、るびもと呼んでいるのは自分だけですけど。Ruby で iOS のネイティブアプリが書けるというツールチェイン。コンパイラ、テストスイート、プロジェクト作成用スクリプトその他を含みます。主に CUI はターミナルでのコンパイルを想定していて、Xcode で開発するのに比べるとだいぶ *nix してるわーという気分になれる代物です。iOS アプリなのに Ruby! iOS アプリなのに CUI! ･･･ これだけでワクテカな方も多いかなと思います。 以下そんなるびもちゃんRubyMotion 様をざっと紹介していきたいと思います。なお、あらかじ
iOS版Chrome リリースに見るiOSプラットフォームの制約 - naoyaのはてなダイアリー
iOS版の Chrome がリリースされましたね。 アプリとしての使い勝手どうこうというところよりも、JavaScript エンジン周りをどうしているのかに興味があったのだけど、TechCrunch の記事 (http://techcrunch.com/2012/06/28/hands-on-with-googles-chrome-for-ios-just-like-chrome-for-android-only-slower/) を見る限り v8エンジンは搭載されていないし、当然 UIWebView での JIT コンパイラも有効にはなっていないように見えました。つまり、JavaScript の実効速度に関して言えば、Mobile Safari のそれを上回ることはない。(厳密に言えば、純粋な JavaScrpit の実効速度以外のところの実装が良くてトータルとして速い、というようなこと
Meteor.js - naoyaのはてなダイアリー
http://www.meteor.com/ で公開された Meteor.js を少し触ってみました。TechCrunch なんかでも話題になっていましたね。 Meteor.js は JavaScript によるウェブアプリケーションフレームワークですが、クライアントサイドでもサーバーサイドでもない、"Isomorphic" なフレームワークです。 コンセプトとしていくつか特徴があるのですが、その最たるものは "Reactive Programming" で、モデルやセッションなどのストレージを更新するとその更新内容がリアルタイムに、そのアプリケーションを開いている全クライアントに伝わるようなアプリケーションを簡単に作ることができます。 この辺は実例を見るのが早いです。 http://www.meteor.com/examples/leaderboard ここにある動画では、あるブラウザで
退職 - naoyaのはてなダイアリー
グリー株式会社を退職しました。昨日が最終出社日でした。 最終日の昨日はちょうど四半期の〆の日ということもあって、開発本部全体での納会 (飲み会) の中で盛大に送り出していただきました。いただいた花束が自分の身長の半分もあろうかというくらい大きさで、徒歩で帰宅途中、通行人にまじまじと見られるという、なかなか得難い経験をさせていただきました。 在職期間は一年半とちょっとと短かったのですが、その中でもたくさんのことを経験することができました。iOS / Android のスマートフォン版の立ち上げに始まり、SNSの開発、直近では US に出張したりしつつグローバル化の推進ですとか。何より、入社当時3名だったチームを一年半で 50人強まで拡大させる中、その人事権をまるごと任せてもらえたのは大きかったです。一緒にやっているメンバーには、自分の試行錯誤で振り回してたくさん迷惑をかけました、ごめんなさい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
