Kỹ năng technical writing

Đôi khi ở công ty nhóm chúng tôi cùng thảo luận cách sửa một đoạn viết bằng tiếng Nhật để tăng cường khả năng diễn đạt bằng tiếng Nhật. Mục đích ban đầu là kỹ năng tiếng Nhật, nhưng đi sâu vào thì tôi thấy những điều rút ra được không chỉ là ngôn ngữ mà là bản thân cách suy nghĩ, cách diễn đạt.

Hiện tại hoạt động này đang tạm dừng, qua bài này tôi mong muốn tranh thủ lưu giữ lại đôi điều đúc rút được từ một buổi thảo luận đã diễn ra.

I. Đoạn văn được đem ra thảo luận

Q: システムを外部の人に使わせるのは可能ですか？

A: 外部の人に使わせるのは、一番問題になるのがセキュリティです。
現在QMのユーザ認証と権限振り分け機能がないですので
利用IP制限と社内Gメール制限で不正アクセスを制限しています。
外部に人に使わせるためには、ユーザ認証と権限振り分け機を
ちゃんと作らないと、かなりのリスクがあります。

Dịch mộc mạc thì đoạn trên nghĩa là:

Câu hỏi: Có thể để cho những người ngoài công ty sử dụng hệ thống được không?

Trả lời: Để người bên ngoài (công ty) sử dụng, vấn đề hàng đầu là security. Hiện tại, vì QM (tên product) không có chức năng authenticate user và phân quyền nên (QM) chỉ hạn chế access trái phép bằng cách hạn chế IP và chỉ cho truy cập từ gmail công ty. Nhắm đến việc open để cho người bên ngoài sử dụng, nếu ta không nghiêm túc làm các chức năng authenticate user và phân quyền thì sẽ khá là rủi ro.

II. Phương hướng cải thiện và kết quả ví dụ

Về cơ bản đoạn trả lời trên cũng không có vấn đề gì lớn, hướng thảo luận của chúng tôi là làm sao cải thiện đoạn này để:

a) Dùng văn phong chuẩn xác tiếng Nhật hơn nữa

b) Diễn đạt tường minh hơn nữa để nêu bật ý người muốn trả lời

c) Kết nối giữa các câu tốt hơn nữa

d)  Tìm cách đưa một cấu trúc mang tính khuôn mẫu để kể cả người mới bắt đầu cũng có thể viết một câu trả lời tốt.

Tạm thời tôi sẽ chưa giới thiệu các phương án phục vụ cho a) Dùng văn phong chuẩn xác tiếng Nhật hơn nữa, vì chúng thiên về kỹ năng và kinh nghiệm tiếng Nhật dùng trong giao tiếp văn bản ở công sở, thay vào đó xin đi  vào các mục đích khác mà bấy kỳ bạn đọc nào cũng có thể hiểu

b) Diễn đạt tường minh và làm rõ ý trả lời

Để làm việc này, ta tập trung tìm hiểu hình thức của câu hỏi và câu trả lời. Về mặt ngữ nghĩa, có thể khái quát đoạn trên như sau:

Q) Có thể làm việc X được ko? (Yes/No question)

A) Để làm X, nếu không làm Y thì khá rủi ro

Ta có thể thấy Q là một câu hỏi có hình thức Yes/No còn A là một câu trả lời mang tính liệt kê sự thực (facts listing) . Trường hợp hình thức thì như vậy nhưng ý hỏi chỉ có tính thăm dò (Nếu làm việc X thì có vấn đề gì không?) thì câu trả lời facts listing như hiện tại hoàn toàn ổn.

Còn nếu khắt khe hơn, trường hợp hình thức và ý hỏi giống nhau thì Q không còn mang tính thăm dò mà nó trở thành một câu yêu cầu nêu ý kiến (Ý kiến của bạn trong trường hợp làm việc X là gì? Có thể làm được X hay không làm được X? ), thì trả lời kiểu facts listing như trên là chưa đủ. Trường hợp này cần trả lời rõ chủ kiến của ta hơn nữa.

Sau đây là một số phương án sửa theo hướng này:
A1) TH làm X, cần phải làm Y

VD: TH cho phép access từ bên ngoài, cần phát triển tính năng authenticate người dùng và phân quyền.

A2) Nếu làm X, sẽ có rủi ro Z, vì thế cần nghiêm túc làm Y

VD: Cho phép access từ bên ngoài thì rủi ro bị access trái phép sẽ tăng lên, vì thế cần nghiêm túc phát triển tính năng authenticate người dùng và phân quyền.

A3) Nếu làm X thì nên làm Y để giảm thiểu rủi ro

VD: TH cho phép access từ bên ngoài, nên phát triển tính năng authenticate người dùng và phân quyền để giảm thiểu rủi ro

c) Kết nối giữa các câu tốt hơn nữa

Để làm việc này, ta có thể theo dõi các thông tin mới mà từng câu trả lời đưa ra và xem chúng có liên kết tốt về mặt từ vựng với nhau hay không. Để đơn giản, ta sẽ gạch chân những danh từ/ cụm danh từ mới được thêm vào ở từng câu.

Câu hỏi: Có thể để cho những người ngoài công ty sử dụng hệ thống được không?

Trả lời:

C1. Để cho người bên ngoài (công ty) sử dụng, vấn đề hàng đầu là security.

C2. Hiện tại, vì QM không có chức năng authenticate user và phân quyền nên chỉ hạn chế access trái phép bằng cách hạn chế IP và chỉ cho truy cập từ gmail công ty. (chú thích QM không được coi là từ mới vì trong context này cả người hỏi và trả lời đều hiểu rõ đang nói về hệ thống nào)

C3. Nhắm đến việc open để cho người bên ngoài sử dụng, nếu ta không nghiêm túc làm các chức năng authenticate user và phân quyền thì sẽ khá là rủi ro.

Như vậy các từ mới xuất hiện lần lượt qua C1, C2, C3 là:

C1: vấn đề hàng đầu, security

C2: chức năng authenticate user, chức năng phân quyền, hạn chế access trái phép

C3: rủi ro

Lại xem xét một cách khắt khe thì các từ security, chức năng authenticate user, chức năng phân quyền, hạn chế access trái phép , rủi ro có liên kết về mặt từ ngữ, nhưng:

– Liên kết này không phải lúc nào cũng hiển nhiên, dễ thấy nếu người đọc không có chuyên môn một chút về IT

– Các từ như vấn đề hàng đầu, security có mức độ trừu tượng cao hơn (chung chung hơn), trong khi các từ như chức năng phân quyền/ authenticate user lại cụ thể hơn, còn cụm từ hạn chế access trái phép thì có mức độ trừu tượng vừa vừa, ở khoảng giữa. Việc liên kết giữa các từ chung chung ở C1 sang các từ cụ thể ở C2 sẽ vì thế sẽ đòi hỏi một logic không tường minh (implicit mapping)

Về thủ pháp để cải thiện diễn đạt, ta có thể dùng key-word base: Quan sát đống từ vựng ở trên và nghĩ ra một key-word có khả năng liên kết tất cả chúng với nhau và dùng key-word này ngay từ câu đầu (C1). May mắn là ở đây ta đã có sẵn một từ khá gần: hạn chế access trái phép. Theo comment của một bạn native người Nhật, chúng tôi đã tạm chọn ra key word là phòng chống access trái phép vì phòng chống nêu bật được mục đích hơn, có chủ ý rõ ràng hơn là hạn chế (chỉ là 1 phương tiện để “phòng chống”)

Dùng keyword này ta có thể sửa lại diễn đạt câu trả lời như ví dụ như sau:

C1. Để cho người bên ngoài (công ty) sử dụng, vấn đề hàng đầu là phòng chống access trái phép.

C2. Để phòng chống access trái phép, hiện tại QM chưa có chức năng authenticate user và phân quyền mà chỉ hạn chế IP / chỉ cho truy cập từ gmail công ty.

C3. Nhắm đến việc open để cho người bên ngoài sử dụng, nếu ta không nghiêm túc làm các chức năng authenticate user và phân quyền thì sẽ khá là rủi ro.

d)  Tìm cách đưa một cấu trúc mang tính khuôn mẫu để kể cả người mới bắt đầu cũng có thể viết một câu trả lời tốt.

Để làm việc này, ta sẽ xem xét “chiến lược” (mạch văn) được dùng trong câu trả lời, thử suy nghĩ xem có thể theo chiến lược nào khác và viết lại đoạn. Cụ thể đoạn trả lời hiện tại đang theo mạch văn sau:

C1. Để làm việc X, vấn đề hàng đầu là Z. –> Nêu quan ngại

C2. Hiện tại QM không có …., nên ….. –> Giải thích hiện trạng

C3. Nhắm đến X, nếu ta không làm Y thì sẽ khá rủi ro. –> Nêu nhận định

Tức là:

 Nêu vấn đề > giải thích hiện trạng > nêu nhận định

Chúng tôi đã hỏi người viết “Vì sao lại đi theo cấu trúc trên?”, người viết nói “Thành thực là cũng vội nên cứ viết theo dòng suy nghĩ, nghĩ gì viết đấy”. Việc nghĩ gì viết đấy so với việc xác định viết theo cấu trúc nào trước rồi mới viết thì dĩ nhiên là nhiều rủi ro hơn. Tất nhiên trong trường hợp này do người viết câu trả lời nói trên (không phải tôi nhé 🙂 ) từng có nhiều năm kinh nghiệm học tập và làm việc tại Nhật nên không cần nghĩ nhiều cũng tự nhiên khắc phục được các rủi ro đó bằng khả năng ngôn ngữ vượt trội. Thử thách đặt ra là nếu giả sử chúng ta hướng dẫn cho một bạn mới làm BrSE/PO thì chúng ta cần nghĩ ra một mạch văn mang tính khuôn mẫu hơn để chắc chắn bạn ấy cứ thế theo là có thể nhanh chóng tự viết được mà câu trả lời chấp nhận được.

Thống nhất rằng nói chung chỉ có hai chiến lược phổ biến là diễn dịch (kết luận, rồi giải thích) hoặc quy nạp (giải thích rồi kết luận) và với người Nhật trong công việc thì diễn dịch là thường được sử dụng hơn, chúng tôi đã đưa ra những phương án cải tiến cấu trúc câu trả lời như sau:

D1: Đề xuất (kết luận) > Lý do (bối cảnh và quan ngại)

VD:

Đề xuất: TH open cho toàn bộ các IP từ bên ngoài đều access được, cần phải phát triển chức năng authenticate user và phân quyền.

Lý do: Hiện tại, hệ thống đang phòng chống access trái phép bằng cách chặn IP và dùng gmail nội bộ để hạn chế access. Nếu ko phát triển các tính năng đó, ta sẽ chịu rủi ro bị access không mong muốn.

D2: Kết luận > Quan ngại 1 > giải thích 1 > Quan ngại 2 >  giải thích 2 > Đề xuất

VD (do chính tay người viết ban đầu tự sửa lại câu trả lời của mình với cấu trúc mới)

Về mặt kỹ thuật thì có thể mở cho bên ngoài sử dụng, tuy nhiên về mặt security thì có các quan ngại sau:

1. Access trái phép: Hiện tại hệ thống đang phòng chống access trái phép bằng cách chặn IP và dùng gmail nội bộ để hạn chế access –> Nếu bỏ chặn IP và dùng gmail nội bộ để hạn chế access thì với việc hệ thống không có chức năng đăng ký và authenticate người dùng, ai cũng có thể truy cập vào hệ thống.

2. Phân quyền: Hiện tại hệ thống chỉ có 1 account và không cần thiết phải phân quyền –> Nếu có nhiều account thì để đề phòng người dùng tình cờ tạo các sửa đổi không mong muốn, ta sẽ cần chức năng phân quyền.

Ý kiến cá nhân của tôi là như thế sẽ cần phải phát triển chức năng authenticate user và phân quyền.

D3: Cuối cùng xin giới thiệu cấu trúc đề xuất của bản thân tôi cho câu trả lời, theo "chiến lược" quy nạp, và cũng đòi hỏi phải viết lại nhiều nhất 🙂

1. Nêu context

  VD: Hiện tại hệ thống đang chặn các access trái phép và không có tính năng quản lý hay phân quyền người dùng.

2. Từ context mà nhìn thì nếu làm việc X ta sẽ có các vấn đề/ rủi ro sau.

  VD: Nếu mở ra để cho người ngoài công ty cũng có thể access được thì:

  + Sẽ phải bỏ cơ chế chặn access trái phép hiện tại, như thế làm xuất hiện rủi ro có access trái phép

  + Vì không có cơ chế phân quyền, xuất hiện rủi ro bất kỳ ai cũng có toàn quyền thay thao tác trên hệ thống (kể cả những thao tác không mong muốn).

  + Xuất hiện rủi ro người dùng thao tác nhầm và tạo ra các thay đổi không phù hợp với bản thân config của account.

3. Để giải quyết các vấn đề/ rủi ro ở trên ta có các options sau:

  VD: + Tránh access trái phép bằng cách đưa vào cơ chế phòng chống mới (vd. đăng ký và authenticate người dùng).

  + Tránh rủi ro thao tác và tự ý thay đổi config account bằng cách thêm đủ số loại account, phát triển chức năng quản lý quyền hạn truy cập/ thay đổi hệ thống dựa trên các account đó.

4. Kết luận

   VD: Nếu chấp nhận làm các việc ở trên (sẽ tốn effort) thì câu trả là Yes: có thể,

   Nếu không chấp nhận được thì ta cần bàn thêm.

—————————–

Vài ghi chú tham khảo.

+ Dùng văn phong tiếng Nhật chuẩn hơn:

外部の人に使わせる → 外部からのアクセスを許可する

不正アクセスを制限　→ 不正アクセス防止

機能をちゃんと作らない　→ 機能を開発しない

+ Nguyên văn tiếng Nhật một vài phương án cải tiến:

外部からのアクセスを許可することができますが、

現在QMは

　　　＋利用IP制限と社内Gメール制限で不正アクセスを
制限しています。

外部からのアクセスできるために

　　　＋IP制限を全て外します。

セキュリティに関してリスクになる

　　　＋不正アクセス

　　　＋権限付与

セキュリティを強くするために

　　　＋ユーザ認証と権限振り分け機能を開発するのが必要です。
開発時間もかかるはずです。これは宜しいでしょうか。
(Th. san)

【構造】

　・結論（提案）

　・理由（背景＋懸念事項）

結論：IPを公開する場合に、ユーザ認証と権限振り分け機能を
開発する必要があります。

理由：現状、IPと社内Gメールのアクセス制限で不正アクセスを
防止しているため、上記の機能を開発しないと、不正アクセスの
リスクを生じる可能性があります。
(H. san)

技術的に使わせることはできますがセキュリティ面で下記
懸念があります。

①不正アクセス：現状はIP制限と社内メール制限で不正
アクセス防止しています。

→　IP制限と社内メール制限をはずしたら、ユーザー登録と
認証機能がないと、誰でもアクセスできてしまいます。

②権限振り分け：現状は一つのアカウントしかないので、
権限振り分け機能が不要ですが
→　複数アカウントが存在する場合意図外修正を防ぐためには、
権限振り分け機能が必要です。

個人意見では、ユーザー登録と認証機能と権限振り分け機能を
開発する必要があります。
(G. san)

現システムでは不正アクセス防止を掛けている、且つ
権限振り分け・管理なし。というわけで、外部からのアクセス
を許可すると下記の問題が出ます：

-　現在の不正アクセスの仕組みを外しないといけない、
すると不正アクセスのリスクあり

-　権限管理なしなので、誰もが全権限でシステムを操作
できてしまうリスク

-　意図しないアカウントを変更などのミスのリスク

上のリスク対策として以下があるが

- 違う仕組み導入が必要になる（ユーザ認証）

-アカウントを追加し、アカウントベースの権限管理機能を
開発する必要

リスク対応にいずれ工数が掛かってしまうがいかがでしょうか。
（私）