アクセンチュア・水上氏が贈る、エンジニア人生のヒント　キャリア形成のポイントは、自分のタイプをいかに導き出せるか　

タイプCはロジカルに物事を考える人

水上廣敏氏（以下、水上）：次は、タイプC。タイプCのCは何だと思っていましたか。実はコンサルティングのCですね。「エンジニアだって言っているのにコンサルティングかよ」って思っている人もいるかもしれませんが、意外とこういうタイプの人っているんですよね。

このタイプの人は、いわゆるロジカル的な物事の考え方をする人なのかなと思っています。先ほど理詰めしちゃいがちという選択肢があったと思いますが、まさにそういう人がこのタイプなんだろうと思いますね。

エンジニアなので、ものを作ることはとても好きだと思いますが、やはりどういう構成で作るかを考えて、その構成をいかに効率よく作るかというところに主眼を置きがちな人だと思います。

なので、自分自身に知識や経験がなかった場合は、やはり事例をすごく大事にしたがる人だと思うんですよね。自分はわからないから世の中どうなっているんだろうと調べにかかる人がこのタイプの人なんだろうなと思います。

そういうタイプはどういうキャリアを歩むのかというと、まずはエンジニアですから、他のタイプと同じように開発を中心にやっていくわけですが、そんな中で、テックコンサル的な役割を求められるシチュエーションがきっと出てくると思うんです。

わかりやすいのが提案をする時。業務部門やお客さんに提案をしようとした時に、「こういうことをやりたいと思います」とまとめに入るわけですが、それが今まで自分が経験したことから導き出せればいいのですけが、提案はなかなかそういうわけにもいきません。

システム開発だけしてきた人間には「うーん、どうしたらいいんだろう」みたいなことがけっこう多かったりします。そういった時にちょっと痛感するんですよね。「システム開発の今までの知識だけではちょっと足りなかったのかな」と。

それをきっかけに、事例をいっぱい調べるわけですよ。「ああ、こういう事例でこういうふうにやっているところがあるんだ」というのをいっぱい調べて、自分の情報としてインプットしていくと、今度は事例そのものに興味が移るわけです。

「この事例ちょっとおもしろそうだな」とか「こんなふうにやっているんだ」とか「クラウドをこういうふうに使っているんだ」みたいな感じで、事例をどんどん深掘りして調べたくなるタイプです。

タイプCのキャリアと活躍の場

そういうことをやっていくと、業務部門やお客さんとの折衝する時間がすごく増えて、お客さんに納得してもらわなきゃいけなくなってきます。納得してもらうためには説得していくことが必要になりますが、一番説得力があるのがロジカルにお話しすることなので、ロジカルシンキング的なことが身に付いていくというのが、キャリアとしてイメージできるのだろうなと思いますね。

そういう人はどういうところが活躍の場になるのかなというところ。さっきもお話ししたとおり、そういう自分の経験と周囲の事例を基に提案に活かせるところがもちろん活躍の場です。

設計したりコーディングしたりすることも当然好きなんですが、こういうタイプの人はそれよりもちょっと分析タイプだと思います。だから「テストの結果がこうだったということは……」みたいな分析に走りがちなんじゃないかなと思います。なので、「もしかしたらこういう機能にもバグが残っているかもよ」とか「こういうパフォーマンス、こういう負荷には弱いかもよ」とか、そういうのを分析しがちな人なんじゃないかなと思っています。

あとは、そういうタイプの人って社内でも非常に重宝される立場になっていくんだろうなと思います。いろいろな人が相談に来るでしょうし、結果、その人にいろいろ情報が集まってくるようになるのかなと思いますね。

タイプCの注意点

この人にも注意点があります。そういうふうに事例をいろいろ調べたりしていると、エンジニアとはいえ、自分で手を動かす機会がちょっとずつ少なくなっていく可能性があるわけですね。

そうすると今度は、自分で手を動かしていないから評論家っぽくなっていくんですよ。やはりエンジニアですから、僕は自分で手を動かしてナンボだと思っているんです。評論家みたいになってほしくはないんですね。

なので僕はいまだに、コーディングをしたりソースコードを読んだりとかしています。このタイプの人は、ちょっとなりがちな気がするので、そういう現場感を忘れないようにしてほしいですね。

タイプDはデザインや見た目にこだわる人

最後に、5個目のDですね。Dは何かわかったかな？　見た目を気にするとか、そういう設問が多かったと思いますけども、デザインのDでしたね。

こういうタイプの人はエンジニアですが、やはりデザインや見た目をすごく気にする人です。僕もこういう一面は持っていると思っていて、モバイルアプリがとにかく大好きですね。

やはり見た目も大事ですし、機能的な美しさもすごく気にする人だと思います。

あと「hogehogeビリティ」みたいな言葉がたくさんありますけども、「その中で一番好きな言葉は何ですか」と聞かれたら、悩まずに「ユーザビリティ」ってきっと答えるでしょうね。あとは色合いね。色合いにもすごくこだわる人なんだろうなと思います。

タイプDのキャリア

そんな人はどんなキャリアになるのか。エンジニアがベースですから、エンジニアとしていろいろ開発をする中で、画面を自分で作ったり設計したりしていくうちに、デザインそのものに興味が移っていって、それを研究し始める感じになると思うんですね。

システム開発そのものだけではなくて、例えばWebアプリだったら、このWeb系のコーディングだけじゃなくて、UI／UXそのものを勉強したり。SketchとかInVisionとかをご存じの方もいると思いますが、きっとああいうUIデザインツールみたいなものの勉強も始めちゃうわけですね。

そのうち、このUI／UXエンジニアとしてモバイルアプリを中心とした開発に携わることになって「見た目も大事だし、使い勝手もやはり大事。システムというかアプリは使われなきゃ意味ないもんね」ということで、UI／UXが鍵となるような案件をどんどん任されるようになっていくような人になるのかなと想像します。

タイプDの活躍の場

そういう人がどういうところで活躍できるかというと、当然ながらWebアプリやモバイルアプリの開発には欠かせない存在ですね。UI／UX重視案件は意外と多いと書いてありますけど、実際にそうです。

例えば業務アプリみたいなものも、一昔前は、本当にそんなデザイナーなんて人はいなくて、エンジニアが作る無機質な画面になりがちな時代もありましたが、最近は、見た目も使い勝手もやはり大事だと言われることが多いです。なので、使い勝手がちょっと違うだけで生産性はぜんぜん変わってくると思います。

なので、そういうのを大事にする案件で非常に重宝される人ですね。言い換えると、最近のシステム開発にはこういう人の存在が必要になるのかなと思いますね。

ポイントは、ただのデザイナーではなくエンジニアなので、自分でモノが作れちゃうわけですよ。だからデザインしてお絵描きみたいなことをするだけではなくて、実際のモバイルアプリにこうパパパッとできちゃう人が活躍できる場なんだろうなと思いますね。

別にそこを目指しているわけではないでしょうが、ゆくゆくはモバイルアプリやWebアプリの画面のデザインだけではなくて、それにまつわる広告とか、そういうのも担当されることになるのかな、となんとなく思いますね。

タイプDの注意点

ちなみに、この人にも注意点があります。最近エモって言いがちですが、このタイプの人には、エモっぽいことが好きな人が多いかなと思います。「エモハラ」という言葉もありますが、あまり言いすぎるとそういう話にもなりがちなので注意していきましょう。

これで5つ説明が終わりましたけど、みなさんどうでしたか。「なんとなく当たっているかもな」という人もいたようで、すごくうれしいですし、「なんとなくよくわかんないな」みたいな人もいたかもしれません。それぞれ、こんなキャリアを歩むのかなという僕の勝手な想像で書いていることがほとんどなので、そう思ってもらえればなと思います。

7〜8年目の時はソースコードのきれいさと道具にこだわっていた

ここでは、私の場合は今までどうだったのかというのを、せっかくなのでちょっと紹介したいなと思います。恥ずかしながら数年にわたる写真が残っていました。特にインタビューで撮られた写真をもとに書いています。

一番左上が若い時代ですね、7〜8年目ぐらいの時の写真です。この当時はタイプで言うとAとかDとかを気にしていました。

冒頭でご紹介したとおり、僕はプログラミングに少し自信がある状態で入りました。その自信が本物だったかどうかはちょっとわかりませんが、そういう状態で入ってきたので、とにかく自分が作るソースコードがきれいでなければならないという信条のもとで書いていました。

それこそ自分が作るものだけではなくて、周りの人が作っているソースコードもきれいでないと嫌でした。この時はまだまだ駆け出しで、「あなたのソースコードを直してください」なんて言える権利もなかったので、人知れず自分が書き直しているみたいな、そういう時代でした。

この時は、僕はすごく道具にこだわっていた時代ですね。みんなもご存じだと思いますが、プログラマー向けのちょっと高いキーボードがあるじゃないですか。あれはけっこう歴史があって、僕が若い頃からありました。PS／2接続でしたが、ちょっと高かったけれど当時奮発して買って「俺、道具にこだわるぜ」みたいなことを気にしていた時代です。

行き着いた先は「プロは道具を選ばない」という考え方

ただ、これにはその後逸話があります。その後、結局道具にこだわらないのがプロなんじゃないかというところに僕は行き着いたんですよ。

当時は、いろいろな現場でサーバー構築をしたり、そのお客さんの端末を触らせてもらったりしていて、そこに毎回毎回自分のキーボードを持ち込むわけにもなかなかいきませんでした。ルール的なこともありますが、そもそも僕は移動する時になるべく手ぶらで移動したい、荷物を少なくしたい派なので、キーボードは小さいとはいえさすがにかさばるのでキーボードを持ち歩くのを断念しました。

僕のキーボードのこだわりは英字配列で、Aの隣にCtrlがないと嫌なタイプなんですが、そんなキーボードは日本にはあまりありません。やはり現場だと、日本語のキーボードが多かったりします。Ctrlも「あぁ、ここにCtrlがあるのか」みたいになることも多かったです。

だけどプロだったら、道具を選ばずなんでも使いこなせる状態でないといけないんじゃないかと勝手に思い、その後は気にせず「どんなキーボードでも使い倒してやるぜ」みたいな方向に変わっていきました。そんな時代でした。

タイプDも強く、UI/UXを崇拝していた

あと、タイプD的な観点もこの頃はありました。時代的にはクライアントサーバーが全盛の時代です。いわゆるクライアント、PCにアプリをインストールして、そのアプリから直接サーバー、ここでいうサーバーとはデータベースのことですが、直接データベースにアクセスするようなスタイルのシステム構成です。

端末はだいたいWindowsなので、当時はWindowsアプリを作っていたんですね。自分でデザインと言うと大袈裟ですが、でも自分でWindowsアプリを作り出していました。

当時Microsoft社の『Windowsユーザーインターフェイスデザインガイド』というのがすごくよくできていて、どういうふうにボタンを配置するべきなのかとか、メニュー構成はこうすべきだとか、いわゆるUI／UXの基礎となるようなことが盛り込まれていたんですね。これは今版のものがWebで見られます。

これに僕はすごくハマりました。使い方も、使い勝手も標準化が大事だなと気づかされたし、この頃はそういうことをすごく意識していた時代です。

10年を経過した頃に、チームやビジネスを意識し始めた

次に右側に移ります。10年ぐらい経ってきた頃ですかね。自分のチームや、自分のお客さんができてきた時代ですね。やはり自分のチームができてきたこともあり、タイプで言うと最初のSとか、あるいはビジネスのB的なところを意識し始めた時期ですね。

やはり自分のチームのメンバーに、いかに効率よく開発してもらいたいかが大事だし。その人たちにどう育ってもらいたいか、どうやって育てていくのがいいのかということを考えたりもしました。あとは、このチームをいかにスケールさせていくかということも気にしていた時代ですね。

あとはタイプB的な要素だと、先ほど言ったように、自分の担当のお客さんができてきた時期でした。確か、結果的に6年間ぐらいずっとそのお客さんの担当をすることになりました。その時に、やはりそのお客さんのことを本気で考えるんですよね。「このお客さんに本当に必要なサービスって何だろう」と本気で考えましたし、そのためにこのシステムはこうあるべきだと考えていた時代です。まさにタイプB的な要素がこの時はあったんだろうなぁと思います。

最近は提案の相談を受けることが増えてきた

下に行って、最近に近い状態だと、もともと根がアーキテクト的なところがきっとあるんでしょうね。いわゆるアーキテクトとして活動することにもなって、より高度なアーキテクチャやプログラムを求めます。

でも高度なだけだと、みんなができるわけではないんですよね。作る人によっていろいろレベル感があります。なので、誰もが高品質でできる世界というものも作り出さなければいけないし、それだけだとつまらないので、高度な世界も残しつつというこのバランスね。というのを求め出すようになったのは最近かもしれません。

あとは、最初にも言いましたが、僕は若い頃からなるべく他の人がやっていないことをやりたがる人なので、いまだに、なるべく誰もやっていない、ちょっとリスキーなやつのほうに僕は惹かれます。これはタイプA的な要素かもしれません。

実は、タイプC的な要素も最近出てきました。経験が長くなってきたからだと思いますが、いろいろな人たちから相談を受けるようになってきました。「こういう提案で悩んでいるんだけど」みたいに、いろいろと持ち込まれるわけです。

自分の経験や知識で答えられることもあれば、「いやぁ、それはちょっとやったことねぇなぁ」みたいなことも正直あります。なのでさっきの話ではありませんが、やはり事例がすごく大事になってきて、事例を一生懸命調べるようになりました。

「その提案をするのに一緒に同行して説明してください」みたいな、そういう機会も増えてきました。お客さんを説得する機会もすごく増えてきたし、先ほども言ったとおり、理論的にお客さんを説き伏せるというか、納得してもらう必要があるので、そういう手法も覚えてきたのかなと思います。

ただ僕は、資料作りはあまり得意ではないので、そういうのは他の人にお任せしています。振り返ると、凸凹はありますが、僕はSからDまで全部の要素を持っているんじゃないかなと思います。

みなさんも、「これだけ！」という人はたぶんあまりいなかったんじゃないかなと思います。「他も要素としてあるかもな」みたいな人が多かったのかなと思いますし、それぞれみなさんそういう要素があるのかな、と思います。

周りにいるそれぞれのタイプを紹介

僕の周りにも、それぞれ「ああ、Sっぽいな」とか「Aっぽいな」っていう人がたくさんいます。いろいろ紹介したいなと思ったんですが、時間がなくなってきたのでざっといきます。

特徴的なのはBかな。Bの人は、先ほどもお話ししましたが、ビジネスやサービスを突き詰めていく人です。でもエンジニアなんですよね。

僕の知っている人の中で一番Bっぽいなという人は、けっこうご年配の方なんですが、金融系の業務にずっと携わっている人です。その人は銀行系の担当の方なんですが、銀行の中身を全部知っているぐらいの業務知識を持っています。

だけど根はエンジニアなんですよ。この前一緒に銀行系のシステムを作りましたが、その時にその人の知識がすごく役に立ちました。その時はちょっと新しめで、Go言語を採用して開発しました。

ご年配の方なので、当然Go言語もよくわからないのですが、「俺はGo言語を今から勉強するから。お前らが作るソースコード、俺がチェックするからさ」みたいなことを言っちゃう人ですね。まさにBタイプの人。

あとは、Dですね。DはDでやはりいます。一緒にお仕事した時に、デザインとデザイン周りの画面開発をしてもらったのですが、「こういうデザインがいいっすかね」みたいなやり取りをして、「なんかちょっと違うな、こういう感じなんだよね」みたいに、イメージでお話ししたら、「ちょっと待ってください」と言って自分のスマホを取り出してワァァァって「こういうイメージですかね」と、その時に自分がインストールしていたアプリの中から、僕が言っていたイメージに近いアプリを探し出してくれました。

「そうそう。そういう感じ」、そういうふうにしてねと言ったら、「じゃあちょっと今作っちゃいます」とか言って、モックのアプリをバーッて作り出す人もいました。他にもいっぱい事例がありますが、そういう感じで僕の周りにもたくさんいるのかなと思います。

自分のタイプを理解して歩みたい道をしっかりと見定めていく

というわけで、ざっとお話ししてきましたが、話をひっくり返すようで申し訳ないのですが、この5種類はすごく無理やり導き出したタイプです。エンジニアってここにざっと挙げていますが、hogehogeエンジニアって本当にたくさんいると思います。

みなさんが目指されているエンジニア像もそれぞれあるのかもしれませんが、今日紹介した5つのタイプを少し参考にしてもらうのももちろんよいですし、それこそ5つの掛け合わせみたいなものもあります。あとはやはり自分なりのタイプをいかに導き出せるかみたいなのもあるような気がするんですよね。

先輩がこういうかたちで育ってきているから参考にしようというのも大事ですが、それだけではありません。やはり自分が歩みたい道をしっかり自分で見定めて進んでいけるといいのかなと思います。

質疑応答

というわけで、時間がなくなってしまったのですが、質問が1個来ていますね。時間がないのでちょっとだけお答えします。

「以前、それこそタイプBのようなことをしていきたいと言ったら『それは中途半端じゃないか』と言われてしまったけれど、実際はどうなのだろうか。中途半端な存在で終わってしまうのか、システムだけ、ビジネスだけにならない色が出せるのか」という質問です。

中途半端になりがちといえばなりがちなのかもしれませんが、中途半端にならないようにするのが大事だと思います。やはり突き詰める。これがすごく大事です。タイプBに限らず、その世界を突き詰めるというのが、僕はすごく大事だと思うんです。ビジネスのことがやはり気になる、サービスのことが気になるというのは、すごく大事なことなので、それを突き詰めてほしいんですよね。

どうしたらこのビジネスをよくできるのか、どういうアイデアが必要なのかみたいなことは、突き詰めて考えてこそやはり活きてくるし、そうしたらぜんぜん中途半端じゃないと思います。そういうふうに意識してもらえるといいのかもなと思いました。

というわけで、ちょうど時間になってきたので、私の話は以上とします。みなさんの今後のエンジニア人生のヒントに少しでもなればと思います。ありがとうございました。