プロセス改善のマネージメントについて
List
あるとき、「プロセスを改善しても何も良いことはない」という人に出会いました。彼の話しで分かったことは、プロセス改善に成功したことで、却って大変な目にに会ったというのです。
彼の話では、前回のプロジェクトで、それまで私のセミナーで仕入れて温めていた方法でプロセスの改善に取り組んだことで、仕様変更も少なく、QAテストで発生するバグも３件／KLOCと、従来の１／５に減少したということです。確かに、仕様のレビューで今までの書き方では有り得ないほどの仕様モレや曖昧な表現の箇所が指摘されています。そこで早く発見されたお陰で、仕様変更やバグが減ったことは間違いなく、最終的に当初の納期を２週間余してプロジェクトは完了したのです。
その結果を持って課長のところに報告に行ったのですが、そこで言われたのは、
「そんなに早く終わったのなら、明日からでも○○プロジェクトの応援に回ってくれないか」
というものでした。課長からは今回のプロジェクトに対する労いの言葉は出てこなかったのです。もともとこれくらいでできるプロジェクトだったと思われたかもしれないと、彼は言います。
彼は、自分のチームに戻って、「○○プロジェクトの応援に回るように言われちゃった」といったものの、内心は面白くありません。彼の心中は、メンバーのみんなにも伝わっています。「○○プロジェクト」は、当初の納期をすでに１ヶ月遅れています。今から応援に回ったところで、評価されるプロジェクトではありません。第一、この時期に参加して応援に入れる状況かどうかも怪しいのです。課長としては、○○プロジェクトについては納期の延長交渉で２ヶ月の期間を確保し、リソースの確保に躍起になってきたのですが、「できることはやった」という言い訳のカードを１枚でも増やしたい中で、プロジェクトを２週間早く終わったチームを回したのです。課長としては、最善を尽くしたつもりなのでしょう。
でも、これは最悪の対応です。結局、このリーダーは、この後二度と納期を余ししてプロジェクトを終了することはしませんでした。他のチームと同じように遅れるか、せいぜい許容範囲の遅れの中で終えるようになったのです。そして、彼自身も“普通のリーダー”で現役を終えたのです。
私自身、こうした形でコンサルティングに行き詰まったケースは、過去に数例あります。おそらく同じようなことは日本中で起きているのではないかと思われます。成功して当たり前で、最終結果しか求めない文化の中では、稀なケースではないはずです。第一、彼のプロジェクト計画の内容は、課長も含めて誰からも訪ねられていません。そこではサイズ見積もりがなされていることにも誰も気付いていません。要求仕様書の構成が変わっていることは課長には見えていたはずですが、そのことに何も注目していませんし、そこでリーダーの考えを確かめることもしていません。これが、このようなことが起きやすい組織の「文化」なのです。
「プロセスの改善に取り組んで損をした」という状態を無くさないかぎり、この組織の将来は開けません。
「プロセスの改善に取り組んで損をした」という問題を解決する方法について、私自身これまでいろいろと考えてきました。その一つの方法は、「ミッションの違い」を明らかにし、トップ（またはそれに相当する立場の人）を巻き込むことで解決することです。
組織の中には、いろいろな立場で責任を負っている人がいます。組織のトップにはトップとしての責任を負っています。部長には部長としての責任を負っていますし、課長にはもっと短期のところで責任を負っています。課長は３月までに２つのプロジェクトを終了させる責任を負っていたり、部長の方は部が扱う７つのプロジェクトを１２月と３月に終了させることが求められています。
このような自分のミッション達成に赤信号が点滅している状況のときに、納期を２週間余して終わったチームがあれば、遅れているプロジェクトに回したくなるのも無理はありません。でも、この選択は最悪の選択と心得て下さい。目先の自分のミッションを達成するために、人を腐らせてしまうことを認識すべきなのです。
とはいっても、その時点では現実には「背に腹は替えられない」状態に陥っていて、早く終わったチームやエンジニアを応援に回してしうのです。こうして、自分のマネージメントのミスを埋めるために、大事な人材を毀損してしまうのです。大事な人材を預かっているマネージャーに、このような対応で人材を腐らせることは許されません。
このような対応を止める方法として「ミッションの違い」を認識させる方法があります。
組織のトップやそれに相当する立場の人には、部長や課長のミッションとは異なるミッションを持っています。納期を達成するというような短期的な目標を達成することのほかに、中長期の視点で競争に耐えるように組織の戦力を強化し、市場や顧客の要求に応え続けるというミッションを持っています。そのために株主によって選ばれているのです。
ところが、現場の部長や課長のこうした近視眼的な対応によって人材が毀損したのでは、トップに課せられた長期的なミッションが果たせなくなります。確かに、目先の納期に対する約束を果たそうとする姿勢は大事ですが、そのことによって人材が腐ってしまうのでは元も子もなくなります。したがって、こうした現場の近視眼的な対応はトップの立場から制止べきなのです。もちろん、ただ制止するだけでは解決しません。なぜ、こうした近視眼的な対応が行われてしまうのか、その原因に遡って対応する中で、こうした近視眼的対応を止めることが大事です。
近視眼的な対応になってしまう原因として考えられることは、プロジェクトの終盤になって大きな遅れが表面化することです。そこでのマネージメントは、「問題報告型」でマネージャーからは動いていません。ただ、命令や指事を出すだけで、納期や約束を実現するために一緒になって動いていないのです。最初にサイズ見積もりも行われていないし、スケジュールの元になる工数もサイズ見積もりを根拠にしていないのです。いや、そういう見積もりの意味も理解していません。１行でも早くソースコードを書くことを求めていることも少なくないのです。そのような状況の中では毎日の作業の結果（実績値）を使って見積もりの調整もできません。そこでは、ただ「結果」だけが求められているのであり、その姿勢が、ある日突然「２ヶ月の遅れ」となって表面化するのです。
そしてサイズ見積もりが上手くできない理由は、そのプロジェクトの中で生成する「中間成果物」が見えていないことにあります。特に、「設計プロセス」に含まれる中間成果物には設計の段階に応じた成果物が存在し、種類も構成も多様になるのです。ゴールに向かうための合理的なプロセスの中で適切な中間成果物を確立しないかぎり、サイズ見積もりもできなければ、その後の実績値で調整もできないのです。（拙著「見積もりと進捗管理」Software People vol. 5 参照）
本来ならマネージャーは、こうしてプロジェクトの最初の段階から深く関わっていれば、そのプロジェクトに対して早い段階で対応できるのです。先行するチームが、サイズ見積もりから計画などをうまく考えていて、その効果として作業の滞りが少ないことが見えれば、管轄する別のチームに対しても早い段階で、サイズ見積もりの仕方を指導してもらうなどの応援を頼むこともできます。そうすれば今までのように、プロジェクトの終盤になって急に大きな遅れが表面化することもありません。
最初の計画時に支援したチームのリーダーも、別のチームのその後の進捗が気になっていますので、遅れが目立つような時にはその対応方法などで途中でも支援してくれることもあります。これこそマネージャーの姿勢次第です。また、自分達のプロジェクトが早く終わった時には、自ら進んで応援に回ってくれることもあるのです。プロジェクトの進め方が自分達のやり方に近く、様子も分かっているので応援しやすいのです。これは、早い段階で複数のチームで交流を促した効果でもあるのです。もちろんプロセスを工夫したことで当初の計画よりも早く終わったチームは、そこで余った工数はそのチームの褒美として与えるべきです。これは原則です。チームのメンバーは、その時間を使って勉強や新しい方法を練習して「次」に備えるのです。
課長や部長が、こうした判断をするためには、最初からプロジェクトの計画書の中身を知っている必要があります。その上で、作業の進行状況を把握することによって、適切な判断が可能となるのです。また、トップまたは組織の責任者は、現場の部長や課長に対して、早い段階からのこうした対応を求めることで、近視眼的な最悪の対応を許さないことが大事です。
こうした対応の結果として、現場のエンジニアとマネージメントとの間の信頼関係が築けるのです。そしてこれが実現できることは、私のコンサルティングの中で確認できているのです。
私のコンサルティングのやり方には、以下のようにいくつかの形があります。
・チームコンサルティング
・リーダーコンサルティング
・オープンコンサルティング
このほかに、プロジェクトを対象とするのではなく、リーダーとしての対応に関するコンサルティングなどもありますが、ここでは上記の３つのコンサルティング、特にオープンコンサルティングに付いて説明します。チームコンサルティング：
これは、チームの単位でコンサルティングを行うもので、事前にコンサルティングの対象に選ばれたチームのメンバー前が集まって、そこで取り組まれていることについて評価したり、アドバイスするものです。基本的には、リーダーを含めチームの全員が参加します。実際にはこのパターンがもっとも多いのですが、他のパターンを採用することもあります。
リーダーコンサルティング：
これは、チームのリーダーだけがコンサルティングの場に出てきて、彼のチームにおける取り組みの状況を確認したり、この間の対応を評価したり、改善点について話をします。チームリーダーだけのコンサルティングの形を選ぶ理由は、チームの構成が外注や派遣のエンジニアの比率が高いときにしばしば採用します。このほか、リーダーの資質に不足があったりして、チーム全員が集まって評価したり改善点を示したりすることによって、メンバーのベクトルがリーダーではなく、コンサルタントの方に向いてしまう危険があるときにも、この方法を採用します。
オープンコンサルティング：
基本的に組織の全員を集め、その前で、あらかじめ選ばれた人の取り組みを発表し、その場で彼の取り組み方についてコンサルティングする方法です。要求の仕様化やリスク管理といった個々の取り組みのテーマで発表しますので、そうしたテーマについてのコンサルティングの効率はもっとも良いのですが、逆にコンサルタントとしてはもっとも難しい方法です。成果物はそこではじめて目にするケースも少なくなく、発表されるのを見ながらすぐに良い点を見つけたり、改良すべき点を見抜かなければならないからです。でもそこで誉め方や改善点の指摘方法も見せることができますので、水平展開の環境の下地を作ることにつながります。ただし、この形のコンサルティングを実施するにはいくつかの条件が整わなければなりません。
このとき、参加者の前に公開する取り組み事例は、もっとも優れたものとは限りません。基本的には、組織の責任者が「全体最適」の視点から選ぶことになります。組織の中には、いろんなチームやエンジニアが集まっています。新しいことに積極的に取り組む人もいれば、失敗を恐れるあまりに慎重になる人もいます。これは性格が作用していることもあって、全員の足並みをそろえることはできません。だからこそ、組織の責任者にはチームや個々のエンジニアの特徴を見て、先行する人、後から付いていく人など、個人の性格や特徴を活かしながら、取り組みを行き渡らせることに配慮をしてもらいますし、私の方も、そのように要請します。
発表者を選ぶのは、基本的には組織の責任者にお願いするのですが、トップからもメンバーからも信頼されている人であればそれに代わる人でも可能です。ただしこの信頼がないと、オープンコンサルティングは白ける危険がありますし、現実にはプロセス改善の取り組みが分解する危険性の方が強くなりますので、実施できません。
一般には、一人が取り組みに先行すれば、同期入社の他のエンジニアも刺激を受けますし、先輩格のエンジニアもジッとしているわけにはいかなくなります。他の形のコンサルティングではそ他のチームの様子は見えませんが、オープンコンサルティングでは、丸ごと見えてしまいますので、「負けん気」が表面にでたりして、組織の中で動き出すのです。組織の責任者は、こうした動きを仕掛けることができます。
テーマや組織の状況によっては、すぐに要領良く取り組む人を先行役で発表してもらうことで、動きの遅いチームやメンバーも刺激されて、取り組みはじめたところで発表の機会を与えます。その時は、組織の責任者がその様子をみて判断しますので、メンバーとこの責任者との間の信頼感も生まれます。
オープンコンサルティングの場には、原則としてこの組織の責任者も出席します。そこで、成果物やプロセスの取り組みのポイントを修得してもらい、この後、現場でのエンジニアの行動や成果物を見る目を養ってもらいます。こうすることで、中間のマネージャーはうかうかできなくなります。「プロセスの改善に取り組んで損をした」というような事態も防ぐことができるのです。そして、普段からトップや組織の責任者との間で、現場での成果物や文化の変化などについて共通の話題ができるのです。
また、オープンコンサルティングでは、コンサルティングの仕方を多くの参加者は見ています。ここでのコンサルティングの仕方は、これとは別に組織におけるプロセス改善の取り組みに対するコンサルタントの信頼にもつながります。
ただし、すべての組織でこの方法ができるとは思えません。