働いてみないとわかりにくいIT業界の構造　SI系・プロダクト系それぞれで異なる“求められる能力”と“キャリアパス”

ウイングアーク１ｓｔ・CTO　島澤甲氏

島澤甲氏：みなさんこんにちは。私はウイングアークでCTOをしている、島澤と申します。このセッションでは、これから技術者を目指されているみなさんに対してなにかヒントになるようなものを伝えられたらいいかなと思っています。

（スライドを示して）まずウイングアークですが、私たちは、帳票やBIと呼ばれるところでトップシェアを占めています。今日は、「このセッションは会社の宣伝をしなくてもいいよね」という話をしたら「別にかまわん」ということだったので、会社の宣伝はもうしません。気になる方はちょっとホームページを見てもらえればと思います。業績などもありますが、順調であるということぐらいにしておきましょうかね。

（スライドを示して）私は猫がすごく好きなエンジニアで、今はCTOをやっています。ちょっとキャリアをお伝えすると、私は学生時代は実は化学の専攻で、ITの専攻ではありませんでした。遺伝子解析が好きでずっとやっていて、特許になったりしたのですが、化学系の会社にはまったく行きませんでした。

今になると1社目は、独立系ベンチャーのちょっとブラックな会社だったかなとは思いますが、SI系の仕事に行って、2社目もSI系に行って、2008年からウイングアークに入って、アーキテクトとして製品開発をけっこうバリバリやっていました。当時は多い時だと月のソースコードの生産量が10万行近くいっていたかなと思います。それから情報系全体の製品の統括で、それからCTOになって今に至るみたいな、私はこんなキャリアです。

同じIT業界でも仕事をする相手・求められる能力・キャリアなどは違う

さて、みなさん、今日ここに来られている方はエンジニアを目指しているんだと思います。私がいざエンジニアになって、いくつか後悔というか、「ちゃんと考えておけば良かったな」というのがあるのですが、このIT業界はまず構造がけっこうわかりにくいんですね。

たぶんみなさんは今エンジニアとしての岐路に立たされているんじゃないかなと思います。私が最初に勤めたSI系があったり、今私が勤めているウイングアークのようなプロダクト系があったりするのですが、まずそもそも、ITのビジネスはSIかプロダクト系かでビジネスモデルもぜんぜん違うんですね。SI系は独立系、メーカー系、ユーザー系みたいなものがありますし、プロダクト系も、パッケージ、SaaS、こんな感じで分かれているかなと思います。

ここからが重要なのですが、実は仕事する相手がけっこう違うんですよ。独立系だったらお客さんの要求にダイレクトに応えて、メーカーだったら本業があるので、そちらの要求に応えます。プロダクト系だったら業務や市場課題に応えます。こんな感じになってくるわけですね。

当然得られる能力も違います。独立系であれば、これも一次請けなのか二次請けなのかによってけっこう違うのですが、顧客との折衝力や、システムの設計、開発というところだし、メーカー系の場合は自社製品の知識も重要ですね。ユーザー系も同じような感じでしょうか。プロダクト系だと、実はSI系とはまったく違う能力が求められて、ビジョンをどう設定するか、課題をどう設定するか。こんな感じで、けっこう仕事が違うんですね。

当然キャリアも違います。SI系は多くの場合はプログラマーから始まって、SEになって、プロマネを目指そうという感じが多いかなと思います。プロダクト系は本当にいろいろなキャリアがありますが、エンジニア一本でいくことができる会社もプロダクト系のほうが多いんじゃないかなと思っています。私たちはプロダクト系なので、（スライドの）右側になります。

これは同じ系統でも、本当に会社によっていろいろなパターンがあるので、みなさんも会社選びで、自分がどこを目指しているのかなみたいなのは考えてみてもいいかなと。私は20年ぐらい前に新卒でしたが、20年前の自分に言ってやりたいと思います。

私たちはプロダクト系としてやっていますが、ウイングアークのおもしろいところは顧客の未来を考えているところですかね。自分たちの課題や顧客の課題など、自分たちが「これがいいんじゃないか」と思うところを考えて、それを実際に企画してみて、お客さんにぶつけています。

プロトタイプを試してもらったり、イベントで見てもらったりして、製品として開発して、市場にぶち込んでいきます。それを基にお客さんの声をどんどん製品に反映させて、また最初に戻るというサイクルでやっているんですね。自分たちの仮説に基づいてものづくりを行っていくところが私たちの仕事のおもしろいところかなと思っています。

トピックスとして重要になっている生成AI

ということで、ちょっと前振りをしましたが、今日の本題にいきましょうか。「エンジニアに求められていく技術とはいったい何なのか」というところですね。

（スライドを示して）これは言うまでもないことですが、当然ながらソフトウェアを作る開発技術力は必要です。私たちもやはりコアコンピタンスとなる技術を持ってこの市場で闘っています。少しだけデモンストレーションをお見せしましょうか。

（スライドを示して）今からお見せするのは、超大量データの集計です。今画面に表が出ていると思うのですが、何年何月どこで何が売れたかみたいなデータがあります。これは1ページに100件ぐらいしかないわけですが、仮に1,000億件あったとしたら、どのくらいの速度で集計できるのか。時間もないのでさっさとやってみましょうか。

今は1,000億というデータに対して集計を開始しました。通常のRDBだと、これは物によりますが1週間ぐらいかかる可能性があります。私たちのエンジンだと今は6秒ぐらいですかね。これはキャッシュも使わずに1件目から1,000億件目までを全部集計・計算して、こういった結果を得られるようになっています。

この速度というテーマは、やはり会社の地力が試されるので、私たちは「ウイングアークだからこれができるよね」というところで、こういった基礎技術力みたいな開発技術力を磨いています。これは、みなさんもそんなに違和感がないんじゃないかなと思います。

（スライドを示して）そして、私たちにとっても最近は生成AIがトピックスとして本当にすごく重要になっています。私たちは自分たちでどんどん新しいものを作れる会社なので、実は今、「ChatGPT」と私たちの製品を組み合わせていろいろなことをやれるようにしています。ちょうど今月リリースする（※登壇当時）プロダクトがあるので、ちょっとだけ紹介します。

ChatGPTはもう説明は不要ですよね。私たちの「Dr.Sum」は、先ほどお見せしましたが、高速処理が非常に得意です。でもデータ加工はちょっと専門知識が必要なんですね。なのでChatGPTを使ってロジックを構築して、処理をChatGPTに生成してもらって、大規模なデータにそれを適用するようにすると全社での利活用が進むよねと考えたんですね。

これからは大規模データをお客さんがイチからSQLを書くのではなくて、こんなのは言葉でサクサクッと操作できる時代にしようじゃないかと、実は新しい機能を作っていました。それも少し紹介します。

今からお見せするのは、これが実際の製品の画面です。SQLやPythonなど、いろいろなロジックが組み立てられるのですが、わかりやすくSQLでいってみましょう。

実際に、テーブルと型みたいなのがこのように入っている状態です。ふだんだったらこいつを使って、SQLをゴリゴリと書いていくわけです。実際にどんな感じでいくか……「社員ごとの達成状況がわかるSQLが欲しいんだよね」「達成率はパーセントで欲しいです」みたいな感じで、ちょっと書いてあげます。

（デモを示しながら）こんな感じでこうするとSQLが返ってくるわけですね。それでその実行結果がこんな感じになります。社員別の予算に対して売上達成率が出ていますね。これはきれいに出る時もあるのですが、達成率がとんでもない桁数になっているので、「達成率は整数でお願い」とリクエストして、結果を見てみましょうか。こんな感じに直りましたね。

今はサクサクッとやってみましたが、私も技術者なのでこれは別に「SQLで書け」と言われたら簡単に書けます。でも、今と同じ時間で書けるかというと、けっこう難しいなと思っています。やはり生成AIみたいなものが入ってくると、お客さんのエクスペリエンスは明確に変わるので、私たちは今、製品にこんな機能を含めて生成AIというテーマを取り扱っています。

（次回へつづく）