第1回～第5回までの記事は「開発生産性の多角的視点 〜開発チームから事業経営に開発生産性を波及させるには？〜」からご確認いただけます。
6.1 その改善って儲かるの？
ソフトウェア事業を予算を元手に戦略と戦術で推し進めていく過程で、人件費は大きな構成要素になります。その人件費の多くを占める割合はエンジニアやデザイナーといったクリエイターになります。さらに、ソフトウェアという性質は無形資産であり目に見えないので不確実性を孕んでいます。
よくプロジェクトで言われる「進捗90％です」という言葉は、実際には目に見えないので嘘とも言えます。こうした事象をホフスタッターの法則とも言いますが、開発している途中はイニシャルコストとして人件費を消費しているだけであり、作っているコンポーネントやシステム同士が結合され、動くソフトウェアになることで始めて生産活動をしている証明となります。
そうした中で、ソフトウェア開発を取り巻く以下の生産活動が事業にどんな影響を与えるのかをエンジニアが説明責任を追わなければなりません。
- リファクタリングしたら、どう儲かるの？
- リモートワークにしたら、どう儲かるの？
- スクラムを導入したら、どう儲かるの？
- MVPで小さくしたら、どう儲かるの？
本当に証明するべきかどうかは別として、本質的には顧客が喜ぶ先にある、コストに対しての売上・利益への貢献依存度は考える必要があります。例えば、リファクタリングに関して言えば、PdMや事業責任者目線でもなんとなく良いことであるのは理解しているものの、どう良くなったのかはわからないことが多いでしょう。
こういった類のものは、エンジニアが説明責任をきちんと果たし、信頼を積み上げていくしかありません。リファクタリングで言えば「Dont refactor the code」という記事では、以下のように述べられています。
多くの場合、それは非常に重要な作業を意味しますが、理由もなく変数の名前を変更するような、怠けているのと区別がつかないこともあります。
これが私が「コードをリファクタリングするな」と言う理由です。あなたがしたこと、していること、またはしようとしていることについて話すときには、別の言葉を使いましょう。「リファクタリング」とは言わないでください。代わりに、以下の表現を試してみてください。
In many cases it means doing a really important work, but it's indistinguishable from almost-slacking-off, like renaming variables for no apparent reason.
And this is what I mean by "don't refactor the code": use different words when talking about things you did, are doing or plan to do. Don't "refactor". Instead try these:
こうした用語についても、価値をわかりやすい形で変換してあげることが重要になってきます。特にリファクタリングというのはいくらでも実施しようと思えばできるものではあります。きちんと言語化しながらやるべきリファクタリングを精査していくのが良いでしょう。
さて、ここから本題である「開発生産性を上げる改善」が事業に与える影響（儲かるのか）とその説明責任について考えていきましょう。
6.2 開発に影響がある管理会計（一部）
開発生産性が売上に与える影響を考えるにあたって、簡単に開発業務に関する管理会計を見ていきましょう。
損益計算書（P/L）と貸借対照表（B/S）の2つです。損益計算書（P/L）は、事業の一定期間における収益と費用の状況を示す財務諸表です。通常、事業責任者は一定期間の予算をもとに、P/Lと常ににらめっこしています。貸借対照表（B/S）は、バランスシートと呼ばれ、ある時点における財政状態を示す財務諸表です。
開発業務に関するP/Lを見ていくと、主にコストの部分です。わかりやすいところで行くと、人件費やサーバーコスト費用から始まり、その他ツール費用や福利厚生費や減価償却費が代表的でしょう。
一方、B/Sを見ていくと私たちが作っているソフトウェアは会社として「資産」として蓄積されていきます。資産・負債・純資産という項目に分かれていますが、現状ではそこまで深く理解する必要がありません。
