よく受託開発案件などでは、ユーザーの現状をヒアリングし、問題点の洗い出しを行うことがあるかと思います。洗い出した問題点に基づいて業務を再考し、適切な形へと組みかえる、BPR（ビジネスプロセス・リエンジニアリング）と呼ばれるものです。 実際、どのように分析して対応策を考えていくかについては、世の中にたくさん記事やら解説やらが揃っていますのでそちらを参考にしてもらうとして。 わたしは、気のせいや考えすぎのきらいがあるのですけど、どうにも見ていると、ある1つの「正解」をあてはめよう、としている雰囲気が感じられるのです。特にその風潮は、実装＜設計＜分析……というように、上層へ向かえば向かうほど強まっていると思えます。 恐らくは分析時などに限定した話題でもなく、プログラムの組み方や設計の行い方など、エンジニアとして関わる分野ほぼ全てに見受けられる傾向なのでしょうが。 要件定義はこうするべき。 ビジネ

過去に＠ITの掲示板でも質問を投げかけてみたことのある、この話題。 その当時から3年経過したにも関わらず、同じように日々悩んでいます。「生産性を上げること」と「人を育てること」、その両方をバランス取って進めていくことに。 あれから時代は進み、人材の両極化はことさら大きく表れてきているような感触を受けます。わたしはそれなりな年数を過ごしてきていますので、「後継者を育てろ！」といろいろな方面から突っつかれていますが、正味なところ、今の自分たちと同じようなことをできるまでに育て上げるというのが非常に困難、もしくは達成できないと思えているのです。 業務としてシステムを作ることを生業としていますので、プログラムの実装では「再利用を行い生産性・保守性を高める」「コーディング量を減らし実装にかける時間効率を上げる」など、基本的に省力化の方向へと進んでいるのはよくあることだと思います。 直接自由にコーディ