三日坊主の繰り返し

大体のことを3日で飽きる人のぼやきです。広く浅く色々手を出していこうと思います。気持ちだけは若くいたい。

【学習】マーケティングの基礎

忘備録として。マーケティングに関する知識が皆無なので手始めにマーケティングの基礎コンテンツから始めてみる。

ポジショニング

  • 自社製品をどう好ましいカタチでユーザーに認知してもらうかを決めるための手法
  • 訴求ポイント(軸)は2つに絞る
    • 強く認識するのは2つまでと言われている
  • 軸の決め方
    • 特徴の洗い出し、以下のポイントで選ぶ
      • 顧客ニーズに訴求するポイント
      • 競合との差が分かりやすいポイント
  • 留意点
    •  ポジショニングとパーセプションマップの違いに注意
      • パーセプションマップとは顧客の認識
    • 新しい差別化軸を考える

【読書録】知識を操る超読書術

メモ

  • 運動すると脳が活性化され鍛えられる=ストレスホルモン(コルチゾール)が減りテストステロンが増える、らしい
  • 読書の準備をする
    • 何を知識として得たいかをハッキリさせておき、読む箇所を決める
    • 速読は意味がない(理解が追いつかない)、やるならスキニング(拾い読み)
    • daigoの場合、真ん中を読んで面白かったらフィットした可能性が高いと考えるらしい
    • 知識が増えればスキニングが上達する、それまではじっくり読んで知識を増やす
    • 読書の質を高める3つの準備
      • メンタルマップ: 行動理由、メリット、期待していることを書く
      • キュリオシティギャップ: 今知っていることと本から得られる知識の差
      • セルフテスト: 日頃の読書で躓いているところを振り返る
  • カラーバス: 意識したことの情報を無意識に取り込もうとする(株を買ったらその会社の情報が目につくようになった、など)
  • デュアルNバックテスト(DNB)、ワーキングメモリを鍛えられる
  • 読書のコツ
    • 読む前と後に予測する(読書後は予測との比較)
    • 視覚化しながら読む
    • 要するにを考えながら読む
    • 他の書籍や事柄と繋げながら読む
    • 読み終わったら質問をする
  • アウトプットのコツ:spice
    • sinplify、シンプルに
    • 相手に利益があるように話す
    • 意外性をもたせる
    • 自信を持って話す
    • 共感を誘う
  • 繰り返すと説得力が増す、ただし同じフレーズでは意味がない

【読書録】LeanとDevOpsの科学

メンタルマップ

なぜ読むか

  • 上司に勧められた
  • 部がDevOps による業務の改善を図っており、知識を身に付けておく必要があると感じたから

期待

  • どういった手法があるのか
  • それによってどのような効果が見込めるのか
  • どうやって導入、浸透させていくのか

気になったタイトル

  • 第1章 業務を加速させるということ
    • 1.1: 「成熟度」ではなく「ケイパビリティ」に焦点を
    • 1.3: DevOps採用の価値
  • 第2章  開発組織のパフォーマンスを計測
    • 2.1: 従来の測定手法の問題点
    • 2.2: 望ましい尺度
    • 2.4: 変革の推進
  • 第3章  組織文化のモデル化と測定、改善の方法
    • 3.1: 組織文化のモデル化と測定
    • 3.5: 組織文化をどう変えていくか
  • 第5章 アーキテクチャのキーポイント
  • 第7章 ソフトウェア管理のプラクティス
    • 7.1: リーンマネジメントのプラクティス
    • 7.2: 負担の軽い変更管理プロセス
  • 第8章 製品開発のプラクティス
    • 8.1: リーン製品開発のプラクティス
    • 8.3: 効果的な製品管理によるパフォーマンス向上
  • 第9章 作業を持続可能にする
  • 第10章 従業員の満足度、アイデンティティ、コミットメント
    • 10.1: 従業員ロイヤルティ
    • 10.2: 組織文化と帰属意識の改善
    • 10.3:組織のパフォーマンスに対する職務満足度の影響
  • 第11章 変革型リーダーシップとマネジメントの役割
    • 11.1: 変革型リーダーシップ
    • 11.2: 管理者の役割
    • 11.3: 組織文化を改善しチームを支援するための秘訣
  • 第16章 ハイパフォーマンスを実現するリーダーシップとマネジメント
    • 16.1: ハイパフォーマンスなチームや組織を実現する管理体制
    • 16.2: リーダーシップの変革、マネジメントの変革、チームプラクティスの変革

POINT

第1章 業務を加速させるということ

    • 1.1: 「成熟度」ではなく「ケイパビリティ」に焦点を
    • 1.3: DevOps採用の価値
  • DevOps の手法は「安全で耐障害性が高く急速に進化できるスケーラブルな分散型システムを構築するにはどうするか」という課題を抱えた、少数の組織から生まれた手法
  • ケイパビリティ: 組織的な能力あるいは機能
  •  モデルの違い
    • 成熟度モデル: 成熟状態に「到達」することに焦点
    • ケイパビリティモデル: 継続的な改善を行い進歩していくことに焦点
  • ケイパビリティモデルの優位点
    • 自身の部署の現況と短期・長期目標を踏まえて、最大の効果を引き出せるケイパビリティに焦点を当てる
  • パフォーマンスが良好な組織とそうでない組織の比較
    • デプロイ頻度: 46倍
    • コミットからデプロイまでのリードタイム: 1/440
    • 平均復旧時間: 1/170
    • 変更失敗率: 1/5
  • 上記は改良すべきケイパビリティを正しく選択した結果、とのこと

 

第2章  開発組織のパフォーマンスを計測

    • 2.1: 従来の測定手法の問題点
    • 2.2: 望ましい尺度
    • 2.4: 変革の推進
  • 誤った生産性の測定手法
    • 書いたコード量
      • 量では質は測れない
    • 速度(ベロシティ)
      • 作業を完了するのに要する時間を推定するために利用すべきで、チーム同士で比較するものではない。
      • 計測として利用すると見積もりや人数を水増しする可能性も
    • 利用率
      • ※ちょっとイメージが沸かなかった、利用率...?
  • パフォーマンスを的確に計測できる尺度の特徴
    • グローバルな成果に焦点を当て、チーム同士が対立するような状況を防ぐ機能をもつ
    • 生産量ではなく成果に焦点を当てる
      • 目標達成にどれだけ貢献できたか
  • いくつかのツールを用いて改善に取り組むことができるが、組織の文化によっては正しく運用されない可能性がある
  • パフォーマンスを改善するために科学的な手法を展開するより前に、自組織の文化の把握と育成に努めるべき。

 

第3章  組織文化のモデル化と測定、改善の方法

    • 3.1: 組織文化のモデル化と測定
    • 3.5: 組織文化をどう変えていくか
  • 組織文化は3つのレベルで存在
    • 基本前提
      • 長期に渡って様々な関係や出来事、活動の意味を会得していく中で形成される
    • 価値観
      • 基本前提にくらべて可視性が高い
      • レンズの役割を果たしており、メンバーはそれを通して周囲の関係や出来事、活動を見る。
      • チームや組織の文化について論じる際、念頭にあるのがこのレベル
    • アーティファクト
      • 経営理念や社是、社訓、テクノロジーなど実体をもつもの
      • 可視性が高い
  • 有益で質の良い情報の3つの特徴
    • 受け手が解消したいと思っている疑問に対し、答えをもたらす
    • 適切なタイミングで伝達される
    • 受け手が有効に使えるようなやり方で提示される
  • 組織文化を変えるには
    • 最初にやるべきは関係者の思考方法を変えるのではなく、関係者の言動、皆が何をどう行うかを変えること
      • [疑問点] 思考が変わらないと言動や行動は変わらないのでは…

 

第5章 アーキテクチャのキーポイント

  • カプセル化された疎結合アーキテクチャと、それに見合った組織構造を実現すると以下2つの効果が得られる
    • 作業のテンポと安全性が向上し、バーンアウトやデプロイ関連の負荷が軽減されてデリバリのパフォーマンスが向上
    • 技術系部署をかなりの規模まで拡大でき、生産性を直線的に高められる
  • アーキテクチャ設計担当者が焦点を当てるエンジニアと成果
    • アーキテクチャの使い手となるエンジニアに焦点をあてる
    • そのエンジニアがより良い結果を出せるよう助け、結果に繋げられるツールとテクノロジーを提供する

 

第7章 ソフトウェア管理のプラクティス

    • 7.1: リーンマネジメントのプラクティス
    • 7.2: 負担の軽い変更管理プロセス
  • リーンマネジメントの構成要素
    • 進行中作業(WIP)の制限
    • 可視化
    • ワークフローの可視化
    • 負担の軽い変更承認プロセス
  • ビジュアルディスプレイのポイント
    • 可視性
    • 質の高いコミュニケーション
  • 変更プロセスについて
    • チーム外の人や組織の承認を得なければ変更できない場合、システムの安定性は向上しなかった
    • むしろ確実に遅れを招く
    • 推奨するのは、負担の軽い変更承認プロセスと、望ましくない変更を探知・排除するためのデプロイメントパイプラインを併用する
  • デプロイメントパイプラインの例

 

第8章 製品開発のプラクティス

    • 8.1: リーン製品開発のプラクティス
    • 8.3: 効果的な製品管理によるパフォーマンス向上
  • リーン開発、リーンスタートアップが重視している点
    • 製品のライフサイクル最初期からユーザーリサーチを頻繁に行い、製品の設計とビジネスモデルを検証し続けるというアプローチ
  • リーン製品開発の構成要素
    • 作業の細分化
    • 管理の可視化
    • 顧客フィードバックの収集と実装
    • チームによる実験
  • MVP: 実用最小限の製品
    • 製品自体とビジネスモデルの「検証による学び」が可能な規模の昨日だけから成るプロトタイプのこと
  • 顧客フィードバックを収集する際
    • 満足度を定期的に測定する
    • 品質について顧客の意見を積極的に収集する
    • 収集した内容を機能やデザインに盛り込む

 

第9章 作業を持続可能にする

  • デプロイ関連の負荷を緩和するための具体例(※内容よく分からないものがあるがとりあえず残しておく)
    • ★テストとデプロイの包括的自動化
    • トランクベースの開発も含めた継続的インテグレーション
    • 情報セキュリティのシフトレフト
    • テストデータの効果的管理
    • 疎結合アーキテクチャ
    • ★個々で独立して作業が進められる環境
    • 本番環境を再現するのに必要なすべての要素のバージョンコントロールによる管理
  • バーンアウトとは
    • 過労やストレスによる心身や感情面での極度の疲労
    • 仕事や日々の暮らしが単調で取るに足らないものに思えてくる
    • 無力感に襲われたりする
  • バーンアウトの背景にありがちなのが、不健全な組織文化やムダの多い非生産的な作業
  • 改善するには
    • 有意義な仕事を提供する努力を怠らない
    • 構成員の福利を助長するよう職場環境を整える
  • 予防法
    • 非難や責任追及ではなく「失敗からの学び」を重視
    • 敬意をもって担当者を支援する作業環境を作る
    • 明確な目的意識を伝える
    • 作業担当者の能力開発に投資する
    • 目標達成を妨げている要因や問題を担当者から聞き出し、是正する
    • 実験や学習のための時間、スペース、リソースを提供する
  • バーンアウトを招きがちなよくある問題
    • 過重労働
    • 自律性の欠如
    • 不十分な報酬
    • 人間関係の断絶
    • 公平性の欠如
    • 価値観のズレ
  • 兆し
    • 疲労困憊
    • 仕事に対する無関心、冷笑癖、無力感
    • 私生活へのマイナス影響

 

第10章 従業員の満足度、アイデンティティ、コミットメント

    • 10.1: 従業員ロイヤルティ
    • 10.2: 組織文化と帰属意識の改善
    • 10.3:組織のパフォーマンスに対する職務満足度の影響
  • 指標
    • eNPS(employee Net Promoter Score): 従業員ネットプロモータースコア
  • 測定用の質問
    • あなたが自分たちの会社・製品・サービスを友人や同僚に推奨する可能性はどの程度ですか
  • 測定方法
    • カテゴライズ
      • 0-6: 批判者
      • 7-8: 中立者
      • 9-10: 推奨者
    • 上記でカテゴライズされた人数の比率から算出される
  • 帰属意識
    • 首脳陣がしかるべき人材投資を行い、従業員が最善を尽くせるよう計らえば組織に対する従業員の帰属意識が高まる
    • → 組織の成長への貢献努力を自然な形で引き出せる
    • 個人の価値とチーム・組織の目標との一致度も帰属意識の決定要因の1つ
  • 職務満足度
    • 作業を進めるのに必要なツールなどのリソースを入手できるか否かに大きく依存する
    • 他にも見落とせない要件として以下が挙げられる
      • 今の仕事に満足しているか
      • 作業に必要なツールなどのリソースを提供されているか
      • 今の仕事で自分のスキルや能力を十分活かせているか

 

第11章 変革型リーダーシップとマネジメントの役割

    • 11.1: 変革型リーダーシップ
    • 11.2: 管理者の役割
    • 11.3: 組織文化を改善しチームを支援するための秘訣
  • リーダーシップは業績に多大な影響を及ぼす
  • リーダーシップを執るには部下を鼓舞しやる気にさせることが必要
  • 変革型リーダーシップとは
    • 部下の価値観や目的意識に訴えて、より良いパフォーマンスの実現のためにやる気を鼓舞し、大規模な組織変革を促進する
    • そうすることで共通の目標に向かって努力するよう仕向ける
  • 変革型リーダーシップと奉仕型(サーバント)リーダーシップの違い
    • 何を重視するかという点で大きく異なる
    • 奉仕型: 部下自身の成長や能力に重きを置く
    • 変革型: 部下に組織との一体感をもたせ、組織の方針に従わせることに重きを置く
  • 変革型リーダーの特性
    • ビジョン形成力
      • 組織が何を目指し、5年後どうあるべきかを明確に把握している
    • 心に響くコミュニケーション能力
      • 不確実で変動する環境下でも、従業員を鼓舞しやる気にさせるような対話を行う
    • 知的刺激
      • 部下の意欲をかきたて、新たな方法で問題に取り組むよう促す
    • 支援的リーダーシップ
      • 部下の個人的要求うや感情に配慮と気づいかいを示す
    • 個人に対する評価
      • 目標の達成、作業品質の向上を認識・称賛し、顕著な業績を挙げた場合には個人的に報奨する
  • リーダーシップは優れたチーム、テクノロジー、組織の構築に役立つ
    • 間接的な影響力を行使することで。チームがアーキテクチャを再構築し、CI/CD やリーン経営の手法を実現できるようになる、ということ
  • 管理者の役割
    • 企業の戦略目標とチームの業務を結ぶ
    • チームのパフォーマンス向上
      • 従業員が安心できる仕事環境の構築
      • 従業員の能力開発への投資
      • 業務障害の排除
      • etc...
  • 好ましいチーム文化を育む方法
    • 部門横断型の協働
    • 学習環境
    • ツール
  • 部門横断型の協働
    • 他チームにいる同じ立場の相手方との信頼関係を構築する
    • 現場担当者に部署間の異動を促す
    • チームの協働を容易にする作業を追求し推進する。そうした作業が成功すれば褒章を与える
  • 学習環境
    • 教育のための予算を計上し、それを組織内で公表する
    • チームメンバーのために「個人的な学習ができる予算」や「アイデアを探求するための時間」を確保する
    • 従業員が失敗を恐れないようにする
    • 情報共有のための機会や場を作る
    • 「デモデイ」やフォーラムを開催して、情報共有や技術革新を促す
  • ツール
    • チームがツールを選択できるようにする
    • モニタリングを優先事項にする

 

第16章 ハイパフォーマンスを実現するリーダーシップとマネジメント

    • 16.1: ハイパフォーマンスなチームや組織を実現する管理体制
    • 16.2: リーダーシップの変革、マネジメントの変革、チームプラクティスの変革

 

 

 

 

bootstrap のカードスタイルをいい感じに表示させる方法

bootstrap には.card, .card-deckというクラスが存在し、自動的にカードスタイルで表示してくれる。

↓こういうやつ

f:id:two-face:20201008235728p:plain
カードスタイル

getbootstrap.jp

ただそのまま使うと横一列に並んでしまった。

なんでだろう〜と思い調べたところ、flex の影響でflex-flow: row wrap;が 効いていないようだった。

f:id:two-face:20201009000505p:plain

この設定を無効にすればこちらの思惑どおり表示されたので、CSS に以下を追加する。

.card {
  width: calc(25% - 30px);  ← コンテンツを4つ表示したらwrap させるための幅指定
  flex: none !important;  ← flex を無効化
  margin: 10px;  ← カード幅の調整
}

無事思ったとおり表示できるようになった。

bootstrap を利用しない場合はここに記載された設定をすればよさそう。

ics.media

東証が....

システム障害でまる1日取引ができないとか、そんなことあるんだね。

富士通が開発してたみたいなので、復旧したら一気に株価下がりそうw

 

けど実際開発する立場になったら笑えなさそう。。。

メンテナンスはあるにしてもほぼ落とせないし、落ちたら影響範囲が半端ないし、開発もだけど運用とかめちゃめちゃ気を遣いそう。

 

とりあえず明日には再開するみたいでよかった。

取引できないから今日は見なくていいや〜と思って1日過ごしたら、普段どれだけ値動きに気を取られてたかが分かったw

配当目当てで購入したものが多いから、あまり気にせず仕事に集中しよう、うん。

とはいえ勉強はちゃんとしよう。 

 

mongo のsave, update

mongodb のデータをupdate したときの挙動を確認したところ、なぜか2回update が走っていた。

色々調べたところ、save, update はPromise を返さないことが判明。

update 処理をawait で処理するようにしていたが、それが原因で2回更新されていた模様。

  • 2回更新が走っていた処理
let result = await model.update(
  {"_id": new ObjectId("id")}, 
  {$push: pushValue}, 
  (err) => { 
    if (err) throw new Error(err); 
  }
);
return result;

update の結果をPromise で返すようにすることで1回更新されるようになり、意図した通りの挙動になった。

  • 想定通り1回更新される処理
return new Promise((resolve, reject) => {
          try {
            model.update(
              { "_id": new ObjectId(qid) },
              { $push: pushVal },
              (err, result) => {
                if (err) return reject(err);  // ← ここはちゃんと動作確認できてない
                resolve(result);
              });

          } catch (err) {
            reject(err);
          }
        });

mongo でネストされた配列から特定の要素を検索する方法

以下のようなデータがあったとして

{ 
  "_id" : ObjectId("5f6a3919a761753bb5e73c68"),
  "author" : "aaa",
  "question" : "test1",
  "answers" : [ 
    { 
      "voters" : [ "ccc" ],
      "_id" : ObjectId("5f6a3919a761753bb5e73c69"),
      "title" : "a" 
    }, 
    { 
      "voters" : [ "bbb" ],
      "_id" : ObjectId("5f6a3919a761753bb5e73c6a"),
      "title" : "b" 
    }, 
    { 
      "voters" : [ "aaa" ],
      "_id" : ObjectId("5f6a3919a761753bb5e73c6b"),
      "title" : "c" 
    }
  ]
}

voters の中に aaa が含まれる箇所だけを取り出したい場合

find を利用

$elemMatch を使うことで配列の中の要素を検索することが可能、全ての内容が返ってくる。

answers のどの要素に対してaaa が含まれるかを特定する必要がない場合はこれで問題ない

> db.questions.find({"_id": ObjectId("5f6a3919a761753bb5e73c68"), "answers.voters":{$elemMatch: {$eq: "aaa"}}})
{ "_id" : ObjectId("5f6a3919a761753bb5e73c68"), "images" : [ ], "member" : [ ], "author" : "aaa", "question" : "test1", "answers" : [ { "voters" : [ "ccc" ], "_id" : ObjectId("5f6a3919a761753bb5e73c69"), "title" : "a" }, { "voters" : [ "bbb" ], "_id" : ObjectId("5f6a3919a761753bb5e73c6a"), "title" : "b" }, { "voters" : [ "aaa" ], "_id" : ObjectId("5f6a3919a761753bb5e73c6b"), "title" : "c" } ], "expire" : "", "publish" : 1, "create" : "2020-09-23 02:49:13", "update" : "2020-09-23 02:49:13", "delflag" : 0, "__v" : 0 }

aggregate を利用

aaa を含むものだけを返すことができる。

> db.questions.aggregate([{$match: {"_id": ObjectId("5f6a3919a761753bb5e73c68")}}, {$unwind: "$answers"}, {$unwind: "$answers.voters"}, {$match: {"answers.voters": "aaa"}}])
{ "_id" : ObjectId("5f6a3919a761753bb5e73c68"), "images" : [ ], "member" : [ ], "author" : "aaa", "question" : "test1", "answers" : { "voters" : "aaa", "_id" : ObjectId("5f6a3919a761753bb5e73c6b"), "title" : "c" }, "expire" : "", "publish" : 1, "create" : "2020-09-23 02:49:13", "update" : "2020-09-23 02:49:13", "delflag" : 0, "__v" : 0 }

$unwind を2回実行する場合は、1つ上の要素名を含めて指定する必要があった。

({$unwind: "$answers"}, {$unwind: "$answers.voters"} のところ)

aggregate に関する仕様は以下

docs.mongodb.com