Skip to main content

ソフトウェア開発の「基本設計」の英訳は、Basic Design ではありません。


私の勤める会社は、SIer (エス・アイヤー、Solution Integrator)なのですが、大規模ソフトウェア開発を行う際に、ソフトウェア開発の設計工程の呼び方として、概要設計、基本設計、詳細設計と呼んでいます。概要設計は、簡単に言えば大体の設計ですが、お客様にわかる言葉で書く。アメリカでは、High Level Design と呼ばれるものに相当します。基本設計は、ネット上では、Basic Design と訳されていますが、これは、和製英語の直訳です。英語圏には、Basic Designと言う言葉はありません。

基本設計に対しては、Functional Design (プログラムが何をするべきなのかを記述する)が一番近い言葉です。語感的に、Detailed Design とか、Low Level Design とか言われますが、英語自体が曖昧です。

詳細設計は、Technical Design(機能が、コードレベルでどのように実装されるかを記述する) と言うのがいいでしょう。

この概要設計、基本設計、詳細設計というカテゴリー分けは、IBMからではないと言うことはわかったので、恐らく、NEC、富士通、野村総研のどこかが言い出した言葉なのでしょう。

Comments

  1. あるアメリカ人(ソフトウェア産業で生きてきた50歳くらいの人)に対して、「君は、Basic Design という言葉を、自分の今までの経験の中で、使ったことがあるか?」と聞くと、「ある。」と答えた。でも、その時の彼の感覚は、Basic Design Document というドキュメントではなく、Basic Designというフェーズをイメージしている。Basic Design フェーズとは、要件をビジネス・デザインに変換するフェーズのことでであると言う。
    それは、要件定義のフェーズから、設計フェーズへの移行の部分を指している。

    そして、ここからが英語の肝ですが、デザインと言うものは、ビジネス寄りのハイレベルなものから、詳しいデザインへ落ちていく過程の中で、Basic Design という言葉のニュアンスは、基本的(Basic)な部分を設計(Design)することであり、基本設計書と言う書物をイメージはしていない。

    設計の中の基本的な部位をイメージしている。Basic とDesign がびしっとつながっているわけではなく、単なる形容詞として、Basic を使っているだけだという事です。
    なので、いくらネットで調べても、Basic と Design がくっついて用語となっている例は、見つからないわけです。

    ReplyDelete
  2. 監査などで基本設計や詳細設計の有無を聞かれるのだけど、海外ではRequirement SpecとFunctional Specとなるので、どのように対応させるのかがしっくり来ません。海外に迎合するわけではありませんが、たとえば基本『設計』は何を設計しているのかさっぱりわからない(業務設計なのかI/F設計なのかデータベース設計なのか)ので、Spec(仕様書)のほうがしっくりきます。

    ReplyDelete

Post a Comment

Popular posts from this blog

プロジェクトのステアリング・コミッティーって、本来何なんだ?

日本の企業の多くの会社が、何らかの「プロジェクト」と呼ばれる活動を行っている。そして、プロジェクトを支える会議の一つとして、ステアリング・コミッティーという名前の会議を作る。 純日本風の会社は、だいたいその言葉を縮め「ステコミ」と呼ぶ会社も多い。(ちょっと、気持ち悪い響き) (ここでは、アメリカのプロジェクト・マネージメントの話をする。どう考えても、それが世界の標準となっているからです。でも、日本では、その標準が、自社に使えるように、いいとこどり、つまみぐいされるから、本物のプロジェクト・マネージメントが持つパワーを享受できない場合が多いような気がします。) ステアリング・コミッティーというのは、何をする会議だと思いますか?大体の日本人は、カタカナの言葉が、ピンとこないから、その会議に参加してみて、自分の経験をもとに、会議の目的を類推して、認識する。 「あぁ~、これは、プロジェクトのメンバーが、何かを報告しているな。つまり、現在のステータス(状態)のチェックだな。」 いいえ、それは、プロジェクト・ステータス・ミーティング(プロジェクト進捗確認ミーティング)の役割です。 プロジェクト・ステータス・ミーティングだったら、その会議を持つ責任者(ミーティング・オーナー)は、プロジェクト・スポンサー(プロジェクト・オーナーまたは、プロジェクト責任者)がやる。 発表は、プロジェクト・マネージャー、もしくは、複数プロジェクトをマネージするプログラム・マネジャーが行います。プロジェクト・マネージャーが、わからない部分に関しては、テクニカル・リーダー、テスト・マネージャーなどが同行し説明します。 ステアリング・コミッティーとは、コロンブスの西インド諸島発見の船旅で喩えると、大きな船の進行方法を左右に変えるために舵(かじ)がある。「舵を取れー」と映画で出てくるあの舵です。その舵を切る動作を、操舵(そうだ)と言いますが、操舵がステア( Steer )です。今、操舵しているのであれば、現在進行形にして、ステアリングとなります。 マストの上には、見張り番が常に望遠鏡で前方、まわりを監視し、何かが起こりそうになると、「それを通知します。」 例えば、前方の氷山が見えるのであれば、舵をどちらかの方向

日米のスケジュールの作り方の違い

昨日、面白いことがありました。 Microsoft Project というプロジェクト・マネージメント(スケジュールをマネージする)のツールが昔からあるんだけど、日本人とアメリカ人とで、視点がまったく違っていることがわかったんです。 日本人が、スケジュールを書くと、「これやって、それから、あれやって。」とやること(タスク)を書いていく。それに対して、アメリカのプロジェクト・マネージャーが不満を言う。「成果物がいつできるのかわからない。」 わかりますか?この違い。 アメリカ人の場合、「これを作って、あれを作って」という、成果物に主眼を置いてプロジェクトを組み立てるんです。「この設計書を作って、それからこのドキュメントを作って、…」という作り物が頭に、先にあるんです。お客様との契約でも、「納品物は、これとこれです。」と言う言い方をします。つまり、ゴールは、納品物を作っていくことなんです。 日本人は、プロセス( How )を重視して、スケジュールを決めますが、アメリカ人は、ゴール( What )を重視してスケジュールを作ります。 こういう視点の差が、実は、仕事の仕方の根本を変えています。 どちらが悪いのかいいのかと言うよりも、この考え方の差で、計画の作り方がまったく違ってくるし、日本人とアメリカ人の間で、大きな意見の食い違いが発生する。 何故かと言うと、お互いに自分たちのやり方が正しいやりかただと信じているからです。 ずーっと平行線をたどります。 なので、昨日は、 4 時間かけて、この話を調整し、お互いに欲しいものは何なのか?それをどう表現すればいいのかを、日本のソフトウェア・エンジニアとアメリカのプロジェクト・マネージャーを入れて、すり合わせました。この違いをはたから見てわかっている第三者が調整しないと、平行線が、平行線のままになって時間だけが過ぎ去っていくんです。 面白すぎます。