職人芸、あるいはブラックボックスの悲劇：組み込み開発の混沌から抜け出そう（1）（2/3 ページ）
組み込み開発の現場では、製品の高度化に伴ってコーディング量の増大や納期短縮といった厳しい現実にさらされている。ソフトウェア開発に新しい手法を導入しなければ、今後の組み込み開発は行き詰まってしまうだろう。本連載では、組み込み開発の従来手法で何が問題なのかを洗い出し、次なる一歩を踏み出す前提条件を明らかにする。
あなた次第の工数見積もりのツケ
コンシューマ向けの製品は、メインの製品を中心に、いくつものシリーズを作ります。海外市場に合わせたカスタマイズ製品も作りますし、1年後には上位バージョンの製品化の予定もあり、別のグループは並行してそのための準備を始めているなど、開発は複雑を極めます。プロジェクト全体では数百人になる、あるメーカーでの話です。
派生するシリーズを担当する2つのグループは、ベテラン技術者をリーダーにメンバー構成は両グループともにほぼ同様です。違っていたのは、一方のグループに新人を投入していたことです。開発の後半になって、テスト担当者から声が上がりました。新人を投入したグループだけ、障害が著しく多いというのです。
テスト担当者 「どうして、こんなに出来が違うの？」
それだけではありませんでした。その時点で一方の進ちょくは2週間遅れ。これは根性で乗り切れるレベルではありません。
テスト担当者 「そもそもこの部分の工数見積もりが、おかしいんじゃない？」
担当者によって、品質が違っていいはずはないのですが、実際そうはいかないのが現状でしょう。例えばこのエピソードでは、工数の見積もりが各担当者の判断で行われ、新人のそれが適正でなかったために、大幅な遅れとなり時間がなくなった。時間が足りないから、コーディングした本人によるチェックは十分に行われず、テスト段階で火の手が上がったということです。
猫の手も借りたい現場にとっては、新人でも重要なリソースです。OJTということで早々に現場に投入されたものの、リーダーの背中を見て仕事を覚えろといった開発現場の伝統だったため、このような事態になったのかもしれません。初めにたっぷり新人教育をしろというのも、現実的ではないのでしょう。とにかく、時間がないのですから。
さて、このプロジェクト、もちろん納期は決まっているので、新たに技術者を投入せざるを得ません。その結果、ほかのグループのリソースを圧迫することにもなり、プロジェクト全体の進ちょくに大きな影響が出てしまいました。
コミュニケーション不足が人手不足を加速させる
同様にシリーズ製品の並行開発が行われている現場の話です。なんとやらの法則なのか、いつも納期が近づくと大問題が持ち上がります。
テスト担当者 「同じ機能なのに、このグループからだけバグが出てる。どうして？ こっちはデグレードしてる。このバグ、前のリリースでは直ってたよね」
このデグレードが、亡霊のようにいくつも現れるのです。
リビジョンやリリースの管理が混乱を来しているようです。直接的な原因は、担当者のミスなのかもしれませんが、実はこれは深刻な問題です。リビジョンやリリースの管理は、表計算ソフトなどを使って行われていることが多いようですが、手段の問題というよりも、担当者任せであることが品質の差を生んでいる原因なのでしょう。
さらに続きがあります。
デグレードがきっかけとなり、プロジェクト内の各グループの状況を調べてみると、同じようなモジュールが、あっちのグループにも、こっちのグループにも存在します。
テスト担当者 「ということは、一度で済むことを、みんなでやっていたということ？」
開発担当者 「そういうことになりますね」
テスト担当者 「お互いに連絡することになってなかったっけ？」
開発担当者 「連絡はしてました、メールで」
情報の共有をどうすべきかという議論はさておき、今回のプロジェクトを何とかしなければなりません。でも、この段階で、モジュールを一本化するのはリスクが高い。安直に手を付けたら、関連するほかのモジュールにも影響が出るかもしれないし、どれだけの工数が必要なのかすぐには判断できません。
テスト担当者 「今回は、このままでいくか」
結局、そのまま突っ走ることになりました。
モジュールの種類がたくさんあるということは、それだけテストの工程も必要ですし、障害も相応に出てきます。プロジェクト全体で考えると、どれだけの工数を損していたことになるのでしょう。
よく情報共有といいますが、このエピソードでは何もしていなかったわけではありません。必要に応じてメールで連絡するというルールはあったのです。でもメールは「シロやぎさん」と「クロやぎさん」のような連絡手段であり、相手が「読んだか、理解したか」は保証の限りではありません。「読まずに食べた」ではなくても、毎日たくさん送られてくるメールを見落としていないか怪しいものです。
同じように見えて、微妙に異なるモジュールがたくさん存在するこのプロジェクト。これをベースにした次バージョンがあるとしたら、それもきっと困難なことでしょう。
Copyright © ITmedia, Inc. All Rights Reserved.