Vì sao công ty Nhật cần tài liệu thiết kế?
Giải thích lý do công ty Nhật coi trọng tài liệu thiết kế trong dự án IT, từ giảm hiểu sai đến bàn giao, review và bảo trì.
Nội dung được JLPTVN biên tập cho người học tiếng Nhật tại Việt Nam. Với lịch thi, đăng ký và địa điểm thi, hãy kiểm tra thêm nguồn chính thức được dẫn trong bài trước khi quyết định.
Introduction
Nhiều developer Việt Nam khi mới làm dự án Nhật sẽ thấy ngạc nhiên: "Tại sao phải viết nhiều tài liệu thế? Sao không code luôn?" Trong một số team startup, developer trao đổi miệng, mở task, code, test nhanh rồi release. Nhưng trong nhiều công ty Nhật, trước khi code thường cần 設計書, 仕様書, review tài liệu, xác nhận với khách hàng hoặc PM.
Bài này giải thích vì sao tài liệu thiết kế quan trọng trong dự án Nhật. Bạn sẽ hiểu các từ như 設計書, 基本設計, 詳細設計, 画面設計, テーブル設計, レビュー, 承認. Quan trọng hơn, bạn sẽ biết cách đọc và hỏi lại tài liệu để không bị sửa nhiều lần.
Bài viết này dành cho N4前後の学習者. Nghĩa là bạn chưa cần viết tài liệu dài bằng tiếng Nhật ngay. Trước hết, hãy biết tài liệu dùng để làm gì, phần nào cần đọc kỹ, và câu nào dùng khi muốn xác nhận.
Main concept
設計書 là tài liệu thiết kế. Trong dự án Nhật, tài liệu này có vai trò như "hợp đồng hiểu biết" giữa business, PM, BrSE, developer, tester và đôi khi cả khách hàng. Nếu chỉ nói miệng, mỗi người có thể nhớ một kiểu. Khi có tài liệu, team có điểm chung để review và quyết định.
Lý do thứ nhất là giảm 認識違い. Ví dụ khách hàng nói "hiển thị danh sách user", nhưng danh sách đó có cần search không, sort không, phân trang không, quyền admin khác user thường không? Nếu không ghi ra, developer có thể làm theo một cách, tester test theo cách khác, khách hàng mong cách khác.
Lý do thứ hai là bàn giao. Dự án Nhật thường có nhiều bên: công ty khách hàng, SIer, vendor, offshore team. Người viết yêu cầu chưa chắc là người code. Người code hôm nay chưa chắc là người bảo trì sau này. 設計書 giúp người mới hiểu hệ thống nhanh hơn.
Lý do thứ ba là review và traceability. Khi có bug, team có thể kiểm tra: bug do implement sai 詳細設計, do 詳細設計 sai 基本設計, hay do 要件定義 ban đầu thiếu? Cách này nghe nặng, nhưng rất hữu ích trong hệ thống vận hành lâu dài.
Common misunderstanding
1. "Tài liệu chỉ để khách hàng xem"
Không đúng. Developer cũng phải đọc tài liệu. Nếu bạn chỉ chờ ticket nhỏ mà không đọc bối cảnh, bạn dễ sửa đúng dòng code nhưng sai nghiệp vụ.
2. "Tài liệu càng dài càng tốt"
Tài liệu tốt không phải là dài. Tài liệu tốt là rõ: điều kiện, input, output, error, quyền, ngoại lệ, ảnh hưởng. Nếu dài nhưng mơ hồ, vẫn gây lỗi.
3. "Nếu tài liệu đã được approve thì không thể hỏi nữa"
Vẫn có thể hỏi. 承認 không có nghĩa mọi chi tiết đều rõ. Khi implement gặp case chưa ghi, bạn nên hỏi bằng cách chỉ ra phần chưa rõ: "この場合の動作を確認したいです。"
4. "Developer Việt Nam không cần biết 基本設計 và 詳細設計"
Nếu bạn muốn đi xa hơn, đặc biệt là BrSE, bạn cần hiểu hai loại tài liệu này. 基本設計 nói hệ thống làm gì từ góc nhìn user và nghiệp vụ. 詳細設計 nói developer sẽ làm như thế nào ở mức logic, DB, API.
Real project example
Một team nhận yêu cầu thêm chức năng export CSV. PM gửi thiết kế màn hình nhưng chưa ghi encoding file. Developer mặc định xuất UTF-8. Khi khách hàng mở bằng Excel tiếng Nhật, chữ bị lỗi. Tester báo bug.
PM: "CSVの文字コードは何を想定していますか。"
Developer: "UTF-8を想定して実装しました。設計書には記載がありませんでした。"
PM: "日本のお客様はExcelで開くため、Shift_JISが必要です。設計書に追記します。"
Developer: "承知しました。文字コードをShift_JISに変更し、設計書の更新後に再確認します。"
Scene này cho thấy tài liệu không chỉ là thủ tục. Nếu encoding, timezone, format ngày, quyền download không rõ, bug có thể xuất hiện dù code không sai về kỹ thuật.
Useful Japanese phrases
| 日本語 | かな | Nghĩa tiếng Việt | Dùng khi nào | 丁寧度 |
|---|---|---|---|---|
| 設計書を確認しました。 | せっけいしょをかくにんしました | Tôi đã kiểm tra tài liệu thiết kế. | Sau khi đọc tài liệu | Lịch sự |
| 設計書に記載がありません。 | せっけいしょにきさいがありません | Trong tài liệu chưa có ghi. | Khi thiếu thông tin | Lịch sự |
| この項目の仕様を確認したいです。 | このこうもくのしようをかくにんしたいです | Tôi muốn xác nhận spec của mục này. | Khi field chưa rõ | Lịch sự |
| 画面設計を更新します。 | がめんせっけいをこうしんします | Tôi sẽ cập nhật thiết kế màn hình. | Khi sửa tài liệu | Lịch sự |
| 詳細設計に反映します。 | しょうさいせっけいにはんえいします | Tôi sẽ phản ánh vào thiết kế chi tiết. | Sau khi có quyết định | Lịch sự |
| レビューをお願いします。 | れびゅーをおねがいします | Nhờ review. | Khi gửi tài liệu | Lịch sự |
| 指摘内容を修正しました。 | してきないようをしゅうせいしました | Tôi đã sửa nội dung được góp ý. | Sau review | Lịch sự |
| 承認をお願いします。 | しょうにんをおねがいします | Nhờ phê duyệt. | Khi tài liệu đã sẵn sàng | Rất lịch sự |
| 前提条件を確認させてください。 | ぜんていじょうけんをかくにんさせてください | Cho tôi xác nhận điều kiện tiền đề. | Khi logic phụ thuộc điều kiện | Rất lịch sự |
| 変更点を共有します。 | へんこうてんをきょうゆうします | Tôi sẽ chia sẻ điểm thay đổi. | Khi tài liệu đã update | Lịch sự |
Vocabulary
| 日本語 | かな | Nghĩa | 使用例 |
|---|---|---|---|
| 設計書 | せっけいしょ | tài liệu thiết kế | 設計書を読みます。 |
| 基本設計 | きほんせっけい | basic design | 基本設計を確認します。 |
| 詳細設計 | しょうさいせっけい | detailed design | 詳細設計を作成します。 |
| 画面設計 | がめんせっけい | thiết kế màn hình | 画面設計を更新します。 |
| テーブル設計 | てーぶるせっけい | thiết kế DB table | テーブル設計をレビューします。 |
| 記載 | きさい | ghi trong tài liệu | 記載がありません。 |
| 反映 | はんえい | phản ánh, cập nhật vào | 設計に反映します。 |
| 承認 | しょうにん | approve | 承認をお願いします。 |
| 指摘 | してき | comment, góp ý | 指摘を修正します。 |
| 前提条件 | ぜんていじょうけん | điều kiện tiền đề | 前提条件を確認します。 |
| 変更点 | へんこうてん | điểm thay đổi | 変更点を共有します。 |
| 影響 | えいきょう | ảnh hưởng | 影響を確認します。 |
Mini quiz
Câu 1
設計書 trong dự án Nhật dùng để làm gì?
- A. Chỉ để trang trí
- B. Giúp team có cách hiểu chung và review được
- C. Thay cho toàn bộ test
- D. Chỉ dành cho sales
Đáp án: B. 設計書 giúp giảm hiểu sai, hỗ trợ review, bàn giao và bảo trì.
Câu 2
Khi tài liệu chưa ghi rõ một case, nên nói gì?
- A. 設計書に記載がありません。
- B. もう終わりました。
- C. 日本語を勉強します。
- D. 休憩します。
Đáp án: A. Câu này dùng để nói trong tài liệu chưa có ghi thông tin cần thiết.
Câu 3
基本設計 thường gần với nội dung nào hơn?
- A. User và nghiệp vụ cần hệ thống làm gì
- B. Chỉ tên biến trong code
- C. Chỉ setting editor
- D. Lịch nghỉ cá nhân
Đáp án: A. 基本設計 mô tả chức năng từ góc nhìn nghiệp vụ và người dùng.
Next action
Nếu bạn muốn hiểu nền tảng trước khi đọc tài liệu dự án, hãy làm chẩn đoán N5/N4/IT. Sau đó học theo vòng 15 phút, ôn từ vựng N5/N4, ngữ pháp N4 và các mẫu câu spec. Nếu muốn kiểm tra nhanh, làm bài luyện IT. Để học đều trước kỳ thi, dùng checklist 14 ngày.
Đọc tiếp: 基本設計 và 詳細設計 khác nhau thế nào, 仕様書 là gì, và khi không hiểu specification nên hỏi lại thế nào.
FAQ
Công ty Nhật có luôn yêu cầu tài liệu rất chi tiết không?
Không phải mọi công ty đều giống nhau. Nhưng trong hệ thống lớn, có khách hàng doanh nghiệp hoặc có vận hành lâu dài, tài liệu thường được coi trọng hơn.
Developer có cần tự viết 設計書 không?
Tùy vai trò. Developer junior có thể chỉ đọc và sửa một phần. Developer senior hoặc BrSE thường cần viết, review hoặc giải thích tài liệu.
Nếu tài liệu sai thì developer có được góp ý không?
Có. Bạn nên góp ý bằng cách lịch sự, nêu case cụ thể và đề xuất sửa. Ví dụ: "このケースの動作を追記したほうがよいと思います。"
Nên học từ vựng nào trước để đọc thiết kế?
Hãy học 要件, 仕様, 設計, 画面, 項目, 入力, 出力, 表示, エラー, 権限, 確認 trước.
Học tiếp sau bài này
Chuyển từ bài viết sang lộ trình học 15 phút
Nếu bạn chưa rõ nên học N5, N4 hay tiếng Nhật IT trước, hãy làm bài kiểm tra ngắn. Nếu đã sẵn sàng, làm một bài luyện N5 ngắn rồi lưu lỗi sai vào vòng ôn tập.