CTO育成・支援「OCTOPASS」～番外編～では、講師にラクスル取締役CTOの 泉雄介氏（以下、泉氏）を招き、自身の経営経験や金融業界での経験をもとに今回は、特に経営におけるファイナンスにまつわる話を座談会形式で行いました。今回は、現役リーダー、CTO層のエンジニアが5名参加してくれました。
ラクスル株式会社 取締役CTO 泉雄介氏 プロフィール
長野出身。10歳の時に渡米。 ニューイングランド音楽院作曲科卒業後、メディア制作会社に勤務。作曲に携わる中で映像に興味を持ち始め、独学でシステム開発に目覚める。その後はシステム開発で起業し、アパレルECや航空券予約販売などの受託開発を経験。モルガン・スタンレー証券会社での債券取引のシステム開発や、ディー・エヌ・エーにおけるゲームプラットフォーム事業やヘルスケアサービス開発のリードエンジニアを経て、2015年にラクスルへシステム部長として入社。2017年10月同社取締役CTO就任。
エンジニアが経営視点を身に着けるのはそこまで難しくない
「ファイナンス、つまり『おカネ』のことですが経済活動をやっている上で切っても切り離せない重要なトピックなのにあまり誰も教えてくれませんよね。」と泉氏は語る。 今回出席したメンバーも、すでにリーダーやCTOという立場で何かしらの役割で経営を担っているが、改めて「お金の時間的価値」「複利の計算」などの基礎から「企業価値の計算」をスプレッドシートを使いながら淡々と説明する。「理論や数式に関しては、特に複雑なことはなく直感的だし、むしろエンジニアのほうが得意なのでは？」と泉氏は話す。経営陣が普段どのように経済合理性を考えながら意思決定するかを、エンジニアにわかりやすい形で紐解いていく。
ソフト開発も複利で考えるー
さらに、話はコーポレート・ファイナンスに進む。「コーポレート・ファイナンスは、資源が有限である前提で複数のプロジェクトがあった時に、どちらに投資すべきかということを判断するための一つの考え方。あるいは投資をしないべきかを判断をするのにも使える。この理論はソフトウェア開発にも同様に考えることができる。」と泉氏は続ける。ソフトウェア開発も投資と見立てると『どの機能から開発するべきか？』という判断にも関係するし、ミクロなレベルでは『今このテストを書くべきか』といった意思決定にも関係するという。
技術負債、どう経営者に伝える？
ソフトウェア開発におけるプロダクトマネジメントや、デザイン思考についてこう語る。
「多くの場合、ソフトウェア開発は、どうしてもやりたいことが多くなってしまい、計画の段階では100位やりたいことを書いてしまいますが、実際にプロダクトインする時は、半分以上は削ります。何故なら、この機能を仕上げる方が優先度が高い、市場に早くリリースする方が良いなど、今日話したNPV（Net Present Value)的な性質を持っているからです。例えば、100あるうちの３つの機能をリリースすれば、キャッシュフローが効率よく回るというのであれば、先にその３つのリリースします。その方が再投資できて、NPVが増えるという考え方ができます。『Low-hanging Fruit（少ない努力で簡単に達成できるモノ）』の考え方ですね。この優先順位をつけることがまさにプロダクトマネジメントにおいて最も重要なアクティビティーなのかと思います。
また最近では、UCD（User Centered Design）、HCD（Human Centered Design）などいわゆるデザイン思考という言葉がでてきています。今100作らなければいけないものを100作るのではなく、もっと小さなプロトタイプを作ることをやるというは、まさにこの理論です。小さく早くリリースして、失敗に気づくとトータルでミスが減る。それは、経営的には非常に良いことだと思っています。」
また、エンジニアを悩ませる「技術負債」についてはこう話す。
「これは最近、ソフトウェア開発の資産化をきっかけに新たに始めた試みなのですが、いわゆる技術負債に伴う『利息』を可視化したものです」
▼イメージ※実際のものとは異なります。
仮に、プロジェクトAとプロジェクトBがあり、それぞれのプロジェクトにおける開発のうち、どの程度積み上がりのある新規開発で、どの程度が運用保守なのかを記録していくと、やがて技術負債の大きさがどのくらいのインパクトなのかがわかると言う。プロジェクトAは技術負債が少なくどんどん開発が資産になっていくが、技術負債を多く抱えたプロジェクトBではいまの運用を継続するために開発が必要となり、最終的な利益が毀損してしまう。
「かなり極論ではありますが、このように技術負債が大きければ大きいほど保守にかかる費用がまるで本物の負債における利息を払う感覚になり、折角の実入りが利息の支払いで消えていっている、とも見えますよね」
技術負債も経営者の気づきを受けたかったら、このような数字をプロットしてみると良いかもしれない。「100%の力を持っているエンジニアの会社なのに、実際は５０%しか使えてないですよ」という気付きを与えるのも経営を担うエンジニアの役割だ。
最後に「経営者にソフトウェアというのはおカネがかかる事業であるー。ということを知ってもらうことが大切」と締めくくった。おカネがかかる事業＝投資であるという目線でお話すると、明日からの開発についてもより深く考えることができるのではないだろうか。
座談会を終えて
2時間にわたる座談会を終えて、参加者から感想をいただきました。
A氏：経営的な知識とソフトウェアの知識は持っていたつもりだったんですが、投資という考え方を持つことは重要だと思いました。 エンジニアはコードを書きたがる傾向がありますが、経営的視点をもって見ると、弊社の社長がなるべくコードは書かないほうがいいと言っていたことが腑に落ちました。
B氏：技術的負債について経営者に説明しても理解が得られず、交渉が失敗していました。今後、経営陣に向けた説明や交渉のはこれを活用していきたいと思いました。
C氏：案件整理をし、有意義なところにパーセンテージを広げていくかというのは良い考えだと思いました。
D氏：新規事業の場合、技術負債をどう見積もるか難しいなと思っていたため、「今日の講義がヒントになるのでは？」というものもあり、実践してみたいです。
Eさん：CFOから与えられたミッションについて話をする時、細かい部分を説明しても理解してもらえないという状況に困っていました。今後は向こうの言葉へ変換していきたいと思いました。
泉氏：技術と経営って接続させるのが難しいと思っていたんですが、皆さんの話を聞いて、深い理解をしていただいたこと嬉しく思います。 ただし、乱用はしないでくださいね。（笑）あくまで一つの見方ですから、引き出しの一つとして活用して下さい！
