Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
こんにちわ。ばたっちです。
前回お届けした「ビジネス側と開発側は仲良く！」。
どうですか？仲良くできてますか？(^—^)
仲良くするためにうまくいった方法があれば、教えてくださいね。
今回は「今、分からないことを認めよう！」、「やるべきことを明確にしよう！」を一気にやっちゃいましょう。
ビジネス側の役割として、「スコープ」と「優先度」を決めないといけません。
決められた時間とお金の範囲で、「やること」と「やる順番」を決めるということですが、ここで２つの決心が重要になります。
「やること」と「やる順番」を決めるためには、まず「やりたいこと」をリストアップして、開発側にどのくらいでできるかを見積もってもらいます。
最初の段階で「やりたいこと」がすべて明確であれば、何も問題はありません。
ですが、最初からすべてが明確であることはあり得ないのです。。。
なんでかって？
ビジネス側はビジネスのプロですが、システムについてはあまりよく分からないかもしれません。
「こんな作業してるけど、システム化できるのかな？」
どこまでシステム化できるのかが分からないと「やりたいこと」が明確にならないことがあります。
システムがある程度できてくると、「この機能をちょっと変えれば、あの作業もできるんじゃない？」といったように、後から「やりたいこと」が見えてきたりします。
開発側も同様で、ビジネスのプロではないため「この機能はどんなものを期待してるのかな？」といったように、すぐにはビジネス側が求める機能をイメージできなかったりします。
また、開発側も技術面において万能ではありません。技術的要素にも不確定な要素があり、「技術的に可能か？」といったことも、後から見えてくることがあります。
[プロジェクト] [ビジネス側] [開発側]
初期 ・システム化できる？ ・どんな機能か？ .... 「最初は分からないこと」
・この技術は可能か？
↓ ↓
中盤 ・あの機能みたいに！ ・あぁ、こういう機能かぁ！ .... 「後から分かること」
・○は□な風に！ ・この技術でいけるぞ！
↓ ↓
そうです。「今、分からないこと」を認めないといけないんですね。
ビジネス側も開発側も互いの領域はもちろん、自分の領域にも「不確定な要素」があるんです。
これは最初にじっくり時間をかけて考えれば分かるということではありません。。(T_T)
実際にプロジェクトが走り出してから分かることなのです。
XPでは「短期リリース」や「イテレーション」といって、繰り返し少しずつ作りながら、実際に動かしつつ開発を進めます。
プロジェクトの途中でも、実際に動くものを見ることができるので、ビジネス側にも、より「システム化」がイメージしやすくなります。
また、少しずつ進めるので、途中でイメージができた時点で軌道修正することもできますね。
[XP] [従来手法]
| |
+--+ +--+
: | : |
[リリース]-->|<-+ 軌道修正♪ : +--+
| : |
+--+ : +--+
: | : |
[リリース]-->|<-+ 軌道修正♪ : +--+ 軌道修正されない。。
| : |
: : :
[ゴール] [ゴール]
ちなみに、少しずつ作る効果は軌道修正だけではなく、「要求の変更」にも対応できるという利点があります。
実は、プロジェクトの途中で当初欲しいと思っていた機能が要らなくなったり、違う機能が欲しくなったりすることがあるんですねぇ。
そして、「今、分からないこと」を認めつつ、「やるべきこと」は、
- 分かる部分から始める
- 何が分からないかを知る
ということです。これを元に優先度を決めていけばいいわけですね。
とくに「分からない」ことを「分からない」と認識することは大事なことではないでしょうか。
「計画ゲーム」は一度きりでなく、「分からないこと」と「やるべきこと」を調整しつつ、何度も繰り返し行います。
あなたもプロジェクトの「安全運転」に活用してみませんか？(^_^;
There is no comment.