運用・保守体制に不足するスキル

 

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

 

結論は・・・

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

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

 

プロジェクトメンバのモチベーションを向上する方法

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

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

ITシステムの保守・運用において陥がちな罠

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

 

開発の現場 vol.007
開発の現場 vol.007

posted with amazlet at 09.09.18

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

あわせてどうぞ。

 

まず、ルールを破れ

「自分より優秀な人材が部下になった場合、どうするか。」
まずは、部下が働きやすい環境を作り上げることに専念すれば良い。

この 本は、優れたマネージャーの資質を解き明かすことを目的に、ギャラップという調査会社が各企業の優秀と言われているマネージャーにアンケート調査を行い、 分析した結果を取り纏めたもの。優れたマネージャーは、企業のルールや先入観にとらわれた決まり事をあまり気にせず、部下のパーソナリティであったり、状 況の変化に応じた対応を行う。そのために、人や物事を良く知り、分析する必要がある、と説く。

面白いのは、やはり「オペレーター」からス テップアップして、「マネージャー」という、組織構造でよくありがちなキャリアアップに疑問を呈していること。「ピーターの法則」みたく、自分の適職では なくなるまで、昇進を続けるようなキャリアパスは、今でもよくある。もちろん、いろんな工夫により見直されていたりもするが。
http://japan.cnet.com/blog/kenn/2004/06/26/entry_post_30/

さて、冒頭の質問に戻って。自分より優秀な人材が部下になった場合、どうするか。
やはり悔しいものである。負けを認めたくない。存在を認めたくない。なんなら、ミスを責めて自分の優位性を示したい。
しかし、それは全体最適でもないし、そういう境遇に出会ったときは、自分の重要な分岐点になるだろう。自分の働き方に大きな見直しが迫られるときだと思うのだ。

同 じ土俵で考えたとき、これまでの自分の何かの努力が足らなかったのかもしれないし、同じ土俵で勝てないのならば、自分の存在意義は違う方向で示すしかな い。そのときに、優秀な人材を「マネージ」する立場として、部下が働きやすい環境を作ることに専念してみる。それによって、自分の働き方が大きく変わる きっかけになるだろう。

負け意識を自分に植え付けるのではなく、敵対心を剥き出しにするのでもなく。
考え方をシフトして、働き方をシフトする。

会社を辞めるのは、その後でも良いだろう。

まず、ルールを破れ―すぐれたマネジャーはここが違う
マーカス バッキンガム カート コフマン
日本経済新聞社
売り上げランキング: 1431

はじめての課長の教科書

ところどころ「課長に特化している話?」と思うところはあるけれど、考えさせられるポイントは多い。

・「マネジメント(大局)」と「現場」の中間に位置する
・課長の権限範囲は、一番最小の経営単位である
・部長の部下は、優秀で退職リスクの低い課長たちだが、課長の部下は、退職リスクの高い若手や非正規雇用者が混在しており、それぞれに適した接し方が求められる

等々。

この本から何を学ぶかといえば、組織はいろんな要素で構成されており、立場によって立ち居振る舞いや考えるポイントなどを、柔軟に変えていく必要がある、ということ。
大体の組織にいれば、多くの人は中間管理職を経験するものだから、そういう組織構造を意識することは非常に重要なこと。

さて、あまり関係ないかもしれないけど、
今また話題の六本木の元社長の組織運営の考え方とか、工夫とか載ってて、
結構面白い。
http://gigazine.net/index.php?/news/comments/20090302_horiemon01/

はじめての課長の教科書
酒井穣
ディスカヴァー・トゥエンティワン
売り上げランキング: 1289

 

自分の強みを知る方法。ストレングス・ファインダーを使おう

自分の強みを知る、というのは案外難しいものです。それは、普段それほど自分の強みを自覚するきっかけが少なかったり、言語化が難しいことによるものです。

というわけで、自分の強みを知るためのツールとして、「ストレングスファインダー」を使ってみましょう。「ストレングスファインダー」は、世論調査やコンサルティングサービスを提供するギャラップ社で開発されたツールです。

Gallup.Com – Daily News, Polls, Public Opinion on Politics, Economy, Wellbeing, and World

ストレングスファインダー自体は、以下の本を購入することで個人でも簡単に実施することができます。効率が10倍アップする新・知的生産術―自分をグーグル化する方法で推奨されていたので、すっかり有名になったのがこの「さあ、才能(じぶん)に目覚めよう」です。

ストレングスファインダーの考え方は、「弱みよりも強みに焦点を当てることで、才能をもっと引き出せるはず」というもので、その詳細はこの本にも書かれています。才能と知識と技術をちゃんと定義し、その違いを明確にしているのですが、これが明確で良いです。才能については、こう書かれています。

才能とは、無意識に繰り返される思考、感情、行動のパターンである。 知識とは、学習と経験によって知り得た真理と教訓である。 技術とは、行動のための手段である。

この本を購入すると、IDがついており、HPにアクセスしてそのIDを入力すると、自分の強みを把握する「ストレングス・ファインダー」のテストを受けることができます。テストをやること30分で、自分の強みとなる5つの要素が弾き出されるのです。本の中でも、それぞれの強みの特性が詳細に書かれているので、照らし合わせてみるとよいでしょう。

これをどう捉えて、どこまで信じるかは個人の自由ですが、僕個人の体験としては、自分の強みが言語化されたことに最初感動を覚えました。そうそう、自分ってそういうところあるよねと思うところもありますし、いろんな物事を「言語化された自分の強み」を通してとらえなおすことができると思います。「自分の特性から考えると、この作業は自分に向いているかも」など、考えるきっかけになるのです。

また、10年程度経過して改めてストレングスファインダーを受けてみましたが、多少の変化はあってもほとんど強みの項目に違いはありませんでした。ある程度、人間の本質的な部分をあぶりだすようなツールといえるんじゃないでしょうか。

ホワイトカラーの生産性

日経新聞を読んでいたら、トリンプ社長の記事があった。 「日本のホワイトカラーの生産性は低い」とあった。 同感だ。自分もホワイトカラーの現場にいるからわかるが、低いと思う。 人間、デッドラインがあれば、それに照準を合わせてだらだら仕事をしてしまう。 デッドラインがなければ、もっとだらだらしてしまう。 毎日の「残業癖」がついてしまっているように思えてならない。 トリンプは、時間がきたら必ず消灯。 残業は事前申請して罰金2万円。サービス残業は罰金5万円。 よくよく考えると、かなり合理的な制度だ。 これぐらいやらないと、人間の意識は変えられない。 ワークライフ・バランスなんて言葉は、泣けるぐらい現状は悲しい。

会議の生産性を上げるには

最近ある人に、会議が長い傾向がある、という話をしたら、
そっとこの本を貸してくれた。
いや、常にこういう意識が必要なんだと思う。
実務レベルで、非常に細かく書いてあって、面白かった。
以下、気になった点を抜粋。

人件費10億円程度の組織(平均賃金700万円程度の社員が150人ほどいる組織)では、2億円から3億円程度が会議に使われていることになります。

会議の効果が出ないのは、「改善案が実効性に乏しいこと」と「優れた改善案が組織に十分に徹底されていないこと」、この2点が問題となっているわけです。

(資料について)
時間と枚数の関係については、A4サイズであれば、説明する資料1枚につき3分から5分を見積もっておくのが適当です。報告時間に15分もらえるのであれば、3枚から5枚が妥当な枚数でしょうか。

優れた議論とは、以下の2つの要件を満たしているものです。
・目的に合った結論が出る
・参加者が結論に納得する
そのためには、次のような条件をそろえなければなりません。
・論点が明確であり、十分網羅されている
・論点を参加者が共有し、必要な意見を述べている

ビジネスコンサルティングの知識工房
会議の教科書 強い企業の基本の「型」を盗む!
会議の教科書 強い企業の基本の「型」を盗む!
山崎 将志


Warning: Trying to access array offset on value of type null in /home/synapsediary/synapse-diary.com/public_html/wp-content/plugins/amazonjs/amazonjs.php on line 637