Rui Software「やった量」と「変わった量」は違う：成果はどこで生まれるのか【第1回】
この記事を読み終えると、自分の1週間の仕事を作業（アウトプット）・成果（アウトカム）・効果（インパクト）の3段階に分解して説明でき、「作ったのに評価されない」がどこで起きているかを自分で特定し、次の一手を選べるようになります。ジュニアエンジニア向け 成果の出し方シリーズ（全12回）の第1回です。
🎯 テーマの主役：「成果の変換段階」——作ったものと、変わったものは別である
今回の主役は成果（アウトカム）です。一言で言えば、成果とは「誰かの状態が、良い方向に変わったこと」です。作業ではありません。作ったものでもありません。変わったことです。
日常の例えで言うなら、レストランの厨房です。シェフが野菜を切り、火を通し、盛り付ける。これは作業です。料理が客の前に出る。これは提供です。そして客が「おいしい、また来よう」と思う。これが成果です。どれだけ厨房で手を動かしても、料理が出なければ客は満足しません。そして料理が出ても、客が食べなければ何も変わりません。厨房の忙しさは、成果の大きさを保証しないのです。
エンジニアの仕事も同じ構造です。コードを書く（作業）→ リリースする（提供）→ 誰かの仕事が楽になる・速くなる・安全になる（成果）→ 事業の数字が動く（効果）。この4つの間には、それぞれ飛び越えられない段差があります。そしてジュニアエンジニアが最もつまずきやすいのは、「作業を頑張れば成果になる」という前提です。残念ながら、この前提は成り立ちません。
この記事の仮説はこうです。評価されるのは作業量ではなく、状態の変化である。したがって成果を出す技術とは、「変化が起きる場所」を特定して、そこに手を入れる技術である。もしこれが正しければ、私たちの努力の向き先は「もっと作る」ではなく、「どこで変化が止まっているかを見る」に変わるはずです。この全12回のシリーズは、その「変化が止まる場所」を1つずつ潰していく構成になっています。
動機：「頑張っているのに、何も変わっていない」という感覚
ジュニアエンジニアとして働き始めて数か月たつと、多くの人が次のような感覚を持ちます。毎日コードを書いている。チケットは消化している。レビューも通している。でも、自分が何を変えたのか説明できない。 そして評価面談で「もっと主体的に」と言われる。何をどうすれば主体的になるのか分からない。
この状態の正体は、努力の量は増えているのに、努力の向き先が成果の発生地点を向いていないことです。第1回のこの記事では、まずその発生地点の地図を配ります。
ここで1つ、身も蓋もない事実を先に書いておきます。組織はあなたの努力を評価しません。組織が評価するのは、あなたの努力によって何が変わったかです。 これは冷たい話ではなく、単純に評価する側から努力が見えないというだけのことです。努力は本人の内側で起き、成果は外側の状態として現れます。外から観測できるのは後者だけです。
これはあなたが悪いわけでも、組織が冷たいわけでもありません。構造の問題です。そして構造の問題は、構造を知ることで対処できます。
🔍 検証①：作業量と成果量は比例しない
まず、最も多い誤解から潰します。「たくさん作れば成果が出る」という前提です。
ソフトウェア開発の世界では、この前提が崩れる理由がはっきりしています。コードは書けば書くほど、維持するコストが増えるからです。1,000行のコードは、2,000行のコードより理解が速く、変更が安全で、障害が起きにくい。つまり同じ機能を半分のコードで実現した人は、成果が同じでも負債が少ない。作業量（行数）と成果は、しばしば逆向きに動きます。
チケットの消化数も同じです。チケットを1日10枚閉じる人は、小さいチケットを選んでいるか、後続の作業を他の人に押し出している可能性があります。数は努力の量を示しますが、変化の量は示しません。
| 測り方 | 何を測っているか | この指標だけを見ると起きること |
|---|---|---|
| コード行数 | 作業量 | 冗長なコードが増え、保守コストが上がる |
| コミット数 | 作業量 | 細かすぎるコミットで履歴が読めなくなる |
| チケット消化数 | 作業量 | 小さい仕事ばかり選び、大きい問題が残る |
| リリース回数 | 提供量 | 出すこと自体が目的化し、使われない機能が増える |
| 利用者の作業時間 | 成果 | 測るのが難しいが、これが本来の目的 |
| 事業指標（時間・金額・件数） | 効果 | 因果が遠く、単独の貢献に分解しにくい |
表の下2行が成果と効果です。そして測るのが難しいからこそ、多くの現場は上の行で人を評価してしまいます。この構造は、あなた自身にも同じ形で襲いかかります。自分で自分の成果を測らないと、他人は作業量で測るしかないのです。
🔍 検証②：成果は「使われた」ときに初めて発生する
次に、成果が発生する場所を特定します。結論から書くと、成果は「あなたが作ったもの」と「使う人」の接触面で発生します。
この境界を挟んで、起きていることがまったく違います。あなたが制御できるのは境界の手前までです。境界の向こう側（使われるかどうか）は、あなたの努力量では決まりません。決めるのは使う人の状況です。便利かどうか、面倒が増えないか、信頼できるか、そもそも存在を知っているか。
「知られていない」は、ジュニアが最も見落とす理由です。存在を知らない機能は、存在しないのと同じです。リリースノートを書く、使い方を共有する、使っている人に直接見せる。この地味な作業が、成果の発生率を大きく変えます。
🔍 検証③：測れない成果は、作業量で代用される
次に、なぜ組織が作業量で評価してしまうのかを、もう一段深く見ます。
これは測定期の理論として知られています。「ある指標が目標になると、その指標は適切に機能しなくなる」という現象です（Goodhartの法則）。イギリスの大学システムを分析した研究では、研究評価の指標が導入された結果、数値は改善したが実質は改善しなかったと報告されています。
エンジニアリングの現場で起きる具体形はこうです。「コードレビューの件数」を指標にすると、細かい修正を大量に出す人が評価される。「チケットの消化数」を指標にすると、チケットが細分化される。どちらも数値は伸びますが、状態は変わりません。
| 代用指標（測りやすい） | 本来測りたいもの | ずれが起きる形 |
|---|---|---|
| 書いたコードの量 | 解けた問題の大きさ | 冗長な実装が評価される |
| レビューの指摘数 | 欠陥の予防 | 本質でない指摘が増える |
| 対応した問い合わせ件数 | 問い合わせが起きない状態 | 根本原因を直さなくなる |
| 会議への参加時間 | 意思決定の質 | 会議が増える |
この構造から逃げる方法は1つだけです。自分で本来の成果を測り、それを言葉にして共有すること。組織の指標が作業量でも、あなたが「これだけ変わった」を数字や具体例で示せば、評価の材料は増えます。測る努力を放棄した人が、測りやすいもので測られるのです。
🔍 検証④：「作った」と「変わった」の間にある時間差
4つ目の検証は時間です。成果には時間差があり、この時間差が努力の評価を難しくします。
作業は当日に発生します。提供は数日から数週間後。成果は数週間から数か月後。効果は数か月から数年後。つまりあなたが今日書いたコードの成果は、あなたが忘れたころに現れます。そして厄介なことに、成果が出た時点では、誰がそれを起こしたのかが見えにくいのです。
これは第1回のシリーズ全体の動機にもなります。成果の時間差があるからこそ、人は短期的な作業量に引き寄せられます。作業量は即座に見えるからです。逆に言えば、時間差を理解している人は、成果が出る前に手を打てます。
🔍 検証⑤：成果を出す動作は3つに分解できる
ここまでで、成果が発生する条件が分かりました。まとめると、成果を出す動作は次の3つに分解できます。
- 状況を掴む：何が問題か、誰が困っているか、何が変われば良いかを特定する
- 安全に変える：掴んだ問題に対して、壊さず・戻せる形で変更を届ける
- 人を動かす：賛成を得る、協力を得る、使ってもらう
そしてこの3つは、それぞれ別の技術です。1つ目は調査と分析、2つ目は設計と運用手法、3つ目はコミュニケーションと提案。学校で教わるのは主に2つ目です。しかし現場で評価が分かれるのは、1つ目と3つ目です。
| 動作 | 問い | このシリーズの対応回 |
|---|---|---|
| 状況を掴む | 何が起きているのか | 第2回〜第5回（障害調査・影響分析） |
| 安全に変える | 壊さず変えるにはどうするか | 第4回〜第5回（影響分析・戻せる変更） |
| 人を動かす | どう伝え、どう頼み、どう提案するか | 第6回〜第9回（報告・質問・提案・バリュー） |
| 続ける | どう時間と約束を管理するか | 第10回〜第11回（見積もり・優先順位） |
| 積み上げる | 信頼はどう作られるのか | 第12回（総括） |
この表が、このシリーズの地図です。第2回以降は、この3つの動作を1つずつ分解していきます。順番には意味があります。まず「壊れたとき」を扱います。なぜなら、障害対応は成果の出し方が最も凝縮されて現れる場面だからです。短時間で状況を掴み、安全に止血し、関係者を動かす必要があります。
結果：成果を説明する3行フォーマット
ここまでの検証を、明日から使える形に落とします。自分の仕事を振り返るとき、次の3行で書いてみてください。
① 何をしたか（作業）： 申請フォームのバリデーション処理を共通化した
② 何が変わったか（成果）：同じ修正を3か所に書く必要がなくなり、修正時間が1件30分→5分になった
③ 何に効くか（効果）： 入力仕様の変更対応が月2件発生しており、月50分の削減。仕様変更時の修正漏れリスクも下がる
この3行が書けないときは、②が空欄になっていることがほとんどです。②が空欄の仕事は、まだ成果になっていません。成果の出し方は、②を埋める作業だと言い換えてもよいくらいです。
| 状態 | ①作業 | ②成果 | ③効果 | 次の一手 |
|---|---|---|---|---|
| 空振り | ある | ない | ない | 使われていない理由を調べる（検証②の3理由） |
| 自己満足 | ある | ある | ない | 効果が出る規模か確認する。対象者を広げる |
| 成果 | ある | ある | つながる | ③を数字で語れるようにする |
| 過小申告 | ある | ある | ある | ②③を言葉にする（多くのジュニアがここ） |
特に4行目の「過小申告」が、多くのジュニアが置かれている状態です。実際には成果を出しているのに、②と③を言葉にしていないため、評価の場に届いていません。成果を出すことと、成果を伝えることは、別の技術であり、両方必要です。このシリーズの第6回〜第9回は、この「伝える側」を扱います。
考察：「頑張り」は成果の通貨ではない
ここまでの内容を踏まえて、少し踏み込んだ話をします。
努力は、それ自体では交換価値を持ちません。 これは厳しい言い方ですが、構造としては正確です。組織があなたに給与を払うのは、あなたが疲れたことに対してではなく、あなたが何かを変えたことに対してです。努力は成果を生むための手段であり、目的ではありません。
しかし、ここで誤解してほしくないことがあります。だから努力は無意味だ、という話ではありません。努力の量は、成果の発生確率を上げます。ただし確率を上げるだけで、保証はしません。だからこそ、努力の向き先を選ぶことに意味が出てきます。同じ量の努力を、成果が発生する場所に向けたほうが、期待値が高い。
そして、成果が発生する場所は、たいてい「面倒で、誰も見ていない場所」にあります。エラー処理、ログ、ドキュメント、テスト、削除、整理。これらは作業量としては地味で、提供も地味で、成果も遅れて現れます。しかし効果は長く続きます。逆に華やかな機能追加は、成果が早く出て、効果は短命です。どちらが良いかではなく、どちらを選んでいるかを自覚しているかが問われます。
もう1つ。この記事の内容は、「評価されるために動け」という話ではありません。成果の地図を持つ意味は、自分の時間を、自分が意味があると思う変化に集中させるためです。地図がないと、人は目先の忙しさに流されます。地図を持つと、「この作業はどの段階に効いているのか」を自分で問えるようになります。この問いを持てる人が、結果として評価されます。
📌 注目ポイント
この記事の核心を4点に絞ります。第一に、成果とは状態の変化であり、作業量ではないこと。第二に、成果は「作ったもの」と「使う人」の境界で発生すること（知られていない・面倒が増える・信頼できないの3つが主な阻害要因）。第三に、時間差があるため、努力が見える速さと成果が現れる速さは一致しないこと。第四に、成果を出す動作は「状況を掴む・安全に変える・人を動かす」の3つに分解でき、どれも別の技術であること。
特に重要なのは第二点です。多くのジュニアは「良いものを作れば評価される」と考えますが、良いものは成果の必要条件であって十分条件ではありません。使われるまでの距離を設計に含めるかどうかで、結果が大きく変わります。
💡 活用事例：社内ツールから生まれた2つの製品
成果の発生場所を示す事例として、「社内で使われていたものが製品になった」話は非常に示唆的です。ここではSlackとAWSを並べます。
Slackは、もともとゲームを作る会社で生まれました。同社はゲームの開発中に、チーム内の連絡と情報共有のためのツールを自作して使っていました。ゲーム自体は商業的に成功しませんでしたが、社内で使っていたツールのほうが「これは外に出せる」と判断され、製品化されました。重要なのは順序です。先に自分たちが使い、次に製品になった。作ってから売り込んだのではなく、すでに使われている状態が先にあったのです。
AWSも同様の構造です。Amazonは自社のサービスを動かすために、計算資源とストレージの仕組みを内製していました。その内製の仕組みを、2006年に外部向けのサービスとして提供開始しました。こちらも社内で既に使われ、鍛えられていたものが外に出た形です。
| 事例 | 作業（作ったもの） | 成果（起きた変化） | 順序の特徴 |
|---|---|---|---|
| Slack | 社内の連絡ツール | 社内の情報共有コストが下がった | 使われてから製品化された |
| AWS | 社内の計算基盤 | 自社サービスが効率よく動いた | 利用実績が先にあった |
| 失敗例：Segway | 技術的に画期的な移動機器 | 普及せず、2020年に生産終了 | 技術が先で、使う人の状況が後回し |
Segwayは2001年12月に発表され、技術的には非常に先進的でしたが、街を移動する人の実際の状況（置き場所・法規制・価格・安全性への不安）に十分に合いませんでした。技術的な新しさは、成果の保証にはならないという典型例です。3つの事例に共通する教訓は同じです。「良いもの」より「使われるもの」が先にあり、使われるものは使う人の状況から逆算される。
✅ 要点まとめ
- 成果＝状態の変化。作業量・コード量・チケット数は成果ではない
- 成果は「作ったもの」と「使う人」の境界で発生する
- 使われない理由は3つ：知られていない・面倒が増える・信頼できない
- 作業・提供・成果・効果には段差があり、それぞれ越える条件が違う
- 努力は成果の確率を上げるが保証しない。だから向き先を選ぶ価値がある
- 成果を出す動作は3つ：状況を掴む・安全に変える・人を動かす
- 成果は過小申告されやすい。②と③を言葉にしないと評価に届かない
🚀 取り込み方：明日から使う3段階
今日（5分でできること）：直近1週間の自分の仕事を3つ選び、「①作業・②成果・③効果」の3行で書き出してください。書けない項目があれば、そこが伸びしろです。特に②が空欄の仕事は、まだ成果になっていません。
今週（小さく試す）：②を埋めるための最短行動を1つだけ実行します。たとえば、作ったものを1人の利用者に直接見せて、感想を聞く。リリースノートを書いて共有する。使われているかをログや利用回数で確認する。「知られていない・面倒が増える・信頼できない」のどれで止まっているかを、推測ではなく観測してください。
今月（業務に組み込む）：自分のタスクを引き受けるとき、「これは誰の何が変わるのか」を1文で言ってから着手する習慣にします。言えないときは、着手前に上長や依頼者に確認します。この1文が言えるようになると、タスクの切り方・優先順位の付け方・完了の定義が変わります。第2回以降で扱う具体的な技術は、すべてこの1文を実現するための手段です。
🔥 ハマりポイント：努力の空振りが起きる3つの型
その1：「作れば伝わる」と思いがちだが、実は伝わらない
症状は、リリースしたのに問い合わせが来ない・使われている気配がない。原因は利用者が存在に気づいていないことです。開発者のタイムラインでは当然の情報も、利用者の日常には入ってきません。対処は地味です。リリースノートを出す・使い方を1枚にまとめる・使う人の前で実演する。特に「実演」は効果が大きく、3分のデモが数週間の告知に勝つことがあります。
その2：「完璧にしてから出そう」と思いがちだが、実は価値が遅れて減る
症状は、完璧を目指して提供が遅れ、その間に状況が変わる。原因は成果の時間差を理解していないことです。成果は提供の後にしか発生しないので、提供が遅れると成果も遅れます。対処は、価値の小さい単位に切って先に出すことです。第5回で扱う「戻せる変更」は、この考え方の技術版です。
その3：「成果は自分で言うと嫌われる」と思いがちだが、実は言わないと存在しない
症状は、実際に成果を出しているのに評価が上がらない。原因は成果が見える形で記録されていないことです。対処は、自慢ではなく記録として書くことです。「私は頑張った」ではなく「この変更で、この作業が30分から5分になった」。事実の記録は、どんな文化の組織でも嫌われません。評価の材料を相手に渡すことは、ずるではなく、仕事の一部です。
🔄 代替アプローチとの比較：成果を測る3つの立場
成果をどう測るかには、複数の立場があります。どれも長所と短所があり、目的によって使い分けるものです。自分の現場がどの立場に寄っているかを知っておくと、評価のズレを説明しやすくなります。
| 立場 | 測る対象 | 向いているケース | 弱いケース |
|---|---|---|---|
| 作業量で測る | コード行数・チケット数・対応件数 | 作業の平準化が必要な初期段階 | 質と成果が置き去りになる |
| 提供量で測る | リリース回数・リードタイム | 届ける速度に問題があるチーム | 使われない機能が増える |
| 成果で測る | 利用者の状態変化・利用率 | 価値の検証が必要な段階 | 測るコストが高く、因果が遠い |
| 効果で測る | 事業指標・コスト・リスク | 経営層への説明 | 個人の貢献に分解しにくい |
作業量で測るほうが向いているケースも正直に書いておきます。たとえば、問い合わせ対応の件数が急増している時期は、まず作業量を把握しないと負荷が可視化されません。測り方に優劣があるのではなく、目的に合うかどうかです。ただし、測り方が上から下（効果の側）へ動くほど、あなたの仕事の意味が伝わりやすくなるという向きは意識しておく価値があります。
📅 今後の展望：成果の測り方は「外側」へ広がっている
ソフトウェア開発の評価は、ここ10年で作業量から成果・効果の側へ少しずつ移ってきました。その代表がDORA指標です。デプロイ頻度・変更のリードタイム・変更失敗率・復旧時間の4つは、「どれだけ出したか」ではなく「どれだけ安定して速く変えられたか」を見る指標です。第11回では、この指標と日々の優先順位の関係を扱います。
もう1つの流れが、プロダクト側の指標との接続です。機能が使われているか、利用者の作業が短くなったかを測ろうとする動きは、プロダクトマネジメントの領域で標準になりつつあります。エンジニアにとっては、「作りました」ではなく「これだけ使われています」と言えるほうが強い時代になっている、ということです。
ただし、測れば測るほど良いわけでもありません。第3の検証で見たとおり、指標は目標になった瞬間に歪みます。だからこれからの現場では、「この数字は何を測っていて、何を測っていないか」を説明できる人が重宝されます。数字を出す技術ではなく、数字の限界を語れる技術が、次の10年の差になる可能性が高いと考えられます。
まとめ
この記事では、成果がどこで生まれるのかという地図を配りました。作業と成果は別物であり、成果は状態の変化です。成果は「作ったもの」と「使う人」の境界で発生し、知られていない・面倒が増える・信頼できないという3つの理由で止まります。そして成果を出す動作は、状況を掴む・安全に変える・人を動かすの3つに分解できます。
これを読んだあなたは、自分の仕事を「作業・成果・効果」の3行で説明でき、②が空欄の仕事を見つけ、②を埋めるための最短行動を選べるようになりました。次の第2回からは、この3つの動作を1つずつ技術に落としていきます。最初に扱うのは障害調査です。壊れたとき、原因より先に手を付けるべきものがある——それが最初の技術です。
参考文献
- Marty Cagan『INSPIRED』（Silicon Valley Product Group） — アウトプットではなくアウトカムで考える製品開発の原則。 https://www.svpg.com/
- Peter F. Drucker『The Effective Executive』（1966） — 「成果」とは何か、何に時間を使うべきかの古典。
- Andrew S. Grove『High Output Management』（1983） — マネジメントのアウトプットを定義した基礎文献。
- Nicole Forsgren, Jez Humble, Gene Kim『Accelerate』（2018） — DORA指標の原典。 https://dora.dev/
- DORA（DevOps Research and Assessment） — デリバリー性能と組織性能の継続調査。 https://dora.dev/
- Google『Site Reliability Engineering』 — SLOとエラーバジェットによる目標設計。 https://sre.google/
- Marilyn Strathern（1997）「Improving ratings: audit in the British University system」 — Goodhartの法則が学術評価で現実化した過程の分析。
- Donald T. Campbell（1979）「Assessing the impact of planned social change」 — 指標が目標化すると歪むという法則（Campbellの法則）。
- Slack Technologies, Inc. SEC Form S-1（2019） — 社内ツールから製品化に至った経緯の一次資料。 https://www.sec.gov/
- Amazon Web Services プレスリリース（2006年3月14日 S3 提供開始） — 社内基盤の外部提供という構造の一次情報。 https://aws.amazon.com/
- Stewart Butterfield インタビュー（Slack創業に関する発言、各種技術メディア） — 「社内で使われていた」経緯の当事者証言。
- Segway に関する報道（2001年12月発表・2020年7月生産終了） — 技術的先進性が普及を保証しない事例。 https://www.reuters.com/
- Douglas K. Smith & Robert C. Alexander『Fumbling the Future』（1988） — Xerox PARC の発明が事業化されなかった経緯。
- Ron Kohavi, Diane Tang, Ya Xu『Trustworthy Online Controlled Experiments』（2020） — 指標設計と意思決定の実務的指針。
- IPA『ITSSレベル別スキル標準／iコンピテンシ ディクショナリ』 — 成果指向の能力定義。 https://www.ipa.go.jp/
- CS2023（ACM/IEEE-CS Computer Science Curricula 2023） — 職業実践と成果を重視する教育基準。 https://csed.acm.org/