2006年9月27日
9月も終わりになり、季節は夏から秋一色になりつつあります。また、この季節になると「いつもやらなければな・・」と思いだすのが、情報処理試験です。最近になり、私は勉強をする癖はようやくついてきましたが、やはり試験と言うと、ちょっと弱腰になってしまいます。
昨今急速な普及しているものとしてITサービスの管理・システム運用に関しての、国際標準であります「ITIL」があります。システム運用での資格の話では、ITILでは、ファンデーション、プラクショナル、マネージャーといった形で資格があります。日本国内でのITILファンデーション認定資格者が2006年2月には約一万人も突破していることを最近知りました。その伸び率も2003年にit SMFの団体が設立されてから2〜3年の間でもっとも普及率が高い国ということで日本は注目されています。
資格ではないのですが、本サイト「Kaizen-ikasu」も、現場に教育、啓蒙するという意味で、教育費の予算枠でご契約をいただいているケースが多いです。是非「kaizen-ikasu」を使いシステム運用の現場にて部門の活性化につなげていただければ幸いです。（担当：伊香輪宣隆）
2006年9月20日
今回は、シスドックアドバイザーとして多くのお客様を訪問した際に、感じたお客様に共通した問題点をお話したいと思います。皆様の運用部署も同一の問題で悩んでいませんか。
まず、最初にお客様から共通してお話頂く内容として以下の自部署の問題点が挙げられます。
- 部員のモチベーションが高くない、どうすれば高めることができるか
そこで、なぜモチベーションが低いのかシスドックとして簡単なヒアリングを行うと、共通した次の２点の事象が見受けられます。
-
障害数が（異常に）多いにもかかわらず、障害を繰り返している（もしくは、障害をなくさなければならない）という意識が見受けられない。
- 自分が行っている業務の（作業）マニュアルが整備されていない。
この２点が、できない理由として運用の人数が削減され時間がないこと挙げています。
これでは、手順もなしに（記憶のみで）仕事を行い、ミスを犯しそのリカバリーも記憶のみで行うという悪循環であり、「楽しくない」「後ろ向きである」という意識が芽生えてしまいます。
この悪循環を断ち切る方法として、「カイゼン」をお客様に体験して頂き、「カイゼン」することの喜び、楽しさを知って頂く。「カイゼン」は、自分がどうすれば「楽になるか」、「早く帰れるか」を最初のキーとして取り掛かることを勧めています。「カイゼン」の結果として「コストダウン」「ユーザーへのサービスアップ」へと繋がって行きます。これにより、ユーザー、上司、同僚からお褒めの言葉や、「カイゼン」をグループが自分が行ったという充実感よりモチベーションアップがはかられる結果となります。
このような現場で、働けるシスドックアドバイザーも楽しい仕事です。それでは、現場でお会いしましょう。（担当：田中康治）
2006年9月13日
おかげさまで、会員制サービス「シスドック」の契約企業が増えてきています。私たちアドバイザーとしては、業績が上がる反面お客様へのアドバイザリー活動が忙しくなるという嬉しい悲鳴を上げている今日この頃です。
私が担当しているお客様へのアドバイザリー活動についてですが、最近の傾向として運用部門の活性化やメンバーの意識改革を目的とした活動がほとんどで、まず、メンバー個々人の行動特性についてコンピテンシー診断を利用して認知・可視化から始めています。
さて、この「コンピテンシー」とはいったい何なのか？何が可視化できるのか？について少し説明します。
「コンピテンシー」とは一般的に「継続して成果を出し続ける能力」と言われており、私たちが実施している診断では「概念化能力」や「状況感受性」など９つの行動特性のバランスを見ることができます。「コンピテンシー」では、その人の能力を「成果につながる行動を続けていけるかどうか」で見るもので、その人が優秀か否かという観点ではありません。各行動特性において、高ければ自信があり、低いと関心があまりないといった具合です。優秀であっても成果につながる行動ができていなければ「コンピテンシー」の観点から言えば能力が低いことになります。比べて、１つの行動特性について確実に行動に移し、実践しているほうが能力が高いことになるのです。
個人診断ですが特に隠すものでもなく部門内の廻りの方々に自分を知ってもらう、また、廻りの人のことを知るということも実践しています。そうすることで新たな気付きが生まれ、少し行動を変えてみようという意識が根付くのではと考えています。
実際「コンピテンシー」診断結果の解説時での印象ですが、概ね納得のいく結果のようで、逆にショックを受けられる方も時々見受けるのですが、それはそれで認知できたことになるのです。また、異様な盛り上がりがそこに存在していることを感じます。
この盛り上がりを維持して、運用部門を活性化させていくカイゼン活動を支援することが私たちのミッションです。まだ、会員になられていない企業の方々、会員制サービス「シスドック」を利用して運用部門を活性化させてみませんか。(担当：横山慎二)
2006年9月6日
5月頃から、あるお客様の基盤再構築に関するマイグレーション設計をお手伝いさせていただいており、8月末に第一フェーズが終了して9月から第二次フェーズに入りました。
この基盤構築設計を進めるにあたり、さまざまなプロダクトやツールを利用して設計をしていきますが、どうしても標準型では業務が実施できない場合、個別対応を実施しますいわゆる”カスタマイズ”です。このカスタマイズで結構問題が発生します。
設計してみたら、「できると思っていたことができなかった」とか「想定していたよりも複雑だった」など、当初想定していた工数を上回って予算内に収まらないなどです。
お客様側としてみれば、当初想定した工数でしか予算を取ってないからその中でやって欲しいいう希望があると思いますが、受注側からすると当初の仕様が変更になったからその分の費用を上乗せして欲しいとの希望があります。
この問題を解消する手段として、設計フェーズと製造/テストフェーズに分けて受注をするといった手段があります。一年ぐらい前にコンピュータ専門誌にも記載されていましたが、今回、この手段を使って受注をしてみました。
具体的にプログラム設計/開発に関する部分については、
- 全て調査/設計フェーズ（第一フェーズ）と製造/テストフェーズ（第二フェーズ）に分ける。
- 調査/設計フェーズと製造/テストフェーズで提出するドキュメントを明確にする。
- 概算費用としては、製造/テストフェーズ（第二フェーズ）も第一フェーズ時から算出しておき、全体的な費用感の意識をします。
- 製造/テストフェーズ（第二フェーズ）の正式見積は、第一フェーズが終了した後に算出する。
- 製造/テストフェーズ（第二フェーズ）に関して、概算費用で提出していた費用と差異がある場合、増減理由を説明して正式な見積ができるように打ち合わせをする。
といったことを実施しました。
前から実施しようとは思っていた手段ですが、お客様に同意が得られずなかなか実施できませんでしたが、今回はお客様にご理解もあり実施することができました。
調査/設計フェーズ（第一フェーズ）と製造/テストフェーズを分けることで、お互いで工数の増減分の理解もできました。もし、お客様側が増分に納得できない場合は、設計書は作成してあるので製造工程を他の会社に依頼することも可能となるわけです。
規模が大きい開発ですと既に実施していたり、規模が小さい開発だと特に必要はなかったりなどいろいろありますが、ぜひ、一度皆さんも試してみてください。(担当：小池拓)
