ITの分業と専門化 - esabataD’s blog

先日、ITは分業化と専門化ができてないと書いた。

IT系って、製造業を経験しないで、アイディアだけで先行するから工業製品を作るという経験をしてないせいなんだろうなと想像する。

例えば、工業製品としてちゃんとした機械を製造販売するのであれば、

等々、分業化してそれぞれのメンバーが専門化している。

設計、製造、検査といった工程を全部同じ人が担当するなんてあり得ない。

ソフトウエアは一つの部隊で顧客の要件を聞いて、業務分析して、仕様書書いて、プログラム書いて、テストしてる。

その方が小回りが効くし、低コストで作れると思う。

だが、その弊害が気になる。つまり、同じ人がずっと工程を続けるので、途中途中の設計書始めとしてドキュメント系がいい加減になるということ。

きちんと作らなくてもその後の工程も自分が担当するからプログラム完成を優先しておざなりになりがちである。

その結果、チームメンバー内で設計書不備で不整合が発生したり、後で引き継いだメンバーが仕様を十分理解できなくなってしまう。

専門化という観点でも顧客の要件を聞いて設計仕様におこすスキルとJava等プログラムを書くスキルは全く別物だと思うのだが、なぜ同じ人がやるのか不思議で堪らない。

キャリアを積む上でいろんな工程の経験を積むべきだと思うが、一つの案件で複数の工程を兼任すべきだはないと思う。

もう１つ思うのはDBAってスキーマとRDBMS構築を兼任するのか/できるのかってこと。
自分もDBAの経験は長いが、業務を分析してスキーマを設計する（テーブルを設計する）のとインフラに近いRDBMS構築は全く別のスキルだと思う。

そりゃ、データベースエンジニアとしてER図の書き方くらいはできなくてはいけないと思う。でも、要するにドライバーやスパナの使い方を知っていても機械設計図が描けるかは別問題。

未だにPL/PMも十分な理解ができてなくて、「データベース」というキーワードだけで兼任することがある。特に小さな案件でメンバーが少ない場合そうである。

でも、DBAの間でも認識が異なる人が居て、兼任しても良いと考えている人も居た。

でも考えて欲しい。スキーマの設計ってアプリの根幹であるはずだ。それをデータベースというキーワードだけで、業務を理解できていない人に任せるのは危険だ。

それもRDBMS構築と兼任なんてできるはずもない。ユーザー業務も分析しつつ、インフラチームと相談しながらRDBMSの設計・構築ができるスキル・時間がある人はスーパーSEだ。

この件もキャリアを積むために、ある案件ではRDBMS構築、次の案件では、業務分析をしてスキーマ設計をやっても良いと思う。が、1つの案件で兼任はNGだと思う。