おはようございます。
最近の3回の記事で、第6章の第1節から第5節までの説明に加えたいことは終わりました。今日はこの6節まで飛びます。その説明内容は今日の記事の題名で分かるかもしれません。読む必要はないかも。
この節の内容をまとめると、要求仕様書ができたら、その要求仕様書を再利用することが効果的、効率的、となります。技術部隊が開発を始めました。仕様書の作成は終わりました。試作品ができあがるまで、企画は少し余裕ができました。
開発が一つスタートすると、事業部長から類似システムの検討を指示されることが普通でした。決断は全て3分でしろと言うのが彼の持論でした。ダメなら指示を修正しろと言われました。小型化し低価格化する、既存の商品の後継モデルへ一部の新機能を搭載するなどなどありました。企画にとって、要求仕様を変更するのは容易でした。しかし、事業部内だけでは技術者が足りません。
そこで企画が社内の研究所や他の会社に出かけ、その機能を開発してもらえないか調査することになりました。一部の機能の開発は外注化も可能です。事業部内の開発チームや緊急プロジェクトチームは今の仕事に集中でき、開発を早められました。彼は迷うと決断をしないのは間違い、迷ったら両方をするのが正しいと何時も言っていました。技術部の人は大変でしたが、売れない商品があると、次の改良モデルをすぐ開発でき、事業としてはOKになりました。
普通、商品は軽薄短小となり、高度になり、ソフトの比重が増します。電子システム手帳やノートブックパソコンが良い例です。ワープロもファクシミリも複写機もでした。新しい素材もどんどん使われました。信頼性テストで合格した商品も不具合が見つかるのが普通でした。ファクシミリは全世界に大量販売、開発部隊と保守部隊が合同で行脚し修理、半年ほどのタイムラグが起きました。
開発遅れがあると競争相手が反撃。競争力が低下します。ですから要求仕様書を最初に創る場合、次のモデルを開発しやすいように、全体を把握しやすく、かつ細部が分かるように記述することが必要です。これは基本の基本です。
さらに細部へ分解した問題を、事前に課題解析しておくことが大事です。要素の構成に従って試験計画をまとめ、導入テストをテスト法の実験だと認識すれば、解決策を実施した時の、その解決策の優劣をすぐ評価できます。運用段階でバグが発生しても、対応策を統合する時間を短縮できます。そのように本に書かれていました。
今日ここまで書いてきて、私は一昨日の私の受験勉強の記事を思い出しました。全く同じことを書いたと思いました。両方ともに実践例。当然でしょう。
今日はここまでにします。
