PR

 引き続き、読者から送られてきたご意見を紹介し、応答文を付記する。


全体像をつかめる人材がカギ
 情報システムのブラックボックス化がもたらす危機的状況は2007年よりもっと後に発生しそうな気がします。最も重要な当初の設計思想や、システム全体のあるべきイメージといった、一見抽象的な感覚を理解していて、新システムの追加・拡充ができるSEは30~40代前半という感じです。その年代が頑張っている、またはその年代にみっちり指導された人がいる間はなんとかなるかなと思います。
 ただし、その年代の転職・異動がここ数年激しいのは気になります。一方、若いSE、特に20代はただの作業者、「とりあえず要求通り動けばいいんでしょう」といった態度の人が多く、指導していて無力感というか、今後どうなるのだろうという漠然とした不安を感じます。

 情報システムの世界で必ず出てくる問題は、全体像の把握と専門性を究めることの兼ね合いである。情報システムの世界に使われる技術は細分化され、多様化しているので、多数のスペシャリストを動員する必要がある。ただし一つのシステムを作り上げるにあたっては、動員されたスペシャリストが同じゴールを目指さなければならない。ゴールとなるのが、そのシステムを作る目的であり、システムの全体像である。ところが、目的を明確にし、その目的を達成できるシステムの全体像を描くところが一番難しい。この能力と、個別要素技術の専門能力とは一致しないからだ。


管理体制そのものも再構築
 他の読者も指摘しておられますが、やはりシステムそのものの再構築が、問題解決の近道でしょう。ただし、普通に再構築しただけでは同じ事の繰り返しですから、仕様書・マニュアル・打ち合わせ記録といったドキュメント類の整備と、稼働後のシステム修正/変更記録の残し方の確認、コーディング時のコメント書式の統一、などを徹底した上で取り組むべきです。
 ここまで取り組むと、システムの再構築にとどまらず、実はシステム管理体制そのもののスクラップ・アンド・ビルドの話になってしまいます。といって小手先の対応策では問題を先送りするだけでしょう。以上の取り組みについて、私自身が出来ているわけではないのですが、「理想」を掲げるという事で書いてみました。

 確かに、システムを再構築するには、ビジネスモデルも、システム開発体制も、すべて再構築する必要が出てくる。再構築プロジェクトの難易度が高まる所以である。開発体制については、せっかくスクラップ・アンド・ビルドして、新しいルールを決めても、そのルールを守らせる役目を持った担当者を専任で置き、プロジェクトチームに常時働きかけをしないとうまくいかない。開発が遅れだし、「ドキュメントを書いている暇がない」「書式の統一は今回見送る」と開発現場が言ってきた時が正念場と言える。


後継者は育つ
 私は団塊の世代ではなく、一世代下の年代です。入社して2~3年目の頃に工場部門の設計システム・生産管理システムをゼロから作り上げ、15年以上にわたって保守を担当、新規のサブシステム構築まで一手に手がけてきました。さすがに長いと感じ、異動を希望したら「後継者を作れ」と言われたので、新人を毎年もらい、ドキュメント化とOJTにせっせとはげんだ結果、なんとか後継者を育てることができ、無事異動できました。
 私がいなくなった後も、その工場は自立してシステムを維持できています。この経験から思うのは、人の育成というのがやっぱり大事ということです。 ただ、バブル景気以降に入社した人は、どうも探究心が少ないように思います。ドキュメントに書いてあることはやってくれますが、そうでないと行間は絶対伝わりません。

 2007年問題対策の成功例である。この方も立派だが、新人を毎年投入した会社も立派である。「異動したくても、後継者の候補になる新人すら回されない」というシステム現場もあるからだ。おそらく人の育成ということを大事にされている企業なのだろう。こうしたことができる企業とそうでない企業の間には、決定的な差が付くに違いない。


(応答文:谷島 宣之=「経営とIT」編集長)