投票をお願いします！「保守/運用」の代替名

谷島宣之

2002.09.26

　今回の記者の眼は，9月17日に公開した「運用こそが上流工程，開発は下流工程」の続編である。前回記事の主旨は，「情報システムの保守と運用は，企画や開発に勝るとも劣らない重要な業務であるにもかかわらず，今一つそれが認知されていない」という問題提起であった。

　その中で，「保守/運用という言葉は後ろ向きの印象を与えがち。例えば，戦略保守/運用といった別な言葉を考えたほうがいいかもしれない。読者の意見を求めたい」といったことを書いた。ありがたいことに多くの方から，記事についての意見と保守/運用に替わる名称の案をお寄せいただいた。筆者が言いたかったことを別な表現で書いてくださった意見を二つほど紹介する。

■開発が前向きという表現を良く聞きますが，開発は瞬間のもの，その時点で最適なものであり，開発完了時は過去のものとなっている。それに対して運用は，単に現状通りに稼働させることが目的ではなく，現状にマッチし，かつ，先行きを見て今あるべき姿を実現している。よって運用の方が前向きな仕事であり，非常に多くの技術情報・知識を必要とする企業システムの核と思う。

■石器時代（汎用機）のシステムでは，「動かして，喜んで使ってもらえて，効果が出てナンボ！」という空気があったように思う。少なくとも，ベンダーの立場としてはお納めして，お客様に使ってもらってから「本番」だったように思う。さて，いつごろからだろうか？皆が「運用」や「本番」を考えなくなったのは？もしかすると，クライアント/サーバーでハードの購入費用や一時的な構築費用は安いが，運用費用や手間はべらぼうにかかるようなシステムを売りつけるようになってからではないだろうか？古いシステムの中にはもう何十年もお客様に喜んで使いつづけてもらっているシステムも多い。はたして，今作られているシステムのいくつが今後20年以上使い続けられるのだろうか？いつの間にか，ITシステムの目的が「使ってもらうこと」から「作ること」いや，「売りつけること」に変化してしまったのだろうか？本来，システムは「動きつづけてナンボ」「使われてナンボ」のものです。

　こうした意見に対し，例によって返答を書いてそれを公開することで，読者の意見を多くの方に紹介しようと考えた。しかし，いつも同じやり方では芸がない。そこで，まったく別なことを思いついた。

　それは，記者の眼の読者の方に「投票」していただこうというものだ。読者から寄せられた保守/運用に替わる言葉の中から，「これはいい」というものを一つ選んでいただきたい（“投票”は本文の最後からどうぞ）。

　筆者は今後，一番票が多かった言葉を使って，運用/保守の重要性をアピールする記事をあちこちで書くことにする。たいへんお手数ではあるが，ご参加をお願いしたい。せっかく双方向性のあるメディアを使っているので，たまにはこうした試みも面白いと思う。

言葉だけ替えても意味がない

　読者から送られた代替名称を列挙する前に，読者の意見をいくつか紹介し，お断りをしたい。まず，「別な言葉を考えてはどうか」という点について，「言葉いじりをしてどうなる」というお叱りを多数いただいた。

■言葉をいじっても，実際の評価が低く抑えられているなら，結局数年後にはその言葉のイメージは今の「運用」と同じレベルに引き下げられるのではないか。言葉を飾るのはアメリカのほうでも同様。技術サポートやヘルプに，「テクノロジー」「リサーチ」「アドバンスト」など，ちょっと恥ずかしい。他人の仕事を軽く見る風潮があるからこそ，それを隠すために肩書きのインフレが起こるのであって，意識改革なしにはいつまでたっても同じことの繰り返しになるでしょう。

■「運用の重要性を経営陣や利用部門，そして運用部門自身に認知させる」のは，言葉ではないと思います。この手のキャッチフレーズは，当たった試しはほとんどないでしょう？それよりも保守/運用の重要性をきちんと経営陣に説明できていないところに問題があるのでは？日経コンピュータで大々的にとりあげれば，少しは経営者の認識も変わるかもしれませんが。もっとも保守/運用業務に携わっている当事者自身に問題あり，というケースも多見されるのもまた事実です。問題とは，受身で開発部門へのフィードバックやコミュニケーションがとれない，といったことです。

■言葉をかえればいい問題なのでしょうか? よく差別用語と銘打って言葉狩りが好きな人もいますが，そういうことは本質的な部分から目をそらすだけで解決にはつながらないように感じます。さらに「資産運用」は後ろ向きに感じませんし，運用という言葉の問題でもないように思います。開発に成功したという記事はよく見るのに運用に成功したという記事は出ません。出るのは失敗だけ。運用はとかく地道で地味な作業に感じがちです。言葉を考え出すより，運用の楽しい部分など，運用のイメージが上がる記事を書いてくださることを希望します。

　代替案について投票をしてください，と書いた直後に書くと変であるが，筆者は「言葉だけ替えてどうなるのか」という意見に実は賛成である。確かに言葉いじりだけしても，本質的な問題を解決しなければ何にもならない。

　しかし，この問題を多くの人にアピールするきっかけとして，言葉を考えてみるのは面白いと思ったのである。「言葉も考えるし，本質的改革ももちろん考える」というつもりであった。今回の投票も，そうした意図の延長にあるので，ご理解いただきたい。

　「日経コンピュータで大々的にとりあげれば」，「運用のイメージが上がる記事を書いてくださることを希望」については，まったくその通りである。早速，日経コンピュータ編集長にかけあって，「保守/運用のイメージが上がる記事を大々的に」掲載してもらうことにした。

　筆者は現在，日経コンピュータ編集部の外にいるので，勝手に書いていいのかどうか分からないが，日経コンピュータの「特集」として掲載する予定である。担当は，西村崇記者になった。西村は優秀な記者ではあるが，保守/運用の実務経験は皆無である。保守/運用について一家言ある方はぜひ，日経コンピュータ編集部あるいは西村に連絡していただきたい。
（日経コンピュータ編集部のメール・アドレスは，ncreader@nikkeibp.co.jpです）

　ありがたいことに，我々メディアへ期待してくださる意見はほかにもあった。

■開発段階では費用対効果がゼロであり，運用に入って初めて効果を生むことが忘れられがちだと思います。運用管理が軽視される原因は，いろいろ考えられます。開発関係の技法や図書は多く，職人芸から工学へと発展しつつありますが，保守運用はそのような取り組みがあまり見えないことも大きいのではないかと思います。雑誌などにおいても記事の比率は開発のウエイトが高いように思われます。

■私はバブル期をUNIXで育った世代ですので，システム管理者とかネットワーク管理者とか運用管理者を「神」だと思っています。いまだに当時のクセが抜け切れません。なんと言っても全知全能のスーパー・ユーザー(root)です。開発工程時も，開発スケジュールや開発ワークフロー，組織間インタフェースのルール作りなどは，特権階級である運用管理者の仕事でした。ライブラリやソース，リリースの管理なども重要なタスクですね。情報系システムのネットワーク設計業務と，勘定系システムの監視オペレーション業務とでは，立場が大きく違いますが，「管理者」として一緒に扱っても構わないでしょう。世の中，業務ノウハウやデータベース設計でメシを食っているSEばかりではありません。いわゆる運用管理者(システム管理者)向けに特化した幅広い技術情報を期待しています。名前は何でもよいですが，新雑誌なんてどうですか?

経営者の問題である

　「運用管理者(システム管理者)向けに特化した新雑誌」は面白いように思う。ただし，ただでさえ雑誌が多すぎると批判される弊社であり，既存雑誌との棲み分け問題があって，発行できるかどうかは不明である。

　次に，経営者にもっと保守/運用の重要性をアピールすべきという意見が寄せられた。

■言葉の定義はどうでもいいが，経営者が運用部門と開発部門の連携の大切さが分かっていない点が問題だと考える。確かに，新たな物を作り出すと言うような斬新さは運用・保守にはない。だが，安定稼働を実現するという大変な仕事である。パソコンはソフトがなければただの箱とはよく言うが，システムは運用がなければただのバイトコードなのではないだろうか？

■新しい言葉がないと重要性を認知できないという，存在価値のない経営陣を排除できる体制を作るべきだろう。できない組織はそろそろ淘汰されてよいのではないか。

■会社になぞらえれば開発は創業であり，運用こそは日々の経営に相当するわけです。経営者たるもの，わが身の仕事に引き当ててよく考えてみる必要があるでしょう。もっともサラリーマン社長というのは，創業者から見ると経営のアウトソーシングと見ることもできますし，やっぱり運用はアウトソーシングしたほうがメリットが大きいように思います。

　筆者は時々，「情報システム部門によるクーデター」とか，「協力ソフト会社による下克上」といったことを妄想する。「存在価値のない経営陣を排除」という下りを読んで，またいろいろ考えたが，このテーマは別な時に書いてみたい。

　また，「運用はアウトソーシングしたほうがメリットが大きい」というご意見についても，“アンチ・フルアウトソーシング派”を標榜している筆者としてはいろいろ書きたいのだが，こちらもまた次の機会に譲りたい。
　
　まずは経営者に理解を求める努力が必要であろう。それについては「定量的手法によるアピールが必要」という意見が寄せられた。　

■経営者に前向きに捉えてもらうためには，経営戦略に対してどれだけ貢献しているかを明示する必要があると思います。開発の費用対効果を見積もるのと同様です。その上で初めて，コストセンターからの脱却ができるのではないでしょうか。保守/運用部門からのアピール不足と思います。

■「上流工程＝決算と生産性の評価」。それ以外はすべて下流工程でしょう。少なくともそういう視点で評価しないと，正しい業務上の判断は下せないと思います。企業として，他に価値判断の基準があれば別ですが｡

■運用部門に費用や人員などリソースの配分が少ないという問題は，システムの開発開始から寿命末期まで通した発生コストの評価（LCA)と数値的なアピールが不十分だからではないでしょうか。ハードウエアと違ってシステムは維持に手間が掛かるというのは随分前から常識です。だたし，掛かるカネの多さについては認識していない経営者層もいるかもしれません。あるいは，製造業の製品(ハード)の見方で，開発設計＝上流，製造＝下流と短絡的に見ているかもしれません。製造業でもこの見方が正しいかと言う問題もありますけど。

　経営者とITプロフェッショナルが議論できる共通言語がないことが，情報化をはばむ大きな要因である。指摘のあった，コストや生産性は，そうした共通言語の有力候補であろう。もう一つの共通言語として，データやプロセスを可視化する手もありそうだ。

■保守や運用の実際の作業を考えた場合､「データベースの管理」をしているのではないですか? 保守や運用が上流工程という概念については賛成です。設計/開発のコンセプトの中にプロダクション移行後のデータベース管理も取り入れることによってはじめて効率の良い，ランニングコストを削減できるシステムが完成すると考えます。UMLを活用すればコンセプトの完成度はよりあがるのではないでしょうか。同時に経営陣に対して，運用/管理と呼ばれる部署の大切さを訴えるデモンストレーションの材料にもなりうると考えます。

■保守/運用を上流工程として認識するのには賛成です。こうした作業をシステム開発の一環として位置付け，業務上重要であるにも関わらず，最も地味な作業と軽視しているのが問題のようです。従って，ビジネスよりの視点を取り入れ，保守/運用をビジネスプロセスの一環として見なせば，社内での重要性も増すのではないでしょうか。そうなると技術に限らず，責任のおよぶ範囲も広くなります。

　経営者問題についても，次のようにメディアへ期待する声があった。筆者は10月以降，経営者や利用部門のマネジャが読んでいるメディアにも記事を書いていく予定なので，そちらでも保守/運用問題を取り上げたいと思っている。

■問題は「経営層にどうやってそれを分ってもらうか」との提言でしょう。一つの方法として，「運用」「保守」の軽視は経営者に直接被害が及ぶという実例を突きつけることでは。ウイルスやみずほ銀行によって機密安全／開発管理の認知度があがりました。これにはマスコミの力が大きかったと思います。「運用」「保守」についても同様の取り組みをお願いしたい。残念ながら社内の人間が訴えるより，社外の第3者的な提言の方が効果があるのは事実です。多額な投資をしたシステムで，実際は動いていないというシステムはいくらでもあり，その中には「運用」「保守」の軽視が原因であるものがあるはず。

　経営者の批判は重要だが，それだけで済ませてしまってもいけない。運用や保守を担当している部門が自己改革すべきという意見も多かった。

■記事全体を通して二つくらい不満がある。運用が軽視されている場面は確かに散見されるが，そういうところの開発は，内情を見ればやっぱり軽視されている。そういう点においていえることは「考えているところは考えている，そうでないところはそれなり」でしかない。上流とか下流とか，そういう選民意識が出てくること自体を私は好まない。よい設計であれば運用も楽になるはずだし，逆もまた然り。すべてとは言わないが，多くのところで「十年一日のごとき」運用を目にしている。そういったところを内部から「改革」していくこともまた重要なのではないだろうか？

■私は製造業の情報化推進部門で働いているのですが我々も全く同じ状況にあります。本テーマは分かり切っていることだけに奥が深く本当に難しい問題だと思います。ユーザー側も仏作って魂入れずではダメだと口では分かっていると言いながら，最終的に魂を入れるのは自分たちだと理解していながら，開発側でうまく入魂してくれないかなぁと心のどこかで思っているのが現実ではないでしょうか。

■大筋は賛成。しかし，運用担当者に企画／設計に参加することを義務化したくても，そんな暇はないというのもまた現実。「開発→運用→開発」のスパイラルを回すうちに，変な方向に進んでしまうこともしばしば。意識改革だけで済む問題ではなかったりします。

成功事例もある

　確かに，「運用担当者の企画/設計への参加」を義務にすることは簡単ではない。しかし，なんらかのやりようはあると思う。今回，読者の書き込みを読んでいてうれしかったのは，元気のいい成功事例があったことだ。

■私どもの会社では，運用の方が開発部門より優秀な人材がそろっています。過去に何度も，「こんなシステムなど動かせるわけがない！」と言われたものを運用にのせてしまいました。また，運用部隊の方が視野が広く，柔軟性に富んでいます。よって，全く別の部署に行っても，結構なじんで仕事をしているようです。

■いわゆる“ユーザー企業”に籍を置くものです。私の部門でもここ数年，システムを企画した人間が運用し，さらにその経験を基にしてシステムの拡張や新規開発を企画する，といったやり方に変え，なかなかうまく回っています。組織や事業の規模，内容によって一概には言えないかもしれませんが，企画=>開発=>運用=>企画，を上流，下流，というように分けずに，同じチームが責任を持ってやれるとよいのではと思います。こうできれば，「運用は日が当たらないからイヤだ」などと言ってられません。

　お差し支えなければ，この二つの意見を書かれた方々は，日経コンピュータの西村記者に連絡していただければと思う（日経コンピュータ編集部のメール・アドレスは，ncreader@nikkeibp.co.jpです）。記事では，「運用の方が開発部門より優秀」とは書かないので安心していただきたい。後者の方はひょっとすると，行きがかり上，運用までしなければならなくなったのではないか。それでも，マイナスの状況をプラスの方向へ持って行かれているのは立派である。

　さて，いよいよ投票である。　

　読者から寄せられた運用／保守に変わる名称の代替案を列挙する（いくつか表記を少し変えたものもある）。一番よいと思われる言葉を一つ選んで，下の「送信」ボタンを押していただきたい（ただし，多重回答を避けるために，回答できるのはIT Pro会員の方のみとさせていただきます[会員登録はこちら]。また，回答はお一人様一回に限らせていただきます）。

　結果は後日，この記事に追記する形でご報告する。先に書いたように今後，筆者はその言葉を使いたいと思う。ただし，日経コンピュータが主催する「事例で探るシステム保守/運用の戦略化」（概要とお申し込みはこちら）については，このままの名称で実施する。ご了承いただきたい。