開発現場が変わるハッピー・コミュニケーション術

　こんにちは。高田です。寒い日が続きますね。

　ひさしぶりのコラムです。

　皆さんは開発現場で、一緒に仕事をする人たちとすぐに親しくなれますか？ 今回は、どうしたら新しい仲間と打ち解けていくことができるのかについてお話ししたいと思います。

　楽しんでいただければ幸いです。

◇　　　　　　◇　　　　　　◇　　　　　　◇

　システム開発はプロジェクトチームで行うのが一般的。同じ会社、同じ部署のメンバーだけで開発することはごくごく稀です。別の部署のメンバーだけでなく、別会社のメンバーも参加します。

　そのため、年齢も経験もスキルもバラバラで、多種多様なメンバーによる混成チームとなります。

　さらに要件定義、設計、開発、試験という、工程ごとにメンバーの増減があるため、出会いと別れの連続。

　システム開発の現場というのは、入学式と卒業式が頻繁に行われるインターナショナルスクールのようなものと言えるのではないでしょうか。いろんな文化を持った人たちが入れ代わり立ち代わり出入りしますので。

　そのため、システム開発という仕事は、システムを作る難しさ以上に、入れ代わり立ち代わり集まってくる、見ず知らずの他人と上手にコミュニケーションをする難しさがあるものです。

　そのようなプロジェクトチームのメンバーとして加わることになると、私は人見知りする性格なので、なかなか他のメンバーと仲良くなることができません。どんなプロジェクトでもすぐに打ち解けられる人たちを見るとうらやましく思うものです。

　あるとき、人見知りせずすぐに打ち解けられるメンバーの様子を観察していて気付いたことがあります。彼らはあることをすることによって、多くの人たちと心を通わせているという事実に気付いたのです。それは……

　共通点を探す

ということです。

　例えば、

A「Bさんって休みの日は何してんですか？」

B「休みの日は草野球やってます」

A「え、野球ですか？ 僕も昔野球部だったんですよ。ポジションは？」

B「これでもいちおうピッチャーなんだよね」

A「僕もピッチャーやってたんですよ。偶然だな～Bさんが野球なんて」

B「今は野球やってないの？」

A「いやー、最近は観戦ばっかですね」

　他にも

C「Dさんって兄弟は？」

D「兄がいます」

C「僕と一緒だ。じゃ子どもの頃の写真少ないんじゃない？」

「うん、少ない」

C「やっぱりね。弟の写真ってなんで少ないんですかね？」

という具合に。

　いろいろと会話が弾んでいるのですが、内容は「共通点探し」だけ。

　人と仲良くなるのってこんな単純なものなのかな？ と思ったのですが、学生時代を思い起こすと納得がいきます。

　学生時代、仲良くなった友だちは何かしらの共通点があります。部活が同じ、趣味が同じ、着ている服のセンスが似ている、見ているテレビ番組が同じ、嫌いな教科が同じ、など共通点があるからこそ仲良くなった気がします。

　また社会人になってからも、共通点を見つけることで親しくなれた人もいました。名刺交換のとき「あ、高田さんですね！」と同じ名字の人に親しみを感じたり、開発現場の担当者との面接のとき「奇遇ですね。わたしも同じ現場にいました」と昔話で大いに盛り上がり、面接をパスしたことなんかもありました。

　ことわざにも「類は友を呼ぶ」とあるように、人間は「気の合った者や似通った者は自然に寄り集まる（大辞泉）」生き物なんだな、とあらためて思わずにはいられません。

　そこでわたしは、

　「似たものは集まる（＝共通点を持つもの同士は親しくなる）」

という法則があるならば、

　「集まるには類似点を探せ（＝親しくなるには共通点を見つけろ）」

という法則も成り立つのでは？ と仮説を立てました。もしこの仮説が正しければ、すごくラッキーです。共通点を見つけるだけなら、人見知りのわたしでもできます。

　それ以降、新しいプロジェクトに加わると、プロジェクトメンバーとの共通点探しをするようになりました。出身地、最寄の駅、生年月日、干支、血液型、星座、兄弟構成、子どもの有無、共通の知人、趣味、などを聞いて、できるだけ多くの共通点を探すようになりました。共通点を見つけたときはグッと親しくなれた気がします。

　共通点ができると、その話題について繰り返し話をすることができますし、わたしからだけでなく、相手からも話し掛けられるようにもなります。結果、コミュニケーションの量が増えるので、自然と一緒にランチを食べに行ったり、飲みに行ったりと親しい間柄になれました。

　やっぱり「親しくなるには共通点を見つけろ」は正しかったようです。次なる入学式や卒業式に備えて共通点探しのスキルを磨いておきたいと思います（笑）。

　ではまた！(^^)/

　こんにちは。コラムニストの高田です。梅雨に入り、しだいにジメジメした季節になりましたね。ただでさえ忙しいのに、季節までが不快に……。印刷した紙もわたしもヘナヘナになりそうです。

　さてこのたび、セミナーを開催することになりました。セミナーのご紹介はコラムの最後にお知らせしますので、是非最後までお読みくださいね。

◇　　　　　　　◇　　　　　　　◇　　　　　　　◇

●必要なスキルは何ですか？

　エンジニアのみなさまにとって仕事をするうえで必要なスキルはなんですか？

　必要なスキルといっても仕事の内容によって違うだろうし、会社での立場によっても違うだろうと思います。

　わたしの過去を振り返ってみると年齢、経験、立場が変わるごとに、少しずつ必要なスキルが変化していったように思います。

　新人エンジニアのころは、ひたすらプログラミング技術を磨いていました。速く、正確に、バグを少なくするために頑張っていました。

　ある程度経験を積むと、設計書の書き方を勉強したり、拡張性の高いプログラムやオブジェクト指向を研究したりしていた記憶があります。チームの中で存在をアピールするため躍起になって本を読んでいました。

　そして30歳を過ぎると、チームをまとめる力や、お客さまと打ち合わせる能力を求められるようになりました。自分の仕事ぶりがチームメンバーに影響を与えてしまう立場です。コミュニケーションの難しさを感じるようになりました。

　その時々によって磨いていたスキルはさまざまですが、いまになって思えば、ソフトウェアに関する「技術的スキル」というのは経験を積めばそれなりに（わたしでも）身につくものだなと感じています。

　一方、人と打合せをしたり、誰かに作業をお願いしたりといった「ヒューマンスキル」については、年齢と共に身につくとはかぎらないなと感じています。誰かが技術的なミスをしてもそれを指摘しやすいですが、人間的な欠点を指摘するのはちょっと気が引けてしまいますよね。

　だからヒューマンスキルを意識するチャンスがなかなかないのではないでしょうか？

●システムエンジニアは「かっこいい」？

　ところで、わたしたちシステムエンジニアの仕事は「3K」だとか「4K」だとか言われていますが、その原因はどこにあるのでしょうか？

　システムエンジニアという仕事は本来モノづくりの仕事で、大変やりがいのある仕事だと思います。作り上げたシステムが稼働し、お客さまに利用されることで、わたしたちは喜びを見いだすことができるはずです。本当であれば「憧れの職業」であるべきではないでしょうか？

　そんな立派な仕事のイメージを悪くさせている原因は、おそらくわたしたちシステムエンジニアが「かっこよく」見えないからではないでしょうか？

　「仕事が楽しい」と言ったことや、ソフトウェア業界の明るい展望について熱く語ったことがあるかと、自らに問い合わせても、大きくYESとは言いづらいところです（笑）。「かっこよく」見えない原因を作った一人としてとても責任を感じています……。

●「不機嫌な開発現場」の理由

　それではわたしたちが仕事を楽しいと感じることができない理由は何でしょうか？個人的な意見としては、決して長い残業時間や技術的な困難さではないと考えています。技術的なハードルの高さは、むしろ、やる気が高まる要因になる可能性があります。

　わたしたちが嫌なのは

• 自分の意見を聞いてもらえない
• 失敗した人間が責められる
• 忙しくても助けてくれない
• 本音で語れない雰囲気

といったコミュニケーションや人間関係が原因なのではないでしょうか？

　みなさまの経験でも思い当たることはございませんか？開発現場の「問題児」は技術的に低い人だったのでしょうか？

●これからのエンジニアに求められるスキル

　わたしもかつて、自分自身が「問題児」だったことがあります。周りに迷惑をかけていたように思います。そして今もその可能性は否定できません。そしてわたし以外の誰もが、人間関係を簡単に悪くすることができてしまいます。

　そんなことから、今のわたしにとって最も必要なスキルは「コミュニケーションスキル」なのです。コラムタイトルに「ハッピー・コミュニケーション」とつけているのもそんな想いがあるからです……。

　さて、みなさまはどんなスキルを磨きますか？

◇　　　　　　　◇　　　　　　　◇　　　　　　　◇

　このコラムを書くきっかけになったのも、実は開発現場を楽しくしたい、そんな想いからでした。

　職場の人間関係に役立てたいと思い「産業カウンセラー」の資格もとりました。そして今も「開発現場を楽しくする」ための険しい道のりを果敢に進んでいる最中です。

　そんな経緯もありまして、このたびコミュニケーションスキルＵＰを目的としたセミナーを自ら開催することにしました。

　セミナーのタイトルは

『SEのためのハッピーコミュニケーション術セミナー』

です。

　わたしが開催するセミナーに集まるかな、と少々不安だったのですが、気がつけば予定していた定員もすぐに満員となりました。参加してくれるみなさまありがとうございます！

　もしコラムをご覧のみなさまの中で「見学してみたい」と思う方は、ぜひわたしまでご連絡下さい。すでに定員に達しているので「受講者」としての参加はできません。それでも見る価値はあると思います。もちろんエンジニア以外の方も大歓迎です。マスコミの方も是非どうぞ。

<<セミナー開催情報>>

• 日時：2009年7月4日（土）　10時～16時（途中退席可）
• 場所：都内（詳細はお問合せ下さい）
• 連絡先：admin@setakada.com（高田まで）

　突然ですが、みなさんは職場に自分のデスクはありますか？

　わたしはいわゆる「常駐」型のエンジニアなので、自社ではなく客先に常駐して仕事をします。つまりプロジェクトのたびに別の現場（客先）に出社することになります。したがって、自分のデスクというものはなく、一時的に協力会社用のデスクを間借りしています。

●零細企業の実態

　IT業界に転職する前は別の業界で仕事をしていましたが、転職した当時、わたしはこの客先常駐というスタイルにとても戸惑ったものです。新しく転職した会社は数十人程度の零細会社です。事務所には60歳くらいの社長と事務の女性がいるだけで、数十人いるはずの技術者たちが事務所にはいません。技術者だけでなくコンピュータも見当たりません。いったいどこで誰がシステム開発をするのだろうと不思議な気持ちがしたことを覚えております。

　しばらくしてこの会社のシステム開発の実態が分かってきました。どうやら数十人いる技術者はお客さんの会社に派遣されて仕事をしているとのことです。零細会社では自社内でシステム開発を行わず、技術者を大企業のお客様先に派遣し、そこで開発作業を行うということでした。自社で仕事をせず、お客さまの会社内で仕事をするスタイルにとても違和感を覚えましたが、それがこの業界の常識とのことでしたので、「そういうものか」と自分に言い聞かせていました。

●客先へ派遣

　入社前に聞いていた話では、入社直後はしっかり研修し、プログラミング技術を身に付けてから開発現場に派遣されるとの話でした。しかし、プログラミング技術を身に付けるどころか、入社してすぐ面接、そして即日、現場常駐ということになってしまいました。しかも面接時にお客さんに提出する経歴書には「開発経験3年」と書かれております。面接の時にお客さんから「SQLはできるの？」「詳細設計書を書いたことはあるの？」といったことを聞かれます。当時のわたしは、SQLという言葉も分からず、設計書なんて見たこともありません。未経験・未研修なので当然といえば当然です。正直に「できません。知りません」と言ってしまいたいのですが、言ってしまったら会社が虚偽の経歴書を書いたことがばれてしまいます。吹き出る汗を拭きながら「ま、何とか大丈夫です」と言ったものの、お客さんと目を合わせられませんでした。

　結局、技術面で不安はあるものの、人手が足りないとの理由で何とかわたしも開発現場に常駐することになりました。ド素人なのに本当に仕事が務まるのか？ と面接に同行した営業の方に聞きましたが、「何とかなるから大丈夫だよ。もし何かあったら電話して」と言われ、「そういうものなのかな」と自分に言い聞かせていました。

●無茶な仕事

　そして、ド素人の「経歴3年のエンジニア」が開発現場で仕事をすることになりました。開発現場では当然、経歴3年相当の仕事が割り当てられます。詳細設計書を読みプログラムを作成するのが与えられた作業です。が、設計書に書いてある単語がよく分かりません。わけの分からない記号も出てきます。そして、サンプルプログラムを見ても何がなんだかまったく分かりません。幼稚園児に因数分解を解かせるくらい無茶なことです。できるはずがありません。

　しかたなく、わたしは同じ客先で別のプロジェクトで働いていた自社の先輩に聞いたり、近くの書店で本を買ったり、同じ開発チームの人の良さそうな方に教えてもらったり、なんとかごまかし取りつくろいながら仕事をしていました。なんとかわたしの「ロースキル」がばれないように頑張りました。どれだけ冷や汗をかいたでしょうか？ きっと疑惑の渦中にある国会議員はこんな気持ちなのだろうな、と思っていました。

　ところで、面接に同行した営業の方ですが、その後何度も「助けてコール」をしたにもかかわらず、現場にくることは一度もありませんでした。これぞ現代の野麦峠です。

●常駐SEは孤独

　小さな会社に所属しているエンジニアは客先常駐というかたちで仕事の場を与えられますが、常にお客さんに監視されているような状態で仕事をします。自社の上司や先輩が一緒に常駐するケースもありますが、最悪な場合、1人で常駐することもあります。その場合、1人でプレッシャーと闘うことになるのです。

　派遣されて孤立した技術者がどれだけ精神的につらい気持ちなのか、自社の方には十分理解してもらいたいものです。派遣で送り込んだから、あとはエンジニア任せ、という会社が多いのはとても残念でなりません。派遣した後のエンジニアの活躍が、すなわち自社のサービスであるわけですから、しっかりとエンジニアの精神的なメンテンナンスを行ってほしいものです。

◇　　　　　　　◇　　　　　　　◇　　　　　　　◇　　　　　　　◇

　最後までお読みいただきありがとうございます。

　次回もお楽しみに。

　以前、英会話スクールNOVAのテレビCMで、宇宙人が関西弁で「オッサンが言うのも変やねんけども、異文化コミュニケーションちゅうのはやっぱりええと思うねんな」と話すCMがありました。みなさんはこのテレビCMを覚えていますか。

　流暢にフランス語を話す日本人女性、上手に日本語を話すイタリア人男性、イタリア語を話す大阪のおばさん、と次々にシーンが展開し、最後に宇宙人が登場する、という内容のCMです。とてもユニークなCMだったので記憶している方も多くいらっしゃるかと思います。

　さて、今回は開発現場における「異文化コミュニケーション」についてお話をしようと思います。

●標準化が大切

　ある金融機関向けのシステム開発に参画していた時のことです。大手SIerが受注した開発案件でかなりの工数だったと記憶しています。ピーク時には300人くらいの技術者が関わっていたのではないでしょうか。

　受注したSIerは技術力には定評のある有名な会社で、各社からエース級の人材を集めてプロジェクトに投入したと聞いていました。規模も大きく優秀な人材が多く集まるプロジェクトです。わたしのモチベーションも久しぶりに上がりました。「この現場で実績を認められるよう頑張ろう」と決意したことを覚えています。

　参加した当初、プロジェクトのマネージャからは「人が多くて大変です。経験がある人もいればない人もいる。所属する会社もバラバラで誰がどこの会社なのか、いまだにわからない。だから“標準化”された開発手法が必要なのだ」とおっしゃっていました。

　なるほど、好き勝手にドキュメントやソースコードを書いてしまったら、保守する人にはとても迷惑でしょう。障害原因を調べようにも読み解けないソースコードであれば、復旧までに時間が掛かってしまいます。また、ドキュメントにしてもある程度同じ体裁で記述する必要があるでしょう。人によって設計書の書き方が異なれば、設計内容以前にドキュメントそのものが理解できなくなります。人数の多いプロジェクトほど標準化が必要というのは十分理解できる話です。

●技術者は交換可能な部品？

　ところで、わたしはそのプロジェクトでチームを管理する仕事を任されていました。ですので、進捗状況や進捗遅れの原因報告などをすることもありました。

　ある進捗会議でのことです。チーム全体の進捗に遅れが出始めたので、プロジェクトマネージャから遅れている原因について聞かれました。わたしは「最初はある程度の勉強期間が必要です。計画では単純に作業量を日数で割っただけですので、遅れているように見えるのでしょう。後半に伸びてくるのでキャッチアップ可能な程度の遅れと認識しています」と答えました。

　しかし、驚いたことにそのマネージャは「A機能は難しい機能だからBさんじゃなくてCさんに担当させる。それと作業中のおしゃべりが目立つから、仕事に専念させるため知り合い同士は近づけないように席替えして」と言うのです。わたしは耳を疑いました。このマネージャは技術者を機械の部品の一部や家畜程度に考えているのだろうか。

　今まで機能の担当者していた人間に代わって、その機能について何も知らない人間が代打を務めることは容易なことではありません。設計書に記載していない背景や事情を知らないため、非常にリスクを伴います。また職場とはいえ、知らない人に囲まれ、冗談も言い合えない環境では緊張し続けてしまい良い仕事ができるはずもありません。

　このプロジェクトの例はかなり特別だと思います。なかなかこれだけ、“人を人とも思わない”人には滅多に出会えません。とはいえ、ここまで極端でないにしても、似たような考え方の人が多いのも事実でしょう。統一された開発手法や標準化された作業手順さえあれば開発は成功する、という考えを持つ人が。勉強熱心なのはとても良いことですが、人間的な視点が欠けているように思います。人間は感情で行動する生き物であることを勉強しなおすべきでしょう。

　結局、そのプロジェクトは“やる気がある”人ほど早く脱落（脱出）していきました。そして、ついには誰も保守に残らないという異常な状態になったと聞いています。

●開発チームは即席で寄せ集める

　開発プロジェクトが立ち上がると、わたしたちのような技術者を集めなければなりません。ところがお客様から案件を受注した元請SIerは技術者を多く抱えているわけではないので、「協力会社」といわれる下請けの会社に技術者集めを要請することになります。「協力会社」は1社ではなく、数社に要請するのが一般的です。

　そうして即席で集められたプロジェクトメンバーには、さまざまな特性があります（所属する会社、経験年数、スキルレベル、得意分野など）。また最近では、日本以外の国の技術者と仕事する機会も増えてきました。同じシステムエンジニアと呼ばれる人であっても、身に付けてきたスキルや経験そして文化に至っては多種多様です。

　各社から技術者が集められプロジェクトチームが組織されるのですが、ほとんどが初対面の人ばかりです。プロジェクトに参画したら最初の1、2週間は“人の名前を覚えるのが仕事”というのもまんざら大げさな話ではありません。

　わたしは人見知りする性格なので、なかなか人と打ち解けられず、プロジェクトが変わるたびに“転校生”のような気苦労をしてばかりいます。「今度のプロジェクトでは皆と仲良くできるだろうか？ いじめられたりしないだろうか？」という具合に。

　何年も一緒に仕事をしてきた仲間であれば、何が得意で何が好きなのか、もしくはどのような性格なのか、などその人の特性や背景を十分に理解した上で仕事ができます。しかし、開発プロジェクトは寄せ集めであるため、人間関係が出来上がっていません。その状態で高いパフォーマンスを期待するのは無茶というものでしょう。

●開発プロジェクトは異文化の坩堝（るつぼ）

　旅に例えるならば、開発プロジェクトは“異国人同士のツアー旅行”のようなものです。お互いが初対面で、使用する言語や文化的背景が異なります。相手の言葉が理解できなければ、旅の間、誰とも話すことができず、伝えたいことも伝えられません。旅の間、孤独で寂しい思いをすることになるでしょう。

　さらに、言葉だけでなく文化についても理解することが大切です。いつもどおりに生活していても、相手の国の風習から見たら不謹慎であったり、場合によっては犯罪とみなされるような振る舞いがあったりするかもしれません。女性が肌を見せることが犯罪となる国があったり、肉を食べてはいけない人たちがいたりするのです。自分と異なる人に対して尊重する姿勢が大切です。こちらから一方的に風習や文化を押し付けたりしては真の友好関係は築けません。

　システム開発において、万能な標準化ルールやテクニックなど存在しません。開発プロジェクトが成功するか否かは、開発チームのメンバーが自主的に動こうとする気持ちであったり、ルールを越えた協力関係であったりするものです。つまりわたしたちのように技術力をもって仕事をする人間にとっても、相手を尊重する人間的な姿勢やコミュニケーションスキルといったものが重要なのです。多種多様な技術者が集る開発プロジェクトでは真の「異文化コミュニケーション」能力が求められるのではないでしょうか。

　さて、冒頭の関西弁を話す宇宙人が登場するNOVAのテレビCMですが、あのCMを通じてNOVAが伝えたかったことは以下のようなことだったと記憶しています。

　「単なる外国語の会話力だけではなく、お互いの文化の違いもきちんと理解して異文化コミュニケーションをしましょう」と（※1）。

◇　　　　　　　◇　　　　　　　◇　　　　　　　◇

※1　残念ながらNOVA自身は社長と従業員の社内コミュニケーションにつまずいてしまいました。

　前回、「人は見た目が大切」とお話ししました。人は見た目で判断するので外見が大事です、と。

　今回は見た目を良くするべく私が取り組んだこと、そして感じたことについて語ってみようと思います。

■老けた顔

　「おまえ老けたな」

　10年ぶりに会った、昔の友人の第一声がこの言葉でした。10年前と比べ、私の見た目は「オッサンくさい」ものだったようです。一方、友人はその年齢にしてはとても若く、イキイキとした印象でした。同じ年齢なのに一緒にいるのが恥ずかしいくらい、自分が老けて見えてしまいます。私も少しは見た目を気にした方が良いかなと思いました。

■人は見た目が9割

　ベストセラーとなった『人は見た目が9割（竹内一郎著）』が火つけ役となり、以来書店には「見た目～」といったタイトルが多く並ぶようになりました。それだけ多くの人が“見た目”に関心を寄せているということなのでしょう。それらの本を読むと、「いつも笑顔でいれば人に良い印象を与えます」とか、「人は足下を見ているので靴はいつもきれいに磨きましょう」とか、「スーツは上質のものを着て“成功者”っぽく演出すると良い」とか、なるほど言われてみればとても勉強になる内容が盛りだくさん書かれています。

　それらの本に書かれているとおり、見た目が他人に与える印象を決定づけるのであれば、見た目を強化しなければならない、と感じたものです。

■上質な服には魔力が潜んでいる

　それらの本のアドバイスのとおり、上質な靴・カバン・スーツをそろえてみようと思いました。早速、伊勢丹メンズ館に行き、平静を装いながら、高額なスーツに袖を通してみました。店員のトークが上手いのか、それとも上質な素材だからなのか、いつも着ているスーツと比べてなんだか“出来る”男に生まれ変わった気がしてきました。さらに鏡の前をクルクル回るたび、いつのまにか見た目だけでなく内面にも自信が湧き起こってきたようです。「ああ、上質なスーツには魔力が潜んでいる！」と感じてしまいました。

　いつもより高級なものを身につけることで、周りの人からも仕事ができそうな雰囲気があると言われたり、お金持ちそうに見えると言われたりと、随分周りからの印象に変化があったように思えました。「なるほど本に書いてあった“見た目の効用”というのはこういうことか」と実感した次第です。

■「見た目」だけの好印象は長続きしない

　見た目の印象を良くする効果はあったものの、その効果は何日も続かない、ということも実感しました。新調したスーツを初めて着た日には褒めてもらえても、次の日にはインパクトは薄れていくようです。それが1週間、2週間と経つうちに、すっかり高級な服の魔法は効かなくなったようでした。

　営業マンであれば商談中の1、2時間の印象を良くすることで、次回会うまでの間は好印象のままでいることができるでしょう。だから第一印象が肝心です。しかし私のような仕事（システムエンジニア）はお客さんと四六時中一緒に開発作業を行うため、最初だけの好感度はすぐにメッキが剥がれてしまいます。

　第一印象がとても好印象の人であっても、開発を一緒にしているうちに良くない印象が少しずつ出てくる方もいます。上から目線で指図をしたり、陰口を叩いたり、気に入らないことがあると怒りだしたり、技術論になるととたんに早口で険しい表情になる方がいたりします。最初の印象がとても好印象だったのに、その変化に驚いてしまう、そんな方が非常に多いように思えます。

　逆に、第一印象がそれほど良くなかったのに、長く付き合ってみるととても好感度が高くなる方もいらっしゃいます。最初はとてもおとなしく、実直に仕事をするだけの影の薄い存在だった人でも、長い時間付き合ってみると、その真面目な仕事ぶりと表情の暖かさが重なりあって、時間が経つにつれて“味わい深く”なる方もいます。

■エンジニアは第一印象より“最終印象”が大事！？

　見た目が大事、第一印象が大事なのは確かですが、もっと言えば中身がともなった見た目が大事なのだということかもしれません。

　私のようなシステムエンジニアがお客さんに「また一緒に仕事しましょう」と言われるか否かは、開発期間最終日の印象がすべてです。終わりよければすべて良し、ということでしょうか。つまり“最終印象”が大事だということなのかもしれません。「○○さんといえば～」という、他人から見た“残像”を良くすることが大切なのかもしれませんね。

　今日はこの辺で。

　◇　　　　　　　◇　　　　　　　◇　　　　　　　◇

　次回は年明けになります。今年は大変お世話になりました。

　来年も引き続きよろしくお願い申し上げます。