継続的改善

イギリス人のQuality Managerから教えてもらったが、英語では継続的改善をContinual Improvementというそうだ。ISO9000の要求事項もContinual Improvementだ。もうひとつ、Continuous Improvementという言い方もあるそうだ。

業務を継続的に改善していくときには、Continual Improvementを使用する。これをContinuous Improvementという言う外人がいたら、その人はQuality Managementを知らない人だと思っていい。

違いは
Continual Improvement：やり方を変えて改善すること
Continuous Improvement：やりかたは、そのままで改善すること
だが、やりかたを変えなければ、大きな本当の意味での改善は見込めない。
生物も突然変異、すなわちContinual Improvementで、生き延び、進化してきた。

これを知ってからは、常にやり方を変える、考え方を変える、見方を変えるなど、今までと違って方法で、取り組もうと考えてやってきた。

継続的改善が組織として自立的に回る組織が一番いい組織だと思っている。
そのため、常にPDCAのサイクルを回し、やり方を変えていこうと思うのだが。

誰でも自分のやり方が一番いいと思っているし、改善する必要、ましては今までのやり方を変えることなど絶対に必要ないと考えている。

一番難しいのは、組織の中にこういった継続的改善の考え方を根付かせること。すなわち部内や会社のカルチャーを変えること。これは非常に難しく時間がかかる。

カルチャーを変えるには、ITILでは確か緑本でジョン・P・コッターの'Leading Change','The heart of Change'を参考にしたらいいと書いてあったので、'The heart of Change'を読んでみた。確かに使える部分はたくさんあったので、参考にしてやってみたいと思う。

私の今までの経験では、PDCAサイクルの中のC、すなわちチェックの部分を充実させること。誰の目にもはっきりと見える客観的事実をチェック項目として使用するのが、自立的に継続的改善を行うカルチャーへと変える一番いい方法だと思う。

具体的には
　・サービスデスク（ヘルプデスク）のトラブルやリクエストのログの解析結果（SLAとの比較）
　・顧客満足度調査結果（特にコメント）
　・ユーザからのクレーム
　・プロジェクト終了時のプロジェクトの進め方のリビュー結果（ユーザのフィードバックを含む）
　・第三者による内部監査リポート
　・コストリポート
　・年間目標の達成度のリビュー結果
　・その他、いろいろ個別に取り決めたKPIのリビュー結果
などが有効で次の改善のためのアクションプランの作成につながった。

インド人のCIOが増えた気がする

最近友達が働いている外資系の会社でアメリカ本社のCIOがインド人に代わった。これで私が知っているだけでも、３人のインド人CIOがいる。どれも名前の知れたグローバル大企業であるから、実際にはかなりたくさんのインド人のＣＩＯがアメリカの会社にいるに違いない。

１１年前に初めて外資系に転職した時、日本のIT部門にインド人の技術者がたくさんいた。ERPのコンサルタント、オラクルのエキスパート、UNIXのシステム管理者、MS-ACCESSの開発者などたくさんいた。英語ができて技術力も高く戦力になる、しかもコストの安かった彼らはとても重宝した。本国と一緒になって働く必要があるので、英語ができないと仕事にならない。当時も今も、英語のできるIT技術者はすくない。

その後彼らのうちの何人かはアメリカ本土で働き、頭角を現しCIOにまで上り詰めた人たちが、かなりいるそうだ。

インド人は学校で掛け算を１９X１９まで暗記するように習うという噂があった時に、実際インドのITマネージャーに聞いてみたら、そのとおりだと言っていた。中には、もっと上の数まで暗記する者もいると言っていた。日本では９X９までだと言うと、Very Easyと言って鼻で笑われてしまった。
中学に入ると英語で書かれた教科書を使った英語での授業になるそうだ。母国語の教科書の数が少ないのかもしれないが、アメリカで使用される教科書が使われると言っていた。

日本の大臣や知事の、英語を学ぶ前に、しっかりした日本語を学ぶべきみたいな発言を聞くと、ますます日本はグローバル化に遅れて、子供達が社会に出る１０年後には、グローバル化に取り残されてしまう気がする。

英語はたんなるコミュニケーションのツールにすぎない。りっぱな日本語を話せたり、書けなくても、ちゃんとした教科書の文法通りの英語が話せなくても、仕事の現場でコミュニケーションできれば十分である。発音も日本語なまりで、かまわない。ようはコミュニケーションは取れればいいと思う。

中学から大学まで英語を勉強しても、コミュニケーションが取れないのが、今の日本の教育の現実である。俗に読むことと文法（書くこと）は、日本の教育でも通用すると言われているが、実際のビジネスの場では、全然通用しない。英語のE-mail、マニュアルなど一日に、どれだけの英文を読みこなさなければならないか、会議の議事録、その他リポート、E-mailなど、一日にどれだけ英文を書かないといけないか、たぶん想像をはるかに超えた量であると思う。

一日の仕事時間

５：００－５：３０の間に起床。６：５０ぐらいまで（めざましTVの今日の占いに間に合うように、このぐらいの時間でやめる）、主にアメリカ本社とメールのやり取り、緊急な場合には電話で連絡を取る。土曜日の早朝も同じ時間帯はだいたい仕事している。月曜日も一応習慣で朝早く起きてしまうが、たまにしかメールは来ていない。

９：００出社、１８：００過ぎぐらいまで会社で仕事。
２０：００前には帰れるので、娘の勉強を見てあげられる。

２１：３０－２３：００ぐらいまで、主にヨーロッパとメールでやり取り、緊急な場合は電話で連絡をとる。金曜日の夜も同じく家で仕事をしている。

時差があるので、どうしても家で仕事する必要がある。家出る前にアメリカにメールしておくと、会社でその返事を読むことができるので便利である。

プロジェクトマネージメント

ITではPMBOKをベースとしたグローバルで標準的なプジェクトマネージメントのメソッドを定義してある。

理由は、グローバルで同じ方法をも用いることで、

- 欧米人は中長期のプランを作成することが苦手なので、モデルが必要
- どこの国でも、同じ方法でプロジェクトを管理するので、国境を越えてのプロジェクトに対応できる
- どこの国へ行っても同じ方法なので、国境を越えた人事異動に対応できる
- 一つのメソッドだけ教えればいいので、プロジェクト管理教育に掛けるコストが削減できる
- プロジェクト管理ソフトを統一できるし、共通のテンプレートの作成も可能
- ERPに共通のプロジェクト管理モデルを組み込め、プロジェクト毎のPL管理が可能

本社のITには、PMO(Project Ｍａｎａｇｅｍｅｎｔ Office)があり、その部署には多数のプロジェクトマナージャーに加え、何名かのプログラムマネージャーがいる。当然彼らはシニアレベルのプロジェクトマネージャーであり、多数のプロジェクトを管理している。当然のことながらＰＭＩの資格を持っているものが多い。

日本では、当然日本のIT Manager(私)が以下のプログラムマネージャーの役割を担う。

- プロジェクトを全社レベルで管理、特にリソース（ITスタッフだけでなく他の部署のスタッフも必要なので）
- プロジェクトマネージャーのコーチ
- 必ずステークホルダーの一人となりプロジェクトに影響を及ぼす（特にスコープ、リソース、スケジュール、コスト）
- IT内で閉じたプロジェクトであれば、スポンサーとなる
- ステークホルダー間の調整
- スポンサーとの調整、根回し（特にスポンサーがIT以外の場合、CFO,COO,CEOとか）
- IT主導のプロジェクトの場合は、ビジネスケース（どれだけのコスト削減が可能か？どれだけ業務改善できるか？など）を書き、スポンサー、他のステークホルダーを説得する
- プロジェクト期間中のワークロードを見積もり、アサインメントの割り当ての依頼する
- プロジェクトをレビューし、常にプロセスの改善を行い管理方法、メソッド、テンプレートに反映させる


プロジェクトは、マトリックス型組織で実行していくので、縦のラインのマネジャーが通常のマネジャーとすると横のライン（複数の部署にまたがるプロジェクト参加メンバー）をまとめるのはプロジェクトマネージャーが勤めることになる。


現在は、専門のプロジェクト管理ソフトを使用しているが、サーバーがアメリカなので、動作がとても遅くてがまんできない。本社のプログラムマネージャーが、全てのITプロジェクトを見ているので、日本だけのローカルなプロジェクト（他の国のITに影響を与えないプロジェクトも結構たくさんある）であっても、そのサーバに入力してメンテしていかないといけない。入力していくのは、タスクとそのスケジュール（当然マイルストーンも設定する）、そのタスクを実行する上で掛かったコスト（人件費と何か物を購入した時の購買費）、ワークロードの見積もりが必須項目である。ただ、イシューの管理、細かいアクションの管理（こちらはスケジュールに載らない会議などであがったアクション）は、Excelで行っているので、不便である。


そのため、最近興味あるのは、専門のProject管理ソフトを使うより、マイクロソフトの製品を組み合わせたプロジェクト管理である。MS Project, Project Server, Outlook, Share point Serviceこれからの製品の組み合わせによる管理である。MS ProjectのタスクがOutlookのタスク（仕事）と連動するので、誰が何をやるのかがわかりやすく、管理しやすい。誰でもOutlookメールは常にオープンしているので、タスクを忘れることもない。（通知の機能をうまく使えば）
また細かなアクションもアサインされた人のOutlookのタスクに依頼できるので一括に管理できてとてもいい。
メンバー間、およびスポンサーやステークホルダーとのコミュニケーションには、Share pointを活用してWEB上で行うことを試みているが、好評である。WEBは、日本で独自にインストールして日本語をサポートしているので、日本だけで行うプロジェクトのコミュニケーションには、もってこいのツールとなっている。

ITマネージャーズ会議

現在一番頭のいたいのが、二週間毎に行われる。ITマネージャーズ会議（アメリカ以外の国々のITマネージャーが参加）で議長をしなければいけないことである。議長の期間は半年、世界のITマネージャーが順番に議長を務める。日常業務レベルの英語力は自信がある。物理的に顔を合わせて行われる会議であれば、何とかこなせる自信はあるが、電話での世界のITマネージャーの議長はとても難しい。

１．いろんな英語が飛び交う
インド、マレーシア、シンガポール、香港、タイ、エジプト、ドイツ、フランス、イギリス、アイルランド、これらの国々の英語が飛び交う。それらに加えて日本語発音の英語が議長をしている。アメリカ英語を勉強してきた私には、はっきり言って、アジアとエジプトの英語はわからない。インド人とは、長いこと一緒に働いた経験があるので、なぜかわかる。イギリス人がいいやつなので、いつも助けてくれる。（彼はいつも大英帝国の代表してリーダーシップを取りたがるので、その流れかもしれない）彼は私が困っているときに、クイーンズイングリッシュに訳して通訳してくれる。
アイルランドの英語は、もっと古いクイーンズイングリッシュって感じで、いつも驚きである。たとえば、他の人がOKとか、Goodとか言う時に、彼はfairly enough（日本語のイメージだと’大変結構’って感じかな）と言う。他の人が、Bye Byeと言う時に彼は、All the best（日本語のイメージだと’ごきげんよう’かな）と言う。

２．アイルランド人はすぐ怒る
と、言われているが本当だと思う。ただ、一度彼をとても誉めて感謝したときに、すごく狼狽して照れていたはすごい驚きであった。

３．どうやって会議を乗り切るか
会議の最後で、決まったこと、次の会議までのアクションだけを確認する。ここでも、間違っていあたらイギリス人が助けてくれる。そしてすぐに、メールで議事録を書いて再度確認する。

４．雑音がすごい
日本時間の夜会議を行うが、ヨーロッパでは早朝なので、自宅から参加する人もいる。そのため子供の声とか、結構入ってきて楽しい。その他エコーが効いていたり、ドイツはいつも音声が以上に大きかったり（そのためドイツ人がしゃべる時だけスピーカーの音量を下げる）、世界の人たちと今つながっているという実感がある。

カルチャーの違いを理解して、お互いを尊重する

トップがヨーロッパ人で占められるわが社のカルチャーは、当然ヨーロッパの価値観に基づいて形成されることになる。外資系にはいいカルチャーはたくさんある（そのためもう日本の会社では働けないと思う）が、以下は日本人の価値観に合わなくて、とまどったカルチャーである。

１．会議は発言、議論する場であり、何かを決定する場ではない。
何も発言しないでいると「全ての意見に同意した」、「頭が悪いのか」、「英語ができないか」と思われる。いくらつまらない会議であっても、発言しないといけない。また、議論の場であるので、会議で決まったことを、実行するヨーロッパ人はいない。しかし日本人には、忠実に実行することが求められる。そのため、議事録に記載される今後のアクションプランは、日本人のみ記載し、けっしてヨーロッパ人のアクションプランを名指しで記載してはいけない。ただし、彼らの意見は、たんなる意見として議事録に反映しないといけない。彼らにとって、積極的に会議に参加した証拠を残しておいてあげないといけない。特に、社長が出席する会議では必須である。

２．逃げることは美徳である
昔バイキングは、海を越え見知らぬ土地を襲い、うまくいけばそこを占領して住み着いてします。逆に相手が強くて、かなわない時には、さっさと逃げかえる。そういった北欧のバイキングの精神がヨーロッパの国々には生きているのか、自分のコンピテンスを超えて何かにチャレンジすることはとても賞賛され上司もサポートしてくれる。但し、そのチャレンジ（全社的なプロジェクトなど）がうまくいかなくなった時は、上司を始めみんな逃げてしまう。日本人にとっては、はしごはずされたような気分になり、落ち込むが、それが当たり前の会社である。うまく行かない時には、メールして返事は来ないし、電話しても出ない。部屋を訪ねても、ドアを閉じて電話中のふりをする。こうなると自分で落とし所を考えて、プロジェクトを収束させないといけない。

３．本社の命令には、3回目でやっと動き出す。
たくさんのプロジェクトや命令（ダイレクション）が、本社が降ってきて、いつのまにか、無くなってしまうことは、日常茶飯事である。外資系に転職した最初は、本社からの命令にいちいち反応していたが、最近はほとんど無視している。本当に必要な時には、社長に直にメールで命令がくるが、社長も３回目ぐらいで始めて、その命令を下に下ろす。本社主体のプロジェクトは、必ず最後の方に導入するように、スケジュールを調整する。最初に導入するといろんな、日本の要求を受け入れてもらえるが、途中で消えてなくなる可能性がかなり高いし、最後の方で、バグの消えたシステムを導入する方のメリットのほうが断然高い。中央集権型なんて、絶対に考えられない。

４．目先の短期的（長くてクオーター3ヶ月）にしか物事を考えることができない
欧米人はプロジェクトなどのプラン作成は苦手中の苦手である。中長期で物を考えることができないので、いつも行き当たりばったりのプランでスケジュールを組む。走りながら考える、思いつきで行動するように日本人には感じられる。ただ、おもいついた後の実行は早い。そのため、メールであさってまでに、一週間後まで、何なにをやれとかの依頼がよく来る。日本人の私は、まじめなので、納期までに何とか実行することが多いいが、他の国は無視する方が多いようだ。この辺も、本社のプロジェクトが、いつのまにか無くなってしまう原因のひとつだろう。日本の会社でプロジェクト管理を叩き込まれた私の作るスケジュール、タスク管理表は、日本人が見たら（特に大手ITメーカーのSEの人）何の変哲もない手抜きの工程管理表であるが、ヨーロッパ人にとっては、信じられないできばえのようだ。

５．部下のヨーロッパ人（現在4名いる）は、社内のルールは日本人のためのものであり、自分達のルールは自分と社長、もしくはヨーロッパにいる私の上司との交渉で決めるものと信じている。私を通さないで（たぶん日本人への影響を考えて）、ルールを決めるので、そのため人事、経理とのもめごとが絶えない。
日本人並みに朝早くから夜遅くまで働くCFOがいるが、彼は毎日きちんとタイムリポートを書いて、社長に承認してもらって残業代をもらっている。日本人は全員年棒制でいくら働いても残業代など出ないのに。これも彼が赴任した後に、長いこと働くはめになり（日本人に合わせて）、社長と交渉した結果である。

ITコストとその割り振り（アロケーション）

財務の視点で定義されるITコストをフェアに各コストセンターへ割り振れるように定義することが大切である。

１．ITコストの定義

全社で、どのくらいのITコストが掛かっているのかを把握するため、PCやWS、アプリケーションのコストを含めて全てのコストを情報システム部のコストに計上するのが一番わかりやすい方法である。そうであれば、ROI（売り上げ高÷ITのコスト）も比較的計算しやすい。特に外資系の場合、日本は全ての物価が高いので、他の国に比べITコストが特別目立ちやすく、経費はカットされやすい。または容易にアウトソースすればという議論になりやすいので、ROIを算出することはとても大事。なぜなら物価が高い分、売り上げ高も、他の国比べて高いずである。

ITコストとは、情報システム部の経費として計上される以下に関わる全ての経費である。キャピタルのコストは、減価償却費として経費に換算して計算する。

　・ワークステーション（PC,Unix,Linuxなどのクラインアントサイドのマシンに関わる全ての経費）

　・サーバ（Windows関連,Unix関連、サーバルーム費用など全てのサーバに関わる経費）

　・通信（電話、携帯電話）とネットワーク（WAN,LAN）

　・アプリケーションに関わる一切のコスト（ライセンス、メンテナンス、コンサルティング、カスタマイズ費用など）

　・内部人的費用（給料、ボーナス、教育、オフィイス費用など全てのIT社員に関わる経費）

　・外部人的費用（アウトソース、コンサルティングなどの経費）

　・その他の経費（オフィススペース、サーバルーム費用など）


２．ITコストの各コストセンターへの割り振り（アロケーション）
以下の方法を組み合わせ、各コストセンターへ割り振る。

　・ユーザ一人当たりのコストを計算して各コストセンターの人数分の金額を割り振る
　　　　ユーザ一人当たりのコストの算出方法
　　　　（ワークステーションコスト＋オフィスアプリケーションコスト（e-mail含む）＋通信費＋上記IT人的（内部、外部の両方）＋サーバルーム費用を除くその他経費）÷社員数（テンポラリースタッフ、コンサルタントなどの外部の人間含む）

　・ワークステーション一台当たりのコストを計算して、各コストセンター所有のワークステーション分の金額を割り振る。
　　　ワークステーション一台当たりのコストの算出方法
　　　　（ネットワークコスト＋サーバコスト＋サーバルームコスト）÷全ワークステーションの台数

　・SAPなどのアプリケーションコストは、ユーザID一つ当たりのコストを計算して、各コストセンターのユーザID分割り振る。

　・そのコストセンターだけのために、IT要員が働いた場合は、IT要員の時間当たりのコストをチャージする。
　　　IT要員の時間当たりのコストの計算方法（チャージする時のコスト）
　　　　情報システム部の年間経費÷（情報システム部の人員数X年間平均就業時間）

業務でPCやワークステーション、プライベートLANなどを使用する場合(たとえば製品の開発センター、テストセンターなどがある場合)、そのコストはITなのか、その業務のコストセンターで負担するのかを決めるのは難しいので、全てのコストはITで持ち、その後該当コストセンターにこの業務に掛かる全てのコストを割り振る。またIT要員が、そのために働いた場合は、時間当たりのIT人員コストを、そのコストセンターにチャージする。

財務のパースペクティブ

社内情報システム部のバランススコアカードの財務のパースペクティブ（視点）には、以下のような戦略的目標が一般的に考えられる。以下コストとはオペレーションコスト、すなわち費用として落とせるコストを表す。キャピタルのコストは、原価償却費としてオペレーションコストに換算して計算する。

１．ITのコスト削減
多くの企業ではITは単なるコストでしか認識されていないので、当然ながらほっておけば増加する一方のITコストを削減する努力が要求される。
（例）
　・ITコストを前年度比１０％削減する。
　・または、社員一人当たりのITコストを１０％削減する。
上記目標に対するKSF(Key Success Factor:重要成功要因）として、
　・購入金額の削減（購買部と協調してサーバやPCなどの購入価格のコスト引き下げをメーカーと調整する）
　・PC、サーバの使用年数を延長する
　・プロジェクトの期間短縮
　・サーバ数量の削減（バーチャライゼーション化）－＞結果的にサーバルームも縮小でき、ファシリティのコストも削減できる
　・アウトソース

２．売り上げへの貢献
ネットビジネスなど、ITの技術が売り上げに直結する企業では、ITに投資したコストがどれだけ売り上げに貢献したのかも、戦略目標となる。
（例）
　・ROI（売り上げ高÷ITのコスト）を前年度比２０％増加させる。
基本的にITは間接部門であるので、SLA（サービスレベルアグリーメント）を遵守したサービスを行うだけであり、直接売り上げに貢献する営業活動に参加する機会は少ないが、小さな会社では以下のようなKSFも考えれる。
　・ITの顧客プロジェクトへの参加数（または率）の増加
　・インターネット受注売り上げ高（または増加率）の増加

いづれにしても、正しくITコストを定義し、フェアに各コストセンターへ割り振る仕組みが必要となる。

仕事はじめ

今日から仕事はじめ。
まずは２００７年度の目標（Objectives)を決めないといけない。
全てグローバルのベストプラクティスに準拠するのが、一番いい方法だと思っているので、目標の設定はバランススコアカードを使用して、今年も目標を決める予定。

１．財務、顧客、Inovation、コンピテンスデベロップメントの４つのパースペクティブに分けて、それぞれの戦略目標を決める。
２．次にそれぞれのターゲットを決め、KPI（Key Performance Indicator)を決める。
３．最後にアクションプランを決めるが、このアクションプランは、部員の２００７年度目標を考慮して決める。実際各部員のアクションになるように、アクションプランを落としこんでいく。

ITの日常的なManagementにはITILのManagement Modelを導入する予定。KPIは、ITIL（アイティル）の成熟度モデル、自己アセスメントの評価結果にしようと考えているが、これを導入する前に、まずはITのミッション、ビジョンを部員全員で理解して、何故このモデル、KPIを使用するのか、何故これが有効なのか？を理解しておかないとうまくゆかない。このへんは、今年のObjectivesを設定する過程で、うまく説明したい。