This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
Freelance translator and/or interpreter, Verified site user
Data security
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
Affiliations
This person is not affiliated with any business or Blue Board record at ProZ.com.
Open to considering volunteer work for registered non-profit organizations
Rates
English to Japanese - Rates: 0.50 - 0.80 USD per word / 16 - 18 USD per hour
All accepted currencies
U. S. dollars (usd)
Project History
0 projects entered
Payment methods accepted
Visa, PayPal
Portfolio
Sample translations submitted: 2
English to Japanese: Bestselling Book on Japanese Startups Released in English General field: Marketing Detailed field: Business/Commerce (general)
Source text - English Bestselling Book on Japanese Startups Released in English
TOKYO, Japan (October 23, 2015) — “The Quiet Comeback – 20 Startup Founders Leading Japan’s Next Tech Boom,” the bestselling Japanese book about Tokyo’s rapidly expanding startup scene, is now available in English for the first time. The Japanese version of the book,「未来をつくる起業家」(Mirai wo tsukuru kigyouka), became a surprise hit when it was released in Tokyo in early 2015, climbing to the top of Amazon Japan’s e-book bestseller list.
Says author Casey Wahl, CEO of Wahl & Case: “As both a participant and an interested bystander, I’ve witnessed the Japanese startup sector grow at an incredible rate over the past five years. My goal with this book was to get some of the leading figures from this dynamic but often secretive scene to share their stories and practical tips on how to launch a successful tech company from Tokyo. The overwhelmingly positive response to the Japanese edition was vindicating, in that it proved that the trends I had observed — and was trying to help fuel by making this info available to aspiring young founders — were very much underway.”
“The Quiet Comeback” features in-depth interviews with the visionary founders behind 20 of Japan’s most successful startups — a diverse cast of entrepreneurs who are challenging the status quo of corporate Japan, setting the stage for the resurgence of the country’s once great tech industry.
These wide-ranging stories from the font lines of Tokyo’s venture scene offer an inside view of how successful startups are built within Japan’s unique culture and business environment. Peppered with practical tips and market insights, the conversations also offer a broad snapshot of the Tokyo tech world today, with interviewees including: Joi Ito and Kaoru Hayashi of Digital Garage, who together brought the Internet to Japan; female entrepreneurs overturning the stereotypes of corporate Tokyo; high school dropouts turned maverick CEOs; a 21-year-old business leader bent on disrupting old industries; and the rare, elite salarymen who were able to cast aside the conservatism of their background and leap headlong into the startup game — and make a fortune in the process.
In their own words, founders share the struggles and strategies that went into their companies. How do you find funding — or investment targets — in Tokyo? How do Japanese tech founders differ from their Silicon Valley counterparts? What does it take to build a service that can thrive in both the Japanese and global marketplace? Where is the Japanese internet lagging behind or leaping ahead of the rest of the world?
For those interested in creating a startup connected to Japan, or anyone curious about the multi-layered questions of Japanese business psychology, this book is the closest you can come to sitting in the same room with the brightest minds in the Tokyo tech scene today.
“The Quiet Comeback” will be available exclusively on Amazon in both print and Kindle versions.
About the Author
Casey Wahl was born in upstate New York, but spent his childhood in the Saudi Arabian deserts. He returned to the United States to attend high school in the Boston area, before pursuing a degree in Japanese and Government as part of a special honors program at the University of Texas. Soon after graduation, he moved to Japan, later earning an Executive MBA from the Instituto de Empresa (IE) in Madrid. Casey has lived and worked in Tokyo for the past 15 years. He is the founder and CEO of two companies: Wahl & Case and Red Brick Ventures. Wahl & Case is an executive recruitment firm with offices in Tokyo, San Francisco and Berlin. Approaching two decades in the industry, Casey remains highly passionate about recruitment. He intends to disrupt and advance the field, while elevating Wahl & Case to a world-class player in its sector. Red Brick Ventures is an angel investment and incubation firm based in Tokyo, committed to making Japan’s resurgent startup ecosystem more vibrant and conducive to international collaboration.
Issued by Wahl & Case
Translation - Japanese 日本における起業をテーマとしたベストセラー書籍の英語版が出版される
Wahl & Case
東京、サンフランシスコ、ベルリンにオフィスを構えるエグゼクティブ人材紹介会社。創業者ケイシー・ウォール氏は、その業界に携わって２０年近くになるが、現在も非常に強い熱意を持って人材発掘に取り組んでいる。彼はWahl & Caseがその分野におけるワールドクラスの企業に成長することを標榜し、努力と奮闘を続けている。
Red Brick Ventures
東京に本社を置く、エンジェル投資や起業支援を事業とする会社。日本のスタートアップ事業を活性化させ、さらにその国際的な協力関係のサポートをする。
Wahl & Case
English to Japanese: What Should I Know about Writing an SRS? General field: Tech/Engineering Detailed field: Computers: Software
Source text - English What Should I Know about Writing an SRS?
Unlike formal language that allows developers and designers some latitude, the natural language of software requirements specifications must be exact, without ambiguity, and precise because the design specification, statement of work, and other project documents are what drive the development of the final product. That final product must be tested and validated against the design and original requirements. Specification language that allows for interpretation of key requirements will not yield a satisfactory final product and will likely lead to cost overruns, extended schedules, and missed deliverable deadlines.
Table 4 shows the fundamental characteristics of a quality SRS, which were originally presented at the April 1998 Software Technology Conference presentation “Doing Requirements Right the First Time.” Reprinted with permission from the Software Assurance Technology Center at NASA (http://www.gsfc.nasa.gov/). These quality characteristics are closely tied to what are referred to as “indicators of strength and weakness,” which will be defined next.
Table 4 The 10 language quality characteristics of an SRS
SRS Quality Characteristic What It Means
Complete SRS defines precisely all the go-live situations that will be encountered and the system’s capability to successfully address them.
Consistent SRS capability functions and performance levels are compatible, and the required quality features (security, reliability, etc.) do not negate those capability functions. For example, the only electric hedge trimmer that is safe is one that is stored in a box and not connected to any electrical cords or outlets.
Accurate SRS precisely defines the system’s capability in a real-world environment, as well as how it interfaces and interacts with it. This aspect of requirements is a significant problem area for many SRSs.
Modifiable The logical, hierarchical structure of the SRS should facilitate any necessary modifications (grouping related issues together and separating them from unrelated issues makes the SRS easier to modify).
Ranked Individual requirements of an SRS are hierarchically arranged according to stability, security, perceived ease/difficulty of implementation, or other parameter that helps in the design of that and subsequent documents.
Testable An SRS must be stated in such a manner that unambiguous assessment criteria (pass/fail or some quantitative measure) can be derived from the SRS itself.
Traceable Each requirement in an SRS must be uniquely identified to a source (use case, government requirement, industry standard, etc.)
Unambiguous SRS must contain requirements statements that can be interpreted in one way only. This is another area that creates significant problems for SRS development because of the use of natural language.
Valid A valid SRS is one in which all parties and project participants can understand, analyze, accept, or approve it. This is one of the main reasons SRSs are written using natural language.
Verifiable A verifiable SRS is consistent from one level of abstraction to another. Most attributes of a specification are subjective and a conclusive assessment of quality requires a technical review by domain experts. Using indicators of strength and weakness provide some evidence that preferred attributes are or are not present.
What makes an SRS “good?” How do we know when we’ve written a “quality” specification? The most obvious answer is that a quality specification is one that fully addresses all the customer requirements for a particular product or system. That’s part of the answer. While many quality attributes of an SRS are subjective, we do need indicators or measures that provide a sense of how strong or weak the language is in an SRS. A “strong” SRS is one in which the requirements are tightly, unambiguously, and precisely defined in such a way that leaves no other interpretation or meaning to any individual requirement.
The Goddard Space Flight Center (GSFC) studied dozens of NASA requirements specifications that revealed nine categories of SRS quality indicators. The individual components in each category are words, phrases, and sentence structures that are related to quality attributes. The nine categories fall into two classes: those related to individual specification statements, and those related to the total SRS document. Table 5 summarizes the classes, categories, and components of these quality indicators. This table was also originally presented at the April 1998 Software Technology Conference presentation “Doing Requirements Right the First Time.” Reprinted with permission from the Software Assurance Technology Center at NASA (http://www.gsfc.nasa.gov/).
Table 5 Quality measures related to individual SRS statements
Imperatives: Words and phrases that command the presence of some feature, function, or deliverable. They are listed below in decreasing order of strength.
Shall Used to dictate the provision of a functional capability.
Must or must not Most often used to establish performance requirement or constraints.
Is required to Used as an imperative in SRS statements when written in passive voice.
Are applicable Used to include, by reference, standards, or other documentation as an addition to the requirement being specified.
Responsible for Used as an imperative in SRSs that are written for systems with pre-defined architectures.
Will Used to cite things that the operational or development environment will provide to the working capacity being specified. For example, The vehicle’s exhaust system will power the ABC widget.
Should Not used often as an imperative in SRS statements; however, when used, the SRS statement always reads weak. Avoid using Should in your SRSs.
Continuances: Phrases that follow an imperative and introduce the specification of requirements at a lower level. There is a correlation with the frequency of use of continuances and SRS organization and structure, up to a point. Excessive use of continuances often indicates a very complex, detailed SRS. The continuancesbelow are listed in decreasing order of use within NASA SRSs. Use continuancesin your SRSs, but balance the frequency with the appropriate level of detail called for in the SRS.1. Below:2. As follows:3. Following:4. Listed:5. In particular:6. Support:
Directives: Categories of words and phrases that indicate illustrative information within the SRS. A high ratio of total number of directives to total text line count appears to correlate with how precisely requirements are specified within the SRS. The directives below are listed in decreasing order of occurrence within NASA SRSs. Incorporate the use of directivesin your SRSs.1. Figure2. Table3. For example4. Note
Options: A category of words that provide latitude in satisfying the SRS statements that contain them. This category of words loosens the SRS, reduces the client’s control over the final product, and allows for possible cost and schedule risks. You should avoid using them in your SRS. The optionsbelow are listed in the order they are found most often in NASA SRSs.1. Can2. May3. Optionally
Weak phrases: A category of clauses that can create uncertainty and multiple/subjective interpretation. The total number of weak phrases found in an SRS indicates the relative ambiguity and incompleteness of an SRS. The weak phrases below are listed alphabetically.
adequate be able to easy provide for
as a minimum be capable of effective Timely
as applicable but not limited to if possible Tbd
as appropriate capability of if practical
at a minimum capability to normal
Size: Used to indicate the sizeof the SRS document, and is the total number of the following:1. Lines of text2. Number of imperatives3. Subjects of SRS statements4. Paragraphs
Text Structure: Related to the number of statement identifiers found at each hierarchical level of the SRS and indicate the document’s organization, consistency, and level of detail. The most detailed NASA SRSs were nine levels deep. High-level SRSs were rarely more than four levels deep. SRSs deemed well organized and a consistent level of detail had text structures resembling pyramids (few level 1 headings but each lower level having more numbered statements than the level above it). Hour-glass-shaped text structures (many level 1 headings, few a mid-levels, and many at lower levels) usually contain a greater amount of introductory and administrative information. Diamond-shaped text structures (pyramid shape followed by decreasing statement counts at levels below the pyramid) indicated that subjects introduced at higher levels were addressed at various levels of detail.
Specification Depth: The number of imperatives found at each of the SRS levels of text structure. These numbers include the count of lower level list items that are introduced at a higher level by an imperative and followed by a continuance. The numbers provide some insight into how much of the Requirements document was included in the SRS, and can indicate how concise the SRS is in specifying the requirements.
Readability Statistics: Measurements of how easily an adult can read and understand the requirements document. Four readability statistics are used (calculated by Microsoft Word). While readability statistics provide a relative quantitative measure, don’t sacrifice sufficient technical depth in your SRS for a number.1. Flesch Reading Ease index2. Flesch-Kincaid Grade Level index3. Coleman-Liau Grade Level index4. Bormuth Grade Level index
Translation - Japanese ＳＲＳ（ソフトウェア要求仕様書）作成において知るべきこと
開発者や設計者の形式言語にある程度の自由が認められているのとは異なり、自然言語を用いて作成されるＳＲＳ（ソフトウェア要求仕様書）は、あいまいさを極力排除した高い正確性が要求されます。なぜなら設計仕様書や作業範囲記述書などは、製品の開発進行を指示するものだからです。また完成した製品は、初めに意図された設計と要求に対し、テストを行い、動作確認することが必要不可欠です。また、重要な要求において異なる解釈を許してしまうような仕様記述は、最終製品が満足のいかない出来になったり、コスト超過、スケジュール超過、さらには最終締め切りに間に合わなくなるといった事態を引き起こします。
表４にＳＲＳの基本的な特性が示されています。この表は元々、１９９８年の４月に開かれたソフトウェア技術会議において“初めに、要求を正しく行うこと”というテーマのプレゼンテーションで紹介されたものです。資料の再印刷については、ＮＡＳＡのソフトウェアアシュアランス技術センターより了承を得ています(http://www.gsfc.nasa.gov/)。それらの品質特性は、次に定義された“強弱の指標”に密接に関係しています。
表４ ＳＲＳの１０の言い回しで表現される品質特性
ＳＲＳ品質特性 What It Means
[完全であること]
[完全性] SRS defines precisely all the go-live situations that will be encountered and the system’s capability to successfully address them.
[矛盾がないこと]
[整合性] SRS capability functions and performance levels are compatible, and the required quality features (security, reliability, etc.) do not negate those capability functions. For example, the only electric hedge trimmer that is safe is one that is stored in a box and not connected to any electrical cords or outlets.
[正確であること]
[正確性] SRS precisely defines the system’s capability in a real-world environment, as well as how it interfaces and interacts with it. This aspect of requirements is a significant problem area for many SRSs.
[変更可能であること]
[可変性] The logical, hierarchical structure of the SRS should facilitate any necessary modifications (grouping related issues together and separating them from unrelated issues makes the SRS easier to modify).
[ランク付けがなされていること]
[階層性] Individual requirements of an SRS are hierarchically arranged according to stability, security, perceived ease/difficulty of implementation, or other parameter that helps in the design of that and subsequent documents.
[テストが容易であること]
[試験の容易性] An SRS must be stated in such a manner that unambiguous assessment criteria (pass/fail or some quantitative measure) can be derived from the SRS itself.
[追跡可能であること]
[追跡可能性] Each requirement in an SRS must be uniquely identified to a source (use case, government requirement, industry standard, etc.)
[あいまいさがないこと]
[明確性] SRS must contain requirements statements that can be interpreted in one way only. This is another area that creates significant problems for SRS development because of the use of natural language.
[妥当性の確認]
[妥当性] A valid SRS is one in which all parties and project participants can understand, analyze, accept, or approve it. This is one of the main reasons SRSs are written using natural language.
[検証可能であること]
[検証可能性] A verifiable SRS is consistent from one level of abstraction to another. Most attributes of a specification are subjective and a conclusive assessment of quality requires a technical review by domain experts. Using indicators of strength and weakness provide some evidence that preferred attributes are or are not present.
What makes an SRS “good?” How do we know when we’ve written a “quality” specification? The most obvious answer is that a quality specification is one that fully addresses all the customer requirements for a particular product or system. That’s part of the answer. While many quality attributes of an SRS are subjective, we do need indicators or measures that provide a sense of how strong or weak the language is in an SRS. “強い”ＳＲＳとは、要求が固定的で、あいまいさがなく、かつ正確に定義され、異なった解釈や、別の意味と勘違いされる恐れがないものを言います。
ゴダード宇宙飛行センターは、数多くのＮＡＳＡの要求仕様書から、９つのカテゴリーに及ぶ品質指標を明らかにしました。個々のカテゴリーの単語やフレーズは、そうした品質特性に関係しています。それら９つのカテゴリーは、個々の仕様記述に関連するものか、ＳＲＳ文書全体に関連するものの、２種類に分類することができます。表５には２種類のクラス、９つのカテゴリー、そしてそれらの品質指標に関する要約が示してあります。
This table was also originally presented at the April 1998 Software Technology Conference presentation “Doing Requirements Right the First Time.” Reprinted with permission from the Software Assurance Technology Center at NASA (http://www.gsfc.nasa.gov/).
表５ 個々のＳＲＳ記述に関する品質指標
命令[文][語] : 何らかの特徴、機能、または成果物の有無を命令する単語またはフレーズ。それぞれ命令度の強い順に下記のリスト上に示しています。
Shall 機能の提供を記述する際に使用されます。
Must or must not ほとんどの場合、パフォーマンスの要求もしくは制約を示すために使用されます。
Is required to ＳＲＳの記述内で、受動態の命令[文][語]として使用されます。
Are applicable [参照][リファレンス]、規格、またはその他の文書に含まれる形で、要求の追加記述として使用されます。
Responsible for ＳＲＳ内の、定義が構築される前のシステムの記述で、命令[文][語]として使用されます。
Will 運用、開発環境が供給する機能を、引用する際に使用されます。例えば、ＡＢＣ装置に動力を供給する排気システムなどです。
Should ＳＲＳの記述に命令[文][語]として使用されることはあまりありません。使用される際には、常に命令度の弱いものとして解釈します。そのため、この単語をＳＲＳの記述に使用することは避けましょう。
継続[文][語]：命令[文][語]に次ぐフレーズ群で、低い階層の要求記述に使用されます。継続[文][語]の使用頻度とＳＲＳの組織構造には、一定の相関関係があります。継続[文][語]の過度の使用は、SRS記述が複雑化する原因となります。継続[文][語]は、NASAのSRSで以下の順で使用されています。ＳＲＳ内の継続[文][語]は、適切な階層で、頻度のバランスを考えて使用してください。
1. Below（以下に）
2. As follows（以下の通り）
3. Following（以下の）
4. Listed（記載された）
5. In particular（特に、具体的には）
6. Support（補助）
指示語：SRS内の説明的な情報を示す単語やフレーズのこと。テキスト全体における指示語の比率は、SRS内の要求の正確性と相関性があります。以下の指示語が、NASAのSRS内で使用されています。
1. Figure（図）
2. Table（表）
3. For example（例）
4. Note（注）
選択[文][語]： SRS記述に自由度を与える単語。このカテゴリーの単語は、SRSの命令度を緩め、クライアントの完成品に対する管理権を低減し、それと同時にコストとスケジュールに関するリスクを高めます。よって、SRS作成時にそれらの単語を使用することは避けた方がいいでしょう。以下にNASAのSRSにおいて、使用された頻度の順に並べてあります。
1. Can(～できる)
2. May(～かもしれない)
3. Optionally（任意に）
“弱い”フレーズ：確実性に欠け、複数あるいは主観的解釈が可能なフレーズ。SRSで見つかる“弱い”フレーズの総数は、そのSRSのあいまいさや不備を示しています。以下に“弱い”フレーズをアルファベット順に並べてあります。
adequate be able to Easy provide for
as a minimum be capable of Effective Timely
as applicable but not limited to if possible Tbd
as appropriate capability of if practical
at a minimum capability to Normal
サイズ：SRS文書の量を示すために使用します。そのフレーズは次の通りです。
1. Lines of text（テキストの行数）
2. Number of imperatives（命令[文][語]の数）
3. Subjects of SRS statements（ＳＲＳ内の[見出し][テーマ]の数）
4. Paragraphs（段落数）
テキスト構造：SRSの各階層中の識別子の数、文書の構造、整合性、記述の詳細に関連しています。最も深い構造のNASAのSRSは９階層に及び、5階層以上のＳＲＳは滅多にありませんでした。
上手に構成されているSRSは、ピラミッドに似たテキスト構造を持ちます。（いくつかの[見出し][テーマ]を持ち、低い階層により多くの記述を持つようなテキスト構造）
砂時計形のテキスト構造（[見出し][テーマ]が多く、中間階層の記述は少なく、低い階層の記述は多い）は通常、導入記述および管理情報記述を多く含みます。
ダイヤモンド型のテキスト構造（ピラミッド型に似た形状だが、低階層の記述量は少ない）は高い階層で導入されたテーマが、さまざまな階層で詳述されたことを示しています。
仕様書の深度：SRS各階層のテキスト中にある命令[文][語]の数。これは、高階層の命令[文][語]や継続[文][語]からつながっている、低階層のリスト項目の数を含みます。その数は、SRSにどのくらいの要求文書が含まれていたかについての考察を提供し、また、SRSの個々の要求がどれくらい簡潔に示されているかを知ることができます。
可読性の統計：一般的な成人が読んで、その要求文書が容易に理解可能かどうかを示し、主に４種類（マイクロソフトワードより算出）の統計が使用されています。可読性の統計はある程度の目安にはなりますが、それにこだわってSRS記述の技術的な深度を損なうことのないよう注意してください。
1. Flesch Reading Ease index
2. Flesch-Kincaid Grade Level index
3. Coleman-Liau Grade Level index
4. Bormuth Grade Level index
More
Less
Experience
Years of experience: 9. Registered at ProZ.com: Jul 2015.
I'm Shinya Tahara, an English-Japanese translator with over 5 years of experience.
I translate various type of files such as IT, marketing, industry, advertisement, mobile apps, video games, educational contents, etc...especially IT is my field of expertise since I had worked as a professional computer programmer in the past.
Please feel free to contact me anytime. I'm looking forward to your offer.
Expertise