Screaming Loud

研究・プログラミングなど気づいたことをメモをしています。読書記録はこちらに記載しています。https://bookmeter.com/users/75944

マーケティングという内容で社内で話した

ついにGravityDaze2をクリアしたmoc_yutoです。 ストーリー的にはフラグ立てるところまでは良かったんですが、回収部分がちょっと物足りなかったです。 ただ、フィールドの自由度はすごかったです。

ということで本題ですが、本日エンジニアによるマーケティングというタイトルで社内LTで発表しました。

www.slideshare.net

エンジニアという職種は技術が優れるのはもちろんなのですが、 ちゃんとマーケティングしていくことも重要だなと感じることが多く、LTで発表しました。

その中でも今回伝えたかったこととしては、 「認知率×配荷率×好意度」 です。

どんなに技術的に優れていても、どんなに機能がたくさんあっても、 そもそも認知されていなければそのプロダクトは利用されないということです。

逆に認知されているなら、配荷率と好意度を上げていく必要があるということ。

当たり前なんですが、以下の本を読んでその認識を強めたのでオススメでした。

play2.4向けにi18n(国際化)をアップデートした話

概要

以前GlobalSettingの撲滅に関してブログを書きましたが、言語対応に関して書いていなかったので、続編ということでブログにまとめました。 yuutookun.hatenablog.com

前提

Play2.4移行の対応を以下スライドを参考に実施。 http://sssslide.com/speakerdeck.com/tsuyoshizawa/play-2-dot-3-kara-2-dot-4-heatupudetositahua

import play.api.play.current
import play.api.i18n.Messages.Implicits._

言語対応に関しては、上記のようにimportを追加して一旦対応していました。

コンパイルは通っていましたが、このままではCookieに対応される言語に変換 これでは翻訳が実行されていませんでした。

根本対応

以下の5ステップで対応を進めました。

1.コントローラーをInjectionの形に移行

変更前

object Account extends Controller

変更後

import javax.inject.Inject
class Account @Inject() () extends Controller 

このようにInjectionの形に修正

同時にroutesの設定を以下に変更

GET /accounts controllers.Accounts.index
GET /accounts @controllers.Accounts.index

2.DefaultMessageApiを継承した自前のmessageApiを作成

MeMessageApiを作ります。

package models

import javax.inject.{ Inject, Singleton }
import consts.AppConfig
import play.api.i18n.{ DefaultMessagesApi, Lang, Langs, Messages }
import play.api.mvc.RequestHeader
import play.api.{ Configuration, Environment }

@Singleton
class MyMessageApi @Inject() (
    environment: Environment,
    configuration: Configuration,
    langs: Langs) extends DefaultMessagesApi(environment, configuration, langs) {
  private lazy val cookieName = AppConfig.play.modules.i18n.langCookieName.toString

  override def preferred(request: RequestHeader) = {
    val langOp = request.cookies.get(cookieName).map(_.value)
    langOp.fold(super.preferred(request))(lang => new Messages(Lang(lang), this))
  }
}

3.MessageModuleを作成

作成したMyMessageApiをbindします。

package modules

import models.MyMessageApi
import play.api.i18n.{ DefaultLangs, Langs, MessagesApi }
import play.api.{ Configuration, Environment }
import play.api.inject.Module

class MyMessageModule extends Module {
  def bindings(environment: Environment, configuration: Configuration) = {
    Seq(
      bind[Langs].to[DefaultLangs],
      bind[MessagesApi].to[MyMessageApi] // instead of DefaultMyMessagesApi
    )
  }
}

4,confにそのmoduleを使う旨を記述

application.confなどに書きます。

play.modules.enabled += "modules.MyMessageModule"
play.modules.disabled += “play.api.i18n.I18nModule"

5,各controllerが継承している親クラスに対してI18nSupportを継承させ、messageApiをInjectさせる

import play.api.i18n.{ I18nSupport, Lang, Messages }
trait BaseController extends I18nSupport { }
class Account @Inject() (val messageApi: MessageApi) extends Controller extends BaseController

元々BaseControllerを継承させていたので、そのControllerにI18nSupportを継承させれば、全部動くので、この方式を取りました。 MessageApiを使うControllerが少ないのであれば、個別に継承させたほうがいいですね。

ここのMessageApiは型を変えなくてもconfでmodule指定をしているので、 自動でMyMessageModuleがDIされてきます。

以上が、i18nの対応です。

まとめ

Controllerが多いと改修範囲が大きいですが、 moduleの形で実装すればロジック的な改修範囲は最低限に抑えられるので、ぜひ挑戦してみてください。

参考URL

play2-i18n-patterns

5月の読書メーター

 

5月の読書メーター
読んだ本の数:2
読んだページ数:647
ナイス数:6

確率思考の戦略論  USJでも実証された数学マーケティングの力確率思考の戦略論 USJでも実証された数学マーケティングの力感想
非常に面白かった。苦悩を書いた物語としての側面、ブランドの構築、実際に利用していた分析のリアルな話、そして組織論へと。 とくにプロダクトの戦略として「好意度・認知・配荷」が最も重要な軸という話には気付かされた。 巻末に確率論がまとまっているので、ストーリーと数式が別々になっており、すごい読みやすかった。 マーケ担当だけでなく、ビジネスを思考する上で役に立つ本。
読了日:05月24日 著者:森岡 毅,今西 聖貴

 


HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメントHIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント感想
マネージャーとしてどのように振る舞うべきかとチームの構成をどうしていくかをインテルのCEOが書いた本。 「ワンオンワンによるメンバーとの対話」と「効率性を上げるためのハイブリッド組織とそれを運営するための二重所属」の部分に関してちょうど考えていた部分でもあり、参考になった。 実際工場のマネジメントなど製造業の話が強いので、情報通信系の場合だと少し期待した内容と違ってしまうかも。
読了日:05月04日 著者:アンドリュー・S・グローブ

読書メーター

技術力を高めるだけがエンジニアの生存戦略なのか?

以前からエンジニアの生存戦略というのはホウボウで語られている。*1

それぞれ色んなエンジニアとして生き方があるが、共通して皆が言っているのはどのポイントで尖るかということだ。

しかし、自分は「信頼」だと思っている。

エンジニアとして生き残る
→職を失わない
→仕事を依頼される
→信頼される

これはエンジニアどうこう以前の問題として、社会人としての生き方、更には価値とも言える。

直近bitcoinが激しく暴落していたりするので、貨幣を話題に出す。 価値というとふわっとしているが、例えば貨幣で言うと、皆がその貨幣を信頼をしているから高騰していくし、この貨幣はここまで高騰するほど価値はないのではと思えば下落していく。 それが日本のバブルであり、サブプライムでのショックでもある。 日本円であっても、皆が1000円札に対して信頼を持っているからあのただの紙切れが価値を持っている。

この貨幣と同じ理論が人間に対しても当てはまると思っている。 「7つの習慣」でも言われている信頼残高という言葉が使われるが、仕事の依頼は信頼を通じて行われる。自分が仕事を依頼する立場になったときに、重要な仕事は信頼している人に依頼するのが常であろう。

エンジニアとして生き残るためには、信頼を得ることが必要であるということはわかった。 ではどう信頼を積み重ねていくか。

以下自分の考えているものを挙げる。

技術力を高めて、困難な課題を解決する。

これは大半のエンジニアが考えているキャリアパスであると思っている。 技術力に対して信頼があるため、その分野の仕事の依頼を行う。 これはふわっとしていて、実際どう技術力を高めるのか曖昧だ。 結局平均的な技術力を目標にしてしまっている可能性もある。

何かの分野で尖る

これは「技術力を高める」を一歩進ませたものだ。 何かの分野で尖るということは、その尖った分野では他の人がいないということである。 ということは、その人の素性に関わらず、その分野では頼る人がその人しかいないということに他ならない。

例えば技術としてだけではなく、 チームのまとめ方に定評があれば、スクラムマスターとしての信頼が得られる。 登壇発表が上手ければ、エバンジェリストとして信頼が得られる。 一つの分野でなくても、複数の分野の掛け合わせでももちろん良い。 というか、よっぽどのブルーオーシャンでないと今の時代一つで尖るのはほぼ不可能な気がする。

依頼された仕事を120%でこなしていく

基本的に依頼する側はここまでやってくれるだろうという期待を持って、仕事を依頼する。 その仕事に対して期待を上回る結果を出せば、周りからの期待も上がっていく。 常に期待を上回るというのは難しいが、期待値コントロールという言葉もあるくらい、戦略としては重要。

自分をブランディングする。

信頼というのは、結局ブランド戦略だ。 OSS活動を小規模でもいいからすすめるというのは重要だと思っている。 とにかくアウトプットをすること。 個人のエンジニアとして価値を向上させていくには、アウトプットは非常に重要だ。 ひたすらインプットをしているというのを時折見るが、ダメだ。 アウトプットのないインプットはオナニーだ。

どうブランディングしていくか?

ブランディング戦略に決まったものはない。 決まっていなければ、まずは小さい組織の中でのブランディングを始めていくのがいい。 いきなり世界に対してのブランディングは精神的ハードルが高い。

その組織の中での自分のブランドを確立し、そこで自信を持つことでより大きな組織でのブランディングができていく。

何をブランディングしていくかがわからない?

世の中には常に自分より優れた人がたくさんいる。 しかし、小さなコミュニティであれば、自分が強みとして持っている部分があるはずである。 まずは世の中全体の中での強みではなくても良くて、そのコミュニティ内で強みと思っているものを伸ばしていくのも一つの戦略である。 小さく初めて大きく伸ばす。これはプロダクトだけではなく、自分のキャリアにも当てはまる。

まとめ

結局エンジニアとしての生き方というより普遍的な話によってしまったが、 言いたかったことは「どう信頼を勝ち取っていくか」だ。 技術力を高める、何かの分野で尖るという話も結局は信頼を高めるための一つの手段だ。 ただその信頼を一つのコミュニティ内で勝ち取っただけで満足していると、ロックインが始まってしまうので、常に更なる大きな枠での信頼を得ることを考えていくべきである。