デグレを degrade と訳しても通じない

Photo by Tim Gouw

「デグレード」は和風英語

ソフトウェアを更新した際に、新たに埋め込まれたバグなどによってそれまで正常に動作していた機能に不具合が生じたりすることを、日本のIT業界ではよく「デグレした」という言い方をします。「(品質などが)低下する」意味の "degrade" (デグレード) に由来しています。

日本語で書かれた情報工学の論文を調べてみると、ソフトウェアの文脈での「デグレード」は 1970年代頃には登場しており、IT業界では早い段階から使われてきた言葉のようです。

大島裕, ソフトウェア・エンジニアリング：ソフトウエアの信頼性, 情報処理, 1975.

菅野文友, 設計べからず集-13-コンピュータ・ソフトウエア作成におけるデグレード防止について(設計のページ), 品質管理 29 (11), pp.1406-1410, 1978.

機能が正常に動作することもひとつの品質特性のため、一見 "degrade" と言っても良さそうに思えますが、英語圏の人が "degrade" を見ると、応答時間の遅延のような非機能の品質低下を想像します。また、ソフトウェアの変更のように何かのきっかけで品質が低下するという意味もありません。

そのため、「デグレ」を "degrade" と訳しても、日本語と同じ意味では通じません。

Photo by ThisisEngineering RAEng on Unsplash

英語では「regression (リグレッション)」

では、英語圏で同じことを何と表現するかというと、"regression" と言います。日本語では「回帰」とも訳されますが、「以前の、あまり進歩していない、あるいは悪化した状態、状況、振る舞い方に戻ること」という意味になります。

日本のIT業界だと、「リグレッションテスト」や「(リグレッションテストを行うための) リグレッション環境」のように、テストの文脈で使われることが多いようです。

International Software Testing Qualifications Board (ISTQB) や Japan Software Testing Qualifications Board (JSTQB) では、ソフトウェアの文脈における regression / リグレッションを以下のように定義しています。

Regression testing: It is possible that a change made in one part of the code, whether a fix or another type of change, may accidentally affect the behavior of other parts of the code, whether within the same component, in other components of the same system, or even in other systems. Changes may include changes to the environment, such as a new version of an operating system or database management system. Such unintended side-effects are called regressions. Regression testing involves running tests to detect such unintended side-effects.
International Software Testing Qualifications Board, Certified Tester Foundation Level (CTFL) Syllabus Version 2018 v3.1.1

リグレッションテスト：修正および変更でコードの一部に対して行った変更が、同一コンポーネント、同一システム内の他コンポーネント、または他システムの振る舞いに意図せず影響を及ぼす場合がある。変更には、オペレーティングシステムやデータベース管理システムの新しいバー ジョンなど、環境の変更も含まれる。そのような意図しない副作用をリグレッションと呼ぶ。リ グレッションテストでは、テストを実行して、そのような意図しない副作用を検出する。
International Software Testing Qualifications Board, テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03

「デグレード」は日本では広く通用するだけに注意が必要

「デグレード」は日本のIT業界では英語圏における「regression (リグレッション)」の同義語として広く通用する言葉になっており、以下のようなソフトウェアテストやソフトウェア品質の専門家による記事でも、英語圏では "regression" の言葉を使うという但し書きをしつつ、あえて「デグレード」を使っています。

デグレ（デグレード）とは｜デグレのリスクや原因、対策 - SHIFT ASIA -ソフトウェア品質保証のプロフェッショナル-

ソフトウェア開発者を悩ませる「デグレード（デグレ）」とは？原因と対策方法【テスト技法・工程 】| Qbook

しかし、英語でIT文書を書く際には、"degrade" は通じないため、"regression" を使うようにしましょう。

海外エンジニアがチャットやコメントでよく使う略語

Photo by Mikhail Nilov

日本と海外のエンジニアに見る略語の使い方の違い

日本の IT業界では、プレゼン、リスケ、スキトラ、ステコミなど、カタカナ略語がよく使われますが、英語圏でも省略形は使われます。ただし、日本語の省略形は単語を短くすることが多いのに対して、英語ではフレーズの各単語の頭文字で表す頭字語がよく使われます。

youneedaken.hatenablog.com

youneedaken.hatenablog.com

今回は、Slack や Teams などのチャット、Pull Request (PR)のコメントなどで、海外のエンジニアがよく使う略語をご紹介します。

チャットやコメントで使われる略語

AFAIK: as far as I know

意味: 私の知る限りでは、私の知っている範囲では

自分では正しいと信じているものの 100% の確信がない時に、文章の先頭か末尾に付加して使います。万が一間違っている情報が正しい情報として伝わらないように予防線を張っているところがエンジニアらしいですね。関西弁で言うところの「知らんけど」です。

• AFAIK, there are no changes to the plan. (私の知る限りでは、計画に変更はありません。)
• Project end is next May 31, AFAIK. (私の知る限りでは、プロジェクトの終わりは5月31日です。)

aka: also known as

意味: ～としても知られている、別名～

"(あまり知られていない)正式名または本名 aka (よく知られている)別名" の形式で使います。

• Amazon Elastic Compute Cloud aka EC2

ASAP: as soon as possible

意味: できるだけ早く

IT現場以外でも英語がよく使われる外資系企業などでは昔からよく使われてきた略語です。やや命令口調のニュアンスもあるため、社外の人や上司などに対しては使わない方が良い表現です。

• Please review and approve the PR, ASAP. (大至急、PR のレビューと承認をお願いします。)

brb: be right back

意味: すぐ戻ります

"I'll be right back." の省略形 "be right back." をさらに頭字語にしたものです。オンラインミーティングを中座する時に使います。たぶんトイレに行ってます。

BTW: by the way

意味: ところで、ちなみに、なお

話題を変えるときに使います。

• BTW, I wanted to thank you for your help last week. (ところで、先週は大変お世話になりました。)

FYI: for your information

意味: ご参考までに、参考情報として、ちなみに

こちらも外資系企業などでは一般的に使われてきた略語です。チャットが普及する以前もメールの件名や、メールを転送する時に書き足すような使われ方をしてきました。

• FYI, the company is implementing a new expense reimbursement process starting next month. (参考までに、同社は来月から新しい経費精算プロセスを導入します。)

IMO: in my opinion / IMHO: in my humble opinion

意味(IMO): 私の考えでは、思いますに、私見では
意味 (IMHO): 私に言わせていただければ、私のつたない意見としては、僭越ながら申し上げると

個人的な意見や見解を述べる際に使います。

謙虚や謙遜の意味の humble が加わると、さらにへりくだった言い方になります。

• IMO, the team's performance exceeded expectations. (私の考えでは、チームのパフォーマンスは期待以上だった。)
• IMHO, being open to different perspectives fosters a more inclusive environment. (私に言わせていただければ、異なる視点に対してオープンであることは、よりインクルーシブな環境を醸成すると考えています。)

LGTM: looks good to me

意味: 私には良く見える、いい感じ

PR のレビューなどで使われます。2000年代に Google で使われ始めたと言われています。上位者による承認というよりは、同僚によるピアレビューのニュアンスがあります。

一時期、Qitta の「いいね」機能としても採用されていたため、日本のエンジニアにも知られた略語かと思います。なお、現在では「LGTM」から「いいね」に戻っています。

Qiitaの「いいね」が「LGTM」に変わります - Qiita Blog

Qiitaの「LGTM」を「いいね」に戻します - Qiita Blog

LMK: let me know

意味: 知らせてください、教えてください、お知らせください

相手や周りの意見を求める際に使います。後述の WDYT より少し柔らかな表現です。

• I created a draft architecture, LMK your thoughts. (アーキテクチャーをドラフトしたので、ご意見ください。)

Nit: nitpick

意味: 細かいですが、重箱の隅をつつくようですが

主にコードレビューで使われる略語です。コード全体の品質に大きな影響を及ぼすものではない、些末な問題を指摘する際にレビュアーが使います。レビューコメントの先頭に "nit: " と付けて使われることが多いです。

• Nit: this bracket should be placed on a new line (nit: このカッコの前には改行を入れるべき)

シラミの卵 (nit) を摘み取る (pick) という意味から転じて、「あら探しをする」「重箱の隅をつつく」という意味の "nitpick" を省略した言葉です。

nit なレビューコメントはリリースするスピードを重視して、実装者の判断により無視しても良いとしている組織もありますが、nit: とつけておきながら修正しないと承認してくれないレビューアーもいます。

What is a "Nit" in a code review?

The Standard of Code Review | eng-practices

ntd: need to drop

意味: 抜けます、落ちます

次の予定などがあって、自分だけオンラインミーティングを抜けなければいけないような時に使います。

TBD: to be decided, to be determined

意味: 将来決定する、未定

未定、未決定、未確定の事柄を示す際に使います。チャットやコメントだけでなく、文書でもよく使われます。

• The release date of the product is TBD. (プロダクトのリリース日は未定です。)

TBH: to be honest

意味: 正直に言うと、率直に言うと、はっきり言って、ぶっちゃけ

率直な考えを伝える時に使います。ややカジュアルなニュアンスがあるため、信頼関係のある相手に対して使います。

• TBH, I think we should reconsider our approach. (率直に言うと、アプローチを再検討すべきだと思います。)

TL;DR: too long; didn't read

意味: 長過ぎ。読んでない。、長文うざい

長文に対して読んでいないことを皮肉を込めて伝える表現です。そこから転じて、長文の要約を示す際にも使われます。

英語圏でもインターネットスラングの域をまだ出ていない表現で、やや相手を小馬鹿にしたようなニュアンスも含むので、オフィシャルな場では使うのを避け、使う場合も信頼関係のある相手に限った方が良いです。

TTYL: talk to you later

意味: あとでまた話そう、ではまた、またね

チャットを一旦終えるような時に使います。あとで実際に話すこともあれば、単なる挨拶の場合もあります。

WDYT: what do you think

意味: どう思う？

相手や周りの意見を求める際に使います。前述の LMK より答えを求める意思が明確なニュアンスがあります。

• WDYT about the latest technology trends? (最近の技術トレンドについてどう思いますか？)

略語を使う際の注意点

今回ご紹介した略語の内、例文のないものは単独で使われることが多いものになります。

また、頭字語は一般的に大文字で書きますが、カジュアルなチャットでは小文字のままで使われることもあります。例えば、brb や ntd とだけ打ち込んでいなくなる場面もよく見かけます。

Pager が鳴らなくて

Photo by Espritdoll

本番システム運用の携行品

IT業界で働き始めて20数年経ちますが、これまでのキャリアでは主にアプリケーションの新規開発や再構築に携わってきたため、システムの移行までは経験しているものの、安定して本番稼働した後のシステムの保守や運用に関わる機会はあまりありませんでした。ただ、最近になってはじめて既に本番稼働しているシステムのコードに触る仕事に携わっています。その一環として、スマートフォンに Pager アプリをインストールすることになりました。

Pager アプリとは、本番障害などシステムに緊急を要する事態が発生した際などに、担当者のスマートフォンにアラームを通知するアプリです。スマートフォンから少し離れていたり、就寝中も気付けるように、かなりけたたましい大きな音が鳴ります。

Photo by iddea photo

Pager とはポケベルのこと

Pager は、今でこそスマートフォンのアプリになっていますが、スマートフォンさらに言うと携帯電話が普及する前は、通知の受信専用の小型デバイスを指していました。外出中のビジネスパーソンと連絡をとるために使われていましたが、日本では「ポケットベル」略して「ポケベル」の通称で1990年代に若い世代を中心に流行しました。

www.soumu.go.jp

Photo by のぽぽん

動詞としての page

英語での "page" は動詞でもあり、「〔館内放送・ポケットベルなどで人を〕呼び出す、〔館内放送・ポケットベルなどで人に〕連絡する」という意味があります。日常生活では、例えばホテルのフロントで人を呼び出すような時などに使いますが、Pager デバイスやアプリを使って呼び出しをすることも "page" と言います。

The Engineering Manager will page the software engineer in case of critical system failures.
(日本語訳)
重大なシステム障害が発生した場合、エンジニアリングマネージャーがソフトウェアエンジニアに連絡します。

page の語源

「呼び出す、連絡する」という意味での動詞の "page" は、中世ヨーロッパの貴族に仕えていた小姓もしくは使者を意味する "page" または "page boy" からきています。小姓や使者を遣わして誰かにメッセージを伝えるところから動詞にもなりました。

現代では、結婚式で指輪を運ぶ役割の男の子のことも "page boy" と呼ばれます。

page | Etymology of page by etymonline

Image by Jocelin Thuret from Pixabay

「○○以上」は “○○+” と表現する

Photo by Claudio Schwarz on Unsplash

「以上」は "or higher" や "or above"

皆さんの職場の中で、何らかの職務を担うのに職位や資格などを条件にしているものはありませんでしょうか？

例えば、次のような条件です。

• 海外出張は、TOEIC 600点以上を必要とする。
• 採用面接は、マネージャー以上が行う。

「海外出張」や「採用面接」は職務で、「TOEIC の点数」や「マネージャー」はそれぞれ資格と職位です。

資格や職位に続いている「以上」は、"or higher" や "or above" のように表現することで、次のように英訳できます。

• TOEIC score of 600 or higher is required for overseas business trips.
• Hiring interviews will be done by Managers or above.

Photo by Tima Miroshnichenko

"up" は和製英語？

"or higher" や "or above" は英語として正しいのですが、2文字で表現できる日本語の「以上」に比べて長いので、たまに "up" という表現を耳にしたり、見かけたりすることがあります。例えば、"TOEIC 600 up" や "Manager up" のような表現です。

この "○○ up" という表現は、日本語の会話や文章の中でよく見かけるのですが、英語圏の人からはあまり聞いたことがありません。おそらく和製英語の一種ではないかと考えています。

Photo by Franco Antonio Giovanella on Unsplash

"or higher" や "or above" の省略形は "+"

英語圏では「以上」に相当する表現として、"○○+" という書き方があります。"TOEIC 600+" や "Manager+" のように書きます。スペースが限られた書式や文章を短くしたい時に、"or higher" や "or above" の代わりに "+" を使うことができます。

プラス記号は数字だけに付加できるような印象もありますが、Manager > Senior Manager > Partner > Senior Partner のように順列があるようなものであれば、"Manager or above" と同じ意味を表現することができます。

IT業界の和製英語「バージョンアップ」

Photo by Clint Patterson on Unsplash

バージョンアップは和製英語

オペレーティングシステム (OS)、ファームウェア、アプリケーションなどといったソフトウェアのバージョンを新しいバージョンに更新することを、よく「バージョンアップ」と言います。大規模なシステムのソフトウェアのバージョンを更新する場合は、それ自体がプロジェクトになることもあり、「＊＊＊システム基盤OSバージョンアッププロジェクト」のようなプロジェクト名がつけられることもあります。

この「バージョンアップ」は和製英語だと言われています。

バージョンアップとは、コンピュータのソフトウェア製品などの機能や性能を改良・向上させて新しい版にすることです。英語の version は「版」のことです。up は上方向を示しますが、通常動詞と結びついて使いますので、バージョンアップは正しい表現ではありません。「新版にすること」を英語では an upgrade といいます。具体的に「最新の版にする」というなら、upgrade を動詞に使って、upgrade to the new (est) version と表します。また、従来の物を改訂・改良することをも意味しますが、その場合は改訂版 a revised version となります。
亀田尚己・青柳由紀江・J. M. クリスチャンセン, 和製英語事典, 丸善出版, 2014.

例えば、「従業員の PC をすべて年内に Windows 11 にバージョンアップする。」という日本語文は、"Upgrade all employee PCs to Windows 11 by the end of the year." という英文になります。

"Version up all employee PCs to Windows 11 by the end of the year." は、英語圏の人も意味を汲みとってくれる可能性はありますが、相当ぎこちない表現として受け取られるでしょう。

upgrade と update の違い

ソフトウェアを更新をする意味の言葉として、upgrade の他に update という言い方もあります。2つの言葉の違いを英語の記事で見てみます。

A software update, which is sometimes called a software patch, is not the same thing as a software upgrade. An update is generally an enhancement to the current version of the software or application, while an upgrade is a whole new version of it. Updates are usually free and simple to install. Often, you must pay for upgrades, and they're more complicated to install.
(日本語訳)
ソフトウェアパッチとも呼ばれるソフトウェアのアップデートは、ソフトウェアのアップグレードとは異なります。アップデートは、通常ソフトウェアやアプリケーションの現行のバージョンを強化するもので、アップグレードは全く新しいバージョンになります。アップデートは通常無料で、インストールするのも簡単です。多くの場合、アップグレードは有料で、インストールも複雑です。

The Difference Between Software Updates and Upgrades

Update is a process of enhancing certain parts of the same application or software like security updates to deal with the newly discovered vulnerabilities so patches are released and users can download the updates to make the software more secure.
Upgrade can be defined as a process of shifting to a newer version of any existing application or software. This definition is in context to the computer science field. For example, we upgrade our windows whenever any latest version comes in the market because the newer version contains certainly more features than the older one.
(日本語訳)
アップデートは、新たに発見された脆弱性に対処するためのセキュリティアップデートのように、同じアプリケーションやソフトウェアの特定の部分を強化するプロセスです。パッチがリリースされることにより、ユーザーはソフトウェアをより安全にするためのアップデートをダウンロードすることがでます。
アップグレードは、既存のアプリケーションやソフトウェアを新しいバージョンに移行するプロセスと定義できます。これは、コンピュータサイエンス分野の文脈に沿った定義です。例えば、新しいバージョンが市場に出荷される度に、私たちは Windows をアップグレードします。これは、新しいバージョンが古いバージョンよりも多くの機能を搭載しているためです。

Difference between Update and Upgrade - GeeksforGeeks

これらは、update と upgrade の違いを説明した2つの例ですが、他にも似たような説明をした記事がいくつかあります。つまり、バージョンが新しいものに変わる場合は "upgrade"、変わらない場合は "update" を使います。

そのため、バージョンが変わることを示唆している日本語の「バージョンアップ」は、"version upgrade" もしくは単に "upgrade" と表現するのが良さそうです。

無料で参照できる英語の要件定義書テンプレート

Photo by Beatriz Pérez Moya on Unsplash

要件定義書は Requirements Document か Business Requirements Document

日本語でいう要件定義書 (要求定義書) は、英語では Requirements Document や Business Requirements Document と言います。直訳すると要件定義書と業務要件定義書ですが、日本語で両者がほぼ同義的に使われることがあるのと同様に、英語でも両者が区別されることもあれば、同義的に使われることもあります。

今回は、主に海外の Webサイトで公開されている Requirement Document のテンプレートをご紹介します。

How to Write a Business Requirements Document | AltexSoft

英語の要件定義書テンプレート

TechWhirl

TechWhirl は、テクニカルライター向けのオンラインマガジンで、リンク先の記事からはソフトウェア開発やその他のITプロジェクトで使用できる Microsoft Word 形式の要件定義書テンプレートをダウンロードできます。日本企業の要件定義の標準でも見られるような項目を含む章立てになっています。

techwhirl.com

1. Document Revisions ／ 改訂履歴
2. Approvals ／ 承認者
3. Introduction ／ 前書き
   3.1 Project Summary ／ プロジェクト概要
   3.1.1 Objectives ／ 目的
   3.1.2 Backgrounds ／ 背景
   3.1.2.1 Business Drivers ／ ビジネスドライバ
   3.2 Project Scope ／ プロジェクトスコープ
   3.2.1 In Scope Functionality ／ スコープ内の機能
   3.2.2 Out of Scope Functionality ／ スコープ外の機能
   3.3. System Architecture ／ システムアーキテクチャ
   3.3.1 Assumptions ／ 前提
   3.3.2 Constraints ／ 制約
   3.3.3 Risks ／ リスク
   3.3.4 Issues ／ 課題
4. Business Process Overview ／ ビジネスプロセス概要
   4.1 Current Business Process (As-Is) ／ 現行ビジネスプロセス (As-Is)
   4.2 Proposed Business Process (To-Be) ／ 将来ビジネスプロセス (To-Be)
5. Business Requirements ／ 業務要件
   5.1 Functional Requirements ／ 機能要件
   5.2 Non-Functional Requirements ／ 非機能要件
6. Appendices ／ 付録
   6.1 List of Acronyms ／ 略語一覧
   6.2 Glossary of Terms ／ 用語集
   6.3 Related Documents ／ 関連文書

Stanford University

スタンフォード大学の IT Project Management Office では、要件定義書以外にもプロジェクトのライフサイクルで必要な文書のテンプレートを Microsoft Office 形式および Google Workspace 形式で提供しています。TechWhirl と比べると、機能要件、非機能要件共に、一段詳細化した章立てになっています。

Templates | University IT

1. Introduction ／ 前書き
   1.1. Purpose of the Document ／ 本文書の目的
   1.2. Document Conventions, Terms, and Definitions ／ 文書規約、用語、定義
   1.3. Intended Audience and Reading Suggestions ／ 想定読者と本書の読み方
   1.4. Scope ／ スコープ
   1.4.1. Project Scope ／ プロジェクトのスコープ
   1.4.2. Business Requirement Document Scope ／ ビジネス要件書のスコープ
   1.5. References ／ 参考
2. Overall Description ／ 全体概要
   2.1. Project Overview ／ プロジェクト概要
   2.2. Product Features ／ プロダクトのフィーチャ
   2.3. User Classes and Characteristics ／ ユーザの分類と特徴
   2.4. Operating Environment ／ 運用環境
   2.5 Design and Implementation Constraints ／ 設計と実装の制約
   2.6. User Documentation ／ ユーザ文書
   2.7. Assumptions, Dependencies, and Risks ／ 前提、依存関係、リスク
3. System Features ／ システムのフィーチャ
   3.1. << Name of System Feature #1 >> ／ <<システムのフィーチャ名 #1>>
   3.1.1. Description ／ 説明
   3.1.2. Stimulus/Response Sequences ／ 刺激応答シーケンス
   3.1.3. Functional Requirements ／ 機能要件
   3.1.3.1. Use Cases ／ ユースケース
4. External Interface Requirements ／ 外部インタフェース要件
   4.1. User Interface ／ ユーザインタフェース
   4.2. Hardware Interfaces ／ ハードウェアインタフェース
   4.3. Software Interfaces ／ ソフトウェアインタフェース
   4.4. Communications Interfaces ／ 通信インターフェース
   4.5. Reporting Requirements ／ 帳票要件
5. Other Nonfunctional Requirements ／ その他の非機能要件
   5.1. Performance Requirements ／ パフォーマンス要件
   5.2. Security Requirements ／ セキュリティ要件
   5.3. Data Requirements ／ データ要件
   5.4. Software Quality Attributes ／ ソフトウェア品質特性
6. Other Requirements ／ その他の要件
7. Campus Readiness and Training ／ キャンパスの準備とトレーニング
   Appendix A: Glossary ／ 添付A: 用語集
   Appendix B: Analysis Models ／ 添付B: 分析モデル
   Appendix C: Issues List ／ 添付C: 課題一覧
   Appendix D: Screenshots, Mock-Ups, and Live Links ／ 付録D: スクリーンショット、モックアップ、リンク
   Appendix E: Test Scenarios ／ 付録E. テストシナリオ

Government of British Columbia

カナダのブリティッシュコロンビア州政府の Web サイトで参照できる要件定義書テンプレートは、要件を機能要件、データ要件、非機能要件、インタフェース要件と分けており、理解しやすい構造になっています。

Business Requirements Document (BRD) Template

1. INTRODUCTION ／ 前書き
   1.1. DOCUMENT PURPOSE ／ 当文書の目的
   1.2. INTENDED AUDIENCE ／ 想定読者
   1.3. PROJECT BACKGROUND ／ プロジェクトの背景
   1.4. PURPOSE OF THE BUSINESS REQUIREMENTS ／ 業務要件の目的
   1.5. BUSINESS GOALS/OBJECTIVES TO BE ACHIEVED ／ ビジネス目標/達成すべき目的
   1.6. BENEFITS/RATIONALE ／ 効果/根拠
   1.7. STAKEHOLDERS ／ ステークホルダー
   1.8. DEPENDENCIES ON EXISTING SYSTEMS ／ 既存システムとの依存 1.9. REFERENCES ／ 参考
   1.10. ASSUMPTIONS ／ 前提
2. REQUIREMENTS SCOPE ／ 要件のスコープ
   2.1. IN SCOPE ／ スコープに含まれること
   2.2. OUT OF SCOPE ／ スコープに含まれないこと
3. FUNCTIONAL REQUIREMENTS ／ 機能要件
   3.1. ACTOR PROFILES SPECIFICATION ／ アクタープロファイル仕様
   3.2. ESSENTIAL USE CASE DIAGRAM ／ 主要なユースケース図
   3.3. ESSENTIAL USE CASE SPECIFICATIONS ／ 主要なユースケース仕様
   3.4. FUNCTION HIERARCHY DIAGRAM ／ 機能階層図
   3.5. FUNCTION DEFINITION REPORT ／ 機能定義記述
   3.6. BUSINESS RULES ／ ビジネスルール
4. DATA REQUIREMENTS ／ データ要件
   4.1. DATA ARCHITECTURE ／ データアーキテクチャ
   4.1.1. Domain Class Diagram ／ ドメインクラス図
   4.1.2. Entity Relationship Diagram ／ 実体関連図 (ER図)
   4.2. DATA VOLUMES ／ データボリューム
   4.3. DATA CONVERSION ／ データ変換
   4.4. DATA RETENTION AND ARCHIVING ／ データの保持とアーカイブ
   4.5. FOI/PRIVACY IMPLICATIONS ／ 情報公開/プライバシー関連
   4.6. DATA DEFINITION REPORTS ／ データ定義記述
   4.6.1. Domain Class Definition Report ／ ドメインクラス定義記述
   4.6.2. Entity Definition Report ／ エンティティ定義記述
5. NON-FUNCTIONAL REQUIREMENTS ／ 非機能要件
   5.1. SECURITY REQUIREMENTS ／ セキュリティ要件
   5.1.1. Authentication ／ 認証
   5.1.2. Authorization and Access Controls ／ 認可とアクセス制御
   5.1.3. Information Security Classification and labeling ／ 情報セキュリティ分類とラベリング
   5.2. AVAILABILITY REQUIREMENTS ／ 可用性要件
   5.3. USABILITY REQUIREMENTS ／ ユーザビリティ要件
   5.4. SYSTEM HELP REQUIREMENTS ／ システムヘルプ要件
   5.5. PERFORMANCE REQUIREMENTS ／ パフォーマンス要件
   5.6. SCALABILITY REQUIREMENTS ／ スケーラビリティ要件
   5.6.1. User Scalability ／ ユーザスケーラビリティ
   5.6.2. Application Scalability ／ アプリケーションスケーラビリティ
6. INTERFACE REQUIREMENTS ／ インタフェース要件
   6.1. USER INTERFACE REQUIREMENTS ／ ユーザインタフェース要件
   6.2. SYSTEM INTERFACE REQUIREMENTS ／ システムインタフェース要件
7. BUSINESS GLOSSARY ／ ビジネス用語集
   APMS UPDATE ／ APMS更新
   REVISION LOG ／ 改訂履歴
   APPENDICES ／ 付録
   APPROVAL ／ 承認

ビジネスプロセスで使うべき動詞、使うべきでない動詞

Photo by Brett Jordan

(2023-08-28 更新)

英語圏ではビジネスプロセスを「動詞 + 名詞」で命名する

前回のブログ記事では、英語圏においてビジネスプロセスのアクティビティーやタスクは、「動詞 + 名詞」で命名することがベストプラクティスとされていることを紹介しました。

その理由として、アクティビティーやタスクの名前にその実行者を主語として加えると、「主語 (S) + 動詞 (V) + 目的語 (O)」の第3文型の完全文となり、英語の読み手にとって理解しやすい構文になることを考察しました。

実行者: Patient
タスク名: Send Doctor Request
完全文: Patient sends doctor request. (患者は診察依頼を送信する。)

一方、日本語ではアクティビティーやタスクを「名詞 + 名詞」で命名することも多く、そのまま英訳すると英語圏の人にとっては理解しにくい表現になってしまうことも紹介しました。

youneedaken.hatenablog.com

NRS Business Process Standards and Guidelines using BPMN

(2023-08-28 更新)

ビジネスプロセスをどのような動詞で命名すれば良いかについては、カナダのブリティッシュコロンビア州が作成した "NRS Business Process Standards and Guidelines using BPMN" が参考になります。Business Process Model and Notation 2.0 (BPMN 2.0) の利用標準ガイドラインである同文書では、ビジネスプロセスにおける命名で使うべき動詞を一覧しています。

NRS Business Process Standards and Guidelines using BPMN

今回は、同文書で推奨されている動詞を日本語訳と共に紹介します。

Photo by Owen Yin on Unsplash

ビジネスプロセスで使うべき動詞

A～E

動詞 (英語)	動詞 (日本語)	動詞 (英語)	動詞 (日本語)
Accept	引き受ける 受諾する 受理する 受け入れる	Decide	裁定する 決める
Adapt	順応させる	Define	定義する
Adopt	採用する 導入する	Deliver	配達する 届ける 納品する 配信する 供給する 送る 引き渡す 交付する
Align	調整する 調節する	Deploy	配備する 配置する 展開する
Allocate	割り当てる 計上する 配分する	Describe	記述する 説明する 描写する 表現する
Apply	適用する	Design	設計する デザインする
Approve	承認する	Determine	決定する 確定する 特定する 判定する 判断する
Arrange	準備する 手配する	Develop	開発する
Assess	評価する	Discuss	議論する
Assign	割り当てる	Distribute	分配する 区分する 割り振る
Authorize	認可する 許可する	Divide	分割する
Begin	開始する	Enable	可能にする 有効にする
Build	構築する	Enter	入力する
Calculate	演算する 計算する	Establish	設置する 制定する 確立する
Capture	取り込む キャプチャーする	Estimate	見積もる
Categorize	分類する	Evaluate	評価する 査定する
Change	変更する	Examine	観察する 分析する 検査する
Choose	選択する	Execute	実行する
Circulate	回覧する 配布する	Expedite	促進させる
Clarify	明確化する	Explore	探索する 調査する
Classify	分類する
Close	分類する
Combine	結合させる
Compile	蓄積する 集める 編集する コンパイルする
Complete	完了する
Conduct	実施する
Confirm	確認する
Construct	組み立てる 建設する 構築する 構成する
Continue	継続する
Control	制御する
Convert	変換する
Coordinate	統合する まとめる 調整する 連係させる 整理する

F～J

動詞 (英語)	動詞 (日本語)	動詞 (英語)	動詞 (日本語)
Facilitate	促進する 円滑に進める	Identify	識別する
Finish	終える	Implement	実行する 実装する
Focus	注目する フォーカスする	Improve	改善する
Forecast	予想する 予測する 予報する 予定する	Include	含める
Form	形成する	Increase	増やす 高める 拡大する
Forward	転送する 送付する	Initiate	始める 開始する 起動する
Foster	発展させる 育成する 助長する	Integrate	統合する
Gather	収集する	Interview	インタビューする
Generate	生成する	Involve	取り込む 参加させる
Group	グループ化する	Issue	発行する
Guide	ガイドする

K～O

動詞 (英語)	動詞 (日本語)	動詞 (英語)	動詞 (日本語)
Launch	始める 開始する 起動する	Name	命名する
Leverage	利用する 活用する	Navigate	航行する 操縦する 操舵する
License	認可する 使用権を認める 使用許可を与える	Notify	通知する
Link	リンクする	Obtain	取得する
Load	ロードする	Offer	提示する 提供する 提案する
Locate	探す	Open	開く
Maximize	最大化する	Operate	操作する
Measure	計測する	Optimize	最適化する
Minimize	最小化する	Order	注文する
Modify	修正する 変更する	Organize	編成する 構造化する 体系化する 企画する
Move	移動する

P～Z

動詞 (英語)	動詞 (日本語)	動詞 (英語)	動詞 (日本語)
Perform	実行する 遂行する	Scan	スキャンする
Plan	計画する	Schedule	スケジュールに入れる 予定を決める
Prepare	準備する	Screen	検査する 選抜する
Present	発表する	Search	検索する
Prioritize	優先する	Secure	確保する 保護する
Process	処理する	Select	選択する
Produce	産出する 生産する 製造する 製作する	Serve	供給する
Propose	提案する	Settle	解決する 調停する 確定させる 決定する 清算する 決済する
Provide	提供する	Share	共有する
Purchase	購入する	Show	表示する
Qualify	資格を与える 適格とする 適任とする	Simplify	単純化する 簡素化する 簡略化する
Quantify	定量化する	Sort	ソートする
Query	問い合わせを行う	Specify	特定する
Receive	受け取る 受領する	Staff	配属する
Record	記録する	Start	始める 開始する
Refer	参照する	Structure	構造化する 構築する スケジュール化する
Register	登録する	Submit	提出する
Release	解放する	Suggest	提案する 提言する 勧める
Replace	置き換える 置換する	Supply	供給する 支給する 提供する
Reply	返信する	Support	支える 支持する 支援する
Report	報告する	Survey	調査する 検査する
Request	要求する	Test	テストする
Reserve	予約する	Translate	翻訳する
Resolve	解決する	Transmit	転送する
Respond	答える 応答する	Update	更新する
Return	返す 戻す 返却する 返品する 返送する 返上する	Validate	正当であると確認する 認証する
Review	再調査 再検討する 再考察する 見直す	Verify	検証する 立証する 実証する 確かめる 確認する 点検する 照合する

ビジネスプロセスで使うべきではない動詞

NRS Business Process Standards and Guidelines using BPMN では、ビジネスプロセスで使うべき動詞と共に、使うべきではない動詞も紹介しています。

以下の動詞は、明確さを欠いていたり、継続的に実行される行為を表すために、アクティビティーやタスクの命名には使うべきではないとしています。

動詞 (英語)	動詞 (日本語)
Administer	管理する 運営する 処理する
Maintain	維持する
Manage	管理する
Monitor	監視する
Process	処理する