やぼったい開発 > コラム > 仕様変更に強くなるには



仕様変更に強くなるには


仕様変更に強くなると言うのはどういう事でしょうか?

それは、「仕様変更に対して内部の変更が最小になるように開発・設計すること」です。


それに焦点をあててポイントを整理していきます。


キーとなる箇所


要求定義 〜お客様の目的(夢・幸せ・メリット)〜


どれだけ影響度が大きいか、説明しなくても直感でだいたいわかるかと思います。ウォータフォールモデル開発では、基本設計(外部設計)のさらに前の段階にあたります。



仕事の基本となる話やセールス、マーケティング、ヒアリングに関する話となると内容が発散してしまうので、そこらはへんはさらっとそれ以外のことについて話します。


大事なことはお客様のメリットをはっきり明確にすることです。


お客様のメリットにならないことをいくら提案しても、押し売りになってしまいます。


例えば、すごくまずくてやたら高級食材が入っている高いラーメンがあって、なんでこんなに高いんですか?って聞いたら「それじゃ生活できないんで」って言われてもお客様は関係ないですよね。


おいしいラーメンをたべたい、満腹感を得たいなど思ってきて、それの対価として料金を払っているわけです。ラーメン屋に寄付ししているわけではないんです。


また、受注するためだけに、自分ができないこと、大赤字になってしまうことを約束することも、基本的なビジネス上あり得ないはずです。


後々黒字になるという話なら戦略上の判断であるのでお任せしますが、できないことを隠して仕事を了承しても、さんざんお金と時間を消費したあげく、まだかかりますというのはとても誠実な仕事とは言い難いです。


※「できること」とは、「できると何から何まで確信を持つこと」ではないです。



ここの部分が明確でないと例え完成しても、 のちのち何も出来ていないじゃないかと信頼を失ったり(根本からひっくり返りましたね)。また、外部設計からやり直したり、できるできない、言った言わないの押し問答になったりします。そのような時は後に引けない状態から、いっそう両方とも意固地になってしまいます。

つまりメインはお客様メリットを考え、そして次に自分たちでは どこまでできる、どこまでお役に立てるかを実際的に具体論で、説明できることです。



機能だけでなく コスト・期間も含めてください。





外部に関わること


お客様に提案した内容をどのように実現するかの部分です。お客様に見えること、お客様が直に接触する部分に大きく絡みます。


なのでわかりやすい、みやすい、使いやすい設計が大事です。基本的に後ろに流れる思想は要求定義と同じですが、機能に近い部分になってきます。また、コストの部分の見積もりは、ここを完了する頃にだいたいできると思います。


全ての画面を示す必要はなくメインとなる方向性と、一例などとして詳細な画面のレイアウトや操作方法、処理フローを提示できる必要があります。


どこまで見せればよいかは、基本的な思想(メリットのある提案)のもと、判断が可能なはずです。

何も考えていなかったり(間違っても判断に対する継続的改善をしていないかったり)すると、全ての画面やフローの提案が必要となり、判断責任をすべてお客様に丸投げしてしまいます。


大事なのはお客様に判断材料を示すことであって、うやむやにして(ややこしくして)責任をお客様に持たすことではないです。


もちろんここで、コストと機能のバランスを複数の選択肢の中から判断してもらうことでもあります。




外部に依頼する部分・外部と調整する部分


上の後の自社でできない部分、行わない部分に関することです。

ハードウエア、ネットワークインフラ部分、土地に関すること、人的リソース(適切な人集め)、DB、開発環境などが当たると思います。


影響度は大きいですが、難易度は高くありません。予算を持っている人と、知識のある人がいれば、特に問題は起こりにくいです。



キーとなる作り方


独立性を持つこと

独立性を保つことのメリット
・独立性が高い→他の機能への影響が少ない→仕様変更時に出戻りが少ない




独立性を持った開発をするためには、各工程の役割を意識し、適切な工程で適切な部分を設計することです。


特に基本設計と機能設計の差を意識して設計することが大事です。例えば基本設計で細かい製造に関する部分や外部に影響する部分を考える必要性はなく、また、機能設計になってやっと基本設計部分考えることは避けます。

モジュールレベルの独立性はこれらが保たれていれば、問題なく設計でき、製造時になってまでも他の機能を考慮しながらコーディングすることは減少するはずです。

詳細設計レベルで言うと コンポーネントの追加のしやすさ、パラメータの変更のしやすさなどに影響します。





設計上独立性なんて、コーディングするまでわからない、設計できないという理由を挙げる人(コーディングした物ができればよいという人もある意味そう)がいますが、考えればできますまず考えてみるような開発をしてみてください。


少なくとも製造の直前には必ず考えているはずです。つまり設計時に明確にするか、製造時まで先伸ばすかの違いです。


ひとりで開発しているときはまとめて考えた方がやりやすい点もあるかと思いますが、そうすると試験で保証する部分が弱くなったり、他の機能と影響する部分がまったくわからなくなります。


その時最悪の場合、たまたま動かしてたら見つかったりし、さらにここまできたらもう対応できないので「仕様です。」という人もいます。


このような事にならないためにも適切な設計工程(要求事項に関することは、要求定義、要求内容に対する基本機能に対しては基本設計、機能連携に関することは機能設計各工程)で、行ってください。





ちなみに「仕様です。」という理由を挙げる人は逃げ道を作って問題責任をうやむやにする傾向があります。


お客様のためにもならないし、問題を正面から取り組み、自分の責任が明確になるように作っていく必要があります。

ここを直視しないと、いくらでも出来ない理由が挙がります。第2に気を付ける点は責任を持って仕事を完遂することです。

柔軟性をもつこと

柔軟性をもつことのメリット
・柔軟性がある→機能の変更に対する影響が少ない→仕様変更時に修正点が少ない

ここまでくるとだいぶ影響度は小さくなります。お客様へ提案した内容についての変更に対しては、柔軟性を持たせて設計しておき、それ以外は固くても良いです。

予想できない部分に対する柔軟性は、独立性のある設計や、コードの可読性によりある程度の予防は可能です。





そのほか気を付けること


◆予想できないことは気にしない。

◆予測できる可能性があったか、考える。
(ブレスト、周知ミーティング)

◆重要度(優先度)や、大まかな部分、 主となる部分を背景に考える。
金銭コスト、時間コスト、お客様のメリット

◆影響度を意識する。

◆時間コストの関係を意識する
お客様調整 > 外部調整 > 他モジュール調整 > 自モジュール調整



まとめると


ほしい物はほしいし、いらない物はいらないし、いい物はいいし、悪い物は悪いのです。お客様に向けて、上流の方でいかに力を入れるかが大事です。

<PR>リンク

類似コンテンツ

ウォータフォールモデルではテストファーストは当たり前?

なぜ自動化するのか?単体テスト自動化のメリットとデメリット

JUnitの役割はどこまで? 試験工程内で 単体テストのできることとできないこと

早わかり Junit 30分講座



<< やぼったい開発 にもどる

http://www2.ocn.ne.jp/~cheerful/JUnit/
since (05/03/2006)
http://www2.ocn.ne.jp/~cheerful/develop/