ITコーディネータを取得した後、「ITコーディネータの知識体験の礎、源流にあたるものを学びたい」と思い、PMBOK*1を学び、PMPを取得した。
PMBOKを学んで分かったことは、ITコーディネータの知識はどちらかというと「広く、浅く」の感がある。浅い、といっても「言葉だけ知っている」という薄っぺらなモノではなく、実務に活かせるであろうレベルであるだろう。
比べてPMBOKは「狭く、深く」の感があった。ITコーディネータとしての力を補強するには非常によい知識であったと思う。実務でもその力を発揮できていると思う。
しかし、上位マネジメントや知り合いのPMP所有者（兼ITコーディネータ所有者も含む）の話を聞いたり見たりしていると、どうもうまく回っていないようなのだ。
第三者としてみていると、うまくいかない理由や対策は見える。しかし、当の本人達にそれを伝えてもピンと来ないようなのだ。
どこの現場でもそうかもしれないが
・内部又は顧客との正確なコミュニケーションが取れていない。
⇒思いこみで仕事を進める
⇒顧客との合意を執らない
⇒他への影響を考えない
・作業をブレイクダウンできていない
⇒作業タスクが粗く詳細化の余地があるため、担当者によって作業レベルが異なる（ゴールがまちまち）
・モニタリングとコントロールができていない
⇒作業タスクの詳細化やスケジュールをチェックし、均一化できていない
⇒スケジュールに対する進捗とその影響を把握できていない
⇒新たに発生した問題のピックアップと対応ができていない
ということが多い。
特に気になっているのが作業タスクの作り方。今ではＷＢＳと呼ばれることの方が多いかもしれないが、書く人によって作業タスクの落とし方は異なる。それの落とし方、レベル感にはマニュアル本的なモノはない。プロジェクトで決めておくべきだろう。プロジェクトで決めていなければ先々そのレベル感の違いがプロジェクトのひずみ、きしみを発生させるリスクにもなりうるのである。
このあたり、どう言えば理解して貰えるのだろうか、と考えていたが、ITコーディネータのもう一つの源流である「監査」の考え方を用いればいいのではないか？と気がついた。
ITコーディネータではモニタリング、コントロール、成熟度判断なども学ぶが、モニタリングとコントロールの具体的な方法については浅かった記憶がある。一方、システム監査では監査対象の工程により確認する項目は異なるが、モニタリングとコントロールは基本である。
モニタリングとは「ちゃんと計画通りに出来てる？」という確認である。PDCAのC（チェック）にあたる。
これがうまくいっていればいいが、そうでなければ「じゃあ、こう変更しよう」と、計画とかやり方を変えるのがコントロールであり、PDCAのA（アクション）にあたる。
そのモニタリングやコントロールをするための前提知識が監査には求められている（はず）で、そこが分かればチェックポイントは押さえられる。
半ば私の思いこみ部分もあるかもしれないが、「監査」がプロジェクトの円滑な推進のために不可欠なのではないかと思えてならない。私の持っている知識も断片的であるので、今年は本格的にシステム監査を勉強していこうと思う。時間は短いが、春の情報処理試験はシステム監査を受験してみようと思う。
*1 PMBOK ： プロジェクトマネジメント知識体系ガイドのこと。Amazonで探すときは「和書」ではなく「洋書」のカテゴリに含まれる。
プロジェクトマネジメント知識体系ガイド第3版 A Guide To The Project M.../Project Management Institute
PMBOKを学んで分かったことは、ITコーディネータの知識はどちらかというと「広く、浅く」の感がある。浅い、といっても「言葉だけ知っている」という薄っぺらなモノではなく、実務に活かせるであろうレベルであるだろう。
比べてPMBOKは「狭く、深く」の感があった。ITコーディネータとしての力を補強するには非常によい知識であったと思う。実務でもその力を発揮できていると思う。
しかし、上位マネジメントや知り合いのPMP所有者（兼ITコーディネータ所有者も含む）の話を聞いたり見たりしていると、どうもうまく回っていないようなのだ。
第三者としてみていると、うまくいかない理由や対策は見える。しかし、当の本人達にそれを伝えてもピンと来ないようなのだ。
どこの現場でもそうかもしれないが
・内部又は顧客との正確なコミュニケーションが取れていない。
⇒思いこみで仕事を進める
⇒顧客との合意を執らない
⇒他への影響を考えない
・作業をブレイクダウンできていない
⇒作業タスクが粗く詳細化の余地があるため、担当者によって作業レベルが異なる（ゴールがまちまち）
・モニタリングとコントロールができていない
⇒作業タスクの詳細化やスケジュールをチェックし、均一化できていない
⇒スケジュールに対する進捗とその影響を把握できていない
⇒新たに発生した問題のピックアップと対応ができていない
ということが多い。
特に気になっているのが作業タスクの作り方。今ではＷＢＳと呼ばれることの方が多いかもしれないが、書く人によって作業タスクの落とし方は異なる。それの落とし方、レベル感にはマニュアル本的なモノはない。プロジェクトで決めておくべきだろう。プロジェクトで決めていなければ先々そのレベル感の違いがプロジェクトのひずみ、きしみを発生させるリスクにもなりうるのである。
このあたり、どう言えば理解して貰えるのだろうか、と考えていたが、ITコーディネータのもう一つの源流である「監査」の考え方を用いればいいのではないか？と気がついた。
ITコーディネータではモニタリング、コントロール、成熟度判断なども学ぶが、モニタリングとコントロールの具体的な方法については浅かった記憶がある。一方、システム監査では監査対象の工程により確認する項目は異なるが、モニタリングとコントロールは基本である。
モニタリングとは「ちゃんと計画通りに出来てる？」という確認である。PDCAのC（チェック）にあたる。
これがうまくいっていればいいが、そうでなければ「じゃあ、こう変更しよう」と、計画とかやり方を変えるのがコントロールであり、PDCAのA（アクション）にあたる。
そのモニタリングやコントロールをするための前提知識が監査には求められている（はず）で、そこが分かればチェックポイントは押さえられる。
半ば私の思いこみ部分もあるかもしれないが、「監査」がプロジェクトの円滑な推進のために不可欠なのではないかと思えてならない。私の持っている知識も断片的であるので、今年は本格的にシステム監査を勉強していこうと思う。時間は短いが、春の情報処理試験はシステム監査を受験してみようと思う。
*1 PMBOK ： プロジェクトマネジメント知識体系ガイドのこと。Amazonで探すときは「和書」ではなく「洋書」のカテゴリに含まれる。
プロジェクトマネジメント知識体系ガイド第3版 A Guide To The Project M.../Project Management Institute