トラブル三題噺〜終電・増殖・コミュニケーション
文：株式会社ビーブレイクシステムズ

最近では Linuxが業務システムに浸鹿取裕樹

価したためであった。

動しており、外部に公開しているシス透しており、読者の皆さんの中にも、もちろん顧客も安さだけで単純に判テムであるため、信頼性も重視される。

「お仕事」としてLinuxを使ったシステ断するわけではなく、OS としての安

そこで Linuxのコストの低さ、信頼ム開発に携わっておられる方もいると定性や稼動するソフトウェアなどを総性の高さというメリットが評価され、思われる。Linux の適用範囲が基幹業合的に判断する。これらの点でもLinux採用に至ったわけだ。Linux の運用ス務へも広がり、既存システムと連携しのメリットは大きい。Linuxは低価格

キルへの顧客の不安は、開発会社に運たシステムを Linux 上に構築したり、のサーバで安定稼動し、PostgreSQL、用を委託することで解消された。

ERP（Enterprise Resource Planning）

Apache、Tomcatといった信頼性の高システムを Linux上で稼動させるといいオープンソースソフトウェアを稼動う例も数多く聞かれる。

させることができるからだ。

■システムの概要

簡単に本システムの概要を紹介してこの連載では、筆者が経験したLinux

これに対し、顧客が Linuxの導入にを用いた業務システム構築の実例を紹感じるデメリットは、運用するスキル

本システムは商社の BtoB システム介し、その中で発生したトラブルとそがないということである。Windowsにで、図1の中心に描かれているPCサー

れに対してどう対応したかを中心に紹慣れている顧客にとって、やはりLinuxバ上に構築されている。特徴としては、介していきたい。

はとっつきにくく、不安に感じるもの

以下の 3つが挙げられる。

■

である。

■Linux採用の理由
Linux採用の理由

おこう（図1も参照のこと）。

1 つめは多国語対応。買い手企業は

本シ ス テ ム は 、「IBM の eServer

日本、中国、アメリカの企業であるた

iSeriesサーバ上に4GL（第4世代言語）

め、本システムでは日本語、中国語、Linuxを使用することのメリット／で構築されている BtoB システムを

英語の 3 カ国語に対応しており、画面デメリットはさまざまな点が論じられLinux＋Javaで再構築する」というも表示からデータ登録までを 3カ国語でているが、顧客にとって一番わかりやのである。「旧システムでは 4GL の保行うことができる。

すいのが初期導入コストが低いことで守料が負担である」、「iSeriesサーバの2 つめは基幹システムとの連携であある。筆者が開発に携わったシステム

空きディスク容量が少なくなったが、る。基幹システムはIBMのiSeries上に（以下、本システムと呼ぶことにしよ追加に多額のコストがかかる」という構築されており、在庫管理、販売管理、う）が構築されることになった理由も、主にコスト面の不満が大きかった。加

会計の機能がある。本システムは、基この初期導入コストの低さを顧客が評えて、基幹の会計／在庫システムと連幹システムの商品マスタの参照、在庫■

98Linux magazine November 2004読者の皆さんは「このようなトラブった。問題外の遅さである。しかも、ルが起きないようにするのがプロなのこれらの検索ができないと開発を先に3つめは提携先企業への受注代行であだ」と思われるだろうが、そうはいか進められないため、早期に修正を行う

る。提携先企業は中国の商社で、ここないのもまた現実。今回は、上記のう必要があった。そこで、私の担当範囲が扱う商品データを本システムに取りち最初の 3つのトラブルについてお話ではあったが全プロジェクトメンバー込み、本システムに登録された受注デすることにしよう。

で対応にあたることとなった。

ータを提携先企業に送信している。な■お、両者の間はVPNで結ばれている。

■トラブルその1
トラブルその1

ログラマーが大声をあげる。夜中の12■SQL万歳！

時は回っていたであろう。メンバーはの引当、受注伝票の登録といった基幹システムとの連携処理を行う。

■プロジェクトの流れ「できました！」 私の隣の新人プ開発が進む中で 1つのトラブルが発ビクっと反応し、時計を見て「まだ終開発プロセスとしてはウォーターフ生した。それは iSeriesサーバ上の DB電がある」とホっとしたのも束の間、ォール型が採用された。プログラム言に問い合わせたSQLの結果が返ってく問題のものとは別のSQLを流している

語はJavaを用いていたが、マネジメンるのが非常に遅いというものである。

ことに気づき、「この SQL じゃないトを担当する会社に反復型開発のノウ一人で悶々と試行錯誤してみたが、どぞ！！」と眠い目をこすりながら対応

ハウがなかったため、従来どおりのプうにもうまくいかないのだ。

した。

ロセスがとられることになったのだ。

顧客からは検索結果が 3 秒以内で返翌日、DB の最適化を行うしかないウォーターフォール型の開発プロセスってくることを求められていた。しかと判断したプロジェクトリーダーは、

では、開発プロジェクトは図2のようし、そのSQLは数個のテーブルを結合

顧客企業の担当者に DB ベンダーにサな流れとなる。

するSELECT文だったが、なんと数分ポートを依頼しましょうと提案したが、かかっても結果が返ってこないのであ「予算がない」とあっさり断られてしプロジェクトにはさまざまなリスクがあり、何が起こるかわからないものである。本プロジェクトも例外ではな

中国提携先

中国

く、ざっと挙げるだけでも次のようなトラブルが発生した。
PCサーバ

日本

・iSeriesへの問い合わせSQLのパフォ

VPN

ーマンスが悪い

インターネット・Javaプロセスが増え続け、システムアメリカが停止する

Linux
ApacheTomcatPostgreSQL

・承認された仕様の変更

IBM iSeries

・iSeriesとの連携APIの致命的なバグ
プロジェクトの特性によるAPI変更
・在庫引当連携機能のバグによる在庫数のずれ
・提携先企業のシステム構築の遅れ

要件定義

基盤の構築

・中国のシステムとの連携
・オープンソースの活用
Linux、PostgreSQL、Tomcat、Apacheを使用する
中国の提携先企業と受注データを連携する・ホスト（IBM iSeries）との連携
・複数会社での共同開発
基幹システムはホスト上に構築されており、商品マスタや受注デー 4社8人の開発者が遠隔地から共同で開発するタなどを連携する

図1 「本システム」のシステム構成図

設計

実装

テスト

データ移行

カットオーバーウォーターフォール型の開発プロセスでは、上流工程から下流工程へと順次作業が進められ、基本的には前工程へフィードバックが行われることがない。そのため、開発途中の仕様変更などに柔軟に対応できないという短所がある。

図2 ウォーターフォール型開発プロセス

November 2004 Linux magazine99

Development

まった。連日の徹夜で反論する気力もうつむきかげんに微笑むのが精一杯だ

間連続稼動させるため、これは致命的なく、その夜も地道なSQLの解析が続った。

な問題である。

かなり原始的な方法をとることになトラブルが発生した際は、まずその食事は、常にメンバー全員で定食のったが、タイトな期間の中で数日を割現象を再現させ、次にその原因を分析出る居酒屋に行っていたのだが、そのいて検証し、なんとかどの検索処理でする、という手順で対応する。

ときの話題といえばプロジェクト進捗も 3 秒以内に検索結果を表示させるこ「再現すればすぐわかるでしょう」

状況とSQLと帰宅時間だけだったと記とができるようになったのだ。「SQLとプロジェクトリーダー。「そうです憶している。

万歳！」と心のなかで大きく叫んだ。

ね」と私は答えた。いつもどおりのトいた。

結局、SQLの書き方をいろいろと変今考えてみると、ラブル発生時のやり取りだ。しかし、トラブルを再現することはならず、さ更して試行錯誤したところ、結合の順序によって結果が返ってくる時間に違・DB ベンダーへのサポートを依頼すいがあるということがわかった。ドキることを顧客に対して強く交渉する

我々は 当初、 J a v a の プ ロ セ ス はュメントによると、DB システム側で・DBベンダーへのサポート依頼が許可

Tomcat のスレッドに対応しているもSQLを解析して結合の順序に関わらずされない場合は、ユーザーの利便性のであり、Javaのプロセスが増えるの処理してくれるはずなのだが、その機を考え、検索スピードを上げるためは Tomcat のスレッドが増え続けてい能がうまく働いていないようであった。に検索方法を変えるように交渉するるためだと考えた。そのため、Javaっそく調査に入った。

Servletや Tomcatの仕様を読み、スレ

そこでレスポンスが遅いSQLを洗い出し、それぞれについて一番早い結合などの対応が考えられる。対症療法のッドの数を制限することができないかの順序を見つけるという地道な作業をために時間を費やすのではなく、機能を調査した。さらにネットでの検索を繰り返した。多いものでは10個のテーの本質的な目的を見極めた対応をして行い、Tomcat のメーリングリストのブルを結合しており、その結合の順序いくべきであった。

ログや掲示板をあたった。

を順番に入れ替えて検証するのには、■かなりの時間がかかった。

■トラブルその2トラブルその2にスレッドの最大値が設定してあり、■増殖する Javaプロセス

掲示板やメーリングリストのログにもこの頃になると、皆、疲れているというより、「うすーく」一人笑いをして自分の世界に入っていた。

カットオーバーが近づいた頃、新たなトラブルが発生した。

しかし、使用している環境ではすでここで設定されている最大値以上にスレッドが増えるという問題は報告されしかしながら、さらに悪いことに、

それは Linux上で Javaのプロセスがていなかった。「ついてないなぁ」と検索画面には複数の条件を指定できる増え続けるというものである。統合テしか言えない状況だ。偶発的な出来事ようになっていて、それらの条件間をストに入りシステムを連続稼動させ、として片づけたいが、そうもいかない「and」でつなぐか「or」でつなぐかを多数のトランザクションを実行するよのだ。システムが落ちてしまうのだかユーザーが選択できるようになっていうになってこのトラブルが明らかになら。動かないコンピュータにしたくなた。このため、ある条件が指定されてった。

いと強く願った。

いてある条件が指定されていない場合

具体的には、システムを連続稼動さそこで、ほかに原因があると考え、や、各条件間を「and」でつなぐ場合せている状態で Linuxの psコマンドをシステムの機能を1つ1つ実行しながらと「or」でつなぐ場合など、非常に多実行するとJavaのプロセスが大量に表psコマンドの結果を監視し、Javaプロ

くのパターンを検証しなくてはならな示されていたのである。さらに、このセスが残る機能を洗い出しにかかった。

くなった。

J a v a プ ロ セ ス が 一定数に 達す る とその結果、ホストへの接続がクロー「できたぞー」とプロジェクトリー

Tomcat でエラーが発生し、システムズされていないという原因を探り当てダーが、皆の目を見ながら軽く叫ぶ。

が停止するということも判明した。

ることができた。

だれも声を出すことはできなかった。

100

Linux magazine November 2004

BtoBシステムは外部に公開され長期

このケースではネットの情報が直接にはトラブル解決につながらなかった

やりたいことを完全に描ききれて確認してもらい確定させていくというが、オープンソースのメリットである

いなかった

反復型開発プロセスを取り入れていくことも検討すべきであろう。

公開された情報の多さには非常に助け

3．顧客が言うがままに仕様を決めておられた。しかし、言語によってこのメり、開発者側から有効な提案がで■リットを享受できるかどうかに大きなきていなかった■一番苦労するのは人間
一番苦労するのは人間■差がある。日本語と英語とでは情報量に非常に大きな差があるのである。オ

このプロジェクトはキックオフが十技術的なトラブルも、もちろん厄介ープンソースソフトウェアを利用する分に行われずに開始されてしまった。

なものだが、相手がコンピュータであ場合、その活用は英語の読み書きがでそのため、構築のプロセスが顧客に十るだけに理屈どおりに対処すれば解決きるか否かが大きく影響することを実分に理解されておらず、仕様確定の重は可能である。人間相手にはそうはい感した。

要性や確定された仕様を変更することかない。

■のリスクが認知されていなかった。

■トラブルその3
トラブルその3

プロジェクトにはお客様やプロジェプロジェクトの早い段階である仕様

クトメンバーといった直接的に関係す確定時点では、顧客はシステムが実際る人のほかに、お客様のお客様、お客要件定義は今も昔もユーザー、開発にどうなるかをイメージできていない。

様の上司、自社の上司、営業担当者な者の双方を悩ます問題である。本シス

したがって、あとで変えることができどの間接的に関係する人がいる。それテムでも要求定義が上手くいったとはるという認識がある。また、そもそもぞれの思惑が異なり、何かを伝えるといえず、一度は顧客から承認を得て判仕様確定の段階ですべてを決めるといきにも、自分では思っていなかったよを押してもらった仕様だが、案の定、うのは不可能なのである。

うに受け取られることがある。

■仕様変更との闘い

このプロジェクトではこの問題に対

このようなコミュニケーション上の「こっちがお金払っているのだから、応し、システムが実際にどうなるかと齟齬が要件定義におけるユーザーと開やって下さいよ」、しかも対応するのいうイメージをはっきりさせるために、発者との間、要件定義担当者と実装担は当たり前で「これが直らないと金を仕様をHTMLで表して実際の画面の動当者との間、プロジェクトマネージャ払わない」とまで言われたのである。

きに合わせて説明した。しかし、そのーと開発者との間、ユーザーとその上よくあることだ。

仕様はほとんど顧客の要望のままに作司との間で少しずつ積み重なって最終すでに承認され確定した仕様なのだられたもので、ユーザビリティや運用的には大きな乖離となることがある。

から、理屈の上では変更を受け入れるまでを網羅した全体的な観点での検討

コミュニケーションを助けるために、必要はないのだが、現実的にはそうもが十分になされていなかった。

変更要求が出た。

UML などさまざまななツールがあるいかない。しかたなく、変更要求に優顧客は、開発者がシステム構築のノが、その使い方も含めて、やはり最終先度をつけ、スケジュール／工数を考

ウハウを生かし、顧客自身が考えられ的にはコミュニケーションを行う人間

慮し、できる限りの対応をするというる仕様以上のものを作りあげるはずだ、しだいということになる。

ことになった。というプロとしての付加価値を期待しソフトウェア開発は、製造業と比較ている。これに応えていくために、こして前近代的と言われている。もちろ

うした全体的な観点での検討と提案をん製造業と条件が異なる点は多いが、していかなくてはならないと感じてい見習うべき点も多いと感じる。

今回のケースをあとで分析してみると、以下の原因が考えられる。

1．顧客に対してシステム構築のプロる。また、仕様の変更は必ず起きると筆者は、開発に携わる人々は工学的セスを十分説明できておらず、仕いう前提に立ち、大きな仕様変更が起なアプローチをとるなどして、効率的様を変更することのリスクが理解きないような工夫をする必要がある。

な開発を行え、ユーザー／開発者の双

具体的には全体に関わる部分、リス方が幸せになれる状況となるよう努力

されていなかった
2．顧客は仕様確定の段階では自分達がクの大きな部分を先に開発し、顧客にしていくべきだと考えている。

November 2004 Linux magazine

101