要求開発はアジャイルのフロントローディング #redajp
要求開発アライアンス 西日本の10月勉強会に参加しました。
これまで、XPJUG関西のMLなどで名前は知っていたもののよく理解していませんでした。今回はチュートリアル編と言うことでお勉強のために参加しました。
まずは稲田さんの概要説明です。感想を交えながら主要なキーワードを説明されました。後半は「要求開発~価値ある要求を導き出すプロセスとモデリング」の共著者の萩本が、要求開発への思いを要求開発、そして匠メソッドに至った経緯を含めて説明されました。
1.全体の感想
最も印象的だったのは
「開発時にモデリングしていては遅すぎる」
と言う言葉でした。アジャイル開発では、顧客に価値を提供するために優先度の高い仕様から実現しますが、要求開発はバックログとして仕様を具体化する前にも、IT技術者が関わって価値の高い者を提供しようというものです。いわば、アジャイル開発のフロントローディングです。
このことが実現できるなら、仕様をあらかじめ決めざるを得ない、アジャイル開発の効果が少ない場面でも有効だと思いました。スコープが変更できない場面でアジャイルは、段階的に開発することで、技術的に未知な部分やUXのリスクを低減できるものの、価値を想像するという感覚は生まれません。そのような開発においても、IT技術者が要件定義の最初から関与することで、戦力的な価値を提供可能な要求を開発することができると思います。
2.要求開発が提供するもの
要求開発は、必要な事と、選択して整備する仕組みを提供します。
その基本は、こたつモデルと呼ばれるもので、戦略的(将来の価値)、業務問題解決(現在の価値)、技術活用の視点、この3つでこたつを囲むように進めていきます。価値、戦略、業務、IT活用、IT実現、に分けて、それらをつなげて、同時並行に回します。早くつなげて価値を創造するのです。戦略と実現の線上にしか価値は存在しないのです。
これらはWHATとHOWの関係です。実装(HOW)に対する要求(WHAT)のように、要求(HOW)に対する業務(WHAT)、業務(HOW)に対する戦略(WHAT)という関係です。これらを、トップダウンに決めるというよりは、HOWを手さぐりしながら開発していきます。そこでは、ものを作る力ではなく、描く力(価値・要求を手さぐりでデザインする)が重要です。要求開発で用いる「プロジェクトシート」は将来の価値と短期的視野で表します。
要求開発で実施することは、フェーズ(準備、立案、デザイン、シフト)とPDCAのマトリックスで表され、「プロセスキャビネット」と呼ばれます。これらは選択的に実施されるのですが、プロセスセルという枠組みがあり、必要と思われるものを組み合わせてプロセスフローを実現します。稲田さんは、この仕組みを「詳細に走らないように用いています」とのことでした。
3.要求開発への思い
要求開発は、萩本さんをはじめとする、今世紀の初めの頃の豆蔵の方達が提唱されました(豆蔵は、オブジェクト指向、RUP、アジャイル開発などで有名な会社です)。ビジネスの開発方法論の必要性から、BDA(ビジネス・ドリブン・アーキテクチャ)、そして要求開発の方法論に発展したそうです。要求開発はカスタマイズ可能で、目的と手段を連鎖させ、プロセスセルはPDCAの慣習化として実現され、無駄なものを作らない方法です。そこには、分析モデルを開発で作るのはおかしい、という思いがあったようです。
要求開発では価値のあるものをつくります。要求開発の4象限はRUPと同じで、HOWはWHATに、つまり価値の高いものを作るためにITエンジニアが手さぐりの協力をします。システム開発以降でIT技術者が協力してももう遅いのです。業務を変えないといけないので、開発はビジネスのところでします。ビジネスの中でアジャイルするのです。
ビジネス戦略を決める際に予想することはは難しいです。やっていないとわからないところがあるので、それをアジャイルでやってみます。そのために、「こたつモデル」は重要で、知識のカスケードをするためにこたつを実現します。ただ、立場の違う人が集まるだけでは空中戦になりがちで、声の大きいものが勝ってします。そこで、ファシリテーションとマネジメントが重要になってきます。
このような萩本さんのお話を聞いて、なぜXPJUG関西の人たちが注目しているかがわかったような気がしました。
4.まとめ
ソフトウェア開発は、単純なウォーターフォールモデルで実現できるような簡単なものではなく、自分たちの能力とその限界を知った上で最高のパフォーマンスを実現しなければうまくいきません。そのための一つの答えがアジャイル開発であったのです。しかし、システム開発を最初からアジャイル開発だけで実現できないので、従来のV字モデル(あるいはW字モデル)の実装部分だけを、アジャイル開発に置き換えている会社も多いでしょう。でも、それではだめだったのです。
価値の高いソフトウェアを開発するには、要求は定義するだけではだめで、開発しないといけないということなのです。要求開発は、いわば「アジャイル開発のフロントローディング」だったのです。
(聞きかじりを個人的な思いでまとめました。間違い等ありましたらご指摘ください)
« アジャイルを考える - Agile Tour Osaka 2011 - | トップページ | [#TiDD] アダプタブル・ウォーターフォール開発の事例 ~想定外の作業はチケットで補完せよ!~ #RxTstudy »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「プログラミング」カテゴリの記事
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -(2021.05.09)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会(2019.01.27)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
この記事へのコメントは終了しました。
« アジャイルを考える - Agile Tour Osaka 2011 - | トップページ | [#TiDD] アダプタブル・ウォーターフォール開発の事例 ~想定外の作業はチケットで補完せよ!~ #RxTstudy »
コメント