方針を正しく管理する

「方針」というとみなさんは何を連想するでしょうか。
ビジネスパーソンであれば経営方針などがわかりやすいですかね。

ソフトウェアに限った話でもないのですが、品質管理を効率的に進めるためには

その組織のトップが組織としての品質に関する方針を明示し、
下部組織はその方針の達成に向けて行動していく

という、一連のしくみが必要になります。でなければそもそも組織を作る必要もありませんし、組織に属する必要もありませんよね。

組織を作ると言うことは、作った側には何かしら目的や目標があるということで、そのためにその組織に続々と参加してくるメンバーに対しある種の指標…ベクトルを指ししめなければなりません。でなければ少なくとも作った側が望む目的や目標にはいつまで経っても辿り着くことはできません。

組織に属すると言うことは、組織と同じ目的や目標が共有できるということです。その達成のために力を貸す気があるということです。それが企業であればその対価として報酬を貰うわけですが、どちらにしても組織の持つ目的や目標のために活動できなければその組織に属する意味がありません。

この大原則を徹底するためのしくみが、方針管理です。

QMSやISMSなどいわゆる「マネジメントシステム」と呼ばれるものには必ずついてくる考え方です。当然、プロジェクトマネジメントにも同じようなものがあります。

方針管理は、方針の『展開』と『管理』によって実施されます。

方針の展開は、最初に組織のトップがその組織のあり方や存在意義などを方針という形で明示することから始まります。

つぎに、各チーム…企業であれば各部門がその方針を受けて、チームごと、部門ごとの方針を策定します。

したがって、方針管理における各方針は、より上位の方針を反映したものでなければいけません。企業であればトップの方針を受けて部長方針が決まり、部長方針を受けて課長方針が決まるようなしくみになります。個々人はそうした方針の流れを汲んだ、直近の所属組織の方針に従って自らの活動目標や計画を立てていくことになります。

このような上位と下位の連鎖で方針を設定するしくみを『方針展開』と呼びます。

方針には「目標」と「方策」があります。

あらかじめ言っておきますと、どちらか一方だけでは成立しません。ソフトウェア開発の世界ではこれを理解していない組織人が非常に多いんですよね。だからすぐに個人主義に走りがちで、組織的な活動がとても苦手な人が多いんです。

取り扱うプログラム言語を使った実現方法に自由度が高すぎるのと、その自由度をある程度引き締めて組織として体裁が整える程度のルールを策定することを苦手としている人が多い…というのが原因の大半かもしれません。ですが、そのことに危機感を抱かないどころか、最低限のルール等に縛られることすら反発したがるエンジニアが多いこともまたそうした問題を加速させる要因なのは疑うまでもありません。

そうなると、もうただの無法地帯です。

億単位のトラブルプロジェクトを経験したことがあるエンジニアやそういったプロジェクトの火消しに駆り出されたエンジニアの多くは理解できることでしょう。

トラブルが起きたプロジェクトはいつも無法地帯です。

ですから私は少なくともただただ意味もなく無法地帯を好むエンジニアを「プロフェッショナル」とは呼びません。論理的な仕組みを組み上げ、その上にシステムやソフトウェアを構築していく「エンジニア」とも呼びにくいところがあるので、ただちょっとプログラミングに詳しい一般人と言った方がいいかもしれません。

さて、「目標」と「方策」のうち目標は良いですよね。
『目標』はマイルストーンであり、ゴールと言っても差し支えありません。

企業などの組織の場合、企業の持つ「目的」ははるか先にあるもので、たった１年で達成できるものでは無かったりしますよね。そんな時、「目的」に向かって正しく進めていることを確認するための中間地点であり、それまでの進め方を見直すポイントとなるのがマイルストーンであり、目標となるわけです。

企業の場合は、このマイルストーン…目標を１年や半期、あるいは四半期ごとに設定していて、最終的な目的を達成するために微調整できるタイミングをいくつも設定しています。

プロジェクトの場合は、その目的を達成するために工程ごとのチェックであったり、あるいは「進捗管理」と称して定期的にマイルストーンを設けていたりしますよね。

『方策』とは、その目標を達成するための具体的な手段のことです。

たとえば「新規ツールを導入して、工程の不適合品率を0.1%にする」という場合、

　「工程の不適合品率を0.1%にする」…目標
　「新規ツールの導入」　　　　　　 …方策

となります。

目標だけ立ててあとは放置…と言うトップやマネージャーも世の中には多いかもしれませんが、それは具体的な方策を一切検討していないせいです。

企業経営にせよ、プロジェクト運営にせよ、方針管理で対象している方針は、品質方針だけではありません。利益、原価、納期、生産性などの重要な経営/運営要素に関する方針も方針管理の対象になります。

ひとつ前までのPMBOK流に言うならば、10の知識エリア一つひとつに方針を立てることが可能である、ということです。

なお、方針の切り替えは企業経営の場合であれば通常１年ごとに行われますね。

プロジェクトであれば基本的にプロジェクト発足時のみに行われることが多いですが、私に言わせれば設計開始時、およびテスト計画立案時にはそれぞれの工程毎の方針を見直すべきだと思っています。なぜなら、最初に立てた計画が、ずっとそのまま計画通りに進むことというのは珍しいことで、基本的には適宜現実に照らし合わせて計画の方を見直すことも多々発生するからです。だから計画当初の方針や方策を見直す機会は適宜設けておくべきなのです。

案外、計画まで落とし込んでしまうと、当初の方針や方策を忘れてしまって目先のことばかり見ようとするマネージャーや担当者が多いと思います。

それは「方針に沿った計画」と呼べるのでしょうか。

計画自体が方針に常に沿っていながら現実にあわせて形を変えるのはなにも問題ありません。しかし、そもそもの方針を忘れて目先の計画ばかりを追っていては、結果的に当初の目論見からまったく異なる結果になることも多いのではないでしょうか。実際

　「進捗管理 = マネジメント」

だと思っているマネージャーは多いと思います。いえ、知識としては他にも色々あるとわかっていても、実際に進捗管理以外は他人任せとしているせいで炎上しているプロジェクトは存外多いものです。

マネージャー起因で炎上するプロジェクトの多くは

　『会議と進捗管理しかしていない（できていない）』

ケースが圧倒的に多いように感じます。そういった現場では

　・そもそも方針なんて考えていない
　・最初から形骸化した方針で守る気がない

空気を肌で感じ取ることができます。顕著に表れるのは

　「言ってることとやってることが違う」
　「その場の思い付きや感情論が横行する」

といった事例です。こうした事例が出た現場、そうしたマネジメントが許容される組織では、そもそも『計画的』『戦略的』に物事を進めることは困難だと思っておいた方がいいでしょう。

またどんなに業績や実績を一時的にあげられたとしても、方針を定められない、方針に従えないマネージャーなどを安易に採用してしまう組織というのも、いずれ組織そのものを空中分解させかねないことを知っておくと良いでしょう。