よく読んでいるブログ、life is beautiful で面白い記事があった。
日本のシステム業界は、ソフトウェアの開発をしたことがない人たちが仕様書を作り、
プログラム作成を外注するゼネコン式システム構築が、業界全体の国際競争力をなくしてしまう、
という仮説である。
以下、ちょっと長いけど一部引用
「プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ端のエンジニアの書いたコードをレビューするのは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。もちろん、レストランに行く側の立場になってみれば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。」
『「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。』
プログラミングは、論理の塊だ。
「残業を申請する」という行為だけで、非常に膨大な論理を作らないといけない。
誰が、誰に申請するのか？正規入社の総合職？雇われの派遣社員？レジのパートのおばちゃん？
亀山の工場の労働者？エクセルを使いこなせないおじさん？
それの承認は誰がすべき？所属の上司？タスクのリーダー？労使？経理の課長？取締役？
それらの人は、システム的にどうやって識別・判断するの？
残業の申請はどんなデータ？
それを提出したという状態は？差し戻されたら？保留は？3段階の承認があったら？提出間違えが
あった場合の対応は？
深夜0時を越えた時間はどのように扱うのか？申請されたデータはどうやって保持しておくべきか？
何に反映されておくべきか？
申請は他にも休日出勤やら住居変更やら企画書申請やら色々あるが、どのように分類すればいいの？
まだまだあるものを、すべてプログラムの言語に直さないといけない。
それも遅いプログラムでは×。
複雑なインターフェースだと×。
プログラミングで実現しやすいものとしにくいものがある。スピードが速いプログラムを求めて
書いたことがない人が、どうやってスピード早いロジックを実現するのか？
業務を分類して抽象化して共有するのが、どのような形式がいいのか？プログラム書いたこと
ない人がプログラム単位で想定出来るものだろうか？
分割して各プログラマーに仕事を振るにしても、どういう単位だとプログラムの断絶を起こすこと
なく作れるのかわかるのだろうか？
システムすべてを一人で作れるわけはないので、仕事の分担は起こるのだけど、
難しい複雑な仕事ほど、縦割りな仕事の任せ方がいいとは思う。コンサルは典型例だと思う。
当然、クラスの共通利用がされない、ボタン配置などの仕様が共通していない、
各サブシステムの品質に非常にばらつきがある、などなど問題はあるけど。
自分としては優秀なプログラムを書けない人が優秀なシステムの構築は出来ない、に賛成やけど
実際はどうなのだろうか？業務寄りのアプリケーション部分より、インフラ部分のミドルウェアやOSなどの
作成にもっと顕著に現れると思う。
是非、他IT業界の会社で働いている人間にも聞いてみたい。