（>>856 の続き）

始めは「考えられるリスクの低減」から
・ライブラリや共通部品の多くは(アルゴリズムやデータ変換を実現する単純なものもあるが)
　データベース/ファイル／ネットワーク/プロセス間通信といったプログラムの
　外部インターフェイス処理が多くを占める
　これらを実装するには、プログラマにシステムコールや標準ライブラリ(>>829)、
　そして社外のライブラリや社内の共通部品等等、幅広い知識が求められる
　これを経験の浅いメンバに負わせるのは無謀
・ライブラリ/共通部品の実装技術は機能仕様(=ビジネスルール)には依存しないから、
　類似のシステム開発プロジェクトがあれば、類似の実装になる
　もしライブラリ設計担当がいくつかのプロジェクトを経験したベテランであれば、
　過去の(失敗を含めた)経験から、既存の設計やコードを改造母体にして短期間で設計できる
　これと同じことを経験の浅いメンバに期待するのは無茶
・万が一、ライブラリ/共通部品の開発日程が遅延して結合テストに間に合わなかったり、
　結合テストでバグが多発する事態になれば、その影響はプロジェクトの全体に及ぶ
　もしモスク(>>856)の中位/上位層であれば影響範囲は限定的だし、
　その炎上の火消しのためにライブラリ/共通部品を担当させて余力のあるベテランを投入できる
　（当然、ライブラリ/共通部品設計には日程厳守(or 前倒し)と高品質(=バグ0)をベテランに要求する）