ご利用は計画的に（計画ゲーム） | column

♪はっじっめて〜のっ、ア○〜ム(^_^)．．．ならぬ、はじめてのXP、トップバッターは「計画ゲーム」。

これはすっごく簡単。

無理のない返済．．．じゃなくて、無理のない計画をこなすだけ。ただそれだけ〜。

以上っ！

．．．って、これで終わったら、タコ殴りにされそうなので．．．

説明しようっ！（戦隊モノ風でどうぞ）

計画ゲームとは、ビジネスをする上でどんなソフトウェアを開発するかを計画するプロセスのことである！

そして、計画ゲームは、ビジネス側と開発側が一丸となり、両者の力が合わさったとき、究極の威力を発揮する！

ビジネス側は、４つの力を使いこなす！

スコープ．．．ビジネス上、最低限何が必要かを決める
プライオリティ．．．どれから用意すればいいかを決める
リリースの集約．．．何があればビジネスがよくなるかを決める
リリースの日付．．．いつまでにシステムが必要かを決める

これらビジネス側の決定の後、開発側も４つの力を使いこなす！

見積もり．．．開発に必要な時間を決める
結果．．．技術的な部分の解決方法を決める
プロセス．．．開発のやり方・進め方を決める
詳細なスケジュール．．．どれを開発するかを決める

こうして、実現不可能に見えるプロジェクトを見事に達成してしまうのだ！！

．．．って、そろそろ普通に話してもいいですか？

まぁ、簡単に言えば、ビジネス側と開発側で協力し合い、よく話し合って、システムを開発する計画を立てましょうというのが、計画ゲームの重要ポイントです。

たまに「要求は全て話した、後はそっちでスケジュールして進めてくれ。任せたぞ。」と言い放って”開発側お任せモード”に入るビジネス側の人を見かけます。これは本当にいけません。

出来上がるシステムについて、完全に責任放棄しているようなもんです。こういうことを言うビジネス側に限って、リリース直前になって「こう作れと言ったじゃないか！！」ととんでもない剣幕でまくしたててきたりするので困ります。

やり始めた方が、ちゃんと責任持ちましょう(^_^)

逆に「開発のことは全てお任せ下さい。何も心配せずにお待ち下さい。」と自ら名乗りをあげて”開発側お任せモード”に仕向ける開発側の人も見かけます。これも本当にいけません。

ビジネスに必要なものを知っているのは、あくまでビジネス側であって、間違っても開発側がメインでスコープ（どの機能を作るか？）やスケジュールを勝手に決めてはいけません。こういうことを言う開発側に限って、リリース直前になって「こんな機能はビジネスに役立つ訳ないじゃないか！」と血走った目でわめき散らすので困ります。

自分の役割でないところに首を突っ込むのはやめましょう(^_^)

お互いのやるべきことを守りましょう！

さて、ここまでは計画ゲームの大前提を説明しましたが、もう少し具体的なことについて解説します。

計画ゲームで出てくる要素は、以下の４つです。

リリース計画
ストーリー
イテレーション計画
タスク

１つ目の”リリース計画”ですが、これはシステムをリリースするにあたって、どのタイミングで中間リリースを行うかという計画です。

XPでは、最終リリースのみの１回で完了というやり方はあまりしません。例えば、リリースまで３ヶ月あるとすれば、１ヶ月に１回の中間リリースを２回行い、最後に最終リリースを行うといった感じで段階的にリリースを行います。

そして、何度かあるリリースのタイミングで、できあがったものが希望通りかをチェックします。そこで希望と違っていたり、希望と違っていなくてもビジネス的にそぐわないことがわかった場合、ビジネス側は開発内容を方向転換するように開発側へとリクエストを出すことができます。

２つ目の”ストーリー”ですが、これはビジネスの要求を簡単なストーリー（物語）としてビジネス側が開発側に説明することです。「何だか難しそう．．．」って思われるかも知れませんが、そんなことは全然ありません。

ストーリーは、ビジネス側が「ストーリーカード」と呼ばれる紙のカードに書きながら、開発側に説明していきます。

例えば、自社ホームページを作るときに、資料請求のためのお問い合わせフォームが必要なのであれば、「ホームページを見にきた人は、お問い合わせフォームから資料請求できる」という感じで手書きでストーリーを書きます。ねっ、簡単でしょ？

これで説明が足りなければ、具体的に「こんな画面にしたいんだ」や「こういった項目をお問い合わせで拾いたいんだ」というのを、ストーリーカードに手書きの絵で書いて説明します。

こうして、説明された要求に対して、開発側は開発するのにどのぐらいかかるかを見積もり、ビジネス側に見せます。それを見て、ビジネス側は時間的にリリースに間に合うかどうかを判断します。

ここでビジネス側のあなたは「あれ？」と思うかも知れません。

開発時間の管理は、開発側の仕事だろ、と。

いいえ、違います。

開発側が行うのは、あくまで見積もりだけです。

ストーリーレベルで「どれをやるか？」「どの順序で行うか？」を決めるのは、ビジネス側です。ここでは、開発側はあくまでアドバイザーという役割なのです。

他にも「あれ？」と思うかも知れません。

要求定義は、開発側に書かせるのが普通だろ、と。

これもやはり違います。

要求定義は、ビジネス側が書くものです。なぜなら、ビジネスのことを知っているのは、ビジネス側であって、開発側ではないからです。

ビジネス側がひたすらやりたいことを話して、それを開発側が聞いて要求定義としてまとめるといったやり方もありますが、開発側がビジネスのことを間違いなく理解していると思いますか？開発側が勝手にビジネスのことを解釈しても構わないですか？

開発側の専門はあくまで「開発」であって、あなたのビジネスではないのです。

また、開発側のあなたがビジネスに詳しいとしても、その知識や経験は今のビジネス側の考えるビジネスと１つも違わず全く同じだと言い切れますか？それがビジネス側の想像するビジネスと違うものだったとき、あなたは責任とれますか？

「ビジネス」はあくまでビジネス側の領域であって、開発側につとまるものではありません。

お互いのやるべきことを守りましょう！

ちなみに１つのストーリーは、１週間〜３週間で開発可能な大きさに調節します。

３つ目の”イテレーション計画”ですが、これはストーリーをいかにシステムの開発へと落としていくかという計画です。

これは、ストーリーを４つ目の”タスク”という単位に分割するところから始まります。

タスクは、開発側が「タスクカード」と呼ばれる紙のカードに書いていきます。

例えば、「ホームページを見にきた人は、お問い合わせフォームから資料請求できる」というストーリーは、「お問い合わせフォームのページを作る」というタスクと「お問い合わせをメールで管理者に投げる」というタスクに分割されます。

そのとき、開発に必要な情報、例えば「メールの送り先となる管理者のアドレスはinfo@〜」や「入力チェックも行う」といったことは、タスクカードに手書きで書き足していきます。

ちなみに１つのタスクは、１日で開発可能な大きさに調節します。

イテレーション計画では、１回のリリースを更に幾つかのイテレーションという単位に分けます。

例えば、１回のリリースが１ヶ月であれば、１イテレーションを２週間として、１回のリリースまでに２回のイテレーションがあるようにします。こうすることで、イテレーション毎に予定通り開発が進んでいるかをチェックできるようになるのです。

このように、XPでは、リリースにしろ、イテレーションにしろ、できるだけ頻繁にチェックするタイミングを作ることで、未知の問題へのリスクを低く抑えつつ、着実に進んでいるんだということを意識します。

このあたりの細かい話は、「短期リリース」で詳しく説明しますね。

さて、ここまで計画ゲームについて簡単に説明しましたが、計画ゲームはとても奥が深く、まだまだ説明することがたくさんあるのですが、入門シリーズが終わった後に始まる実践シリーズで私たちが実践した記録と共に実用的な説明をしたいと思いますので、どうぞお待ち下さいm(_)m

次回、12/3(金)は「短期リリース」についてです。

お楽しみに！

フィードバック下さい！

There is no comment.

Chat (Lingr.com)

Informaiton

Daily

Column

Zope Solution

Extra

アーカイブ

OSS案内所

Site Info

関連リンク

フィードバック下さい！