IT業界は逆ピラミッド型へ？
IT業界の受託開発プロジェクトは、よく建設業界の業界構造に例えられることがあります。ある程度の規模以上のプロジェクトになると、発注するクライアントから直接受注するプライムベンダー、プライムベンダーから発注を受けるパートナー企業、さらのそのパートナー・・・という階層構造となる場合がほとんどだと思います。
階層構造の中で、特に役割を持たないというか、プロジェクトにあまり関わらずに契約のみ通してマージンを得る・・・なんてこともあったりします。開発プロジェクトは案件に応じてその規模が異なりますし、プロジェクトごとに対象となる業務や必要とされる業務スキル・システムスキルが異なりますので、すべてを自社の要員のみでカバーするということは事実上不可能に近いこともあり、ある程度の階層化はやむをえないと思います。
また、受注の階層に応じて、担当者の役割も、コンサルタント、要件定義担当者、開発設計者、プログラマーと変わってきます。
IT業界の少々厄介なところは、どの役割でもそうですが、スキルのミスマッチやスキル不足の要員がある程度の割合でプロジェクトに入ってくることにあると思います。例えて言うなら、釘の打てない大工さんが現場にいるような感じでしょうか。釘が打てなければ直ぐにミスマッチであることは分かるのだと思いますが、IT業界では以下のような理由からなかなかミスマッチに気付かないことがあります。
- 設計指示する人と、開発するプログラマが顔を合わせないことがある(時としてその人が本当に居るのかも疑う場合もあります）
- プロジェクトに関わる会社が異なれば作業場所もことなることがある
- 指示する人がそもそもスキルを持っていないことがある（Javaのスキルが必要な場合で、VBの浅い経験しかない人が来てもそれを見抜けないなど）
特に３番目の点ですが、本来、きちんとプログラミングできる人、ある程度の経験がある人が設計をした方がよいのですが、大手企業に入社した場合などは、プログラムを書かずに直ぐに設計をする場合もあります。そうすると、現場で釘を打っているのを見ても、それが正しいのかどうか判断が出来ないことになってしまいます。
クライアント企業の要望を要件としてまとめ、実現する方法を設計し、実際にシステムを構築する過程で、問題が発生する場合が頻繁にあります。私も何度もそういう現場に居たのですが、問題が発生したときに、その原因の特定や解決策が指示系統の末端のプログラマに丸投げされることがあります。
パフォーマンスが悪いので１０倍くらい早くしないと使い物にならない。画面の項目が足りなかった。使い辛いので画面遷移を増やして欲しい。などなど。時には、プロジェクトの成功失敗に関わるような重大な問題であることもあります。
指示系統の中間層が適切なスキルを持っていない場合、末端のプログラマの一言が方針に大きく影響する御寒い場合があります。
- パフォーマンスは限界です。H/Wのスペックを上げて下さい。（設計ミスである場合がよくあります）
- 今から項目を追加するのは1人月くらい工数がかかります。（数日で対応できたりする場合もあります）
- それはできません。（スキルがなく、やり方がわからないだけである場合があります）
プログラマの一言は、受注のピラミッドを下から上に疾走し、発注側のトップに伝えられ、仕方なく機能改善の方針を取り止めるなんて、かなり笑えない話です。
ITエンジニアの数が今後減少していくのであれば、上記のような逆ピラミッド型のプロジェクトが増えないようにプロジェクト全体をきちんとまとめられるようなコーディネーターがますます重要になってくるんだと思います。