ちょっとした認識の違いや解釈の齟齬で発生した手戻りや仕様変更というものがあると思います。こういう問題でいうコミュニケーション力とは、なのでもっと広義なコミュニケーション力を指しているのであって、社会適応能力という狭義の問題を指しているのではないと考えています。

ちなみにこういう技術力とコミュニケーション力の話、個人的には
　・TCP/IPのプロトコルスタックで、一番重要なレイヤは何か
を議論しているのと同じような感覚をおぼえます。

コミュニケーションというのは、相互の関係です。
だから、手戻りが発生したというのは両者に問題があったということです。
一般的には、伝えようとする人がそれを理解する人より
多大な労力を支払わなければいけません。
どんなに受け手が努力したって、伝え手が言いたいこと以上のことは
生まれないわけですから。

技術者のコミュニケーション力を嘆く前に、自分のコミュニケーション力の不足を
認識した方がいいでしょう。
聞き手に100％伝えたかったら、150％以上の言葉で説明しなければなりません。
伝える側は、「伝えよう」という意識を強く持ちましょう。
もう嫌って言われる位に、同じ事を復唱しましょう。
それでようやく、相手に伝わる可能性が少し増えてきます。

はじめまして。ちょりぽんと申します。

・コミュニケーションの大切さを前面に訴える者は、技術から逃げているのではないか。
・技術を訴える者は、コミュニケーション能力が不足しがち。

まるで両者がトレードオフな関係にあるという誤解は、往々にして生じやすいと思います。

これは、同じフロアに居合わせて仕事をする者同志であれば、言葉にせずとも誤解が生じませんけど、ここの様なテキストのみのやりとりでは難しい場合がありますね。で、wonaさんはありがちな事象を一例として用いたのであって（と、私は読み取りました）、wonaさんが至らない人と見て取れる返信に少しだけビックリしました（笑）

Naokiさんもお判りのだろうと思いますが、技術とコミュニケーションスキルはトレードオフの関係ではなく、社会人として両方備わっていて当然の能力ですよね。

会話の無さが原因で、技術的にはかなり高度な実装をされていたにも関わらず、発注側から見れば要件にカスりもしない、どうでも良いロジックをひたすら書いてたというケースに何度か遭遇しています。

つまり、wonaさんが仰る、
> ・TCP/IPのプロトコルスタックで、一番重要なレイヤは何かを議論しているのと同じような感覚をおぼえます。

に帰結すると思うのですが、如何でしょうか。

ソフトエンジニアにとってのコミュニケーション力とは、詳細を理解する
能力だと思います。お客さんから要件を聞きながら、要件の全体像を頭の
中に作ります。話を進めるうち、その全体像で説明できない内容をお客さん
が、ふっと言うことがあります。それに気づかず、次に進んでしまう人は、SE、
特に要件定義定義屋さんとしては、失格です。そういう細かい矛盾点が、
自分が考えている全体像と、お客さんが思っていることの違いを、気づかせて
くれる、数少ないチャンスなおのですから、絶対見逃してはいけません。

ところが、こういう能力、やはり経験をベースとした、SEとしての自信が
なければ、矛盾点を矛盾点として、認知できないものです。頭、頭の良さも
必要です、学生時代常に１００点に近い成績をとっていた人は、完璧に
物事を理解するといことがどういうことかを知っています。そうでない人、
にはそれがなかなかわからないものです。１００点に近い成績を常に
とっていた人は、些細な矛盾点に気づくことげできるのです。

ということで、SEにのとってコミュニケーション力とは、頭の良さということ
かと思ってます。

IT業界の話を聞くといつも世界が違うんだなぁと思うのですが、わりと今回も驚いてたりｗ

優れた設計書があるならば、それをコードにすることは簡単なんじゃないんですか？
コーディング力というのが、仕様からコードにすることを指すのであれば、たいした技術はいらないような気がします。
いや、もちろん人によって渡される設計書や仕様の程度が異なるのでしょうが・・・

プログラムを組むのに一番苦労するのは、仕様だと思うのですよ。
そして、仕様を作る、もしくは仕様を理解するのに必要なのがコミュニケーション能力じゃないかなぁ。
仕様が大雑把であれば、細部まで決定する必要がありますよねぇ。

>聞き手に100％伝えたかったら、150％以上の言葉で説明しなければなりません。

これもそうですがーお客が相手だった場合などは、その逆が必要になるわけです。
こー「１を聞いて１０を知る」みたいなー聞き取り能力ですね。
これは話術であったり、蓄積された経験であったり色々なわけです。
この辺のやり取りを含めて、コミュニケーション能力と呼んでいると思います。

この手の話は、「そんなのできて当たり前だー」と考えているものが違うだけで、だいぶ変わりますよねぇ。
自分の立ち位置によっても、印象は大きく変わるのだと思います。
お客に接することもなく、優秀な設計図が配布されている環境ならば、コミュニケーション能力はそれほど求められないと思いますね。

あとは・・・難しいと思うものの違いですかね(^^;
私は、仕様やロジックを決定するのがもっとも難しいと考えているので、それが決定すれば、コーディングは機械的な作業だと思うのです。
それにたいしてお客との打ち合わせなどは、営業的な駆け引きなども絡んで神経をすり減らしてたりｗ

だから本文の
>システムの良し悪しを決定するもの、それは最終的にはプログラマの技術力に他なりません。

個人的には、技術力よりも仕様だと考えちゃいますねぇ。
プログラマの技術力で改善されるのは、処理速度だけじゃないかなぁ？

題名と内容から、「プログラマの方々！コミュニケーション云々言う前に、自分の基礎技術はどうなの？」ってことですよね？

IT系派遣会社に就職さえすれば、即プログラマです。３～５年居続ければ、勝手にＳＥ。そんな人達に技術力つけろっていっても「はぁ？なにいってんの？」で終わりです。
それに、そんな人達がそもそも＠ＩＴを見に来るかと。

あなたのコラムは楽しみにしてますが、今回はどうでしょう？もう言い尽くされた感があるのですが。

技術力って、なんですか？

プログラムって、コンピューターとのコミュニケーションだと思うこの頃。

皆さまからのたくさんの投稿に驚いています。
色々な意見、参考になります。

■ レイヤ
一番重要なレイヤなんて一つも無いですよね。
なるほど、つまり「どちらも重要だから両者を比較するのは意味が無い」ということ
だったんですね。読解力が無くてすみません。

■ トレードオフ
確かにその通りです。
自分もトレードオフということを言いたかったわけではなく
どちらも必要だと言いたかったんです。
ただ、技術力が軽視される事が多いので、こういった記事を書きました。

■ 詳細を理解する能力
人によって様々なコミュニケーションのとらえ方がありますね。
要件定義の段階では、そのような能力が大事です。
僕が書いたのは、もう少し後の段階の話で
ある程度大枠が決まっていて、コーディングに入ろうというプログラマに
関するものでした。

■ 優れた設計書
作るシステムの種類によると思います。
Webサイトなどの比較的簡単なシステムならば
大したコーディング力は必要ないのかもしれませんが
企業の業務基盤となるようなシステムを作るときには
相当の力が必要になります。設計書→コード、とすんなりいかないのです。

ロジックが決定すれば、それはもう充分ですね。
そこからコーディングというのは機械的な作業です。
というか、ロジックが決定すればもうコーディングは完了しているのというのが
僕のスタイルなので。
ロジックを決める作業すらもコミュニケーション能力だとは、考えていませんでした。
ここらへんはホント単語のとらえ方次第ですね。

■ 改善
その処理速度が問題でうまくいっていないプロジェクトをたくさん見てきました。
充分に改善されるべき項目だと思います。
あとは、保守性や拡張性なども、技術力で随分変わってきます。
つまりこれは、技術力の差によってコストが大幅に変わってくるということです。
ビジネスの面から見ても、技術力の改善はプラスになると考えています。

■ 勝手にSE
そういう人たちは、もう何年かすればいなくなると思ってます。
海外の技術者の方が安くて技術力も高いですから。
@ITはメジャーなので、色々な人が見にくると思います。

■ 技術力
確かに、それすらも曖昧な定義でしたね(苦笑)。
個人的には読みやすいコードとスマートなロジックだと思ってます。
Javaだったら整理されたパッケージやクラス構成なども大事です。
そこら辺の話は、また今度します。

話を「プログラマ」に限定すれば、大雑把にいって
「コーディング力」だというお話は納得できるものです。
設計・言語での実装力もプログラマの仕事に含まれるということでは。

----
「自動化」する「機械」という話では、結局、何をさせたいか
どこまで細かくさせたいか、速度や大きさはどうか。という話かも。
また、安全性・堅牢性という要素の問題です。

　部品というのも、汎用性が高く、精度や速度・大きさを気にしない
のであれば、多くの選択肢が得られます。
　誤差が1mmの部品でも10個使えば、最大10mmのズレがでます。
ズレが許容範囲を超えれば、欠陥になります。
　ソフトも部品と考えると、結局は製品は部品の構成全体で決まります。
部品は部品です。製品全体で見ると大きくても半完成品にすぎません。

　ある携帯電話は、いろいろな機能が問題なく動いていますが、
GUI部分の切り替え動作が遅いです(200ms～1s)。
だから、あるボタンを押してから画面が切り替わるのに止まった
ように感じたり、あることのボタンを2回押しても、連続押しと
判定されていて、続けて画面が2回切り変わったり、2回目が
受け付けられなかったり。カメラでボタンを押して電話を動か
したら、映像がブレていたり。

　機能という枠組みも、結局は部品と部品の組み合わせで、
その機能の中で問題がなければ、それは正常に動作します。
機能同士を結びつけることも同じです。
　だから、上記の携帯電話は、正常に動作しています。

　問題は、部品の組み合わせ・選定です。
それによって、機能毎の性能・精度・大きさ・速度・安全性・堅牢性
などが決まってきます。ソフトウェアでの実装というのも基本的には
この部分を担っています。

　性能や速度が欲しいというときには、アセンブラが必要な場合もあります
し、ハードウェアの方が目的を達成しやすいというときもあります。
　ただ、「無いなら作る」しかないという点で、プログラマの仕事は重要です。
そういう点では、このお話は、正解だと思います。

　製品は、使用される状況や条件によって考えられ、設計されます。
前提条件が違っていれば、使用者の想いとかけ離れたものが
出来上がります。

　自分個人は１からモノを作れるかというと「いいえ」なので、
作れるようにとは思う訳ですが、まだまだ駄目です。
自分のできることをしようというだけで精一杯です。

----
コンピュータを使うお仕事は、複数の要素技術によって
なりたっています。

　ロジック・言語・実装技術・環境構築・数学・物理など。
機械に「させたいこと」(要求)やそのための条件が分かっていても、
「実現方法」が分からなければ機械やその動作は作れません。
　高度の技術をすべてひとりで請け負うのは、難しいですし、
機械を作るのに時間が掛かってしまいます。

　そこで、機械のソフトウェアを複数の人々で完成させるために、
ITSSなどコンピュータでのお仕事を分解・整理する
試みなどが行われています。

----
コミュニケーション・通信とは、相互理解です。
送り手の情報を、受け手がもらう時には、情報の劣化が
必ず起こります(エントロピーの増大)。
　送り手は、より丁寧な(冗長な)情報発信が必要ですし、
受け手には、それで正しいかの確認が必要です。

　同じ言葉や一定の技術を持つ者同士ですら、情報の誤認は
起こりえます。なぜなら、完全に同じ情報を共有しているの
でも、プロトコルや通信仕様を定義して、限定した規則・単語で
内容を伝えているわけではないからです。背景が異なります。
　ここ(エンジニアライフ)では尚更、ひとつの単語を別々の意味で
捉えていることをよく目にします。

　話の内容が「機械にさせる仕事」のことなら、詳細で込み入った
話になるのは必然です。
　人間同士のプロトコルや通信仕様を定義するようなすり合わせる
ところから、雰囲気や感覚を、理論や数値に置き換える作業が
会話の中に含まれます。

　ただし、人間は単に１つの仕事をしているのではなく、それぞれの
事情や感情をもっています。仕事かそうで無いかに関わらず、
会話での、否定や拒絶は受け入れられにくいというような。
そういう部分を含めると、コミュニケーション力や交渉力というのは、
深いです。

　自分個人としては、頭の良い人や優秀な人が、聞いたことを完全に
理解できるかというと疑問です。
　頭の良い人や優秀な人は、優秀であるが故に正しい結果や最適な結果を
導け出せます。細かい矛盾点への深い洞察力に目をみはるときがあります。
　しかし、それ故に遠回しな言い方、歪曲した話などに気づかない場合、
考えていないことさえあります。
　失敗経験が無い故に、多くの人が犯すであろうミスを盛り込めない
場合もあります。最適化された思考には、ウッカリは入っていません。

　「１を聞いて１０を知る」ということは、その背景に多くの経験や
知識の蓄積があるからこそだと思います。

少なくとも自分は、「10聞いて1知る」程度です。いろいろな諸条件
や状況を「明確」にして、始めて 根本にある理屈や方法という
「理解」にたどりつけます。

　自分が当たり前だからと、相手の心情を勝手に解釈したり、
特に「確認」を怠ると手痛い目にあうことが往々にあります。

　自分個人は、コミュニケーション力や交渉力が高いとは言いにくい
部分もあるので、間違った認識をしているかも知れません。

・「会話」の嫌いなところは、記録に残りにくいこと。
　　誤解や思い込みが素道りしやすいところ。
・「文章」が嫌いなところは、感覚や散漫な考えなど伝わり難いこと。
　　質疑応答に素早が欠けること。
・「言葉」の嫌いなところは、理屈が直線的になりやすい。
　　立体的でないこと。
　　単語によるチャンク化の粒度が一意に保ち難いこと。
・「図」が嫌いなところは、イメージであること。
　　抽象さの意味をそろえ難いこと。

　もっとも、自分自身の最大の問題点は「知識」と「理解力」かな？

＞10年選手でも、自分で1からものを作れない人が、この業界には山ほどいます。
＞そういった人達は何人集まっても、あるライン以上のものは作れません。

これは、全て個人の責任でしょうか？
年齢と経験年数だけで、人を見ている上に、単価は安くたたく体質はどう思いますか？

理想論としてはトレードオフではなく、双方持つべきもの。
ですが、現実論としてはトレードオフ状態によく遭遇します。

非常にテクニカルな技術を持ちながら、それ以外を全くやろうと
しないＰＧさん
→作るのが仕事だ、それ以外は全くしません。閉じこもります。
かつ自分の理想とするコードを実現するために報告相談もなく
設計とは違うコードを書きます。
（性能はいいが、保守性がだだ下がり

テクニカルじゃ勝てないから強力会社管理やマネージメント、
顧客調整といった方向に走ります。
→技術を一向に知ろうとしないＰＬの誕生

両方持ってる人って稀ですよね。
（それとも私のまわりがおかしいのか）

まことに申し訳ないですが、「読みやすい」「スマート」というのも、曖昧です。

私など、古い N系BASIC などに囚われた古い人は、「どうやって実現するか」が判りやすいコードを、「読みやすい」と判じます。しかし、構造化プログラミングにおいては、「何が実現されるか」が判りやすいことを、「読みやすい」と評します。
スマートにしても、掲示板では「スマートな方法はないですか」という質問が、何度か出てきますが、大抵の場合、「どういうのをスマートとしますか」という返答があります。

> これは、全て個人の責任でしょうか？
個人だけの責任ではないと思います。
個人的には、雇う側の問題が大きいと思っています。

> 年齢と経験年数だけで、人を見ている上に、単価は安くたたく体質はどう思いますか？
自分もそういった奴らが大嫌いな性分です。
年齢とか経験年数だけで、その人の能力は測れません。

> 両方持ってる人って稀ですよね。
確かにその通りだと思います。
しかし今後は、両方持ってる人達が生き残っていくのではないでしょうか。
自分の周りでも、そういう人は今のところ皆無です。

> まことに申し訳ないですが、「読みやすい」「スマート」というのも、曖昧です。
確かにその通りですね。
わかりやすいコードというのは、人によって違います。

だから、正確に言えば
「そのコードを実際に見る人達が、読みやすいと感じる」かどうかが
重要だという事でしょうか。

しかしそういった主観的な面はありつつも
一般的な「読みやすさ」というのはあると思っているのですが、どうでしょうか。
自分が書いたコードは、大抵誰からも読みやすいと言っていただけますし
汚いコードを見つけてそれを人に話すと、やはり「汚いよね」という意見が
得られることが多いです。

スマートというのはより主観的な要素が強いです。
非常に端的に言えば「無駄なコードが無い」という結論になってしまうのですが
それをスマートではないという人もいるかもしれません。

>Naokiさん
>ある程度大枠が決まっていて、コーディングに入ろうというプログラマに

なるほど、じゃー高いコミュニケーション能力は不要かなぁ。
・・・というか、その段階で問題になるのはプログラマとか関係なく致命的のような気がします。
コメントしている人の多くは、主にお客との仕様打ち合わせを想定しているんじゃないかなぁ。

Naokiさんにとって、ロジックはコーディング寄りなイメージのようですね。
私は、仕様寄りなイメージが強いんですよ。
先のコメントもそのような視線で読んでいただければ、基本的な認識は似ているんじゃないかなと思います。
仕様にからまないロジック・・・ソートなどの一般的なアルゴリズムはコーディング寄りなんですけどね。
それ以外の部分に技術の差がでるんでしょうね。

>あとは、保守性や拡張性なども、技術力で随分変わってきます。

イメージとしてはコーディングというより仕様かなぁ。
初期段階で、どの程度の仕様変更に耐えられるようにするかどうかじゃないんですかね。

こー時代的に、コーディングに関しては、誰でもできるような時代になってきてるんだと思うのですよ。
・・・というか、できないと食べていけないわけで(^^;
達人プログラマが一人で全部やる時代は終わったと思うのですわ。
少数の設計者が作成した優秀な仕様を、多数の凡人なプログラマがコーディングする時代。
そして、多数の凡人なプログラマは、徐々に機械に置き換わっていくのかなと。

達人プログラマはプログラマの憧れであり目標だと思うのですが、企業やお客の需要は少ないんじゃないかなぁ。
動作しているプログラムだけみたら、達人と凡人の差は減っていると思いますし・・・
結果だけみるとわずかな差だけど、技術的には大きな差があったりするのは面白いとこですけどねｗ

求められるのは、優秀な仕様が作れる人だと思います。
そして、仕様を作るのにもっとも必要なのがコミュニケーション能力だと思うのですよ。
これが、「技術力よりもコミュニケーション能力」の正体じゃないかなぁ。

お客からみたら、営業マンがプログラム組めるのが理想なんじゃないかぁ。
まぁ・・・営業ができるプログラマがSEなのかもしれませんが(^^;

コーディングが誰でもできるような時代だなんて、
甘いなぁ、と個人的には思ってしまうのですが
ビジネスとして考えれば中途半端な技術力でも何とかなるのかもしれませんね。

別にあなたがそれで満足しているならば、何も問題はないです。
ただ、もし理想や空想だけでそういう発言をしているのならば、問題ありますね。

テーマは、一歩先の技術力です。
誰でも出来るようなコーディング能力なら、僕らの職業自体が必要ないって
結論になってしまいますから。

ビジネス的に、優秀な仕様が作れる人が求められているのは、理解しています。
しかし、それだけで今後続くかというと難しいとも考えています。
営業マンがプログラム組めるほど、甘い世界じゃないですよ。多分。
極めたもののソレは、他を圧倒するような凄みがあります。

プロフェッショナル 仕事の流儀で、こんな事を言ってる人がいました。
あなたにとって、プロフェショッナルとは何ですか？
「1000人が束になっても太刀打ちできない人」
僕が目指しているのは、そういう人です。
あくまで理想です。現実は、そんなに甘くないです。

だんだん話がそれてきているような気がしつつ、読ませていただいた雑感を。

コミュニケーションと技術が両立できるか。

が主題な気もしますが、逆に両立できない人は、プロジェクトチームでの
作業に不適切な方だと思います。

技術とコミュニケーションを天秤にかけなければならない状況は、
それだけ不適切な方が多い証拠だと思います。
であれば、コミュニケーション云々ではなく、そういった方達をメンバーに
迎えたときに、いかに円滑にプロジェクトをまわすか。といった議論のほうが、
良いのかな。と思いました。

>> あなたにとって、プロフェショッナルとは何ですか？
>> 「1000人が束になっても太刀打ちできない人」
>> 僕が目指しているのは、そういう人です。

そうですね、プロフェッショナルって色々な意味合いを持つ、主観的な話だと
思いますので、一番最初にこれを提示すべきですね。
そうすれば皆さんのコメントも、もう少し変わってきたのかと思います。

>> 営業マンがプログラム組めるほど、甘い世界じゃないですよ。多分。
>> 極めたもののソレは、他を圧倒するような凄みがあります。

これは、営業の方に大変失礼な言い回しですね。
「極めたもののソレ」が何を指すのかわかりませんが、
営業の方にケンカでも売りたいのか？と思ってしまいます。

一端の技術屋として非常に気持ちはわかりますが、熱くならず
冷静に見直してから投稿される事をお勧めします。

最後に私の主観も。。。

1000人束になってもかなわない技術力でも、
たった一人の顧客に嫌われたら、仕事がなくなるかもしれません。

業務を円滑に進める為に必要な事は、柔軟に吸収し、努力し、自分のモノにする。
これは、エンジニアに関わらず、ビジネスマンとして必要な事だと思っています。

まぁ、自分自身が思う「プログラマの仕事」というのは、
ある範囲の機能分担をすべて請け負っていて、
設計・仕様間の調整などの「デザイン」するということですかね。

Jack Reeves が、
＞「実はソースコードが設計書で、(建築でいう)モノ作りに相当するのは、
＞コンパイラーとリンカーを動かしてる時間だけじゃないだろうか」

( 新しいソフトウエア開発手法 マーチン･ファウラー :
http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html )

と言っているようなところに帰結すると言いますか。

　そうなると、プログラマっていうのは、関数やクラスなどの極々
小さい部分よりもっと大きな部分や多くの部分の「デザイン」を
受け持つことになると思います。

　この上の方に大雑把な仕様書を貰ったときの話が出ていますが、
そのとき仕様書の足りないところや不備や間違いに「気づく力」も
必要かもしれません。
　複数の仕様書をつき合わせたら、「嫌な臭い」が分かるような
感覚ですか？
　例えば、「ここは上位層との接続がやりにくいな」
「これとあれの2/3は同じものだ、ひとつにまとめられるだろう」
「ここは臭いな。どう解決しているのだろうか、聞いてみよう」

　仕様というと考え方の根本は同じでしょうが、
もっと細かくなると言語での実装ということでは、
JavaとRubyやPythonなどそれぞれ、書き方とか流儀は違っていて
それぞれに精通するものは異なるとは思います。
　やはりそこは、修練がいると思います。高度の錬度になると
仕様書の突合せで、それぞれの部品の接続の具合というか
連動状態が把握しやすくなるとは思う訳です。

　何回も開発している経験から分かる知見とでもいうような。

　大きな枠での仕様そのものは、言語の特性には依存しないのですが、
機能分割などの設計の過程では、言語仕様によって構成が変わって
来る部分も大きい訳です。

　プロトタイプや動かしながら確認というRAD的なものだと、
素早くコードを書けるプログラマの方が生産性が高いでしょう。

　もっとも、特定の技術とか言語に知識が特化しすぎると、
その部分での仕事しかできないということにはなる訳ですが……

----
コード自体については、自分としては以下のようなものがあると
嬉しいですね。
・『コードコンプリート』などで言う「エレガンス」のようなもの。
　　http://www.atmarkit.co.jp/fdotnet/bookpreview/codecomp2nd_index/codecomp2nd.html
・コーディングルールのような一定の書き方に従っている。
・仕様との一体感がある。
・コメントに文章で理由が書かれていること。
・入出力の関係が分かりやすい。

　コードそのものは手続きのような処理の、部分があるわけで
コードだけ見ても「何をさせたいか」という仕様や理由の部分が
掴みにくいことがあります。
そこで、なぜこのようにしているのかが分かるようなコメントが
文章であると仕様との関係を理解しやすいかなと。
よく言われるように、コメントで処理の流れを書かれても、
流れ自体はコードを読めば分かるので、「なぜ」「どうして」
というのが見える方が嬉しい訳です。

　また、一見では冗長または不要なものが……
「○○処理の結果によって動作が変ります……」
「ここでは、○×する必要があります、なぜならば……」
と、いう風なコメントで明確になるときがあります。
これは、あまり良い例ではありませんが、表面上見えてこない
環境の都合・実装上の都合という処理の場合です。

　また、エラー処理など、直接の処理から見ると従属的なもの
が途中に入り込む場合、本筋と付属的・従属的な処理が
分離されていることも判別しやすさに繋がります。

----
　コミュニケーションも、複数のプログラマが集まって
作業するわけで、仕様のことで話あったり、単体テストで協力
してもらったりします。また、問題が発生して助けが必要になるとき
交渉することもあるでしょう。

それぞれ背景が異なっているので、用語集のような仕様に関連
する話。動作や問題点の議論に関して、言葉で意味が異なったら
誤解が生じます。
　この辺りは、お客とメンバーという話す相手が異なっても
交わされる会話に違いが無い部分もあると思います。

　お客との話だと、金銭的な話など利害に関わる部分も
増えてきますから、話し方に難しいところもあるのでしょうが。

----
「達人プログラマ」を雇う企業的な意味は個人的には3種位あると思います。

　・達人というかいわゆるウィザードに沢山のコードを速く書いてほしい。
　・自分たちで解決できない問題が発生。
　　技術的にどうしていいか分からない、助けてほしい。
　・達人の仕事やり方やコード・ノウハウを取り入れることでの改革。
　　一度やり方が分かれば、真似れば良い。

そろそろ脱線しかかってきたので、いったんお開きにしたいと思います。
また、次のコラムでお付き合い下さい。