|
||||||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||||||
| 仕様変更 | ||||||||||||||||||||||
|
「どうして現場に血が流れるんだ」私は天井を見上げてつぶやいた。この2週間は毎日デフォルトで終電帰りとなりました。徹夜も2、3日ありました。 2週間前のことです。本システムの核となる発注機能・見積機能の実装を何とか終えて、顧客担当者への説明会を行いました。遅れていたスケジュールをリカバリして、システムを形にすることができた私たちは、若干の自信を持って説明会に臨みました。 しかし、私たちを待っていたのは予想していなかった担当者からのダメだしの言葉でした。この仕様では業務が回らない、とのことです。発注を受け付けた後の基幹システムへの連動と、営業担当者らへの連絡の機能が要件を満たしていないといわれたのです。 |
||||||||||||||||||||||
| 仕様書のみの落とし穴 | ||||||||||||||||||||||
|
筆者らの開発チームは、要件定義工程を担当したベンダーから引き継いだ仕様書をもとに実装を行ってきました。当然、その仕様書は顧客からの承認を得た、と聞いていました。そのため、仕様書そのままに実装を行ってきたのです。 仕様書をそのまま鵜呑みにして、仕様が含む問題点に気づくことができなかったのは、筆者らの力不足であったと思います。しかしプロジェクトは、前工程の成果物をもとに以降の工程を実施していくものです。本プロジェクトはウォーターフォール型の開発プロセスを採用していたため、なおさらそうせざるをえませんでした。 要件定義と実装とでベンダーが異なっており、実装段階で要件定義を担当したベンダーはプロジェクトから抜けていました。そのため実装チームにとっては仕様書が全てであり、仕様の背景までは把握することが難しい状況でした。 この事件に対して、本プロジェクトでは仕様変更に対応する、という方針を採ることになりました。そして対応するのは当然私たちです。こうして終電帰りの2週間がはじまったのでした。 |
||||||||||||||||||||||
| POIとの出会い | ||||||||||||||||||||||
|
仕様変更に対応しつつ、本来スケジュールされていた他の機能の開発を行い、BtoBユーザが使用する機能をほぼ完成させました。重い機能の開発を終えた筆者らは、商社の担当者向けの機能の開発に入ることができ、少しだけほっとしました。 担当者向けの機能として売上の分析レポートがありました。システムはWebベースのものでしたが、レポートは出力後にPC上での加工を行うことができるように、Webブラウザ上に出力するのではなくExcelで出力したいとの要件がありました。この要件を満たすため、本プロジェクトの設計フェーズでオープンソースであるPOIというライブラリを使用することが決められていました。 |
||||||||||||||||||||||
|
「POIとは」 POIとはApacheやTomcatで有名なJakartaプロジェクトで開発が進められているオープンソースソフトウェアです。Microsoft OLE2複合ドキュメントをJavaプログラムから扱うためのAPIを提供しています。POIを使用することで、例えばJavaからExcelの値の参照・Excelへの値の出力が可能になります。
Jakarta POI:http://jakarta.apache.org/poi/ |
||||||||||||||||||||||
|
私はこの時はじめてPOIを使用したのですが、セルへの値のセット、セルの装飾などが容易に行えることに驚きました。JavaでExcelファイルを生成できることと、そのようなライブラリがオープンソースで提供されていることにちょっとした感動さえ覚えました。他の開発メンバー達と「こんなこともできるんですねぇ」と感心し、楽しささえ感じながらコーディングを進めていきました。 |
||||||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||

