ワークマンは 商品を変えずに売り方を変えただけで なぜ2倍売れたのか

ワークマンは社員全員データ分析してるとか、最近はカジュアルウェアを売って成功しているみたいな話を聞いて興味があったので読んでみました。経済誌の特集記事のような感じなのでとても読みやすかったです。企業の事例について興味がある人は読んでみてもよいと思います。

本書は筆者がトピックごとにワークマンの社員にインタビューした内容を中心に紹介するという形式で、経済誌の特集記事のような雰囲気です。特にワークマンプラスの背景を中心に紹介しています。以下、目次です。

  • はじめに ワークマンとは何者か
  • 第1章 ワークマンを変えた男
  • 第2章 大躍進の裏に「データ経営」あり
  • 第3章 ものづくりは売価から決める
  • 第4章 ファンの「辛辣な文句」は全部のむ
  • 第5章 変幻自在の広報戦略
  • 第6章 店づくりは壮大な実験
  • 第7章 継続率99%! ホワイトFCへの道
  • 第8章 「変えたこと」と「変えなかったこと」
  • 第9章 アフターコロナの小売りの未来

有名な企業はそれぞれ有名になるだけの歴史というか背景があると思うのですが、ワークマンの場合はこういう歴史があって、背景があって、今に至るんだなと思える内容でした。もともとデータを取りながら手堅く徹底した標準化を進めていた企業に、商社出身の土屋哲雄氏が入社して更に成長するというような内容でした。1980年に創業したような企業でも2012年に入社した土屋氏が変革できるというのは、もともと変革できるの素地がワークマンにあったにしても、やはり土屋氏がやり手なんだろうなと思いますし、そういう事例もあるんだなーという気持ちになりました。

個々の施策の詳細は本書を読んでもらえればと思います。また、当然書籍に書かれているとこは上手く行っている部分を取り上げるので、実際には土屋氏が主導した変化の軋轢はあったと思いますし、今現在でも上手く行かない部分もあるんだと思います。振り返ってまとめると、こんな風にまとまるという感じだと思います。とはいえ、やはり成長するには理由があるんだなと思える内容でした。

Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

おもしろそうなので読んでみました。全体的に共感する内容で大当たりだと思いました。アドテクノロジーに興味がある人や自社サービスの開発をやっている人は読んでみるとよいと思います。

VOYAGE GROUPさんの各社のエンジニアの方にインタビューをしながら事業内容や文化について説明してもらうというものです。Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち – 技術書出版と販売のラムダノート を読むと雰囲気がより分かると思います。具体的には6章に分けて以下の会社というかサービスというかチームが紹介されます。

  • 第1章 fluct ― 広告配信の舞台裏の技術者たち
  • 第2章 Zucks ― フルサイクル開発者の文化
  • 第3章 VOYAGE MARKETING ― 20年級大規模レガシーシステムとの戦い
  • 第4章 VOYAGE Lighthouse Studio ― 数十万記事のメディアをゼロから立ち上げる
  • 第5章 サポーターズ ― 事業の成長を止めない手段としてのシステム刷新
  • 第6章 データサイエンス ― エンジニアによるビジネスのための機械学習

第1章 fluct、第2章 Zucks、第6章 データサイエンスはアドテクノロジーに興味がある方は読んでみることをおすすめします。管理画面も含めて説明していて雰囲気がつかめると思います。私自身も2012〜2013年頃にアドテクノロジーの会社に所属していてアドネットワークサーバーやDSPの開発に関わっていました。在職期間が短いためそこまで詳しくはなれませんでしたが、接続先としてfluctさんもいたと思いますし、アドサーバーやアドネットワーク、DSPの特性についてはビジネス面含めて多少学びました。そのため、読んでいてとにかく懐かしかったですし、他社さんでもいろいろ試行錯誤しながら開発していたんだなーと思いましたし、当時あれこれ考えていたことの答え合わせをできたような嬉しさもありました。

文化的な所だと第1章 fluctで紹介されているインフラと開発を分けない方針ですとか、第2章 Zucksで紹介されている Netflixにおけるフルサイクル開発者―開発したものが運用する - VOYAGE GROUP techlog というのは、私自身が前職で目指していたものだと思いました。当時はフルサイクル開発者という言葉をしらなかったので「ふわっとしたビジネス要件をサービス仕様に落とし込んで設計から実装、運用までをフルスタックエンジニアみたいに横断して提供する」という感じで話してたと思います。この辺の考え方も非常に共感するもので、やっているところが他にもあったんだと嬉しくなりました。

第3章 VOYAGE MARKETINGではレガシーシステムとの付き合い方について共感と畏敬の念を覚えました。概要は デブサミ2019講演「レガシーとのいい感じの付き合い方」の資料を公開します。 - VOYAGE GROUP techlog でも読めます。規模は全然小さいですが、私自身も前職で途中から自社サービスのシステムを引き取って、2年以上掛けて1つのサブシステムをリプレースしたことがあるので、長い時間軸で少しずつ取り組んでいくというのは実感があります。いや、ほんと。

残りの章も共感する内容や参考になる内容も多くあり、ビジネスと近い距離で開発をするということのイメージが湧く内容ですごくよかったです。私もなるべくビジネスと近い距離で開発をやりたいと思っているので、そういう会社さんがいることを知れてよかったです。ほんといろいろな知見を学べるので一度読んでみることをおすすめします。

おもてなし幻想 デジタル時代の顧客満足と収益の関係

タイトルがおもしろそうなので読みました。内容に説得力があり実践方法についての具体的な手順も示していて非常によい本だと思いました。カスタマーサービス業務に関わる方は一度読んでみるとよいと思います。

本書の主張は感動するようなカスタマーサービスは顧客ロイヤルティには影響せず、一方でひどいカスタマーサービスの経験は顧客ロイヤルティに悪影響を与えるというものです。具体的には何らかの問題がありカスタマーサービスを利用せざるを得ない状況になった顧客が問題を解決するまでの顧客努力を減らすことが重要であるという主張です。顧客努力というのは顧客が問題を解決するためにサポートページを検索したり、カスタマーサービスにメールや電話をすることを指します。そして顧客努力軽減に優れた企業の事例を紹介し、自社でも同じようにするための具体的な方法を示します。例えばサポートページの改善の仕方であったり、カスタマーサービス部門の教育方法や評価方法などを説明してます。

特徴的なのはそれぞれの主張を述べる前提として事前にアンケートを実施し、その分析結果に基づいて主張を述べ、具体的な事例を紹介している点です。そのため、非常に説得力がありました。また、どのように実践すればよいかについての説明も明確で具体的でした。例えばカスタマーサービスのやり方を変える場合であれば現場のメンバーに方針を決定してもらうことで動機づけを行ったり、まずは達成すべき目標を絞って段階的にレベルアップしていくというようなものです。

顧客努力を減らすというのは自分自身がユーザーである場合は全くその通りだなと思いました。今困っている状況をなるべく早く手間を掛けずに解消したいと思うことはあっても、期待を超えるようなサービスをしてもらって感動するみたいなことはあまりない気がします。とはいえ、例えばディズニーランドであれば期待するサービス内容みたいなイメージはあるので、要は期待値と乖離しないことが重要なのかなと考えています。明らかに期待を超えるサービスを提供されると想定している企業なりサービスにおいて普通の対応をされるとがっかりしてしまいそうな気がします。一方で、特に期待を持っていない場合は問題の解消をなるべくスムーズにできれば十分で、そこで感動するような対応をされても反応に困るというか、カスタマーサービスを売りにしてるのかな?ぐらいには思っても特にロイヤリティがあがる気はしません(何度か続けば期待値のイメージが変わってそれ以降は期待するようになる気がしますけども)。ですので、まずは期待値の設計が先にある気はしています。カスタマーサービスも当然コストが掛かるので、どこにリソースを割くかという話だと思いますので。後は、一般的なカスタマーサービス部門の業務内容や評価方法について知れたのもおもしろかったです。

ITエンジニアが覚えておきたい英語動詞30

ITエンジニアが覚えておきたい英語動詞30

ITエンジニアが覚えておきたい英語動詞30

仕事で使えそうな表現を覚えられるかと思って読みました。とてもよかったです。海外のITエンジニアが使う英語表現を知ったり、do や have などの基本的な動詞を使って意思疎通する方法を学びたい人におすすめだと思います。

本書の構成は大きく3つのパートに分かれています。Part1では10個の基本動詞の解説と例題です。do や have、give、make などについてどのようなイメージ捉えればよいか解説があり、最後に10問例題があります。次にPart2では追加で20個の基本動詞の解説しています。need や find、store などについて解説しています。最後にPart3では打ち合わせのやりとりの内容を一通り日本語から英語に翻訳します。やり取りごとにどのようにイメージして英語にすればいいか解説しています。

実際に普段使う単語もあれば、あまり使わない単語もあり参考になりました。後はよくある言い回しについてなぜこの単語を使うのかという解説が随所に載っているのがよかったです。例えば会議に向かう際に I'm going soon. ではなく I'm coming soon. と言うのですが、これは go は離れていくイメージで come は向かってくるイメージだからでした。他にも look、see、watch の使い分けとか store と save の使い分けなども解説がありました。

1月と2月で1日10分ずつぐらい読んで4周しました。定着したかと言われると悩ましいところですが、日本語から英語に翻訳するという行為にストレスを感じるようになったので打ち切りました。翻訳という行為にストレスを感じる理由は2つです。1つは英作文をしたり英語を話す際は伝えたいイメージから直接英語を考えるようになったので、普段の英語を使うプロセスと異なるという点です。もう1つは翻訳には正解が複数あるためです。問題文の日本語の解釈によって英語も変わりますし、載っているのはあくまで回答例と分かっているつもりです。ですが、自分の回答例が一致しない際に日本語の解釈について想像する行為自体にオーバーヘッドというかストレスを感じるようになりました(もちろんそもそも自分の回答が間違っていたり、うまく作文できないこともまだまだあるんですけども(^_^;))。

前述のようなこともあり、今後は英語で書かれた本で英語を学ぶように切り替えていった方がいいかなと考えています。とはいえ、日本語で書かれた本の方がイメージや概念の説明は分かりやすいと思いますので、今年1年でいろいろ試してみようかなと考えています。

会社を変える分析の力

去年は英語学習関連の本しか読んでいなかったので、違う分野の本も読もうと思って読みました。想定読者が経営者、会社員、研究者、学生と幅広いので数学的な話は出てきませんし気軽に読めます。仕事でデータ分析をやる前にそもそもデータ分析とは何なのかを理解するには良い本だと思いました。

本書の主張は一貫しており、ビジネスにおけるデータ分析は意思決定に寄与する必要があり、ITや分析手法は手段に過ぎないというものです。その説明をするために以下の4章に分けて、ビジネスにおけるデータ分析について説明しています。

  • 第1章 データ分析に関する勘違い
  • 第2章 データ分析でビジネスを変える力
  • 第3章 分析力を向上させるための流儀
  • 第4章 分析プロフェッショナルへの道

私自身もデータ分析関連のPoC案件を数件やったことがありますし、前職ではミドルマネジメントもやっていたのでITや分析手法は手段に過ぎないというのは全くもって同感です。結局、意思決定というか具体的なアクションが変わらないことをやってもビジネス上は意味がありませんので*1。実際、意思決定するために各種データを揃えて分析し、その上で具体的な意思決定とオペレーションへの落とし込みみたいなこともやったことも何度かあります。

データ分析という切り口で書いている本ですが、ITシステムやアプリなどもビジネスに寄与するために作られているものなので、そういう意味では一歩引いてみるシステム開発にも応用の効く話だと思いました。システム開発であれば何のために作るのかという話ですし。一方で、本書ではデータ分析の具体的な内容はあまり出てきませんので、具体的な内容を知りたいなら仕事ではじめる機械学習確率思考の戦略論 USJでも実証された数学マーケティングの力 (角川書店単行本)も合わせて読むと良いかなと思いました。

*1:一方で、個人的にはその手段で生活するためにビジネスをやってるだけだったりしますけどもw

速く・正確に読む ITエンジニアの英語

速く・正確に読む ITエンジニアの英語

速く・正確に読む ITエンジニアの英語

  • 作者:平井 通宏
  • 発売日: 2011/02/17
  • メディア: 単行本(ソフトカバー)

なぜか2011年に購入して手元にあったのと、英語の論文を読む際に役に立つかと思って読んでみました。英文法の知識が十分にある人にとっては良い本かもしれません。。あと、応用編の英文はいくつか面白い内容が含まれていました。

本書の構成としては基礎編と応用編の2部構成になっています。基礎編は語彙と構文の2つの観点で誤読・誤解釈しやすい例文について正確に読む方法について解説しています。応用編は雑誌や参考書、マニュアルなどの実際の英文の抜粋とその翻訳が載っています。

基礎編の構文の解説は正直よくわかりませんでした。。おそらく文法書も読みつつ解説を読めば理解できると思うのですが、そこまで細かく文法を理解していなくても内容を理解できる例文もそれなりにあったので、解説を読み解くモチベーションがわきませんでした。応用編はあまり解説はなく、英文を読んで、その翻訳を読んで理解を深める感じだったので、英文を正確に読む能力の向上に役立つのかわかりませんでした。ただ、応用編で取り上げている英文自体は面白いものもそれなりにあったので、せっかくだと思って最後まで読みました。

「はじめに」に書かれているように英文和訳を正確に行うには基礎編に載っているような文法も理解している必要があると思います。一方で私自身は英語によるコミュニケーションを主目的としていて、英文を理解する際はなるべく日本語に翻訳せずに英語のままイメージを理解するようにしていますし、英文も先頭から順番に読んでそのまま理解するというやり方で文の途中を行ったり来たりみたいなことはしないので、あまり相性がよくない本だったかなと思います。実際、応用編は文章にもよりますが8割ぐらいは読めていたので、この本に書かれているアプローチの優先度というか学習効果は低いと判断しました。一方で、この本に書かれているような文法は理解できていないことを把握できたので、それはそれで参考になったと思います。1年とか2年後に改めて読んでみて、どの程度理解できるか確認するのも面白そうだと思いました。

2020年振り返り

年はあけてしまいましたが、2020年について振り返ってみたいと思います。ちなみに、去年は2019年振り返り - n3104のブログでした。

転職した

2月にB2B系の自社サービスの会社に転職しました。今回はプレイヤー職でお仕事をさせてもらえるということで、一応API開発エンジニアとして入社しました。結果的には直接開発とは関係しないプロジェクトも含めていくつかのプロジェクトのリーダーをやったり、AWSも含めたインフラタスクを掛け持ちでやったりする1年でした。やはり、全体から見て私の経験を活かせるタスクを担当するのは年齢的にもある程度必要なことだと思っていたので、完全にプレイヤーとしてだけやれないのは想定通りというか仕方ないかなと思っています。1年かけてある程度自分の立ち位置のようなものは確立できたと思いますので、今後はAPI開発も掛け持ちでやっていければと考えています。

実際に転職してみて前職でのミドルマネジメントの経験は再現性があることを確認できたのはよかったです。マネージャー職は担当していないのですが、依頼されたのでオブザーバー的にリーダー陣の会議には参加させてもらっていますし、組織上のいくつかの課題について間接的に働きかけて解決できることも確認できました。逆に言うと、それぐらいまだまだ組織的な課題の多い発展途上の状態だとも言えます(^_^;)

ちなみにプロジェクトのリーディングとしてやったことは非常に単純で、情報を一元化して適宜作業依頼をするというだけです。具体的には関係者を集めたSlackのチャンネルを作成し、各担当者にヒアリングをしつつプロジェクト全体の状況のサマリを1つのWikiページに集約して、適宜担当者にタスクを依頼して、定期的に全体の進捗と状況をWikiに反映し、打ち合わせもしくはSlackでも共有しただけです。このような作業の進め方は前職で慣れたのですが、そのまま適用できました。

AWSも含めたインフラタスクについても前職でAWSのSAをやっていたこともありますし、自社サービスの開発保守運用をやる際はアプリケーションからインフラまで全てやっていたので、その際の経験を活かした感じです。とはいえ、インフラ自体はもともと専門ではないので、レビューできる部分はレビューしつつ、知らない部分はその場で調べたり教えてもらいながら進める感じでした。

あと、エンジニアの半数が海外出身であるため、SlackやWiki、打ち合わせも英語を使うようになりました。割合でいうと日本語と英語半々ぐらいでしょうか。詳細はリンク先に記載しています。ただでさえ英語を使うので細かなニュアンスを伝えられない上に、異文化理解力を読んでいたので文化差があることは分かっていても、具体的にどう話せばいいのか毎回悩みました。例えばSlack上のちょっとしたやり取りのテンションや絵文字のチョイスもありますし、作業依頼の仕方とかスケジュールの相談の仕方などです。1年である程度は慣れましたが、再現性のある知識というかノウハウとして文化差を踏まえたコミュニケーション能力を向上できた印象はないので、ここはもう少し意識的に取り組もうと思いました。

まとめると、立ち位置は違えど、前職とやっていることにあまり差がない1年だった気もします。とはいえ、現職と前職を比較することで色々と知識の整理はできましたし、転職しても自分の立ち位置を構築できるということも確認できたのはよかったです。英語を使う環境への適用も何とかなったかと思います。今後は事業ドメインへの知識を深めつつ、アプリケーション開発もやっていけるとよいかと考えています。

英語

去年は200時間ぐらいやると予想していましたが、結局今年も英語学習をメインにして300時間以上学習しました。どこまでやるかは特に決めていないのですが、仕事上での英語を用いたコミュニケーションに不安がなくなるぐらいにできるといいかなと思っています。何年かかるか正直わかっていませんが、毎年成長する実感はありますし、実際仕事上も役にも立っているので、気長に取り組むつもりです。

読書

今年は英語学習関係を除くとほとんど読みませでした。来年は英語関係以外の本ももう少し読もうかなと思っています。

SICP

今年は16回読書会(通算92回)をやり、ついに読み終わりました。詳細はリンク先を参照してもらうとして、問題を解くため読書会も含めて今年は毎月10時間ぐらいやってました。前職も含めて最近はコードを読むことはあっても書くことはこのSICPぐらいでしかやっていなかったので、そういう意味ではちょっと寂しいです。大学で情報工学を学んでいないので、こういう本を読むのは発見が多くて楽しかったです。新しい言語を覚える際の題材としてLISPインタプリタもあるかなと思えるようになったのは収穫かもしれませんw

データ指向アプリケーションデザイン

去年から読書会形式で読み始めました。今年は読書会を9回開催して2章から5章まで進みました。ほんといい本だと思います。あと、脚注の参考文献が非常に充実しているため、気になったものは読書会の後に軽く目を通しています。仕事でもKVSの移行案件をやっていたこともあり、知識の整理に役立ちました。来年も読むのが楽しみです。

その他

今年もプライムビデオでアニメを観てました。個人的に良かったのは以下でしょうか。

あとFGOを5月に再開してしまい、そこからずっと続けてます。第6特異点で止めてたんですが、再開後は各種イベントをこなしつつ、Lostbelt No.2まで進みました。いやー、やっぱり面白いですね。星5確定ガチャぐらいでしか課金していないのですが、思ったより普通に確率アップでも引けるので、問題なく進められました。キャストリアも2枚引けましたし、村正も無事引けました。ゲーム自体のコツもある程度分かってきたので、今年もゆるく続けようかなと思ってます。

まとめ

振り返ってみると、ありがたいことに2020年も密度の高い1年だったと思います。一方で40歳になり、周囲の方から叱っていただけるような年齢でもなくなってきたので、常に謙虚にいられるように何らかの仕組みを用意できるといいかなと考えています。