「設計の理論」の版間の差分
削除された内容 追加された内容
編集の要約なし |
編集の要約なし |
||
274 行
Game.exe
のようなファイル構成のフリーソフトも時々、見かけます。
==== テストプレイして説明書を書く必要性 ====
===== 概要 =====
フリーゲームなどは、あまり説明書が細かくかかれないので、気にする必要はないでしょうが、一般IT企業のソフトウェア説明書や製造業の組み込みソフトなどは、もっと細かく一通りの操作方法を説明します。
イメージしやすさの都合で本ページでは、製造業などの組み込みソフトを例に、説明書の書き方を説明します。
なんと、組み込みソフトの説明書を書くためには、'''テストプレイが必要'''です。
だから例えば工場の生産ライン用の設備に組み込まれてる組み込みソフトの説明書なら、その説明書の文面は、工場で下書きしてるわけです。
オフィスで下書きするのではなく、工場で下書きするのです。なので、工場にノートブック（文房具）と筆記用具（要・赤ペン）を持ち込んで、そこで説明書の文面を下書きするわけです。
たいていの新人は、実機でのテストプレイに気が引けがちです。
実機でテストプレイばかりしてると「周囲の先輩から『この新人は書類も読まずに実機をいじって遊んでる』と周囲に見られるんじゃないか？」と不安になったりとかして、実機によるテストプレイを遠慮しがちです。また、仕様書は読んでて勉強になりますので、ついつい仕様書ばかり読みがちで、テストプレイを遠慮しがちです。
しかし、それは新人特有のよくある勘違いなのです。説明書を書く場合にも、実機でテストプレイをするべきなのです。
なので、下書きが終わったら、さっさと実機プレイをするべきなのです。
===== 組み込みソフトの場合の手順 =====
まず、仕様書などをもとに、説明書の大まかな章や節などの構成を、仮決めします。
大まかなページ数などの仮決めのために、仕方なく仕様書を見ながら、仕様書から想定されるハズの操作方法を書きます。
この下書きは、これはこれで必要であり、あとのテストプレイ時にチェックすべき項目を示したチェックリスト的な意味合いもあるので、とりあえず、実機プレイなしですが下書きをします。
ですが、この想定した操作方法は、まだ何のテストもしてないので、高確率でミスが含まれています。
なので、下書きした説明書のプロトタイプと筆記用具（赤ペン）を持ちながら、実機のある現場に移動して、到着したら実機で説明書どおりにテストプレイしながら（絶対に説明書を見ながら、杓子定規に説明書どおりにプレイします）、実機操作中に発見した説明書のミスを、赤ペンで下書き説明書に、追記でメモ書きしていくワケです。
このように仕様書ばかり読んでないで、さっさとテストプレイします。
だから、説明書を書くオフィスは、そういうテストプレイが気軽にできる環境の近くに存在する必要があります。
また、組み込みソフトの説明書を書く技術者は、工場の組み込みソフトを書くなら、技術書の服装としてはブルーカラーの作業着で仕事してるわけです（背広ではないです）。作業着でないと原則、現場に入れないので
組み込みソフトは、機械などに組み込まれてるわけですから、安全が確保されていて可能な限り、仮想化などではなく、実機でテストします。
（仮想化でテストすると二度手間になります。なので可能なら最初から実機でテストしたほうが早いです。）
このような仕事を、よく新人がやらされます。
新人は消費者目線に近いので、どこの業界でも、新人がよくテストプレイヤーにさせられることが多いのです。
同様の理由（消費者目線）で、説明書を書く仕事も、どこの業界でも、新人がよく説明書を書かされます。
===== ゲームにどう当てはめるか =====
ただし、上記の説明は、ゲーム業界ではなく、一般IT企業の業務用ソフトや、製造業での組み込みソフトの話題です。
また、説明書を書き始めるべきタイミングは、ベータ版でもよいので、とりあえずプレイできる状態になってからでないと、説明書は満足には書けません。
もしベータ版の時点から説明書を書いた場合、とりあえずリリース版が出る直前あたりに、説明書をもう一度、見直して、間違いがないようにチェックします。（説明書も広義のデバッグの対象です。）
子供向けの玩具で電子玩具の説明書などだと、場合によっては説明書の文面が子供口調（「～だよっ！」とか「～だね！」みたいな口調）で説明が書かれていたりしますが、けっして説明書を書くお仕事が子供の学校の図工みたいな作り方をしてるワケではないでしょうし、おそらくは実際の執筆手順は上記の組み込みソフトの説明書のような感じの手順で説明書を書いていってると思われます。説明書の口調という表面にダマされないようにしましょう。
ああいう子供口調やら女口調の説明書は、集団作業の場合なら、下書きの段階での口調は、普通のビジネスマン的かな書類の口調で書いているか、たとえ くだけた職場の場合でも普通の大人のくだけた口調で書類を書いているのであって、あとの工程で口調だけ入れ替えて子供口調や女口調に入れ替えるという手間を掛けています。けっしてイキナリ、子供口調とかで書類を書きはじめるわけではありません。
{{コラム|失敗学|
失敗は無数にパターンがあるので、すべての失敗を学ぶことはできません。
しかし、初心者がよくある失敗パターンというのは割と限られています。
そういうのは、学ぶようにしましょう。
航空事故など大規模事故が起きた際に組織される『事故調査委員会』も、失敗を次世代に繰り返させないために、原因究明をして事故調査をしているわけです。
高校物理などで習う「共振」現象だって、その共振によって米国のタコマ橋が実際に崩壊する事故という失敗例があったから、
その失敗例に学ぶことで橋梁（きょうりょう）設計の理論が進歩したののです<ref>[https://www.jstage.jst.go.jp/article/jjlp1960/43/2/43_2_182/_pdf 『失敗学のすすめ』]</ref>や。
なお、畑村は、2011年の福島原発事故の際、国家の組織する原発事故調査委員会のリーダーを勤めています。
チームにおいて失敗が起きた場合は、人的ミスではなく、組織設計のミスだと見るべきです。畑村はそう提唱しており、だから原発事故調査でも、責任追及をしないこと・させないことを貫きました。
}}
===== 調整の理論 =====
{{コラム|アブストラクト|
欧米の経営者が、経営哲学でよく「目標はすべて実現しようとするのではなく、優先度の差をつけろ」というのは、おそらく、こういう事を言ってるのでしょう。日本人の知ってる例でも、ソニーの元経営者のハワード＝ストリンガーは「アブストラクトを作れ」と日本社員に言ってたようですし（ここでいうアブストラクトとは、けっして日本語でいう「抽象」ではなく、論文とかの冒頭に書く要点の文を「アブストラクト」と言うように、要点のことであり、つまり設計の際に優先実現したい機能のこと）。米国アップル・コンピュータのジョブスも似たような事を言っていました。
よく、『アップルのスティーブ・ジョブスが「機能を絞って設計しろ」と言った』のような経営ノウハウが日本では有名ですが、
実はジョブスだけでなくソニーのストリンガーも言ってます（2003年から2013年までソニー取締役）。
ある元ソニー技術者の著作した新書（2010～2020年あたり、書店ではPHP新書あたりの本棚コーナーにあった。PHP本かどうかは忘れた）に書いてあったのですが、『ストリンガーが「製品は抽象的に設計しろ」と言った』のようなソニー内部での伝令を、その技術者は著書で批判していました。
しかしこの「抽象的に」は誤訳の可能性が高いのです。
と言うのも、abstract という英単語には、「抽象」という意味のほかに、「要点」・「要約」・「概要」といった意味があります。だからストリンガーはおそらく abstract という英単語を使って「機能の要点を絞って設計しろ」と言ったと考えれば、意味も通りますし、経営者として妥当な指示です。
学術論文では、「アブストラクト」といって、 論文の冒頭にその論文の要点・概要を書かなければなりません。そうしないと、論文を読まされる審査員が面倒なので、論文の査読などが後回しになったり、最悪、論文の受付けが拒否されます。
ストリンガーの言ってることも、多分そういうことです。つまり、「機能てんこもり家電だと商品コンセプトが消費者に分かりづらいから、消費者に商品の魅力が伝わらない。だからもっと機能を絞るとかして、分かりやすくしろ」みたいなことを言ってたんだろうと思います。
もっとも、日本の国語教育などでも、全くアブストラクトという概念は教えられてないのが当時も2020年代の今もそうなので、ソニーの通訳者が知らないのも無理はありません。日本の名門大学を出たはずの人でも、「アブストラクト」を意識した設計や作文を教えられてない人も、昔は多くいました。当時は日本の大企業ソニーですら、これが通訳の限界でしたのでしょう。
}}
{{コラム|パラメータ・バリエーション|
背景となる工学的な考えかたとして、下記の「パラメータ・バリエーション」という考えかたがあります。「パラメータ・バリエーション」とは何かと言うと、複数の変数からなる多変数関数のようなモノの適正値を探すときに、とりあえず1種類の変数だけを実験的にイジッてみて、その後に測定してみることで調整していく方法です。フレデリック・テイラーという機械工学者が、工作機械の研究での旋盤加工の回転速度・送り速度・直径・角度などの他変数の最適条件を探す研究の際に、こういう探求手法を1880年ごろに提案しました。<ref>橋本 毅彦 著『「ものづくり」の科学史 世界を変えた《標準革命》』、講談社、2018年3月13日 第7刷発行、143ページ</ref>
ただし、あくまでテイラーのこの手法そのものは、研究の方法でしかなく、つまり活用可能なのは大企業の工場のような十分な予算と研究員のいる場所でのビッグビジネス的な企業での科学研究的な方法なので、中小零細の企業での設計の実務では、そのままでは合わない方法かもしれないので、私たちは適宜、自分の勤務先の状況に応じて「パラメータ・バリエーション」をアレンジして応用する必要があるのでしょう。
歴史的には、パラメータ・バリエーションの考え方のほうが古く、ストリンガー経営哲学やゲーム調整方法よりも古いですが、しかし歴史の順番どおりに学ぶ必要はないです。学習はたいてい、現代の実務的な方法から学んでいくほうが効率的です。
:もし数学の用語に読者が詳しいなら、「パラメータ・バリエーション」とは、実験による検証において「偏微分」（へんびぶん）や「変数分離法」を合わせたような、謎（なぞ）の調整手法を、解を求める代わりに擬似的に実験（ゲームの場合ならテストプレイ）で用いたモノという表現でしょうか。
:ちなみに物理学の解析力学という分野にある「変分法」（へんぶんほう）という計算手法を英語でバリエーションというが、しかし、ギルブレスのいう「パラメータ・バリエーション」は明らかに（物理学の）変分法とは別の手法である。
}}
{{コラム|動点固定法|
;悩みは個別に切り分けるのが解決の基本テクニック
あと、よく『お悩み相談』などで相談員がアドバイスに使う方法ですが、「悩みは切り分けろ」という基本テクニックがあります。
たとえば、2010年以降の現代なら、アニメ評論家の岡田斗司夫などが、よくYouTubeでの視聴者からのお悩み相談などで使っていテクニックです。
別に岡田の発明した手法ではなく、たとえば1990年代から数学者の秋山仁が、インタビューを受けた雑誌などでの読者からのお悩み相談企画などでも使っている方法でした。
秋山の場合、こういう悩み切り分けのテクニックを、数学の幾何学問題の解法テクニックである「動転固定法」になぞらえていました。
座標上にある複数の点がある条件に従って動くとき、受験問題などで「この点Aと点Bの長さの値が○○となるときの点Aの位置を求めよ」的な問題では、
とりあえず、点Bの片方の座標位置(Xb,Yb)を、単なる定数のように認識すると問題の解法が思い浮かびやすいとアドバイスしており、そういう方法を動点固定法と呼ぶらしいです。
数学にたとえると難しそうですが、実際に当時の秋山に来た相談内容は、エロ本雑誌の読者の恋愛相談で、たとえば「僕はクラスのA子が美人だと思うのですが、でもA子は特に僕に気がないようで、それどころかA子は僕をいじめるときもあるし、僕は成績も普通でスポーツの成績はあまりよくなく、進路は○○を目指していますが（以下略）」みたいな相談内容です。
そういう相談の質問に対して、秋山は、問題を切り分けて対処しろとアドバイスしているわけです。
問題を切り離して、解決しやすい問題から解決していけ、という類のアドバイスです。
まず、「A子がときどきお前をいじめてくる問題については、他の問題と切り離して考えろ。これは他の問題と切り離しやすいから。」という感じのアドバイスを秋山はします。そして、「進路やそのための学力も、他の問題と切り離せる。お前の受験勉強で解決できるからだ。」みたいな感じのアドバイスをして、予備校講師の経験のある秋山は相談者に受験勉強の仕方などをいくつかアドバイスしました。
そして、そういう問題の切り離しをした上で、「美人のA子が好きでいるべきかどうかという問題については、まず他の問題と切り離して、これだけ考えろ。
いじめてくるA子なんて忘れるもよし。どうしても美人の忘れたくなくて未練が強く残るなら、イジメの復讐としてレイプするとか、いろいろと行動の選択肢がある」みたいな感じのアドバイスをします。たしかエロ本雑誌『スコラ』で、秋山はそういう感じで読者からの相談に答えていました。
}}
===== 数学的に不可能なことなど =====
{{コラム|小室直樹の「二値最適化」の問題|
政治哲学などの格言で「最大多数の最大幸福」という言い回しがありますが（なおこの格言を『ベンサムの功利主義』という）、しかし京都大学の数学科出身の経済学者・政治学者の故・小室直樹の著書によると（経済評論の書を多く出している）、これは数学的にはありえないとの事です。
小室の言い回しは忘れましたが、たしか「二値最適化」のような表現で言うらしく、それは数学的に存在しえないことが証明されているとおことです。一般に、（二変数関数ではなく）二値以上の関数を同時に最適化するのは、数学的に不可能とのことです。なお、数学・工学では「変数」は入力のことです。一方、「値」は出力のほうです。
小室が言及したか覚えてないですが、二値最適化の例外があるなら、たまたま偶然に同じタイミングで複数の出力値が最大化する関数などの特殊な形状の関数でない限り、一般には二値最適化はありえないでしょう。
小室によると、そもそも「幸福」をどう数値化するのかという議論が昔からありますが、仮になんとか幸福を数値化できたと仮定しても、二値最適化は数学的には不可能とのことです。
数学的にありえるのは、「一定多数の最大幸福」または「最大多数の一定幸福」のみだと小室は著書で言います。
小室は三値以上については述べてませんが、たったの「二値」ですら同時に最適化するのは数学的にはありえないわけですから、ましてや三値の同時最適化はありえないのは明白でしょう。
小室は東大・京大・ハーバード大などを卒業して著書多数で先端の経済学・政治学・法学を学んで著書まで書く経済学者・政治学者ですから（ただし学位は法学博士）、もし三値最適化がありえるのなら、そういった大学の後輩の天才たちがとっくに議論して経済学書などに書かれるわけです。書かれてないのですから、推して（おして）知るべきです。
ただし「二値最適化がありえない」の前提として、人口集団の性質や規模の前提として、経済学で扱うような十分に人口が多くて経済規模も大きい集団を前提にしているでしょう。
小室は特に前提を語っていなかった気がしますが、上述の仮定のため数学的には連続関数（ほとんど途切れずに、つながっている関数）で滑らかな関数（ほとどの場所で微分可能な関数）を前提にしていると思われます。
コンピュータ上の数値モデルは厳密には連続関数ではないかもしれませんが（だから「離散数学」（りさんすうがく）などの分野がある）、しかし昨今の大容量化したゲームで扱う数値モデルは、近似的に連続関数のようなものとして考えても差し支えないでしょう。ゲームの設計でそんなに複雑な数学モデルを使わないです（ゲームデザイナーが把握しきれず、役立たないので）。
;パレート最適
一応、経済学では「パレート最適」という、複数の（出力値ではなく）入力変数の調整に対応する理論もあり、パレート最適はどういう手法かというと、「どうやら現状が最適でありそうだ」と思われる状態になったら試しに条件を部分的に少しだけ変えてみて、もし悪化したら、「変更前の状態こそが、現状の条件の近くででは最適っぽいようだ」とみなす手法です。
しかしこれは出力値ではなく入力変数だけ複数の場合の手法です。出力値そのものが複数個の場合については、「パレート最適」の理論は何も保証していません。
なお小室もよく著書でパレート最適について言及しています。
;大小関係の前提
数学的には、「最大」や「最小」といった大小関係を語るには前提として、何かの尺度にもとづいての序列化を直線的・一面的にだけ行う必要があります。裏を返せば、ジャンケンのグ－・チョキ・パーのように強さが循環するものについては、大小関係を定義できないということが、数学的に解明されています。（出典を求めるなら、たとえば数学科の大学2年レベルの代数学などの教科書（『群論』（ぐんろん）や『集合論』（しゅうごうろん）などの科目）で説明されている。）大小関係では、ジャンケンのような循環は許されません。
}}
==
多項式近似 ==
なお、一般にIT業界での実務の多項式近似では、原理的には9次でも20次でも、どんなに次数が高くても（おそらく int 整数型の限界くらいまで）計算できてしまいますが、
しかしIT業界などの実務では人間の検算などの手間を減らすために、なるべく、せいぜい2次式や3次式といった、低めの次数におさえて利用するのが、IT企業では普通です。
もし先端科学のための多項式近似なら、9次を超えるような多項式近似をするような場合もありますが、しかし、一般の企業では、そこまでの多項式近似は不要ですし、むしろ検算などの管理の手間が増えるので、9次のような多すぎる次数は嫌われますので、なるべく2次ていどに抑えましょう。
| |||