紹介文 :
増加する派生開発の案件に対応するために、既存の協力会社では間に合わず、新たに外部の協力会社を頼む必要が生じることがある。しかしながら新たに参加する協力会社の技術者には、今回の開発製品やシステムに対するベースの知識が不足していたり、ソースコードの設計の隠れた情報を「読み取るスキル」が不足していたりするため、変更への対応ミスが生じやすい。短い開発期間の中で、このギャップをどのように埋めるかという問題は、多くの現場に共通する問題と思われる。
従来から変更に関連する情報を提供していたが、渡した資料の範囲が広すぎたりしてうまく活用されなかった。その解決方法として、機能と資料とのマトリクスの中で関係情報の所在を示すと同時に、関連する情報を小さな短冊（Chips）にして、目的の箇所に辿りやすくなるように工夫した。マトリクスのマスター情報に対して、今回の変更に関係する箇所がわかるように更新して渡すことで、時間の無駄も省いた。

紹介文 :
一般に、派生開発では機能の追加と変更が中心になる。その結果、応答時間などに変化が生じることがある。設計の担当者は応答時間の変化に気づかなかったり、気づいていた時でも、これくらいなら問題ないだろうと勝手に決め込んだりしていることが多く、納品後に「時間効率性」の劣化としてクレームとなる場合がある。時間効率性に関するクレームは、必ずしも遅くなったから問題になるとは限らない。派生開発の場合、使い慣れている状況に対して変化が許容範囲を超えると操作に影響を与えるからである。
設計者が応答時間等の劣化に気づかない理由として、ソースコードの該当箇所を探す際も、機能の変更に気を取られ、その機能が操作と絡んでいることに気がついていないことがある。そこで、変更要求を捉える段階で、メモリー処理や通信処理などの時間効率性に影響を与えそうな機能を変更するときには、時間の変化を予測して、「EMOT(Estimation Method Of Time behavior degradation)」の確認表を使って変化時間の目安を確認する。そこで事前に想定している許容範囲を超える時は、早めに依頼者と変更方法などを協議する。また他に変更方法がない時は、操作側で事前にトレーニングして備えてもらうことになる。こうした対応によって、後からのクレームになることを回避する。

紹介文 :
セキュリティ対策など、優先度の高い対応をスピーディに行う場面では、使用性への配慮が不足しがちです。その結果、業務効率を悪化させることが開発終盤や納品後に判明し、手戻りの要因となっています。このような問題を、顧客のビジネスリソース(作業分担，システム連携，作業自動化の程度など）の違いに着目し、解決しようとしています。チェックリストで注意を促す古典的なやり方との違いは、顧客と自社のビジネスが両立する仕様決定を促す点です。