非エンジニアがエンジニアとの会議で困らないために覚えたいIT用語

エンジニアとの会議では、すべての技術用語を知っている必要はありません。大切なのは、話題が「何を作るか」「どう作るか」「いつ安全に出すか」のどこに属するかを見分け、曖昧な点をその場で確認することです。頻出語を会議の流れに沿って整理します。

要件と仕様を区別する

要件は、利用者や事業が実現したいことです。仕様は、その要件を満たすためにシステムが備える具体的な動作や条件です。「購入済みの利用者だけが有料用語を見られる」は要件、「購入情報を起動時に確認し、未確認なら鍵を表示する」は仕様に当たります。

会議では「それは要件ですか、それとも実装方法の案ですか」と確認すると、目的と手段の混同を防げます。

フロントエンドは利用者が操作する画面側、バックエンドはデータ処理や権限確認を行うサーバー側です。APIは両者が決められた形式で情報をやり取りする窓口です。

不具合の相談では「画面で入力できない」「APIの応答がエラー」「サーバーの保存に失敗」のように、どの層で問題が起きているかを分けて伝えると調査が速くなります。

データベースは情報を整理して保存する仕組みです。表に相当する単位がテーブル、一件分のデータがレコードです。会議で「データを追加する」と聞いたら、保存先、必須項目、重複の扱い、削除方法、閲覧権限まで確認します。

個人情報や購入情報を扱う場合は、保存できるかだけでなく、誰が読めるか、いつまで保持するかも要件です。

開発環境は実装作業用、検証環境は公開前の確認用、本番環境は実際の利用者向けです。検証環境で成功しても、本番の権限、URL、データ、外部サービス設定が異なれば動かないことがあります。

「どの環境の話か」「同じ条件を再現できるか」を必ず確認します。スクリーンショットやログには、環境と発生時刻も添えましょう。

デプロイはプログラムを実行環境へ配置すること、リリースは利用者が新機能を使える状態にすることです。ロールバックは問題発生時に以前の安定版へ戻す対応です。配置と公開を分ける運用もあるため、「デプロイ完了」がそのまま「利用者に公開済み」とは限りません。

公開前には、対象バージョン、公開時刻、確認担当、異常時の戻し方を合意します。

バグはプログラムの誤り、障害はサービスを正常に利用できない状態を指します。調査依頼では、期待した結果、実際の結果、操作手順、端末やバージョン、発生時刻、再現頻度を伝えます。「動きません」だけでは原因候補を絞れません。

理解できない語が出たら、知ったふりをせず、次のように確認します。

用語の暗記よりも、目的、対象範囲、完了条件を自分の言葉で言い換えることが重要です。会議の最後に決定事項、担当者、期限、未決事項を読み上げれば、技術知識の差による認識ずれを大幅に減らせます。