Development)のT21研究会「PFDによるプロセス設計」主催のフォーラムにて、「DX時代のプロセス設計~PFDとPRePの融合~」というテーマでPRePモデルのワークショップを実施いただきました。Process)」を提供しています。Diagram)というプロセス設計手法の効果的な活用方法の検討を行っています。このPFDとPRePモデルを融合することで、どのような相乗効果が得られたのか、T21研究会メンバーにお話を伺いました。「第6回アフォードフォーラム」の詳細はこちらPFDとの融合により、PRePモデルのメリットを活かし、難しさを補完なぜPRePモデルとPFDを融合させようと思ったのですか?八木さん:私がPRePモデルとPFDを知ったのはほぼ同時期で、2010年くらいになります。非常に似ている手法だなという印象がありました。端的に言うとPRePモデルは成果物のみを記述しますが、PFDでは成果物に加えてプロセスを記述します。PRePモデルは同期関係などから業務のリスク箇所を明示できるというメリットがあるものの、成果物のみの表現であるため、モデルを理解したり、作成したりすることに難しさがありました。そこで、PRePモデルに近い手法で、成果物だけでなくプロセスも併記するPFDを連携することで、PRePモデルの欠点を補えるのではないかと考えました。ダイアグラムを見るだけで問題点を発見できる!PRePモデルを最初に聞いたときの印象は?野沢さん:難しそうだなと思いました。PRePモデルに触れたのは、ソフトウェア・シンポジウム2019のワーキンググループに参加したときです。そこでは、グループワークでPRePモデルを作成していきました。PRePモデルはプロセスを書かずに成果物のみ記載するので、参加者間でイメージが沸きづらく、「これはこういうことをやりたいんだよね」と、プロセスの話をしながら進めていましたね。T21研究会メンバーには、私からシンポジウムでの実施内容を共有した際にPRePモデルを知ってもらったという流れになります。伊藤さん:野沢さんから伺ったときに、難しいなと思いました。作成したPRePモデルだけ見ても、背景を知っている人でないと理解が難しいのかなと感じましたね。曽我さん:私も伊藤さんと同じ印象を受けました。スイムレーンがあるので、「誰が何をやっているか」は分かりました。梶本さん:皆さん難しいと言っていますが、私は、割とすんなり受け入れていましたね。PFDは成果物とプロセスで記載していきますが、成果物のみで記載する方法もありだなと。「ある成果物を扱っている人がいなくなったときに、どうすればよいか」が、考えやすい手法だと思いました。ご自身でPRePモデルを描いてみて、いかがでしたか?伊藤さん:やはり、プロセスの方が考えやすいので、プロセス無しで描くのは難しいですね。今回のフォーラムで実施したように、一旦PFDで描いて、その後プロセスを抜いてPRePモデルを描くと良いと思いました。PRePモデルを描いて良いなと思ったのは、実際に研究会メンバーで実施したときに、しっかり描けていると思ったPFDが、PRePモデルにしてみると「あれ?意外と抜け漏れあるじゃん」ということに気付けたことです。AsIsを描いているときに、曖昧なものを可視化できるところも良かったです。PFDでは「曖昧」というのが直感的に分かりづらいので、PRePは表記法に含まれていることが良いと思いました。あとは、スイムレーンですね。PFDではアクターが増えると、文字を読まないと分からないので、見やすいなと感じました。曽我さん:私は、成果物間の同期の考え方が難しかったですね。その同期関係が、プロセスを複雑にしているなど「改善ポイント」になることが多いので、ダイアグラムだけで問題が分かるというのは、すごいなと思いました。(左から)八木さん、伊藤さん野沢さん全体最適な視点で大きな改善を実施する際に適した手法PFDだけのときと比較して、どんな効果がありましたか?伊藤さん:PFDはプロセスと成果物の両方を描くので、ダイアグラムが大きくなってしまうんですよね。PRePモデルはプロセスを書かないので、ダイアグラムとしてスッキリし、ある程度分かっている人からするとPRePモデルの方が理解しやすいと感じました。梶本さん:PFDはゴールが明確な状態のときに「どのように作るのか」を描く記法です。1回固まってしまうと、途中で問題が起こらない限り、なかなか書き換えることをしないところがあります。ゴールに対して「もっと良いのがないか」などToBeを考えていくときにはPRePモデルの方が考えやすいと思います。野沢さん:プロセスを取っ払って成果物だけ考えるので、今のプロセスに引っ張られずに整理できるところが良いと思いました。曽我さん:梶本さんと似たような話になりますが、PFDを作ると、なかなか変えないです。変更するとしても、全体を見ずに部分最適になってしまう。そこを、PRePモデルに出会うことによって、一歩引いて、全体的な観点で考えられるようになったと思います。「こういう風に変えたい」というビジネス要求に対してPFDで描くのは難しいと思うので、PRePモデルを使うと良いと感じました。PRePモデルにPFDを組み合わせることで、どんな効果がありましたか?野沢さん:いきなり成果物だけを描くのは、難しいと思います。AsIsのPRePモデルを描く最初の一歩として、PFDを使うと良いと思いました。ToBeを描いた後も、PRePモデルだけでは理解しづらいので、PFDでやることを整理していくと良いと思います。秋山さん:野沢さんと同じで、PFDは万人向けというか、プロセスがあるので読み手にやさしいです。最終的に落とし込むのはPFDが良いと思います。最初の分析と最後の分析にPFDを使うと良いかなと思いました。梶本さん:成果物を作るためにはプロセスがないといけません。PRePモデルのToBe像を実現するためには、PRePモデルで考えた成果物を作るためのプロセスを考えてPFDにする必要があると思います。DXや業務改善に関わっている人にはぜひオススメしたいPRePモデルをどのような方にオススメしたいと思いますか?曽我さん:経営戦略を考える立場にある人に使って欲しいと思います。全体最適な視点で問題点を分析し、今後どうするかを考えていくのに適した手法だと思います。Notation)を使っていて、最近では廃れているので、それに代わる手法として伝えたいですね。伊藤さん:私は、既に、グループ会社でERPの導入コンサルを行っている人に紹介しています。システムの導入コンサルなど、ある程度専門性のある方にオススメしたいですね。秋山さん:業務や生産ラインなど、課題を持っていて変えなければいけない「改善を迫られている」部隊に紹介したいです。DXや業務改善を担当されている方には、ぜひ使っていただきたいですね。ToBeを実現するためには、PRePモデルだけでは難しいと思うので、研究会での検討内容であるPRePモデル+PFDの両輪で紹介したいと思います。梶本さん:それなりの規模の会社の業務システムを考える方には使っていただきたいです。規模が大きいと、さまざまなところにデータをもっています。それを統合して1つのシステムにするなどの大きな改革を考えるときには、PFDでは難しいので、PRePモデルがオススメです。DXを考える際には、自社がどのようなデータを持っているのか理解し見極めて、「どう変わるのか」をPRePモデルで作り、実際のプロセスに落とすところはPFDに置き換えるという進め方を取っていただくと、かなり効果が上がる気がしますね。伊藤さん:それは、すごい同感です。今後、PRePモデルをどのように使いたいですか?曽我さん:フォーラムの参加者からは「改善点を見つけるのに強い。何回か試して習得したい」と好評でした。残念ながらフォーラムに参加できなかった方からも「やってみたい」という声が挙がっているので、再度、開催したいと考えています。(左から)秋山さん、梶本さん、曽我さんプロセス設計のプロフェッショナルな皆さん。ワークショップの設計、ファシリテーションと素敵なフォーラムをありがとうございました。DX時代に必要なプロセス設計について引き続きディスカッションしていきたいと思っています。modelは、有限会社ケイプラス・ソリューションズの登録商標です。技術情報コラム会員ページお問い合わせEnglish。