ｱｲﾌｫｰｽ･ｺﾗﾑ No.6 ｢巨大ｼｽﾃﾑ開発に挑む｣　その2

数Mｽﾃｯﾌﾟの大規模ｼｽﾃﾑ｡

しかも短納期･･･その苦境を打開し､成功に導いた秘策とは？

昭和64年｡そう､平成元年の年である｡

昭和天皇崩御の号外を手にしながら､我々は､再度､某通信機ﾍﾞﾝﾀﾞｰの工場に集まり､一気にSDHｼｽﾃﾑのｼｽﾃﾑ試験を開始することとした｡

このｼｽﾃﾑ試験の準備にも時間をかけた｡ﾓｼﾞｭｰﾙA､B､C､D1､D2の全てのｼｽﾃﾑを同時に開発していたため､総開発規模は数Mｽﾃｯﾌﾟに及び､ｿﾌﾄｳｪｱｴﾝｼﾞﾆｱ､ﾌｧｰﾑｳｪｱｴﾝｼﾞﾆｱの数も総勢200名以上となるﾁｰﾑであった｡

このような､類稀な大規模ﾌﾟﾛｼﾞｪｸﾄでは､従来技法では歯が立たない｡潜在するﾘｽｸが予測できないからである｡約１０万項目に達するであろうｼｽﾃﾑ試験工程に備えて､私はある作戦を思いついた｡その作戦とは､次のような内容である｡

【大規模短工期開発への作戦】

ｼｽﾃﾑ試験企画ﾁｰﾑを設計工程から準備
ﾄﾞｷｭﾒﾝﾄ整備ﾁｰﾑの常設
製造工程要員は全員新入社員

経験深いﾍﾞﾃﾗﾝ･ｴﾝｼﾞﾆｱの方が見れば､なんとなく言わんとすることが分かっていただけるかと思う｡

まず､本来ｼｽﾃﾑ設計者が､ｼｽﾃﾑ試験の企画を行うのだが､10万という項目数の分量から見て到底無理｡しかし､何とかして数か月の間に､全ての機能を確認すべく､ｼｽﾃﾑ試験項目と手順書を作成しなければならない｡

ﾍﾞﾃﾗﾝの技術者を担当させたいところだが､逆に血気盛んな新入社員だけのﾁｰﾑ5名を組織し､このｼｽﾃﾑ試験企画ﾁｰﾑとすることにした｡

基本設計の最初の工程から､全ての社内ﾚﾋﾞｭｰ､ﾍﾞﾝﾀﾞｰとの定例会議､ｴﾝﾄﾞﾕｰｻﾞｰとの定例会議に出席させ､議事録を記録する事から始めた｡こうすれば､設計当初から議論されているIssueを逃さず聞き取ることができる｡すなわち､設計段階で問題視されていた技術的に難しい部分や､他の要因で開発が困難な部分が､明確に確認ができるのである｡

この｢設計時に問題としていた｣機能というのは､意外にも開発工程の後半では忘れ去られてしまうものである｡しかし､ﾌﾟﾛｼﾞｪｸﾄのｸﾘﾃｨｶﾙ･ﾊﾟｽそのものである事には間違いない機能なのである｡

多くのﾌﾟﾛｼﾞｪｸﾄで､当初問題にしていた機能と､さほど問題ではない部分と､ｼｽﾃﾑ試験では公平に扱う場合が多い｡試験密度でいえば､どちらの機能も公平な密度で試験する事が一般的だったからである｡しかし､考えてみればこの事は矛盾しているのではないか｡当初から問題視されていた機能は､ｼｽﾃﾑ全体の要であるはずで､かつ､そのﾌﾟﾛｼﾞｪｸﾄのｸﾘﾃｨｶﾙ･ﾊﾟｽなのである｡

したがって､他の機能と比較して､より念入りに多方向からの試験を行う方が合理的ではないかと考えた｡特に､少数のｴﾝｼﾞﾆｱで構成されるﾌﾟﾛｼﾞｪｸﾄでは､開発を担当したｴﾝｼﾞﾆｱ自身が､自分の開発担当部分の試験手順書を作成するｹｰｽが多い｡自分自身を､自分でﾃｽﾄするなど､まかり通るのはｺﾝﾋﾟｭｰﾀｼｽﾃﾑ開発の分野だけではないのか｡

第三者が､ﾁｸﾁｸと痛いところをつつくようにﾃｽﾄして､初めて品質の高いｿﾌﾄｳｪｱが完成するのではないかと思う｡そういった環境を実現するために､ｼｽﾃﾑ試験ﾁｰﾑを設計当初から組織したのである｡

効果はすぐに現れた｡血気盛んな新人ﾁｰﾑである｡まだ､社会人になって間もない｡したがって経験もなければ実績もない｡しかし､何とか先輩社員から認めてもらおうとする熱意と､ｼｽﾃﾑ全体を理解しようとする探究心は､10年選手の比ではない｡瞬く間に､ﾁｰﾑﾘｰﾀﾞｰよりも､さらに詳しく全体を把握できる情報量を持つようになったのである｡

当然である｡毎日､議事録を書き､理解できない言葉があれば､徹底的に勉強するのだから｡しかも､新入社員である｡歯に衣を着せぬとはこの事で､言い難いことも平気で発言する｡

｢先週の会議では､こういう約束がされていましたができていますか？｣という具合である｡

ﾍﾞﾃﾗﾝ･ｴﾝｼﾞﾆｱ､あるいはﾏﾈｰｼﾞｬであれば､まあ､そこまで確認しなくても｢きっとやっているだろう｣と高を括るｼｰﾝである｡

そう､この歯に衣着せぬ態度､どんな些細なことでも進捗を確認する態度こそが､本来のﾌﾟﾛｼﾞｪｸﾄﾏﾈｼﾞﾒﾝﾄのあるべき姿なのである｡

10年経験を持つ有能（と言われている）ﾏﾈｰｼﾞｬができない事を､数か月前に入社した新入社員がやってのける姿を見て､私は確信を持った｡経験は人の能力を鈍化させる場合がある･･･しかも､その本人はその事に気がつかないであろうという事に｡

2番目の策として､ﾄﾞｷｭﾒﾝﾄ専門ﾁｰﾑを組織した｡

大量の設計ﾄﾞｷｭﾒﾝﾄ､ｿｰｽｺｰﾄﾞ､ｿｰｽﾘｽﾄ､議事録･･ありとあらゆるﾄﾞｷｭﾒﾝﾄの管理をそのﾄﾞｷｭﾒﾝﾄﾁｰﾑの絶対権限の配下に置いた｡

良くある話だが､ﾍﾞﾃﾗﾝ･ｴﾝｼﾞﾆｱほどﾄﾞｷｭﾒﾝﾄを書かない｡書けないのではなく､書かないのである｡当然､基準となる書類がないのだから､ﾁｰﾑ内のｽﾀｯﾌの情報に差異が出てきてしまう｡その差異を指摘して叱りつける仕事が､ﾍﾞﾃﾗﾝ･ｴﾝｼﾞﾆｱのﾍﾞﾃﾗﾝたる姿であると勘違いしている場合がある｡

大規模開発では､毎日のように大量のﾄﾞｷｭﾒﾝﾄが更新される｡いや､更新されなければならない｡このﾄﾞｷｭﾒﾝﾄの更新を機械的に完全な形で実施するために､以下のような規則を作った｡

ﾄﾞｷｭﾒﾝﾄを修正するときは､赤ﾍﾟﾝを用いて､修正ﾏﾆｭｱﾙの規則に従って修正する｡

赤入れされたﾄﾞｷｭﾒﾝﾄは､翌日までにﾄﾞｷｭﾒﾝﾄﾁｰﾑが査閲し､ﾏﾆｭｱﾙ通りに修正されている部分のみをﾜｰﾌﾟﾛで更新し､最新ﾄﾞｷｭﾒﾝﾄとしてﾌｫﾙﾀﾞする｡

最新ﾄﾞｷｭﾒﾝﾄは､ﾄﾞｷｭﾒﾝﾄﾁｰﾑの許可なくして持ち出しはできない｡

このたった3つの規則で全てが上手くいった｡

ｴﾝｼﾞﾆｱは慎重に赤入れを行う｡ﾏﾆｭｱﾙには事細かに修正方法が記載されているので､自分が修正したい事象に合った修正方法はどれに当たるのか探すことになる｡探しながら､考えるのである｡考える事が品質につながるのである（ああ､他の場所も修正しなくてはならないなと気がつく）｡

ﾄﾞｷｭﾒﾝﾄﾁｰﾑは､規則通りに赤入れされたﾄﾞｷｭﾒﾝﾄのみを､正本へ更改する｡どんな偉い先輩ｴﾝｼﾞﾆｱが入れた赤入れだろうと､規則にしがっていなければ｢却下｣として突き返されるのである｡

こうする事で､ﾄﾞｷｭﾒﾝﾄはどんなに大量であろうと､常に最新の状態を保つことが可能になった｡

くだらないと思われるかもしれないが､常に最新の状態のﾄﾞｷｭﾒﾝﾄなど､今の時代､ｲﾝﾀｰﾈｯﾄが普及したこの時代であっても稀なのである｡そして､ﾌﾟﾛｼﾞｪｸﾄを成功させるためには､絶対的な条件なのである｡

3つ目の施策は､積極的に新入社員を担当させたことである｡

もちろん複雑で高度な設計工程では､経験のないｴﾝｼﾞﾆｱでは太刀打ちができない｡しかし､詳細設計工程以降､特に製造工程以降では､そのｴﾈﾙｷﾞｰは爆発的な効果を生み出すのである｡

この文章を読んでいただいている貴殿が､ｼｽﾃﾑ開発のﾍﾞﾃﾗﾝであったなら､製造工程で担当するｻﾌﾞﾙｰﾁﾝの全てのﾌﾛｰﾁｬｰﾄ､ﾃﾞｰﾀ定義書､ｲﾝﾀﾌｪｰｽ仕様書を書きなさいと言われたら､実施しますか？

あるいは､それらのﾄﾞｷｭﾒﾝﾄをﾁｰﾑ内でﾚﾋﾞｭｰし､議事録を提出しなさいと言われたらできますか？

出来上がったｿｰｽﾘｽﾄをﾌﾟﾘﾝﾄ出力し､ｳｫｰｸｽﾙｰﾚﾋﾞｭｰをしなさいと言われたら､やりますか？

そう､ﾍﾞﾃﾗﾝのｴﾝｼﾞﾆｱになればなるほど､こういった基本的な作業を嫌がるものである｡

基本に従わなくても同じ品質のｿﾌﾄｳｪｱが作れるというのが､自称ﾍﾞﾃﾗﾝの連中の言い訳なのである｡

私から言わせれば､本当のﾍﾞﾃﾗﾝとは､基本を忠実に実行し､さらにその上で経験やﾉｳﾊｳを生かせる人の事をいう｡

新人ｴﾝｼﾞﾆｱは､もちろん真剣なまなざしで基本作業を忠実に実行しようとする｡そして一つ一つを誰よりも丁寧に実行しようと考える｡

私は､このSDHﾌﾟﾛｼﾞｪｸﾄでは､ﾍﾞﾃﾗﾝの勘や経験よりも､基本に忠実であることを重要視し､この方策を実施した｡実際には､製造工程に倍近い時間が必要になったが､しかし､品質は倍以上に優れたものになったのである｡