「品質」を犠牲にして「速度」を得ることはできない〜生産性の正体と成長の尺度

このブログではこれまで、仕事を「技芸」と捉え、売上や規模といった外的な拡大ではなく、年輪を刻むような内的な「成長」を目指すことを書いてきました。

しかし、そうした「目に見えない成長」を、一体何をもって測ればいいのでしょうか。特に、プログラミングのような高度な技能が求められる世界において、自分や仲間の熟達を正しく認識するための尺度をどこに置くべきかは、非常に難しい問題です。

今回から数回にわたり、ソフトウェア開発における「技芸の成長を測る尺度」を解剖していきたいと思います。

その第1回となる本稿では、多くの現場で誤解されている「生産性と品質」の真実、そして生成AIが当たり前になった時代に、人間にこそ求められる「審美眼」という尺度について深掘りします。

ソフトウェア開発の生産性は「量」では測れない

「ソフトウェア開発の生産性をどう測るか？」

これは、ソフトウェア開発という生業が誕生して以来、この業界が抱え続けている永遠の課題です。かつては、エンジニアが書いたコードの行数（ステップ数）で測ろうとした時代もありました。しかし、今ではそれが全くの無意味であることは誰もが知っています。

なぜなら、行数を増やすほど、その後の保守や修正の手間が増え、余計なバグを生み出すリスクが高まるため、意味のないコードを大量に書くことは、むしろ悪でさえあるからです。

しかし、では行数に代わる明確な尺度を提示できている組織がどれほどあるかと言えば、驚くほど少ないのが現状です。

一般的に、ビジネスの世界における生産性は「成果物の量 ÷ 時間」という工業的な計算式で導き出されます。たくさん作れば生産性が高い。速く作れば効率がいい。至極真っ当な論理に聞こえます。

しかし、ソフトウェア開発を単なる生産作業ではなく、高度な技能と創造性が求められる領域、すなわち技芸として仕事を捉えるならば、この単純な計算式は通用しません。

そもそもソフトウェアにおいてコードの量は「資産」ではなく、むしろ維持管理が必要な「固定費（負債）」です。不用意に増やされたコードは、将来の変更を阻害し、保守コストという利息を生み続ける「高利貸しの借金」になり得ます。真の生産性とは、いかに少ないコードで（＝負債を最小限に抑えて）、ビジネス価値を実現するかという点にあります。

「1人月」という幻想が生む現場の摩擦

私がかつて、大手システム会社でプロジェクトマネージャをしていた頃の話です。

あるプロジェクトで、２０名ほどのメンバーを率いることになりました。メンバーの力量はまさに千差万別です。呼吸を合わせるだけで自律的に動くベテランから、配属されたばかりの未経験者に近い若手までが混在していました。

当時の業界の常識――そして悲しいかな、今なお根強く残る常識――では、エンジニアは「１人月」という均一な単位で数えられていました。ベテランも新人も、パズルのピースのようにスケジュール表の空きに埋め込まれていく。しかし、現場で起きていた現実は、その計算式を根底から覆すものでした。

熟練した開発者には、事細かに指示を出す必要はありません。「こういう問題を解決したい」という意図を伝えるだけで、彼らは背景にあるビジネスの文脈まで汲み取り、自ら考え、最短距離で実装へと辿り着きます。

一方で、未経験者に近いメンバーに同じ伝え方をしても、一向に開発が進まないか、あるいは途方もない時間がかかってしまいます。彼らを動かすために、タスクを極限まで噛み砕き、具体的な手順に分解し、手取り足取り説明して手渡すことになります。

初心者を管理する「コスト」の正体

 「ここまでタスクを分解して説明するコストを払うくらいなら、自分でコードを書いた方が圧倒的に早いのではないか？」こう考えるのはマネージャーの傲慢ではなく、物理的な真実です。

初心者を戦力にするための「管理コスト」や「教育コスト」が、彼らが生み出すアウトプットの価値を上回ってしまうことが往々にしてあるのです。工業的な「１人月」という単位は、時に価値をマイナスにしてしまう幻想に過ぎませんでした。

さらに深刻だったのは、出来上がったコードの「質」の差です。

熟練者が書いたコードは、洗練された文章のように読みやすく、設計の意図も伝わってきます。意図が明確であれば、読めばすぐに理解できます。したがって、コードレビューも短時間で終わります。

対して、未熟なメンバーが書いたコードは、解読すること自体が困難を極めます。変数の名付けに一貫性がなく、ロジックが絡まり合い、どこに罠が潜んでいるかわからない。コードレビューをするには、まずレビューする人が仕様を深く再理解し、書かれたコードがその意図を反映しているか、一行一行「発掘調査」のように進めなければなりません。

もとの仕様を自分で理解し直し、意図通りに作られているかを確認していくのは、むしろゼロから作るよりもコストのかかる作業になることもざらです。不適切な設計のまま積み上げられたコードは、もはや修正するよりも、全てを捨てて最初から書き直したい衝動にかられます。

彼らが費やした数日間の作業時間と、レビューする側の苦悩は、成果物として何も残らず消えていく。工業的な計算では見えない、これこそが、短期的な生産性を著しく欠如させてしまう実態です。

「品質」を犠牲にした「速度」は必ず破綻する

ここで、多くの経営者やマネージャー、そして焦っている開発者が陥る致命的な誤解を正さなければなりません。それは「急いでいるから、多少品質が悪くても速く作ってほしい」という要求です。この要求は、経営判断として一見正しく見えます。しかし、これは「今日走るために、明日のガソリンを抜く」ような行為です。

断言しますが、ソフトウェア開発において、「品質」を犠牲にして「速度」を得ることはできません。

「とりあえず動けばいいから汚いコードでいい」という判断は、短期的には進捗が出たように見えるかもしれません。しかし、その汚いコードは、解読を困難にし、バグを誘発し、修正を難しくし、未来の開発時間を確実に奪っていきます。品質を下げた瞬間に、長期的、あるいは中期的でさえも、速度は失われるのです。

品質とは、速度を遅くするブレーキではなく、速度を維持し続けるための潤滑油のようなものです。

美しいコードは、未来の時間を創出する「機能」である

ソフトウェア開発における生産性とは、キーボードを叩く速さのことではありません。その根源は「美しさ」が生み出す無駄のなさにあります。

ここで言う「美しさ」とは、単なる見た目の良さや趣味の問題ではありません。ましてやエンジニアたちの自己満足でもありません。

たとえば、説明なしで他人が意図を理解できる「可読性」、未来の自分が迷いなく修正や拡張を加えられる「保守性」、そして複雑な問題を最もシンプルな構造に落とし込む「簡潔性」。

それによって「変更コストが極めて低い状態」を作り出し、ビジネスを推進する上での改良や改善、市場の変化に対して即座に対応できる「アジリティ（機動力）」が手に入ります。つまり、「美しさ」は極めて実利的な「機能」と言えます。

熟練者が初心者の１０倍、１００倍の生産性を出すと言われる理由は、指の動きが速いからではありません。彼らは「無駄な仕事（解読、バグ修正、手戻り、不必要な管理）」を発生させないからです。

「美しく書く」ことは、自分や仲間の「未来の時間」を創り出す行為です。逆に言えば、美しさを欠いた仕事は、誰かの未来を奪っていることになります。

生成AIという魔法の杖と、加速する「ゴミ」の量産

現代の私たちは、かつて持ちえなかった「生成AI」という強力な武器を手にしています。様々なツールが、定型的なコードを瞬きする間に生み出してくれます。

「AIがあれば、初心者の生産性もベテラン並みになるのではないか？」 そう期待する声も聞こえます。しかし、プロの視点から見れば、現実はむしろ逆です。AIの登場は、開発者の「練度」の差をより残酷に、より顕著に浮き彫りにしています。

初心者がAIによって生成されたままのコードを作ってきたとき、そのコードに美しさも意図もなければ、レビューする側の負担が大きくなるだけです。熟練者は、AIをキーボードの代わりのように扱うだけで、意図を込めたコードを生み出すことができます。初心者と熟練者の生産性の差は開くばかりです。

AIは、過去の膨大な学習データから「それっぽい解」を高速に提示します。しかし、AIはプロジェクトが１年後にどう変化し、誰がそのコードをメンテナンスするかまでは考えてくれません。

意図を持たず、ただ「動くこと」だけを目的としてAIに書かせたコードは、初心者の書く「解読不能なコード」を、より巨大なスケールで、より高速に量産するリスクを孕んでいます。１００行の解読不能なコードを人間が書くのも、１万行の解読不能なコードをAIに書かせるのも、それが「未来の時間を奪うゴミ」であるという本質に変わりはありません。

AI時代に問われるのは「書く技」よりも「選ぶ技」

AIは「作業」を高速化してくれますが、そのアウトプットが「美しい」かどうか、つまり「未来の時間を奪わないか」を判断する最終的な責任は、依然として人間にあります。

「もしAIが完璧に美しいコードを生成できるようになったら、この議論は成立しないのではないか？」

確かにAIの進化によって、コードの「可読性」や「簡潔性」といった客観的な品質は、誰もが一定水準で得られるようになるでしょう。しかし、その時でさえ、開発者の価値が消えることはありません。なぜなら、「美しさ」とは、単なるコードの整い方ではなく、常にビジネスの文脈と将来の不確実性の中に存在するものだからです。

AIが生成した「美しいコード」も、プロジェクトの進む方向が変われば、あっという間に負債と化します。どのコードを採択し、どのコードを将来の変更に耐えうる「資産」と見なすか。そして、そのコードにどのような「意図」を込めるのか。

むしろ、誰でも大量のコードを出力できるようになった今、かつてよりも高い「審美眼（目利き）」が求められています。

• AIが提示した複数の案から、どれが最もシンプルかを見極める力
• AIが見落としている「将来の不確実性」や非機能要件を補完する力
• AIが出したコードが、チームの規約や美学に則っているかを検閲する力

これからのソフトウェア開発者の価値は、「書く技」から「選ぶ技」へとシフトしていきます。

道具が魔法のように進化したからこそ、使い手である人間のセンスが、生産性を決める決定的な要因となるのです。この「審美眼」こそが、AI時代における「リスク管理能力」であり、損失を防ぐ専門性となります。

成長のステップ：機能を動かすことから、質を極めることへ

では、どうやって自分自身の成長を測ればいいのでしょうか。

初心者のうちは、動くものを作るだけで精一杯でしょう。その段階では、どうしても周囲の時間を奪ってしまいます。しかし、そこから技芸を磨き、熟練していくにつれて、仕事の焦点は確実に変化していきます。

それは、「動くものを作る（Function）」段階から、「美しく作る（Quality）」段階への移行です。

動くものを作る（Function）のは、プロとしての入り口、いわば「免許」のようなものです。しかし、ソフトウェア開発者としての本当の評価は、その先にある「品質（Quality）」で決まります。複雑な問題をどれだけシンプルに解いたか。その解法がいかに鮮やかで、後続のエンジニアを助けるものになっているか。

このステップアップに終わりはありません。品質はゼロイチではなく段階があります。内部品質である「美しさ」の追求こそが、技芸における成長そのものなのです。そして、その追求は単なる自己満足ではなく明確な価値を生み出すことになります。

その仕事は、他人の「時間」を創出しているか

最後に、個人の成長を実感するための具体的な問いを提示します。自身の仕事の結果を振り返り、以下の問いを立ててみるべきです。

「自身の仕事によって、チームメンバーの時間は増えただろうか？ それとも、彼らの時間を奪ってしまっただろうか？」

書かれたコードが、説明不要で仲間に理解され、その後の開発をスムーズにしたなら、それはチームに「時間」を提供した証になります。逆に、そのコードの解読や修正に誰かが追われたなら、それは時間を奪った行為となります。

自分の書いた「美しいコード」が仲間の作業を楽にし、チーム全体の生産性を高める。これは短期的な貢献ではなく、生産性のレバレッジを効かせる行為です。こうした「他人の時間を創出できる能力」こそが、熟練のソフトウェア開発者が持つ能力の本質です。

「良いソフトウェア」を生み出す「良い仕事」とは、単に自身のタスクを速く終わらせることではありません。後工程に負担をかけず、関わるすべての人を楽にする、美しい配慮と技能の集積なのです。

次回は、この「練度」の話に加え、もう一つの重要な成長の軸である「仕事の領域」へとテーマを移します。ソフトウェア開発者の仕事は、コードという「点」から始まり、いかにしてビジネスの「全容」へと広がっていくのか。そこには、役職を変えるのではない、独自の「ホロン構造」としての広がりがあるのです。