プロセスを細かく書き過ぎることなく、行動規範で定着を促す
私たち日本人は、何かにつけ、緻密にルールを決めたがります。
プロセス定義も同じです。
特にエンジニア気質の人は、何でもかんでも見境なくプロセスに突っ込む傾向があります。その結果、巨大化したプロセスは利用されません。
プロセスは、サイクルに置き換えることで定着しやすくなります。ところが、大規模で複雑なプロセスをサイクルで完全に表現するには、サイクルの定義が何階層にも及んでしまいます。
別建てのプロセス定義ドキュメントに切り出してもいいのですが、所詮、複雑すぎる定義書が読まれることはありません。
ならばとばかりにプロセスの減量に取り組んだとしても、これが一筋縄ではいきません。
そこで今回は、その一助になればと筆を執りました。
実は、行動規範をうまく定義してプロセスの外堀を埋めれば、プロセスの記述は少なくてすみます。
ピンとこない方のために、行動規範の例を挙げておきましょう。
・ 自分で責任をとれる範囲は各人が判断する。
・ 自分の手に負えないときは、抱え込まずに上司に判断を仰ぐ。
・ 計画を立ててから行動すし、計画は立てっぱなしない。
・ 積極的に権限委譲するが、権限委譲した後は任せっぱなしにしない。
・ できない約束はせず、約束したことには責任を持つ。
・ 取引先とは対等な立場で付き合う。
・ 上司は部下の自己実現に責任を持つ。
以前にこんなことがありました。
私は、プロジェクト型で事業運営する組織からプロジェクトマネジメント力強化の仕事をいただきました。ここのプロジェクトはどれも大型で複雑でしたが、プロジェクト運営は属人的でした。
はじめは複雑な仕組みをトップダウンで導入しようとしましたが、うまくいきませんでした。組織のガバナンスが脆弱で、トップダウンはまったく効かなかったからです。
そこで私は、文化や価値観、働き方などといった組織の基礎づくりを優先させることを提案しました。ボトムアップである程度の成熟度に達したら、トップダウンも効くはずだと考えたからです。
私は、ごくシンプルな行動規範を「プロジェクトマネジメントの基本行動」として定めました。
1. 毎週、進捗会議を開催する。
2. 作業ごとに「始めたか」「終わったか」「いつ始めるか」「いつ終わるか」を確認する。始められない、終われない場合は理由を確認し、対応策を検討する。
3. プロジェクト計画を更新、再計画する。
4. 計画に合意し、会議を解散する。
5. 計画に沿って、 1 週間、作業をする 。
基本行動を速やかに定着させるには、口で諭してもダメです。そこで、マイクロソフトのプロジェクトマネジメント支援ツール（Microsoft Project）を利用することにしました。頭ではなく、行動（＝操作）と身体で覚えさせようと考えたのです。「教育」ではなく「躾（しつけ）」です。
これが図に当たり、プロジェクトマネジメントの基本行動は組織内に広がりました。
このように、行動規範を徹底すればプロセスの詳細度は抑えられ、脚注の但し書きを減らすこともできます。これはプロセスに限った話ではありません。制度やルールにはもっと効きます。
行動規範は息が長いのが特徴で、プロセスや制度・ルールのような頻繁で更新してはいけません。行動規範やこれに込められた熱い思いは時間の経過とともに組織内部に浸透し、価値観と結びつき、文化となって脈々と受け継がれます。
皆さんも、これをヒントに、ぜひ工夫してみてください。
★★★ 概念化.com を立ち上げました ★★★
https://www.gainenka.com/
★★★ ぜひ、お立ち寄りください ★★★