第16回Xupper事例紹介セミナー講演レポート

公開日 : 2014年04月13日
更新日 : 2021年12月28日

 1994年のリリースから18年目を迎えた純国産の上流分析・設計ツールXupper。毎年恒例となる同製品の「ユーザ事例紹介セミナー」(ケン・システムコンサルティング主催)が、2012年11月に開催された。

 第16回目となった今回のセミナーでは、まず、プロジェクトマネジメント・コンサルティングの瀬尾惠氏による基調講演「トラブル・プロジェクトの予防と是正」が行われた。

 続く事例紹介セッションでは、明治座の赤俊也氏が「鳥の目を持って、地べたを這う」、日本アイ・ビー・エムの森下隆治氏が「プロジェクト・マネジメントにおけるSWエンジニアリング適用の有用性と実践的ソリューションの提言」をテーマに、それぞれ講演を行った。まずはじめに、基調講演の内容をお伝えする。

株式会社プロジェクトマネジメント・コンサルティング 様

医療に学ぶトラブル・プロジェクト対策と整備すべきフレームワーク

 基調講演には、書籍『トラブル・プロジェクトの予防と是正』(鹿島出版)の著者、瀬尾惠氏が登壇。同書のテーマでもある、医療分野に学ぶべきトラブル・プロジェクトの予防や診断、治療(是正)、それらの前提となるトラブル分類・体系化などを紹介するとともに、プロジェクト・マネジメントを支える社会制度やインフラ、研究・教育基盤などの現状について問題提起した。

株式会社プロジェクトマネジメント・コンサルティング 瀬尾惠 様

医療のように強固なフレームワークの整備が急務

 病気とトラブル・プロジェクトには、多くの共通点がある。ともに「人」にまつわる事象であり、早期に手を打つほど影響は軽微、また、適切な対策により予防も可能だが、対処(治療)には専門知識と経験が必要だ。

 トラブル・プロジェクト対策において、予防・診断・治療といった医療行為に学ぶべき点も少なくないだろう。ただし、医療とプロジェクト・マネジメントを取り巻く環境の" 厚さ" には大きな差がある。

 今日、私たちがこれだけ充実した医療を受けられるのは、まず、医療行為を支える社会の仕組みによるところが大きい。

 例えば、医師は国家資格であり、医師国家試験への合格および2年以上の臨床研修を受けなければならない。これに対して、プロジェクト・マネジメントの仕事は、まだ多くの企業において資格という概念で扱われず、ロール(役割)として定義されている。

PMP(Project Management Professional)というプロジェクト・マネジャーの公的資格は存在するが、国家資格ではない。

 法律についても、医療法、医師法、薬事法、薬剤師法など多数の法律やガイドラインに支えられた医療に対して、プロジェクト・マネジメントに関する法律は存在しない。規律を支えるのは「倫理と行動規範」だけだ。

 また、医療は、学門・研究教育基盤としての「医学」にも支えられている。基礎医学では約10 種類の分野、応用医学では50 種類以上の実績を持った分野が確立されており、医学部を有する大学も国内に80 大学ほどある。

 一方、プロジェクト・マネジメント学と呼べるものは基礎分野でせいぜい3 ~ 5 種類。多くの論文が発表されているものの、ほとんど応用分野として「分化」していない。基礎研究・教育を行う大学(学科レベル)もごく少数だ。こうしたプロジェクト・マネジメントを支えるフレームワークの整備が急務であることを瀬尾氏は強調した。

トラブル・プロジェクトを114 種類に分類・体系化

 医療において「予防」は予防医学に基づき、健康増進・疾病予防の第1 次予防、早期発見・早期措置の第2 次予防、リハビリテーションの第3 次予防が定義されている。瀬尾氏は、プロジェクトのトラブル予防をこれに即して説明。

 第1 次予防は、トラブルが発生しないようにするための高品質なプロジェクト計画の作成などが該当する。第2 次予防は、レビューやチェックリスト、モニタリング、早期措置によるトラブルの早期発見と治療。そして第3 次予防としては、トラブル回復後の処置として、教訓の蓄積と再利用(伝染防止)、プロジェクト・マネジャーへのリハビリなどを挙げた。

 医療行為の診断における前提として、病気は疾患の種類や病巣の局在、原因、進行など様々な要素で分類され、それぞれ固有の病名がついている。電子カルテなどIT 化に伴い、現在はICD 国際疾病分類によってコードも標準化されている。

トラブル・プロジェクトを114 種類に分類・体系化

 それに対して、トラブル・プロジェクトについては類似のトラブルが多発しているにもかかわらず、「病名」が存在しない。適切な診断・是正のためにも、トラブル分類の体系化や用語標準化が望まれるところだ。

 そこで瀬尾氏は、「特徴」「分類名(原因)」「組織」「影響度」という4 要素から成るトラブル名称を定義し、「恒常性<特徴>リソース不足<分類名>プロジェクト<組織>(レベルB)<影響度>」のように、病名に相当するトラブル名称を体系化した(図1)。

 原因分類をトラブルの一般呼称とし、原因は5 カテゴリーに区分。これにより、トラブルは合計114 種類に分類されている。なお、瀬尾氏の著書『トラブル・プロジェクトの予防と是正』では、114 種類それぞれについての徴候や予防法、是正法まで網羅し、紹介されている。

対症療法のみならず根本療法=再発防止策のプロセスを確立すべき

 歴史ある医療においても「診断」は困難な行為であり、(調査によって数値は異なるが)約10 ~ 30%の「誤診」が起きている。瀬尾氏の経験上、トラブル・プロジェクト診断の誤診率は、医療よりも圧倒的に高いという。

 また、トラブルの「再発」も多く、これは誤診または根本治療がなされていないことに起因するようだ。医療の場合、症候分類(症候学)に基づいて決められた項目を診断するが、プロジェクトの診断においても、トラブルの「徴候」を分類し、体系化できると瀬尾氏は指摘する。

 例えばプロジェクト全体なら報告遅延や課題管理異常、計画(乖離)ではスケジュール遅延やスケジュール変更、プロジェクト・マネジャーという「人」が対症の場合であれば勤務状況異常やコミュニケーション欠落などに、その徴候を見ることができる。

 診断に続く「治療」については、表面的な症状を軽減するための「対症療法」と、病気の原因そのものを取り除く「原因療法(根本療法)」の2 つに大きく分かれる。プロジェクトではほとんどが対症療法であり、原因療法がなされていないという。

対症療法のみならず根本療法=再発防止策のプロセスを確立すべき

 スケジュール遅延に対して「残業でリカバリ」や「人員追加でリカバリ」、コストオーバーに対して「コンティンジェンシー(予備費用)の取り崩し」といった対応は、すべて対症療法だ。

 また、治療の根本療法でもよく使われる「医療手術」は、「術前同意」「術前管理」「術前措置」「術後管理」といったプロセスが確立されており、トラブル・プロジェクトにおいても、このような体系化が望まれる。

 瀬尾氏は、トラブル・プロジェクトの診断・是正プロセスについても改めて、3 つのプロセスと2 つのゲートを使って整理(図2)。

 ポイントとして、是正計画には対症療法のリカバリのみならず、根本療法となる「再発防止策」を組み込むこと、是正措置のガバナンス期間による評価と確認のプロセスにおいて、再発防止策を企業内プロセスへ組み込むことなどを紹介し、講演を終えた。

株式会社プロジェクトマネジメント・コンサルティング 様の基調講演PDFは下記よりダウンロードできます

基調講演PDFをダウンロードする

株式会社明治座 様

「鳥の目を持って、地べたを這う」
現場の強みを徹底的に生かすデータモデル/プロセスモデルの作り方

 「この、ひろい世の中は赤の色や、緑の色や黄の色や、さまざまな、数え切れない色合いによって、成り立っているのじゃ」─明治座の赤氏は、池波正太郎の小説『黒白』で主人公の秋山小兵衛が息子に語った言葉を冒頭で紹介。現場のユーザーと開発側が立場の違いを超えて共通認識を持ち、曖昧な"無数の色合い"から仕様を固めてシステムとして具体的な形にするためには上流工程で何が必要なのか、自身の経験に基づいて解説した。

株式会社明治座  赤 俊也 様

ユーザーの思いを汲み取り、論理モデルに落とし込む

 システム開発の作業を困難なものにする大きな要因として挙げられるのが、開発側とユーザーの間のコミュニケーションギャップだ。それはシステムの仕様を決める段階から発生しており、「要求仕様」を引き出すことと「要件定義」自体を行うことを混同しているケースも多いと赤氏は指摘する。

 「要求」とはユーザーが情報システムで実現したいことであり、「要件」とは要求を踏まえて情報システムに落とし込むべきもの。開発側としてはどうしても要件定義を急ぎがちだが、まだ要求が明確でない段階で要件定義を進めようとしても歪みが生じ、1 つ1つの機能が無駄に膨らんでしまう。

 要求と要件を整理するためには、最初の上流工程が重要となる。システム開発を川の流れに例えれば、ユーザーが本当にやりたいこと、つまり「要求」が源流であり、そこから流れ出す思いを汲み取って整理し、下流への流れを作るのが上流工程の役割といえる。

 また、赤氏は上流工程について「システムのプロと業務のプロとの間で相互翻訳作業を行う工程」とも表現し、単にシステム屋(開発側)が業務屋(ユーザー)の言葉を翻訳するのではなく、相互に理解し合うことが大事だと強調。その際、「おもてなしの心がとても重要になる、お互いを思いやる気持ちがなければ相互理解は難しい」と述べた。

 さらに、上流工程を「論理モデルを作成する工程」と捉え、上流工程のアウトプット(成果物)は「何を作るか」を明確にした論理モデルであり、それは「下流工程のインプットとして役立たなくては意味がない」とした。

リポジトリによる一元管理で3つのモデルの精度を高める

 続いて赤氏は、上流工程における「翻訳の元ネタ」として使うモデルについて説明。まず、ビジネスの静的側面をデータモデル、動的側面をプロセスモデルで表す。そして、静的側面と動的側面の交点を、CRUDマトリクスで表現する。

 下流工程ではいろいろなモデルを使う必要が出てくるが、上流工程においては、この3 つのモデルの精度を極限まで高めることを赤氏は重視している。それは、最小の管理(成果物)で最高の成果を得るためだ。また、データモデルもプロセスモデルも、「トップダウンで骨組」を作り、「ボトムアップで肉付け」することを原則とすべきだという。

 データモデル、プロセスモデル、CRUD マトリクスを、例えばExcel やVISIO などでそれぞれ作り、手作業でブリッジするという方法で管理することもできないわけではないが、規模が大きくなればなるほど、手作業の管理では無理が生じる。

リポジトリによる一元管理で3つのモデルの精度を高める

 Xupperを活用すれば、これらをリポジトリにて一元管理し、わかりやすい形にまとめることが可能だ。赤氏はその点を、「これだけきちんと一元管理できるツールは、なかなか存在しない。まさにケン・システムコンサルティングの企業コンセプトでもある『究極の生産性と品質向上の追及』を実現してくれるツール」として、高く評価している(図1)。

データモデル作成のポイント

 ビジネスの静的側面を表すデータモデルは、トップダウン中心でリソースモデルを、ボトムアップ中心でイベントモデルを作る。リソースモデルについては、ビジネスルールから作るのが基本だが、データモデルパターンの活用も有効だという。

 例えば、ビジネスルールなどがうまくまとまらない場合に、トップダウンモデリングの一環(代わり)として使用することができる。

 また、データモデルパターンと自社のモデルとの差異に着目し、それが明らかな「強み」なのか、あるいは、慣習など理由不明なもので「改善すべきポイント」なのかを判断するといった使い方も可能だ。

 業務の流れの中で発生するイベントモデルについては、業務フロー(ビジネスフロー)や業務の流れを表す画面イメージから抽出し、項目として落とし込んでいく。

 データモデル作成の留意点として、赤氏は、各エンティティの存在価値が明確になっていること、所属するフィールドの1 つ1 つに対しての「5W2H」が明確であることなどを挙げた。フィールドの" 価値" がきちんと認識されていれば、格納されたデータの価値は増大する。

 ちなみに「5W2H」とは、通常の「5W1H」に「How Many(量)」を加えたものだ。データモデルを現場のユーザーに理解してもらうためには、「目に見えるもの」を提示することも必要だ。

 データモデルを現場のユーザーに見せても、おそらく理解できない。そこで、マスタ登録画面イメージや、フィールド一覧としてのエンティティなどを切り出し、提示して1 つ1 つ確認していくといった地道な作業が求められるのだ。

現場のユーザーを業務フローの世界に巻き込む

 ビジネスの動的な側面を表すプロセスモデルには、Xupperの業務フロー(ビジネスフロー)を使用する。業務フローを使う最大のメリットは、シンプルに「わかりやすさ」だという。

 プロセスモデル作成において赤氏が最重視しているのは、現場の強みを最大限に生かすことだ。それには、現場のユーザーの視点に立って業務を表現すること、そして、その表現を共有することが求められる。

 そこで重要となるのが、ストーリー性だ。設計者は「ストーリーテラー」としてプロセスモデルを作成し、「物語」(ストーリー)を「主人公」であるユーザーと共有する。そうすることによって、ユーザーを業務プロセスの世界に巻き込んでいく(図2)。

現場のユーザーを業務フローの世界に巻き込む

 利用部門の担当者に業務フローを遂行する「主人公」の視点に立ってもらうためには、図(BFD)の内容に引き込む工夫が必要となる。赤氏は、そのコツを2 つ紹介した。

 1 つは、これから共有すべき業務の前提を伝えること。言い換えれば、物語の状況、背景をきちんと理解してもらうことだ。詳細な状況設定をすることで、新業務フローのイメージを具体的に持ってもらえるので、仕様の漏れなども見つかりやすくなる。

 もう1 つは、業務フローの内容を説明する際に、業務の流れを表す線を赤ペンなどでたどりながら話すこと。ユーザーが業務の流れを具体的にイメージできるように、順を追って説明し、一緒に物語(ストーリー)を共有して作り上げていく。

 赤氏は他に留意点として、各プロセスに対して役割を明確に定義しておくこと、データモデル×プロセスモデルの最小粒度をきちんと管理しておくことなどを挙げるとともに、まとめとして「天高く舞う鳥の視点を持ちつつ、地べたを這って泥臭く仕様を固めることを両立しなければならない」とし、セッションを結んだ。


株式会社明治座 様の事例PDFは下記よりダウンロードできます

事例PDFをダウンロードする

日本アイ・ビー・エム株式会社 様

ホストマイグレーションやオフショア開発を支援する「N 字統合開発ソリューション」

 1990年代から担当プロジェクトの9割でXupperを活用し、これまでMDFrame/XやXupperのIPOエディターなどXupper自体の機能拡充にも深く関わってきた日本アイ・ビー・エムの森下氏。同氏は今回、ホストシステムのマイグレーションやオフショア開発において多くのユーザー/ベンダーが直面している課題を解決し得るソリューションとして、Xupper を核とした「N字統合開発ソリューション」を発表した。

日本アイ・ビー・エム株式会社 森下隆治 様

ホスト環境の複雑化とオフショア開発上の課題

 ホストシステムの更改は高額な投資を必要とし、業務に与える影響も大きいことから、容易には行えない。そのため、フロントエンドのみWeb 化を進め、結果的にシステム環境の複雑化・肥大化を招いているケースや、複数の異なるホスト基盤の運用に苦労しながらも、なかなか統合に踏み切れないというケースは多い。

 こうした中で、リスクを考慮した実現性のあるマイグレーションを、より短期間で可能にするソリューションを求める声が増えているという。

 加えて、今日多くの企業が直面しており、今後ますます増えていくと思われるのが、オフショア開発上の課題だ。オフショア開発においては言語や文化の壁を乗り越えなければならないのはもちろんだが、課題はそれだけではない。

 森下氏は、解決すべきポイントとして、設計情報を確実に伝える方法の確立、属人性の排除、オフショア側の作業スコープ検討(コーディングや単体テストだけでなく、基本設計や結合テストも含めたオフショア化でコスト削減効果を高める)などを挙げた。

 そして、森下氏はこれらを含めたシステム開発上の様々な課題とその原因を整理。解決すべき内容を、次のように定めた。

■あるべきソリューションの狙い・目標

 ① システム業務全体像の見える化と要件を決めるベースラインの確立

 ② システム改変による全体への影響分析と変更実現性の評価を可能とする

 ③ マイグレーションによるベースラインの確立と資産の有効活用

 ④ 業務要求について発注側と請負側の双方で共通理解を持つ方法の確立

 ⑤ 成果物の変更による整合性を保証し、設計内容とテスト仕様の不整合をなくす

 ⑥ オフショアで有効な開発方法の確立

 ⑦ 並行開発における設計情報更新の整合化を図る

 ⑧ 機能要件の上流での実現性評価とテスト段階での早期検証

 ⑨ 設計リポジトリとプロジェクト管理上有効なエンジニアリングの活用

 ⑩ 従来型のウォータフォールモデル開発から反復型開発方式へのシフト

マイグレーションにおいて必須の現行保証を上流工程で実現

 これらを具現化したソリューションとして森下氏が提案するのが、従来のV 字モデル(ウォータフォールモデル)にリバースソリューションによる現行分析工程を組み合わせ、ソフトウェアエンジニアリングの手法を取り入れた「N 字統合開発ソリューション」だ。

 ほとんどの場合、ホストマイグレーションにおいては現行機能保証が必須となる。通常のコンバージョンツールを使ったマイグレーションでは、コンバージョン実施後にテスト局面にて現行保証が確定するため、テスト工数の増加や手戻り発生のリスクが大きい。

 N 字統合開発ソリューションでは、従来のV 字モデルにおける設計工程の前段階に、リバースによる現行分析を実施。現行分析情報と設計情報はXupperの設計リポジトリにより一元管理され、上流工程での現行保証が可能となる。

 分析工程では、まず現行プログラムのソースコードをベースに現行設計書にリバースして設計情報を現状最新化し、現行システムの全体像としての、フォワード開発のベースラインを確立する。リバース作業は、2 つのアプローチで行なう。

 1 つはソースコードリバースからプログラム設計レベルのリバースアプローチであり、もう1 つは不完全な現行設計情報のベースをトップダウン観点で整理しながらリバース作業を通じて詳細設計、外部設計、要件定義レベルに仕上げていくアプローチである。

 2 つのアプローチの成果物は、設計リポジトリとしてプロセスモデル、データモデルが整合性の取れた形でXupper リポジトリに実現でき、設計のベースラインを確立することができる。

 最初のリバース作業でのポイントは、移行対象のソースはできる限り棚卸してデッドコードを排除し、規模の最適化を行うこと。特に4GLからの移行では、利用しているマクロ関係を展開すると規模が膨らむため、マクロ変換して畳むなどの開発保守対象規模を抑える工夫が必要である。

 2番目のアプローチでは、全体像を把握するのに必要なプログラム構造分析、ジョブフロー図、判定条件検出などのリバースツールを活用しながら、現行設計ベース情報を設計リポジトリとしてXupper リポジトリに構築する。

 1番目のアプローチでソースリバースしたプログラム仕様(IPO情報)を設計リポジトリにインポートすることで、設計情報とソース情報のトレーサビリティを実現する。

 現行保証は2 段階で実施。まず、移行後のソースレベルで現行比較し、保証されたものをベースに設計に反映する。そして、テストによる現行保証を行う。すなわち、リバースの結果ベースラインとして作成した設計リポジトリにソースとの紐付けを行い、現行ソースの追跡を可能とし、テスト工程での現新比較の精度向上を実現する。

マイグレーションにおいて必須の現行保証を上流工程で実現

 これにより、手戻りリスクを最小限に抑え、かつ現行設計情報・プログラムを最大限活用できるという(図1)。

設計リポジトリによる課題解決とオフショア開発への活用

 課題解決ソリューションとして、Xupper自体の持つメリットは最大限に活かすことができる。要件管理機能では、業務要件とシステム要件の対応、要件と実装との関係などのトレーサビリティを実現し、業務全体の見える化が可能(図2)。

処理機能記述をIPO(入力情報、処理、出力情報)形式で定義するIPO エディターにより、リポジトリ情報を参照しながらIPO 情報を定義することで整合性を保持できる。要件変更によるシステムへの影響調査も、クロスリファレンス機能で設計・ソースレベルまで一貫した分析が可能だ。

 リポジトリを活用した設計作業により、膨大な成果物(設計情報)間の整合性の保証ならびに並行開発における設計情報の整合性も保証できる。

 N 字統合開発ソリューションでは全工程をXupperの設計リポジトリで一元管理することから、リモート開発やオフショア開発との親和性も高い。設計情報からコーディングレスでソースコードを自動生成するツールを取り入れているため、安定した開発品質と生産性を確保できるほか、単体テストの自動化およびテストケース抽出機能とテスト半自動化ソリューションの採用もオフショア開発において有効だ。

設計リポジトリによる課題解決とオフショア開発への活用

 とりわけ、クラウド環境を活用した設計リポジトリのオフショアとのシェアにより、最新情報の提供や、スキル伝達と同時に人材の流動性のリスク対策が可能である点は大きなメリットといえるだろう。

 

日本アイ・ビー・エム株式会社様の事例PDFは下記よりダウンロードできます

事例PDFをダウンロードする