　例えば、何かトラブルが発生したとしましょう。すると、一見柔軟と思える対応策を取ることになり、それなりにトラブルは片付いたかにみえるのです。しかし、問題はその後にありました。何が悪かったのかを分析しようとしません。メンバーからの週報や週1回の会議など、問題を掘り下げる機会はあるはずなのに、問題の原因を知ろうとしないのです。

状況

　しかも、状況はもっと深刻でした。ここには、ソフトの開発者だけで30人程度が在籍しています。メンバーの多くは、ずっとこのA社の中で仕事をして育ってきています。中途採用の社員はもともと少なく、この悩み多き課長が久しぶりの中途採用でした。長い間この状況の中に漬かっているおかげで、メンバーはこの状態に疑問を感じていないようにみえます。気付いていないだけなのか、あるいは気付いていても声を上げる勇気と元気を失っているのか、それとも、これが楽だからなのか。いずれにしても、この状況は一種の「企業文化」となってしまっているのでした。

　現象は「不具合」という形でも表れていました。最近の不具合の多さは、A社内の品質保証部から指摘を受けていました。もちろん現場が気が付いていないはずはありません。しかし、現場のいい分は「時間が不足している」でした。開発に費やせる時間は、突然割り込んでくる仕事のせいで圧迫され、日程は遅れ、テストの時間が十分に取れないという説明です。

　しかし、不具合の指摘は、社内からだけでありませんでした。A社で作っている製品は、一般コンシューマー向けではありません。ある限られた工場などで使用する特殊な、大掛かりな機器です。基本機能は共通でも、納品先の企業によってカスタマイズする部分も多く、オーダーメイドに近い状態となっています。納品先は、国内にとどまらず、アジア各国にも顧客企業を抱えています。

　もし、納品後にトラブルが発生すると、顧客からA社のサポート窓口に直接問い合わせが寄せられます。すると開発担当者は、事実関係を確認したり、トラブルを解決するための策を打たなければならず、場合によっては顧客企業に出向くこともあります。一方営業からは、顧客からの要求がどれもこれも「優先度　高」で、容赦なく押し寄せるのです。

　実際に開発者は、彼らの本業ともいうべき「開発」の作業を実質半分程度しかできていない様子です。ですから、当初は2日でできると考えていた作業が4日かかり、その結果として後工程にしわ寄せが来るのはうなずけます。残りの半分は、不具合対応、お客さまからの問い合わせ対応、営業からの変更要求対応に費やされているというわけです。

すれ違い

　現場のこの空気を、「開発のルール」という目で冷静に見てみると、ソースコード以外の成果物が何も規定されていないことが分かってきました。例えば仕様書は、要求仕様と機能仕様と詳細仕様が混然一体となったような状態です。しかも、作成者によって粒度、密度がばらばら。後工程の時間が圧迫されているという以前に、上流工程がまったく体を成していないのでした。これでは、精度の良いソースコードは無理。不具合も出て当然だし、変更やトラブルへの対応も場当たり的にならざるを得ません。

　「プロセス」について語り掛けても、現場にはそんな概念は存在していないようで、話がかみ合いません。開発者たちは、時間がないことや割り込み作業が多いことが品質低下の原因だと考えており、自分たちのやり方に問題がないかを見直そうとは考えていませんでした。

ソースを書いた方が早いですから。

　それも確かだけれど、それでは状態は悪くなるばかりです。ルールを整備する時間がないから、不具合が出る。その対応に追われているので開発の時間が圧迫される。開発の時間が圧迫されているから、ルールを整備する時間がない……どこが発端かはともかく、負の方向に転がっていることだけは事実でした。

　　　　　　 1|2|3 次のページへ