プロジェクト初参画で戸惑った！現場で飛び交うITビジネス用語・言い回し集
はじめに
IT業界には、専門用語が数え切れないほど存在します。
特にチーム開発の現場では、日常生活ではまず耳にしない言葉が頻繁に使われています。
私自身、某大手SIerのプロジェクトに初めて参画したとき、現場で初めて聞いて戸惑った用語や言い回しがいくつもありました。同じような経験をされた方も多くいらっしゃると思います。
今回は、そんな「プロジェクト初参画時に私が知らずに困ったIT系ビジネス用語・言い回し」について、体験を交えながらご紹介します。これから現場に入る方の参考になれば幸いです。
私が知らずに戸惑ったITビジネス用語・言い回し一覧
目次
人月／人日
「人月」や「人日」は工数（作業が完了するまでに必要な人数・時間を表す）の管理をするための単位です。
- 人月（1人が1日8時間×20日間稼働すると仮定した場合の仕事量）
例：とあるタスクが1日8時間稼働で完了まで30日かかりそうな場合、1.5人月と表現します。
- 人日（1人が1日8時間稼働すると仮定した場合の仕事量）
例：とあるタスクが2人で8時間ずつ稼働で完了まで3日かかりそうな場合、2×3=6なので、6人日と表現します。
※案件によっては1日の稼働時間が8時間ではなく7.5時間基準の場合があります。
私が携わっていた案件も1日7.5時間勤務でしたので、7.5時間を基準とした人月／人日を用いて いました。
横展開・横展開調査
「横展開」とは、ある部門やプロジェクト、システムなどで得られた知見・ノウハウを、他の部門やプロジェクトにも適用していくことを意味します。
また、似た言葉に「横展開調査」があります。横展開調査とは、バグや問題が発生した際に、同様の問題が他のシステムなどにも起きていないか調査することを意味します。横展開調査のことを略して横展開と言う場合もあるので混同に注意しましょう。
私が携わっていた案件では、横展開調査を単に横展開と呼んでいました。
ボールを持つ／投げる
ボールを持つ、あるいはボールを投げるとは、プロジェクトの進行やタスクの対応や責任が現状誰のもとにある、という意味で使われる比喩表現です。
私が携わっていた案件では、チームのミーティングでタスク状況を確認する目的で「○○の件って誰がボールを持っていますか？」という風に使われていました。
（例）「システムAの改修案検討のボールは今誰が持っていますか？」
（例）「ファイルBの不具合修正が完了しましたので、開発チームにボールを投げます」
棚卸し
IT案件での「棚卸し」は、一般の棚卸しとは少し異なり、情報・タスク・課題などを整理・洗い出して可視化する作業のことを意味します。私が携わっていた案件では「今残っている○○関連のタスクの棚卸しをお願いします」という風に使われていました。
デグレーション（デグレ）
「デグレーション」（degradation）とは、システムの改修後に、以前は正常に動いていた機能や性能が低下したり、今までなかったバグが新たに発生してしまうことです。略して「デグレ」と呼ばれることもあります。既存のコードに修正を加えた際はデグレーションの調査は必須です。私はこのことを認識しておらず、案件内にて先輩社員に「デグレが発生していないか確認した？それをやらないとバグ対応完了とはいえないよ」と指摘されてしまいました。
コンフリクト（競合）
「コンフリクト」とは、競合・衝突を意味する単語です。IT現場では、基本的にバージョン管理（Gitなど）におけるコンフリクトのことを指します。具体的には、ファイルの同じ個所を同時に複数人がアクセスして編集し、どちらの変更を採用すべきかシステムが自動で判断できずに更新できなくなってしまう現象です。
コンフリクトが起きた場合、手動で修正をしなければならないため手間がかかります。コンフリクトが起きないように、共有されているファイルは常に更新して最新状態にする・他の誰かが編集する可能性があるファイルを自分が編集するときはチャットツールで告知をするなどの対応を心がけましょう。
私も案件でコンフリクトを起こしてしまったことがあります。また、プログラムなどのコードファイルだけでなく、設計書等のエクセルファイルでもバージョン管理をしている場合はコンフリクトが発生する可能性があるので気を付けましょう。（携わっていた案件では設計書関連はTortoiseSVNというバージョン管理システムを使っていました）
リファクタリング
「リファクタリング」とは、外部（機能自体）は変更せずに内部（コード）を改善することです。
可読性・保守性や拡張のしやすさを考慮して、コードの質を上げるのが目的です。
具体的なリファクタリング例は以下です。
- 同じような処理を何度も行っている ⇒ メソッドを作って再利用する
- 変数名が分かりにくい（「a」「list」など） ⇒ 具体的な意味を持つ変数名に変更する（「userName」「itemPriceList」など）
- 1つのメソッドが長すぎる ⇒ 複数のメソッドに分割する
私が携わっていた案件でもこの単語は普通に使用されていました。
まとめ
私が実際に案件に参画してから初めて聞いて困惑したIT用語・言い回しを紹介しました。
あらかじめ多くの用語を知っておけばコミュニケーションや仕様・タスクの理解が多少楽になるでしょう。もちろん、上記以外にも専門用語は無数に存在します。特に、システムやプロジェクト固有の用語の場合は、参画してから覚えるしかありません。
重要なのは、わからない言葉が出てきたときにそのまま放置せず、その場で確認・質問する姿勢です。
曖昧なままにしてしまうと、後々の認識ズレやミスにつながる可能性があります。
知らないことよりも、知らないままにすることの方が問題という意識で取り組みましょう。
