付録2
想定学習時間: 7分
プログラミング学習では、パソコンに直接指示を出すための画面や、そこで使う命令文について理解することが重要です。ここでは、開発作業で頻繁に登場する基本的な用語を解説します。
ターミナルは、パソコンに文字で命令を直接入力し、実行させるための画面です。ファイル操作、アプリケーションの起動、Gitを使ったバージョン管理など、様々な作業をここで行います。最初は少し難しく感じるかもしれませんが、Codexに操作の意味を尋ねながら、少しずつ慣れていくことができます。
コマンドは、ターミナルで実行する命令文のことです。例えば、ファイルのリストを確認したり、特定のアプリケーションを起動したり、Gitで現在のプロジェクトの状態を確認したりといった作業を指示できます。ただし、ファイルやデータを削除したり上書きしたりするコマンドは、取り扱いに十分な注意が必要です。意味が不明なコマンドは、実行する前に必ずCodexで確認するようにしましょう。
開発を進める上で、問題が発生することは避けられません。ここでは、問題に直面した際の対処法や、品質を確保するための用語を学びます。
エラーとは、プログラムが期待通りに動作しなかったときに表示される問題やメッセージのことです。初心者のうちは失敗だと感じやすいかもしれませんが、エラーは問題の原因を特定するための重要な手がかりとなります。Codexにエラーについて尋ねる際は、エラーメッセージを省略せず、そのまま正確に伝えることが基本です。
エラーメッセージは、何が問題になっているかを具体的に知らせる文章です。多くの場合、英語で表示されますが、慌てる必要はありません。Codexに「このエラーメッセージを初心者向けに説明してください」と依頼すれば、その意味を分かりやすく解説してもらえます。
バグとは、プログラムの不具合全般を指します。例えば、「画面が表示されない」「データが保存されない」「計算結果が間違っている」「ボタンを押しても反応しない」「削除したくないデータまで消えてしまう」といった現象は、すべてバグの一種です。
デバッグは、バグやエラーの原因を特定し、修正する作業です。この作業では、「どこで処理が止まっているのか」「何が期待される動作と異なるのか」「どのファイルが関係しているのか」「直前にどのような変更を加えたのか」といった情報を整理しながら進めます。
テストは、作成したプログラムが正しく動作するかを確認する作業です。具体的には、「正常な入力で動作するか」「入力が空欄の場合でも壊れないか」「想定外の入力に対してどう反応するか」「件数や合計金額は正しいか」「データの保存や削除が期待通りに行われるか」といった点を検証します。
テストデータは、プログラムの動作確認のために用意する架空のデータです。実際の顧客情報や売上情報ではなく、サンプルとして作成されたデータを使用します。AIやCodexにプログラムの動作をテストさせる場合、まずテストデータを用いるのが安全な方法です。
サンプルデータは、動作確認や機能の説明のために使う例のデータです。例えば、「山田太郎」「test@example.com」「テスト商品」「サンプル会社」といった、実在しない情報で構成されます。本物の個人情報や機密情報を避けるために非常に重要です。
安全なシステム開発には、情報の取り扱い方やチームでの作業方法に関する理解が不可欠です。
個人情報とは、個人を特定できる情報のことです。氏名、住所、電話番号、メールアドレス、契約情報などがこれに含まれます。AIやCodexに情報を渡す際は、本物の個人情報を扱わないよう細心の注意を払う必要があります。
機密情報とは、外部に漏洩させてはならない重要な情報のことです。社内資料、顧客リスト、売上情報、契約内容、APIキー、パスワード、未公開の事業情報などが該当します。GitHubなどの公開リポジトリやAIへの入力に、機密情報を含めないよう厳重に注意しましょう。
認証は、システムを利用している人が本当に本人であるかを確認する仕組みです。ログインIDとパスワードによる認証、メール認証、二段階認証など、様々な方法があります。本格的なWebアプリケーションで利用者ごとにデータを区別する場合、認証機能が必要となることが一般的です。
権限管理とは、誰がどの情報を見られるか、何を編集できるかといったアクセス権限を管理することです。例えば、「管理者だけがデータを削除できる」「担当者は自分の案件だけ閲覧できる」「一般利用者は閲覧のみ可能」といったルールを設定します。
バックアップは、データやファイルの予備を保存しておくことです。プログラムの修正前にフォルダをコピーしたり、Gitで変更をコミットしたり、重要なファイルを別の場所に保存したりすることで、万が一の失敗時にも元の状態に戻しやすくなります。
リファクタリングとは、プログラムの外部的な動作を変えずに、内部のコードをより読みやすく、整理された状態に改善する作業です。具体的には、重複するコードを減らす、変数名や関数名を分かりやすくする、処理を小さな単位に分割する、不要なコードを削除するといった活動が含まれます。初心者の場合、整理しすぎるとかえってコードが複雑になることもあるため、Codexに「初心者が読みやすい範囲でリファクタリングしてください」と指示すると良いでしょう。
レビューは、作成したコードや設計が適切であるかを確認する作業です。このプロセスでは、「問題がないか」「目的に合致しているか」「危険な情報が含まれていないか」「既存の機能を壊していないか」「より良い実装方法はないか」といった点を多角的に検証します。
プルリクエスト（略してPR）は、GitHubなどのバージョン管理システムにおいて、自分の変更内容をプロジェクトの本体（メインブランチなど）に取り込む前に、他の開発者に確認（レビュー）してもらうための仕組みです。チームでの開発では、変更を直接本体に反映させるのではなく、レビューを経てから取り込むのが一般的です。初心者が一人で学習する段階では、「変更を安全に確認してから取り込むための仕組み」と理解しておけば十分です。
人にたとえると
新しい製品開発を進める会社での一幕を想像してみましょう。
開発の「司令室」では、担当者が「指示書」を出し、作業を進めます。もし製品に「不具合」が見つかれば、その原因を調査し、改善します。完成した製品は「品質検査部門」に送られ、動作が正しく行われるか確認されます。最終的に、変更内容は「上司に提出して承認を求める書類」で正式に承認されます。