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

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

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

　いったんサイトが立ち上がった後、すぐに開発インフラの整備に取り組みました。まだ生まれたばかりのインターネットサイトを成長させることに力を注ぐことが、今後の会社の成功を決めるものと判断したからです。インターネットサイト成功はコンテンツ公開のスピードが重要であると考えていたため、われわれとしてはシステム開発がサイト運用の足かせにならないように、まず開発の生産性の向上に着手しました。

　開発生産性の向上を図るために、初期開発プロセスの分析を行い問題点を把握し、初期開発で学んだことを合わせて改善策の１つ１つに取り組みました。これからの活動は依頼された企画を開発するのではなく、インターネットサイトを日本一にすることに目標を置きました。サイトを日本一にするためにわれわれが最も重要視する活動は開発を迅速化するために何か手を打つことであり、プログラム開発だけに集中しないことをメンバー全員で確認しました。結果として開発リリースは速度を増し、開発内容はコンテンツ部隊とち密な連絡を取り合う活動にすることができました。

　インターネット開発基盤作りはインターネットだけの開発ではなく、会社全体の開発効率の向上を図ることを目的として活動しました。会社全体の活動が迅速でなくては、今後の企業の発展につながらないものと思っております。われわれが構築した基盤はあくまでプロトタイプとして試行錯誤した結果の成功モデルとして広めることを考えています。また、開発部隊だけにとらわれずにすべての部門での利用を考えながら作成しております。なにはともあれ、2000年の、われわれの課の目標設定とメンバーの活動が始まりました。

■開発基盤の構築

　初期開発のプロセス別分析の第1段階を実施しました。ここでは、プログラム作成方法の改善と開発支援ツール検討の経緯と、決定内容をご紹介します。われわれは、ツールの役割を開発者が開発に集中するためのものと定義しております。余分な作業の発生を起こすことなく作業の軽減・安定を図ることを前提に取り組んできました。特に複数のツールを利用する場合に、複雑な運用に陥ることがよくあります。できるだけ煩わしくなくシンプルな形に整えるように考えました。

　現在の環境は、すべてのツールを１つのイントラネットのWeb画面上に取り込み、画面を切り替えることなく開発者へのサービスを行っております。この環境は実験的要素も大きいことから、できるだけ現状利用しているＩＴ技術をそのまま応用して利用することで費用をかけずに作成しようと考えてきました。

開発者は「開発用イントラネット」を利用し、ソースコードやドキュメントの管理（作成、更新）、連絡事項の伝達を行う

開発のプロセス分析を行った結果、プログラミングと連結テストに工数がかかっていることがわかった

　分析の結果、「プログラミング」と「連結テスト」に工数がより多くかかっていることが分かりました。「プログラミング」ではコーディングと予備調査、「連結テスト」では戻り修正の発生が、必要工数を占めておりました。われわれは有効な幾つかの課題をかかげ実践していきました。最も効果的だった対応は以下の3つでした。

1	部品化の推進とドキュメント生成
2	情報の共有化とバージョン管理
3	開発手法（プロセス）の確立

（1）部品化の推進とドキュメント生成
　処理を部品化して使うことが生産性の向上につながることは、過去のシステム開発からいわれていたことでした。初期の開発では部品化ができておらず再利用率が極端に低いことが問題でした。特に、ドキュメントをまったくなくしたことが影響しており、部品を再利用する際に「どのような機能があるか」「どのように使うのか」を把握できていませんでした。Ｊavaは部品化をするのに適した言語ですが、オブジェクト指向による特性を生かすことに取り組みました。

　ドキュメントを作成した場合に、やはり開発が遅くなることも事実です。特にスパイラル方式で開発を行おうとしたときには、ドキュメントの破棄・修正という多くの無駄な時間が発生してしまいます。そこで、完成したプログラムに対して後からツールでドキュメントを生成させることにより、開発生産性を損なわず保守も効率的に実現することに着手しました。開発者はプログラムにコメントを入れることは苦にならないことに目を付け、規定したコメントをプログラムに埋め込むようにしました。ツールはこのコメントを読み取り、表示を行います。完璧ではありませんが、効果は大きいものと考えられます。

　部品化で重要なことは、部品作成と考えられがちですが、実は再利用を促進させることに大きな意味があります。開発活動プロセスの１つとして開発メンバーが欲しい部品をすぐに入手できるように、イントラWeb画面上から直接利用できる配慮をしました。

A．ドキュメント作成ツールの利用
　2000年１月より、開発効率の向上を図るため、ツールで自動生成する方法を構築しました。幾つかフリーウェアを検討した結果、Javaに標準で付属するJavaDocツールがわれわれの求めているもの（プログラムのコメントをドキュメント化して表示する）に近いと判定し採用しました。また、オブジェクト手法のUML（Unified Modeling Language）を採用したことから、このUML生成フリーツールも使い表現しました。

　ＵＭＬはオブジェクト思考を表現するための１つの手法です。当時、プロジェクトで複雑な処理要求に一貫性を維持した部品を作成していくために、オブジェクト思考と最も標準的なオブジェクト手法を採用したわけです。ここで行った革新は、コストをかけずに、大きな効果が得られたと思います。

ソースコードのドキュメント化にはJavaDocを活用

B．EJBの活用
　当初はプログラムの作成・役割配置などを開発者に任せた結果、開発者の個性でプログラムの形態が異なりました。追加要求および機能不備の保守作業が遅く、漏れが発生しやすくなったことから作成プログラム種類の役割を規定しました。JSP、Servlet、EJB、Jarでおのおのどのような役割を行う処理にするか……特に、EJBと通常のJavaBeansの使い分けで混乱をきたしましたが、EJBは以下の3点が実現できることから、効果があると判断しております。

・	分散コンポーネントにより、実際にサービスを行うJava処理と別なマシンに配置をすることができる
・	EJBは複数のJava処理で共有できることから、リソースの最少化が図れる
・	ビジネスロジックとAPIを分離し、DBの変更、ファイルアクセスの修正への対応が処理に影響を与えることがないため、作業を最小限にできる

　費用の最適化から考えて、リソースを最少化できるメリット……例えばオンラインであれば10本のプログラムで100人を処理したりしますが、同じことをEJBはするわけですからメモリなどのリソースが最小限でよいことになります。また、EJBはリソースを最小限のプログラムでサービスしますし、CPU負荷を別プラットフォームに逃がして動かすことも可能です。このことは、われわれがシステム構築で念頭に置いた、最適なコストパフォーマンスでの運用にマッチしたものなのです（……が大きいと考えております）。

　また、EJBの役割として、データベースアクセスなどのユーザーインターフェイスが必要な処理をパッケージすることに用いることにしています。例えば、データ蓄積をサイトの成長に合わせて、SQL ServerからOracleに変わるケースがあると思いますが、多くのプログラムに影響を与えてしまいます。これをEJBでパッケージにすることで、環境が変化してもEJB内部を変更することで処理プログラムへの影響を極力与えずにサイトの成長に柔軟に対応できると考えています。

（2）情報の共有化とバージョン管理
　2000年3月、これまでのプロジェクト単体の開発効率向上から、複数のプロジェクトを同時に推進するための複雑な作業に対する効率向上に目を移しました。

インターネットのプログラムが増えるに従い、プログラムが個人に依存しないことが望まれてきます。これは、情報の共有を行う必要があると認識するきっかけになりました。共有すべき情報は数多くあり、開発の生産性に大きな影響を与えていることも分かりました。

　プログラム開発をするにあたり、第1に諸規定の確認を簡単にできることが必要でした。第2に、技術調査作業の重複が発生しやすくなることから、現在の調査情報・過去の調査情報の共有が必要になりました。第3に、人材の人事異動に備えて、個人の知識の部署への保存も必要でした。メンバーの異動は優秀なメンバーであればあるほどその可能性は大きなものになり、かつ個人が所有している情報も重要で大量になります。存在が消えたときに生産性が落ちる可能性は大きく、これを回避する必要がありました。第4に、実際の開発作業は複数のプロジェクトが並走することから、ほかのプロジェクトの開発プログラムまで理解しておく必要がでてきました。だれが、どのプログラムを使用するのかの情報を共有しないとトラブルを起こす原因となります。

　情報共有化も情報の蓄積が重要ではなく、情報の利用が重要なポイントになります。情報の活用が活動の一部となるように配慮をしました。

A．知識データベースの構築
　このデータベースの構築は情報共有（2000年3月より）を行うとともに、人が所有している知識を格納することで作業効率を向上させることを目指しております。ツールはマイクロソフトのSite ServerとSQL Serverを利用して、情報の検索と蓄積を行う独自の仕組みを作成しました。知識データベースは、利用されることを重要視した情報を確認しやすいものにしています。特に、この仕組みは、蓄積されていない情報も含めた、どのような問い合わせでも解決できるようにしました。確認した情報がない場合は、この仕組み自身が調査します。調査情報はさらにデータベースに格納され、利用されるほど情報が蓄積され成熟していきます。ツールの利用はできるだけ利用者の苦痛にならないように考え、ほかのツールと同様のイントラWeb画面上で確認できるようにしております。

知識データベースの画面。知識データベースを設置することで、個人に蓄積しがちなスキル情報の共有化を図っている

B．プログラムバージョン管理ツールの活用
　企画の迅速な提供を行う場合に、複数のプロジェクトが並走することになります。この開発作業は複雑で、問題が発生しやすいものです。同じプログラムに対する修正の発生、リリースタイミング、開発期間のズレによる開発プログラムバージョンのコントロールを開発者に求めた場合に、開発に集中した時間以外の時間を取られることになります。プロジェクトの規模が大きくなればなるほど、この時間も大きくなり生産性は低下してしまいます。

　そこで、プログラムのバージョン管理を機械が管理することにより作業効率向上と問題発生率低下を図ることが必須と考えました。ツールは先に基幹システムで利用していたメラントのＰＶＣＳをそのまま利用しました。PVCSを導入した理由は「シェアがNo.1であったこと」、「プラットフォームの依存が小さかったこと」、「扱えるプログラム種類が多かったこと」の3点でした。ＰＶＣＳの機能として、プログラムの利用者の管理と、バージョンの管理、過去のプログラムの管理ができ、この機能とイントラWeb画面を融合させて構築しました。

　実際にPVCSでは、「プログラム管理」と「設計ドキュメント管理」をしております。スパイラル手法を用いた場合に発生する修正内容を、時系列に・最新内容を確実に管理していくために、2000年5月よりＰVCSを中心に開発活動を進めております。

ソースコードはPVCS Version Managerを使って管理している。イントラネットの画面上でチェックアウト作業を行う

（3）開発手法（プロセス）の確立
　開発生産性の向上は、開発メンバーが開発作業に集中することを邪魔しないことだと考えます。初期開発の経験から、スパイラル方式では開発作業でプログラム作成途上での後戻りが発生し、集中力が途切れ大きな失速になることを認識しました。しかし、製品の完成度を高めるにはスパイラル方式をどうしても採用したいと考えていました。

　結局、いままでの概念にとらわれない新しい方式を検討することにし、プロセスをバラバラに崩しBPRとActivityBasedCost（ABC）分析を用いて一番効率的な方法の模索をしてみました。ＢＰＲはご存じのとおり、Business Process Reengineeringのことで活動（作業）プロセスを分類して、業務の流れや業務の内容を最も合理的にするものです。また、ＡＢＣ分析は時間軸をもとに投資コストと収入を最適化するための分析を行うもので、この両者を組み合わせて、最も成功への貢献度を高めるプロセスを検討した結果、いまの手法を導き出しました。

　あくまで、BPRのモデルとするべく取り組みましたが、内容は設計と開発をそれぞれ切り離して独立させて推進することにしました。できるだけ１つの企画を細かく分けて、複数段階でリリースさせていきます。最も効果を生みつつ、開発速度を向上させます。各段階の開発を短くリリースすることのメリットは、修正をできるだけ少なくすること、開発が並行に進行できること、早く効果が得られること、必要に応じて進路修正ができることです。進化を求める場合は、いままでの概念の外に答えがあるものです。

　具体的には、設計サイドでは、要求定義、設計、プレゼンテーションというプロセスを繰り返します。ただし最初の設計段階で変更が発生しないバックエンドの仕様を追求しドキュメント化、これをPVCS Version Managerでチェックして開発サイドに渡します。開発サイドはこのドキュメントをもとに複数のメンバーが、JavaDocによりソースコードの概要とパラメータのドキュメントを確認し、再利用するソースコードや共通部品をチェックアウトします。このように設計サイドと複数の開発サイドの作業が並行して動くわけです。そして、設計サイドではプロトタイピングの繰り返しによって画面の仕様を数回にわたってチェックしますが、開発サイドでは最終的な修正は画面だけで済むように開発を進めます。開発が終わると開発サイドでソースコードをチェックして本番展開へと進めます（編集注：詳細は後編で解説します）。

3/4

4.さらなる革新に向けて

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

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