「機能A：データ多量、検索コスト多」と「機能B：データ少量、検索コスト少」のどちらを選択するかの判断軸

二手に別れた道の前に立っている。「機能Aの道」と「機能Bの道」。

前提

「機能B」を選択すると「機能A」へのシフトはデータを機能B用に分割不可能なため出来ない。
「機能A」を選択しても「機能B」へのシフトは可能。しかし、「機能A」はやっぱ使わないとなり「機能B」へシフトするまではデータ量、検索コスト多の状態が続く。
「機能A」は「将来使うかも知れないし、使わないかも知れない」そして、その判断が今すぐにできない、使わない確率のほうが高いかも。
データ量、検索コスト多といっても、HDDがパンクしたり、レスポンスがまったく帰ってこないという状態ではない。普通に使える。

判断軸 1 「機能Aを使う可能性が低いならつけない」 => 機能Bを実装

ここを判断する背景には、「余計な機能をつけたくない」「コードをシンプルに保ちたい」という判断軸を持っている。

判断軸 2 「少しでも使う可能性があるなら機能Aをつける」 => 機能Aを実装

ここを判断する背景には、「機能Aへシフト出来きない設計はまずい」という判断軸を持っている。

判断軸 3 「機能Aを使うか使わないか判断するまで機能を実装しない」 => 機能を実装しない

ここを判断する背景には、「もう少し仕様が煮詰まるのを待つ」「仕様がもっと出来ていないと駄目だ」という判断軸を持っている。

まとめ

あなたならどうする！？コメント欄に匿名投票歓迎。

Permalink | コメント(2) | トラックバック(0) | 17:11

コメントを書く

littlestarling 2010/07/30 19:09 いくつか条件はつくと思いますが、実装しないという3を選びます。

機能Aが必要かどうかの判断がつかないという前提がありますが、ある検索を行うことが現状必須の要件とは読めません。
検索自体が必要ということであれば、改めてAが欲しいと言われた時に再設計が必要になる前提であってもシンプルにBを
選択すると思います。実際の検索機能の実装をベースに何らかのフィードバックがあることを期待します。それを取り込むと
当初のAとはまた違うものになってくるかと。

検索機能の有無をおいておけば、Aの実装の要不要の判断がつく条件は何かを詰めるのが筋ではないでしょうか。
そうすれば今すぐに判断して実装する機能がなんであるかが見えてくるのではないかと思います。

japanrock_pg 2010/09/18 11:48 id:littlestarlingさん
機能Aの要不要の判断を付けるのが大切ですね。迷っている段階で”そもそもこの機能が必要なのか”を考える必要がありそうですね。”実装しない”はたしかにです。実際、一旦この機能はペンディングになり、2ヶ月くらい経過していますが、大きな影響は出ていません。ちゃんと必要かどうかを判断することが大切ですね。