設計と実装の分離ハードであれソフトであれ、研究系の新しいアイデアの製品開発や実装を外部に発注する場合、そのテーマや関連研究の実装経験のある相手に発注するのは、あたかも合理的なように思う。ところが、これが以外と落とし穴で、アイデア段階のものを実装力のある外部に頼むと、仕様が不明だとか、そこは想定してなかったという言い訳をしながら、最終的に実装力で作り込みで仕上げる。結果的に、完成するのだから良いじゃないかと思うかもしれなが、こういう仕事をする人や組織は、逆に仕様書等が残らない。コードが仕様書だとか言う人がいるけど、新しいアイデアであればあるほど、特定の開発環境や言語に依存しないアーキテクチャをきちんと設計する事が重要なので、それが実装コードというの望ましくないはずだ。実装(施行)は、分離されることが多いのだが、ソフトウェア開発ではあまり聞かない。アジャイル開発とかコンカレントエンジニアリングを曲解して、設計も詰め切らないのに、いきなりコードを書くパターンも多い。組み込み系などで、明確に外部インタフェィスや制約条件が決まっていて、ゴールの形が目に見えやすい場合は、まぁ開発期間も短いし、大きな問題にならないこともある。新しいプロトルコの研究開発等で、比較的長期になるプロジェクトは、屋上の上に屋上を重ね、年々深みにはまっていくという恐ろしいことになる。そこで、つくづく思うのは、公的な研究プロジェクトなどは、設計と実装の発注を分離する事が望ましいのではないだろうか?そもそも、国や公立の研究機関の場合には、その成果はあまねく広く展開される事が望ましいのだから、なおさらではないかと思う。いう、業務の仕組みの視点で、デスマーチなプロジェクトを減らす取り組みというのに,少し興味が出てきた。夜は、財務部門の人と,久しぶりに会食.財務とかもストレスが大きくて大変だな...[ツッコミを入れる]この日記は、FaceBookにフィードしているので、ツッコミはそちらだけで受け付けることにしました。1.8.7-p371。