ソフトウェア・シンポジウム 2015 in 和歌山

要件開発プロセスへのPRePモデルの適用

田中 康†

後神 義規††

光井 邦雄††††有限会社ケイプラス・ソリューションズ †東京工業大学 ††株式会社日立製作所 †††クラリオン株式会社†ytanaka@kplus-solutions.com †ytanaka@cs.titech.ac.jp ††yoshinori.goko.yv@hitachi.com †††Kunio̲Mitsui@clarion.co.jp

では，顧客経験価値の視点から業務を見直すことによって，要旨

この超上流工程からシステム要求を考える取り組みを行っ

PReP（プレップ）モデルは，ソフトウェア開発プロセている3）．しかし，現状の業務プロセスのモデル化方法

ス改善のために考案した成果物観点によるプロセスのモ

では，前項で述べた問題に加え，経験価値視点から業務デル化方法である1）．業務システム開発の現場で認識されを見直すために，対象業務の本質的な意味や理由を理解ていた従来方法による業務プロセスモデリングの難しさと，することが難しいという声があった．

業務を超上流から改善する際の有用性の問題に関して，成ビジネスプロセスモデリングの例を図1に示す．図1は，果物観点のプロセスモデルが有効であるとの仮説に基づき，旅行予約プロセスをモデル化したものである4）．プロセ

PRePモデルを業務システム開発の超上流工程に適用した．

スモデルの各ノードは「アクティビティ」または「タスク」

適用結果を，プロセス改善のためのプロセスモデル要件と呼ばれている．

に沿って評価した．また，本手法を適用する際に重要と

確認
航空券を
予約する
航空券が
必要か

1. はじめに

キャンセル

航空券予約
サービス

要求

なる観点に関して，適用経験から報告する．

キャンセル
予約を取り消す確認

大規模なシステムをサービスの集まりとして構築する

ホテルを
予約する

SOA（サービス指向アーキテクチャ）の普及に伴って，業旅程をチェックする

務プロセスのモデリング方法であるBPMN，BPEL，WfMC，

ホテルが
必要か

クレジットカードでの支払いを処理する

キャンセル

顧客に
通知する

ホテル予約
サービス

要求

キャンセル

予約を取り消す
旅程を
受信する

要求
確認
レンタカーを予約する

がOMGに移ってUMLとの統合が図られたことによって，旅程

BPMNでモデリングをしBPELでプロセスを記述してサーレンタカーが必要かキャンセル

レンタカー予約サービス

UMLなどの標準が整備されてきた．特に，BPMNの標準化

キャンセル
予約を取り消す

ビスを動作させ連携させるといった上流工程の流れが整予約上の問題

備されてきている．

通知を
送信する

予約を
取り消す

通知

1.1. 現在の業務プロセスの記述の問題
図1. 旅行予約プロセスの例

その一方で，業務プロセスを記述する際に，「適切な粒度でのプロセスのモデル化が難しい」，「抽象度のレ

このプロセスの例では，旅行の予約業務は，取得したベルが混在してしまう」といった問題や，「どこまで描け

顧客の旅程をチェックし，航空券を予約し，ホテルを予ばすべて描いたことになるのかわからない」といった網

約し，レンタカーを予約するといったタスク（「〜する」

羅性の問題など，モデル化自体の困難さに関する声が現と表現される）の流れとなって定義されている．一見する場から上がっていた．

と順当なプロセスであると思われる．このように，現在の業務プロセスモデルでは，「何をするのか」と，それさらに，「業務プロセスを記述しているつもりがシスに対応するサービスを定義することはできる．

テムの仕様記述になってしまい、業務自体の見直しが難し
かった」，「現状の業務プロセスを描いてはみたものの，

しかし，我々が経験価値の視点から考えたいことは，どこをどのように改善すれば良いかが見えてこない」といっ

何故，「旅程をチェックする」，「航空券を予約する」，

た業務改善における有効性の問題もあがっていた．

「ホテルを予約する」というタスクがプロセスモデルのノードとして表出されたのか，そして，されるべきであったの

1.2. 超上流工程での有用性の問題

か，という「何故」という問いである．

IPA（独立行政法人情報処理推進機構）は，ITシステム

旅行者の目的は，航空券を予約することではない．ホの要件を，経営と業務の視点を含めて定義する過程を「超テルを予約したいから旅行に行くわけではない（そのよ上流」と呼び，その重要性を訴えている2）．日立製作所
162

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

うな旅行者もいるかもしれないが）．多くの旅行者は，であり，プロセス改善の検討や再利用に適しているとして安心して快適に旅行に出発したいのである．面倒な航空いる6)．

券やホテルの予約などはできれば避けたい．旅行者が望また，プロセスをモデル化する観点からの分類として，むことは，例えば，「これからはじまる旅行を，ワクワ

タスク観点と成果物観点の区分けがある7）．作業行為にクした気持ちでシミュレーションしたい」かもしれない

着目してプロセスをモデル化する方法がタスク観点であり，し（その過程を通して，いつの間にか必要な予約ができて作業成果物（以下「成果物」）の関係に着目してモデルいるといった方法も十分考えられる），人によっては，化する方法が成果物観点である．UniversalとAtomicレベ「旅行先で待ち受ける未知の体験を大切にしたいので，

ルのプロセスのモデル化方法は主にタスク観点によるモデ

泊まるホテルの情報はあまり知りたくない」といったよル化が取られており，Worldlyレベルのモデル化は，成果

うなドキドキ感を期待する人もいるかもしれない．

物観点によるモデル化が有効であるとされている6)．プロ

我々が行いたいことは，顧客の経験価値を最大化する

セスモデルの抽象度とモデル化の観点を表1に整理する．

プロセスを設計することである．旅行者が旅行の準備をす

表1. プロセスモデルの抽象度による分類る過程で，「旅行者にとって，何が嬉しいのか」，「それ抽象度が，どのように嬉しいのか」，「それは何故なのか」といった問いを，旅行者の視点から分析・理解しながら業
務プロセスを設計したい．そのために，「要するに旅行の予約をするということはどういうことなのか」という本質を理解したい．しかし，現状の業務プロセスのモデ

モデルの利用モデル化方法Universal

プロセス概念の理解

タスク観点

Worldly

実際の開発活動の理解・改善・管理・再利用

成果物観点

Atomic

特定の作業手順の記述

タスク観点

ル化方法では，そもそも，何故そのようなプロセスになっ現状の業務プロセスのモデル化方法は，主にタスク観ているのかといった，本質的な意味や理由を理解するこ

点によるモデル化方法がとられている．そのために，モとが難しという声があった．

デル化されたプロセスは概念のレベル（Universal）か，
もしくは，特定の作業手順の記述のレベル（Atomic）と1.3. 現状の業務プロセスモデルの問題の原因仮説なる．「適切な粒度でのプロセスのモデル化が難しい」，

確かに，現行の方法は，業務プロセスモデルからサー「抽象度のレベルが混在してしまう」といった問題は，ビスを定義・特定し，業務を支援するシステムとその連携

現行のプロセスモデルがタスク観点によるモデル化を行っを定義するには有効であると考える．しかし，前項で述ているために，概念レベルと作業手順のレベルとが混在

べた下記の3項目の問題は，どこから来るのだろうかしてしまうのではないかと考えられる．

1) モデル化自体の困難さの問題

例えば，図1に示した旅行予約プロセスにおいても，

2) 業務改善のための有効性の問題「旅程をチェックする」が，概念のレベル，つまり，旅3) 業務プロセスの本質的な意味・理由の理解の困難

程をチェックするという行為のレベルともとれるし，具体的な作業，つまり，旅程をチェックするという作業のさの問題レベルとも解釈できる．現在の業務プロセスのモデル化

プロセスモデルの分類にはいつかの観点がある．1990

方法は，タスク観点によるモデル化方法がとられているた年に開催された第6回ソフトウェアプロセスワークショッ

め，目的と手段の混在や，抽象度や粒度の定義の困難さ

プ（6th ISPW）では，記述モデルの主な目的，記述表現，が生じ，モデル化自体の困難さの問題の原因となってい記述要素，動作制御の方法，そして基礎となる言語によるのではないかと仮説する．

る分類等によって，18種類のプロセスモデルが比較検討

また，Humphrey らは，プロセスのモデル化はプロセ

された5）．その結果，Humphreyらは，プロセスモデル

ス改善のための重要な要素であり，プロセス改善のためを，表1に示すような抽象度によって，「Universal」，のプロセスモデルは次に示す目的のもとに使用されるとし「Worldly」，「Atomic」の3 段階に分類・定義できるとている8）．

した6)．

• プロセスに関する効果的なコミュニケーションの実現• プロセス改善の支援• プロセスの管理

Universalはプロセスの概念を提供する抽象度の高いレベルであり，プロセスを目的的に概観するために有効である．Universalとは逆に，抽象度が低く特定の作業手順をモデル化するレベルがAtomicである．Universal レベル

さらにHumphrey らは，上記3項目を実現可能とするとAtomicレベルとの間の抽象度で，実際の開発活動をモ

プロセスモデルの要件として下記の3 項目を定義し，これデル化するレベルがWorldlyレベルである．Worldlyレベらの要件を満足するためには，Worldlyレベルでのプロセ

ルは，実際に行われている活動の実体をモデル化するもの

スのモデル化が有効であるとしている6）, 8)．
163

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

1) 現実に行われている，または行われるべき活動をモデル化できること
2) プロセスのモデル化と改善を行うために十分であるとともに柔軟で理解が容易であること
3) 必要とする粒度でのプロセスの洗練が可能である
こと

おり，分野によって解釈が異なる．現状の業務プロセスが固定されない）．「◯◯帳票」といった物理的な実体ではなく，意味的なまとまりを定義する（そのため，物理的なひとつの帳票は複数の成果物として定義される場合もある）．
• プロセスモデルを構成する成果物を「定義する業
務プロセスにおいて，共有されかつ管理されているもの」のみとして定義• 成果物を，プロセスの品質目標を管理する視点か
ら「中間成果物」と「マイルストン成果物」に分類
し，外部プロセスへ引き渡される成果物を「最終成果物」として定義• 成果物は状態を持つ．例えば，「申込書」という成果物に関して，「受け付けられた」と「確認された」といった状態に対応して，２つの異なる成果物として定義するモデルでは，主にタスク観点がとられている．その理由と

2）成果物の関係の定義方法

しては，例えば，システム開発の分野では，「時系列に並• 成果物間の関係を，「入力関係」と「同期関係」の2種類で表現

すなわち，業務プロセスの本質的な意味や理由を顧客の視点から理解・分析し，利害関係者間で効果的なコミュ
ニケーションをとりながら，顧客の経験価値を最大化す
るプロセスを設計するためには，Worldlyレベル，すなわ
ち，成果物観点によるプロセスのモデル化方法が有効であるとの仮説を立てた．
ところで，「プロセス」という語彙は曖昧性を含んでんだイベントの集まり」が一般的に「プロセス」として定義されており 9） ，逐次的な処理として業務の場合の3）Backwardに検証する「タスク」や「アクティビティー」が想起されるためでは• 描いたプロセスの検証を行う場合，後ろから前方向に，成果物の関係を逆方向に辿る

ないかと思われる．一方で，プロセス改善の分野では，
例えばCMM の場合，「プロセス」は「一連の活動，手法，

2.2. 業務プロセスのモデル化のための拡張

プラクティス，変換」と定義されている10）．ある目的を持った一連の活動であり，必ずしも手順やフローとして

PRePモデルを業務プロセスモデルへ適用するために，記述されるものではない．

次項に示す拡張を行った．
2.2.1. 基本フレームの定義

2. PRePモデルの業務プロセスへの適用

業務プロセスのモデル化を行うために，新たに「業務PRePモデルは，Worldlyレベルでのプロセスのモデル

スコープ」，「業務ゴール」，「最終成果物」，「サブ化方法として，ソフトウェア開発プロセス改善のために考プロセス」の概念を追加し，図2に示す業務プロセスの基案した成果物観点のプロセスのモデル化方法である．

本フレームを定義した．

Worldly レベルの抽象度のモデルを提供することによって，業務スコーププロセスの改善や，ソフトウェアとハードウェアの協調開業務ゴール

発プロセス設計のために考案した方法である1)．

外部プロセス（入力）

Actor

サブプロセス

サブプロセス

外部プロセス（出力）

前節の仮説を検証するために，ソフトウェアプロセス
改善のために開発した成果物観点によるプロセスのモデ

責務
インサイト

ル化方法を，実際の業務プロセス開発へ適用した．さら中間成果物

マイルストン
成果物

同期関係に，業務プロセスへ適用する際に重要であった観点に関し
入力関係て適用経験から報告する．
責務
インサイト

2.1. PRePモデルの特徴

最終成果物

図2. 業務プロセスの基本フレーム

成果物観点によるプロセスモデルは，何を成果物としまた，基本フレームは，以下の関係を有するものとして定義するかがモデリング時の主要な観点となる．成果物て定義した．

の定義を含め，PRePモデルは主に次の特徴を持つ．

• 業務プロセスは，経営視点から定義される業務の目的（ゴール）を持つ• 業務プロセスのスコープは，最終成果物によって定義される• 最終成果物は，その成果物が利用される外部プロ
セスによって意味が定義される• 最終成果物は，業務の目的と一貫した対応を持つ

1）成果物の定義方法• 「プロセスの目的から見た意味的なチャンク」を成果物ノードとしてPRePモデルでは「成果物」と呼ぶことにする（「チャンク」とは，人が情報を理解・認識する際の情報のまとまりであり，単位

164

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

上記の定義から，業務プロセスのスコープ定義が確定

ソースモデルを適宜理解し，モデルを検証・精緻化していくされる．すなわち，業務プロセスは，経営視点から見た
関連する外部プロセスとの関係の上で，最終成果物を媒介

4）業務間の関係の理解としてそのスコープと目的的意味（経営的視点から見た業• 業務全体の関係を，業務間の入出力となっている
成果物をたどりながら，その繋がりを検証する務の意味）が定義される．そして，業務プロセスのゴールと品質目標が定義される．

5）問題の把握と原因の特定• まずはじめに，業務上のQCDの問題が現象している成果物を特定する• 問題は，原因によって引き起こされる．原因となっている成果物は，問題が現象している成果物の入力側にある場合が多い．PRePモデルでは，問題が現象している成果物に対して，その入力側の成果物と同期している成果物の関係から理解することによって，原因を特定する• 原因となっている成果物に着目し，担当アクターの責務やインサイトなどを考慮しながら本質的な問
題を特定していく

2.2.2. 業務プロセス管理のための構造の定義
さらに，上記で定義される業務プロセスのゴールと品質目標を実現・管理するために，個々の業務プロセスは，
以下のプロセス管理構造を持つとした．
• 業務プロセスのゴールと品質目標を実現・管理するための管理ゲートのための成果物として，業務プロセスにはマイルストーン成果物が定義される• マイルストーンで区切られる一連のプロセスは，
業務プロセスのゴールと品質目標を実現・管理するという目的で認識される．これを「サブプロセス」と定義する

6）ボトルネックの特定• 各業務の問題構造とその原因の関係理解ができた
ら，モデル化された業務全体を俯瞰し，スコープとなっている業務全体の中で，一番の障害の根本原因とその理由を理解する

2.2.3. 経験価値視点による分析要素の追加
また，アクターに「責務」属性と「インサイト」属性を追加した．インサイトとは，アクターの本音であり，例
えば，アクターの責務が業務上では「適正数量を発注する

2.4. PRePモデルを用いた改善プロセスの設計こと」と定義されるも，本音の部分では，「欠品になったら大変なので適正量よりも多めに注文しておこう」とプロセスの改善，すなわちTo-beプロセスの設計は，動いてしまうようなことである．このようなインサイト

As-isプロセス全体の中の最大のボトルネックに着目して，は，業務リスクを分析する上で重要な観点になることが，それを解消することに集中して改善方法を考える．その場

今回の適用事例でも確認された．

合，適用技術制約やリソース制約の見直しなども考慮する．
リソース制約の見直しでは，アクターの責務の見直しも含2.3. PRePによる現状プロセスの分析方法

め，組織レベルの再構築も考慮する必要もある．

PRePモデルを用いて現状（As-is）のプロセスをモデル

2.5. 業務プロセスモデルからシステム要求へ化し分析する場合，基本的に以下の考えかたと順番とな

PRePモデルでは，個々の成果物を「プロセスの目的かる．ただし，実際の作業は反復的に進められる．

ら見た意味的チャンク」として定義している．そのため，

1）対象業務ドメインの理解

個々の成果物ノードは，業務を記述する際の適切な概念• プロセスをモデル化する対象の業務スコープを，登場する組織，アクター，大枠の業務概念と業務間でやり取りされる（インタフェースとなっている）成
果物をもって把握するの単位となっていると考えられる．例えば，PRePモデル
では，「申込書」という帳票実体を経営視点から見た業務の意味チャンクとして再定義する．その結果，「申込書」
は，業務の意味からとらえると「申込者情報の取得」と

2）業務フレームの理解「申し込み証票の取得」の目的に分解された別々の成果• モデル化対象業務の枠組みを理解するために，最終成果物に着目し，最終成果物が関連する外部プ
ロセス，最終成果物と業務プロセスのゴール，当該業務のアクターとその責務を把握する物として定義され，それぞれが業務機能と対応する場合がある．「申込書」という帳票は，2つの機能を実装するために考えられた実体，すなわち設計の結果である（一般的な業務プロセスモデリングでは「申し込みをする」と

3）業務構造の理解

一つのタスクとして定義されてしまう場合が多い）．この• 当該業務プロセスを，業務の品質管理のゲートとなっているマイルストーン成果物に着目しながら入力関係と同期関係の構造によって理解していく• また，何故そのような業務構造になっているか，マイルストーン成果物および最終成果物から関係を逆方向に辿りながら，その理由を，技術モデルとリように定義された意味的チャンクとしてのPRePの「成果物」は，データモデリングでのひとつのエンティティーを業務観点から定義する際の主要な観点になると考えられ
る．

165

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

PRePモデルの業務プロセスモデル拡張で定義した，業在庫異常で生産・輸送計画を変更する

Goal

ID: 05-02

務，サブプロセス，成果物という構造は，それぞれ，業

更新日: 2015/02/19

In

務の目的と品質，業務目的と品質実現のための業務のリ

1

機種別の在庫異常値に対して、適切な是正処置を講じる

2

エア予算内で対応策を講じる要素に対応する．この構造に合わせて業務を支援するITシ

㻿㻯㻼㻸㻭㻺

㻞

㻭㻿㻠㻜㻜

㻟

㻳㻙㻼㻿㻵照会・シミュレーションｼｽﾃﾑ

4

G-PSIモニタリングｼｽﾃﾑ

5

5

手作業

Actor

在庫異常に対する対応策の検討と販社との合意（製品、工場時間、調整された生産計画）変更により自分の責任ではないのに他部門から苦情がでる

機種別輸送手段調整案

生産工場 生産管理

生産計画変更連絡書

リスク★☆☆
シミュレーションで効果が出（会社CD、機種、在庫日数、在 せない
庫数、日程、調整手段、エア費
用予算進捗率）

輸送手段対応策シミュレー
ション

工場の生産調整ID：

承認された（会社CD、機種、ロット＃、調整手段（中止、追加、繰上げ、繰
リスク下げ（赤紙））） ★★☆
追加繰上げ時、変更計画に対して部品納期が追従できない
輸送手段変更連絡書

納期回答（輸送手段変更
後）
GHQの承認が得られた

工場内で確認された（製品、在庫場所、輸送先、輸送手段、輸送数）

役割：
機種別の在庫異常値に対して、エア費用の軽減を考慮した
適切な是正処置を講じる

Out

輸送手段変更の承認

生産計画対応シミュレーシ
ョン

日次で生産状況をモニタリングする
ID：05-01

ステムへの要求を整理することによって，ITシステムの支㻝

4

機種別生産計画調整案

スク管理ゲート，業務を実行管理するための意味的概念

System3（会社CD、機種、在庫日数、在庫数、日程、調整手段、エア費
用予算進捗率）
リスク★☆☆
シミュレーションで効果が出せない（会社CD、機種、台数、ロット＃、工場出荷日、輸送手段）（機種、ロット＃、数量、日程、
エア費用、エア費用負担部門、
エア予算進捗率）
リスク★☆☆
エア費用予算を超過してしまう

輸送手段変更連絡書

リスク★★☆
目先の対応で先手の対応に手がまわらない

GHQの承認が得られた（機種、ロット＃、数量、日程、
エア費用、エア費用負担部門、
エア予算進捗率）

援目的，業務リスク管理目的，業務実行管理目的といっ間にあわせてくれれば文句ないた構成でITシステムへの要求を整理することができ，支援

出荷対応
ID：06-01

リスク★☆☆
入力データがきちんと更新
されない

販社営業

する業務との対応が取りやすくなると考えた．

日次で生産状況をモニタリングする
ID：05-01

役割：
GPSIを確認して対応策の妥当性を判断し合意する

グローバルPSI計画

リスク★☆☆
時差の影響で、緊急時の連絡がとれない（【工場出荷から販社販売まで】
会社CD、機種、日付、入庫数、販売数、在庫数、受注＃（カーメーカーからの注文＃）、PO＃（販社から工場の注文）、得意先、倉庫＃、ロット＃（MO）、仕入先、原価、【工場の部品入庫
から製品出荷まで】会社CD、品
目番号、日付、入庫数、出庫数、在庫数、PO＃、仕入先、MO＃、倉庫、原価）

輸送手段変更確認・合意

毎日更新された（機種、ロット＃、生産日程、調
整台数、調整手段、費用負担
部署、エア費用、エア費用予算
進捗率）

輸送手段変更連絡書
エア費用予算計画
承認された

供給、納期を順守する
年次予算策定ためにはエアを使わざ
ID：
るを得ない

2.6. ワークショップ形式による業務プロセスの改善（機種、ロット＃、数量、日程、
エア費用、エア費用負担部門、
エア予算進捗率）（会社CD、予算エア代、実績エア代、日付、仕向）

GHQ
役割：
輸送手段の変更が適切かどうかを判断して承認する

筆者らは，超上流工程を進めるための前提条件として下記を定義している3）．

図3. PRePモデルツールでのプロセスモデル画面の例• ユーザ企業内のステークホルダによって，ビジネ
ス要求とシステム要件とが並行に開発されていること• ビジネス要求とシステム要件とが，各ステークホ
ルダによって自発的に合意され，ユーザ企業の意
思決定を構成するものになっていること．すなわ
ち，システム要件のレビュープロセスが，企業内での経営的意思決定プロセスと連携して実行されていること• ビジネス要求とシステム要件の記述内容が，抽象的なレベルではなく，判断・行動の指針となる具体的なレベルで記載されていること

05-01
2015/02/19

項番

1
1-1

項目

要件項番

機能目的 販売計画の最新情報でG-PSIデータを日次更新する
前日に更新されたグローバルPSI計画の取得
外部機能 ★☆☆ 入力データがきちんと更新されない
in

日次で生産状況をモニタリングする

out

グローバルPSI計画：前日に更新された

in

in
in
in

out

機能要件
機能要件
機能要件
機能要件
機能要件
操作要件
操作要件
操作要件
操作要件
操作要件
1-3

外部機能
in
in
in
out
機能要件
機能要件
機能要件
機能要件
機能要件
操作要件
操作要件
操作要件
操作要件
操作要件

上記条件を満足するためには，業務プロセスの改善とGHQ（新設部門）

中間

○

○
○
○
○
○
○
○
○
○
○

GHQ（新設部門）○

G-PSIデータ更新日時、【工場出荷から販社販売まで】会社CD、機種、日付、入庫数、販売数、在庫数、受注＃（カーメーカーからの注文＃）、PO＃（販社
から工場の注文）、得意先、倉庫＃、ロット＃（MO）、仕入先、原価、【工場の部品入庫から製品出荷まで】会社CD、品目番号、日付、入庫数、出庫数、在庫数、PO＃、仕入先、MO＃、倉庫、原価、機種毎のロットまとめ最小数（MOQ）、機種毎のロットまとめ数（SNP:MOQを越えた後の刻み数）
販社CD、注文＃、機種、台数、出荷日、バケット、仕向（得意先）、販売単価、販売計画（日単位）：27週分のうち、手前の3カ月分が販社終業時間で毎週更新された（N-1日）
中間
販売輸送手段、更新日
在庫数（販社・本社・直販）：販社終業時間で毎日更新されている（N-1日）
中間
販社CD、倉庫CD、機種CD、在庫数、仕向、更新日
発注情報：毎日更新されている（N-1日）
中間
販社CD、発注＃、機種、発注数量、納期日、輸送手段、発注先
G-PSIデータ更新日時、【工場出荷から販社販売まで】会社CD、機種、日付、入庫数、販売数、在庫数、受注＃（カーメーカーからの注文＃）、PO＃（販社
から工場の注文）、得意先、倉庫＃、ロット＃（MO）、仕入先、原価、【工場のグローバルPSI計画：日次で販売情報が更新された（N-1日）
マイルストン
部品入庫から製品出荷まで】会社CD、品目番号、日付、入庫数、出庫数、在庫数、PO＃、仕入先、MO＃、倉庫、原価、機種毎のロットまとめ最小数（MOQ）、機種毎のロットまとめ数（SNP:MOQを越えた後の刻み数）
1 地域（欧州、米州、アジア）ごとに設定した時間で集約したデータを〆て更新する
2 データを移動処理する
3 読み取るデータが無かった場合は最後に受け取ったデータで更新する
4
5
1 データの更新状況が分かる（入力データがきちんと更新されているかが工場ごとに判断できる）こと
2345
販売計画を取得する★★☆ 控えめな販売計画になりうる。緊急出荷の割合が GHQ（新設部門）
増えるリスクがある
販社受発注・在庫管理業務
本社受発注・在庫管理業務
直販受注・在庫管理業務
販社CD、注文＃、機種、台数、出荷日、バケット、仕向（得意先）、販売単価、販売計画（日単位）：27週分のうち、手前の3カ月分が販社終業時間で毎週更新された（N-1日）
中間
販売輸送手段、更新日
1
2
3
4
5
1
2
3
4
5
在庫数（販社・本社・直販）取得
GHQ（新設部門）グローバルPSI計画：前日に更新された

中間

外部機能

1-5

販社受発注・在庫管理業務
in本社受発注・在庫管理業務
in直販受注・在庫管理業務
in
在庫数（販社・本社・直販）：販社終業時間で毎日更新されている（N-1日）
out
中間
販社CD、倉庫CD、機種CD、在庫数、仕向、更新日
機能要件
1
機能要件
2
機能要件
3
機能要件
4
機能要件
5
操作要件
1
操作要件
2
操作要件
3
操作要件
4
操作要件
5
輸送在庫数を取得する
GHQ（新設部門）
外部機能
出荷対応
in
積送在庫数：毎日更新されている（N-1）
out
機能要件
1

として進めることが有効であると考えている．

○

G-PSIデータ更新日時、【工場出荷から販社販売まで】会社CD、機種、日付、入庫数、販売数、在庫数、受注＃（カーメーカーからの注文＃）、PO＃（販社
から工場の注文）、得意先、倉庫＃、ロット＃（MO）、仕入先、原価、【工場の部品入庫から製品出荷まで】会社CD、品目番号、日付、入庫数、出庫数、在庫数、PO＃、仕入先、MO＃、倉庫、原価、機種毎のロットまとめ最小数（MOQ）、機種毎のロットまとめ数（SNP:MOQを越えた後の刻み数）

1-4

システム要求定義を，業務側と情報システム側両者のステー
クホルダ参加によるワークショップ形式による共同作業

パラメータ

是正処置につなげるために各機種の在庫異常を検出する

機能要件
機能要件
機能要件
機能要件
機能要件
操作要件
操作要件
操作要件
操作要件
操作要件
1-2

1
2
3
4
5
1
2
3
4
5
グローバルPSI計画の日時更新機能
外部機能 ★☆☆ 入力データがきちんと更新されない

属性

手作業

システム機能スコープ・要件定義

AS400

各機種の在庫異常を検出し、是正処置につなげる。

G-PSIモニタリングｼｽﾃﾑ

システム

日次で生産状況をモニタリングする

SCPLANID
更新日
Process
Goal 1
Goal 2
Goal 3
Goal 4
Goal 5G-PSI照会・シミュレーションｼｽﾃﾑ

システム機能スコープ定義書 ©2014 K-plus solutions Co., Ltd.

中間b) To-be 05G-PSI日次生産状況モニタ_20150308

インボイス、B/L、PACKING

○

○
○
○

○

○
○
○
○
○
○
○
○
○
○
○

○
○
○
○
○
○
○
○
○
○
○
○

○
○
○
○
○
○
○
○
○
○
○
○
○
○

1/3

図4. PRePによる業務プロセスモデルからExcel形式で出力されたシステムスコープ・要求定義書画面の例

3. PRePモデル ツール
業務プロセス改善のための初期の探索的なモデル化作

4. グローバルPSIシステム構築への適用

業から，To-beの具体的な業務とシステムの要求を詳細に定義するまで，モデルを洗練させ成長させていく必要があ

クラリオンは，主に車載機器を中心に，日本，アジア，

る．そのための一貫した手段を提供するために支援ツー

欧州，北中南米とグローバルな販売，生産，流通の拠点

ルを開発した．

を持つ．今回のPSI 業務とシステムの改善では，これまで

本ツールは，Microsoft社のVisio 2013のAdd-inツール

それぞれの地域で行われてきたPSI業務を，グローバルなとして開発し，ワークショップ形式による業務プロセスの観点から全体最適化し，経営目標として定めた在庫回転モデル化作業を支援するとともに，定義した業務プロセ

率を達成しようというプロジェクト「グローバルPSIプロ

スモデル上でシステムスコープ定義と要求の整理を行うこ

ジェクト」である．

とができる．そして，最終的にシステムスコープ・要求書

PRePモデルをグローバルPSIプロジェクトに適用すると業務定義書とをExcel形式で出力することができる．図3

にあたって，前節で述べた「超上流工程を進めるための前にプロセスモデル画面，図4に，Excel形式で出力されたシ提条件」に従って下記を考慮した．

ステムスコープ・要求定義書の代表的な画面を示す．

1）ユーザ企業内の有識者に参画してもらうこと：現
在の業務とシステムを意味的に理解しているメンバであり，定義した業務とシステムの要件の実装時のリー
ダーレベルのメンバを「有識者メンバ」として参画してもらうことを条件とした

166

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

また，PRePモデルの本事例への適用を通して下記が行

2）ビジネス要求とシステム要求とを並行に開発する
こと：業務有識者とシステム有識者が一緒になってワー
クショップを進めることを条件とした
3）超上流工程が，企業内での経営的意思決定プロセ
スと連携すること：適切なタイミングで，本テーマのステークホルダのレビュープロセスを組み込むとともに，経営的判断が必要となる局面（業務とシステ
ムのあるべき姿の方向性の判断）においては，経営
ステアリングコミッティの合意形成プロセスを組み込んだ4）ビジネス要求とシステム要件の記述内容を，業務とシステムの実装がイメージできる具体的なレベルで定義すること：業務改革プロジェクトとシステム
構築プロジェクトへのスムーズな引き継ぎを実現するえることと，その効果を検証した．
• 業務プロセスの改善課題の特定ができること• 改善課題を解決するための業務プロセスと業務機能の設計（業務改革への入力となる）• 業務プロセスから出力されるシステム要求定義の有用性（システム構築への入力となる）

4.1. 実際の適用過程
今回のプロジェクトは表2および図7に示すように進んだ．本プロジェクトに適用した超上流工程の基本プロセス
は，現状の業務プロセスを外在化し理解するというリバー
スエンジニアリングの過程と，定義した改善課題を解決するための業務プロセスを設計し，ITシステムの要件を定義するデザインの過程からなる「逆Vモデル」3）を基にした．

写真1. As-is業務の理解ワークショップ

写真2. PRePモデルツール利用

To-be主要構造

日単位の生産計画を確定注文に応じて見直す
ID: 05
更新日: 2015/02/19

Goal

1

各機種の在庫異常を検出し、是正処置につなげる。

2

機種別の在庫異常値に対して、適切な是正処置を講じる

3

エア費用を軽減するように対応策を講じる

1

System4
5

写真3. ボトルネッックの分析

SCPLAN

2

AS400

3

G-PSI照会・シミュレーションｼｽﾃﾑ

4

G-PSIモニタリングｼｽﾃﾑ

5

手作業

在庫異常で生産・輸送計画を変更する

In
Goal

ID: 05-02

グローバルPSI計画
更新日: 2015/02/19

1

機種別の在庫異常値に対して、適切な是正処置を講じる

2

エア予算内で対応策を講じる

1

System3

4

前日に更新された日次で生産状況をモニタリングする
ID：05-01

In

5

Goal

ID: 05-02

本社受発注・在庫管理業務
ID：直販受注・在庫管
理業務
ID：

In

エア予算内で対応策を講じる

Actor（製品、工場時間、調整された生産計画）変更により自分の責任 在庫数（販社・本社・直販）ではないのに他部門から苦情がでる

機種別輸送手段調整案
販社終業時間で毎日更新されている（N-1日）
生産工場 生産管
日次で生産状況を理
モニタリングする（製品、在庫場所、輸送先、輸
役割：
積送在庫数
ID：05-01

機種別の在庫異常値に対して、エア費用の軽減を考慮した
毎日更新されている

適切な是正処置を講じる

機種別工場完成品在庫数間にあわせてくれれば文句ない

送手段、輸送数）

変更により自分の責任ではないのに他部門から苦情がでる

リスク★★☆
目先の対応で先手の対応に手がまわらない
毎日更新されている（N-1）

製造指図書

生産計画を立てる
ID：04-01

機種別の在庫異常値に対して、適切な是正処置を講じる

2

4

日次で生産状況をモニタリングする
ID：05-01

生産工場 生産管理

役割：
機種別の在庫異常値に対して、エア費用の軽減を考慮した
リスク★☆☆
適切な是正処置を講
入力データがきちんと更新
じる
されない

生産日が設定された（N-1）
納期回答（製造指図の日程を変更しないで出荷日程を
販社営業
役割： 変更する場合）

在庫異常に対する対応策の検討と販社との合意

1

日次で生産状況をモニタリングする3
ID：05-01

27週分のうち、手前の3カ月分が販社終業時間で毎週更新された（N-1日）
機種別生産計画調整案5

出荷対応
ID：06-01

完成品倉庫管理ID：

AS400
G-PSI照会・シミュレーションｼｽﾃﾑ

4

G-PSIモニタリングｼｽﾃﾑ

5

手作業

在庫異常で生産・輸送計画を変更する

Actor
販売計画（日単位）
更新日: 2015/02/19

販社受発注・在庫
管理業務
ID：

Out

SCPLAN

2
3

リスク
★★☆
目先の対応で先手の対応に手がまわらない
グローバルPSI計画

輸送手段変更の承認

SystemグローバルPSI計画

4
ID：03-01,02,03
5生産計画変更連絡書

リスク★☆☆
シミュレーションで効果が出承認された
在庫異常に対する対応（会社CD、機種、在庫日数、在 せない（会社CD、機種、ロット＃、調整策の検討と販社との合意
庫数、日程、調整手段、エア費
手段（中止、追加、繰上げ、繰
用予算進捗率）
リスク下げ（赤紙））） ★★☆
追加繰上げ時、変更計画に対して部品納期が追従でき
輸送手段対応策シミュレー
生産計画対応シミュレーシ
ない
輸送手段変更連絡書

機種別生産計画調整案
ション

承認された
（会社CD、機種、ロット＃、調整手段（中止、追加、繰上げ、繰
リスク下げ（赤紙））） ★★☆
追加繰上げ時、変更計画に対して部品納期が追従できない
輸送手段変更連絡書

工場内で確認された（製品、在庫場所、輸送先、輸送手段、輸送数）（会社CD、機種、在庫日数、在庫数、日程、調整手段、エア費
用予算進捗率）
リスク★☆☆
シミュレーションで効果が出
せない

合意する

毎日更新された

G-PSIモニタリングｼｽﾃﾑ
手作業
工場の生産調整Out

日次で生産状況をモニタリングする
ID：05-01

工場の生産調整ID：

後）（機種、ロット＃、数量、日程、
エア費用、エア費用負担部門、
エア予算進捗率）

GHQの承認が得られた（会社CD、機種、台数、ロット＃、工場出荷日、輸送手段）

納期回答（輸送手段変更
後）

輸送手段変更連絡書

GHQの承認が得られた（機種、ロット＃、数量、日程、
エア費用、エア費用負担部門、
エア予算進捗率）

GHQの承認が得られた
出荷対応（会社CD、機種、台数、ロット
ID：06-01＃、工場出荷日、輸送手段）

日次で生産状況をモニタリングする
ID：05-01

納期回答（輸送手段変更
リスク
★☆☆
後）
エア費用予算を超過してしまう

輸送手段変更連絡書

GHQの承認が得られた
輸送手段変更確認・合意

GHQの承認が得られた（機種、ロット＃、数量、日程、
エア費用、エア費用負担部門、
エア予算進捗率）

GPSIを確認して対応策の妥当性を判断し毎日更新されている（0週～2週間分）（N-1）

年次予算策定ID：

AS400
G-PSI照会・シミュレーションｼｽﾃﾑ

日次で生産状況をモニタリングする納期回答（輸送手段変更
ID：05-01

生産計画変更連絡書★☆☆

シミュレーションで効果が出
工場内で確認された

せない（会社CD、機種、在庫日数、在（機種、ロット＃、数量、日程、（製品、工場時間、調整された（会社CD、機種、在庫日数、在機種別生産計画調整指示
庫数、日程、調整手段、エア費
エア費用、エア費用負担部門、生産計画）
庫数、日程、調整手段、エア費
用予算進捗率）
エア予算進捗率）
用予算進捗率）
リスク★☆☆
シミュレーションで効果が出
リスク
★☆☆
せない
機種別輸送手段調整指示
輸送手段対応策シミュレー
エア費用予算を超過してし機種別輸送手段調整案
ション
まう

Out

SCPLAN

輸送手段変更の承認
ID：

ョン

リスク

1

2
グローバルPSI計
画の策定3

日次で生産計画が更新された（N-1日）

生産計画対応シミュレーシ
ョン

在庫異常で生産・輸送計画を変更する（【工場出荷から販社販売まで】リスク（機種、ロット＃、生産日程、調リスク★☆☆ 間にあわせてくれれば★☆☆
ID：05-02
会社CD、機種、日付、入庫数、整台数、調整手段、費用負担
時差の影響で、緊急時の連 文句ない
入力データがきちんと更新
エア費用予算計画
販売数、在庫数、受注＃（カーされない
部署、エア費用、エア費用予算
絡がとれないメーカーからの注文＃）、PO＃
進捗率）（販社から工場の注文）、得意
販社営業 成果物の状態
先、倉庫＃、ロット＃（MO）、仕グローバルPSI計画
輸送手段変更確認・合意
役割：
入先、原価、【工場の部品入庫
GPSIを確認して対応から製品出荷まで】会社CD、品策の妥当性を判断し目番号、日付、入庫数、出庫合意する
毎日更新された数、在庫数、PO＃、仕入先、MO＃、倉庫、原価）（【工場出荷から販社販売まで】 （機種、ロット＃、生産日程、調リスク★☆☆
会社CD、機種、日付、入庫数、 整台数、調整手段、費用負担
時差の影響で、緊急時の連エア費用予算計画 部署、エア費用、エア費用予算
販売数、在庫数、受注＃（カー絡がとれないメーカーからの注文＃）、PO＃
進捗率）（販社から工場の注文）、得意供給、納期を順守する
年次予算策定先、倉庫＃、ロット＃（MO）、仕ためにはエアを使わざ
ID：（会社CD、予算エア代、実績エ
入先、原価、【工場の部品入庫
るを得ない
ア代、日付、仕向）から製品出荷まで】会社CD、品
目番号、日付、入庫数、出庫GHQ数、在庫数、PO＃、仕入先、役割：
MO＃、倉庫、原価）輸送手段の変更がエア費用予算計画
適切かどうかを判断して承認する

輸送手段変更連絡書

GHQの承認が得られた

出荷対応
ID：06-01

出荷対応
ID：06-01

生産計画変更連絡書

承認された工場の生産調整

輸送手段変更連絡書
ID：
承認された

（機種、ロット＃、数量、日程、
エア費用、エア費用負担部門、
エア予算進捗率）

輸送手段変更連絡書

承認された

供給、納期を順守する
年次予算策定ためにはエアを使わざ
ID：
るを得ない

（会社CD、予算エア代、実績エア代、日付、仕向）（機種、ロット＃、数量、日程、
エア費用、エア費用負担部門、
エア予算進捗率）

GHQ
役割：
輸送手段の変更が適切かどうかを判断して承認する

原因構造モデル図6. 原因構造モデルからTo-beの主要構造を設計（ポストイットを使用）したのち，各プロセスの詳細設計に入る

図5. As-isプロセスの分析からボトルネックを特定し，原因構造モデルを作成（ポストイットを使用）

167

SEA

ソフトウェア・シンポジウム 2015 in 和歌山
表2. クラリオン グローバルPSIへのPRePモデルの適用過程
項
番

ワーク
ショッ
プ回数
2

目的
理解ベースライ

実施項目

関与者

実施内容

PRePモデル研修

情報システム部門全員

情報システム部門全員 に対して1.5日のPRePモデル研修を実施．

プロジェクトキックオ

業務部門と情報システ

参加メンバ要件（有識者の参画を条件とすること）とプロジェクトのフ

ム部門のマネージャ

基本計画の合意．プロジェクトの基本情報共有．目的と成功基準を

ンの形成
1

ODSCに従って確認．ステークホルダマップ（誰が嬉しいのか）と競争力モデル（どのように嬉しいのか）の確認
5

As-isプロセス

As-is業務プロセスモ

分析とボトルデル化

有識者

ホワイトボードを使用し，現在の業務の基本概念を理解．模造紙版
PRePモデルテンプレートに，基本概念理解の過程で見えてきた業務

ネックの特定スコープや成果物をポストイットで貼り出し，主要業務の大枠をつかんだ（写真1）．現状の業務プロセスのモデル化がある程度見えてきたところで，PRePモデルツールに落とした（写真2）．また，必要に応じてAs-is業務プロセスモデル化とあわせて業務プロセスMapを作成し，業務間の関係を確認した．

2
技術・リソースモデル

有識者

現行のPSIの管理技術とリソースをモデル化して理解したうえで，As-分析

is業務プロセスに対して，リスク分析とインサイト分析を行い，重要

リスク・インサイト分

なボトルネックを特定した．PRePモデルによる分析では，業務の構析

造をプロセスの後ろ（最終成果物）から前方向に，プロセス構造の理由に着目してレビューを行う．特定されたボトルネックの原因部分において，プロセスの構造とアクターのインサイトが相互に関連していることがわかった．写真3 はボトルネックが見えた瞬間

1

改善ポイント

経営方針確認

ステークホルダの合意
3

As-isとして分析された業務プロセスから改善モデルを特定するために，あらかじめ収集していた経営目標要求と経営制約を再度確認

改善ポイント合意

ステークホルダ

ボトルネックの発生原因の構造を取り出し，分かりやすくモデル化してステークホルダに説明．潜在する制約などをステークホルダから引き出しながら改善すべきポイントの合意形成を図った．

8

To-be業務プロ
セス基本設計

As-is改善ポイントの
モデル化

コアメンバ

To-beプロセスの設計は人数を5人（業務部門と情報システム部門から構成）に絞って進めた．To-be設計にあたり，原因構造をポストイ
ットを用いでモデル化（図5）．

To-be主要構造設計

コアメンバ

原因構造からTo-beの主要構造をポストイットを使ったワークショッ
プ形式で設計（図6）．

To-beプロセス基本設
計

コアメンバ

To-beの基本構造が見えてきたところで，PRePモデルのツールを使ってプロセスの設計を進めた（図6）．必要に応じて印刷し，プロセス間の関係などを確認した．業務プロセスの設計では，意識的に，実現方法（How）は意識的に考慮から外した．As-is分析で特定されたボトルネックの原因を構造的に分析することによって，PSI業務の全体最適化を実現するためのTo-beプロセス構造が見えてきた．To-beプ
ロセスの設計に伴い，新たな組織構造や責務要件が見えてきた．

改善方針のステーク
ホルダ合意

ステークホルダ

To-be業務プロセスの検証と，あとに続く業務改革とITシステム構築
をスムーズに進めるために，ステークホルダのレビュー受け，基本合意を得た．

ステアリングコミッテ
ィからのコミットメン
ト獲得

コアメンバ
ステークホルダ
ステアリングコミッテ
ィ

設計したTo-be業務プロセスとその効果を説明し，あとに続く業務改
革プロジェウトとITシステム開発に関する経営判断を仰ぎ，コミット
メントを獲得した．ステアリングコミッティー向けの説明資料は別途作成し，ステークホルダによるレビューを受けた．

To-beプロセス詳細設
計

コアメンバ

設計した業務プロセスをもとに，業務とシステムの実装を具体的にイ
メージしながら，ITシステムの要件を定義し，To-beのプロセスを完成させた．

システムスコープ・要
件定義

コアメンバ

PRePモデルでは，業務プロセスとの関係の上で成果物パラメータの精緻化，システム割り振り，機能要件・操作要件定義を行うことによってシステムスコープ定義・要件定義書がExcelフォーマットで出力される．プロセスモデルが実装レベルで具体化する過程で，それまで見えていなかった業務とシステムに関する様々な制約が見え，それにともなって，To-beプロセスも修正が加えられた．

To-beプロセスの検証

コアメンバ，業務ステークホルダ

設計したTo-be業務が正しく動くかを検証するために，実際に業務を行っているステークホルダを交えたステージプロトタイピングを用いたウォークスルー検証を行った．

モデルの精査とまとめ

コアメンバ

検証結果をTo-be業務プロセスへ反映させ，To-be業務プロセスとシステムスコープ・要件定義のベースラインをリリース．あとに続く業
務改革プロジェクトとITシステム開発プロジェクトへ引くつぐ課題を
整理した．

4

8

To-beプロセス
詳細設計とシステムスコー
プ・要件定義

5

168

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

To-be 業務プロセス基本設計

改善ポイントの合意
経営方針確認・経営目標要求
・経営制約

改善ポイント合意
・原因モデル・制約確認

As-is
改善ポイントのモデル化

To-be
主要構造設計To-be プロセス
基本設計

As-is プロセス分析とボトルネックの特定

As-is プロセス分析
・技術モデル・リソースモデル

As-is リスク分析
・リスク
・インサイトAs-is
業務プロセス
モデル化

As-is
プロセス Map でのプロセス間関係の確認

理解ベースラインの形成

改善方針のステークホルダー合意

ステコミ
コミットメントTo-be プロセス詳細設計とシステムスコープ・要件定義

キックオフ
・メンバ要件・ステークホルダ確認・競争力モデル

To-be
プロセス
詳細設計
システムスコープ・
要件定義

PReP model
研修

To-be プロセスの検証

モデルの精査とベースライン化

図7. クラリオン グローバルPSIへのPRePモデルの適用プロセス• ボトルネックの原因を成果物の関係から理解することによってTo-beの基本構造を設計することができた• その結果，業務改善では，アクターの責務定義の大きな見直しと，組織の大幅な変更の必要性を特定することができた• 後続するシステム開発とに引き渡ためのシステム
スコープ・要求定義書を出力することができた

4.2. 適用結果
今回のプロジェクトでは，PRePモデルを適用することによって，As-is業務プロセスのモデル化から改善課題を特定し，To-beの業務設計と，システムスコープ定義，シ
ステム要求の整理を行った．また，あとに続く業務改革とシステム開発プロジェクトそれぞれの実行計画までを，さらに，今回のプロジェクトにおけるPRePモデルの適参加有識者とともに策定した．その結果，今回の適用を

用に関して，参加メンバーアンケートを行った．アンケー

通して，下記の効果を確認した．

ト内容は，Humphreyらがプロセス改善においてプロセス• 業務部門のメンバーと情報部門のメンバーとが非常に良い協力関係でワークショップを進めることができた• 特に，業務部門のメンバーが率先して業務プロセスのモデル化をリードすることができた• 現状の業務プロセスの最大のボトルネックとその原因を，問題が顕在化している成果物とその原因
成果物の観点，さらに，関係アクターのインサイト分析の結果から特定することができた

モデルが持たなければならないとして定義したプロセスモ
デルの下記の3要件8）にもとづいて行った．
• 現実に行われている，または行われるべき活動をモデル化できること• プロセスのモデル化と改善を行うために十分であるとともに柔軟で理解が容易であること• 必要とする粒度でのプロセスの洗練が可能である
こと

169

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

アンケート項目とその結果を以下に示す．

20%

1. As-isの業務プロセスとして，現実に行われている活動をモデル化することができましたか

3

60%

20%

1

2

40%

60%

1

1
2
（はい）

2

1
2
（はい）

3

4
5
（いいえ）

•関係部門の人達と一緒にAs-is及びTo-beを整理したことで情報の共有化が図られた•進むべきベクトルの向きボリュームが明確になった•資料を整理するツールにより，統一された分かり易い資料が作り上げられた•今回経験した手法，ツールが今後のシステム開発に
活用できる

60%

2

•普段のシステム企画や設計では，このように時間をかけてじっくり作りこめる機会は少ない（余裕が無かったということでしょうか．．．）ため，じっくりと纏められたことは良かったと思っています．
特に組織が硬直していたり，マンネリ化している日
本では，時間をかけて空気を盛り上げて行くことは必要かもしれず，，，ただし，そういったアプロー
チは社内の力だけでは難しいので，コンサルタントの話の進め方に非常に助けられたと思っています．
本来であれば，若手が参加すべき内容であったと思いますが，，，なかなか余裕がないですね

1

1
2
（はい）

3

4
5
（いいえ）

6. 総合的に良かった点を教えてください（自由記述）

2. To-be の業務プロセスとして，Global-PSIの実現に向けて実現すべきことをモデル化することができましたたか

40%

3

4
5
（いいえ）

3. To-be の業務プロセスを検討するためのモデル化方法として，柔軟で理解が容易でしたか20%

2•現状業務を再理解することができた（知らなかったことも含めて）80%

1•プロセスを検討する上で，現状困っている事に対しての改善策を導き出す方法など，理解できた
1
2
（はい）

3

4
5
（いいえ）

•第三者的な観点で進めていただいたことが良かった

4. To-be のシステム要件を検討するためのモデル化方法として，柔軟で理解が容易でしたか•まとめや進行など全体的に俯瞰して見ていただいたことが良かった•核となる業務単位にフローを整理することで業務の流れが理解できる

20%

3

60%

20%

•業務間の連携，関連度が検証できた

1

2•プロセスを検討する上で，現状困っている事に対しての改善策を導き出す方法などが理解できた

7. 改善点を教えてください（自由記述）
1
2
（はい）

3

4
5
（いいえ）

•核となる業務を繋ぎ合わせた全体像が確認できると良いのでは．

5. To-be の業務プロセスを検討するためのモデル化方法として，必要とする粒度でのプロセスの洗練が可能でしたか•最終アウトプットまでのステップ感や手順が見えな
かった．

8. 今回の取り組みが成功するための条件として考えられることは何でしたか（自由記述）•無理と思っていてもやってみようと思うこと•業務に精通した関係部門の人の参加，及び現状を変えたいという意思とあるべき姿を持っている人の参加•会議の進行をコントロールするコンサルタントの参
加

170

SEA

ソフトウェア・シンポジウム 2015 in 和歌山•業務全体の流れを知らないと踏み込めない，また，踏み込んでいかないと改善策がうまく出来ない的な状況下で活動する状況適合的なチーム作りが必要•参加人材と意識改革と目的・目標の共有

識の高いメンバーが参加し，非常に良いチームワーク•活動計画と，そのチェックポイントのもとで作業を進めることができたことにあると考えである．今回のプロジェクトの大きな成功要因は，意•ITと業務の連携ている．一方で，適用するモデル化手法や支援ツール•プロジェクトメンバを中心とした意識の改革が必要と感じている

以前に，今回のようなチームが構成できなければ，プロジェクトの成功はとても困難であったと思われる．

•若手を中心とした人材の育成も重要

参考文献

9. まとめ1) 田中, 飯田, 松本: 成果物間の関連に着目した
開発プロセスモデルPReP:(PReP: ProductBased Modeling Method for Software
Process, ) 情報処理学会論文誌, 2004 年「社会人学生」論文, 2005.
2) ソフトウェアエンジニアリングセンター（編）: 経営者が参画する要求品質の確保〜超上流から攻めるIT化の勘所〜, 第２版, （独）情報処理推進機構, p.35（2006）.
3) 高田, 豊田, 渡辺, 曽我, 中川, 田中: 超上流工
程における合意形成手法「Exアプローチ」,
情報処理学会デジタルプラクティス, Vol.4
No.2(Apr. 2013), pp.133-140, 2013.
4) Michael Havey: 詳説ビジネスプロセスモデ
リング, p.4, 2006.
5) M. Kellner, D. Rombach: Session summary,Comparisons of Software Process
Descriptions, Proc, 6th International
Software Process Workshop, IEEE
Computer Society Press, pp.7-18,
Hakodate, Japan, October 1990.
6) Watts S. Humphrey. : Managing theSoftware Process, Addison-Wesley, ISBN0201180952, 1989. 藤野喜一（監訳）: ソフ
トウェアプロセス成熟度の改善, 日科技連,
pp.268-274, pp.298-300, 1991.
7) 井上, 松本, 飯田. :ソフトウェアプロセス, 共立出版, p.27, 2000.
8) Watts S. Humphrey, Marc I. Kellner. :Software Process Modeling: Principles ofEntity Process Models, CMU/SEI-89TR-002, 1989.
9) マイケル・ジャクソン. : プロブレムフレーム,
p.382, 2006.
10) M. Paulk, B. Curtis, M. Chrissis, C.
Weber. : Capability Maturity Model for
Software (Version1.1), CMU/SEI-93-TR-024,
1993.

経営視点から業務改善を行い，システムのスコープと要求を特定する超上流工程において，現行の業務プロセスのモデル化に関して，現場から下記の声が上がってきていた．
• モデル化自体の困難さの問題• 業務改善のための有効性の問題• 業務プロセスの本質的な意味・理由の理解の困
難さの問題
上記の問題に対して，成果物観点によるプロセスのモデル化方法が有効であると仮説し，ソフトウェア
開発プロセス改善のための成果物観点のプロセスのモデル化方法であるPRePモデルを，業務プロセスのモデル化のために拡張し，実プロジェクトへ適用した．
適用結果を，Humphreyらが定義したプロセス改善においてプロセスモデルが持つべき3要件にもとづいて評価を行った．その結果，3要件を概ね満足していることがわかった．また，実際の適用の中で下記の効果を認識した• SEではなく，業務部門のメンバーが率先して業務プロセスのモデル化をリードすることができた• 現状の業務プロセスのボトルの原因を特定する
際に，インサイト分析が効果的であった

10. 適用から見えた課題
現状の業務プロセスをモデル化を通して理解・分
析し，さらにTo-beを設計するという過程は，探索型であり反復的な学習のプロセスでもあった．そのため，
我々が何を発見し，それをどのように解決できるのか（もしくは，できないのか）を予測することが難しく，初期段階で精度の高い計画を立てられなかった．チー
ムメンバからは「全体感が持ちにくい」という意見が出た．
探索型の学習プロセスは，そもそも，進行に伴ってすべきことや進めかたが調整されていく．作業を定型化し，標準的なプロセスやワークフローを適用しようとすると，逆に，効率や品質が低下する場合もある．
このようなプロセスを成功させるためには，より変動

171

SEA