【キャリア】IT業界の門を叩く者へ 〜現場視点で語る適性チェック〜 Webアプリエンジニア編
はじめに
この門をくぐる者は一切の希望を捨てよ
ダンテ・アリギエーリ『神曲』地獄篇 第3歌
対象
- 他業種からIT業界への挑戦を考えている社会人向け。
- 特にWebアプリ開発を主とするITエンジニア。
「夢を持って飛び込みたい！」という方には少々刺激が強いかもしれません。本記事は厳しい現実の話ばかりですが、世の中にはやりがいや楽しさに満ちた記事が沢山ありますので、苦手な方にはそちらをおすすめします。
先達の方へ
既にIT業界の深淵を覗いてしまった先輩諸氏におかれましては「これが必要なチェック項目や！」というご意見・ご感想がございましたら、
- 職種：バックエンドエンジニア・フロントエンドエンジニア etc…
- 体験談：法律・契約に違反しない範囲で
と共に、コメントにて補足いただけますと幸いです。
主語デカを防ぐために副題を『Webアプリエンジニア編』として保険をかけさせていただいておりますが、それでも正直まだ主語は大きいと思います。本記事は私の業務経験をもとにまとめています。職種・環境が異なれば事情が違うことも多いので、その点はご留意ください。ここまで書いても恐らくクソリプは飛んでくるでしょう。
インフラエンジニア編・ネットワークエンジニア編などが書きたいという酔狂な方は、『IT業界の門を叩く者へ 〜現場視点で語る適性チェック〜』というタイトルおよび章立て・構成など、オマージュやパロディはご自由にどうぞ。
著者略歴
Webフレームワークを用いたアプリケーションを開発しているITエンジニアです。職種としてはバックエンドエンジニア・フロントエンドエンジニアに相当します。
いわゆるベンチャー企業から創業50年を超える中小企業まで、炎上している現場から疲弊している現場まで。そして比較的まともな企業・現場も合わせて、一通り経験してきたつもりです。まともな現場率は30%くらいです。
多少ぼかしますが、東日本大震災後の時期にフリーター（コンビニ店員）からIT業界へ転職し、現在ではフリーランスのITエンジニアとして活動しています。成功しているかは分かりませんが、食うには困っていません。
今はただ平和に安全に良い製品を作り続けられる現場を探しています。
現場視点で語る適性チェック
どの項目からでも読めます。
転職する貯金と覚悟がある
この業界に入るための最初の転職のことではありません。より良い現場を求めてガチャを回すという意味でもありません。法律違反上等のブラックな環境に足を踏み入れてしまったとき、戦略的撤退するという意味での転職です。
治安の悪い現場が多い（当社比）
履歴書や職務経歴書は面接で見られるため、短期間で辞めた案件が並ぶと印象が悪くなります。面接で説明できる正当な理由があればよいのですが、その説明も伝え方を工夫してもネガティブなものであることに違いありません。
というのも厄介な人である可能性が高いからです。例えば、
- プロジェクトの途中で突然出社してこなくなる。
- 技術力不足で戦力外通告を受けた。
- 契約違反に該当する行為があった（許可されていない環境で開発）。
- セキュリティ脆弱性などの注意義務違反があった。
など余程のことがない限り、短期間で現場を移ることはないでしょう。しかし、
- パワハラや長時間労働が常態化している。
- 給料未払・基本給の据置・税金の未納。
- ライセンスを無断で使い回す。
- 入社時の約束（配属・キャリア）を守らない。
などコンプラ的に問題のある企業が存在するのは事実です。特に未経験からの転職ともなると残念ながら、こうした現場に当たる確率は無視できません。
中堅エンジニアが人材不足で疲弊しているのに、まともな教育コストを払わないで未経験者歓迎なんて募集をかけている中小企業に、受け入れ体制が整っていると思いますか。「要領の良い人が運良く生き残る」のが実際のところです。
冷静に戦略的撤退の判断を
不幸にもこうしたヤバい現場に遭遇してしまった場合、直ぐに次を考える必要があります。もし異動願を出せるのであれば、期限を決めて打診し、文面として残しておきましょう。まともに取り合ってもらえない可能性が高いです。
企業自体に問題があるという場合、否応なしに転職活動を始めることになります。そのとき貯金がなければ選択肢は狭まります。精神的にも疲弊します。最低でも3ヶ月は働かなくても生活できる貯金を確保しているのが望ましいです。
そして常日頃から転職市場の動向にアンテナを張っておきます。何を身に付ければ食いっぱぐれないかを調べ、必要なら資格試験を受けるなどして研鑽を積みましょう。
また決断を下すのは自分自身です。誰もその責任を取ってはくれません。まともな判断ができるうちに、転職を自分の意思で決めなければなりません。次の仕事が直ぐに見つかるかも分かりません。職歴が空けば焦りも出ます。無職であることに病みます。
いざというときに備え、必要であればすぐに動ける覚悟を持つことです。
貯金は確保できていますか？
いざというとき転職の判断をくだすことができそうですか？
最低限の法律知識が持てる
業務上、必要な法律の勉強をしない人が多すぎる気がします。開発者である前に社会人です。技術の勉強も大事ですが、最低限守るべき法律は守ってほしいです。
ITエンジニアを取り巻く法律
例えば一口にチーム開発といっても、メンバーにより契約内容は異なります。正社員・派遣社員・フリーランスなど、様々な人が各々の法の下に契約を結んでいます。
- 労働基準法
- 労働者派遣法
- 下請法・特定受託事業者に係る取引の適正化等に関する法律
- ...
企業の人事部や面談・面接を実施する役職者ですら把握していないことがあります。現場のITエンジニアともなると、請負契約と準委任契約の違いすら理解していないことがあります。有名なのは責任範囲の違いですが、指揮命令権すら知らない人が多い昨今の労働環境はどうかと思います。
最近、フリーランス新法も施行されました。まだ確認されていない方は、この機会に一度目を通しておくと良いかもしれません。
なにしろパワハラ・偽装請負・経歴詐称・長時間労働などの用語が、SNSで当たり前のように飛び交う業界です。私も何度か遭遇しています。
また度重なる増税により注目度がアップしていますが、自分の給料や報酬がどのように確定するか、きちんと見直したことがある方は少ないのではないでしょうか。
- 所得税法・消費税法
- 厚生年金保険法・国民年金法・国民健康保険法
もしフリーランスになるなら確定申告は必須です。こちらはインボイス制度で更に面倒になっております。会計ソフトの準備や帳簿の管理といった税務対応が不可欠です。もしくは諭吉（栄一）を生贄に税理士さんを召喚します。
自浄作用のない業界で自衛するために
こうした法律や制度を知らないと、気づかぬうちに損をします。最悪の場合、自分が加害者になってしまうケースもあります。
他業界でも必要な知識ではありますが違いがあるとするならば、問題が表沙汰になるのは重大なインシデントが発生したときだけという点でしょうか。それも大規模なシステム障害や情報漏洩などの、全体からすれば微々たる不祥事だけです。
IT業界ではセキュリティの都合上、企業をまたいだ横の情報共有ができません。今後もこの業界で食べていくなら、内部告発なんて真似はできませんし。狭い業界なので口コミでも書こうものなら、誰が書いたかなど直ぐに知れるでしょう。接客業のように目に付く場所でもありません。
脆弱性を作り込むような人も案件を変えてITエンジニアであり続けますし、何回もやり直しさせることを前提で作業を丸投げするのが当たり前の現場もそのようにあり続けます。訴える時間も金ももったいないので、まともな人から辞めるだけです。自浄作用はありません。
もちろん全ての人や現場がそうではありませんが、一定数存在するのは事実です。違法な働き方を強いられないためにも、自分の身を守るための知識は持っておくべきです。そして何とか自力で助かってください。
まずは自分に関係のあるところからで構いません。
法律の勉強です。脱落するなら今のうちですよ？
交渉力がある
一般的には一緒くたにコミュニケーション能力といわれますが、現場視点では交渉力という単語がより適切だと考えています。ITエンジニアの職務上のコミュニケーションは、そのほとんどがプロジェクトの意思決定に関わるものです。
全員が完璧に満足する仕様は存在しない
技術的な制約もあるでしょう。顧客のお財布事情もあるでしょう。営業の思惑や、社長の意向もある筈です。製品一つとってみても、様々な立場の関係者が利害関係に苦労しています。
仕様調整において交渉を円滑に進めるためには、己を知り相手を知り、技術を理解し、時に弁論術や心理学を駆使して、議論を適切に進める必要があります。論破する必要も、詭弁を使う必要もありません。むしろ使ってはいけません。それは信頼を損ねる行為です。
重要なのは双方が妥協点を見つけ、最終的に順当な落としどころを見つけることです。
特定の提案が絶対的な正義ということは通常ありません。大抵はどの案にもメリット・デメリットが存在し、利害関係による損得の程度の問題になってきます。ITエンジニアがライブラリの仕様上A案がいいと思っても、顧客の要望を素直に聞くとB案の方が適切、ということは往々にしてあります。
このときいかに争いを生まずに、上手く着地できるかです。A案なら少しでも使いやすくなるよう設計を見直す、あるいは他の機能で顧客の要望を優先する、B案なら独自実装部分に保守費用を上乗せするなど。交渉材料は色々あるでしょう。
厄介な相手をいなす処世術
仲良くなる必要はありませんが、厄介なメンバーを相手に波風立てない大人な対応も必要です。意味もなく衝突してチームの生産性を下げるのは逆効果です。真正面から取り合わない、イネイブラー（問題行動を容認する人）にならないようにするなど、自衛に徹します。
もちろん交渉は一方通行ではないため、相手が論破上等のスタンスでは成立しません。あまりにも酷い場合は撤退するしかないと思います。ただ「1人でも苦手な人がいたら即転職」していては正直厳しい業界です。
私は客観的に違法性・実害があるかで判断するようにしています。たとえ個人的にいけ好かなくとも数年同じチームにいることもありますし、未払・パワハラなどコンプラ違反が業務に支障をきたすレベルでは、数ヶ月以内に契約を終了しています。
現場次第というより経営層次第でしょうか。厄介な顧客や営業、メンバーが何らかの理由で放置されている現場では、ときにハッキリと断るタイプの交渉に迫られます。
相手の言いなりになるという選択肢も浮かぶかもしれません。しかし無理難題を提示されたり、誤った主張を押し付けられたりすることは、現実問題としてあります。例えばセキュリティ上の脆弱性を無視した仕様の強制や、真夏にサーバールームの空調を止める指示などです。
丁寧に理由を説明した上で、それでも「やれ」と言われたら交渉せざるを得ません。万が一、どうしても実行せざるを得ない場合は、録音や念書を取るくらいの慎重さが必要です。
ITエンジニアは日々が意思決定の連続です。
交渉の場に立つ勇気はありますか？
身体が丈夫・体力がある
ITエンジニアはデスクワーク中心の仕事なので、一見すると体力的に楽な仕事に思われがちです。しかし長時間同じ姿勢でキーボードを打ち続けるため、別の意味での体力が求められます。
心身を壊す様々なケース
長年勤めたITエンジニアやマネージャーの中には、四十肩・五十肩を患い整体通いが日課になる方がいます。腰を痛めて長時間座るのが困難になる人も。
目は酷使されドライアイとなり、花粉症の季節ともなれば眼精疲労とのダブルパンチが目を襲います。歳を取れば老眼・近眼との戦いが始まるでしょう。
ストレスで胃腸や耳、精神をやられる人もいます。適応障害や鬱病をはじめ、ITエンジニアは病みやすいといわれています。突然職場に出社しなくなる、気が付いたら誰かが休職していた、ということも。
食生活も乱れがちです。仕事のキリの良いタイミングでファーストフードやコンビニ弁当を買いに行き、調味料といえばマヨネーズや醤油で濃いめにコレステロールもたっぷり。客先や同僚との飲み会で肝臓を酷使し、運動不足からお腹周りには脂肪が蓄積していきます。
健康への投資と運動習慣
もしフルリモートを夢見ている方がいらっしゃいましたら、机と椅子にだけはお金をかけることを強くおすすめします。合わない机・椅子は近い将来、あなたの首・肩・腰を破壊します。
身体に不調を感じたら、なるべく早めに病院へ。歯医者には定期的に検診に行きましょう。健康は一度失うと二度と返ってきません。
このままではいけないーーそう気づいたITエンジニア達は30歳を過ぎた頃から、健康志向に目覚めます。筋トレ・ジョギング・ウォーキング・ジムトレーニングなどに挑戦し始めますが、自制心がなければ続かないのが現実です。年に一度の健康診断前に、ちょっと頑張るくらいです。
ラジオ体操でも散歩でも、何らかの趣味・スポーツでも構いません。運動する習慣を身に付けましょう。できれば毎日、せめて毎週。小中高大学と貯金してきた体力も、歳を取れば維持するためのコストを払わなければ、どんどん衰えていきます。
山野を走り回り採集や狩猟をしていたホモサピが、1日8時間以上座りっぱなしなんて、もうそれだけで不健康を積んでいるんです。
ちなみに実家にいる・結婚している場合は、この限りではありません。
身体は丈夫でしょうか。体力はあとどのくらい持つでしょう。
日々、健康に気を配っていますか？
ストレスマネジメントができる
コロナ前はカラオケでオールしたりもしましたが、今はマクドナルドでポテナゲ特大とバーガー単品を買ってドカ食いすることが多いブログ主です。
ぶっちゃけ関わる人次第
案件であれ経営層であれチームであれ、まともな人で構成されているか次第です。取り扱う技術はどこも大きく変わらない訳ですから、労働環境に差が出るとすれば人間関係や環境です。
案件の先には発注した企業があり人がいて、要件定義や仕様調整がきちんとできる取引先であれば、炎上することもそうそうないでしょう。まともでない場合、期日を過ぎても仕様が決まらないのに納期はズラせない、後出しで大事な要件を追加してきた、なんてことになったりします。
またチームのメンバーが4人だとして、週5日・1日8時間一緒に仕事をしますよね。チャット・プルリク・ミーティングなどを考えると、業務的に関わらないようにすることの方が難しいので、苦手な人やヤバい人とは至近距離で上手くやっていく必要があります。
ブリリアントジャークやトキシックワーカー、脆弱性をぶっこんで来たのに契約期間が終わるまで面倒を見なければならない人、マネジメントしないのにマネージャーの席に座っているだけの人（申し訳ありません、少なくない私怨が入りました）。
とにかく常に供給され続ける負の要素に対して、ストレスをストレスと思わないで楽しむ術・ストレスを受けても早めに解消する術を持つ必要があります。
迷ったら自分の人生を大事に
仕事とプライベートの切替がスパッとできる人が良いです。時間になったらGet Wild退勤して、頭の中はもう明日のライブのことで一杯！ 仕事のことは出勤してから考える、くらいでもいいです。もちろんストレス要因が全くなく、趣味がITエンジニアの方は例外で、ずっと考え続けていても問題ありません。そのような現場と巡り会えたことを感謝しましょう。
逆に仕事でのミスや嫌な上司のことが頭の中でぐるぐる回ってしまうような人は要注意です。お風呂に入っても布団に入っても、仕事のことが頭から離れず。土曜は1日中もやもやしていて、日曜の午前中にようやく抜けたと思ったら、午後からは月曜のことを考えてしまう……そんな人は、精神を病んでリタイアする可能性が高いです。
平日夜および土日で、しっかりとストレスを発散できるかどうか。仕事以外のコミュニティや趣味を持つことは、とてつもなく大事です。ゲーム・料理・散歩・音楽・アニメなど、何でも構いません。仕事を忘れて没頭できるストレス発散方法を持っていますか。
軽視されがちですが、うつ病や適応障害は深刻な病です。一時のキャリアだけでなく、その後の人生に影響を及ぼすデバフとなり得ます。もし自分がそうした病みやすい性質を持っていると感じるなら、老婆心ながらIT業界を避けたほうが良いと思います。
会社の社員に代わりはいますが、あなたを守れるのはあなただけです。
ストレス耐性は高い方ですか？
日本語の文章が読み書きできる
この業界で最も難しく、最も争いを生むもの。
それが日本語です。
ITエンジニアが読み書きする書物
ITエンジニアがコードを書いている時間は、業務全体の2割にも満たないのではないでしょうか。自動テストのコードも含めれば、もう少し増えるかもしれません。コードも含めた多くの場面で、他人が読むための文章を書きます。
- 各種仕様書
- 要件定義書・基本設計書・詳細設計書・試験仕様書
- API仕様書・ファイル仕様書・外部仕様書
- README.md・Wiki・環境構築手順書
- コード内のコメント
- チケット・コミットメッセージ・プルリクエスト
- 参考資料・会議のレジュメ・議事録・日報
- チャット・メール
ぱっと思い付くだけでも、日々これだけの文章を書いています。
そして書いている以上に読んでいます。上記はもちろん、
- ライブラリ・フレームワーク
- 公式ドキュメント・GitHubのイシュー&プルリクエスト
- OSSのソースコード
- 技術記事・技術書・ニュース
- エラーメッセージ・ログ・通知
など、様々な文章を読んでは処理しています。
日本語なのに日本語が通じない話
『英語の読み書きができる』は次の段階です。まずは日本語をしっかり書けるようになりましょう。日本語がズタボロな状態で英語を気にするのは順番が違います。いわずもがな英語が公用語のような外資系企業の話ではありません。
まずは『てにをは』と文法を守った文章を書く。主語は略さない。客観的な視点を徹底し、視点をコロコロ変えない。意味が通じる文章を書く。大事なポイントは誤解を招かないこと。行間や解釈の違いで混乱を生じさせないことです。
最低限、意味が通じる文章が書けないと、この仕事は難しいと言わざるを得ません。仮に何とか採用されて働けたとしても、誰かしらに迷惑をかけてしまうことになります。
また文章を書くということは、その文章は誰かに読まれるということです。何を当たり前なことをと思われるかもしれませんが、なら「解読班はよ」という迷台詞やクソリプは生まれません。相当酷く稀なケースですが、業務でこの類の文章コミュニケーションを見かけたことはあります。
業務の大部分が文章の読み書きとミーティングで構成される職業です。様々な文章も技術も全て、誰かが造ったもの・書いたものです。書き手であれ読み手であれ、文章の向こうの誰かに敬意を払うことのできる方であれば、上手くやっていけるのではないかと思います。
テキストコミュニケーションは得意ですか？
商売道具の使い方が分かる
仕事がデキる方は、商売道具を使いこなすのは勿論、丁寧に手入れし、大事に使うそうですね。
普及したデバイス・ツールを使いこなす
パソコンやキーボード・マウス・ヘッドホン・スマホ・ゲームパッドなど、ITエンジニアは様々なデバイスを使います。
最近はスマホしか使ったことがない世代もいるとの噂ですが、結論から申し上げるにキーボードはまだ必要です。音声入力やAIによる議事録生成が進化しているとはいえ、どんな現場でも使えるとは限りません。プログラムや文章を音声入力だけで書くのも難しいです。最終的な微調整は手作業でしょう。
フルリモートの企業では、会議は必然的にオンラインになります。ヘッドホンの入力・出力設定がおかしい、音が小さすぎる・大きすぎる、雑音が入ってきて会議に集中できない。これらは業務以前の問題です。
Webアプリをスマホ対応するなら、スマホからの見え方や操作感を知っておく必要があるでしょう。また最近では次々にAI関連技術が登場しており、動きの早いITエンジニアはさっさと課金して使い方を学んでいます。
技術の勉強も大事ですが、開発環境を取り巻くツール・サービスも年々進化しています。それらを道具として使いこなしていくことも大事です。
最低限のITリテラシー
現場入りすると真っ先に必要な作業が、各種アカウントの作成とパスワードの変更・二段階認証の設定です（2025年3月現在）。これによらずWebアプリの基本的な使い方は押さえておきましょう。仕組みを深く理解するのは、実際に開発するときでいいかもしれません。
大切なのは仕事をするうえで困らないようにすることです。車の整備士が運転できないのは困るでしょうし、ジャッキの使い方を誤れば大怪我に繋がります。脆弱なパスワードで客先の利用するWebサービスに不正アクセスされたらと考えると恐ろしいです。
最低限のITリテラシーだけは身に付けておきましょう。若い世代は義務教育で教わっているかもしれませんが、転職を考える中高年層は改めて学び直した方が良いと思います。基本情報技術者試験か、難しそうならまずはITパスポートからでも勉強してみましょう。
IT介護という造語をご存知でしょうか。ITリテラシーが低い社員のサポートを行う様を表しています。IT介護する人のことをIT介護士と呼んだりもします。残念ながら常に人材不足のこの業界、IT介護をしている暇はありません。仮に人事が採用しても現場が発狂すると思います。
パソコンをお持ちですか？ また使いこなせていますか？
自走力がある
自走力とはこの場合、自力で仕事を完了させる程度の能力です。
分からない技術があれば自ら調べ、必要な知識を身に付けながら、与えられたタスクをそつなくこなし。手が空けば次にやるべきことを確認して、進んで消化していく姿勢が求められます。
企業側には教育する義務はない
もちろん懇切丁寧に教えてくれる環境もあるでしょうが、激レアだと思っていてください。例えば4月入社で新卒採用と被った場合、例外的に同じ研修を受けられる可能性はあります。
しかし通常、未経験の中途採用1名のためだけに特別なメニューが実施されることは稀です。日々の業務をこなしながら隙間時間で技術習得していくことになります。先輩社員も仕事の片手間に教えるものですから、どうしても資料を渡した上での自学自習となります。
- 『Ruby on Rails チュートリアル』を一通り行う。
- 入門的な技術書を読みスライド資料にまとめて発表する。
といっても学習の方向性を面倒見てくれて、更に勉強の時間もいただけるというのは、それだけでありがたいことです。いきなり難しい仕事が振られて、検収やテストの段階で後出しジャンケンとダメ出しが続出するような現場もあります（これはこれで別の問題はありますが）。
実は私も電話対応や名刺の出し方、JavaやRubyの資格を取るなどの研修を受けたことがありません。自分でWebサイトを運営している話をしたら、研修をすっ飛ばして現場に配属され、その後は中途採用やフリーランスなので、機会に恵まれませんでした。
学無止境・習うは一生
いわゆる定型業務はほとんどありません。
決められた仕様通りに実装することもあれば、アイデアを考え仕様に落とし込む作業から開始することもあります。技術は日進月歩で進化するため、昨日まで使えていた実装方法が、今日には古いと烙印を押されることもあります。
だから常に学び続ける必要があります。しかし今『何を勉強すべきか』は誰も提示してくれません。業務をこなしつつ、技術イベントや言語・ライブラリの更新情報にアンテナを張り、ロードマップを参考に自分で学ぶ内容を選び、資格取得なども進めていく必要があります。このため学校や塾のように明確な目標が提示されないと動けない人には厳しい業界です。
また一度覚えたことを繰り返すだけではない仕事です。同じ言語・フレームワークを使用していても、バージョンやライブラリ、開発する機能の違いによって、実装は毎回異なります。 モンハンシリーズを比較してタイトルごとに最適な動き方を探ったり、Minecraftの最新の仕様を常に追いかけてエレベーターやトラップタワーを作っているようなものです。
技術が楽しくて仕方がなくて、勉強を勉強と思わないような奇人変人がぞろぞろいる業界です。
さあ、一生勉強し続ける覚悟はありますか？
何かする前にまず調べる
コスプレで山に入って猟友会に怒られたり、コミケの文化を知らずにお客様感覚で訪れたり。こうした問題は「自分が素人である」と自覚せずに行動することで起こります。ITエンジニアとて例外ではありません。
「分からない」は恥じることではない！
何かを始める前に目的やルールを調べるのは基本です。誰だって最初は初心者、恥じる必要はありません。知ったかぶりをして無理を通す方が余程ダサく見えます。その無理はきちんと勉強している人にはバレます。無知を自覚し、学びながら挑戦する人こそ評価されるべきです。
ITエンジニアは規格や仕様を理解し、既存の製品・言語・ライブラリを組み合わせて最適化する、いわばカスタムメカニックのような仕事です。もし専門知識なしに見た目のカッコよさと速さだけでカスタマイズしたら、それは車の違法改造と何が違うのでしょうか。
Webアプリの世界では脆弱性や仕様誤りが顧客の損失に繋がることもあります。『安全なウェブサイトの作り方』は必読です。フレームワークによっては専用のページが用意されています。
このような知識に自力で辿り着く方には素質があると思います。
調査した上でやっていいことをやる
「やれること」と「やっていいこと」は別です。生まれた姿のまま公園で遊ぶことは技術的に可能ですが、日本では公然わいせつ罪でお縄になるので法律的にアウトです。その辺で採ってきた野生のきのこを食べることも技術的に可能ですが、最悪命に関わるでしょう。
では我々はそれが駄目なことと、どこで知るのでしょうか。注意喚起の看板？ SNS？ 親や学校で？ では注意してもらえず、教わる機会もなければ、知らなかったで済む問題でしょうか。 冒頭でも述べましたが、技術であれ文化であれ、何かを仕出かす前にまず調べましょう。
特に人為的ミスが直接人命に関わる場合、厳格なルールや法律が整備されます。しかし医療やインフラに直接関係のないWebアプリ・ゲームなどでは、「プログラムが間違ったところで、直接人が死ぬ訳ではない」ため、血で書かれたマニュアルのような厳しい規制が追いついていないのが現状です（その間違いが誰かの人生を狂わせる可能性は十分にありますが）。
「できるから」という理由で「やってもいい根拠」を調べずに行動する人は、この仕事には向いていません。いつか必ず大きなトラブルを引き起こします。そういう人は周囲にも気づかれるものです。直接指摘されなくても、知らないうちに距離を取られていきます。
新しいことを始めるとき、きちんと調べてから始めていますか？
セルフマネジメントができる
夏休みの宿題は7月中に済ませましたか？
8月の第3週くらいに終わっていると丁度良いかもしれません。
タスクを分解・業務を調整する
実際の業務では、期日付きでタスクが振られることが多いです。期日が明記されていない場合も必ず確認します。予想が付けづらいタスクでも、希望や目安はある筈です。例えば「CSVエクスポート機能を8月リリースで提供したい」という具合です。
まずは作業を細かく分割し、どの程度の工数がかかるか見積します。
- CSVエクスポート機能を実装する
- 要件・仕様を確認し、不明点は問い合わせる。
- 実装方法やライブラリを調べる。
- 実装の方向性を責任者と調整する。
- 実装・自動テストを書く。
- 検証環境で手動テストを行う。
内容にもよりますが、ここでは仮に実装開始から試験終了までで10人日としましょうか。いつまでに設計を終わらせて、いつまでに検証環境にデプロイする必要があるか。
もし現在の作業状況を鑑みた結果、納期的に厳しい場合は調整します。9月リリースにずらすか、8月リリースの他の機能を遅らせるか。自分の持っている作業を他の誰かに依頼するか。状況に合わせた臨機応変な対応が求められます。
効率的に余裕を持ってマルチタスク
加えて問い合わせを待っている間に、他の作業を進めます。
- CSVエクスポート機能を実装する
- 実装方法やライブラリを調べる（軽めに先行着手）。
- TwitterボタンをXボタンに改修する
- 公式サイトでガイドラインを読む。
- 社員旅行の打ち合わせに参加する。
- 定例ミーティングのレジュメと資料を作る。
また割込で質問が飛び込んでくるかもしれません。
- 仕様に関する質問に回答する。
- プルリクエストのレビューを行う。
このように自分で段取りを組んで作業を進めます。複数の作業を同時並行で進める力が必要です。例えるなら魚を焼きながら味噌汁を作り、ご飯を炊くようなものです。要領良くタスクを捌くセンスが求められます。
夏休みの宿題を8月31日まで放置するタイプの人には向かないかもしれません。少なくとも7月中には大まかな方向性を決め、頼れる大人に相談し助言を仰ぎ、8月前半で大体仕上げて最終チェック、残りで質を高めるようなスケジューリングでありたいところです。
そうそう、割込タスクが飛び込んでくるかもしれませんので、常に余裕は持っておきましょう。
是非、子どもの頃の自分ではなく「今の自分が計画を立てられるか」で考えてみてください。できそうでしょうか。
正解のない課題を解決できる
学校のようにあらかじめ正解が用意されてはいません。正解があるかどうかすら分かりません。何をもって解決したとするかは、チーム・マネージャー・営業・顧客など利害関係者と相談しながら決めます。
要望「東京から大阪に行きたい」
例えば「東京から大阪に行きたい」という要望があります。
どう解決しますか？
直ぐに「新幹線に乗ればいい」と思いましたか？ 確かに新幹線は交通手段の一つですが、他にも飛行機・高速バス・車・徒歩など様々な移動方法があります。
また真っ先に移動方法だけに的を絞るのも考えものです。
- 大阪に行く目的は何か？
- 予算はどれくらいかけられるのか？
- いつまでに到着する必要があるのか？
まずは これらの問いを立ててヒアリングを行い、課題を明確にしていく必要があります。
例えば大阪に行きたい目的が「焼き立ての美味しいたこ焼きを食べたい」だけなら、東京に存在する本場有名店の情報を紹介することや、たこ焼きパーティーを開くことが解決策になるかもしれません。もし「大量のデータが入ったHDDを大阪の拠点に運ぶ」のであれば、そこで初めて移動方法を考えるべきです。
もしかしたらある程度の調べは付いていて、「子連れ旅行のため、新幹線か自家用車か迷っている」ということかもしれません。本当に知りたいのが迷いを断ち切るための情報だとしたら、詳しい話を聞かずに「飛行機が早くて楽だよ」と助言するのは軽率でしょう。
IT業界で生き残るための課題解決能力
このように課題は要望に隠れていて、その解決方法も状況により様々です。相談しながら慎重に進めなければ、見当違いの対応をしてしまいます。
学校では「東京から大阪へ新幹線で行く」と決まっている前提で、その具体的な手順を調べる訓練をします。 しかし一旦社会に出てしまえば課題自体が曖昧なケースばかりです。特にITエンジニアは誰かの要望をシステムとして実現する仕事です。このため「そもそも何が求められているのか」を意識的に考えなければなりません。
それでもITエンジニアになりたての頃は「新幹線のチケットを取る」「たこ焼きを焼く」といった具体的な作業をすることになります。ある程度の開発経験を経て、上流工程つまり要件定義・要求定義・基本設計などに携わるようになります。
先述のような課題解決能力がなければ、上流工程を任せることができません。つまり作業者としての道しか残らなくなります。しかしGitHub CopilotやCursorなどのAI利用技術の発達により、単なる作業者としてのITエンジニアの将来性は失われつつあります。
また仮に上流工程に携われたとしても、課題を取り間違えることは炎上と疲弊に繋がります。予算オーバーや納期の遅れ、顧客からのクレーム対応に追われる可能性が高く、多くの作業がやり直しになれば現場から悲鳴が上がるでしょう。
さて、貴方は「正解のない課題を解決できる」ようになる自信がありますか？
おわりに
最後にお尋ねします。
あなたは自分に、ITエンジニアの適正があると思いますか？
今の仕事を辞めてまで、ITエンジニアに転職したいと思いますか？
ステュクスの河の畔で、お待ちしております。
Discussion