IT業界にいる人って、自分の業界って何ですかって言われると困ることがあるんですよね。アンケートなどであなたの業界に〇をつけてください、っていう質問で、IT業界っていう選択肢はないことが多いです。どこにつけるかといいえば「サービス業」です。IT業界イコールサービス業っておかしくないですか。
サービス業とは、顧客の「◯◯したい」「〇〇してほしい」といった様々な要求にこたえることが仕事です。専門的な技術や知識、体験など、提供しているものに形はありません。生産と消費が同時に起こり、その場に応じて臨機応変に対応しなければならないという特徴があります。
すごくぼかして言えば、ユーザーが「◯◯したい」「〇〇してほしい」といった様々な要求にこたえるって、SIerがやっているSIの仕事にすごくにてますから、サービス業かなーって選ぶようになったんですかね。
でも、上記の文でもありますが、医療とか教育とか不動産とか、もう一緒にしすぎなんじゃないでしょうか。もう、業種はなんですかっていう質問自体をやめた方が良いと思います。もしくは、IT業という業種を誕生させるべき時なんじゃないでしょうか。
さて、このIT業界ですが、日本はアメリカや諸外国に比べて劣っているとメディアから酷評されがちですが、これはなぜなのか、考えたことがありますでしょうか。
Twitterでは各種の情報技術に対して資格試験を勉強しているとかこんな研究をしているとか、結構勉強熱心な方が多いです。経産省も50年近く情報処理技術者試験を継続していて合格された方もたくさんいます。技術者は結構育ったと思うんです。でも実装段階でどうも日本はやらかすことが多い。IT投資をしても満足な結果が出ない。そんな話をずっと聞いています。
この原因、心当たりはあるんです。
「どう実装するか」について、IT業界に所属している人が少なすぎるということです。システムを構築するときに要件をまとめますが、この部分に関わっている人より、どう設計するか。どう実装するか。どうテストするか。どう運用するか。要件定義後のフェーズに関わっている人の数の方がえらく多いのです。
大手SIerは最近、共創、DX、と言う言葉で顧客とともに要件を作り上げることを掲げていますが実際現場レベルにいる人々は昔と変わりありませんから、プロセスとしてはやはり要件定義から始めるのは変わりません。
要件定義においては、IT業界の純粋なテクニカルスキルだけでは仕事にはなりません。顧客が何に困っていて何を解決するかについて、言語化できることが最低条件です。だから要件定義をたくさんやっている人は、顧客の業務内容まで把握できるようになるんですね。それってITではないんです。むしろ顧客の業界のことを知ることになりますから、この経験を活かしてコンサルタントに肩書きを変える人も出てきます。
一方で、プログラミングの勉強、プロジェクトマネジメントの勉強、クラウドの勉強、ネットワークの勉強など、ITにもいろいろな幅広い技術知識があり専門的ですが、これら、さっぱり顧客の業務内容とは独立しています。
日本の抱えるITの問題は、まさに、業務とITの間のギャップにあります。IT業界にいる人は実装技術ばっかり勉強するので、顧客から降って来た要件を実装することにしか執着せず、その結果、「使われないシステム」ができあがってしまう。
それを見て一般人は、「なぜ日本のSIerは使われないシステムを量産するんだ」みたいな話を斜め読みし、SIerに対して悪いコメントを言うというのをよくSNSなどで見かけます。
それは、顧客がSIerにちゃんと要件を伝えないからだ、とか、顧客がシステムエンジニアを雇って内製すればいい、という意見も見ます。私はこれらも的外れだと思っています。顧客はITの専門じゃないので、ITで何を作れば問題解決できるかについて知識がありません。また、システムエンジニアを社内に囲って内製化しようとしても、そのシステムエンジニアが技術のことばかり勉強し、社内の業務に関心を示さなければ、SIerに投げるのと同じです。情報システム部門を子会社化して失敗するのは、子会社にしたことで業務と切り離されるので、降りて来たことしか実装しない受け身の会社になるからです。
結論として、IT業界の人々はもっと顧客業務のことを知るべきです。ベンダー資格等々ばかりに手を付けて専門家ぶる人のほうが私は過剰ではないかと思っています。それより特定業種に精通した標準的なITスキルを保持した人の方が今後重宝されるのではないかと思っています。
ITのスキルって、結構身に着けるのってコツというか経験が必要だと思います。だからこそ、顧客側にいて最先端のITスキルを身に着けるのは結構難しく、だから最近ローコードやノーコードなるものが流行し始めているんです。でも、システムを知っている人はわかると思いますが、ちゃんと業務に対して責任を持つシステムを構築するなら、伝統的なウォーターフォールで、プロジェクトマネジメントして対応したほうがリスクは少ないし、基幹システムは今でもそうでしょう。だから、私はIT業界のほうから、顧客の業務知識を勉強する方向に進んだ方が、より効率的に顧客のITに寄与できるはずだと思っています。内製ではなくて、です。
ま、その理屈で、業務知識が付いたシステムエンジニアが、顧客の情報システム部門に部長待遇で迎え入れられるケースが多いのも存じていますが。でも、IT業界側だって業務知識を身に付けて行くべきだと思います。
