DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

【質問】
今まで現場一筋で仕事をしていたのですが、異動でPMOの立場になりました。PMOでプロジェクトマネジメント標準を作成することになっているのですが、組織で共通利用するドキュメント作りは初めてなので、出来るかどうか不安です。
現場では、特別なことをやるわけではなく、スケジュール管理や課題管理等誰もが普通にすることをしてきただけなので、何を文書化すればよいかよくわかりません。（39歳男性）

【かずみ先生より】
システム構築プロジェクトで、日々仕事をしてきた人にとって、バックオフィスで仕事をすることへの不安は誰しも少なからずあると思います。
特に個別プロジェクトを睨んで計画を立て、プロジェクト固有の問題に対処してきた人にとって、「組織のみんなが使う標準」と言われても困ってしまいますよね。
「そんなのプロジェクトによって重視すべきところは違うだろ」「何か問題にぶち当たっても経験と勘でマズイところが臭うんだよね」と思っている方も多いのではと思います。私もその一人。「なんとなくこうすれば上手くいくかも．．．と気付くセンスが必要だよ」と思っていました。

でも、PMOの経験により、ちょっと違う見方ができるようになりました。
自分で標準を作らなければならない立場になった時に、自分の経験を言語化できることに気づきました。ただ頭で考えるだけではほとんどそれができません。

まず、同じようなテーマの書籍や標準を何種類か熟読する。その際、自分の経験と照らし合わせてみると「こちらの書籍の課題管理の方法は共感するが、別の書籍は、進捗メトリクスが参考になる」など自分が何を重視してきたか分かります。
これは成功経験だけではなく、失敗体験でも活用できます。
「リスク管理をしていなかったが、心の中でリスクは感じていた。ただ、文書化していなかった結果、他のメンバーとの認識が合っていなくて、リスク発生時には自分一人で対処したな」などです。

書籍や他社からの購入した標準をそのまま使えば．．．というわけにはいきません。所属している組織やプロジェクトの特性により制約条件や重視すべきところが違います。
その組織での“経験”は、その組織の制約条件や重視すべきところが詰まっています。
その組織に合った標準を作る作業（テーラリング）は“経験”が非常に活きます。そしてテーラリングがなければその標準は「使えないなぁ」と人から疎ましがられるドキュメントになります。

(1)　元ネタにするものを探す。
(2)　自分の経験を言語化（理論に）する。（複数の情報を基に自分の経験を振り返る）
(3)　元ネタを修正する。
(4)　他の人の経験も仕入れ言語化する。（たとえば、いろんなプロジェクトのトラブル事例を収集し、事象や原因を分析、その組織の弱点を見つける。弱点を克服するための対策を標準に盛り込む等）

これを繰り返すことで組織に合った標準が出来てきます。

ちなみに、簡単な仕事ではありません。難しいからこそ、弊社のコンサルティング事業が成り立っているのですから．．．。

＊＊＊＊＊＊
4月から日経BP出版の日経SYSTEMSにコラムを書いています。毎月毎月締切があり本当に苦しい。
そして、このブログも2週間に1回の締め切りがある。
そしてそして、研修教材の締め切りも。
締め切りに追われ、人気作家みたい！！！なんて妄想にふけりながら、只今カフェで執筆中です！

日経SYSTEMS編集長さん、いつもいつも下手な文章でゴメンナサイ。