第9回　金勘定とエンジニア

さて、昔から「エンジニアと金勘定」というのはよく話題としてあがる内容です。先日はCTO48というイベントがスーツとギークというテーマで開催されましたが、まあそれも同じような趣旨だと思います。

エンジニアも金勘定ができるほうがいい！という意見があれば、金勘定を気にするエンジニアなんて駄目だ！という意見もあったりして、まあそんな私見同士の論争に首をつっこんでもしょうがないと思いますが、筆者は「絶対金勘定できたほうがいい」というのが私見です。

今回は、そんなエンジニアと金勘定にまつわる話というのを考えてみたいと思います。

金勘定が必要な理由（ワケ）

筆者は新卒採用された会社では元々エンジニア志望で、採用もエンジニアだったのですが、この性格が災いしてか（？⁠）⁠、入社前に社長に説得されて営業配属に変更になってしまいました。そこで2年ほど営業をやりました。年間5億くらいは売り上げていたので、営業の中でもわりとトップクラスの成績でした。そういう意味ではその会社の社長の読みは当たっていたのかもしれません。それはさておき、営業を経験したおかげで、数字（営業的な意味で）に強いエンジニアになることができました。

そういえば、金勘定以外でも筆者は「エンジニアはコミュニケーション力が高いほうがいい」という私見といか持論ももっているので、そういう意味でよく「エンジニアも1年や2年くらいは営業を経験したほうがいい。なかなかそんな機会はないけど」という話もよくします。

なんでそもそも金勘定できたほうがいいと思っているかについてですが、それにはいくつかの理由があります。

まずひとつ目は調達です。

エンジニアは機器やソフトウェアやシステムの選定をまかされるケースがあります。そういう場合、業者を呼んで要件を伝えて見積をもらう、という展開になります。

ちょっと気がきいていれば、複数業者を呼んで相見積りを取ろうとするでしょう。さらに気がきいていれば、一番安い業者の見積を他社に投げて値引きしてもらって、それをさらに他社に投げてということを繰り返して、1社以外ギブアップするまで続けると思います。

余談ですが、某データセンターで働いていたときに、サーバを500台調達するという件がありました。当時はまだ1Uサーバが登場したばかりで、各社とも気合が入ったセールスを展開していました。そのときの候補は3社ほどあったのですが、そのうちの1社がDELLでした。他2社はIDEモデルがあったために安い見積りだったのですが、DELLは当時SCSIモデルしかもっていなかったので比較的高い見積りでした。

もちろんSCSIのほうが活線挿抜（ホットプラグ）はできるし、パフォーマンスもいいというメリットがあるのですが、そもそも1Uサーバでフロントパネルからアクセスできないのに活線挿抜できてもしょうがないですし、またそのときの要求としては性能より価格だったので、DELLに対しては「SCSIがいいのはわかりますが今回は値段で決めます！(キリッ」と伝えました。

そのときDELLは1Uサーバを日本で販売したばかりで（他社もですが⁠）⁠、いきなり500台の導入事例というのはとても魅力的だったのか、なんとUS本社のマイケル・デルの決裁を得て、赤字覚悟で他社価格に対抗した見積を出してきました。もちろんその見積を残りの2社にぶつけたわけですが、他の2社はIDEで原価も低いため、対抗してさらなる値下げをすることができました。

というわけで、DELLに「他社がさらに下げましたがここまで下がりますか？」と聞いてみたところ、本社に問い合せた結果「マイケル・デルがすごく怒ってるので今回のコンペは辞退します」という回答でした。SCSIが安く買えれば嬉しかったのでちょっと残念でした。余談にしては長かったですね。

金勘定とかけ引き

さて、相見積りを何度も繰り返せば、それなりにいい値段にはなってきます。でもまだまだそれでも値引きの余地はあったりします。自分も営業をやっていたので、営業の心理というのは面白いほどよくわかりました。

今は知りませんが、その当時は、ネットワーク機器などはモノによっては50%値引きしてもまだ4割利益が出るようなものがたくさんありました。ちょっと上の世代の人だと「半値7掛け」という言葉を使っている人もいました。つまり35%まで値引きしてもらってようやく妥当ということですね。

まあこれはいちがいに言えることではないですが、ただ営業というのは、最初はたいがい値引き余地を残した提示をしてくるものです。長い付き合いをしていると、だいたい「あ、ここまでが値引きの限界だな」というのがわかってくるものです。そこで使った手としては、当時某S社で働いていたときのことですが、「⁠S社にこの製品が入ったということになればいい実績ですよ。他社にも販売しやすくなるでしょう。だからたとえ赤字でも元は取れるんじゃないですか」ということを伝えて、実際赤字だったかどうかまでは知りませんが、相当な値引きをしてもらったこともあります。まあこれは所属している会社がメジャーだったからできたことでもあります。

ただ、叩く（値引きする）だけでは関係が続かないので、いったん導入したあとはその担当の営業から継続して購買し（もちろん価格は引き続き相当頑張ってもらった金額でしたが⁠）⁠、その担当の人はその年の営業成績でかなり優秀な成績をあげることができたそうです。営業というのは、相手をハッピーにさせないと成功しないものですが、そういう意味では購買で叩くときも営業をハッピーにすることができると、それはもう素晴しい調達と言えるのではないでしょうか。

調達のとき、相手が何を求めているかというのを見抜くというのは重要なことだと思います。まあたいがいは粗利を高くしたいというのがほとんどですが、ケースによっては実績を増やしたい（その会社への実績を増やしたい、もしくは新製品の販売実績を増やしたいの両方）という場合もあります。そういう場合、そこでうまくトレードオフを成立させると、両者にとって良いディールにすることができます。

イノベーションをにらんだコスト把握

筆者が今まで手掛けた中でも、かなり効果の高かったケースをひとつ紹介しましょう。

某ISPにおいて、それまでメールサーバは普通のサーバにRAIDボックスを接続したものをたくさん使うという使い方をしていました。物理的に場所をとる構成だったために、1ラックで収容できるユーザ数があまり多くなく、メールサーバだけでラックを数十本使っているような状況でした。また、サーバ台数が100台超と非常に多かったため、故障はしょっちゅう出るし、OSパッチがあるときなどももう大変な状況でした。まだその当時は、業務系はともかくフロント系では巨大サーバや巨大ストレージにconsolidateするような使いかたはなかったのです。

そこで、主に業務系をターゲットにした新機種がHPから出たため、その機種とSUNのE4500の2つを性能比較し、またストレージも当時としては巨大ストレージ（SANではなくDASですが）を選定して、まったく新しいシステムを構築しました。

性能比較したところ、最初はE4500のほうがパフォーマンスが出ていたのですが、本来のCPU性能を考えるとあきらかにおかしい結果でした（ストレージの条件は同じ⁠）⁠。なんでだろうと思っていたのですが、当時Solarisはnscdというキャッシュデーモンをとっくに実装していたのに対して、HP-UX 10.xはまだそういう実装がなかったのです。

ところが、ちょうどその比較をしているときにHP-UX 11.xが登場し、11.xからはpwgrdというキャッシュデーモンが搭載され、この条件で比較したところ圧倒的にHPのほうが高速な性能を出すことができたため、結局HPにしました。このときも、HPの機種は戦略的な新機種であったため、導入事例が出ることがHPにメリットが多かったためにかなりのディスカウントを得ることができました。

今となってはというか、2000年くらいでは、メールサーバにおいてvirtual domainが作成できたり、認証にRDBやdbm系のバイナリDBを使えるのは普通のことですが、なにせ当時はsendmailやqpopperあたりにもまったくそのような機能もなかった時代です。POP before SMTPも、qpopper用で出回っていたパッチは外部processをforkするようなオソマツなものだったので、自分でqpopper自体を改造していました。また、virtual domainはchroot環境を使用して作成し、管理ツールなどもすべて自作でした。もっともこの数年後、sendmail社が商用の商品などを出してきたので、そのあとは商用の製品に切り替えたようですが…（そのときすでに筆者は転職していました⁠）⁠。

そしてその結果、数十本あったラックをわずか3本にすることができたのです。年間あたり数億円の削減をすることができました。ここで筆者が言いたいのは、この削減プランは業務指示が出たわけでもなく、筆者が自分からやりたいと思ってやったということです。まあ100台超のサーバをお守りするのは嫌だというのももちろんありましたが。

求められるのは「利益を生むエンジニア」

エンジニアというのは、より限られた条件で同じことを達成できるほうが優秀です。そしてその条件にはもちろん、予算という条件が入ってきます。

世の中のほとんどのエンジニアは企業で働いているでしょうから、何らかの収益のために活動していることになります。ということは、エンジニアの活動の目的の1つには、より利益を出すということが必然的に含まれているはずなのです。

そこをキリキリ追求しすぎても、またお金のことを気にしなさすぎでも駄目な気がしますが、いずれにしても金勘定ができ、かつそこまで考慮した行動を取ることができ、より厳しい条件でも目的を達成できるエンジニアのほうがいいに決まっています。

予算をじゃぶじゃぶ使って贅沢な環境を用意してシステム組むほうが楽なのは当然です。ただここで注意しないといけないのは、お金をたくさん使えば誰でもできるかといえば、それもまた違います。お金を山ほど使ってすら目的が達成できないのは論外です。ただ、同じ達成するのであれば、より費用を抑えてシステムが組めるエンジニアのほうが優秀だと言えるでしょう。

その実現方法は、前述した値引きや相手の意図を読むという営業的交渉術もあれば、これもまた前述したシステムを根本から見直してみる（サーバ費用でなくラック費用に着眼するなど）という方法もありますし、またなんでもかんでもDBではなくKVSを使ったり、SQSを活用して必要なサーバ台数を抑えるというのも重要です。

ほとんどのエンジニアは、値引き交渉で実現するよりは、技術力で実現するほうが良いと思う気がしますが、これらは別に排反背反するものではないので、両方やれば良いというのが正解だと思います。私見ですが。

また、もちろん技術力によって費用を抑えるときも、目的をちゃんと定めてやることが重要です。単に速くなっただけではなく（それも重要な視点ですが⁠）⁠、それによってどのくらい利益が増えるのかまで考えられれば最高でしょう。

またこれまでは、調達額を抑える側の話ばかりしましたが、もちろん粗利というのは売上から原価を引いたものですから、より売り上げが上がるという発想ももちろん有効です。それはパフォーマンス向上によるユーザロイヤリティの向上であったり、正しい冗長化によるシステムの信頼性であったり、クラウドなどをうまく活用したピークトラフィックの処理であったりするかもしれません。こういった点についても、単に技術的興味からだけ取り組むのではなく、それによってどういう効果があり、自身が関わるビジネスでプラスになるのか、というところまで考えられれば、これはとても素晴しいことだと思います。

今回は技術の話というよりお金の話になってしまいましたが、エンジニアとして必要な部分だと筆者が思っている重要な部分の1つの話でした。