　この開発部隊は総勢20人程度。当然、ベテランもいれば若手もいます。そして、常に10以上のプロジェクトが同時進行しています。メンバーは常に、複数のプロジェクトを担当しているという、組み込み開発ではよくありがちな現場です。1つのプロジェクトを構成する人数は、1人の場合もあれば、5人程度の場合もあり、さまざまです。

状況

　現場のメンバーは常に作業に追われ、進行はいつも遅れている。メンバーは、愚痴をいうことはあっても、開発現場なんてどこでもこんなもんだろうという程度にしか考えていないようです。ただ、決して効率が良いようには思えないし、確証はないけれど、みんなが、そのときに一番しなければならないことをしているとは思えない。そもそも「一番しなければならないこと」どころか、自分のかかわっているプロジェクトが、現在どこにいるのかすら見えていないのではないか……リーダーはそう感じていました。

どうしていつもこんなに作業に追われてしまうのだろう。

　それぞれの開発作業は関連や依存関係を持っており、複雑に絡み合っています。そのため、1つの作業の遅れが、プロジェクト全体の進行にも影響を与えてしまいます。影響は、そのプロジェクトの中だけでは片付きません。

　「Aプロジェクトが大幅に遅れているらしい。このままでは収拾がつかないから、Bプロジェクトから1人回そう。Bの方はまだ少し余裕があるから」。こうして、Bプロジェクトから1人の助っ人が駆り出されます。しかし、これがもとで自分が担当していたBプロジェクトの作業が遅れてしまい、その影響で今度は、Bプロジェクトが窮地に立たされます。すると、「Bプロジェクトが大幅に遅れているらしい。このままでは収拾がつかないから……」。プロジェクトは、もうすぐ納期を迎えるものもあれば、始まったばかりのものもあります。そのため、常にどこかのプロジェクトが窮地に立たされているような状態です。

不安

　最悪なのは、作業の「見落とし」です。作業をブレークダウンする段階で、綿密に洗い出したつもりでも、検討し忘れている、あるいは見落としている作業が出てしまいます。しかも、たいがい開発工程の後半になってから発見されるという状態です。それを、そもそも遅れ気味の作業の間に無理やり押し込むのですから、窮地に立たされるのも無理はありません。

少し遅れ気味
まだ取り戻せる
大きなトラブルがなければなんとかなる
かなり遅れている
納期に間に合うかどうか

　作業遅れの「深刻度」は、いつも感覚的にしか表現できず、正確に把握できていないのが実情です。誰がどの作業をしているのかすらリーダーには分からない。開発途中の本当の進ちょく具合は、まったくといっていいほど見えていないのです。

そもそも、計画が間違っているのではないだろうか。

　いつも作業が遅れるということは、そもそも計画を立てる段階で工数や時間の見積もりが間違っているのではないかと、リーダーは思いました。予定をはるかに遅れてしまうスケジュールも、作業の見落としも、そのベースとなる計画に問題があるはずだと。

　しかし、プロジェクト計画や工数の見積もりについて、ソフトウェア工学的な知識をメンバーに教育しても、すぐに実践できるようになるとは思えません。また、いくつもある開発手法のうち、どれが自分たちのプロジェクトの粒度に適しているのか、それをそのまま適用していいのかどうかも分かりません。開発手法の勉強に専念できるまとまった時間も取れないし、現場の改善につながるのは遠い先になってしまうでしょう。確かにアカデミックな手法は正しいのかもしれないけれど、自分たちには無理があるような気がするのです。

決断

でも、何かを始めなければ、どこかで軌道修正しなければ。

　そう、誰かが腰を上げて修正しなければ、このままの状態が続いていくのは間違いありません。少しずつ仕事量が多くなっているのは間違いないし、綱渡り的な状態でいつまで持ちこたえられるのか、リーダーには危機感がありました。とはいえ、何から手を付ければよいのか。問題はほかにもいろいろあるし、メンバーにはメンバーのいい分もあります。それに、プロジェクトは常に進行していて、リセットできるわけではありません。

　もう一度、自分たちの目の高さで、問題を考えてみました。いま誰が何の作業をしているのかがよく分からない。どのプロジェクトがどのフェイズにあり、どれくらい遅れているのか、はっきりしないといった状況です。その結果、メンバー1人1人が抱えている山ほどの作業のうち、何を優先すべきなのかが、まったく分かっていないのです。

まず、きちんと知ることから始めてみよう！

　こうして、改善のための第一歩が始まったのです。

　　　　　　 1|2|3 次のページへ