ASP.NET Webアプリ開発の裏事情 エピソード3：「決まらない仕様」と「迫る納期」のはざまでの闘い ――　ASP.NETでプロジェクトが火を噴くのを回避せよ　―― 小田原 貴樹（ハンドル・ネーム：うりゅう） 2004/12/25

筆者略歴 8年間のベンチャーIT企業勤務を経て、フリーのプログラマとして独立。専門はWebアプリケーションの設計・開発。「生涯一プログラマ」を目標に、常に中小事業者を対象とした現場に立ち続けている。納期・締め切りとの闘いには、ほぼ全敗中……。

　 　

顧客担当者：	「小田原さん、どうですか？ お願いしているショッピング・サイトは予定どおりに完成しますか？」
筆者：	「も、もちろんじゃないですか。予定どおりになるように最善を尽くしています」
顧客担当者：	「いやー、関係各社にもサイトのオープン日を伝えてありますので、お願いしますよ！」
筆者：	「そ、そうなんですか……。頑張ります……。で、今日頂けるはずの、サイトで販売する商品の詳細情報を受け取りに来たんですが」
顧客担当者：	「あー、ごめんなさいねー。こっちも忙しくて、まだ資料が出来てないんですよね。出来上がり次第ご連絡しますから」
筆者：	「え……でも、サイトのオープン予定日まで、あと5日なんですけど……」

　すべてのプログラマにとって、プロジェクトにおける最大の懸案事項といえば、やはり納期の問題だろう。営業職であれば、受注金額やプロジェクトの利益の方が気になるところなのだろうが、技術者であり生産者であるプログラマにとってみればそんなものは正直、二の次だったりする。

　納期を守れないとなると、すみませんでしたでは済まされない。何とかそれを避けようとすると、どうしても無理な勤務状況になってしまう。精神的な安定のためにも、ゆったりと開発できる納期が欲しい……ところなのだが、現実はなかなかそれを許してくれないものだったりする。

　結果として、どうしても納期ギリギリの勝負になってしまうのが常だ。納期が迫っているのに仕様がすべて決まっていない……なんて、プログラマにとっては悪夢のようなこともインターネット系のWebアプリケーション開発では当たり前だったりする。

　冒頭のような会話はあくまでその一例にすぎないが、とかくWebアプリケーションの開発においては、プログラマの苦労が増大しやすい。ということで、今回は、特に中小規模の開発現場で起こっている納期にまつわる悲劇をご紹介し、そしてそれに対する筆者なりの苦肉の策を示していこう。

「決まらない仕様」との闘い

　クライアント／サーバの業務システムと比較して、インターネット系のWebアプリケーション開発では、仕様がなかなか確定しないことが多い。これは、企業ホームページやショッピング・サイトなどは、必要に迫られて発注されるものではないからだ。

　各機能の要件定義などを行う際でも、業務システムではニーズがはっきりしているため「こうしてほしい」という要望がしっかりと決まっていることが多いが、インターネット系の場合には「こうだったら面白い」というような漠然とした希望であることが多いようだ。

　プロジェクトの初期段階において、要件定義の代わりとしてサイトマップを作成することが、中小規模のWebアプリケーション開発では一般的に多いだろうが、サイトマップ作成によりサイト全体の構成が決まっても、各ページの詳細な機能設計までは確定できない。よって、プログラマ自身が顧客との打ち合わせを担当している場合には、詳細な設計が必要なページを重点的に詰めておくことで仕様が決まらないという問題を回避できる場合もある。しかし、営業担当やデザイナーが窓口の場合には、そうした認識そのものが欠けている場合もあり、仕様がなかなか決まらないという事態になりやすい。

　例えば、あるホームページの案件で、発行するメール・マガジンのバックナンバーを検索できる機能を作成することになったときのことだ。

筆者：	「頂いた各ページのデザインですが、確かに検索のページはあるのですが、肝心の検索結果のページがないのですが……」
元請け担当者：	「え？ 検索結果のページって、メール・マガジンの内容を表示するページじゃないんですか？」
筆者：	「いえ、この仕様だと何年何月に発行したかという条件で検索した場合、複数の結果が取得できますよね？ なので、実際の内容を表示するページの前に、複数の検索結果がまとめて参照できる一覧ページが必要になります」
元請け担当者：	「なるほど。じゃあ、検索結果では何を表示したらいいんでしょうか？」
筆者：	「いや、そこについては顧客と打ち合わせしてくださいよ！」
元請け担当者：	「あー、そうですね。話をして決めておきます……」

　この段階で、最初に決まっていた納期まで3週間程度。筆者は、このまま放っておくのは危ないと判断した。元請けの会社はホームページ・デザインを主業務にしている会社だったので、担当者はプログラミングに関する知識に乏しかったようだ。そんな担当者と、同じくプログラミングを知らない顧客が打ち合わせをしても仕様が確定するとは思えなかった。

　そこで、検索ページの内容から想定し得る検索結果ページを、ASP.NETのDataGridコントロールを利用して仮に作ることにした。もちろんデザイン性は無視しているので作り直しは承知のうえだ。打ち合わせのベースになるひな型がないと仕様が確定しないだろうと判断したからだ。仮の検索結果ページをテスト環境に配置して担当者に見せると、検索結果の一覧ページの内容をイメージできたらしく、数日後には顧客からの要望が取り込まれたデザインが送られてきた。仮作成したページは完全に無駄になってしまったわけだが、そのおかげで仕様を確定させることに成功したのだ。

　これはあくまで「仕様が決まらない」ケースの一例にすぎないが、インターネット系のWebアプリケーション開発では、どうしてもこういった「要件が定まらない」という問題が付きまとう。特に、納期とのはざまに立たされると「いいかげんにしてくれ」と思わないでもないのだが、顧客の担当者は通常業務をこなしながら、その中で時間をやりくりしながら打ち合わせや資料の準備をしているわけで、それを考えれば仕方のないことなのかもしれない。

トリはつらいよ？ どうしても最後になってしまうプログラミング

　納期をシビアなものにするのは、なにも顧客だけとは限らない。

筆者：	「M社のショッピング・サイトのデザイン、もう出来上がったかな？」
デザイナー：	「いえ、まだ出来ていませんけど」
筆者：	「あー、そうなんだ……。現段階で、どのくらい出来上がってる？」
デザイナー：	「……半分くらいです」
筆者：	「え！？ 納期まであと2週間しかないんだけど……」
デザイナー：	「だって！ 思いつかないんですから、しようがないじゃないですか！」
筆者：	「そ、そうだね……。でも、早くしてね……」

　「エピソード2：デザイナーとの飽くなき闘争（前哨戦）」でも書いたが、ショッピング・サイトなどのインターネット系のWebアプリケーション開発の主役は、プログラマではなくデザイナーである。ユーザー・インターフェース（UI）部分の構築をデザイナーが担当するのだから、顧客との打ち合わせの主体も、デザイナーである彼／彼女らがデザインし、作成した成果物となる。デザインが完成する前にプログラマにできる作業は、データベースへの接続部分などの下ごしらえ的な部分だけになることが多く、どうしてもデザイナーの作業を待ってから本格的なプログラミングを開始することになってしまう。

　さらに、これは現実的な問題として、中小規模のインターネット系のWebアプリケーション開発において、1つの案件で納期が半年後ということはまずない。ショッピング・サイトの構築など大がかりな開発であっても、3カ月も開発期間が取れればよい方だ。悪くすると、全体を1カ月程度で構築しなければならないケースも多々ある。

　これは、ショッピング・サイトを運営する顧客がそれほど長い期間を待ってくれないという問題以上に、それを開発するわれわれが1つの中小規模サイトの開発案件に半年以上も時間をかけていては採算が取れないという企業経営面での問題の方が大きい。

　仮に納期の確保がうまくいき、例えば3カ月の開発期間があるとする。その場合、それぞれのフェイズで必要になる期間は大体以下のようになるだろう。

1. 要件定義（サイトマップ作成）：0.5カ月
2. 仮デザイン作成（打ち合わせ）：0.5カ月
3. ページ・デザイン作成：1カ月
4. プログラミング（兼テスト稼働）：1カ月

　プログラミング・フェイズの中のテスト期間が仮に1週間だとすると、順調にいってもプログラミングにかけられる期間は3週間程度ということになる。しかし、ほぼ必ずといっていいほど順調にいったりはしない。

　まず、仮デザインを作成しても顧客から何度か修正要望が入る。それを直して再度打ち合わせをしながら、実際のページ・デザインを作成していくことになるのだが、デザイナーというのは芸術系でクリエイティブな職種なので、「相性」というか「好き嫌い」というか、案件が肌に合うか合わないかによって、制作スピードが大きく変化するようだ。

　そして不幸にも肌に合わない案件だった場合、スケジュールがぐいぐいと押してくる。その結果、先のような会話が繰り広げられることになってしまう。気が付くと、「プログラミング開始から納期まで1週間くらいしかないや。あはははは」と、笑うしかないような事態もしばしば起こってしまう。

　これが自社内のデザイナーであれば、管理が悪いから仕方ないということにもなるが、デザイン部分は元請け会社が作成して、それ以外のプログラミングのみを下請けとして受注した場合に、このような事態が起きてしまうと、何もいえなくなってしまう。

　状況をかんがみて、元請けが顧客と納期交渉をしてくれればいいのだが、どうしようもないケースもあり、その場合は完全に時間との勝負になってしまう。そして経過はどうあれ、納期直前の段階（もしくは納期を過ぎた段階）で出来上がっていないのはプログラムということになり、納期との闘いで最も厳しい部分を受け持たなければならなくなる。自然とプレッシャー・ストレスも大きくなるし、トラブルが発生した場合の非難も受けやすい立場だ。仕方のないことなのだろうが、全体の作業の最後（トリ）を受け持つというのは何かにつけてつらいものである。

ASP.NETは解決策になり得るか？

　インターネット系のWebアプリケーションの開発には、ここまで紹介してきたようないろいろな問題が付きまとう。筆者のこれまでの経験から、プログラマ・サイドでこうした問題に対処する方法は、大きく分けて以下の3つがあると思う。

1. 全体構成はもちろんだが、各機能（ページ）の要件定義にあいまいな点を残さないように、怪しい個所は早い段階で詳細を詰めておく。
2. 必要に応じて、挙動を確認するための仮のプログラムを作成する。
3. 仕様変更や修正に素早く対応できるように、再利用しやすいプログラミングを行う。

　1に関しては最も大事なことなのだが、これはコミュニケーションの問題であるので、普段から気を付けるしかない。この連載ではコミュニケーションの重要性を訴えてきているつもりだが、技術者にとって技術力と同じくらい大切なのがコミュニケーション能力だと筆者は考えている。

　2と3に関しては、ASP.NETが解決策に十分になり得る。2の仮プログラムの作成は、できるならばしたくない作業だが、状況によっては必要になる。ただしその際に、仮プログラムを作成するのに時間がかかってしまうようでは本末転倒だ。

　短時間に低労力でざっと挙動を確認できるようなプログラムを作成する必要があるが、その場合、ASP.NETで用意されている便利なコントロールや、豊富なクラス・ライブラリには大きなアドバンテージがある。特に、打ち合わせレベルでの要件定義・仕様決定が煮詰まりきらない場合には、テスト段階での大幅な修正を前提として、とにかく一度すべてを仕上げてしまう方がよいことが多い。仮のものといえども、納期前に全体的な仕組みを仕上げてしまえば、顧客とのトラブルを回避しやすい。そうした割り切った開発を行うときにも、効率的で簡単な開発が可能なASP.NETの優位性は大きい。

　このようなASP.NETの優位性については3についても同じことがいえる。ASP.NETによるWebアプリケーションの開発では、基本的に再利用性を加味したプログラミングが効率よく行えるようになっている。例えば、デザインを修正しても、コードビハインドのおかげでコードの大部分は影響を受けずに済む。また、データベース接続部分などサーバ側ロジックをクラス化しておけば、ユーザー・インターフェイス（UI）そのものの変更にも柔軟に対応できる。今回、例に挙げているような中小規模のインターネット系のWebアプリケーション開発で、極端に短納期な制作を要求された場合には、この再利用性に関する効率の良さは、プログラマにとって非常に有効な武器になり得ると筆者は考えている。

　今回は、納期に関する問題として、どちらかといえばプログラマ自身の責任ではない（つまり、プログラミングが遅延して納期に間に合わなかったわけではない）ケースと、それへの対処法らしきものをいくつか紹介した。「現場ではこういった理由で、プログラマは苦しんでいるんですよ！」ということを強く訴えたかったのだが、もちろんプログラマ側に責任があるケースもたくさんある。

　ベンチャー企業やフリーのプログラマの場合、ある時期に1つの案件だけを受け持っていることはまずない。少なくとも2つ3つは案件を掛け持ちしているのが普通だ。そんな状況で、スケジュール調整を誤ってしまったり、もっと赤裸々にいえば、納期に余裕があるのにプログラミングを始めていなかったり、揚げ句の果てに、「いやー、どうも納期ギリギリにならないと乗らなくて……」などと、訳の分からないことをのたまっていたりする。だんだんと、筆者自身の胸が痛くなってきたのでこの辺にしておくが、このようなプログラマ自身の意識の問題については……自分自身で直していくしかない。いや、本当に直します。ごめんなさい。

　まぁ、とにかく、納期との闘いは、プログラマである限り永遠に終わらない闘いである。最大限、勝率が上げられるよう、筆者ともども、努力していこうではないか。

　

「ASP.NET Webアプリ開発の裏事情」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）