DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear
ホーム > ブログ > 中山 嘉之の記事一覧 > アジャフォール型開発手法


アジャフォール型開発手法

Pocket

 今回のブログは再び開発方法論を取り上げてみたい。最近、久しぶりにアジャイル/ウオーターフォール論争がネット上で活況を呈しているようだ。エンタープライズ・アーキテクチャの転換を唱えている本シリーズでも、構築するターゲット・アプリケーシヨンの変化や構築技術の進化を背景に、ここらで一つの開発手法をまとめておくことにしたい。“一つの”と書いた理由は、本来、開発手法はプロジェクトの性質にマッチした様々なスタイルがあり、しかも、ベースとなる方法論をプロジェクト毎にテーラリングして活用するものだからだ。今回取り上げるプロジェクトは基幹系/情報系のアプリ種別やパッケージ/スクラッチ等の実装方法を問わず、数百人月規模のビジネスアプリケーションを対象にしていると思っていただきたい。期間は半年~長くて1年程度といったところ。なお、全体で数千人月の大規模アプリケーションでも1リリース単位を1年以内に刻んだ際はこの規模になり得る。

反復開発

 かねてより「プロジェクトの成功からプロダクトの成功へ!」、「システムを作ることから創ることへ!」を標語に、あるべきシステム開発の姿を模索し続けてきた私としては、まず、開発工程の中核に位置する“設計・構築・テスト工程”にアジャイル手法を取り入れることを推奨したい。ここでお断りしておくと、財務会計に代表されるような定石がある業務アプリケーション(通常パッケージシステムを適用)はこの対象にはならない。なぜなら、それらは既に設計の大部分を終えており、イテレーションによる最適デザインの模索が不要だからである。

 図1はタイトル通り、「モデル主導でかつテスト駆動型の反復開発手順」を絵にしたものである。右上の時系列での作業比率の絵は懐かしいRUPのなごりであるが、ここでは分析作業は入っていない(システム分析は要件定義フェーズへ移動)。この手法の大きな特徴は何と言ってもモデル主導にある。各スプリントには当然ながら“設計”の要素が入っており、ドキュメントレスのアジャイル開発でもモデル図(データ及びプロセスモデル)だけはメンテンナンス対象として、反復の回数を重ねる度にそのバージョンを上げて行く。

 これと並行して変更管理するものにテストデータが挙げられる。教科書にないところは、このテスト工程で用いるテストデータ品質に力点があるところである。私のエンタープライズ・アプリケーション開発経験から、プログラマーの作り物のデータによるホワイトボックス・テストに長時間を割くより、既存システム上の生データを元にしたブラックボックス・テストにできるだけ早く取りかかる事が重要と思われる。このテストデータは、スプリントを回す度に、より本番データに近付けるべく、既存システムを熟知した“テストデータ作成チーム”が裏方として機能し、各スプリントにタイムリーに供給する。

 さて、ここまでは、アジャイル開発のメリットをできるだけ享受してプロダクト品質を磨く為に考えられた“開発プロジェクトのBODY“に相当する部分である。問題はここからだ。往々にして、”ちまた”のアジャイル/ウオーターフォール論争は、お互いの事を知らない者同志が相手を揶揄するばかりで、かみ合わないものが多い。これは、ウオーターフォールが、エンタープライズ・アプリケーションを対象とすることに起因する(最近ではエンタープライズ・アジャイルにも関心が高まりつつあるが)。エンタープライズ・プロジェクトの性格は、厳しい非機能要件に基づく高度な品質(Quality)、厳格な納期(Delivery)やコスト(Cost)がその特徴である。自由奔放に開発したいと思っても、背に腹は代えられない厳しい制約条件が突きつけられている。

アジャフォール型開発

 ではこれらのリスクを最小化しつつアジャイルの良さを活かすにはどうしたら良いだろうか?現時点での現実解としては、要件定義までは通常のウオータフォール型を採用することが賢明である。論理モデル、採用アーキテクチャ、インフラ環境等の大枠が一旦確定した状況下で、アジャイル開発に突入しないことには、あまりにプロジェクトリスクが大きいからだ。図2にその概要を絵にしてみた。真ん中の設計・構築・テストフェーズはアジャイル開発を採用し、両端の要件定義フェーズと移行フェーズはウオーターフォール型で実施するというハイブリッドなものである。下段には、開発に参画する各種プレイヤーをフェーズ別の役割とともに大よその面積比で示した。言うまでもなく、ここでのユーザ側情シス、エンドユーザの参画は必須である。

表題の”アジャフォール”はアジャイルとウオーターフォールをミックスした造語だが、反復によるシステムの進化も、要件定義から移行までの開発全体の進行も、どちらも曖昧なユーザ要求から具体的システムに落とし込む様は、高い所から低い所へ水が流れ落ちる状況の方がなぜかしっくりする。つまり言葉的にはスパイラルアップとは逆のイメージである。

  エンタープライズに浸っている人間は、自由度の高いアジャイルによって、要件が発散し収集がつかなくなるのではという潜在的不安がある。このリスクをヘッジし”物事が収束するイメージ”を加えたものが、この”アジャフォール”である。慣れない事に取り組む際には、まずは少しずつ馴染ませるのが良い。大事な事は、自己(社)流でも良いので、新たな開発手法にチャレンジする事である。なぜなら変わらない事も大きなリスクだから。

 

 

 

| 目次
Pocket

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
中山 嘉之
1982年より協和発酵工業(現、協和発酵キリン)にて、社内システムの構築に携わる。メインフレーム~オープンへとITが変遷する中、DBモデラー兼PMを担い、2013年にエンタープライズ・データHubを中核とする疎結合アーキテクチャの完成に至る。2013年1月よりアイ・ティ・イノベーションにてコンサルタントを務める。【著書】「システム構築の大前提 ― ITアーキテクチャのセオリー」(リックテレコム)

Recent Entries最近の記事