ユーザー事例

Corporate Profile

ユーザー事例

株式会社イニタウトジャパンは、大日本スクリーン製造株式会社と関連企業を顧客とし、ネットワーク構築、システム支援、その他IT関連サービスを行うSIerである。

イニタウトジャパンは、2003年前半から大日本スクリーン製造に対し同社のNotes/DominoR4.57を Notes/Domino6.5にアップグレードするプロジェクトの提案を開始した。イニタウトジャパンはその時点で既にTeamstudioバンドル（当時7製品セット）を所持していたので、当初から問題設計の確認等を行っていた。

設計標準化までを見据えた移行プロジェクトでTeamstudioを有効に活用

2004年2月に、大手SIerである株式会社大塚商会と共に、大日本スクリーン製造Notes/Domino6.5移行プレ・プロジェクトを開始した。これを期に、Teamstudio Analyzer、Delta、Configurator、及びLibrarianを5ライセンスずつ追加導入した。そしてそこで提出した6.5移行案が採用され、2004年6月より本プロジェクトが開始されることになった。

重要なことは、それが単なる移行プロジェクトではなく、同時に設計の標準化を視野に入れたプロジェクトである、ということである。

Teamstudio for Notesにより、大日本スクリーン製造のND6.5移行プロジェクトがどのように実現されたか、Teamstudioはそれに如何に貢献したか、そしてそれだけではないTeamstudio導入の目的を、本プロジェクト開始直前にイニタウトジャパン前川氏・小山氏に伺った。

当初から存在していた問題点

まず最初に、Teamstudioバンドルを2003年3月に購入した理由は？
「移行プロジェクトをこれから策定するにあたり、Teamstudioを評価したかった事です。そして修正箇所の洗い出し、設計の比較、工数積算や設計の標準化など移行のあらゆる局面でどのような効果が得られるかを知りたかった、と言う点もあります。」

そもそもそれまでの大日本スクリーン製造に於けるNotes/Dominoシステムの問題は何だったのか。
「まず大きくは、設計の標準化が出来ていなかったことが上げられます。同じような悩みをかかえる方は多いのではないかと思いますが、仕様書を十分に残さず場当たり的な修正を繰り返し、アプリケーション品質の低下、それに伴うサポート工数の増大などが起こっていました。」

具体的には？

「例えば、

• かな漢字等の2バイト文字をフィールド名に使用したフォーム。これは、Web化を行った際問題が生じる。
• モジュール化を行わず、LotusScriptがフォームやビューのアクションボタンに直接書き込まれているケースも多かった。コピーして開発する段階では楽に思えても、修正が必要な際、多くの時間を要し効率的でない。
• 他ＤＢとの連携が必要な場合、マスタを作らずにプログラム中に直接サーバやファイル名称を書き込んだために、サーバの移動が必要になっただけでプログラム改修が必要という設計も多い。

など、メンテナンスをしていく上での悩みは多かったのです。」

Analyzer監査フィルタで不可能だと思われた作業が可能になった

具体的に、Teamstudio製品を移行上の問題解決のためにどのように使ったのか？ 「まずAnalyzerです。上述のような設計内容の分析、絞り込み、問題点摘出等は人間が行うと莫大な工数がかかり、Analyzerでなければ無理でしょう。 その際、もちろんIBMのCodeCheckerを利用しての設計非互換部分の特定も行いました。」

順調に進んだのか？ 「費用・移行スケジュール作成が主目的のプレ・プロジェクトの終盤になって、CodeCheckerで検出できないある問題設計の件数が移行費用の算出に大きな影響をおよぼすことが分かりました。該当設計箇所の調査が急遽必要になり、しかも数日で800個以上のDBに対してそれを行う必要があったのです。」

それは手作業ではもちろん、Analyzerの分析結果DBだけでも、時間的には不可能ではないか。 「そこで大塚商会に、Analyzerの監査フィルタを利用したチェックフィルタ、及びそれを自動的に監査するバッチファイルを作成してもらいました。それでこの作業が可能になりました。」

この監査フィルタとバッチファイルにより、当初数百日の工数が必要かもしれないと考えられていた問題点が、実際は30日程度で対応可能と判明した。これが移行案選択の大きなキーとなった。

結果的な効果としては？
「工数算出のための時間削減は相当なものです。そもそもAnalyzerがなければ、具体的に問題設計を検出して、根拠のある移行工数を算出する事自体あきらめていた可能性があります。また、どの程度の修正作業が発生するかを具体的なデータで確認できたことにより、実現性の高いスケジュールや人員の計画をたてることができた事も大きな効果だと言えるでしょう。」

バッチ処理により出力されたAnalyzer監査結果

設計標準化実現のためにLibrarianの活用

Librarianに関してはどうか。
「移行時の推奨設計や、特定の設計と入れ替えたいものをLibrarianに登録して利用したいと考えています。」

標準化について、どのような問題があるのか？
「経験の浅い開発者は、当初他の開発者が作成したDBをコピーして真似ながら、設計をはじめることが多いです。当然、設計の良し悪しを判定する力も不足しているので、品質の低い設計をコピーしてしまったり、どれが必要かわからないので不要な設計までコピーするという事態が起きてしまいます。このような状況の改善にもLibrarianが有効だと考えています。」

現在、標準化に向けてどのような作業を行っているか？
「ＤＢ移行の第一段階として、まずは標準とする設計を決定するための打ち合わせを何度か開催し、開発メンバー全員で討議してもらっています。普段は先輩後輩の遠慮もあり設計の良し悪しについてストレートに意見交換しにくかったりもするらしいのですが、今回は目的が後々も財産になる標準設計を作り出すということであったため、かなり激論が戦わされているということです。打ち合わせの予定時間を超過することもあり、この作業自体が開発者メンバー全員の技術の底上げに非常に役立っていると聞いています。」

今後はどのような計画か？
「移行中、移行後もこのような場を継続して定期的にもち、メンバーが有効だと判断した標準設計を随時Librarianに追加していきたいと考えています。そして、それを活用することで新規で開発メンバーの増員を行った際も、品質のばらつきのない開発が行えるような環境を整えていきたいです。」

単なる移行プロジェクトではない。それが移行プロジェクトを進める事になった理由だ

今回の移行プロジェクトは、Notes/Domino6.5への移行のみを目標としているわけではない？ 「移行の対象となるＤＢ数が多く、設計の標準化や仕様書の整備が不十分、長く4.x世代のバージョンを使用していて長くバージョンアップとは無縁だったという条件がそろえば、たいていは移行を考えた時、費用の試算の結果に驚くことになります。 サポートが切れているので移行することは避けられない。それだけの動機で大きな費用がかかるということは利用部門の理解も得にくく、実際にもったいないことでしょう。 移行という作業の中で、全ての設計を分析し、問題設計を修正するという作業が必須であれば、その対象を移行上の問題箇所だけにとどめず、設計の標準化という観点からみて問題の大きいもの、保守性の低いものまで広げてはどうかと考えました。 AnalyzerやLibrarian、Configuratorを活用することで、対象を広げることによる作業工数をかなり削減できます。それとは逆に、この事により得られるものは大きいのです。」

移行作業の完了と同時に、設計の分析や標準化が終わり、実際に各開発者がLibraianを利用し、標準化に即した設計を用いてアプリケーションを開発するという体制が確立できれば、この時点で当初の問題点であった品質管理の問題も同時に解決することになるだろう。これがイニタウトジャパンの今回の移行プロジェクトの大きな目標の一つである。

「具体的な作業予定としては、まず現状250個程度存在する掲示板やディスカッションのテンプレートを少数の設計に絞り込むことから始めます。これは保守が容易になるだけではなく、利用者にとっても移行費用を小さく抑えることが出来るという大きなメリットが生まれます。
移行というのは利用者にとっても負担の大きい作業でありますが、なるべくトラブルなく進め、同時にきちんとした開発基準を定め、低コストで品質の良いアプリケーションを提供していくことで、メリットも感じてもらいたいと考えています。」
その他、将来の計画としては？
「将来的にアプリケーションのWEB化というニーズもありますが、現状では移行と同時に進めると不具合の切り分けが困難です。そのためにまずノーツネイティブで6.5クライアントへの移行を基本として考えています。
このような作業のいろいろな場面でTeamstudioには、大きな役割を期待しています。」

Deltaで設計差分特定、工数削減

その他のツールの活用は？
「Deltaもよく利用しました。同じ設計ではないかと推測しているＤＢが複数あっても、設計のボリュームが大きいと調査工数がかかり過ぎて、それを確認することが通常は難しいでしょう。 結果的にそれぞれ別の設計として扱うと、移行工数が増大するということになりますが、このような問題もDeltaで解決出来ました。差分の特定が大きな設計でも数分以内で可能なため、まったく同じ設計と確認出来たものは、移行時は一つのテンプレートを開発準備するだけで良く、無駄な工数をかなり削減出来ました。」

Configuratorはどうか。
「まだこの時点では実際に活用してはいませんが、これからの設計内容変更の実作業で利用する予定です。」

Teamstudioで目覚ましい工数削減が可能になった

対費用効果という点に於いてはどうか。
「特定のフィールドの名称を変更するためには、それが及ぼす影響を把握せねばならない、古い設計と新しい設計でどこが違うかを知らねばならない、と言った、"人間が行うと膨大な時間がかかる作業"を非常に短時間かつ正確に行えることで、目覚ましい工数削減が可能になります。」

工数削減以上の効果としては？
「やはりLibrarianです。Librarianによって、経験が浅い技術者でも確実なモジュールを安心して再利用することが可能になります。もちろん設計の標準化を実現する為のツールとしても有効です。」

Teamstudioの総合的な評価としてはどうか。
「設計調査に有効なツールを活用しない場合、費用を想像で算出する他はなく、積算結果に説得力がありません。費用削減を要求された場合、あるいはベンダーより不必要に高い見積を提出された場合のどちらについても、それを否定する根拠がないのです。更に、結果的に実際に必要な工数と大きく乖離した工数に基づいてスケジュールを立てれば、作業の大幅な遅れや無理な作業による品質低下・トラブル発生にも結びつく可能性があります。 Teamstudioの活用によって、このような問題を回避する事ができることは、プロジェクトを進める上で非常に大きなメリットと言うことが出来るでしょう。」

移行の今後について

最後に今後の予定を聞いた。
「2004年6月中旬から移行の本プロジェクトに入ります。そして2005年10月にDBに関してはカットオーバーする予定です。」

このようにイニタウトジャパンでは現在、Teamstudioを活用しながら、便利になったとユーザに満足して頂けるシステムの実現を目指し、プロジェクトを推進している。

2004 年 6 月 30 日
* Notes/Domino は IBM Corp. の商標です。