※本ブログの目的と内容¹、読者の方へ²

概要

Workload Identityとは何か

Google CloudのWorkload Identity連携（Workload Identity Federation: WIF）は、外部IDプロバイダ（OIDC/SAML）が発行する短期トークンをGoogle CloudのSecurity Token Service（STS）で交換し、サービスアカウントの一時的な資格情報として利用する仕組み。
サービスアカウント鍵を配布・保管せずに、GitHub ActionsなどのCI/CDや他クラウド・オンプレ環境から安全にGCPへアクセスできる。

Workload Identityのメリット・デメリット

メリット

• サービスアカウント鍵の廃止（キーレス）で漏えいリスクを低減
• 短命なトークンを都度発行・自動ローテーションし、運用負荷と影響範囲を最小化
• 最小権限の原則を徹底（SA権限は最小限、紐付けは属性条件でリポジトリ/ブランチ単位に制限）
• 監査性の向上（IAM監査ログとOIDCクレームで誰が何を実行したか追跡しやすい）
• マルチ環境対応（他クラウドやオンプレ、複数CIから安全に利用可能）

デメリット

• 初期設定がやや複雑（プール/プロバイダ、属性マッピングと条件式、バインディング設計）
• トラブルシュートに知識が必要（クレーム不一致、aud/sub、時刻ずれ、ロール不足）
• 一部の古いツール/SDKでは対応が不十分な場合がある
• トークン有効期限の制約により長時間ジョブは再認証の考慮が必要

参考リンク

• デプロイメント パイプラインとの Workload Identity 連携を構成する
• Configuring OpenID Connect in Google Cloud Platform
• Authenticate to Google Cloud from GitHub Actions

Workload Identity

Google Cloud Console > IAMと管理 > Workload Identity 連携 で以下の設定を行う。

プール作成

名前

GitHub

プールID

github

プロバイダ作成

名前

GitHub

プロバイダID

github

発行元（URL）

https://token.actions.githubusercontent.com

JWKファイル（JSON）

ブランク

オーディエンス

デフォルト

属性のマッピング

属性条件

attribute.repository == "{ owner }/{ repo }"

Service Account

Google Cloud Console > IAMと管理 > サービス アカウント で以下の設定を行う。

サービスアカウント作成

名前

GitHub Actions

サービスアカウントID

github-actions

権限

デプロイ対象に応じて権限を変更する。以下は functions をデプロイする場合。

Cloud Functions 開発者
Service Usage ユーザー
閲覧者

アクセス権を持つプリンシパル

プリンシパル

principalSet://iam.googleapis.com/projects/{ project }/locations/global/workloadIdentityPools/github/attribute.repository/{ owner }/{ repo }

ロール

Workload Identity ユーザー

プリンシパル追加

App Engine default service account

アクセス権を持つプリンシパル

プリンシパル

github-actions@{ your-project-id }.iam.gserviceaccount.com

ロール

サービス アカウント ユーザー

Default compute service account

アクセス権を持つプリンシパル

プリンシパル

github-actions@{ your-project-id }.iam.gserviceaccount.com

ロール

サービス アカウント ユーザー

GitHub Actions

以下のステップをデプロイ直前に追加する。

- id: auth
  name: Authenticate to GCP (OIDC)
  uses: google-github-actions/auth@v3
  with:
    create_credentials_file: true
    workload_identity_provider: projects/{ project }/locations/global/workloadIdentityPools/{ pool }/providers/{ provider }
    service_account: github-actions@{ your-project-id }.iam.gserviceaccount.com

- name: gcloud auth login
  run: gcloud auth login --brief --cred-file="${ steps.auth.outputs.credentials_file_path }"

prototype

JavaScriptはプロトタイプベースの言語。別のオブジェクト（＝プロトタイプ）を参照して性質を引き継ぐ。 あるオブジェクトにプロパティやメソッドが見つからなければ、プロトタイプをたどって探す。 prototypeに定義された関数はインスタンス間で共有され、メモリ効率も良い。

サンプル

class構文の実態はprototype構文である。

class構文

class Animal {
  constructor(name) {
    this.name = name;
  }
  
  speak() {
    console.log(`${this.name} makes a sound`);
  }
}

class Dog extends Animal {
  constructor(name, breed) {
    super(name);
    this.breed = breed;
  }
  
  bark() {
    console.log(`${this.name} barks!`);
  }
}

prototype構文

function Animal(name) {
  this.name = name;
}
Animal.prototype.speak = function() {
  console.log(this.name + " makes a sound");
};

// Animal 概念
/*
  [[Prototype]]: Function.prototype,
  [[Call]]: (thisArg, [name]) => {
    // Animal("Pochi")
    thisArg.name = name;
    return undefined;
  },
  [[Construct]]: ([name], newTarget) => {
    // new Animal("Pochi")
    const obj = OrdinaryCreateFromConstructor(newTarget, Animal.prototype);
    Animal.[[Call]](obj, [name]);
    return obj;
  },
  prototype: {
    [[Prototype]]: Object.prototype,
    constructor: Animal,
    speak: function() {
      console.log(this.name + " makes a sound");
    }
  },
  name: "Animal",
  length: 1 // 仮引数の数（name）
*/

function Dog(name, breed) {
  Animal.call(this, name);
  this.breed = breed;
}
Dog.prototype = Object.create(Animal.prototype);
Dog.prototype.constructor = Dog;
Dog.prototype.bark = function() {
  console.log(this.name + " barks!");
};

// Dog 概念
/*
  [[Prototype]]: Function.prototype,
  [[Call]]: (thisArg, [name, breed]) => {
    // Dog("Pochi", "Shiba")
    Animal.[[Call]](thisArg, [name]);
    thisArg.breed = breed;
    return undefined;
  },
  [[Construct]]: ([name, breed], newTarget) => {
    // new Dog("Pochi", "Shiba")
    obj = OrdinaryCreateFromConstructor(newTarget, "%Object.prototype%", internalProto = Dog.prototype);
    Dog.[[Call]](obj, [name, breed]);
    return obj;
  },
  prototype: {
    [[Prototype]]: Animal.prototype,
    constructor: Dog,
    bark: function() {
      console.log(this.name + " barks!");
    }
  },
  name: "Dog",
  length: 2 // 仮引数の数（name, breed）
*/

const dog = new Dog("Pochi", "Shiba");
dog.speak(); // Pochi makes a sound
dog.bark();  // Pochi barks!

// dog 概念
/*
  [[Prototype]]: Dog.prototype,
  name: "Pochi",
  breed: "Shiba"
*/

// dog 全体像
/*
{
  [[Prototype]]: {
    [[Prototype]]: {
      [[Prototype]]: Object.prototype,
      constructor: Animal,
      speak: [Function: speak]
    },
    constructor: Dog,
    bark: [Function: bark]
  },
  name: "Pochi",
  breed: "Shiba"
};
*/

Object.getPrototypeOf

prototypeを取得する。

インスタンスオブジェクト

Object.getPrototypeOf(dog) === Dog.prototype;                   // true
Object.getPrototypeOf(Dog.prototype) === Animal.prototype;      // true
Object.getPrototypeOf(Animal.prototype) === Object.prototype;   // true
Object.getPrototypeOf(Object.prototype) === null;               // true

コンストラクタオブジェクト

Object.getPrototypeOf(Dog) === Function.prototype;              // true
Object.getPrototypeOf(Function.prototype) === Object.prototype; // true
Object.getPrototypeOf(Object.prototype) === null;               // true

instanceof

インスタンスオブジェクトが特定のコンストラクタオブジェクトから生成されたかどうかを判定する演算子。

サンプル

dog instanceof Dog;       // true
dog instanceof Animal;    // true
dog instanceof Object;    // true

内部処理イメージ

プロトタイプチェーンをたどって判定。

function instanceOf(left, right) {
  const proto = right?.prototype;
  let cur = Object.getPrototypeOf(left);
  while (cur) {
    if (cur === proto) return true;
    cur = Object.getPrototypeOf(cur);
  }
  return false;
}

this

種類

デフォルトバインディング

this → strict: undefined / 非strict: window（または global）

function showMessage() {
  console.log(this?.message || "no this");
}
const message = "global";
showMessage(); // strict: no this / 非strict: global

暗黙的バインディング

this → 呼び出し元のオブジェクト

const user = {
  name: "Alice",
  greet() {
    console.log(`Hello, I'm ${this.name}`);
  }
};
user.greet(); // "Hello, I'm Alice"

明示的バインディング

this → call / apply / bind の第1引数

function introduce() {
  console.log(`I'm ${this.name}, ${this.age} years old.`);
}
const person = { name: "Bob", age: 25 };
introduce.call(person); // "I'm Bob, 25 years old."

コンストラクタ呼び出し（暗黙的バインディングの一種）

this → 新しく生成されたオブジェクト
※以下の例では increment がインスタンスごとに生成されるため、メモリ効率が悪い。通常は Counter.prototype に定義する

function Counter() {
  this.count = 0;
  this.increment = function() {
    this.count++;
    console.log(this.count);
  };
}
const c = new Counter();
c.increment(); // 1

// c 概念
/*
  [[Prototype]]: Counter.prototype,
  count: 0,
  increment: function() {
    this.count++;
    console.log(this.count);
  }
*/

// c 全体像
/*
  [[Prototype]]: {
    [[Prototype]]: Object.prototype,
    constructor: Counter,
  },
  count: 0,
  increment: function() {
    this.count++;
    console.log(this.count);
  }
*/

クラスのインスタンスメソッド（暗黙的バインディングの一種）

this → そのクラスのインスタンス
※詳しい仕組みは prototype や Array 参照のこと

class Player {
  constructor(name: string) {
    this.name = name;
    this.hp = 100;
  }
  attack() {
    this.hp -= 10;
    console.log(`${this.name} attacked! HP: ${this.hp}`);
  }
}
const p = new Player("Rin");
p.attack(); // "Rin attacked! HP: 90"

アロー関数（レキシカル this）

this → 定義されたときの外側スコープの this

const team = {
  name: "Red",
  members: ["Ken", "Mia"],
  showMembers() {
    this.members.forEach(member => {
      console.log(`${member} from ${this.name}`);
    });
  }
};
team.showMembers(); 
// "Ken from Red", "Mia from Red"

DOM イベントハンドラ

this → イベントを受け取った要素

document.querySelector("button").addEventListener("click", function() {
    this.textContent = "Clicked!";
    console.log(this); // <button>Clicked!</button>
});

Array

JavaScriptのArrayはオブジェクトであり、ブラケット記法で要素にアクセスする。 pushやpopはArrayオブジェクトのメソッドであり、暗黙的バインディングによりthisは配列オブジェクトを指す。

const arr = [10, 20, 30];
arr.push(40);
console.log(arr[3]); // 40

// Array 概念
/*
  [[Prototype]]: Array.prototype,
  0: 10,
  1: 20,
  2: 30,
  length: 3,
*/

// Array 全体像
/*
  [[Prototype]]: {
    push: function(...items) {
      let len = this.length >>> 0;
      for (let i = 0; i < items.length; i++) {
        this[len] = items[i];
        len++;
      }
      this.length = len;
      return len;
    },
    pop: function() {
      let len = this.length >>> 0;
      len--;
      const value = this[len];
      delete this[len];
      this.length = len;
      return value;
    }
  },
  0: 10,
  1: 20,
  2: 30,
  length: 3,
*/

closure

外部の変数情報を保持した関数のこと。 外部の変数情報はレキシカル環境に保持される。

function createAdder(a: number) {
  return function add(b: number) {
    const sum = a + b;
    return sum;
  }
}

// createAdder 概念
/*
  [[Prototype]]: Function.prototype,
  [[Call]]: (thisArg, [a]) => {
    // createAdder(2)
    const add = function add(b) {
      const sum = a + b;
      return sum;
    };
    return add;
  },
  prototype: { constructor: createAdder },
  name: "createAdder",
  length: 1
*/

const addTo2 = createAdder(2);
addTo2(5); // 7

// addTo2 概念
/*
  [[Prototype]]: Function.prototype,
  [[Call]]: (thisArg, [b]) => {
    // addTo2(5)
    const sum = [[Environment]].a + b; // 2 + 5
    return sum;
  },
  [[Environment]]: {
    // 実行時のレキシカル環境
    a: 2,             // 環境レコード
    outer: GlobalEnv  // 外側のレキシカル環境への参照
  },
  name: "add",
  length: 1
*/

asynchronous

Promise

「未来の結果を入れる箱」を作る。 resolve() が呼ばれると「成功」状態に、 reject() が呼ばれると「失敗」状態になる。

const promise = new Promise((resolve, reject) => {
  if (Math.random() < 0.5) resolve("成功しました");
  else reject("失敗しました");
});

promise
  .then(result => console.log(result))
  .catch(error => console.error(error));

setTimeout

「一定時間後に関数を実行する予約」を行う。 呼び出し時点で関数はまだ実行されず、タイマーを設定して即座に戻る（ノンブロッキング）。

setTimeout(() => {
  console.log("1秒後に実行されました");
}, 1000);

clearTimeout

setTimeout の返す「タイマーID」を clearTimeout に渡して呼ぶと、その予約はキャンセルされる。

const timerId = setTimeout(() => {
  console.log("これは実行されません");
}, 3000);

clearTimeout(timerId);

AbortController

controller.signal

スイッチの状態を監視するオブジェクト。

controller.abort()

中断スイッチ。 signal.aborted が true になり、 "abort" イベントが発火する。

const controller = new AbortController();
const { signal } = controller;

signal.addEventListener("abort", () => {
  console.log("中断されました！");
});

setTimeout(() => {
  controller.abort();
}, 2000);

※本ブログの目的と内容¹、著作者の方へ²

集中力を自在に操る３つのルール

• ルール１：鍛え方を知っている
  • ウィルパワー
    思考や感情をコントロールする力。 ウィルパワーの総量には限りがあり、集中することで消耗する
  • 集中力を鍛える２つのアプローチ
    1. ウィルパワーの総量を増やす
    2. ウィルパワーを節約する
• ルール２：長時間集中していない
  • そもそも人間の脳は集中を維持させないようにできている
• ルール３：「疲れ」を脳でコントロールしている
  • 「疲れているから、集中できない」は錯覚

高い集中力を生み出す７つのエンジン

環境

行動しやすい「環境」をつくる。 選択肢やモノを減らし、集中力を奪う迷いや決断を減らす。

• 集中力を奪うモノ
  • スマホ（注意をそらすものは断捨離する）
  • 散らかったモノ（モノを減らすほど自己コントロール力が増す）
• 集中力を高めるモノ
  • 目的にあったモノ（自分の重視したい目的に向けて部屋を整える）
  • 鏡（だらけ始めた自分に気づき、「いかん、いかん」と戒める）

姿勢

だらけた姿勢はウィルパワーを浪費する。 １日に何回か座り直す習慣をつくる。 １５分に１回のペースでイスから立ち上がる。 脳に新しい刺激が伝わり、集中力を持続させる効果がえられる。

理想的な姿勢

• あごを引いて頭は首の上にのせる
• お尻と腰を直角にする
• 両膝をつける
• 足の裏を床につける

食事

ブドウ糖はウィルパワーの燃料庫。 「低GI食品」を中心とした3食とナッツ類を中心とした「おやつ」の補給が、集中力を深め、持続させる。 血糖値の乱高下に、人間は強いストレスを感じる。 血糖値のつなぎとして「間食」がおすすめ。

• 低GI食品
  • そば、玄米、全粒粉パン、リンゴ、チーズ、ヨーグルト
• 間食
  • ピーナッツ、ヘイゼルナッツ等のナッツ系、クルミ、アーモンド、カボチャの種、ひまわりの種
• コップ一杯の水
  • 水を飲まないと集中力と記憶力が落ちる
  • １〜２時間にコップ１杯ほどの水分を補給する
• セロトニン（幸せホルモン）
  • バナナ、卵、鶏肉、ひじき

感情

怒りには人を突き動かす強い力が秘められている。 怒りは「目標思考行動」を強く促す。

フロー体験

• ちょうどいい難易度
• コントロール感覚
• 直接的なフィードバック
• 集中が邪魔されない

習慣

習慣化でウィルパワーを温存し、新しい習慣やスキルを身につけるためにウィルパワーを使う。 「意思決定」で人は疲れる。即時判断がウィルパワーの浪費を防ぐ。

７本のハンガーが集中力をつくり出す

日常の生活の中で、選ぶ場面が少なければ少ないほど集中力は上がる。 目的に向かって集中できる人は、この「仕組み化」に力を入れ、ウィルパワーを節約し、人生で大切なことに集中している。

運動

運動は脳をリセットする。 ２０分の軽い運動をした後の３〜４時間は認知能力、集中力や考察力が高まる。 運動には人の感情をポジティブにする働きもある。

グリーンエクササイズ

緑の中を５分ほど散歩する。 水の側＆午前中の陽の光を浴びるとさらに効果が高まる。

アクティブレスト

軽い運動をすることで効果的にウィルパワーを回復させられる。

瞑想

集中力が向上する。

やり方

1. 体を動かさず、じっと座る
2. ゆっくりと呼吸する
   • ７秒かけて吸い、７秒かけて吐く

疲れをリセットする３つの回復法

睡眠

睡眠不足は集中力を奪う要因。 成功している人たちは長時間眠っている。 平均睡眠時間は約８時間。一方、一般人の平均睡眠時間は６時間。

• 何時に寝たかが重要
  • 眠り方の基本はやはり朝型の生活スタイル
  • 睡眠の質は２２時から夜中２時の間に深い眠りに落ちているかどうかで決まる
• 音ではなく「光」で起きる
  • 質の高い睡眠には、暗闇の中での睡眠と、光での目覚めが必要
• １５分のパワーナップ
  • 仮眠することで日中でもウィルパワーを回復できる

感覚から癒やす

「目の疲れ」を「脳の疲れ」と錯覚する。 脳が処理している情報のうちの８割以上は、視覚を通して集められる。 「目を休ませる」には、視覚情報をシャットアウトする。

不安を書き出す

不安を書き出すことでワーキングメモリーが増える。

集中力を自動でつくり出す５つの時間術

超朝早起き

社会的成功者の４時半起床・２０時半就寝といった生活リズムは、体にとっては最適なリズム。

朝のゴールデンタイムを自分のために使う

集中力が最も高くなるのは朝の２時間。その中でも朝食を摂った後の３０分が特に重要。 何か新しいことを始めたい、資格を取るための勉強をしたいと思っているなら、この３０分を有効に活用すべき。

朝、行うべき７つの行動

1. 早起きして、朝食を摂る
2. 朝日を浴びながら軽く汗を流す
3. モチベーションが上がる話題や言葉、詩に触れる
4. 日常の幸せへの感謝を書き留める
5. 「今日が人生最後の日ならどうする」と自分に問う
6. その日の計画を１０分以内に立てる
7. 短時間の瞑想をする

ポモドーロ・テクニック

２５分の集中と５分の休憩を繰り返す。 作業に飽きる前に休憩する（焦らす）ことで、再開したときもスムーズに集中状態に戻れる。 休憩中は、瞑想したりする。 ポモドーロ・テクニックの優れた点は、「やる気が起こるから行動するのではない。行動したからやる気が出る」という作業興奮の原理を実践しやすい点にある。

集中することはたった１つ

２５分間では「１つのこと」に集中する。 「他のことをしない」というルールを守るだけで、集中力が必ず高まる。

観念によって人の行動が変わる（プライミング効果）

どこに意識を向けているかによって同じ時間、同じ作業をしていても成果には大きな差が開く。 集中力が高い人は、自分の集中しやすい環境にこだわり、入ってくる情報やモノ、単語（言葉）ですら選び取っている。 「集中力を保てた」と感じられた環境や時間を記録する。

取り組む時間を短くするほど、早く終る

人は目に見えないと、つい「無限にある」と思い込んでしまう。 「あれもこれもやれる」と思っている状態ほど、集中できず、結果に結びつかない可能性が高い。 集中力は自由なときよりも制限のある状態のほうが高まる。

ウルトラディアンリズム

ポモドーロ・テクニックの応用編。９０分集中、２０分休憩。

アイビー・リー・メソッド

１つの作業が終わるまで、断固として次のことをやらない。 選択と集中によって、本当に大事なことのみ全力を尽くす。 それ以外のことは、やらない、あるいは、誰かにやってもらう。 それにより迷いを消し、行動につなげる。

６つのステップ

1. 「明日やるべきこと」を６つ、メモする
2. 重要な順に並べ替える
3. 翌日、順番に取り組む
4. 全部できなくても、悔やむことなく忘れる
5. 明日のための６つの項目を新しくメモする
6. １〜５を丁重に繰り返す

スケジュールに余白をつくる

後悔したり自分を責めるようになると、結局、人は行動しなくなる。 多少ズレても吸収できるようにするためのあそびを持たせる。 また、あえてサボる時間をつくり、リラックスする習慣を持つことで、結果的に翌日以降の集中力を高められる。

※本ブログの目的と内容¹、読者の方へ²

config

モノレポ運用で必要な設定をパッケージで管理している。

• npm
• GitHub

コンセプト

• 共通設定を @o3osatoshi/config に集約し、モノレポ全体で型・ビルド・リントを一貫管理する
• 各アプリはベース設定を継承し、必要な差分だけを上書きすることでメンテナンスコストを抑える

役割

• tsconfig … 型チェック
• tsup … ビルド＆バンドル
• biome … フォーマット＆リント
• eslint … ソート

tsconfig

型チェックのみに利用する。 共通の設定を base.json にまとめ、各パッケージ・アプリケーションで継承する。

base.json

厳格性に関する設定

厳格さをできる限り高める。

互換性に関する設定

ESMをベースとしつつ、CJSやバンドラ挙動とも整合を取る。

next.json（Nextアプリ）

汎用設定

個別設定

browser.json（React UIライブラリ）

汎用設定

tsup

ビルド＆バンドルに利用する。

共通設定

browserPreset（React UIライブラリ）

ビルド

Client Componentの成果物には、先頭に"use client";が必要。 しかし、tsup等でビルドすると、tsxファイル先頭の"use client";は削除されてしまう。 対策として、ビルド完了後に成果物の先頭に"use client";を後から付与する。

ポイント

• ClientサイドのコードとSeverサイドのコードを別々にバレルする
• 成果物はClientサイドとServerサイドのそれぞれでバンドルする
• tsupのonSuccessフックで、Clientサイドの成果物の先頭に"use client";を付与する

※コンポーネント毎にビルドし、それぞれに"use client";を付与する方法もあるが、管理が少々煩雑になる

設定

// tsup.client.config.mjs
export default await browserPreset({
  bundle: true,
  entry: { index: "src/index.client.ts" },
  onSuccess: "node ./scripts/ensure-use-client.mjs dist/client/index.js",
  outDir: "dist/client",
  splitting: false,
});

// tsup.server.config.mjs
export default await browserPreset({
  bundle: true,
  entry: { index: "src/index.server.ts" },
  outDir: "dist/server",
  splitting: false,
});

functionsPreset（Firebase Functions）

ビルド

Firebaseの仕様から、ビルドまわり（特に依存管理）が少々特殊になっている。 詳細はこちらの投稿を参照のこと。

publicDualPreset（外部配布ライブラリ）

biome

フォーマット＆リントに利用する。

base.json

適用

全体にbiomeを反映させるため、ルートに以下のbiome.jsonを配置する。

// /biome.json
{
  "extends": ["@o3osatoshi/config/biome/base.json"],
  "root": true
}

next.json（Nextアプリ）

適用

個別にbiome.jsonを配置することで、設定の上書きが可能。nextやreact用の設定反映範囲を限定できる。

// /apps/web/biome.json
{
  "extends": [
    "@o3osatoshi/config/biome/base.json",
    "@o3osatoshi/config/biome/react.json",
    "@o3osatoshi/config/biome/next.json"
  ],
  "root": false
}

read.json（Reactアプリ）

適用

// /packages/ui/biome.json
{
  "extends": [
    "@o3osatoshi/config/biome/base.json",
    "@o3osatoshi/config/biome/react.json"
  ],
  "root": false
}

eslint

ソートのみに利用する。 biomeのカバー範囲がまだまだ狭いため、補完的にeslintを利用する。

config

ライブラリ毎にconfigを作成し、一つにまとめてexportする。

import jsonc from "./jsonc.mjs";
import perfectionist from "./perfectionist.mjs";
import vitest from "./vitest.mjs";

export default [
  {
    ignores: [
      "**/node_modules/**",
      "**/dist/**",
      "**/generated/**",
      "**/.next/**",
      "**/.turbo/**",
      "**/.idea/**",
      "**/storybook-static/**",
    ],
  },
  ...perfectionist,
  ...jsonc,
  ...vitest,
];

適用

プロジェクトルートでは、importしたconfigをそのままexportする。

// /eslint.config.mjs
import config from "@o3osatoshi/config/eslint/config.mjs";

export default [...config];

※本ブログの目的と内容¹、読者の方へ²

前提

• functionsのみのモノレポ化を対象としている
• hostingはモノレポ化の対象外（当方はvercelを利用している）

デプロイフロー

Firebase Functionsモノレポの問題点

Firebase Functionsのデプロイフロー（仕様）

1. 対象ディレクトリ（ apps/functions ）をサーバにアップロード
2. アップロードされたディレクトリで npm install を実行

問題点

npm install 時に、ローカルパッケージ（ packages/application等 ）を見つけられずにエラーになる。

解決策

バンドルを組み合わせたデプロイフロー

1. functionsのビルド＆バンドルをデプロイ前に行う
2. 対象ディレクトリ（ apps/functions ）をサーバにアップロード
3. アップロードされたディレクトリで npm install を実行

ポイント

ローカルパッケージへの依存をバンドルにより事前に解決する。

構成

⏺ root/
  ├── 📁 apps/
  │   ├── 📁 web/                          # Next.js
  │   │
  │   └── 📁 functions/                    # Firebase Cloud Functions
  │       ├── 📁 src/
  │       │   └── 📄 index.ts
  │       ├── 📄 package.json
  │       ├── 📄 tsconfig.json
  │       ├── 📄 tsup.config.ts
  │       └── 📄 turbo.json
  │
  ├── 📁 packages/
  │   ├── 📁 application/                  # アプリケーション層
  │   │   ├── 📁 src/
  │   │   │   └── 📄 index.ts
  │   │   ├── 📄 package.json
  │   │   └── 📄 tsconfig.json
  │   ├── 📁 domain/                       # ドメイン層
  │   │   ├── 📁 src/
  │   │   │   └── 📄 index.ts
  │   │   ├── 📄 package.json
  │   │   └── 📄 tsconfig.json
  │   └── 📁 prisma/                       # インフラストラクチャ層
  │       ├── 📁 src/
  │       │   └── 📄 index.ts
  │       ├── 📄 package.json
  │       └── 📄 tsconfig.json
  │
  ├── 📄 package.json                      # ワークスペース設定
  ├── 📄 turbo.json                        # Turborepo設定
  └── 📄 firebase.json                     # Firebase設定

設定

モノレポ化にあたって、重要なポイントのみ説明する。 フルコードは、GitHubリポジトリを参照のこと。

apps/functions

functions/src/index.ts

1. 通常通りにローカルパッケージからインポートする

import { GetTransactionsUseCase } from "@repo/application"; // <------------- 1
import { PrismaTransactionRepository } from "@repo/prisma"; // <------------- 1
import { onRequest } from "firebase-functions/v2/https";

const repo = new PrismaTransactionRepository();
const usecase = new GetTransactionsUseCase(repo);

export const getTransactions = onRequest(async (request, response) => {
  const transactions = await usecase.execute();
  response.json(transactions);
});

functions/package.json

1. tsup でビルド＆バンドルを行う
2. ローカルパッケージへの依存を明記しない

{
  "scripts": {
    "build": "tsup" // <----------------------------------------------------- 1
  },
  "dependencies": { // <----------------------------------------------------- 2
    "firebase-admin": "^12.6.0",
    "firebase-functions": "^6.0.1"
  },
  "devDependencies": { // <-------------------------------------------------- 2
    "firebase-functions-test": "^3.1.0",
    "tsup": "^8.4.0",
    "typescript": "^4.9.0"
  }
}

applicationパッケージ等への依存を明記すると、Firebase側のインストールでエラーが発生してしまう。 ローカルビルド時にバンドルすることでエラーを避ける。

functions/tsconfig.json

1. applicationパッケージ等への依存はパスエイリアスで解決する

{
  "compilerOptions": {
    "paths": {
      "@repo/application": ["../../packages/application/src"], // <---------- 1
      "@repo/prisma": ["../../packages/prisma/src"] // <--------------------- 1
    }
  }
}

functions/tsup.config.ts

1. バンドルサイズ削減とビルド短縮のため基本的に除外し、Firebase側のインストールに任せる
   ※ autoExternals でpackage.jsonの dependencies と devDependencies を配列化する

export async function functionsPreset(opts: Options = {}) {
  return defineConfig({
    external: [ // <--------------------------------------------------------- 1
      ...autoExternals(),
      ...((opts.external ?? []) as NonNullable<Options["external"]>),
    ],
    format: opts.format ?? ["cjs"],
  });
}

functions/turbo.json

1. ルートの turbo.json を継承する
2. application等への依存を明示する

{
  "extends": ["//"], // <---------------------------------------------------- 1
  "tasks": {
    "build": {
      "dependsOn": ["@repo/application#build", "@repo/prisma#build"] // <---- 2
    }
  }
}

Turborepoは package.json の dependencies と devDependencies に記載された情報から依存関係を自動検知する。 今回の場合、 package.json でapplicationパッケージ等への依存を明記していないため、Turborepoには依存関係が認識されない。 この状態で turbo run build --filter=functions... を実行しても、applicationパッケージ等のビルドは行われない。 そこで turbo.json にapplicationパッケージ等への依存を明示することで、functionsのビルド前にapplicationパッケージ等のビルドを強要する。

packages/application

Firebaseを意識した特別な設定はなし。

application/src/index.ts

export class GetTransactionsUseCase {
  constructor(private readonly repo: TransactionRepository) {}

  execute(): ResultAsync<GetTransactionsResponse, Error> {
    return this.repo.findMany().map(toTransactionsResponse);
  }
}

application/package.json

1. src-firstにexportsを設定する
   ※ dist-firstでも問題はない

{
  "exports": {
    ".": "./src/index.ts" // <----------------------------------------------- 1
  },
}

packages/prisma

Firebaseを意識した特別な設定はなし。

prisma/schema/schema.prism

v16.16.0からrustエンジンの利用を避けられる（詳細はこちら）。 rustエンジンは往々にしてデプロイ関連でエラーを引き起こすため使用を避ける。

generator client {
  provider   = "prisma-client"
  output     = "../generated/prisma"
  engineType = "client"
}

prisma/src/index.ts

export class PrismaTransactionRepository implements TransactionRepository {
  findMany(): ResultAsync<Transaction[], Error> {
    return ResultAsync.fromPromise(
      prisma.transaction.findMany(),
      (e) =>
        newPrismaError({
          action: "FindTransactions",
          cause: e,
        }),
    ).andThen((rows) => Result.combine(rows.map(toEntity)));
  }
}

root

package.json

Firebaseを意識した特別な設定はなし。

{
  "scripts": {
    "build:functions": "turbo run build --filter=@o3osatoshi/functions...",
    "deploy:functions": "firebase deploy --only functions"
  }
}

turbo.json

Firebaseを意識した特別な設定はなし。

{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["$TURBO_DEFAULT$", ".env*"],
      "outputs": ["dist/**"]
    }
  }
}

firebase.json

1. rootからの相対パスでfunctionsを指定する
2. デプロイ前にfunctionsのビルド（ pnpm build:functions ）を実行する

{
  "functions": [
    {
      "source": "apps/functions", // <--------------------------------------- 1
      "predeploy": "pnpm build:functions" // <------------------------------- 2
    }
  ]
}

メリット・デメリット

メリット

• Firebaseの問題をfunctionsディレクトリ内で完結して解消している
  • applicationやrootの設定・コードに変更が不要（汚染されない）
• バンドルの設定がシンプル
  • 複雑な設定・構成を必要としない
• ソースコード（ functions/src/index.ts ）内でローカルパッケージをインポートできる
  • ローカルパッケージへのジャンプも機能し、開発体験を損なわない（その逆も可能）

デメリット

• 今のところ見つかっていない

※本ブログの目的と内容¹、著作者の方へ²

※本ブログは、YouTube動画（Claude Codeの開発効率を3倍に引き上げる7つの上級者向けTips）の視聴備忘録である

開発の進め方

1. 要件定義
   • はじめに init を実行
   • ヌケモレなく要件定義するために、AIにヒアリングさせる
     • 大枠の要望を記述した上で、「要件を詰めたいので、ヒアリングしてください」と追記する
   • ヒアリング結果は、要件定義書としてCLAUDE.mdに出力させておく
     • CLAUDE.md
       • 守ってほしいルールなどを一般的に記述する
       • 使用する技術のベストプラクティスも記載しておくと良い
       • モノレポ構成でアプリごとに配置することも可能
2. チケット分割
   • 要件定義書に基づいて必要な機能を洗い出させる
   • プロンプト例

     要件定義書を機能毎にチケット分割してください。/docs配下にお願いします。 マークダウンファイルを使用し、ファイル名に連番を振ってください。 各ファイルでTodo管理も行います。- []で終わったら- [x]を入れるようにCLAUDE.mdファイルに記載しておいてください。

3. チケットベースで開発を進めさせる

オプション Tips

• --dangerously-skip-permissions … 許可を求められない
• --resume … 過去の会話を遡れる
• --continue … 直近の会話から再開できる

hooks

• PreToolUse … 事前処理を指定できる
• PostToolUse … 事後処理を指定できる（prettierを実行するなど）
• Stop … すべての処理が完了したあとの処理を指定できる（通知など）

GitHub との連携

1. ghコマンドをインストールする
2. リポジトリを作成させる

   ghコマンドを使って、リポジトリを作成してください

3. issueを作成させる

   今のアプリで、実装すべきissueを作成してください

   • リポジトリ内でチケット管理しても良いし、GitHubのissueでチケット管理しても良い
   • Claude GitHub Actionsで、issueベースに開発を進めていくことも可能
     • /install-github-app で、Actionsがセットアップされる

MCP

外部サービスをAI経由で操作できる。

1. プロジェクトルートに .mcp.json を作成する
2. claude --mcp-config=.mcp.json で接続
3. playwrightでmcpのテスト

   手動テストをPlaywrightMCPを起動して行ってください。講座が閲覧できてるか確認したいです。

Tips

• mcp.so で人気なmcpを調べられる
• MCPify でMCPサーバの作成も可能

Agents

各専門領域に特化したエージェントを作成できる。 Nextjs専門のエージェントやバックエンド専門のエージェントなど。 エージェント毎にコンテキストが保持されるため、分野毎のコンテキストを汚染せずに済む。

1. Create new agent
2. Generate with Claude ※推奨設定から作成する場合
   • エージェントの内容を指示　※以下は公式推奨文

     User the code-reviewer subagent to check my recent changes

   • .claude/agents 配下にエージェント用mdが生成される

Tips

• 各分野用に調整されたmdを配布している人もいるので探してみると良い

カスタムスラッシュコマンド

1. .claude/commands ディレクトリを作成
2. xx.md でファイルを作成し、Claude Codeへの指示文を記載する
3. スラッシュで追加したコマンド xx が使用できるようになる

Tips

• Claude Codeにカスタムコマンドを作成させることも可能

※本ブログの目的と内容¹、著作者の方へ²

哲学

達人プログラマーは、眼の前の問題を考えるだけでなく、常にその問題をより大きなコンテキストで捉え、ものごとの大局を見据えようとする。

あなたの人生

あなたは自分自身の人生を生きている。あなたには現状を打開する力がある。 この業界には驚くほど多くの機会が横たわっている。積極的な行動に出て、機会をつかみ取る。

気質

開発者には主体性が必要。

• アーリーアダプター
  • 試すことが生きがい
• 研究好き
  • 疑問を感じやすい
• 批判的
  • 額面どおりに受け取らない
• 現実的
  • 本質の理解に務める
• 何でも屋

謙虚である

自らの無知や過ちを率直に認める。 すべての問題をベンダー、プログラミング言語、管理、同僚のせいにしてはいけない。 弁解の代わりに対策を提案する。

自負と偏見

他人のコードに対して敬意を払う。

我々は所有することによって誇りを持つべき。 「私はこれを記述した。そして、この仕事についてのすべての責任は私にある」と。 成果物には、品質の証明としてあなたの署名が入っているべき。

ユーザを喜ばせる

開発者としての我々の目標は、「ユーザを喜ばせる」こと。

ポートフォリオ

知識と経験は、最も重要な資産。

1. 定期的に投資する
   • 継続によって大きなものとなる
2. 多様化する
   • まず現在使っている技術の詳細を知る
   • 世界はどんどん変化する
3. リスクを管理する
   • 技術という卵をすべて１つのかごの中に入れない
4. 安値で買い、高値で売る
5. 見直しと再配分をする

ポートフォリを充実させる活動

• 毎年少なくとも言語を１つ学習する
• 月に１冊のペースで技術書を読む
• 技術書以外の書籍を読む
• 講習を受講する
• 近場のユーザグループに参加する
  • 孤独はあなたの経歴によって避けるべき
• 異なった環境に慣れ親しんでみる
  • Winのみで作業してきたのであれば、Linux環境に親しんでみる
• 最先端にとどまり続ける
  • ニュースやオンライン投稿に目を通す

継続は力なり

数多くの小さな進歩を継続して積み重ねる。 スキルを日々磨き、新たなツールとレパートリーを増やしていく。

開発手法

チーム

達人のチームは、10〜12人の小規模な構成になっている。 コードをエンドツーエンドで構築でき、インクリメンタルかつイテレーティブに開発できるチームを構成する。 チームメンバーに質問を投げかけると、すぐに答えが返ってくるようになっているべき。 品質は、チームメンバー全員が個々に貢献することによってのみ達成できる。

コンウェイの法則

開発しているプロダクトは、チームや組織の社会構造とコミュニケーション経路によって影響を受ける。

ソフトウェアのエントロピー

ソフトウェアも時間とともに無秩序になっていく。特に、プロジェクトの文化がソフトウェアの腐敗に大きな影響を与える。 ネガティブな考えには伝染性がある。放置は他のどのような要因よりも腐敗を「加速」させる。

十分によいソフトウェア

不可能なスケジュールを約束したり、納期に間に合わせるために基本的な技術面をおろそかにするのは、プロフェッショナルとしてあり得ない。

見積もり

直感的にものごとの大きさを判断する。 見積もりを始める前に必ず問題領域について考える。 タスク（作業）ごとに「楽観的時間」、「最確時間」、「悲観的時間」の３つの時間を見積もる。

万能な方策は存在しない

あらゆる方法論の良いところを抜き出し、利用できるように適合させる。 どんな状況にも適用できる万能の方策など存在しないため、普及している手法を１つ導入するだけでは済まない。

あるべき方法

ソフトウェアを構築する唯一の方法はインクリメンタルに進めていくこと。 エンドツーエンドの小さな機能を構築し、そこから作業を進めながら問題について学習していく。

アジャイルソフトウェア開発宣言

• プロセスやツールよりも個人と対話を
• 包括的なドキュメントよりも動くソフトウェアを
• 契約交渉よりも顧客との協調を
• 計画に従うことよりも変化への対応を

要件定義

落とし穴

要求とは通常、さまざまな仮定、誤解、政策の奥深くに埋められている。 自らが欲しているものを正確に認識している人などいない。 境界条件を探し出し、相談者に尋ねる。 要求はフィードバックループの中で学んでいく。 ユーザとともに働き、ユーザのように考える。 優れた要求は抽象的な記述からできあがっている。 要求とは「ニーズ」。 失敗プロジェクトの多くは、スコープの膨張が原因。 用語集を管理する。 プロジェクトの参加者は、全員、整合性を保証するためにこの用語集を使うべき。

不可能なパズルを解決する

ある制約は「絶対的なもの」であり、他のものは「単なる先入観」。

曳光弾

要求の段階で、システムの最終形態となるイメージを目に見えるかたちで、何度も提示する。 最大のリスクを洗い出し、開発の優先順位を付ける。 コードは最小限だが、最終的には商用で利用する。

目的

• アプリケーション全体がどのように連携するのかを知る
• アーキテクチャ上の骨格を開発者に提示する

メリット

• テスト用プラットフォームになる
  • 大々的な統合テストを実施するというビッグバン型の開発ではなく、毎日テストを実施できるようになる
• 進捗が明確になる
  • ユースケース単体で作業に取り組める

プロトタイプ

曳光弾の前に行う偵察、諜報活動。コードは破棄する。 コードではなく、学んだ教訓に勝ちがある。

設計

よい設計の本質

ETC原則 … Easier To Change（変更をしやすくする）

世の中の設計原則は、ETC原則を特殊化したもの。 ETCは「ルール」ではなく「価値」。 常に「簡単に変更できる」という究極の選択肢を採用する。 鍵は「疎結合」と「高凝集」。

DRY原則

DRY原則 … Don’t Repeat Yourself（繰り返しを避ける）

DRY原則は知恵や意図の二重化についての原則であり、 コードの二重化すべてが知識の二重化というわけではない。 あなたが行うべきことは、既にあるものを簡単に見つけ出して再利用できるようにして、 同じものを何度も作成しないような環境を構築すること。 コードの二重化は、構造に問題がある証拠。

開発者間で発生する二重化

さまざまなところで必要となり、明確に責務を分類できない機能やデータは、何度も実装されてしまう。 開発者間での活発かつ頻繁なコミュニケーションが奨励される。

直交性

直交性とは、独立性であり、結合度を表す。 片方を変更しても他方に影響を与えない場合、それらは直行している。 直行していないシステムは本質的に変更や制御が難しくなる。 自己完結したコンポーネント（「凝集度」の高いコンポーネント）を設計するべき。

メリット

• 変更が局所化され、開発期間とテスト期間が短縮される
• 再利用が促進される
• コンポーネントの組み合わせが容易になり、最小努力で多くの機能を手に入れられる

結合度の最小化

不必要な情報は他のモジュールに公開せず、また、他のモジュールの実装を当てにしない記述を心がける。 オブジェクトの状態を変更する必要があるのであれば、それをオブジェクト自身に行わせる。

あるモジュールがデータ構造を露出させる時、そのデータ構造を使用するすべてのコードが該当モジュールの実装と結合する。 そのため、オブジェクトの属性を読み書きする際には、可能な限りアクセッサー関数を使用する。

グローバル変数を避ける

グローバル変数の使用は、データを共有しているコンポーネント同士を結びつける。

テスト

直交性を念頭に置いた設計、実装されたシステムは、テストが簡単になる。 ユニットテストの記述自体が、直交性の興味深いテストになる。

並行性

• 並行処理
  • 同時に実行されているように振る舞うこと
  • ソフトウェアのメカニズム
• 並列処理
  • 本当に同時に実行されていること
  • ハードウェアの関心事

時間的な結合を破壊する

アーキテクチャの設計に取りかかったり、プログラムを書いたりする際には、ものごとは線形になりがち。 こういったアプローチでは柔軟性、現実性ともに乏しいものとなる。

アーキテクチャ

アーキテクチャーは移り変わる。流行を追い求めないようにする。 できることは変更を容易にすることだけ。抽象化レイヤーで隠蔽する。

コーディング

プログラムを長期間にわかって正確かつ生産的なものに保つには、熟考や熟慮を要する意思決定が常に必要。 達人プログラマーは自分自身のコードを含めたすべてのコードに対して常に批判的な目を向ける。 テストの主な利点は、テストについて考え、テストを作り出している時に生み出される。

契約による設計（DbC）

「コンポーネント間で”契約”を交わし、その契約を守る限りバグは起きにくい」という考え方。

function assert(cond: unknown, msg: string): asserts cond {
  if (!cond) throw new Error(`Contract violated: ${msg}`);
}

class BankAccount {
  private _bal: number;
  constructor(initial = 0) {
    // 前提条件チェック
    assert(initial >= 0, "initial ≥ 0");
    this._bal = initial;
    this.inv();
  }
  get balance() { return this._bal; }

  withdraw(amount: number) {
    // 前提条件チェック
    assert(amount > 0, "withdraw > 0");
    assert(this._bal >= amount, "sufficient funds");
    const before = this._bal;
    this._bal -= amount;
    // 後続条件チェック
    assert(this._bal === before - amount, "post: bal decreased");
    this.inv();
  }

  // 不変条件チェック
  private inv() { assert(this._bal >= 0, "balance non-negative"); }
}

インヘリタンス（相続）税

継承を使わない。

問題点

• コード共有のために使う
  • 結合を生む
• 型構築のために使う
  • 複雑さが増す

優れた代替

以下の代替によって、継承を使わなくて済むようになる。

• 委譲
  • 機能の追加ができる
  • has-a は is-a に勝る
    • has-a … A has a B AはBをプロパティとして持つ
    • is-a … AはBを継承する
• インターフェースとプロトコル
  • 型情報を共有できる
  • ポリモーフィズムを実現できる
• mixin と trait
  • 手段の共有ができる

変換のプログラミング

ある形式のデータや構造を別の形式に変換する処理を軸としたプログラミング手法。

const names = users.map(user => user.name);
const upper = text.toUpperCase();
const ids = data.filter(d => d.active).map(d => d.id);

メリット

• 副作用が少ない（元データを破壊しない）
• テストしやすい（入力と出力が明確）
• 可読性が高い（意図が明確）
• 再利用性・合成がしやすい（小さな関数の組み合わせで大きな処理）
• 非同期処理などとの相性が良い

分離

結合は変更の敵。 結合によって、離れた場所にある２つのものごとの整合性を常に取る必要が生み出され、 一方を変更した際に必ずもう一方も変更しなければならなくなる。

TDA原則（Tell, Don’t Ask）

「教えるな、命令せよ」という設計原則。

悪い例

if (account.getBalance() >= amount) {
  account.withdraw(amount);
}

良い例

account.withdrawIfPossible(amount);

キャッチ＆リリースは魚釣りだけに

早めにクラッシュさせる。多くの場合、プログラムのクラッシュは最も正しい行いとなる。

達人のコード利点

• エラーハンドリングがコードに埋もれない
• コードの結合度を下げる

凡人のコード

try {
    addScoreToBoard(score);
} catch (error) {
    if (error instanceof InvalidScoreError) {
        console.error("Can't add invalid score. Exiting");
        throw error;
    } else if (error instanceof BoardServerDownError) {
        console.error("Can't add score: board is down. Exiting");
        throw error;
    } else if (error instanceof StaleTransactionError) {
        console.error("Can't add score: stale transaction. Exiting");
        throw error;
    } else {
        throw error;
    }
}

達人のコード

addScoreToBoard(score);

アルゴリズムのスピード

単純なループを記述している場合であっても、それがO(n)アルゴリズムであるということを意識する。 アルゴリズムのオーダーを見積もること。

最善は常に最善ではない

アルゴリズムの改良は、それが本当にボトルネックになっていることを確認してから行うべき。

コードのためのテスト

テストは、コーディングの指針を与えてくれる極めて重要なフィードバック。 メソッドのテスト記述を考えることで、ユーザという観点に立ち、外部からメソッドを客観的に捉えられるようになる。

テスト文化

テストコードは本番のコードと同じくらい慎重に扱う。 結合を低く抑え、クリーンかつ堅牢にしておく。 テストがプログラミングの一部であることを忘れない。

達人のスターターキット

早めにテスト、何度もテスト、自動でテスト。 優れたプロジェクトでは「成果物のコードよりも多くのテストコード」が存在する。 コードのカバレッジではなく、状態のカバレッジをテストする。 バグが既存のテストの網の目をくぐり抜けたのであれば、次回はそれを捕まえることのできる新たなテストを追加する。

テスト駆動コーディング

とにかくTDDを実践する。

テストについて考えることで、

• コードの結合度が低下する（データベース接続を引き渡す等）
• 柔軟性が向上する（テスト対象のフィールド名をパラメータにする等）

契約に対するテスト

契約が遵守されていることを確認するテストケースを記述する。

プロパティベースのテスト

このテストでは、テスト時にランダムな値を生成する。 このテストでは、不変性と契約という観点からコードについて考えさせてくれる。

リファクタリング

いつリファクタリングを行うべきか？

「おかしなもの」に遭遇した時。

リファクタリングを避ける言い訳として、納期というプレッシャーがよく用いられる。 そういった理由でリファクタリングをやめてはいけない。 今リファクタリングすることをやめれば、将来問題が発生した際、 今以上に多くの依存関係を考慮しながら問題修復をするために大量の時間投資が必要になる。

早めにリファクタリングすること、そしてこまめにリファクタリングすること。

どのようにリファクタリングするか？

1. リファクタリングと機能の追加を同時に行わない
2. テストを用意する
3. 小さな単位に作業をまとめ、慎重に進める

偶発的プログラミング

その場しのぎでコードが構築されてしまうこと。または、本来意図しない形で「たまたま動いてしまうコード」を書いてしまうこと。 「とにかく今動いているんだから触らないほうがいい」と、簡単にこういった考え方に陥ってしまう。

暗黙の仮定

すべての段階で、人々は心の中に多くの仮定を置いて作業を進めている。 しっかりとした事実に基づいていない仮定は、すべてのプロジェクトにとって有害なものとなる。

ストループ効果

単語は最優先で処理される。 何かに名前を付ける場合、常に自らの意図を明確にする方法を探し求める。

リソースのバランス方法

ファイル参照をどこかに保持しておくのではなく、パラメータとして引き渡すようにする。

設定

変更する必要があると分かっているデータは、コードの外に出す。 外部に出した設定は、APIの裏側などに隠す。 設定の表現という詳細とコードを分離する。

セキュリティの基本原則

• 攻撃界面を最小化する
  • 複雑なコードは攻撃ベクターにつながる
    • シンプルで小さなコードが優れている
  • 出力データは攻撃ベクターとなる
    • むやみに情報を提供してはいけない
  • デバッグ情報は攻撃ベクターとなる
    • デバッギングを容易にするための情報は、ハッキングも容易にする
• 最小権限にする
• デフォルトをセキュアなものにする
• 機密データを暗号化する
• セキュリティアップデートを適用する

ツール

常に道具を増やすことを心がける。何をするにも常によりよい方法を探すように心がける。

• シェル
  • 慣れ親しむことで生産性が向上する
• パワーディット
  • 繰り返し作業に「もっとよい方法があるはずた」と考える
  • オートリピートを使わない
  • マウス・トラックパッドを使わない
• バージョン管理
  • すべてのものがバージョン管理されているようにする
• デバッグ
  • 常に問題の原因の根を見つけるように努力する
  • 緻密な観察を心がける
  • デバッグの戦略
    1. バグを再現する
    2. テストを失敗される
       • テスト作成によってソリューションが見えてくる
  • アプリがライブラリ・APIを正しく呼び出していないと考えたほうが一般的に正しい
    • バグがOSやサードパーティ製品内に内在する可能性もあるが、 そういった考えを最初に持つべきではない
• テキスト操作言語
  • データをプレーンテキストで保存し、これらの言語を使用して操作する

※本ブログの目的と内容¹、著作者の方へ²

達成の心理学

鉄人（大きな成功を収めた人たち）は、「やり抜く力（情熱・粘り強さ）」を持っている。

達成の方程式

努力は才能の2倍重要。努力によって才能はスキルになり、努力によってスキルが生きる。

• 才能 x 努力 = スキル
• スキル x 努力 = 達成

鉄人の神格化

常人の域をはるかに超えたパフォーマンスに圧倒され、それがすさまじい訓練と経験の積み重ねの成果であることが想像できないと、 なにも考えずにただ「生まれつき才能がある人」と決めつけてしまう。

目標のピラミッド

目標のピラミッドが全体としてひとつにまとまり、各目標が関連性をもって、整然と並んでいる状態が望ましい。 たったひとつの究極の目標があり、ほぼすべての行動がその目標達成に向けられている。

粘り強さ（必死に努力したり、挫折から立ち直ったり）よりも、情熱（長い間わき目もふらずに、同じ目標にずっと集中し続ける）の方がはるかに大変。 人間のどんなにとてつもない偉業も、実際は小さなことをたくさん積み重ねた結果。

• 重要度の高い目標 … 粘り強く努力を続ける（安易に妥協しない）
• 重要度の低い目標 … 臨機応変に態度を切り替える（ほかのやり方を試す）

目標達成法

1. 目標を25個書き出す
2. 重要な5つにマルをつける
3. 残りの20個には関わらない

「同じ目的」につながる目標を生かす。時間とエネルギーは限られている。

「やり抜く力」を伸ばす

大変な方法は独力（内側）でがんばること。ラクな方法は同調性（外側）を利用すること。 私たちがどんな人間になるかは、「遺伝子」と「経験」の相互作用によって決まる。

内側

1. 興味（初期）
   • 自分がいちばん楽しいと思うことを見つけ、それに取り組む（仕事にする）
     • 満足度と業績が高くなる
   • やりたいものが見つかるまでにはかなりの時間がかかる
     • 子どものころには早すぎてわからない
     • 内省ではなく、外界との交流で生まれる
   • 初心者のうちにあまり厳しくすると、せっかく芽生えた興味が台なしになってしまう
   • 興味を持続させるには、みずから積極的に掘り下げ、深めていく必要がある
     • 自分から積極的に行動することが大事
2. 練習（中期）
   • 意図的な練習を行う
     1. 高めの目標を設定する
     2. 集中して目標達成を目指す
        • フィードバックを求める
     3. 何度も繰り返して練習する
   • ひとりで練習する時間が多い人ほど、スキルの上達が早い
   • 小さな弱点の克服をこつこつと積み重ねていくことが、驚異的な熟練の境地に至る道
   • 時間の長さよりも「どんな練習をしているか」が重要
   • 「ルーティン（毎日同じ時間同じ場所）」として「意図的な練習」に取り組む
     • 大変なことをするのにルーティンにまさる手段はない
3. 目的（後期）
   • 「他の人々にとって重要な意味を持つ」と思うこと
   • 社会のことも考えて行動する人のほうが、長い目で見て成功する確率が高い
     • ただし「興味」がないと、大きな努力に結びつくことはない
   • レンガ職人の寓話
     1. レンガを積んでいる
        • 仕事（生きるために必要なこと）
     2. 教会をつくっている
        • キャリア（もっといい仕事に移るためのステップ）
     3. 歴史に残る大聖堂を造っている
        • 天職（人生でいちばん大切なもののひとつ）
   • 肩書よりも重要なのは、本人が自分の仕事をどう見なしているか
4. 希望
   • 成長思考 → 楽観的に考える → 逆境でも粘り強くがんばれる
   • 楽観主義者と悲観主義者（鉄人は楽観的）
     • 楽観主義者 … 苦しみは一時的で特定の原因があると考える
     • 悲観主義者 … 苦しみを変えようがない原因のせいにし、自分にはどうすることもできないと考える
   • 成長思考と固定思考（鉄人は成長思考）
     • 成長思考 … 努力すればきっとうまくできると信じる
     • 固定思考 … 挫折の経験を自分には能力がない証拠だと解釈する
   • 身近な大人の成長志向を子どもはまねる
   • 「逆境を乗り越えた経験（がんばればどうにかなった経験）」がレジリエンスを高める
     • 脳は「筋肉」のように鍛えられる

外側

賢明な育て方

賢明な育て方とは、支援は惜しまないが、要求は厳しい育て方のこと。 賢明な教師など、親以外にも「支援」と「自信」を与えてくれる人との出会いが重要。

親をまねる

子どもは親をお手本にし、やることをまねる。 親自身が「努力家で、なにかに挑戦するときは全力を尽くし、楽しみよりもやるべきことを優先させ、遠い目標に向かって努力する」姿を子どもに見せる。

「やり抜く力」が身につく4つの家庭ルール

1. ハードなことに挑戦しなければならない
   • 「ハードなこと」とは、「意図的な練習」のこと
2. やめてもよい
   • ただし区切りの時期がくるまではやめてはならない
   • 無理に続けても機会損失の可能性がある
3. 自分で選ぶ
4. 2年間は続けなければならない

適応の母

「やり抜く力」を強化するには、「やり抜く力」の強い文化を見つけ、その一員となる。 自分が属している文化の影響をあらゆる面で強く受ける。

「環境」が変わると、一瞬で自分が変わる。私たちは必要に迫られれば変化する。 慣れない状況のなかでがんばっていくうちに、やがて新しい考え方や行動が身について習慣となる。

社会的相乗効果

バスケがうまくなるコツは、自分よりややスキルの高い仲間と一緒にプレーすること。 なにかを本当にうまくなりたいと思ったら、自分の能力以上に背伸びする必要がある。

課外活動

学校の勉強以外に、楽しんで取り組めるような習いごとや活動を見つけて、かよわせる。 重要なのは、やろうと決めたことを、1年たってもやめずに翌年も続け、そのあいだに何らかの進捗を遂げること。 課外活動の継続年数は、大学の卒業率や就職率、収入の向上に影響を与える。

その他

• 成熟の原則 … ほとんどの人は人生経験を重ねるにつれ、より誠実になり、自信や思いやりが増し、穏やかになる
• 対応原則 … 人は自分の性格に適した状況に引き寄せられるが、その結果、さらにその特徴が強化される
• 学習性勤勉性 … 勤勉さは練習によって身につけられる
• グリット・スケールが高いと、幸福感や健康状態も良い
• ベテランが目新しいと感じるのは微妙な差異（ニュアンス）なのだ

※本ブログの目的と内容¹、著作者の方へ²

序論

時代は「御用聞き営業」から「仮説営業（顧客に会う前にニーズの仮説を準備する）」へと変化している。 営業としての成長とは、能動的に「型」の数を増やすこと。

「セールス重視」から「マーケティング重視」へ

「顧客をどう説得するか」より、「どの顧客を説得するか」の方がインパクトが大きい。

• 内勤営業（インサイドセールス） … アポ前
• 外勤営業（セールス） … アポ後

仮説営業に必要な力

1. 仮説思考力
   • 仮説思考とは、課題の原因を推論し、それを検証するマインドセットのこと
   • 妄想で終わらせず、実行に移して検証し続けることが重要
   • 顧客の課題（ニーズ）の特定で本領を発揮する
2. 因数分解力
   • できるだけ細かく分解する
   • 大きな数値目標は必ず分解する
     • 年間売上目標は、月単位などに分解する
   • コツ
     • プロセスで切る
     • 「量 x 質」で切る
     • MECEを意識する
     • やるべきことが明確になるまで分解を続ける
     • 課題を分解しても、解決策を分解してもいい
     • 分解できたと思ったら、さらに１段深堀りしてみる
3. 確率論的思考法
   • 営業は確率の世界
4. PDCAを回し続ける力
   • PDCAにおける計画（＝課題に対する解決策）はすべて仮説
   • サイクルを回して仮説が定説になったものが、営業が増やすべき「型」
   • PDCAでもっとも難しいことは、PDCAサイクル自体を続けること
     • 習慣づけるコツは、同時に多くのPDCAサイクルを回さないことと、大きな課題に取り組まないこと
   • ステップ
     1. ゴールを定量化する（KGIの設定）
        • あらゆるPDCAは、たどり着きたいゴールを決めることから始まる
        • ポイントは、期日、定量化、具体性
        • 定性的な目標であっても、それを数値化し、具体的に把握しやすい状態に置き換える
     2. 現状とのギャップを洗い出す
     3. ギャップを埋める課題を考える
     4. 課題を優先度づけして３つに絞る
        • タスクを同時に抱えすぎるとフォーカスポイントが曖昧になって成果が思うように出せなくなる
     5. 各課題をKPI化する
        • KPIは、ゴールに近づくための「サブゴール」
     6. KPIを達成する解決案を考える
     7. 解決案を優先度づけする

マーケティングプロセス

1. リスト選定・顧客の絞り込み
   • リスト選定にもPDCAが効く
     • 仮説を立てたらまずは小さく試す
   • 「もっといいリストはないか」と問い続ける
     • 最重要顧客のペルソナをひたすら考える
   • 「顧客はすでに課題への理解があるか否か」も重要な因子
2. 情報収集とニーズの仮説構築
   • ファーストコンタクトで自分のことを「ただの営業」だと思われるのか「使えそうな営業」だと思ってもらえるのかで、 天と地の差が生まれることをもっと意識すべき
   • 経営課題の仮説を立てるのは決して簡単なことではない
     • 企業の事業モデル、業界の動向等、自分が経営者になったつもりでありとあらゆる情報を持っていないといけない
3. アプローチ
   • 流れ作業でアプローチしていると思われないか、下心（営業色）を消せるかが勝負
   • 営業をかけるなら決済者をダイレクトに攻める
   • 受付突破率こそが営業プロセスの最大のボトルネック
   • 受付突破の２大パターン
     1. 自分と相手（経営者や決済者）との関係性を感じてもらう
     2. 提案と相手のニーズとの関係性を感じてもらう
4. 見込み顧客管理
   • 見込み顧客管理の目的
     • 時間効率の最大化
     • 適切なタイミングで機動的に提案しにいける
   • 中期・長期の顧客は、自分の手間をかけないで関係性を維持する
5. 面談
   • ニーズ喚起が重要
   • 相手の課題の遠からず近からずのところから始めて、いつの間にか本題に入る 流れを切らないことが重要
     • 「相手が話したいことで、なおかつ普段話せないこと」を話題に選ぶ
     • 孤独な経営者のよき相談相手になれるように努力を続ける
   • 信頼
     • 人間的信頼 … 感情
     • ビジネス的信頼 … 合理
   • 人間的信頼関係で大切なこと
     • 信頼されないことをしない
       • お互いの信頼関係は比例する
     • 相手との共通の話題や体験を持つ
       • 共通項を探す。共通項が多いほど人間的信頼関係は強くなる
     • 相手の価値観に共感する
       • 究極系は、その人の哲学や生き様に共感すること
6. プレゼン・検討
   • あくまでも「相手の課題を解決するためのプレゼン」であるべき
   • プレゼンの順番
     1. Whyの明確化（課題）
     2. Whatの明確化（ゴール）
     3. How・When・Whereの明確化（実行策）
   • 営業感のある言葉は使わない（相手が急速に冷める）
7. 紹介
   • 自分からわざわざ「紹介してください」と言わなくても、自分の強みを相手に印象づけることさえできれば、向こうから声がかかることが多い
     • 名刺交換のタイミングでは、自分は何ができるのか、何の専門家なのかということを１つや２つに絞って伝える
   • 経営者や富裕層のコミュニティでは、基本的に２人紹介したら最低１人は紹介されるというのが暗黙のルール
   • 優良顧客でなくても、「優良顧客の人脈を持っている人」なら、時間と手間をかける 業界に影響力を持っているような人をたった１人でも突破できれば、そこから横に広がっていく

その他

成長のための思考と行動

小さなことを積み重ねることが、とんでもないところに行くただひとつの道。 インプットとアウトプットを繰り返す。

分解とは思考を深堀りすること。 深堀りするからこそ、いままで気づかなかった課題が見え、課題が見えるから解決策をひねり出そうとなる。 絶えず問い続ける。

成長に繋がらないことに時間を割かない。 日々の振り返りに時間を割く。

日々の業務が、自分が本当に叶えたいと思っている目標につながっているのだということを絶えず意識することが、継続的な努力のコツ。

強い営業組織

「この目標を達成するためにはどう行動したらよいのか」と全員が考える。 本音を出しやすくする工夫としては、甘いものを持ち寄るなど、少しカジュアルな雰囲気を演出するといい。

ミッションやビジョンをどう社員に定着させればいいのかというと、基本はこれでおかというほどに言い続けて、言い続けて、言い続けること。

部下に「自走力」をつけてもらうことは育成の基本。

※本ブログの目的と内容¹、著作者の方へ²

ゴールデン・ブレインを育てる６つのサイクル

• 土台をつくる３つのサイクル（健康に育つための土台）
  • 睡眠
  • 食事
  • 運動
• 才能を育てる３つのサイクル（自ら考え判断して生きていく力）
  • 遊び
  • 読書
  • デジタルメディア

脳の初期発達に影響を及ぼす要素

• 極度のストレスや感染
• 安定した愛着と社会的支援
• 十分な栄養

睡眠

眠りは自分の中で起きること。 親の役割は子どもを寝かしつけるというより、よく眠れるための環境をつくること。

睡眠の重要な２つの機能

1. 老廃物をなくす
2. 記憶の強化

健康的な睡眠パターンをつくる７つのテクニック

1. 余裕を持って起きる
2. 日差しを浴びる
3. お昼寝をする
4. 眠くなる環境をつくる
   • 照明を落とし、テレビの音をなくす
5. １人になれる時間をつくる
   • 涼しいほうが熟睡できる
6. 規則的なリズムを守る
7. 睡眠リズムを見直す

食事

健康は食べ物で決まる。 どんな食べ物をどう食べるか、子どもがきちんと決められるようにすることも重要。 親が食べる量を決めたり、子どもの口に食べ物を入れてやったりするのではなく、 子ども自ら体の声を聞き、自分で食べ方を決められるように機会を与える。

脳の発達に必要な栄養素

1. タンパク質
   • 人体の正常な成長や維持に必要
2. 脂肪（長鎖多価不飽和脂肪酸）
   • 認知機能の発達に影響
3. 鉄分
   • 器官の機能や成長に影響
4. 亜鉛
   • 細胞分裂に必須
5. ビタミンB群
   • 認知機能を維持

砂糖は猛毒

砂糖は脳の機能を乱す。多動性のある子どもの食事には砂糖が多く含まれる。 シュガーハイ（砂糖で興奮する）で、子どもたちは集中できなくなる。 人工甘味料に注意する。

小児肥満は脳に悪影響

肥満は認知機能・学力を低下させる。 注意すべきは、テレビやスマホを見せながら子どもにごはんを食べさせること。 映像を見ながら食事をすると、満足のサインに鈍感になり、普段より多くのカロリーを接種してしまう。 体と脳が疎通しながら食事できるように、食事の時間には食事に集中できる環境をつくる。

感情的摂食に注意

感情的摂食（ネガティブな感情を解消するための食事）の原因は、退屈とストレス。 子どもの機嫌が悪いときに、親がなだめようとして食べ物を与える影響が大きい。 なだめるために食べ物（特に甘い食べ物）で気は引かず、親もストレス解消のために食べ物（特に甘い食べ物）に頼らない。

水を飲む

水分が不足すると、認知機能（記憶や集中力など）が低下し、疲労しやすくなる。 飲料よりも水を飲む習慣を育むべき。 家に水以外の飲料を買い置きせず、出かけるときには水筒を持つ。

母乳と粉ミルク

母乳は脳の発達によく、粉ミルクは成長速度を加速させる。

食事の悩み

大人には目に見えるものを口に入れて食べることが重要だが、子どもにとってはそうではないことを忘れないようにする。 食事の時間には五感を使って、料理がくれる経験に子どもがどっぷり浸かれるようにする。

薬事の悩み原因３選

1. 食事のスタイルが変わる
   • 液体を飲むだけだったのが、新たな質感の食べ物が口の中に入ってくる感覚的ショックを経験する
2. 遊びの面白さを知ってしまった
3. フードネオフォピア
   • 慣れない食べ物を避ける行動

偏食を受け入れる

子どもの口におかずを無理やり入れる行動は、子どもの自立に干渉してしまうため、よくない。 親が食べ物の量や種類に干渉すると、子どもは自分の体を理解し、適切な意思決定をする機会を奪われることになる。

野菜を食べない、新しいものを拒否する、お箸やスプーンを使わない、食事の時間に歩き回るなどの問題は、大きくなれば改善する。 楽しくてリラックスした雰囲気で食事する環境をつくることが、子どもには何よりの応援。

神経質になりすぎない

無理に料理をつくって疲れた親とごはんを食べるよりも、リラックスして楽しそうな親と仲良くピザを食べるほうがいい。

運動

跳ね回る子どもは賢い

子どもは動きながら学んでいる。 運動は脳の発達に大きな影響を及ぼし、学習や記憶になくてはならない。 運動している人は、老年期まで脳の健康を維持する。

長時間じっとしていることの問題点

肥満率が上昇し、体感（体を支える役割）が弱くなる。 未就学児童の場合、どれだけ運動したかではなく、どれだけ座っている時間を減らせたかが重要。

効果的な運動

歩くことと走ることだけは省かない。多用な筋肉を複雑に使う運動にも多くの利点が期待できる。 素足で歩くことは感覚や運動能力を育てる。

自然の中での運動が感覚を育む

自然環境は感覚能力を発達させる。 脳の発達について語るとき、私たちは認知的な機能を中心に考えがち。 体を動かすことや感覚を育てることも脳の重要な機能。

規則や制限なく自由に遊ぶことが子どもをいい子にする。 外に出て、自然の中で思いっきり走り回らせる。 間違いなく変化がある。

遊び

遊びは脳を育てる

遊びは脳を大きく複雑にする(育てる）。また、遊びを通じて生存に必要な技術を習得する。 楽しさをくれる身体活動はすべて遊び。

社会的な脳は遊びによってつくられる

１人で遊ぶときより誰かと一緒に遊ぶときのほうが、我慢すること（自己抑制）が多くなる。 友だちと遊ぶことは、してもいい行動としてはいけない行動を学ぶ最もいい機会。 親が追いかけながら「待ちなさい」「殴っちゃダメ」と叫ぶより、強力な力を持っている。

同じ遊びの繰り返し

子どもが同じ遊びを繰り返す理由は、その中に新しい喜びを感じ続けているから。 大人の目には同じように見える遊びも、実は少しずつ変化している。

遊びの４つの心得

1. 遊びの時間は奪わない
   • 遊びのポイントは無目的性
   • 遊びのために子どもに必要なのはおもちゃではなく、機会
2. 自分で決めて行動させてあげる
   • 重要なことは、遊びの自発性と自己主導性（自分が面白いと思う行動を選択する）
   • 自分で選択する行動が自分自身を理解することにつながる
3. おもちゃでは学べないことがある
   • 子どもは、自分の環境を見て、遊び道具を見つけて遊びをつくっている
   • 子どもは退屈しても平気。子どもの退屈を恐れて、親が何とかしてあげなくてもいい
   • 退屈という問題を解決する能力を育てて、その能力を自由に発揮できるとき、子どもは本当の自分を発見する
4. ストレスに耐える力を育てる
   • 遊びには、ポジティブな気分を高め、不安やストレスを克服する効果がある

読書

本を読むことの効果

本を読むことで、子どもの言語の発達を促し、表現力を優れさせ、共感能力を高める。 いいメッセージを込めた文章、世間に対して新設で、他の生命を尊重する気持ちのこもった文章を読むことで、私たちの視線は変化する。 いい本を読んで、他の人の立場を理解する能力が育った子どもは、世の中を愛するようになる。

読解力を育てる３つのカギ

どんな能力も遺伝的要因と環境的要因の相互作用によって育つ。

1. 手軽に本に出会えるようにする
   • 定期的に家の本をチェックし、子どもが関心のある本や、楽しく読める本が用意されているか点検する
2. 本を読む時間が必要
   • 子どもに本を読むには、子どもの時間より親の時間が重要
3. 親の文章読解力も重要
   • 「周囲の大人が『本を読むことを大事に考えている』と子どもが気がつくこと」が立派な環境をつくる重要な要素

デジタルメディア

デジタルメディアは害悪

デジタルメディアに触れる時間が増えるほど、子どもの言語の発達が遅延する。 親がデジタルメディアを利用しても、やはり子どもの言語の発達にはネガティブな影響がある。 デジタルメディアの利用により、子どもたちが失ったのは経験（親との会話）の機会。