「IT業務アーキテクト」という新キャリア
システム・エンジニアの在り方って、この20年くらいおそらくほとんど変わっていない。ただこのところ、なんだか世の中のシステムに対する要求やエンジニアの在り方が少しずつ変わってきているような気がしています。
エンジニアのみなさん、またはエンジニアと関わりのある立場にあるみなさんはどう感じていますか？
システム・エンジニアってなんだっけ？
システム・エンジニアって、そもそも何を目的にした人たちだっけ？
だいぶ広義になってしまいますが、日々の業務を効率化したり、新たなビジネスを実現化するためにITを使った業務の支援をするエンジニアですよね。業務でシステムをどんな風に活用するか、課題を取りまとめ、業務に沿った設計をし、事業プランに合わせた開発をし、実務がはじまれば運用メンテ、保守までのライフサイクルを請け負うことが多いんじゃないかと思います。単にソフトウェアを作るだけの人は明確にプログラマと分類されたりします。
わたしはヒューレット・パッカードでシステム・エンジニアとしてソフトウェア開発を10年ほどやっていました。会社組織や開発チームは素晴らしく、学生時代には考えられない環境で技術を学べることがただ楽しく感激したことを覚えています。ITバブルがはじけだいぶ窮々としはじめていましたが、それでも社内教育は今と比べると充実していて、技術研修だけでなく社会人としてのマナー研修から始まってチームビルディングやマネージャー育成など幅広く開かれていた印象があります。プロジェクトごとにチームが編成されるため、そこには無数のチームと多数の優秀なプロジェクト・マネージャーが在籍していました。さまざまなタイプの優れたマネージャーと関わることができ、その行動や言動はいまでもわたしの規範になっていると常々感じています。
そんな環境にあってなお、あるときからこのままシステム・エンジニアを続けていても本質的なシステム構築はできないのではないかと、消化しきれない思いが募るようになりました。なぜならシステム・エンジニアはプログラマと違い、その存在意義はシステムそのものの完成度ではなくビジネスやその業務に携わる仕事を改善することにあるからです。にも関わらず、業務構築の主管は（それがどれだけシステム技術に依存したものであれ）エンジニアではなくそれを使うユーザ企業側にあるという、IT産業そのものの中に構造的な壁があると漠然と気づきはじめていたからではないかと思います。その後、結局わたしは開発者としてのキャリアに見切りをつけ、方向性を変えてユーザ企業に転身し「実務」に携わりながらIT導入を推進してきたちょっと変わった経歴を持っています。
「システム開発」とクライアントの「実務」の両サイドに積極的に関わってきたエンジニアは多分それほど多くないと思います。ここでいう実務には人事評価、チームビルディング、部門間の連携、組織運営や会社の経営など、システムの背景にある様々な要因をも含みます。ほぼすべての実務はエンジニアが思っている以上にシステムだけでは完結せず、組織には物理的な「物」の動きがあり、それにまつわる「人」が根深く絡みます。そんな経験から、いまシステム・エンジニアは世の中の仕事にどう貢献しているのか？という問いをぶつけてみたいと思います。
従来の仕事（システム化以前）
仕事には作業があり、その作業が適切に流れるようにするために、みなさん日々の仕事の中で試行錯誤をされていると思います。この仕事全体の作業の流れのことを、業務フローなんて呼んだりします。
同じ業界であっても、それぞれの会社によって業務の仕方はマチマチで、特有の業務フローが存在しています。（おそらく日本の場合は特に）人材の流動性が低い上に業界の横のつながりもあまりないので、どうしても会社ごとのやり方が属人的になりがちなのかもしれません。
システム開発の観点から言うと、システムは同業種で画一的なフローに揃えれば揃えるほど効果がでやすいので、どうしても属人化は悪だというイメージが拭えません。ただ、実務の観点から言えば、属人化そのものは必ずしも悪ではありません。確かにブラックボックスになりがちではありますが、一子相伝でも構わないから担当者の中で適切な技能の教育と伝達が行われている限りにおいて本来は何の問題もなかったはずです。
IT導入して業務効率化！？
ただ、近年はどうしても景気も芳しくないので、現場の人員に余裕がなく技能を伝達する後任も思うように育てられない状況は否めません。ですから、その人材不足をITによってまかなおうという期待が多くの企業で生まれてもおかしくありません。
それに加えて、取引先との状況も急速に変化しています。企業間のやりとりやら取引がどんどんデジタル化されるようになってきました。そうこうしているうちに業界から取り残されてしまうのではないか？それによって、どうしても一部の業務をデジタル化させていく必要と不安に駆られるのです。
どうせ世の中の変化に応じてITを導入するのであれば人材不足を補うためにも業務改善をし、ITによる効率化を推し進めよう！なんて、社内の機運が高まっていきます。
そこで、従来の業務フローの中で、世の中的に対応しなければならない部分と、一番手間がかかっていて手が回らなかった部分を「システムに置き換えよう」と考えるのです。
でも、この発想はうまくいきません。よほどのことがない限りまず失敗するでしょう。
人とシステムは特性が違う
なぜ失敗するのか？その理由はとってもシンプルです。実際の人間が行う作業（実務）と、コンピュータが扱う処理は向き不向きが異なります。
実務においてボトルネックになる最もわかりやすい要因は物量です。人間が処理できる量には物理的な限界があるからです。注文数量が倍になったからといって、作業スピードを倍にしろ！空いている時間をめいっぱい使って業務時間内の生産量を倍にしろ！と言われても限界があります。
ところが、システムは違います。人が1時間かけて処理するようなものであっても、一瞬で処理が完了してしまいます。休みなしで働き続けることもできます。反復作業が得意なので同じ処理を繰り返すだけなら限界を知りません。もちろん厳密に言えば量的限界はあるのですが、実質的に人間がこなす量から考えれば上限はないに等しい。
一方で、システムは種類過多がボトルネックになります。人が意識することすらなく簡単にできるようなことであっても、システムにはできません。「１０（全角）」も「10（半角）」も人には同じものとして理解できますが、システムではそうは行きません。事前に、半角の1と全角の１は同じ意味を持つものであるというプログラムが必要になります。さもなければ、人が手作業ですべての全角数字を半角に置換してあげる事前処理が必要になるでしょう。さきほども少し触れましたが、システムは画一的なフローに揃えれば揃えるほど効果がでやすいのです。反対にどんなに些事であっても判断が必要になるものは不得意です。よって、あらゆるデータの揺れや、処理のパターン、サービスの種類を「絞る」「統一する」「画一化する」ということはめちゃくちゃ重要な要素になります。
そんなのプログラミングでなんとでも回避できるじゃん、と思うかもしれません。でも、少しこんな状況を想像してみてください。例えば、キャベツの千切りの機械を料理人が導入したとしましょう。キャベツの千切り機械は3mmの細さにしか切ることができません。そこで、これを1mm単位で細さを変えられるように機械を改造することにしました。1mm毎にカッターの刃を取り替えるようなしくみに改造するのです。これで、キャベツの千切りは3mmでも、5mmでも、10mmでも汎用的に対応ができます！野菜スープにも使えるし、トンカツに添えるキャベツにも使えます！これ一台で二役も三役もこなせます！これがプログラムで機能追加した状態だと思ってください。
しかし、運用を見てみましょう。千切りの細さを変えるためには、毎回カッターの刃を入れ替えなければなりません。その度に機械を停止させなければなりません。異なる厚さのキャベツが混入しないように、刃を入れ替えたあとは機械全体をクリーニングしないといけません。などなど。。。つまり、そのような事前設定が必要になり、メンテナンスも必要になってきます。それを更に自動化しようものなら、数mmの差を生み出すためだけに、更に何百万もの改修費用がかかってしまうかもしれません。こんなに手間がかかるなら、安い千切り機を2台買ったほうがよかったじゃん。。。なんてことになりそうです。
いずれにしても、機能としてできることと、業務として利便性が上がることは別なのです。機械に例えるとあたり前のことも、ITだと実体の見えないデジタルデータとして扱われるのでなかなかイメージしにくいのです。
システム化をしようとすると、なんでもかんでも盛り込もうとする担当者はいつもいます。できる・できないで言えばもちろん「できます」。が、このように実務とシステムの特性を見極めないと、なんでもかんでもシステムに盛り込むということはそれだけ複雑な判断が必要になり、システムの長所をまるで活かせないしくみになるのです。
このように、まずは何より「実務」と「システム」の軸をしっかり見極めることが全体を設計する上での要になります。
いまのシステムは全体最適か！？
このことを理解せずに、従来の業務フローにあわせてシステム導入をするとどうなるでしょう。
多くの企業では、単純に従来の業務や作業をシステムに「置き換える」観点で導入されることが多いので、結果的にキャベツの千切りを導入した料理人と同じような状況に置かれてしまいます。それを定常業務に落とし込もうとすればするほど、日々の業務は複雑化し絡まったスパゲッティーのような状態になっていきます。
システム導入をしていざ蓋を開けてみると、システムを「使うため」の業務が生まれ、複数のシステムを「同期するためだけ」に毎回誰かが手作業で連携処理を行ったりしていませんか。
特定の部分だけをみれば、効率化され従業員の仕事が代替されているように見えるのですが、全体を通してみると返って従来よりも手間がかかっていたりします。
これをシステム・エンジニア視点で見ると、このような状況は範疇外であり、わりとエンジニアからは見えないものです。エンジニアはあくまで担当者が求めている機能実装をするのが目的なので、それが実際にどう使われていようとシステムが「滞りなく稼働してること」に注意を払います。もっと現場の動向を分析しろと叱責するクライアントもいますが、実際のところエンジニアはキャベツの千切りについては詳しいかもしれませんが、料理人そのものではないので、料理の効率的な手順を聞かれてもわからないのです。業務の主管であり責務を追うのは誰か？これはよくシステム・エンジニアの中でも議論になります。正しいか正しくないかは置いておいて、「業務設計の責務はその業務を担当するユーザが負うべきである」これが昨今の一般的なエンジニアの見解です。
一方で、末端の現場作業者ではシステムを含む業務全体のあるべき姿が描けないので、致し方ないことだとして受け入れるしかありません。特にこのような無駄作業は業務時間内に追加作業として詰め込まれることが多いのではないでしょうか。だから、経営上の数値にも現れにくく業務の責任者や経営者からは見えないことが多いのです。手間の割に評価されない。現場の余裕と時間が闇雲に失われ、柔軟性のない窮屈な組織になってゆきます。このような組織は見かけ上は効率的に見えても、緊急事態や新しい事業への挑戦に対してものすごく弱い体制になってゆきます。
これでは本末転倒です。
システム・エンジニアにとっても、業務の担当責任者にとっても、適切に全体の業務フローや使われている技術そのものを俯瞰できず、結果的に部分最適に陥ってしまうのです。
IT導入したことによって「返って不便になった」という現場や末端の作業者の声があるチームや組織では、システムと業務がそれぞれ個別に設計されており、業務全体を俯瞰したフローがまったく出来上がっていないのではないでしょうか。
（再）システム・エンジニアってなんだっけ？
殆どのエンジニアは、この問題に目を背けているような気がします。わたしもよくセミナーなどに参加するのですが潰しの効く技術やツールの習得ばかりが注目されます。最新の技術やマーケットにインパクトのある手法を学ぶことは確かにエキサイティングです。でも、ツールの導入や技術の習得だけでは、こういった足元の業務改善はしてくれません。
これだけ様々なITツールがあふれ、あらゆるシステムが開発されているにもかかわらず、実際の現場に行くと「結局、ITベンダーに頼んでも自分たちが望んだ形にならない。。。」という不満を驚くほど耳にします。年々その声は大きくなっているように感じています。
そうは言っても、わたしはシステム・エンジニアでもあるので、エンジニア側の言い分もとてもわかります。ユーザ企業は従来のやり方ばかりに固執し、システムの特徴を理解しようとしません。自分たちの手を汚さずに無意味な手間や無駄な開発ばかり要求するのです。その不毛な開発に対する拒否権はなく、そこには業務委託という金銭のやり取りがある以上オーナーの言うことはある意味絶対です。そのとばっちりを受けるのは、どうしても末端のエンジニアになりがちなのです。システム・エンジニアをやっていると、オーナー対エンジニアの呪縛から身を守るためのリスクヘッジやセーフティーネットを嫌というほど張って仕事をしています。自分がエンジニアであるのか御用聞きであるのかも、わからなくなっていくのです。
これもまた本末転倒です。
だからこそ、いまもっとも必要とされているのは、システム・エンジニアそのものではなく、「実務」と「システム」の両輪を並行して、ひとつの業務フローとして描ける人です。
これからのIT業務設計
本質的な業務改善は、ITによる「デジタルの流れ」と「実務の流れ」の２本の矢印を適切に設計することです。従来のやり方を戦略的に残すべきところは残し、デジタル化すべきところは全体をデジタルのフローとして設計しなければ効果は期待できません。
どんなに最新の技術や高額なツールを導入しても、部分最適でやりすごせる時代はもう終わっているのです。
従来のやり方を残すべきところはどこか？従来のやり方を脱却しシステムの特性に合わせてどう画一化するか？そのために切り捨てるべきサービスは何か？それを見極める作業はエンジニアリングではなく、むしろ経営戦略です。そしてこの判断にはとてもドロドロとした出血を伴うかもしれません。システムに業務を代替させるのではなく、業務そのものにもメスを入れる必要があるからです。これまで培ってきた地位や部門にとって触れられたくないところにメスを入れる必要がでてくるでしょう。売上も一時的に落ち込むかもしれません。
先程のキャベツの例で言えば、いかに効率よく千切りの細さを変更するかを考えたときに、例えば、必要に応じて都度カッターの刃を切り替えることをやめ、曜日ごとにカッターを使い分けることで必要分を在庫しておくという工夫だったり、機械をいっそ2台購入してしまおうという判断であったり、あるいは、3mmの千切りキャベツだけを提供すればよいようにサービスメニューそのものを工夫しよう、という経営判断こそがほんとうの改善につながるかもしれません。
その判断は、単に千切りの機械のことだけを知っているだけでは十分ではありません。「実務フロー」と「システムフロー」の両輪を俯瞰できる人材が重要であるということです。
業務の全容をITを通して設計する "設計士（アーキテクト）" のポジションがいまIT業界には存在していません。仮にこのポジションをここでは「IT業務アーキテクト（仮）」と呼ぶことにしましょう。
「IT業務アーキテクト」へのキャリアパス
この両輪を担える人材は、今日明日にすぐに育成できるものではありません。
各企業の業務フローは企業毎に異なっており、長年培ってきた技能やノウハウがあるはずです。それがその企業のコアビジネスになっていることが多いので、そもそも個別の企業で「実務設計」できるまでの実務を身につけるまでには、半年から数年を要するでしょう。
「システム設計」の技能を身につけるにも、IT技術や知識、課題管理、工程管理、リソース管理などだけでなく、システム特有の特性や向き不向きに対する経験則、品質管理や、リスク管理、これら多くの技能を習得するには同じように少なくとも数年を要するでしょう。
その両方を持ち合わせた人材の育成となると、更に長い期間が必要になるでしょう。
しかしながら、現実問題として、この「IT業務アーキテクト」という職種さえ存在しておらず、キャリアパスがない。空白のポジションのままなのです。まさに道なき道をゆくしかありません。
欧米信仰は都市伝説
このような話をすると、欧米ではこうだとかシリコンバレーなどのやりかたを成功事例として語るエンジニアも多いです。けれども、日本のIT産業は欧米の構造とはだいぶ違っています。
欧米では7割近いエンジニアが、実務担当のいるユーザ企業側に雇用されている現実があります。一方で、日本は建築業界のゼネコンの思想に大きく影響を受けていると言われていて、ITは社外に外部委託するのが基本になってます。みなさんの会社でもほとんどの場合、社外のIT専門家に委託しているケースが多いのではないでしょうか？そのため、欧米とは反対に日本では7割のエンジニアはITベンダーというIT導入専門の会社に雇用されている現実があります。
この産業構造が正しいのか間違っているのかをここで議論するつもりはありません。ただ、少なくとも欧米での成功事例をそのまま日本に持ってきても通用しないだろうということです。
ユーザ企業側の「実務」をIT視点で俯瞰できる人材を育てなければいけないという状況は変わらないからです。ユーザ企業側で実務を習得できる環境にあるシステム・エンジニアがそもそも日本ではかなり限られているのです。
ここを直視しないと、ただの欧米化または技術信仰で終わってしまうでしょう。
30年デフレが続いたことの意味
新たなビジネスの担い手（といっても、もう30代、40代の中年層）にとって、これまで新しいビジネスモデルの構築や、新しい産業の創出へのチャレンジをする機会がほとんど与えられてこなかったのではないでしょうか。大きな企業ですら保守的で、リスクを下請けや外注に押し付けるケースも見受けられます。これはシステム開発でも同じです。
今になって思います。この失われたデフレの30年のインパクトは思ったより大きいかもしれない。守りを固めることに関してはめっちゃ得意だけど、新たな産業を生んだり新たな生産手順を構築したりすることにまったく慣れていないのではないか。新しいもの好きのわたしですら思います。どうしてもリスク管理の思考が先行してしまうのです。仕事とはそういうものだと、"デスマーチ" とか "過労死" なんて言葉が流行った頃に教育された身としては、恐怖とともに身体にその思考が染み付いて離れません。
以前、ある経済学者が言っていたのですが、デフレの本当の怖さは資金が回らなくなることではなくて、むしろ培ってきた生産手段や技能そのものの継承が途絶え失われてしまうことなのだと。最近なんだか、その言葉がとっても実感をもって思い出されます。
だから、2、30年以上も前の超アナログ時代の成功事例をひたすら継承することが正義になってしまっている企業もものすごく多い。システム導入案件等で業務改善を本気で進めようとすると、未だに「その領域は誰々部長の許可が」とか、「どこ部との交渉が難航する」とかいう組織の壁が立ちはだかって、一向に進まなかったりするのです。
前時代を知らないわたしには。。。バカバカしい！とつい憤ってしまうのですけれど、これは良し悪しは置いといて、この30年という長い氷河期を乗り切るために企業が選択したリスクヘッジだったのかもしれません。
業務のパターンを絞り、統一規格化するといった挑戦は、現場の業務変更だけでなく、時には売上にも痛みを伴うものです。この業績の思わしくない社会環境のなかで、そういった負の側面までどのように正当化するかをシステム・エンジニアの力量だけに頼るのはハードルが高すぎるのです。
2025年の崖問題
今から5年ほど前に国内で17万人不足していると言われたIT技術者の数は、2025年にはより深刻化し43万人不足すると予測されています。更に導入してから20年以上経つ旧式の基幹システムが2025年には企業の6割を占めるというとんでもない報告も上がっています。IT業界は技術の進歩が著しいので旧式の技術はメンテナンスするほうが難しくなるものです。すると企業はサポート終了に伴うリスクに晒されることになります。延命措置を施そうにも、旧式のシステムをメンテナンスできるITバブル時代の人材が2025年にはごっそり引退していなくなってしまう。後戻りもできない状況です。
経済産業省はこれを「2025年の崖」問題と呼称して対策に乗り出しています。谷ではなく崖です。それほど事態は深刻ということなのでしょう。
欧米と違って日本は、ITを外部ベンダーに委託する構造が主流だから、そのしわ寄せをベンダー側が契約に縛られた形で負わされるのでは、と想像するとIT業界に身を置くこと自体に寒気を覚えます。
このような状況で、システムの設計者、エンジニア、コンサルタント、実務の設計者、そしてプログラマなどの立ち位置を今一度、IT産業全体で見直さなければならないと思います。
IT業務アーキテクトの育成とセーフティーネット
IT技術者がいくらいても、それを適切に業務フローに組み込めなければ、意味がありません。だからこそ、2025年に向けて、いま最も必要なのはむしろ「IT業務アーキテクト」の存在なのではないかと、わたしは思っています。そのための、キャリアパスの前例を作らなくてはいけないのではないかとわたし自身も感じながら、いま色々な働き方を模索しています。
ただ、前例がないだけに課題も多い。
複数社に分散して雇用される働き方
わたし自身個人的に「IT業務アーキテクト」として、仲間のエンジニアを企業に引き込もうとしたときにいくつかぶち当たった壁があります。
エンジニアの単価は高い。わたしの年収の倍以上もらってるんじゃないかというような若手もゴロゴロいるなかで、複数のシニア・エンジニアを企業が抱え、育成するのは費用面でも運用面でもかなり難しいと思います。そもそも、普通の企業は彼らの人事評価すらまともにできないですから。
しかも、エンジニアにしてみたら、ユーザ企業側に雇用されることで技術者としてのキャリアが途絶えてしまうというイメージも払拭し難いものがあります。
そこで、より雇用形態を柔軟にして、エンジニアに対して正社員と同程度の福利厚生を充実させつつも、時短や週2、3勤務などを許容すべきではないかとわたしは思っています。そうすることでエンジニアは複数の会社をゆるく掛け持ちながら働くことができるようになります。企業側は高単価のエンジニアを週2、3という少ない勤務という形で費用を抑えて雇用できるメリットがあります。それにより、副業や掛け持ちという形で、エンジニアはトータルで単価を下げることなく、実務経験の習得とシステム開発の両輪をバランス良く保つ働き方ができる可能性があります。エンジニアとしてのキャリアが途絶えてしまうのではないかというリスクも、働き方を分散することで払拭できるのではないかと考えています。
実際に一昨年くらいまでは、3割程度の稼働で複数社をゆるく掛け持つような働き方ができないか画策したのですが、あまり現実味がありませんでした。当時勤務していた会社とも交渉してみたものの、実現には至りませんでした。。。反対されたというよりも、そもそもそういう人事制度がないから、どう扱えばいいのか企業側も判断できないというのが正直なところだったと思います。しかし、コロナ禍によって図らずも、このような働き方が急激に現実味を帯びてきているように感じています。
いまエンジニアがこれに近い働き方を選択しようとすると、フリーランスになるという選択しかないのじゃないかと思います。では、みんながフリーランスに転向すればよいかといったら、そうではないとわたしは思っています。フリーランスは雇用される側にとって社員に比べるとどうしても自己責任というリスクを伴います。企業側にとっても、せっかく社内で育ってきたエンジニアが会社から独立して離れていってしまっては意味がありません。企業側でしっかり吟味してほしいのは、あなたの会社の業務をしっかり把握できるIT業務アーキテクトを育てるのには年単位の時間がかかるということ。今いて社内の事情を多少把握してくれているエンジニアをまずは手放さないこと。彼らに時短や副業、週2の勤務、テレワークなどの柔軟な働き方を許容し提案してみることはできないだろうか？今すぐにでも検討を始めてほしいと思います。
背負いきれない責任
次にわたしが感じたのは、ユーザ企業側にエンジニアを抱え込む地盤がないため、どうしてもひとりないし少数のエンジニアにすべてのITの責任を負わせようとする傾向がある点です。
フリーランスでの個別契約でも同様のことがかなり多く発生しているのではないかと推測しています。フリーランス化することで、仕事に余白がなくなり返って厳しくなっているようにも思います。「ITに関してはわからないから全てIT専門の○○さんに任せよう」といった話はよく耳にするのではないでしょうか？
単にパソコンやネットワーク機器のトラブルシューティングだけでなく、今やITはすべての分野に少なからず関わっていて、その分野は多肢に渡ります。会計・経理、ネット販売、広告、社内基盤、基幹システム、セキュリティー、個人情報保護、IT統制などなど、これらすべての専門分野を極めて少数のエンジニアに任せたいというのは、無謀過ぎる期待だという理解をしっかり持ってほしいと思います。
それだけ、「IT業務アーキテクト」には、多くの責任が降りかかるリスクが高いと思います。そのようなリスクを回避するために、企業側は明確に複数のエンジニアをチームとして雇用する体制を作ったり、社外からの暫定的な応援を呼びやすいような人事規定の特例を用意したり、エンジニア自身もそのようなリスクを回避するためのコミュニティーを作っておくことも大事になってくると思います。
プログラマの待遇について考える
日本ではプログラマの待遇が低すぎる、という議論にも少し触れておきたいと思います。確かに日本の場合、プログラマはただシステム設計に則ってソフトウェアのコードを書くだけの人という位置づけのため、システム設計者の下のポジション（建築でいうと末端の大工さん）に当たるのがプログラマです。
単にプログラミングだけを本職にしている人は、業務を設計したりシステムをファシリテートする人と比べて単価がかなり低くなってしまいます。そのため、日本からは天才的なプログラマが現れにくく、ひきずられてそのような芸術的なプログラマが生み出すサービスやツールが生まれないのではと言われています。
わたしもその意見には一部賛成です。より有能なプログラマが、プログラマとして生きていける十分な高位のポジションはあってしかるべきだと思います。それによって、国際競争力の高いソフトウェアが生まれる可能性はぐっと高くなるのではないかと思います。日本人はそもそもソフトウェア開発に向いていないと言う極端な意見を言う人もいますが、ブロックチェーンの核になる技術を生み出したのも日本人ですし、日本人がソフトウェアに向いていないということでは決してないと思います。
ただ、プログラマの待遇が悪いという話と、このIT業務アーキテクト（ITを通した全体業務設計を描ける人）がいない、という話は混同しないほうが良いと思っています。
ここでいうプログラマの高待遇とはつまり天才的な一部のプログラマのことを指しているのだと思いますが、これまでのようにソフトウェアやITサービスが決定的に不足していた時代であるならともかく、これからはシステム自体もどんどん飽和していくでしょう。そうなったときに、純粋なプログラマとして立身できる人材が世の中にどれほどいるのか？という疑問にぶちあたります。これだけ車が大衆化したいま、エンジン設計ができるポジションは一握りです。むしろ、車の整備士から、車を使ったビジネスやサービスの設計、そういったビジネスに必要な需要はシフトしていっているはずです。
システムが大衆化していくにあたって、人材不足を単にプログラムができる人材に絞って考えるのは、とても狭義な視点だと思うのです。
デジタル脳の育成
最後に忘れてはいけないのが社員教育です。今の仕事世代の多くは物理的な世界をデジタルに置き換えて処理するというデジタル脳に慣れていないように感じています。学校教育も今の社会のあり方にまだまだ追いつけていません。例えば、期末テスト一つをとっても答案用紙は未だに紙なので、仮に答案用紙をデジタル化したときにどういった不備が予測されてどのようなリスクが潜んでいるのか、ということが感覚としてイメージできないのです。答案用紙の漏洩や紛失を防ぐための対策だって紙とデジタルではやらなければいけないことは同じでもそのやり方は全く異なります。カンニングだって考えうるやり方が全く変わってくるはずですよね。だから、大人になって会社でデータ集計したりファイル管理するときに、どのようなことに気を配って管理するのが得策なのかが誰もイメージできないのです。習っていないのだから当然です。
かといって、若い世代もスマホやテレビゲームなど極端に部分最適化された機器やアプリに慣れ親しみすぎてしまっています。何でもかんでも直感的にワンタッチでやりたいことが実現できてしまうシンプルな世界観しか体感していないのです。すると目の前のちょっと複雑な問題解決をするのに、アプリをどう使いこなせばよいのか、どう組み合わせればよいのか、その途端フリーズしてしまうのではないでしょうか。
まったく当然の結果として、それはエンジニアでないとわからないと匙を投げてしまうのです。デジタル処理にはどのような応用の可能性があって、それをすることでどんなメリットがある反面リスクがあるのかということを体系的にすべての社員が学ぶ必要があるのです。
システム・エンジニアをゆるく社内に抱え入れつつ、社内の本丸の社員を少しずつデジタル脳に教育していく。次世代の担い手として、社内でこれまで培ったさまざまな知識や技術を継承しつつ、デジタルの世界でそれを生き生きと再現できる人材を育てていく地道な活動が必要になるのではないかと思うのです。
最後は、ちょっとわたしの抱えている不満の話になっちゃいましたが💦 長々と付き合ってくれて、ありがとうございます。
この記事をキッカケにYuitaさんが、ご自身の体験をnoteにしてくれました。こちらも合わせてどうぞ！！
この記事が気に入ったらサポートをしてみませんか？