1994年のリリースから18年目を迎えた純国産の上流分析・設計ツールXupper。毎年恒例となる同製品の「ユーザ事例紹介セミナー」（ケン・システムコンサルティング主催）が、2012年11月に開催された。
第16回目となった今回のセミナーでは、まず、プロジェクトマネジメント・コンサルティングの瀬尾惠氏による基調講演「トラブル・プロジェクトの予防と是正」が行われた。
続く事例紹介セッションでは、明治座の赤俊也氏が「鳥の目を持って、地べたを這う」、日本アイ・ビー・エムの森下隆治氏が「プロジェクト・マネジメントにおけるSWエンジニアリング適用の有用性と実践的ソリューションの提言」をテーマに、それぞれ講演を行った。まずはじめに、基調講演の内容をお伝えする。
株式会社プロジェクトマネジメント・コンサルティング 様
医療に学ぶトラブル・プロジェクト対策と整備すべきフレームワーク基調講演には、書籍『トラブル・プロジェクトの予防と是正』（鹿島出版）の著者、瀬尾惠氏が登壇。同書のテーマでもある、医療分野に学ぶべきトラブル・プロジェクトの予防や診断、治療（是正）、それらの前提となるトラブル分類・体系化などを紹介するとともに、プロジェクト・マネジメントを支える社会制度やインフラ、研究・教育基盤などの現状について問題提起した。 |
 |
医療のように強固なフレームワークの整備が急務
病気とトラブル・プロジェクトには、多くの共通点がある。ともに「人」にまつわる事象であり、早期に手を打つほど影響は軽微、また、適切な対策により予防も可能だが、対処（治療）には専門知識と経験が必要だ。
トラブル・プロジェクト対策において、予防・診断・治療といった医療行為に学ぶべき点も少なくないだろう。ただし、医療とプロジェクト・マネジメントを取り巻く環境の" 厚さ" には大きな差がある。
今日、私たちがこれだけ充実した医療を受けられるのは、まず、医療行為を支える社会の仕組みによるところが大きい。
例えば、医師は国家資格であり、医師国家試験への合格および2年以上の臨床研修を受けなければならない。これに対して、プロジェクト・マネジメントの仕事は、まだ多くの企業において資格という概念で扱われず、ロール（役割）として定義されている。
PMP（Project Management Professional）というプロジェクト・マネジャーの公的資格は存在するが、国家資格ではない。
法律についても、医療法、医師法、薬事法、薬剤師法など多数の法律やガイドラインに支えられた医療に対して、プロジェクト・マネジメントに関する法律は存在しない。規律を支えるのは「倫理と行動規範」だけだ。
また、医療は、学門・研究教育基盤としての「医学」にも支えられている。基礎医学では約10 種類の分野、応用医学では50 種類以上の実績を持った分野が確立されており、医学部を有する大学も国内に80 大学ほどある。
一方、プロジェクト・マネジメント学と呼べるものは基礎分野でせいぜい3 ～ 5 種類。多くの論文が発表されているものの、ほとんど応用分野として「分化」していない。基礎研究・教育を行う大学（学科レベル）もごく少数だ。こうしたプロジェクト・マネジメントを支えるフレームワークの整備が急務であることを瀬尾氏は強調した。
トラブル・プロジェクトを114 種類に分類・体系化
|
医療において「予防」は予防医学に基づき、健康増進・疾病予防の第1 次予防、早期発見・早期措置の第2 次予防、リハビリテーションの第3 次予防が定義されている。瀬尾氏は、プロジェクトのトラブル予防をこれに即して説明。 |
 |
それに対して、トラブル・プロジェクトについては類似のトラブルが多発しているにもかかわらず、「病名」が存在しない。適切な診断・是正のためにも、トラブル分類の体系化や用語標準化が望まれるところだ。
そこで瀬尾氏は、「特徴」「分類名（原因）」「組織」「影響度」という4 要素から成るトラブル名称を定義し、「恒常性＜特徴＞リソース不足＜分類名＞プロジェクト＜組織＞（レベルB）＜影響度＞」のように、病名に相当するトラブル名称を体系化した（図1）。
原因分類をトラブルの一般呼称とし、原因は5 カテゴリーに区分。これにより、トラブルは合計114 種類に分類されている。なお、瀬尾氏の著書『トラブル・プロジェクトの予防と是正』では、114 種類それぞれについての徴候や予防法、是正法まで網羅し、紹介されている。
対症療法のみならず根本療法＝再発防止策のプロセスを確立すべき
|
歴史ある医療においても「診断」は困難な行為であり、（調査によって数値は異なるが）約10 ～ 30％の「誤診」が起きている。瀬尾氏の経験上、トラブル・プロジェクト診断の誤診率は、医療よりも圧倒的に高いという。 |
 |
スケジュール遅延に対して「残業でリカバリ」や「人員追加でリカバリ」、コストオーバーに対して「コンティンジェンシー（予備費用）の取り崩し」といった対応は、すべて対症療法だ。
また、治療の根本療法でもよく使われる「医療手術」は、「術前同意」「術前管理」「術前措置」「術後管理」といったプロセスが確立されており、トラブル・プロジェクトにおいても、このような体系化が望まれる。
瀬尾氏は、トラブル・プロジェクトの診断・是正プロセスについても改めて、3 つのプロセスと2 つのゲートを使って整理（図2）。
ポイントとして、是正計画には対症療法のリカバリのみならず、根本療法となる「再発防止策」を組み込むこと、是正措置のガバナンス期間による評価と確認のプロセスにおいて、再発防止策を企業内プロセスへ組み込むことなどを紹介し、講演を終えた。
株式会社プロジェクトマネジメント・コンサルティング 様の基調講演PDFは下記よりダウンロードできます
株式会社明治座 様
「鳥の目を持って、地べたを這う」
|
 |
ユーザーの思いを汲み取り、論理モデルに落とし込む
システム開発の作業を困難なものにする大きな要因として挙げられるのが、開発側とユーザーの間のコミュニケーションギャップだ。それはシステムの仕様を決める段階から発生しており、「要求仕様」を引き出すことと「要件定義」自体を行うことを混同しているケースも多いと赤氏は指摘する。
「要求」とはユーザーが情報システムで実現したいことであり、「要件」とは要求を踏まえて情報システムに落とし込むべきもの。開発側としてはどうしても要件定義を急ぎがちだが、まだ要求が明確でない段階で要件定義を進めようとしても歪みが生じ、1 つ1つの機能が無駄に膨らんでしまう。
要求と要件を整理するためには、最初の上流工程が重要となる。システム開発を川の流れに例えれば、ユーザーが本当にやりたいこと、つまり「要求」が源流であり、そこから流れ出す思いを汲み取って整理し、下流への流れを作るのが上流工程の役割といえる。
また、赤氏は上流工程について「システムのプロと業務のプロとの間で相互翻訳作業を行う工程」とも表現し、単にシステム屋（開発側）が業務屋（ユーザー）の言葉を翻訳するのではなく、相互に理解し合うことが大事だと強調。その際、「おもてなしの心がとても重要になる、お互いを思いやる気持ちがなければ相互理解は難しい」と述べた。
さらに、上流工程を「論理モデルを作成する工程」と捉え、上流工程のアウトプット（成果物）は「何を作るか」を明確にした論理モデルであり、それは「下流工程のインプットとして役立たなくては意味がない」とした。
リポジトリによる一元管理で3つのモデルの精度を高める
|
続いて赤氏は、上流工程における「翻訳の元ネタ」として使うモデルについて説明。まず、ビジネスの静的側面をデータモデル、動的側面をプロセスモデルで表す。そして、静的側面と動的側面の交点を、CRUDマトリクスで表現する。 |
 |
Xupperを活用すれば、これらをリポジトリにて一元管理し、わかりやすい形にまとめることが可能だ。赤氏はその点を、「これだけきちんと一元管理できるツールは、なかなか存在しない。まさにケン・システムコンサルティングの企業コンセプトでもある『究極の生産性と品質向上の追及』を実現してくれるツール」として、高く評価している（図1）。
データモデル作成のポイント
ビジネスの静的側面を表すデータモデルは、トップダウン中心でリソースモデルを、ボトムアップ中心でイベントモデルを作る。リソースモデルについては、ビジネスルールから作るのが基本だが、データモデルパターンの活用も有効だという。
例えば、ビジネスルールなどがうまくまとまらない場合に、トップダウンモデリングの一環（代わり）として使用することができる。
また、データモデルパターンと自社のモデルとの差異に着目し、それが明らかな「強み」なのか、あるいは、慣習など理由不明なもので「改善すべきポイント」なのかを判断するといった使い方も可能だ。
業務の流れの中で発生するイベントモデルについては、業務フロー（ビジネスフロー）や業務の流れを表す画面イメージから抽出し、項目として落とし込んでいく。
データモデル作成の留意点として、赤氏は、各エンティティの存在価値が明確になっていること、所属するフィールドの1 つ1 つに対しての「5W2H」が明確であることなどを挙げた。フィールドの" 価値" がきちんと認識されていれば、格納されたデータの価値は増大する。
ちなみに「5W2H」とは、通常の「5W1H」に「How Many（量）」を加えたものだ。データモデルを現場のユーザーに理解してもらうためには、「目に見えるもの」を提示することも必要だ。
データモデルを現場のユーザーに見せても、おそらく理解できない。そこで、マスタ登録画面イメージや、フィールド一覧としてのエンティティなどを切り出し、提示して1 つ1 つ確認していくといった地道な作業が求められるのだ。
現場のユーザーを業務フローの世界に巻き込む
|
ビジネスの動的な側面を表すプロセスモデルには、Xupperの業務フロー（ビジネスフロー）を使用する。業務フローを使う最大のメリットは、シンプルに「わかりやすさ」だという。 |
 |
利用部門の担当者に業務フローを遂行する「主人公」の視点に立ってもらうためには、図（BFD）の内容に引き込む工夫が必要となる。赤氏は、そのコツを2 つ紹介した。
1 つは、これから共有すべき業務の前提を伝えること。言い換えれば、物語の状況、背景をきちんと理解してもらうことだ。詳細な状況設定をすることで、新業務フローのイメージを具体的に持ってもらえるので、仕様の漏れなども見つかりやすくなる。
もう1 つは、業務フローの内容を説明する際に、業務の流れを表す線を赤ペンなどでたどりながら話すこと。ユーザーが業務の流れを具体的にイメージできるように、順を追って説明し、一緒に物語（ストーリー）を共有して作り上げていく。
赤氏は他に留意点として、各プロセスに対して役割を明確に定義しておくこと、データモデル×プロセスモデルの最小粒度をきちんと管理しておくことなどを挙げるとともに、まとめとして「天高く舞う鳥の視点を持ちつつ、地べたを這って泥臭く仕様を固めることを両立しなければならない」とし、セッションを結んだ。
株式会社明治座 様の事例PDFは下記よりダウンロードできます
日本アイ・ビー・エム株式会社 様
ホストマイグレーションやオフショア開発を支援する「N 字統合開発ソリューション」1990年代から担当プロジェクトの9割でXupperを活用し、これまでMDFrame/XやXupperのIPOエディターなどXupper自体の機能拡充にも深く関わってきた日本アイ・ビー・エムの森下氏。同氏は今回、ホストシステムのマイグレーションやオフショア開発において多くのユーザー/ベンダーが直面している課題を解決し得るソリューションとして、Xupper を核とした「N字統合開発ソリューション」を発表した。 |
 |
ホスト環境の複雑化とオフショア開発上の課題
ホストシステムの更改は高額な投資を必要とし、業務に与える影響も大きいことから、容易には行えない。そのため、フロントエンドのみWeb 化を進め、結果的にシステム環境の複雑化・肥大化を招いているケースや、複数の異なるホスト基盤の運用に苦労しながらも、なかなか統合に踏み切れないというケースは多い。
こうした中で、リスクを考慮した実現性のあるマイグレーションを、より短期間で可能にするソリューションを求める声が増えているという。
加えて、今日多くの企業が直面しており、今後ますます増えていくと思われるのが、オフショア開発上の課題だ。オフショア開発においては言語や文化の壁を乗り越えなければならないのはもちろんだが、課題はそれだけではない。
森下氏は、解決すべきポイントとして、設計情報を確実に伝える方法の確立、属人性の排除、オフショア側の作業スコープ検討（コーディングや単体テストだけでなく、基本設計や結合テストも含めたオフショア化でコスト削減効果を高める）などを挙げた。
そして、森下氏はこれらを含めたシステム開発上の様々な課題とその原因を整理。解決すべき内容を、次のように定めた。
■あるべきソリューションの狙い・目標
① システム業務全体像の見える化と要件を決めるベースラインの確立
② システム改変による全体への影響分析と変更実現性の評価を可能とする
③ マイグレーションによるベースラインの確立と資産の有効活用
④ 業務要求について発注側と請負側の双方で共通理解を持つ方法の確立
⑤ 成果物の変更による整合性を保証し、設計内容とテスト仕様の不整合をなくす
⑥ オフショアで有効な開発方法の確立
⑦ 並行開発における設計情報更新の整合化を図る
⑧ 機能要件の上流での実現性評価とテスト段階での早期検証
⑨ 設計リポジトリとプロジェクト管理上有効なエンジニアリングの活用
⑩ 従来型のウォータフォールモデル開発から反復型開発方式へのシフト
マイグレーションにおいて必須の現行保証を上流工程で実現
これらを具現化したソリューションとして森下氏が提案するのが、従来のV 字モデル（ウォータフォールモデル）にリバースソリューションによる現行分析工程を組み合わせ、ソフトウェアエンジニアリングの手法を取り入れた「N 字統合開発ソリューション」だ。
ほとんどの場合、ホストマイグレーションにおいては現行機能保証が必須となる。通常のコンバージョンツールを使ったマイグレーションでは、コンバージョン実施後にテスト局面にて現行保証が確定するため、テスト工数の増加や手戻り発生のリスクが大きい。
N 字統合開発ソリューションでは、従来のV 字モデルにおける設計工程の前段階に、リバースによる現行分析を実施。現行分析情報と設計情報はXupperの設計リポジトリにより一元管理され、上流工程での現行保証が可能となる。
分析工程では、まず現行プログラムのソースコードをベースに現行設計書にリバースして設計情報を現状最新化し、現行システムの全体像としての、フォワード開発のベースラインを確立する。リバース作業は、2 つのアプローチで行なう。
1 つはソースコードリバースからプログラム設計レベルのリバースアプローチであり、もう1 つは不完全な現行設計情報のベースをトップダウン観点で整理しながらリバース作業を通じて詳細設計、外部設計、要件定義レベルに仕上げていくアプローチである。
2 つのアプローチの成果物は、設計リポジトリとしてプロセスモデル、データモデルが整合性の取れた形でXupper リポジトリに実現でき、設計のベースラインを確立することができる。
|
最初のリバース作業でのポイントは、移行対象のソースはできる限り棚卸してデッドコードを排除し、規模の最適化を行うこと。特に4GLからの移行では、利用しているマクロ関係を展開すると規模が膨らむため、マクロ変換して畳むなどの開発保守対象規模を抑える工夫が必要である。 |
 |
これにより、手戻りリスクを最小限に抑え、かつ現行設計情報・プログラムを最大限活用できるという（図1）。
設計リポジトリによる課題解決とオフショア開発への活用
|
課題解決ソリューションとして、Xupper自体の持つメリットは最大限に活かすことができる。要件管理機能では、業務要件とシステム要件の対応、要件と実装との関係などのトレーサビリティを実現し、業務全体の見える化が可能（図2）。 |
 |
とりわけ、クラウド環境を活用した設計リポジトリのオフショアとのシェアにより、最新情報の提供や、スキル伝達と同時に人材の流動性のリスク対策が可能である点は大きなメリットといえるだろう。
日本アイ・ビー・エム株式会社様の事例PDFは下記よりダウンロードできます