アジャイル開発をビジネスアジャイルに
前回指摘したように、現在のアジャイル開発では、ユーザーからの要求が正しいことを前提に開発作業を進める。あるいは、オンサイト顧客から獲得した要求が正しい要求であると考える。しかし、そもそもビジネス要求はもっとビジネス戦略的な視点、業務オペレーション的な視点、IT活用の視点で考えるべきである。これには要求開発のコタツモデルを参考にするとよい。
また、アジャイル開発が最も必要とされる領域は、システム開発のような後工程ではなく、業務開発段階という最上流であるはずだ。なぜなら、業務開発を行う際に、IT開発も同時に行うことができれば、それは素晴らしく価値の高いものとなるからだ。
業務開発段階でアジャイル開発を行うためには、現在のアジャイル開発をさらに発展させなければならない。
どのような点で発展させなければならないかというと、やはり業務開発の戦略的なプランニングの中でアジャイル開発を行えるようにすることである。これを骨と肉にたとえると、業務開発の戦略的なプランニングの部分は全体的な骨格として形成しておき、その肉の部分はアジャイルで回してスピーディに最適解を得るようにする。ビジネス発展の方向性については、形成した骨格のプランニングに基づき、みんなで現在の戦略が指し示す方角を知り、道に迷わないようにしておく。
アジャイル開発をビジネスの観点で進めることが重要である。システム開発の中でITエンジニアたちがやり甲斐や生き甲斐を持つために、ビジネスの中枢にアジャイルを持ち込み、それで戦うアジャイルチームの登場を期待したい。
そのための武器として、現在のアジャイル開発には要求開発のような、コタツモデルの形成、ビジネス戦略の「見える化」とプロジェクトゴールの立案などを行う必要がある。
開発サイクルとしては、1年間というスパンのストラテジ・イテレーション、そしてその中で数カ月ごとに行うビジネス・イテレーション、その配下でアジャイルチームによる開発を行うイテレーションといったプロセスが必要とされ、アジャイルチーム自体は、ビジネス・イテレーションのサイクルで形成するとよい。
業務とシステムの切り口を正す
ビジネスアジャイル開発だけですべてうまくいくわけではない。ビジネスアジャイル開発は、ビジネスの変化が激しいフロントエンド領域で、比較的システムのサイズが小さく、ITをフル活用するようなビジネス領域に向いている。しかし、従来のビジネスのように比較的規模が大きく、バックエンドシステムとの連携などもテーマとなる開発も今後存在し続けるだろう。
そのような開発は、いままでどおり、システム開発段階で計画的に進めていくことが必要とされる。なぜなら、どうしても契約主導になってしまうからである。しかし、だからといって従来のウォーターフォール開発や反復開発のようなアプローチでよいはずがない。あきらかに両プロセスには多くの問題がある。このことは第1回（ITエンジニアは職人気質を取り戻すべき）で紹介したようにさまざまな手法的な改善が必要とされるのである。
まずは、いままでのように業務とシステムの関係を縦に切るのではなく、斜めに切ることが重要となる。
その中でユーザーと開発者が業務のあるべき姿や課題を抽出し、課題を「見える化」し、ToBeの業務も「見える化」することが重要だ。そのToBeの業務の「見える化」の部分としてユースケース図やユースケース記述が必要となる。
ToBe業務を「見える化」し、ユーザーに覚悟を取り付けるためには、業務フローとシステムを利用する部分のユースケースとユースケース記述、また、その中で使用する画面イメージや操作可能な画面プロトタイプなどが有効とされるのである。
このことから従来のシステム開発段階でドキュメント化していたユースケースや画面などは、もっと前段階の業務開発に移行すべきなのだ。
つまり、システムユースケース図の作成などは、システム開発でやるべきことではない。あくまでToBe業務を説明するドキュメントとして、ビジネス視点で整理することが重要となる。クラス図を使った分析モデルの作成も同様である。
従来の手法では、ユースケースからユースケース記述を抽出し、ロバストネス分析を行い、分析モデルを作成する。このようなやり方は非常に回りくどく、ほとんど非生産的なアプローチであるといえる。それを大量の時間とコストをかけてやってきた。このことは、本連載の第1回、第2回で説明したとおりである。
分析モデルもビジネス構造として業務開発段階にサラリと低コストかつ短期間で作成可能で、作成したものを開発工程にて有効に使うべきだ。
新たな観点でプロセスを再策定すべき
従来の慣習や、システム開発という狭いスコープで定義された古めかしいプロセス（ウォータフォール開発や反復開発）などは捨て去り、新しいプロセスを策定し、その中で、それぞれのモデルや作業について、システム開発に入れておくべきか、それとも業務開発のプロセスに当てはめるべきなのかを見極めることが必要だ。
開発プロセスの表層的な部分だけを見ることなく、その本質に迫り、もし改善が必要だと感じたら自分たちで開発プロセスの改善を行うことが重要である。現代のITエンジニアにその責務が託されていることを忘れてはならない。これにチャレンジしないかぎりIT産業は衰退していくだろう。もちろん筆者も自社にて、ここで紹介したような業務開発プロセスやシステム開発プロセスを開発中なのである。
さて、今回で、この連載も最終回となってしまった。皆さんに多くの気付きとやる気を与えることができないかと考えて始めたこの連載、いかがだっただろうか？ 少しでも気付きとやる気が出た方は、ビジネスとITが一体化した新しいプロセスの策定にチャレンジしてみていただけるとうれしい。
それでは、また、なんらかの連載でお会いすることを楽しみにしている。
筆者紹介
株式会社 匠Lab 代表取締役社長
リコーソフトウエア株式会社 技術顧問
ケペル株式会社 フェロー
株式会社ニッポンダイナミックシステムズ フェロー
要求開発アライアンス 理事
萩本順三（はぎもとじゅんぞう）
2000年、ソフトウェアを人の思考に近い「もの」という単位で考えることで、分かりやすいソフトウェア開発を行えるというオブジェクト指向技術の企業、豆蔵を立ち上げ、ITアーキテクト、メソドロジィストとして経験を積む。現在は、ビジネスとITの可視化を行うための要求開発方法論を要求開発アライアンスメンバーとともに作成し、自らユーザー企業で実践しながら後進の指導に当たる。2008年7月、匠Labを設立し、IT業界のさらなる価値向上を目指す。
Copyright © ITmedia, Inc. All Rights Reserved.