「開発スタイル」開発法 ―仕事に合わせて,自分に合わせて―

第1章 受託開発編

2008年6月16日

この記事を読むのに必要な時間:およそ 1.5 分

はじめに

受託開発の場合,まず顧客の要望があって開発がスタートします。その要望に応えられるシステムを作成するというのがプロジェクトの最終的なミッションです。

ここでは,受託開発というフィールドの中で,どのような開発プロセスが考えられ,実際に採用されてきたかについて簡単に紹介します。

ウォーターフォール型開発モデル

システムの開発工程を各フェーズに分割し,それを順番に実行していこうという開発モデルをウォーターフォール型と呼びます。ウォーターフォール,つまり滝のように流れ落ちるように作業を進めていくことからこの名前がつきました。

基本は,各フェーズをきちんと順序立てて進めていく,ということです。一般に,システムの開発工程は次のようになっています。

システムの開発工程

システムの開発工程

ウォーターフォール型の開発では,各フェーズで成果物を残し,それを元にして次の工程を進めていくことになります。基本的には,前の工程が終わるまで次の工程に進んではいけません。各フェーズをきちんとやっていれば,その次のフェーズであれこれ迷う必要がなくなるので非常に効率のよい開発スタイルと言えます。

欠点としては,最終的なシステムができあがるまで顧客がシステムを実際に見ることができないということが挙げられます。せっかく完成したのに顧客が思っていたものと違うものができあがってしまった……。この場合,作業に後戻りが発生するため非常に手間がかかってしまいます。どれほど各フェーズをきちんと進めていても,このリスクをなくすことはできません。

スパイラル型開発モデル

そうしたウォーターフォール型の開発の欠点を克服しようとして考えられたのが,スパイラル型の開発モデルです。

スパイラル型の開発では,まずプロトタイプと呼ばれるシステムを作成します。プロトタイプの目的は,顧客に実際のシステムを見せることで,要求や仕様に問題がないかのレビューを行うことです。レビューのフィードバックを元に,再びシステムを開発し直します。それを何度も繰り返すことでシステムの完成度を上げていきます。何度も繰り返す1回1回は,ウォーターフォール型の開発そのものです。

たとえプロトタイプといえども,最終的に必要とされる機能をすべて備えている必要があります。そうしないと完全なレビューが行えず,プロトタイプを作成する意味がなくなってしまいます。したがってコストが非常にかかる手法であるため,実際に採用されるケースは少ないようです。

実際の運用

受託開発の現場では,ウォーターフォール型の開発モデルが採用されてきました。その理由として,開発工程が順々に分かれているので計画が立てやすく,分業しやすいということがあります。

大規模なプロジェクトでは,プロジェクトに参画するメンバーを1つの会社で揃えるというのは実際問題として困難な場合が多かったのです。そういう事情に,「設計する人」「実装する人」が異なっていても問題ないウォーターフォール型の開発モデルは非常にマッチしました。要求分析から設計までを行う会社と,実装だけを行う会社が協力してシステムを開発するということが一般化したのです。

この分業制はさらに発展し,今日ではオフショア開発と呼ばれる形態も取られるようになっています。たとえば,日本にある企業が要求分析,設計を担当し,実装を外国(中国,インドなど)にある企業に委託するような形態です。外国の企業に発注した方が人件費が安く済むため,トータルでコストを抑えることができると期待されています。

ドキュメントとコミュニケーションの大切さ

分業するからには,それぞれのフェーズの担当者の間で認識を合わせないと失敗します。まずはドキュメントをきちんと書くことです。設計書,仕様書がきちんと書かれていない限り,認識を合わせることは不可能です。お互いの理解を助けるためにも,ドキュメントはしっかり書かれる必要があります。もちろん,必要以上に体裁にこだわる必要はありませんが。

そうしてドキュメントを作成したとしても,設計者の思った通りのシステムが実装されてくるとは限りません。常にコミュニケーションを行い,認識のズレが生じていないか確認しておく必要があります。オフショア開発の場合,コミュニケーションはさらに重要な要素となります。そのためのコストが想像以上にかかることも多いので,本当にオフショア開発が効果的なのかどうかは慎重に判断する必要があるでしょう。

細かいイテレーションへ

分業が進むと,どこかで手戻りが発生した場合のコストが大きくなってしまいます。もうすでに実装が開始されていたり,実装が完了しているシステムに対して仕様の変更など予定外のことが発生した場合,作業をやり直すコストは非常に高くつきます。ウォーターフォール型の開発の最大の問題は,最初からシステムを完成させることをゴールに据えて大きな単位で作業が進んでいくことなのです。

そのため,もっと小さな単位でイテレーション(反復)を行うことが考えられるようになってきています。たとえば1機能,1画面の単位で短期間でシステムを開発し,顧客のレビューを通しながら徐々にシステム全体の軌道修正を行っていくといった方式です。それを継続して行い,機能を少しずつ加えていくことによって,完成したシステムが顧客の思っていたものと違っていた,といった失敗を防ぐことができます。

小さな成功を積み重ねていけば,大きな成功により近づくことができるのです。

まとめ

必要なドキュメントを書くこと,コミュニケーションをしっかりとること。そして小さな単位でイテレーションをまわし,それを積み重ねていくこと。こうした方式を,アジャイルソフトウェア開発手法と呼ぶこともあります。興味を持たれた方は,「アジャイル」で検索してみてください。いろいろな工夫が開発ブロセスに対して行われようとしているのがわかると思います。

著者プロフィール

山岡広幸(やまおかひろゆき)

1978年,東京・小岩生まれ。

詩を書いたり料理をしたりプログラミングしたり。MoonyというPHPのフレームワークを制作中。

ウノウ株式会社エンジニア。

Twitter: http://twitter.com/hiro_y

コメント

コメントの記入

ピックアップ

EC事業者が注目,.shopドメインとドメイン名をとりまく新たな流れ

インターネットの可能性を広げる新たな動きが,ドメイン名をめぐって起こりつつあります。

エンジニア特化型Q&Aサイト「teratail」のトップランカーたちが語る,確実な力を付けるための“質問力”

エンジニア特化型Q&Aサイト「teratail」のトップランカーの方々に集まっていただき,座談会を開催しました。

Webサイトに“安心”をプラス―知らないでは済まされないSSLサーバ証明書の仕組み

いまやユーザといえでも必須の知識となったWeb通信の暗号化と,その信頼性を確保するための「SSL証明書」のしくみについて紹介します。

リクルートライフスタイルの技術力を追え!

ビジネスを拡大し続けるリクルートライフスタイルの技術力を,編集部の徹底取材により紐解きます。

開発スピードに限界を感じたときの処方箋

「JIRA」をはじめとするアトラシアンのツール群。多くのオープンソースソフトウェアを継続して提供する支えとなっている使い易さを探ってみます。

デジタルコンテンツを日本から世界へ―MyCommerceで始める越境EC

自社開発ソフトウェアを海外も含めてオンラインで販売したいというニーズに即したサービス「MyCommerce」を用いて,誰もが手軽に越境ECを実現するためのノウハウを紹介します。

バックナンバー

No12(2009.04)

今回のSoulHackで主に取りあげるのは,梅田望夫の「ウェブ時代をゆく」という本です。

No11(2009.03)

今回のSoulHackで取りあげるのは,阿部謹也の「世間学への招待」と他1冊の本です。

No10(2009.02)

今回のSoulHackで取りあげるのは,山本七平の「空気の研究」という本です。

No9(2009.01)

今回のSoulHackで取りあげるのは,アーノルド・ミンデルの「紛争の心理学」という本です。

No8(2008.12)

今回のSoulHackで取りあげるのは,河合隼雄氏の「カウンセリングを語る」という本です。

No7(2008.11)

特集:2008年度日本OSS貢献者賞受賞者インタビュー

No6(2008.10)

特集:エンジニアの実践的キャリアアップ思考法

No5(2008.09)

特集:事例でわかる,プロジェクトを失敗させない業務分析のコツ

No4(2008.08)

特集:ゼロからはじめるPSP

No3(2008.07)

特集:今こそ使える! プロトタイピング

No2(2008.06)

特集:「開発スタイル」開発法

No1(2008.05)

特集:エンジニアが身につけたい基本スキル 2008

-->