TOP業界裏話注目ニュース徒然コメントリンク紹介
『外資系企業に住む住人の視点からIT業界の出来事を伝えます。』

誰もが考えていながら書いてこなかった、パワーポイント・ワード・エクセルのすべてをカバーする資料作成テクニックが1冊の本になりました。2014年8月20日に発売され、丸善等の大手書店・amazon等のオンライン書店の週間ベストテンにランクインしています。
※購入頂きました皆様、ありがとうございます。
http://www.amazon.co.jp/o/ASIN/4820748998/

siryou_cover.jpg
類書では紙面やボリュームの都合から実現していなかった「外資系コンサルが実践する資料作成の基本」を、本書は280ページの大ボリュームでまとめました。資料作成のプロでもある外資系コンサルタントが日々実践している、無駄なく、完成度の高い資料を作成するための王道のスキル、テクニックが網羅的に70項目にまとめられています。私が新人・中堅コンサル向けに教えている「あたりまえ」だけどなかなか実践できない大切な基本スキルやテクニックをステップごとに図解を交えてわかりやすく説明します。


【吉澤準特の本:累計7万部以上】
外資系コンサルの仕事を片づける技術』はロングセラーで重版多数
フレームワーク使いこなしブック』はロングセラーで重版多数
兄弟本の『ビジネス思考法使いこなしブック』はロングセラーで重版多数

【吉澤準特の過去配布レポート】
「外資系コンサルの仕事を片づける技術」特別抜粋版のダウンロード
「最新会議運営の基本と実践がよ〜くわかる小冊子」のダウンロード
できる人の9つの法則
コンサルタント直伝!コミュニケーションのプロになれる!


IT業界の裏話(まぐまぐ殿堂入りメルマガ)へ
メルマガ登録ならコチラ メルマガ解除ならコチラ
メールアドレス:
メールアドレス:



2011年08月28日

誰でも分かるRFPの基本:18項目で網羅的に作成
このエントリーを含むはてなブックマーク

情報システム部の存在意義は、ITサービスを通したユーザ利便性の向上にあります。ITサービスとは単一、もしくは複数のシステムによって提供されるものですから、新しいシステムを企画立案して運用に漕ぎつけるまでの流れは、情報システム部の主たる業務と言えるでしょう。

新しいシステムを構築するためには、企画段階で得た構想を要件レベルに具体化し、システム設計者に引き渡します。企画をした人間が設計・構築・テスト・リリースまで担当できるにこしたことはないのですが、上流工程を担当する人間はスキルセット上、高コスト(月単価150万円以上)であることがほとんどですし、そもそも社内でシステム実装スキルを有する人間を必要数確保できないという根本的な課題もあって、要件定義フェーズ以前と設計フェーズ以降では担当者が異なることが多いのが実情です。

そこで要件定義フェーズで整理したことを正確に設計フェーズにつなげるために用いられるのが RFP(Request For Proposal 提案要求書)です。RFPをうまく作成できるかどうかで、そのシステムの命運が決まると言っても過言ではありません。なぜなら、システムの実装内容だけでなく、自社とベンダーの責任関係を決めるインプットになる文書であり、RFPで書かれた内容に従ってベンダーは提案書と契約書を作成するからです。曖昧な表現や適切性に欠ける責任関係を記してしまえば、そのまま契約内容に跳ね返ってきます。

今回は「適切なRFPの作り方」というテーマで、「委託内容」と「契約スキーム」の2つに分けてRFPに必要とされる項目の記入方法を紹介します。あなたの会社にもRFPのひな形があるかもしれませんが、その内容が本当に妥当であるか、一度検証してみることをおすすめします。もし、足りない項目や考慮不足があるようでしたら、次の RFP作成までに修正しておきましょう。

ちなみに、RFPで示す各項目の内容は要件定義フェーズで全て決めている必要があります。RFPの項目をしっかり定義できていれば、それを記入するために必要な情報も明らかになります。つまり、要件定義フェーズで決めるべきことも自ずと決まってくるということです。

RFPで最初に定義する必要があるのは、委託内容に関する次の6点です。

委託範囲に関して定義すべき項目

  • 委託範囲
  • 納品成果物
  • 体制・役割分担
  • スケジュール
  • 前提条件
  • 応札要件

委託内容を確実に遂行するために、契約スキームに関する次の6点を定義します。

  • 契約形態
  • 契約変更/解除ルール
  • 契約有効期間
  • 想定外事象発生時の対応
  • 業務委託料、諸費用、支払方法
  • 成果物権利

最後に、RFPに対する提案の手続きを指定します。RFPを受領した後、ベンダーが提案書を提出するまでに行われる以下の点を明記します。

  • 提案書を提出する窓口
  • 納品方法
  • 納品期限
  • RFPに関する問い合わせ窓口
  • 提案受領後の審査プロセス
  • 審査結果の告知

特に納品方法では、紙媒体/電子媒体の数を指定します。容量を勘案し、提案書の一部(エグゼクティブサマリー/見積り明細など)を別途電子メールで受け取る方法もあります。受け取り側の都合に合わせて、納品期限は日にちだけでなく、時間まで厳密に指定しましょう。

ここまでに挙げた18点は、以下のリンク先で詳細説明をしています。はてブ500超の記事ですので、おそらく参考になるかと思います。興味のある方は御覧ください。

http://enterprisezine.jp/article/detail/3414

posted by 吉澤準特 at 23:53 | Comment(0) | TrackBack(0) | 注目記事

2011年08月08日

自己啓発本を買い漁る人にありがちな話
このエントリーを含むはてなブックマーク

Togetterで、自己啓発本をよく読んでいる人にありがちな話がまとめられているのですが、「たしかにあるかも」と思わせる内容がいくつかあったので、紹介します。
http://togetter.com/li/171474

  • 人に好かれる上手い話の聞き方という本を読んで、他人の話の聞き方にケチをつける。結果本を読む前より人に嫌われる。
  • 偉そうに成功者はこう言っていたとか誰彼構わずのたうちまわる。結果おまえそんなに偉そうな事言ってるくせに、なんにも成功してないじゃん、とか言われて逆ギレする。
  • 英語のテキストより英語学習のノウハウ本を選ぶ
  • どうすればよいか語れるけど、実はやったことがない
  • 自己啓発書を読むことが目的化する
  • 読んでも実生活にフィードバックされない
  • 片付け・整理本が何冊もあり部屋を占拠している
  • 読み慣れるとタイトルと装丁だけでどんなこと書いてるかパターンが分かってしまう
  • 目次を読めば8割がた理解できる
  • 毎年同じ周期で特集が組まれている雑誌に気付かない。

コレクターで終わる人にならないための方法、なんてテーマで本を書いたら受けますかね?

posted by 吉澤準特 at 02:51 | Comment(0) | TrackBack(0) | 徒然コメント

2011年08月07日

SEはいずれ消えゆく仕事か?
このエントリーを含むはてなブックマーク

この2ヶ月あまり、mixiのSEコミュニティであるトピックが賑わっていました。すでに2000以上のコメントが寄せられており、近年稀に見る炎上に陥っているのが、「SEは要らない子?」というトピックです。

その1
http://mixi.jp/view_bbs.pl?id=62523671&comm_id=8128
その2
http://mixi.jp/view_bbs.pl?id=63436046&comm_id=8128
その3
http://mixi.jp/view_bbs.pl?id=63872589&comm_id=8128

この過激なタイトルのトピックを投稿したのは外資系コンサルファーム所属のコンサルタントであり、いわゆる上から目線が何人かのコミュニティメンバーの逆鱗に触れ、大炎上していました。

トピック内容を要約すると以下のようになります。

「SEは減っている。上流工程からはコンサル、下流工程からはプログラマが職域を広げており、SEの領分は侵食されつつある。これについてSEが生き残るための意見を聞かせて欲しい」

最初はコメント投稿者の個別意見に対して真摯に回答していたトピック主でしたが、投稿数が数百を数えるところからだんだん直接的な表現を用いるようになり、的外れなコメントには容赦無い否定を示すに至ります。

例えば、

・SEは顧客の要望と実装をつなげる橋渡しだから、なくなる訳がない。
・SEが減っているというソースを示せ。
・SEは時代に応じて役割を変えていく。今と同じ形のSEは減るだろうが、別の形に変わってさらに守備範囲を広げるはず。
・むしろコンサルの職域を侵食するSEもいるわけで、コンサルこそ消えゆく存在。

といった意見についてのトピック主の回答は、

「思考停止のSEは相手にしない」
「今のSEの携帯からどう変化すべきかを考えてほしい」
「今の職域のままサラリーが下がったら、生き残っているとは言い難い」

という具合であり、反論する形で議論に参加したどこぞのCTOに対しても、「大したことないな」とバッサリ切り捨てていました。

SEという職種に多くみられるクローズドな性格、「自分の意見は基本的に正しい」というキャラクター性を分かった上で、敢えて挑発的な問い掛けをしているトピック主は、自分のロジックには絶対の自信を持っているようですが、実はSEの性格に近いように思えます。

トピック主の主張の一つにあった「単価が下がったら生き残ったと言えない」という主張についても、自身が所属するコンサル業界全般で単価ダウンの傾向が進行している現状を知っての挑発であれば少々悪質ですし、知らなかったというなら、無知ゆえの愚かしい争いにしか思えません。

すでにトピックは3つめに達し、投稿数も2600を超えるくらいになって、ようやく落ち着きを取り戻したように見えますが、実際には、トピック主を無視して独自の議論を続けるグループと、自分の意にそぐわないコメントには無視か茶々入れをするトピック主のコメントに大きく別れており、「なんだかなぁ」という気持ちにさせました。

私自身が全てのコメントに目を通して持った考えは、結局みんな似たようなことを思っているようだけど、相手の言葉の定義や発言の前提を自分勝手に補足してしてしまうから、諍いが起きている、というところですね。バベルの塔みたいな話。

誤解を恐れずに要約すると、

『(ユーザー)→(コンサル)→(SE)
→(プログラマ)→(ツールによる自動実装)→(システム)

という流れのなかで、それぞれの境界が曖昧になりつつあるため、SEに限らず、コンサルもプログラマも業務領域が変化しつつある。

この変化を感じ取り、自己成長を怠らない人間を目指そう』

というところでしょうか。細かい話は前述したリンク先を読み込んでみて下さい。瑣末な議論も多いですが、トピックの流れを感じ取るのは面白いかと思います。


最後に、私からはこの言葉をトピックの皆さんに送りたいと思います。

    竜馬は議論しない。

    議論などは、よほど重大なときでないかぎり
    してはならぬといいきかせている。

    もし議論に勝ったとせよ、
    相手の名誉をうばうだけのことである。

    通常、人間は議論に負けても
    自分の所論や生き方は変えぬ生きものだし、
    負けたあと持つのは負けた恨みだけである

異論のある方もいると思いますが、
そういう人に対しても私はこの考え方で臨みたいです。

posted by 吉澤準特 at 11:31 | Comment(0) | TrackBack(0) | 業界裏話

2011年08月04日

Plan-CheckとDo-Actionの違いが分からない人へ
このエントリーを含むはてなブックマーク

PDCAと聞いて「何ですか、それ」と問い返す人はいないというくらいには知られている品質改善プロセスのフレームワークについて、本当はよく理解せずに使っている人は意外に多いかも知れません。

例えばITの世界では、サービスマネジメントのデファクトスタンダードであるITILによって、PDCAという継続的改善活動は身近なものになっていますが、最初に改善活動の計画を立てたものの、そこから先は目先の改善に終始してしまっているケースが散見されます。

しかし、PDCAサイクルを本当に分かっているなら、「長期的な計画→実行」と「短期的な計画→実行」を明確に使い分け、長期的な改善の方向性に沿って短期的な改善が行われていることを定期的に確認するタイミングを設定すべきです。

言い換えると、「考える系」のPlan-Check、「行動する系」のDo-Actionを混同することなく使い分けることが、PDCAサイクルを有効機能させる重要要因になるということです。


翻って、皆さんの周りで行われている定例ミーティングでどんな改善活動が行われているを思い返してみてください。タスクフォースや分科会を立ち上げて、直近の改善計画を立てたものの、それを定量検証する術もなく、漫然と週次や月次の実施状況確認に臨んでいませんか?

もしそうであれば、その改善活動をもっと効果的にする術を採用してみませんか。難しい話ではありません。やるべきことはとてもシンプル。次の3点だけを意識して下さい。

#1. 長期的(半期・年次)における改善目標を決める
→長期計画(Plan)と実施要領(Do)を決めます。
できるだけ数値で測れる目標にしましょう。

#2. それを満たすための短期的(週次・月次)な検証タイミングを設ける
→各タイミングで達成すべき小目標を定義した上で、
進捗状況確認(Check)と遅延解消方法(Action)を都度決めます。

#3. 最初の長期計画の結果を踏まえて次の長期計画を立案する


PDCAサイクルをさらに確実に成功させるには、数値目標としてKPIを設定することや、実施要領の具体化でIPO(インプット・プロセス・アウトプット)を定めるなど、ビジネスフレームワークを複合させるのが良いです。

気になる方は、拙著、「フレームワーク使いこなしブック」をご覧になると、もう少し具体的なイメージを持つことができると思います。

『フレームワーク使いこなしブック』(JMAM)
http://www.amazon.co.jp/dp/4820746626/

他にも30以上のビジネスフレームワークをカタログ的に取りまとめているので、ひと通り目を通すことで、今まで気づかなかった切り口から、さらに有効な改善取り組みを提案できるようになれるかもしれません。

お陰さまで皆様の好評を頂き、すでに第5刷に達しました。本屋の立ち読みやAmazonの中身検索でチラ見して頂き、興味を持って下さった方はお手元においてもらえると大変嬉しいです。

posted by 吉澤準特 at 19:01 | Comment(0) | TrackBack(0) | 徒然コメント





【IT業界の裏話】過去コラム(No.1-337)
[ TOP ]IT業界の裏話

▼ IT業界の人々
「内製率を高めたい」のに「世界...
人の話を聞かないIT技術者の...
コンサルを目指す学生との対話...
IT業界、悪魔の辞典『ヒト編』
改善は「自分が楽をすること...
近くて遠きもの、プログラ...
IT企業が求めるプログラマ...
ITプロの3割が機密情報に...
10年働くソルジャーが欲しい...
PGとSEの仕事の面白みは何...
メールをすぐ返信する人、しな...
├ ITコンサルタントになる方法
我がコードは我流。我流は無...
欧米人がグリーンITに積極的...
実は変化など望んでいないエ...
├ 実はコミュニケーション能力に...
IT業界人は自分のドッグフード...
IT業界を不人気にした重鎮...
IT業界の変わった人々
電子メール禁止!ゼロメール...
名言集−運用フェーズ−
システム開発における名言集
失敗から学ぶ人、学ばない人...
SEに多いコーチングタイプは...
あなたのコーチングタイプは...
ITエンジニアの年収公開サ...
CTCは何の略?
会議は踊る、されど進まず...
繰り返し使われるメールアド...
遅刻しそうなので面接受け...
社内SEが人気を集めている...
サポートセンターの悪夢
IT業界に向いていない人
日本の夏、熱暴走の夏
客前で後ろから刺される
システム障害でクビが飛ぶ人
病欠って何ですか?
昼休みって何ですか?
Windowsに弱いIT技術者2
Windowsに弱いIT技術者
エンジニアは音を伸ばさない
話しにくい人
転職する人しない人
サイコロ一振りで給料を決め...
コンサルがお絵描き好きなの...
コンサルの報酬額って?
ITコンサルとSEの違い
SEのITリテラシ
公私のケジメ

▼ 仕事のやり方
客先で自分のPCが差し押さえられ...
「闇リリース」は善意でやっても...
新人のための7つのワークハック...
仕事の質を落とさないメソドロ...
組織が150人を超えると仕事の質...
世界最大のコンサル会社が最低...
IT業界、悪魔の辞典『SI編』
パワーポイントを紙芝居に貶め...
日本と米国の違い:ベンダーサ...
定時退社日に罪悪感を感じるIT...
ストレス厳しい職場を生き抜く...
おまえが呼ぶな、俺が呼ぶ「ハ...
ITプロレタリアートは多機能工...
図表をリッチにする5つのシン...
セクシーパワーポイント道
エンジニア御用達のIT誌
メールコミュニケーションを200.
├ ニッポン・エンジニア・レボリュ...
ITのプロって何ですか?
クールビズにも限界、冷房28...
真夏に長袖!なのに裸より涼...
測定しにくいものを測定する方...
山田さんの使いやすいシス...
SEの品格
コンサルの品格
ダメシステムはひとまず葬れ
眠気対策アイテムを考える
長篠メソッド
ITサポートがユーザーに教え...
資格の価値
出張先のホテルでインターネ...
お口の恋人
絶対に潰れない会社の悩み
エアエッジが必要になる理由
ハイプ曲線+キャズム理論
ユンケル黄帝液とスーパー黄...
一貫性が信用を生む
デビルズ・アドボケイト
落とし所を見定める
クライアントの良き友人たれ
キャンペーンでたたみかける
比較で暴利をごまかす
権威を活用する
ヒヤリハットの考え方
密談のタバコ部屋
「えいや」で決まる、魔法の言葉
海外テレカンの心得
IT業界でうまく生きていくコツ
ポンチ絵
仕事と作業の違い
上司に背を向けると怒られる?
ロケットスタートのススメ
人の考えを利用すべし
「見える」化
仕事の範囲
ワークシートのススメ
フローチャートの基本
仕事のやり方、片付け方
もんたメソッド
高橋メソッド
作業時間の見積り方
仁義を切る
アクションプラン
ミーティングと議事録
ベンダー選定の基準
ITと数学
レスポンシビリティとアカウンタ..
仕事の密度
リクルーティング
ドキュメントプロパティ
クライアントが納得する答え

▼ 仕事の環境
こんなのITのプロらしい仕事...
デスマーチに陥るお決まりパ...
外資が休暇を大切にする”真”...
HTMLメールとテキストメール...
ペーパーレス化が紙の無駄...
携帯電話のSDカードも禁止す...
人々は安定性と安全性の両方...
カタカナ会社はあやしい会社?
サービスリリースの落とし穴
IT業界の職場環境
IT業界の労働環境悪化は...
英語の必要性
正月出勤
年末年始の過ごし方
止められないコンピュータ
動かないコンピュータ
リリース直前の危機

▼ IT業界の動向
クラウドプレイヤーの名言集...
ネット史上最大の惨事、マイクロ...
ベンダー努力を台無しにするIFRS...
電子政府構想は無駄遣いの温床...
NASAのレポートがIT業界に与える...
中国当局によるプログラム盗用は...
コンサルもSIerもいらない内製...
中国のソースコード強制開示制度...
IBMは当て馬、Oracleが演出する...
PWCCが復活、ベリングポイントを...
IBMに喰われたSun、IT業界に訪れ...
ヤフー、自社データセンター所有...
自分が決めたルールに違反するGo...
SOAは死んだ
データセンターを巡るIT業界三...
├ リーマン破綻にみる米国証券業界...
IT史に輝く「すべったテクノロジ...
冷却を必要としない常温データ...
過去のIT業界10大予測を振り...
├ エンジニアよ、大志を抱け!
├ 黒箱襲来!コンテナがDC...
IT業界進化論: SIer 2.0を目...
IT業界がダメな理由を学生の...
IT業界温室効果の1/4はDC...
新生ニコニコ動画、ニコンド...
システム前線異常アリ!ゆう...
ニコニコ動画は文化の架け橋
Web2.0の向こう側〜サードリ...
セカンドライフだけで宣伝の...
国家戦争にも利用されるDDo...
DoCoMo2.0に見る情報格差...
DoCoMo2.0とWeb2.0
ITIL準拠という幻想
システム障害訓練の日を制...
WAONとnanacoが提携したい...
NTT東西の野望〜光回線編...
mixi招待制の綻び
Vistaが売れない理由
独自仕様に走り過ぎて泣き...
米国事情から見る日本のIT...
MVCからAjaxへ
外字ってなんですか?
Sunがx86サーバにIntel採用...
やりたい放題バッドウェア!
アウトソーシングという名の幻...
ソフトバンクモバイル、MNP停...
やっぱり止まったソフトバンク...
あらゆる意味でやり過ぎの...
経営者不在の日本版SOX法...
働いてみたいIT企業ランキン...
サーバの進化がデータセン...
_システム運用にRSSを活用
電力線通信が認可される日...
携帯メールはSSL通信よりも...
経営者不在の日本版SOX法...
Microsoftがサイトリニューア...
停電に脆弱なシステム
システムは誰のためにある...
ITILで運用が楽になる?
進化するコールセンター
Vacademy
IT業界にロングテールはある...
時間をお金で買う
あなたの猫はコンピュータウ...
個人情報保護法の範囲
あなたvsプロジェクト構成管理
ドラマ24にみるシステム最前...
次世代トレンドと枯れた...
日本版SOX法の施行に向け...
新しいWindowsはWeb決済...
地震に強いシステムをお持...
IT Doesn't Matter
SOAと分散コンピューティン...
各社で定義が異なるESB
おサイフケータイに見...(2/2)
おサイフケータイに見...(1/2)
子会社のシマを荒らす親会社
アインシュタインに学ぶソフ...
公職選挙法とインターネット
マイレージ負債
インターネットの舞台裏:海底...
ゼロ・クライアント
サーバのトレンド
外資系パッケージベンダー

▼ 業界の構造
対極にあるIT業界とコンビニ業...
IT業界は成果報酬型のサービス...
特定ベンダー以外をふるい落と...
欧米人なら爆笑するレベルと...
IT業界が詐欺師集団と言われる...
IT業界の格差社会、年収200...
├ 新基準導入でデスマーチがな...
公式では言えないニコニコ動...
├ コンサルとアプリ開発者、格差...
システム運用はIT業界の最下...
テストフェーズの呼び方は千...
2000年問題再来!?サマー..
減り続ける正社員の割合
労働局が偽装請負の抜け道...
会社貸与のPCは何年償却?
ITIL Foundationを2万円で買..
IT製品もイメージ重視?
お試しできない製品は売れない
IT業界は無免許制
どんぶり勘定
標準価格と提供価格
ソフトウェアライセンス
社外秘の秘密度合
偽装請負 
システム開発の流れ7 テス...
システム開発の流れ6 開発...
├ システム開発の流れ5 開発...
システム開発の流れ4
システム開発の流れ3
システム開発の流れ2
システム開発の流れ1
IT業界の構造

▼ 業界ランキング
SIerランキング2005
コンサルランキング2005

▼ その他
「幣社」という表現は相手を見下...
コミュニケーション力の不足は...
聞く耳を持たないYahooニュース...
黒デスクトップ事件に見る中国...
ITコンサルから見たブラッディ...
違法ダウンロードでネット追放...
就職難民=不出来な学生とい...
モンスターペアレント、会社襲来
あえて言おう、Yahooの掲示...
プログラマ向きなカフェをオー..
├ Japan Brog Award 2008を..
日立さん、IT大喜利をもう一度
インターネット上の信頼できる...
IT業界でありそうな迷惑勧誘...
倒産してもカネを要求する悪2...
倒産してもカネを要求する悪1...
├ 枯れた技術の水平思考で
├ ずさん極まりない環境保護ラ...
世界の奇妙な法律を集めた...
50万円のキーボード
洋楽を1曲10円で購入できる...
CNETとZDNetは同じ会社
情報の価値(情報商材)
コンパイル1回12時間の世界
楽天ポイント事件
楽天ポイント事件〜利用者...
楽天300ポイント付与で謝罪
ライブドア強制捜査
└ ネットワークベンダー