「高等学校工業 機械設計/その他」の版間の差分

削除された内容 追加された内容
編集の要約なし
編集の要約なし
1 行
{{substub}}
== 社用印 ==
一般の技術系・職人系の企業では、現場への作業指示としての設計図(完成予想図)には、スタンプなどで「最新版」などの印字の業務用ハンコを押したりして区別したり、
 
------------------
ゲーム業界はどうか知らないですが、一般の技術系・職人系の企業では、現場への作業指示としての完成予想図には、スタンプなどで「決定」などの印字の業務用ハンコを押したりして区別したり、さらに誰がその決定稿のスタンプを押したのかが分かるように、業務用の日付印ハンコで、
| 最新版 |
|  |
|-----------------|
 
 
さらに誰がその決定稿のスタンプを押したのかが分かるように、業務用の日付印ハンコで、
------------------
| 山田 太郎 |
10 ⟶ 19行目:
たとえばアニメ業界でも、よく、古いアニメのキャラクターデザインの設定イラスト表などに業務用ハンコで「決定稿」とか押してあるでしょう(アニメショップとかでも、一部のアニメでは、消費者むけに設定イラスト集などもアニメグッズとして販売している。最近はアニメ業界ではデジタル化をしたので、「決定稿」スタンプは押さない場合もあるようだ)。
 
ああいうのと同じで、一般企業で図面とかを管理するとき、そういうふうに「決定稿」スタンプみたいな業務用ハンコの印字で区別したりします。
 
 
さらに一般の技術系企業でも、検討中のほうの予想図には、ハンコで「検討」とか「未定」とかのスタンプを押して区別したりすると、より安全です。「検」だけだと「検証済み」などと誤解される恐れもあるので「検討」と最後まで書くのが安全でしょう。また、正式な図面には「最新版」印字や「旧版」印字など版の状態が分かるスタンプを押します。
 
:※ よくネットのビジネス素人のビジネス評論では、こういう企業での「決定」ハンコみたいなモノの存在も知らずに使い方も知らずに、「山田」とか「田中」とかの人名の認印みたいなのだけを想定して「ハンコは不要」とかいうバカの一つ覚えの評論を言うだけのバカが多いですが(そして、そういうバカが残念ながら外資系IT企業の日本法人という名の実質的な日本代理店にもチラホラといたりしますが)、(マンガ業界とかはどうか知りませんが、)難しい製品を扱っている企業とか精密な製品を製造する企業では、人名の認印のほかにも、「決定」「検討」とかの印字の業務用のハンコが存在している事を把握しておきましょう。(ゲーム業界がどうかは知りません。)
 
 
:※ 「客先公開用」みたいに、公開してもイイ資料の場合には、そういうハンコも押されます。そういう公開許可の指定が無いかぎりは、原則的には外部公開の厳禁である企業秘密の事項なので、いちいちハンコ(「極秘」印字みたいなの)は押しません。ですが、いちおう「外部非公開」とか「内部閲覧用」とか「秘密」とか「極秘」みたいなハンコは、ある程度の規模の大きい一般企業にも本当に存在しています。外部公開用と似たような内容の書類、いちぶ内容の重複する書類でも、外部非公開の詳細な書類とかも存在する場合がありえるから、区別のため、そういう非公開の指定をする印字もあります。
30 ⟶ 40行目:
:完成予想図の原案としての大まかな予想図をある部署Aが作成し、
:さらに詳細の完成予想図を別部署Bが作成、
といったように、段階的・階層的に別々の人たちで書き分けたりする手法も、一般企業どうしでは、よくあります。(ただし、ゲーム企業がどうしてるかは知りません。)
 
 
こうすることで、要求事項などが明確に伝わってるかの確認も出来るので、一石二鳥です。
46 ⟶ 57行目:
 
 
作業者には、更新の無いようの決定後に、(書類が分厚い場合などもあるので、)該当のページだけを印刷して渡したりします。現場側は、当面はホチキスなどで、更新後のページを完成予想図の一覧バインダーとかに留めたりするワケです。(まだまだ今後の更新も多々あるかもしれないので、当面のあいだは、予想図の書類全体の再発行はしないでおき、修正ページだけを渡したりすることが一般企業では多い(ただしゲーム企業はどうか知らない)。)
 
 
83 ⟶ 94行目:
 
== 書類どうしの関係 ==
部品図では、同じ製品でのほかの部品図の説明は不要ですし、むしろ管理の手間を増やすので避けるべきです。
本ページでは、要求事項や完成予想図などを書き方の要点を述べるが、それぞれの書類は、他の書類と説明がいちぶ重複する場合もある。
 
なぜかというと、もし部品図どうしで意図的に重複させて他の部品図の内容を引用すると、もしその参照された側の予想図Aで設計内容の変更が起きたときに、参照する側の予想図Bにも設計変更が必要になってしまいます。
たとえば、要求事項で説明した内容を、完成予想図でまた指定するかもしれません。
 
なので、完成予想図の部品図では、説明のための記述の重複は不要です。
 
製造業でも、ひとつの末端部品の図面では、他の図面はなるべく引用しないようにします。製造業の『図面』で他図面を参照するのは、せいぜい、組み立て方法を指示する『組立図』(くみたてず)の場合と、後述する『フロー図』の場合くらいです。
この場合、要求事項を知らない作業者もいるかもしれないし、いちいち要求事項書を参照するのは手間なので、なので完成予想図と要求事項書は重複してもかまいません。(つまり、重複していい。) というか、完成予想図は、それ単独で、いちおう製品を完成まで持っていけるような情報量でなければ、なりません。
 
 
なぜなら、もし、それぞれ別種類の書類で説明にいくつか重複があれば、むしろ、他の書類と相互に照合できるようになり、その結果の利点として設計ミスなどを見つけやすくなる場合もあるという長所もあります。
 
さて、アナログ電子機器の設計の業界では、よく、組立図とは別途に、電気信号のフロー図を書きます。どこの通信ケーブルに、どういう種類のデータが流れるとか、そういうのを指定するワケです。しかし、デジタル機器の場合は、普通、外部とのやり取りは一本の通信ケーブルで、あらゆる種類のデータを取り扱うのが通常です。
それぞれの書類は、異なる視点から、作るべきソフトウェアのあるべき姿を描いています。さまざまな視点からソフトウェアを検証することにより、設計ミスを見つけやすくなるのです。
 
製造業では、なにかの電子機器を製造する際、実はフロー図を描かなくても、一応は製品を完成できてしまいます。たとえば、たとえば途上国の組み立て工場など(もしや日本もそうかもしれませんが)、そういう状況でしょう。アメリカ製スマホの中国組み立て工場の作業員が、スマホの内部プログラムのフローを知ってるワケ、無いですね。
なので、説明が多いぶんには、構わないのです。
 
しかし、組立て工場ならともかく、設計を行う企業では、フロー図を描かないのは、好ましくないです。
 
むしろ、ヘタに説明を簡略化しようとすると、伝達モレなどのミスに、つながりかねません。
 
 
ただし、同じ製品の複数枚の完成予想図どうしの重複は、必要ないですし、むしろ管理の手間を増やすので避けるべきです。
 
 
== 設計図書ファイルとその目次 ==
なぜかというと、もし完成予想図どうしで意図的に重複させて他の書類の参照をすると、もしその参照された側の予想図Aで設計内容の変更が起きたときに、参照する側の予想図Bにも設計変更が必要になってしまいます<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、228ページ、</ref>。
どんな業界でも、技術系の業界なら、設計のために必要な書類(『設計図書』(せっけいとしょ)といいます)を、管理します。
 
なので、完成予想図では、説明のための重複は不要です。これは、製造業の製図でも同様です。製造業でも、ひとつの末端部品の図面では、他の図面は参照しないようにします。製造業の『図面』で他図面を参照するのは、組み立て方法を指示する『組立図』(くみたてず)の場合と、後述する『フロー図』の場合くらいです。
 
製造業における、(ある製品の)『設計図書』の書類の構成は、前から順に、おおむね
:表紙
:目次
:部品表(購入部品表、内部調達部品表)
:資料(部品カタログなど)
:図面(組立て図、フロー図、部品図)
:その他の参考資料
などです。
 
まず、部品を購入するなどして調達しないことには組立てできないので、部品表は最初のほうに書きます。
 
何か特殊な部品を購入する場合などは、それらのカタログなどの該当ページを資料などの項目に入れます。
 
そのカタログの該当ページに、購入する部品以外の他部品の情報も書かれているなら、文房具の色マーカーなどで、購入する部品の情報について-線を引き、購入する部品だけを目立たせます。
製造業では、なにかの電子機器を製造する際、実はフローチャートなどのフロー図を描かなくても、一応は製品を完成できてしまいます。たとえば、たとえば途上国の組み立て工場など(もしや日本もそうかもしれませんが)、そういう状況でしょう。アメリカ製スマホの中国組み立て工場の作業員が、スマホの内部プログラムのフローを知ってるワケ、無いですね。
 
 
このように、設計に必要な書類が、バラバラにならないように、ひとつのファイルに、まとめて入れます。(コンピュータを使うなら、そういうファイル(ディレクトリ)に入れて、さらに目次をつけて管理します。
(デジタル機器でなく)アナログ電子機器の設計の業界では、よく、組立図とは別途に、電気信号のフロー図を書きます。どこの通信ケーブルに、どういう種類のデータが流れるとか、そういうのを指定するワケです。しかし、デジタル機器の場合は、普通、外部とのやり取りは一本の通信ケーブルで、あらゆる種類のデータを取り扱うのが通常です。
 
ですが、重要なのは、組立図と別に、(製造業では無くても製造できるのに)説明のためのフロー図があるという、アナログ電子機器の設計業界での実務知識です。
 
 
もし、設計図書ファイルに目次を作るとき、ページ数は不要です。単に、番号とタイトル名だけで十分です。
 
:1 部品表
== 設計図書ファイルとその目次 ==
:2 資料
どんな業界でも、技術系の業界なら、設計のために必要な書類(『設計図書』(せっけいとしょ)といいます)は、上述のように、何冊も必要になります。
:3 図面
 
などのように、なります。なぜなら、あとの編集によってページが変動する可能性が高いからです。
なので、そのファイル内の目次が必要です。設計図書ファイルの目次を作るとき、エクセルなどの表計算ソフト形式で作ります(パソコン用ファイルだけでなく、事務用品ファイル用の設計図書でも、エクセル表形式の目次をプリントアウトする)。
 
こうすることで、もし落丁があっても発見が用意になります。
 
一般に、企業で業務用の報告書を作る場合も、ページ数は不要です。
 
イメージ的には
 
{| class="wikitable" style=" text-align: center; margin: 2pt;"
|+ 『○○』(←製品名)設計図書_目次: 1/1
|-
! style="text-align: center;" | 書類ID番号  !! 書類の種類     !! 最終版の年月日  
|-
| 001 || 目次 || 2015年6月10日
|-
| 002 || 企画書 || 2015年6月14日
|-
| 003 || 完成予想図 || 2017年3月21日
|-
|}
 
のような感じでしょうか。
 
部品表を作るとき、たとえばその部品表が3ページにわたるなら、
本屋とかで売ってる市販の書籍の目次とは、ビジネス書類の目次はこのように書式が違うので、気をつけてください。
 
:1枚目には題名「部品表 1/3」
:2枚目には題名「部品表 2/3」
:3枚目には題名「部品表 3/3」
 
のように、題名を数えます。
 
分子の数字は、現在のページ数です。分母の数字は、その書類が合計で何ページあるかです。
このように、設計に必要な書類が、バラバラにならないように、ひとつのファイルに、まとめて入れます。(コンピュータを使うなら、そういうファイル(ディレクトリ)に入れて、さらに目次をつけて管理します。
 
 
こう命名することで、もし目次のどれかが紛失しても、紛失したことの確認が容易です。
表のタイトルの末尾についている「1/1」という数字については、分子の数字は、現在のページ数です。分母の数字は、その書類が合計で何ページあるかです。
 
この例では、合計1ページしか無いので、分子も分母もともに「1」になります。
 
もしなお完成予想図など個別の書類の数が多い場合目次がたとえば合計2ページあれば、目次の1ページ目には「1/220とつけ、目次2ような合計ページ目に番号(例では「2/220)はつけないのが普通です。
 
なぜなら、予想図の枚数が今後の不具合修正などで増える可能性があるのが普通だからです。
あるいは、目次が合計3ページなら、3枚の目次には、末尾がそれぞれ「1/3」「2/3」「3/3」となります。
 
 
前提として、1枚の部品表には、10個とか20個のような数えやすい個数までの部品を掲載すべきです。けっして17個みたいな数えにくい個数を掲載すべきではないのです。
こう命名することで、もし目次のどれかが紛失しても、紛失したことの確認が容易です。
 
 
なお、もし追加部品が必要になった場合、最後の部品表の末尾に追加部品の情報を追加していきます。
なお、完成予想図など個別の書類には、「1/20」のような合計ページ番号(例では「20」)はつけないのが普通です。
 
なぜなら、予想図の枚数が今後の不具合修正などで増える可能性があるのが普通だからです。
 
 
さて、事務用品メーカーから、実際に業務用ファイルが販売されていますので(事務用品メーカーのキングジム とかアクスルとかの販売しているアレ。パイプホルダーを通すヤツ)、そういう業務用ファイルに、その製品の設計関連の書類をひとまとめにします。
原理的には、設計図書の目次の枚数だって今後の修正で(設計図書の目次のページ数が)増える可能性がありますが、しかし普通の設計図書なら、設計図書じたいの目次のページ数がけっして何十枚と膨大になることは無いのが普通です。
 
 
技術系企業では、そうやって、まとめられた設計関連の書類のことを『設計図書』(せっけい としょ)と言います。主に土木工事で使われる用語ですが、じつは製造業でも『設計図書』という用語は使われています(ただし製造業では企業が非公開にしている)。
 
さて、アナログな職業でも、実際に業務用ファイルが販売されていますので(事務用品メーカーのキングジム とかアクスルとかの販売しているアレ。パイプホルダーを通すヤツ)、そういう業務用ファイルに、その製品の設計関連の書類をひとまとめにします。
 
技術系企業では、そうやって、まとめられた設計関連の書類のことを『設計図書』(せっけい としょ)と言います。主に土木工事で使われる用語ですが、製造業でも『設計図書』という用語は使われています(ただし製造業では企業が非公開にしている)。
 
設計図書の中には、何種類も書類があるので、目次の書類が必要です。しかしページ数は変動するので、設計図書の目次では、ページ指定の必要は無いです(そもそも不可能)。
182 ⟶ 188行目:
 
 
もし設計図書ファイルパソコンでも管理する場合、表紙や目次が冒頭に来るようにするには
 
:「001_『○○』目次」
:「002_001_『○○』企画書」表紙
:「003_002_『○○』完成予想図」目次
:003_『○○』部品表
:004_『○○』資料
:005_『○○』図面
:006_『○○』その他の参考資料
 
みたいにファイル名の冒頭を番号で管理すると、確実にそのファイル内の先頭に目次が来ます。
231 ⟶ 241行目:
 
 
== 書類の履歴の管理 ==
、開発前の段階で書いた要件定義書や設計図(完成予想図)やコード解説書などの「仕様書」を、ソフト完成後にも残す必要があります。
企業で、何らかの手順書を書くとき、履歴を残すのが普通です。
 
なぜなら、開発前~開発中の経緯を、上司や他部署に事後的に報告したり、のちに入社してくる後輩などに教育としてソフト開発時の出来事を教えるためです。
 
このため、こういった仕事の書類には、著者や、著作・改訂の日時(「改訂日: 2018年8月30日」)や改訂者(「改訂者: 山田太郎」)などの履歴(りれき)も記載する必要もあります。
246 ⟶ 255行目:
|-
|}
 
 
のようになります。(企業では、こういうページのパソコンでの文書管理は、エクセルなどの表形式データになってるのが普通。)
 
 
ただし、機械図面の履歴の管理については、違います。上記のようなエクセル表は、あくまで手順書などの履歴の管理の方法です。
 
機械図面の履歴は、製図の記法に従って行います。なので、機械図面の履歴についてはエクセルでは管理しません。