2025-06-26

「エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ」の翻訳内容レビューに参加させていただきました。

今月 6/5に発売した「エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ」の翻訳内容のレビューに参加させていただき、先日書籍をご恵贈いただきました。

www.oreilly.co.jp

f:id:kakts:20250626000543j:image

内容としては、エンジニアリングマネージャーや、CTOなど、技術組織をマネジメントする役職や、それに準ずるリーダー職を円滑に進め、事業成功に導くための手法・考え方が網羅的にまとめられています。

私自身テックリード・エンジニアリングマネージャーとしてエンジニア組織でのリーダーシップを発揮する立場で日々組織や技術的な意思決定などでこうしたトピックについて考えを巡らせながら取り組んでおりますが、課題解決のヒントが散りばめられており、自ら翻訳内容をレビューしながら大変勉強となりました。

現時点でリーダー職でないかたでも、事業成長のためにより視座の高い考え方、悩みの対処法を学ぶことができる本であり、大変お勧めします。

「スタッフエンジニアの道」など、何度も読み返すほど質の高い本の翻訳レビューに関わらせていただき、訳者の島田浩二様には今回も感謝を申し上げます。

## 目次

本書への推薦の言葉
はじめに

1章　エンジニアリング統括責任者のポジションに就く
    1.1　なぜエンジニアリング統括責任者を目指すのか
    1.2　一点もの
    1.3　現在の会社でエンジニアリング統括責任者のポジションに就く
    1.4　別の会社でエンジニアリング統括責任者のポジションに就く
    1.5　面接プロセス
    1.6　契約交渉
    1.7　オファーを受ける決断
    1.8　ポジションを得られない
    1.9　まとめ

2章　最初の90日間
    2.1　まず何を学ぶべきか
    2.2　適切なシステム変更を行う
    2.3　最初の90日間の作業
    2.4　まとめ

3章　エンジニアリング戦略を立てる
    3.1　戦略の定義
    3.2　戦略例
    3.3　策定プロセス
    3.4　全社戦略が存在しない場合の対処法
    3.5　診断を確立する
    3.6　基本方針を確立する
    3.7　基本方針の視点の高さを保つ
    3.8　首尾一貫した行動を選ぶ
    3.9　戦略はボトムアップで立てるべきでは？
    3.10　まとめ

4章　計画の仕方
    4.1　標準的な計画プロセス
    4.2　計画の3つのフェーズ
    4.3　第1フェーズ：財務計画を立てる
    4.4　第2フェーズ：組織内のリソース配分を決定する
    4.5　第3フェーズ：ロードマップに合意する
    4.6　避けるべき落とし穴
    4.7　まとめ

5章　効果的なバリューを作る
    5.1　バリューはどんな問題を解決するか
    5.2　エンジニアリング組織はバリューを持つべきか
    5.3　効果的なバリューの条件
    5.4　エンジニアリングバリューとエンジニアリング戦略はどう違うか
    5.5　いつ、どのようにバリューを展開するか
    5.6　私が役に立ったと感じたバリュー
    5.7　まとめ

6章　エンジニアリング組織の測定
    6.1　自分のために測定する
    6.2　ステークホルダーのために測定する
    6.3　アプローチの順序
    6.4　アンチパターン
    6.5　まとめ

7章　M&Aへの参加
    7.1　複雑なインセンティブ
    7.2　同じ視点を持つ
    7.3　統合計画を策定する
    7.4　今すぐに異議を唱えよ。さもなくば永遠に沈黙せよ
    7.5　買収される
    7.6　まとめ

8章　リーダーシップスタイルの開発
    8.1　統括責任者に複数のリーダーシップスタイルが必要な理由
    8.2　ポリシーで導く
    8.3　コンセンサスで導く
    8.4　信念で導く
    8.5　リーダーシップスタイルの開発
    8.6　リーダーシップスタイルのバランスを取る
    8.7　まとめ

9章　優先順位とエネルギーの管理
    9.1　「会社、チーム、自分自身」フレームワーク
    9.2　エネルギーの管理はポジティブサム
    9.3　持続可能な互恵関係
    9.4　不整合の反射鏡
    9.5　直交はしているが対立はしていない
    9.6　柔軟性を保つ
    9.7　まとめ

10章　効果的なエンジニアリング組織のためのミーティング
    10.1　ミーティングが必要な理由
    10.2　必要不可欠な6つのミーティング
    10.3　他のミーティングについては？
    10.4　誰がミーティングを運営するか？
    10.5　ミーティングのスケーリング
    10.6　まとめ

11章　社内コミュニケーション
    11.1　随時発信を維持する
    11.2　ブロードキャストする前にテストする
    11.3　パケットを作る
    11.4　短くまとめる
    11.5　あらゆるチャンネルを使う
    11.6　まとめ

12章　個人と組織のプレゼンスを高める
    12.1　ブランドとプレゼンス
    12.2　プレゼンスを築くことはあなたにとって価値があるか？
    12.3　不定期の高品質コンテンツでプレゼンスを演出する
    12.4　プレゼンスの測定は地雷原
    12.5　まとめ

13章　CEO、統括責任者陣、エンジニアリング組織との協働
    13.1　あなたは支持されているか、容認されているか、それとも嫌われているか？
    13.2　暗黙のパワーダイナミクスをかじ取りする
    13.3　ナラティブの架け橋になる
    13.4　過去の経験にとらわれない
    13.5　団結する習慣を育てる
    13.6　変更を少数に絞り込む
    13.7　衝突はあっても良いが、未解決のままにしない
    13.8　同僚のパニックを切り抜ける
    13.9　まとめ

14章　エンジニアリング組織の幹部層を団結させる
    14.1　幹部層の分析と確立
    14.2　幹部層の運営
    14.3　幹部への期待
    14.4　幹部間の争い
    14.5　まとめ

15章　ネットワークの構築
    15.1　ネットワークの活用
    15.2　近道はあるか？
    15.3　ネットワークを構築する
    15.4　他の種類のネットワーク
    15.5　まとめ

16章　同格の統括責任者のオンボーディング
    16.1　同格の統括責任者のオンボーディングが重要な理由
    16.2　統括責任者のオンボーディングとエンジニアのオンボーディング
    16.3　メンタルフレームワークの共有
    16.4　役割を明確にする
    16.5　信頼は時間とともに育まれる
    16.6　どの程度の進歩が可能か
    16.7　まとめ

17章　検証を伴う信頼
    17.1　信頼による管理の限界
    17.2　信頼だけではマネジメント手法とは言えない
    17.3　検証を伴う信頼がより良い理由
    17.4　検証の道具
    17.5　組織に検証を取り入れる
    17.6　まとめ

18章　基準の調整
    18.1　基準のズレがもたらす危険
    18.2　組織の基準に合わせる
    18.3　慎重にエスカレーションする
    18.4　ロールモデルとして振る舞う
    18.5　基準の調整
    18.6　まとめ

19章　エンジニアリングプロセスの進め方
    19.1　プロセス運用の一般的な発展の過程
    19.2　パターンの長所と短所
    19.3　「ベースライン」パターンの運用
    19.4　予算編成の現実に対処する
    19.5　トレンドサイクルのかじ取り
    19.6　まとめ

20章　採用
    20.1　採用プロセスの確立
    20.2　完璧よりも効果的なものを狙う
    20.3　採用の進捗状況と問題点をモニタリングする
    20.4　重要な候補者のクロージングを支援する
    20.5　候補者をレベル付けする
    20.6　報酬の詳細を決定する
    20.7　採用の優先順位を管理する
    20.8　採用責任者をトレーニングする
    20.9　社内やネットワーク内から採用する
    20.10　採用で多様性を高める
    20.11　エンジニアリングブランドを構築する
    20.12　採用委員会を導入すべきか？
    20.13　システムはあなたをサポートするために存在する
    20.14　まとめ

21章　エンジニアリング組織でのオンボーディング
    21.1　現実世界の例
    21.2　オンボーディングの基礎
    21.3　オンボーディングプログラムが失敗する理由
    21.4　会社全体のオンボーディングとの統合
    21.5　オンボーディングを優先するタイミング
    21.6　まとめ

22章　パフォーマンスと報酬
    22.1　相反する目的
    22.2　パフォーマンスと昇進
    22.3　報酬
    22.4　どのくらいの頻度でサイクルを回すべきか
    22.5　完璧を追い求めない
    22.6　まとめ

23章　企業文化診断データの活用
    23.1　企業文化診断結果の読み方
    23.2　企業文化診断に基づいて行動を起こす
    23.3　企業文化診断に用いる質問を変更するタイミング
    23.4　いつ始めるべきか、どのくらいの頻度で実施すべきか
    23.5　まとめ

24章　エンジニアリング統括責任者のポジションを離れる
    24.1　辞める前の引き継ぎ計画
    24.2　去就を決める
    24.3　在任期間の短さをどう考えるか
    24.4　次の職を得てから退職するか、それとも得ずに退職するか
    24.5　CEOに伝える
    24.6　退職パッケージの交渉
    24.7　コミュニケーション計画の確立
    24.8　引き継ぎと実際の退社
    24.9　決断の再検討
    24.10　まとめ

25章　結び

付録A　追加のリソース

付録B　エンジニアリング統括責任者の面接

付録C　損益計算書の読み方

付録D　エンジニアリングハブの立ち上げ

付録E　探索の重大さ

参考文献
訳者あとがき
索引

コラム目次
    学びはふりかえりを通してのみ得られる
    時間とエネルギーを管理する
    エンジニアリングコストの資産計上方法
    ベンダー契約の更新
    計画のタイムライン
    データに対する信頼を築く
    エンジニアリング評価テンプレートの推奨トピック
    統括責任者が意欲を失う理由
    核心を抽出する
    対外的なコミュニケーションについて考える
    このアドバイスに従っている人はいるか？
    エスカレーションプロセスの体系化
    エグゼクティブアシスタントとのパートナーシップ
    未経験の職務を管理する
    企業文化診断に関するインタビュー
    目の前の問題から目をそらす

2025-06-18

terraform plan -generate-config-outでのimport結果がファイル生成されない場合の原因

Terraform Terraform

Terraform管理外のインフラリソースをTerraform管理したい

Terraformでのインフラ構成の管理において、Terraform管理外ですでに作られているリソースをTerraform管理かにおきたい場合、Terraform importの機能を使えば管理下におくことができます。

Terraform管理下におく方法

Terraform 管理下におく、つまり既存のリソースをtfstateに記録する方法は大きく分けて2つあります。

terraform import でリソースを指定して、import
- この場合は terraform importを実行した場合、tfstateに指定したリソースの情報が記録されます。
importブロックを指定して、terraform plan -generate-config-out="generated.tf" を実行して、管理外のリソースを-generate-config-outオプションで指定したファイルに出力する
- これにより、tfstateにリソースの情報が記録されるとともに、-generate-config-outに指定したファイルにimportしたリソースの設定が出力されます。これを元に値を修正して利用することができます。

terraform plan -generate-config-outでimport内容が生成されない場合

ここで、2番目の terraform plan -generate-config-out を実行した際に、何もplan結果は実行されるがファイルに出力されない場合があります。

この要因として、importの作業とかですでに指定のリソースがtfstateに記録されている、つまりTerraform管理になっている場合が考えられます。

原因調査方法

terraformコマンド実行におけるトラブルシューティングは、まずはログレベルの変更から試します。 terraformの実行時のログレベルをDEBUGにすることで、ファイルの生成処理の状況を確認できます。

シェルでの例ですが、TF_LOGという環境変数に DEBUGを指定して実行します。

TF_LOG=DEBUG terraform plan -generate-config-out=generate.tf

こうすると、terraform実行時にデバッグログが出力されます。

2025-06-18T14:09:41.516Z [DEBUG] expandResourceImports: skipping import address aws_cloudfront_distribution.test-dist already in state

今回の例だと、容器のようにすでにtfstateに指定のリソースが記録されていたためスキップされていることがわかります。

importの生成ファイルのスキップ処理の実装について

上記のログの出力箇所について調べてみました。
terraform v1.12.2において、以下の処理でファイル生成がスキップされていることがわかります。

github.com

    // filter out any known import which already exist in state
    for _, el := range knownImports.Elements() {
        if state.ResourceInstance(el.Key) != nil {
            log.Printf("[DEBUG] expandResourceImports: skipping import address %s already in state", el.Key)
            knownImports.Remove(el.Key)
        }
    }

先ほど説明した通り、importブロックを解析してファイル出力する処理において、すでにimportされているかをチェックして、それに含まれていたら出力をスキップしていることがわかります。

2025-03-18

GitHubの Third-party ActionのコミットSHA指定と、dependabotによるコミットSHAの更新

GitHub

概要

GitHub Actionsでファイルの変更差分を取得するためのサードパーティツールであるtj-actions/changed-files でのコミットの侵害により、Actionsのシークレットの内容をactionsの実行時に出力されてしまうというインシデントがありました。

www.stepsecurity.io

その際に、actionsのGitタグも書き換えられてしまい、そのためこのactionをタグ指定で使っているリポジトリは、この侵害の影響がありました。

対策の一つとして、このactionsのバージョンの指定をタグで指定せず、コミットSHAで指定する方法が推奨されており、その方法と、なぜタグ指定が良くないかについて整理します。
また、Gitリポジトリのツールなどのバージョン更新を行ってくれるdependabotの運用において、コミットSHAでの指定での自動更新をするやり方についてもまとめます。

GitHub Actionsにおけるセキュリティ対策

GitHub ActionsにおけるThird-party actionsを使用する際のセキュリティ対策として、GitHub公式のドキュメントとしてまとめられています。

docs.github.com

actionをフルレングスのコミットSHAで指定する
actionのソースコードを監査する
開発者がそのThird-party actionの作者を信頼している時のみタグを指定する

この3つが挙げられてますが、1つ目が重要です。

今回のtj-actions/changed-filesでのタグ侵害について

タグを指定した場合になぜ影響があるかを今回の例で説明します。

上述したStepSecurityでの記事によると、既存のタグが参照するコミットSHAが、悪意のあるコミットを指すように更新されていました。
これによりタグを指定した場合に悪意のあるコードが実行されることとなります。

$ git tag -l | while read -r tag ; do git show --format="$tag: %H" --no-patch $tag ; done | sort -k2
v1.0.0: 0e58ed8671d6b60d0890c21b07f8835ace038e67
...
v35.7.7-sec: 0e58ed8671d6b60d0890c21b07f8835ace038e67
...
v44.5.1: 0e58ed8671d6b60d0890c21b07f8835ace038e67
...
v5: 0e58ed8671d6b60d0890c21b07f8835ace038e67
...

git tagのそもそも

git tagについて改めて整理します。

git-scm.com

git tagは、git リポジトリの特定のコミットに対して参照するための名前をつける際に使われます。下記のように指定したタグの情報を確認できますが、タグに対してcommit 項目で紐づいているコミットSHAが確認できます。

$ git show v1.4
tag v1.4
Tagger: Ben Straub <[email protected]>
Date:   Sat May 3 20:19:12 2014 -0700

my version 1.4

commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <[email protected]>
Date:   Mon Mar 17 21:52:11 2008 -0700

    changed the version number

そして、一度作成したタグに対しては、あとからまたタグを付け直すことが可能です。

$ git tag -a v1.2 9fceb02

$ git show v1.2
tag v1.2
Tagger: Scott Chacon <[email protected]>
Date:   Mon Feb 9 15:32:16 2009 -0800

version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <[email protected]>
Date:   Sun Apr 27 20:43:35 2008 -0700

    updated rakefile
...

こうすることで、既存のタグに対しても、特定のコミットSHAを参照させることが可能になるため Third-party Actionをタグで指定した際には今回のような事象が発生するため、明確にコミットSHAを指定するのが重要です。

actionsのバージョンをコミットSHAで指定する

このコミットSHAをバージョンとして指定するには、 ${actionName}@${commitSHA} で指定します。

仮に、actions/setup-dummyのタグv2.0.0 に紐づいているコミットSHA: abcd....123456789を使いたいとすると下記のようになります。

steps:
  - uses: actions/[email protected]

これで、指定したactionをコミットSHAで指定することができます。

dependabotによるコミットハッシュでのバージョン指定

dependabotによって、上記のactionを自動で更新するには、#を使って指定した形式でタグ名も指定するとdependabotによってタグとコミットSHAを判定でき、自動更新ができます。

${actionName}@${commitSHA} # ${tag} という形式でコミットSHAの後ろに#とタグ名を指定するtだけで可能です。

steps:
  - uses: actions/[email protected] # v2.0.0

これでdependabotによる書き換え対象となります。

kakts-log

技術・エンジニアリング組織などについて調べたことをまとめます