開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略：きのこる先生のエンジニア転職指南（6）（2/2 ページ）

» 2011年12月26日 00時00分公開

コミュ力を捨てろ

　次に「コミュニケーション」の定義を投げ捨てましょう。

　応募書類のアピールポイントとして定番の「高いコミュニケーション力」。

　エンジニアには時々、「人と話すより、エディタやターミナルと仲良くする方が何倍も得意」というタイプの人がいます。普段からそういった同僚を見ているエンジニアが、転職時に「よし、いっちょコミュ力をアピるか！」と張り切ったとしても不思議はありません。

　職務経歴書でしばしば、下記のような文言を見ます。

顧客との折衝経験があります
サブリーダーとしてチームをまとめました
上流SEとの仕様調整を行えます

　「自分はエディタやターミナルじゃなくて人間とちゃんと話せるよ！」という気持ちが生み出したものかもしれませんが、はっきりいってこうしたアピールは書いても無駄です。「コミュ力があります」「そうか、じゃああなたを採用します」となるわけがないからです。

●敵も味方も本能寺にあり

　自社サービス／自社開発の場合、コミュニケーションの対象は、自社メンバーの場合が多いでしょう。自社サービスやプロダクトの顧客は、そのシステムを実際に使う「エンドユーザー」です。彼らがシステムに価値を認め、楽しさや利便性に対価を払ってもらうのが、ビジネスモデルです。

　とはいえ、エンドユーザーの声を直接聞いてばかりいるだけでは、仕事になりません。スマートフォンアプリやグルメサイトで、レビューに酷評がつく問題がありますが、移り気で無責任なエンドユーザーの声は、そのままでは「顧客の声」とは呼べないことが多いのです。

　そのために、自社サービスやプロダクトを開発する際には「ディレクター」や「プランナー」など、開発の方向を企画する職種を設定することが多いようです。エンドユーザーの要求を整理し、一番効果的な次の一手を考える、いわば「エンドユーザーの代理人」として見ると、エンジニアにとっては彼らこそが「顧客」と呼ぶべき存在でしょう。

●コミュニケーションの目的

　そして同時に、彼らは同じ会社に所属し、同じミッションに取り組み、同じゴールを目指す「チームの一員」でもあります。ですから、常に協力し合い、時には衝突しながら、最終的な目標を達成するために、常にコミュニケーションを取り合う必要があるのです。

　つまり、Web系企業で求められる「コミュニケーション能力」とは、上辺を繕ったり、なあなあになっている事象の落としどころを探したりする能力ではなく、“手ごわい質問をぶつけ合い、本質を明らかにする”能力なのです。

　SIerではアピールになる「顧客との折衝経験があります」という記述は、Web系企業への転職活動においては役に立ちそうにもないこと、お分かりいただけたでしょうか。「コミュ力アピールを書かないと職務経歴書が寂しくなる」というなら、それはまだ転職の準備が整っていないのかもしれません。

●おそれることなく進め非コミュ

　というわけで、Web系企業を目指すなら「コミュ力アピール」を捨てて「問題解決能力アピール」を目指しましょう。

　人と話すのが苦手な人は、ちょっと訓練が必要かもしれません。どのみち、書類審査を通過すると面接が待っています。そういうタイプの人は、IT系の勉強会に参加して訓練してみるといいかもしれません。

　最低限の常識を持ち、人を不快にさせることなく相手の言うことを理解し、自分の考えを伝え、合意を形成する。まずはここを目指してみてください。

幻想を捨てろ

　最後は一番の強敵、「Web系企業への幻想」を捨てましょう。

　志望動機でよく見掛けるもののうち、この「幻想」にまつわるものをいくつか挙げてみましょう。

技術レベルの高い環境で働きたい
作って終わりではなく、愛着を持って継続的に開発したい
ユーザーの声を直接聞ける仕事がしたい

　さて、1つずつ見ていきましょう。皆さま、幻想を打ち砕かれる覚悟はできましたか？

●パレートの法則と向き合えますか？

　まずは技術レベルについて。

　「パレートの法則」をご存じでしょうか。最も有名なのは「働きアリの20％はさぼっている」というお話です（知らない方はさくっとグーグル先生に聞いてみよう！）。

　法則というよりは経験則からですが、私は結構信じています。では、エンジニアの集団に当てはめてみましょう。

　エンジニアが複数いるとして、一定以上のレベルで優秀なのは全体の20％程度。残りの80％の人は凡庸の能力しかありません。さらに凡庸の80％を見てみると、許容できる程度に凡庸なエンジニアが80％（つまり全体の64％）。残りは、凡庸というレベルにすら及ばない、ひょっとしたら「マイナスの生産性」を発揮してしまうかもしれないエンジニアです。

　つまり、優秀なエンジニアだけが集まる「神の国」のように見える企業でも、内実はそんなもの、と思ってください。「あの企業に行ったら優秀なエンジニアにもまれて成長できるに違いない！」という幻想は、できるだけ早く窓から投げ捨てましょう。

●レガシーコードと向き合えますか？

　次に、自社サービスのダークサイドについて。

　サービスがユーザーに受け入れられ、利益が出るようになると、継続的に運用や追加開発を行うことになります。「自分が作ったものに愛着を持ちたい」という気持ちがある人には、とても魅力的な特徴でしょう。

　しかし、別の側面から見ると、これは「同じコードベースをメンテナンスし続ける」ということでもあります。そういうシステムは大抵、程度の大小こそあれ「レガシーコード」になります。

　あなたの前任者はOOPを理解していたでしょうか？ユニットテストを書く習慣があったでしょうか？適切な名付けができていたでしょうか？最低限のドキュメントを作っていたでしょうか？そうではないコードを引き継ぐ場合、その日からレガシーコードとの飽くなき戦いが始まります。

　また、すでに動いているサービスのアーキテクチャを刷新するには、大変な困難が伴います。サービスの停止が許容されますか？安定して動きますか？習熟しているエンジニアはいますか？そしてなにより、経営的な視点から、アーキテクチャを刷新するコストを認めてもらえますか？納品して終わりの受託開発では、顧客から検収印をもらえば、そこでコードたちとはお別れです。デキのいい子と別れるのはつらいでしょうが、残念な仕事との関係をリセットできるのはメリットなのです。

　あこがれのあのサービスは、とんでもないレガシーコードの山かもしれない。今をときめくこのサービスのプラットフォームも、「うちのソースは汚い」と中の人が断言しているかもしれない。

　サービスの魅力とコードの魅力を混同する気持ちも、ぽいっと投げ捨てましょう。

●本当の顧客と向き合えますか？

　コミュニケーションのところで少し触れた「エンドユーザーの声」についても少しお話ししましょう。

　「ユーザーの声を直接聞ける」。確かに魅力的な環境です。苦労して開発したプロダクトが、エンドユーザーの役に立つ。その結果として対価を支払ってくれたり、感謝の声を聞かせてくれたりする。エンジニアをしていて、一番嬉しい経験です。

　では、プロダクトがエンドユーザーの期待を満たせなかったら？届くのは、容赦ない罵倒です。本文に「死ね」と100回書いてあるメールなどが、ユーザーサポートの窓口にはしょっちゅう届きます。エンドユーザーの期待や愛着が大きいほど、裏切られたときの反動も大きくなります。人気サービスを運営している企業には、「死ね死ねメール」や「おたくの社員に危害を加えます」という物騒な予告の手紙が届くこともあります。また、Twitterや2ちゃんねるなどソーシャルメディアにも、酷評が書かれることは珍しくありません。

　こういう罵倒や酷評も含めて、本当の「エンドユーザーの生の声」なのです。「毎日感謝の声が届くからモチベーションがうなぎ上り！」という幻想も捨てましょう。