株式会社NTT データ東海
要件定義にXupperをフル活用し物流倉庫システムの短納期開発を実現NTTデータ東海は、自動車部品などを扱う専門商社の物流倉庫システム構築プロジェクトにXupperを活用。4ヵ月弱という厳しい納期要求に応えるために、膨大なビジネスフロー図を用いたユーザとのコミュニケーションで業務運用イメージを明確化し、要件定義から設計に至るプロセスの大幅な効率化を実現した。Xupperならではのビジネスフロー図の作成効率の高さが、今回のプロジェクト成功を支えた大きな要因となっている。 |
 |
複数の外部倉庫を集約する物流倉庫システム構築プロジェクト
NTTデータ東海の10年来の顧客であるT社は、自動車に使われる樹脂素材や部品、塗料などをはじめ、生産工程で必要となる機械用オイルやウエス、手袋などの消耗品まで幅広く扱う専門商社であり、研究開発部門やメーカー機能も有している。
T社では商品物流機能として、東海地域を中心に外部委託を含む35ヵ所の物流倉庫を利用していたが、小規模・複数の外部委託倉庫は費用的にも運用効率の面でも問題があった。
そこで、自社の研究施設内に新物流センターとして自社運用の大規模倉庫を建設することを決定。今回、NTT データ東海が手がけたのは、この新物流センターで運用する物流倉庫システムの構築である。
なお、NTTデータ東海が最初に開発依頼を受けたのは2006年12月末。T社が要件に挙げたサービス開始日は2007年5月7日であり、非常に厳しい納期要求のプロジェクトとなった。
システム化の対象業務は、言うまでもなく倉庫に関わる業務全般。入荷・入庫・出庫・出荷・在庫管理・ロット管理はもちろん、液体や薬品も保管するため、消費期限管理や危険物管理も含まれる。さらに、業務の状況に応じて要員を流動的に配置するという要員管理の機能も必要とされた。
自動倉庫システムやハンディターミナル、基幹業務ホストとのインターフェースも必要だ。また、すでに倉庫の建物は建設中でLANケーブルが引けないため、無線LANの導入も必須。ほかに要員管理とも関係して、出荷状況などの作業情報をモニターに表示する「IT ボード」の導入も開発要件に含まれていた。
新物流センターの倉庫は、保管目的に応じて大きく3 つに分けられている。1つは、一般資材商品を扱い、900 パレット強の保管能力を備えた資材倉庫。自動倉庫はここに入ることになる。
もう1つは、300 パレットの保管能力を持つ危険物倉庫。そして、3 つ目が温度湿度管理が可能な定温倉庫。5 月7 日のサービス開始時点では、35 ヵ所ある外部倉庫のうち15 ヵ所分をこれらの新倉庫に集約し、約40 万アイテムの商品を管理することとされた。
その根幹を支えるのが、新たな物流倉庫システムである。従来の外部委託倉庫による物流管理では、複数拠点をまわる配送効率の悪さはもとより、入出庫業務などがシステム化されていないため、属人的な管理によって誤出荷や不良在庫などが頻繁に発生するという問題があった。物流倉庫システムでは、これらの問題を撲滅することが命題とされていた。
厳しい条件の中、プロジェクトを成功させるにはXupperが不可欠
このように、短納期かつ複雑なシステム要件のもと、2007 年1月早々にスタートしたT社の物流倉庫システム構築プロジェクトだが、プロジェクト開始後にはさらに厳しい条件が加わることになった。
まず、一部システムの納期がさらに短縮されたことが挙げられる。新物流センターのサービス開始日は5 月7 日に設定されていたが、2月末の段階で急遽、危険物倉庫のみ先行して4 月上旬のサービス開始へと変更された。これは、危険物に関しては1ヵ月程度の十分なテスト運用が必要というT 社の業務判断によるものだ。
さらに、ユーザ側の体制構築にも遅れが生じた。自社での物流倉庫システム運用はT 社にとっても新規の業務であり、実務経験者もほとんどいない。
そのため、プロジェクト担当者の選任には試行錯誤を繰り返した。最終的に正式な担当者および運用体制が確定し、新体制でのキックオフが行われたのは3 月上旬となっている。
もちろん、1月から2 月にかけてT 社の担当者が完全に不在でプロジェクトがストップしていたわけではない。何度も担当者の変更を行ったものの、徐々にコアとなるメンバーが決まっていったというのが実情だ。
NTT データ東海では、その時点でアサインされていた担当者のもとへ足を運び、1月より要件定義を開始。2 月中旬まで、ヒアリング、運用課題の整理、要求仕様整理などの作業を順次実施した。
ここで真価を発揮したのがXupperである。NTT データ東海は、以前よりXupperを上流設計ツールとして活用しており、過去にもXupperユーザ事例紹介セミナーにおいて事例発表を行っているほど、その有用性を十分に理解している。
今回のプロジェクトに関しても、当初より要件定義および設計の効率化が不可欠と考え、Xupperを活用することについて事前にT 社の了承まで得ていたという。
ビジネスフロー図で業務を可視化しユーザと運用イメージを共有
今回の物流倉庫は新設であり、T 社の担当者も業務の一部分しか分からない状況からプロジェクトがスタートした。そこで、NTT データ東海では、まず倉庫業務を目に見える形で情報提供し、運用を確定させていく中で課題や問題点を1つ1つ発見して、解決していく手法を採った。
具体的には、Xupperで作成したビジネスフロー図の有効活用だ。倉庫業務のビジネスフロー図を作成し、それを見せながらT 社担当者へのヒアリングを実施。ユーザとのコミュニケーションを図りつつ、さらにレビューとビジネスフロー図の修正を繰り返し行った。
こうして倉庫業務を徹底的に可視化することで、ユーザ側の運用イメージも次第に明確になってくる。逆に、運用イメージが明確にならなければ、仕様を確定することも不可能だ。
今回のプロジェクトにおいて、NTT データ東海は特にこの工程を重視し、1月中旬から下旬にかけてヒアリングを10 回以上行い、80 枚以上のビジネスフロー図を作成した。
続いては、物流量や確定している倉庫担当者の人員数、入出荷予定から運用を確定するステップとして、運用課題の整理を行った。ここでは、倉庫内での要員の動きを考慮した動線図なども作成。
業務運用ビジネスフロー図と一緒に、Xupperにビジネスルール（設計資料）として格納していった。
なお、NTT データ東海では、プロジェクトにおいて設計担当SE が個別機能の設計を行う場合に、ビジネスルールの記述内容をガイドラインとして作業することをルール化している。
製造方式や基本機能をビジネスルールとして一元管理しておくことで、今回のプロジェクトのように自動倉庫の制御インターフェースや基幹ホスト連携、ハンディターミナルのプログラムなど、種類の異なる技術や設計要素が混在する環境においても、複数のSE が分担してスムーズに設計を実施することができるのだ。
このように、Xupperを活用して要件定義の効率化を図ることで、NTT データ東海は、ほぼ3 週間ですべての仕様を確定することができた。ただし、続く基本設計および詳細設計の工程においては、ちょうどT 社の担当者が変わり、新体制へと移行した時期と重なったことも影響して、手戻りが少なからず発生したという。
これも結果的には、Xupperで設計情報を一元管理していたことが、手戻りの影響を最小限に抑えることにもつながった。
また、今回のようにAS/400 ホスト、物流倉庫システム、自動倉庫用サーバなど、複数のデータベース・システムへのアクセスが発生する詳細設計を実施する場合、データベースのエンティティ設計が完全に完了した上でプロセス設計を行うことが理想だが、現実的には、設計途中でのエンティティ（項目）変更・削除・追加などが発生することも多い。
|
その際、設計書に書かれている入出力項目がデータベースから消えている、数値項目のはずがコードになっているといった齟齬が発生して、テストプログラムが突然動かなくなるようなケースも珍しくない。 今回のプロジェクトでは、Xupperですべてのエンティティ情報と設計書情報を一緒に管理していたため、そのような問題が発生する前の段階での発見・対応が容易に行えた。これも、無駄な工数を削減し、工期短縮につながる大きなメリットと言えよう。 最終的に、NTT データ東海は4 ヵ月弱という厳しい納期要求に答えることができ、T 社新物流センターの物流倉庫システムは、予定どおりサービスを開始。今後は残りの外部倉庫もすべて新物流センターに移管し、物流機能を完全に集約する予定だという。 今回のプロジェクト成功の要因はもちろん上流工程だけではないが、NTT データ東海では、要件定義・設計におけるXupperの実効性を改めて高く評価している。 |
 |
株式会社NTT データ東海様の事例PDFは下記よりダウンロードできます
株式会社電力計算センター
運用管理上の課題を解決すべくXupperで設計情報をDB 化顧客システムの運用管理業務においては、不具合対応や追加開発など、設計情報からシステム仕様を確認しなければならないことも多い。しかし、設計時点から運用工程での利用を想定した形で整理しておかなければ、設計情報は非常に扱いにくいものとなってしまう。電力計算センターでは、Xupperでビジネスフロー、エンティティおよびプロセスなどの情報をデータベース化し、こうした状況を改善。設計情報の有効活用を可能にした。 |
 |
リポジトリによる一元管理。全工程での生産性向上を実現するXupper
複雑化するユーザのニーズに的確に応えながら、低コスト・短納期が求められる今日のシステム開発を成功させるためには、まず、上流工程で、ユーザニーズを正確に把握して、その後の中・下流工程の開発につなげていくことが重要なポイントとなる。
|
こうした要求に応えるのが上流分析／設計ツールXupperである。その最大の特長は、業務を可視化することで経営者やユーザ部門にも分かりやすく、システム部門とのコミュニケーションがきちんととれることだ。 さらに、設計情報がリポジトリで一元管理されているため、システム開発の工数削減と品質向上が可能になることだ。設計途中で仕様変更が発生した場合も、クロスリファレンス機能を使用することで、影響分析や一括修正が可能となり、大幅な品質向上が図れる。
|
 |
設計情報の扱いにくさがシステム運用上の課題に
電力計算センターは、IT プロバイダとしてA 社システムの運用管理を行っている。対象システムは、財務会計や資産・プロジェクト管理、人事労務・給与管理などの各システムをデータ連携し、ポータルで入口を統一した「基幹業務統合システム」だ。
この基幹業務統合システムは、業務システムの統合を目的とした約2 年間の大規模な再開発によって構築された。サーバ台数は22 台で、そのうち運用系が12 台。Windows 系とLinux 系が混在し、ミドルウェアはWebSphere Application Server にOracle9i Real Application Clusters という基本構成だ。
なお、スクラッチ開発およびパッケージカスタマイズ開発を含む業務アプリケーションのプロセス数は約1800、データベースのテーブル数は約1000 となっている。
電力計算センターでは、A 社の要求に対応すべく基幹業務統合システムの運用開始後も小規模な追加開発や改良・改修を行ってきたが、そこではさまざまな問題が発生していた。
たとえば、システム更新にあたっては当然、影響範囲を事前に把握する必要があるが、その特定にはかなりの時間を要した。業務アプリケーション設計書の更新にも非常に手間がかかっていた。
また、追加開発発生時に限らず、通常の運用においても、顧客からの質問に対する回答に時間がかかる、業務アプリケーションの情報（仕様）が見えにくいといった課題を抱えていた。
これらはすべて、「設計情報の扱いにくさ」に起因する問題だ。もちろん、運用開始時点の詳細設計書は存在し、A 社にも納品されているが、これだけプロセス数もテーブル数も膨大なシステムの設計書の中から必要な情報をすぐに探し出すのは難しい。こうした状況を改善するために、電力計算センターでは次のような対策が必要と判断した。
まずは、プロセスとデータの関係を明確にする。そこから業務フローを明確にして、扱いやすく整理することで人の判断を支援する。
そのための作業として、基幹業務統合システムの設計情報に対し、データ情報やプロセス情報、CRUD 情報の再整備を行い、業務フロー情報を追加する。そして、それらを利用しやすい環境を実現するために、情報参照用インターフェースなども作成する。
Xupperの利用を前提に手作業で設計情報を整理
電力計算センターは、まず「どうすれば設計情報を利用しやすくできるのか」という観点から、「簡易ポータル」のイメージを作成した。
これは、業務処理間の関係を、データを中心に表現し、マップ化したものだ。A 社の協力を得たことで、「財務会計」「資産」「購買」といった業務や各種処理、更新・参照などのデータの流れを、ユーザにも理解しやすい形でまとめることができた。
次に行ったのが、利用するツールの選定だ。Xupperのほかには、ソースプログラムからCRUD 情報をリバース生成する方法も検討したという。しかし、調べてみても該当する製品は存在せず、自社で開発するには負担が大き過ぎた。
また、フリーウェア（当時）のツールも候補に上がったが、業務フローが扱えることや出力機能が豊富であること、そして過去に利用経験があったことなどが決め手となり、Xupperを選択した。
ツール決定後は、さっそく設計情報を整備する実作業を開始した。最初は手作業による設計情報起こしである。
基幹業務統合システムの運用開始時点の情報に関しては、Excel形式のCRUD 表がまとまっていたので、それを精査。そこに、運用開始後に電力計算センターで改良・改修した差分を追加していった。
また、大規模な追加開発を行った際のCRUD 情報がなかったので、その分はExcelでCRUD 表を新規作成し、現状との整合性を確保した。
さらに、導入しているパッケージソフトウェアの設計情報についても、パッケージベンダに業務委託という形で協力を依頼。もちろん、設計情報（仕様）が開示されない製品もあり、一部は抜ける形になってしまうが、財務会計パッケージ「FinaliZe」を提供しているゼストプロの協力を得ることができた。
これにより、FinaliZe の設計情報をExcel のCRUD 表にまとめ、さらにカスタマイズによる差分情報も追加された設計情報を入手できた。
5つの壁をクリアしてDB化公開設計情報をHTMLで出力
Xupperに情報を入力してデータベース化する段階では、以下のような「5 つの壁」があったという。
- CSV 形式にまとめても、一括入力できない情報がある
- マトリックス分析からの出力はプリンタ形式のみ
- ビジネスフロー図からの出力はプリンタ形式のみ
- アプリケーションエリアの更新に時間がかかる
- 繰り返し利用される共通部品などのオブジェクトの扱い
1.はCRUD 情報のことを指している。プロセス情報やエンティティ情報と異なり、CRUD情報はCSV 形式でXupperへの一括入力ができない。これについてはシンプルに「こつこつと手入力」することで対応した。
2.3.は入力後の問題だが、Xupperにまとめた設計情報をさまざまな形で活用していくためにも、ある程度汎用性の高い形式への出力が必要と考えていた。そこで、ケン・システムコンサルティングから提供されているQuery API Sample のExcel 形式マクロやBFD 関連機能（Version 2.20）を活用し、Excel およびHTML 形式での出力を実現した。
4.についてはCRUD 情報と同様に、エンティティの括りは「こつこつと更新」することで対応した。
5.についてはXupperのDLCP 機能への入力を検討したが、BP やDAP のマトリックス分析を外部出力する機能がないことや、入力作業工数の見積りも膨大であったことから断念。そこで、「全対象エンティティ」と「共通部品」、「プロシジャー」と「プロセス」など8種類の組み合わせについて、「エンティティ」と「プロセス」の関係と同様に表現した。ただし、設計時点からXupperを使用する場合なら、やはりDLCP 機能を用いるのが有効だという。
こうして5 つの壁もそれぞれクリアし、準備した設計情報をすべてXupperに入力した。これでデータベース化自体は完了するわけだが、電力計算センターはさらに、設計情報を「利用しやすい仕組み」を追加。
Xupperに格納した設計情報をQuery API Sample を使ってHTML 出力し、それを最初に作成した「簡易ポータル」のマップにリンクさせた。
たとえば、「財務会計」をクリックすると対応したビジネスフロー図が表示され、そこからマトリックス（CRUD 表）などもリンクでたどれる仕組みだ。これによって、運用管理担当はもちろんA 社のユーザも、簡易ポータルから直観的に必要な設計情報を参照することができる。
この仕組みを有効に活用していくために、電力計算センターは変更管理・リリース管理を手順化した。まず、設計情報の確認、変更要求の妥当性確認・承認を経て、構成変更を行う。
そして、設計情報DB（Xupper）を変更したらHTML に出力。「公開設計情報」として、簡易ポータルのリンクを差し替えていく。こうすることによって、常にXupperで管理している最新の設計情報に、簡易ポータルからアクセスできるというわけだ。
設計情報をデータベース化した効果としては、やはり設計情報が利用しやすくなったことが第一に挙げられる。設計情報を有効に活用することによって、作業効率の向上と判断ミスの軽減を図ることもできた。
また、顧客の経営層に対して、基幹業務統合システムの理解を深めるための道具としても有効に機能しているという。
すでに、簡易ポータルからの検索機能やビジネスフロー図の拡充など、いくつかの機能改善案も上がっており、今後それらにも順次対応していく。また、電力計算センターでは今回の経験を通じ、「今後は設計時から運用管理を強く意識し、積極的にXupperを活用する」と考えている。
株式会社電力計算センター様の事例PDFは下記よりダウンロードできます
株式会社 大和総研
金融機関向けシステムの保守開発をXupperとMDFrame/X で効率化金融機関向けに幅広いソリューションサービスを展開する大和総研では、投信窓販システムの保守開発効率化のためにXupperを採用。上流工程における設計情報の整合性確保、DOAによる安定したデータベース構造の設計に取り組み、緊急の変更対応やシステムの根幹にかかわる機能拡張などもスムーズに行える環境を構築した。また、Xupperの設計情報と連携したMDFrame/XのSQL自動生成機能も活用し、生産性と保守性を高めている。 |
 |
Xupper ＋ MDFrame/X によるプログラム自動生成
|
ケン・システムコンサルティングでは、Xupper のリポジトリを拡張し、モデル駆動型の開発を実現するツールMDFrame/Xも提供している。このMDFrame/X は、リポジトリに登録された設計情報からプログラムを自動生成するので、プログラミングによるバグの発生が抑えられる。 上流工程ではXupper を用いて業務フロー図とビジネスルールをベースに、エンドユーザにも分かりやすい設計情報を作成する。そして、下流工程ではMDFrame/X を用いて、詳細モデルを記述し、そこから Java、 .NET、 Biz/Browser 等のプログラムを自動生成する。 詳細モデルは、業務ロジックのみを記述するだけでよいため、工数を最小化できる。さらに、仕様変更が発生した場合でも、モデルの変更のみで対応できるため、設計にかかる負担は大幅に軽減できる。 これによって、上流から下流まで一気通貫で設計情報の一元的な管理ができ、「見える化」を実現するとともに、設計プロセス全体の効率化やスピードアップも可能となり、さらには品質の向上や保守性の向上も図ることが可能である。 |
 |
設計情報の整合性確保と生産性・品質の向上を目指して
大和証券グループのシンクタンクである大和総研では、銀行の投信窓口販売業務を支援するソリューションとして、投信窓販フロント・ミドルシステムの「SONAR-FR」、投信窓販インターネットフロントシステムの「SONAR-IC」などを提供している。
ユーザはこれらのシステムをASP サービスとして利用する仕組みであり、低コストで導入・維持できるのが特徴だ。複数社でサーバやソフトウェアなどのリソースを共同利用することから、法制度改正への対応なども1社あたりの負担が少ないというメリットもある。
また、各社各様のコンプライアンスチェック機能や顧客カード情報管理機能、金融商品取引法対応などを柔軟に取り込むことも可能となっている。
大和総研では2004 年にSONAR-FR のシステム開発に着手し、2005 年4 月よりサービス提供を開始した。一方、SONAR-IC は2006 年末に開発をスタートし、2007 年夏にリリースした。
これらのシステムにおいては、上記のようなサービス特性からも分かるように、リリース後もシステム全体にかかわる変更やユーザごとのカスタマイズといった保守開発が頻繁に発生する。
安定したサービスを提供し、かつ継続的に機能向上を図っていくためには、この保守開発をいかに効率的に行うかが重要な鍵となる。
このSONAR-FR とSONAR-IC のシステム保守開発において、大和総研ではいくつかの課題を認識していた。
1つは、ビジネスフローやER 図、テーブル定義書といった設計情報が、Word、Excel、Visio など別々のドキュメントフォーマットで作成され、管理されていたことだ。
そのため、設計情報を更新する際は各ドキュメントを個別に修正する必要があり、それぞれの関連性は人間が判断するしかない。設計情報をより効率的に、整合性の取れた状態で管理することが求められていた。
また、ユーザごとのカスタマイズ要件をシステムに取り込んでいく上では、その影響範囲を正確かつ迅速に把握することも必要だ。
さらに、安定したデータベース構造とするために、DOA（Data Oriented Approach）によるデータベース設計も必要と考えていた。
XupperとMDFrame/Xをそれぞれ最適な範囲で適用
大和総研では、こうした課題を解決するために最適なCASE ツールを検討し、Xupperの導入を決定。
決め手の1つは、Xupperは他製品との連携機能など、CASE ツールとして機能が豊富であったことだ。また、ライセンス体系も重要なポイントとなった。
開発ピーク時のユーザ数に合わせたライセンスが必要となるとコスト的な負担も大きいが、Xupperは同時利用ユーザ数のライセンス体系なので、開発要員の増減にも柔軟に対応できる。加えて、社内の別部門でも導入されているという安心感もあった。
Xupper導入後には、Xupperの設計情報からSQL やJava ソースを自動生成できるというMDFrame/X についても導入を検討。コーディングの属人性を排除することは品質向上にも効率化にも直結すると判断し、採用を決定した。
既存システムに対してXupperを適用する上で必要な作業として、まず取り組んだのはディクショナリの整理だ。ネーミングについてはXupperの制約を満たす必要がある。たとえば、これまでは異なるテーブルでそれぞれ「商品区分」という同じカラム名が存在していた。
一方はファンド情報の「商品区分」であり、もう一方は取引情報の「商品区分」だ。もちろん管理している情報は異なり、桁数も異なる。このままでは登録できないため、取引情報のカラム名を「取引商品区分」という名称に変更した。同様に、対象となるすべてのプログラム、テーブル、カラム名を変換し、整理した。
Xupperの利用方法を確立する上での苦労もあった。SONAR-FR やSONAR-IC は頻繁に機能向上やカスタマイズが発生するシステムであり、あまりに詳細にわたって完璧な管理を行おうとすると、Xupperの管理自体がオーバーヘッドとなってしまう場合もある。
開発プロジェクトの性質に応じて利用機能を決定し、管理すべき設計情報の範囲を決めることが必要だ。そこは試行錯誤を重ねながら、最適な利用方法を模索していった。
また、Xupperでは設計情報を変更するとすべて最新の情報に置き換わり、いつどのように変更したのか履歴が分からなくなってしまう。複数のプログラマが同時に変更をかけていくと、どこまでが実装されているのか、あるいは開発中なのかといった管理が難しくなるため、実際の運用上は、特定の担当者が設計情報の登録を集中して行い、管理することでカバーした。
MDFrame/X についても、最適な適用範囲を検討。MDFrame/X でプログラムまで自動生成することも可能だが、大和総研ではStrutsによるWebアプリケーション開発を行っており、開発の自由度や既存資産の有効活用を考慮して、SQL 自動生成のみ適用することとした。
既存のプログラムに関しては、SQL 部分の書き直しを実施。一部のプログラムでは複雑なSQL を生成できないこともあり、そこは複数の単純なSQL に分解してプログラムのロジック変更で補う形で対応した。
設計情報の一元管理とSQL自動生成が生む効果
SONAR-FR およびSONAR-IC の保守開発にXupperを導入したことにより、上流工程における設計情報の一元管理が可能となった。その効果として大和総研が第一に挙げるのが、システムの根幹にかかわる機能拡張もスムーズに行えるようになったことだ。
システム変更の影響を分析するために、従来のように複数のドキュメントやソースを解析する必要がなく、Xupperのリポジトリ情報から迅速に影響範囲を確認できる。
また、以前はテーブルレイアウトなどの設計情報をファイル配布していたが、それを止めてXupperの参照を全員に義務付けた。もちろん、プログラム変更が発生した際は、必ずXupperの設計情報を修正することもルール化している。
これにより、全員が常に最新の情報で開発を進めることができるようになった。頻繁に発生する項目追加やテーブル追加にも、スムーズに対応可能となっている。
なお、Xupperの設計情報登録完了まで、下流工程では作業着手できないということになるが、これにより従来のような見切り開発がなくなった。その分、手戻りはほとんど発生しないようになったという。
|
ディクショナリの整理を行ったことで、プログラムの可読性も向上した。同じ項目名で内容の異なる項目が一切なくなったので、プログラム内のソースの検索によって当該項目の使用箇所を確実に抽出することが可能だ。これは、保守性の向上につながっている。 MDFrame/X に関しても、現状はSQL 自動生成のみの適用だが十分な効果を生んでいる。それは、自動化による作業時間短縮だけに留まらない。 以前は複数のプログラマがSQL を書いていたため、どうしてもプログラマによって書式にクセが出て、読みにくいSQLや効率の悪いSQL も存在していた。 それが、MDFrame/X でソフトウェア的に自動生成されるSQL なら、誰が操作してもSQL の書式は統一されることになる。もちろん、複雑なSQLや効率の悪いSQL の生成は抑制されるので、生産性と保守性をともに高めることができるのだ。 なお、大和総研では、今回のXupperとMDFrame/X を活用した保守開発効率化の取り組みを通じ、Xupperに対する設計情報の変更履歴管理機能の追加など、いくつかの要望事項をケン・システムコンサルティングに挙げている。 こうした現場のニーズを取り入れていくことで、XupperやMDFrame/X が今後もさらに開発の効率化や品質向上に貢献するツールとして進化し続けていくことに大いに期待したい。 |
 |
株式会社 大和総研様の事例PDFは下記よりダウンロードできます