雀巽の日記帳

雀巽が綴る日常の記録

「価格の心理学」を読んだ

『価格の心理学 なぜ、カフェのコーヒーは「高い」と思わないのか?』を読みました。

価格の心理学 なぜ、カフェのコーヒーは「高い」と思わないのか?

価格の心理学 なぜ、カフェのコーヒーは「高い」と思わないのか?

「はじめに」にある通り、この本は「価格に対する顧客心理をビジネスに活かす方法を、手順ごとにわかりやすく伝える解説書」です。 内容の半分くらいは、元々コンサルタント向けの研修マニュアルだったそうで、そのためか密度の濃い実践的な本となっていました。

行動経済学認知心理学に基づいた、価格特化のマーケティング本、という感じでした。

直近価格について何か決めることは特にないのですが、様々な心理作用とその実際の活用事例を知ることができて面白かったです。

価格決定やマーケティングに関わる人が読むと、即座に実践できそうなことがたくさんのっており、得るものが大きいかと思います。

また、特にそれらに関わらない人でも、世の中の商品の価格がなぜそうなっているのか、 どのような心理作用やメッセージがあるのかを考える切っ掛けになり、とても楽しいです。

認知バイアスからは逃れられないとは思いますが、「あーこれもしかして」と考えたり気づくきっかけになるんじゃないかと思います。

もし価格について考えたり決めたりする機会があれば、また是非読み返したいと思える本でした。

認知バイアスヤバイ。それを活かした行動経済学イカス。

「データベース・リファクタリング」を読んだ

「データベース・リファクタリング データベースの体質改善テクニック」を読みました。

データベース・リファクタリング

データベース・リファクタリング

  • 作者: スコット W アンブラー,ピラモド・サダラージ,梅澤真史,越智典子,小黒直樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2008/03/26
  • メディア: 単行本
  • 購入: 10人 クリック: 211回
  • この商品を含むブログ (53件) を見る

内容はタイトルの通りで、前半は発展型データベース開発の概念と手法の基本、後半は各リファクタリングのリファレンスです。

データベースの質を高めるために、一通り「こんなことができるんだ」と知っておくと良いと思える内容でした。

データベースの修正は「面倒」で「怖い」と言った理由で避けられがちですが、 この本を読むと、それに立ち向かうための武器や考え方が得られるんじゃないかと思います。

以下、個人的に印象に残った点について書いてきます。

移行期間を設ける

当然といえば当然なんですが、Web API やライブラリの場合と同じで、 移行期間を設けることで、保守コストはあがりますが、移行がしやすくなります。

移行期間中は新旧両方のコードが動くので、大規模デプロイを避け、少しずつ対応を進めることができます。

小さい変更を少しずつ反映していくほうが安全で確実ですね。

確実に動く小さな変更を早めにマスターに反映していくことができれば、 他の人の作業とぶつかる可能性も下げることができます。

リファクタリングの意義

コードは情け容赦なくリファクタリングしなければならない。 というのも、質の高いソースコードを扱っているときが、一番生産性があがるからだ。 コードに新しい機能を追加するときには、まず「このコードはこの機能を追加するためにもっとも良い設計になっているだろうか」と考えなければならない。

同意しかないので特に追記することはありませんが、「作業前に周りをキレイにする」という作法はもっと広まってほしいなと思います。

データベースの不吉な臭い

本に記載されていた「臭い」は以下の通りです。

  • 複数の目的に使われるカラム
  • 複数の目的に使われるテーブル
  • 冗長なデータ
  • カラムの多すぎるテーブル
  • 行の多すぎるテーブル
  • 「スマート」カラム
  • 変更の恐怖

噛み砕くと One Fact in One Place が守られており、かつ理解しやすい設計になっているかが鍵だと思います。

コードの場合は単一責任原則が守られており、かつ理解しやすい設計になっているかが鍵だと考えているので、 コードでもデータベースでも、「不吉な臭い」の根幹は似ているなと感じました。

この辺の嗅覚を上げるには SQL アンチパターン が非常に有効だと思います。

necojackarc.hatenablog.com

設計とドキュメントの関係

設計がきれいなほど、必要なドキュメントは少なくなる

なるほど確かに、と思いました。

ドキュメントやコメントが不要だとは考えていませんが、コメントやドキュメントで説明が多く必要なときは、 そもそも設計自体が不適切な場合は多いと感じます。

データベース・アクセスのカプセル化

カプセル化されていれば、当然変更箇所が少なくなるので、データベースの変更コストが少なくなります。

これはいわゆる、結合度を下げる(凝集度をあげる)とメンテナンスコストが下がるのと同じです。

例えば Rails の場合、where を外から呼ばず scopeを使い、 ActiveRecord 外にデータベースの詳細を染み出させないようにする、などが一例として思いつきました。

データベース・リファクタリングと政治

組織にデータベース・リファクタリングを取り入れたければ「政治ゲームに参加する」必要もある

変革を起こすには、どうしても政治力が必要になりますよね。そりゃそうだ。

まとめ

コード・リファクタリングよりも、どうしてもコストはかかりますが、 データベース・リファクタリングも十分日常的に行える作業だと思います。

大事なのは、コード・リファクタリングと同じく、

  • 「不吉な臭い」を嗅ぎ取ること
    • 単一責任原則 / One Fact in One Place などの基本原則を抑える
  • 小さな変更を繰り返し適用すること
    • 安全性も確実性も高まり、更に環境を最新に保ちやすい

あたりだと思います。

唯一不変なものである変化に対応するには、継続的改善が必須です。

データベースも継続的改善を行っていきましょう!

Happy New Year 2017

あけましておめでとうございます。

昨年はありがとうございました。 今年もよろしくお願いします。

それでは、今年もまずは簡単に2016年を振り返りたいと思います。

necojackarc.hatenablog.com

去年のブログによると、2016年の目標は、

だそうです。

とりあえず一つずつ振り返ってみます。

英語

大学時代、英語が最も苦手な科目であり、英語で留年した*1と言ってもある意味過言ではないのですが、2016年は継続的に頑張りました。

necojackarc.hatenablog.com

最終的に TOEIC のハイスコアは870点まで伸びました。

また、オンライン英会話も継続的に行っており、調べてみたところ現時点で468回受講しているようです。

ただ、伸び悩みを強く感じるようになってきたので、今年は何かを変えないとダメだなと思います。

競技プログラミング

競技プログラミング全くしてない\(^o^)/

これは興味が「コンピューターサイエンス」から「ソフトウェアエンジニアリング」に盛大に推移したのが原因です。

競技プログラミングというか、データ構造とアルゴリズムについては、自分の弱いところだなという認識もあるので、 どっかのタイミングでテコ入れしたいなとは考えていますが、どうも後回しになっています。

その代わりに優先した IT 周りのこととして、

などの、Web サービスの設計や開発で重要になる技術が挙げられます。

健康

ここ数ヶ月は生活リズムが非常に安定してきており、いい感じです!

ただ、健康診断で尿酸値アウトだったり痔瘻になったりしたので、微妙な感じです。

やっぱりいちばん重要なのは健康だと思うので、まずは食生活と睡眠リズムを安定させたいです。


目標を基準に振り返ってみましたが、なんとも微妙な達成率……。

次はさっくり時系列順に振り返ってみます。

去年のブログを見ると、

2016年は地力を底上げする成長の年にしたいなと思います。

と書いてあるのですが、これは達成できたかなと思います。

2016年は新規事業を任されたおかげで、学びと実践を繰り返し行えたのが非常に良かったです。

2015年は変化、2016年は成長ときたので、2017年は何か大きな挑戦ができたら良いかなと思います。

現時点で何に挑戦するかは特に決める気はありませんが、何か挑戦したと言える、そんな年にしたいです。

というわけで、2017年の指針は、

  • 挑戦
  • 英語
  • 健康

にしたいと思います。

加えて2015年のブログに、

将来の自分が過去の自分に向かって胸張れる存在になれるようにマイペースに生きていきたい

とありますが、この方針はもちろん変更なし!

あと、イチロー選手の『小さいことを積み重ねるのが、とんでもないところへ行くただひとつの道』という言葉が強烈に頭に残ってるので、 これも今後の方針としてきっちり組み込んでおきたいと思います。

それでは2017年、楽しんで行きましょう!

*1:フランス語にも殺されました

ぜひ読んでもらいたいオススメ書籍一覧

随時更新します。

一番のオススメ

「ファスト&スロー」が世界の見え方を変えてくれる正にバイブルだった

思考

ソフトウェアエンジニアリング

Web サービス

データベース

ネットワーク

UI/UX デザイン

組織・チーム

ビジネス

英語

レビューリンクの無い英語関連書籍については、TOEIC440点の社会人が8ヶ月間で850点を取得した勉強法 にて一括で触れています。また、英語学習法については、TOEIC 900・IELTS 7.0 取得までのスコア別勉強法まとめ もあるので、興味のある方はそちらも参照してみてください。

フランス語

エンジニア読み物

音楽

関連記事

「部下育成の教科書」を読んだ

「部下育成の教科書」を読みました。

部下育成の教科書

部下育成の教科書

一言で言うと「それぞれのステージに応じた仕事の任せ方、アドバイス、フィードバックをしよう」という話でした。

まず、本書ではざっくりステージを以下のように定義しています。

一般社員層

  1. スターター (Starter / 社会人)
    • ビジネスの基本を身につけ、組織の一員となる段階
  2. プレイヤー (Player / ひとり立ち)
    • 任された仕事を一つひとつやりきりながら、力を高める段階
  3. メインプレイヤー (Main Player / 一人前)
    • 創意工夫を凝らしながら、自らの目標を達成する段階
  4. リーディングプレイヤー (Leading Player / 主力)
    • 組織業績と周囲のメンバーを牽引する段階

マネージャー(管理職層)

  1. マネージャー (Manager / マネジメント)
    • 個人と集団に働きかけて、組織業績を達成しながら変革を推進していく段階
  2. ディレクター (Director / 変革主導)
    • 対立や葛藤を乗り越えながら、変革・改革を起こし、組織の持続的成長を実現する段階
  3. ビジネスオフィサー (Business Officer / 事業変革)
    • 戦略的な資源配分を通じて、自ら描いた事業構想を実現する段階
  4. コーポレートオフィサー (Corporate Officer / 企業変革
    • 社会における自社の存在意義を絶えず問い直し、自社の進路を決める段階

スペシャリスト (管理職層)

  1. エキスパート (Expert / 専門家)
    • 高い専門性を発揮することを通じて、組織業績と事業変革に貢献する段階
  2. プロフェッショナル (Professional / 第一人者)
    • 卓越した専門性を発揮することを通じて、事業変革に道筋をつける段階

これらのステージは段階的に登っていくものであり、飛び級は基本的にないと書かれていました。

そして、これらのステージに応じた「仕事の割当、支援、評価」をするべき、というのがこの本の骨子です。

加えて、ステージを登るのは大きな転換であり、仕事のやり方や価値観、モノの捉え方そのものなどを大きく変える必要がある、とのことです。

単なる延長ではなく、価値観や視野を変える必要がある大きな転換であるため、ステージを登るのは大変だそうです。

伸び悩みというのは、このステージの移行(トランジション)がうまくいってない状態とも書かれており、 このトランジションをいかにサポートできるかがマネージャーの育成能力、という感じでした。

さらに、チームメンバー同士がこのトランジションを促進しあうチームを作れるというのも重要です。

なかなか、シンプルでわかりやすいなと思います。

個人的にいいなと思ったのは、トランジションという概念でした。

ここでのこの言葉の出典は、ウィリアム・ブリッジズの『トランジション』で、

と言ったものです。

また、

「終わり」は、自分を取り巻く環境や状況が変化する中で、うまくいっていたことがうまくいかなくなることから始まるといいます。 これまでの安定が崩れ、失うものに対する恐怖心がわき、不安定な状態になるのです。 そして「ニュートラル・ゾーン」は喪失・空白の時期であり、喪失感や空虚感を素直に受け止め、耐える時期としています。 それは暗闇を手探りで進むようなものですが、次の「始まり」のために、内的な方向づけをする大切な時間だといいます。

と解説されています。

うちの社長がよく「憂鬱でなければ、仕事じゃない」という言葉を引用するんですが、 これも「トランジションを経ないと、成長しないよ」と、捉えれるなと思いました。

もう少し狭い話ですと、新しいライブラリやフレームワークデザインパターンを使うときでも、 確かに「終わり、ニュートラル・ゾーン、始まり」みたいなのがあるなと感じ、 成長したり何か新しい世界に入るときには、このトランジションを経るのだろうと思いました。

端的にまとめると、その人の現在の状況に適したマネジメントを行うこと、 トランジションは苦しいが成長のためには必要なこと、これらを念頭においておくと良いと思います。

トランジションを知っているだけで、心が折れることも少なくなりそうです。笑

なかなかおもしろい本でした。

『部下を持ったら必ず読む「任せ方」の教科書』を読んだ

『部下を持ったら必ず読む「任せ方」の教科書「プレーイング・マネージャー」になってはいけない』を読みました。

端的にいうと素晴らしい本でした。

部下を持ってなくても、人と協力して何かを行う機会がある人は読んでおいて損はないです。

つまり、ほとんどの人は何らかの学びや気付き、もしくは自分の考えに深みを出すための何かがあると思います。

メインの「任せ方」に関する要点は、

  • 人間の能力と時間の有限性を理解すること
  • 各々がスムーズに動けるようにすること
  • 「長所」と「短所」がトレードオフだと理解すること

あたりかなと捉えました。

この辺を理解していると、タスクを抱え過ぎたり、無茶振りしたり、不適当な教育をしたりといったことが減ると思います。

それに加えて「多様性がある組織は強い(同質化した組織は弱い)」ということも、常に念頭に置く必要がありそうです。

また、精神論を振りかざさないという話題の中で、

  • 「働けば働くほど、生産性があがる」と考える人が居るが、科学的根拠はなく、むしろ「短時間に集中して取り組んだほうが、労働生産性は向上する」
  • あらゆる医学的根拠が「若い人であっても、長時間労働すると、注意力や生産性が低下する」

ということが書かれていたのですが、これはぜひ全員に知ってもらいたいです。

これについては、本当に自分の考え方と一致していたので、今度から積極的に引用していきたいと思います。

また、

  • インプット(人・本・旅)を増やし、洞察力を育てる(適材適所を実現させるためには洞察力が必要不可欠)
  • 世代ごとに「違う音符」を持っている(60代に、20代、30代の考えは「わからない」)
  • ロサダの法則(人は、「褒める」と「叱る」の割合が「3:1」でないと、ポジティブな気持ちを保てない)

といったことが印象に残りました。

内容と直接関係は無いのですが、本を通して、ライフネット生命 CEO 出口さんは、本当に絶えず学び変化してきた人なんだと感じました。

柔軟であり続けること、変化に適応し続けることは本当に重要なので、ぜひ見習いたいです。

非常に読みやすい良書ですので、ぜひ読んでみてください!

"Web API: The Good Parts" を読んだ

"Web API: The Good Parts" を読みました。

Web API: The Good Parts

Web API: The Good Parts

一言で言うと Web API 設計時に考慮すべきことと良い見本が詰まった本 でした。

個人的にはエラーの表現方法、レスポンスヘッダ(HTTP の仕様に即したメタデータや Content-Type の扱い)、運用面の話が印象に残りました。

エンドポイント (URI) 設計については良くやっているので「せやな」と思いながら読み進めていたんですが、 SSKDs 向け(というかほぼ自分向け)の Web API しか作成したことがなかったので、LSUDs 向けのレスポンス設計や運用面の話はかなり学びが多かったです。

また、Web API 設計時に HTTP の仕様や制約をどう活用するかという話も非常に良かったです。

例えば、バージョン情報や独自ヘッダを Content-Type で表すのは HTTP の仕様上は美しいが、 クライアントとしては不便になることがあるなど、 仕様上の美しさと利便性のトレードオフを考えないといけない点などが印象に残りました。

運用面では Web API バージョニング(廃止)の話で取り上げられていた Twitter が実際に行った Blackout Test はなかなか参考になりそうだなーとも思いました。 あと、バージョニングはセマンティックバージョニングのメジャーバージョンだけを指定すれば良いようにするのも、なるほど確かに、という感じでした。

リソース指向の Web API の上にオーケストレーション層を載せる話も出てきました。

thenextweb.com

オーケストレーション層を作ったことはありませんが、こうすると良いよなぁとは思っていたので、 JSON を吐く機械になれる機会があればチャレンジして見ようと思います。

Web サービス開発に関わるは読んでおいて損はないと思える本でした。