IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

機能を追加するリスク・コスト 継続開発がキツイ理由、詰む理由

若干わかりづらい話をします。半分メモ代わりに。

 

工数というものは機能単位で出すことが多いですが、実際は「対象×機能」が最も近い値だと考えています。
対象というのは基本的にモデルです。Classと捉えても良いと思います。
一つのClassにまとめられるのであれば(super classを作れるのであれば)、多数のClassがあっても機能追加は高コストではありません。
まとめられないClassが多いほど、また機能が多いほどやることが増えます。

これはスコープを変えて、マクロ的に見てもミクロ的に見ても成り立ちます。
例えばアプリケーション全体ででも考えられますし、一つの画面に対しても考えられます。

 

f:id:otihateten3510:20180301030340j:plain

 

上の画像では、対象が3つ、機能が3つで「6個」と捉えたくなりますが、実際は「9個」と捉えるのが正しいです。
感覚値と実際の差が3個分出るので、見積もり漏れにつながります。
(正しく見積もった場合も、そんなにかかるの?と訝しがられます)

 

f:id:otihateten3510:20180301031042j:plain

 

普通に考えるとこうです。
機能を追加するには、1個分の開発工数が必要な気がします

そもそも、改善要求が上がってきたときには、対象ー機能の一つ分しか大抵は意識していません

しかし、整合性が取れなかったり、あまりに不自然ということで、機能と対象は乗算されます。

そしてこれこそ、継続開発で詰む要因となります。

 

f:id:otihateten3510:20180301031240j:plain

 

上の画像で考えます。
対象が5つ、機能が1つです。
機能を1つ増やす際のコストは5個分です。
そして、機能を1つ増やしたことで、将来対象を増やす際のコストが1個から2個に増えます。これが機能を追加するリスクです。

コスト1個と思っていたら、実際には5個で、更に次から全部1個分増える。
そんなことが継続開発の現場では起きています。

 

しかも、この対象ー機能のラインは保守運用対象であり、リリース時にはテストも必要です。対象と機能を増やすたびに、コストは想定の二乗のスピードで増大します。

この対象ー機能のラインが多くなるほど、整合性を取るのが大変になります。片方を直したらもう片方に影響するなど、密結合・ジェンガコードの状態になてしまいます。

 

最終的には、ちょっとした改修なのに2週間掛かるような自体に陥り、それはスピード低下につながり、競争力の低下につながります。
困ったことに、そういった場合傍からは大きな工数がかかるようには見えません。また、本当に重要な機能はごく一部であり、それ以外の追加された対象や機能に工数が奪われるような事態になります。

そのようなサービスは世の中にたくさんあります。
大企業や有名なプロダクトにおいても発生しています。

 

どうすればいいか

機能追加、対象追加のリスクの度合いを把握する。

仕様レベルで疎結合を心がける。(機能ー対象ラインを減らす)

さもないと、実装レベルでどれだけ疎結合を気をつけても複雑度が高くなってしまいます。

 

ただ、プロジェクト的にここらへんを制御できる立場にいるエンジニアはかなり少ないと思います。
じゃあどうすればいいか、というのは現状ではあまり思いつきません。
自分がPOになるくらいですかね。

 

参考

qiita.com

 

 (追記)少し修正:対象のほうがコストが高い

機能というのは例えば「画面」「検索」「お気に入り」「保存」などがが考えられます。
対象というのは例えば「商品」「レビュアー」「色」「在庫数」などです。

 

工数はやはり「対象×機能」に比例して発生するので、「対象を増やすこと」と「機能を増やすこと」は同等に見えます。

しかしよく考えてみると、対象を増やすと自ずと機能が自然発生してしまうことが有ります。

例えば、「店舗」に「位置情報」という対象を追加すれば、「店舗の地図」のような機能が欲しくなるように。
もちろん機能をWANTにすることもできるでしょうが、ものによってはMUSTになってくるでしょう。

更に言えば、大きな対象(Class)を作ると、自ずとその子の対象が生まれることが有ります。

対象を増やす方が合計したリスクは大きくなるはずです。機能を増やすことより対象を増やすことに慎重になったほうが良いのかもしれません。特に大きな対象は覚悟が必要です。
機能そのものを増やすより、対象そのものを追加するほうが軽いように思えてしまう所も罠です。

 

ECサイトの例が分かりやすいかもしれませんね。商品に加える情報や、扱う商品のタイプを増やせば増やすほどしんどくなります。最初は5人程度で作っていたのが、やがて50人体制になり、それでも進捗がスローに感じてしまうやつです。
それで上手く成長すれば良いんですが、方針転換が迫られたり、新しい概念を導入しようとすると素早い対応ができなくなります。

 

 

これ、今回はざっくり抽象的に考えてみましたが、より詳細な分析もできそうですね。
対象のタイプとか、複数の対象が混ざるケース、更に保守運用のコストなど。

こういう戦略の話ってどこかで研究されていないんでしょうか?聞いたことが無いです。

追記:敢えて言えばファンクションポイント法