“リーンソフトウェア開発と組織改革”を読み終えて

リーンソフトウェア開発と組織改革
Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳
アスキー・メディアワークス
売り上げランキング: 331,165


なぜリーンか
Project Management Professionalのワタシがアジャイルに手を出した後にリーンにまで手を伸ばそうとしているか、である。PMP自体、もう珍しくともなんともない。10年前とは違うのである。PIMだって PMI Agile Certified Practitionerとして認める時代なのだ。


ウォーターフォールだけでプロジェクトを回すことはできる。全く問題ない。しかし、である。全く問題がないウォーターフォールのプロジェクトのかなりの割合でなんらか問題が起きるのである。


ウォーターフォールはただの枠である。PMBOKも枠でしかない。単なるフレームワークなのである。その枠の中を埋めるものが実際のプロジェクトを左右するhowtoとknow-howなのである。プロジェクトマネージャが自分のプロジェクトを運営するとき、何をしなければならないかを知っているのであれば、そのプロジェクトではどのような道具を使って采配するか、そのプロジェクトに合ったテラーリングが出来るなら問題は起きないのである。しかし、実際のプロジェクトでは問題が起きる。小さいものから大きなものまでそれこそ問題が発現するのだ。で、当事者のプロジェクトメンバは、「やっぱり(トラぶった)。」と言うのである。


問題を呼び込むプロジェクトは、自ら招いていると言っても過言ではないだろう。成るべくして成っているのである。“育てたように子は育つ”を地でやるから“マネジメントしたようにしかプロジェクトの成果は出ない”のである。


話を戻そう。なぜ“リーン”なのか。ウォーターフォールでさえ上手くまわせないエンジニアにアジャイルやリーンは無理だ。でも、ビジネスは刻一刻と動いているという現実がある。それを支えなければならない。出来ないエンジニアに考えろと突き放しても何も生みはしないし、何の解決にもならない。役割に応じたソリューションを“しくみ”として提供する他ないのである。


ならば、ウォーターフォールを改良して少しでも現場のプロジェクトがまわせるようにしたいではないか。ただそれだけの些細な願いから“リーン”にも手を出したのだった。


プロジェクトは救わなければならない
ここそこに書き残しているけれど、上手くいっていないプロジェクトがまだ生きているなら、何とかしなくてはいけない。怪我をしている状態なら、処置をしなければならない。


その様な事態になっている大体のプロジェクトは、現状把握ができていない状況になっていることが多いので、そこから手を付けなければならないものだ。そのときに必要なアクションは、現状を把握するための“見える化”から。そして、優先順位をつけて仕事の流量をコントロールする。もちろん、並行してスタックしているプロジェクトの進捗の腫瘍となっている箇所を見極めたり、暫定的な作業計画を立てたり、終了までの見通しが立てられるようにする。


このようなプロジェクトの場合、同じチームのメンバ同士のコミュニケーションが悪くなっているものである。不思議なことに、外から見たら一目で分かるのにプロジェクトのメンバは誰一人、コミュニケーションが悪い、おかしくなっていることに全く気づいてないことが多い。だからその大差策として、朝会をするし、昼は一緒に食べに行く。外に出て気分を転換させることも必要だし、食べているときにいろいろ聴けるものだ。


ここで肝心なことは、スピードである。方針を立てるのも、状況を把握するのも、コミュニケーションを取るのも、何事にも、兎に角、急がないと症状は悪化するだけだから。

見える化、優先順位、流量、朝会、スピード。


PMPなのにスクラムもリーンも違和感なく取り込める背景
全くと言っていいほど、アジャイルな、スクラムなキーワドばかりだ。でもね、これ、ワタシは意識せずにウォーターフォールでやっていた。偶々かもしれないけれど、ソリューションサービスを提供するプロジェクトマネージャだったからかもしれない。


ソリューションサービスは、パッケージとそのパッケージを導入する業務ノウハウ持つからこそ、スクラッチ開発と比べて短期間で、が売りなのである。そこには、デリバリのスピードとソリューション業務の知見が求められる。


プロジェクトメンバとプロジェクトの全貌と一人ひとりのメンバに期待する作業と成果を共有するために、MS ProjectのWBSを当該工程の詳細まで広げて印刷して、毎朝ミーティングをしながら配ったものだ。誰かの作業が停滞していたら、朝会で判明するので、他の人の混雑状況で分担を変えるなんてそれこそ日常茶飯事だったし、作業の優先順位づけなんて、その時々で変わるモノだから、先を見ながらコロコロ変えたものだ。それを朝令暮改と言うならそのエンジニアは思慮が足らない。計画は計画を立てたときから時々刻々と変わるものだし、計画を実現するエンジニアだって日々状況が変わるのだ。


スケジュールはやっぱり、工程を枠ととらえて、その中で好き勝手にどんどん組み替えていく。それには“プロジェクトマネージャの仕事はプロジェクトが完了するまでプロジェクト計画書を更新続けることだ”と思っているからに他ならない。


ウォーターフォールという枠の上にどのようにプロジェクトを実施するかのhow-toをのせて顧客に届けるためには、その届けることの行為から生まれるモノを確実に届けるために日々の振る舞いのカイゼンとそれを営むエンジニアのマインドセットを背中から押し続けるリーダーシップが必要なのだと改めて知る書籍だ。