経験年数をある業務(業種)の経験年数として考えてみる

(「エンジニアの価値は経験年数じゃなくて開発手法とか能力に求められる」と考えたいので、ITサブコン系エンジニアでもやりたい仕事があるならやれる可能性を考えてみるのだ...)

要件定義終了後のタスクは「エンジニアの価値は経験年数じゃなくて開発手法とか能力に求められる」と考えたい。

自分がよく目の当たりにする、業務系のシステム開発、古典的なウォーターフォールモデルのプロジェクトで考えてみよう。

ウォーターフォールモデルだと、上流から下流に従い、求められる言語スキルは概念的に

と遷移する。(V字モデルなのでCDUTフェーズ以降は上流に戻っていく事となる)

要件定義ではシステム要求を自然言語で曖昧さを排除し書き出す能力さえあればいい。
ということは、SIerではなくてユーザがやったほうがいい。
SIerは、記述レベルだけ要求してレビューすればいいだろう。

要件定義終了後のタスクは、多段プリコンパイルだといえる。
であるならば、基本設計以降は言語理解能力と言語表現能力さえあえれば良いことになる。
もし、要件定義書が完全であれば、これ以降のタスクに業務知識など不要なわけだ。

PMは、こと基本設計フェーズまではとにかく業務知識でエンジニアを評価する(登用を決める)。
即戦力を求めてその業務(業種)の経験年数で評価するケースが多いだろう。

テクニカルスキル、ヒューマンスキルなどは最優事項ではない。

これは、日本の場合ユーザ企業が自システム開発に「自分たちの方言に合わせてどれだけオーダーメイドしたか」ということで価値を見出すことが非常に影響していると思う。

ここで問題なのは、基本設計フェーズまでも業務(業種)の経験年数で評価しているということだ。
それは、要件定義が不完全である前提で要員計画を立ている可能性があるからだ。

まず、どんなエンジニアもユーザーの業務経験を超えることはできないわけだから、実は、ゼロベースでもそんなに困らないことが多い。

ヒューマンスキル(コミュニケーション、ライティング、リーディング、ヒアリング、プレゼンテーション)が重要なのは自明の理となる。

業務知識は豊富なのだけど、伝わらない残念な人って多いことだろう....

いずれにせよ、業務知識を持ったエンジニアなどそんなに沢山いらないということだ。

また、基本設計フェーズでは、プロジェクトメンバが業務知識偏重でテクニカルスキルが不足していると、まともな方式設計などできず、詳細設計であらゆる手戻りが発生することになる。

基本設計以降のフェーズであれば、業務知識を要求されていても本質は異なると自信を持っていいと思う。
PMが目先の作業と目先のリスクに目を奪われている可能性があるので、「気づき」として業務知識より重要なスキルがあること、自分がそれを持っていることをアピールするのは有効だと思う。

...だから、経験年数をある業務(業種)の経験年数として考えた場合でも、要件定義終了後のタスクは「エンジニアの価値は経験年数じゃなくて開発手法とか能力に求められる」と考えたい。