■ 1. 主張の前提と結論
- エンジニアが事業目線を持つ必要は必ずしもない
- ただし以下の条件のいずれかに該当する場合は事業に関心を持たざるを得ない
- 給与を上げたい場合
- 会社・上司・プロダクトの方針に対して批判や意見を述べたい場合
- 自分のキャリアや生活の生殺与奪を自分で握りたい場合
■ 2. 給与と事業目線の関係
- 指示された業務のみを行うポジションの給与は市場相場によって決まり、上限がある
- 給与を上げるには「言われていないこと」を自分で見つけて取りにいく必要がある
- 「言われていないこと」を発見するには事業に対する自己の理解が前提となる
- 給与は「収益」と「レバレッジ（波及効果）」から生まれる
- ユーザー価値の追求が事業収益に接続していない環境では給与は上がりにくい
- ビジネス構造自体を設計できる立場に立つか、収益と接続した環境に乗るかのいずれかが必要
- 技術力が高ければ給与が上がるという見方は条件付きで正しい
- その技術が求められる環境を自ら理解・選択できている場合に限る
■ 3. 批判の権利と解像度
- 会社や上司の方針に文句を言うには、それに値する解像度が必要
- 事業構造を理解していない状態での批判は不平不満にしかならない
- 「事業目線を持て」という言葉がビジネスサイドのポジショントーク（「俺の言うことを聞け」）として使われる場合は無視してよい
■ 4. AI時代における指示待ちのリスク
- 指示された通りに正確にこなす業務はAIに置き換えられやすい
- タスク境界が明確で入出力が定まっており判断の余地が少ない仕事はAIの得意領域
- AIで効率化した時間を「深く考える」「事業構造を理解する」「自分にしか出せない価値を作る」に使わない限り、効率化によって交換可能な部品に近づく
- AIを働かせる側に立つか、AIに働かされる側に回るかが組織内のポジションを左右する
- 「言われたことだけやる」ポジションに留まることはAI時代において自分の仕事を最もリスクの高い場所に置く選択となる
■ 5. 事業目線の広げ方（実践的手順）
- PLやBSの学習から入ることは推奨しない
- 抽象的すぎて自分の仕事と接続されず、理解で終わりやすい
- ステップ1: 自分が現在の職場で出している価値を言語化する
- 「なぜ自分は給与をもらえているのか」を自分の言葉で説明できるようにする
- ステップ2: 会社のビジネスモデルを自分で説明できるようにする
- 誰からどのようにお金をもらっているか（受託、SaaS、従量課金、広告など）を理解する
- ステップ3: 両者を合成する
- 「自分の価値が会社の儲け方のどこにどう接続すれば給与が上がるか」が見えてくる
- 自分の半径内から始めることが正解であり、IRや株主総会資料は後回しでよい
■ 6. 自分のプロダクトを持つことの意義
- 会社という装置を抜きにした状態で自分が何で価値を出せるかを試すことを推奨
- 全工程（企画→設計→実装→公開→改善）を一人で回す経験が事業構想力の練習場となる
- AIの進化によって技術的ハードルが低下し、個人でのフルサイクル開発が現実的になった
- 会社は同僚・上司・システム・ブランド・顧客リスト・給与前払いなどの投資をしており、それを「自分の力」と混同することが最も危険
■ 7. 転職とビジネスモデルの多様化
- 転職先はビジネスモデルが異なる職場を選ぶことが望ましい
- 同種のビジネスモデルへの転職は視界の広がりが小さい
- 「会社がどうやってお金をもらい」「何が差別化領域で」「自分がどう貢献するか」という問いに答えられるかが転職先選択と入社後の活躍に影響する
- ビジネスモデルへの合致はメンタルモデルとの整合性の問題であり優劣ではない
■ 8. 事業目線の定義
- 事業目線とは直接的にお金を生み出すことだけを指さない
- 会社があなたを雇った「狙い」を理解し、その狙いを超えて動けることが事業目線を持ったエンジニアの定義
- 実装速度、レビューの的確さ、陳腐化しにくい設計、チームの士気向上なども事業目線の範疇に入る
- 短期の数字では測りにくいが長期的に価値を出せることが最も重要であり、短期の説明しやすい数字に飛びつくことは「逃げ」にあたる
■ 9. 統合と全体性
- 自分がやっていること、会社がやっていること、業界での位置、人生における仕事の意味を一つのナラティブとして語れることが重要
- 解像度を上げるとは情報を集めることではなく、集めた情報を自分の中で繋ぎ合わせること
- 事業に関心を持つこととは、自分の半径内の点を繋いで統合していく作業
■ 10. 分業のあり方
- 何でもできる人が集まり、得意なことをあえて分業する形が理想
- 他職能の仕事を理解した上での分業と、知らないままの分業は全く異なる
- AI時代に「自分の担当範囲しか知らない」という状態は選択肢として不利
- 知った上で分業するか、全部一人でやるか、いずれかを自分で選んで進むべき
■ 11. 「お膳立てされている自覚」から始める
- 会社員は同僚・システム・ブランド・顧客など多くの投資を受けた状態で仕事をしている
- 「このお膳立てに乗り続けるか」「自分で立つ準備を始めるか」を自分で選択することが出発点
- 事業に関心を持つかどうかは最終的にこの選択の問題
- 給与を上げたい、文句を言いたい、生殺与奪を自分で握りたいのいずれかに当てはまるなら事業に関心を持たざるを得ない
■ 1. 概要
- エンジニアの「事業目線」論争に対し、「持たなくていい、ただし条件付き」という逆張り構造で論を展開する記事
- 釣りタイトルを自覚的に使用しているが、結論は実質的にタイトルの逆であり、「事業目線は必要」という通説の言い換えに過ぎない
- 実用パートは具体的で有用だが、主張の多くは著者の個人的経験に依拠しており、証拠としての強度は低い
- 全体として読みやすく実用的な示唆はあるものの、論考としての厳密さに欠ける
■ 2. 評価軸と分析
- 論理構造 (2.5/5):
- 骨格は「事業目線は不要、ただし①給与上昇、②文句を言う権利、③AI代替リスク回避のいずれかを望むなら必要」という条件分岐
- 三つの「条件」は独立した論点として提示されているが、互いに強く重なる
- 「AI代替」のパートは「条件2」の補足として突然挿入され、前後の論理との接続が弱い
- 後半では主張が「全体性を持て」「自分のプロダクトを持て」「転職先のビジネスモデルを変えろ」と際限なく拡張され、元の主張との整合性が曖昧になる
- 節々で論理の飛躍と話題の横滑りが生じており、論考として締まりに欠ける
- 説得力 (3/5):
- 逆張りのタイトルとその自己解体という構成は読者を引き込む点で巧み
- 著者自身のキャリア（SIer→自社プロダクト→BASE）を具体的に示しており一定の説得力を持つ
- 説得の根拠が「自分はそう思う」「自分はそうだった」の集積に留まっている
- 強い主張が裏付けなしに断言調で提示されており、懐疑的な読者を論理で説得する力は弱い
- 文体のテンポの良さが内容の薄さを補っている側面がある
- 主張の妥当性 (3/5):
- 「事業文脈を理解しなければ自分の貢献と報酬を接続できない」という中核的主張は妥当
- 「ユーザー価値追求だけでは給与は上がらない」という指摘は多くの現場で観察される現象と一致する
- 「解像度が低い批判は説得力がない」という主張は、正当な不満を持つ当事者に黙れと言う圧力として機能しうる
- 「指図されたことしかやらない→AI代替確定」という図式は過度な単純化であり、AIが現時点で確実に代替できる仕事の範囲はより限定的
- 結論部での「自覚を持ちましょう」という断定は反証可能性のない同語反復に近い
- 証拠の質 (1.5/5):
- 外部データ・研究・統計・他者事例はほぼ皆無であり、証拠として機能するのは著者自身のキャリア経験のみ
- 「AI代替のリスク」「事業理解と給与の相関」「ビジネスモデルを変えた転職の効果」といった重要な主張に裏付けとなる一次資料が存在しない
- 自身の過去記事へのリンクが多数登場するが内容は本記事内で要約・引用されておらず、議論が外部に委ねられている
- 明確さ・可読性 (3.5/5):
- 文体は軽快で読みやすく、見出し構造も整っている
- 「最初に結論を述べ、後から条件を展開する」という段落構成は読者を引き込む点で効果的
- 実用パート（ステップ1〜3）は具体的で、読者がアクションに移りやすい形で書かれている
- 同じ主旨の文が繰り返し登場し、後半になるほど新しい論点が少ない
- 全体的に2割ほど圧縮すれば、主張はより鮮明になる
■ 3. 総評
- エンジニアへの実務的な示唆として一定の価値を持ち、特に「自分の価値を言語化し、会社のビジネスモデルと接続する」という実用パートは具体的で有用
- 「論考」として評価すれば、証拠の欠如と論理の弛緩が致命的
- 強い主張の多くが著者の個人的直感に由来しており、反論や例外への耐性が低い
- タイトルの逆張り構造は読者を引きつけるが、結論は通説の言い換えに過ぎず、独自の洞察として成立していない
- 文章の巧みさと内容の実質的薄さの乖離が大きく、「読みやすいが論証が弱い」という評価が妥当
■ 4. 採点結果
- 論理構造: 2.5 / 5
- 説得力: 3 / 5
- 主張の妥当性: 3 / 5
- 証拠の質: 1.5 / 5
- 明確さ・可読性: 3.5 / 5
- 合計: 13.5 / 25