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

業界動向 | 職場

» 2008/09/22

　さる官公庁のシステム開発に参加したときのことです。基幹システムをダウンサイジングするという話でした。不勉強な私ですら名前を聞いたことがある有名なシステムです。元請は超大手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」の職場と呼ばれ、優秀な人材が逃げていくことになるでしょう。

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