ソフトウェアサービスというのは、リリースした瞬間から、もっと言えば書いてリポジトリにコミットした瞬間から「コスト」を産み始める。
新しい機能を作りたいとき、われわれは既存の機能、既存のコードとの整合性をとる必要がある。そのため、「既存のコード」の量が多ければ多いほど、「新しい1行」を追加するときのコストは上がる。また、ライブラリアップデートやフレームワークのアップデートをするときも、「既存のコード」の量が多ければ多いほど作業量は増える。また、リリースされているのであれば、そのコードが使う計算資源は当然ランニングコストとしてかかってくる。また、顧客からの問い合わせの調査においても、コードの量が多ければ多いほど調査のコストは増える。つまり、あらゆるコードは「ランニングコストのかかる困ったもの」であるとみなすことができる。
では、なぜそのような困ったものが存在することが許されるのか。これは単純で、そのコード（あるいはシステム全体）で稼ぐ金額が、そのコードが生み出すコストよりも大きい（あるいは、大きくなることを見込んでいる）からだ。
そう考えると、「同じ価値（売上）が出るのであれば、より少ないコード、より少ない仕様であるほうがコストが抑えられて利益率が上がる」という当然の帰結が導かれる。導かれるのだけれど、この「当然のこと」というのはすぐに見えなくなってしまう、ということに注意が必要だ。
まず、「コードや仕様を追加するときに、自分たちがあらたなランニングコストを抱えようとしている」ということに敏感になりがちなのはソフトウェアエンジニアであることが多い。それは当然のことで、実際にコストがかかる作業をすることが多いのはソフトウェアエンジニアだから。一方で、「そのソフトウェアの仕様や機能で出る価値（売上）」に敏感なのはディレクターや営業であることが多い。これも当然で、売上の源泉である顧客のニーズを日々肌で感じる機会はソフトウェアエンジニアよりも多いだろうから。このとき、ソフトウェアエンジニアが顧客に無頓着で、ディレクターがコストに無頓着であったらなにが起こるのか。当然、「なんで価値が出ることをやりたがらないんだ」VS「またランニングコストだけが増えて行くのか」という対立構造になってしまう。そんな組織、腐るほどあるのではないかな。
これはまあコストとベネフィットの「要はバランス」ではあるのだけれど、要はバランスというときは「どこにバランスさせるのか」ということも同時に議論しないとなんの結論も進捗も出ない。ではどうやってバランスさせるのか。「同じ価値でも、このやり方のほうがランニングコストが抑えられますよ」ということについてはソフトウェアエンジニアのほうが詳しい。というかそうあるべきだ。一方、いま簡単に言った「同じ価値」について、ほんとうにそれが同じ価値の出るものなのかどうか、つまり顧客理解については、ディレクターのほうが詳しい（はず）だ。よって、バランスさせるためには、コストに詳しいエンジニアとベネフィットに詳しいディレクターが「ここでいう価値とはなにか」を同じ基準で、あるいは同じレベルの目線で話し、お互いの専門性を差し出しあう必要がある。
事業会社ソフトウェアエンジニアは、ソフトウェアを切り売りしているわけではなく、そのソフトウェアを使って利益をあげている。ならば、ソフトウェアエンジニアこそが１行のコードがうむ価値の収支を意識すべきだ。その収支のコストの評価をするためには、ソフトウェアエンジニアの専門性が必要なのだから。コストだけに目を当てれば、当然、ソフトウェアに閉じた工夫（なるべく保守性が高くなるようにソフトウェアの設計原則を意識して書く、計算量を無駄に増やさないようにする、など）も必要だ。だけど、それだけでは済まないことも多く、「そもそもこの仕様を削ればめちゃめちゃコスパが良くなるんだからそうしましょうよ」という提案も必要となる。このとき、「コスパが良くなる」の根拠は、少なくとも「コストが減る」「けど（ほぼ）同じ価値が提供できる」の二つが必要となる。そりゃ当然だ。コスト「パフォーマンス」なのだから。後者の「同じ価値が提供できるでしょ」を添えて議論しなければ当然「要はバランス」のバランスを崩してしまうことになる。ソフトウェアエンジニアとしては無頓着になりがちな「価値」の話をきちんと理解し、提案する力が必要となるはずだ。
ただ、この「価値」ってのがけっこうややこしくて、「だってお客さんが欲しいって言ってるじゃん」みたいな話に終始すると、価値の見積もりが不可能となってしまう。どんなものでも「やるべき価値のあること」になるので。一番ダイレクトな問いは「それって、それをやることでどれくらい売上に効くんですか」となるだろうけど、あまりにダイレクトすぎて顧客目線から遠くなっちゃうこともあるので、プロダクトごとに、合意された「価値の見積もりの基準」が作れると良いだろう。その基準さえあれば、それぞれの専門性を持ち寄った上で「コストかけてやる？ やらない？」を納得感もって決断することができるはずだ。それが、結果的に企業としてもユーザーとしても従業員としても嬉しい結果につながるはずだ。
ここから先は余談。成熟したチーム、あるいは互いに高いプロフェッショナリズムを持ったチームは明文化しなくとも、基準が存在していると感じることがある。じゃあ未成熟なチームはどうするべきかって考えた時、パッと思いつくのは「じゃあ基準を明文化しましょう！！ そのためのワークショップをやりましょう！」とかになるんだけど、これはあまり機能しないと思っていて、なぜならば漏れのある抽象化の法則が発動し、ルールとして作った基準は常に個別の事例に対して不足するから。わたしは必要なのはルールではなく文化の醸成である、という立場をとっていて、どうやって文化を醸成するのかと言ったら、ソフトウェアエンジニア側からで言えば、嫌がられても臆せず敬意をもって「これユーザーにとってはどういう価値なんですか？ 教えてください！」「わかんないので一緒にユーザーのところ行かせてください」というように「こっちがそっちの基準をまず理解しにいくよ！」という行動を取り続けることでボトムアップで変わって行くしかないのだろうと思う。
