品質の、品質による、品質のためのマネジメント
こんばんは。
今、風呂に入っていたら、唐突に思い浮かんだ言葉が私の考える理想的なプロジェクトマネジメント像に合致したので、思いがけず飛び出して書き始めました。
米国の大統領であったリンカーンが1863年11月、ペンシルバニアのゲティスバーグで行った演説のなかの言葉で、民主主義政治の原則を示したものですね。
対象となるものが、
何を行うもので、
何よって行われるもので、
そして何のために行われるものなのか
を明確にした言葉です。人民の政治を、人民の手によって行い、そしてそれらは人民のためでなければならない、と言う固い決意を表した言葉ということですね。
翻って、私たちが一般的に行う『仕事』と言うのはいったい
何を求められていて
何によって行うべきもので、
そして何のために行われるもの
なのでしょうか。これをソフトウェア開発…いわゆるIT企業のプロジェクト活動に当てはめた場合、私は前提に『品質=顧客満足度』としたとき、
品質の、品質による、品質のためのマネジメント
management of quality, by quality, for quality.
こそがまさに今求められているのではないかと思うのです。
(仕事の)品質のマネジメント
まず最初に重要となってくるのは一つひとつの仕事の品質です。そしてその品質の高い仕事のマネジメントです。アクティビティ、単作業と言えばいいでしょうか。いわば『点』の品質です。
一挙手一投足、自らの仕事、作業、行動の品質ってみなさん具体的に意識したことはあるでしょうか。いやまぁ私も今だから言えることですが、新人のことは結構適当なことをしてたと思います。挨拶一つとってもそうですし、ビジネスメールにしてもまともに書けるようになったのは結構後だったんじゃないですかね。社内メールって最低限度って縛りはあっても多少程度の誤りでは気にされませんしね。
たとえば尊敬語、謙譲語や丁寧語の使い方、様や殿などの使い方、文法、構成、etc.…日本人なのに日本語すらまともに使えないなんてこと、普通にありましたしね。私も、教育する側の立場になってはじめて気づかされたことが多々ありました。もちろん、伝わりさえすればそんな細かいこといちいち気にしなくても…とは思うのですが、相手が気にする以上従うしかないんですよね。
ですが、こうした一つひとつの品質…特に情報伝達や情報共有と言ったコミュニケーションに関わる品質は、そのままチームワークやその後の仕事の品質に大きな影響を与えます。
これを疎かにした仕事、疎かにした仕事のマネジメントでは、決してプロジェクト目的を果たすことはできません。
(プロセス)品質によるマネジメント
単作業、アクティビティの品質を向上させたところで、それら"点"をつなげて"線"の品質として成立させなければ、プロジェクト活動そのものの目的を果たすことはできません。
ここでいう「プロセス」とは、その『線』…すなわち仕事の流れのことを言います。仕事…と言うとアクティビティの品質が最小単位になりますが、ソフトウェア品質の定義ではプロセスの品質が最小単位になります。それより小さい単位は各企業、各組織で自由に定義すればいいってことなんでしょう。
このプロセス品質をしっかりとマネジメントできるマネージャーと言うのはなかなか見かけません。一般的なIT業界のマネージャーと言うと、大抵はスケジュールとコストばかり見ています。
もちろんマネージャーが一人ですべてマネジメントする必要はありませんが、自らの思い描く(あるいは顧客に言われるがままに描いた)スケジュールとコストの中で、進捗だけを見ていてそれ以外は他人に丸投げ…と言う人が多いと思います。アーキテクトやQAなどが別にいるプロジェクトもみかけますが、少なくともしっかり連携しているのは数えるほどしか見たことがありません。
そういったマネージャーが管理するプロジェクトは、とにかくプロセス品質が粗く、雑です。
たとえば、ルール1つ作ることを怠ったとします。
そうすると内部品質が影響を受け、バグを作りやすい土壌が形成されるわけです。もちろんそれが必ずしも成果物品質(外部品質)に直結するわけではありませんが、わざわざ「作りにくい」環境しか与えないマネジメントを行えばパフォーマンスは上がらず、進捗に影響を与え、残業が増え、品質も低下する…と言う負のスパイラルを生み出してしまいかねません。少なくとも、無いなら無いなりに現場のメンバーに苦労を押し付けていることでしょう。
プロセス品質をベースにしたマネジメントは高い水準が維持されていなければ、いざと言うときにトラブルを招きこみかねません。
(成果物)品質のためのマネジメント
これはマネジメントの『目的』の話ですね。いったい、何のためにマネジメントするのか?という問いに対する答えです。当たり前ですが、ソフトウェアを作ると言うのは最終的に
お客さまの要望(困った問題や課題)を叶える(解決する)ため
です。それ以上でも、それ以下でもありません。そのために必要十分となる取り組みはすべて実施されなければなりません。不足すれば、十分な品質とは言えなくなります。
「仕事」である以上、もちろん自社の売上や利益は大事です。一人ひとりのエンジニアやマネージャーにとっては、自らの評価や出世なども大事だと思います。ですから、成果物品質だけ見てそれ以外を度外視していいとはならないと思います。
ですが、品質の低い製品を作って世に出して、企業は社会的に評価を受けますでしょうか。売上・利益の前に受注機会を損失しかねませんし、最悪の場合は倒産もありえます。
納品後にクレームを受けるような仕事ばかりしていて、社内で評価を受けると思うでしょうか。最悪、まともなプロジェクトでは活用してもらえなくなるかもしれませんよね。
私が言いたいのは、
「品質」だけ見ていればいいと言うものでは無く、
「品質」を第一にしつつ、他も疎かにしてはならない
というものです。決して品質の奴隷になればいいと言っているわけではありません。そもそも、
個々の仕事の品質を高める努力もせず
チームのプロセス品質に注意を払うこともせず
最終的に出来上がる製品の品質に誇りも持てない
そんなマネジメントもチームワークも本当に意味のある結果になりますでしょうか。
私は、プロジェクト活動に限った話ではありませんが、日々の仕事の中で最も重要なのは「品質」だと考えています。これまでも言ってきたように、出来上がった成果物の品質だけではなく、日々の活動の品質や様々な活動/仕事の流れの品質も、です。
むしろ、それらの品質を高めることもしないで、スケジュールやコストをしっかりとコントロールすることなんで不可能だと思っています。
基本的にQCD…品質、コスト、期限のすべてに達成すべき基準はあると思いますが、あえてこれらの中に優先度を設けるのであれば、やはり品質だと思います。というか、なんでこのQ・C・Dの順番で呼ばれているのか思いを馳せてみればわかることですよね。
いやー…風呂入って何考えてんだ?って話ですが。
別に仕事のことばかり考えていたわけでもなかったんですけどね。
なんとなくボーっとしてたら、リンカーンの言葉が思い浮かんできて、それがなんとなくシックリくるもので、色々な言葉を「人民」の替わりにあてはめてたら、ものすごく自分らしさに合致したのがたまたま「品質」で、
「品質のー…品質による、品質のための?なんだ?」
「つっても、これ全部同じ品質じゃないな、何の品質だ?」
とか考え始め、行きついたのがタイトルの通りです。自分らしい仕事のコンセプトを言葉にしたらそうなったって感じです。そして、世の中の仕事の在り方が、もし同じようになっていけば、プロジェクト活動…なかでもソフトウェア開発業のプロジェクトは、劇的に改善されていくと思います。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。