IT業界のシュールな現実（1）

スキル | 人間関係 | 業界動向

» 2008/09/12

　これから申し上げるのは、わたしが実際に仕事の上で経験したことです。これらは今日の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の間に信じられないような揉め事が生じたという記述を目にします。わたしたち実装屋には上流で何が起こっているかよくわからないのですが、下流から実際の開発体制を見ていると、そんなシュールな噂がいちいち納得できてしまうのです。恐ろしい話です。