外資系企業に住む住人の視点からIT業界の出来事を伝えます。ご興味のある方は、メルマガの登録をお願い致します。Twitterやっています。→http://twitter.com/juntoku_yマイナビニュースで「IT業界裏講座」を掲載中です。そちらもヨロシクお願い致します。→コンサル直伝−IT業界”裏”講座EnterpriseZine(翔泳社)で記事掲載中です。そちらもヨロシクお願い致します。マネジメントセンター(JMAM)より「フレームワーク使いこなしブック」を上梓しました。仕事の質と効率を高める思考の枠組み・フレームワーク。本書は、架空のパンメーカー・ナイスハーベスト社を舞台に、新人のむぎ夫がフレームワークを使って課題を解決していくストーリーを追いながら、フレームワークを学べる仕掛けになっています。最終章では、オリジナルのフレームワークを作る方法も紹介。「わかる」レベルから「使える」レベルに無理なくステップアップできます。2012年7月末、同じくJMAMより「ビジネス思考法使いこなしブック」を上梓しました。こちらもむぎ夫が登場し、ロジカルシンキング・ラテラルシンキング・クリティカルシンキングの3つをどうやって使いこなすか、問題解決の発想技法を学べる仕掛けになっています。このジャンルでは、おそらく初めて3つのシンキングを体系的に1冊の本でまとめている本です。以下の書籍も執筆しています。こちらも合わせてどうぞ。『外資系企業に住む住人の視点からIT業界の出来事を伝えます。以前好評いただいた『資料作成の基本』から図解作成だけにテーマを絞って抽出した本が2018年6月23日に発売となります。https://www.amazon.co.jp/dp/4799106511本書は「資料」ではなく「図解」の作成に特化しています。図解は、論理的にわかりやすい内容、感覚的に心地よい見た目が好まれます。図形のカタチ(フォーム)と配置(ポジション)で生み出される「要素のバランス」、色の使い分け(カラー)によって醸し出される「コンテンツの強弱」です。それらを「図解キューブ」というモデルで表し、その実践例をチャートとグラフの「図解パターン」として体系的・網羅的に整理しました。これらを「エグゼクティブ図解術」と私は呼んでいます。本書を図解作成のハンドブックとして、ぜひ使ってみてください。日頃から激務に耐えてきたシステム管理者を称える日が今年もやってきました。AGORIAのニュースレターでこんな紹介がなされていました。「SysAdminDay.com」ドメインを取得してサイトを開設し、2000年7月最終金曜日から実施されています。英国/スペイン/オランダ/ドイツでも賛同者が活動を展開。日本では、システム運用の独立系ベンダーの(株)ビーエスピー社が、2006年から同記念日を広める活動として、日本記念日協会への登録と、毎年7月にイベントを開催しています。氏は、システム管理者の仕事ぶりを、「日曜の午前2時だろうと、メールサーバが落ちれば呼び出されて出勤」「スパム、スパイウェア、ウィルスを心配してのゲート設定」「災害時に備えてのバックアップと復旧」「ユーザーの苦情やヘルプに対応」・・・と、縁の下の力持ちであると記しています。』ITproにも紹介されていました。http://itpro.nikkeibp.co.jp/article/OPINION/20090729/334717/でも、この記念日を知っている人、実はそんなに多くなさそうです。特定ベンダー以外をふるい落とすために細かすぎる仕様書を作るシステム開発の入札(ベンダーからみるとSI案件)に競争入札(コンペ)は付き物です。コンペの目的は、入札者同志で金額を競ってもらい、提案内容の質とコストのバランスが最も優れたベンダーを決定することにありますが、時折、「こんなに詳細な要件を指定してベンダーが理解できるのか?」というRFP(提案依頼書)を見かけます。曖昧すぎるRFPはリスクが大きくなるので嫌われますが、一方で細かすぎるRFPについても、内容理解で相当の持ち出し工数が発生するのでベンダーは嫌う傾向にあり、提案辞退によってコンペが機能しなくなるケースもしばしば聞く話です。これに関して、半年以上前の話になりますが、公正取引委員会のグループウェア導入入札に関する契約監視委員会の議事で次のようなやりとりが記録されていました。(ある委員からの質問)「平成20年1月の入札には1社しか参加していない。1社しか入札に参加していないのか。私が考えるに,仕様書の条件が細かすぎたためにそれに対応できる会社が極端に少なくなったのだと思うが。必要なもののみを絞って書くべきだと思う。何となく,落札した会社しか参加しにくいものとなっているのではないかと思われる。」(担当者回答)「ネット接続,ファイアウォール運用や迷惑メール振り分防止などインターネット接続と接続に係る情報セキュリティ確保に関する業務を行う会社が異なると障害発生時など調整が複雑になるので一手に引き受けてもらう会社を条件とした。大手の会社にはすべて兼ね備えているところがあるので数社は入札に参加してくれると思っていた。「仕様書に書いたものはすべて必要なものだと考える。セキュリティはしっかりしてもらいたいのでかなり具体的になってしまった。仕様書に書く内容をどこまで細かく書くかという課題がある。調達までのスケジュールが非常にタイトだったので,今後は期間を長くとって多くの会社の目に触れるようにしたい。http://www.jftc.go.jp/info/zuikeitekiseika/kanshiiinkaigaiyo2.pdfシステム開発の提案というのは、RFPをベンダーに投げてから2週間〜1カ月以内で提案書を出してもらうのが一般的です。レビュー、必要に応じて協力会社との事前調整というタスクをこなす必要があり、RFPの内容が過度に細かいとこれらの工数が比例して肥大化します。私もRFPを作る側と受ける側をある程度経験していますが、細かすぎるRFPを書いた場合、3週間以上のリードタイムを設定しないとベンダーから意味のある提案書は出せませんし、出てきません。いった事態に陥らないよう注意することが必要になりますが、これを逆手に取る方法もあります。「特定ベンダーに決定するために、要件の過度な詳細化とタイトなスケジュールを提示する」というテクニックです。公正取引委員会の場合は、結果としてこうなってしまったのだと理解しますが、意図的に同じ状況を作り出せば、事実上の随意契約、つまり「最初からこのベンダーに取らせることが決まっている状態」になるのです。RFPを作る方、提案書を作って応募する方は、このあたりを意識するといろいろとコントロールできるようになります。有名なダルタニャン物語に登場する一節です。三銃士と言った方が分かりやすいでしょうか。私自身、この話をよく読んでいないので細部は分かりませんが、お互いを助け合う場面でおそらく使われているのですよね。チームワークを高めるキャッチコピーとして定着している感があります。このあまりにも有名なフレーズに対して、新訳を唱えている人がいることを先日知りました。きっかけはフェイス総研の社長コラムです。よれば、この言葉の訳は大間違いで伝えられているのだと言う。一般的に伝わっている解釈は「一人はみんなのために、みんなは一人のために」チームプレイの大切さを表す美しい言葉として、座右の銘としている経営者も多いだろう。平尾氏によれば「ワン・フォー・オール(一人はみんなのために)」の訳は正しいが、「オール・フォー・ワン(みんなは一人のために)」の部分が大いなる誤訳である、というのだ。”である、のだという。「一人はみんなのために、みんなは勝利のために」が正しい、ということになる。http://www.faith-h.net/press/oguclm/mc090717.htmlこれは面白い視点だと思います。won」という考え方によって、冒頭のフレーズは180度違った意味になります。これまで護送船団方式よろしく助け合って進めていくチームワークを謳っていたはずなのに、oneがwonになるだけで、勝利のためならどんな犠牲も厭わないという姿勢に変わるのです。前述の社長コラムにもこんな話が述べられていました。『僕たちはまず自分の足で立つことから始めよう。”「一人のために」と、「助けられ合い」をするのは止めよう。泳げない人は、溺れている人を助けることはできない。自分の足で「勝利」へと向かって立つ。「相乗効果」を発揮して「勝利」をつかむのだ。相乗効果を得るために不可欠なのは単体による自立である、というポイントはスティーブン・R・コビーが著書「7つの習慣」でも触れられていた話です。→「interdependence(相互依存)」という3つのステージを想定していたと記憶しています。http://it-ura.seesaa.net/article/117318575.htmlWin-Winであり、シナジー効果をもたらすためには、まずは助け合い無しに一人一人が強く自立した存在でなければならず、その上で全体の勝利を目指すのが最上だということです。Won」の方が確かに理にかなった解釈ですね。システマチックな組織を作り上げるには「みんなは勝利のために」でもよさそうですが、日本人がこれまでに培ってきた感覚は、やっぱり「みんなは一人のために」の方です。Wonの精神が強すぎてブラック会社と呼ばれている企業を私はいくつも知っていますし、一部の人間以外を不幸にしてしまうこの精神は万人向けではありません。Won」を使い分けるという方がいいかなという気がします。One」が正しいはずです。tous」と書かれているので間違いないと思います。英語に訳された際に上記のような解釈が考えられたのでしょうね。徒然コメントサイバー犯罪者の告白やぁ、元気。面白いWebサイトを見つけたんだ。偽のセキュリティソフトをダウンロードさせるとかって実際にあったことらしいのだけど、そういった犯罪手口を犯罪者が告白するという形で紹介してるんだ。カメラ屋さんとかにあるデジカメの写真プリントする機械でウイルスに感染したりするらしいよ。君も結構騙されそうだから、一度見てみたらいいと思うよ。徒然コメント2009年07月18日こんなのITのプロらしい仕事じゃないTVドラマの節々でITシステムが登場するようになって久しいですが、IT部署を扱ったドラマというのはあまりなかったように思います。以前、英国ドラマでIT部署をテーマにしたものを紹介しましたが、ヒューマンドラマに比重が置かれすぎていて、ITのお仕事はそれほど多く出てきていませんでした。ところが先日、インテルのサイトでIT部門をテーマにした面白いWebドラマを見つけたので、ここで紹介しましょう。http://it-ura.seesaa.net/article/123657185.htmlこのショートムービーを作った脚本家、いい腕してますね。1話あたりおよそ3分程度の中に起承転結をきっちり収め、話が盛り上げるところでは効果的なテーマソングを流すあたり、狙い通りに仕上げていることが伝わってきます。話の発端は、社内IT部門に加藤という人物が転属させられたことです。営業部でセキュリティインシデントを起こした彼は、最初はIT部門の仕事に偏見を持って取り組んでいましたが、そのうち、自分も苦しめられたシステムセキュリティの新しいあり方について思いを巡らせるようになります。同僚や上司との対決を潜り抜けて、ついには役員プレゼンに到達するというサクセスストーリー。このドラマが秀逸なのは、話のテンポが良いだけではなく、1話ごとにその後日談として主人公の加藤自身が振り返りの文章を残しているところ。第1話「不満」ではドラマ内でセキュリティインシデントに関する報告と同僚からの嫌味のやり取りがありましたが、それに対する主人公の後日のつぶやきはこの通り。何が「情報漏洩を引き起こした挙げ句」だ。「部署を変えられちゃった」だと。オレは別に、会社に迷惑をかけたかったわけじゃない。8年目の営業として初めて任されたプロジェクト。その資料づくりのために画像処理のフリーウェアがどうしても必要だっただけだ。いって、ファイル交換で手に入れようとしたのは確かにマチガイだった。会社の機密のデータに影響が及ばないようにしたつもりだったが、まさか、プロジェクトの企画書自体が流出してしまうとは。それだけだったからこそ、島流しで済んだのかもしれない。会社の顧客情報が流出していたら。よってシステム開発部に異動するなんて。自分のスキルを上げていかなければならない。この部署はなんだか閉鎖的で立ち入れない領域が多いように思う。あのときだって、当然、正式にソフトウェアの購入を申請する手はあった。プロジェクトを進める上で時間がなかった。会社、特にシステム開発部の対応は遅い。個別のソフトウェア購入が通る可能性はゼロに近い。確かにリスティングとラベリングで資産管理をしている現状では、その管理は面倒だろう。部門もそうなのだろうか?』この後ろでさらに各回のポイントを解説する技術的なコラムが掲載されているのは構成の妙ですね。インテル、さすがです。http://it-ura.seesaa.net/article/123657185.html全六話。ハマった人は、その2もあります。このショートムービーで主人公の加藤がつぶやくこんなセリフがあります。他の社員が帰った深夜から始める全社PCクライアントのセキュリティアップデートの作業に立ち会った際に口にした言葉ですが、私たちはこの言葉をどれほど意識して普段の仕事に臨んでいるでしょうか?ITという名前を冠した部門でありながら、やっていることはかなりアナログな現場を私はいくつも知っています。何かをチェックする、集計する、特定の視点で分析する。いった何かのルールに沿って行うアクションは概して自動化することで省力化が期待できるのですが、漫然と与えられた仕事をこなしているだけではこういった発想はでてこないでしょう。第2話の石田が「ウイルスチェックは深夜作業をともなうから残業代が出てラッキー」だと言っていましたが、そもそもの発想として、深夜作業にならないための効率的な方法を考えるべきではないか、ということです。今の状況から一歩踏み出して考えることができる人は、変化の激しいITの世界でも生き残っていけると思います。ない場合は・・・職種転換を考えた方がいいかもしれません。シー・アイ・オー)営業からシステム開発部に異動してきた加藤慎平。上司の理不尽な押しつけに、立ち向かうすべはあるのか。日経SYSTEMSで紹介されました私事ですが、現在発売中の日経SYSTEMS(日経システムズ:日経BP社)の7月号で、吉澤準特の会議術が紹介されました。特集2の「元気が出る会議」の冒頭箇所と中盤、「参加者に”決め方”と”決めるための情報”の同意を得る」という箇所で私のやり方が取り上げられています。「長引いて、なかなか終わらない」「意義のある結論が出ない」「議論の本筋とは関係のない発言が目立つ」など相変わらず改善しない会議の効率。参加者が本音を語り合える、結論が見えてくる、効率が良いなど「元気が出る会議」を実践している現場を取材し、実現のポイントに迫ります。(2009年7月号)http://www.nikkeibpm.co.jp/cs/mag/it/nos/tokusyu.htmlよろしければご覧ください。マスターヨーダもクリエイター:クリエイティブになる31の方法(05/31)主要ツール120個を網羅するDevOpsツール周期表、作り方(05/26)ロジカル・ラテラル・クリティカルシンキングで発想力を鍛える(05/26)ユンケル黄帝液とユンケルスーパー黄帝液の違い(08/24)文章をわかりやすくする【18個】のルール(05/31)誠意を見せつつ相手に納得してもらう「謝罪報告書」の書き方(04/11)10年前に予測したITの将来が2017年どれだけ実現できているか?(03/30)【IT業界名言集】我がコードは我流。