IT基礎研修 — 未経験・文系向け ITエンジニア入門講座

はじめに

未経験や文系の方がエンジニアを目指す場合、ITの基礎知識としては「基本情報技術者試験」の内容を理解できていれば十分だと考えています。ただし、教科書の内容だけだと、実際の業務イメージがつかみにくいのが難点です。

現場でエンジニアとして働きながら資格の勉強をする場合は、日々の業務と資格の知識が結びつくので理解しやすいですが、エンジニアになる前に勉強を始めると、なかなか業務をイメージしづらいかもしれません。

そこで本記事では、より実務をイメージしやすいように、一部の内容を解説していきます。
※基本情報技術者試験に合格していると、就職や転職活動でも有利になります。

また、「基本情報技術者試験」などの過去問を繰り返し練習できる無料Webサービスもありますので、ぜひ活用してみてください。

過去問道場はこちら

この記事を読んだときのゴール

• 基本情報技術者試験では理解しにくいエンジニアの現場のイメージ理解
• 前もってエンジニアを知ることにより入社後のギャップを減らせる
• 入社後にタメになる知識を身につける

開発手法

それでは、ITの基礎について学んでいきましょう。
システム開発には、主に以下のような「開発手法」があります。

• ウォーターフォール型開発（Waterfall Model）
• アジャイル開発（Agile Development）
• プロトタイピングモデル
• スパイラルモデル
• DevOps（デブオプス）

• ウォーターフォール型開発（Waterfall Model）
  要件定義 → 設計 → 実装 → テスト → 運用の順に段階的に進める従来型開発手法
  • メリット: 進捗管理がしやすく、各工程の成果物が明確、大規模開発で使われやすい。
  • デメリット: 途中仕様変更に弱く、後戻りが困難

• アジャイル開発（Agile Development）
  要件定義や設計、実装、テストを短い期間（イテレーション）で繰り返し、段階的にシステムを完成させていく手法。小さく作って少しずつ改善していく。
  • メリット: 途中仕様変更に強く、早期に動くシステムを確認でき、顧客満足度が高い
  • デメリット: 進捗管理が難しく、ドキュメントが少なくなりやすい。
  • 実践手法(フレームワーク)：スクラム、カンバン、エクストリームプログラミング（XP）等

• プロトタイピングモデル
  開発の早い段階で試作品（プロトタイプ）を先に作り、フィードバックを得ながらを明確化していく。依頼者の要望が不明確な時に適している。
  • メリット：早期にフィードバックをもらえるため、要件の認識違いを減らせる
  • デメリット：試作品作りに手間やコストがかかることがある。

• スパイラルモデル
  ウォーターフォールの計画性とアジャイルやプロトタイピングの反復性を組み合わせている。リスク管理をしながら反復的に開発
  • メリット: リスク管理に優れている
  • デメリット：プロセスが複雑で管理コストが高く、小規模開発に不向き。

• DevOps（デブオプス）
  開発（Development）と運用（Operations）の密に連携し、継続的な価値提供を実現
  • ポイント: 開発手法というより「文化・仕組み」の側面が強い
  • メリット: リリース速度が速く、品質が安定する。顧客への価値提供が早い。
  • デメリット：組織や文化の変革が求められる。

上流工程/下流工程

• 上流工程（じょうりゅうこうてい）
• 下流工程（かりゅうこうてい）
• その他、開発工程(上流工程/下流工程)以外

ITエンジニアの仕事には、川の流れのように「上流」から「下流」へと進んでいき、さまざまな工程があります。
入社後に「想像と違った」というミスマッチを防ぐためにも、開発の流れと各工程の内容を知っておくことが大切です。

上流工程（じょうりゅうこうてい）

上流工程とは、システム開発の工程の中で、計画や設計に関わる初期段階の作業を指します。

主な作業内容

1. 要件定義：
   クライアントやユーザーの要求を聞き取り、システムに必要な機能や性能を明確にする作業
   ・成果物：要件定義書（やりたいことリスト）
   
   例：
   カフェのオーナーとの会話
   オーナー：スマホで事前注文できるアプリが欲しい
   開発者：どんな機能が必要ですか？
   オーナー：メニュー表示、注文、決済、受取時間指定ができればいいな
   
2. 基本設計（外部設計）
   要件定義をもとに、システム全体の構造や操作画面の設計など、大まかな仕様を決める
   ・成果物：画面設計書、画面遷移図
   
   例：
   アプリの画面をざっくり絵にしてみる
   トップ画面：ロゴ＋「注文する」ボタン
   メニュー画面：コーヒー一覧（写真付き）
   注文画面：個数選択＋受取時間選択
   
3. 詳細設計
   基本設計をさらに細かく分けて、各プログラム単位でどのように作るか具体的に設計する
   ・成果物：処理フロー図、データベース設計書
   
   例：
   注文ボタンを押したときの以下処理を設計
   1. 注文ボタンが押される
   2. 選択された商品と個数を確認
   3. 在庫をチェック
   4. 合計金額を計算
   5. 注文確認画面へ遷移

上流工程はシステムの要求や仕様を決める重要なフェーズで、ここでの決定が後の開発の品質や進行に大きく影響します。

下流工程（かりゅうこうてい）

下流工程は、上流工程で決められた設計をもとに、実際にプログラムを作成し、動作確認や納品まで行う工程です。

主な作業内容

1. プログラミング（実装）
   設計書をもとにコードを書く作業
   ・成果物：プログラムコード
   
   例：
   注文ボタンの処理をコードで書く
   
2. 単体テスト
   個々のプログラムが正しく動くか確認するテスト
   ・成果物：単体テスト仕様書、テスト結果
   
   例：
   合計金額計算のテスト
   テスト1：コーヒー（300円）× 2個 = 600円 ✓
   テスト2：ケーキ（500円）× 0個 = 0円 ✓
   テスト3：マイナス個数 → エラー表示 ✓
   
3. 結合テスト
   複数のプログラムを組み合わせた動作確認
   ・成果物：結合テスト仕様書、テスト結果
   
   例：
   注文から決済までの流れをテスト
   ・メニュー選択 → 注文画面へ遷移OK？
   ・注文確定 → 決済画面へ遷移OK？
   ・決済完了 → 注文データが保存されているか？
   
4. 総合テスト・受け入れテスト
   システム全体としての動作確認とユーザー検証
   ・成果物：受け入れテスト結果、最終確認書
   
   例：
   カフェスタッフが実際に使ってみる
   ・朝の混雑時間帯でも注文できるか？
   ・100人が同時注文してもOKか？
   ・オーナーの要望通りに動いているか？

その他、開発工程(上流工程/下流工程)以外

開発工程(上流工程/下流工程)後に作られたシステムを運用・保守することがあります。

主な作業内容

1. 運用・保守：システム稼働後の管理やトラブル対応、機能改善など

請負構造

• 請負契約（うけおいけいやく）とは
• 多重下請け構造

請負契約（うけおいけいやく）とは

「請負契約」とは、簡単に言うと「ある仕事を●●円でおまかせします！」という契約のことです。
例えば、「システムを３ヶ月で作ってくれたら100万円払います」というようなイメージです。
この契約のもと、エンジニアや開発チームは納品物（システムやソフトウェア）をきちんと完成させたら報酬がもらえます。

※「準委任契約」は”請負契約が成果物の完成で報酬をもらえる”のに対して、一定の業務遂行(作業時間や実績ベース)で報酬をもらえます。

多重下請け構造

IT業界では、請負契約が複数の会社にまたがって段階的につながっていることが多く、これを「多重下請け構造」と呼びます。

「家」を建てるで例えると、

1. 依頼人（施主）:
   「眺めの良い、3階建てのモダンな家を建てたい！」と依頼する。
2. ハウスメーカー（元請け）:
   依頼を聞き、「分かりました！最高の家を建てましょう！」と全体の責任者になる。設計図を描き、大工さんや専門業者を手配し、プロジェクト全体を管理します。
3. 工務店（一次下請け）:
   ハウスメーカーから「この設計図通りに、家の土台と骨組みを作ってください」と、具体的な作業を依頼される。
4. 専門業者（二次下請け）:
   工務店から「うちは電気工事のプロなので配線をお願いします」「うちは内装のプロなので壁紙を貼ってください」と、さらに専門的な仕事を依頼される。

依頼人の「家を建てたい」という一つの大きな仕事が、ハウスメーカー → 工務店 → 専門業者というように、どんどん具体的で専門的な仕事に分かれています。

IT業界のシステム開発もこれと同じような構造です。

このように、仕事が上から下へ流れていく構造を、業界では**「商流（しょうりゅう）」と呼びます。そして、この流れが何層にも重なっている状態が「多重下請け構造」の正体です。

上記は一例であり、三次請け、四次請け〜と続くこともあります。もちろん大きくないプロジェクトでは一次請けで全てを完結し「多重下請け構造」にならないこともあります。

アルゴリズム

• 身近なアルゴリズム
• アルゴリズムの例(自動販売機でジュースを買う)
• 基本的なアルゴリズムの考え方
• なぜエンジニアはアルゴリズムを学ぶの？3つのメリット

アルゴリズムとは、問題を解くための手順や計算の流れのことです。

身近なアルゴリズム

• 日常生活のアルゴリズム
  • 料理のレシピ
  • 道順の案内
  • 自販機で飲み物を購入
• ITサービスのアルゴリズム
  • Google検索の仕組み
  • SNSのタイムライン表示
  • ECサイトのおすすめ商品

アルゴリズムの例(自動販売機でジュースを買う)

以下は、自動販売機で飲み物を購入する手順をアルゴリズムとして表したものです。

1. 買いたい飲み物を選ぶ
   自動販売機のディスプレイを見て、購入したい飲み物を決める
2. 必要な金額を確認する
   選んだ飲み物の価格を確認する
3. お金を用意する
   財布から必要な金額分の硬貨や紙幣を取り出す
4. お金を投入する
   用意したお金を自動販売機の投入口に入れる
5. 商品のボタンを押す
   買いたい飲み物のボタンを押して購入を確定する
6. 商品を受け取る
   取り出し口から飲み物を取り出す
7. おつりを受け取る
   おつりがある場合は、返却口から受け取る

このように、日常的な行動も順序立てて整理すると、立派なアルゴリズムになります。

基本的なアルゴリズムの考え方

• 順次処理
  上から順番に実行する処理です。
  
  • 例：
    上記「アルゴリズムの例(自動販売機でジュースを買う)」で1~7番まで上から順番に実行します。

• 条件分岐（if文）
  「もし〜なら」という条件によって処理を分ける考え方です。
  
  • 例：
    上記「アルゴリズムの例(自動販売機でジュースを買う)」の「3.お金を用意する」際、
    もし必要な金額が硬貨だけで足りるなら、硬貨だけを取り出す。
    もし硬貨だけでは足りないなら、紙幣も取り出す。

• 繰り返し（for文）
  同じ作業を条件が満たされるまで繰り返す処理です。
  
  • 例：
    上記「アルゴリズムの例(自動販売機でジュースを買う)」の「4.お金を投入する」際、
    130円の飲み物を買うために、硬貨を繰り返し投入します。
    繰り返し開始 → 100円投入 → 10円投入 → 10円投入 → 10円投入 → 繰り返し終了

なぜエンジニアはアルゴリズムを学ぶの？3つのメリット

アルゴリズムを学ぶ具体的なメリットを、エンジニアの仕事に結びつけて解説します。

• メリット1：効率の良いプログラムが書けるようになる
  同じゴールでも、手順が違うと速さや使うエネルギー（PCのメモリ）が変わります。
  
  • 例：
    自動販売機で買いたい飲み物を買う際、「2. 必要な金額を確認する」と「3.お金を用意する」の順番を逆にすると、処理の効率が悪くなります。
    1. 必要になりそうな硬貨をとりあえず10枚財布から取り出す
    2. 必要な金額を確認する
    3. お金を投入する
    4. 使わなかった硬貨を4枚を財布に戻す
    
    適切な手順（アルゴリズム）を知っていると、無駄がなくなり効率的なプログラムが作れるようになります。

• メリット2：問題解決能力がアップする
  複雑な問題に直面したとき、どういう手順で解決すればいいかを考える「思考の型」が身につきます。
  
  • 例：
    自動販売機が故障して飲み物が出てこない時の対処法として、
    1. まず落ち着いて状況を確認する
    2. もう一度ボタンを押してみる。
    3. 返金レバーを押してみる
    4. それでもダメなら管理会社の連絡先を探す
    5. 連絡先に電話をかける
    このように、問題を小さなステップに分解して順番に解決していく力が身につきます。

• メリット3：他の人が書いたコードを理解しやすくなる
  世の中には「定番の型（有名なアルゴリズム）」があり、それを知っていると他の人の意図が汲み取りやすくなります。
  
  • 例：
    どの自動販売機でも基本的な使い方は同じです。
    お金を入れる → ボタンを押す → 商品が出る
    この「定番の流れ」を知っていれば、はじめて使う自動販売機でも迷わず使えるように、プログラミングでも定番パターンを知っていれば他の人のコードを素早く理解できます。

見積もりの基礎知識

• 人月とは
• 見積もり計算は難しい
• 見積もり計算・工数管理は大切c
• 開発にかかる時間と費用の関係

人月とは

IT業界では、システムを開発するときの「作業量の目安」として**人月（にんげつ）**という単位がよく使われます。
これは「1人のエンジニアが1ヶ月間働いた場合に終わる仕事の量」を1人月と呼びます。例えば「3人月」と言われたら、以下のような意味になります。

• 例1: 1人だと3ヶ月かかる作業 = 3人月
• 例2: 3人だと1ヶ月で終わる作業 = これも3人月
• 例3: 6人だと2週間で終わる作業 = 6人 × 0.5ヶ月 = 3人月

見積もり計算は難しい

1. 人を増やしても単純に早くならない
   例として料理で考えてみましょう。
   ハンバーグを1人で1時間かけて作るとしても、10人いれば6分で作れるわけではありません。
   
   ・キッチンやフライパンなどの設備に制限がある
   ・作業手順の順番を変えられない
   
   こうした制約があるため、人数を増やしても時間が比例的に短くなるとは限りません
   
2. 初めての仕事は所要時間が予測しにくい
   初めて作る料理レシピと、何度も作ったことがあるレシピでは調理時間が異なりますよね。
   システム開発も同じで、似たような開発でも細かな違いによって必要な時間が大きく変わります。

見積もり計算・工数管理は大切

IT開発では、作業開始時にすべてが確定していることは少なく、
途中で要求変更や予想外のトラブルが発生しやすいです。

そのため、見積もりを甘くしたり安易に値引きすると、
本当は必要な工数（作業時間・人数など）や費用・納期が足りなくなり、
納期遅延や品質の低下、エンジニアの過剰な負担（いわゆる“デスマーチ”）につながってしまいます。

開発にかかる時間と費用の関係

1ヶ月に1人が1日8時間20日間働くと、合計160時間となり、これを1人月と換算します。
もしシステム開発の見積もりで「この仕事は1人月でできます」とした場合、
実際には2人月かかると、1人の1ヶ月分の作業時間・給与分が赤字となります。

こうした赤字リスクがあるため、見積もりは慎重かつ現実的に行う必要があります。

プロジェクトステークホルダー

• ステークホルダーとは
• ITプロジェクトの主要ステークホルダー
• ステークホルダーが重要な理由

ステークホルダーとは

ステークホルダー（Stakeholder） とは、直訳すると「利害関係者」のことです。
簡単に言うと「そのプロジェクトが成功したらハッピーになったり、逆に失敗したらガッカリしたり、何かしらの影響を受ける人たち全員」のことです。

ITプロジェクトの主要ステークホルダー

内部ステークホルダー

• プロジェクトマネージャー（PM）
  プロジェクト全体の責任者

• 開発チームメンバー
  実際にシステムを作る人たち

• テスター・QAエンジニア
  システムの品質保証を担当

外部ステークホルダー

• クライアント（発注者）
  システムを発注する企業・組織

• エンドユーザー
  実際にシステムを使う人たち

• 経営陣・意思決定者
  予算承認や重要な判断を行う

• ベンダー・協力会社
  外部委託先やパートナー企業

ステークホルダーが重要な理由

• プロジェクトの成否を左右する
  多くのプロジェクト失敗は技術的課題よりも、期待値の不一致や合意形成不足など「コミュニケーション／ステークホルダー起因」で発生します。
  早期に「誰が何を成功とみなすか」を明確化することで、判断軸が共有され、ブレを防げます。

• 品質向上と満足度アップ
  利用者、運用部門、法務・セキュリティなど、各ステークホルダーの知見を適切に反映することで、使われる品質（有用性・安全性・保守性）が高まります。
  また、誰の満足がKPI（売上・利用率・品質・コンプラ）に直結するかが定まり、意思決定が一貫します。

• 変更リスク・手戻りの抑制
  影響力と関心を可視化して優先順位を付け、関係者を適切なタイミングで巻き込むことで、後出し要件や仕様巻き戻しを減らせます。

• 意思決定の迅速化
  決裁者・相談先・周知対象が明確になり、承認停滞や「誰が決めるのか不明」を解消できます

筆者のひとりごと

• 一次請け企業で得られた多様な経験

一次請け企業で得られた多様な経験

私は新卒でソフトウェア系のエンジニアとして、受託開発現場で働き始めました。学生時代は文系で、IT知識もほとんどない状態からのスタートでした。就職活動中、「ITエンジニアの世界には下請けという仕組みがある」と知り、その中でも特に“三次請け”以降の会社には入らないように意識していました。「上流工程」に関われる可能性が高い企業を選びたく、特に三次請け以降の企業は、どうしても業務範囲が限定的になりやすいと考えたからです。しかし、実際の就職活動では、会社側が「うちは三次請けです」と教えてくれないことがあります。もし「上流工程」も経験したいという希望があれば、面接時や説明会などで、「案件はどのように受注していますか？（顧客直請けか、二次請けかなど）」や率直に「御社は何次請けですか？」といった質問をしてみるのも有効だと思います。

私は幸いにも顧客とやり取りできる一次請けの会社に入社でき、幅広い業務を経験することができました。（※誤解のないように補足すると、何次請けかが企業の良し悪しを決めるわけではありません。最も大切なのは「自分がやりたい仕事ができる環境か」です。私の場合は、まず多様な経験を積みたいという思いが強かったが、エンジニアの知識がないため、幅広い経験ができる可能性の高い一次請けの会社を選択をしました。）

次のステップ

IT基礎研修はいかがでしたでしょうか？

次はSQLを学んでステップアップしましょう！
データベースを操作できるようになると、ITエンジニアとしての実践力が大きく向上します。

SQL研修で学べること

• 30秒で完了する環境準備
• SQL基礎概念の理解
• 実際にデータを操作する体験

入社前に即戦力レベルの基礎スキルを身につけて、一緒に頑張りましょう！

「【SQL研修#1】完全初心者向けSQL入門｜基礎概念から環境構築まで解説」の記事はこちら▼

【SQL研修#1】完全初心者向けSQL入門｜基礎概念から環境構築まで解説

SQL初心者必見！データベースの基礎概念から実践環境まで完全解説。インストール不要で今すぐSQL学習を開始。テーブル・行・列、データ型などを分かりやすく図解付きで学べます。無料で手を動かしながら確実にスキルアップ！

humdev.jp

2025.09.10