S、A、B、C、Dの中でどれを一番多くピックアップしたか?

水上廣敏氏(以下、水上):ここから結果に入っていくわけですが、5つのタイプに分類します。今までS、A、B、C、Dをそれぞれ選んできてもらったと思いますが、4問あったうち、自分がピックアップしたのはどれが一番多いか、数を数えてほしいんですね。

複数選んでいて同率がある人もいるかもしれないですね。BとCが同じ個数でしたという人もいるかもしれません。そうしたら両方ですね。

いろいろなパターンがあると思いますが、これから5つのタイプをそれぞれ説明します。もちろん一番多かったタイプを気にしてもらいたいのもありますし、多くなかったとしてもピックアップされたところは、自分がその要素をちょっとは持っているかもしれないと考えて聞いてもらえればと思います。

あとは、この選択肢は選択していなかったなというものに関しても、まったくないというわけではないと思いますし、たまたま選ばなかっただけで、私の質問の仕方が悪かっただけかもしれません。なので他のことに関してもチェックしてもらえたらなと思います。S、A、B、C、Dの順でそれぞれ紹介していきますね。

タイプSはチームワークや人とのつながりを大切にする人

まずはタイプSからいきます。回答していた方はなんとなく気づいたかもしれませんが、タイプSは、けっこうチームワークや人とのつながりを大切にするタイプなのかなと思います。

いわゆるアジャイルのスクラム開発で言うと、スクラムマスター的な、そういうロールがもしかしたら適している方だと思うんですね。当然チームワークを大事にしますし、エンジニアだからものを作るわけですが、それはやはりみんなで作りたい。みんなで楽しく作りたいというのを重要視する人だと思います。

あとは、例えばシステム開発の場合だと、いつかはシステムリリースをすることになるわけですが、「ヤッタァ」と盛り上がって、このコロナ禍だとなかなか難しいかもしれませんが、みんなで飲み会をするのをすごく期待している人とかね。

やはり人情味があるでしょうし、面倒見がよくて、交渉上手だったり。そういうのが得意なタイプかもしれません。いずれにせよ、けっこうマルチに活躍できる素養を持たれている方なのかなと思います。

何度も言うように、勝手に僕が言っているだけですからね。本当にそうかどうかはわかりませんが、僕はそう思います。

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

では、この人がどんなキャリアを積んでいくことになるか。想像で書いていますが、当然ながらさまざまなシステム開発をこなしていくことになるので、きっと自分の下にチームを作っていくわけですね。なので最初は数名から始まって、それがちょっとずつ大きくなっていくのが想像できます。スクラムなのでそんなに大きなチームではないかもしれませんけどね。

あるいは、規模がどんどん大きくなって、プロジェクト全体を任される人になっていくイメージがあるのかなと思います。

では、そういう人はどんなところで活躍していけそうか。やはりデリバリをスクラムマスターみたいな立場でやっていくわけですから、いわゆる開発プロセスそのものを決めたり。チームメンバーを大事にしている人ですから、チームメンバーが楽しく有意義に過ごせるやり方は何だろうと考える人なんだろうなと思いますね。

あとは、もちろん管理そのものが大事なので、「みんな好き勝手にやってくれ」というふうにやれればいいですが、やはり結果を求められるので、そんな中でどう管理するかをすごく気を遣ってやっていくかたちになるでしょう。

あと、チームメンバーが作っているものをしっかりとレビューすることも大事ですし、お客さんやプロダクトオーナーと折衝することもあるでしょうね。

というようなかたちで、この人たちはこんなキャリアを積んでいくのかなとなんとなく思います。

タイプSの注意点

注意点が1点あります。このタイプの方が仮に管理系になっていくと、そっちに寄っていきがちなんですね。「やはりみんな大事だから管理しないと」となって、エンジニアなのに技術をちょっと横に置いて、そっちに注力しちゃうと、個人的にはあまりよくないかなと思うんですね。

やはり技術そのものは大事ですし、それを基にシステム開発をしているわけですから、技術そのものはしっかりとキャッチアップを進めながら、管理は管理でもちろんしっかりしていく感じで進むといいのかなと思います。

タイプAはアーキテクト的な人

次はタイプAです。先ほどコメントで、「Aはアーキテクトかな」とか言っている人がいましたが、そのとおりですね。タイプAのあなたは、アーキテクチャを気にする人なんじゃないかなと思います。

アーキテクチャを気にするタイプ。ロールで言うと、それこそアーキテクト的な人になっていくんだと思います。やはりそういう人は、タイプ的には、シンプルで美しい仕組みって何なのかなと追求したくなりがちです。

あと、当然技術が大好きですよね。その技術力でいつまでも尖っていたいと思うタイプです。僕は、意外とアートな感覚がアーキテクチャには必要だと思っていて、僕自身けっこうアーキテクトとして活動しているところもあります。アートな感性を持っている人もけっこう多いんじゃないかなと僕は思いますね。

意味的にアーキテクチャって、IT業界だけで使われる言葉ではありません。やはり構成美ってあると思うんですよね。建築でもアーキテクチャって使いますし、アーキテクチャおよびシステムに求める美しさって、わかる人にはわかると思うんですが、そういう感性も大事にする人だなと僕は思います。

一方で、これは僕自身がそうなんですが、コミュニケーションが得意じゃない人が多いんじゃないかなと思います。人と話さなくて済む世界があるのであれば、それに越したことはないみたいな、そういう人も多いんじゃないかなと思います。

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

そんな人は、どんなキャリアを歩んでいきそうかというと……エンジニアですから、みんなと同じようにシステム開発をするのですが、自分の書いているコードが美しくなきゃ気が済まないタイプだと思うんですね。

コードをいかにきれいに書けるかを気にしてやっているんですが、自分だけではなくて、システムを全体的にもっと美しくしたくなるのがこのアーキテクトタイプの人だと思います。

もちろんアーキチームみたいなところにいて、システム、プロジェクト全体の仕組みや品質を担うような役割になっていくでしょう。自分にとって技術的なチャレンジを繰り返していく中で、いわゆるアーキテクトとしてより高度な案件を任されるようになっていくキャリアが想像できるんじゃないかなと思いますね。

そういう人にとっては、どういうところが活躍の場なのか。技術力があるから難しい実装は「あのー、お願いします!」とだいたい回ってくるんですよ。そういうふうに、みんなから技術力を頼られるのがまんざらではない。「そうやって頼ってきやがってー」とか思いながらも、意外とまんざらではないタイプです。

あと、先ほどから言っているように、なるべく効率良く、品質良く作る。どうやったら作れるか、どういうアーキテクチャだったらいいかというのを考え出す。これってもう何十年も前からずっと追求されているシステム開発の永遠の課題だと僕は思っているんですが、その沼にハマっていくのがこのアーキテクトタイプの人なんだろうなと思います。

タイプAの注意点

この人にも注意点があります。そういうふうに技術畑でやっていくと、いわゆる研究に集中しがちになります。それは、なるべく避けたほうがいいんじゃないかな、と僕は思いますね。

やはり現場で使える技術でナンボみたいなものが当然ながらあると思うんですよね。いくら技術を研究していても、現場で将来にわたって使える技術じゃないんだとしたらあまり意味がないんじゃないかなと思います。そういう研究だけで済まさずに、しっかり現場で活かせる技術って何だろうね、そのためにはどうしたらいいんだろうねという発想になるほうがいいんじゃないかなと僕は思います。

タイプBはビジネスが気になる人

次は、タイプB。これが多かった人はいたかな? Bは、ビジネスのBですね。エンジニアを軸にしているんですけども、作っているビジネスがどうしても気になっちゃう。サービスというのが気になっちゃう人がこのタイプBなんだろうなと思いますね。

だから当然、どういう技術で作っているかも気になりますが、それ以上に、このシステム、アプリケーションは、どこのビジネスでどういうふうに役立っていくんだろうという点をすごく気にしちゃうタイプです。すごく重要なことだと思います。当然ながら、その気になっているビジネスを、どんどん深堀りしていくようなタイプなんだろうなと思います。

ITというのは、あくまでそのビジネスを実現するための道具であるという考え方も当然あると思うのですが、そういうのがタイプBと呼べる人なのかなと思います。

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

ではその人はどんなキャリアを歩んでいくのか。エンジニアなので、エンジニアとしてシステム開発をしていくと、先ほど言ったとおり、そのビジネスやサービスそのものが気になり出しちゃうんですね。そこに興味が移っていくわけです。

なので、ビジネスのことを研究したり勉強したりし始めるのですが、根はエンジニアで、システムそのものをよく知っているので、この人はビジネスとシステムの両方をよく知っている存在になっていくんだと思います。いわゆるビジネスアナリスト的な存在と言うんですかね。

(スライドを示して)「オレオレビジネス」と書いてありますが、別に揶揄しているわけではありません。世の中のビジネスは実際、ほとんどがいろいろな制約や制限がある中で、みなさんサービスを展開していると思います。

そんな中で、「いや、ビジネスの理想はこうなんだけどな」とか、「このビジネスには、こういうシステムを組めるほうが本当はいいんだけどな。だけどいろいろ制限があって、なかなかそううまくはいかないな」みたいな考え方をする人だと思うんですね。そういう人がそのまま経験を積んでいくと、マジでビジネスもシステムも詳しい人間として育っていくわけなので、その世界の生き字引的な存在になると僕は思います。

では、そういう人はどういうところで活躍できそうか。そうやってビジネスやサービスの内容を押さえている人ですから、当然ながら業務要件とかを押さえることになります。

システム開発によってどういうところで役立つかというと、テスト。こういう要件を満たすためにこういうテストが必要だというのが、この人は最初から頭に浮かべられるわけですよ。

最近、話題になっているBDD的な、振る舞い的な、ビヘイビア的な開発手法にとっても重宝されるわけですね。システムを組む前から、なんならテストケースが出せちゃう人で、こういう人がいないとBDDはできないと思います。そういうところにとても役立って、品質を担保できる人になっていくんだろうなと思います。

ほかにも、例えば、最近DXといっていろいろな会社さんが「変革しないと!」となっていますが、今までやってきたビジネス以外のサービスを提供して、変革をどうしていこうかと悩まれるケースはけっこう多いんだろうと僕は思っています。

そういった時に、こういう方がすごく役に立つわけですよ。そのビジネスを進めるためにイチからシステムを作ります。でもやったことがないのでビジネスのことも知っている人が必要ですと、システムもビジネスも両面必要な人が求められるので、その人が新しくチャレンジしようとしているビジネスを押さえていれば、大活躍をすることになっていくのかなと思っています。

タイプBの注意点

この人にも注意点があります。これはあくまで、ビジネスもシステムも両面押さえているからすごく価値があるわけで、ビジネスだけ押さえていると、俗にビジネスコンサルチックになっちゃいます。別にビジネスコンサルを否定するわけではありませんが、我々はエンジニアを目指したいわけですから、やはりエンジニアでありたいですよね。

なので、もの作りとかエンジニリングそのものはしっかりと押さえたうえで、ビジネスというものをキャッチアップしていくといいのかなと僕は思います。

(次回へつづく)