言語と人と運用と〜プロジェクトに立ちはだかる壁
文：株式会社ビーブレイクシステムズ

L i n u x を 始め と し て 、 A p a c h e 、

鹿取裕樹

行っていなかった。

・承認フローをシステム化する

Tomcat、PostgreSQL、Perlなど、多本システムについても運用を筆者のくのオープンソースソフトウェアが業所属する会社が請け負うことになった。

データの流れと機能との関連は図2

務システムにも浸透している。読者のそのため必要な機能が適切に実現されのようになる。具体的な業務の流れを、皆さんの中にも、「お仕事」としてオれば、使用する技術には特別な要件は実績データと計画データに分けて少しープンソースソフトウェアに取り組んなかった。予算、筆者の会社がノウハ

詳しく説明しよう。

だ経験のある方がいるだろう。

ウを有していたこと、安定稼動が可能

今回も筆者が経験したプロジェクトなことなどを考慮し、オープンソースの中で、オープンソースを活用した業ソフトウェアの利用を提案し、採用さ務システム構築の実例を紹介する。

れることになった。

実績データの流れは、以下のようになる。

・従業員は毎日の作業内容／作業時■

間／顧客を時間入力機能を用いて登ースならではの問題、オープンソース■システム概要
システム概要録する。また、顧客名／請求方法／とは関係ない問題ともに発生した。本

■請求時期などが登録された顧客マス

このプロジェクトでは、オープンソタを別途登録しておく

稿では、これらの問題の内容と対応策

簡単に今回のシステム「経営管理シを紹介する。読者の皆さんの参考になステム」の概要を説明しておこう。ま・入力された時間データを、関連するれば幸いである。

ず、システムの構成図は図1のように顧客ごとに集計し、顧客マスタに登■なる。

録されたタイミングで請求書を生成■オープンソース採用の経緯
オープンソース採用の経緯

そして、システム導入の目的は以下のようなものだ。

■

・時間入力やマスタ登録には承認のワークフロー機能がある

今回紹介するシステム（以下、本システム）の顧客は、従業員200 名未満・従業員がサービスを提供した実時間のサービス業である。独立したシステと各種マスタを元に請求書を自動生ム部門を社内には持っておらず、IT関成・発行する連の業務は総務部門が兼務している。

し、出力する

これに対して計画データの流れは、以下のようになる。

・計画値と実績値とを元に各種分析レ

よって、技術についてのスキルは高くポートを出力する

・プロジェクトマネージャが担当者のないため、システムの運用は自社では・顧客情報を管理する

稼働時間などプロジェクトごとの計

100Linux magazine January 2005

画を入力する

要件定義→実装→結合テスト→ユーザー供する。

・計画には、変更をしない当初計画とテスト→データ移行→カットオーバー

今回の案件では、この POIライブラ

状況の変化に合わせて変更していくリを帳票作成機能で利用している。

現在計画の 2つのバージョンを持た結合テストまでを 3カ月で終え、残■プロジェクトの流れせる
・これらの情報により、次のような分りの 1カ月でユーザーテストとデータ移行を行うという計画であった。

開発期間は約4 カ月の予定で、以下析を行う。

しかし、（詳しくはこのあと紹介すの流れで行われた。

・各担当者の稼動計画
・プロジェクトの収益性分析

東京

・当初計画と現在計画の比較
・顧客ごとの収益性分析
経営管理システム

使用するソフトウェアは、図1のシス
テム構成図にあるとおりだ。お馴染みのものが並ぶ中で、「POI」というソフ
インターネットトウェアはご存じない方もいるかもし

PCサーバ
Linux
PostgreSQL
TomcatApache
POI

れないので、簡単に言及しておきたい。
大阪

POIとは、Apache Jakartaプロジェ
クトにおいて開発が進められているオープンソフトのライブラリで（http://
jakarta.apache.org/poi/）、Excel やWordといったマイクロソフトのドキュメントをJavaで扱うためのAPIを提図1 参考事例のシステム構成図

担当者

入力

入力
マネージャ

実績時間

発行
請求書

顧客情報

プロジェクト計画

レポート

図2 データの流れと機能概要

January 2005 Linux magazine101

Developmentるが）顧客の社内状況をよく把握できわかった。

示した。すると、さっそくメンバーかていなかったためにユーザーテストや「ネットで検索してみて」筆者はインら質問を受けた。「 印刷できるものがデータ移行が遅れ、開発終了からカッターネットで解決に必要な情報を検索ありません

トオーバーまで予想以上の時間がかかできるだろうと思い、メンバーに指示すか？」。それくらい、と思われるかることになった。

した。しかし返ってきた答えは、「見もしれないが、そのメンバーは英語が■つかりませんでした」であった。

まったく駄目だったのである。

言語の壁って英語で何と言うのでオープンソースソフトウェアのメリ筆者も加わり調べた結果、生成したットのひとつとして、公開されている

Excel のシートが選択されていない状

開発開始から2週間ほど経過し、POI情報の多さがある。インターネット上態の場合、そのファイルを開こうとすのライブラリを使用した Excelの帳票にコミュニティがあり、メーリングリると問題のエラーが発生するという情出力機能の開発を始めた頃、あるエラストを通して Q＆Aなどが行われてい報を見つけることができた。

ーに悩まされることになった。

るため、それらから多くの情報を得る

■言語の壁
■

それは、POIによって生成したExcel

インターネットが普及し、膨大な情報を簡単に手に入れられるようになっことができる。

ファイルを開くと表示される「印刷でだが、ネット上の豊富な情報を享受た。しかし、日本語の情報は全体のほきるものがありません」というエラーするには条件がある。それは「英語をんの一部にすぎないのである。英語のである。

読める」ことである。

能力があれば得られる情報量はぐんとこの取りつくしまもないエラーが起

メジャーなソフトウェアや、日本国増加する。以前の回にも書いたが、こきると、Excel は起動するもののファ内で開発されたソフトウェアであれば、れからはソフトウェア技術者も英語をイルが開かれない。生成されたファイ

多くの日本語のドキュメントがあるだ

身につけていくべきだと痛感したしだ

ルのサイズを見ると空ファイルというろう。しかし、今回使用した POIはそいである。

ことではなさそうだ。さらに、生成しれには該当せず、ネット上で得られる■

たExcelファイルのシートの数が1つで日本語の情報が限られていた。

進まないユーザー作業■進まないユーザー作業

あればエラーが発生せず、2 つ以上にそこで筆者は再度、日本語以外のドなった場合にエラーが発生することがキュメントも対象に検索することを指画面1 POI の日本語ページ
このページは POIプロジェ
クトのトップページを翻訳したもので、Jakartaプロジ
ェクトの一環として提供されている。ただし、POIの細かな技術的なドキュメン
トやニュースなどについては、日本語の情報は用意されていない。

■
POIにより完全ではないにしろ、APIを使って Javaから Excelファイルを生成できるというのは、開発工数を減らすのに大きく役立った。
プロジェクト開始から 3カ月ほどで開発／単体テスト／結合テストを終え、ユーザーテストの段階となった。カットオーバーまで残り 1カ月となった頃である。
システムの説明を行い、システムをユーザーに開放し、ユーザーテストをしてもらうように依頼した。テスト開始日は顧客の事務所にてテストのサポートを行ったが、それ以降は自社に待機し電話にてサポートすることにした。
「テストの進捗はいかがでしょうか？」。テスト開始から1週間がたった

102

Linux magazine January 2005

ていたため、画面プログラムと画面制

頃、ユーザーに電話をかけてみた。テ運用の視点が欠けた設計

御プログラムの変更にとどまった。

スト開始以降、ユーザーからの問い合■

わせがなく不安に思ったためである。

■運用の視点が欠けた設計「すみません。業務が忙しくてできま■ ようやくユーザーテストが進み出に実現することに注力してしまい、シせんでした。今日からやります」。うし、半分ほどの機能のテストが終わっステム運用への考慮が不足していた。

すうす予想していた答えであった。

た頃、顧客から打ち合わせをしたいとシステムは開発すれば必ず運用されてこのとき、「確かに月末で業務が忙の申し出を受けた。ある機能が使いづいくものであり、運用についてはいくしくてまだテストどころではないのだ

らく運用できそうにないため、変更しら考慮しても考慮しすぎということはろうな。まだスケジュールに余裕もあたいとのことだった。

ないであろう。

筆者らは、どうしても機能を納期内るし……」と思い、手を打つこともな

最初にこの話を聞いたとき、正直な

特にマスタメンテナンスや業務フロ

く「わかりました。では、よろしくおところ「要件定義のときに確認して、ーは、ある程度以上のシステムでは十願いします。わからないところがあれ承認したではないか！」と思ってしま分検討しなくてはならない。

ばご連絡ください」と答えてしまった。

った。

これが失敗であった

さらに 1 週間たって問い合わせてみたところ、全20機能のうちテスト済み

顧客は業務のことはよく知っていてしかし、システムは使ってもらうたも、システム構築についてほとんど知めに作るものである。プロとしてのらないことが多い。そのため、システ我々技術者は顧客が運用できるようにムにさまざまな機能を盛り込もうとす設計しなければならない。こちらにもる。それをそのまま受け入れていくと非があるのは認めざるを得ない。

どんどん複雑になり、最終的に入力できる項目や機能は多いが結局使われなは 2 機能のみという状態だった。しかただ、変更には当然コストがかかり、もそのうち 1 機能はテスト開始日に顧すべてに対応することはできない。そ客先で筆者らがサポートしながら行っのため、できるだけ少ないコストで使要件定義の際に顧客から求められるたものであった。つまり、それ以降、いやすさを大きく改善できるような変ままに作っていくのではなく、顧客の1 つの機能しかテストが行われていな更を考えなければならない。

業務の本質を考え、それをできるだけかったのである。
前述したとおり、この顧客は大企業

幸い、内部設計はオブジェクト指向による設計で変更に対応できる形にしい、ということになりかねない。

シンプルに実現するシステムを設計することが必要であろう。

ではなく、システム専門の担当者がいるわけではない。システム担当を兼任

Columnしている総務部の方は経理も行っており、月末になると月次処理で忙しくな語の読解で問題になるのは、単語の訳よりも翻訳サイトは使える？

文書の概略が掴めれば、原文と照らし合わせる。こういったケースでは、顧客の業務や忙しい時期はいつかなどを考慮してユーザー作業を依頼しなくてはならないであろう。

SEにも英語力が求められるのは、本文で触れられているとおり。特に、海外発のオープストなのだろうが、現実的に考えて、忙しい業務の隙間を縫って習得するのは難しい。そのため、開発側はどのような手順とスこで解決策として浮かんでくるのが、翻訳ソケジュールでテストを進めるかというフトやネット上の翻訳サービスだ。と実感した。

利用する価値はアリだろう（編集部）。

が限られてくる。英語をマスターするのがベめて行うということも少なくない。そトするといったこともしていくべきだて内容を理解できるはず。英語の苦手な人は、ンソースソフトウェアの場合は日本語の情報また、顧客はシステムのテストを初ガイドを示し、顧客先につめてサポー構文の理解だろう。翻訳ソフト／サービスで専門用語や独特の言い回しの多いコンピュータ技術の文章は、こうした機械翻訳の苦手分野とされている。ただ、技術文書の英POIの英語ページを翻訳すると……

January 2005 Linux magazine103