米政府「これからはFBIに全ての中国IT製品を検閲させる」中国政府「・・・」

5年ほど前、「米国政府が調達しているネットワーク機器に中国製の偽シスコルーターが流通している」というニュースが話題になりました。

（中国製偽シスコ・ルータが米国の重要インフラに流通している件）
http://motivate.jp/archives/2008/04/post_153.html

当該ルーターを含む機器の火災事故の際の調査にて、FBIがシスコに解析を依頼した結果、偽造品であることが判明したとのこと。FBIによる捜査の結果、偽造ルーターは中国深セン市の工場で生産されたものと推定されています。

中国製の偽シスコ製品はさまざまな販売経路から格安で米国に卸されていました。バックドアが仕込まれていることはなかったとのですが、やろうと思えば米国中枢のネットワークにアクセスされるリスクがあったことは事実であり、このニュースの頃から、コスト偏重による中国製品シフトへのリスクが一般的に知られるようになり、米国政府もハードウェア調達方針を見直す流れが起こり始めました。

そして、2013/3/28、中国IT製品購入に係る審査ルールが発表されました。

『米政府の一部機関は、中国企業からＩＴ（情報技術）製品を購入する際に必ず連邦捜査局（ＦＢＩ）などの審査を受けることになった。製品に隠された機能によって、コンピューターシステムから機密情報を持ち出すスパイ行為が行われたり、システムを破壊するサイバーテロが起きたりする危険性を警戒したためだ。
（中略）
対象となる機関は、司法省、商務省、米航空宇宙局（ＮＡＳＡ）、国立科学財団（ＮＳＦ）の四つ。中国によるサイバー攻撃の懸念を巡っては、米下院の情報特別委員会が昨年１０月に報告書を出し、中国の通信機器会社「華為技術」と「中興通訊（ＺＴＥ）」を米政府のシステムから排除することや、米民間企業との取引自粛を求めた。』
（http://www.yomiuri.co.jp/net/news1/world/20130328-OYT1T00556.htm）

華為技術（ファーウェイ）などは、ここ数年で日本企業での採用実績も増えています。身近なところでは、イーモバイルのLTEルーターがファーウェイ製です。

この米国政府の動きに対して、中国政府の対応は今のところ分かっていませんが、本質は異なれど字面だけで見れば、かつて中国政府がやろうとして諦めた、電子輸入品に対するソースコード開示要求に近い話なんですよね。

『中国政府がデジタル家電などの中核情報をメーカーに強制開示させる制度を５月に発足させることが２３日、明らかになった。
（中略）
制度は、中国で生産・販売する外国製の情報技術（ＩＴ）製品について、製品を制御するソフトウエアの設計図である「ソースコード」の開示をメーカーに強制するものだ。中国当局の職員が日本を訪れ製品をチェックする手続きも含まれる。拒否すれば、その製品の現地生産・販売や対中輸出ができなくなる。
どの先進国も採用していない異例の制度で、非接触ＩＣカードやデジタル複写機、金融機関向けの現金自動預け払い機（ＡＴＭ）システムなど、日本企業が得意な製品も幅広く開示対象になる可能性がある。』
（中国のソースコード強制開示制度はオープンソースを促進させるか？ ）
http://it-ura.seesaa.net/article/117995133.html

このときは、世界中からの猛反発を受け、中国政府は速やかに要求を撤回しましたが、米国政府の今回の措置に対抗するために、再びソースコード強制開示を求めてくる可能性はあるかもしれません。

今後、第三者機関が安全性を確認する術が必要になってくるのであれば、そのコストが製品価格に上乗せされることになるかもしれませんし、情報漏えいを懸念し、IT機器調達がブロック経済のごとく、地域ごとの調達を優先させるようになる可能性も否定はできません。

ITの未来が疑心暗鬼の世界を招かないことを願います。

PMOが機能しないシステム開発プロジェクトはデスマーチまっしぐら

「PMOが機能しないプロジェクトは失敗する」ということはIT業界ではよく知られていますが、その割に、「機能していないPMO」は世の中に溢れています。なぜでしょうか？

おさらいですが、ある程度の規模のシステム開発プロジェクトになると、必ずPMO（プロジェクト・マネジメント・オフィス）を配置します。PMOは「全体管理チーム」という言葉で表現されることも多く、プロジェクト全体の進捗・課題・リスクを管理し、問題解消を促すことがその役割です。

このことをプロジェクトメンバー全員が正しく理解していないと、そのプロジェクトはデスマーチ（不眠不休の長時間労働状態）を突き進むことになります。たとえば、次のような認識齟齬があるプロジェクトは、デスマーチまっしぐらの典型です。

【ケース１：検討漏れが発覚してデスマーチへGO】
PMOメンバー
「自分たちは進捗・課題・リスク管理とプロジェクト外への報告書を作るだけ」
他チームメンバー
「PMOは領域横断課題を取り上げて解決支援もしてくれる」

【ケース２：PMOに作業が集中してボトルネックとなりデスマーチへGO】
PMOメンバー
「自分たちは進捗・課題・リスク管理とプロジェクト外への報告書を作る」
「チームに跨る横断案件は全部自分たちが預かって判断する」
他チームメンバー
「困ったらPMOにエスカレーションすれば、そこで判断してもらえる」

つまり、最低限しかやらないPMOにあらぬ期待を抱いているプロジェクト、なんでもレビューしないと気が済まないPMOを抱えているところは失敗プロジェクトであり、機能していないPMOを抱えているということです。やらなすぎもやりすぎも良くありません。

ケース２については、「十分な数のPMOがいれば問題ないのでは？」との疑問を持った人がいるかと思います。横断案件を仕分けするだけなら単純作業者のマンパワー投入で済むかもしれないと考えるかもしれませんが、仕分けて判断するためには業務内容をある程度理解している人が担当しなければ難しいでしょう。

しかし、そういう人材をPMOに置いておくくらいなら、各業務チームに配置して仕事をしてもらった方が生産的です。そもそも、そのような戦力に余裕のあるプロジェクトはありませんから、現場からすれば、絵に描いた餅です。

では、最適なPMOとは、�@どういう役割を担う組織で、�A数はどれくらい必要になるのでしょうか。

�@については冒頭で述べたことがそのまま答えになります。「プロジェクト全体の進捗・課題・リスクを管理し、問題解消を促すこと」です。重要なのは、PMOに割り当てられた工数で対処できるよう、横断的な問題の解消ルールがプロジェクト全体で合意できており、各チームの業務分掌がはっきりとしている状態を保つことです。

結局、どれくらいの工数をPMOに割り当てるかに帰結します。プロジェクト全体に対するPMOの要員数割合は、経験則からプロジェクト全体の10％程度と言われることがありますが、プロジェクトの性質・状態によって幅が出ます。私や周囲のベテランPMの見解では、以下の割合がベースになるように思えます。

●横断課題が比較的多発しそうな時期（要件定義・基本設計）
PMO：全体の10％〜20％
100人の社員・ベンダーを管理下に場合、PMOは10〜20人配置
※工数を高める要因：
管理ルールの内部徹底、横断課題の仕分け、各チームへの働きかけ

●それ以外の時期（詳細設計、結合テスト、総合テスト）
PMO：全体の7％〜15％
100人の社員・ベンダーを管理下に場合、PMOは7〜15人配置

％の下限はプロジェクトの参画人数が150人を超えるケース、上限は参画人数30人以下の小規模ケースでの要員割合を想定しています。プロジェクトメンバーが多くなるほど、PMO一人あたりの担当数が増えるイメージです。

また、プロジェクトメンバーの全体数は、PMOが直接管理することになるユーザー、ベンダーの要員数を意図しています。ただし、ユーザーやベンダーの中に専任のサブPMOがいるなら、その領域の要員数は全体数に含めずに考えます。アウトソーシングベンダーが20人のサブPMOと200人のPJメンバーを抱えているなら、サブPMOが役割を果たす限り、上位PMOの作業量はそれほど変わらないと考えるからです。

※サブPMOの工数に大きな不足はないという乱暴な前提を置いています

たとえば、社員50人、ベンダー200人、うちアウトソーシングベンダー100人（自分たちの領域についてプロジェクト管理は実施されていく）というケースで要件定義を実施するなら、

｛50人＋（200人-100人）｝×10％＝15人。

この15人がPMO要員数の素案です。配置の仕方としては、各チームに1名ずつチーム進捗管理要員を置き、残った人数を専任PMOとしてチーム化します。5つのアプリチーム、1つのアーキチーム、2つの試験チームがあるなら、それで6人カウントし、残りの9名でプロジェクト管理を行います。

社員10人、ベンダー20人で試験をするなら、

（10人＋20人）×15％＝4人

アプリチームが2つ、アーキチームが1つとして、テストフェーズなので各チームは兼務レベルの課題管理要員を置いてもらいます。その代わりにPMO要員の4人が集中管理をしていきます。

だいたいこれくらいの数がPMO要員数を議論するスタート地点になるでしょうか。あとは、プロジェクトの複雑性を加味して、鉛筆を舐めながらさじ加減を決める世界でしょう。accenture、IBM、NTTデータなどの超大規模なSI企業は要員見積りの方法論を持っていますが、ツールを叩いて出てきた数字について、検証せずにそのまま使っているところはありません。

ということで、長くなりましたが、「その役割に対する認識がプロジェクト内で齟齬が無い」ことと、「プロジェクト要員数の7〜20％くらいの範囲を素案とした工数検証」の両方が揃って、ようやくまともなPMOが動き出すという話でした。

私自身振り返ってみて思いますが、これができていないプロジェクト、相当たくさんありますね。できない理由は、予算制約や関係者の無理解など、外的要因によるものが多いと感じます。PMOがやることは戦術であり、PMOの役割・体制・工数を決めるのは戦略です。こういう状況を思うと、銀河英雄伝説でヤン・ウェンリーが語った名言が頭に浮かびます。

「５分と５分の条件を揃えるのが戦略だ 戦略を無視して戦術を論ずるなど、実際の戦争ではありえないことだ」

デスマーチに突入するプロジェクトは、たいてい戦略を無視した戦術を論じているところです・・・

ITシステム開発のフェーズを2つに大別すると・・・政府調達に見るIT投資の無駄遣い

『要件定義／基本設計／詳細設計／開発・単体テスト／結合テスト／総合テスト』というシステム開発全体を通して、2つに大別するとフェーズをどのように分けることができるのか、という質問をいろいろな人にしてみたところ、面白い傾向が見受けられました。

まず、答えの大半は2パターンのいずれかでした。一番多かったのはこの区分です。

【回答１】 Ｖモデルによる区分パターン
要件定義／基本設計／詳細設計 vs 開発・単体テスト／結合テスト／総合テスト

システム開発には必ずテストフェーズがあります。テストフェーズでは、要件・設計に基づいた開発がしっかりと行えているかを試験項目に沿って検証するので、必然的に、「開発・単体テスト」は直前フェーズの「詳細設計」で決めたことができているかを確かめることになります。同じように、「結合テスト」は「基本設計」で決めたことの確認、「総合テスト」は「要件定義」で決めたことの確認をします。

このため、要件・設計フェーズとテストフェーズの2つに大別できるという考え方が回答１です。クライアントの業界（通信・金融・官公庁など）に関係なく、様々な人たちがこの回答をしていました。

一方、回答１に次いで多かったのがこれです。

【回答２】 調達単位による区分パターン
要件定義 vs 基本設計／詳細設計／開発・単体テスト／結合テスト／総合テスト

回答２を挙げてくれた人たちは、明らかにクライアントの業界において偏りが見られました。それは、官公庁の案件に関わる機会が多い人からの回答が多かったのです。

官公庁や半官半民と言われる企業の場合、特定フェーズを担ったベンダーは別のフェーズを受注してはならないとしていることがあります。これは分離調達と呼ばれる官公庁由来の調達制限の仕組みです。ひとつのシステム開発が数十億円に上る官公庁では、これを1社に独占させてしまうと、「規模の大きいベンダーしか受注できなくて不公平である」ということで、小規模ベンダーにも案件受注のチャンスを広げるために、わざわざこのような制度ができました。

分離調達の場合、システム開発の案件をフェーズによって分割することになります。一般的なのは、要件定義フェーズ／設計・開発・テストフェーズに分けるケースです。要件定義まではユーザー側の業務支援という位置づけですが、設計フェーズ以降はシステム開発の受託者ということでユーザ側との役割が明確に線引きされるので、ここをもってフェーズを分けるのが一番インパクトが少ないというのが理由です。

他にも、規模が超大な案件では、結合テスト・総合テストフェーズも別のベンダーに発注するケースがあります。なんとも非効率に思えますが、要件定義からテストまで1つのベンダーに任せてしまうことで失われる競争原理と中小ベンダーへの機会不平等を踏まえると、分離調達というのはやむを得ない措置というのが発注側の言い分です。

では、回答２（分離調達）を挙げた人が回答１（Ｖモデル）を否定したかというと、そんなことはありませんでした。むしろ、「まあその方が普通の分け方だね」と自嘲するような言い方が目立ったように思えます。反対に回答１を挙げた人に回答２の考え方を伝えると、官公庁の案件に関わったことのない人たちは、「それは不自然だし、むしろ悪影響なのでは？」との疑問の声が聞かれます。

この声と同じ考えを、実は政府中枢の人間も持っています。たとえば、2010年12月の「最適化、調達の高度化に向けた調査結果」というＣＩＯ補佐官等連絡会議の資料では、次のような問題意識が発表されています。
http://www.kantei.go.jp/jp/singi/it2/denshigyousei/dai5/siryou3_1.pdf

• 分離調達によって、（フェーズ間の）整合性をとるための費用が増加。・・・安値入札によるロックインでトータルコストの増大。開発失敗リスクによる捨て金の増加。
• 能力不足のベンダーが受注するリスクや期間内に受注が確定できないリスクは増えた。
• 多くの業者が調達に関わり、仕様・要件に対する共通理解が困難。・・・基盤受注業者が個別受注業者の責任まで負わせられ、そのコスト負担を強いられる。

他にもさまざまな問題点が挙げられていますが、残念なことに、2年以上前の問題提起も空しく、まだ現場ではこれらを解消しようとする動きは大きくありません。

開発以前のフェーズとその後ろのフェーズは明確に性質が異なるので、担当チーム（もしくはベンダー）を分けることは、品質検証という意味はありますし、その意味でテストチームは開発チームと分けているプロジェクトというのは一般的です。（ベンダーを分けるところまでやるのは超大規模な案件に限られますが）

しかし、要件定義と設計フェーズを分断するのは、システム開発上のポジティブな意味はほとんどありません。むしろ、設計に責任を持たない人たちが好き勝手に要件定義を行って、絵に描いた餅が出来上がってしまうリスクを高めます。そうさせないためには、要件定義をしたベンダーが責任を持ってい設計・開発を行うように調達計画を定めなければなりませんが、今の仕組みはそうなっていません。

官公庁の案件に関わっている人たちは、是非、調達計画の仕組みの不自然さについて声を上げてみてください。政府中枢で最適化計画の調達の仕組みに関わっている人たちに、その声が届けば、特許庁の55億円の無駄金、そのほか下記リンクに示したIT投資の無駄遣いが減って、日本の国のシステム開発はもう少しマシになるのではないかと思います。

『電子政府構想は無駄遣いの温床： 8754万円の電子申請システムが4年間使われず』
http://it-ura.seesaa.net/article/127063402.html

• 沖縄県駐留軍用地の返還にともなう給付金支給申請システム（初期費用：3.9億円、ランニング費用：0.4億円/年、利用件数：4件/年）
• 政治資金・政党助成申請・届出オンラインシステム（初期費用：5.7億円、ランニング費用：2.9億円/年、利用件数：0件/年）
• 公益法人の事業計画書及び収支報告書の届出システム（初期費用：5.2億円、ランニング費用：0.4億円/年、利用件数：29件/年）
• 高校卒業程度認定試験の合格証の交付手続きシステム（初期費用：11.8億円、ランニング費用：1.1億円/年、利用件数：115件/年）
• 製造タバコの小売販売業の許可等239手続きシステム（初期費用：0.5億円、ランニング費用：0.1億円/年、利用件数：55件/年）
• 恩給申請手続きシステム（初期費用：1.9億円、ランニング費用：0.6億円/年、利用件数：476件/年） 等

韓国大規模サイバーテロ、Windows7不正使用が理由はデマ？

韓国では2013/3/20の14時頃、主要テレビ局3社、大手銀行などの社内イントラネットがほぼ同時間帯から使えなくなったことが報道されています。

『（前略）
聯合ニュースによると、システムがダウンしたのは韓国のKBSテレビとMBCテレビ、YTNテレビの3放送局と、新韓銀行の情報システムである。「社内業務システムがダウンした」「社内メールが使えない」「社内パソコンが起動できない」などの被害が報告されている。』
http://itpro.nikkeibp.co.jp/article/NEWS/20130320/464581/

報道時点では外部からの大規模テロ攻撃の疑いがあるということで、北朝鮮のハッカー集団が疑われていましたが、ネット上では、今回の被害に韓国軍が含まれていないことに着目し、「Windows7のアクティベーション回避（ライセンス料未払いでOSを利用）が原因の障害ではないか」との話題が広まっています。

『128 +7：名無しさん＠１３周年 ：sage：2013/03/20(水) 22:11:40.79 ID: NnrTug/uP (1)win7 SP1 強制うｐデート開始
http://gigazine.net/news/20130319-win7-sp1-rolling-out/

160 三毛(catv?) sage New! 2013/03/20(水) 18:57:13.70 ID:bDliyWCV0
>>114
調べてたら思い出した。
Windows 7のアクティベーション回避法のうちの1つにMBRを使った方法があって、これを適用した環境でService Pack 1をインストールすると起動できなくなる、というトラブルがあったはず。もしかしてこれに引っかかったんじゃ・・・・・

『20日午後、KBS、MBC、YTN [040300]、新韓銀行、農協など放送・金融機関の電算網を麻痺させた、悪意のあるコードは、これらの機関のPCブート領域（MBR）を破壊したことが明らかになった。

政府は、放送通信委員会、警察庁、韓国インターネット振興院などにサイバー脅威合同対策チームをKBSなど派遣、被害を受けたPCからマルウェアのサンプルを入手して分析した結果、このよう明らかになった。放送通信委員会は同日午後、2次ブリーフィングで"被害機関から採証した悪意のあるコードを分析した結果、特定のベンダーのアップデータ管理サーバー（PMS）で悪性コードが流布されたものと推定される"と説明した。しかし、悪意のあるコードが流布された具体的なポイント等については確認していなかった。

合同対策チームは、国の公共機関の被害がないものと認識しており追加のマルウェアなどの攻撃に備え、全機関に警戒を強化して攻撃発生時の迅速なリカバリシステムを稼動するように措置した。政府はコンピュータ・ネットワーク麻痺の原因が分析されるように国家サイバー安全戦略会議を開き、国家レベルのフォローアップなどを議論する予定である。』
（ソウル=連合ニュース）

これ、ぶっちゃけほぼ原因確定ですね。』
http://uni.2ch.net/test/read.cgi/newsplus/1363783710/

いくつかのサイトでは、韓国軍は以前、マイクロソフトとWindows7のアクティベーションに関するやりとりで多額のライセンス料請求を受けていたことに触れており、その結果、同軍は正規ライセンスで利用することになったから、今回は問題が発生しなかったと推測していました。

もっともらしく思えたこの推測ですが、その後、セキュリティベンダーの調査も進み、3/21木曜昼時点で、以下の情報まで判明しています。

『（前略）
アンラボは現地時間3月20日午後6時に同社Webサイト上で専用のワクチンソフトの提供を開始して、検査、治療を実施できる体制を整えている。同社Webサイトによると、今回のサイバー攻撃はマルウエアを利用したもので、感染するとハードディスクが破壊される。

　Windows XPおよび同 2003 Serverでは、物理ディスクのMBR（マスターブートレコード）とVBR（ボリュームブートレコード）にゴミデータを書き込んでハードディスクを破壊する。Windows Vistaと同 7では、論理ドライブのすべてのファイル内容を削除してハードディスクを破壊する。

　シマンテックはマルウエアと推測される「Trojan Horse/Trojan.Jokra」と「WS.Reputation.1」を検知しているとブログで解説している。

（中略）

　今回の攻撃内容は目新しいものではなく、2012年8月に中東でも同様の被害を受けた組織が多くあったとしている。』
http://itpro.nikkeibp.co.jp/article/NEWS/20130321/464626/

また、直近のニュースでは、攻撃元のIPアドレスは中国のものであったとの報道がロイターからありました。韓国政府は、これまでも中国内からの北朝鮮ハッカーによるサイバー攻撃があったと発表しており、今回もその可能性は十分あるでしょう。先日、北朝鮮は韓国との休戦協定を破棄すると通告しており、名実ともに現在の韓国は北朝鮮と交戦状態になったと理解して良いかもしれません。

完全解析にはさらに5日程を要すると韓国政府は発表しており、続報がある程度分かったら、再度取りまとめます。

【2013/3/22 続報】
ITproにて本件の取りまとめがありました。

　◎マルウエアまん延の原因はパッチ更新管理サーバーのハッキング、韓国政府
　　→ http://itpro.nikkeibp.co.jp/article/NEWS/20130321/464942/?ml

　◎韓国の大規模サイバー攻撃は非正規Windowsサーバーのパッチ配布が原因
　　→ http://itpro.nikkeibp.co.jp/article/COLUMN/20130321/464661/?ml

韓国内で使用されているWindowsのパッチ提供サーバ（不具合・バグフィックスプログラムを配布するサーバ）の参照先がマイクロソフトが関知しない非公式サーバを参照しており、そこで正規版のパッチに混じってマルウェア（悪意のあるパッチ）が配布されていたため、膨大な数の企業内Windwsサーバが感染し、システムが破壊される（3/20の14時にOSが削除される）という甚大な被害につながったとのことです。

このことから分かるのは、韓国内の大手企業でさえ、社内で使用しているWindowsパッチ提供サーバの少なくない数が、海賊版のWindowsを搭載していたということです。好意的に解釈すれば、このせいで他の健全なWindowsサーバも被害に遭ったと言えますが、悪意を持って解釈すれば、他の業務サーバもかなりの数の海賊版Windowsサーバが使用されていたのではないかという疑惑が出たということです。

過去に韓国では海賊版Windowsが多数稼働しており、マイクロソフトが問題解決に取り組んでいたという事実がありますので、後者の疑惑はそれなりの信憑性をもって捉えられることでしょう。

新人のための７つのワークハック（裏・7つの習慣）・改

4月前になるといろいろなところで新人への心得が語られていますね。正攻法のエントリーが多いので、ここでは裏話的なワークハック（要領よく仕事をしちゃう術）をスティーブン・R・コビーの『7つの習慣』になぞらえて書いてみようと思います。

その前に、前提としてビジネスマンもエンジニアも社会人であれば必読書と言われている『7つの習慣』が何かを知ってますか？ 知らない方がいたら、この機会に覚えておいて下さい。もはや社会常識になりつつある概念です。

第1の習慣：主体性を発揮する（Be Proactive）
第2の習慣：目的を持って始める（Begin with the End in Mind）
第3の習慣：重要事項を優先する（Put First Things first）
第4の習慣：Win-Winを考える（Think Win/Win）
第5の習慣：理解してから理解される（Seek First to Understand, Then to Be Understood）
第6の習慣：相乗効果を発揮する（Synergize）
第7の習慣：刃を研ぐ（Sharpen the Saw）

長くなるので、各習慣の意味を知りたい方は以下リンクを参照ください。
→ http://it-ura.seesaa.net/article/117318575.html

7つの習慣は正攻法として素晴らしいものの、これだけ渡り歩けるほど優しくないのがIT業界です。私の過去の経験を踏まえ、新たに７つのワークハックとして紹介したいと思います。

 

【第1のワークハック：できる奴の主体性を発揮させる】
⇔第1の習慣：主体性を発揮する（Be Proactive）

日本の企業は出る杭を容赦なく打ち付けます。自分から声を挙げて「やります」なんて言った日には、アナタの元に余計なトラブルまで舞い込んでくることでしょう。そういうときは周りも積極的に巻き込んでしまいましょう。有識者をうまく持ち上げれば、きっとあなたに協力してくれますよ。これで波風立てずに成功を勝ち取って下さい。

「私がやりたいのですけど、きっと力不足ですよ。ああ、Aさんほどの能力があればなぁ・・・え、手伝ってくれるのですか？」

【第2のワークハック：目的がなくても始めてみる】
⇔第2の習慣：目的を持って始める（Begin with the End in Mind）

目的を持って行動するのって疲れませんか？ 何か行動を起こすときには常にプランニングが必要だなんて、そんなことじゃ楽しく仕事なんてできませんよ。あなたは物事を楽しむのに目的が必要なほど石頭なのですか？ 目の前でアプリケーションが動くのを見るのを楽しんでいるうちにコーディングなんて終わらせることができますから。

「なぜコーディングをするのかって？ そこにコードがあるからだよ！」

【第3のワークハック：重要ではない事項を優先してみる】

⇔第3の習慣：重要事項を優先する（Put First Things first）

緊急ではないが重要な事項について効率的に着手することが大切だなんて言われてますが、重要な仕事というのは例外なく多大な労力を伴うワケです。こういうのを上手くこなせるようになると、ますます仕事がたくさん振られてワークライフで人生が終わりますよ。そういう事態を避けるには、重要性の低い仕事を優先させてみましょう。あなたが人並みのパフォーマンスを発揮しているように見えるので、周囲が過度な期待をしなくなります。仕事がとても楽になりますよ。

「あれ、その仕事って昨日で終わったんじゃなかったの？早く終わったようだから仕事を分けようと思ったのに残念。」

【第4のワークハック：Win-Loseをアピールする】

⇔第4の習慣：Win-Winを考える（Think Win/Win）

「お互いがWin-Winになるよう協力していきましょう」というのもいいですが、もっと効果的なのは「あなたがコレをやらないとLoseになりますよ」という具合にリスクを煽りまくって相手を焚きつける方法です。自分の努力はそこそこに、相手の多大な努力を引き出してやりましょう。

「俺はどうなってもいいんだけどさ、それをやらずに困るのはお前の方だぜ？」

【第5のワークハック：主張してから譲歩させる】

⇔第5の習慣：理解してから理解される（Seek First to Understand, Then to Be Understood）

相手の言い分に理解を示してから自分の言い分を聞いてもらうだけではうまく行かない場面があります。ずけずけと自分の主張を押し通す相手には自分も同じスタイルで望まなければ太刀打ちできません。最初に高い要求を繰り返し主張し、相手が辟易したところで妥協ポイントをハッキリ提示することで交渉を終結に向かわせることができます。いわゆるハイボールという技ですね。

「あなたの立場を考えて今回だけは特別にこの点で妥協しよう。良かったな、この交渉上手め。」

【第6のワークハック：相殺効果を回避する】

⇔第6の習慣：相乗効果を発揮する（Synergize）

犬猿の仲という言葉がある通り、どうしても相性が悪い相手というのもいるものです。少しずつ仕事を進めていくのが好きなのに、巨人の原監督のように「ぐわっとやろうぜ」とか言われても意味が分かりません。もう少し私のやり方を尊重してもらえませんか？ などという不毛なやり取りが起きるシチュエーションは極力回避していきましょう。そのためには、自分の得手不得手を知った上で、苦手なタイプの人には近づかないように。それが長く仕事を続ける秘訣です。

「ねえねえ、ちょっと頼みたい資料があるんだけどさ・・・あれ、いなくなった？」

【第7のワークハック：人知れず刃を研ぐ】
⇔第7の習慣：刃を研ぐ（Sharpen the Saw）

学生時代からいましたよね、こういうタイプ。全然勉強していないと言いながら徹夜で勉強しちゃうなんて卑怯ですよ。でも、社会に出て評価されるのはそういうタイプなんですよ。突然仕事を振られても、実は事前にちょこちょこ調べていたからうまくできました、という部下が私も欲しいです。

「悪いのだけどコレについて調べてもらえないかな？ えっ、もう当たりが付いている？ ほぉ、なかなか優秀じゃないか。」

 

あなたが共感できるワークハックはありましたか？

ちなみに、7つの習慣にヒントを得た考え方は他にもたくさんあります。たとえば、「脳に悪い7つの習慣」という本では、次の7つのことを避けるようにアドバイスしています。

1. 「興味がない」と物事を避けることが多い
2. 「嫌だ」「疲れた」とグチを言う
3. 言われたことをコツコツやる
4. 常に効率を考えている
5. やりたくないのに、我慢して勉強する
6. スポーツや絵などの趣味がない
7. めったに人をほめない

海外のサイトでは、「7 Habits of Highly Ineffective People」という7つの悪影響を与える習慣が紹介されています。

1. Not showing up.
   （遅刻する）
2. Procrastinating half the day.
   （半日をだらだら過ごす）
3. When actually doing something, doing something that isn’t the most important thing right now.
   （重要ではないことばかりに着手する）
4. Thinking too much.
   （考えすぎる）
5. Seeing the negative and downsides in just about anything.
   （マイナス思考に陥る）
6. Clinging to your own thoughts and being closed to outside influences.
   （自分の意見に拘泥する）
7. Constantly on information overload.
   （あれもこれもと情報を集めすぎる）

また、「7つの悪習慣」として、7つの習慣の裏側をなぞって反面教師にするというものを紹介しているエントリーもあります。
http://blog.livedoor.jp/habuakihiro/archives/65204690.html

・第1の悪習慣 人のせいにする
・第2の悪習慣 目的を持たないで始める
・第3の悪習慣 １番大切なことは後まわし
・第4の悪習慣 勝ち負けという考え方
・第5の悪習慣 まず自分が話し、それから聞くふりをする
・第6の悪習慣 頼れるのは自分だけ
・第7の悪習慣 自分をすり減らす