プログラマでありたい

おっさんになっても、プログラマでありつづけたい

「勘違いをなくせば、あなたのホームページはうまくいく」を読みました

 著者の中山さんに「勘違いをなくせば、あなたのホームページはうまくいく」を頂きました。ありがとうございます。

f:id:dkfj:20180108221426j:plain

対象読者


 この本は直接的には自社ホームページの運用を改善する為の指南書です。その為に対象読者は、次のような方となっています。

・ウェブ活用がなかなかうまくいかない中小企業の経営者
・がんばってホームページを作ったのに,売上が増えずに困っているWeb担当者
・本やネットで必死に学んだのに,ホームページやWebで成果を出せずに悩んでいる方

 一方で、私はもっと色々な人に読んで貰えると良いと思っています。この本は、実は目的をどのようなプロセスで達成するかを書いた本なのです。そのプロセスの具体例としてはホームページ運営を使っていますが、他の分野でも充分応用が聞くと思います。私も、この本を読んでいて、直接的にはこのブログの改善のことを考えましたが、それ以外に現在の仕事を拡大させる為の戦略・道筋を考えながら読んでいました。

「勘違いをなくせば、あなたのホームページはうまくいく」の構成


 上記の通り、単純なSEOのように如何にホームページの集客力を集めるかというテクニックの話ではないです。利用者目線でホームページを作る時にどういう心理になるのか、またそこで陥りやすい行動は何か筆者のWebコンサルタントとしての豊富な経験を元に1つ1つ具体例をあげて解説しています。章立てとしては次の10章構成で、章タイトルも全てユーザーが陥る勘違いをベースとなっています。

第1章 ホームページのビジネス活用に関する勘違い
第2章 社内体制・ウェブ担当者に関する勘違い
第3章 パートナー会社選びの勘違い
第4章 ホームページ制作に関する勘違い
第5章 コンテンツ作成に関する勘違い
第6章 集客に関する勘違い
第7章 SEOに関する勘違い
第8章 広告に関する勘違い
第9章 アクセス解析に関する勘違い
第10章 オフラインとの関係に関する勘違い

 実はこの本、昨年末に頂いていました。思いの外読むのに時間が掛かって、感想書くのが随分と遅くなりました。私は自分で言うのも何ですが、結構読むスピードが速い方です。この本も一時間くらいで読めるかなと思ってたのですが、その何倍も掛かりました。理由としては、自分が知らないことが沢山あって色々驚きながら考えながら読んでいた為です。

著者の中山陽平さんについて


 ところで、著者の中山陽平さんについてです。中山さんはWebコンサルタントとして独立・会社設立をしていて、600社50業種以上のコンサルティング経験があると非常にWebに関して造詣の深い方です。私は中山さんの前職時代に仕事を通じてお付き合いがあり、独立後もSNSを中心にやりとりが続いています。
 この中山さん、とにかく頭の良い方です。それでありながら現場主義で、まず自分が経験して考えるということを徹底されています。PodcastとかWebでの連載とか色々あるので、興味を持った方はまずググってみてください。
 

どんな形式で解説しているのか?


 ちょっと本の内容から外れた話ばかりしていたので、具体例を1つあげます。4章のホームページ制作の勘違いの中に、「扱っている商品をすべてホームページに載せないと機会損失になる?」という問があります。これに対しての答えが、全ての商品を並列に扱っても意味がなくサービスを分類した上で導線を考えることの重要性が説明されています。
 まず商品やサービスをフロントエンド・ミドルエンド・バックエンドの3つに別けます。フロントエンドは、一番最初に売れるもので買い手にとっても買いやすいものです。ミドルエンドは、その次に買うもの。バックエンドは、ファンになってくれた人が買うものと定義しています。これを中山さんのサービスの実例を元に、導線設計を解説しています。主力製品がバックエンドだったとしても、それだけを一生懸命説明しても意味がないって話ですね。私自身陥りがちな事なので、身につまされました。

f:id:dkfj:20180108230242j:plain

感想


 とりあえず一読しましたが、折に触れて何度か読み直そうと思います。実践して上手くいかなければ、もう一度読み直して立ち返るというスタンスの本かなと思います。あと読んでいて、私もいつか技術書ではなくビジネス書を書いてみたいなと思いました。私はAWSやクローラーによる情報収集技術を得意としているのですが、じゃぁそれを使ってビジネスにどう活かすのか、そんな視点で考えてみたいと思います。宣伝ですが、AWS本の第三弾、「Amazon Web Services 業務システム設計・移行ガイド」がもうすぐ発売します。こちらもよろしくお願いします。

勘違いをなくせば、あなたのホームページはうまくいく ~成果を上げるWeb制作・ネット集客・販促戦略の心構え

勘違いをなくせば、あなたのホームページはうまくいく ~成果を上げるWeb制作・ネット集客・販促戦略の心構え

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

See Also:
Amazon Web Services 業務システム設計・移行ガイドの目次
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました
「この一冊で全部わかるWeb技術の基本」の監修をしました
「データを集める技術」という本を執筆しました
アプリケーションエンジニア向けのAWS本を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました

2017年の振り返りと2018年の目標

 あけましておめでとうございます。今年もよろしくお願いします。毎年恒例となってきているので、正月のうちに1年を振り返ってみます。2017年の主な活動は、出版2冊と雑誌寄稿2回、後は職務上の役割変更でした。

5,6冊目の本の出版


 まず出版ですが、5冊目の本としてイラスト図解式 この一冊で全部わかるWeb技術の基本の監修し2017年3月に出版しました。また、まだ発売はしていませんが自身6冊目の本、AWS本の第三弾として、Amazon Web Services 業務システム設計・移行ガイドを2018年1月に出版します。


 Web技術の基本は、その名の通りWebに関する入門書です。これからITエンジニアを目指す人や、なりたての人、或いはIT業界に入ったのでWebとはなんぞやと知りたい営業・企画の人など、非エンジニアでも読めるように意識して書かれています。そもそもWebと一口に言っても、現在では凄く範囲が広がっています。昔は、Webサイトと電子メールが解っていれば充分でしたが、今やスマホアプリやIoTもWebの副産物となっています。ITのニッチな分野であったWebが、今や大部分を占めるようになってきています。ということで、そんなWebを体系的に学ぶ為の一冊となっています。
 この本に関しては監修ということで、基本的には殆ど書いていません。NRIネットコムの後輩で、大学時代にしっかり情報工学を学んでいた2名に書いてもらいませいた。私はちょこっとコラムを書いたくらいで、初期の構成と後は出来上がってきたものを確認するという役割でした。しかし、出来上がったものも、よく書けていたので余りすることがなかったというのが正直なところです。
 今までAWS本やクローラー本と、どちらかと言えばニッチな分野の本ばかりに関わっていました。この本で初めて、IT本のメインストリームといえるような分野に関わらせて貰いました。感想としては、やはりメインストリームは読者層のボリュームが大きくて面白いです。こういった分野で自分に何ができるか、もう少し考えてみています。

イラスト図解式 この一冊で全部わかるWeb技術の基本

イラスト図解式 この一冊で全部わかるWeb技術の基本


 Amazon Web Services 業務システム設計・移行ガイドは、過去2冊のAWS本と違い技術ではなく「利用する人」にフォーカスした本です。これから社内でAWSを利用する方や、管理する方向けに書いた本です。AWS本は数あれど、どの本もAWSのアカウント1つで構築すること前提で書いているものが殆どです。しかし、企業内ではAWSのアカウントが5個10個とゴロゴロとしているのが現実です。それをどう管理するのか、実際の利用している事業部門も情報システム部門も頭が痛い問題です。その辺りを真正面から取り組んでいます。発売は、もう少し先ですが是非読んで頂ければと思います。

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

雑誌寄稿


 今年も2回、日経クラウドファーストに寄稿しました。SQSの話とDynamoDB
NoSQLデータベース - Amazon DynamoDB | 日経クラウドファースト - AWS・Azure導入の先端技術情報-
の話です。SQSの話だけで特集を組める機会は中々ないので、わりとノリノリで書かせて頂きました。
 日経クラウドファーストの執筆陣は、AWSのプレミアパートナーを中心に集められています。本当に濃いメンツで、定例会議にいくと非常にためになる話が聞けます。勉強させて貰いながら、原稿も書かせて貰えているのでありがたい限りです。

職務上の役割変更


 2017年4月から所属する会社で部長になりました。あまり職務上の事は書けないけど、考えないといけないことは思っていた程はあまり変わらず、しかし感じ方はだいぶ変わったような気がします。この辺りは、どこかで一度整理しようと思います。ようやく少し慣れてきたので、来年は少し攻めていこうと思います。

ブログ


 2017年は何と18本のみでした。2016年は53本だったので、大幅減です。一方でブログのアクセス数は、2017年は228,420ページビューと2016年に対して62%増です。ブログの執筆数が減ったのは、AWS本絡みで執筆に対して大スランプに陥ったこと。書くリズムが完全に狂いました。その一方でアクセス数が増えたのは、長年の懸案であった検索減の原因が解消したこと。

f:id:dkfj:20180101013350p:plain

 顛末は、「3年近くGoogleからSEOスパム扱いされていて、ようやく解消した話」を見て頂ければ幸いです。本出版しだしてからの期間がゴソッと検索に掛からなくなっていたので、もったいない限りです。またせっかく検索されるようになってきたので、それに対応するコンテンツ増やそうと思いつつ書けていないので、ここは2018年は頑張りたいところです。

2017年の目標に対しての採点


 2017年の目標は、これでした。

  • 本を2冊書く ⇒ ◯ ちょっと嘘くさいけど、とりあえず達成
  • Kindle本を書く ⇒ ☓ 今年も実現できず。こちらを優先すべきというのは解ってはいるものの。 
  • AWS本の英訳 ⇒ ☓ とりあえず実験的に英語ブログを立ち上げて、一記事だけ投稿してみた。これを継続から始めたい 
  • 資格試験 ⇒ ☓ 新3種が日本語化されていないのでスキップ。ワインエキスパート、申込みしなかった。
  • ワークバランス ⇒ △ ここはイーブンくらい。残業時間は前年度比で減らした。
  • メジャーイベントへの登壇 ⇒ ☓ 引きこもりすぎて、メジャーどころかイベント登壇ゼロ。
  • 健康 ⇒ △ FitBitを使いだして歩数・睡眠時間は意識しだした。走るとかは元々無理なので、出来るところを意識する。

2018年の目標



  • 本を2冊書く ⇒ 今年も2冊は書く。既に書籍企画が6〜7件あるので、どうこなすか考え中。
  • Kindle本を書く ⇒ 今年こそ。完全に自分でコントロールする本を書いてみたい 
  • ブログ ⇒ 40記事。400,000ページビュー目指す。 
  • 英語ブログ ⇒ 過去記事の翻訳を含め30記事。30,000ページビュー目指す。 
  • 資格試験 ⇒ 新3種が日本語化されたら受ける。ワインエキスパート、申込みする。
  • ワークバランス ⇒ 平均残業時間30時間未満。望み小さいけど、まずはここから。
  • 健康 ⇒ 睡眠時間平均7時間。週5で体操。1万歩/日
  • 3つ目の分野 ⇒ クローラー/AWS以外にもう1つ露出できるような分野を作る

まとめ



 まわりの凄い人を見ていると焦るけど、今年も自分ができる事を1つ1つやっていきます。

See Also:
2016年の振り返りと2017年の目標
2015年の振り返りと2016年の目標

「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました

 AWS本の第三弾として、Amazon Web Services 業務システム設計・移行ガイドという本を書きました。その名のとおり、企業内でAWSを使うということにテーマを据えています。ユーザー企業の情シスの人も、事業部で直接AWSを使っている人も、或いはSIerでユーザー企業にAWSを提案している人にも読んで欲しい内容となっています。

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

Amazon Web Services 業務システム設計・移行ガイドを書いた理由


 過去2冊AWSの本を書いていて、一冊目のAmazon Web Services パターン別構築・運用ガイドは、AWS上にサーバーサイドのシステムをどう作るのかをサービスを中心に解説しています。2冊目のAmazon Web Services クラウドネイティブ・アプリケーション開発技法は逆にアプリケーションエンジニア目線で、AWSのサービスを使ってどうやって楽してアプリを作るかという本です。
 3冊目であるAmazon Web Services 業務システム設計・移行ガイドは、技術ではなく利用する人をベースにしています。例えば、企業内でのアカウント管理。普通に使っていると、AWSアカウントは1つではなく5個10個とドンドン増えてきます。それをどう管理すれば良いのか。開発環境や本番環境を、1つのアカウントで運用するのか、或いは環境ごとにアカウントをわければ良いのか。ケースバイケースで違うのですが、その考え方を書いています。
 つまりこの本は、普段業務としてAWSの導入支援する際にユーザーから相談されることをベースに、その1つの解になるように目指しています。対象とする範囲は、アカウント管理やIAMユーザー管理、社内システムとの連携をベースにしたネットワーク設計からセキュリティ・データ移行・運用と多岐に渡ります。企業にAWSを導入する際には、必ず参考になると思います。

Amazon Web Services 業務システム設計・移行ガイドの構成


 本書は、7章構成です。 ページ数も400ページ弱と、前2作に比べて、だいぶ薄めになっています。最初にAWSのサービスを紹介した上で、2章で本書で取り扱う内容の説明と指針をかいています。その後、3章以降で具体論を解説しています。わりと実用的な内容になっているのではと思います。

Chapter1 AWSサービスの概要
Chapter2 全体設計(管理方針と移行計画)
Chapter3 アカウント管理と権限付与
Chapter4 ネットワーク接続の設計・構築・維持管理
Chapter5 システム設計とサービスの導入
Chapter6 移行テクニック
Chapter7 運用監視の設計・実施

Amazon Web Services 業務システム設計・移行ガイドの執筆陣


 本書は、NRIグループの5人で書いています。林 晋一郎さんは、1冊目であるAmazon Web Services パターン別構築・運用ガイドの共著者で、NRIネットコムでAWS構築・運用の実務面の責任者です。何十というシステムの構築・運用を手掛けて来て、運用する自分自身が困らない設計・構築技法を身に着けています。6章の移行テクニックと、7章の運用監視の設計・実施を執筆しました。
 瀬戸島 敏宏さんは、野村総合研究所でAWSの実務面を取り仕切っています。Amazon Web Servicesクラウドデザインパターン設計ガイドの改訂版も執筆していました。また、NRI主催の各種ハッカソンやOne JAPANという企業横断プロジェクトのNRI代表などをしている多芸な人です。今回は、5章のシステム設計とサービスの導入を執筆しています。
 宮川 亮さんは、NRIグループのAWS周りのネットワークを一手に引き受けるスペシャリストです。NRIが提供するダイレクトコネクトサービスの設計・運用責任者として、通信キャリアやAWSと日々ハードネゴシエイトしています。開設したダイレクトコネクトの数は、おそらく日本有数だと思います。4章のネットワーク接続の設計・構築・維持管理を執筆しました。
 金澤 圭さんは、普段は大手B2C企業のAWSシステム構築を担当しています。最近はもっぱらサーバーレスアーキテクチャに傾倒していますが、今回は業務システムの話を書いてもらいました。何気に5人の中で、担当した部分が一番多いです。3章のアカウント管理と権限付与と、5章のシステム設計とサービスの導入を執筆しています。
 私(佐々木拓郎)の方は、全体的な構成と1章のAWSサービスの概要と2章の全体設計(管理方針と移行計画)を担当しています。

 著者陣に共通するのは、みんなAWSを使い倒しているということです。SIerの中の人と聞くと、手配師になってExcel方眼紙を触るだけの人と想像するかもしれません。しかし、そんなやり方をしないメンバーが集まって、この本を書き上げました。

まとめというか感想


 本書は、とにかく執筆に苦労しました。下のコミット履歴をみてみると、2月くらいから手掛けていて出版までほぼ一年掛かっています。理由としては、今まで執筆してきた中で一番業務に直結することなので、どこまで書けばよいのか逆に解りづらくなってしまったことにあります。また執筆は、業務時間外の平日夜間や休日に書くこともあり、本書の内容から土日も仕事をしているような感じでモチベーションが沸かなかったこともあります。まぁ凄いメンバーで何とか書ききれたので、私としては満足です。

f:id:dkfj:20171225092417p:plain

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

目次編
Amazon Web Services 業務システム設計・移行ガイドの目次


See Also:
「この一冊で全部わかるWeb技術の基本」の監修をしました
「データを集める技術」という本を執筆しました
アプリケーションエンジニア向けのAWS本を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました
『Rubyによるクローラー開発技法』を書きました

獺祭の適正価格に関する雑感

 もの凄く炎上しそうなので躊躇してますが、言いたいことが沢山あるのでつらつらと書いてみます。

日本酒と酒蔵を巡る現状


 まず予備知識として、日本酒を取り巻く状況を確認します。日本酒の国内出荷量のピークは1970年ごろで170万klで、現在はその1/3くらいの60万klまで減っている。造り手である酒蔵も減っていて、3,000以上あった酒蔵も今では1,400件程度になっています。この数字だけ見ていると、見事に市場は縮小しています。一方で興味深い数字もあります。特定名称酒とされる吟醸酒、純米酒の出荷量は堅調です。一番高い純米吟醸酒については、逆に増えています。
 ここの数字を見ていると色々と面白い物が見えてくるのですが、年間5,000kl以上の大規模生産者は15社あって、その15社が日本酒出荷の半分を担っています。そしてその生産の大半が、特定名称酒以外(≒安い酒)です。逆に規模が小さい生産者ほど特定名称酒の出荷割合が高いです。
 つまりは、小さい所ほど高級化路線の模索をしているのが垣間見れます。と言うより、生産量が少ないので付加価値高い物を売っていくしか生きていけないのでしょう。

f:id:dkfj:20171212003029p:plain

出典 
清酒製造業の概況(平成28年度調査分)日本酒をめぐる状況 - 農林水産省
清酒製造業者数の推移

獺祭の広告


広告の目的については、獺祭の旭酒造の社長インタビューの記事があるので、そちらをご参照ください。目的としては希望小売価格と取扱店を知らしめるという事のようです。キャッチーなコピーはどうかと思いますが、かなりの反響だったのでマーケティングとして成功なのではないでしょうか。

日本酒「獺祭」の蔵元、旭酒造が「高く買わないでください」と呼びかける新聞広告を掲載。広告に込めた思いを聞いた。

適正価格とは?


togetter.com

 この件で個人的にずっと引っかかってるのが、適正価格って何という話です。私は学生時代は経済学部だったので基本的には需要と供給が価格を決定するというシンプルな考え方が根底にあります。また、社会に出てから様々な商品の販売戦略、マーケティングを横で見てきて、価格を決めるという事の難しさも知っているつもりです。一方で個人的な体験として、買い手がいる価格に収斂していくという事も感じています。
 10年以上前にアメリカのグループ会社で働いていました。その時は結構暇だったので、eBayで買って日本のヤフオクで売るというせどり的な事を興味本位で幾つかの商品でやってました。その結果、商品の知名度(市場規模)で2つの傾向があることが解りました。知名度が高いものは、仕入れの価格帯もほぼ同じで常に商品がある代わりに、一定の手数料分をつけた値段でしか売れない。Fire Kingのマグカップやらポラロイドカメラがこのパターンです。Fire Kingはだいたい2,000円くらいで買ってヤフオクで4,000円くらいで売れるという感じです。倍で売れても送料やら手数料で利益は殆ど出ないです。買ってる方も、雑貨屋さんが仕入れとして買ってるケースが多く、店頭では8,000円くらいで売られていたようです。話を聞いてみると、手間を考えると別に儲かるものではないが、定期的に入荷する事でそれ目当てのお客さんが来るので入れているという感じのようでした。ちなみに知名度が低いものは必要とした人が探して買うと言うものが多く値段とはあまり関係なく売れました。
 話をFire Kingのマグカップに戻すと、元々は数百円だったものがアンティーク化されて一万円近い値段になった訳です。また、それぞれの工程で倍々の値段になっても売れます。結局、買う人がその値段に納得して買っているのであれば、何でも良いのじゃないと考えています。モラルの問題では無いと思います。もちろんお酒の場合は保存状態で品質劣化して造り手としては悩ましい問題なのは解ります。また、ニンテンドースイッチのように転売屋が買い占めるというのも望ましくないでしょう。ただ高くても良いから買いたいという人に、知恵と手間かけて商売している人がいても良いのではと思ってます。

ところ変われば値段も変わる



 少し話変わりますが、レストランでボトルのワインを注文した場合、小売店の店頭価格に対してどれくらいの価格差があるかご存知ですか?どのような店舗形態かによっても大きく変わりますが、一般的には3〜5倍という価格設定が多いです。つまり、レストランで3,000〜5,000円で売っているワインは、酒屋で1,000円のワインです。メニューで5,000円という値段をみるとかなりの高級ワインに感じるかもしれませんが、ごくごく一般的なワインです。で、この値段が高いと感じるか、安いと感じるか。単純にワインだけで考えると高く感じるでしょうが、店側の言い分としては買い付けや保管料、サーブするサービス料、そもそもの店舗の運営費を載せた金額になっています。また、料理とあわせる付加価値という面もあります。
 あるいは、アメリカの寿司屋では、十四代とか一本あたり恐らく2〜3万円の価格設定で出されていました。高いところだと、10万円近いところもあったんじゃないかなと思います。それでも、日本酒好きなアメリカ人はこれが旨いんだよといって喜んで飲んでいました。逆に、現地のスーパーで1,000円くらいで売ってたワインが、日本の小売店だと2,000〜3,000円くらいというのもザラにあります。ところ変われば値段も変わるのです。獺祭を高値で売っているお店も、売れる値段で売っているのです。

売り手は、売ってしまった商品に対しては願望を伝えることしか出来ない。



 そもそも売ってしまった後には、売り手ができることって殆どないのですよね。今回の広告も、それがよく解っているので、お願いという形になっているんでしょう。私も、何冊か本書いていて或いはアプリとか出したことがあって、受けてがどう受け取るかで非常にやるせない思いをすることもありあmす。

 例えば、Amazonのレビューで★1のやつ。

内容はOK、Kindle版のデータ形式はクソ

 それは著者の私でもどうしようも出来ないのだよと強く主張したいのですが、買い手としては総体としてのサービスなので上記のようなサービスになります。これに対して怒ってもどうしようもないです。或いは、想定の読者層と違う人がよんで、難しすぎるとか初歩的すぎるとか。言いたいことも色々でてきますが、甘んじて受け止めるしかないのです。

そもそも日本酒って安すぎない



 どうでもよい愚痴をつらつら書いていましたが、もうひとつ。ワインを普段飲んでいる身としては、日本酒って相対的に安いなと感じています。もちろん輸入しているものと、生産国で買っているという違いがあるものの、同じ価格帯で比べると日本酒の方がクオリティ高いものが多いように感じます。また、上限もせいぜい数万円くらいです。もっと10万、20万するような日本酒が出ても良いのではないでしょうか?そういう意味で、ブランド戦略が非常に上手くいっている獺祭については、もう少し強気な価格設定したほうが良いんじゃないのと思っておりました。
 Twitterで教えてもらったのですが、元サッカー選手の中田さんが海外で高級路線の日本酒を出しているようです。このような取り組み、国内国外問わずにもっとあっても良いのではないかなと思います。

forbesjapan.com

どんな日本酒が好きなの?



 最近はそれほど飲んでいないのですが、私は日本酒も結構好きです。大吟醸のようなスッキリしたものではなく、純米のような雑味が多いものが好きですね。冬はぬる燗くらいでちょっと温めたくらいが良いですね。銘柄は特定のこれというのは無いですが、七本槍とか而今とか好きでしたね。(而今も今は、プレミア酒になっているとか)

f:id:dkfj:20171212122228j:plain

まとめ



 需給だけで考える奴は馬鹿だろという反応に対して、何考えているかを書き出してみた次第でございます。しかし、別に当事者ではないので、これ以上特に思うところはありません。一方で、酒蔵やっていた親類が5年ほど前に廃業していて、もったいないなぁという思いはずっとあります。

コンテナ化とサーバーレス、2つのトレンドに対する雑感

 日本からre:Inventを眺めていた雑感です。速報で2つほど新サービスに対しての感想をまとめていますが、今回は全体的なトレンドに対して今考えている事です。今回は1行じゃないですよ。

サービス展開の方向は、全方位的


 サービスの展開方向としては、去年と変わらないような気がします。他のクラウド(Google, Azure)に対して弱かった部分をきっちりキャッチアップし、伸びている分野(AI・機械学習)のラインナップを増やしていく。そして、サードパーティが提供している機能に対して、一定以上の規模が出てくると(買収 or 自社開発で)サービス化する。いわゆるサードパーティ殺し。
 そんな中で提供されているサービスの作り方/インフラ的な部分を見てみると、コンテナとサーバレス(lambda)を使った物が多いです。AWS自身がコンテナとサーバレスを活用することで、開発を加速しサービスをスケールしやすくしていることが見て取れます。

2015年のWerner VogelsのKeynoteを振り返る


 そんな光景をみていると思い出すのが、2015年のWerner VogelsのKeynoteです。『自由』をテーマにビジネス/エンジニアが何から開放されるのかを語っていました。注目は、その中の一枚のスライドです。

f:id:dkfj:20171203062754p:plain

AWS re:Invent 2015 Keynote | Werner Vogels - YouTube
www.youtube.com

 AWSの中心的な存在である仮想マシン(ec2)に対して、コンテナとfunctions(≒Lambda,サーバレス)を並べています。当時のトレンドとしては、コンテナに対する理解はだいぶ進んでいたものの、functionsに対しては何じゃそれというのが大半でした。そんな情勢なのに、コンテナだけでなくfunctionsについても同列に置くのかと驚いていました。
 次の2枚の写真は、Google Trendsでみる検索数の推移です。検索語については変えていますが、コンテナの方が当時でも優勢です。

f:id:dkfj:20171203063749p:plainf:id:dkfj:20171203064110p:plain

 その後をみていると、特にIoT関連のサービスが顕著なのですが、サービスがLambda連携で作られているモノ/拡張される物が多数出てきています。ユーザーにはfunctionsを使わせるという方向です。で、このコンテナとfunctionsですが、別に対立的な関係になっている訳ではないのです。
 AWSが作ってるLambdaも(Dockerじゃないけど)コンテナをベースに作られています。そして、そのコンテナもEC2などの仮想サーバをベースに提供されています。つまり、個々のトレンドは一足飛びで突然出てきている訳ではなく、連綿と続くサービスの積み重ねの上で提供されているということです。ということで、クラウド・プロバイダという点では、AWS, Google, Azure以外の所の台頭は難しいんでしょうね。例外的には、中国という独自の環境で育ったAlibabaがありますが。

それでは、ユーザーはどうするか?


 じゃぁ今後ユーザーはシステムをどうやって作っていけば良いのでしょうか?何でもサーバーレス・何でもコンテナって考えると、たぶん失敗します。結論的には、月並みな言葉ですが、適材適所で作っていきましょうとなります。
 まずサーバーレスですが、作る上での制約が厳しいです。 API Gateway・Lambdaを始め、AWS側の制約に則って作る必要があります。だってAWSのルールですから。一方で、システム構築/サービス展開する上で、この制約に則って作ることは良いものが出来る可能性は高いです。何故ならば、AWSが今まで作ってきたもののベストプラクティスを元にしているからです。その為、非機能要件のような汎用的に求められるものについては、サーバレスの仕組みにデフォルトで組み込まれています。だからサーバーレスで作れないか検討してみましょう。それが駄目だったら、コンテナか普通の仮想マシンを検討するのが良いです。
 次にコンテナ。これも新規に作るシステムだったら、仮想マシンじゃなくてコンテナから検討した方が良いと思います。一方で、過去のシステムをコンテナ化しようとすると、作った人を恨みたくなるとかいろいろ闇が出てくるので止めた方が良いかもしれないです。逆にこれから作るシステムでコンテナ化できないようなものは、たいていの場合はアーキテクチャなり設計を見直した方がよいです。システムが密結合になり過ぎているということでしょう。
 一方で、システム/サービスの肝となる部分については、サーバーレス・コンテナに縛られずにゼロベースで考えるべきです。プラットフォームの制約のためにサービスの性質を変えるというのは、恐らく間違っている可能性が高いです。

コンテナ化とサーバーレス化が進んだ後の世界


 ついでにコンテナ化とサーバレス化が進んだ後はどうなるのだろうと、ちょっと考えてみましょう。恐らくマルチクラウド化が進むと思います。コンテナ・サーバーレスともシステム/アプリケーションの可搬性を高めます。そうなると、AWSで動かしてたシステムをGoogleやAzureに持っていくことが簡単になります。当然、逆も然りです。
 可搬性が高いのであれば、より有利なクラウドを選ぶようになります。例えば、re:Inventの発表前では、AWSはKubernetesベースのサービスは提供されていませんでした。そこで、コンテナ関係はGoogleのクラウドを利用するという選択肢があり、実際AWSをメインに使っていてコンテナ部分だけGoogleで動かしているという話も結構聞きます。

マルチクラウド化になると複数のクラウドを使えなければいけないのか?


 じゃぁみんなが複数のクラウドを使いこなさないと駄目なのでしょうか。これはNoだと思います。まず、企業としては規模次第です。大規模な会社でシステムも多く多数のエンジニアがいる場合は、適材適所でクラウドを使い分ければよいと思います。一方で少人数のエンジニアチームで複数のクラウドを使いこなすというのは、よっぽどの精鋭チームでしか出来ないと思います。また、個人にフォーカスしてみると全部のクラウドに精通するということは、時間的な制約で恐らく難しいでしょう。複数のクラウドのマスターだよって人は是非手をあげてください。今だと引く手あまたです。
 マルチクラウドの話に戻すと、恐らくデータの集積の基本となるクラウドと、それを元に部分的に複数のクラウドを使っていくという形が増えていくのではないでしょうか。今だとデータをS3に集めて、AI部分のみ別のクラウド使って、またADだけAzure使ってという所は結構あるかもしれません。基本となるクラウドが1つあれば、後は良いとこ取りできるよというのがマルチクラウドだと思います。

まとめ


 毎年、re:Inventで発表されるサービスを見るたびに、この先どこで食っていこうかなと思います。ここ2〜3年は、コンテナ・サーバーレスの知見があれば食っていくことには困らないでしょう。一方で、正味のシステム構築部分自体は小さくなってきます。昔から言われていますが、SIer的なピラミッド構造の産業は難しくなってくるでしょうね。また、発注側の情報システム部門も厳しくなると思います。だって、クラウドに着いて行くのが難しいんだもん。

シリーズ
AWSの新サービス群に対する一行所感
(続)AWSの新サービス群に対する一行所感

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

(続)AWSの新サービス群に対する一行所感

 昨日のAWSの新サービス群に対する一行所感に続き、二回目です。タイトル通り一行じゃないのは、書いてる時の気分の問題です。

AWS Serverless Application Repository


Serverlessアプリケーション版のGithub。SAM形式で作ってたら公開可能。限定公開とか一般公開とか出来る 。とりあえず9割の人が利用者側にまわるサービスかな。

aws.amazon.com

AWS Cloud9


2016年にAWSに買収されたオンラインIDEのCloud9。1年の雌伏の時を経てAWSのサービスとして登場。ペアプロとかも出来る。ちなみにCloud nineというのは、至福という意味

aws.amazon.com

Amazon EC2用スプレッドプレイスメントグループ


 従来のプレイスメントグループに、機能拡張。今までは、ネットワーク的に近くという目的だったが、今度は物理的に別の筐体にという指定。耐障害性があがるが、Multi-AZ構成と性能計算をちゃんとやってればいらないのではという気も。一方で、デフォルトで指定されててもいいかも。

aws.amazon.com

インターリージョンVPCピアリング


 リージョンまたいでのVPCピアリングが可能に。先月発表されたDX Gatewayと併せて、どう使うかよーく考えよう。
※ほぼ執筆完了した本で、企業のネットワーク設計をどうすべきかという話をあーだこーだ書いてて前提が変わったので困ってる

aws.amazon.com

AWS WAFのマネージドルール


WAFの設定をTrend Microのような専門の会社から買うことが出来る仕組み。当然、定義の自動アップデート機能付き。セキュリティ会社的には嬉しいだろうが、AWSへの従属性高まるので手放しでは喜べないだろうなぁ

aws.amazon.com

T2 Unlimited


 バースト特性のあるt2インスタンス。問題は、バースト期間を過ぎると極端に性能が落ち、バーストしている時は例外なく負荷高い時なので、切れると死ぬということ。それをお金で解決するのがT2 Unlimited

aws.amazon.com

API GatewayのVPCサポート


ようやく来たAPI GatewayのVPC対応。今まで何度お客さんに、何でVPC内で使えないのと聞かれたことか。

Amazon API Gateway でプライベート VPC とのエンドポイント統合をサポート

まとめ


 EFSやSQSのFIFOキュー、結局東京リージョンに来なかったね。

シリーズ
AWSの新サービス群に対する一行所感
コンテナ化とサーバーレス、2つのトレンドに対する雑感

Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る
Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る

AWSの新サービス群に対する一行所感

 今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。

AWS AppSync

 モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな?認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか?

2017/12/3 追記
中の人曰く、次のような役割分担とのこと

AWSの新サービス群に対する一行所感 - プログラマでありたい

ありがたし / Cognito Syncは「一つのIdentityに(≒一人の人間)が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それってCognito Syncでやりたかったことじゃないのかな?”

2017/12/03 12:21
b.hatena.ne.jp


aws.amazon.com

Amazon GuardDuty

 初見の印象は、TrendMicroを殺しに来るサービス。一方で、TrendMicroの方もLauch Partnerとして、Amazon GuardDuty and Deep Securityを出してきている。庇を貸して母屋を取らないようにギリギリのところで勝負している印象。

aws.amazon.com

Amazon EC2 Bare Metal

 生のハードウェアを貸しますよという昔のSoftLayerのようなサービス。目的は2つあって、全ての仮想化サーバーをAWSで取り込めるようにするのと、ガチGPU勢とかハードウェアリソースを100%使いたい人に対応だと思う。これ普及したら、なんちゃってプライベートクラウドはなくなるだろうね。

aws.amazon.com

Amazon MQ

 Apache Active MQのPaaS版。既存のMQ入れている所に対して、そのまま移行できますよというサービス。IBMとかを殺しにいっているのかな。SQSを既に使っている人は、そのままSQSで良いでしょう。ところで、FIFOキューは日本に来ないの?

aws.amazon.com

AWS Fargate

 仮想サーバじゃなくてコンテナを直接起動するサービス。もう世の中、コンテナだよね。中の人曰く、イベント・ドリブン的なサービスは、Lambda。ロングランなバッチなどにはFargate。

aws.amazon.com

Amazon Aurora Serverless

 もうちょっと名前の付け方考えた方がよいのではというのが、Aurora Serverless。Lambda等のサーバレスアーキテクチャと親和性が高いAuroraという訳ではない。単純に個々のインスタンスを意識せず良い塩梅にコントロールしてくれるというサービス。PaaSのAuroraが、SaaSのAuroraになったようなイメージ。

aws.amazon.com

Amazon Neptune

 フルマネージドなグラフDBサービス。これ、裏でAuroraの技術使っているのではという気もする。いずれにせよ、NoSQLも自前でインストールして使う時代ではなくなったのだろう。

aws.amazon.com

Amazon DynamoDBにGlobal TablesとOn-Demand Backup追加

 Global Tablesは、AzureのCosmoDB、Google Spannerを意識した機能かな。バックアップ/リストアは、ようやく来たのかという感じ

aws.amazon.com

Amazon Elastic Container Service for Kubernetes

 予想通りECSのKubernetes対応が発表。去年のがっかり感が、ようやく解消。略称がEKSというところに、Amazonのプライドと苦悩が垣間見れる。

aws.amazon.com

S3 Select と Glacier Select

 Simple Storage Serviceという名前に関わらず、恐ろしく多機能になっているS3。Select文でオブジェクトの一部のデータが抽出が可能に。Athenaとかの開発の副産物でしょうな。

aws.amazon.com

Amazon Rekognition Video

 映像の認識処理のサービス。ぜったいDMMのAPIとつないでみる奴でてくるで

aws.amazon.com

Amazon SageMaker

 機械学習のライフサイクルをサポートするサービス。これもサードパーティー殺しだな

aws.amazon.com

Amazon Transcribe

 音声⇒テキスト変換。初回Launchは、英語・スペイン語のみ。きっとすぐに、日本語に対応してくれるでしょう。

aws.amazon.com

Amazon Kinesis Video Streams

 大量のセンサーデータをKinesisが扱うように、ビデオ画像もKinesisで扱えるようになった。先述のRekognition Videoのようなものと組み合わせて、防犯カメラからの映像をリアルタイムで異常検知というようなことができるようになるんでしょうね。

aws.amazon.com

Amazon Translate

 リアルタイム翻訳サービス。APIが提供されるだろうからプロダクトに組み込みやすいだろうが、精度の点でGoogleに勝てるのだろうか?

aws.amazon.com

IoTサービス群

 怒涛のIoT関係サービスのリリース。これで、ほぼほぼ出揃った?

 AWS IoT Device Defender IoT版のDeepSecurityみたいな感じ?

aws.amazon.com

 AWS IoT Device Management IoTの個々の機器の管理。やっぱり必要だよね

aws.amazon.com

 AWS IoT Analytics IoTの分析サービス。AWSは分析サービスをいろいろ出してるけど、どれもイマイチ感は拭えない。。。

aws.amazon.com

 Amazon FreeRTOS IoT用のOSまで作っちゃいました。

aws.amazon.com

AWS Systems Manager

 EC2 System Managerを更にラップしたようなサービス。複数のEC2やRDS,S3をグルーピングしてくれる。もうちょっと拡張してIAMの権限管理とかもできれば、本番・開発環境のために複数アカウントとかする必要なくなるのだけどなぁ

aws.amazon.com

Amazon Time Sync Service

 とどのつまりが、NTPサービス。やっと出してくれたのかという反面、なんで今までなかったのか。

aws.amazon.com

Amazon Comprehend

 自然言語処理。Mecab以来目立って進化していないような気がするので、何気に嬉しいし使い所が沢山ありそう。自然言語処理ってなんぞやと言う人は、文章中から特定のキーワードを引っこ抜くとか単語単位に分解するサービス程度に認識してればO.K.

aws.amazon.com

まとめ

 まとめきれません。

続き
(続)AWSの新サービス群に対する一行所感
コンテナ化とサーバーレス、2つのトレンドに対する雑感


Amazon Web Services 業務システム設計・移行ガイド

Amazon Web Services 業務システム設計・移行ガイド

  • 作者: NRIネットコム株式会社:佐々木拓郎,林晋一郎,株式会社野村総合研究所:瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る
Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2015/03/25
  • メディア: Kindle版
  • この商品を含むブログを見る