いかにして開発を効率化し、納期を短縮化するか? 家造りの考え方を参考に短納期開発の方法をあらゆる確度から紹介してきたエクスプレス開発バイブル。最終回となる今回は、従来以上にスピードが求められる本格的なクラウド時代の到来に備え、いま一度、エクスプレス開発手法の実践のポイントを振り返っておこう。
家を造るように、効率よくシステム開発ができないだろうか?──システム開発の短納期化が年々進む中、多くの開発関係者がこのテーマに関心を寄せ続けています。そうした中、本連載は「家を造るようにシステム開発を行うことは、可能である」という前提に立ち、筆者自身の開発経験を裏付けとしたノウハウを「エクスプレス開発手法」と名付けて、具体的な実践方法を紹介してきました。
最終回となる今回は、エクスプレス開発手法の開発現場への適用に役立ててもらえるよう、これまでに紹介した数々のノウハウを振り返り、その特性をあらためて解説しておきたいと思います。これにより、筆者の知見をあらゆる開発案件に少しでも生かしてもらえれば、本連載は本当の意味で目的を果たしたことになるからです。
では早速、本論に入りましょう。以下では、第1回で解説した「家造りの文化の7つのエッセンス」に当てはめて、連載を振り返ってみたいと思います。
以下にまとめた「システム開発に適用すべき、“家造りの文化”のエッセンス」は、(ビルなどの大規模かつ特殊な建築物などではなく、)「一般的な家屋を造る」という意味での「家造りの手法」の特徴をまとめたものです。
エクスプレス開発は、この7つのエッセンスのすべてを、システム開発に適用しています。各エッセンスについて詳しく述べている連載回数も記したので、クリックして、ぜひもう一度読み返してみてください。
システム開発に適用すべき、“家造りの文化”のエッセンス |
|
提案と選択 (第2回) |
顧客の要望をイチから聞き出すのではなく、既存の案件や事例を提案し、選択してもらう 実現のカギ=業務イメージ図 |
専門性 (第3回) |
システム開発はもちろん、顧客企業の業務についても深い知識を持つ“プロフェッショナル”として接する 実現のカギ=業務とシステム開発の知識・経験、進め方の専門性 |
説明は写真やイラストを中心的に使い、文字は付加情報として使う。顧客にとって必要な情報以外は最小限の説明にとどめる 実現のカギ=業務イメージ図 |
システムを使って作業を行う“業務の現場”に実際に出向き、進ちょくなどを打ち合わせする 実現のカギ=2チーム制/開発現場に置く開発サイト |
|
重要な打ち合わせには、プログラマやエンドユーザーも含めて、主要メンバー全員が参加する 実現のカギ=2チーム制/開発現場に置く開発サイト |
|
モジュール化 (第4回) |
モジュール化を進める。目的のシステムを開発するうえで、顧客が“部品”として認識しやすいモジュールをそろえる 実現のカギ=設計思想書 |
コストやリスク面で顧客の要望と折り合わなくとも、「どうすればできるか」を徹底的に考える 実現のカギ=開発案件3分割 |
「提案と選択」「専門性」といった各エッセンスと、それぞれの「実現のカギ」を対比していただいても分かると思いますが、「エクスプレス開発」とは、システム開発の深い経験・ノウハウと、それに基づく「分かりやすいドキュメント」が実現のカギになっています。
すなわち、エクスプレス開発は、「プロとして蓄積してきた経験・ノウハウを応用する」ことと「必要な情報を可視化する」こと――この2つが実践のカギとなっているのです。まずはこの前提をしっかりと認識してください。
では、エクスプレス開発手法を実際に取り入れていくためには、具体的にはどんな点がポイントになるのでしょうか? 以下では、準備段階と実行段階のポイントをあらためてまとめておきます。
ちなみに、顧客やユーザーにエクスプレス開発手法自体を理解してもらう必要はありません。そこで時間を費やすのはとてももったいないことです。仮に説明を求められても、従来のウォーターフォール・モデルとして説明しておけば、相手の専門知識の有無を問わず、理解を得やすいと思います。
ただ、エクスプレス開発は「短納期」を目的とした手法であることから、文字通り「短納期」を求められている案件には絶大な効果を発揮しますが、そうではない場合、必ずしも効果を発揮できるとは限りません。特に対象となる開発プロジェクトが以下のどれかに当てはまる場合、適用はお勧めできません。
筆者の経験から言えば、エクスプレス開発は数十人月以下の、中/小規模のプロジェクトに適していると言えます。一般に、大規模プロジェクトではシステム自体が複雑なものとなるため、概要設計の段階から「機能」や「影響範囲」を想定しつつ3分割して開発を進めることは、後工程で仕様変更のような事態が持ち上がる可能性もあり、コスト、時間、労力の面でリスクが高くなるからです。
エクスプレス開発では、基本的に顧客の業務現場を重視し、開発サイトを現場に置くことを前提としています。そうすることで、ユーザーの意向を迅速かつ柔軟に開発作業に反映することを狙うわけです。従って、この現場側に置く開発サイトと、本社側に置く管理者サイト、2つの部隊の物理的距離が遠いと、開発を円滑に進めることが難しくなってしまいます。例えば、現場主導でシステムの仕様変更を行ったり、テスト計画を立案した際などに、プロジェクトマネージャが直ちに確認するといったことがしにくくなるわけです。
むろん、近年はクラウドサービスとして提供する開発ツールなど、開発チームのロケーションの問題を解決する製品も存在してはいますが、場合によっては、現場にいるユーザーを交えてドキュメントを参照しながら複数の関係者で話し合ったり、その必要があれば、すぐに業務現場から関係者を連れてくる、といったことも求められます。
こうしたケースについて、システムでもある程度は対応できますが、やはり「全関係者が物理的に近いところに集まっており、いつでも会える」ことの利便性・機動力にはかないません。すなわち、エンドユーザーの業務現場が遠隔地にあるような場合、エクスプレス開発は基本的に適しているとは言えないのです。
前述のように、エクスプレス開発は「プロとして蓄積してきた経験・ノウハウを応用する」ことが前提となります。すなわち、そのシステムで支援する業務に対する深い専門性や経験が不可欠となるのです。むろん「開発に業務知識が不可欠」なことは、エクスプレス開発に限らず、すべての開発案件に当てはまる極めて基本的なことではあります。しかしエクスプレス開発の場合は、開発案件を3分割するなど、作業を効率化するうえで業務に対する深い知見が必要となるため、未経験の業務にはなおさら適用が難しくなるのです。
Copyright © ITmedia, Inc. All Rights Reserved.