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

以前好評いただいた『資料作成の基本』から図解作成だけにテーマを絞って抽出した本が2018年6月23日に発売となります。 https://www.amazon.co.jp/dp/4799106511

図解作成の基本
本書は「資料」ではなく「図解」の作成に特化しています。図解は、論理的にわかりやすい内容、感覚的に心地よい見た目が好まれます。図形のカタチ(フォーム)と配置(ポジション)で生み出される「要素のバランス」、色の使い分け(カラー)によって醸し出される「コンテンツの強弱」です。それらを「図解キューブ」というモデルで表し、その実践例をチャートとグラフの「図解パターン」として体系的・網羅的に整理しました。これらを「エグゼクティブ図解術」と私は呼んでいます。本書を図解作成のハンドブックとして、ぜひ使ってみてください。


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

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


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



2017年03月30日

【IT業界名言集】我がコードは我流。我流は無形。故に誰にも読めぬ。【10年進歩なし】
このエントリーを含むはてなブックマーク

10年近く前にまとめたIT業界の名言集を久々に読み返したところ、今見ても新鮮味があるというか、IT業界の変わらなさを実感し、ちょっと残念な気持ちになりました。この10年間でIT業界は果たして進歩してきたのでしょうか。2017年版の要素も追加して、IT業界迷言集を紹介します。

【その1】-------------------------------------
「バグは夜更け過ぎに 仕様に変わるだろう」

何をやってもバグが解消せず、終電がなくなってもまだ直らない。こうなったら「仕様」と言い切るしか術は無い・・・そんな悲しい状況が目に浮かびます。私はDBコネクションプールで同じ憂き目を味わいかけました。

この迷言、10年経ってもまったく色褪せません。しかし、2019年頃と目される民法改正でシステム開発契約における「瑕疵担保責任」の考え方がさらに厳しくなります。もう仕様と言い張ることもできなくなりそうです。

【その2】-------------------------------------
「1年に1回起こる可能性が1%の問題なんて無視していい。俺は100年後はもう居ない」

総稼働時間で考えれば、100台同時に動かすと1年で問題発生ですね。ハードディスクの耐久性能で”100万時間稼動”(MTTF)という製品の考え方と同じ理屈です。この論理で押し切れるクライアントがいたら、逆にヤバいです。

2017年現在では、クラウド運用業者は同時に数千台のサーバーを動かしますし、GoogleやFacebook規模だと毎日数台のサーバーが不良で止まります。1万分の1の確率さえ「起こり得る事象」と捉えなければなりません。もっとも、ユーザーにフェイルオーバーを感じさせない技術も発展したため、フロント側からすると「止まらないシステム」に見えるものも増えました。

【その3】-------------------------------------
「営業が出した要件が全てだと思うな」

おいおい、身内を欺いてどうするんですか。孔明の罠なんて誰も求めてませんから、さっさと仕様を聞き出してきてください。

この迷言、10年経っても変わりません。営業と現場は敵同士のところはまだまだ多いです。DevOpsで開発vs運用の戦いが収まりつつあるなら、「SalesDevOps」まで踏み込んでしまえばいいのに。

【その4】-------------------------------------
「所詮ボクらは農耕民族。誰かが開墾した畑を守るだけなんです」

運用チームにこんなことを言われると本気で泣けてしまいます。そんなに卑屈にならないで下さい。どこの業務ユーザに苛められたんですか?あなたのチームがいるからみんな仕事ができるんですから、どうか自信を持ってください。

2017年、DevOpsが徐々に世に広まり、DevがOpsの仕事を巻き取る(奪う)ようになってきました。運用チームに狩猟民族の血を入れる必要はありませんが、好奇心旺盛で開発に首を突っ込んでくるプロモーターの血は必要でしょうね。畑を守るだけの運用チームに居場所はなくなりつつあります。

【その5】-------------------------------------
「画面は青かった・・・ 」

ああ・・・哀れ、ブルースクリーンを見てしまいましたか。ダンプ情報が書かれているのに、一瞬で消えてしまうから内容を確認する間もないという冗談みたいな画面。なんのためにエラー情報吐いているんだぁ!!

2017年、ブルースクリーンを見ることはかなり減りました。オフィス製品がフリーズして作成中のファイルが失われてしまうことも、オートバックアップのおかげで減ってきたと思えます。

【その6】-------------------------------------
「論よりコード」

「UTSL(Use The Source, Luke)!」
コード至上主義の方と仕事をすると似たような話を聞きます。確かに一理ありますし、生産性も高いのですけど、官公庁の仕事でそんな無茶を言わないで下さい。

2017年、あれから10年でソースコードからの設計書自動作成技術はあまり発展していません。やはりまだまだ手動で仕様書は作らないとダメですね。もしワードで作るなら、「外資系コンサルのビジネス文書作成術」(東洋経済新報社)が役立ちますよ・・・

【その7】-------------------------------------
「我がコードは我流。我流は無形。故に誰にも読めぬ・・・」

論よりコードに似ているようで全然違います、コチラの方はコードの可読性が限りなく低い!一体誰に保守させるつもりでしょうか。我流で書けるのは分かりましたから、次はコメントの書き方やデザインパターンを学んで、可読性の高いコードをお願いします。

2017年、今でもこうしたコードを見かけます。開発費をケチられたといっても、保守できないレベルのコメントしか残していないというのは開発者の矜持に欠けますよ。

【その8】--------------------- ※「SEの格言・迷言・ことわざ集」引用
「いつまでもあると思うな保守のカネ」

2人月×12か月で積んでもらった保守費用なのに、わずか6か月で使い切るとはなんということでしょう。バグだらけのシステムを無理やりリリースしたばっかりに。この後半年間、どうやって過ごすつもりでしょう。

【その9】--------------------- ※同上
「嘘から出た受注」

IT業界は慢性的な人不足。それは昔から変わっていません。なのに、受注金額はなぜこんなにも低いのでしょう。裏を返せば、単価を高くしたら仕事をもらえないということ。だったらお断りする前提で高値入札しちゃいますよ、と勇んで出した提案書が通ってしまったとき、営業は青ざめるのです。やばい、空売りだ!その結果、頭数は10人しかいないのに20人分の働きをしなければならなくなることも。

しかし、2017年は働き方改革の影響で残業規制がすさまじいです。月残業が45時間を超えると指導が入りますから、130%以上働く月が続くとアウト。IT業界特有の働き方がこの機に改まることを願います。

【その10】--------------------- ※同上
「弘法、言語を選ばず」

一説によれば、15以上の言語を操れるレベルで一人前のプログラマーらしいです。Java、JavaScript、C、C++、C#、PHP、Python、Ruby、Objective-C、HTML5、CSS、Perl、Haskell、Go、COBOL、R、VBA…これだけできれば一人前か。そんな人いるんですかね?

【その11】--------------------- ※同上
「電話いそげ」

メールでコミュニケーションしたい気持ちはわからんでもないんですけど、そのメールを1通書くより先に電話を一本したほうがいいんじゃないでしょうか。そのメール、障害報告ですよね?

【その12】--------------------- ※同上
「転ばぬ先のテスト」

それな。テストドリブンでもテストファーストでもどっちでもいいですから、テストしてないものを本番環境で動かすのはやめましょう。やってないテストコンディションを「やった」と言い張るのも、1回目のテストエラーは全部ノーカウントで、2回目からトラッキングするとかいうのも怖いからやめてあげてください。運用保守チームが死にます。

【その13】--------------------- ※同上
「風が吹けばコンサルが儲かる」

ちょっとしたことを大事にして案件に仕立て上げる。そんな悪いことをする人は最近のコンサルにはいません。そんなことをせずとも、クライアント企業の企画部門は人員不足に苦しんでいます。予算さえ確保できれば、すぐにコンサルに声をかけるのです。何せ日本のIT部門の生産性は指折りの低さ。やることはどんどん増えるのに残業規制で働きたくとも働けない。そんな状況では、外部のコンサルに仕事を切り出すしかないんです。案件の絶対量と納期がもっと緩くなればいいのに。

【その14】--------------------- ※同上
「納品良ければすべて良し」

いくらたくさんのテストエラーが出ようとも、課題検討会で相手にボコボコにされようとも、サービスインがうまくいって、納品完了すればよいのです。雨降って地固まるよろしく、苦労を共にするとベンダーとクライアントの一体感は激増します。だからといって家に帰れないデスマーチに陥ると納品にたどり着かないことには注意!

【その15】--------------------- ※同上
「Do IT Yourself」

「Do it yourself」(自分でやれ)ではなく、「Do IT(アイティ) yourself」(ITは各自で取り組むように)です。もはやITを情報システム部門に頼る時代は終わりました。クラウド活用が叫ばれる昨今、ユーザーは自分でクラウドサービスを申し込んで、自分でサービスを利用開始してしまいます。そう、Salesforceのように。そういう勝手ITはユーザー自身の手で後始末してくださいね、と言えたらどんなに楽でしょう。

 

最後はまともな名言で締めましょう。

「プログラムを書いたことのない者、情報システムを語るべからず」

一を聞いて十を知る人も確かにいますが、多くの人は一を聞いて一を理解する程度です。いや、確実にその一を達成できる人はやっぱりそんなに多くないでしょう。だからこそ、書籍や伝え聞いた話で理解した気になるのではなく、実際にソースコードがどんなものかを感じ取ってからITを語ってほしいです。そういう点で、最強のIT戦士になるためのスタート地点はプログラマーなのだと思っています。

ITコンサルもSEも、原点はプログラマーにあり。

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

2017年03月29日

【3万時間でたどり着いた文章術】 読みやすい資料を作るための6つのルール
このエントリーを含むはてなブックマーク

ビジネスシーンで用いられる実践的でわかりやすい資料は、一定のルールを満たしています。ドキュメントの読みやすさは、ロジック(ストラクチャー)/書式(スタイル)/図表(スキーマ)によるところが大きいですが、何よりも「文章術(センテンス)」の出来の良し悪しは目につきやすく、資料作成の力量が問われます。

あなたにそのつもりがなくても、相手の誤解や認識不足を招いてしまいかねない言葉は用いません。難しい表現、あいまいで抽象的な表現はできるだけ避けます。文法が正しくとも、言葉と言葉のつながりがわかりにくくなるほど長い文章は、適度なボリュームに切り分けることも必要です。

センテンスがわかりやすい文書は、「言葉を簡単にする」ための6つのルールを実践しています。

1.一般的な表現を使う

カタカナ語句の多用は、あなたの表現力の弱さを読み手に感じさせ、文章の質を損ないます。社内ではカタカナ語句が飛び交う外資系企業でも、対外的に提出する文書では乱用しません。ただし、海外とのやりとりが多い部門や、業界標準の多くが海外で決まる世界(IT業界など)では、避けようもなくカタカナ語句が溢れています。そうした言葉を組織の人々で共有するためのやり方として、用語集を作ることを推奨します。

「〜性/〜的/〜化」の接尾辞を持った熟語を減らし、文として説明するように書き換えると、漢字の比率が下がり、読みやすくなります。ビジネス文書に書きなれると、文字数を節約するために熟語を多用しがちです。本文中にこうした熟語を用いる際は、「熟語化を避けた方が読みやすくなるか」を自問し、もしYesなら、熟語の使用はやめましょう。

形式名詞/副詞/接続詞/補助用言/複合動詞は読みやすさの点から漢字にひらきます。ビジネスの現場でよく登場する「ひらく」漢字はだいたい決まっています。たとえば、副詞なら以下の通りです。一般的には30%、ビジネス文書なら40%以下の漢字率を目指します。

予め → あらかじめ準備しておく
一層 → いっそう磨きがかかる
如何に → いかに解決するかを考える
所謂 → いわゆる正攻法ではダメだ
殊更 → 酒にはことさら弱い
暫く → しばらく飲み会は控える
直ぐに → すぐに医者へ行く
唯 → ただひたすら痛みに耐える
兎に角 → とにかく禁酒を勧められる
取り敢えず → とりあえず忠告に従う
尚更 → なおさら酒が飲みたくなる
正に → まさに蛇の生殺しだ
先ず → まず食生活から改善しよう
専ら → 夕食はもっぱら豆腐だけだ
素より → もとよりトンカツは食べない

また、「似て非なる漢字を使った言葉」での誤用は目立ちます。以下に示す言葉の使い分けを厳密に行えていれば、それだけでも文章の質は高まります。

20170329_WS000011

20170329_WS000012

 

2.明確な表現を使う

あいまいな表現を用いると、相手の勘違いを招きます。勘違いは混乱や手戻りにつながり、悪くすればビジネスを頓挫させてしまいます。人によって捉え方が異なる表現は避けて、数字や具体的な表現を用います。

誰かに聞いた話(伝聞)、あなたが想像した話(推量)は事実とは言えません。ビジネス文書では、事実ではない情報を極力排除します。あなたの意見が求められる場合に限り、推測にもとづく内容も伝えます。

・自分の意見が強い場合は能動的、一般的な考えである場合は受動的に表現する。
・推量表現を英訳する場合は以下の確率を目安にする。
Most likely    :90%
Probably     :80%
Likely :50%
Maybe / Perhaps :30%
Possibly    :10%

期限と度合を表す言葉で認識違いが起きると、致命的なミスになりかねません。必ず具体的な数字を使って記述します。

コストとボリュームに関する情報は具体的な数値を使って説明すると説得力が大きく増します。たとえば、「このシステムを導入すると業務効率が向上して新規事業に取り組む余裕がでます」と言われるより、「今まで10人でやっていた事務作業が5人で済むようになり、残りの5人分で新規事業に取り組むことができるようになります」と言われた方が、具体的な効果をイメージすることができます。

20170329_WS000013

 

3.文体を統一する

日本語で書かれるビジネス文書は、敬体/常体のいずれかで記述します。敬体とは「です/ます」調の文章です。この文章も敬体で書かれています。常体は「である/だ」調の文章です。常体表記の方が短い文字数で表現できるため、特に決まっていないのであれば、ビジネス文書の本文レベルは常体で表現します。

何かを相手に依頼したり、自分側の落ち度を謝るときには、本文を敬体にすべきです。敬体は柔和な印象を漂わせ、指示や依頼が持つプレッシャーを和らげる効果があります。「一方的に押しつけられた」と相手に思わせないための工夫です。社外向け文書についても同様で、相手に一方的なプレッシャーを与えないために敬体で書きます。

20170329_WS000014

 

4.トートロジーを削る

トートロジー(Tautology)とは、文章の知的レベルを損ない、文書の内容自体に疑いを持たせかねない、誤った重複表現です。見つけたらすぐに書き改めます。単純なものとして、「白い白馬」や「頭痛が痛い」のように、言葉同士で同じ意味を持つものを組み合わせてしまう「同語反復」があります。同語反復に気づいてしまった人はそれが頭の中に引っかかり、几帳面な性格の相手なら議論が脱線してしまうこともあるでしょう。話に集中してもらうために、同語反復は文書の中から排除しましょう。

同語反復よりも見つけにくく内容面で致命的なのが、理由と結論が繰り返されている「同義循環」です。たとえば、「右とは左の反対である」と「左とは右の反対である」はいずれも正しい定義ですが、両者を同時に扱うと同義循環になります。

20170329_WS000015

 

5.「〜を行う」を多用しない

検討を行う、調整を行う、設定を行う……気づけばつい使っている「〜を行う」という表現は、名詞にくっつけるだけで動詞に早変わりします。便利ですが、使い過ぎると文章を稚拙でわかりにくくする原因になります。たとえば、「処理を行う」という文は「処理する」と1語で表すとシンプルになります。「Aする」と書ける部分を「Aを行う」と表すことで、助詞の「を」が増えます。こうした表現が増えるほど、文中に登場する「を」の数が増し、文のリズムを狂わせます。目安として、1つの文で許容する「行う」は2語までとし、それを超えるものは動詞1語で書き表すことにします。

前提や仮説を含めて書くビジネス文書は多く、文中には名詞との組み合わせで「可能だ」という表現が頻出します。しかし、この表現が文中に何度も出てくると漢字比率が高くなり、格式ばった文章に見えがちです。そこで「可能だ」→「できる」と書き改め、文を読みやすくします。 「来週までに提出可能だ」は「提出できる」と書き換えます。

「可能だ」と並んでビジネス文書頻出の表現が「必要だ」です。これも「すべきだ」と書き換えることで文を読みやすくできます。たとえば、「修正が必要だ」→「修正すべきだ」と改めることができます。

20170329_WS000016

 

6.受け身を多用しない

受け身とは「れる」「られる」といった受動態で表現するさまを意味します。「会議を開く」を受動態で表現すると「会議が開かれる」になります。

受け身表現で文章を書くと、主語にすべき言葉がぼかされ、主体者不在のような印象を読み手に与えます。受け身が多く使われている文書を読むと、「他人事のように書いている」と思わせてしまうリスクがあります。

受け身同様、主体者不在と捉えられやすい表現に「せる」「させる」があります。この言葉は、相手に何かをさせる場合に用いる使役表現です。

@「わかりました、改善させます」
A「わかりました、改善します」

両者を比べると、@よりもAの方が積極性を感じられます。自分が代表して意見を述べる場面では、Aの表現を用いて主体性を示します。

20170329_WS000018

 

わかりやすい文章を作る方法はこれだけではありません。相手へ誤解なく情報が伝わる文章は、例外なく構造が単純です。これについても次の6つのセンテンスルールが存在します。

7.長くない一文で表す
→長文が続く文章はビジネス文書に向かない
→一文の文字数は100字、それ以上は分割する

8.接続詞と指示語を多用しない
→長文を避けて短文を多用しても読みにくい
→文のつなぎ目では接続詞をできるだけ使わない
→指示語を多用する文章は読みにくい
→指示語は具体的な内容に置き換える

9.前提を明示する
→人によって理解度は違う
→主張を理解してもらうための前提を示す

10.主語を明示する
→主語のない文は勘違いのもと
→主語を省略しても許される唯一の例外:「私」が主語
→主語と述語のずれを防ぐ
→主語と述語だけをつなげてみる

11.主語と述語を近づける
→主語と述語が離れると複数の解釈ができてしまう
→主語と述語を近づけて解釈を迷わせない

12.校正機能を利用する
→オートコレクトを絞りこむ
→言葉のゆらぎ/文法の謝りを修正する
→スペルミスを修正する
→読みやすさを自動的に定量評価する
→文章の修正経緯を変更履歴で辿る

先に取り上げた1〜6についても、もっと踏み込んで具体的に説明できますが、いずれもコンテンツのボリュームが大きいため、詳細な解説は外資系コンサルのビジネス文書作成術』(東洋経済新報社)をご覧ください。センテンスのルールだけではなく、ロジカルシンキングにもとづくコンテンツ構造を作るルール(ストラクチャー)、使いやすくて見やすい書式設定のルール(スタイル)、チャートとグラフをわかりやすく表現するルール(スキーマ)についても図解しています。

posted by 吉澤準特 at 05:07 | Comment(0) | TrackBack(0) | プロフェッショナル仕事術

2017年03月25日

外資系コンサルのビジネス文書作成術
このエントリーを含むはてなブックマーク

「外資系コンサルが扱う書類」と聞くと、PowerPointで華麗にお絵かきされたチャートやExcelで緻密に関数処理されたワークシートを思い浮かべる読者も多いでしょう。しかし、日々のビジネスを支えているのはWordで作成した文書です。何か新しいことを提案するのにPowerPointは有効ですし、複雑なデータをわかりやすくまとめるのにExcelは役立ちますが、文書管理の視点から、「フォーマルな業務文書はWordだ」と考える組織はとても多いです。

それほど重要なWord文書の作成法を体系的に学んだ人はほとんどいません。見よう見まねで作成する、過去に誰かが作成したテンプレートを上書きすることが繰り返され、Word文書はどんどん見にくく、読みづらい存在になっています。その結果、「Word文書は扱いにくい」という認識を多くの人が持つようになりました。

Word文書にはPowerPointにもExcelにもない、それ自体で相手の納得を引き出す力があります。しかし、そのことをあなたの周囲も、あなた自身も真に理解していると断言できるでしょうか。

累計数十万部を数える「外資系〜シリーズ」には、パワーポイント向けの「スライド作成術」、エクセル向けの「Excel作成術」があります。しかし、ワード向けの本は存在しませんでした

これはチャンスです。ルールさえ知ってしまえば、Word文書を自在に操ることは、実は難しくありません。本書では私がコンサルタントに指導しているWord文書作成メソッド、「伝わる文書を書くロジック」と「効率よく作成するWord機能の使い方」を解説しています。優れたWord文書を効率よく作成する方法を知り、適材適所でビジネス文書を作り分ける術を自分のものにしましょう。

※書籍で「ビジネス文書作成レベル診断」を行うことができます。

●書籍概要------------------------------------------------------------

『外資系コンサルのビジネス文書作成術』
〜ロジカルシンキングと文章術によるWord文書の作り方〜
https://www.amazon.co.jp/dp/4492557776

WS000005

★PowerPoint、Excelに続き、Wordの作成術がついに登場
★診断結果から、本書のどのページを読めばよいかわかります
★「ビジネス文書の構造」と「Wordの機能」を図解で紐づけたありそうでなかった文書作成術です
★ビジネス書に必要な日本語の使い方を図解し、「読んでわかる」→「見ればわかる」ようにライティング技術を解説
★Wordのキラーコンテンツ「議事録」の書き方・レビュー観点をシンプルなのに詳しく具体的に解説

【1.ストラクチャー〜論理構造を組み立てる〜】

・文書の目的をはっきりさせる2つのルール

→文書を作る前にWHO、WHAT、WHYを決める
→3段階でレビューを受ける

・ロジックを組み立てる6つのルール

→PREPで論点をまとめる
→主観と客観のPREPを使いわける
→ロジカルシンキングでPREPを作る
→ラテラルシンキングでPREPを作る
→クリティカルシンキングでPREPを作る
→アウトラインと見出しでコンテンツを構造化する

【2.スタイル〜体裁を整える〜】

・更新しやすい文書を最初から作る

→ヘッダー/フッターで文書のレイアウトを揃える
→インデントとタブで文章位置を調整する
→書式をスタイルでグループ化する
→スタイルを使いこなす:段落/文字/リスト/表

・推奨しない表記を避ける

→環境依存文字を使わない
→全角と半角の表記ゆれがない文章を書く
→送りがなにルールを設ける
→カタカナ語句は音引きを省かない

・正しく記号を使い分ける

→カッコを使いわける
→区分記号を使いわける
→強調記号を使いわける

【3.センテンス〜文章を整理する〜】

・言葉を簡単にする

→一般的な表現を使う
→明確な表現を使う
→文体を統一する
→トートロジーを削る
→「〜を行う」を多用しない
→受け身を多用しない

・構造を単純にする

→長くない一文で表す
→接続詞と指示語を多用しない
→前提を明示する
→主語を明示する
→主語と述語を近づける
→校正機能を利用する

【4.スキーマ〜図表を活用する〜】

・Wordで図表を使う

→単純な図はWordで作る
→単純なマトリクスと集計表はWordで作る
→Excel、PowerPointを組み合わせる
→図表番号、相互参照を使う

・チャートとグラフを使いこなす

→チャートを使いわける
→グラフを使いわける
→図形にルールを設ける

・色を使いわける

→最初は色を使わずに作る
→強調・基本・極薄のベースカラーを決める
→相手に合わせてベースカラーを使いわける

【巻末付録〜議事録の作成〜】

・Wordで議事録を書く

・議事録作成をシミュレーションする

 

紹介用のPDFはこちらからどうぞ。

ダウンロードリンク

 

WS000006

WS000007

WS000008

WS000009

WS000010

以上。

posted by 吉澤準特 at 03:37 | Comment(0) | プロフェッショナル仕事術

2017年03月13日

ITエンジニアのコミュ力
このエントリーを含むはてなブックマーク

IT業界に長く生きていると、様々なタイプの人に出会います。

コンピューターに向かい合う業界なので、技術に詳しい人が多いと思いきや、「技術的なことは大してわかりません」という人も数多くいました。そうした人はコミュニケーションスキルに長けた方が多く、ユーザーとの接点も多いため、クライアント側からは頼りにされます。

一方で、コミュニケーションベタが理由で、優れた能力を持っているのに「この人は頼りにならない」とネガティブなレッテルを貼られることもあります。「自分の理解できない説明ばかり」「知りたいことにピンポイントで答えてくれない」などの不満から、クライアント側で評価は低く、これが相手との信頼関係を損なって、本来は不要なコミュニケーションをどんどん求められるという構図に陥ります。

スキル本位のギークな世界であるはずが、「コミュニケーション」というスーツの世界に浸食されている状況を憂うITエンジニアは多いかもしれません。だったら、スーツの世界の武器を1つ手に入れてみればよいだけの話です。人と人とのコミュニケーションも、アプリ間のインターフェースと本質は変わりません。許可されているコマンドとオプションの数が多いだけです。

コミュニケーションのコマンド&オプションのバリエーションを覚える近道は、具体的なやりとりをたくさん見聞きして経験値というか熟練度を増やすことです。日々の仕事の中で経験してもよいですが、典型的なパターンを本から学ぶのも効率的でしょう。

私の手元にある『ITエンジニアとして生き残るための「対人力」の高め方』(日経BP社)では、次のケースが列挙されています。バッドケースとグッドケースが両方示されているので、理解しやすいです。

・相手のことは聞いてみなければわからない
・お客様のビジネス全体を意識して会話する
・自己満足の提案書を作らない
・聞き手を意識して話す
・相手が知りたいことに焦点を当てる
・相手が本当に知りたいことを考える
・「わかった気」にならずにもっと掘り下げる
・相手の事情も考慮して進め方を検討する
・相手の気持ちにも配慮する
・どうすればできるかを考えてみる
・何事も「自分ごと」で考える
・相手が受け入れやすい言い方をする
・相手が判断しやすい根拠を示す
・話しかけやすい人になる
・共感したうえで相手に考えさせてみる
・仕事の目的や全体像を伝える
・相手の「やる気のもと」を理解しておく
・相手が動きたくなる以来の仕方を考える 等

この本に謳われている『「他人ごと」を「自分ごと」にする』という姿勢は、ギーク・スーツ問わずに共通する必須のコミュニケーションスキルです。相手の状況を察して「自分があなたの立場にあったらこうします」という意見を持っている相手だからこそ、信頼を獲得することができるのです。

こうした事例を手元に置いてイメージトレーニングすることは、スーツの上を行くギークになる近道になるでしょう。

posted by 吉澤準特 at 01:28 | Comment(1) | 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ポイント付与で謝罪
ライブドア強制捜査
└ ネットワークベンダー