今回はよく使いそうなIT用語、第二弾です！
今回は技術やITに特化した用語というより、プロジェクトのミーティングでよく出てきそうな言葉を中心にチョイスしています！
では今回もいつものノリでいってみましょう！
アグリー
「同意」って意味。誰かの意見に対して、アグリー(同意）するとか、アグリー（同意）できません。みたいな感じで使います
※利用例
アジェンダ
会議などで「議題」という意味で使われたりします。
これを決めとかないと話がよく脱線します。
「完成させるためには、何を決めればよいか？」を簡単でも良いので、予め議題としてあげておくと、脱線率を下げる事ができます！
※アジェンダの例
▼ チャーハンを美味しくするにはどうすべきか？
- パラパラにすべきかシットリさせるべきか
- ネギは青ネギか白ネギか
- 油はラードを使うべきかごま油にするべきか
- 米は冷や飯で作るか炊きたてで作るか
- 名古屋コーチンの卵を使うべきか
- チャーシューではなくベーコンはありか
ASAP
エーエスエーピー派とアサップ派に分かれます。
エィサップなんて感じで読むとちょっとおしゃれかな？
これは「as soon as possible」の略で「可能な限り早く」って意味です。
超余談ですが、裏技で「soon」を「much」にすると「できるだけ長く」という意味になるそうです。
でも、これを「AMAP」とか言っちゃう強者はまだ見たことありません。
オーソライズ
「承認や権限を与える」とか「権利を得た」みたいな使われ方が多いです。
よく「このソフトウェアのライセンスはオーソライズが必要です」みたいな事が書かれてるソフトがあります。
これは「ライセンス認証」して下さいって意味です！
※利用例（相手に突っ込まれそうなケース）
オンスケ
「オンスケジュール」の略で。スケジュール通り順調に進んでいるときに使います。
反対に、スケジュール変更をして調整する事は「リスケ」という言葉を使います。
でも結果的に、オンスケよりもリスケの方が、実際は言葉としてよく使います（涙）
コンセンサス
「複数人の同意を得る事」です。
プロジェクトは、色々な部門や他社との調整がとにかく多いです。
方針を決めたときに、部門1人だけの同意を得るのではなく、「部門単位」での同意を得るという意味で使われます。
「部門の誰か」ではなく「部門」として同意を取り、それを議事録などに証拠を残して進めていく事がすごく重要なポイント！
そうしないと、プロジェクトを進めても進めても、反対者が後を絶たず、前に進まないという事態に遭遇します。
なので、部門単位で先に合意を得る事は「最重要項目」なんです！
合意事項が重要な場合は、発言力のある部門長に同席をしてもらうのも良い作戦！
※利用例（激情型ブラック部長 Vs クールなマネージャー）
リリース寸前かもしれないが
こんな仕様じゃダメだ！
徹夜してでもやり直せ！
仕様変更が発生してもリリース後に実施という決まりで進めています。
この件は定例会で関係者全員のコンセンサスが取れている筈です。
ペンディング
単純に「保留」って事です。
調査してから進めた方が良い場合であったり、優先順位を調整するときに、いったんペンディング（保留）にして別なタスクを進めるときなどに使います。
※利用例（とある夫婦の1コマ）
フィックス
「決める・固定する」という意味です。
プロジェクトなんかでは「これで確定しますよ！」みたいなときに通常使われますね。
話し合えば話し合うほど、どんどん案が出てくるんですけど、決めないと話が前に進まないんですよね。
なので「この件はこれでフィックスします！」という線引きが必要なんです。
こういった議長の発言は「確定しましたので、もう方針変更はダメです」って宣言なんで、参加者は理解してあげましょう。
※利用例（デート編）
マイルストーン
スケジュールなどの「節目」という意味合いで使います。
節目を設定しておく事で、完成まで後どれくらいかかるのかが解りやすくなります。
さらに節目に期限を設定すると、関係者は優先順位の判断材料にする事ができるんです！
※例として車を買う計画にマイルストーンを設定してみました。
- 貯金の開始→2019/11/30に開始
- 貯金の完了→2020/11/30までに完了
- 家族の説得→2020/12/30までに完了
- 車の選定→2020/1/10までに完了
- 購入・手続き→2020/1/12までに完了
- 納車→2020年の1月下旬ごろの予定
ローンチ
「新しいサービスを世に出す」とか「サービス開始日」とか「新作リリース」といったような意味合いで使われます。
言い回しの例として「〇月〇日がローンチの予定日です」みたいな感じですかね。
私の時代は、サービスインとかリリースって言う事が多かったんです。
でも、気が付いたら、ローンチという表現がよく使われるようになっていました。
相手によっては、リリースという言葉を使った方が良いかもしれないので注意しましょう。
※利用例（チャーハンベンダーのローンチ情報）
これからプロジェクトを経験する皆様へ
最後だけ真面目な話をします。
エンジニアを目指している方は沢山の知識を身につける為、日々勉強していると思います。
しかしたくさんの技術を身につける事だけに固執しないようにして下さい。
また、たくさんの事を知っているという優越感に溺れないよう注意して下さい。
これは自分もそうでしたが、多くのエンジニアがこの落とし穴にハマりやすく、これが原因で、苦い経験をしています。
プロジェクトは1人だけではなく、沢山の役割の人と進めていくので、自分の覚えた技術を、他の人とどう連携して生かせるかがポイントです。
実践では技術の知識量よりもこちらのスキルが問われます。
ですので技術の目線だけではなく、他のポジションの人とどう連携をするか？という目線も意識する様にしてください。
これは長年この業界にいる私からのアドバイスです。
関連書籍（今回のテーマに近い書籍）
