こんにちは。Garoon 開発チームの臼井です。
この記事では、英語が苦手な PM（プロダクトマネージャー）が英語でバックログを書けるようにするためにチームで支援していることを紹介します。この記事は PHPerKaigi2023 スポンサーセッション サイボウズGaroon開発チームの「完成度低いの歓迎LT大会」（PHPerKaigi出張版） および 【Cybozu Tech Meetup #21】PHPerKaigi 2023 後日談 でお話しした内容に基づいています。
Garoon 開発チームの言語事情と、言語政策（方針）
Garoon 開発チームでは日本とベトナムにそれぞれ開発メンバーがいます。仕様書・試験仕様書・不具合管理システム・バックログなど、ある程度長期間にわたって更新されたり閲覧されたりする文書は、できるだけ共通語として英語を使って書くようにしています。こういった文書を開発メンバーが英語で読みやすくスムーズに書けるように支援するのが私の仕事です。後述するバックログを書きやすくするための施策もその一部です。
一方で、チームには日本語と英語の通訳や翻訳を担当するメンバーがいません。エンジニアの中にも英語が得意だとか自信があるというような人はいないので、なんでもかんでも英語化しようとするとチームにとって負担が大きく、手間に見合った効果が得られない可能性があります。このことから、英語共通語化の範囲は「ある程度長期間にわたって更新されたり閲覧されたりする文書」に限ることにしています。
ちなみに、以前は仕様書などを含む多くの文書で日本語と英語（または日本語とベトナム語）を併記していました。2言語併記には次のような問題があるため、現在ではできるだけやらないようにしています。
- どちらか一方の言語を更新したときに、もう一方の言語への翻訳依頼を忘れがちになる
- 両方の言語を読み比べる人はほとんどいないので、翻訳忘れや誤訳があっても気づきにくい
「英語苦手」はチームの問題、チームで解決する
「英語は各自でがんばって勉強してね」という方式にしないのは、次のような考え方に基づいています。
- 「英語苦手」の影響はチーム全体に及ぶ
- 「英語苦手」の解決を個人に委ねるのは非効率
「英語苦手」の影響はチーム全体に及ぶ
苦手な人が誰からも助けを得られないまま文章を書こうとすればそれだけでも時間がかかります。できあがった文章を読み解くにも時間がかかりますし、書き損じや読み間違いがあれば開発の仕事に手戻りが発生したり、製品の品質が低下したりといった悪影響を及ぼします。
さらに、英語が苦手な人は他の人が書いた英文をコピペで再利用する傾向があるので、読みにくい文章を放っておけば同じように読みにくい文章が増えていく悪循環に陥ります。
「英語苦手」の解決を個人に委ねるのは非効率
義務教育で英語を習って、仕事でも英語を使う機会があるのに英語が苦手になってしまうのは、自分に合った継続可能な練習方法に出会えなかったことが一因であると考えられます。練習方法がない人にただ「練習してね」というだけでは（今まで解決しなかったのだから）解決する見込みは薄いでしょう。学習習慣をつけて自力で練習し続けることができるようにチームとして支援したほうが、総合的に見て効率がよいはずです。その人が英語でスムーズにコミュニケーションできるようになることがチームにとってよい影響をもたらすのであればなおさら。
また、英語を練習して正面から苦手を克服するだけでなく、他の人を頼れるようにすること、テンプレートなどの仕組みを利用して自分で英文を考えなくて済むようにすることもチームで問題を解決するための取り組みの一面です。
TOEIC 315点のPMが英語でバックログを書けるようにするためにやったこと、やっていること
英コ（英語個人練習）
「英コ」は「英語個人練習」の略です。その名の通り、PMと1対1での英語練習を月に数回、1回につき30分程度の時間を確保してやっています。
英コでは、PMがこれから書こうとしているバックログのネタや、悩んでうまく書けずにいるバックログを題材として、モブ形式で英語の文章に落とし込んでいきます。開発と英語の両方の知識を持つメンバー（私）がナビ役を担当しています。日英翻訳ではなく英語の作文（および作文のスキル向上）が趣旨なので、次のような点に気を付けています。
意図を明確にする。日本語で書いた文章を英語に置き換えていくのではなく、伝えたい内容に注意を向ける必要があります。まずPBIで伝えたいことをPMに口頭で説明してもらい、それを英語でどのように表現すればいいかを一緒に考えていきます。
英語として読みやすい文章構成にする。日本語の発想で「背景情報が先、話の核心は最後」という構成になりがちですが、これをそのまま英語に置き換えると非常に読みにくいです。大事なことから先に述べる構成を推奨しています。
シンプルに表現する。Garoon 開発チームではPBIを読む人も英語母語話者ではないので、シンプルでやさしい英文を書くことが求められます。母語として使いこなせる日本語で先に考え始めてしまうとどうしても複雑な構文や高度な語彙を無意識に使ってしまいがちなので、ここでも「日本語から訳さない」という方式が重要です。学校の英語の授業でも序盤で出てくるような頻出単語を使う、あまりたくさんのことを一度に言おうとしないようにする（一文一義）といった点に注意しています。
PMからのコメント
「いつか役立つ英語ではなく、すぐ役立つ英語が学べるのでモチベーションが高く取り組めますし、成長も実感できるのがとてもいいです。」
PBIや要件のタイトルのガイドラインを作る
PBI（プロダクトバックログアイテム）や要件には、その内容を手短に要約したタイトルをつけることになっています。このタイトルを英語でわかりやすく書けるようにするための推奨事項を例文付きでまとめたものが「PBIや要件のタイトルのガイドライン」です。
推奨事項の一例として「命令文を使う」というものがあります。これは「そのPBIの目的は何か、要するに何をすればいいのか」を明確にする効果を意図したものです。
この推奨事項を作る前は、次のように一見しただけでは目的が読み取れないPBIのタイトルが作られることがありました。
- Maintenance of the command line tools （訳：「コマンドラインツールのメンテナンス」) →メンテナンスをどうするのか？
- Push notifications can be sent to the mobile app （訳：「プッシュ通知がモバイルアプリに送信できる」) →現在の事実として「送信できる」と言っているのか、あるいは「これから送信できるようにする」ということなのか？
- The error message for the error code 00123 is not easy to understand （訳：「エラーコード00123のエラーメッセージがわかりにくい」） →「わかりにくい」のはいいとして、それについて何をするのか？）
命令文で「○○をせよ」と明示することによって、タイトルを見るだけでPBIの目的を把握しやすくなります。
- Maintain the command line tools
- Enable the user to send push notifications to the mobile app
- Make the error message for the error code 00123 easier to understand
ユーザーストーリーのテンプレートを見直す
Garoonの新機能や仕様変更を扱うPBIでは、その新機能や仕様変更の背景を説明する「ユーザーストーリー」を記載します。このユーザーストーリーのテンプレートを、英語が苦手なPMにも書きやすいように変更しました。
以前使用していたユーザーストーリーのテンプレートは、次のようなものでした。
As a < type of user >, I want < some goal > so that < some reason >.
このテンプレートでは、「誰（どのような属性の人）が」「何を」「なぜ」必要としているのかを1文で書くようになっています。これを使ってユーザーストーリーを書くと、例えば次のようになります。
As a user of the Report application, I want to reuse reports that I wrote in the past so that I don’t have to search and find who to share my report with every time I write one.
この「1文で書く」というところがポイントです。1文で書くということはそれだけ多くの内容を密に結合させるということなので、構文を使いこなす知識や表現力、前後関係や一貫性に気を配る能力などが求められ、難易度が上がります。もちろんテンプレートがこうだからと言って2つ以上の文を書いてはいけないということはないのですが、英語が苦手な人にとってはまず英語で書くだけでも精一杯、テンプレートに従うだけでも精一杯で、内容に応じて文を分けることまで気が回らないこともしばしば。「今回の内容は1文にまとめるのは難しいから分割して、表現を変えよう」などと思いつくこと自体、それなりの英語スキルが必要になるわけです。
このようにして作られたユーザーストーリーは誤記や誤解を招く表現が含まれることも多く、書き手だけでなく読み手にとっても業務のスピードを低下させる一因となっていました。
そこで、新しいテンプレートでは「誰が」「何を」「なぜ」という3つの要素をそれぞれ1つずつの質問形式にしました。
[What is your role?]
[What do you want?]
[Why do you want it?]
このテンプレートでは始めから書く内容を分割するという頭で書き始めるので、1文あたりの内容の密度が小さくなり、考えることを減らせます。これによってユーザーストーリーを単純な構文で表現しやすくなりました。
[What is your role?]
I am a user of the Report application.
[What do you want?]
I want to reuse my old reports.
[Why do you want it?]
I don’t want to search and find who to share my reports with. It’s a hassle.
逃げ道を用意する
英文を書きやすくするための施策がどれだけあっても、やはりうまく書けなくて悩んでしまう、気分が乗らない、忙しくてできないというような日もあります。自力で困難を乗り越えれば力にはなるのですが、そうは言っても本来の目的は読みやすいPBIを書くことなので、「いつでも全部自力でがんばる必要はない」とPMには伝えています。状況に応じて、私から文章構成や表現の案を提示したり、まるごと英訳を引き受けたりすることもあります。
誤訳や誤解を招きそうな記述があったら直す
誤訳や誤記を完全に防ぐことは難しいです。このため、PMが登録したPBIには私がなるべく目を通すようにしています。そこで問題が見つかれば修正を加えるとともに、どこを直したのか、なぜ直したのかをPMにフィードバックしています。
最後に
今回の記事では、英語が苦手なPMが英語でバックログを書けるようにするための取り組みをご紹介しました。英語苦手問題について「チームの問題としてチームで解決する」という考え方に共感してくれる人が増えてくれればと期待するとともに、すでにチームで問題に取り組んでいる人の参考になれば幸いです。
