元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2016/03/15

Ubuntu に Oracle Java (JDK) を サイレントモードでインストールする


メモ。

PPAで公開されている webupd8team のリポジトリを使えば、apt で Oracle Java (JDK) がインストールできるので便利。

なのですが、 Chef さんとかで自動化しようとすると、途中でインタラクティブにご出現されるライセンスの同意画面が大変やっかいなので、なんとかサイレントモードでインストールしたい。

で、どういう風にやったかというと、下記で何も問われることなくインストールできた。


# add-apt-repository -y ppa:webupd8team/java
# apt-get update
# echo debconf shared/accepted-oracle-license-v1-1 select true | debconf-set-selections
# apt-get -y install oracle-java8-installer

あとは、これを Recipe 化して無事自動化完了、というログでした。

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


参考

2016/02/19

デブサミ2016「プロダクト開発におけるプロダクトマネージャーの役割とは」講演メモ #devsumi


楽しみにしていたセッションの1つ。メモメモ。


「プロダクト開発におけるプロダクトマネージャーの役割とは」

  • 丹野 瑞紀 氏
  • (株)ビズリーチ
  • サービス企画部 本部長

講演のコンセプト

「コンセプト」は、ターゲットと提供価値がセットになっているもの

  • ターゲット
    • ITエンジニアとして次のキャリアを模索
  • 提供価値
    • PMの役割と求められるスキルの理解

プロダクトマネジメントとは

  • あるプロダクトを市場に出荷していくお仕事
  • プロダクトに求められる要件
    • ユーザ課題が解決できる
    • 技術的に実現可能
    • ビジネスとして継続可能
  • PMはそれぞれを理解してプロダクトを作っていく

プロダクト開発のプロセス

  • 市場調査
  • 市場機会の発見
  • 事業計画
  • 製品コンセプト立案
  • 製品開発
  • マーケティング戦略実案
  • 市場の投入
  • PR・プロモーション
  • 結果の評価

よくある例としては、

  • 上の3つは、 経営企画室の仕事
  • 次の2つは、テクニカルPM (プロダクトオーナー) の仕事
  • 最後の4つは、ビジネスPM (ビジネスオーナー) の仕事

テクニカルPMが関わるプロセスの詳細

-問題の発見

  • 現認の特定
  • 解決方法の考案
  • 仕様詳細化
  • 設計
  • 実装
  • 公開
  • 結果の評価

プロダクトマネージャーの仕事の範囲

  • PMは上の4つ(idea)だけやればいいの?
    • 実際に偉大なプロダクトが完成するまでにはとてつもない量の妥協(トレードオフ)が必要
    • 実装過程で明らかになる矛盾や課題をエンジニアと一緒に解決していくこともPMの重要な仕事
  • プロダクトマネージャとプロジェクトマネージャの役割の違い
    • プロダクトマネージャ
      • What (何を作るか)
      • Why (なぜ作るのか)
    • プロジェクトマネージャ
      • When (いつまでに作るのか)
      • How (どうやって作るのか)

PMの仕事の実際

新規と既存改善それぞれでケーススタディベースで。


既存プロダクトの改善

ex.) あるECサイトで、ダイレクトメールからの購入率を改善したい

  • メール受信唐子運輸までのプロセスを因数分解する
  • 繊維率を算出する(受信to開封率...etc)
  • 指標を時系列で可視化する
    • ex.) ある日から急に数値に変化がある場合・・・
  • 仮説を洗い出す。ユーザインタビューをすると仮説が出やすい
    • 色々な案内メールが来るから見落とす
    • タイトルがいつも同じなのでスルーされている
    • 買い物するのは隙間時間だけど、メールの着信は仕事中 => 送信時間がキー?
    • そもそもメール見ていない
  • A/Bテストで仮説を検証する
    • A: 朝8時に送信、 B: 昼12時に送信

  • コツはユニークユーザで捉える
    • △: 10通に1通が開封
    • ○: 10人に1人が開封
    • 現象は人間の行動に還元される
  • 人間の行動を理解するには「インサイト」を押さえる
    • インサイトとは顧客の潜在的意識の中にある行動に影響を与える価値観や感情

コンシューマ・インサイトとは

  • Wiiのコンセプト
    • 「お母さんを敵に回さない」
  • ゲームに対するお母さんのインサイト (想像)
    • 部屋にこもってゲームばかりやっていて困る
    • 親子のコミュニケーションが減った
    • もっと体を動かしてほしい
  • リビングで家族で体を動かして遊べるゲーム機となった

  • システム思考の「氷山モデル」
    • 現象(氷山) => 購入率低下
    • 時系列パターン => ある時期から開封率低下
    • 構造 => DMの配信時間がズレた
    • メンタルモデル => ユーザは隙間時間に購入したい

新規プロダクトの開発

  • ex.) 中学生が思う、紙の暗記帳の欠点
    • 色々な強化の暗記帳を持ち運ぶのが大変
    • 作るのが大変、友達と共有したい

  • アプリ作ってストアに公開、どんどんダウンロード数はのびた
  • しかし、DAUは伸びていない
    • そこで、DAUを時系列に表示すると、月末だけ上がっていることがわかった
  • ユーザにヒアリングしたら、、、
    • 一夜漬けでの勉強に便利だから、月末テストの前によく使われていることがわかった
  • では毎日使われるようにするにはどうするべきか
    • 暗記帳を持ち運んだり作ったりする手間よりも、継続して学習することに関する課題をみんな感じていることに気づいた
  • 暗記帳を元に暗記クイズを出題する機能をつけた
    • するとDAUも伸び始めた

  • システム思考の「氷山モデル」
    • 現象(氷山) => DLは増える、DAUは増えない
    • 時系列パターン => 月末だけDAUが増える
    • 構造 => 月末に小テストがありテスト前に頑張る
    • メンタルモデル => 普段は勉強したくないけど、追試は避けたい

作業レベルで解説
  • まずは主観で考える
    • 「自分だったらこんなプロダクトがほしい」と考える
  • ペーパープロトタイプを作る
    • とにかく手を動かしながら考える
    • PM自身が明確なゴールイメージを保つためには、自ら画面イメージを描く必要がある
  • ユーザ課題の仮説が言語化される
  • ヒアリングシートを作ってインタビューする
    • 想定していなかった回答が出てくる
      • 仮説は外れる
      • 主観から客観に落とし込んでいく
  • ヒアリング結果を整理する
    • ユーザのタイプが分けられる(それぞれのインサイトは異なる)
      • 横軸
        • とりあえずテストを乗り切れればいい
        • 実力をつけたい
      • 縦軸
        • 自分で勉強できる
        • 補助が必要
    • これらからプロダクトのターゲットを絞る
  • コンセプトが明確になる
    • ターゲットと提供価値がはっきりする
  • 同構造の問題の解決例を探す
    • Nikeのアプリみたいな、ダイエットやフィットネスアプリ(やらねばと思うが続けられないもの)
  • 課題解決のコアアイデアが生まれる
    • 努力の可視化や友達との競争によって、"勉強を"遊び"に近いものに
  • MVPを作って定量的に検証する

PMへのキャリアチェンジを考える時のポイント

  • PMに必要な知識やスキル
    • 論理的思考力
    • 複雑な問題を整理してモデル化する力
    • 実現可能性の判断力
    • (プロダクトの)デザインパターンの引き出し
    • 開発プロセスの理解
    • 市場・事業構造・ユーザ真理の理解
    • マーケティングの基本フレームワーク

  • 上の5つは、ITエンジニアの経験が強みになる
  • あとはマーケティングへの苦手意識を克服すればPMはできる

  • 「でも、コミュ力が必要なんでしょう?」
    • PMに必要なコミュ力は、雑談力や社交性ではなく、ファシリテーション力に近い
      • 自分が伝えたいことを伝える力
      • 相手が伝えたいことを聴く力
    • ステークホルダーの意見を聞きすぎると、多機能だけど誰も使いこなせないものができる
      • いきなり解決方法を考えるのではなく、問題の発見に立ち戻り議論を論理的に整理する

  • 「PMって楽しいの?」
    • 正直、ステークホルダーの調整がちょっとめんどくさいw
    • 狙い通り(企画)に当たった時の喜びが全てを癒す!

興味のある方は

  • Product Manager Japan on Slack があります!
    • 「pmjp」で検索
    • 参加してみませんか?

2016/02/18

デブサミ2016「大規模Redisサーバ縮小化の戦い」講演メモ #devsumi


メモメモ。泥臭い話で面白かったです。


「大規模Redisサーバ縮小化の戦い」

  • 駒井 祐人 氏
  • (株)アカツキ
  • ゲームのサーバサイド機能開発、インフラの設計構築・保守運用

Redisとは

  • インメモリDB
  • 5種類のキーバリューのデータ型
  • ファイル永続化オプション

システムの問題点

  • EC2サーバが20台に対して、AWSのElasticCache(Redis)が64台あった
  • なぜ64台あったかというと、リリース直後にRedisの負荷問題があり、8台 => 64台になった
  • 調査するとkeys("")を実行している箇所があった
  • 当然お金がかかる(cache.m3.large * 64台 = 約135万円/月)
  • 冗長化しんどいし、設定ファイルの記載も辛い
  • ので、縮小化と冗長化の対処をしたい

現状整理

  • 格納されているデータ
    • フレンド情報、セール情報、ランキング情報
  • キーの件数
    • 1サーバに8DB、1DBあたり7万〜40万件
    • しかし各Redisで利用されていたのは1DBのみであった...(8=>64台にしたときにコピーして増やしてゴミが残ったままだった)

マージ方法の検討

  • それっぽいツールがあったけど、makeできなかったので、自力で頑張ることに
  • 案1: key/valueを全部抜き出すパターン
  • 案2: dumpファイルを結合するパターン
    • ヘッダとフッタをいじればなんとかなりそうだし、計算も案1より少なそうなのでこっちを採用

dumpの構造

  • バイナリデータとなっている
    • ヘッダが9バイト
    • DB番号が2バイト
    • その後、key/hashのデータが続いていく
    • DB番号・・・データ・・・(繰返)
    • 終端文字が1バイト
    • checksumが8バイト

マージ方法

  • まず要らないゴミを消す
  • 最初のDBのヘッダをつけて、そのあとにデータをつなげていく
  • 最後にchecksumを付与する
    • checksumを無視するオプションもある
  • redis-check-dumpを使って構造上問題ないか確認する

縮小化の流れ

  • メンテナンス開始
  • バックアップ
    • EC2でRedisを動かして、リードレプリカとして設定して、dump出力する
  • ゴミデータ削除
  • マージ
    • S3へ
  • リストア
    • S3のパスを指定して起動
  • メンテナンス終了

失敗談

  • バックアップ失敗
    • ReadReplicaとして接続した際に、過去データをdlushされる前にsaveしても、正確にバックアップが取れない

結果

  • かかった時間はトラブル含め4時間
  • 縮小&冗長化した上に、135=>38万円/月へコスト削減

縮小後に発生した事象

  • Redisのコネクション上限に達した
    • APサーバ数 * Unicornのプロセス数 * DB数
    • しかし、ElastiCacheの接続数上限は変更できない
    • よって、今度はDB数を減らす必要がでてきた

再度マージ方法を検討

  • 最初に検討した案1を採用(計算量は多いけど)
    • しかし、応答が返ってこない、、、時間はかかる
    • 複数サーバで並列に実行し、縮小することができた

7つのデータベース 7つの世界

7つのデータベース 7つの世界


オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)