Synapse Diary

ITシステムの運用・保守体制においては、決まった定型作業を実施することが多いため、オペレーター気質の人が向いているというイメージが強い。

もちろん、それも一理あるのだが、それよりも重要なスキルが、現場では不足しているように思える。それがコミュニケーション能力だ。その理由は、現場では次のような状況に対応する必要があるからだ。

ユーザの要望は完璧ではない

予め決められた作業や、ユーザの言われた通りの作業を行えば全ての作業が完了、という現場は少ない。ユーザの中にはシステムに不慣れであったり、ITシステムに対する知識が不十分な人もいる。なので、誤解をして依頼内容を伝えてくる場合もある。また、ユーザも人間なので、単純に間違えることもある。

こういうときに、ユーザの依頼の意図や背景を丁寧に読み解く必要がある。設計書や過去の書類を確認したり、場合によってはユーザに直接ヒアリングもする。それぐらい、作業内容を理解して実施するべきなのだ。さもないと、思い込み・決め付け・誤解が生じ、ささいな作業ミスから、重大な障害を引き起こすことだってある。

ユーザの要望を正確に汲み取るとき、効果的かつ煩わしさを感じさせない、ユーザとのコミュニケーションが重要になる。

ITシステムには連携先がある

ユーザの業務は、大抵の場合ひとつではなく、複数のシステムで成立している。それらはデータの連携を行っており、それぞれのシステムは別のベンダーが管理していることが多い。

この状況が何を作り出すかといえば、連携部分に変更が生じたりすると、必ずベンダー間で仕様やテスト方法をつめなければならない。ここで、明確な責任範囲と、確実なシステム変更を達成するために、コミュニケーションスキルが求められる。お互いのベンダーの思い込みや決め付けを回避するのだ。

さらに話をややこしくするのは、各システムのユーザ側の主観が異なる部局だったりする場合。こういうときは、例えば2システムに関係する4者（自分、自分の主管ユーザ、連携先ベンダー、連携先ベンダーの主管ユーザ）がやり取りすることになり、情報伝達の交通整理を行わないと、コミュニケーションロス、食い違いなどの、深い混乱を招く恐れがある。

運用体制に外注先ベンダーがいる

IT業界はゼネコン体質だと言われている。それは開発でも運用・保守でも変わらない。運用・保守体制の中に、外注先ベンダーが加わることがあるのだ。

この場合、自分の会社の論理が通じなかったり、微妙な距離感が出てしまうので、自分の立ち位置をうまくコントロールし、円滑なコミュニケーションを実現することが重要だ。社内で通じる「あ・うんの呼吸」の類が通じないこともあるので、十分な説明を心がけたり、外注先の会社・組織の理解を深める努力も必要だ。

結論は・・・

端的に言えば、運用・保守を行う上でもたくさんの関係者がおり、臨機応変で柔軟な対応が求められる。また、各関係者に説明責任を果たさないと、自分の信用は失墜することだってある。

だから、人を雇う側の立場の人は、必ずそういうコミュニケーションを発揮できる人がいるか、考えてみましょう。雇われる側の人は、関係者がどれぐらいいて、それぞれに対してどういう立ち位置で接触するかを考えてみましょう。どう接することが、円滑な作業進捗に寄与するでしょうか。

速効! SEのためのコミュニケーション実践塾 (日経ITプロフェッショナルBOOKS)

posted with ヨメレバ

田中 淳子 日経BP社 2004-04-10

Amazon

Kindle

楽天ブックス

運用・保守におけるプロジェクトメンバは、モチベーションを維持するのが難しい。長期化するプロジェクト、大半を占めるルーチン作業。そして、「できて当たり前」の空気をユーザから前面に出され、ミスをしたら怒られる。
 
こういった状況の中で、どうやってモチベーションを維持・向上させればよいのか。

一般的なモチベーションのきっかけ

一般的に言えるモチベーションの向上策は、「金銭・賞与で評価する」「ポジションで評価する」がほとんどだ。しかし、運用・保守では金銭はそんなにリッチじゃない。この間書いた記事にもあるように、コスト圧縮力が強く働くからだ。
 
また、ポジションでの評価も難しい。運用・保守で何百人規模、なんてのはほとんどなく、数名から、多くて数十名で運用するのがほとんどだ。そうなると、ポジションがほぼ固定になる。さらに、長期プロジェクトとなるため、余計人の移動がない。よって、ハイレベルな仕事を与えてストレッチ、という状況は作りづらい場面が多い。

新しい何かを取り入れようぜ

ただ、手をこまねいているだけでは芸がない。お金がなくても、人の移動が少なくても、意識を変えるためにできることは多い。考えられる点を列挙してみた。

①最近のIT業界の情報を入手してますか。自分だけじゃなく、同じプロジェクトのメンバともそれを共有できてますか。

日経コンピュータでも良いし、ビジネス本などでも良い。それがプロジェクトの現場にあって、みんなが手に取り、休憩中などに読める状態にする。知るだけど行動や考え方が変わることがある。情報に触れ、それを共有する場があると良い。

②勉強会やイベント情報は入手していますか。

勉強会などの情報は、ネットで探せばすぐに見つかる。ここで一番大事なのは、「行くこと」ではなく、「行くつもりで情報を集める」ことにある。とにかく行動してみる。もちろん、自分のキャリアに合致する勉強会があれば、行く方がいいに決まっていますが。
http://jibun.atmarkit.co.jp/lcom01/special/benkyo/benkyo01.html

③IT資格の取得に向けて勉強してますか。

ITは、情報処理技術者試験で、体系的にランク・専門が分類され、スキルアップの基準としてわかりやすく設計されている。今の自分に合致する資格を選び、それを取得することで、知識の向上、自分ブランドの向上につながる。プロジェクトを出てからも有効に使えるのもメリットだ。また、それ以外にもOracleやSAPなど、専門ベンダ試験も豊富であるため、今の自分に有効な資格、というのは、探せばあると思う。さらに、お客さんの業務に関連する資格を取得してみるのも面白い。法律や流通、販売に関する資格も、世の中にはたくさんある。

④お客さんの業務や立場は本当に理解していますか。それに関する情報は定期的に取得していますか。

お客さんがメールマガジンやブログをやっていたら、購読する。お客さんの取り巻く業界情報なども、日経新聞やGoogleアラートなどから、積極的に入手する。これだけでも、お客さんの業務理解が深まり、コミュニケーションが円滑になったり、その業務を支えるITシステムを運用している自分たちに、社会的な意義を見出すような観点が生まれるかもしれません。

⑤「オフ」で会話できる機会は、どれぐらい作ってますか。

「飲みニケーション」ではないけれど、仕事の場以外で上司や同僚と会話できる機会は設ける方が、やはりコミュニケーションは円滑に進む。それは飲み会でなくても、ランチでも良いし、コーヒーブレイクでも良い。タバコ部屋だって、立派なオフだ。（個人的にはタバコは吸わないが、気分転換とコミュニケーションのきっかけとしてはプラスであり、そのためだけに吸おうと考えた時期もある。）なんだったら、「オフ」な内容のメールを送るのだって、立派なコミュニケーションだ。コミュニケーションは、知識の取得、意識の向上、気分転換を促す良い手段である。コミュニケーションは、適度にないと閉塞感が漂い始める。
 
 
とりあえず、こんなもんだろうか。そんなにお金をかけなくても、できることはあるんだと改めて思う。
あとは、「自分が変えていく」という信念ぐらいですかね。必要なのは。

図解 きほんからわかる「モチベーション」理論 (East Press Business)

posted with ヨメレバ

池田 光,栗原 晴生,滝本 泰士,永屋 義行 イースト・プレス 2008-06-25

Amazon

Kindle

楽天ブックス

ITシステムは、よく開発が注目されるが、保守・運用も実は重要なポイントである。
なじみがない人にとっては、ITシステムの運用といわれてもイメージわかないかもしれないが、
地味ながら、世間的には結構な金額が投資されている世界である。
（ITコスト全体の7～8割を占める、ともいわれているし、あの社会保険庁のシステムの運用・保守費は800億円/年ぐらいらしいです。民主党参議院議員　ふじすえ健三: 社会保険業務センターの視察）
 
保守・運用で何をやるかといえば、ざっくり次のようなことである。
・障害対応（作ったシステムにバグがあった場合に）
・作業依頼（ユーザがアプリ上から操作できないが、実施する必要があるものを行う。データ登録等）
・仕様変更（法律や社会情勢が変わったり、使用しながら改善箇所が生じた場合に、プログラムを修正）
 
他にもユーザに対する研修のサポートも行ったりする。
 
さて、本題。
運用・保守において陥りがちな罠として、大きく4つ挙げてみる。
 
・慣例主義になる
　「過去同じ手順でやったから大丈夫」みたいな、慣例主義的な状況に陥り、より効率的・効果的な見直しに対する動きが著しく小さくなる。
 
・ITコスト減少圧力を受けやすい
　契約する年数にもよるが、契約更改時には必ず、「作業に慣れてきてるんだから、次の契約では10%以上は削れるだろう」みたいなコスト減少に対する圧縮が必ず生じる。これ自体悪いことではないし、一般的な理論としては間違っていないが、総合的な状況を踏まえて、本当に削減して運用・保守できるかは注意が必要である。
 
・作業メンバの確保
　運用・保守は、ある程度長期（2～3年以上）の要員確保が望ましい。なぜなら、システム技術に加えて、必ず顧客の業務理解も求められるし、大抵は業種に限らずどこでも業務は1年間のリズムでできあがっているので、2年以内で辞められてしまうと、費用対効果が低くなるからである。一方で、IT業界は人のサイクルは早い。
 
・作業メンバのモチベーション低下
　運用・保守は、全てではないにせよ、ルーチンワークが多い。そうなると、やはりモチベーションは低くなりがちである。システム開発は、仕様を調整して、開発して、テストして、テストさせて、というフェーズの切れ目があり、流れと勢いがあるが、運用・保守ではそれがほとんどない。
 
 
ざっと思いつくのはこれぐらいだろうか。
これらについて、効果的に手を打てているところは、実はあまりないのではないだろうか。
ユーザから見えないところで、結構綱渡りで作業を実施したり、人のやりくりをしてしまっているプロジェクトも多いと思われる。
 
まずは、こういう問題が存在することを、情報システム部門や運用・保守を担うITベンダの作業メンバは、認識することから、安定的な運用体制の構築が始まる。
今後は、もうちょっと具体的な解決策なんぞも含めて考えてみたい。

開発の現場 vol.007

posted with amazlet at 09.09.18

翔泳社
売り上げランキング: 55121

Amazon.co.jp で詳細を見る

 

あわせてどうぞ。