eソリューションの現場から

｢ニッセンオンライン」ECサイト構築の軌跡（前編）

2.ファーストリリースへの歩み

　リリースまでのわずかな時間が過ぎる中で、とにかく安く速く開発するにはどうしたらよいか悩みました。あらゆる無駄を取り、省けるものは省き、いままでのやり方をすべて白紙にして推進させようと心に決めました。いままでのやり方にとらわれていては、確実に間に合わないと思ったからです。

　問題は山積みでした。この活動に確保できたメンバーが私を入れて2.5人（1人は別作業と並行参加）。全員がインターネットおよびJava開発の素人でした。技術／開発スキルの習得とプログラム開発を同時に行わなければならない……なんといってもWebLogic自身の性能を引き出すセッティングをしなくてはいけない……どれもが手探り状態でした。1分を惜しんで手に入る情報を取り込み、何とか開発につなげていきました。どうしたら早くリリースできるか模索し、実現に移すことだけを頭に置きました。

■スキル不足への対策

　どうやっても、絶対的に足りないスキルをすぐに埋めることはできません。やはり、社外に強力なパートナーを得ることで補うことにし、参加を呼びかけました。少ない費用で、時間の不足を補えるパートナーを求めました。キーポイントである時間不足を補うパートナーに求めたものは、

1.「即戦力であること」
　環境、システム構成などの説明をしている時間はとてもありませんでした。最小限の説明ですぐにシステム構築に着手できるパートナーが必要です。これはいまでも選択の基準としています。

2.「創作意欲が高いこと」
　こちらから作業を指示／依頼することが期待できません。自らが活動、提案していただけるメンバーを望みました。作業者でなく、協力者であること。システムリリースの成功を目標として一緒に歩んでいただけるメンバーを求めました。

　本当に、運良く時間内に優秀な「開発パートナー」と「WebLogic技術サポートパートナー」を得ることができました。スキル確保の難題が緩和でき、協力パートナーの皆さまには感謝の限りです。

（１）開発パートナー
　開発パートナーとして、CSK社さまが手を挙げてくださいました。CSK社さまと当社は基幹システム開発保守のお付き合いがあり、以下の理由から即座にお願いしました。

・	会社の仕組みをよく知っており、教育時間が不要
・	オープン環境での開発の実績があった
・	インターネット研究活動を早くから実施していた

　CSK社さまも今後のインターネットでの開発ビジネスを模索していたところで、両者の思惑が合致したわけです。開発スキルの補填とメンバー2名の増員を図ることができました。参加いただいたメンバーは責任感が強く、作業を任せておくことができ、成功のかぎとなったのはいうまでもありません。当社メンバーとは別の作業を分担し、効率良く活動することでシステムの立ち上げという目標に力を集中させることができました。

（２）技術サポートパートナー
　WebLogic購入にあたり、価格だけでなくサポート力に焦点を当てて購入先決定の検討をいたしました。これは、カタログ機能および論理的な能力を実際に実現できるパートナーでなければ成功はあり得ないと考えたからです。インターネットシステムの経験のある企業を必要としていました。

　幾つかの会社から提案を頂き、BEA社との連携状況を評価したうえで、沖電気さまをパートナーとして決めました。WebLogicの上でシステムを構築・開発するに際し、すべての問題点への迅速な返答、対応策の提示をしていただく役割を担当していただきました。おかげでシステム構築活動を加速させることができました。

■初期開発の取り組みの反省点

　当初、プログラム開発は、できるだけ開発者の裁量に任せて開発スピードを確保する方法を取りました。この作業方法で問題を起こさなかったのは、非常に少数で活動したことの産物だったと感じます。現在のような大部隊になったときには開発標準化が必要であるとあらためて思います。個人の裁量に任せた場合には、開発は早いが保守に時間がかかります。

　ここでは、大ざっぱな5つの確認だけをするにとどめ、すべてのプロセスを並行に進め、何かを待っている姿勢がないように努めました。取り決めた活動は、進めていくうちに長所・短所が分かり、次の活動につながるものとなりました。

1	スパイラル手法の採用
2	ドキュメント記述作業の撤廃
3	ツールの利用による作業量の軽減
4	基幹システムの部品的な利用
5	会議の廃止

（1）スパイラル手法の採用
　とにかく画面を確認してもらいながら開発した方が完成が早いと考え、レビューと開発をできるだけ並行に実施するように努めましたが、半分は失敗でした。レビューの都度修正が発生し、開発者の混乱とバックログを発生させることになったからです。

　レビューは、悪い点が指摘され、難しい機能を要求されます。指摘はすべて正しいものばかりですが、必要性や重要性を判断する根拠を導き出すのに多くの時間が必要になります。今回は時間を取られることを避けるため、投資効果の検討をすることなく受け付けました。さらに、リリースを2段階に分けて対応することにして、第1段階の開発に集中しました。つまり、「必須なもの、現状レベルの実現」と「必要であるが必須ではないもの、オプション機能の実現」とに分けて整理し、周りの賛同を得て進めました。100％完璧であれば稼働が遅れていたでしょう。50％の開発工数でしたが、80％の能力のものが提供できました。残りの開発は作業工数の割に効果が小さくなります。現在は投資効果を考えてリリース範囲を決めるように考えています。
（編集注：第１段階のリリースでは、消費者にカタログ番号で注文を受け付ける仕様を実現した）

（2）ドキュメント記述作業の撤廃
　開発者も設計者もドキュメント記述は概して苦手なものです。ドキュメントを記述するより、プログラムを作ってしまう方を優先させる傾向にあります。また、スパイラルな開発手法を採用したことにより、評価と設計を繰り返す状況が発生して設計書や仕様書への修正が多くなることが予測され、一度作成したものを無効にする無駄な修正時間は解消したいと考えました。以上の2点から、すべてのドキュメントをなくし、開発に集中させる方針を出しました（ただし、必要が生じたら、必要なものだけを作成することにしていました）。

　これは、一長一短でした。長所は、想定どおりプログラムの作成が速かったことです。短所は、機能修正や保守時の生産性が悪くなってしまうことです。仕様変更、要求変更があった場合には、必然的に特定の開発担当者に依存してしまうことになります。これは1人のメンバーに作業が集中する結果となり、効率を悪化させてしまいます（現在はこの状況を解決するために、ドキュメント生成ツールを利用することで、メリットを失わず解決させています。これについては後半で解説します）。

（3）ツールの利用による作業軽減
　ツールを利用した開発速度の向上を試みました。習得する時間がないことから、どれも失敗に終わっています。ツールの利用は、当初の効率が非常に悪く、後から効果がでることから、当プロジェクトには向いておりませんでした。ツール導入時は少し長めに設定できる小さなプロジェクトから採用した方がよいと思います。特に期待していたのは以下の2つのツールでした。

●Borland JBuilder
　前述のとおり、習得する時間と必要事項を規定するだけの時間がないことから、逆に開発速度を鈍らせてしまいました。将来迅速な開発につながることは分かりましたが、時間の余裕が作れない状況が効果を上げられない原因でした。結局、直接コーディングする方が速く、当時は利用を一時ペンディングしました。

●Microsoft　FrontPage
　画面の作成と設計レビュー後の修正作業には効果を発揮しました。簡単に画面が作成でき、設計レビューでは問題点の指摘をその場で変更することもできました。当初、システム構築を素早く完成まで持っていくツールと評価していました。

　ところが、実際にこのツールで生成される画面はマイクロソフトのくせのあるHTMLでした。Internet Explorer以外のブラウザで動作しなかったり、Windows以外で動作しないケースがありました。スキルがないわれわれが原因を究明するまでにすごく時間を費やし、泣かされることになりました。無駄なコードの削除が、かえって時間を使うことから利用を取りやめました。ほかのツールも調査しましたが、安くて良いツールを見つけることができませんでした。

（4）基幹システムの部品的利用
　システム開発方法として、基幹システムの処理を部品として利用することで開発時間と工数の短縮を図りました。この選択は正しかったと考えます。受発注管理、在庫管理、出荷の仕組み、売掛金管理など複雑な処理はすべて基幹システムにありました。必要なものは基幹システムと連動させ、フロントの表示と操作の仕組みを作ることに集中できました。基幹システムに接続できたことは、開発の迅速さだけでなく、システムの安定、パフォーマンスの維持、リアルタイム処理サービスのすべてを達成できることになりました。

（5）会議の廃止
　全員の時間が取られる会議はできるだけ行わず、ひざを突き合わせた分科会とメールによる情報交換でコミュニケーションを図ることにしました。活動はゲリラ的で小回りを常に意識しました。メールでのコミュニケーションは、相手の集中している作業を妨げることなく確認を取り付けるものとして有効なものでした。また、メンバーはできるだけ席を目の届く範囲に集めて、近い距離で活動するように考えました。これは致命的な問題点、緊急調整事項をすぐに声を掛けて検討、解決するのに役立ちました。効果を発揮した策の１つです。

　WebLogicは想定した性能を発揮し、基幹システムのオンライン処理を直接利用できたことから1．5カ月という短期間に、わずか4.5人のメンバーでインターネットシステムを稼働させることができました。開発期間中には数々の問題が発生しましたが、特に「異機種マシン・異なるブラウザでの動作チューニング」「基幹システムとの接続技術スキル」「ＥＪＢ構築」「仕様変更対応」には苦労いたしました。

　当時、スキルのないわれわれにとって信じられないことでしたが（現在は常識の話ですが）、Internet Explorerで動作してもNetscape Navigatorで動作せず、同じブラウザがWindowsで動作してもMacintoshでは動作しませんでした。また、ブラウザのバージョンが異なるだけで動作の不備が発生し、すべての共通したコードを見つけ出して稼働確認をするのに非常に手間取りました。あとの3つの問題はスキル不足から発生したもので、当初マニュアルと電話を片手に悪戦苦闘しました。記述されていることの意味を正しく理解できず、相手が何をいっているかを理解するのに時間がかかりました。

　これらを解決して、2000年の新年に、まだあまり存在していなかったリアルタイム処理型インターネットサイトを生むことができたのです。もちろん、まだまだ不備もありましたが、何も告知をしていないのにお客さまにどんどん利用していただきました。インターネットチャネルの現実の驚異とビジネスに大きな期待ができる分、すぐに次の手を打つ必要があると感じました。今回の成功の要因は、ITおよび手法によるものより、メンバーの力によるものが大きかったと思っています。　

2/4

3.開発生産性向上への取り組み

INDEX
「ニッセンオンライン」ECサイト構築の軌跡（前編）
	1.経験ゼロからのスタート
	2.ファーストリリースへの歩み
	3.開発生産性向上への取り組み
	4.さらなる革新に向けて

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