Skip to content

Instantly share code, notes, and snippets.

@kakutani
Created July 16, 2021 13:23
Show Gist options
  • Save kakutani/e8acd046829c11263970a786d7dfabb5 to your computer and use it in GitHub Desktop.
Save kakutani/e8acd046829c11263970a786d7dfabb5 to your computer and use it in GitHub Desktop.
『ユニコーン企業のひみつ』レビューワー向けREADME

🦄 competing-with-unicorns-ja

[build Re:VIEW PDF]

『ユニコーン企業のひみつ - Spotifyで学んだソフトウェアづくりと働き方(仮)』のためのリポジトリです。原書はJonathan Rasmusson著「Competing with Unicorns - How the World’s Best Companies Ship Software and Work Differently」です。 訳書は2021年にオライリー・ジャパンより刊行予定です。

📢 レビューに参加いただく皆さまへ

このリポジトリに来て書名を知ったら、「ああ、なんだSpotifyモデルの話か……」 という印象を持つ方が多少なりともいらっしゃるかもしれません。 今やちょっとググれば巷にはSpotifyモデルの解説があふれています。 レビューワーの皆さまのなかにも「スクワッド」「トライブ」「チャプター」「ギルド」みたいなキーワードをご存知の方もいらっしゃるかと思います(初耳だ、という皆さんはおめでとうございます! 🎉)。

レビューにあたっては一旦、現在お持ちのSpotify Modelに対する印象や予備知識は脇に置いておいていただいて、本書に目を通していただければ幸いです。 エンジニアリング組織のマネジメントモデルというものは「これでどうだバーン!」と打ち立てられてるようなものでは決してなく、Spotify Modelも、Spotify自身がエンジニアリング組織を運営していく試行錯誤のなかで生まれた取り組みのスナップショットなのです。

それではどうぞよろしくお願いいたします。

以下、レビュー参加にあたっての説明文です。かなーり長いですが、ご自身のペースでお目通しくださいませ。

🕵️ 本書の対象読者

  • お仕事でソフトウェアデリバリーに関わっている人すべて(開発者,テスター,デザイナー,マネージャーなどなど)
  • 経営リーダーなど、チームをプロダクトやソフトウェアのデリバリーにフォーカスさせる組織づくりの担当者
  • いわゆるエンタープライズ企業や従来型企業でいわゆるDigital Transformation(DX)に挑戦している方

Q&A on the Book Competing with Unicornsでの著者発言と、本書冒頭の推薦の言葉を参考にしました。

原著のpragprogのサイトでは「前提とする知識: 」となっていますが、それは言いすぎでは…という気持ちです。

👀 レビューワーの"ミッション"

(ミッションは第2章に出てくるので参考にしてください; 今回はミッションコマンド原則ふうに書いています)

⛰️ レビューの目的

  • 想定対象読者の方々にとって、日本語として素直に読める書籍とすべく、出版前に品質を上げたい
  • 訳者たちは何度も繰り返し眺めているあいだに視野が固定されている可能性があるので、外部の視点からフィードバックを得たい
  • 用語や表現などが想定対象読者層にとって、理解できるものであるかを確かめたい
  • 読者が読んでいて引っかかった、理解しづらかった点を明らかにしたい

🎯 レビューによって到達したい状態

  • 想定対象読者の方々にとって、レビュー前よりも一読して内容を把握しやすくなっている(適切な訳注, 用語の使用)
  • レビューワーからは改善案・修正案よりも、どうして引っかかったか、理解しづらかったかを教えてもらえている
  • すべての章に対して、複数人のレビューワーからのフィードバックが得られている

⛓️ レビューにあたっての制約

  • 期間は2021年1月上旬あたりです(12月いっぱい+年始ぐらいを目安にお考えください)
  • 全ページをレビューいただかなくても構いませんが、目安として、5割以上のページには目を通していただいたうえでフィードバックをいただけることを期待しています
  • 想定読者の中心層は英語原書を読まない方がたなので(それはそう)、レビューワーにいわゆる「英語力」は求めません
  • レビュー観点は、翻訳書としての読みやすさです。原著の主張や論旨はレビューの対象外です(フィードバックは直接Jonathan宛でお願いします…)
  • いただいたフィードバックのすべてを反映することはお約束できません(採用されなくても泣かない!)
  • 制約というわけではありませんが、誤字脱字については、レビューワーに指摘してもらいたい関心事の中心ではありません(気づいたらお知らせいただければ幸いです、程度です)
  • 原稿の公開、他者への配布、公表解禁前の書名の公開はできません
  • レビュー御礼の見本誌はオプトイン方式です。期日までにご希望の提供方法(書籍・電子書籍)や送付先(書籍のみ)をお知らせください(別途連絡します)

📝 レビューの進めかた

    1. PDFファイルのスナップショットビルドを入手する
    1. 読んだフィードバックをIssueに起票する
    1. 訳者たちがコメントしたり、フィードバックを反映したりしなかったりします
    • 訳者たちの作業結果をレビューワーが確認してコメントする必要はありません(投げっぱなしでok)

読んだけど特に気になるところはなかったな、という場合でも読書感想文をIssueにフィードバックいただけると、訳者たちの励みになります

以下、順番に解説します。

1. PDFファイルのスナップショットビルドを入手する

ゲラ(PDF形式のみ)はGitHub Actionを用いてコミットごとにビルドされています。最新のゲラは以下から入手可能です。

  • リポジトリのメニューから「Actions」を選択する
  • 最新(あるいは任意)のコミットをクリックする
  • 「Artifacts」にあるPDFをダウンロードする

可能であれば最初から最後までひと通り目を通していただけると嬉しいですが、途中で力尽きて読んだところまででも構いませんし、自分が気になるところだけ拾い読みしていただくかたちでも構いません。 50%以上は目を通したかな…というところを目標にしていただければと思います(100ページぶんぐらい)。

「ダウンロードの方法がよくわからん!」という場合は、このREADMEの最後部にDiscordサーバーへのリンクがありますので、そちらからご相談いただくか、 「なるほどわからん!」みたいなIssueを起票いただければと思います → [issues/newへのリンク]

スナップショットPDFの図の訳文

原稿中の図については、オライリーさんに提出した後に業者の方が作業していただくことになっています。 そのため、ゲラ(PDF)内の図は原書のままです。 図中にでてくる英文の訳は、見出しや図の直後に置く形で表しています。図の文字列も、すべてを訳出するかどうかは 未決定 です。

2. 読んだフィードバックをIssueに起票する

リポジトリのIssueに自由な形式でお知らせください。

[issues/newへのリンク]

こちらからよろしくお願いします!

以下、フィードバックにあたっての訳者たちの期待を簡単に解説します

Issueの起票単位は、好きにしてください

原則: 訳者たちの処理コストよりも、レビューワーのフィードバックしやすさを優先したいと考えています。

よって、やりやすい方法で、どうぞ!

  • 気になった点1つにつき、1つのIssue → OK
  • 章単位で複数の指摘をまとめて、1つのIssue → OK
  • セクション単位で複数の指摘をまとめて、1つのIssue → OK

スタイルが一貫している必要もありません。やりやすいようにやってください。迷ったら、フィードバックしやすいやり方で!

起票単位を小さくしすぎると煩雑になりますし、大きくしすぎるとフィードバックするまでの作業も時間も大きくなると思います。 「多すぎず、少なすぎず。ちょうどいい」大きさと頻度の「ラーゴム」な起票単位は人によって異なると思います。いくつか起票を試しながらいい感じを見つけてもらえればと思います。

Issueにフィードバックする内容

訳者としては 読者が読んでいて引っかかった、理解しづらかった点を明らかにしたい です。 よって、どの箇所で、どうして引っかかったのか、理解しづらかったのかを教えてください。

  • 改善案・修正案は必須ではありません。 もちろん、ありがたく参考にしますが、反映するかどうかは訳者たちが判断します。可能な範囲で構いません

  • 原文との対応の確認も、必須ではありません。 むしろ書籍の読者の大部分はそういうことはしないので、訳者たちはレビューワーの皆さんにも、求めておりません(禁止はしませんが、ご無理のない範囲でお願いします)

  • 表記揺れ、誤字脱字の指摘の優先度は低いです。 こちらも指摘自体は大歓迎ですが、限られた時間と集中力をどこにフォーカスするかという点で、皆さんの判断にお任せいたします(気になるのを止めるつもりはありません!)

  • 原稿のどの箇所に対するフィードバックなのかは、厳密に一意に特定できなくても大丈夫です( PDFの何ページの何行目とかは無くてもOK )

  • ただ、具体的にどこに対する指摘なのかのヒントになる情報はほしいのでご協力ください(「第N章を読みましたが、全体的によくわかりませんでした」だとこちらも困ってしまうので…)

  • レビューしたPDFビルドのバージョン(ファイル名にコミットハッシュが含まれています)をお知らせいただいても構いませんが、お手間にならない範囲で大丈夫です(grep is our friend🔍)

  • 他のレビューワーとの指摘の重複は気にしないで大丈夫です! (たくさん指摘がくれば、ああ、引っかかる人が多いんだな…と訳者たちが気づくことができます)

  • Issueの文体は殺伐調でも問題ありません! 報告にあたって文体は殺伐としたぶっきらぼうなもので構いません。フィードバックのしやすさを優先してください。「お世話になっております/よろしくお願いします」とかは不要です。用件のみでOK! ただ、これは豆知識として…指摘は殺伐としていてもかまわないのですが、もし読みやすかったとか「参考になった」といったところがあれば、そういうフィードバックもたまにいただけると、訳者たちの励みになるので、歓迎します

また、レビューのフィードバックとして特に指摘するところがなかったな…という場合は、読書感想文をIssueに書いていただけると、こちらも訳者たちの励みになります。

3. 訳者たちがコメントしたり、フィードバックを反映したりしなかったりします

  • GitHubから通知が飛んだりはすると思いますが、フィードバックをしたあとに、レビューワーの方に作業をお願いすることはありません。投げっぱなしでokです
  • 不明点などを訳者たちがコメントすることはあると思いますが、それに対して必ず反応をする必要はありません(ウォッチしていただくぶんには大歓迎ですが、ご無理のない範囲で…)

ディレクトリ構成や原稿ファイルについて

ディレクトリ直下にRe::View形式で書かれた原稿が管理されています。構成は [catalog.ymlへのリンク」 を参照ください。

原稿は対訳形式で作業をしています(原書の英文をコメントアウトしてその下に訳を記述しています)。マークアップなども含まれているため、*.re ファイルの原稿テキストだけを直接読んでいくのはちょっと大変かもしれません。ゲラで気になった部分があった場合に、必要に応じて原稿を読んでいただければと思います。

原書のオリジナル原稿も、[リンク] 配下で管理しています。

👾 なにか気になることがございましたら

本書の作業用Discordサーバーがあります [Discordサーバーへのリンク]

#reviewers でお待ちしております 💌

"これはマラソンだ。短距離走じゃない"

レビューワーの皆さまからのフィードバックをお待ちしております。お疲れのでませんように🎽

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment