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

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

»

 さる官公庁のシステム開発に参加したときのことです。基幹システムをダウンサイジングするという話でした。不勉強な私ですら名前を聞いたことがある有名なシステムです。元請は超大手SIerです。私はその3次請け業者の面談を受けました。技術的に高度なことを矢継ぎ早に質問されてたいへんな面談でしたが、とりあえず合格したようで、来月から来てくれといわれました。

 現場に行くと、大部屋に100人以上の人が机を並べていました。官公庁がユーザーであるせいか、空調が高めに設定してあって(いわゆる「クールビズ」です)やたら蒸し暑い。部屋の途中に衝立があって、向こうは2次請けの会社が入っている。私がついた担当SEは、その2次請け会社の人たちにたいへん気を使っていました。ほとんど鼻息をうかがうくらいです。衝立のそのまた向こうに衝立があって、その向こうには元請会社が入っているようですが、こちらはもう“殿上人”のような扱いで、口をきくのも畏れ多いといった様子でした。エンドユーザの官庁職員には結局会うことはありませんでしたが、もしその姿を見たらきっと目が潰れてしまったことでしょう。

 およそ官尊民卑を絵に描いたような雰囲気でした。それでもきちんとした開発が進んでいるならいいのです。ところが開発の実態はじつに奇怪なものでした。

 今回もまた基本設計がない。全体のスケジュールはなく、いつ完成させるのかもはっきりしません。それも単に資料がないというレベルの話ではなく、このプロジェクトがいつ始まったのかすらまったく不明でした。システムの全体像を示す資料はなく、誰がプロジェクトの責任者なのかもわからない。開発するシステムのハードウェアスペックはおろか、開発言語も不明なのです。どこからかC言語を使うといった不気味な声すら聞こえてきます(もちろんこれはC言語を貶めているのではありません。大規模システムにC言語を使うリスクについては理解してもらえると思います)。

 このような状態で詳細仕様書を作れという。どうやって? 発注会社の担当者からざっとした話を聞いて、それを文書にまとめればいいといわれました。不条理なことですが、IT業界ではよくある話です。しかし担当者の説明を聞いても、どうしても要領を得ない。自分でも仕様を理解していないのか、それとも不用意に仕様を決めて責任を取らされるのを恐れているのか、言葉の端々を濁しながら、口の中でぶつぶつとつぶやくように話します。1時間聞いても仕様はぼんやりしたまま。

 そのくせこれまたレビューが半端ではない。官公庁に収める文書だからでしょう。それこそ句読点のうちかたから、フォントの大きさ、数字の全角半角までうるさく詮議されます。そのくせ内容についてはほとんどかまわない。第一にそれが作るべき仕様書かどうかもはっきりしません。私がその仕様書を手渡されても、それによってどんなソースコードを書けばいいかさっぱりわからないという代物です。

 そんな仕様書1枚が完成するまで半月以上の時間がかかります。書くこと自体より、むしろレビューに時間がかかる。まず担当者のSEがチェックする。その注文が入って修正する。その段階をクリアするのに2、3度レビューをする。そのたび議事録を書く。それだけでも結局1週間かかってしまう。さらに2次請け担当のレビューが入る。修正して際レビューを待つ。ところが今度はいつまでたってもレビューの日程が決まらない。たなざらしになっている間に別の仕様書が注文されて書き始め、なんとなくそのままになってしまう。だれかPMになって督促するわけではないから、だれも文句をいう人はいない。

 そんな仕様書の1つで、入力項目としてコードが必要になりました。基本設計書がないので、誰かに聞くしかありません。担当SEにきくと、彼は驚いたことに「それは詳細設計で決めてくれ」といいます。まるで「そんな失礼なことを元請に聞けるか!」といわんばかり。彼の理屈では、コードなどのような細かい仕様は詳細設計で決めることだ、というのです。コード設計はシステムの根幹にかかわる重要な事柄です。それを一詳細設計者が独断で決められるわけがありません。「できません」と拒否すると、担当SEは憤然としながら、それならばその部分は自分で書くからといって引き取りました。後で彼が書いた内容を見ると「周囲の状況に合わせてコードを選ぶ」といった、まるでお役人のごまかし答弁のような記述がしてありました。これで私はもう何をいう気もなくなってしまいました。

 いったい私を呼びつけて私に何をさせたいのか、さっぱりわからない開発でした。同じように詳細設計要員として技術者が机を並べていましたが、その人たちも何をさせられているのか要領を得ない様子でした。どうやら私たちを割り当てようとしていた開発にGOサインが出なかったらしいのです。それをさいわい、暫定3カ月の契約期間が来たところで、こちらから契約を打ち切らせてもらいました。

 後から思うと、まるでカフカの不条理小説のような開発でした。

 コード設計を詳細設計者に任せたことからも3次請けSIerのSEのレベルが極端に低いことがわかります。何カ月も設計作業を続けながら、基本設計1つ作っていない2次請け業者も同様です。ユーザーの要件定義が固まらないのをいいことに、基本設計のカットアップを引き伸ばしていたのでしょう。スケジュールは遅れているけれど、詳細設計工程が始まったから、その要員を集めてしまう。詳細設計から先行開発させて、それをボトムアップでつめていけば、基本設計も固まるだろうといった、ほとんど倒錯的な開発方針をもくろんでいたのかもしれません。

 なんという税金の無駄使いでしょう。今日国会では財政再建の議論がなされていますが、私が見たのも国の財政赤字が生み出されている現場の1つだったのでしょう。この国が陥っている病の根深さを痛感しました。

 しかし、それよりもなによりも、このような開発体制でいったいどのような品質のソフトウェアができ上がったことか、そちらのほうがはるかに心配です。おそらく最終的には膨大な量の設計書が書かれたことでしょうが、ユーザーに理解させることを主目的にした、プラットフォームの物理的条件を無視した設計ですから、そのままでは実装作業には使えません。結局は誰かがそれを見て実際の作業に合わせた設計をしなおしたことでしょう。その工程にしっかり工期と予算がとってあればいいのですが、それすらなく、すぐ切り詰めた工期で実装作業が始まったとしたら……。

 それはもはやブリューゲルの「バベルの塔」の絵にあるような、巨大で、統一性がなく、何のために作られたのかすらわからない、人間の倨傲を象徴するようなシステムになってしまったでしょう。

 先日、そのようなシステムの末路をうかがわせるような話を聞きました。

 新しい仕事の面談にいったときのことです。

 ある公益法人の基幹システムの保守運用の作業を頼みたい。JavaのWebアプリケーションで、かなり大規模だという。それがトラブル続出で、恐ろしい事態になっている。具体的な作業の内容はおもに電話対応と原因究明だが、システムの利用者数が多いので、電話対応係は事実上コールセンター業務のようになっている。原因究明係は不具合を大まかに分析するだけで、改修はほかの業者に依頼することになるのだが、それだけでも月200時間を越える作業量になってしまう。

 面談担当者は以上のような説明をした後、せかせかした口調でこういったものです。「ついこのあいだ、また担当者が辞めていったので、その補充をしたいのだが、一度この仕事を始めたら最低2年間は続けてもらいたいので、十分考えてから返事をしてくれ。」

 これはもう「保守運用」のレベルの話ではありません。このシステムはまだ完成していないというのが正しい判断でしょう。そもそも保守運用を外注の人間に任せること自体がすでに異常事態なのです。

 JavaによるWebアプリケーションは、J2EEによって大規模なシステムを構築することができます。これが今日Javaが広く普及した要因の一つでであることは、いまさらいうまでもありません。しかしそれを使う側は――少なくとも日本のIT開発者はその使い方を誤ったようです。必要性の少ないドキュメント作成に不条理なほど莫大なマンパワーをつぎ込んだ挙句に、肝心のソースコードの品質劣化を招き、総開発コストを予算オーバーにしたばかりでなく、保守運用にも多大なリスクを残した。一方、ダウンサイジング需要が終わってSIerに残ったのはスキルの乏しい大量の技術者。自社だけでは保守運用に当てる人材すら手配できないありさま。

 未熟な技術とマネジメントで巨大なアプリケーションを開発してしまった結果です。誤った方法によってすでに作られてしまったソースコードの量を想像すると、気が遠くなりそうです。

 しかも多くの企業、官公庁ではそのことをまだ「失敗」だと認識していない。本来ならシステム改修のためにきちんとした予算を組まなければ直らないものを、運用保守のレベルで解決させようとする。その結果現場の技術者に多大な負担がかかっているのです。こんな現場に配属された技術者は人身御供にされたようなもの。IT業界はますます「3K」の職場と呼ばれ、優秀な人材が逃げていくことになるでしょう。

 もっともこのような大金をかけたシステム開発が失敗だったと認めるような判断は高度に「経営的」な判断でしょうから、私も軽々しいことを勧めたくはありません。開発が「失敗」だとしたら、その責任はだれが取るのかという問題も発生します。私は毎月のようにマスコミを騒がす「システム障害」のニュースを聞いて、経営陣の複雑な胸中を忖度(そんたく)し、些細なバグが社会的な大事故につながらないことを祈るばかりです。

Comment(3)

コメント

こういった社会問題について世間は何も知らないんですよね・・・
世間はきっと、情報産業だけの問題であって自分は関係ないと考えているのでしょう。
このブログを通じて、この社会問題が少しでも減る事を祈っています。

Any

自分も大手メーカー、大手SIer、官公庁の上流公定・下流工程に
関わってきましたが、まったくそのとおりでした。

某携帯会社の基地局Gatewayサーバーのシステム開発のことですが、
詳細設計レビュー時に、ぼそぼそと説明する2次請けと
フォント間違ってることを大声で怒鳴る1次請け。これが2時間。
結局このレビューでは書式の指摘のみで内容の整合性については
指摘ゼロでした(後でとんでもない要件・仕様不整合が発生)。
詳細設計書も3次請け会社の外注が作成したものです。

100億円規模の開発でしたがその九割がテストフェーズとバグ改修という名のつじつま合わせのコード変更に費やされました。
1次、2次請けはそれらしく見える仕様書の体裁を整えることが仕事でした。

これらの「とほほな人たち」はバブル全盛期にSIerに入社した人たちが多くて、
実装技術力および経験のない人ばかりでした。

開発環境も開発プロセスも20年前とほとんど変わっていません。
手書きがワープロに変わっただけです。
C言語を使用していましたが採用理由が
・それ以外の言語を自分たちが使用したことがない
・下請けがそれ以外の言語で書かれると自分たちがソースコードが読めないから
自分たちの技術力のなさを開発言語の採用理由としていました。
開発環境や開発プロセスが改善されないのも同じ理由でした。
・新しい方法は自分たちが理解できないから採用しない

あの東証問題で「CIO特命プロジェクトチーム」が召集されて発表された提言が...

「プログラミングや単体テストなど開発ベンダーが担当する工程のテストケースやテスト結果まで東証が踏み込んで検証する」

検証する能力がない人間がそんなことをしたらトラブルはもっと増えると思います。

正しい提言は
「システム開発から1次請け、2次請けを除外し、経験豊富な3次請けに直接担当させる。」
だと思います。

底辺の住人

役人の殆どは、実はその地位に値する能力がありません。
だから、責任の回避(下流への丸投げ)に奔走します。
彼らの成果[物]がハリボテかつ薄っぺらくなっていくのも、新しい事や判断・評価を
ひたすら避けるのも、真っ当な処理能力の不足からです。
ロクすっぽ試験もせずにβ制度を施行するものだから、国力の衰退も至極当然です。
彼らの中に軍隊的現実主義をキッカリ持ち込んだら、生き残れるのは極わずかでしょう。

ダメなモノに注視していても、何も解決しません。幸い、軍に限らず製造・販売など
老舗の業界を調べれば、未熟な当業界でも使えそうなやり方は転がっているようです。
腐敗した地雷は放置して、ハイレベルを求め低コスト化を追求するのが吉と思っています。

コメントを投稿する