PR

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


現場は“並”ばかり
 従業員100人弱の当社において、一番腕のたつエンジニアは、会社のナンバーツーになってしまって、ほとんど開発の現場にはおりてきません。頭脳はピカ一 ですが彼は、GUI(グラフィカル・ユーザー・インタフェース)とかイベント・ドリブン開発といった新しい技術に乗り遅れてしまったようです。あと数年す れば、彼はナンバーワン、すなわち社長になり、彼の下は「並みの技術者の群れ」ということになります。全く人ごとではありません。ところで、「プログラマ は 30数歳で定年」という説は一体何だったんでしょう?

 筆者が記者になった21年ほど前、「プログラマは35歳で定年」といった言葉を聞いた。当時取材したSEマネジャや、情報システム責任者は、「情報システムの仕事は奥が深い。要件を整理する仕事、システム全体の構造を決める仕事、開発作業の進捗を取り仕切る仕事など、ベテランになればなるほど力を出せる領域がたくさんある」と教えてもらったものである。ところが、ベテランはこうした仕事というよりは、部下を持つ管理職に向かってしまった。あるいは、会社がそうした道しか用意しなかった。今さらながら、専門職のあり方が問われている。管理職以外の明るいキャリアを提示できない企業に若者は行かないだろう。


コンセプトを記録せよ
 ベテランSEの一人として一言。 システムをブラックボックスにさせないためには、開発の初期フェーズで、設計思想を明確に記述した「概念(コンセプト)仕様書」を残しておくことです。そ のシステムは何を目的にしており、何ができ、何ができないか、いったことをまとめておくのです。枝葉末節まで記述してある仕様書は、細かすぎてメンテナン スが追いつかず、かえって役に立ちません。
 残念ながら既にブラックボックスになってしまったシステムについては、ほぼ同じ機能を実現できるパッケージ・ソフトに置き換えるしかありません。置き換えを機に、過去のしがらみから脱出できる利点もあります。

 ブラックボックスの解読に取り組んでいたあるソフト技術者から、「ソースコードをたどることができても、注釈文が書かれていないと、なぜそのようなロジックを組み込んだのかが分からない。開発者に“文脈”を尋ねることができれば、解読作業は非常にはかどるのだが」と言われたことがある。開発コンセプトだけでも記録しておければ、後の作業が軽減できると思われる。


“元現場SE”を動員
 今更、責任の所在をあれこれ問うても大した意味はありません。「再構築が解決策」という意見がありましたが、IT企業側のお粗末な理由で、お客は金を出すのでしょうか?それなりにお客を説得する知恵とパワーが必要でしょう。ただし、再構築が可能なところなら、先々の事を考えるとある意味で現実解になりえます。
 ノウハウ継承についてですが、60歳近くになっていて現役のSEではなくても、管理職などになって社内に残っているのであれば、その人をつかまえ、ノウハウをドキュメントの形で残すしかないでしょう。
 蛇足ですが、私が前にいた職場は大変でした。担当者が異動してもノウハウはほとんど継承されず、ドキュメントも不完全。かろうじて残っているドキュメントには嘘が記述されている。あげくの果てに、「仕様はソースコードを見ろ!」と言われるありさまでした。あのときは私も若く、必死でやっていましたが、今思うと恐ろしい職場だったと思います。

 確かにベテランと若手が対決し、批判し合っていても意味がない。同じように、お客とIT企業が非難し合っていても意味がない。情報システムをブラックボックスにしてしまった責任は、手をこまねいていたお客にも、忠告しなかったIT企業にもある。両者が納得できる再構築計画案を書くことができれば、現実解に一歩近づくことになる。


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