ソフトウェア開発の予測と記録と資産〜プロジェクト失敗率 69%の壁〜

この記事は、DMMグループ Advent Calendar 2022の1日目の記事です。

こんにちは。DMM.comの石垣雅人(@i35_267)と申します。
普段は、プラットフォーム事業本部の部長をしながら、VPoE室を兼務しております。

去年のDMMグループAdventCalendar 2021では、事業とエンジニアリングを接続していきながらプロダクトをスケールさせる方法について寄稿しました。

事業をスケールさせるエンジニアリング〜技術のコモディティ化にエンジニアは敗北する〜｜inside.dmm.com

今年は、もう少し実働的な部分でソフトウェア開発の開発プロセス・プロジェクトの進め方について述べていきたいと思います。

想定読者は、複数のチームを巻き込んだり組織の中で比較的大きなプロジェクトを担当しているプロジェクトマネージャーやプロダクトマネージャー、エンジニア、デザイナーを想定しています。

DMMグループは、エンジニアの数が1,000名以上おり事業数も60を超えるため、ダイナミズムな施策が企画されると数十チームを巻き込みながらプロジェクトを進めることがしばしばあります。その中で経験した安定したプロジェクトを運用する勘所についてご紹介できればと思います。

数字で見るDMM｜DMM Group

 

プロジェクトの失敗率は、約69%

東証一部上場企業とそれに準じる企業の計4499社を対象とした調査結果である、企業IT動向調査報告書 2022によると、プロジェクトの失敗率は極めて高いです。

「工期」「予算」「品質」の3つのカテゴリーで分け、プロジェクト規模を「100 人月未満」「100~500 人月未満」「500 人月以上」で分類したデータを見てみます。

ここでは、21年度の数値かつ100人月未満のプロジェクトデータを要約します。

• 工数に関して、予定通りに完了した割合 : 34.4%
• 予算に関して、予定通りに完了した割合 : 37.0%
• 品質に関して、予定通りに完了した割合 : 23.0%

3つの割合の平均するとおおよそ31%前後になります。

逆を返すと何かしらの原因で満足いかない可能性が約69%あるということです。 さらに、工数・予算・品質のすべてが予定通りに終わる確率は、工期（34.4％）× 予算（37.0％）× 品質（23.0％）で約3%です。

もちろん、このデータは事業環境の違いや目標とする工期・予算・品質の違いはあるにしろ、工数・予算・品質のどれも落とさずに成功プロジェクトは、自身の経験と照らし合わせても約3%というのはあながち間違っていないと思っています。これは、工期が「100 人月未満」→「100~500 人月未満」→「500 人月以上」と増えるごとに数値が悪化していきます。

引用 : 図表 7-3-1 プロジェクト規模別・年度別 システム開発の工期遵守状況(https://juas.or.jp/cms/media/2022/04/JUAS_IT2022.pdf)

 

引用 : 図表 7-3-2 プロジェクト規模別・年度別 システム開発の予算遵守状況(https://juas.or.jp/cms/media/2022/04/JUAS_IT2022.pdf)

 

引用 : 図表 図表 7-3-3 プロジェクト規模別・年度別 システム開発の品質満足度(https://juas.or.jp/cms/media/2022/04/JUAS_IT2022.pdf)

原因は、計画・仕様・システムの不確実性

どうして予定通りにならなかったのか。についても調査されており、その多くは計画時の考慮漏れや仕様変更の多発、システムの複雑性が挙げられています。 100人月前後のプロジェクトの計画をはじめから考慮漏れがなくするのも難しいですし、プロジェクトの途中での仕様変更も含めて不確実性コーンの話が発生していきます。

引用 : 図表 7-3-4 予定どおりにならなかった要因(複数回答)(https://juas.or.jp/cms/media/2022/04/JUAS_IT2022.pdf)

よくある失敗

あらゆる不確実性が高まっている中で、よく見る失敗例を述べていきたいと思います。

1. 同じ失敗を繰り返している

大きな組織にいたり、仮説検証サイクルが早い現場にいると、常日頃複数のプロジェクトが回っており自分自身も今まで何十個ものプロジェクトを経験してきました。 その中で、デジャブのように「こういったこと前にもあったな」という場面に出くわします。 プロジェクトに関わっているメンバーも違えば、意思決定する人も違うので組織として失敗と成功のノウハウが溜まっておらず、同じ道を歩んでいきます。

2. 超大作な失敗をする。小さく失敗したい。

これは、レポートラインの問題で、正しく情報が流れてこないと現場で情報が溜まってしまい、重要なことが重要だと判断できなくなると蓋を開けてみたら、どうしようもできなくなりプロジェクトを終了させるケースです。大きな予算をかけたが、何もアウトプットがないという状態が一番つらいです。

課題は、時間が経てば立つほど深刻化していくため、小さい課題が雪だるま形式で肥大化していき、解決するにも時間が指数関数的にかかっていきます。できるだけ小さい課題を高速に解決していくサイクルが理想です。

技術的なリノベートも同じ文脈で、リファクタリングを怠ったり内部品質（テストがない等）が低い状態で、どんどん機能追加をするとスピード感でも限界がきます。（Is High Quality Software Worth the Cost?） もとのスピード感を取り戻すために、再度多くの時間と予算、その間に開発できたであろう新規機能分の利益も失います。

3. 上流工程が、なかなか終わらない

プロジェクトの途中であっても、要件定義完了デットラインが決まっておらず、次々に仕様が変わったり追加されたりするパターンも多く見ます。 特にエンジニアサイドの開発スケジュール、ソフトウェア開発の勘所が浸透していないと、どんどん足し算で「あれもほしい」「これもほしい」という状態が蔓延してきます。 それ自体は悪いことではありませんがとりあえず動くものを作り、そこから機能を追加するなどフェーズの考え方が必要になります。

どうしていくべきかの考え方の提案

プロジェクトを進めるにあたっての課題は現場ごとに沢山あるかと思いますが、ひとつの解決策に近いアプローチとして予測→記録→資産があると思っています。

プロジェクトごとに目標値を予測しないとスピード感を意識が薄れてきますし、プロジェクトのプロセスをプロットしていかないと後から振り返りができません。 資産というのは、いわゆるノウハウという意味です。 きちんと、ソフトウェア資産計上を行うタイミングでそのプロジェクトにかかった工期・費用を振り返り、プロジェクト途中に発生した事象をプロットしてパターン化していく。それを次に活かす。 というサイクルを回すことで少しでも、同じ失敗をせずにかつ良いパターンはどんどん学習に使っていくことが大事になってきます。

予測して、記録して、資産化する

 日々、プロダクトをアップデートするためには、年間を通しても複数のプロジェクト、仮説検証を推し進めることが必要ですが、その多くは予測から始まります。 その予測が目標値になり、のちの記録と資産へつながっていきます。
予測の基本は、要件定義（PRD・DesignDoc等）を確定させ、WBSやロードマップを作成し、見積もりを行い工数を算出、目標リリース日を設定し（設定されている）、そこに達成するために必要なリソース調達やリスク管理を始めることで準備が完了します。

さまざな現場や自分自身の経験と照らし合わせても、ここの初期計画（予測）があいまいのまま進めると、そのあとのプロジェクトを記録して評価する（資産化する）プロセスができなくなるために成果物を「作って終わり」という事象が発生したり、「前にも同じ失敗してなかったけ？」という現象が組織の中に蔓延してきます。

逆を返せば、予測をすれば予測する意味を考えるようになるため、記録するというフローに進めます。プロットしていくと言っても良いです。 記録については、マクロな部分ではBPM（ビジネス・プロセス・マネジメント）といったプロジェクごとのIDを発行して、ソフトウェア開発の開始からリリースまでにかかった人件費を資産計上し、リリース時点から減価償却を行い、プロセスを記録してソフトウェア資産計上を行うための記録であったり、もっとミクロなエンジニアリングに近い部分で開発チームでは、プルリク作成からマージまでのブランチ生存時間を計測したり、広範囲に及びます。ソフトウェア開発のプロセスのすべての可観測性を向上させ、観測可能にすることが大事になってくると思います。

最後に、予測し、実測値を記録した後は、評価をして学習するフェーズに入ります。 予測をそのプロジェクトの目標値として設定して、実際の活動を記録しても、そのあとに学習や利活用ができなければ意味がありません。 次のプロジェクトを進めるあたって過去のデータを引っ張ってきて再度予測に使ったり、膨大なプロジェクト記録が組織に集まれば、良いアセットになります。 開発したソフトウェアを資産として資産計上する過程で学習したり、個別最適化で色々なフォーマットで評価していきます。

これより、「予測」「記録」「資産」について個別に述べていきます。

1. 予測

ソフトウェア開発の予測から見ていきます。

予測とは、あらかじめ推測することや推し量ることを意味します。
ソフトウェア開発の予測を考えていくと、ぱっとイメージするのはプロダクト戦略を実現するにあたって、アドオンするべき機能や改善するべき事象が、いつユーザーに届けられるかでしょう。

昨今は、スモールチームでのアジャイル開発が主流なので1~2週間をサイクルタイムとしてベロシティートラッキングなどを使って提供できる成果物（インクリメント）の時期感を予測します。 基本的には、その周期の積み上げで特定の形をもったソフトウェアや機能、改善を作りリリースしていきます。 それとは別にダイナミズムをもったインパクトや影響範囲が大きい企画を遂行しようとすると複数チームを1つの集合としたプロジェクトマネジメントになります。ここはスモールチームでの開発予測とは別の頭の働き方をしなければいけません。

ただし、プロジェクトを始める前の初期計画に時間をかけるのは不確実性が高く本質的ではないため、あくまでもフェーズを切るなど初期予測をしやすい単位でスコープを切ることをお進めします。
つまり、1年後や2年後の工数出しをこの時点でするのが難しい場合が多いため、フェーズを分割して1週間や1ヶ月の単位で予測して学習を転がしていきながら全体の不確実性を下げていきます。

1.1 ミクロな予測（スモールチームでの予測）

規模の違いはあるにしろマイクロサービスと開発チームが、1 : 1 にしていることことが多いです。その1つ1つがアジャイルチームの中で、ある程度アジャイルの思想に乗っ取り、予測をしていくのが通例ではあります。 身軽な開発プロセスを選択し、小さく物事を捉えることで変更の予測をあげていくことで変化に強いチーム・プロダクト・プロセスを作っていきます。

予測という面では、一番イメージしやすい「見積もり」のプラクティスも沢山あります。
アジャイルは、短いイテレーションを選択し、極力不確実性を減らし変化に強い方法を取っている中での予測になるため、そこまで正確な見積もりというよりかは、動かしながら軌道修正をしていくという考え方でしょう。

アジャイルにおいて「見積もりをする」という行為には「見積もりの精度を高くする」ことが目的ではありません。
「信頼を獲得する」「意思決定をする」という2つの目的のために行います。

そこを忘れてしまうと「見積もりが精度が高い。ベロシティーが安定している！」ということに満足してしまいます。 本来はそこが目的ではありません。

「意思決定をする」とは、何を意思決定するのかというとアイテムの優先順位を決めていく。 もう少しいうと「アイテムの価値（消化したときのインパクト値）」と他アイテムとの相関関係を考えた上での「ボトルネック」に探りを入れることで、同時にアイテムの優先順位をつけていきます。

例えば、Aというアイテムはスプリントゴールを達成するためには必須の機能（価値）で、これを完了させることで後続のアイテムが出てくる（他アイテムの相関関係）、かつAというアイテムは時間がかかるという制約が見れれば、自ずと優先度をあげて対応するべきものとわかります。 そうした判断材料の1つとして見積もる。 そして、見積もりと実際の結果の「予実」から学習していきます。

言い換えれば、見積もりは必要なく、決定を下すのが目的です。

もうひとつの「信頼を獲得する」とは、プロダクトオーナーやステークホルダーから、チームへの信頼です。 ここに関しては見積もり = 計画の予測という文脈になりますが「このチームは計画どおりに開発できるのか」「生産性はどうか」といった疑問に対して、見積もりの精度をあげることで、信頼を獲得していきます。

ここでは、見積もりの方法として3つ紹介します。

1. ポイントでの見積もり
2. 時間での見積もり
3. No-Estimate

以下の記事をベースに抜粋していきます。

見積もり（Estimate）をしない。絶対しない。｜medium.com

1. ストーリーポイント見積もり

ストーリーポイントとはユーザーストーリー（プロダクトバックログアイテム）を見積もるための架空の単位です。
つまり、作業量の定量化です。 ストーリーポイントは、何に対して見積もるのかというとストーリーが「完了」するためのすべての作業に対して見積もりです。

ユーザーストーリーが実装されたということは、ユーザーに提供できる状態であり、もちろん本番の環境で利用可能であるということです。

見積もりの方法として、一番有名なやり方としてフィボナッチ数列の値で表現するやり方があります。 フィボナッチ数列は、1,2,3,5,8…等で表現していきます。 これは、相対見積もりの一種でアイテムの「重さ」を表しています。 架空の単位なので、チームメンバー間での限定した価値間の単位です。 この手法の肝となる部分は、圧倒的なサンプル数による相対的な見積もりであることです。相対的なサイズの比較と言っても良いでしょう。

Aのアイテムに対して開発チーム全員で各々が思うストーリーポイントを提示していきます。 このときに「前回のスプリントで行った作業と同じぐらいの重さで、このチームでの「2」とつけたから今回も 「2」でいこう」という経験知から来る提示を各々が行い、それが開発チーム全員の共通認識として合うかです。

その次にBのアイテムを見積もる際に、Aのアイテムの大体2倍ぐらいの作業量がありそうだということで「4」をつけると言った形で、バックログアイテムに対して見積もりをつけていき、このストーリポイントの合計値が、次のイテレーションでアジャイルチームが消化するべき生産性の指標となります。

一方、単位が架空なので、そのチーム限定の価値観でもあります。チームが解散して他チームでもう一度アジャイルプロセスを構築しようとすれば、また1からそのメンバーと価値観を作り直していきます。 つまり、イテレーションを始めた頃は、ポイントによる見積もりは価値観の積み上げがないため、精度は低くなるケースが多いです。

2. 時間での見積もり

次に時間見積もりです。 これはシンプルに作業量から見て「何時間かかるか」という単位で見積もっていきます。

いつもストーリーポイントでの見積もりを比較され、エンジニアのスキルの差から完了目処にばらつきがでてくるなどの理由で、牽制されがちが見積もりです。AさんとBさんではスキルに差があって、終わる時間も違うだろうとことです。

ですが、チームが成熟していれば、意外と有効な見積もり方法です。 なぜなら「時間」というのは、全員が統一してもっている価値観だからです。1時間の認識は、全員同じ1時間です。スキルの差などによるズレは会話をしてコミュニケーションを取ることで補えます。 ストーリーポイントはある意味、皆の頭の中にある空想の単位なので全体が統一された価値観を持っているかは確認仕様がありません。

何事も「単位」が揃っていることは大事です。

3. No-Estimates（見積もりをしない）

ストーリーポイントや時間による見積もりの課題としてあるのが、プランニングの時間が長くなる傾向にあることです。 ひとつひとつのアイテムに対して開発チーム全員で見積もりをしていき、ズレがある場合にはそこで議論が始めるため時間が長くなります。 特にアジャイルチームが組成されてすぐの形成期や混乱期では、各々のスキルレベルや価値観も違うためズレが発生し議論も発熱していきます。

一方、チームが成熟してくると見積もりをするという作業が必要なくなる傾向があります。 いわゆる、開発チーム全員が思う、各ストーリーポイントのイメージが統一されている状態です。 例えば、ストーリーポイント「3」をつけたアイテムの作業量やアウトプットの量、質ともに全員の頭の中が一致しており、この領域までチームをもっていければ、かなり自己組織化しているに等しい状態です。

ひとつひとつのアイテムに対する作業量・質の感覚的な暗黙知が開発チームのメンバー同士で共有できている状態です。 これは、形式的に頭ではわかってやろうとしてもなかなかできないことでアジャイルチームとして、近い距離で暗黙知を高めながら開発を進めたことによる賜物でしょう。 そのため、チームが成熟していない状態で導入しても、統一された暗黙知がないため生産性が安定せずに予測が難しいです。

見積もりをしないアプローチのことを「No-Estimates」と言います。 これは本来「見積もりをするな」ということではなく「見積もりに踊らされるな」というメッセージです。 アジャイルに限らず、開発することで大事なのはベロシティーをあげることではなく、ユーザーに価値を届けることです。 No-Estimatesにおける生産性の指標は、消化ストーリーポイント数ではなく、消化アイテム数になります。 そのため、チームが一番作業しやすい粒度の作業量のイメージを共有して、ひとつのアイテムを作成するようにします。 例えば、ひとつのアイテムはストーリーポイントが「3」ぐらいのイメージで作成しましょう。という認識が取れていれば、生産性をアイテム数で計算しても認識が合います。

以上が、見積もりでの予測アプローチの例です。 ちなみに、アジャイルソフトウェア開発宣言の発起人である Ron Jeffries氏は、ストーリポイントでの見積もりを後悔している※ という風にも言っていたり、No-Estimateがだんだん浸透してきた印象を受けています。

※ Story Points Revisited (https://ronjeffries.com/articles/019-01ff/story-points/Index.html)

引用文献

• 見積もり（Estimate）をしない。絶対しない。(https://medium.com/i35-267/aeee1dadec7f)
• Story Points Revisited （https://ronjeffries.com/articles/019-01ff/story-points/Index.html）
• NoEstimates Part 1 — Doing Scrum Without Estimates（https://neilkillick.medium.com/noestimates-part-1-doing-scrum-without-estimates-b42c4a453dc6）
• NoEstimates Part 2 — Contract Negotiation and the Old Banger（https://neilkillick.medium.com/noestimates-part-2-contract-negotiation-and-the-old-banger-3f7e61e7ffd7）
• NoEstimates Part 3 — The Palm Off（ https://neilkillick.medium.com/noestimates-part-3-the-palm-off-5bf38a4c0118）

1.2 マクロな予測（チームの集合体での予測）

次にこうしたアジャイルチームがタスクフォース的な動きをするプロジェクトの予測についてです。 対象プロジェクトを担当するリーダーが、個別のアジャイルチームの情報をすべて把握しているわけでもなく、コントロールができるわけでもありません。 そのため、きちんと 流れてくる情報・フォースを設計 してレポートラインをしっかりして作っていく必要があります。下図でいう右側になります。

1.2.1 流れてくる情報・フォースを設計する

体制構築

体制面でいえば、DMM.comは約60事業ある中で、例外はあるにしろそれぞれが事業が事業部制やカンパニー制を取る独立採算的なアプローチを取っている組織体制です。 そのため、このような複数チームや事業部に跨ぐ際は、タスクフォース的に一時的にプロジェクト化していき体制を組んでいきます。

一般的な体制の例はこちらです。

• プロジェクトのオーナー（PO・PdM）
• プロジェクトマネジメント（PM）
• 各システムの担当プロジェクトリーダー（PL）

を選出していきます。

その上でそれぞれの期待感、コミュニケーションルートの確保や意思決定機関の決定、プロジェクトコードなどを発行などをしていきます。 ここに抜け漏れがあると、 正しく情報が流れてこなかったり独自の解釈で意思決定が走るとプロジェクト全体が混乱するためレポートラインを握っておきます。

1.2.2 リソースマネジメントを意識する

そこから、各チームのプロジェクトリーダーにしてもらうのが以下の4つです。
PRDの作成は済んでいる想定で、例ではリリース日は色々な事情で固定で決まっているものとします。
※ 数値はすべて仮です。

1. 超概算工数の算出
2. 工期の算出
3. 人的リソース資源の算出
4. リソースマネジメントの確認

1. まずは、超概算でも良いので工数を算出してもらいます。
   PoC（Proof of Concept）やMVP（Minimum Viable Product）なども考えるため、プランAとプランBなど基本は複数出しそれぞれの工数算出を行います

2. 様々な戦略・要員の中でリリース日が決まっているとして、間に合うようにするための工期（スケジュール）を記載してもらいます。

3. その工期に間に合うようにするための開発人数を記載してもらいます。付随して、ここで費用感も確認できます。チームによってはイテレーションの切れ目が違ったりするので厳密にすると、工数 / 対応人数 = 工期にはなりませんがわかりやすく例ではそのような計算式にしています。

4. その上で、現チームでの不足メンバーがいれば、リソースマネジメントをしながらチーム間で開発リソースの課題を解決していきます。

1.2.3 意思決定を早めるための工数・工期・費用の超概算

図の例では、プランがAとBがあります。

• プランAは、売上リフトアップが約1億円という仮説がある。開発リソース的にも不足分は5人とリソースマネジメントや各チームでのPriorityの変更でいけそう

• プランBは、売上インパクトは大きそうだが工数が約数倍かかり、12/1をリリース日とすると開発リソースが足りない

と言った形で、どちらを選択するのかは別として意思決定するための材料として算出します。 また、ここでの見積もりは超概算で問題有りません。意思決定に利用したり規模感把握がメインなので時間を大幅にかけての見積もりは必要はなく、だいたい、50~60%の精度で良いでしょう。

目的は、いち早くプランAなのかプランBなのかを判断するため です。

こういった形で、予測 = 目標値ができてくると次は、プロジェクトを進行しながら記録の作業を行っていきます。

 

1.2.4 予測 = 目標値の妥当性

この目標値についても、単純に今の開発チームが出した工数 = その組織の限界となるため、スタンダードなデータも確認しながら予測には使っていきます。

例えば、JUASが出しているスタンダード的な考え方を紹介します。 これを参考にしながら、いまの開発チームを評価しても良いと思います。

ソフトウェアメトリックス調査・IT運用コストメトリックス調査 | JUAS 一般社団法人 日本情報システムユーザー協会

この中にある、PDFから抜粋していきます。https://juas.or.jp/cms/media/2020/05/20swm_pr.pdf

工期の計算式としては、調査結果によって変わるが大きくは以下の式になります。

工期 =2.70 x 工数の3乗根

例えば、10人月であれば、工期は5.9人月となります。

引用 : https://juas.or.jp/cms/media/2020/05/20swm_pr.pdf

費用については、全体工数に対して、117万円をかけていきます。

10人月 x 117 = 1,170万円（費用）

引用 : https://juas.or.jp/cms/media/2020/05/20swm_pr.pdf

これを高いとおもうのか低いと思うのかは目的やリターンを意識した上での判断なのであくまでも参考値として使います。 特にソフトウェア開発は、すぐに速効性がある取り組みだけではなく、システムの刷新などは1年後、2年後の開発速度を見越して、いまのタイミングでやるという判断もできます。

こうした形で、うまく今の組織と比較しながら、向かうべき目標値を作っていきます。 大事なのは、実績値の積み上げで同じ開発メンバーで、複数のプロジェクトを実施するときは、予測値よりも実績値のほうが参考になるため、予測→記録→資産の流れを作り、実測値から新しいプロジェクトが始まるときの予測値（工数・工期・費用）を作り出すのが利用だと思います。

引用文献

• ソフトウェアメトリックス調査2020 システム開発・保守調査（https://juas.or.jp/cms/media/2020/05/20swm_pr.pdf）
• なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか（https://qiita.com/hirokidaichi/items/7f7f7881acba9302301f）
• ソフトウェアPJの工期は工数の3乗根に比例する数式を理解する（https://qiita.com/yaju/items/175a54427800840e15d0）

2. 記録

ここでいう記録というのは、ソフトウェア開発の活動をトラッキングしていきながらプロットしていく作業です。

本記事では、大きく分けて2つの軸で述べていきます。

• 工数管理からの資産計上する上で必要な記録
• 開発チームの戦闘力を定量化するための記録

2.1 工数管理からの資産計上する上で必要な記録

BPM（ビジネス・プロセス・マネジメント）的な目線でいうと、ソフトウェア開発に関する工数を管理する上で、それをどのツールでどの粒度でトラッキングしていき、特定機能を作るにあたって紐づく人件費やその他費用を可視化していきます。それは最終的にはソフトウェア資産計上を行ったりするのに利用していきますが、詳しくは「資産」のパートで述べていきます。開発中のステータスでは資産化できていないのでソフトウェア仮勘定というステータスで計上したりします。

フローの例としては以下の手順を踏むことが多いです。

1. プロジェクトが開始するときには、新しいプロジェクトコードを発行する
2. 毎日の勤怠と紐付ける形で、対象プロジェクトコードにかけた時間を入力
3. 月1やプロジェクトが完了時に数値を確認し、最適化していく

下図は例ですが、DMMでは毎日の勤怠入力と同時に「今日1日、何にどのぐらいの工数をかけたか」を入力してもらっています。 これが最終的には、会社のBI（ビジネスインテリジェンス）ツールなどに蓄積されていきます。

ここで肝となるのは、トラッキングするタイミングとデータ設計です。
例えば、Project-Aの成功を望んでいる中で、できるだけ開発チームの無駄な作業を減らしてProject-Aに対する有効稼働率を増やしたいと思ったとします。有効稼働率とは、文字通り有効に稼働できている時間のことですが、ここでは開発者が開発に当てられている時間のことを指します。

その場合には、有効稼働率を基準に取得したデータを設計していって、開発作業と非開発作業を分けて入力してもらうようなプロジェクトコードを発行するようにしていきます。

もっと詳細にProject-Aの中身を確認したい場合には、要件定義や設計、開発、テストなど分割していきます。 とはいえ、トレードオフとして入力に対する労力コスト（LOE）がかかるので、そこまで厳密すぎるデータを求めるよりかは、あくまでも最適化が計れる傾向分析ができれば良いと考えています。

• 有効稼働
  • Project-A : 開発比率（%）
    • 要件定義比率（%）
    • 設計作業比率（%）
    • 開発作業比率（%）
    • テスト作業比率（%）
  • 保守・運用比率（%）
  • プロジェクト管理比率（%）
• 開発外比率（%）（非有効稼働）

トラッキングするタイミングについても、毎日の勤怠提出作業と工数管理を紐付けることによって、より正確なデータが入力されるようにしていくことが理想でしょう。

2.2 開発チームの戦闘力を定量化するための記録

上記の話は少し全面的な話でしたが、日頃の開発プロセスについても記録が必要です。

様々な観点がある中で、プロジェクトや仮説検証のサイクルを高速で回してくには、開発スピードを上げていく必要があります。 DMMでは、エンジニア組織のパフォーマンス可視化について、Findy Team +などを使いながら、全社的な可視化を進めています。

こうしたデータをプロジェクトの途中でモニタリングしながら、Googleが提唱しているエリートチームなどを指標として現状とのパフォーマンス力の差分を比較してトラッキングしていきます。

エリート DevOps チームであることを Four Keys プロジェクトで確認する｜cloud.google.com

それ以外にも、アジャイルプラクティスの中では開発プロセスを最適化するものは沢山あります。

• VSM（バリューストリームマッピング）
• Velocity Tracking
• BurnDown Chart
• ControlChart
• 累積フロー

など、あらゆるものをチームで選択してソフトウェア開発の活動をプロットしていきます。

 ※VSM（バリューストリームマッピング）の例

3.資産

最後のパートである、資産です。

プロジェクトや仮説検証を工数・工期・費用をベースに予測値を立てながら、プロジェクト遂行とともに特定の基準をもとにトラッキングし、記録していく。そうして、プロジェクトが完遂した後に行うのが「資産化」です。

資産化といっても、財務諸表に載せるためのソフトウェア資産計上だけではなく、プロジェクト資産的な考え方もあります。

3.1 Project - knowledge

プロジェクトを行う際に、予測→記録を行うとそれらがログとなり、会社の知識的な資産（knowledge）になります。

3.1.1 予測からの"ズレ"を学習

例えば、前述したプロジェクトのプランAについて、実測値として「工期 = 38人日 → 40人日（+2人日）」「費用 = 3,375万→4,162万（+約700万円）」といった形で、必ず ”ズレ”がでてきます。 このズレが何が起因なのかは、きちんと記録できていれば判明させることができます。

システムに複雑性や仕様変更による「工数」のズレなのか、対応できる人数の違いによる「工期」のズレなのか、理由はさまざまです。

3.1.2 プロジェクトの追体験から傾向分析ができる

また、サンプル数がどんどん集まることで、似たようなプロジェクトを行う際に工数・工期の傾向がわかります。 たとえば、「以前決済機能をリプレイスしようとすると80人月ぐらいかかり、設計に30人月かかった」などがわかると同じことをしようとしたときに傾向分析ができるのと、VSM（バリューストリームマッピング）などがあれば、プロジェクト途中に起こったことが追体験できます。

すると、同じ失敗をしなくなったり、ある程度違う人がプロジェクトリーダーをやっても進め方の方法や仕組みが一定になり、安定してきます。

3.2 ソフトウェアの資産計上

最後に、プロジェクトや仮説検証を経て私達が作ったソフトウェアが最終的にどのような形で資産として認識されるのかを理解することは非常に重要です。

まずは、なぜ資産計上をするべきかなのか、ひいてはプロダクト開発にどう関わってくるかを考えていきます。

なぜ、ソフトウェアを資産計上しないといけないのか
自分たちが作ったソフトウェアという無形資産が、会社の財務諸表ではどういった扱いとなっているかを考えたことがあるエンジニアはそこまで多くないでしょう。 たしかに、ソフトウェアがサービスと言う形に変わってユーザーに使ってもらいながら、課金をしてもらい売上が立つというイメージは湧くと思いますが、ソフトウェア自体もソフトウェア資産計上という形で財務諸表にその価値が記載されています。詳細な部分で言えば、B/S（貸借対照表）にあります。

B/Sの中で、固定資産という枠があり、ソフトウェアはその中の「無形固定資産」にあたります。 細かいですが、ソフトウェアで計上できるものは確実に将来の収益や費用削減が見込まれるものになります。それ以外は、費用として計上します。例えば、運用・保守や調査などは資産計上しないことが多いです。

引用 : https://www.eurekapu.com/software

ちなみに以前は、無形固定資産の勘定項目に「ソフトウェア」がなかったらしく、いくら開発して成果物（ソフトウェア）を残しても、資産にならず単純に開発コスト（人件費等）が費用として垂れ流していたそうです。

「 ソフトウェアの資産計上」は業界の求めたこと | おごちゃんの雑文｜www.nurs.or.jp

次に、ソフトウェアを資産計上しないと、どうなるのかを考えていきます。

何か利益が見込めるソフトウェアをエンジニア3名で1年かけて開発するとするとします。 1人あたりが年間1,000万の費用がかかるとして、人件費が1年で3,000万です。 これを資産計上しなかった場合、単純計算でコスト3,000万のB/Sの費用がコストとしてかかってきます。

一方、当然この3,000万のコストをかけて何もしなかったわけではなく、何かを作っているはずです。 それがソフトウェアだとすると「将来的に会社に収益をもたらすことが期待される」ことが前提として、きちんと財務諸表に「資産」として計上しなければいけない。 そうではないと何も価値を生み出さなかったことにB/S上ではなったしまいます。

ここまではなんとなくイメージが湧くと思いますが、ではどういった風に計上すれば良いかの話になります。 そのわかりやすい方式が「減価償却」という会計処理です。

3.2.1 減価償却とは

ソフトウェアにおける減価償却とは、ソフトウェアにかかる支出をそのソフトウェアが使用できる期間にわたって費用配分するというソフトウェアの資産計上方法です。

つまり、ソフトウェアという固定資産の購入費用を使用可能期間にわたって、分割して費用計上する会計処理です。 業務に使用していて、かつ時間の経過とともに資産価値が減少する固定資産は減価償却試算の対象となります。

逆に価値が変わらないものは減価償却の対象外となり、減価償却をする目的は損益計算を適正に行うためです。

例えば、100万円の車を購入することを考えます。
車を購入する前の利益が100万円あったとして100万円の車を購入してしまうと利益は0円になったりします。 しかし、車は通常、来年も再来年も継続して使うことが多く、そうなると100万円の車の費用を、初年度にすべて計上してしまうと、企業の損益状況を正しく把握できないことになります。 そのため、車の全額ではなく、一定額あるいは一定割合を費用として計上する減価償却の考え方が必要となりました。

これはソフトウェアでも同じだと定義されています。

減価償却費の計算方法
減価償却の額を算出するためには、「定額法」と「定率法」について理解する必要があります。 両方ともどういった方式で費用分配していくかの違いがあります。

定額法は、毎年一定額を減価償却する方法です。
(購入価額) × (定額法の償却率)が1年間での減価償却額。 100万円の資産を10年間使うのであれば、定額法を使って減価償却費を算出する場合、100万円÷10年=10万円となります。

定率法は、毎年一定の割合ずつ減価償却をしていく方法です。 100万円の資産を20%の定率法で減価償却費を算出する場合、初年度は100万円×20%=20万円です。2年目は(100万円‐20万円)×20％＝16万円、3年目は(100万円‐20万円‐16万円)×20％＝12.8万円となります。 前述した、この図は定率法。一点の割合で引いて5年で償却済みにします。

3.2.2 ソフトウェア仮勘定とは

もう一つ、覚えておくと良いこととして「ソフトウェア仮勘定」という項目があります。 減価償却はいわゆる、ソフトウェアができた状態が前提で、そこから定率法なりで償却が始まります。

一方、開発中のソフトウェア（無形固定資産）はどういった扱いにするべきか。それを解決するのが「ソフトウェア仮勘定」です。 開発中についても勘定科目を設定してコストをプールします。

ソフトウェア実務指針を見ていくと、B/Sでいう無形固定資産 -> ソフトウェアとは別掲で記載する必要があるとのこと。

(製品マスターの制作原価) 10.製品マスターについては、適正な原価計算によってその取得原価を算定する。製品マス ターの制作原価は、制作仕掛品についてはソフトウェア仮勘定などの勘定科目により、ま た、完成品についてはソフトウェアなどの勘定科目によって、いずれも無形固定資産とし て計上する。なお、無形固定資産としての表示に当たっては製品マスターの制作仕掛品と 完成品を区分することなく一括してソフトウェアその他当該資産を示す名称を付した科目 で掲げることとするが、制作仕掛品に重要性がある場合にはこれを区分して表示すること が望ましい。

引用 : 研究開発費及びソフトウェアの会計処理に関する実務指針(http://kato-cpafirm.com/audit/files/No12-RD20141128.pdf)

実際には，間接費の配賦など、最終的に作業完了しなければ正確な取得価額が算定されないことも多いです。

ある程度合理的に見積もられた金額を「ソフトウェア仮勘定」としてプールしておいて、資産振替の時点で正確な数値に洗替を行う方法もあります。（本勘定振替）

ただ、ソフトウェア仮勘定の実態は、人件費になることが多いです。以下が例です。

• 22年1月に社内の人件費削減のために利用するソフトウェアを外注した。合計の費用は100万だとする。まずは、40万を当座預金から払ったとする。
• 会計的には、「ソフトウェア仮勘定 : 400,000円 / 当座預金 400,000円」となる。
• 次に22/03に二回目の代金として30万を当座預金から払ったとする。
• 会計的には、「ソフトウェア仮勘定 : 300,000円 / 当座預金 300,000円」となる。残りは、30万（100万-30万–40万）となる。
• いよいよ、22年6月には成果物が完成し、即日利用を開始した。

ここで初めて、仮勘定から本勘定になｒます。 会計的には「当座預金 300,000円」をとりあえず払い「ソフトウェア仮勘定 : 700,000円」を消して「ソフトウェア : 1,000,000円」という計上になります。

以上が、ソフトウェアの資産計上の入門でした。 自分たちが開発しているものがどのようなフローを踏んで、どういうふうに会社の財務諸表に計上されるのかを考えて行動することもプロジェクトを管理する上では必要な知識だったりします。

参考文献

• 「 ソフトウェアの資産計上」は業界の求めたこと（http://www.nurs.or.jp/~ogochan/essay/archives/5008）
• 研究開発費及びソフトウェアの会計処理に関する実務指針（http://kato-cpafirm.com/audit/files/No12-RD20141128.pdf）
• ソフトウェアの資産計上〜減価償却編〜（https://medium.com/i35-267/ae58abc5a657）
• ソフトウェアの資産計上〜ソフトウェア仮勘定 編〜（https://medium.com/i35-267/bb81fe3ebe38）

全体まとめ

最後にまとめです。

• 予測が目標値を作り、出発点である
• ソフトウェア開発のプロセスをあらゆる観点で記録をすることで、可観測性が上がり観測可能になる
• 予測 → 記録 → 実測が貯まると、組織に知見（knowledge）が溜まっていく
• 知見（knowledge）をもとに学習していくことで、組織の戦闘力の安定性が向上していく

以上、ソフトウェア開発における予測と記録と資産についてでした！