ITコーディネータの吉田聖書です。
以前、プロセスマッピングを使ったWBSの作り方について書きました。
このテーマで実際に手を動かすワークショップも開催しました。
基本的な理屈はこれで充分なのですが、
比較的大規模なプロジェクトに
適用しようとすると項目が多くなるため
プロセスマップが描きにくくなりますし、
時間もかかってしまいます。
それを短時間で作成する方法をご紹介します。
およそ大規模なプロジェクトでは
「工程」という概念を取り入れています。
工程とは業種・業態を問わず
簡単に言うと次のようなものです。
計画→設計→実装→検証→完了
もちろんプロジェクトによっては
設計がさらに何段階にも分かれていたり、
検証が何段階にも分かれていたりということもありますし、
工程の呼称も組織の文化によって様々ありますが
まあ大体こんなものです。
必要に応じて読み替えてください。
例えば次のようなシステムの開発を考えます。
皆さんはA社の担当者だと考えてください。
工程はそれ全体で一つの作業とみなすことが出来ますので、
まずは工程に必要な資源（インプット）と
工程の成果物（アウトプット）を書き出していきます。
そうすると次のような表が出来上がると思います。
（一部を抜粋します）
プロセス定義（一部）
特に金融業など開発プロセスが厳格に決められている職場もあろうかと思いますが、
その場合はプロセスの定義に従って工程ごとの成果物を書き出せばよいです。
表が一通り書けたなと思ったら
この工程と資源・成果物をつないで
プロセスマップを描きます。
トップレベルのプロセスマップ（一部）
すると、出所の分からない資源が
あることに気づくかもしれません。
プロセスマップでは
どこからもつながっていない
資源が該当します。
それは既に入手出来ているのか、
今後誰かから受領するのか、
誰かがどこかから調達（購入）するのか、
あるいは誰かが作成するのか…
ということを見極め、図示していきます。
（これは次回触れます）
それによって、
定義された工程とは別の
準備工程ともいえる工程が
必要なことが分かる場合もあります。
もしプロセスの定義が存在する場合、
それは前工程に含まれるかもしれませんが、
前工程の本来の作業と異なるのであれば
便宜上、別の工程として取り扱った方が
分かりやすいと思います。
こうして出来上がったプロセスマップが
第一段階（トップレベル）です。
（次回へ続く）
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。