コストなんかかからなければかからないほうが良い。一方で、なにかをするためには資本（金、時間、労力）を投下しなければならない。そんなわけで、どこもぶち当たる課題「コストをなるべくかけず高い成果をあげたい」という話が生まれる。
しかし、これだけではなにも言っておらず、「ではそもそもわれわれにとって成果とは？」ということをまずは定義しなければならない。利潤を追求する企業であれば成果というのはとうぜん最後は「利益です」になるのだけど、それだと日々の生活との距離が遠すぎるので、もう少しブレイクダウンされたものが必要となるだろう。ここはじつはビジネスの構造、ビジネスモデルによって何が成果であるか決まってくる。あえてめちゃめちゃ単純化して、「書いた行数がそのままお金になります」というビジネスであるのであれば、書いた行数を成果として定義すればよいとなるけれど、現実の世界はもうちょっと複雑で、「われわれにとっての成果ってなんですか？ なんの指標で測りますか？」という問いには一生懸命答えないといけないことが多い。この「われわれはこれを成果とします」という宣言がチーム、あるいはその上位概念と合致していない場合、まずはそこの認識を合わせることから考える必要がある。
話を少し変えて、「開発運用に関するコスト」について。開発に関するコストは、いくつかの視点によって整理することが可能だが、今回はソフトウェアエンジニアがコントロールできる範囲と、それを、どのように拡張していけるのかに注目をしたい。なお、本記事では話をわかりやすくするために事業会社のソフトウェアエンジニアリングをスコープとし、受託開発はスコープとしない。
さて、コストの圧縮で、なおかつソフトウェアエンジニアがコントロール可能なものとして一番わかりやすいのは、ソフトウェアの機能的な振る舞いに影響を与えずに計算資源を節約することだ。具体的にいえば、たとえばN+1を無くしていく、スロークエリを無くしていく、オートスケールやscheduledなスケールアウト、スケールインを適切に使う、など。そうすることで、単位あたりの計算資源で捌ける計算量が増えて行き、「そもそもDBのスケールダウンができるかも」「appサーバー減らせるかも」ということにもなるし、同じ量の計算資源で捌けるユーザー、トランザクションの量がふえ、「ユーザーが増えたらそのぶん計算資源のコストも増える」というその増え方を抑制することができる。つまり、計算資源に注目した時、低コストで同じ"成果"を、あるいは、同じコストでより高い"成果"を実現できるわけだ。
では、どういう条件がそろえば、ソフトウェアエンジニアがこのコストをコントロール可能になるのか。その条件はパッと思いつくだけでもいくつかある。組織的な話としては、ソフトウェアエンジニアがそのような仕事をすることが許される組織であること、言い方を変えると人的資源をそこにきちんと張るという意思決定がなされている必要がある。また、テクニカルな話として、システムのオブザーバビリティがお粗末である場合、「そもそもどこを改善したらいいかわからない」となってしまうので、こちらも条件となるだろう。これらの条件は「どちらも満たされている」ことが重要で、オブザーバビリティを向上させるぞ！ といってAPMを導入したが、改善のための労力は投入しません、となる場合、「観測されるべきものがすべて垂れ流しになってむしろコストばかりかかっていく」という悲しいことになってしまう。これけっこうドキッとする現場多いんじゃないかな。
この問題のむずかしいところがまさにここにあって、「機能的なふるまいに影響を与えない」ということが、一見すると「価値を生んでないじゃん」に見えてしまう。「価値を生まないところに資本を投下するわけないじゃん、むしろそこはコストカットしていこうよ」となり、「計算機資源を節約するための仕事」は、最悪の場合着手されず、よくても「やすいところに運用をまかせちゃおうぜ」となってしまう。こうなると、「運用」を任せられた側は計算機資源を節約するメリットはべつにないので、結果として放置されてしまう。また、計算機資源の節約というのはそのビジネスの特性とほんとうは深くリンクしている（夜中にどれくらい使われることがあるシステムなんだろう？ クリティカルなユースケースはなにで、そこはちょっと富豪的に守らないといけないけど、べつにクリティカルなユースケースじゃないところはギリギリを攻めて節約していいよね、とか）のだけれど、それらのリンクが断ち切られてしまうことになる。
「そういう仕事に時間や人間を張れるか」というのは、ありていに言うと「上がちゃんと考えてくれるか」にかかっており、いちエンジニアが直接変えることができないことも多い気がする。が、「言うだけタダ」なんで、この記事を添えて「こういう問題うちにもありますよね」って言うくらいはタダかもね、とは思います。
いまは計算機資源の話をしたけれど、他にもプロダクトの価値を下げないまま「そもそもの開発にかかるコスト」を下げるためにソフトウェアエンジニアがむしろ機能的な要件にコントロールの範囲を伸ばしていくべきである、という話がある。ここは「複利で効いてくる」ものなので重要な話になる。さらに、それを複利で聞かせるために組織が、あるいはテクニカルにどういう条件を満たす必要があるのか、という話題、そのコントローラブルな範囲を増やせる組織であるためにソフトウェアエンジニアの観点からなにをすべきか、という話に進んでいくんだけど、すでに結構な量を書いているので今日はここまで。ブログなのですきなときに書いてすきなところでやめるのだ。
