「設計の理論」の版間の差分
削除された内容 追加された内容
編集の要約なし |
編集の要約なし |
||
472 行
もし先端科学のための多項式近似なら、9次を超えるような多項式近似をするような場合もありますが、しかし、一般の企業では、そこまでの多項式近似は不要ですし、むしろ検算などの管理の手間が増えるので、9次のような多すぎる次数は嫌われますので、なるべく2次ていどに抑えましょう。
{{コラム|バグあると人の死ぬ業界|
ゲームではバグがあっても、人は死にません（過労自殺などを除けば）。なので、アイデアが思いついたら、どんどんとプロトタイプで試してみましょう。
ですが、他の業界だと、バグがあると人が死ぬ場合もあります。たとえば、製造業での、組み込み機器などがそうです。
書籍で紹介されている事例だと『メタルカラーの時代』シリーズ（山根一眞（やまね かずま）による取材）で、
「日本ユニシス」というIT企業がかつて、提携している別企業のNC工作機械に向けた組み込みソフトの開発で（組み込みソフト部分をユニシスが開発）、開発テスト中のバグにより工作機械の刃物が本体にぶつかって折れて飛んできて、あやうく人が死ぬところだった、
・・・という感じの事例がインタビュー先のプログラマから紹介されています。
それまで日本ユニシスおよびその担当プログラマーでは、組み込みの仕事はほとんど扱わずに、どちらかというとIT業界内での顧客を仕事をしていたので、そういう人が死にそうな事例に経験することがなかったので、製造業の組み込みソフトでは特にバグおよびバグ予防に対する考えをIT業界内の仕事とは変えなければならない必要があることに気づかされた、とユニシスの技術者はインタビューで述懐しています。
}}
== メンテナンス書類 ==
しかし、著者の過去の技術系の企業経験で、実際に、メンテナンス用の書類が無かったせいで、メンテ不可能に陥った製品などを見てきたので、
その際の強い思い「絶対にこのようなメンテ不可能な失敗を、次世代に繰り返させてはなるまい」をもとに、このページが書かれています。
なので、出てくる例が、ゲームでなく（製造業系）組み込みソフトとか回路図とかです。
なお、本ページでは電子回路図（ただし工業高校レベル）をもとに説明したりしていますが、しかし電子工学の市販の大学教科書や技術書などを読んでも、本ページでいう「部品と機能の対応表」相当の書類がメンテナンスのために必要であるという内容は、一切、それら市販の教材には書かれていません。だから、電子工学者がこういうことを知らないので、情報工学者もこういうことを意識していないです。当然、情報工学の教科書にも、無い内容です。
== メンテナンス用の書類の概要 ==
完成形をつくるだけの「設計図」的な「仕様書」だけでは、バグ発生時や設計ミス発生時などのさいの修理が不可能です。
また、移植などの際に、もしソースコードだけしかなくて書類不足だと、「コードがどのように動いているのか？」を後任の人が把握できずに、移植困難になってしまうトラブルもあります。
前任者が会社を辞めてしまっている場合などもあるので、色々と書類が必要でしょう。こういうことから、もし下記のような資料が無いと、不具合の発生時に、修理のための設計変更で、どこをどうイジればいいか特定できず、困ります。
:* 部品と機能の対応表（下記では「フロー図」、「コード解説書」などと呼称することもある）
:* 「なぜ、こういう設計になったのか？」という設計者の思考の経緯を伝える資料
というか、残念ながらこういう資料の不足している職場は多く、なので日本のIT技術者は困っています。
上記書類のうち、特に「部品と機能の対応表」、「コード解説書」は、メンテナンス目的以外にも、設計図のチェックにも利用される。なので、そういう目的もあるので、ぜひ作成しておくのが望ましい。
「部品と機能の対応表」のことを、IT業界で何と言うのか、このページの著者は知りません。しかし、ともかくそういう対応表がないと、メンテナンスが後々に困難になります。
== コード解説書 ==
=== なぜ書くのか ===
発売後の（一般のIT企業では）ソフトにも、修理・メンテナンスが不可能になる場合があります。
そのため、製造業などの組み込みソフトなど、まともなIT業務では、ソースコードの内部構造・全体構造のコード解説書とでも言うべき書類があることが望ましいです。（特に名前は決まっていない。また、中小企業などでは作成しない場合もある）
一般のIT企業では「内部設計書」や「プログラム設計書」などの名前の場合もありますが、しかし既に設計図などで大まかな指定はできていますので、設計の時点では、これらの「設計書」が不要な場合も多くあります。
これらの書類の目的は、どちらかというと、設計よりも、後日に読み返したときのメモ書きです。主要な変数、主要な関数などは、第三者が、なんのドキュメントも無い状態でその意図を読み取るのは、なかなか手間が掛かります。なお、最終製品やあるいはコードだけから逆に設計書や設計図などを書き起こすことを「'''リバース・エンジニアリング'''」と言います。リバース・エンジニアリングは、本来なら、後任者などには、させるべきではないのです。
大目的として、完成後のメンテナンスなどの際に、'''リバース・エンジニアリングという手間のとても掛かる作業を、けっして後任者にしないでも済むように書類を残すのが、正しい書類作成および書類管理のありかた'''です。これが、前提の大目的です。これさえ押さえてくれれば、ほぼこのページで言いたいことは尽くされています。このページの残りの説明は、単にイメージを具体化するためのケーススタディです。
会社でリバース・エンジニアリングの手間の発生が起きるのは、経営者にとっても時間と予算のロスでしょう。また、リバース・エンジニアリングをさせられる側である社員も、利益を生み出すわけではない作業に時間を多く取られ、とても負担です。なのでとにかく、リバース・エンジニアリングの発生予防が必要です。
で、具体的にどうすればいいかというと、リバース・エンジニアリングの発生を防ぐためには、なんらかの方法で、少なくとも主要な変数や関数と、その設計意図の対応表のようなものが必要です。
（完成図である）設計図だけでは、このような機能の解説をするのは不可能または困難なので、さらに変数・関数と、設計意図との、対応表のようなものが必要です。この対応表のようなもののことを本wikiでは「コード解説書」と呼んでいます（IT業界で何と言うのか知りません）。（設計図だけでも機能の解説を出来ているなら、その部分は解説書に書く必要はありません。）
要するに、'''機能と部品との対応表'''も残すべきだという亊です。「この部品、どの機能に対応してるの？」ってのが分かればいいのです。
異業種の例ですが、下記の２つの回路の図面を見比べてください。
[[File:Flipflop-RS OR Clock no module japanese.svg|left|thumb|400px|クロック入力付きRSフリップフロップ（NOR型）]]
[[File:Flow Drawing example jp.svg|thumb|500px|フリップフロップをフロー図で表現した例]]
{{clear}}
どう比べても、右の「フロー図」のほうが、仕組みが分かりやすいでしょう。もし回路設計の専門外の素人が上記の回路図面を見ても、フロー図のほうなら機能が一目瞭然です。
このように、部品と機能を比べる書類があれば、とても後任者がラクになります。
また、このような部品と機能の対応の書類を作っておくことで、設計ミスの防止にもつながります。
上記の図面の例は、電気回路の設計の業界のハナシなので、ITではないですが、ともかく、こういう'''部品と機能の対応表'''があると、仕事がいいカンジです。
「フロー図」だの「コード解説書」などの名前はどうでもいいです。重要なのは、'''部品と機能の対応表'''を残しておけ、という事です。
逆に言うと、部品と機能の対応が分からないような書類ばかりを作っていても、無駄です。
けっして、やみくもに「○○設計書」のような名前の書類をいくつも残すのではないべきです。目的である、「部品と機能の対応表」を忘れないようにしましょう。
IT業界でこういう書類を残しているか知りませんが、少なくとも電子回路の業界では、こういう書類を残しています。けっして、（ブラック企業だらけだと悪評高い）日本IT企業の習慣のマネではなく、世界に冠たる競争力をもつ日本のB to Bの電子機器の製造業の手法をマネしましょう。
{{clear}}
一般の企業でのITソフトは、発売後から10年後や20年後にもメンテナンス等が必要な場合があるので、コードの全体構造の解説書が必要なのです。たかが1～2年で流行の廃れるソフトの管理手法なんか、手本にしてはいけません。
コード解説書を書かない場合、それでも将来的なリバースエンジニアリング予防のために解説を残したい場合には、おそらくですが、代わりに「仕様書」などの既存の種類に流用で、変数名や関数などの指定を記載したりする必要が生じるかもしれません。ソフトウェアの設計図（完成予想図）はその性質上、解説などはあまり長く書けません。それはそれで一つの方法です。勤務先などに応じて、うまく方法を選んでください。
しかし、個人製作ソフトの場合、仕様書は無いのが普通なので、簡易的にコード解説書を書いたほうが早いかもしれません。プログラミングは、仕事や学業などの都合で中断される場合もありますが、再開後に、中断前のアイデアなどを思い出すためにも、コード解説書は書かれていると便利です。（コレがないと、時間が経つと、ほぼ作業内容を忘れる。）
さて、経団連企業などの東証一部の上場企業のIT業界の人が「仕様書を書かないと、あとでコードの仕組みを忘れる」とか言ってるのは、きっと、このコード解説書のことでしょう。経団連発言の時代的な文脈的に、けっして要件定義書とか完成予想図とかのことではないハズなので、勘違いしないようにしましょう。
このコード解説書の書き方には、けっして、決まった書き方がありません（なので、市販の入門書では、紹介されてない）。ですが、ともかく、経団連企業とかの技術系企業の設計部門では、こういう書類も書くのが望ましいとされています。
重要なことは、コードのどの部分が、ソフトウェアのどのような機能を実現するために、何を構成しているかと言った情報を、コード解説書または仕様書などで残すことです。
===== システム構造の書き方 =====
システム構造を解説するには、要するに変数名や関数名や、モジュールが、設計図に示した設計意図にどう対応しているかを、記載できれば良いのです。こういった大目的をまず忘れないようにしましょう。
では、どうやったら、こういう解説をできるのかを、これから考えていきましょう。
ソフトウェア開発前には実際のシステム構造（プログラムをどういう仕組みにしたとか、変数名をどうつけたか、とか）を書くのが難しいので、ある程度、開発が進んでから、開発中にシステム構造を書くことになります。
このコード解説書には、決まった描き方がありません。（なので、一般むけの「仕様書の書き方」入門書では、紹介されていない。）
なお、この「コード解説書」書類の呼び名は特に決まっていません。呼び名が無いと不便なので、とりあえず「コード解説書」と呼ぶことにします。
====== ファイルの解説を書く ======
まず、ソフトウェアのシステム構造を解説する場合、どのファイルがエントリポイント（コンパイル時に最初に呼び出されるファイル。Main関数などがある）なのか、そういうことから、コード解説書に書いてください。
C言語にはファイル分割という機能があり、ソースファイルを複数のファイルに分割できますので、実際のソフトウェアではファイルが何種類もできます。
なので、コード解説書にエントリポイントがどのファイルなのかを書いてないと、いちいち読者がファイルを開いて読まないと、どのファイルが最初に呼び出されるのかを理解できません。
ファイル分割されたファイルが幾つも（いくつも）ある場合、例えばゲームソフトだとして、ジャンルがRPGなら
:wikiFantasy.cpp
:battle.cpp
:map.cpp
:menu.cpp
などのようにファイルが幾つもある場合、
システム構造書に、
<pre>
ファイルとその内容
* wikiFantasy.cpp : このソフトのエントリポイント（最初に呼び出されるファイル）
* battle.cpp : 戦闘処理のファイル
* map.cpp : マップ処理（フィールドやダンジョンなど）のファイル
* menu.cpp : 「道具」「装備」などのメニュー画面のファイル
</pre>
などのように、それらのファイルが何を処理しているのかを第三者が分かるように書いてください。また、なるべく箇条書きで書くのが、読みやすくて便利でしょう。
当たり前に残すべきメモのように思えるかもしれませんが、しかしこういったメモが残されてない職場は多くあります。悪い見本です。とにかく、瑣末なことでリバース・エンジニアリングを後任者にさせないように書類を残す習慣をつけましょう。
ダメな一般IT企業だと本当によくあるパターンで、ファイル解説の書類など何も残ってないのに自社アプリのファイルサーバーには「system.cpp」などの漠然とした名前のファイルだけがいくつもある場合が時々よくあり、「systemって何のシステムだよ・・・」と後任者があきれたくなるファイル名のプログラムがいくつもある場合、これは大変にリバース・エンジニアリングの手間を発生させる、プログラマーにとってイヤなパターンです。
暗黙の前提ですが、画面名やファイル名などの名前を決める際には、具体的な名前をつけるべきです。
書籍『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』によると、ゲーム業界でもそう指導されています<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、213ページ、</ref>。
ゲーム業界に限らず、一般のIT業界でも同様に具体的に命名するべきでしょう。つまり、「file1.cpp」とか「a.cpp」みたいなファイル名は厳禁です。また変数名でも「b」とか「variable1」（英語でvariableとは「変数」という意味）みたいな変数名は避けてもらいたいです。
なお、一般企業では箇条書きの説明をするとき、よくエクセルなどの表形式で説明することもあります。
{| class="wikitable" style=" text-align: center; margin: 2pt;"
|-
! style="text-align: center;" | 変数名 !! 内容 !! 注記事項
|-
| wikiFantasy.cpp || このゲームのエントリポイント（最初に呼び出されるファイル）||
|-
| battle.cpp || 戦闘処理のファイル ||
|-
| map.cpp || マップ処理（フィールドやダンジョンなど）のファイル ||
|-
| menu.cpp || 「道具」「装備」などのメニュー画面のファイル ||
|-
|}
のような表形式でよく箇条書きが書かれます。
開発した原作者には、「ファイル名から予想がつくだろ？」と当然に思うことであっても、意外と、通じない場合がありますので、きちんとコード解説書に、ファイルの処理内容を文章で書くべきです。
例えば、RPGの「メニュー」と言われても、あなたは「道具」「装備」などの画面を思い浮かべても、ほかの人は、戦闘シーンの「戦う」「逃げる」などのコマンド画面を思い浮かべるかもしれませんし、あるいは会話イベントの「はい」「いいえ」などの返事の選択画面を思い浮かべるかもしれません。
また、「マップ」 map と言われても、あなたは「主人公が現在いる場所の周囲」を思い浮かべても、ほかの人は、道具「地図」を使うと画面表示される世界マップと、世界地図のなかでの、主人公のいる地方の位置を思い浮かべるかもしれません。
または、「洞窟などのダンジョンの構造が書かれた地図のような道具が、そのゲームの中にあるのでは？」とか想像する人もいます。
このほか、数学用語で「map」（日本語でいう写像（しゃぞう）のこと）という用語がありますので、それと混同される場合もあります。
このように、ファイル名だけだと、いろいろと想像されてしまいます。
なのでコード解説書を作る場合、もし仕様書側に解説が無い項目なら、そのファイルのソースコードを読まなくても理解できるように、きちんとファイル内容の要約を解説書に書きましょう。
このほか、どうしても「System.cpp」とかのような漠然とした名前のファイルがある場合、何のシステムなのか、わかるように書いてください。（そもそも、そういう漠然とした名前を避けたほう安全ですが。）
====== パラメーターの名称と内容を書く ======
たとえばRPGを作るなら、
<pre>
パラメータとその内容
* chara_name : 勇者「イノウエ」や魔法使い「タナカ」などの名前
* chara_level : 人物のレベル
* hp : ヒットポイント
* hp_max : 最大ヒットポイント
* mp : マジックパワー
* mp_max : 最大マジックパワー
* sp : スキル パワー
* sp_max : 最大スキル パワー
* attack_power : 人物の攻撃力
* defence_power : 人物の防御力
* strength : 人物の腕力
* magical_force : 人物の魔力
* wise : 人物の賢さ
* mental : 人物の精神力
（後略）
</pre>
などのように、そのゲームで使うパラメーターについて、ひととおり、変数名と、その内容の要約を書いてください。
たとえ原作者には「当然だろ」と思えることであっても、他人には意外と通じません。
たとえば、「defence_power」と言われても、仮にアナタは「防御力」のことだと思っても、ある人は
:「戦闘コマンド「防御」を選択したときのダメージ減少量なのか？」
とか、思うかもしれません。
また、防具の防御力と、人物の防御力とを、同じ変数にするか、違う変数にするのかどうかも、「defence_power」という名前だけでは分かりません。
でも「人物の防御力」というように要約があれば、「あっ、防具の防御力は、人物の防御力とは別の変数なんだな！」って分かります。
また、
:magical_force : 魔力
:wise : 賢さ
:mental : 精神力
のような、魔法のような非現実的なファンタジーを前提にしたパラメーターがある場合、そのパラメータが何に影響をするのか、仕様書のほかの部分に書いてください。
例えば、
:「魔力は、最大MPだけに影響するのか、それとも魔法の威力にも影響するのか？」とか、
:「敵のつかった魔法攻撃で味方のうけるダメージに、魔力は影響するのか？」とか、
:「賢さが増えると、魔法は強くなるのか？」とか、
:「精神力は、賢さ と、どう違うのか？」とか、
上記の要約だけでは、疑問がどんどんと出てきます。
市販のRPGでも、「魔力」「賢さ」「精神」の数値が増えると、何に影響するかは、ゲームごとに違います。
つまり、
:「このゲームでは、魔法の威力は、○○と△△によって決定される。」
:「最大MPは、□□によって決定される。」
などのように、何によって決定されるのかを、書いてください。
もし要件定義書など別の書類に書いてあるなら、それを参照する形で簡略化してもいいですが、しかし要件定義書には一般に変数名（「attack_power」とか）は書かれていないので、やはり、こういうコード解説書も作っておくのが良いでしょう。
:業界によっては、この変数名などの詳細を指定した書類を「プログラム設計書」と読んだりして区別する場合もあるが、業界や会社ごとに意味がバラバラなので、本ページでは、その呼び方（「プログラム設計書」）は用いないことにする。
たとえ、コード解説書の記述が、他の書類と説明がいちぶ重複していても、かまわないでしょう。
むしろ、他の書類と相互に照合することにより、設計ミスなどを見つけやすくなる場合もあります。
とはいえ、コードのすべてを解説するのも時間的に困難なので、説明に優先順位をつけ、設計者に必要なことを優先して書くようにしましょう。
なお、このコード解説書を書く場合、けっして単に「どこの変数の内容がいつ、どういう内容に変わる」とかだけを書くのではなく、その作業を通して何を実現しようとしているのか等の意図も、書くようにしましょう。
自分の書くコード解説書でバグのある内容を記述してしまうというミスをしてしまう場合もあります。なので、万が一、そういうミスをしてしまった場合に、将来的に仕様書を読まされる後輩たちが修正しやすくするためにも、できれば各コードの意図・目的なども併記するようにしましょう。
たとえ執筆時点でバグは無くとも、ソフトウェアによっては将来的にOSやらミドルウェアやらの変更が必要になったりする場合もあり、そういう場合に既存の仕様では動作しなくなる場合もあるので、仕様に変更の必要が生じる場合もあります。
もちろん、細かいことはソースコードにコメント文で書け済みますが、しかしもしソース側でかけないような事があれば、解説書の側で書くと良いでしょう。
なので、そういった将来のミドルウェア変更のような事態も見越して、特に重要になりそうな各プログラムがあれば、そのプログラムの作業内容の意図・目的なども、できれば、どこかに書いておきましょう。
とにかく、それぞれの書類で説明が他書類と重複していて説明文がやや増えても、説明の多いぶんには、デバッグが効率化するので問題ないのです。仕様書の分野では、説明の「大は小を兼ねる」です。
== 後任者は思考の経緯も知りたい ==
後任者が、仕様書や「要件定義書」や「○○設計書」などの各種の書類などを読むのは、仕組みを把握したり完成目標を確認する理由のほかにも、前任者の開発の経緯やそれにともなう思考の経緯を知りたいという理由もあります。
たとえば、もし古いソフトに不具合が出たときなどに、設計ミスなので設計変更が必要ですが、
後任者がどこの設計部分がどういう事情でそういう設計になったかが分からないと、後任者がどう設計変更でイジレナイからです。
（実際には書類不足などで前任者の意図が分からない場合も多く、そのため、テストを頻繁に繰り返すことになり、工期が増えて残業なども増えてしまったりします。）なので、もしも書類がうまく残っていて、前任者の「こういう理由で、こういう設計にしました」という設計者の思考の経緯が書類に残っていれば便利です。というか、それが無いと困ります。しかし困ったことに、無い場合が多いので、日本の技術者はよく困ります。
設計者の思考の経緯を伝えられるような、そういう定型の書類形式というのが、ありません。「要件定義書」、各種の「○○仕様書」、「△△設計書」などを見ても、そこには通常、思考の経緯は書かれていません。
「要件定義書」や「○○設計書」などは無いよりかはマシで、思考の経緯などを推測するヒントにはなりますが、あくまでヒントどまりです。
「部品と機能の対応表」のようなものがあれば、かなりヒントにはなりますが、しかし、それでもヒントどまりです。
なお「部品と機能の対応表」の目的は、けっしてヒント目的だけでなく、設計内容のチェック用資料や他ソフトなどとの連携をする際の資料なども兼ねています。なので、たとえ思考の経緯を残した書類を書けても、「部品と機能の対応表」の種類も書類作成を省略せずに作るべきです。
とにかく、後任者のために書類を残すとき、思考の経緯もうまく手短かに分かるように書類も作りましょう。
このコード解説書のページ数は特には決まっていませんが、おおむね、持ち運びやすい程度の厚さになるページ数にしておくべきでしょう。
== よくあるトラブル: メンテ資料紛失 ==
この手のメンテナス資料でよくあるトラブルが、退職エンジニアの資料紛失です。
会社の上司が、メンテナンス資料の定期チェックをサボりたいあまりに、担当エンジニア個々人のパソコンにだけ資料を保存させておいて、そのエンジニアが退職などしたときに資料が紛失するトラブルが日本各地で多発しています。（もし印刷すると、正式資料と混同されるので、紛らわしいから、印刷しない場合が多い。）退職したエンジニアの使っていたパソコンは、次の新人のためにフォーマット初期化するので、フォーマットの際にメンテナンス資料も消えてしまうというトラブルです。
「会社の共有フォルダにメンテ資料を置きましょう」と提案しようにも、しかし上司のチェックすらされてない資料が共有フォルダに置かれるわけもないので、結局はそういう会社ではエンジニア個人のパソコンでメンテ資料を管理させられたりもします。そして、いつしかメンテ資料が消失しています。
;対策
この手の資料消失のトラブルを未然防止する簡単な方法は、定期的に、部署の部長課長などや上司などの管理者が、現場エンジニアから上がってきたメンテナンス資料の原稿を、（管理者が）定期的にチェックする必要があります。
また、こうやって定期チェックすれば、万が一、メンテ資料消失しても、資料を普段から検査してきた上司や検査担当者の頭の中に記憶が残っているので、ノウハウの復旧が比較的に容易です。
;解説
しかし、部長や課長などが原稿チェックを面倒くさがっていると、上述のようなトラブルになります。
どこの技術系の企業でも、設計図のチェックは念入りに行いますが、しかしメンテナンス用資料のチェックが省略されたりする会社が多くあります。
資料紛失は会社側の自業自得でもあります。
なお、上司がチェックを面倒くさがっているという理由でメンテ資料が個人管理されている場合、当然、その資料は印刷などはされていません（もし印刷すると、正式資料と混同されるので、紛らわしいから、印刷しない）
なので、退職しなくても、ハードディスク故障などが起きればメンテ資料は消失して一巻の終わりです。
退職が決まったときに会社は引継ぎ資料をエンジニアに作成させようとしますが、当然、上述のような技術資料が急に作れるわけもなく、そもそも資料の内容が上司や同格の技術力のエンジニアから検証チェックもされてないので信頼性も不明だし、よって急ごしらえの資料作成は大抵、失敗に終わります。
根本的な原因は、メンテ資料のための作成費用を普段から出していなかった会社の態度です。また、この手の会社は、そもそも論として、退職エンジニアより昔の前任者からのメンテ資料すら用意していないのが通例です。そんな杜撰（ずさん）な管理体制なので、大抵の企業では、急ごしらえのメンテ資料の作成は失敗します。会社の自業自得です。
つまり資料消失であわてる会社というのは、そもそも、まともにメンテ資料の上司によるチェックもしていなかったという会社であり、いろいろと自業自得です。
== 「単位動作」という概念 ==
主に機械工学教育の用語なのですが、「単位動作」という用語があります。
たとえば、熟練工の動作は、一見すると色んなスキルを習得しているので複雑に見えますが、しかし動作のひとつひとつは、たとえば卓上ボール盤なら教科書どおりの卓上ボール盤の使い方ですし、やすりがけ の動作も、教科書どおりの動作です。
複雑な動作も、教科書どおりの動作を、組み合わせただけに過ぎません。
そして、その やすりがけ だけの動作の説明も、図や写真などを使って、「手順1：○○をする。」、「手順２：△△をする。」などと一段階ずつ、1ステップも抜かりなく 教えます。
だから、工業高校や大学の機械工作実習では、教科書どおりの動作をひとつずつ、教えます。
けっして、いっぺんにまとめて、別種の動作を教えません。
このように、動作をひとつひとつの単純な動作に分解することを単位動作といいます。
なぜ、わざわざこんな事を説明するかというと、世間では複雑な物事を説明するときなのに、いっぺんに教えたがる人がいます。
しかし、そういう教え方は、多くの開発現場ではNG（エヌジー、ノー・グッド）です。
残念なことに、インターネット上には、一見すると説明書の文章量が多くても、
実態を読むと、このような作者以外でないと操作方法を読み解けないようなダメな説明法をされているツールも、
残念ながらネットに多く公開されてしまっています。
単位動作を意識した解説の書き方は、べつに難しくなく、普通に、
たとえばwindowsのオフィスソフトなどのヘルプファイルや、あるいはオフィスソフトについての市販の操作解説書のように、
「～～をしたい」といった操作目的の種類ごとに一個ずつ手順を段階的に教えればよいだけです。
単位動作の説明を軽んじる人が根本的に勘違いしていることは、「複雑な動作を練習したほうが、スキルが上達する」という勘違いです。
しかしそれは、上述のアニメーター教本の例などからも分かるように勘違いです。
むしろ物理学の公式のように、単純で短いものに置き換えたほうが、物事を考える際の部品として使いやすくなるのです。
だから実際の順序は、「単純な動作を見つけ出すために、その何倍もの練習や試作をする」のです。たとえるなら、発明家の努力のようなものです。「99%の努力の上での、1%のひらめき」です。
| |||