バラバラエンジニアのプロジェクトマネジメント（3） ～プロジェクトは生き物！開発期間・費用を半分にしたSさん～
今年も残すところ、あと僅かとなりました。来年もよろしくお願いいたします。
前回、開発に関わるメンバーで「製品コンセプトから青写真」をきちんと共有することが大事であるとお話をしました。
自動車のエアバッグの加速度センサーを例に、たったちっぽけな部品1つをとっても、何に使われるのか、正常に動作しなかったら命に関わることだと考えながら、設計をする・組み立てることがいかに重要であることなのか、エンドユーザーを常に意識ながら、丹精込めて作り上げることが「モノには魂が宿る」と言われる所以でもあります。
ハード屋、ソフト屋、メカ屋のやたら自己主張が強く、プロジェクトとしてもバラバラでまとまりがなく開発もいつも遅れ気味だったチームを、プロジェクトリーダーとして見事にチームをまとめあげて、いち早く製品を市場に投入し成功を収めた。そのSさんが何をやったのかを、今回はご紹介します。
■開発期間、開発費用ともに半分でやれ！
「製品コンセプトの共有が大事」と今も言い続けるSさんは、メーカーの開発部門の管理職です。自らもまだ第一線で設計業務に携わっています。部下育成にも熱心で、仕事の後も部下を誘って、大好きな日本酒を飲みながら、部下の良き相談相手になることもしばしばです。
Sさんの部門が開発する製品規模は年を追うごとに大きくなってきました。ハードのスペックだけではなく実装ソフトの高機能化、機構部品の高信頼・高耐久性化など、理由はさまざまです。
加えて、市場の競争はより激化し、マーケットニーズを素早くキャッチし、タイムリーに市場に製品を投入することが求められます。おのずと開発期間の短縮化は必須です。
このSさんが新たに開発のプロジェクトリーダーを務める新製品プロジェクトに最初に課せられた命題は、「従来1年かかっていた開発期間を6カ月で行え！」というものでした。
■常識的に考えると「できるわけがない」
よく、ソフトウェア開発の工数見積で「○人月」という考えを頭に描いてしまうと、同じ開発規模として、開発期間が半分でやれとなると単純に、「2倍の人が必要です」となります。Sさんも最初は倍の開発リソースが必要だなと考え、経営層に掛け合いましたが、返事は開発期間短縮だけではなく、「開発費も削減で従来の半分で行うように！」と、余計なおまけまでもらってきてしまいました。したがって、メンバーの追加もあり得ないとのこと。
開発会議ではこんな予定ではなかったのになと思いながら、今回のプロジェクトが「開発期間、開発費用ともに半分」とプロジェクトメンバーに伝えたら、大ブーイングが起こるだろうと予想していました。なにしろ、昨今の不景気の影響もあり、開発現場には時間短縮のあおりで残業規制がかかっています。時間短縮であっても、仕事が減るわけではないので、サービス残業をしながらしのぎを削ってきたわけなので。
「開発期間が半分の6カ月に、人は今のままで増えない、費用は半分で実現する」
現場はすんなりと受け入れてくれるでしょうか？
受け入れてくれたとして、はたして実現できるのかも心配です。
■プロジェクトは生き物である
このSさんは、製品開発に必要なスキルや知識は当然、重視します。しかし、最も重要視するのは「人」であり「チーム」です。若手の育成、チームとしての成果を大事にする人です。
Sさんの口癖は「プロジェクトは生き物だ。プロジェクトを構成する人により、どうにでも変わりゆく性質を持っている」です。長年、多くの難題プロジェクトに関わりながらも成功に導いてきたSさんの言葉だけに、シンプルな言葉の中に秘められた何か大切なものがあるようです。
人が大事なことは、言われなくてもわかっているよ！と言う読者のかたも多いことでしょう。しかし、人を大事に丁寧に扱ったからといって、十分に能力を発揮し、素晴らしい製品を作ってくれるかどうかとなると、そんな単純なものではないはずです。
生き物には息吹きがあるように、Sさんがこのプロジェクトにどのように魂を入れていったのかをお話します。
■最初は主義主張ばかり
もともと、Sさんの開発部門は主にソフトウェア設計部隊で、そのほとんどが組込みです。他にハード設計を行う部門と、メカ・駆動系の設計を行う部門があります。わかりやすくするために、「ソフト屋」「ハード屋」「メカ屋」と呼びます。
プロジェクトの総勢は外注の協力会社を入れると50名近くになるものです。皆、それぞれ一癖も二癖もある連中です。全体の打合せにおいても、自部門の主義主張ばかりで、これまでも建設的なディスカッションができた例がありません。
「そんな仕様じゃできないよ」「だから、相談しているのに、そんな言い方をするならいいよ」と、普段からお互いに仲が良くないので、開発期間は半分・費用も半分ということを話したら、火に油を注ぐようなもので、その怒りの矛先は全部、Sさん自身に向かうことも予想していました。
■ビジョンを作り「軸を共有」
なんとなく先が思いやられそうなSさんですが、最初に行ったことがプロジェクトビジョンを作ることから始めました。
なぜ、この製品が必要かをプロジェクトの核となるメンバーだけで決めるのではなく、全員で決めるというやり方を取りました。当然、最初は自部門の主義主張が強いメンバーばかりなので、そうすんなりとはいきません。まして、メンバーも50名近くいます。
そこでSさんが行ったこと。まずはチームづくりを最優先し、このプロジェクトで何を目指すのか、1人ひとりの思いを語ってもらい共有しました。
これは当社でもよく似たやり方を行いますが、「軸を共有する」ということに他なりません。軸がぶれたら、都度、仕切り直しが必要となるので半年で開発を終えることなど到底無理だとSさんは考えたからです。
「ぶれない軸を作る」ことは、軸が共有できていれば、開発途中で問題が発生したり迷いが生じても、「最初はこうだったよね！」と原点の立ち位置に戻ることができます。
このプロジェクトビジョンはプロジェクトが終了するまで、模造紙に書いて、開発現場の壁に張っておきました。
■コンセプトづくりに徹底的に時間をかける
次に取りかかったことは、製品コンセプトを作ることです。
今まではマーケッティング部門からの要求をそのまま鵜呑みにして、いきなり製品に搭載する機能を決めて、仕様も決めていました。
したがって、開発部門としては技術者の冥利で、ついついオーバースペックのものを作ってしまったり、お客様がほとんど使いもしない機能を盛り込んでしまったりすることも少なくありませんでした。結果、開発工数やコストもかさみます。
Sさんが過去の開発事例を丹念に調べてわかったことは、開発日程に遅れが生じる要因は、基本的な仕様のミス解釈や出来・不出来ではなく、オーバースペックや過剰機能によるものが原因でした。
要は、Sさんは開発者がお客様や市場のニーズを、自分自身で咀嚼し切れていないということを問題視し、核をきちんと固めるために製品コンセプトを、開発者自らで作ることに徹底的に時間をかけることにしました。
誰かが作った、上から落ちてきた製品コンセプトではなく、自分たちで考えた製品コンセプトをまとめあげるプロセスに時間をかけ、開発プロセスの中に挿入することで、先のプロジェクトビジョンである「軸」はより強固なものとなるわけです。
■コンセプトづくりを通じたイノベーションを生む仕掛け
コンセプトづくりも先のビジョンと同じで、全員で行います。
表現も自分たちの言葉が少しでも生のまま残るようにします。こうすることで、「あれ、僕の言ったところ」「私が考えたもの」と、人のものではなく自分のものとして受け止めることもできるようになります。
少し話が飛びますが、イノベーション(革新)とは急に生まれるものではありません。また、たった1人の天才が生み出すものでもありません。そして、たった1人でイノベーションを実行できることもありません。
仲間が必要で、仲間のコミットメントを得ながらリーダーがまとめあげて実行していくものです。そこには「腹に落ちるプロセス＝納得するプロセス」が必須です。
Sさんはコンセプトづくりを通じて、納得するプロセスを作り出すことを行っていたわけです。他人事ではなく、自分たちのプロジェクトであるという動機づけをしたことに他なりません。
■プロセスを共有することの一体感
先のビジョンづくりとコンセプトづくり。この時間に実に2カ月近くを費やしました。周りからすれば、いつもみんなで集まって何かやっているなと思いながら、なかなかプロジェクトが進展している様子でもないしと思っていました。同時に、どうせ半年で開発なんて、できっこないじゃんと決めつけている人も、メンバー以外にいたかもしれません。
ここでポイントとなることは、先のビジョンやコンセプトはSさんからメンバーに落としたものではないことです。自分たちがどうしたいか？を考えて、作り上げるプロセスをメンバーで共有しているということです。
この理屈は単純です。人は決定事項を告げられて、「はいそうですか」と素直に受け入れられるものではありません。きちんと途中の過程にも参画し、見聞きしながら、そこに少しでも自分の言葉や考えが反映されていると、強力な動機づけとなります。
皆さんも学生時代に学園祭や体育祭などで、クラスみんなで1つの目標に向かって、何かを製作したり、放課後遅くまでクラスメイトと一緒に時間を過ごしたかたもあることでしょう。その時にどんな効果があったかを思い出してみてください。 出来上がった時の達成感も一際でしょうし、取りかかった後では「一体感」がより強くなったという経験をお持ちの方もいることでしょう。
このようにプロセスを共有することは、組織論で言うところの「チームビルディング」の1つの方法論です。当社も「プロセス共有型コンサルティング」とうたっていますが、現場の参画意識やモチベーションを高める、当事者意識を醸成するためには、プロセスを共有するということはとても重要です。「やらされ感」もほとんど発生しなくなります。
■急がば回れ！
かなり遠回りをする開発プロジェクトのように見えますが、、具体的な課題がある中で、常識的に行ったら絶対にできそうにない、今回の開発の例で言えば、開発期間が間に合わない開発費用もオーバーしてしまうという時など、場面によらず高い効果を出します。これは我々の経験則からも全く同じことが言えます。
こちらも理屈はシンプルです。最初から仲たがいしている者同士で、一緒に仕事をしてもトラぶるのは目に見えています。プロセスを共有し、作り上げるという共同作業を通じて一体感を作り出す。別の見方をすれば、Sさんはプロジェクトをダシに使って、組織づくりと人づくりもしていたわけです。
「急がば回れ」という諺がありますが、開発期間が短く急いでいる時だからこそ、省略してはいけないプロセスであると我々もSさんも考えています。
■開発コスト、コミュニケーションの見える化
もう1つ、開発コストの半減もテーマです。
何をやったかと言うと、開発コストの見える化です。表計算ソフトでカッコ良く作ったものではなく、かなりアナログ的な手法で、模造紙と付箋紙の世界です。
製品構造はこう、そこにはこんな機能があり、この機能を実現するためにはいくらかかっているか？「機能 vs．スト」チャートのようなものを作り、それがお客様や市場が要求するレベルに達しているか、技術者の思い込みでオーバースペックになっていないかなどを徹底的にディスカッションします。
この行為を通じて、積極的なコミュニケーションも図ることができます。最初は仲が悪かった部門同士でも、この頃になるとハード屋だけで実現できない要求機能は、ソフト屋とも仕様書を作る前に相談しながら進めるという、今までの開発手法とは違う動きが出始めます。そこにメカ屋が加わることもあります。
細かなことは割愛しますが、部門間を行き来するものは図面や仕様書だけでは、無機質ですよね？ モノはできるかもしれないですが、何かトラブルが発生した時には「うちは正しい、そっちが悪い」となるわけですから、最初から総動員しておけばいいわけです。トラブルシューティングの時間も極端に短くなります。
■過去最速、最低開発費で実現
これら、さまざまな仕掛けを行いながら、Sさんがリーダーを務める製品は、過去最速、最低の開発費で商品化を実現しました。
現在、この製品は競合他社の追従を許さずダントツ1位となっています。
開発に関わるメンバーも達成感が高いことはもちろん、誇れる製品開発に携わることができたと言っています。社内の他部門の開発部門からは、このプロジェクトがなぜ成功したのかを学ぼうと、Sさんに聞きに来ます。
■プロジェクトを生かすも殺すもあなた次第
最初はバラバラのエンジニア集団を、新製品開発プロジェクトで見事に1つにまとめあげたSさん。技術も面白いですが、人と組織は明確な正解がないので面白いですねと話していました。
「プロジェクトは生き物」だと言っていたSさん。 実際には、本コラムでは書き切れないほどの、小さな仕掛けをあちこちに仕掛けています。
バラバラエンジニアのプロジェクトマネジメント。プロジェクトという生き物を活かすも殺すもあなた次第です。人は理屈では動かず、共感・共鳴して始めて動く。強制力では決して良いものはできないという教訓でもあります。
さて、次回は2012年1月の予定です。良い年末年始をお迎えください。
コラムニスト：株式会社カレンコンサルティング 世古 雅人