第6回 案件分析を行動につなげる「Goal POST」で計画立案
競合戦略や顧客内の政治力学を分析し、不足する情報や、競合に対して取るべき手は明確になった。それでも多くの商談で受注に失敗してしまうのは、せっかく分析した案件情報や競合戦略が、日々の営業活動にうまく生かされていないからです。確実に勝率向上につなげるための行動計画の立案方法を紹介します。 前回まで、商談の勝率向上をテーマに「案件アセスメント」、「競合戦略」、「顧客内政治力学」という順番で、案件の分析手法や商談を有利に進めるための戦略の考え方を紹介してきました。 勝率向上のための商談戦略の立案は、その過程を「インプット（収集すべき情報）」、「プロセス（分析の切り口）」、「アウトプット（行動計画への落とし込み）」の三つに分類できます。そしてこれら三つが効果的に連携して初めて価値を持ちます。いくら案件の分析が正しくても、顧客に対する実際の営業活動の一つひとつが的外れだとすれば、勝率向上はおぼつきませ
データセンターから“場所貸し”がなくなる日
「データセンター事業者から電気料金を追加で請求されるケースが増えて困っている」。こんな話を，ある大手製造業の情報システム部門長から聞いた。どうやらこの企業が預けているサーバーやストレージなどの機器が，サービス事業者が想定していた以上の電力を消費したためのようだ。 データセンターが電力不足に陥り，ラックのスペースは空いているのにサービスを提供できないケースがあるという話は，去年あたりから何度か耳にした覚えがあった。そこで実際に，いくつかのデータセンター事業者に話を聞いてみると，電力事情はより深刻になっていることがわかった。 その度合いは，従来のデータセンター・サービスの考え方を一変させかねないと思われるほど高いように感じた。筆者は，このままではコロケーション・サービスと呼ばれる，いわゆる「場所貸し」のサービスを提供するのが困難になるのではないかと懸念している。消費電力をコントロールするのが難
最後までやり抜く気迫あるSIerを選ぶ 「何でもできます」は最低の提案だ
ソリューションプロバイダには、「自分たちが最後までシステムを作り上げるんだ」という気迫と責任感をもっと見せてほしいと、いつも感じている。 現在のITシステムはホストコンピュータの時代と異なり、さまざまな機器やツールが絡み合う複雑な構造になっている。すぐ下請けやツールの開発元のせいにするようなソリューションプロバイダと組めば、システム開発が失敗するのは目に見えている。かといって、異なるメーカーのソフトやハードの特性を把握して、トラブルなくシステムを構築する作業は、ユーザー企業には負担が大きすぎる。ソリューションプロバイダには複数の工事業者を一手に束ねて建設現場を仕切る、ゼネコンの現場監督のような手綱さばきを期待しているのだ。 新たに付き合うソリューションプロバイダもこうした観点で評価する。過去の実績を考慮するのはもちろんだが、当社の開発スタッフと顔を突き合わせた状態で、彼らができることだけで
ビジネス上の利益を示せなければ、SOAへの失望感が広がる
SOA（サービス指向アーキテクチャ）の実行基盤を提供する米ビトリア・テクノロジーのデイル・キーンCTO（最高技術責任者）兼共同創業者は「SOAに対する期待は失望へと変わりつつある」と指摘する。この状況を変えるためには、SOAを採用することでビジネス上の利益をいかに拡大できるかを明解に示すべきだと訴える。（聞き手は矢口 竜太郎） SOAに対する失望が広がっているというのはショッキングな話だ。 米国では確実に失望感が広がりつつある。システムでSOAを実現しても、どういったビジネス上の利益があるのか分かりにくいことが理由だ。 SOA自体はITのインフラに近い部分の技術に過ぎない。「変化に強いシステム」といったことだけでは、CEO（最高経営責任者）を納得させることは難しい。業績に直結するメリットが求められている。 SOAは一時のバズワードとして消えていくのか。 企業が競争力を高めるためにはSOAが
ソフトウエアの「専門化」は進化か，単なる問題のすり替えか
筆者は先に，「Intelligent Application Gateway (IAG) 2007」を担当しているMicrosoftの「Security, Access, and Solutions Division（セキュリティ，アクセス，ソリューション部門）」による非常に長い説明会に参加した。IAG 2007は，Microsoftが2006年に買収したWhale Communications技術をベースとするリモート・アプリケーション・アクセス・アプライアンスである。 IAG 2007はMicrosoftの名の下で販売される，このソフトウエアの最初のバージョンだ。今後のバージョンには「Microsoft Forefront」というブランドが誇らしげに記されて，おそらく今よりもMicrosoft色が濃くなるだろう。前ふりが長くなったが，今回は，企業におけるソフトウエアが「専門化（spec
日本HPがMercury製テスト・ツールの新版を出荷
日本ヒューレット・パッカード（日本HP）は，米Hewlett-Packardが買収した米Mercury Interactive製テスト・ツールの新版を，9月3日から順次出荷する。機能テスト・スイートの新版「Quality Center 9.2」3製品と，負荷テスト・スイートの新版「Performance Center 9.0」2製品である。価格は，Quality Centerの基盤ソフト「TestDirector for Quality Center 9.2」が504万円から，Performance Centerの基盤ソフト「LoadRunner software 9.0」が789万6000円から（いずれも税込み，以下同）。 Quality Centerは，情報システムのテスト工程において，ソフトウエアの品質を高めるための仕組みとノウハウをソフトウエアの形態で提供するもの。開発プロジェクト
第3回 位置付けが不明確では評価指標を策定できない
システム子会社に対する親会社の期待は「コストセンター」「サービスセンター」「プロフィットセンター」などになるが、現実には様々な思惑が重なり、あいまいな場合も多い。まずグループ内での役割や位置付けを明確にしなければ、システム子会社の評価指標は策定できない。 前回はシステム子会社の「外販率の向上と収益率の向上」の関係に焦点を当てて、親子の理想的なパターンと危惧（きぐ）されるパターンを説明した。換言すれば、システム子会社の財務状況という視点からの考察であった。今回は親子の関係をグループマネジメントという視点から考察する。 一般的にシステム子会社も含めた子会社を親会社から見たときの期待（ミッション）は、以下の3つに分類できる。 （1）便利なコストセンター：グループ会社の要求には、廉価で上質なサービスで応えてほしい （2）戦略的なサービスセンター：グループの競争力を高めるために、新しい技術も含めてコ
「新規開発」が3カ月連続で 4％以上の予算未消化，「再構築」も4カ月連続で未消化幅が拡大
2007年6月の企業・組織の「IT予算執行率INDEX（平均の予算執行率）」をシステムの分野別に見たところ，「新規開発」「再構築」「運用保守」の予算執行率がいずれも前回2007年6月調査（2007年5月実績）より低下。特に「新規開発」の予算執行率INDEXは前々回2007年5月調査（2007年4月実績）から3カ月連続で -4％ラインを下回っている。「再構築」の予算執行率も2007年3月調査（2007年2月実績）の -1.6％以後4カ月連続で低下している。「ハード購入」「ハード購入」の予算執行率もそれぞれ前回2007年6月調査（2007年5月実績）より2ポイント弱下がった。 一方，業務アプリケーション分野別を見ると，前回2007年6月調査（2007年5月実績）では8分野（その他の業務分野を除く）中6分野が約5％～約7％の大幅な未達ゾーンに沈んでいたが，今回は「人事・給与」「物流」「会計」「C
[メソドロジ編]納品するドキュメントだけ残せばいいと思ってはいけない
「ドキュメントは，納品する最新バージョンのドキュメントだけ残せばいい」――。あなたは，そう考えてはいないだろうか。 確かに，2001年のアジャイル開発宣言には，「ドキュメントよりも動作するソフトウエアを重視する」という項目がある。この宣言を真に受けているわけではないだろうが，「委託先に納品する最終ドキュメントだけを残し，そこに至るバージョンまでを維持・管理している開発現場は非常に少ない」（日本IBM 東京基礎研究所 IBMディスティングイッシュト・エンジニア 榊原彰氏）。 多くの開発現場では，ソースコードの構成管理は行っている。しかし，ドキュメントの構成管理までは行っていないことが多い。同じことは，テスト・シナリオやテスト・データにも当てはまる。プロジェクトが短納期化するなか，ドキュメントやテストの構成管理まで実施する余裕がないからだろう。 だが，アーキテクチャ説明書や議事録など納品しない
SaaSの提案だけで思考を止めるな 具体的な移行や運用の方法を示せ
2010年をメドにIBMメインフレームを撤廃するため、中核である販売・物流システムの再構築プロジェクトを立ち上げた。システム運用コストの削減や保守効率を高めるためだが、狙いはそれだけではない。これを機に、2007年問題に対応したい。ベテランのシステム部員が引退する前に、販売・物流システムを作るための勘所を、中堅・若手部員に引き継いでいく。 新システムの具体的な構築方法は、これから決める。市販の業務パッケージを適用するのか、自社で独自開発するのか、SaaS（ソフトウエア・アズ・ア・サービス）方式を採用するのかなど、いろいろな面から新システムの在るべき姿を探る。この過程では、これまでの付き合いがあるかどうかにこだわらず、さまざまなITベンダーの営業担当者から提案を募るつもりだ。 「構築費用を抑えるには業務パッケージをベースにアドオンしましょう」「今後の主流は、SaaS方式を採用してシステム運用
[設計編]ユースケースに詳細を書いてはいけない
機能要求を「ユースケース」（利用者＝アクターから見たシステムの利用場面）としてまとめ，それを基に分析設計することが一般化してきた。ところが「ビジネス・ルールを入れ込んだり，if～thenレベルのロジックまで書き込んだりと，誤った書き方をしている人が結構多い」と，日本を代表するITアーキテクトの1人，榊原彰氏（日本IBM 東京基礎研究所 IBMディスティングイッシュト・エンジニア）は指摘する。どんどん詳細化し，必要ない情報まで盛り込んでしまうのだ。 「詳細化しないと気が済まないのだろう。『分析麻痺（Analysis Paralysis）』と言える」と同氏。オブジェクト指向分析設計とプロジェクトの「見える化」を実践・推進するチェンジビジョンの平鍋健児氏（代表取締役）も同意見。「画面レイアウトなど情報量が多過ぎることが結構ある。ユースケースはシステムの目的なのに，ユースケース＝機能と考えるからそ
【続報】全面退任を決めたニイウスの末貞会長、「医療事業のASPで失敗」
ニイウスコーの末貞郁夫代表取締役会長は8月29日、全5人の取締役退任の理由について、決算会見の席上で説明した（関連記事）。午後8時から開催した会見の冒頭、末貞会長は「医療サービス事業からの完全撤退に伴い、特別損失を計上し40億円の債務超過に陥る。投資家や関係先にご迷惑をおかけした」と厳しい表情で説明し始めた（写真）。 ニイウスコーは、企業の合併・買収やデータセンターへの投資を通して、約3年前から医療機関の運営を支える「医療情報システム」のASPサービス事業を拡大してきた。しかし、目論見通りにはいかず、「このまま続けると赤字が拡大するため、全面撤退を決断した」（末貞会長）。 誤算は大きく2つあった。1つは「当初はシステムを買い取る需要が高くこの分野でエンジョイしてきたが、この1年間で医療機関がコスト削減を進めたため売れなくなった」（末貞会長）ということ。2つめはそれを補うために舵を切ったAS
【速報】ニイウス コーの全取締役が退任、新CEOを野村総研から招聘
ニイウスコーは8月29日、末貞郁夫代表取締役会長を含む全取締役が退任すると発表した。医療事業の撤退などから、「07年6月期の連結決算で多額の特別損失を計上したことの責任を取った」（広報室）という。末貞氏は今後、ニイウスの経営には関わらない。 新しい社長には野村総合研究所の大野健取締役が就任する予定で、会長職は置かない。9月末の定時株主総会で割方美奈子現社長が退任し、10月下旬の臨時株主総会で現会長の末貞氏が退任する見通し。 ニイウスは07年6月期の連結決算で、603億円の売り上げに対して291億円の特別損失を計上した。同期の純利益は302億円の赤字となり、純資産が約40億円のマイナスとなる。そのため投資会社であるロングリーチグループなどに第三者割り当てを実施する考え。10月末の臨時株主総会で認められると、「ロングリーチグループが発行済み株式の67％を握る筆頭株主となる」という。
Part1 科学的な進ちょく管理が不可避に
要件があいまいで手戻りが発生した，バグ修正のために予想以上に工数がかかった――。進ちょくの遅れに直結するリスクが多様化するにつれて，納期や予算を順守できないプロジェクトが増えている。今こそ「EVM」を導入し，進ちょく状況を“可視化”するべきだ。 富士通は「受注額1億円以上」のすべてのプロジェクトを対象に「EVM（Earned Value Management）」と呼ぶ進ちょく管理手法の利用を義務付けている。EVMで算出した進ちょく率をベースに売り上げと利益を月単位で管理し，採算が悪化しているプロジェクトの早期発見，迅速な対応で赤字の回避につなげるのが狙いである。 EVMとは，プロジェクトで実施すべき作業を細かく分割し，それぞれに定義した予定コスト（単位は金額または工数）に基づいて，プロジェクト全体のスケジュールの遅れやコストの超過を“可視化”する進ちょく管理手法のことだ。 大規模プロジェク
「若い技術者は顧客の業務を知らない」、その俗説と本当の理由
「最近の若い技術者は、びっくりするほどお客の業務を知らない」。そんな話を年配の技術者から何度か聞いたことがある。その理由として必ず挙げられるのが、「システムがオープン系に移行したため、多くの技術者は最新の技術について行くことに精一杯で、業務を理解する余裕がない」との“俗説”。私もそんなもんだろうと同意していたが、どこか「ちょっとヘン」との違和感が残っていた。 そもそも最新の技術について行くことに精一杯の技術者って、どんな人だろう。私はこれまで、プロを自認する技術者からそんな泣き言を聞いたことがない。年配の技術者だって、もし今、Javaあたりでシステム開発をバリバリやっていれば、嬉々として最新の技術に取り組んでいることだろう。 きっとプロとしては疑問符がつく技術者が大勢いるのだろうが、こういう人たちは今も昔も、顧客の業務をまともに理解してなんかいない。昔の方が多少は理解していたのかもしれない
ベテランだから扱いにくい？
「私のことが気に入らないのですか。もう来るなということですか。」ある朝突然、プロジェクトメンバーである協力会社の方から言われて、面食らいました。急に何を言い出すのかと戸惑いながらも、よくよく考えてみると思い当たる節があります。それにしても・・・ こんな話を、あるプロジェクトマネージャからお聞きしました。協力会社の方であるＰさんには、プログラマーとしてこのプロジェクトに参画していただいているそうです。ベテランのＰさんは、その分野の技術に詳しく、厳しいスケジュールのなかでも黙々と真面目に仕事をしてくださっていました。 １週間程前のこと。このプロジェクトで決めている標準とは異なる方法で、Ｐさんが作業をしておられたので、標準的な方法でしていただくよう、メンバーからお願いをしました。ところがＰさんは「自分はこれまでずっとこの方法でやってきたし、誰からも文句を言われたことはない！」と声を荒げ、その日は
カンバン方式でプロジェクトを“見える化”するツールの新版，Tracチケット連携などを追加
チェンジビジョンは，Java統合開発環境Eclipseをベースとしたリッチ・クライアント環境であるEclipse RCP（Rich Client Platform）上で実現したプロジェクト管理ツールの新版「TRICHORD 1.2」を，8月7日にダウンロード出荷した。プロジェクトの“見える化”に注目した製品である。価格は，1ユーザー2万1000円。 TRICHORD 1.2は，Eclipse RCPベースのプロジェクト管理ツール。特徴は，トヨタ自動車の生産工場で採用されている“カンバン方式”を用い，業務プロジェクトの進ちょく状況をプロジェクト参加メンバーで共有できるようにしていること。カンバンとは補充部品の数などを記した票のことを指しており，「今まさに何をやるべきか」を示すことによってJIT（Just In Time）の生産や行動を実現する手法である。 TRICHORDのカンバンは，（1）
リスクを告げてこそ信頼が生まれる---キリンホールディングス 佐藤 一博氏
当社の場合、システム子会社であるキリンビジネスシステムがグループ全体の情報化を推進しているが、現在多忙を極めている。グループとしてのITインフラの在り方やセキュリティ対策、内部統制の仕組み作り、M&A（企業の合併・買収）に伴うシステム整備など、複数テーマを同時並行で進めているからだ。これらのプロジェクトを実践するには、ITベンダーの支援が欠かせない。 こうした状況は今後も続く。ITベンダーには、性格の異なる複数の情報化関連プロジェクトに目配りし、それを取りまとめる能力を求めたい。 ベンダーマネジメントはキリンビジネスシステムの仕事だが、やはりITのプロの力は必要だ。失敗しないように目の前のシステム構築プロジェクトに全身全霊をかける。これ自体を否定するつもりはないが、我々はそれしかできない会社をパートナーとして認めるつもりはない。 複数の課題を切り盛りするというソリューションを提供できてこそ
ITシステムから見た年金問題考察（3）システム問題へのすり替えは策謀である：戸並隆のSEは中流を目指せ！：ITpro
社会保険庁のシステムは，長年のメンテナンスや改良維持のため，ソースコードはスパゲッティ状態。改造改築の温泉旅館の曲がりくねった渡り廊下状態になっているはずです。メンテナンスコストも幾何級数的にはね上がっているでしょう。「年金記録問題検証委員会（年金検証委）」の中間報告では，使い勝手の悪い旧式システムを更改せずに使ってきた，と業者の責任にしていますが。とんでもない！ 業者（ITベンダーやSE）には再構築したい！という強い気持ちがあるはずです。 年金記録の紛失問題を，システムの問題にすり替えることは断じて許せません。NTTデータも，我々IT側を代表し，主張すべきは主張して欲しい。政府・自民党はITを“犯人”として前面に押し出すことで，国民やメディア，野党の目をそらし欺こうとする魂胆のようです。 ITは経営システムを実現するためのツールに過ぎません。コンピュータの黎明期から40年経った今でも，「
ソフトウエア開発に役立つマインドマップ
ソフトウエア開発は，コーディングやテストばかりではありません。顧客との打ち合わせやエンドユーザーとの会話，さらには開発者同士のミーティング，ブレインストーミング，仕様の構想といった「アイデア」と「コミュニケーション」に本質がある活動がたくさん含まれています。マインドマップは，このような柔らかな人間活動をビジュアルにうったえることでサポートする発想法であり図解法です。この連載記事では，話題の書籍『ソフトウエア開発に役立つマインドマップ』（右図）から，すぐに使えるマインドマップの利用法を抜粋してお伝えします。 目次 ・第1回 マインドマップって何？ --- 注目技術の理由と特徴 ・第2回 議事録と会議ナビ --- チームの合意をすばやく作れ！ ・第3回 ブレインストーミング --- 広がるアイディアをつかまえろ！ ・第4回 ロジカルシンキング --- 概念を分類・整理しよう！ ・第5回 まとめ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
