ソフトウェア開発とライフタイムバリュー - デジタルトランスフォーメーション時代のソフトウェア開発3

世界中の"むずかしい"を簡単にする株式会社diffeasyの取締役CTO西です。
この記事はアドベントカレンダー「diffeasyCTO西の24(にし)日連続投稿チャレンジ Advent Calendar 2019」の17日目の記事です。

デジタルトランスフォーメーションとは - デジタルトランスフォーメーション時代のソフトウェア開発 1
パッケージとしてのソフトウェアとサービスとしてのソフトウェア - デジタルトランスフォーメーション時代のソフトウェア開発2
に続く、「デジタルトランスフォーメーション時代のソフトウェア開発」シリーズ３回目の今回は、ソフトウェア開発と運用保守についてです。

小さく作って大きく育てる

前回の記事では納品はゴールではなくスタートだ、ということを書きました。

不確実なユーザーの課題に対応するには、仮説と検証が必要です。
仮説と検証は当然１回では終わらず、仮説と検証のループが必要です。
ループを回すためには、小さく早く失敗する必要があり、そのためにもまずは最小限の機能のシステムをリリースする必要があります。

優先度が高い、なくてはならない機能から始め、徐々にソフトウェアを市場や業務に最適化させていくことが大事です。

もちろん課題が明確で、その課題を解決したいというソフトウェアもあると思いますので、必ずしも全てのソフトウェアに上記のことが当てはまるとは思いません。

発注者の不安とソフトウェアのライフタイムバリュー

自社サービスであれば事業サイド、受託開発の場合はソフトウェア開発の発注者側からすると、小さく始めるのは良いにしても、継続的に改善を続ける場合に、長期的にどれだけの投資が必要でどれだけの価値をうむのか？ということが気になります。

「継続的に改善していきましょう！」と言われてもコスト感がわからず、ゴールも見えない状態では、当然発注者側は不安になります。

ソフトウェアの寿命を何年と考え、ソフトウェアが価値を生むまでにどれくらいの期間がかかり、長期的にソフトウェアがどれくらいの価値をうむのかを考える必要があります。

経営戦略・事業戦略とIT戦略

ソフトウェアのライフタイムバリューによって、どのようなソフトウェアを開発するべきか？も、どのような技術を使うか？（技術選定の仕方）も変わってきます。

ソフトウェアのライフタイムバリューを考える上では、経営戦略・事業戦略からソフトウェアのライフサイクルを考慮する必要があります。

極端な例ですが、一時的なキャンペーンサイトを開発するのと、長期的なサブスクリプションサービスを開発するのでは、技術選定のポイントが全く異なってきます。

経営戦略・事業戦略とIT戦略がマッチしていないと、過剰で高コストなソフトウェアになってしまったり、逆に経営戦略を支えることができない非力なソフトウェアになってしまう恐れがあります。

自社にエンジニア組織を持つ場合も同様で、経営戦略・事業戦略からIT戦略を導出し、最適なエンジニア組織のあり方を設計する必要があります。

どのように見積もるか？

ソフトウェア開発において、一番難しいのが、開発全体の工数見積もりです。

原価がないソフトウェアの場合は、基本的には開発にかかる人件費がソフトウェアの金額になります。

原価がない分、非常に計算が難しく、ほとんどの場合、見積もりを作成する担当者の過去の経験によるところが大きくなります。
過去の開発実績値から機能を重み付けし、ポイント換算して見積もりを作成する場合もあります。

しかしいずれにせよ、ソフトウェアの規模が大きくなるほど、誤差も大きくなりがちです。

発注者側も開発者側もお互いに幸せになる為には、誤差を最小限にする必要があり、その為にも開発の単位を小さくする必要があります。

その後の改善・保守フェーズの見積もりは、上の章で紹介したソフトウェアのライフタイムバリューから、どれだけ改善・保守に投資するかを逆算して、必要な改善のボリュームを算出するのが良いかと思います。