プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
「リーン」について : 「何を作るか」よりも「何を作らない」か - naoyaのはてなダイアリー
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す･･･というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─
エンジニアにとって良い組織とは何かを知りたい? - naoyaのはてなダイアリー
「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが･･･」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。 How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメントposted with amazlet at 14.10.18エリック・シュミット ジョナサン・ローゼンバーグ アラン・イーグル 日本経済新聞出版社 売り上げランキング: 19 Amazon.co.jpで詳細を見る 小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則posted with amazlet at 14.10.18ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン 早川書房 売り上げランキング: 7,579 Amazon.co.jpで詳細を見る Tea
日本語で読める IT名文書 三選 - naoyaのはてなダイアリー
pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。 伽藍、バザール、ノウアスフィア、おなべ(3) http://www.artonx.org/diary/20120411.html#p01 artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した http://anond.hatelabo.jp/20111018190933 (前編) http://anond.hatelabo.jp/20111018192953 (中編) http://a
HBFav 2.7.1 をリリース。iOS 8 に対応しました - naoyaのはてなダイアリー
審査に時間がかかってしまいましたが、無事 HBFav 2.7.1 をリリースできました。 https://itunes.apple.com/jp/app/hbfav/id477950722 これで iOS 8 にするとクラッシュする問題が解消されました。 ただし、iOS 8 でプッシュ通知を受け取ろうと設定しようとしたとき正しく設定できない問題が見つかったため、急遽修正しまして 2.7.2 の審査待ちです。デバッグの過程で既存のプロビジョニングファイルをいろいろいじったせいで、もしかすれば既存のバージョンもプッシュ通知が届かなくなっているかもしれません、申し訳ないです。プッシュが届かなくなっているもしくは iOS 8 でプッシュが来ないかたは 2.7.2 のリリースをお待ち下さい。 このところ HBFav の開発にあまり時間が取れず、バージョンアップの割に目新しい機能はほとんどありませんが
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 の上に構築されており
Deploy to Heroku / Webアプリケーションのポータビリティ再び - naoyaのはてなダイアリー
Heroku の新機能で Heroku Button が出た。 見るよりも、触る方が早い。以下のボタンを押すと md2inao をあなたの Heroku アカウントにデプロイして、動かすことができる。 ボタンを押すと以下のような画面が出て、Deploy to Free を押すと直ちにデプロイが始まる。 GitHub からソースコードが Heroku にデプロイされて、Web アプリケーションが動く。 ご満悦。 このボタンを README.md に置いておけば、Webアプリケーションを自分で動かしたいなと思ったユーザーが、自分自身の環境で好きな時にそれをデプロイして使うことができる。 すなわち、Heroku Button で、URI を介した Web アプリケーションの交換が可能になった。 Heroku Button Heroku Button を有効にするための前提は割とシンプルで Git
Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
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 トラックは立ち見が出てるくらい盛況で、やはりこの分野に注目が集
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
less-css-mode - naoyaのはてなダイアリー
Pixate もそうですがこのところ LESS で css を書く機会が多いのでさぼっていた emacs での less-css-mode.el を導入。 インストール M-x list-packagesで ELPA から less-css-mode をインストール。less-css-mode は lessc コマンドがあると flymake で syntax check そのほかをしてくれるので % node -g install lessで入れておく。 設定 ;;; init.el (require 'less-css-mode) (setq exec-path (cons (expand-file-name "~/.nodebrew/current/bin") exec-path)) ; (setq less-css-compile-at-save t) ;; flymake (ad
Text::LTSV - naoyaのはてなダイアリー
勢いで Text::LTSV という perl モジュールを書いたけど、ただ tab を split してコロンで split するだけなのでわざわざこんな駄モジュールを使うまでもない、という･･･。 use Text::LTSV; my $hash = Text::LTSV->parse_line("hoge:foo\tbar:baz\n"); is $hash->{hoge}, 'foo'; is $hash->{bar}, 'baz'; my $data = Text::LTSV->parse_file('./t/test.ltsv'); # or parse_file_utf8 is $data->[0]->{hoge}, 'foo'; is $data->[0]->{bar}, 'baz'; my $ltsv = Text::LTSV->new( hoge => 'foo', b
knife-solo 0.2.0 supports Amazon Linux - naoyaのはてなダイアリー
おお、これはこれはご丁寧にありがとうございます。ところで、どちらさまですかね･･･と思ったら knife-solo の開発者の方ではないですか!! なんだこの神。 開発メモ#5 : Amazon Linux で knife-solo を使って chef-solo 実行 - naoyaのはてなダイアリー で knife-solo を使って EC2 で chef-solo を使う話を書きました。その時点のバージョン 0.1.0 ではパッチを当てないと Amazon Linux では使えなかったところ、今日出た 0.2.0 でサポートされたようです。 実際使ってみましたが、prepare はじめ各種コマンドがきちんと実行できました。Amazon Linux には初期状態では chef-solo が入っていませんが、knife solo prepare で Omnibus Chef Packagi
AWSブログを3行でまとめる試み#2 : RDS Multi-AZ の料金値下げ - naoyaのはてなダイアリー
Amazon RDS を Multi-AZ で使ったときの料金を 15% 〜 32% 値下げするぞ Multi-AZ は簡単にデータベースを冗長化する機能だ 値下げは 2013年2/1 分からだ。ヨロシクゥ cf: http://aws.typepad.com/aws_japan/2013/02/aws-price-reduction-rds-multi-az.html コメント Multi-AZ は簡単にスタンバイが作れて嬉しい、というのもあるけど本当の緊急時に限ってうまく動かなかったりするフェイルオーバーの機能すなわちスタンバイのマスタ昇格まで面倒みてくれるところが良いんじゃまいか。使ったことないから分からないけど。 RDS は個人で使うのにはちょっとお高いので、どんどん値下げしてほしい。ブログの例では DB は MySQL になってるけど、確か Oracle とか SQL Serve
AWSブログを3行でまとめる試み#3 : Amazon Redshift が US East で利用可能に - naoyaのはてなダイアリー
昨年末に発表した Amazon Redshift が US East で利用可能になったぞ Redshift はクラウドなデータウェアハウス (DWH) だ。オンプレなDWH の 1/10 のコストで10倍のパフォーマンスが出るぞ Management Console から簡単にいじれて S3 や DynamoDB や EMR や EC2 からデータがロードできるように統合されているぞ cf: http://aws.typepad.com/aws_japan/2013/02/amazon-redshift-now-broadly-available.html コメント 昨年の AWS re:Invent で発表されたAWS の DWH です。従量課金。いまちょうど fluentd のユーザーミーティングに来てますが、ビッグデータやなんやでこの辺の分野が我々のWebサービス界隈でもホットです
3行でAWS blog#5 : Marketplace で RHEL アプリケーションをサポート - naoyaのはてなダイアリー
AWS Marketplace で RHEL 用のソフトウェアパッケージをサポートしたぞ AWS 上で RHEL アプリケーションを使うとサポート面、あるいはアプリケーション提供面でお得だぞ AWS MarketplaceがRHELとして知られるRed Hat Enterprise Linuxで稼動するソフトウェアをサポート開始いたしました。AWS上でRHELをご利用の方は、トップクラスのソフトウェアベンダーが提供する、成長を続ける数々のアプリケーションを、見つけ、購入し、ワンクリックでデプロイすることができるようになります。 コメント この手の小さめのニュースまで3行にまとめるかどうか悩む。昨日の AWSサミット開催の話はスキップしちゃいました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
何か用ですか - naoyaのはてなダイアリー
