連載
» 2009年08月17日 12時00分 公開

納期・コストを削減する“開発案件3分割”の術エクスプレス開発バイブル(5)(1/3 ページ)

開発案件に含まれる業務処理機能を精査して、カットオーバー日までに必要な機能とそうでないものを分けたうえで、開発作業に優先順位を付けてみよう。たとえ厳しいスケジュールでも、要求をクリアするための確かな抜け道が見えてくる

[西村泰洋(富士通),@IT]

 第4回『“設計思想書”で開発の効率と質を高めよう』では、開発の作業効率を高める方法として、システム設計の目的や要点をまとめた“設計思想書”を用意し、過去の開発資産を積極的に再利用する方法を紹介しました。

 これは「日常的に行っている多数の開発案件の“基本部分を共通化”することで、あらゆる開発案件の作業を迅速化する」という考え方によるものです。しかし、開発案件はさまざまです。この考え方だけでは対応できないケースも出てきます。今回は、個々のシステム開発作業を迅速化する、別のアプローチを紹介しましょう。

顧客の求める開発期間をうのみにしない

 まず事例を通して考えてみましょう。第1回『超短期開発を支える7つのエッセンス』でも使った、「日本法人を展開したばかりの外資系企業が、ビジネスの立ち上げを急ぐため、システム開発会社に、3カ月での物流システム開発を求めた」ケースを想定してください。

 そうした場合、ウォーターフォールでは求められたシステムが仮に小規模であったとしても、こう答えるのが一般的だと思います──「要件定義と概要設計で2カ月、詳細設計と開発作業で3カ月、各種テストで1カ月──合計6カ月を要するので3カ月では無理です」

 しかし、それでは“徹底した顧客起点”の考え方を重んじるエクスプレス開発の流儀に反します。仮に条件が合わなくても、「できない」とむげに切り捨てるのではなく、「どうすればやれるか」を考え、「3カ月で何とかやります。ただ、必要な部分は協力してください」と答えたいところです。

 そのためのノウハウも、この連載でこれまでも複数紹介してきました。例えば、時間がかかりがちな要件定義では、顧客の要望をイチから聞き出すのではなく、既存の事例を用意してアイデアを提案・選択してもらう、概要設計フェイズでは、前回紹介した設計思想書を利用して、既存資産の中から使えるものを再利用する、といった方法です。

 しかし、それでも納期の短縮化には限界があります。特に顧客の個別要求を具現化する詳細設計以降は、どうしても時間がかかるものです。とはいえ、開発チームとしては、顧客の期待や信頼が大きければ大きいほど、先方の希望する「3カ月」という納期を死守したいはずです。いったいどうすればよいのでしょうか?

 そこで、あらためて確認してほしいのです。顧客のいう「3カ月」とは、「本当に3カ月なのか?」と──。

よく考えれば、“実質的な開発期間”がみえてくる

 これは、「順調に進まないケースも想定した“実質的な開発期間”を、現実的な視点であらためて見直してみよう」という意味です。この例の場合、「納期3カ月」、すなわち「システムのカットオーバーまで3カ月」ということですが、本当に“きっかり3カ月”なのでしょうか?

 まず確認すべきはカットオーバーする具体的な日付です。これはシステム開発に携わる方であれば、皆やっていることと思います。例えば「3カ月でカットオーバー」といっても、現在が2009年7月18日だとしたら、「2009年10月18日」より、「2009年11月1日」と考える方が現実的ではないでしょうか?

 それを顧客企業に確認して、推測が正しかったとすると、厳密には3カ月に加えて「10日間ほどの余裕」という“のりしろ”を確保できたことになります。“のりしろ”の有無は詳細スケジュールを組むうえで重要なポイントとなるので、必ず確認しておきましょう。

 正式な日付を確認すると、また別の疑問がわいてきます。それは「顧客企業は本当に、11月1日にすべての処理をオペレーションするのだろうか?」、換言すれば「本当に11月1日までに、開発案件に含まれるすべての処理機能が必要なのだろうか?」ということです。

  処理といってもいろいろありますが、例えば 「棚卸し処理」などの利用時期は期末が一般的です。月に一度は棚卸しをするという企業でも、処理をするのは月末でしょう。従って「棚卸し処理」と「月次の更新処理」機能などは、厳密にいえば「11月1日に必要不可欠な処理ではない」と判断することができます。ここでまた新たな“余裕”が確保できました。

 これが今回の考え方のポイントです。まず最初にカットオーバーの日付を確認したら、数ある処理を「カットオーバーまでに不可欠な処理」と「不可欠でない処理」に分ける(注1)のです。これだけで“実質的な開発期間”を伸ばすことができます。これは、金融機関の大規模システムなどを構築する際に、以前からよく用いられている考え方です(注2)。


注1: あえて言及しませんでしたが、ハードウェアやソフトウェアの基本設計・構築は、むろん「カットオーバーまでに不可欠」です。この2分割法の対象となるのは、基本的にハードウェア・ソフトウェアの“作り込み”にかかわる各種処理機能です。

注2: ただ、金融システムの場合、カットオーバー日に必要な処理と、そうでない処理を分けるのは、「顧客の期待に応えるため」というよりは、 大規模開発のため、「この日でないと、その処理機能を完成させられないため」というケースが多いのが実情です。最終的なカットオーバー日も各処理機能の完成日程を積み上げて決めるのが一般的です。ここでは開発期間確保のための基本的な考え方を理解してもらうために例示しました。


       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ