やーまんぶろぐ

気が向いた時にだけ書くブログ

英語で読み解く ドラッカー『イノベーションと起業家精神』 メモ

この本の中では「変化をチャンスと捉えて、その変化を活かして新しい価値を生むこと」をイノベーション、「そのイノベーションという手法を使って、新しい価値を生む事業を立ち上げる人がアントレプレナー(起業家)」としています。

著書「イノベーション起業家精神」を原文そのままで読むことで、ドラッカーの本当に伝えたかった意図に気づくことができる。というものです。

キーセンテンスがまとまっているので、非常に読みやすい作りになってました。

英語で読み解く ドラッカー『イノベーションと起業家精神』

英語で読み解く ドラッカー『イノベーションと起業家精神』

The Practice of Innovation イノベーションを起こす

起業家精神は理論として実践でき、体系的に学ぶことができるものだとしています。その理論とは、変化を当然かつ健全なものと見ることで、以下の7つの変化の種があります。

  • The unexpected 予期していなかった結果
  • The incongruity 不一致、ギャップ
    • 不一致、ギャップを適した形に変えることでイノベーションを起こす。「アクションはまずは小さく、シンプルに、フォーカスを利かせて」が鉄則。
  • Innovation based on process need プロセスニーズ
    • 明確な目的があるプロセスの中で生まれるニーズ。既に存在している仕事や作業の確立されたプロセスの中に生じるtask focused。
  • Changes in industry structure or market structure that catch everyone unawares 業界と市場構造の変化
    • 旧来型のビジネスを続けていくことは、ほぼ崩壊を保証するものであり、会社に滅亡を宣告するようなものだ。
  • Demographics(population changes) 人口動態
    • 近い将来に動く人口動態とそこから生まれる新たな機会は、誰でも予測することができる。
  • Changes in perception, mood, and meaning 認識の変化
    • 認識というのは目に見えないので変化を捉えるのが難しい。
  • New knowledge, both scientific and nonscientific 新しい知識
    • 「知」によるイノベーションが最強。完成したビジネスシステム、市場の絞り込みと集中、戦略的に優位なポジションで独占することが成功の鍵。

The Practice of Entrepreneurship 起業家的にマネジメントする

イノベーションを起こし、成功させ続けるための組織マネジメントについて書かれています。以下の6つにポイントを意識します。

  • policies 考え方
    • イノベーションを魅力的で、自分たちにもメリットがあるものだと捉えることが重要。破棄こそがイノベーションへの一歩で、変化をチャンスと捉えるようにマネジメントされなくてはならない。
  • practices 実施作
    • 問題に意識を奪われるよりも、チャンスに焦点を合わせること。最も価値のあるせいかとは、組織全体の考え方や風土が変化していくこと。
  • measurement 評価
  • structures 組織
    • 旧来の既存事業とは切り離して運営する。
  • staffing 人材
    • 必要なのは学ぼうとする姿勢。
  • dont's タブー
    • 自社の得意領域から外れたイノベーションのための努力は、成功する確立が極めて低い。

Entrepreneurial Strategies 起業家的に戦う~戦略~

具体的に4つの形の戦略が書かれています。

  • Fustest with the Mostest 最速、最強の戦略
    • その市場の中でリーダーの地位を獲得することが目的。最も優れているが、最もギャンブル性が高い。
  • Hit Them Where They Aint't 不意を突く戦略
    • 敵がきづかないうちに攻めよ。創造的模倣戦略は、ほぼ完成している製品をより完全なものにし、市場で適切な場所に位置づける。起業家的な柔道戦略は、ほぼ完成していたビジネスの種を事業化して成功を収める戦略。最もリスクが低く、成功しやすい。
  • Finding and occupying a specialized "ecological niche" ニッチ狙いの戦略
    • ニッチ戦略は他者からの脅威にさらされることが少ない。料金所戦略、専門技術戦略、特殊マーケット戦略がある。
  • Changing the economic characteristics of a product, a market, or an industry 製品、市場、産業の経済的価値を変える戦略
    • 顧客を創造する戦略。紅葉を創り出す戦略、値づけ戦略、顧客側の社会的・経済的事情に適合する戦略、顧客にとって真に価値あるものを提供する戦略がある。

英語で読み解く ドラッカー『イノベーションと起業家精神』

英語で読み解く ドラッカー『イノベーションと起業家精神』

DDoS関連のCloudWatchメトリクス

AWSのDDoS対策ですが、これから検討している方はまず実際に攻撃されてるかをCloudWatchで確認することをお勧めします。

DDoS関連のCloudWatchメトリクスは、AWS上でのDDoS対策資料のp55に一覧があるのでメモしておきます。
AWS Solutions Architect ブログ: [AWS Black Belt Online Seminar] DDoS 対策 資料及びQA公開

名前空間 メトリクス 説明
CloudFront Requests HTTP/Sリクエスト数
CloudFront TotalErrorRate 全リクエスト中HTTPステータスコード4xx/5xxの割合
Route53 HealthCheckStatus ヘルスチェックエンドポイントのステータス
ELB SurgeGueueLength ロードバランサーでバックエンド応答を待っているリクエスト数
ELB UnHealthyHostCount AZ中のunhealthyなインスタンス
ELB RequestCount 登録インスタンスに転送した処理済みリクエスト数
ELB Latency ロードバランサーがリクエストを転送してから応答までの経過時間(秒
ELB BackendConnectionErrors 失敗したコネクション数
ELB SpilloverCount キュー飽和により拒否されたリクエスト数
AutoScaling GroupMAXSize オートスケーリンググループの最大サイズ
EC2 CPUUtilization CPU使用率
EC2 NetworkIn ネットワークインターフェースでの受信バイト数
DDoSProtection DDoSAttackBitsPerSecond DDoS攻撃の秒あたりビット数(0より大はDDoS攻撃検知)
DDoSProtection DDoSAttackRequestsPerSecond DDoS攻撃の秒あたりリクエスト数(0より大はDDoS攻撃検知)

DDoSProtectionsは「AWS Shield アドバンスド」のことです。

本番環境だけでなく、検証環境のリソースも確認しておきましょう。
自分の環境で確認してみたところ検証環境のELBのSurgeQueueLengthが単調増加していて、ログからアクセス元のIPを確認してみると外国からたくさん攻撃されてくることがわかりました。

私は検証環境だったので削除することで対応しましたが、本番環境の場合はWAFでIPをブロックするなどの検討が必要になります。

冒頭にも書きましたがまずは確認することをおすすめします。

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント メモ

Googleの働き方に対する考え方がわかる本です。

How Google Works (ハウ・グーグル・ワークス)  ―私たちの働き方とマネジメント

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

Googleのように優秀なエンジニアが成り立たないような考え方も多かった気もしましたが、新しいものを生み出すためには参考になる考え方がたくさんありました。

文化

スマートクリエイティブという言葉が頻繁に出て来ます。
自分の専門分野の深い知識を知性・ビジネス感覚やさまざまなクリエイティブな資質と組み合わせる人物のことです。

既存のビジネスではなく、新しいビジネスを生み出すためには、このスマートクリエイティブのような人材が求められているのだと感じました。

7つのルール(マネジャーは最低7人の直属の部下を持つこと) というのが印象的でした。
階層構造ではなく意思決定者を近くにおくことで組織をフラットに保つことが重要なようです。

マネージャーを少なくして、スマートクリエイティブ達が素早い意思決定を行えるようになっているのがGoogleの強みなんだと感じました。

戦略

市場調査はしない、技術的アイデアを中心に考える、顧客には聞かない。というように完全なプロダクト主義のようです。
個人的にはプロダクト主義こそ顧客に細かくぶつけながら開発していかないと市場と乖離したものが出て来てしまう気がするのですが、、

Dogfoodingな製品なら可能なのか?それともスマートクリエイティブならそれくらいできて当たり前なのか?

この部分はそのままは参考にできないかなと感じました。

人材

大事なのは「何を知っているか」ではなく、「これから何を学ぶか」というのが共感できました。環境変化が激しく、自分も1年間同じ働き方をしたことがないので、これからも「何を学ぶか」を大事にしていきたいと感じました。

人材を簡単にスケールさせる方法として、全社員が自分より優秀だと思う人を1人連れて来ればよい。というのが印象的でした。

新入社員のリクルーター活動をやったことがあるのですが、あれはある程度の人材をある程度の人数集める活動でしかないと感じました。
その活動の中で甲子園に同じ高校が毎年出られるのは、リクルーティングと教育がしっかりしているからというのを聞きました。

そのときはリクルーティングに力を入れる具体策は思いつかなかったですが、Googleのように全社員に人を集める権利持たせるというのも面白いと思いました。

意思決定

データに基づいて意思決定すると良いみたいです。

コミュニケーション

どんな情報でもオープンにする。

なんとなくですがGoogleはメール文化なのかな?と感じました。
個人的には入社してからずっとチャットでのコミュニケーションをとってきたので、メールが多いだけでがっかりしてしまいます。

場所を問わずリアルタイムにコミュニケーションを取れるチャットは便利ですね。

イノベーション

有名な20%ルールの話もでてきます。
個人的には20%で集まってきた人は、日が経つにつれて既存の80%の業務を優先して参加しなくなる傾向があると思っています。

新しいことをやるには、100%それに力をかけれる環境作りが大事だと思っています。
新しいことに力を入れているときは、余計な業務を振らないでほしい。

How Google Works (ハウ・グーグル・ワークス)  ―私たちの働き方とマネジメント

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

インシデント対応ボードゲームの参加メモ

社内で行われたインシデント対応ボードゲームに参加しました。

sp.trendmicro.co.jp

インシデント対応ボードゲームとは、実際にインシデントが発生したと仮定し、各プレイヤー同士がどのようにインシデント対応を行うべきか、それぞれの立場・視点で議論するというものです。

私のグループは以下の4つの役割になりきって実施しました。

  • CIO
  • システム管理者
  • セキュリティ担当者
  • 広報担当者

私はセキュリティ担当者でした。

ゲームを進める上で、前提を明確にしないと判断できない部分が多々あり、認識をすり合わせながら進めるのが難しいと感じました。

反対にインシデント対応の意志決定をするためには、いくつか情報が必要というのが気づきになります。

例えば、自社のトップページ画像が改ざんされたときに、前提によってインシデント対応が変わってしまいます。

現在改ざんの影響がわかっていない、社内にセキュリティのことがわかるエンジニアがいない、外部ベンダーを呼ぶ費用はこれくらい、停止したときの被害がこれくらいなどを決めておいて初めて意思決定できて、議論することが可能になります。

実際にインシデントが起きたときには余裕ないと思うので、
普段からシミュレーションしておくことを心掛けたいと思いました。

RDSを定期的に停止するスクリプトを作成してみた メモ

ちょっと前ですがRDSが停止をサポートしました。
Amazon RDS でデータベースインスタンスの停止と開始をサポート

以下のリンクを参考に定期的に停止するスクリプトを作成しました。
(テストしづらかったので、環境変数はCloudwatch EventではなくLambda側に持たせることにしています。)
dev.classmethod.jp

試しに停止中に停止コマンドを実行してみると以下のエラーが発生しました。
operation: Instance hoge is not in available state.

7日より使用頻度が少なかったので延長してくれないかなと思ったのですが、さすがに無理でしたね。
(最大7日間の停止で、7 日後に自動的に開始されてしまうという制約があります)

しょうがないので毎日定時で停止するようにして、起動時間をなるべく短縮することにしました。

2017/11/3 追記
シングルAZ構成のRDSインスタンスのみが対象で、マルチAZ構成では停止/開始できないので注意が必要。

Amazon Dash ButtonとMacを連携させてみた

Amazon Dash ButtonとMacを連携させてみました。

基本的には下の記事を参考にさせてもらってます。

qiita.com

Node.jsとnpmのアップデート

Node.jsとnpmが古い場合は事前にアップデートしておきましょう。
yamano3201.hatenablog.jp

$ node -v
v7.4.0

$ npm -v
4.0.5

Amazon Dash Button の購入

以前、購入したときの記事です。
yamano3201.hatenablog.jp

このとき購入した「食器用洗剤」の他に、「トイレットペーパー」と「ティッシュ箱」と今回の「Mac連携用」の計4つを購入しました。

Amazon Dash Button のセットアップ

1.Amazonアプリの左上ハンバーガーメニューより「アカウントサービス」

2.下部にあるDush端末の「新しい端末をセットアップ」

3.表示される通りDushボタンの電源を入れ、Wifiに接続

4.Wifiに接続完了すると商品を設定する画面が表示されるのでここでやめる。

ここは参考サイトそのままの手順になります。
ボタンを押したときのスマホへのPush通知をオフにするために、
Amazonアプリの「端末を管理」から、「このDash Buttonを無効にする」で無効にしておきます。

node-dash-buttonを使ってAmazon Dash ButtonのMACアドレスを取得

$ npm install node-dash-button
$ sudo node bin/findbutton
Watching for arp & udp requests on your local network, please try to press your dash now
Dash buttons should appear as manufactured by 'Amazon Technologies Inc.' 

# ここでAmazon Dash Button を押します

Possible dash hardware address detected: XX:XX:XX:XX:XX:XX Manufacturer: Amazon Technologies Inc. Protocol: arp

XX:XX:XX:XX:XX:XX の部分が取得できたMACアドレスになります。

node-applescript を使って Apple Scriptを動かす

ここではsayコマンドでMacに喋らせるScriptを用意しています。

$ npm install applescript
$ cat << EOF > script.applescript
tell application "System Events"
    say "test"
end tell
EOF

続いて、Amazon Dash Buttonが押されたタイミングで Apple Script を実行するJavaScriptを用意します。
XX:XX:XX:XX:XX:XX には事前に取得しておいたMACアドレスを入力します。

$ export MAC_ADDRESS=XX:XX:XX:XX:XX:XX
$ cat << EOF > app2.js
var applescript = require('applescript');
var dash_button = require('node-dash-button');
var fs = require('fs');
var dash = dash_button("${MAC_ADDRESS}", null, null, 'all'); 
dash.on("detected", function (){
    console.log("test");
fs.readFile('./script.applescript', 'utf8', function (err, script) {
        applescript.execString(script, function(err, rtn) {
            if (err) {
                // Error
                console.log(err);
            }
        });
    });
});
EOF

このJavaScriptも参考サイトそのままです。

動作確認

$ sudo node app.js

# ここでAmazon Dash Button を押します

test

ターミナルに「test」と出力され、Macからも声として出力されればOKです。

最後に

思ったより参考にしていた記事と変わらなくなってしまった。。
あとは好きなコマンドに変えれば面白いことできそうですね。アイデアは考え中です。