用語集

「何を作るか」をお客様と決める工程。機能一覧や業務フローを作成する

直接参加は少ないが、決まった内容を読んで理解する機会がある

画面や機能の「見た目・動き」を決める工程。外部設計とも呼ぶ

画面設計書を見ながら実装することが多い

プログラムの「中身の処理」を決める工程。内部設計とも呼ぶ

詳細設計書を読んで実装するのが1年目の主な仕事

設計書をもとにプログラムを書く工程。コーディングとも呼ぶ

1年目のメイン業務

作った機能を1つずつテストする工程

自分が書いたコードのテストを担当する

複数の機能を組み合わせてテストする工程

テスト実施や不具合修正で関わる

システム全体が要件通りに動くかテストする工程

見学程度のことが多い

完成したシステムを本番環境に導入すること。デプロイとも呼ぶ

手順書に沿って作業する、または見学する

リリース後のシステムを維持・改善する作業

不具合対応や小さな改修で関わることがある

要件定義→設計→実装→テストと順番に進める開発手法。大規模・堅い案件で多い

SIer・受託開発で採用されることが多い

短い期間で「作る→確認→改善」を繰り返す開発手法

Web系・スタートアップで採用されることが多い

アジャイルの代表的な手法。役割・イベント・成果物が決まっている

スプリント、デイリースクラムなどの用語とセットで覚える

1〜4週間の開発サイクル。「今スプリント」「次スプリント」のように使う

「このスプリントで何をやるか」を意識して動く

毎日15分程度の短いミーティング。朝会とも呼ぶ

「昨日やったこと」「今日やること」「困っていること」を報告

やるべきタスクの一覧。優先順位がついている

「バックログから次のタスクを取る」という形で仕事を進める

スプリント終了時に成果物を確認する会

自分の成果をデモする機会になることも

スプリント終了時の振り返り会。「KPT」形式で行うことが多い

チームの改善に意見を出す機会

タスクや課題を管理する単位。Jira、Redmine、Backlogなどで管理

「このチケットお願い」と言われたら、そのタスクを担当する

チケットの状態（未着手→作業中→レビュー中→完了など）

作業の進捗に合わせてステータスを更新する

プロジェクトの重要な節目・目標日

「〇〇マイルストーンまでに完了」という期限を意識する

作業を細かく分解した一覧表

自分の担当タスクがWBSのどこに該当するか確認する

タスクのスケジュールを横棒グラフで表したもの

全体のスケジュール感を把握するのに使う

データを入れておく「箱」のようなもの

userName = "田中" の userName が変数

処理をまとめたもの。引数を受け取り、結果を返す

calculateTotal(price, quantity) のような形

関数に渡す値

上の例では price と quantity が引数

関数が返す結果

return total で返される値

データと処理をまとめた「設計図」

User クラスから user1 インスタンスを作る

クラスから作成した実体（オブジェクト）

new User() で作られたもの

複数のデータをまとめて扱うもの

[1, 2, 3] や ["りんご", "みかん"]

処理を繰り返すこと

for文、while文など

条件によって処理を分けること

if-else文、switch文など

プログラム実行中に発生するエラー

エラーログで「Exception」と出たら要注意

エラーが発生するまでの処理の流れを示したもの

どこでエラーが起きたかを特定するのに使う

「値がない」ことを表す

NullPointerExceptionは最もよくあるエラーの1つ

文法の間違いによるエラー

カッコの閉じ忘れ、セミコロン忘れなど

動かしてみて初めて発生するエラー

0での割り算、存在しないファイルへのアクセスなど

コードを保存・管理する場所

「リポジトリをクローンして」→ コードをダウンロードする

リポジトリをローカルにコピーすること

新しい案件に入ったら最初にやる作業

変更を記録すること

「意味のある単位でコミットする」が基本

ローカルの変更をリモートに送ること

コミットしただけでは共有されない。プッシュが必要

リモートの変更をローカルに取り込むこと

作業前に「プルして最新化」が習慣

作業を分岐させること

「featureブランチを切って作業する」

ブランチを統合すること

作業が終わったらmainブランチにマージする

同じ箇所を別々に変更して衝突すること

解消方法を覚えておく必要がある

マージを依頼すること。レビューを受ける単位

「PR出しました」→ レビューお願いします

他の人にコードを確認してもらうこと

PRを出したらレビューを待つ

データを格納する「表」

Excelの表をイメージすると分かりやすい

テーブルの1件のデータ

ユーザーテーブルの「1人分のデータ」

テーブルの項目

「名前」「メールアドレス」などの項目

レコードを一意に識別する列

ユーザーIDなど。重複しない値

他のテーブルを参照する列

注文テーブルの「ユーザーID」など

データベースを操作する言語

SELECT、INSERT、UPDATE、DELETEが基本

データベースへの問い合わせ

「クエリを投げる」= SQLを実行する

データを取得するSQL

最もよく使う。まずこれを覚える

データを追加するSQL

新規登録処理で使う

データを更新するSQL

編集処理で使う。WHERE句を忘れると大事故

データを削除するSQL

WHERE句を忘れると全件削除。要注意

複数の操作をまとめて扱う仕組み

「全部成功」か「全部失敗」かを保証する

プログラム同士がデータをやり取りする仕組み

「このAPIを呼び出してデータを取得する」

APIの設計スタイルの1つ。HTTPメソッドを使う

GET、POST、PUT、DELETEでCRUD操作

APIのアクセス先URL

/api/users/123 のような形式

APIへの要求

「こういうデータをください」という依頼

APIからの応答

要求に対する返答データ

データ交換フォーマット

{"name": "田中"} のような形式。APIのやり取りはほぼJSON

リクエストの種類（GET/POST/PUT/DELETE）

GET=取得、POST=作成、PUT=更新、DELETE=削除

APIの結果を示す3桁の数字

200=成功、400=リクエスト不正、404=見つからない、500=サーバーエラー

リクエスト/レスポンスの付加情報

認証トークンやContent-Typeなど

「何を」「どうやって」「どうなればOKか」を記載したもの

テストケースに沿ってテストを実施する

テストケースをまとめた文書

これを見ながらテストを進める

想定通りの入力でのテスト

「普通に使ったら動くか」を確認

想定外の入力でのテスト

「おかしな入力をしたらどうなるか」を確認

範囲の境界でのテスト

「0〜100」なら、-1、0、1、99、100、101をテスト

修正後に他の機能に影響がないか確認するテスト

「直したら別のところが壊れた」を防ぐ

関数やメソッド単位のテスト。コードで書くことが多い

自分のコードにテストを書く

複数の機能を組み合わせたテスト

画面から操作して確認することが多い

自分のPCの環境

自由に実験できる。壊しても影響なし

開発チームが共有する環境

他の人も使っているので、壊すと迷惑をかける

本番に近い確認用環境

本番リリース前の最終確認に使う

実際にユーザーが使う環境

絶対に慎重に。ミスは許されない

統合開発環境。Visual Studio、IntelliJなど

エディタ+デバッガ+ビルドツールがセット

ソースコードを実行可能な形に変換すること

「ビルドエラー」が出たら動かない

アプリを環境に配置すること

「開発環境にデプロイする」など

「あなたは誰か」を確認すること

ログインで「本人確認」をする

「何ができるか」を制御すること

ログイン後に「この機能を使える権限があるか」を判断

ログイン後の状態を維持する仕組み

ログアウトするとセッションが切れる

認証情報を表す文字列

APIアクセス時にヘッダーに付けて送る

Webページに悪意のあるスクリプトを埋め込む攻撃

ユーザー入力を画面に表示する際に注意

SQL文を不正に操作する攻撃

ユーザー入力をSQLに埋め込む際に注意

ユーザーになりすまして操作を行う攻撃

フォーム送信時にトークンで防ぐ

サービスを提供するコンピュータ

「サーバーにSSHで接続する」など

インターネット経由で利用するコンピュータ資源

AWS、Azure、GCPなどが代表的

自社で管理するサーバー環境

クラウドの対義語として使う

アプリと依存関係をまとめた実行環境

Dockerで作る。「コンテナを起動する」

サーバーに安全に接続するプロトコル

ターミナルからサーバーに入るときに使う

コード変更時に自動でビルド・テストする仕組み

PRを出すと自動でテストが走る

自動でリリース可能な状態にする仕組み

mainブランチにマージすると自動デプロイ

ビルド→テスト→デプロイの自動化フロー

「パイプラインが失敗した」= ビルドかテストがエラー

システムの動作記録

エラー調査のとき最初に見る

システムの稼働状況を監視すること

異常があればアラートが飛ぶ

異常を検知して通知すること

「アラートが鳴った」= 何か問題が起きた

システムに問題が発生したときの対応

1年目は先輩のサポート役から始める

プログラムの不具合

「バグを見つけた」「バグを直す」

バグを見つけて修正すること

開発者の重要なスキル

動作を変えずにコードを改善すること

読みやすく、保守しやすくする

他者にコードや成果物を確認してもらうこと

PRレビュー、設計レビューなど

将来の開発効率を下げるコードや設計

「負債を返す」= リファクタリングする

技術検証。実現可能性の確認

「まずPoCをやってみよう」

新メンバーがチームに慣れる過程

「オンボーディング資料」など