生産性の高い人がやっていること

エレガントに行動する、という響きは良いですね。
先手先手、等というよりはエレガントな表現だと思います。
朝ちょっと早く起きる、というのも、自分の生活においてやりたいことの一つです。
まずは小さい一歩から。

＝＝＝
　さて、一石二鳥を実現する方法ですが、大きく分けて二つが考えられます。一つには、何かをやりながら「ここからもっと何かを得られないか？」と考えること。例えば、ある人材開発担当者は、研修会社の営業担当とのミーティングを単なる案件の打ち合わせの場以上にできないかと考えました。そして、「今、他社さんはどんな研修を頼んできますか？」といった仕事に直結することから、さらには「これからどんなことが流行るんでしょうねぇ」「ためになる本とか読みました？」と雑談に近いことまで聞いてみることにしました。情報を得られることはもちろん、より楽しくミーティングが出来るようになったとか。

　もう一つは、仕事のリストを見ながら、その中で一度にやってしまえることがないかを考えることです。たとえば前述のチームメンバーのトレーニングについて、他の仕事をその機会に使えないかチェックしてみるわけです。うまくいくと、一つの機会で、人によって別々の課題、例えば「とにかく発言する」「まずは人の話を聞く」「人の意見をまとめる」などに取り組めます。


エレガントな動きを目指して
　一石二鳥について書きつつ、もう一つ思ったのは、エレガントな動きを目指している人が生産性の高い人の中に結構いるということです。ただ論理的合理的に考えるというと、味も素っ気もない感じがしますが、エレガントさ（美しさ）を求めていくと考えることがより楽しくなるようにも思います。

　そしてその一つの方法が「少し早く動く」ことです。「速く」ではありません。例えば、ランチに12時より少し前に出ると、すいていてゆったりできますし、注文した物もすぐに出てきます。「そんなの論理思考ってほどのものじゃないよ」と言われるかもしれませんね。確かに、もし誰かに「12時より少し前に行くとすいてていいよ」と聞いてそうするだけならあまり考えていません。

　しかし「ランチを少しでもエレガントに出来ないかねえ」と思って状況を観察し、「そうか、少し前に行くだけで結構変わるんだ」と考えたなら、これはロジカルな思考です。「同じことはピークタイムのあることならみんな当てはまるな」とあらゆることに当てはめ始めるとさらにロジカル。「行楽渋滞を避けるために30分速く出ると1時間早く着いたりするのはなぜだろう？」と考え始めると、実は相当なものです。

　もう一つ例を。これは仕事ではないのですが、朝、起きるのが15分早いか遅いかで、効率もエレガントさもだいぶ変わります。うちは子どもたちもいるので15分遅いと「早くしなさい！」と子どもたちを追い立てなければならないのですが、だいたいすぐには動かないので何度も言うことになり、やかましいし疲れます。忘れ物もしたりして全然エレガントではありません。

　一方、15分早いとガミガミ言う必要が無くなりますし、実は彼らもスムーズに行動することが多くなります。一緒にゴミ捨てに行ったりして近所の人にも褒められ彼らも上機嫌で出発し、こちらも無駄に疲れていないので仕事の集中力が上がります。

　会議やプロジェクトなど人とやることについて、先に先に動いて効率を上げている人もいます。ミーティングのスケジュールも早めに決めた方が最適な時間を簡単に押さえられる可能性が高いのはもちろんです。また、いつまでに何をやってくるのかも先に先に確認しておくそう。

　会議が生産的になるかどうかは、そこにかかわる人みんなの生産性に影響するので、みんなに協力してもらう、その自覚を持ってもらう、そのために十分間に合うタイミングで「次はこれをやってこよう」と打ち出すのだそうです。当然、自分もその通りにやってきて範を示す必要があります。前もって先を読んでおく必要がありますから、難度が上がりますが、うまく回り出すと好循環になりそうです。

「はやぶさ」と「龍馬伝」のプロジェクトリーダーたちと話し合った「ホットチーム」

メンバーの役割を共有化するやり方は他にも色々あるだろうが、これも一つの方法でしょう。
モチベーションを高める・維持させることは難しい。
コミュニケーションを取り続けないと、すぐに悪化する。
怒らない・受け入れる、ですな。
プライベートみたいですが（笑）


＝＝＝
　チームのメンバーの役割に関係なく、一人一人がその仕事に誇りと責任を持つことは、よいチームワークには不可欠である。そこで、チームが発足したり、新メンバーが参加したりしたときには、全てのメンバーの役割の確認と調整をするための簡単な技法を紹介しよう。これは、チームの発足時だけでなく、定例会議で時間のあるときや新メンバーが加わったときなどに行う1時間〜2時間の簡単なセッションだ。

　大事なことは、どのようなメンバーでも必ず一度は参加させることである。たとえ、事務方、在庫の整理をするロジスティックスの担当者といった、チームの直接の業務を担当するメンバーでなくとも、参加してもらう。ここでは、全てのメンバーは、自分の役割を、紙の上部にヘッダーとして書き出す。次に、その下に、自分の仕事がうまくいくために、して欲しいこと、して欲しくないこと、続けて欲しいことの3つを書き出す。たとえば、備品の在庫を管理する担当者は、「突然大量の在庫を使うような場合には、2週間前にあらかじめ相談に来て欲しい」、「相談もなく勝手に備品を持ち出さないで欲しい」、「プロジェクト全体の進捗の報告書の回覧をやってもらっているが、引き続きやってほしい」、などと書くかもしれない。次に、2人から3人のペアになり、メンバーの書いた要件が実行できているか、どうしたらできるようになるかを話し合う。時には、誰もやっていない業務が見つかる場合もある。そのときは、誰かがそれを分担するように、役割に加える。

　先に紹介した「社会的手抜き」は、自分が手を抜いても誰にもわからない、誰も自分の仕事に関心がないと感じたときに増加する。このようなセッションを通じてメンバーは、自分の役割とその達成状況を、他のメンバーに関心を持って見てもらえていることが確かめられ、チームの一員としての誇りと責任を高めていく。

仮想化は本当に安いか

今のプロジェクトでは、共有ストレージは大丈夫なので、初期導入コストは比較的少なくなるでしょう。
オペレーションコストを計測するためにも、トレースの計画をしっかりとしなければいけないですね。
とはいえ、ツールを入れるのは。。。
データセンター側でモニタ出来ればベストかも。


===
仮想化を阻む壁の破り方
　こうした「仮想化の壁」を破る必要があるが、さて、どのようにして打破すればよいのか。

　まず、「初期導入コストが高い」という壁に対しては、「スモールスタートができる」という仮想化のメリットを利用しよう。最初から大きく、完璧な仮想化環境を目指すのではなくて、小さな規模からスタートするのだ。

　そのためには、仮想化環境に本当に必要な要件を明確かつ冷静に分析する必要がある。例えば高機能ツール群は非常に魅力的なので、仮想化環境の導入時には「こんなツールも使えるといいな」というものがいっぱいある。しかし、本当に必要かというと、システムによってはそこまでの要求がなかったりするものだ。

　後からツールを追加できるシステム構成にしておくのも良い方法だろう。最初に入れなくても、いずれ追加できるような構成は、比較的簡単に検討できる。そういった構成で見積もりを出すとよい。

　仮想化環境ではスケールアウトもスケールアップも容易なので、その点を念頭において最初の規模を見積もろう。例えば仮想マシンのスケールアップは、割り当てるメモリーリソースやCPUリソースをGUIの管理ツールから増やしてやればよい。仮想化環境のスケールアウトは、より高性能なサーバーを追加していくことで実現する。リソースが足りなくなったタイミングでより大きなサーバー、より大きなストレージを用意し、仮想マシンを動的に移行していけばよい。要するに、仮想化環境をあらかじめ大きく見積もる必要は全くないのだ。


ランニングコスト、オペレーションコストの削減効果に注目を

　投資の回収プランも事前にきっちりと検討しておく必要がある。仮想化する際、初期導入コストはどうしても高く付きやすいが、仮想化環境では物理サーバーと比べてランニングコストを大幅に下げられる。ここに注目して投資を回収するのが一般的な考え方である。

　ランニングコストを含めて投資対効果（ROI）や総所有コスト（TCO）を計算するツールもある。「VMware ROI / TCO Calculator（英語）」だ。電気代、場所代のコスト削減により、何年間で投資を回収できるのかを計算する。初期導入コストを中心に仮想化の計画を立てることももちろんあると思うが、大幅にランニングコストが下がるという点をぜひ見逃さずに試算してほしい。

　さらに、仮想化によって、見えないところでオペレーションコストがかなり下がるというデータがある。海外の事例を紹介しよう。仮想化する前は、オペレーションコストのうち、インフラ管理に42％、OS/アプリケーションの管理に30％を使っていたという。だが仮想化後は、これらのコストが大幅に下がった。インフラ管理は30％に、OS/アプリ管理は15％にまで抑えられたという。浮いたお金は、インフラの改善やOS/アプリケーションの管理に追加投資してもよいだろう。

　「リソース使用率を高く見積もるのが怖い」という壁については、仮想化環境の運用開始後に、リソース配分を日常的にチューニングしていくことで解決しよう。運用時にリソースが不足する事態に備えるのはもちろんだが、逆にリソースが過剰に割り当てられているケースでは、パフォーマンスの問題などとして表面化しないため、状況を問題視せずに放置していることが多い。投資計画面では、過剰リソースの割り当ては大きなマイナスの影響をもたらす。実際には不要なリソースを与え続けていることになるからだ。

　この点についても利用できるツールがいくつかある。例えば「VMware vCenter CapacityIQ」を使うと、普段どのぐらいのリソースを要求していて、実際にどのぐらいのリソースが割り当てられているかを監視できる。この情報を基にリソース配分をチューニングしていけば、過剰なリソース購入を回避できる。仮想化環境の構築自体は比較的簡単だろうが、それだけで満足せず、必ずチューニングを続けてほしい。

仮想化固有の運用管理要件とは？

「これまでの運用管理方法は通用する。だが、新たに増える仮想化レイヤーの管理を変更・追加すべき」ということだ。仮想化環境の運用監視は、基本的に従来の延長線上にあると考えてよい。

　ただし、仮想化によるメリットを最大限に引き出すには、少なくとも次の点には注意してほしい。それは、仮想化によって増加する運用管理のコストよりも、従来必要だったコストの削減分が上回るようにすること。あるいは、仮想化で実現する新規サービスの価値が、仮想化により増加する運用コストを上回っていることである。この見極めは、仮想化環境の運用を実際に経験してみないと少し難しいかもしれない。

　上記のコストを考える際には、「作業時間の短縮」に注目してもらいたい。なぜなら、仮想化環境の利用によって得られるメリットのほとんどが「時間短縮」だからである。

　では実際の運用管理プロセスにおいて、仮想化により追加・変更となる部分を説明していこう。着目してほしいのは、「ハードウエアをソフトウエアのように運用管理することで影響を受ける部分」である。

（1）ハードウエアとサービスの依存関係の把握
　仮想化環境を導入すると、個々のハードウエア上で動作しているサービス数がほとんどのケースで増加する。同時に、ハードウエアとサービスの依存関係が複雑化する。

　また、サービス間に依存関係があるため、ハードウエア障害などによって、どのサービスに影響が出るのかを把握することが従来に比べて困難になる。よって運用管理面では、ハードウエアとサービスの依存関係を確実に把握することが重要となる。具体的には、構成管理データベースに、従来のハードウエアとサービスの依存関係に加えて、仮想化を考慮した依存関係の情報を追加することが望ましい。

（2）リソースを共有するサービスの把握
　同一のハードウエアを共有するサービス間では、リソースの競合が発生する可能性がある。よって、サービス同士のリソース共有関係の把握が重要となる。これについても、構成管理データベースに把握機能を追加することが望ましい。

（3）共有されるリソースの監視
　複数のサービスに共有されるリソースは、常に競合が発生する危険性を持つ。また仮想化環境では、従来は共有できなかったCPUのようなサーバーリソースも共有可能になる。よって共有されるリソースの監視が一段と重要になる。サービス・レベル管理やキャパシティ管理における監視対象として、仮想化によって追加された項目を重要度の高い監視対象として追加するなどの対策が必要である。

（4）構成変更の頻度が高くなることに対応
　仮想化環境を導入すると、従来と比べシステムの構成変更が容易になる。このメリットを生かすには、運用管理ルールにおける「変更に伴う承認プロセス」を、変更頻度が高くなっても対応できるようにすることが重要となる。変更承認プロセス自体の改善も必要だろうが、仮想化環境のメリットである「検証環境の作成が容易であること」を利用して、変更内容のレビュープロセスを効率化することができる。

（5）リリースの頻度が高くなることに対応
　構成変更の頻度が高くなるので、当然リリース（実際に変更を適用する作業）の頻度も高くなる。よってリリース頻度が高くなっても対応可能にすることが重要となる。具体的には、リリース管理のプロセスを、仮想化のメリットである「容易な検証環境の構築」および「容易なカットバック（変更前の状態に戻すこと）」を利用したものに変更することなどが挙げられる。

（6）インシデント対応に仮想化技術を応用
　仮想化環境を導入すると、従来実施していたインシデントへの対応方法に、仮想化ならではの手法を追加可能となる。このメリットを利用するには、インシデント対応のプロセスに仮想化技術を利用したワークアラウンド手法（暫定的な問題回避策）を使えるようにすることが重要だ。

　まず仮想化のメリットである「容易にシステムの状態を保存できる」ことを利用して、インシデントに関連する事象を記録する（インシデント発生時の仮想マシンイメージを保存するなど）。また、「高速な再起動」および「バックアップイメージからの直接起動」などを利用して、短時間で復旧できるようにしたい。

（7）問題の解決に仮想化技術を利用
　インシデントが発生したら、ワークアラウンド手法でサービスが復旧した場合でも、あとで原因を調査して解決する必要がある。原因がリソース不足などの場合は、仮想化を利用した対策が有効なことがある。

　インシデント対応と同様に、問題管理において仮想化を利用した対策を利用可能にすることが重要だ。そのポイントとして、仮想化のメリットである「リソースの動的配分」や「動的追加」などを利用した問題解決などが挙げられる。

（8）サービス・レベル管理に仮想化を利用
　従来のシステムでは、顧客とのSLA（Service Level Agreement）を守るために、必要なリソースを予測した最大需要量を顧客ごとに準備する必要がある。一方、普段利用されないリソースを共有することは、技術的な問題やセキュリティの維持のため難しい。

　仮想化環境では、この余剰リソースの効率的な共有が可能で、セキュリティも多くのケースで問題にならないレベルを維持できる。よってサービス・レベル管理に仮想化を利用した手法を利用可能にすることが重要となる。具体的には監視と組み合わせたリソースの動的配分などの利用が挙げられる。

（9）キャパシティ管理に仮想化を利用
　サービス・レベル管理と同じ理由で、仮想化を使った手法を利用可能にすることが重要となる。具体例もサービス・レベル管理と同じになる。

（10）可用性管理に仮想化を利用
　仮想化環境を導入するメリットに、可用性を高めるHA（High Availability）構成を導入すると、消費するリソースやコストを比較的小さくできることがある。よって可用性管理に、仮想化を利用したHA構成を導入可能にすることが重要である。具体的には、従来必要だったスタンバイサーバー用の資源を無駄にしないよう、仮想化を利用した構成を採用することなどが挙げられる。

（11）セキュリティ管理に仮想化を利用
　セキュリティに関連するインシデントや問題に対応する際、仮想化技術が役に立つ場合がある。例えば、侵入者に気づかれずにサーバーの状態を保存したり、隔離したりすることを容易に実現できる。

　仮想化環境導入のメリットを最大限に享受できるように、以上のような重要ポイントを十分に考慮して従来の運用管理ルールと運用手順に対して、変更や追加をしてほしい。

IT技術者よ，システムの動き方を説明してますか？

まさに昨日客先で話していた内容で、びっくりしました。
落としどころは、情報システム部門としてのコア業務を「表現」に気をつけて上長に説明すること。
施設管理と同じレベルで情報システムを考えている人たちには、業務全体に影響するコア業務がどれくらいあるのかを説明するしか無いと考えています。


============
　ITの認知度向上が話題になったとき，かつては「昔の鉄道などのように，IT業界もストでも張って，システムを止めてはどうですか」などと話していた。“脱IT依存”を掲げる利用者側が，「コンピュータを利用しない日」といった活動をすることはあっても，ITの運用側からシステムを止めるケースはほとんどない。

　空気や水のように，「なくなって初めて分かる，その価値」を狙うわけだが，どう考えても現実味はない。どんなIT関係者も，スト提案には楽しげにうなずくものの，システムが決して止まらないように考え・行動するのもまた彼らだからである。

「サブプライム候補者」に惑わされるな！

IT業界も一緒だなー、と。
サブプライムITベンダーは多いと思います。
自分がそうならないように。


=========
　約束は、一度破られればもう信用されません。当選政治家の公約違反は、国民の希望を信用不安に陥らせるという意味で、国際的には非常に重く責任を問われるものです、が・・・日本は「普通選挙」の施行以来、公約違反が常態化している極めて不思議な国になっている。その理由も別途論じたく思います。

　「公約」を守れば「まともな政治」、守れなかったら責任重大な「公約違反」ですが、では、最初から守れるアテもなく、実現も不可能な「公約」を掲げて選挙戦に出るということがあれば、これは何と呼べばいいでしょうか・・・たぶん「詐欺」でしょう。あるいは「公約バブル」と言ってもいいかもしれません。根拠のあいまいなことで泡を吹くという意味では、バブル経済とこの手の候補者（残念ながら「泡沫候補」のみならず、大政党の公認候補の公約の実態が怪しいケースも少なくないわけですが・・・）と、やっていることは変わりません。

　こういうことを言う人は、実体の裏づけがないのに「サブプライム商品」などを売り出した証券業者と同様「サブプライム候補者」とでも呼んでおくとよさそうです。

　こんなふうに整理していくと、改めて有権者として候補者を選ぶ際に考えるべきオーソドックス、大原則のコツを再確認することができそうですね。つまり

　「選挙公約に掲げられる政策目標が、具体的かつ実現可能なものである候補者だけを、投票の対象として考えること」を、強く勧めたいと思います。