【テックリード】テックリードへの道：タスクが「動かない」時に見直したいソフトスキルの話
はじめに
シニアエンジニアやテックリードを意識し始めると、自分でコードを書くこと以上に「チームやプロジェクトをどう動かすか」という課題に直面することが増えてきます。
先日、社内のエンジニアリングマネージャー（EM）に壁打ちをさせてもらった際、自分の中での「もやもや」が整理されたので、同じような立場にいる方に向けて共有したいと思います。
「重要かつ緊急」なのにタスクが進まない
アイゼンハワー・マトリクスで「重要かつ緊急（第1領域）」と定義したはずのタスク。
「これをやらないとシステムの土台が保てない」という危機感もあり、PdMやエンジニアとも目的・背景の読み合わせは済んでいる。ゴールも示している。
それなのに、なぜか思うように進まない。そんな状況に陥っていました。
なぜタスクが「依頼」で止まってしまうのか
自己分析をしてみると、いくつかの要因が見えてきました。
1. 依頼（指示）の「強度」と「形式」
Slackで依頼はしているものの、「投げっぱなし」になっていないか？
定例ミーティングなどで顔を合わせて、「これが最優先事項です」と改めて熱量を持って伝えるプロセスが欠けていたかもしれません。
2. 「具体的」か「抽象的」か
相手側で、「具体的にどう手をつければいいか」がイメージできていない可能性に気づきました。
既存の対応に追われている中で、抽象的な「重要事項」が投げられても、とっつきにくいのは当然です。
3. リソース配分の調整不足
「リソースが足りない」のは常ですが、PdMと握って「優先度の低いものを後回しにする」という合意形成を、徹底できていたか。
自分が手を動かさない、という「覚悟」
ここで一番の葛藤は、 「自分でやったほうが早い」という誘惑 です。
しかし、自分が動けば他のマネジメントや全体設計が止まってしまう。
「自分ではなるべくやらない」と決めること。 これは一見、怠慢のように見えて、実はチームを回すための「マネジメント」そのものなんだと実感しました。
シニア以上に求められる「ソフトスキル」の正体
今回の経験を通じて、シニアエンジニア以上に求められるスキルの輪郭が見えてきました。
- 合意形成の技術：チームやステークホルダーと「いつまでに」「何を」「どの優先度で」やるかを握る。
- タスクの細分化：相手が「とっつきやすい」レベルまで解像度を下げてあげる。
- AIの活用：これも一種のソフトスキル。思考の整理や、タスク分解の壁打ち相手としてAIを使い倒す。
結局、技術的な正解を知っているだけでは不十分で、それをいかに「組織の動き」に変換できるかが勝負なのだと思います。
今後のアクション：解決に向けて
今回の壁打ちを経て、以下の3点を徹底しようと考えています。
- PdMとの再握り：全体のタスクリストに明確に入れ込み、優先順位の合意を再確認する。
- 期限（いつまで）の明確化：自分が考えている期限と相手が考えている（または気にしていない）期限の認識を合わせる。
- タスクの細分化（解像度アップ）：相手が迷わず一歩目を踏み出せるレベルまで、タスクを噛み砕く。
おわりに
「マネジメントっぽい動き」に戸惑いを感じることもありますが、これもエンジニアとしての市場価値を高める重要なソフトスキルの一環です。
同じような悩みを持つテックリード候補の読者に少しでもためになれば嬉しいです。
【参加レポート】TechLead Conference 2026 〜AI時代のエンジニアリングを再定義する〜
はじめに
2026年4月23日に開催された「TechLead Conference 2026」に参加してきました。
AIエージェントの普及が加速する中、私たちのエンジニアリング原則や組織のあり方がどう「進化」すべきか、主要なセッションの内容をメモ書きしたものをまとめた。
1. AI時代のエンジニアリング原則：変わるもの・変わらないもの
AIがコードを書くことが当たり前になった今、開発ライフサイクルは「終焉」ではなく「進化」の過程にある。
内部品質のパワーバランスの変化
- 変わらないこと: 理解容易性やモジュール性の重要性は不変。むしろ、AIと人間が共存する上でこれまで以上に重要になる。
- 変わること: 変更容易性の定義が変わります。人間よりも許容範囲が広いエージェントが変更を担うため、「読むのは人間、変更はAI」という新たなバランスをテックリードが采配する必要がある。
TDD（テスト駆動開発）の再評価
- AIエージェントは迷走しやすいため、動的検査であるテストは強力なガードレールとなる。
- 「テストファーストでエージェントに指示を出す」伴走モードや、リアルタイムに介入する同期モードなど、エージェントとのペアプログラミング的な関わり方が主流となる。
アンラーニングの必要性
- 「人間がソフトウェアをメンテナンスする」という前提の一部を捨て、AIをアンプリファイ（増幅器）として活用するマインドセットへの転換が求めらる。
2. APIガバナンス：AIを制御する「門番」の役割
AIエージェントが自律的に行動する時代、API管理は不要になるどころか、その重要性は指数関数的に増大している。
- リスクの正体: OWASP Top 10 for Agentic Applicationsでは、ツールの不正利用（ASI02）や権限の濫用（ASI03）が挙げられる。
- セマンティックバリデーション: 従来の「型チェック」から、AIや専用ゲートウェイによる 「意味のチェック（ビジネスルールに反していないか）」 へと進化させる必要がある。
- シフトレフト・ガバナンス: 後工程になるほど対応コストは増大します。設計・実装時からAPI設計図を活用し、Agent in the loopによる事前テストを行うことが推奨される。
3. シニア・新人それぞれの学習とキャリア
t_wadaさんのセッションを中心に、AI時代に求められるスキルについて。
| 対象 | 意識すべきポイント |
|---|---|
| 共通 | プログラミング能力は「外注できない能力」として学び続けるべき。コードが読めなければAIの回答の正誤を判断できない。 |
| シニア | 広く浅い知識でAIとの「壁打ち」を可能にしつつ、いくつかの深い専門性を持つことでAIの誤りを見抜く。 |
| 新人 | 焦らず、AIと二人三脚ですべての工程を体験する。効率よりも「学びの強度」を優先し、基礎を固める時期とする。 |
- チームプログラミングへの移行: 1人のシニアがレビューのボトルネックになるのを防ぐため、数人でエージェントの出力を確認し、即断即決する「多対多」の開発スタイルへ移行していく兆しがある。
4. テックリードが今すぐ取り組むべきこと
AI活用の定着に向けた具体的なアクション。
- 「戻れなくなる便利さ」を構築する: CI/CDが当たり前になったように、AIがプルリクエストを自動作成するなど、新しい働き方に標準を合わせたフォーマットを作ること。
- 具体と抽象の往復: AIに質の高い指示を出すためには、人間側が具体的な事象を想像し、抽象化して伝える能力が不可欠です。
- 情報のオープン化: AIがプロジェクトのすべてを把握できるよう、一次情報を管理ソフト等に集約し、検索可能な状態に整理しておくことが重要です。
5. 所感
「AI時代は基礎が不要になる」という誤解がありますが、実際には 「基礎がある人ほどAIを増幅器として使いこなせる」という格差が広がる時代だと強く感じた。
特に、APIを単なるエンドポイントではなく「知的なフィルター」として再定義する考え方は、今後の業務においても積極的に取り入れていきたいポイントである。
【Datadog】不要なログを取り込む前に除外する
課題
Log Pipelineに合わないログなどがあった際に取り込む前に除外したいパターンがありました。
そのやり方がわからず調査しました。
解決方法
Log Index の Exclusion Filter を使用する
Datadog の Log Management では、特定のログをインデックスから除外するために Exclusion Filter を使うとのこと。
Logs > Pipelines との違い
| 方法 | 用途 |
|---|---|
| Exclusion Filter | ログをインデックスから完全除外（コスト削減） |
| Pipeline Processor | ログの属性加工・パース（除外には不向き） |
ログを単純に見たくない・保存したくない場合は Exclusion Filter が最適ということです。
