私が会社を起こし分不相応にも社長をやっているのは、更に分不相応な「業界を変えたい！」という思いから（もあって）です。
古いエントリーですが、業界はこんな感じです。
ソフトウェアの仕様書は料理のレシピに似ている
仕様書を書く ＝ 設計士の仕事
コードを書く ＝ 肉体労働者の仕事
IT業界には上にあるような、嫌なヒエラルキーが存在し、料理を作ったことがない人がレシピだけを書いています。
ゼネコン構造になっていて、ヒエラルキーの最下層にいる弊社の様な小さな会社は、トンチンカンなレシピに文句を言わず、そのまま再現する扱い易い料理人であることが求められます。
先ほどのエントリーにもあるとおり、料理をほとんど作ったことのない人が味見もしないで書いたレシピですから、トンチンカンになるのは当たり前の話です。
大手の仕事（下請）以外は、弊社の技術者はかなりアバウトな仕様（要望）で作り始めます。
新しいレシピの料理を味見しないで作れるなら、天才を超越した神か悪魔か、余程の味音痴と考えているためで、お客様にも、都度、味見をお願いしながら進めたいと考えています。
ところが、一般的な業界の構造では、馬鹿げたことにユーザにレシピを見せてユーザがＯＫした時点で作り出すことが正しいとされています。
もちろん、レシピを見ただけで料理の味を完璧に想像できるそんな神のようなユーザが存在するわけもなく、この承認は仕様書の厚みであったり体裁であったり…で、承認していると思われます。
当然、そんなユーザの承認を得たと言われる仕様書を見ても、何がしたいのか全く理解できないことの方が多いです。
その承認に意味はないと判っていそうなものですが、IT業界では、そんなユーザの承認を金科玉条のように持ち出し、レシピどおりに作れば「不味くてもユーザの責任だ」と平気で言います。
そして、ユーザが作り直しを要求すれば当然のように追加料金を取ります。
結果、ユーザは不味い料理を我慢するか、追加料金を支払うかしかなくなるわけです。
また、弊社のようにヒエラルキーの最下層にいる技術者は、技術者であるのにもかかわらず、技術ではなく作業時間を切り売りする契約になります。
そんな中小零細のソフトハウスにとっては、時間を切り売りしているため、トラブルが多い方が儲かるという構造です。
ですから、中小企業の技術者は、積極的に技術を磨くよりも、トラブルをやり過ごす技を身に着けることになります。（それも大事なスキルではあるのですけれど）
製造業であれば小さくても世界的になくてはならない技術を有した企業は存在しますが、IT系ではそんな技術力を望むべくもありません。
私は、こんな業界を変えたいと思っているのです。
日本のIT業界は、現場はオフショアとの板ばさみの中で……という記事にある図の様な構造になっています。
支払いが完成後になるため、その間の資金繰りが小さな会社では持たないため、資金力のある大手に頼らざるを得ないのは、仕方がない部分もある。
しかし、お互いに技術者なのですから、技術者としてのプライドを持って、プロとしてユーザに対してどれだけ価値のあるものを提供するかを問うような構造になっていけばと、切に望みます。
頼っている大手様を批判することを書いて大丈夫か？と思いながら…。
<< 第３７回目 「エクセル de バブルブレーカー(Excel de Bubble Breaker)その９」 | | 第３９回目 「エクセル de バブルブレーカー(Excel de Bubble Breaker)その１０」 >>
コラムの全インデックス
アーカイブ
