本日はシステム管理者感謝の日

日頃から激務に耐えてきたシステム管理者を称える日が今年もやってきました。AGORIAのニュースレターでこんな紹介がなされていました。

『wikipediaによると、シカゴ在住のシステム管理者Ted Kekatos氏が、「新しいプリンタの導入に成功したシステム管理者が、他の社員たちから感謝のプレゼント攻めに逢う」というHP社の広告を見て思いつき ”ほとんど敬意を払われることの無いシステム管理者に感謝を表する日”として「System Administrator's Day」を提案。「SysAdminDay.com」ドメインを取得してサイトを開設し、2000年7月最終金曜日から実施されています。

すでに、英国／スペイン／オランダ／ドイツでも賛同者が活動を展開。日本では、システム運用の独立系ベンダーの（株）ビーエスピー社が、2006年から同記念日を広める活動として、日本記念日協会への登録と、毎年7月にイベントを開催しています。

Ted 氏は、システム管理者の仕事ぶりを、「日曜の午前2時だろうと、メールサーバが落ちれば呼び出されて出勤」「スパム、スパイウェア、ウィルスを心配してのゲート設定」「災害時に備えてのバックアップと復旧」「ユーザーの苦情やヘルプに対応」・・・と、縁の下の力持ちであると記しています。』

ITproにも紹介されていました。

（記者の眼：明日はシステム管理者感謝の日）
　→ http://itpro.nikkeibp.co.jp/article/OPINION/20090729/334717/

でも、この記念日を知っている人、実はそんなに多くなさそうです。あなたの周りにはどれくらい知っている人がいますか？

特定ベンダー以外をふるい落とすために細かすぎる仕様書を作る

システム開発の入札（ベンダーからみるとSI案件）に競争入札（コンペ）は付き物です。コンペの目的は、入札者同志で金額を競ってもらい、提案内容の質とコストのバランスが最も優れたベンダーを決定することにありますが、時折、「こんなに詳細な要件を指定してベンダーが理解できるのか？」というRFP（提案依頼書）を見かけます。

曖昧すぎるRFPはリスクが大きくなるので嫌われますが、一方で細かすぎるRFPについても、内容理解で相当の持ち出し工数が発生するのでベンダーは嫌う傾向にあり、提案辞退によってコンペが機能しなくなるケースもしばしば聞く話です。

これに関して、半年以上前の話になりますが、公正取引委員会のグループウェア導入入札に関する契約監視委員会の議事で次のようなやりとりが記録されていました。

（ある委員からの質問）
「平成２０年１月の入札には１社しか参加していない。なぜ１社しか入札に参加していないのか。私が考えるに，仕様書の条件が細かすぎたためにそれに対応できる会社が極端に少なくなったのだと思うが。必要なもののみを絞って書くべきだと思う。何となく，落札した会社しか参加しにくいものとなっているのではないかと思われる。」

（担当者回答）
「ネット接続，ファイアウォール運用や迷惑メール振り分防止などインターネット接続と接続に係る情報セキュリティ確保に関する業務を行う会社が異なると障害発生時など調整が複雑になるので一手に引き受けてもらう会社を条件とした。大手の会社にはすべて兼ね備えているところがあるので数社は入札に参加してくれると思っていた。」

「仕様書に書いたものはすべて必要なものだと考える。セキュリティはしっかりしてもらいたいのでかなり具体的になってしまった。仕様書に書く内容をどこまで細かく書くかという課題がある。また，調達までのスケジュールが非常にタイトだったので，今後は期間を長くとって多くの会社の目に触れるようにしたい。」
→ http://www.jftc.go.jp/info/zuikeitekiseika/kanshiiinkaigaiyo2.pdf

システム開発の提案というのは、RFPをベンダーに投げてから2週間〜1カ月以内で提案書を出してもらうのが一般的です。一見すると相応の期間だと思う人もいるかもしれませんが、ベンダーにとっては、RFPの内容理解、提案骨子作成、内容記述、内部レビュー、必要に応じて協力会社との事前調整というタスクをこなす必要があり、RFPの内容が過度に細かいとこれらの工数が比例して肥大化します。

私もRFPを作る側と受ける側をある程度経験していますが、細かすぎるRFPを書いた場合、3週間以上のリードタイムを設定しないとベンダーから意味のある提案書は出せませんし、出てきません。そういった事態に陥らないよう注意することが必要になりますが、これを逆手に取る方法もあります。

つまり、「特定ベンダーに決定するために、要件の過度な詳細化とタイトなスケジュールを提示する」というテクニックです。公正取引委員会の場合は、結果としてこうなってしまったのだと理解しますが、意図的に同じ状況を作り出せば、事実上の随意契約、つまり「最初からこのベンダーに取らせることが決まっている状態」になるのです。

RFPを作る方、提案書を作って応募する方は、このあたりを意識するといろいろとコントロールできるようになります。

「みんなは一人のために」という嘘と新訳

「一人はみんなのために、みんなは一人のために」

有名なダルタニャン物語に登場する一節です。三銃士と言った方が分かりやすいでしょうか。私自身、この話をよく読んでいないので細部は分かりませんが、お互いを助け合う場面でおそらく使われているのですよね。チームワークを高めるキャッチコピーとして定着している感があります。

このあまりにも有名なフレーズに対して、新訳を唱えている人がいることを先日知りました。きっかけはフェイス総研の社長コラムです。

『不世出の名選手にして元全日本監督、平尾誠二氏によれば、この言葉の訳は大間違いで伝えられているのだと言う。

一般的に伝わっている解釈は「一人はみんなのために、みんなは一人のために」チームプレイの大切さを表す美しい言葉として、座右の銘としている経営者も多いだろう。

しかし、平尾氏によれば「ワン・フォー・オール（一人はみんなのために）」の訳は正しいが、「オール・フォー・ワン（みんなは一人のために）」の部分が大いなる誤訳である、というのだ。「オール・フォー・ワン」の「ワン」とは「一人」という意味ではなく「勝利」を意味する“ Victory ”である、のだという。

つまりは「一人はみんなのために、みんなは勝利のために」が正しい、ということになる。』
　→ http://www.faith-h.net/press/oguclm/mc090717.html

これは面白い視点だと思います。「All for won」という考え方によって、冒頭のフレーズは180度違った意味になります。これまで護送船団方式よろしく助け合って進めていくチームワークを謳っていたはずなのに、oneがwonになるだけで、勝利のためならどんな犠牲も厭わないという姿勢に変わるのです。

前述の社長コラムにもこんな話が述べられていました。

『僕たちはまず自分の足で立つことから始めよう。一人で立てもしないうちから“ All for One ”「一人のために」と、「助けられ合い」をするのは止めよう。泳げない人は、溺れている人を助けることはできない。まずは自分の足で「勝利」へと向かって立つ。そして「相乗効果」を発揮して「勝利」をつかむのだ。』

相乗効果を得るために不可欠なのは単体による自立である、というポイントはスティーブン・R・コビーが著書「7つの習慣」でも触れられていた話です。同書では、

「dependence（依存）」
　　→「independence（独立）」
　　　　→「interdependence（相互依存）」

という3つのステージを想定していたと記憶しています。
　→ http://it-ura.seesaa.net/article/117318575.html

Win-Winであり、シナジー効果をもたらすためには、まずは助け合い無しに一人一人が強く自立した存在でなければならず、その上で全体の勝利を目指すのが最上だということです。この実現にあたっては「One for All, All for Won」の方が確かに理にかなった解釈ですね。

ただ、システマチックな組織を作り上げるには「みんなは勝利のために」でもよさそうですが、日本人がこれまでに培ってきた感覚は、やっぱり「みんなは一人のために」の方です。All for Wonの精神が強すぎてブラック会社と呼ばれている企業を私はいくつも知っていますし、一部の人間以外を不幸にしてしまうこの精神は万人向けではありません。

スタッフや一般社員、低級管理職向けには「All for One」、激務奨励の幹部職員向けには「All for Won」を使い分けるという方がいいかなという気がします。


ちなみに、補足しますと、私が調べた限りでは「All for One」が正しいはずです。原文には「Tous pour un, un pour tous」と書かれているので間違いないと思います。英語に訳された際に上記のような解釈が考えられたのでしょうね。

サイバー犯罪者の告白

やぁ、元気。

ちょっと面白いWebサイトを見つけたんだ。

http://www.trendmicro.co.jp/kokuhaku/?kid=friend&from=friend
トレンドマイクロってウイルスバスターっていう
セキュリティソフトを作ってるメーカーの
「サイバー犯罪者の告白」っていうやつなんだけど、
豚インフルエンザにかこつけたスパムメールを送るだとか、
偽のセキュリティソフトをダウンロードさせるとかって
実際にあったことらしいのだけど、そういった犯罪手口を
犯罪者が告白するという形で紹介してるんだ。

カメラ屋さんとかにあるデジカメの写真プリントする機械で
ウイルスに感染したりするらしいよ。

君も結構騙されそうだから、一度見てみたらいいと思うよ。

こんなのITのプロらしい仕事じゃない

TVドラマの節々でITシステムが登場するようになって久しいですが、IT部署を扱ったドラマというのはあまりなかったように思います。

以前、英国ドラマでIT部署をテーマにしたものを紹介しましたが、ヒューマンドラマに比重が置かれすぎていて、ITのお仕事はそれほど多く出てきていませんでした。

ところが先日、インテルのサイトでIT部門をテーマにした面白いWebドラマを見つけたので、ここで紹介しましょう。

　『ROAD TO CIO（ロード トゥ シー・アイ・オー）』
　→ http://it-ura.seesaa.net/article/123657185.html

このショートムービーを作った脚本家、いい腕してますね。1話あたりおよそ3分程度の中に起承転結をきっちり収め、話が盛り上げるところでは効果的なテーマソングを流すあたり、狙い通りに仕上げていることが伝わってきます。

話の発端は、社内ＩＴ部門に加藤という人物が転属させられたことです。営業部でセキュリティインシデントを起こした彼は、最初はＩＴ部門の仕事に偏見を持って取り組んでいましたが、そのうち、自分も苦しめられたシステムセキュリティの新しいあり方について思いを巡らせるようになります。同僚や上司との対決を潜り抜けて、ついには役員プレゼンに到達するというサクセスストーリー。

このドラマが秀逸なのは、話のテンポが良いだけではなく、1話ごとにその後日談として主人公の加藤自身が振り返りの文章を残しているところ。

たとえば第1話「不満」ではドラマ内でセキュリティインシデントに関する報告と同僚からの嫌味のやり取りがありましたが、それに対する主人公の後日のつぶやきはこの通り。


『何が「勝手に」だ。
　何が「情報漏洩を引き起こした挙げ句」だ。
　「部署を変えられちゃった」だと。

　オレは別に、会社に迷惑をかけたかったわけじゃない。
　8年目の営業として初めて任されたプロジェクト。
　その資料づくりのために画像処理のフリーウェアが
　どうしても必要だっただけだ。

　だからといって、ファイル交換で手に入れようとしたのは
　確かにマチガイだった。
　会社の機密のデータに影響が及ばないようにしたつもり
　だったが、まさか、プロジェクトの企画書自体が
　流出してしまうとは。

　だが、それだけだったからこそ、島流しで済んだのかもしれない。
　もし、会社の顧客情報が流出していたら。。。

　しかし、よりによってシステム開発部に
　異動するなんて。
　誰からも期待されていないなかで、
　自分のスキルを上げていかなければならない。
　だが、この部署はなんだか閉鎖的で
　立ち入れない領域が多いように思う。

　あのときだって、当然、正式にソフトウェアの購入を
　申請する手はあった。
　だが、プロジェクトを進める上で時間がなかった。
　会社、特にシステム開発部の対応は遅い。
　さらに IT 資産管理の問題とかで、
　個別のソフトウェア購入が通る可能性はゼロに近い。

　確かにリスティングとラベリングで資産管理を
　している現状では、その管理は面倒だろう。
　そのせいで手間が増えることを恐れて
　保守的にならざるを得ないのはわかるが、
　これでは IT がビジネスの武器になる日は
　いつ来るというのだろう？

　他の会社の IT 部門もそうなのだろうか？』


この後ろでさらに各回のポイントを解説する技術的なコラムが掲載されているのは構成の妙ですね。インテル、さすがです。

　http://it-ura.seesaa.net/article/123657185.html

全六話。面白いです。ハマった人は、その2もあります。

このショートムービーで主人公の加藤がつぶやくこんなセリフがあります。

「こんなのITのプロらしい仕事じゃない」

他の社員が帰った深夜から始める全社PCクライアントのセキュリティアップデートの作業に立ち会った際に口にした言葉ですが、私たちはこの言葉をどれほど意識して普段の仕事に臨んでいるでしょうか？

ITという名前を冠した部門でありながら、やっていることはかなりアナログな現場を私はいくつも知っています。

何かをチェックする、集計する、特定の視点で分析する。そういった何かのルールに沿って行うアクションは概して自動化することで省力化が期待できるのですが、漫然と与えられた仕事をこなしているだけではこういった発想はでてこないでしょう。

第2話の石田が「ウイルスチェックは深夜作業をともなうから残業代が出てラッキー」だと言っていましたが、そもそもの発想として、深夜作業にならないための効率的な方法を考えるべきではないか、ということです。

今の状況から一歩踏み出して考えることができる人は、変化の激しいITの世界でも生き残っていけると思います。

でも、そうでない場合は・・・職種転換を考えた方がいいかもしれません。

ROAD TO CIO（ロード トゥ シー・アイ・オー）

営業からシステム開発部に異動してきた加藤慎平。社内の IT を改善するべく「仕事のあるべき姿」を追い求める加藤が見いだした答え「ビジネスを持続的に成長させる IT システム」の姿とは。そして、上司の理不尽な押しつけに、立ち向かうすべはあるのか。

• 第 1 話「不満」
• 第 2 話「目覚め」
• 第 3 話「提案」

• 第 4 話「新しい視点」
• 第 5 話「対決」
• 第 6 話「そして…」

日経SYSTEMSで紹介されました

私事ですが、現在発売中の日経SYSTEMS（日経システムズ：日経BP社）の7月号で、吉澤準特の会議術が紹介されました。

特集2の「元気が出る会議」の冒頭箇所と中盤、「参加者に”決め方”と”決めるための情報”の同意を得る」という箇所で私のやり方が取り上げられています。

決定版！元気が出る会議
「長引いて、なかなか終わらない」「意義のある結論が出ない」「議論の本筋とは関係のない発言が目立つ」など相変わらず改善しない会議の効率。参加者が本音を語り合える、結論が見えてくる、効率が良いなど「元気が出る会議」を実践している現場を取材し、実現のポイントに迫ります。（2009年7月号）
http://www.nikkeibpm.co.jp/cs/mag/it/nos/tokusyu.html

よろしければご覧ください。