14回 Xupper事例紹介セミナー：パネルディスカッション
設計情報の一元管理を推進する意義とこれから取り組むべき課題セミナー最終セッションでは、「設計情報の一元管理で防ぐ『動かないコンピュータ』」と題したパネルディスカッションを実施。事例紹介に登壇した平末氏、森下氏のほか、日本電気ITサービスビジネスユニット OMCS事業本部 主席主幹の大場彰夫氏、ケン・システムコンサルティング 取締役 技術本部長の本村智之氏が参加し、Xupperによるモデルドリブン開発の有効性やこれからの取り組みについて意見を交わした。 |
 |
複雑な仕様変更への対応で効果を発揮
|
事務作業を代替するためのツールからビジネスの中枢を担う戦略的な武器へITシステムは企業内でのポジションを大きく変化させてきた。システムに携わる身としては大いに喜ぶべきことではあるものの、ビジネスと密接に関わるということは常にその変化に対して柔軟な対応を求められるということでもある。 |
 |
NECの大場氏が手がけた大規模開発案件では、やはりビジネス的な要求の変化に対応するべく、プロジェクト開始後にシステム化の範囲が「コード数にして2～3 倍」という規模で拡大した。
「サブシステムの追加のほか、組織が大きいこともあり、業務フロー図作成後のユーザーへの説明で部門ごとに異なる要件がどんどん増えていったことも原因として挙げられる。
仕様変更が発生するたびに影響範囲を調査しなければならなかったが、ソースコードをチェックするのではなく、Xupperによる影響分析を徹底したことで、調査漏れを防ぐことができた」（大場氏）。
IBMの森下氏もシステム変更に対するXupperの有効性を体験している。20000ファンクション規模の官庁向けシステム開発プロジェクトを担当した際には、約200 名の要員を投入し、毎週500ファンクションのペースで開発を進めると同時に1000ファンクションの修正に対応したという。
影響範囲の調査からコードの自動生成までXupperとMDFrame/Xをフル活用して凌いだという同プロジェクトは、結果的に1週間当たり1500ファンクション相当の工数が発生していたことになるが、「品質的には、バグ発生率0.1％未満に抑えることができた。これは明らかに、設計情報とコードの整合性を確保しながら開発を行ってきた成果と捉えている」（森下氏）。
このような仕様変更時における影響分析や、設計情報とソースコード間の整合性確保は、XupperおよびMDFrame/Xが提供する代表的なメリットと言えるだろう。
継続的な利用によって得られるメリット
|
こうした即効性のある効果のほかに、継続的な利用によって得られる効果もある。それは、リポジトリに蓄積した情報を組織全体の資産として共有し、再利用できることだ。「我々がXupperによる設計情報の一元管理に取り組む最大の目的はそこにある」と、NTT データ東海の平末氏は語る。 |
 |
ただし、Xupperを導入したすべてのユーザーが、このような効果を上げているわけではない。ケン・システムコンサルティングの本村氏は、次のように話す。「継続的に利用していく中で得られる効果も大きいのだが、やはり短期間である程度の導入効果が得られないと見放されてしまうケースも、残念ながらある。
Xupper を16年間担当してきた経験から、個人的には、お客様がXupperを有効に使えるかどうかの鍵は、データ項目にあるのではないかと感じている。データモデルとユーザーインターフェイスの双方でしっかりとデータ項目を定義されているお客様は、その後も有効に活用されているように見受けられる」（本村氏）。
Xupperをより有効なツールへと進化させるために
これまでケン・システムコンサルティングでは、継続的なバージョンアップやアドオンによって、Xupperの機能拡充を図ってきた。そこにはユーザーの声が色濃く反映されており、現在も様々な新機能の開発が計画されている。森下氏が自身の事例紹介セッションの中で取り上げた「IPOエディター」も、その1 つだ。
「設計情報を確実に下流のアクションダイアグラムまで反映し、プログラムに落とし込むためには、現状のXupperの機能ではまだまだ不十分。そこで、IPOエディターの開発をケン・システムコンサルティングにお願いした。
ただ、Xupperですべてをカバーする必要はないと考えている。例えば、Xupperには変更履歴管理の機能がないが、IBM Rational Team Concert のRational DOORS のように設計書の履歴を容易に追跡・管理できるリポジトリを持っているツールとうまく連携させるという方法もあるはず。
最終的な目標はシステム開発プロジェクトを成功させることなので、今後も特定のツールに限定せず、様々なツールの長所を活かしながら、有用なソリューションを模索していきたい」と森下氏は今後の目標を語った。
実は大場氏も、森下氏と同様に、Xupperの新機能開発についてケン・システムコンサルティングとの間で調整を重ねているところだという。「私も、上流の設計情報をいかに下流工程へと確実につなげていけるかが、やはりこれからの大きな課題だと感じている。
今、ケン・システムコンサルティングにお願いして取り組んでいるのは、テストの自動化。上流で設計した内容をべースにテスト仕様書を自動生成し、テストスクリプトを自動実行する機能を、Xupperにアドオンして使える形にしたいと考えている。
他にも、日本語で書いた設計書の内容を極力そのまま手を加えずにコーディングまで落とし込むための仕組みなど、取り組みたいテーマはたくさんある。まずはテスト自動化の機能を実現して、次回のセミナーでご紹介できるようにしたい」（大場氏）。
両氏の発言を受け、最後に本村氏は「Xupperには、まだまだ改善すべき点が多いと認識している。現在お二人が取り組まれている機能のほか、以前から開発に取り組みながらまだ実装できていない機能もあるが、今後も皆様のご意見を参考にさせていただきながら、お客様のシステム開発業務に少しでも貢献できるように、Xupperをより有効なツールへと進化させていきたいと思う」と締めくくり、セミナーは盛況のうちに幕を閉じた。
パネルディスカッションのPDFは下記よりダウンロードできます
株式会社NTT データ東海 様
Xupperを標準設計ツールとして活用しプロジェクトのノウハウ継承や標準化を推進NTTデータ東海では、8年前よりXupperを活用。自社が手がける様々なシステム開発プロジェクトの標準設計ツールとして位置付けている。その目的や、標準ツールとして組織全体に定着させるための取り組み、そして実際のプロジェクトにおけるXupper適用事例について、同社法人事業部 開発担当 課長代理の平末篤史氏が紹介した。 |
 |
組織の方針として継続的にXupperを利用
|
NTTデータ東海では、上流工程から下流工程に至るまで、「様々なノウハウの蓄積・再利用を促進すること」を組織の方針として掲げている。 |
 |
上流工程で顧客と開発側のギャップを埋める
|
こうした体制のもと、NTTデータ東海ではXupperを活用し、様々なプロジェクトに取り組んでいる。その1つが、同社法人事業部の平末氏らが手がけた、販売管理システム再構築プロジェクトである。 |
 |
これは、顧客と開発側の間にあるギャップを埋めて双方の認識を合わせるプロセスであり、そのためには顧客とのコミュニケーションを密にし、認識の齟齬や問題点を1 つ1 つ解決していくことが必要となる。
今回のプロジェクトにおいても、上流工程の3 ヶ月間で約40回もの打ち合わせを実施。こうした中で顧客の理解を得るために、Xupperで作成した様々なドキュメントを活用した。特にビジネスフロー図は顧客にとってもわかりやすく、共通認識を深めていくうえで非常に有効だったという。
ツールの機能は適材適所で活用
ビジネスフロー図の他にも、ビジネスルール、DFD（データフローダイアグラム）、エンティティ設計などのドキュメントをXupperで作成（図1）。これらによって情報の関連付けを行うことで、以降の工程での情報の整理が大幅に効率化されたという。
一方、Xupperの機能を使わずに設計した部分もある。例えば、画面設計についてはHTMLでプロトタイピングを行い、ある程度の動作を確認できるモックを作成し、事前に顧客の操作検証を受けることで、手戻り防止を図った。
そのような経緯もあり、最終的な画面設計はフレームワークとして採用しているintra-martの機能で独自に作成。設計資料については、Xupperのプロセス階層図に紐付けて管理することとした。
NTTデータ東海ではこのように、ドキュメントの作成手段については適材適所で必要に応じて取捨選択する方針としている。自社の標準ツールとして継続的に利用していくうえでも、すべてをXupperの機能で作成することにこだわるのではなく、柔軟に他の方法と組み合わせて使い分けるというスタンスが有効なのだろう。
情報の一元管理や成果物の標準化がもたらす真価
Xupperの代表的なメリットとして挙げられるのが、すべての設計情報をリポジトリで一元管理できること。これにより、仕様変更の影響範囲などをすばやく容易に把握できる。
NTTデータ東海が特に重視しているのは、さらにその先のメリットだ。どんなプロジェクトでも課題や問題は必ず発生するが、その影響調査にかかる工数をXupperで省力化できれば、それだけ本来注力すべき「解決策の検討」に集中できるようになる。
また、NTT データ東海では、これまで蓄積してきた情報やノウハウをベースに、様々なプロジェクトに適用できる「雛形リポジトリ」を作成し、各プロジェクトの成果物標準化に取り組んでいる（図2）。
成果物がある程度固定されれば、品質の底上げにつながる。また、プロジェクトが変わっても作成すべき成果物が同じなら、プロジェクト間で要員の異動があっても作業者は業務ノウハウの習得に専念できるようになる。
これらの効果は、単一のプロジェクトにおいてそれほど即効性のあるものではないが、NTT データ東海では、あくまでも「継続的に利用していく中で、情報やノウハウを蓄積し、次に活かしていくという点において有効に活用できるツール」としてXupperを評価しており、今後も組織として継続的に利用していく方針だという。
株式会社NTTデータ東海様の事例PDFは下記よりダウンロードできます
日本アイ・ビー・エム株式会社 様
設計リポジトリをベースに上流から下流まで一貫した開発手法の確立に向けてPM（プロジェクト・マネージャ）として22年間、様々なプロジェクトに携わってきた日本アイ・ビー・エム GBS事業部 保険アプリケーション開発 エグゼクティブプロジェクト・マネージャの森下隆治氏。担当プロジェクトの9割でXupperを適用し、MDFrame/Xの製品化にも深く関わっている同氏は、ベンダーの立場を越えたPMとしての視点で考案した開発手法「統合開発ソリューション」の提案を行った。 |
 |
今日のシステム開発における課題
|
森下氏は冒頭、システム開発の課題として、日本のSI開発プロジェクトにおけるQCD（品質・コスト・納期）遵守率の調査データを紹介した。それによると、プロジェクトの成功率（QCDすべての遵守率）はわずか30％程度。これは5年前の調査データと比較しても、それほど大きな改善の見られない数値となっている。 |
 |
次に森下氏は、システム開発に関わるそれぞれの立場ごとの課題について指摘した。例えば、経営層の課題として多いのは、経営のスピードに対してシステム化のスピードが十分に追随できていないこと。
また、情報システム部門は、既存システムの硬直化から、システム改修・保守が課題となっているケースも少なくない。特に、数千万ステップもの大規模なシステムを抱える企業では、「オープン化したくても保守で手いっぱい」というのが実情だろう。
一方、開発側（ベンダー）は常に、要求内容に対するユーザーとの認識ギャップという課題を抱えている。そして、多くのPM を悩ませているのが、スコープの増加と、それに伴うコスト超過や納期遅延の問題である。
開発保守工程全体から見た問題点
続いて森下氏は、開発保守工程全体から見た問題点を整理。まず、要件定義における問題として挙げたのは、業務要件がシステム要件に確実に反映されていないこと。
また、非機能要件が網羅されていないことや、各要件と設計情報との紐付けが不明でトレーサビリティが確保されていないといったことも問題となる。
設計工程においては、設計書が古い、または不足しているというケースがある。設計書間の不整合という問題も少なくない。
開発工程で特に多いのは、設計情報とソースコードの不整合およびトレーサビリティの欠如だ。また、開発スキルによる生産性のばらつきなど、属人的な問題も大きい。
テスト工程においても、テストケース漏れ、テスト自体の生産性など、様々な問題が起こり得る。そして、後工程に行くほど、テストで手戻りが発生した場合のコストや納期に対するリスクが増大してしまう。
Xupperを核とした統合開発ソリューション
|
こうした様々な課題や問題点に対する解決策を、森下氏はPM としての視点から検討。それらを体系化し、ソフトウェアエンジニアリングの手法を取り入れて、上流工程から下流工程までの一貫した開発手法としてまとめたものが「統合開発ソリューション」である。 |
 |
また、統合開発ソリューションは、要件定義と設計に重点を置いた開発手法であり、コーディングレス開発を指向している点も大きな特徴だ。
設計情報と整合性の取れたコードの自動生成は、MDFrame/Xの機能によって実現。特定の言語に依存しないアクションダイアグラムの記述でコードが生成できるため、開発者のスキルに依存せず、プログラムの品質と生産性の均一化を図ることができる。
なお、XupperにはIPO（Input Process Output）情報を定義する機能がないが、ケン・システムコンサルティングでは現在、森下氏の依頼により、設計リポジトリ管理ツールの一機能として「IPOエディター」の開発を計画中だ（図2）。
これにより、今後はIPO 設計情報によるトレーサビリティが実現されるという。また、リポジトリのIPO情報からテスト仕様候補を抽出してテストカバレッジを確保する機能の追加なども予定されている。
テスト自動化やパイロット開発も可能に
他にも、統合開発ソリューションは下流工程において、画面テスト操作自動化や回帰テストの自動化、テスト結果検証自動化、エビデンス自動取得などの機能を提供。これらは、IBMのソリューションを組み合わせることで実現している。
その1 つが結合テスト・システムテストやユーザー受け入れテスト（UAT）をサポートするツールで、テスト時の画面やDBなどの取得を簡易化し、テストエビデンスを自動生成することができる。
また、画面テスト操作や回帰テストの自動化ツールはselenium等をベースとしたもので、プロジェクトごとに最適な方法でテストスクリプトを記述し、自動テストを実行可能。
こちらも、標準化されたテストエビデンスを生成する機能を提供する。これらのツールは、Xupperのビジネスフロー図からテストケース作成機能とも組み合わせて活用することができる。これらはテスト実施工数の削減はもちろん、テストそのものの品質向上にも有効だ。
設計リポジトリの画面設計情報からJSPを自動生成する画面設計ツールも、現在作成中だという。この機能を活用すれば、要件定義段階から画面をパイロット開発する方式を取り入れることも可能となり、要件漏れやテスト工程での手戻り防止といった効果が期待できる。
現時点では実現されていない機能や計画中の機能も含まれる統合開発ソリューションだが、設計リポジトリによる全工程の一元管理や属人性を排除したコーディングレス開発といったアプローチは、リモート開発を前提とするグローバルな開発スタイルとの親和性も高い。より安価な開発要員の確保や開発期間の短縮にも有効な仕組みとして、今後、大いに期待できるのではないだろうか。
日本アイ・ビー・エム株式会社様の事例PDFは下記よりダウンロードできます