[etc] : ソリューション型とプロダクト型 Inspired: 顧客の心を捉える製品の創り方
作者: マーティケイガン出版社/メーカー: 株式会社 マーレアッズーロ発売日: 2015/02/07メディア: Kindle版この商品を含むブログ (1件) を見る
経営者が考えるビジネスのロジック 会社の経営は一言で言ってしまえばビジネス(営利・非営利の事業)を作ることであり、そのために人・モノ・金を動かす権限を持つ。ビジネスには様々なモデルが存在し、どのようなエコシステムを目指すかはその会社の経営者が自身で判断しなければならない。最近良く話す内容としては会社経営も成功ロジックを書くことであり、システムエンジニアが処理手続きを書く事と非常に似ている。成功までの最短となるプロセスをロジックを積んだ言語によって書き起こしているだけである。
ソリューション型 成功ロジックの中身をどう書くか。経営でよく上がる話として、ソリューション型、プロダクト型のどちらのビジネスを目指すべきかという点。または両社を目指す場合のコミット度合いの配分をどのように線を引くか。ソリューションは"顧客の課題を解決すること"であり、コンサル、SIなどはここでは含まれる。顧客のビジネスの深い業務知識を保有し、そこに対して他の誰も届けることが出来ない課題解決のコミットメントが継続できるのであれば、顧客の成功体験サポートをし満足度を得ることで、安定的な収益を重ねることができる非常に有効なビジネスだ。その一方で顧客に向き合う人数と時間を必要とする人工型になってしまう。
プロダクト型 対してプロダクト型とは"自社が開発した製品・商品を必要とされる市場に提供する事"とここでは定義する。モノやサービスを中心として顧客の需要に応えていく方針を持ち、自発的なプロセスを回していく。プロダクト型でも製品の提供結果として顧客の課題を解決する(上記のソリューション)ことは可能なので、ソリューション型の定義の中にプロダクト型も含まれるという定義がより近いであろう。自身たちが作るプロダクトの定義や展開先の市場特定もプロアクティブな意思決定が可能であり、課題に対する時間のコントロールが可能。その一方で開発初期においては本当に市場を取れるかどうかの不安が常に残る。
決定的な違いはなにか ソリューション型、プロダクト型の決定的な違いはなにか。それは顧客課題解決に対しての時間の使い方とキャッシュの発生である。どちらを会社の中心ビジネスとして採用するかによって対応する人の姿勢とスキル要件が大きくことなってくるので、会社全体としての顧客課題への向き合い方というものが自然と決定される。ソリューション型は役務ベースでのコミット成果に対する収益であり、プロダクト型は市場浸透に対しての収益となる。両方の型をビジネス目指す会社も多く、特にソリューション型で得られた具体的な知見をヒントに汎用化プロダクト型にシフトしていくやり方だ。ソリューション型の具体例を基に共通化して使える部分を抽象化した形で汎用型のテンプレートを開発し、ビジネスや業務の効率を目指すスタンスはソフトウェアの開発業務でもよく行う。会社内でビジネス変換を個別ソリューション型 = 汎用型プロダクト型に行う場合は全社にその戦略転換を伝達し共通理解と認識を持ち、採用要件が異なる中で集められたメンバーで役割を担う組織を作り、実行していく必要がある。
[etc] : 久しぶりの投稿 1年以上日記を書くことをサボっていました。日記を再開し、これからは仕事やプライベートで感じたこと、調査したこと、考えたことの整理として投稿を再開していきます。最近はメタ思考を意識しながら生きています。できる限り早く成長したいです。
[etc] : 新しい環境で得た学び イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)
作者: クレイトン・クリステンセン,玉田俊平太,伊豆原弓出版社/メーカー: 翔泳社発売日: 2001/07/01メディア: 単行本購入: 59人 クリック: 811回この商品を含むブログ (393件) を見る
2017年4月末から「Innovationで世界を変える」というビジョンを掲げる会社で、ゼロから物を作り顕在的な市場に当てはめることを楽しんでいる状況で、過去の環境では得られなかった 組織体制、採用 について新しい学びがあり、それをメモとして記載します。
Managerという職位をあえて作らない 今の会社は50人程の規模でチーム数は8個程ですが、チーム組織長やプロダクト管理職などの所謂Managerを作らず、全員がフラットな関係で業務を担当していくという姿勢を保っています。チームメンバーに求める事として 全員が何でも自分で考え、自走する ことを行っており、個々のメンバーが重要なポイントであるチームOKRを忘れなければ、意外と成り立つ世界であることが分かります。前提としては、採用のハードルで誰も通らない程の経験や学力レベルでフィルタリングをしている事もありますが、タスクを与えられる事無く自分で考えて行動できる素養をそもそも身につけているメンバーが多くいる(可能性のある人を採用し、中で意識付ける)ということがうまく回っている要因で、このような環境の場合管理者は不要であると感じます。
私も過去には幾つものManager職を兼務しておりましたが、その職位に全く固執していなかったので、常に廃止しても良いと考えていました。Managerがいることによって個々のメンバーは自分の得意専門領域に注力しがちになり、事業や会社を見る視線が低くなってしまう。逆にManager側はメンバーの専門タスクをどううまくコントロールするかという、規模が小さなフェーズの会社にとって使うべきではない時間に追われるなど… 様々な問題があったように感じていました。
まとめると、今の環境は自分がもともと考えていた理想体制にすごく近い。人数が増えてきた時はまた新しい問題が見つかると思いますが、そこまでは今のまま走り続けるべきと思います。
海外からデータサイエンティストを採用する 私のチームは ビジネスを研究し、データサイエンスの価値を提供する ことを行い、機械学習の実務や最新研究への精通、クライアントのニーズを理解して解決方法を提案するコンサルティング能力、潜在顧客のリードから顕在顧客を導き出すマーケティング施策実行など、幅広い業務知識を必要とします。上でも書きましたが、それが故に採用ハードルが高く、人手を必要とするタイミングでも人が取れないという問題が長くあったようです。
採用のハードルを下げることはせず、そして日本のみの人材市場で上の能力を持つ人を探すのはもはや無理というのが会社の結論で、英語を利用した採用に枠を広げることによって、数少ない候補者をなんとか探そうというのが短期的な方針のようです。
私も何名か面接対応をさせていただきましたが、スーパーハイエンドな海外の人材でも日本で働くことに強い動機や意思があり、会社のビジョンや小規模フェーズの体制への理解があるような方からの注目は意外とあり、そういった方が積極的に入社をしてくれることは喜ばしいことです。
当然コミュニケーションが必然的に英語になるわけですが、細かい表現やちょっとしたニュアンス全て伝えきれているかという不安は常にあるので、英語での伝え方を勉強せねばという思いでおります。
最後に 上記以外にも数多くの気付きがありますが、また機会を見つけて書こうと思います。会社全体として自分より何でもできる人が多くいるというのは、知らない経験や世界を人から自身の体験として聞けることは環境として非常に恵まれていると感じますね。
[etc] : Consumer Monopolyの基準 億万長者をめざすバフェットの銘柄選択術
作者: メアリー・バフェット,デビッド・クラーク,井手正介,中熊靖和出版社/メーカー: 日本経済新聞出版社発売日: 2002/05/20メディア: 単行本購入: 6人 クリック: 110回この商品を含むブログ (66件) を見る
GWに部屋の掃除をしたら収納の奥から出てきた「バフェットの銘柄選択術」を十数年ぶりに読んでみた。以前は本の内容をConsumer Monoploy(消費者独占)の性質を企業に対する投資の視点として読み取っていたが、読み直してみると事業を作る企業としてもMonoplolyの対極にあるCommodity企業に染まらないようPositionを確立することが重要であるという内容として感じる。Commodity化された事業についてはMarketへの参入が競争という形であるため市場が存在することは明確であるが、激しい価格競争に打ち勝ち、他社製品との差別化のため圧倒する技術革新を起こす事が求められる。対してMonopoly事業では独占資本市場への参入であるため明確な市場定義は無く、独自ブランド(選択の余地が無い)を確立して企業の価値をZeroから作っていく必要がある。
話を本の内容に戻して、銘柄選択としてのMonopolyの基準としては下記のものがある。 1. 独自ブランド、2.EPSの増加、3.多額負債が無い、4.ROE、5.内部保留利益の再投資状況、6.インフレを価格に転嫁可能 。独自ブランドについては上で書いた通りだが、EPS(Earnings Per Share)、ROE(Return On Equity)といったFundamentals分析も重要であるということ。Fundamentals分析の指標は四則演算で全て求められる単純なものだが、何を意味するかを理解するのが難しいのと指標が分からないまま書を読み進めるのも難しいのでMemoとして下に記載。(計算式を理解することで不足変数を脳内で算出することができる。)
ちなみにバフェットはFundamentals分析も利用した上でMonopoly企業を事前に見定め、そのStockが悪材料によって下がった時に買い妥当な水準に戻った時に売るという手法により成功している。投資の姿勢としてはリスクが高い逆張りをしているわけだが、本当は優秀かつ優良な企業に目を向けて支える投資家としては正しいあり方なんだろうなぁと思う。
時価総額 時価総額 = 株価 * 発行済み株式総数 EPS(Earnings Per Share) : 1株あたりの利益 EPS = 当期純利益 / 発行済み株式総数 BPS(Book-Value Per Share) : 1株あたりの純資産 BPS = 純資産 / 発行済み株式総数 PER(Price Earnings Ratio. P/E) : 株価収益率 PER = 株価 / EPS PBR(Price Book-Value Ratio.
[etc] : Team Geekを読んだ Team Geek ―Googleのギークたちはいかにしてチームを作るのか
作者: Brian W. Fitzpatrick,Ben Collins-Sussman,及川卓也,角征典出版社/メーカー: オライリージャパン発売日: 2013/07/20メディア: 単行本（ソフトカバー）この商品を含むブログ (20件) を見る
GWを利用して積読の消化をを実践中。Googleのギークたちはいかにしてチームを作るのかというサブタイトルが印象的な一冊。主にチームの文化形成やリーダー(マネージャー)としての在り方の部分を重点に自分なりに感じた言葉として纏める。
2章 素晴らしいチーム文化を作る
チーム文化 = エンジニアリングチームが共有する経験、価値、目標。 優秀なエンジニアに働いてもらうためには優秀なエンジニアを採用しなければならない。優秀なエンジニアトップダウンのマネジメントではなく合意ベースのマネジメントを好み、意思決定に参加したいと思う。 建設的な批判はチームの発展や成長には欠かせない。 MTGの数を減らして非同期コミュニケーションを増やすべき。 ミッションステートメントを作成し、注力すること、やらないことを明確化し、プロダクトの方向性の合意を得る。ただしプロダクトのピボットに合わせて修正可能なものとする。 MTGを行う際のルールを作る。 絶対に必要な人だけを呼ぶ。新しいものを設計するMTGには5人以上呼んではいけない。 アジェンダをMTG前に配布。 ゴールを達成したらそこで終了。 MTGを順調に進める。 お昼、終業の前に開始時間を設定する。 Face to FaceのMTGを過小評価してはいけない。 全てのコードはコードレビューされるべき。品質を保つと同時に品質への誇りを持たせる。 3章 船にはキャプテンが必要
Googleではチームリーダーは二つの役割に分かれている。 TL(チームリード) : プロダクトの技術的なものに責任を持つ。 TLM(テクニカルリードマネージャ) : エンジニアのキャリアに責任を持つ。 多くのエンジニアはマネージャーになりたくないと思う。 マネージャーになることは、自身をスケールさせたり、より多くのエンジニアと協力してより多くのコードを書くことができるし、もしくは自分がマネージャーに向いているかもしれない。 必要以上のマネージは行わないこと。例:マイクロマネジメントなど サーヴァントリーダーシップのようにエンジニアが働きやすい環境を整えるために、あらゆる障害を排除することも必要。 採用においては自分の言いなりになる人ではなく、自分より優秀な人を採用すべき。自分より優秀な人は自分の変わりになってくれるだろうし、新しい刺激を与えてくれるかもしれない。 1〜2人ほどのパフォーマンスが低い人がいるだけでチームはうまく回らなくなってしまう。そういった人をチームに残すことはその人のためにもならない。今の場所で成長させるか退席させるかを判断する。 パフォーマンスが低い人へのコーチングは2-3ヶ月で達成する目標を定めてあげる。小さい目標から入って小さい成功体験を何個か積み重ね、次第に目標を大きくしていく。 採用を妥協してはいけない。イマイチな人を採用した結果、採用を妥協したことのコストより大きくなってしまう恐れがある。 チームメンバーの幸せを追い求める。また面談では必要なものを聞く。 チームメンバーにタスクを委譲するものと、自分で手を汚して対応する必要がある。リーダーになって間もない頃であればタスクをメンバーに渡してチームが学習する機会とする。しばらくリードした後であれば他の人がやらないような領域で自ら手を動かし尊敬を集める。 事を荒立たせる必要がある時もあり、その場合は直ぐに着手する。自然解決を待ってはいけない。 人を幸せで生産的にするのは外発的動機づけではなく、内発的動機づけであり、内発的動機づけには自律/熟達/目的の3つが必要。
[DMP] : The Data Management Platform: Foundation for Right-Time Customer Engagement [DMPに関する欧米の調査内容(2012.12)] The Data Management Platform: Foundation for Right-Time Customer Engagement 調査資料
http://www.iab.net/media/file/Winterberry_Group_White_Paper-Data_Management_Platforms-November_2012.pdf
2012年12月にIABから出されたDMPに関する実態調査的な資料を見つけたので目を通してみた。※尚下記で引用される英文説明や図は全て上のリンクからの出典となる。
DMPの概要
出典元の表現としては以下のように書かれている。
the data management platform (DMP), an emerging technology solution that supports “Big Data” implementation for advertisers, marketers, publishers and others looking to aggregate, integrate, manage and deploy disparate sources of data. data management platform(DMP)は分断されたデータソースを集約/結合/管理/配布したい広告主、マーケータ、パブリッシャー、その他...の人たちのための"Big Data"の実装をサポートするテクノロジーソリューションとして用いられる。DMPとしては上図にあるように
AGGREGATE(DATA SOURCES)、INTEGRATE AND MANAGE(DMP APPLICATIONS)、DEPLOY(USE CASES) の3パートに分かれており、データの収集、解析、利用という流れがある。AGGREGATEのフェーズにおいてデータソースとして中核となるのはFirst-Party(クライアントだけが持つデータ)、Thrid-Party(データ公開をしている外部クライアントが持つデータ)としてのデジタル化された行動履歴のデータであり、その他よく使われるものとしてはOfflineのデータ、商品の購買データ、新しいデータソースなどがある。収集したデータソースに対してデータの記録と保管/バラバラのフォーマットにならないようデータの正規化/必要なデータを選択、セグメント化/分析した結果を見て意思を決定する。その先に、デジタルデータの独立したフィードを集約or管理し、インターネットユーザーのより深い興味解析やOnline広告のターゲティングを強化し、mediaのセールス拡大のために行動するであろうインターネットユーザーのセグメントをリッチ化する。更にインターネットユーザーのデジタル体験を最適化するためにデジタルとデジタル以外のデータを集約してあらゆるチャネルをとおしてユーザーとコミュニケーションをする。
[etc] : 機械学習の種類と特徴 人間ではなく機械が自動的に意思決定することのメリットとして、大量のデータをInputとした予測、推定、分類などの処理をAlgorithmの構築によって瞬時に行える事である。 1枚の画像だけを見て何が写っているかのような判断においては人間の脳が優れているものの、大量のデータInputを基にした組み合わせの選択や最適解に瞬時に辿り着くという目的においては機械に任せてしまったほうが効率的とも言える。昔から機械学習による予測、推定、分類などの処理は様々な手法として提案されており、どういった問題を機械に判断させるかという切り口で最適なものを人が選択する。下記表に機械学習の種類と特徴を纏めてみた。※ただし必ずしも6種類のいずれかに分類される訳ではない。例としてニューラルネットワークがあり教師あり学習であり深層学習にも位置する。
機械学習の種類 特徴 代表的なAlgorithm 備考 教師あり学習 正解を持つデータを入力とし、特定の法則に従って予測データの出力を行うこと。
(例) 男女などの正解ラベルがあるデータを入力とし、ラベルが未知のデータに対して法則を適用し予測ラベル出力する。 SVM
NaiveBayes
回帰分析 教師あり学習 - Wikipedia 教師なし学習 正解ラベルなどが無く、データそのものを解析して特徴などを出す手法。
(例) データとして距離的に近いものを同一のクラスタとして定義する。 LDA
LSI
主成分分析
K-Means 教師なし学習 - Wikipedia 半教師あり学習 正解を持つデータの数は少ない場合、正解と未知のデータを合わせて学習することで効果を高める事ができる。
(例) 教師あり学習であるSVMを拡張して既知/未知データを合わせて学習する。 S3VMs(Semi-Supervised Support Vector Machines) 半教師あり学習 - 機械学習の「朱鷺の杜Wiki」 構造学習 個々のデータに対して推定を行わずに全体のデータ構造に最適な形として個々の推定を行う。
[Product Manager] : Good Product Manager/Bad Product Manager Good Product Manager/Bad Product Manager
↑は良いProductManagerとそうでないも内容のまとめ。タイトルについつい釣られて読んでしまったので日本語で起こしてみる。良い/悪いの判断なんて周りが決めることで、もし貴方がProductManagerであるならば例え途中で失敗したとしても自身のProductを成長させたいという信念を曲げずにTryしまくればいいと思いますね。
Good
市場,Product, Productの方向性と競合がどのようにうまくやっているかを知り,精通した基礎知識からの判断と信頼が必要。ProdctのCEOである。製品に対する全責任を取り,Productの成功によって自身を評価する。Productと時間と必要なすべてのものに対して責任を持つ。Contextの方向性も知っている,例えば会社,資金調達,競争等。言い訳をせずにこれらの責任を持ち勝ちプランを実行する。良いProductを良いタイミングで届けるために一緒に協力しなければならない様々な組織に対して時間の時間を全部取り上げるようなことはしない。またチームの時間をとるようなことや様々な機能のProject Manageもしない。自身はProduct TeamではなくTeamを管理する。Engineer Managerとのmarketingの窓口担当になる。ターゲットを定義して「何」(方法とは対照的な)を届けるかという管理を行う。Engineerの人たちと口頭と同じように書き込みでもコミュニケーションをする。非定型的な方向性を与えない。情報を非公式に収集する。FAQやプレゼン,説明資料などを作成する。Productの深刻な問題を発見し現実的なsolutionとして構築する。重要な問題から取り掛かる(差別化の銀の弾丸,頑丈な設計選択,厳しいPorductの決断,攻めや収益のための市場)。チームを収益と顧客に集中させる。多大な力と実行力で良いProductを定義する。インバウンド計画と到達する市場シェアと収益の目標の間に優れた価値を提供することを考える。問題の分解に優れている。プレスに扱われたいstoryを考える。プレスに対して質問をする。プレスとアナリストは賢いことを前提としている。自分の仕事と成功を定義する。訓練されているので毎週ステータスレポートを送信する。
Bad
言い訳を沢山持っている。資金調達が充分でない, Engineering Managerが優秀ではない, Microsoftは10倍のEngineering人材がいる, 自分はハードワークしている,方向性を得ていない。方法論について理解することが最善だと思う。Sales強化のために質問が殺到しそれに答えることに対して不満を言う。一日中問題の火消しになる。口頭で自身の意見を述べ、権限が無く何もできないことを嘆く。失敗を想像する。Microsoftがどのような多くの特徴を持っているかに集中させる。実現できないProductを定義したり必要なものを何でもEngineeringさせる。(それは最も困難な問題を解くこと) 価値の提供と競争力のある機能,価格,普遍性の間の差異について混乱する。全ての問題を一つに結びつけてしまう。多くの特徴をカバーと正確な技術をプレスしたいと考える。プレスのどんな質問にも答えてしまう。プレスとアナリストを区別していないく混ざっている。明白な説明を決してしない。常に誰かから何をすべきかを説明されたいと思う。ステータスレポートの送信を忘れてしまう。
[etc] : scalaのimmutable immutable or mutable, val or var scalaでcollection(List,Seq,Set,Map,Tupple...)を扱う場合はimmutable(不変) or mutable(可変)を使うかで言語内部でのデータの持ち方が異る。また変数の宣言をval(再割当て禁止) or var(再割当て可能)を使うかで実行可否や挙動が変わる。よって2つの観点(immutable or mutable / val or var)の組み合わせで調査をする必要がある。関数型言語ではvalを利用する事が推奨され、scalaのcollectionはdefaultでimmutableが選択されている。よって自然な組み合わせはval × immutableとなり、変数を定義した後に変数に対しては再割当てが行えないので副作用無く安全な方法とされている。これにより通常valで宣言した変数に対して操作を加えた結果を格納する場合はまた別のvalで宣言する必要があるが、collectionにてmutableを用いてvalにて宣言した場合、模倣的な操作が可能なので挙動を追ってみる。
まずはcollection以外の場合、例えばStringなどはval or varのどちらで宣言しても扱うデータとしてはimmutableなので、元のデータに操作を加えた場合後は新しいデータよる再割当てを行おうとする。以下は再割当て挙動、同一性(ポインタが指し示すものが同じ)、等価性(値が同じ)、についての確認。
最初の例ではvalを使用し再割当てできないもの。immutableなのでデータ更新処理で再割当を行おうとしているが変数側のvalでエラーが表示される。
// valで文字列 scalaを代入。 scala val a = "scala" a: String = scala // valで別の変数にコピー。 scala val b = a b: String = scala // valなので再割当てができない。 scala a = a + " java" :8: error: reassignment to val a = a + " java"
[etc] : mysqlでgroup毎のTop-K行を取得する方法 How to select the first/least/max row per group in SQL · Baron Schwartz's Blog
mysqlを用いた特定のgroupに所属する行を一定数ずつ(もしくは何かしらでsortされたTop-K行)取り出したいという問題がある。これしきの事、単純なgroup byを使って簡単に解きたい内容であるがちょっとしたテクニックを必要とする。調べたところ以下の解決方法がある。
1. union allを使ってgroup毎に抽出した結果を結合。
2. tableをgroupで自己結合し特定行数取得。
3. session固有のユーザ定義変数を使って特定group内の行をcountしていく。
因みにposgre/sql serverはrow_number()というgroup毎に数を採番してくれる便利関数が存在してこれを利用するらしいが、mysqlにはまだ無い様子。
解決方法1の場合は各group毎に特定行抽出した結果をunionするのでgroupが増えるとQueryが冗長でダサい。2の場合はgroupのcross結合を行うのでgroupに紐づくデータが膨大だとつらい。よってここでは 3.session固有のユーザー定義変数を使って...について簡単に紹介する。
下はidの昇順にてTop-10を出している。最初の行でsession固有の変数を定義している。SQL中の@group = media_idがGroupの指定。group変数が未定義の場合は1を同一の場合にはnumをincrementしている。subquery内のrow_numberがincrement数なので最後のwhereにてrow_numberが10以下を指定するとTop-10を抽出できる。rand()にてgroup内からrandomで特定行数抽出したい場合はsubquery内のsubqueryで最初にrand()しておくと良い。
set @K := 10, @num := 0, @group := ''; select id, media_id from ( select id, media_id, @num := if(@group = media_id, @num + 1, 1) as row_number, @group := media_id as mid from contents -- randomに切り替えたい場合はfromとして下記を利用 -- from (select id, media_id from contents order by rand()) as c order by media_id ) as t where t.