答え：人による（当たり前
身もふたもない話ですが、SIerに限らず、世の中にはできる人とできない人しかいません。できない人はできる人になれることもあればなれないこともあります。一方で、SIerの業務はできる人がやるべき仕事と、とにかく人数がいればなんとかなる仕事とその中間の仕事があります。適切に役割分担が出来ているSIerの現場ではなんと！できない人も食い扶持があります！！そうではない現場ではできない人が本来してはならない仕事をすることで悲惨なことになる場合があります。
そういう事情があるので、SIerの現場では往々にして「タスクを作業レベルに落とす」という作業が発生します。これは無駄な場合もあれば効果的な場合もあり、一概に良いとも悪いとも言えません。
というわけで。
自分の作ったもの、たとえばメソッドなりクラスなりなんなりを作ったとして、その仕様を説明できないという人がかなりいます。
代わりに、延々と自分がコーディングした記述の説明をしてきます。
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
やった！コーディングならできてるんだ！
…実際の問題としては、これはできてるとは言いませんね。ところで、この「自分が作ったもの」と言うのは設計も自分でしたのでしょうか。その人は設計をできるレベルだったのでしょうか。
問題点：SIerの現場には設計ができる人、コードは書ける人、テストしかできない人が混在している。
テスト終わりました！カバレッジ100%です、と言われて見てみたら、たしかにカバレッジは100％だけど返り値の確認を一切していないというコードを見た時が一番度肝を抜かれました。
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
おかしいですね。SIerの現場ではテストケースと証跡（エビデンスね）こそが全てです。なぜカバレッジ100%がゴールになっているのでしょうか。
だからRailsやったことある＝RailsのControllerを書いたことがある、であると信じて疑わない。もちろん、一からURL設計をしてください、といったことは全くできません。 それどころか、動かないのは自分の責任じゃないのに、といったことをいう人までいてびっくりです。
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
はい。Javaをやったことがある＝StrutsのActionクラスを書いたことがある、です。当然ですが、jspが最終的に吐いたHTMLなんて確認してません（ブラウザに表示されたぜ！！！まで）。当然ですが、JavaのServletAPIを直接叩くという思考は持ち合わせていません。でもそこにはコーディング規約があって、コーディングガイドがあって、設計書とテストケースがあるんですよ？（ない場合も多々ありますね。多分この人死にますね）
try {
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
...
}catch(Exception e) {
return false;
}
こういうコードを書いてせっかくのエラー情報を握りつぶしたりするのです。catch節を書いたのは静的解析ツールに怒られるからで、それがなかったら読み捨てるんでしょう。 それで、ずっと後になって「エラーが出たはずなのにどこにも記録されない」なんて事態が起こります。
えーと…コードレビューは？
スパゲッティコードって、長い紆余曲折を経て作り出されるものだと思っていたのですが、頭がスパゲティな人がいきなりスバゲティを茹でることがあるんですねえ。
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
はい。というか、スパゲッティじゃないコードを書ける力って、ある程度の研鑽の結果じゃないですかね？そしてその研鑽をその人はどこでやるのでしょう。ここですよ！
というか、すぐ嘘をつくとか、もう開発者どうこうというより、人としてダメなんじゃないのか。
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
だめです。ところで、「できてるんだよね？YESかYESで答えて？」という人がたまにいますね。嘘をつくインセンティブがあると人は嘘をつきます。というか、嘘をつかないと殺されるのではないか、という経験を積むと人は嘘をつきます。
それはそれとして、個人的には上にあげたようなこと、一個でも引っかかるようなやつは一発でクビにしてよいと思っているが、そんなことしてたらうちからはもう紹介できる人がいませんとか言われるくらいこういうのが「普通」なのです。
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
はい。クビにしたいですね。でも外注（いわゆる再委託）であれば、僕達が発注先に保証させされるのは事前に合意した成果物の品質であり、個々のメンバーの実力を問うこと自体が違法です（実態として、品質の問題として改善を約束させることで間接的に注文していることもあるし、進捗管理の単位が細かくて実質指摘になっていることもあるし、レビューのプロセスとかで直接やりとりせざるを得ない（本当はダメだけど）こともありますね）。
これが普通、という問題は大変な問題なんですが、大変な問題であり、大変な問題です。
もちろんこんな人たちは開発者とは呼べないし、IT土方とすら呼べないのではないだろうか。だって自分の仕事の内容を自分で説明できないんだよ？そんな仕事人いる？！
SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
ちょっと待って下さい。土方と呼ばれる人は自分のやっている作業についてどれだけ理解していなければならないのでしょうか。作業指示があり、明確なゴールがあれば、大抵の場合それは考えなくてよいのではないでしょうか。そういうプロセスに落とし込まれた現場でただ作業だけをこなす低レベルな人材（まさにここで書かれているような）のことをIT土方と呼んでいるのではないでしょうか。であるならば、そこにある問題は作業員のレベルが低いことではありません。そのレベルに合わせたタスクが振られていないという事実です。
え、そんなレベルでデキる仕事なわけ無いだろ？そうですね、そういうプロジェクトもありますね。であれば、そのプロジェクトはIT土方レベルの人は必要ないプロジェクトなんですよね。でもIT土方しか雇える人がいません。辛いですね。
ここに書かれている問題意識ってのは正しい。SIerの現場って必ずしも技術力を必要としない局面もあって、また、人数が必要なこともあってかなりの割合で顕在化します。実にしんどいですね。常識で言ってありえねーだろというのがよく起きるの常識だし、その状態はクソでしかない。
ただ、それは「SIerの下請け開発者」という属性の問題点ではありません。SIerの現場にそのレベルの人を受け入れる余地があり、混じってしまうという問題であり、下請けの人だろうがなんだろうができる人はできるしできない人はできない。できない人が行きていけるから遭遇する機会が多いってことですね。だからできる人にも多数遭遇します。できるできないなんて通常のスキルレベルピラミッドで言ったら底辺のほうが多いに決まっているので率的にはできない人のほうが沢山ですね。
SIerの現場は、十分なトレーニングを受けたり資質の確認をしないまま、とりあえず修行とばかりに放り込まれた人が現場の流儀にアダプトするだけで生き延びるということも発生しうる現場です。まともなSIerはBPさんの教育プロセスも含めプロジェクトを計画しますし、定期的に会社レベルでの問題を話し合いますし、現場の技術レベルを向上させることに前向きです。限界はありますが。一方でそんなレベルに頓着できない死につつあるプロジェクトも多数存在するのです。
結論：人による（当たり前
できない人をどうするか（育てる、クビにする等々）も大きなマネジメント課題ですよね。
