情報システムについて，以前から，少し，気になっていることがある。課題の整理もできておらず，実態すら把握できていないのであるが，とりあえず，問題を提起してみることとしたい。
つい最近の報道によれば，ある電子申請システムが，完成以来，全く利用されていないにもかかわらず，開発や保守に多額の費用を使っているとの会計検査院の指摘を受けて，近く，廃止されることになったという。対象となる製品を添付することが必要な申請手続において，申請書類の提出だけを電子化したもので，申請者にとって，電子申請によって得られる利点の無いシステムであったという。
この例は，人や組織の活動を十分に理解せず，電子的に処理できる部分だけを対象に開発した失敗例として片づけてしまうこともできる。構造化プログラミングに端を発したソフトウェア工学は，最近では，要求工学 (Requirement Engineering) などという言葉も目にするようになった。ソフトウェア工学が目指してきた開発効率と品質の向上，利用者にとって有効な情報システムの構築といった成果を生かせなかったのは事実であろう。一方で，不要になったソフトウェアを的確に識別し，廃棄することができた事例としてとらえることもできる。
ある企業では，プログラムの保守作業の際に，以前のコーディングをコメント化して，変更履歴を残してきた。新たな機能の追加や変更に当たって影響範囲を調査すると，コメント化されて死んでいるはずのコーディング（＝ゴースト）が検出されてしまい，影響がないこと，修正が不要なことを確認するために，相当の人手と時間を取られてしまっている。
そこで，保守作業の効率向上を図るために，コメント化されているゴーストの部分をソースプログラムから完全に削除することを計画している。しかし，生きている部分のコーディングを誤って削除してしまわないか，また，履歴が消滅してしまうことで，今後の保守において，以前と同じ過ちを組み込んでしまわないかといったことが懸念され，安全で確実なゴースト退治の方法が見つけられないでいる。
最後に採り上げるのは，より深刻なもので，30年ほど前のある都市銀行での事例である。
銀行では，本部で業務施策を立案し，その遂行を支店に指示する。新たな業務施策が立案されると，対象先を選定するための候補をリストアップしたり，業務施策の進捗状況を管理したりするための資料として，新たな帳票が制定され，支店への還元が開始される。業務施策は永続的なものではなく，経営環境の変化に伴って，毎年のように見直しが行われる。多少の手直しだけの場合には，還元帳票は変更されずに使い続けられたり，小規模な変更が加えられたりする。業務施策が大幅に変更されたり，新たな業務施策で置き換えられたりするときには，新たな還元帳票が制定される。その際，旧帳票の廃止がシステム部門に伝えられることは，ほとんどない。本部の担当者が異動して，新たな業務施策が立案されたときには，前任者が制定した還元帳票が存在したことさえ忘れられている。このようにして，還元帳票の種類は単調増加を続け，実際には使われていないはずの還元帳票の出力に，夜間作業の時間が割り当てられ，保守作業にも多くの工数が費やされるようになっていった。
システム部門では，無駄な還元帳票を減らそうとして，アンケート調査を実施した。本部では，自部門が所管する還元帳票の一覧を担当者に回覧し，必要なものには“○”を，不要なものには“×”を付けさせた。担当者は，自らが立案し，推進している業務施策の還元帳票が必要であることは識別できるが，その他の還元帳票については，要否を判別することはできない。回覧を終えた一覧には，“○”が幾つか付いているだけで，“×”はひとつもなく，残りの大部分は，“○”も“×”も付いていない，要否が不明のものである。本部の各部門では，要否が不明なものを不要と回答して，何かトラブルがあったとき，その責任を負うことはできないとの考えから，システム部門に対しては，すべての還元帳票は必要であると回答することになる。
支店でも，事情は本部と大差はない。担当者は，自らが遂行を担っている業務施策の還元帳票が必要であることを識別できるだけである。 支店によっては，システム部門の意図が理解できず，支店の成績を評価するために，本部が，業務施策の推進への取り組み状況を調査しているものと勘ぐって，すべての還元帳票は，本部から指示されたとおり，適切に使用していると回答したところもあったようである。
ある時，業を煮やしたシステム部門は，強硬手段に訴えた。夜間に出力された還元帳票のうち，過去の業務施策に関連したもので，もう使われていないと思われるものをセンターに留め置き，支店に送付しなかったのである。これは，システム部門の独断で，所管する本部にも各支店にも無断で行われた。送付しなかった還元帳票について，どの支店からも問合せがなければ，使われていないことの証左になる。案の定，ほとんどの支店からは，何の反応も無かった。ところが，ある支店から，当該の還元帳票が届いていないとの問合せがあった。還元帳票を携えて支店に向かったシステム部門の担当者が確認した事実は，次のようなものであった。 その支店では，事務担当者が，前任者から引き継いだ仕事として，センターから送付された還元帳票をバインダーに綴じていた。連続用紙（11×15インチ）に出力された還元帳票は，ミシン目を切り離されることもなく，折りたたまれたまま，左側を22穴のバインダーに綴じられ，支店の大金庫に保管されていた。バインダーに閉じられた状態では，還元帳票に何が印字されているのかを確認することはできない。長い間，誰もその還元帳票の中身を見ていないことがうかがえる状況で，バインダーに綴じるという仕事だけが，連綿と引き継がれていたのである。
一つ目の事例のように，最初から“ゴミ”として作られたソフトウェアは，容易に捨て去ることができるだろう。二つ目の事例からは，すでに廃棄された“ゴミ”となったソフトウェアでも，最終処分は，必ずしも容易ではないことがうかがえよう。最後の事例のように，多くの“ゴミ”となっているソフトウェアが識別できずに，目に見えない産業廃棄物として，多大な時間と労力と費用を費やして，捨て去られることなく，企業内に隠され続けているのではないだろうか。
ソフトウェア工学の分野では，開発効率や品質，適用範囲に対する有効性といった観点から，主として “作り方” が研究されてきた。人や組織の活動を支え，密接な関係をもつ情報システムのあり方を考えるとき，“作り方”だけでなく，利活用や維持・管理などといった“使い方” はもちろんのこと，“捨て方”にも焦点を当てていく必要があるのではないだろうか。
以上，述べてきたことは，あくまでも私見であり，独断と偏見に満ちたものであるとは思うが，情報システム学会の今後の活動において，何らかの参考にしていただければ幸いである。