機械翻訳が高度化しても英語力は必要

DeepLやGoogle翻訳がどんどん賢くなって、翻訳の精度が上がってくると、自分の下手な英語力より格段に速く正確に翻訳してくれます。

僕は英語の素養はそこそこあるとは言え、得意言語の訳でもなく、読むのがまどろっこしいような複雑な文章の時は翻訳ツールに頼ります。

ビジネスの場面や苦情を伝えたいときなど、相手に正しく伝えたい場合の英語も翻訳ツールを使います。

海外旅行でもポケトークなどの翻訳機が活躍しているようです。

だからといって、英語（だけでなく第2、第3の外国語）を学ぶ必要がないのか？というとそうではないと考えています。

母国語が日本語じゃない人との会話においていちいち翻訳機などを使っていたのでは会話は弾みません。

ソフトウエアエンジニアの場合、海外のサービスが多いですから英語のドキュメントを読む必要があり、大量の文書をいちいち翻訳していたら手間がかかります。

技術的なドキュメントの場合に、必ずしも正しく翻訳されないという問題もあります。

せめて英語くらいはやはりマスターしておくべきと考えています。

機械翻訳にかけるより手間なく読める

どの程度の英語力が欲しいかは、どんな仕事に就くかやどんな目的に利用したいかによるでしょう。

僕は会話がペラペラできるような英語力を持っているわけではないですが、技術的な文書は割と読めます。

翻訳ツールにかけるなくても十分理解できます。

そのくらいの能力があると、あまりツールに頼らなくてすみます。

僕は、機械翻訳にかけた結果、日本語の意味がよく理解できず原文（英語）を見直すことも少なくないため、ちゃんと理解しようとすると翻訳されたものより原文をそのまま読むことが多いです。

これは人によりけりでしょうけど、エンジニアを目指すなら原文のまま読めるようにしましょう。

自分の言いたい表現は人工知能が教えてくれる

僕は過去何度か海外に出張していますし、アジアやヨーロッパのエンジニアと日本で一緒に仕事をした経験があります。

そのたびごとに、思ったようにしゃべれなくて残念に思ったことは数知れません。

AIを使った翻訳が登場するまでは、「こういうことを話したい」と思っても、適切な英語を調べることが至難の業でした。

日常あるいはビジネスのいろんなシーンで使える文例がたくさん載っている参考書を買ってきても、自分が言いたいことが載っているとは言えません。

どちらかというと自分が話したいことを見つけることがほぼ困難です。

だから、どうしても知りたいときは、親しくなった英語を母国語とする友人に尋ねて表現を聞いていました。

今はそういう英語を知りたければ、DeepLでもChatGPTでも聞くことができます。

そういう意味でとても便利になったと感動します。

会話は日常会話会話以上が話せるといい

基本的な日常会話などを勉強したら、その先いろいろなシーンでどう言えばいいか人工知能との学習で学べばより効率的だろうと思います。

最近では英語学習のアプリも優秀になってきてチャットで会話ができたり、アレクサに英語で指示することでちゃんと理解されるか判断するのにも使えます。

こういうツールを利用することで英語学習のハードルは以前よりグッと下がっている気がします。

何とか日常の会話程度話せるといいですし、できればもう少し複雑な会話もできるようになると、話していてうまく表現できずにまどろっこしい感じは少し減らせるでしょう。

翻訳の正しさを見るためにも英語力が必要

英語の表現はいろいろ学習しないと自分が表現できる範囲が広がりません。

ビジネス文書やビジネスメールではやはりAIの力は絶大です。

自分では思いつくことができなかったような表現が可能になります。

そうやって翻訳させた結果を自分が学んでいくといいです。

こういう場面でこう言えばいいんだなとわかります。

また、翻訳させたい日本語の書き方によって答えは変わってきます。

自分が英語を書きたいとき、それが自分でうまく表現できなければ、何とか表現可能な日本語に変えていくことはよくやる方法でしょう。

同様に、機械翻訳においても日本語を少し変えることによってより言いたいことに近づいていくようになります。

翻訳された英語を読んで足りない部分を感じたら日本語を変えて翻訳し直してみる、そういうことは必要ですね。

そのためにも英語の正しさをある程度判断できる語学力も必要です。

人工知能が賢くなれば、そのうち自分が言いたいことをくみ取って考えて翻訳してくれるようになるときも来ると思います。

（改行）

成長は仕事の中でしか得られない

リスキリングがとかく言われています。

リスキリングとは新しい技術を身につけ新しい業務や仕事に就くことですが、残念ながら仕事に使えるスキルは一朝一夕には身につかないです。

仕事に使えるレベルのスキルにするには何千時間とそのことに費やす必要があります。

ですので、それを仕事とは別に時間を割いて個人的な時間でやるには相当の時間が必要になります。

それと個人で技術習得しているときは、うまくいかないときも「まぁいいか」と諦めてしまえる環境にあります。

ところが仕事でやっているなら、「まぁいいか」で終わらすことはできず、是が非でも仕上げる必要があります。納期があるなら、徹夜してでもやり遂げる必要があります。

この「是が非でも仕上げる」ところに本当のスキルアップがあります。

妥協など許さず自分で自分を追い込める人はともかく、そうでない大多数の人は仕事でスキルアップするのが時間も確保でき、レベルも上がります。

同じ仕事では成長がない

仕事で成長すればいいとは言え、同じ仕事をしているだけでは下手をするとルーティンワークになる恐れもあります。

単純な繰り返しという仕事ではなくても、経験を積み上げてくるとその仕事のコツがわかってきますし、失敗しないための勘所も得られるようになってきます。

そうすると、効率的になりミスも少なくなるため、必然的に成功率も上がってきます。

仕事はあまりがんばらなくてもうまくいくし、上司や他部門の人からの信頼も上がり、仕事が楽しくなります。

こうなると、職場でも一家言のある人となり自然と重要な役割を担ったり、役職も上に上がったりしていきます。

それはある程度まではいいことなのですが、こういう繰り返しの場合、成長は少しずつ頭打ちになってきます。

成長しなくたって仕事はうまくいくのですから。

ひとつ上の仕事を目指す

そこで、成長のためにも自分が今できることのひとつ上のレベルの人がやっている仕事をできるように目指しましょう。

これは簡単なようで実際にはなかなかできないかもしれません。

なぜかというと、組織には役割に順列がありますし、上司がひとつ上の仕事を認めてくれないと実際には担当が難しいからです。

だからといって準備しておかないと、いざというときに問題なくやっていくだけのスキルがないということになります。

そういう場合でも、ひとつ上の仕事をやるつもりで取り組んでみましょう。

• プログラミングをやっているなら、少し上の設計や仕様書を書いてみる
• 自分の作業計画を立てるだけでなく、チームの計画をとりまとめる
• ある機能の一部の担当をしているなら、より大きなモジュールを担当する
• 機能設計をやっているなら、ひとつ上流の要件定義をしてみる

などなど、1つ上のレベルを目指す方法があります。

ひとつ上の仕事をやろうとすると、カバーしなければならない範囲がかなり大きくなり、やるべきことが大きく変わります。

これこそがまさに成長につながることになります。

目線が大きく変わる

ひとつ上の仕事をしようとしたとき、最も変わるのは「目線」だと思います。

1階にいると目の前のことだけしか見えませんけれども、2階に上がるともっと後ろや横との関係、あるいはもう少し向こうまで見渡せるようになります。

これによって周りを見る意識が生まれ、その中で仕事をうまくやるために新たなスキル習得が必要になります。

上に挙げた例で、どんなスキルアップが起きるか説明します。

• プログラミングから設計に上がると、全体の構成などを把握したり、将来の改修計画などを把握することが求められます。
• チームの計画をまとめるためには、各人の役割、スキル、スキルレベルなどを考慮して、どういう仕事の割り振りをして、どう開発を進めたらよいかを決めていく必要があります。
• より大きなモジュールを担当すると、関係するモジュールが増え、外部システムとの連携なども考慮しなければいけなくなり、他の機能についての把握が不可欠になります。
• 機能設計から要件定義に仕事をアップグレードするには、顧客の要求を聞くという新たな仕事が必要になります。言われて作る状態から、顧客の要望に合わせて作ることに考え方を変換する必要があります。

このように、1段階上に上がるだけでもぐっと広い視野を持つことが必要になり、スキルを上げないとやっていけません。

転職よりまずは社内でスキルを磨く

スキルを上げるというと転職を考える人も少なくないと思います。

確かに、転職でなければ得ることができないスキルアップもあります。

今の会社ではやっていないような事業領域や、会社には存在しない職種などもあります。

そういう人は転職も視野に入るでしょう。

ただ、どんな会社も「外から見える会社の姿」と「中に入ってわかる会社の実情」はだいぶ違うのが現実です。

仮に「こういうことをしたい」と望んで入ったものの、採用の際に聞いていた話とずれがあるのは避けられないと思います。

誰も嘘を言ってないとしても、表現された内容とそれをどう受け止めどう理解するかには常にギャップがあります。

ですので、転職を考える前に、まずは今の会社内でステップアップできる道を探しましょう。

会社でしっかり成長した方がより転職もうまくいくと思います。

どういう人がITエンジニアに向くか？

ITエンジニアに限らず、エンジニアという職は時に過酷だと思うときがあります。

それは、機械にしろソフトウエアにしろ、100%期待通りに動かなければ完成とは言えないからです。そして、100%に仕上げる道のりが決して楽ではないからです。

プログラムであれば実質的にバグがゼロでないといけません。

※「実質的に」と付けているのは、バグがゼロの状態にすることはとても難しいですが、仮にバグをすべて修正できなくても、めったに起きないなど現状の使い方では「実質」問題がないと判断しバグが残るけどよしとすることがありますので、その状態のことを言っています。

バグの原因を追いかけて、確実にそのバグだけを修正する必要があります。

直し方によっては、そのバグは直るけれども、別のバグを誘発することもあるからです。

プログラムを例にしましたが、ITエンジニアが仕事で対象にするものの多くは、「バグがゼロ」を目指さなければいけません。

そのためには、仕様書を間違いなく書き、隅から隅までプログラムし、緻密にテストし、問題があれば緻密にその問題を解消していくことが欠かせません。

そういうことをいとわない人、つまり、問題を理詰めで考えられるタイプの人が向いています。

少し具体例で作業を見ていきましょう。

理詰めで考えるとは？

理詰めで考える能力というのはどういうことでしょうか？

ITエンジニアの仕事の中で、例えば計画を立てることが求められたとき、「だいたいこのぐらいでできそう」という感覚で計画を出すことがありがちです。

計画のレベルによっては、そのざっくり感が重要な場面もありますが、より詳細な計画を耐えてるためには、作業に分解して正当な理由のある計画を立てないといけません。

仕様を理解するのに何日、仕様書を書くのに何日、設計に何日、コーディングとデバッグに何日、といった具合です。

僕の経験でも、ざっくりと出した計画はだいたい遅れます。自分が「このくらいでできるだろう」と思った期間はほぼ100％外れてました。

なぜかというと、作業を積み上げて書いていないからです。

それぞれの工程の日数を出すにも、こういうドキュメントをこのくらいの量を書かないといけないからどのくらいかかりそうだ、という積み上げで出す必要があります。

ところがそれができないのです。なぜでしょうか？

自分のスピードがわかっていない

見積がざっくりでいつも遅れる人は、何が原因かというと「自分の仕事の速度をわかっていない」からです。

コーディングスピードだとか、仕様書を書くスピードなど、1日にどのくらいの量を書けるか？をベースにして見積をしないといけないのですが、そもそも自分がどのくらいのスピードで仕事ができるかをわかっていないのです。

かくいう僕もそんなこと全くわかっていませんでした。

ざっくり「2週間かな」と出して、大幅遅れもいいところでした。

まずは自分の純粋な速度を知る必要があります。

仕様書を書くスピードやプログラミングするスピードです。

1時間当たりあるいは1日あたりどのくらい書けるかというような基準です。

ところが、自分のスピードというのは、単純に「自分の作業速度」にはなりません。

なぜなら、会社にいれば他の仕事も入ってきて、1日のすべての時間をその仕事に使えるわけではないからです。

そういった、週に固定で行われる会議などの時間を差し引き、1日辺りどのくらいのスピードで仕事をこなしているかが重要です。

最初は難しくても、2回3回繰り返すと、だいたいこのくらいで終わらせられるな、というのがわかってきます。

そうすると「だいたい2週間」という見積の精度も確からしくなってくるというものです。

そんなことを自然と考えてできるようになる必要があります。

バグの原因を突き詰める

なかなか直らないバグがあったのに「特に何もしていないけれど出なくなった」という状態が起きることがあります。

担当者としては、難しいバグが1つ発生しなくなったので単純に「うれしい」気持ちではあるのですが、これは多くの場合ぬか喜びとなります。

というのは、バグはあるときでなくなっても、全く別のタイミングで再度発生するようになることがあるからです。

たとえ、発生しなくなった場合でも、発生するバージョンに戻して発生の原因を突き止めておくことが、その後の再発を予防する上で欠かせません。

市場に出そうとする前の最終テストや市場に出てからお客さんが利用しているときに起きると問題はとても大きくなってしまいます。

ですので、こういうバグが起きたときに「ラッキー」と思わず、原因を探る地道さが必要です。

仕様書の機能をもれなく書く

ITエンジニアが関わる仕様書とは、相当に精密さが求められます。

UIの動作を記述するのであれば、絵で描くUIのパーツを正しく存在させないといけませんし、このボタンを押したらどうなるということを正確に書かなければいけないのが仕様書です。

仕様書を見た人から、

「仕様書に書いてある取り消しボタンってどこにありますか？」と聞かれ、

「取り消しボタンは機能の名前がキャンセルに変わったんだよ、わかるよね？」

と言い返す仕様書作成担当者。

確かに「取り消し」が「キャンセル」になっても想像はできますね。

だけど、「プロパティ」が「詳細」という名称になっている場合など、簡単には同じ機能のボタンとは言えませんね。

あるいは、「キャンセル」ボタンを押したときの動作として「本当にキャンセルしますか？」と確認する仕様になったのだとすれば、それを正しく反映する必要があります。

仕様書は例に過ぎませんが、「正しく書く」「変わったら反映する」という地味な作業をきちんとできることが必要になります。

能力は上げられる

上に書いたようなことができなければITエンジニアになれないのかというとそういうわけではありません。

僕だって最初はできなかったけれど、少しずつできるようになっていったのです。

最初はボロボロで見積とは名ばかりでしたし、仕様書も間違いだらけであちこちから指摘されていたのです。思い出しても恥ずかしい･･･

ITエンジニアでなくても、それが経理であろうと営業であろうと、最初はできないことがあっても徐々にできるようになっていきます。

その仕事に向くか向かないかはその職種ごとにやるべき仕事を喜んでやれるかということになります。

外に出て知らない会社に営業に行くのがいやな人が営業になれないように、毎日パソコンに向かって黙々と作業するなんてできない人であれば、ITエンジニアは難しいかもしれません。

ITエンジニアの仕事を喜んでやれるか？、その基準で判断してみください。

（改行）

どんなITエンジニアが望まれるのか？

どんなITエンジニアだったら、転職に優位になり独立にも向くでしょうか？

僕は転職を繰り返した達人でもなく、転職を支援する職業でもありませんので、この質問に適切な答えをするのは難しいかもしれません。

それでも、自分が社外に発注したり、自分で仕事を請け負った経験から言えば、「しっかりした実力を持つことは最低限必要」ということは言えます。

ところが、実力があるエンジニアが常に喜ばれる存在とは言えません。

実力があってもビジネスがわからない人や、頭が固くて柔軟性に欠けるような人は、ある場面では活躍できるし不可欠ではありますが、その人に仕事を頼みたいかというとそうではないこともあります。

かといって、社交性があってビジネスも理解するけれど、知識が広く浅くで専門性が不十分だと、これまた使い物になりません。

バランスが取れていることがやはり重要です。

技術力もあり、ビジネスも理解する、そういう力のある人がやはり重宝されます。

ゼロから作り上げる実力を磨く

仕事をする以上、実力が伴っていなければなりません。

そんなの当たり前だよ、と思いますよね。

肝心なのは、どの方面でどんな実力を身につけるかです。

企業で働いていると、いろいろ仕組みがあってその仕組みの上で仕事していることが多いものです。

新しい製品やサービスを作るといっても、全くゼロから作ることは少なく、既存製品や既存サービスを改良することが多いですし、新規性が高くても全くのゼロから考えることは多くありません。

ですから、社内でバリバリ実力を発揮していても、いざ転職や独立をすると全く別の仕事になり、前職でやっていたようには仕事ができないことにもなりかねません。

新しい会社で実力を発揮するには、どうしてもその会社の既存製品や仕組みに強くならないといけなくなります。

そうならないためにも、既存の仕組みにとらわれず、ゼロから作り上げていける能力というのがすごく重要になります。

ゼロから作るとは？

会社の中ではそういった過去の資産を使うことがよしとされますが、転職したり独立するとそういったものは一切使えなくなりますので、それでもやっていけるような実力を身につける必要があります。

プログラミングであれば素の環境から作れることです。

企業でサービスを作るとき、ある程度機能が共通化された下地となる環境がありますが、そういうものがなくても作れるようになることです。

AWSのようなクラウド環境が整っていてその上で作る分には問題なくても、それを一から構築できるようになるということです。それには経験と知識が必要になりますね。

また、要件定義や設計をする場合でも、社内のよく使われるフォーマットを使うのではなく、ゼロベースで要件書を書いてみる、設計書も書けるようになる、そういうことです。

元になるものがあると、それが本当に正しいかどうかは置いといても、なにがしか形のあるものが作れるものです。

要件書などもそうです。既存のものを書き換えながらやっていくとそれなりのものに見えるのですが、ゼロから作ってみると、「こういう項目にするのがいいのか？」「こんな書き方でいいのか？といった疑問がいろいろ沸くのです。

やっとこ作り上げても、次のステップで設計書を作ろうとしたら、うまく設計できなかったり、石英の漏れが発生して不十分さに気づくこともあります。

会社の中で長年仕組みの上に乗っかっていると、ゼロから作るといかいうことが本当に難しくなります。

転職準備は自分の経歴を見直すチャンス

転職支援会社のCMに「転職しないのに転職エージェントに登録するのは、キャリアの健康診断だ、常識だよな」というような話しが出てきます。

転職するかどうかは置いといても、転職するつもりで自分のキャリアシートを書いてみると自分が今できていること、足りないことに気づかされます。

僕もプロマネとしていっぱしの経歴があると思ってキャリアシート書こうとサンプルを見てみると、結構大規模な人数のプロジェクトを引っ張ったとか、そのとき扱ったプログラミング言語は何だとか出てきて、自分のキャリアのしょぼさにがっかりした覚えがあります。

もちろん、すごいキャリアがなければ転職できないとかそういうことではなく、ときどき自分のキャリアを振り返っておかないと、いざ転職する時にキャリアの弱さに気づき弱気になってしまうということです。

自分の得意分野を明確に

結局のところ、転職するにしろ仕事を獲得するにしろ、「あなたは何ができるんですか？」というストレートな質問に答える必要があります。

「あれやりました、これもやりました」という話しはできても、「だから何ができるんですか？」とズバッと質問されて、右往左往することになりかねません。

それを防ぐためには、専門性を高めるということが不可欠です。

その結果、

「プロジェクトマネジメントができます」

「Webアプリを一人で書き上げることができます」

のように明確に答えることができるようになります。

エンジニアは正直な人が多く、自分を過小評価する人も少なくありません。

営業職の人に「そんな交渉よくできますね？」と感心して話しをすると「はったりだよ」と堂々と言うのを見て、営業職は人種が違うかも･･･と思ったことは一度や二度ではありません。

本当ははったりをかませればいいのですが、そうは行かない小心者のエンジニアは地道に実力を身につけるしかないのです。

実力を付けたとき、はったりではなく堂々と「○○ができます」と言えるようになってます。

ITエンジニアの進む道は多様

どんな職種であれ自分のキャリアパスは気になるところです。

キャリアパスとは、この先自分はどのような成長ができて、その結果どんな仕事ができ、どのような生活を送れるようになるか、ということですね。

自分の体験も交えキャリアパスについて考えてみたいと思います。

僕は大学を卒業して入った会社はよく名の知れた電子機器メーカーでした。

新卒から何でも任せてくれる会社で、製品作りにすぐに関わらせてくれました。

自分が担当した製品が、全世界で100万個以上売れると聞いたとき、うれしいというより「こんな自分にそれだけの確かな製品が作れるのだろうか？」と不安を覚えました。

しかし、その不安は一時的なものでひたすら製品作りに邁進し4年で3つの製品を世に出すことができました。

「俺だってやればできる！」

そう自信を深めていたときに、ふと気になったことがありました。

それは10歳年上の上司のことです。

経験豊富で信頼できる先輩としていろいろなことを教わっていましたが、その上司は10年経っても私と同じような製品作りに携わっていました。

その上司は根っからのエンジニアという感じの人で、その仕事を楽しんでいるようでした。

ですので、製品作りにこだわってやっているのは間違いないのですが、私の目には「10年経っても今と同じことをするのか･･･」という不安に映りました。

僕が携わっていた製品とは電子機器で、その中のプログラムを開発する仕事です。

当時ですら、世の中にはパソコンやワークステーションなど汎用化されたOSでソフトウエアを作ることが行われ始めていた時代でした。

「このまま小さな世界に埋没していていいのだろうか？」

入社4年の若造の頭にそんな不安が浮かんできていました。

思い切って転職

そんな不安から半年くらい経った頃でしょうか、プロジェクトも一区切りしたのを機に転職することにしました。

転職先はワークステーションの開発をしている大手企業です。

福利厚生も整っているとの評判の会社でした。

「より汎用的で大きな仕事に関わりたい」

そんな気持ちで転職を決めました。

私が4年いた会社も十分に魅力的で、1年1作程度のペースでいろんな製品作りに関われるのは何物にも代えがたい魅力でしたが、より長期的な展望でキャリアを変えることにしました。

長い目で見て、この転職は大成功だったと言えます。

転職は目標設定が大事

この転職が僕にとって大成功だったと言える理由は、「汎用的で大きなソフトウエア開発に関わり、推進する力を身につけることができた」と言えるからです。

しかし、これがわかるには15年から20年ほどかかりました。

前職では1人で開発する組み込み型の小さなソフトウエアのプログラマでしたが、転職先では数人〜10人以上の開発をするのでは求められる能力が大きく違いました。

特にプロジェクトの管理が厳格なことやその過程で生成される仕様書や設計書、検査の設計やその記録など、前職ではあまり重視されてこなかったものが必要となりました。

それらをひとつずつ身につけて自分でできるようになるには相応の時間が必要でした。

最初の頃は前職の経験が生きる仕事でしたが、自分でも徐々にやりたい範囲を広げていきましたので、そのたび壁にぶち当たるということが続いていました。

戦略的に能力を高める

ITエンジニアとしての経験が30年くらいになりますが、本当にこの世界にいて良かったなと思うのは、プログラマとしてのスキルを高めることを目指さず、外注マネジメントやプロジェクトマネジメントなど、プロジェクトの管理者としてのスキルを上げてきたことによります。

仕事で成果が上がったと思うのは、プロジェクトの目標が達成されたということより、お客さんが喜んでくれた時が最もうれしいです。

直接にお客さんがいなくても、商品が売れることで会社に貢献できればそれも良いです。

お客さんに喜ばれる、あるいは売れるためには、お客さんの困りごとを解決してあげることが大事で、それが実現されたとき感謝されたり売れたりします。

逆に言えば、プロジェクトは成功したのに（納期を守って作ったのに）、お客さんに喜ばれなかったり売れなかったら意味がないのでしょう。

そういうゴールを見失わないためにも、プロジェクトマネジメントはとても大事な役割になります。

言われたとおり作るプログラマから、売れるサービスを開発推進することができるスキルを身につけたプロジェクトマネージャになる、これができたからこそ今の僕があります。

プロマネができると強い

プロジェクトマネジメントができるようになると、いろんなことに役立ちます。

プロジェクトとはルーチンではない新しく取り組むことがらですので、世の中の多くのことはすべからくプロジェクトとなります。

プロジェクトマネジメントとは、こういったものに対して、「望まれていることは何か？」「どのくらいお金をかけられるのか？」「いつまでにほしいのか？」というようなことを整理して最適な解決策を出していく、ということです。

もちろん、その結果としてソフトウエアなりハードウエアを作る必要がありますが、最も大事なことはその目的を忘れずゴールに導くことです。

プロマネができて、その上プログラムも自分で書けるとより強いかもしれませんが、僕はプロマネとプログラミングは両立させなくてもいいと思っています。

というのは、プロマネはゴールや仕様をコントロールする必要があり、そのためには費用や納期が許す範囲でよりよいものを目指しますが、プログラマなど実装する人は少しでも楽になることを望みます。

つまりプロマネの目指すことと、プログラマが望むことは相反することも少なくないのです。

ですから、両方を兼ねると「本来はこうした方がいいけれど、プログラミングを楽するためにこうしよう」という妥協が働く可能性があります。

もちろん、プロジェクトを実現するには妥協も必要で、正論ばかり振りかざすと終わる仕事も終わりません。

そんなバランスの取れたプロマネを目指したいものです。

（改行）

ITエンジニアの活躍の場はなくならない

AIがプログラムも書けるようになってきて、ITエンジニアの未来は大丈夫か不安になる人もいるかもしれません。

でも大丈夫！僕は今後もITエンジニアの未来は明るいと断言します。

ITエンジニアの仕事はプログラムを書くことだけではありません。

顧客から要求を正しく引き出し、それを文書化しどういう技術で実現するのが良いか判断して、実行していくことが欠かせません。

確かに、AIは簡単なプログラムであれば精度が高くバグの少ないコードを書いてくれますし、プログラミング初心者の教師として使えるとの話もあるので、上手に使えば省力化につながることは間違いありません。

AIの力を借りながら、より短時間で作業していく、あるいは、より高度なことを実現していく、そういう風に活用することが大事になっていくでしょう。

ITエンジニアが関わる仕事で、人でなければできないことを紹介します。

コミュニケーション

何かしら課題を解決したいとき、まず困っている人から何をどう解決したいのかをヒアリングして聞いて整理していく必要があります。

僕の経験でも、そういった困りごとを持っている人が正しく要求を出すことはほぼできません。

ああしたい、こうしたい、とは言うものの、それがそのままシステムへの要求になることはまれです。

多くの場合、そういった言葉の裏にある背景を聞いていかないと、本当の要求はつかめません。

ですので、そういった困りごとを整理して行く作業は、AIでは難しいと考えられます。

もちろん、今後そういう対話が可能なAIが登場してくる可能性は否定しませんが、要求を聞き出すテクニックのようなものは定型化しにくいので、難しいんじゃないかと思ってます。

人から要求を聞き出すことは人がやり、聞き出したいくつかの困りごとを分類、整理するような作業をAIに任せると有効ではないかと思います。

プロジェクトをうまく進めていくためには、常に要求を頭に置きながら問題の解決に当たることが欠かせません。

AIに何かを判断してもらうには、要求を文書化してそれを使って判断に利用してもらうことが必要になるでしょう。

ユーザー体験や運用の設計

ユーザー体験や運用設計のような、人が主に使うものに対してどういう仕様にするのがよいだろうか？ということは、人が考えた方が良いでしょう。

良いユーザー体験を考えるには、人がどういうシーンでどう感じるかということを考えながら設計しなければなりません。

その結果、そのサービスなどを使って楽しいと感じてもらえるようにすることが重要です。

その過程では、ストーリーマッピングを作ったりすることによって、ああでもないこうでもないと議論しながらようやく決まっていくことが多いです。

運用設計もすべては自動化できずに、人が対応しなければならないことも少なくないです。

本来なら全部自動化できればいいのですが、すべてを自動的に対応できるようにしたら、運用のための開発コストがバカになりません。

そういう問題もあって自動化できない部分を人が対応しなければならいことが多いのが現状です。

こういうものに対して、どこまで投資して、どこを人でやればいいか、というようなことをそのときの開発予算などを加味しながらバランス良く判断していく必要があり、AIでの判断が難しいところと思います。

プロジェクト管理やリーダーシップ

プロジェクト管理とかリーダーシップというのは、人間力のようなものが重要になってきますので、こういったものはAIには取って代われない分野と思います。

プロジェクトが平時で特に問題がないときに、取るべき対応のようなものはAIでも語れるでしょうけど、プロジェクトを進めていくときはそんなに定型的なパターンで進むことばかりではありません。

プロジェクトに関わるたくさんの人の感情が絡み合っていますので、正論だけ振りかざしていても残念ながらプロジェクトはうまく動かないものです。

時に「この人が言うんだからやろう」というような感情の部分が欠かせません。

大上段にあるべき論を振りかざしてくるような人には誰も付いていきたくないんです。

機械的な判断ではない、人の機微というものが大事になります。

複雑なものやカスタムソリューション

AIが得意とするものは、過去に事例があって対応方法が確立されているものになりますから、まだ未知のものについては対応が難しいと言えます。

その点で、複雑な問題をそれぞれ絡み合っているものを解きほぐしながら解決策を導いたり、顧客に独自の制約や過去のしがらみがある場合のカスタムソリューションなどは、人が考えていく必要があります。

このように考えてくると、いかにAIが発達しても人の代わりにはならない部分は存在します。

AIの力を生かしながら、どうやってより効率的に、より速く問題を解決していくか？

ITエンジニアの今後はその力が求められるでしょう。

ITエンジニアは幸せか？

ITエンジニアという職業は幸せか？と問われたら、僕は幸せな職業だと答えます。

確かに納期に追われているときはしんどいのは事実。

納期までに顧客の要望を必ず実現しなければならず、そのために時には徹夜をしてでも完成させなければならないときがあります。

そういうときは、確かにしんどいです。

でも反面、意外と自由が多いです。

納期に間に合うなら、その間ある程度裁量に任されて仕事を進めることができますし、有休を取って旅行に行くこともできます。

パソコンひとつで仕事はできるので、在宅で仕事をすることができますし、ネットで仕事を受けることもできます。

ネットで仕事を受けることができる職種は増えていると思いますが、ITエンジニアであればより受けられる仕事の幅は広いです。

ビジネスで一儲けを目指すようなタイプではなく、ビジネスを考えることは得意ではないですが、コツコツ積み上げ、その一つ一つの積み上げを地味に喜んでいけるタイプの人間が多い気がします。

そんなこんなで、僕はITエンジニアの仕事が好きです。

ITエンジニアは自由が多い

エンジニア全体に言えることだと思いますが、納期までにどうやって実現するかは、自分の裁量によるところが大きいです。

どんな仕事も、一人でやっているケースはあまり多くないので、すべてのことを一人で決められるケースは限られるでしょうが、いつまでに何を終わらせて、その先完成させるまでの計画は自分で立てることが多いです。

その計画の実現のために日々何をやるかは自分で決められますので、そういう意味で割と自由に時間を使うことができます。

僕がいた会社では、仕事の納期が年末に設定されていないような人は、年末になるとクリスマスの頃から年末年始にかけて2週間ほど休む人は少なくなかったですし、そういう自由が認められる点がすごく良かったと思ってます。

ITエンジニアっていいな、とこういうときに思います。

もちろん、いいことばかりでないので次に話しますね。

ITエンジニアの苦しみとは

自由な反面、ITエンジニアには苦しみもあります。

僕はときどき「エンジニアは割に合わない」と思う時があります。

それは、100%完成させないと終わらないからです。

100%の意味は、例えばプログラムをすればすべての部分が正しく動かないといけませんし、いろいろなテストを実施してもすべての項目で問題なく動かなければいけないからです。

例えば営業であれば、売上がこちらの希望の100%に達しないことなどもあると思います。90%だけどOKにするか！という判断もできると思います。

ところがプログラムは隅々まで完全に動かなければダメです。

お客さんの要望に応えられないからです。

ちゃんと動かないところがあれば、使うお客さんにの期待通りに動かなかったり、エラーメッセージが出るなど、不具合があることが一目瞭然なのでごまかしが利きません。

動かない部分が仮に全体の0.1%しかなくて残り99.9%が正常に動いていても、その0.1%が動かないことによってお客様にサービスを提供できないこともあります。

そして、100%に持って行く作業が生みの苦しみになることもあります。

僕が「エンジニアは割に合わない」と思うのはこういうときです。

仕事では、80％のできで十分、それを90％、95％を目指すから大変になるんだと言われます。

エンジニアの仕事は、90％では全然足りなくて、100％を実現する仕事なのでそこが苦しいです。

常に成長できる

ITエンジニアが関わる技術は日進月歩です。

どんどん便利で新しい技術が現れてきます。

より便利なサービスは生まれてきますし、プログラミングの世界もより開発が簡単になるようなフレームワークも次々と登場してきています。

そういう新しいものへのキャッチアップが欠かせませんし、それが大変ではあるのですが、何よりそういうことに触れることで自分が常に成長できます。

以前なら使いこなせなかったサービスを今は使いこなして効率化できる、1年前ならできなかったことが今はできるようになる、そんな成長を日々感じることができます。

常に成長が必要って苦痛に聞こえるかもしれませんが、実はとても楽しいことです。

自分が成長しているって楽しいことです。

成長の途中に苦しい段階はあります。

自分が成長しているかわからず、悩むときは誰しもあると思います。

いろんな職種でそれぞれ成長が求めるものは違うと思いますが、ITエンジニアの成長はわかりやすいし僕は楽しいものだと思います。

ITエンジニアの生活

自由もあり、追い込まれるときもあり、でも成長を実感できる、それがITエンジニアの日常だと思います。

確かにパソコンに向かっていることは多いので、「オタク」と思われるかもしれませんが、決してそんなことはないです。

社交的ではない人もいますけれど、なんだかんだおしゃべりです。

ITエンジニアって追い込まれてくると何も言わずにパソコンとにらめっこしてバグ取りすることになるのですが、ただひたすらコードのバグを追いかけていると時を忘れます。

ホント、あっという間に時間が過ぎます。

その結果、問題を解決できたとき、心で「ヤッタ！」と叫びたくなります。

うれしすぎて、リアルに声が出るときもあります。

ニヤニヤしてしまうときもあります。

そんな時周りの人から「どうしたんですか？」と問われ、「なかなか取れなかったバグが解決したんです！」と言って「良かったですね！！」と言ってもらえるのはITエンジニアだけですね。

こういう至福の時間は普通の人にはわからないかもしれませんね。

目指すはITのよろず相談

ITエンジニアと言えばいろいろな捉え方がありますが、僕は「ITの困ったことがあれば相談したら解決できる人」のような幅広い知識を持つことが大事だと考えています。

ITエンジニアとしてどこか得意な分野を持つことは欠かせませんが、その専門性だけではちょっと物足りないです。

専門性は高めた上で、ITに関わるいろいろなことに知識を深めていくことで、よりスキルが磨かれたり領域広げるきっかけとなり得ます。また、その経験が意外なときに役立つことがあります。

そして、何か頼まれたときに「この人ならITのことはだいたい解決してくれるな」と思ってもらえる存在になる、というところを目指しましょう。

そのためにもまずは得意分野を持ち、そこを起点に広げていきましょう。

具体的にどういう知識やスキルが必要なのか、紹介しましょう。

PCなどハードウエアの選定に強くなる

ITを使う上でハードウエアは欠かせません。

PC・スマホ・タブレットなどの端末、Wi-Fiルーターなどネットワーク機器、データを保存するためのUSBドライブやネットワークストレージなど、いろいろな機器を使います。

こういったものを選定する必要があり、多種多様な機種の中から何を選べばいいのか見極める必要があります。

最初の頃は何を基準に選べばいいのかわかりません。

PCならWindowsなのかMacなのかという選択がありますし、CPUのスペックを選んだりメモリやSSDの容量を決めなければなりません。

安ければいいわけでもないし、お金をかければいいものが買えるわけでもありません。

性能と価格のバランスは製品ごとに違いますので、どんな性能のものをいくらの予算で買うのか、という目利きになる必要があります。

会社のPCであればサポートも必要になる場合もありますし、故障したらすぐに代替品が提供されることも大事な要素になるかもしれないです。

新しいモデルが出ると旧モデルが安くなりますし、旧モデルで問題あるのかないのか、最新のOSが出たときにバージョンアップができるかどうかも考えておくべきことです。

そういったハードウエアの選定のための基準をまずは自分なりに作り上げる、そして条件に適した商品を選べるようになると、自分にも会社にもプラスになります。

ネットワーク環境の構築

ネットワークはネットの時代には不可欠になりますが、会社でネットワーク環境を作るとなると意外と難しいです。

ネットワークはWi-FiやLANケーブルで端末間をつなぎ、ネットワークドライブやプリンタなどを接続して利用できるように構築します。

ところが、接続できる・接続できない、プリンタやドライブが見えない・印刷できない、という問題が結構発生します。

解決しようと試みますが、最大の難所はネットワークというのは目に見えないので原因の特定が難しいということです。

例えば、すぐそこにWi-Fiルーターがあるのに接続できないという時に、Wi-Fiが出している通信方式に端末が接続できないのか、接続できる端末を制限しているのではないか、などひとつずつ調べていく必要があります。

また、ネットワーク上にドライブがあるのに接続できないという場合には、ドライブ側の認証の設定が正しいか、接続のプロトコルは合っているかなど調べていきます。

プリンタやスキャナに接続できない場合は、プリンタやスキャナを利用するためのソフトを使うため、さらに難しい場合があります。

ひとつずつ要因と思われることを探り、絞り込んでいって原因を見つけます。

経験を積み重ねることが必要なスキルです。

OSとアプリケーション

MacかWindowsか？という選択は個人であれ、企業であれ悩ましい問題になると思います。

企業であればWindows一択のところもあるでしょう。

以前ですと、Microsoft Officeの互換性の問題が大きかったと思いますが、今は大きな障害ではありません。

MacでMicrosoft Officeで使ったときのファイルの互換性が保証されたことで、ビジネス文書を作る際にはMacでもWindowsでも問題なくなったからです。

※それでもフォント等によるレイアウトの崩れは起きがちです。

今Windowsが選択される理由の多くは、企業が求めるセキュリティ関係の機能を付けるなど機能拡張がしやすいということがその一つの判断になっていると思います。

一方、MacはWindowsとは異なる操作性になりますが、とても使いやすい部分もあり、今でも人気は高いです。

使いたいアプリケーションを考えて、どちらを選ぶべきかを選択する必要があります。

クラウド時代になって、MacでもWindowsでも同じアプリケーションが動くようになってきていますので、クラウドアプリケーションによる選択はあまり悩む必要はなくなりました。

それでもWindows出しか動かないアプリ、Macにしかできないことはわずかにあります。

OSやアプリケーションの選択は難しいことですが、それができるようになるくらい知識を付けましょう。

そのためにも、アプリケーションの使いこなしトラブルシューティングをしていくことで、少しずつ知識が蓄積されます。

ソフトウエア開発

ソフトウエア開発とは、すなわちプログラミングをするということです。現在ですと、ビジュアルにアプリケーションを開発するノーコードによるアプリケーション開発も含めるでしょう。

ソフトウエア開発と呼ぶときは、単なるアプリの開発というよりは、チーム開発や決められた開発手順に則って開発するという意味があります。

何か1つのアプリを開発するといっても、開発言語や使う技術の選択は一つではありません。

複数の言語やミドルウエア、フレームワークなどの中から用途に合ったものを選ぶ必要があります。

これを選定できるようになるには相当の経験が必要になります。

※ちなみに僕はプログラマとしての経験が薄いので、言語やフレームワークの選定は自信を持ってできません。

ソフトウエア開発は、プログラマだけじゃなく、開発全体を推進するリーダーの役割も欠かせません。

プログラマがたくさんいても船頭となる人がいなければ、船は思うように進んでくれないからです。

そういう、プログラミングをするだけじゃなく、その先にリーダー的な役割になってソフトウエア開発をまとめる道も目指しましょう。

プロジェクトマネジメント

プロジェクトマネジメントは、上に書いたリーダーになってソフトウエア開発進めることや、さらにその上位で複数の開発チームを統合するなどして推進する役割を持ちます。

プロジェクトマネジメントには、予算の獲得や計画の策定、プロジェクト関係者への合意、開発の推進などあります。

プロジェクトマネジメントはそれだけで1冊の本ができてしまうくらい重要な仕事なので、やるべきことは広範囲ではありますが、ITエンジニアの将来像の一つとして描いてもらえたらと思います。

最終的なプロジェクトマネージャとなって、開発を率いることを目指しましょう。