IT（情報技術）を活用してビジネスモデルを変えたり、効果的に経営改革に生かす極意とは――こんな質問をされたら、あなたなら何と答えますか。日経情報ストラテジー3月号（1月29日発売）特集1「有力企業357社CIO調査　企業戦略を変えるリーダーが明かす　IT活用の極意は「3つの力」にあり」の取材班は、（1）課題創造力、（2）戦略実行力、（3）巻き込み力――との結論に達した。 具体的な事例は本誌で解説しているが、簡単に説明すると（1）の課題創造力とは自社の変えるべき部分を冷徹に見極める力である。的確に自社の問題点を認識できれば、効果的なITの生かし方も見えてくる。（2）の戦略実行力とは、経営トップの戦略を深く理解して将来像を共有しながら、必要なIT基盤を先回りして設計する能力だ。（3）の巻き込み力とは、ITを導入して変革を遂行するために必要な協力を、現場から得る力のこと。優れたIT基盤を導入して

「“顧客”にフォーカスすることが、一番重要だ」。 オムロンのCIO（最高情報責任者）である、執行役員常務事業プロセス革新本部長の樋口英雄氏は2008年1月31日、「ITpro EXPO 2008」の基調講演でこう主張した。樋口氏は、日経情報ストラテジーが毎年選出している「CIOオブ・ザ・イヤー2007」の受賞者である（関連記事）。オムロンの業務革新をCIOとして実行した経験から、その極意を語った。 IT（情報技術）バブル後の赤字転落から立ち直ったオムロンは、2007年度までの4年間、「事業価値の倍増」を目指して収益体質強化に取り組んできた。この初期の2004年6月に樋口氏はセンサー部門の事業部長から本社に異動してCIOに就任した。他部門と協働しながらサプライチェーンや本社部門の改革を進めて、売上高販管費率を2ポイント引き下げるのに貢献した。 2005年度に売上高の2.4％を占めたIT費用も

顧客側から見ると，PMOははっきりとした成果物がなかったり，プロジェクトマネジャと役割が重なっていたりする場合がある。このため，何をやっているか分からない組織と見られることが多い。“存在理由”を疑われたPMOメンバーは，モチベーションを急速に失っていくだろう。そうなる前に，プロジェクトマネジャはPMOの必要性を顧客に訴え，PMOメンバーにスポットライトを当てる必要がある。 後藤 年成 マネジメントソリューションズ マネージャー PMP 本来，「PMOは目立てない組織」です。それゆえに，PMO経験者の中にはこんな経験をした方もいらっしゃるのではないでしょうか。 ●顧客から「PMOは何をしているか分からない。必要なの？」と言われた。 ●プロジェクトメンバーから「業務内容を知らないくせに，偉そうに命令ばかりするな」と言われた。 私がPMOをしていた時に，実際に言われた言葉です。PMOの仕事は縁の

多くのユーザー企業で、情報システム部門が衰退した----これは動かしがたい事実であるが、ではその原因は何か？ 経営者がITに無理解だったからという天動説や、経営の期待にシステム部門が応えらなかったという地動説など諸説ある。しかし、よくよく考えてみると、システム部門の衰退は“歴史的必然”なのだろう。 今、システム部門が総力を挙げて取り組む開発プロジェクトは、どれくらいの頻度があるだろうか。おそらく金融機関、通信、一部の製造業を除けば、よほどの大手企業でも4～5年に一度程度だろう。そんな頻度では、システム部門が経営の視点でIT活用を考え、利用部門に対してリーダーシップを発揮してIT化を推進することなど、夢のまた夢である。 そもそも、システム部門が最も経営の視点でモノを考える機会は、基幹業務システムの構築など大規模な開発プロジェクトの時である。大規模なシステム構築とは業務プロセスの再設計であり、

土日出勤や連日の深夜残業といった過重労働，スケジュール通りに進まないプロジェクト，次々に登場する新技術に対応しなければならないプレッシャ，将来のキャリアパスが見えない不安…。ITエジニアを取り巻く環境は厳しさを増す一方だ（図1）。過酷な状況に追い込まれれば，当然，疲れやストレスが溜まり，やがては“こころの病”へと移行する可能性がある。読者自身あるいは読者の周りのエンジニアにも，“こころの病予備軍”は結構いるのではないだろうか。 こころの病やこころの“不健康状態”を，ここでは「メンタルヘルス不調」と呼ぶことにする。 メンタルヘルス不調者はここ数年，明らかに増加傾向にある。財団法人・社会経済生産性本部メンタル・ヘルス研究所が2006年4月に実施した上場企業2150社に対するアンケート調査（回答数は218社）でも，6割以上（61.5％）の企業が「過去3年間で，こころの病は増加傾向にある」と答えて

JTBモチベーションズ　コンサルタント。日本ヒューレット・パッカードにて，ITコンサルタントとして製造業を中心に，ビジネスプロセスの構築からシステム設計・運用までに携わった後，パッケージ・ベンダーの採用や社員育成に携わる。現在はJTBモチベーションズで，モチベーション・コントロールを軸とした，企業向けのコンサルティングを行っている。モチベーション理論やNLP（神経言語プログラミング）のカウンセリング理論のノウハウを活かし，個人と組織を活性化させるコンサルティング，研修講師，講演などを行っている。メルマガ無料配信中。 人は目標が明確になっているときにモチベーションが上がりやすい，ということは前回お伝えしたとおりです。今回は，目標を設定してモチベーションを上げるための具体的な方法をご紹介しましょう。 ■周囲の人に目標について話す（宣言効果） 目標を達成するためには，自ら「目標を達成しなくてはな

ここ数年「ITアーキテクト」という言葉が広がり，関連する雑誌や書籍，イベントなども増えてきた。ところが肝心の現場を見ると「ITアーキテクト」という肩書きを持つエンジニアはほとんどいないように思う。実際，ユーザー企業やベンダ－各社にITアーキテクトへの取材を申し込んでも「そうしたエンジニアはうちにはいない」と断られることが少なくない。 なぜ，言葉だけが先行してITアーキテクトが現場にいないのか。「そもそも必要ない」という意見もあるかもしれない。だが，あるユーザー企業の情報システム部長は「全体最適の視点で技術や製品を選定できるITアーキテクトがいてくれたら」と嘆く。情報システムは大規模化・複雑化し，より重要な経営基盤になっている。そんな中でベンダー1社にすべてのシステムを見てもらうのは困難になってきた。そこで，社内にITアーキテクトを置いて「自分たちの手で適切なシステム構造や実装方針を決定した

「私のことが気に入らないのですか。もう来るなということですか。」ある朝突然、プロジェクトメンバーである協力会社の方から言われて、面食らいました。急に何を言い出すのかと戸惑いながらも、よくよく考えてみると思い当たる節があります。それにしても・・・ こんな話を、あるプロジェクトマネージャからお聞きしました。協力会社の方であるＰさんには、プログラマーとしてこのプロジェクトに参画していただいているそうです。ベテランのＰさんは、その分野の技術に詳しく、厳しいスケジュールのなかでも黙々と真面目に仕事をしてくださっていました。 １週間程前のこと。このプロジェクトで決めている標準とは異なる方法で、Ｐさんが作業をしておられたので、標準的な方法でしていただくよう、メンバーからお願いをしました。ところがＰさんは「自分はこれまでずっとこの方法でやってきたし、誰からも文句を言われたことはない！」と声を荒げ、その日は

私が要求開発やコンサルティングなどを行っているとき，UMLのクラス図によるモデリングについてよく聞かれることがあります。それは，「どうやったらモデリングが上手くなりますか？」という質問です。 そうした場合，私は「プログラムを書いたらいいですよ」とか「モデルを理解するためにも，プログラムを書いてみましょう」といったたぐいのことを，よく言います。 しかし，こう回答すると，とても嫌な顔をされることがあります。「実装はプログラマのやることだろ」とか「プログラムを書かずにうまくなれないですかね～」などと言われたりします。確かにTFP分割によるモデル図などは，ユーザー系の方でも「読めたり」または「書けたり」するので，プログラミングまでする必要はないかもしれません。 誤解のないよう，ここで要求開発に携わる人の役割を定義しておきましょう。ビジネスユースケースや要求ツリー，業務フロー，TFP分割図（読み書き

(1)部下を便利な作業者と思ってはいけない。あくまで自分で考えて，自分の責任で部下に任せなくてはならない。 (2)短い期間でも放っておいてはいけない。報告，相談，連絡を密にしなくてはならない。 (3)部下とのルールを決めなくてはならない。 (4)指導の際には何が悪いのか，良いのかを納得させる説明をしなくてはならない。 (5)仕事上の思想を持たせるようにしなくてはならない。 坂本にはこんな話をしました。しかし，実際のところすぐにうまくいくとは思っていませんでした。上司と部下の関係にはすぐなれますが，だからと言って，すぐに信頼関係が構築できるものではありません。 時間をかけて，一緒に問題に直面し，知恵を出しながら解決して，相互に成長していく・・・これができなければ本当の意味での上司と部下の関係にはなれないのです。 今回は，これに関する坂本のエピソードを紹介します。 部下と"どのような約束"をす

先週、ある大手ITサービス会社の経営幹部の方々と雑談していた時の話。経営企画を担当する幹部からは、「3年後にはSIの仕事がなくなる」とのものすごい危機感が口を衝いて出てきた。それに対して、SIの現場を預かる幹部は、「SIの未来に問題なし」との判断だった。どちらが正しいと言う前に、同一企業の中でのこの感覚のズレ。少しヤバイ気がしたのだが・・・。 ただよく考えると、この手の感覚のズレは、この会社だけでなく、ITサービス会社ならいずこも同じだ。経営幹部同士の意見の相違でなくても、経営トップと現場の感覚のズレだったりする。そりゃ、そうだ。SIの現場、あるいは営業現場では、もう絶好調。とにかく忙しい。営業部長の中には、「悩みなんかない」と公言する人までいる。 SE単価がなかなか上がらないのが気にかかるが、なんせ仕事を選べる。得意分野に集中すればよいから、失敗するリスクはほぼ皆無。従ってノリシロは不要

前回は，ユーザーの立場から見たベンダー・SEのあり方を取り上げたが，今回は同じ“供給側”ということでコンサルタントを取り上げよう。ユーザー企業および情報システム部門自身の責任については，この次に取り上げる予定なので，もう少しお待ちいただきたい。 一口にコンサルタントとは言っても，「戦略」「経営」「業務」「IT」などに分かれる。ここでは，すべてのコンサルタントに共通するものがあるという考え方に立って，コンサルタント全般を対象に総括的に検討していく。 経験不足のコンサルタントを利用して当初案への認可を得る コンサルタントについて，ユーザーから少なからぬ批判がある。「当り外れがある」「無駄な金を払った」「理想論を提案しっ放しだ」などなど。しかし，時に「すばらしいコンサルタントに巡り会えた」という話も聞く。ここでは，一般的に議論されるコンサルタントの資質や能力などは当然備えているものとして話を進め

顧客がベンダーやITエンジニアを見る目は，年々厳しくなっている。最新技術を追いかける根性や，徹夜してでも納期を守る体力だけでは，もはや評価してもらえない。「注文通りのシステムを作ればよい」というエンジニアは，消え行くのみだ。 介護用品の販売・リースを手がけるA社は2003年11月，新・販売管理システムの導入に踏み切った。ここ数年で問い合わせや受注が激増し，従来のシステムではさばききれなくなったことがきっかけである。同社はこれまで，商品への問合せや見積作成，在庫確認，成約といった一連の受注業務を，それぞれ異なるソフトを使って個別に処理していた。このため，顧客からの見積依頼から成約処理までに1週間近くかかることが珍しくなかった。二重，三重入力作業が発生するためミスも起きやすく，顧客からクレームを受ける原因になっていた。 そこでA社は，受注関連業務を一元的に管理できる新システムの導入を決断。さっ

検収は、システム開発契約義務の履行もしくは不履行を判断する方法として不可欠のプロセスである。検収の内容や方法については、契約によって事前に詳細に合意しておく必要がある。加えて、検収時に発生したトラブルの対処手順や、遅延によるコスト負担の責任についても明確にしておかなければならない。 検収は、システム開発契約における最後の履行段階である。あらゆる取引の履行に関して、その履行が契約の趣旨に合致しているか否かを検査し、その検査に合格した時点で履行が完了するという制度は、どこの国においても認められている制度である。わが国の商法は、第526条「買主による目的物の検査及び通知」がそれを規定している。 ただし、商法第526条が定める検査は、目視もしくは簡易な使用による検査を前提としており、コンピュータプログラムやシステムの検査を念頭においた立法ではない。そのため、極めてハイレベルで、かつ複雑な技術成果物

顧客役を務めるシェイクの森田英一社長に、新入社員が「顧客ニーズ」の聞き取りに訪れる [画像のクリックで拡大表示] 「お客様にメールを出す前に上司の確認を取りましたか」 「客先で、お客様より先に着席するのはマナー違反ですよ」 新入社員を前に、厳しくミスを指摘する指導員。印刷機器製造国内最大手の小森コーポレーションで、この4月新入社員向けに実施した研修のひとこまだ。 「自らの力で壁を破る人材」を採用基準とする同社では、入社したての新入社員に、社会人として自律的に行動する「クセ」をつけるため、丸1日を費やして「シミュレーション研修」を実施している。 50人あまりの新入社員を4人ずつのグループに分け、各チームを「旅行代理店で企業向けの社内旅行を企画するグループ」と仮定する。顧客のニーズを聞き取って旅行プランを立案し、プレゼンテーションするまでの仮想的なプロセスを実施する。外部の研修会社の講師が顧客

あなたは，苦手意識に悩まされたことはないだろうか？　SEであれば，顧客企業のシステム担当者がクレーマーのようにうるさい人物だったり，自分の上司とどうしてもウマが合わなかったり･･････。できればそういう人物には近寄りたくないし，仕事でどうしても会わねばならない時には，何とか事なきを得たいと祈るような気持ちになるに違いない。 だが時として，自分のキャリアをかけるような大型プロジェクトにおいて「苦手な相手」に遭遇してしまうことがある。ビジネスで成功するためには，どうしてもその道を避けて通ることができず，正面から立ち向かわなくてはならないとき，自分の内にある苦手意識をどうやって克服したらよいのだろう。 トップ・アスリートも苦手意識には勝てない 実は，この苦手意識というくせものは誰もが持っている。それは並はずれた精神力を持つトップ・アスリートでも同じことである。いかに優れた能力を持っていたとして

7月11日夜，銀座で筆者のビジネスユニット（NTTデータの事業単位）主催のパーティを開いた。会社で5月の創立記念日に業績表彰を受賞したので，お祝いとふだんお世話になっているパートナー企業の方への御礼をするためだ。来賓として6月にNTTデータ代表取締役常務からNTT代表取締役副社長（CTO，CIO）になられた宇治則孝さんにご参加いただいた。宇治さんには7年間にわたってお世話になり，トップセールスや難しい問題への対応で幾度も助けていただいた。パーティの冒頭で宇治さんへの御礼とお祝いを申し上げた。 このようなパーティは今回が2004年，2006年に続いて3回目だった。2004年には約100人，昨年と今年は約60人の方を招待した。表彰には賞金がついているのだが，それを一晩ですべてパーティに使ってしまうのだ。思い出のために記念品を作ろう，などという発想はまったくない。招待するお客様の数は賞の大きさに

この前、大手SIerのCFOと“SI進行基準”の件で話す機会があったが、彼はその導入に憤懣やるかたなしだそうだ。2008年度から会計処理に導入されるこの進行基準は、システム開発の進捗状況に合わせて売上を“分散計上”するやり方で、内部統制制度と合わせ、経営管理能力に劣るITサービス会社には恐ろしい負担になるだろう。だが、このCFOが怒っているのは、そこではない。 進行基準の話はこれまでも何度か書いたので、そちらも読んでいただきたいが、要は国際会計基準とのコンバージェンスの関係で、SIの売上についても従来の完成基準から進行基準に変更しなければならない。今では検収書をもらってから売上を計上していたが、これからは毎月投入したSEコストに見合う売上を計上するようになる。 ちょっと考えただけでも、これは大変だ。プロジェクトに遅れなどの問題が生じ、大量のSEを投入した場合、そのコストに見合う売上を建てる

プロジェクト成功の秘訣は「プロセスの明確化」と「トップの承認」 エーオン　リスク　サービス　ジャパン インフォメーション・テクノロジー　担当部長 野間文子氏 「成長過程にある会社に移り，自分のやりたいことをもっとアグレッシブに実現できる会社で思い切り仕事をしたい」──転職を決意した私は，次の会社を選ぶ前に，まず自分の強みは何かを考えました。 日本では，「技術には強いが，プロジェクト・マネジメントには弱い」という人が多いといわれています。私はゼネラル・エレクトリック・インターナショナル（GE）で働いた4年半で，ITの知識とプロジェクト･マネジメント力を培ってきました。これに英語力を加えた3つが，私の強みになると思いました。 そしてもう一つ，私は自分のキャリアのテーマとして「ITを活用した経営手法を用い，会社を良くしていく」ことを強く意識するようになり，これを実現できることも次の職場を選ぶ上で

伊藤健太郎さんの書籍「プロジェクトはなぜ失敗するのか」（2003年10月発行）がヒットしたことに気をよくした筆者は、当然のことながら、続編の執筆依頼をするために伊藤さんの許を訪ねました。たしか、2004年の春ごろだった思います。前作の執筆中に、盛り込みたいテーマについて伊藤さんとディスカッションを何度も重ねていたので、次回作は、IT分野で仕事をしている理系人間が概して苦手とする、リーダーのヒューマンスキルでいきたい、ということはすんなり決まりました。 では、どんなタイトルを付けようか――「原稿が1行もできていないのに、タイトルを考えるなんておかしいのでは」と思われる読者もいらっしゃるでしょうが、実はそうでもありません。最初にタイトルありきで、中身は後から考える、というやり方でヒットした本は世の中にいくらでもあります。書籍編集部の編集会議で企画が議論されるとき、つねに話題になるのは「では、こ