来週6月3日(水)より、オブラブ2009夏イベントの参加お申込みを開始します!恒例のライトニングトークス、また、実はこちらがイベント本番との声も多い懇親会のお申込みも同時に開始となります。夏イベント当日まで、ブログも随時更新していく予定です。こちらもご覧ください。[1]こんにちは、平田です。今号から要件定義に関する短期連載を担当します。自身も日々プロジェクトの現場で悪戦苦闘している最中ですが、現場で得たものを少しでも読者のみなさんと共有したいと思い、連載をさせていただくことにしました。初回となる今回は、なぜこの連載を始めることにしたか、という動機について書いていきます。今要件定義か設計やプログラミング等の技術の進化が続いているにも関わらず、プロジェクトの成功は相変わらず容易ではないと感じています。プログラマから考えると「いつまでも決まらない仕様」「続いていく仕様変更」という問題があり、システムをリリースしてみたら「作ったシステムが役立っていない」などなど。要件定義の軽視からプロジェクトがうまくいかなくなった例は枚挙に暇がありません。プログラマなのかアジャイル開発の流行を例に出すまでもなく、ソフトウェア開発ではコミュニケーションが重要なものだと認識されています。開発チーム内のコミュニケーションロスを減らすために、お客様の価値に直結しないドキュメントを山のように作るという対症療法もありますが、そもそも、開発チーム内でのコミュニケーションパス自体を減らすことにより、コミュニケーションロスを減らしていけるのではないかと考えます。発するシステムのサイズを適正な規模に保つ(横のコミュニケーションパスを減らす)ということも有効ですが、この連載では、開発チーム内での役割分担のレイヤーを減らす(縦のコミュニケーションパスを減らす)ということに着目していきます。実際に動作するものを提供できるプログラマこそが、お客様と直接対話して、お客様のビジネス価値を創造していくのが効率的ですよね。要件定義って工程が存在しないんだけど要件定義というのは、開発プロセスの種類によっては工程ですが、どんな開発プロセスであっても必要なタスクです(唯一の例外は、使う人自身が1人で開発を進める場合)。その成果物が分厚い要件定義書だろうと付箋に書かれたユーザストーリーであろうと、「システムに求められている要件」が書かれたものである以上、同じ技術を活かすことで実現が可能なのです。この連載では、その要件定義に必要なTipsを紹介していきます。次回は「理由を追い求める」です。お楽しみに!(平田)_______________________________________________________________________この記事への評価にご協力をお願いします。URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用のブラウザに表示されれば投票完了です。