<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>実践テクニック アーカイブ - ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ</title>
	<atom:link href="https://atueda.com/tag/%e5%ae%9f%e8%b7%b5%e3%83%86%e3%82%af%e3%83%8b%e3%83%83%e3%82%af/feed/" rel="self" type="application/rss+xml" />
	<link>https://atueda.com/tag/実践テクニック/</link>
	<description></description>
	<lastBuildDate>Tue, 18 Aug 2026 04:30:05 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0.4</generator>

<image>
	<url>https://i0.wp.com/atueda-com-2025.s3.ap-northeast-1.amazonaws.com/wp-content/uploads/2025/11/22185004/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88-2025-11-12-10.23.00.png?fit=32%2C27&#038;ssl=1</url>
	<title>実践テクニック アーカイブ - ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ</title>
	<link>https://atueda.com/tag/実践テクニック/</link>
	<width>32</width>
	<height>32</height>
</image> 
<site xmlns="com-wordpress:feed-additions:1">250220958</site>	<item>
		<title>年俸交渉で多動性を強みに変える実践テクニックと事例解説（チェックリスト付き）</title>
		<link>https://atueda.com/%e5%b9%b4%e4%bf%b8%e4%ba%a4%e6%b8%89%e3%81%a7%e5%a4%9a%e5%8b%95%e6%80%a7%e3%82%92%e5%bc%b7%e3%81%bf%e3%81%ab%e5%a4%89%e3%81%88%e3%82%8b%e5%ae%9f%e8%b7%b5%e3%83%86%e3%82%af%e3%83%8b%e3%83%83%e3%82%af/</link>
					<comments>https://atueda.com/%e5%b9%b4%e4%bf%b8%e4%ba%a4%e6%b8%89%e3%81%a7%e5%a4%9a%e5%8b%95%e6%80%a7%e3%82%92%e5%bc%b7%e3%81%bf%e3%81%ab%e5%a4%89%e3%81%88%e3%82%8b%e5%ae%9f%e8%b7%b5%e3%83%86%e3%82%af%e3%83%8b%e3%83%83%e3%82%af/#respond</comments>
		
		<dc:creator><![CDATA[植田篤]]></dc:creator>
		<pubDate>Tue, 18 Aug 2026 04:30:00 +0000</pubDate>
				<category><![CDATA[ADHD]]></category>
		<category><![CDATA[エンジニア視点]]></category>
		<category><![CDATA[チェックリスト]]></category>
		<category><![CDATA[プロトタイピング]]></category>
		<category><![CDATA[多動性]]></category>
		<category><![CDATA[実績提示]]></category>
		<category><![CDATA[実践テクニック]]></category>
		<category><![CDATA[年俸交渉]]></category>
		<category><![CDATA[年俸交渉で多動性を活かす]]></category>
		<guid isPermaLink="false">https://atueda.com/?p=2118</guid>

					<description><![CDATA[<p>年俸交渉で多動性を活かす実践テクニックと事例、チェックリストでエンジニアが短期プロトタイプで評価額を引き上げた具体手順を示します。交渉前に使えるチェックリスト付き。</p>
<p>投稿 <a href="https://atueda.com/%e5%b9%b4%e4%bf%b8%e4%ba%a4%e6%b8%89%e3%81%a7%e5%a4%9a%e5%8b%95%e6%80%a7%e3%82%92%e5%bc%b7%e3%81%bf%e3%81%ab%e5%a4%89%e3%81%88%e3%82%8b%e5%ae%9f%e8%b7%b5%e3%83%86%e3%82%af%e3%83%8b%e3%83%83%e3%82%af/">年俸交渉で多動性を強みに変える実践テクニックと事例解説（チェックリスト付き）</a> は <a href="https://atueda.com">ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ</a> に最初に表示されました。</p>
]]></description>
										<content:encoded><![CDATA[<div class="veu_autoEyeCatchBox"><img data-recalc-dims="1" fetchpriority="high" decoding="async" width="1024" height="572" src="https://i0.wp.com/atueda-com-2025.s3.ap-northeast-1.amazonaws.com/wp-content/uploads/2026/08/18132908/d80b65e8-a22b-4b13-be13-23964d2c0120.jpeg?resize=1024%2C572&#038;ssl=1" class="attachment-large size-large wp-post-image" alt="" /></div>
<h1>年俸交渉で「多動性」をポジティブにアピールする技術</h1>
<p>結論：多動性（ADHDの「多動性・衝動性」傾向）は、年俸交渉では「高い実行力・短納期での価値創出」として具体的成果とリスク緩和策を示せば大きな交渉材料になります。要は「エネルギーを成果に変換できるか」を証拠で示すことが鍵です。</p>
<p>私は開発チームで短期のプロトタイプを大量に出して方針決定を促し、結果的に評価金額を改善した経験があります。本記事ではその実例と共に、エンジニア視点で使える具体テクニック、メリット・デメリット、実行の判断基準を整理します。</p>

  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-1"><label class="toc-title" for="toc-checkbox-1">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"></li><li><a href="#toc1" tabindex="0">要点まとめ</a></li><li><a href="#toc2" tabindex="0">多動性とは何か（定義とエンジニア視点）</a></li><li><a href="#toc3" tabindex="0">年俸交渉で使える具体テクニック</a><ol><li><a href="#toc4" tabindex="0">1. 成果を定量化して「高速実行力」を示す</a></li><li><a href="#toc5" tabindex="0">2. リスクを先回りして対策を提示する</a></li><li><a href="#toc6" tabindex="0">3. ハイパーフォーカスを証拠化する</a></li><li><a href="#toc7" tabindex="0">4. 交渉フレームを設計する（提案型交渉）</a></li></ol></li><li><a href="#toc8" tabindex="0">メリット</a></li><li><a href="#toc9" tabindex="0">デメリット</a></li><li><a href="#toc10" tabindex="0">向いている人</a></li><li><a href="#toc11" tabindex="0">向いていない人</a></li><li><a href="#toc12" tabindex="0">比較：伝え方の選択基準</a></li><li><a href="#toc13" tabindex="0">チェックポイント</a></li><li><a href="#toc14" tabindex="0">行動のポイント</a></li><li><a href="#toc15" tabindex="0">結論と次の一手</a></li><li><a href="#toc16" tabindex="0">よくある質問</a><ol><li><a href="#toc17" tabindex="0">Q. 多動性を正直に言うべきですか？</a></li><li><a href="#toc18" tabindex="0">Q. 証拠が少ない場合はどうしますか？</a></li><li><a href="#toc19" tabindex="0">Q. チームに嫌われない伝え方はありますか？</a></li><li><a href="#toc20" tabindex="0">Q. フルタイムとフリーランスでアピール方法は違いますか？</a></li><li><a href="#toc21" tabindex="0">Q. 交渉時の具体的な希望レンジはどう決めるべきですか？</a></li></ol></li></ol>
    </div>
  </div>

<h2><span id="toc1">要点まとめ</span></h2>
<p>まず交渉で伝えるべき核は次の点です。以下の項目は交渉前に簡潔にまとめておくと効果的です。</p>
<ul>
<li>多動性＝高頻度の試行と短いサイクルで価値検証する能力であること</li>
<li>過去の成果を定量化して「継続的な価値創出」として提示すること</li>
<li>リスク（集中力ブレや納期不安）への具体的対策を用意すること</li>
<li>役割と報酬のミスマッチを回避するため、期待値を明確にすること</li>
</ul>
<p>上の要点は、交渉の冒頭で口頭または資料で示せる短い箇条書きにしておくと説得力が上がります。以降は各ポイントをエンジニア向けの具体例とともに掘り下げます。</p>
<h2><span id="toc2">多動性とは何か（定義とエンジニア視点）</span></h2>
<p>多動性は「じっとしていられない」「衝動的に行動する」といった特性を指しますが、職場では「試行回数が多く、短期間で手を動かして検証する力」として説明できます。要するにPDS（Plan-Do-Study）のDoを高頻度で回す能力です。</p>
<p>例：短納期プロトタイプを5日で3案提示し、そのうち1案がプロダクト化に繋がった事例。これは多動性があったからこそ可能になった結果です。</p>
<h2><span id="toc3">年俸交渉で使える具体テクニック</span></h2>
<p>以下は現場のエンジニアがすぐに使えるテクニック集です。各節に現場例を付けています。</p>
<h3><span id="toc4">1. 成果を定量化して「高速実行力」を示す</span></h3>
<p>数字が説得力を持ちます。コミットした機能数、バグ修正速度、リリースサイクル短縮の貢献などを用意します。例えば「昨年度、私のイテレーションで機能Aを2週間→3日でプロトタイプ化し、投入後3ヶ月で利用率20%向上、売上に××万円貢献」といった具体値です。</p>
<p>エンジニア例：CI/CDパイプラインの改善でデプロイ時間を70%短縮し、デイリーデプロイが可能になったことをKPIで示す。</p>
<p>なぜ効くか：多動性は「速く試す」能力に直結するため、速度と成果が紐づくとポジティブに評価されます。</p>
<h3><span id="toc5">2. リスクを先回りして対策を提示する</span></h3>
<p>多動性が懸念される点（計画変更や忘却、品質低下）を自分から挙げ、具体的な緩和策を示します。例：ペアプログラミングやコードレビューを週2回入れる、タスクを細分化してチケット駆動で管理する、アラートやドキュメントを作る、など。</p>
<p>エンジニア例：衝動的な実装で発生した仕様逸脱を防ぐため、設計レビューのチェックリストを導入し、逸脱率を削減した実績を提示する。</p>
<p>なぜ効くか：雇用側は「不確実性」を嫌うため、予測可能性を高められることを示すと信頼度が上がります。</p>
<h3><span id="toc6">3. ハイパーフォーカスを証拠化する</span></h3>
<p>多動性の裏返しとして現れる「ハイパーフォーカス」は大きな武器です。長時間没頭して高品質なアウトプットを出した事例（バグを根本解決した、難問のプロファイリングでパフォーマンスを改善した）を用意しましょう。</p>
<p>エンジニア例：数日間のハイパーフォーカスでCPUボトルネックを突き止め、レスポンスを50%改善した報告書やコミット履歴を提示。</p>
<p>なぜ効くか：集中の深さを示せば「散発的な多動」ではなく「必要時に深く取り組める人材」として評価されます。</p>
<h3><span id="toc7">4. 交渉フレームを設計する（提案型交渉）</span></h3>
<p>年俸の単純な金額交渉ではなく、条件で勝負する方法を用意します。例えば、目標連動のボーナス、短期評価での昇給トリガー、リモート可否やフレックスなど非金銭条件の組合せです。</p>
<p>エンジニア例：KPI達成で追加報酬、プロジェクト成功時のストック付与、オンコール頻度を下げる代わりに基本給を調整する提案。</p>
<p>なぜ効くか：衝動的に高額を要求するのではなく、成果と報酬を紐づけることで受け入れやすくなります。</p>
<h2><span id="toc8">メリット</span></h2>
<p>ここでは多動性をポジティブに訴えることの利点を説明します。エンジニア職で特に価値が出やすい点を挙げます。</p>
<ul>
<li>短期間で多くの仮説検証ができるためプロダクトの方向性を早く固められる</li>
<li>ハイパーフォーカスで難関バグやアーキテクチャの課題を解消できる</li>
<li>スピードが評価されるスタートアップやPoC段階で特に高い価値</li>
</ul>
<p>上の利点は、採用側が「早く成果を出したい」状況で強く響きます。面談資料には具体的な数字やコミット履歴を添えると説得力が増します。</p>
<p>例：短期スタートアップで急速に機能を出し、ユーザーテストで早期検証を行ったことで投資判断が早まった実体験。</p>
<h2><span id="toc9">デメリット</span></h2>
<p>ポジティブに見せても、懸念点は存在します。交渉で先に説明すべき項目です。</p>
<ul>
<li>計画性や継続性に疑問を持たれる可能性がある</li>
<li>チームワークやドキュメント品質が後回しになりがちと評価される恐れ</li>
<li>オンコールや長期運用面で負担に見える場合がある</li>
</ul>
<p>上記はあらかじめ対策を用意することで軽減できます。たとえばドキュメントの自動生成や、オンコールの回数を契約で定めるなど具体対応を提示してください。</p>
<p>例：自分が過去に引き起こした作業漏れを補うため、CIのテストカバレッジを上げ、Slack通知で進捗を可視化した事例。</p>
<h2><span id="toc10">向いている人</span></h2>
<p>次のような性質がある人には、このアピールが向いています。</p>
<ul>
<li>試行錯誤で価値を生み出せるエンジニア（プロトタイプ志向）</li>
<li>ハイパーフォーカスで深い課題解決ができる人</li>
<li>短期の成果を評価する組織やプロジェクトに配属される人</li>
</ul>
<p>各項目に心当たりがあれば、年俸交渉で多動性を武器にできます。</p>
<p>例：SaaSプロダクトの初期フェーズで短期リリースを重視するチームのエンジニア。</p>
<h2><span id="toc11">向いていない人</span></h2>
<p>次に当てはまる場合は、別のアプローチを検討した方が良いです。</p>
<ul>
<li>長期保守や厳密なプロセス遵守が最重要な現場</li>
<li>コミュニケーションの摩擦が多く、個人の速度がチームを不安にさせる場合</li>
<li>自己管理が困難で、度重なる予定変更が発生する人</li>
</ul>
<p>向いていない場合は、まず内部改善（自己管理ツール導入やサポート体制の確立）を行ってから交渉に臨むべきです。</p>
<p>例：24/7稼働のインフラチームで頻繁に予定変更が起きると信頼低下に直結するケース。</p>
<h2><span id="toc12">比較：伝え方の選択基準</span></h2>
<p>多動性をアピールする方法は大きく二つに分かれます。どちらを選ぶかは組織と自分の実績で決めます。</p>
<ol>
<li>スピード重視（迅速な仮説検証を強調）</li>
<li>信頼性重視（リスク管理とハイパーフォーカスを強調）</li>
</ol>
<p>選択基準は次の通りです。短期間で価値を出す必要があるなら1)。長期運用や保守が評価基準なら2)を選び、リスク緩和策を前面に出してください。</p>
<p>例：新機能のA/Bテスト迅速化が求められるプロジェクトでは「スピード重視」が有利。ミッションクリティカルな決済周りの改修なら「信頼性重視」。</p>
<h2><span id="toc13">チェックポイント</span></h2>
<p>交渉資料作成時に必ず確認すべき項目を挙げます。次のチェックで準備不足を減らせます。</p>
<p>以下は提示する資料や口頭で触れるべきポイントです。</p>
<ul>
<li>具体的な成果（数値・期間・影響）を3つ以上用意しているか</li>
<li>リスクとその緩和策を明文化しているか</li>
<li>評価指標（KPI）とそれに紐づく報酬提案を提示できるか</li>
<li>チームへの影響と調整方法を示しているか</li>
</ul>
<p>これらを用意すれば、面談での反論を先回りできます。エンジニアはログやコミット履歴、Issueのクローズ率など客観資料を使うと非常に強いです。</p>
<p>例：Gitのコミット数ではなく、マージされたPRのリードタイムやリリースノートを引用して成果を示す。</p>
<h2><span id="toc14">行動のポイント</span></h2>
<p>交渉当日にすべき具体行動を短くまとめます。準備と実行の優先順位です。</p>
<ul>
<li>冒頭で「結論（希望のレンジと条件）」を明確に述べる</li>
<li>成果を「問題→自分の行動→結果」の順で3分以内に話せるよう練習する</li>
<li>懸念点は自分から先に提示して緩和策をセットで示す</li>
</ul>
<p>実行例：3分プレゼンを用意し、同僚に1回リハーサルしてフィードバックを得る。これで衝動的に話が脱線するリスクを下げられます。</p>
<h2><span id="toc15">結論と次の一手</span></h2>
<p>多動性は年俸交渉で隠すべき弱点ではなく、適切に証拠化して提示すれば強力な交渉材料になります。重要なのは「速度と品質のバランス」を示すこと、そして「予測可能性」を担保する具体策を持つことです。まずは過去6〜12ヶ月の成果を定量化し、リスク緩和策をドキュメント化して1枚の交渉シートにまとめてください。</p>
<p>次の一手：今日中に以下を行ってください。1) 過去の成果を3件、数値と期間で書き出す。2) そのうち1件を詳細な事例（行動とインパクト）にまとめる。3) 緩和策を3つ準備して交渉シートに入れる。</p>
<h2><span id="toc16">よくある質問</span></h2>
<h3><span id="toc17">Q. 多動性を正直に言うべきですか？</span></h3>
<p>言うかどうかは状況次第ですが、自分から説明すると面接官の誤解を避けられます。重要なのは「多動性をどう管理しているか」「どのように価値に変換しているか」を必ずセットで話すことです。</p>
<h3><span id="toc18">Q. 証拠が少ない場合はどうしますか？</span></h3>
<p>小さな成果でも「短期間に多く試した履歴」「プロトタイプ数」「改善サイクルの速さ」を示せます。コミット履歴、PRやIssueのクローズ率、ユーザーテストのログなどを集めましょう。</p>
<h3><span id="toc19">Q. チームに嫌われない伝え方はありますか？</span></h3>
<p>懸念点を先に示し、チームルール（レビュー頻度、ドキュメント基準）を自分から提案することです。相手の不安を解消する姿勢が信頼を作ります。</p>
<h3><span id="toc20">Q. フルタイムとフリーランスでアピール方法は違いますか？</span></h3>
<p>違います。フリーランスでは短期で結果を出す実績（納期厳守、成果報酬）を強調し、フルタイムではチーム適合性と継続的な価値提供を強調します。</p>
<h3><span id="toc21">Q. 交渉時の具体的な希望レンジはどう決めるべきですか？</span></h3>
<p>市場相場（同職種・同職位）を基準に、自分の「短期での価値創出ポテンシャル」と「リスク管理策」を加味して決めます。希望はやや上乗せで提示し、成果連動の条件を入れると交渉しやすいです。</p>
<p>投稿 <a href="https://atueda.com/%e5%b9%b4%e4%bf%b8%e4%ba%a4%e6%b8%89%e3%81%a7%e5%a4%9a%e5%8b%95%e6%80%a7%e3%82%92%e5%bc%b7%e3%81%bf%e3%81%ab%e5%a4%89%e3%81%88%e3%82%8b%e5%ae%9f%e8%b7%b5%e3%83%86%e3%82%af%e3%83%8b%e3%83%83%e3%82%af/">年俸交渉で多動性を強みに変える実践テクニックと事例解説（チェックリスト付き）</a> は <a href="https://atueda.com">ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ</a> に最初に表示されました。</p>
]]></content:encoded>
					
					<wfw:commentRss>https://atueda.com/%e5%b9%b4%e4%bf%b8%e4%ba%a4%e6%b8%89%e3%81%a7%e5%a4%9a%e5%8b%95%e6%80%a7%e3%82%92%e5%bc%b7%e3%81%bf%e3%81%ab%e5%a4%89%e3%81%88%e3%82%8b%e5%ae%9f%e8%b7%b5%e3%83%86%e3%82%af%e3%83%8b%e3%83%83%e3%82%af/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">2118</post-id>	</item>
	</channel>
</rss>
