個人事業主にしてベテランプログラマー。人呼んで「IT業界の小関智弘」(?)

IT業界のシュールな現実(1)

»

 これから申し上げるのは、わたしが実際に仕事の上で経験したことです。これらは今日のIT業界の病根の深さを示すものです。

 とある会社のシステム開発に呼ばれていったときのことです。まず見せられたのは画面見本でした。すでにHTMLで詳細な画面が作られています。画面数が多く、画面上の項目数も多い。これは相当意欲的なシステムだと思われました。これを実装できるなら、きっと充実した仕事になるでしょう。

 ところがいつまでたっても開発が始まりません。誰がプロジェクトを管理しているのかもわからない。誰もスケジュールをはっきり説明できません。おまけにドキュメントサーバのどこを探しても基本設計書がありません。業務フローもなければシステム構成図もない。膨大なER図だけが公開されていて、ときどき修正されているらしい。

 いつまでも遊んでいるわけにはいかないからと、詳細設計書を先に書くことになりました。基本設計書がないのに詳細設計が書けるか! 普通の人なら驚くでしょうが、この業界ではよくあることです。IT業界の技術は日進月歩で、プログラミング工程はたいへん生産性が向上しています。製造工程であまったマンパワーを設計工程に回すために、詳細設計書はPG自身が書くことは珍しくありません。基本設計書が変更になれば、当然その設計書も手戻りになりますが、遊んでいるよりはいい。

 いやだったのは、それにもかかわらずこってりとレビューをすることです。いったい何を根拠にレビューをすればいいのでしょう。チェックするところといえば、段落はさげてあるかとか、句読点は打ってあるかなどといった形式上の瑣末事です。それもすぐユーザーから仕様変更が伝えられて書き直しになる。またレビューのやり直し。文書直して、アポとって……。

 しばらくそんな不毛な作業を繰り返しているうちに、上流で何が起こっているか次第にわかってきました。元請SIerがユーザーと揉めていたのです。元請は見積もりを誤ったのか、機能が多すぎるので削ってほしいといっているらしい。ユーザーは受け入れたくないし、何より元請業者の開発方針に不審を抱いているようでした。いつまでたっても納得できるような基本設計が出てこない。SE、PGをたくさん集めたけれど、仕事はしていない。きっとユーザーには人手不足を理由に人間をかき集めただけで、管理する能力もなく遊ばせていると見えたことでしょう。

 上流でことが進まないなら、せめて下流ではこの時間を利用して開発準備を進めていたいところですが、それもどうも怪しい。そもそも先行してコーディング作業に入ることが禁止されていました。個々のプログラマにソースを任せてしまうと、どんな勝手なソースを作るかわからないからというのでしょう。いくつかのパラメータを入れればスケルトン(プログラムの原型)を作るツールを作って、それを使うことを義務付けようとしていたのです。ところが何度見ても出力されるスケルトンの構造がわからない。おまけにそのツールの動作が不安定だし、操作方法が意味不明だし、しょっちゅう手直しが入るし、これならEclipseでコピーして作ったほうが早いと思われました。ただ若手の新しがりのSEの自己満足のために作られたようなツールでした。

 そのうえプロパー社員SEの技術レベルは悲惨なものでした。わたしが下についたSEはやたら威張っていました。年のころは30歳前半だったでしょうか。わたしは彼が何か具体的な成果物を作っているのを見たことがありません。単にわたしの詳細仕様書に対する「お目付け役」だったように思えます。まあ、下の人間は上の人間が何をしているのかは理解できないものです。何かしていたんでしょう、きっと。

 あるとき彼は、わたしが書いた仕様書にテーブルの検索条件が書き込んであるのを見つけて烈火のごとく怒り出しました。

 「SQLを設計する前に報告するようにといったでしょ!」

 その声の大きいこと、周りにいた人たちが驚いて振り向いたくらいです。

 要するにその部分は自分が設計するつもりでいたのを、わたしがさっさと書いてしまったので怒り出したのです。あとから知ったのですが、そのSEはSQLしか知りませんでした。つまり自分もきちんと詳細設計ができるところを見せつけて、わたしを恐れ入らせようとしていたのです。

 まったくバカなSEもいたものです。SQL設計など下流に任せておけばいいものを。テーブルの検索条件だけははっきりイメージすることができるので、そこだけは人任せにできなかったのでしょう。人を使うことの基本ができていない。やがて何度かやり取りするうちに、わたしの管理をするのに飽きたのか、異動願いを出して、先述のスケルトンツールを作る部署へと移っていきました。そんなスキルでそこの仕事が勤まったかどうか知りません。

 わたしにはこのSIerが、社員の技術を空洞化させてしまった典型的なケースに思えます。ソフトウェア開発の業界では、PGよりSEのほうが単価が高いので、SIerは自分の社員をできるだけ早くSEにしようとします。そのためSIerにはSEがたくさんいますが、実装技術が未熟な人も多い。わたしを担当したタカビーなSEのように、すこしばかりSQLをプログラミングしたというだけでSEの業務につかされるケースも出てきます。彼らがしてきた仕事はといえば、ほとんどが仕様書作成。わたしはあまり役にも立たない仕様書作りなどまともな仕事だとは思わない(失礼! でもそう思う理由はあるのです。いずれ説明したいと思います)のですが、それだけを専門にしてきたSEはそれが正しい有意義なシステム開発の手法だと思い込んでいます。それを2、3年も続ければ、当然自分はさらに上流工程で仕事ができると思い込んでしまう。それが出世だと思い込んでいるし、そうしないと自分はいつまでもつまらない仕様書書きを続けさせられることになる。件のSEからは、実装作業に対する根拠のない侮りと、強烈な功名心と自分の置かれたポジションについての不満しか感じられませんでした(真の技術者はあまりポジションには執着しないものです。自分の技術が自分の価値を決めるのだと知っていますから)。

 ユーザーとの間に起こったトラブルも、SIerの基本的なプロジェクト管理能力、設計能力に対する不信が大きな要因だったと思えます。IT開発の基礎体力であるプログラミング技術がなくなると、プロジェクト管理ができません。というのもプロジェクトの管理には実装作業の豊富な経験が必要だからです。仕事を適正に分担すること1つにしても、PG各人の技量を詳しく知らなければできません。未熟なPGはちょっと複雑な仕様にぶち当たっただけでプレッシャーに負けてしまったりします。ですからPMはSE、PG全員をよく知っているベテランがなるのが望ましいのですが、最近は若手社員がなることすらめずらしくはない。人の入れ代わりが激しいので、プロパー社員の絶対数が少ないのです。PMは、たとえば工期の遅れを取り戻すために臨時に作業者を増員するなどの権限が必要な「管理職」、おいそれと外注するわけにも行きません。その結果、経験不足を承知で若手社員をPMとして登用しなければならないのです。若手PMがすべて無能だとは思いませんが、SIerのプロジェクト管理能力を低下させる構造的要因の1つであることはまちがいありません。

 最近ネットで検索すると、ユーザーとSIerの間に信じられないような揉め事が生じたという記述を目にします。わたしたち実装屋には上流で何が起こっているかよくわからないのですが、下流から実際の開発体制を見ていると、そんなシュールな噂がいちいち納得できてしまうのです。恐ろしい話です。

Comment(3)

コメント

それは大変でしたね。貴方様のほうがキャリアが長いので、どれだけそういう目にあっているのかと考えると寒気がします。
私も似たような出来事に何度も遭遇しています。
なおかつ、最近は上流の馬鹿さが加速して、「仕事を持ってくる」だけが上流の仕事になりつつあります。
私は本気で情報処理技術を学んできましたので、お客と会話するのと同時に頭で設計書とがかけますし、プログラミングをある程度脳内内で来ます。
ですから、元請けの話しを聞いた瞬間に「こりゃ動かないシステムだな」と判断できますが、それを元請けは認めようとしません。
仕事もってくるだけなのに、何を根拠にか「強固な自信を持っている」のです。
もちろん、私の指摘した間違いが後で発覚するのですが、元請けはそれすら覚えていません。なおかつ料金不払いなどが横行しています。
誤解が無いように先に言っておきますが、私が偶然そのような会社としか出会っていないのでしょうが、そのような会社が普通に営業している事が怖いですね。
高いお金を出して品質の悪い物を買っているお客の事を考えると胸が痛みます。

エムワイ

個人事業主です。
やはり皆さん同じ苦労してるんですね。
というか、やはり何処も同じ状況なんですね。
私もこういった状況に何度かなりました。
お客様とお話しをすると要件としてまったく難しい事ではないので、
さっさと作ってしまおうと思うと、元請けのリーダーやらマネージャーから
止められてしまう。
そういう「出来る」ところを見せると、新人を連れてきて、
「こいつに教えてやってくれ」と頼まれる。
でもプロジェクトは進まない。
挙句には、いきなり向こうから契約を切られる。
現在はそんなに大きな規模のプロジェクトに参加していないので、
1人で上流から全て行っておりますが、そんな中なんと
上の方から突然今月で契約を切られました。。
理由はグループ会社のSIerに全て任せるとの事。
その引継ぎを行っていると、「ここは要件が固まっていない」「ここはまったく別の実装要件だから違うタスクにする」など、
私の目から見ると数日で終わる物を、わざと上流工程に戻して時間を稼ぎたいだけのように見えました。
担当のお客さんも「要件が固まっていないと言われても。。」と困ってました。
難しい横文字やプロジェクト管理のライセンスなどで「出来る」ところを見せつけたいようです。。
こういう職業が成り立ってる事が不思議でなりません。

コラムニスト後藤

エムワイさんへ。
コラムニストの後藤です。
コメントありがとうございました。
途中で契約打ち切りとはひどいですね。
しかしエムワイさんはそれもさることながら、自分が作った部分を理由もなく否定されてしまったことに怒っていらっしゃるご様子。文面からそんな無念さが読み取れました。
それこそ技術者魂というものです。
たしかに今のIT業界は技術に対する正しい評価ができず、奇怪なことがまかり通っています。
しかしIT自体は決して斜陽産業ではありません。これからますます社会に必要な技術になって行きます。
めげずにがんばっていけば、きっといいことがあります。
それを信じてお互いがんばりましょう。

コメントを投稿する