【A9V6待望論】

【A9V6】ディレクターが「要望」を書け【そしてA10へ】

・「要望」「要求」「要件」の違い（談）
・「作品」とは何か（再）
・【上総湊始発】「すべてのステークホルダー」が見えているか【君津オンライン・コントロール・システム（KOCS）あり】
・「“簡単”な実装」を侮るなかれ

　[3885]の続き、そして[3897]の補足です。

・（再掲）
　http://sugisugi.net/jun/log/eid2111.html

　> 聞いた話だと、時間軸の変更はプログラム的には簡単なことなんだそうです。でも、当初のスピードにした理由は、等倍に近づけるほど画面の動きがほとんどなくなって、画面がフリーズしたように見えてつまらないからとのこと。30倍モードもありますが、60倍がちょうど良さそうな気がします。

・[3654]
　> いかにもじぶんはこのゲームでは遊ばなくて、動いているかどうか（青い画面で落ちないかどうか）確かめるとき、かなりズームアウトしてぼけーっと見てますみたいな言い分ですよね。ふつう、ペンタブレットでイラストを描くひとみたいに両手で…じゃなくて、マウスとキーボードを同時に使っていろいろなズームレベルを目まぐるしく切り換えながらじゃないと遊べない（そうじゃないのは遊んだうちに入らない）ので、「動きがない」なんてことはあり得ないですよね。そして、いかにも長年、プログラミングだけしてきたみたいなひとにありがちですけど、無駄に複雑に考えるひとって、いますよね。どうして「ニューゲーム」を「30倍」に1本化できないんですかね。ええ、まったくだわ。（※見解です。感想ではありません。）

　そんなことでいいのか本件ゲーム。…いいわけがありません！（※断言）

　https://b.hatena.ne.jp/entry/s/qiita.com/Saku731/items/741fcf0f40dd989ee4f8

　うーん。

　> 要望、要求と要件の違い、初めて知りました。

　うそーん！！ そんな、ごけんそんをー。

　> なぜうまくシステムができないのかがよくわかる。

　> 実際には「困っているからどうにかしろ」「何でも良いから解決しろ」程度の願望や愚痴のことも多く、その場合はまず構想策定が必要　あとで書く

　…『あとで書く』！！

　> Qiitaには珍しい上流工程の記事。開発者側の知識だが、発注者側も理解して手を動かせると圧倒的にコストが安くなる。

　ここなんですよ。（ばーん

　https://tech.nikkeibp.co.jp/it/article/Watcher/20110202/356761/

　> 場合によっては、要件定義を終わらせた段階でRFPを書くケースもある。自社で要件定義まで行って、それをベースにベンダーに発注する場合だ。これができるのは一部の大手企業など限られたケースだが、そのまま設計に使えるレベルのRFPであれば、それに対するベンダーの提案も、より精度の高いものになるだろう。

　本件ゲームでいえば、（どの者が社内なのか社外なのかは知らないが）ディレクターが『要望』（提案依頼書）を示して開発チームを召集する（＝『要望』に書いてあることを実装できそうという人を集める）とともに（詳細で実現可能な）「要件定義書」を仕上げていく。これがプロジェクトの見取り図になる。（※すべてのメンバーが同じ会社に属していても、そこには「ベンダー選定」「発注」と同じ関係性が生じることに留意。）ディレクターが『要望』（提案依頼書）を示す前から開発チーム（に入るであろう人）とよく話し合って、実質的に「要件定義書」を先に書いていけるなら、そんなに大失敗はないだろうけれど、あまりにも味気ないものになるともいえましょう。

　https://icotto.k-img.com/system/press_images/000/143/398/39a7a8682cdb4e97acbd88f3b59130a60f461a3d.jpeg

　業務システムではなく作品をつくるんです。ディレクターが『表現者！（笑）』みたいな腕章…じゃなくて、大きな顔をしていい。もっといばれということである。ディレクターとしては「バクハツだ！」と叫びながら色とりどり（しばらくお待ちください）実現可能かどうか考えるのは後にして（＝いま実現できないからといって考えもしないということはないようにして＝いまは実装しない機能もいつかは実装するつもりで＝）『要望』をひたすら出し切る（＝いずれはぜんぶ実装できるといいなという完全性のあるリストをつくる＝）労力を払わないといけないと思われませんか。

・「芸術家肌」とは
　https://eow.alc.co.jp/search?q=%E8%8A%B8%E8%A1%93%E5%AE%B6%E8%82%8C

　> 芸術家肌である
　> have an artistic mind

　> 芸術家肌の人
　> artistic person

　（たとえくじ引きで引いたとしてもじゃんけんで負けたとしても）ディレクターという『役』になったら、元来の自分の性格や専門性とは違うとしても（よく勉強して）「芸術家肌」を演じなければなりません。…色とりどりはバクハツだ！（※白目）それを役作りともいう。…いいません！！ ところで「アートディンク」を日本語で言えますか。な・・・なんだってー！！（※表現は演出です。）

※受託開発を本業とする同社が自主制作に挑むのは、発注者の考えかたを理解して本業を改善しようというロールプレイングのはずだから、もっと発注者みたいに「芸術家肌」を演じきれということです。

　そこをさぼってとはいわないけれど、なまじ仲間意識があって（じぶんも技術者だからわかるよ、みたいにいい人ぶって）開発チームが「やりたくない（※「めんどうだ」という本音）」といってくるのをうのみにしていませんか。（手慣れた『レパートリー』にないこと＝新しいことや工夫しないといけないこと＝を）考えることすら面倒というか、それはじぶんの仕事じゃない（雇用契約に含まれない）と認識している（※それは大事なことで、ちゃんと守ろう＆守らせよう！）人が言う「やりたくない」には技術的な根拠がないこともある。ちょっと探せばお手本があるようなものを面倒がってはいけないけれど、しかし、そこでお手本を見つけてきて「こんな感じでたのむ（きらっ」と言ってイラっとさせる役回りはディレクターが演じるものである。知ってた。（※表現は演出です。）

　しこうして（しばらくお待ちください）なるほど確かに何らかの商品が完璧に納期を守って仕上がってくる。動く動かないという意味では完全に動くから技術として完璧である。しかしそこには寄せ集められた技術しかない。作品として成立していないのである。…がびーん。これはすべてディレクター1人の（1人だけでぜんぶ負う）責任である。（同じ社内であってなお）「提案依頼書」がそうだから、そういう製品にしかならないのである。開発チームは完璧である。肝心なディレクターが「じぶんは頼まれたから引き受けただけだ」とか「社長の指示だから」とかみたいな態度（※要するに“技術者根性”のまま）だと悲劇である。（※現に悲劇である。そして社長がじきじきにディレクターというのはいいようでよくない。本当でしょうか。）

※だからといってディレクターに「孤軍奮闘せよ」とは言わない。客が何かいろいろいうのはぜんぶ「＃ちゃんと寝ろ」…じゃなくて、「＃ディレクターもっとちゃんとやれ」という“叱責”であると同時に“応援”である。客がディレクターを敵視してどうなる。いや、〜ない。（※反語）

　> 従来のウォーターフォール型開発の場合は要件定義、基本設計（外部設計）、詳細設計（内部設計）というそれぞれの開発工程の境が明確なのに対し、アジャイル開発やプロトタイプ開発などは、これらの各工程の境目が曖昧で、「目に見えるモノを作りながら仕様を固めていく」というスタイルを取る。
　> このような開発手法の場合、「ここをもう少しこうしてほしい」といった要求が出てきてそれを仕様として記述していくことになるので、これが要求仕様書のイメージに近いのではないか、というわけだ。

　（あとからあとから湧いて出る）それを「いちゃもん」という。なるほど「要求＝イコール＝いちゃもん」だから『いちゃもん書』と呼べばいい。（棒読み）

・[3843]
　> 客の要望を正確に読解できてすらいないのに、じぶんたちは要望に応えたと思い込んでいるのである。現在までの実装やリリースの文章を読む限り事実である。実際の客の要望を読める立場にはないがおおよそ想像はつく。そことの差分を想像したとき、実にとんでもない実装ばかりなのである。客が要望を送るのはよほどのことだから、かなりちゃんと考えてちゃんと書いてあるはずだが、それをはなから見下しているか、本当に読解できないからそうなるのか、どちらかしかない。半端な形であれ実装したということは前者ではないということになるので後者しか残らない。

・あえて「根性とは」のイメージです
　https://www.itmedia.co.jp/im/articles/0704/03/news161.html
　https://image.itmedia.co.jp/im/articles/0704/03/r5team04_01.gif

　> 「プロジェクトはすべてユニーク（一意）である」

　> 会社でもエースの技術者として扱われてきました。
　> いままでの立ち位置は、いわゆる「技術頭」でした。

　> 工数を見積もったのはGさん自身です。

　> 自分が作るイメージで
　> 自分が作るイメージで

　きゃー！ 「自分が作るイメージで」あぶないー！ Gさん気をつけてー！（棒読み）

　> 自分であれば画面に何日、DBに何日……

　> 他人に伝えるための資料の作成や、説明の時間。中間成果物のレビュー
　> 頭の中で「自分なら」とシミュレートした工数が現実のコストと一致するのは非常に難しい

　「根性」という言葉を使わない人ほど、じぶんが「根性」だけで仕事してたり、他人の「根性」を使って（＝じぶんと同じくらい「根性」があるメンバーだけを集めて）仕事していたりする。そのこと自体によしあしがあるわけでなく、仕事できさえすればなんでもいいともいえるが…（てんてんてん）。

　https://image.itmedia.co.jp/im/articles/0704/03/r5team04_02.gif

　> よく「技術者」が設計をする際に陥る「見積もりアンチパターン」の1つに、この最も「効率的な機能設計」があります。何年もシステムにかかわっていると、顧客の要望がSEには一見「無駄にしか思えない」ことは実はよくあります。
　> しかし、深く相手の要望を掘り下げて、顧客の業界の「プロ」の目から見るとそれは「必須」の要件だったりします。

　> 顧客の業界の「プロ」の目から見るとそれは「必須」の要件
　> 顧客の業界の「プロ」の目から見るとそれは「必須」の要件

　本件ゲームでいえば▼「名前をつけてかわいがり」機能や▼「駅の並べ替え」、▼「駅構内にも速度制限標を」、▼「進行方向が変わったら速度制限解除」、それに▼「バラストの山というアイテム」…はともかく、▼「両側から遮断桿が順に下りてきて開くときは同時に上がる踏切ただし道幅は狭い」、▼「実際に吹鳴する汽笛吹鳴標（線路に吸着）」、▼「任意の整数値を設定できる巡航速度！（例えば87キロ！）」などのことですよ。なあにわれわれは「プロ」なんですよ。大船から当駅始発で必ず座れるつもりでいてくれればいい。（違）

　https://blog-imgs-128.fc2.com/s/t/6/st614/20190726-5.jpg
　https://upload.wikimedia.org/wikipedia/commons/9/9e/Kintetsu_3220_KL21_Express.jpg

　なるほど▼車両側（先頭車）に「通過標識灯」という、時間帯やトンネルと関係なく任意に点灯と消灯ができる灯具（という機能）を実装のうえ、▼「ダイヤ設定」で「発車」となる設定のときに「通過標識灯を点灯」みたいなチェックボックスがあって、次に「発車」するまで点灯していればいいんですな。次の「発車」でチェックボックスをオフにしてあれば、そこに停車すると消灯するんだな。…はひ！？（※ほんのちょっとした機能に思えても、実装が非常にややこしくなる場合があるということを例示しています。そういう機能がほしいという『要望』を述べるものではありません。…ほしいけど！！）

　> 仕様の打ち合わせをする中で、Gさんが当初「無駄」だと思った機能が次々と追加されていきます。細かいところで、チェックボックスを足したり。選択時に色を変えたり……。

　「根性とは」のイメージでした。

　> このとき彼は本来の役目のマネージャではなくリーダーから抜け切れていないことが分かります。マネージャはQCDのバランスを常に計算し続けなければなりません。その任務はアプリケーションの完成とチームの維持ではなく、プロジェクト全体の成功……、顧客は無論チーム、自身の開発組織……、すべてのステークホルダーに対するメリットにほかなりません。

　> すべてのステークホルダーに対するメリット
　> すべてのステークホルダーに対するメリット

　本件ゲームのディレクター（※そのひと個人ではなく「役」に着目してください）が「技術頭（エースの技術者）」のまま「マネージャ」という仕事をしてしまうから本件ゲームがこうなる。「マネージャ」（※ただしプロダクトが『作品』であるという性格にあわせていえば「（映画と同じ意味での）監督」）が実質的には不在のまま開発が進んでしまうとこうなる、ということを体現していると思えてきませんか。いえ、思ってください。（※断言）「すべてのステークホルダーに対するメリット」とは、▼許諾を出した鉄道会社にとってもメリットとなる（※「だめじゃない」だけでなく「いいね！」という評価を得られないといけない＝いろいろなコラボなどとんとん拍子で話が進むような作品に！）ことも含みます。いえ、含んでください。（※断言）

・「含んでください」とは
　https://thesaurus.weblio.jp/content/%E5%90%AB%E3%82%81
　https://www.weblio.jp/content/%E3%81%8A%E5%90%AB%E3%81%BF%E3%81%8A%E3%81%8D%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84

　> ある物を計算や考慮の対象に含むこと
　> 相手に対して事情をよく理解して心にとめておいて欲しい時の敬った言い方。

　https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1236733892

　> 合併で富津市が誕生する前の旧・天羽（あまは）町の中心で、
　> 周辺では利用者数が比較的多い駅だからではないでしょうか。

　> 上総湊〜蘇我（千葉）間のローカル列車と
　> 君津〜東京間の通勤快速を１本にまとめたような性格の列車です。

　…なぜにそこで上総湊始発が連想されてくるし！ どこへゆく京葉線。（違）「要望」は市町村単位だから、天羽町がどんなに小さくても「要望」としては1つと数えられる。▼茨城県としての「終電を遅くしてほしい」＆「終電は東京から直通してほしい」かつ「特急ではだめだ（快速じゃないとヤダー）」みたいな要望に1つでお応え「北茨城市まで普通列車グリーン車」（[3661]）である。小数は切り上げでオネガイシマス。（※切り上げはイメージです。）

　> 1面2線なので

　君津以南は単線だから交換駅でありさえすればどこでもよかった。○か×か。（※表現は演出です。）

　https://ja.wikipedia.org/wiki/%E4%B8%8A%E7%B7%8F%E6%B9%8A%E9%A7%85

　> 信号設備上、1・2番線いずれも両方面からの到着および出発が可能である。
　> 上記設備を用いて普通列車が通常とは反対側のホームに入り、特急の待避を行う場合がある。

　内房線の全体を見渡してちょうどよいキロ程のところにあるからそのような設備を設けた。そのような設備があるから通勤快速の始発も設定できた。だから「交換駅でありさえすればどこでもよかった」というのは×である。（棒読み）

　> 以前、JTB時刻表では当駅に「市の代表駅」を示す「◎」印がついていたが、市役所の移転に伴い大貫駅に「◎」が移動している。

　これだね。「利用者数が比較的多い駅だからではないでしょうか。」ということではないんですよ。もっと名目的なこと（「市の代表駅」）で決まっていて、決めた時とは状況が変わっても鉄道のほうは変わらない。もっとこれだね。

　https://ja.wikipedia.org/wiki/%E6%B9%8A%E7%94%BA_(%E5%8D%83%E8%91%89%E7%9C%8C)

　> 1915年（大正4年）1月15日 - 木更津線（現内房線）木更津駅 - 上総湊駅間の開業にともない上総湊駅が開業。

　もっと最初から、そもそも上総湊駅こそが終点であった！ しつれいしました。

　https://ja.wikipedia.org/wiki/%E5%86%85%E6%88%BF%E7%B7%9A

　> 房総半島を一周する鉄道のうち、東京湾側の鉄道として1912年（明治45年）に蘇我駅 - 姉ケ崎駅間が木更津線（きさらづせん）として開業したのが始まりである。以後小刻みに延伸を繰り返し、1919年（大正8年）に安房北条駅（現在の館山駅）まで達したところで北条線（ほうじょうせん）と改称し、その後1925年（大正14年）に安房鴨川駅に達して現在の内房線の区間が全通した。

　> 1912年（明治45年）8月21日：姉ケ崎駅 - 木更津駅間が延伸開業。
　> 1915年（大正4年）1月15日：木更津駅 - 上総湊駅間が延伸開業。
　> 1916年（大正5年）10月11日：上総湊駅 - 浜金谷駅間が延伸開業。

　そのようなタイムラインにおける上総湊であり、また、工事の都合で上総湊を区切りにするのがちょうどよかったということである。

　> 1970年（昭和45年）3月24日：木更津駅 - 君津駅間が複線化。

　君津までの複線化は後年のことであるから、上総湊駅ができた時点では「君津以南は云々」というような決定的な段差はなかったということである。複線化が君津までなのは製鉄所のおかげである。もっと知ってた。（※恐縮です。）

　https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E8%A3%BD%E9%89%84%E5%90%9B%E6%B4%A5%E8%A3%BD%E9%89%84%E6%89%80

　> 君津オンライン・コントロール・システム（KOCS）

　…君津オンライン・コントロール・システム（KOCS）すごくサイバーだっぜ！！（※恐縮です。）

　https://kotobank.jp/word/%E3%82%B3%E3%83%BC%E3%82%AF%E3%82%B9-64066

　> コークス（〈ドイツ〉Koks）

　…コークス！ コークス！（棒読み）

　https://youtu.be/mvDveDf0Wbk




　> 10 HOURS NO LOOP (4K)

　これはさすがにクレイジーすぎる。

　> 1960年（昭和35年）1月 - 木更津・君津地区の立地調査実施。
　> 1960年（昭和35年）11月 - 君津町（当時）への進出を正式発表。
　> 1961年（昭和36年）8月 - 君津漁協との間の補償協定に調印。

　そのあたりの年代のことである。だから複線化は君津までである。電化して電車特急（「１８３系」）を投入するところまではオイルショックより前の計画だから房総半島ぐるり電化は達成されたのが何よりであった。（棒読み）

　https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q13184761393

　> グリーン料金が必要なのは高萩まで、高萩大津港間は乗車券のみで乗車出来ます。

　> 大津港到着後、高萩まで回送され、翌日の始発になります。

　「北茨城市まで普通列車グリーン車」のイメージでした。…そっちは大津港ですよぅ。琵琶湖じゃなくてね。（違）

　https://youtu.be/COuh0GuYCkc




・「大船から当駅始発で必ず座れるつもりで」とは
　https://thesaurus.weblio.jp/content/%E5%A4%A7%E8%88%B9%E3%81%AB%E4%B9%97%E3%81%A3%E3%81%9F%E3%81%A4%E3%82%82%E3%82%8A%E3%81%A7%E3%81%84%E3%81%AA%E3%81%95%E3%81%84

　> 案ずることなかれ
　> 何も問題ない

　ありがとうございました。（違）

・[3878]
　> 「車窓モード」というグラフィックにリアルさを吹き込むために何かすごい量のコーディングが必要かというと、実は運動方程式が1つなのである。

　あえていえば「After Effects®」の「wiggle」である。「車窓モード」に限らず、「撮影モード」「録画モード」などと称して「焦点距離」（「広角」「標準」「望遠」）ともどもプレーヤーが自由に設定できてすらよい。ゲームのロード時の「プレビュー」と呼ばれるオープニングのカメラのモーションを編集させるだけでなく、もっとゲームの中で自在に使わせればよいのである。風速がシミュレートされているのだから強風ならカメラが揺れればいいし、重い機関車が間近の線路を通過したらカメラが三脚ごと上下に揺れればよい。そういう実感を持っているかいないかというのが開発にあたって大きく響いてくる。実物を知っているということは重要である。（キリッ

※社長氏はフィルムやテープの時代に映画してた人だから、カメラは絶対に揺らしてはならない（揺らすと記録が途絶えたり乱れたりする）という固定観念があるのではないか。そうだとすれば、カメラを揺らせばリアルになるなどという発想を獲得するには天地がひっくり返るような衝撃をともなうはずだ。わー、びっくり。（棒読み）

・[3866]
　> 「実装のコスト×ほしがる客の数」という『かけ算』！：コストが少なくて多くの客が喜べば“御の字！”だけど、どうもそういうのは「あとでいいや」みたいにされて、それっきりになることが多いような…（てんてんてん）。ディレクターとしては「コストをかける」ほうに目が向いている。仕事の割り振りを考える立場だからしかたない。コストがかからない（細切れすぎる）仕事ほど他人には頼みにくい。じゃあ（※）ディレクター自身もがしがしコードを書けばよい。な・・・なんだってー！！（※ムンクみたいなポーズで。）

　『要望24』（[3702],[3705]）みたいなのをディレクターがじぶんで書けないといけないし、書いた端から「これならできる」など判断できないといけないし、よほど簡単なものはじぶんでコードを書いたり、せめて「ペーパープロトタイピング」（[3812],[3832]）すべき。答えがおのずと見えてくるのが「ペーパープロトタイピング」です。

・（再掲）「ペーパープロトタイピング」のイメージです（2004年6月23日）
　https://www.ohmsha.co.jp/Portals/0/book/large/978-4-274-06566-8.jpg
　https://www.ohmsha.co.jp/book/9784274065668/

　そして、『要望24』で挙げたような事項のほとんどは、それ自体にコストがかかるというものではないんですよ。それ全体を見通して仕様を決定する、そのとき一時的には『要望24』（※箇条書きでも9万字ほどある）の内容ぜんぶをじぶんの頭に入れる、そういうプロセスが必要だから分担できない、1人の人にずしっと重責がかかる。そこのコストが高いということなんですよ。…そもそもそれをディレクターというのではありませんか。（棒読み）▼「Option」については[3679]など、▼「意味不明な設定項目をなくす方法」については[3835]を参照。

・[3662]
　> 「オプション」と呼ばれる（開発者にとって）都合のいい画面（…迷ったら「オプション」に入れておけっ）を安易に設けてしまうことによって、個々の画面設計が洗練される機会を逸しているんですよ。

・[3679]
　> 車窓モードのままでは「Option」が開けなくなった：えー（＝後述の通り「影」「カメラクリップ」などを頻繁に切り替える＆車窓モードにしてから切り替えることが多いので、それができないのは不便すぎる）

・[3654]
　> 「Custom」「Option」「Help」は『変な色！』してるから触りたくない（！？）とか（「なんかむずかしいやつ」「触ると変になる」という理解がされるとか）「Help」から「動画ガイド」を選ぶまでの操作回数も多いんですよ。

・[3662]
　> 「自社物件に着色する」はいかんでしょ

　> > オンにすると、マップ上にあるすべての自社物件が、緑色に着色されます。

　> 「着色」＝ハイライト表示＝いま目先の操作をする直接の対象＝「選択（状態）」だというメンタルモデルがあるので、「選択」して「ごみ箱」みたいな操作でもなんでもないときに「着色」するのはいかんですばい。「オプション」の「データ表示」でチェックをつけたり外したり…なんてこったい！！ そんなの「Market」から「不動産取引」を開いたときに自動でオンになって、閉じればオフになればいいじゃないですか。そもそも「不動産取引」の画面に「自社物件に着色する」のチェックボックスがあればいいじゃないですか。わあぃレジの横に乾電池やガムっ。牛乳とコーンフレークを近くに並べて訴求だっ。（棒読み）「オプション」と呼ばれる（開発者にとって）都合のいい画面（…迷ったら「オプション」に入れておけっ）を安易に設けてしまうことによって、個々の画面設計が洗練される機会を逸しているんですよ。（※見解です。）

・[3695]
　> …われわれはゲームなので！ どちらかといえば模型での「惰行」の表現（そう見えるように速度を変えてみせる）を参考にするべきです！

　> 「Option」に項目を増やして「使いたいひとだけ使へ〜」的に

・[3662]
　> 「オプション」と呼ばれる（開発者にとって）都合のいい画面（…迷ったら「オプション」に入れておけっ）を安易に設けてしまうことによって、個々の画面設計が洗練される機会を逸しているんですよ。

　ある項目を「Option」に入れるのか各機能のところに並べるのかの吟味が甘いし、画質設定みたいに頻繁に切り替えるものはカメラなどと同じ並び「サイドメニュー」にアイコンが増えてもいい気がする、の意。「ハイトバー」はアイコンでオン・オフしなくても必要なときに自動で表示されて作業が終わると自動で消えればよい。そこで空いたアイコンの跡地を「画質設定」みたいなスパナかナットみたいなアイコンにするんですな。スパナかナットみたいなのはわれわれかもしれませんな。飛行船の床から頭だけ出してスパナを投げてすぐ頭を引っ込めるんですな。（違）「Option」というのは、メニューの構成を大きく変えることなく柔軟に新しい機能を投入していくための“ゆりかごっ！”という意味があったのではありませんか。「“いかにもOptionらしい”項目を入れるところ」（※意訳）などと逆転した認識になってしまって『思考停止！』するのはいけない。すごくいけない。（※見解です。）

　https://u-site.jp/alertbox/why-user-interviews-fail

　> ユーザーインタビューは、UXの重要な生成的手法だ。生成的な手法（インタビューやフォーカスグループなど）は知識を生み出す。
　> 想像上のものではない、ユーザーの実際のニーズに対処することを可能にする。（デザインを開始する前に）製品やサービスを利用する可能性のあるユーザーと話す時間を取ることで、他の方法では決して発見できないこと、すなわち、通常のユーザビリティテストを実施しても明らかにはならないことを知ることができるだろう。

　https://translate.google.com/translate?hl=ja&sl=en&u=https://www.nngroup.com/articles/outcomes-vs-features/

　> 製品計画における最大の落とし穴の1つは、結果よりもアウトプットに焦点を当てることです。つまり、目的を明確に定義する前に、何を構築するかを議論することです。

　> 機能は製品またはサービスが提供するものであり、メリットは顧客が実際に望むものです。

　> 設計ソリューションを決定する前に、次の手順を完了してください。
　> 1.問題を述べる
　> 2.ユーザーデータを収集して証明する
　> 3.コアコンピテンシーを定義する
　> 4.具体的な目標を設定し、成功基準を定義する
　> 5.複数のアイデアをテストする

　これをぜんぶ逆にするのが本件ゲームだと思いました。そしてわたしたちもまたいきなり開発に臨めばそういうことになってしまうと思いました。きょうこのときをわたしたちはわすれません。（※なぜかカップヌードルの同時通訳みたいにナレーションしてください。そして唐突に何らかの常套句みたいなのの定訳を無意味に差しはさんでください。）

　なにをかいわんや。…すでにいってるし！（棒読み）

・[3835]
　> 項目の1つずつには意味があってはっきりしていて、1つずつならよくわかるのに、その項目とあの項目を同じところに集めて設定項目（選択肢を並べて選択を迫るUI）にしちゃうというのがおかしい。ばらばらに分解するべきだ。

　> これらの動作（挙動）は「売上」や「自動発展」にしか影響をおよぼさないもので、仮にアップデートパッチで急に変えたとしても、「ダイヤが狂う」という影響は出ない。だからいつでもアップデートパッチでいきなり変えてもらって問題ないのである。ウエルカムである。

　https://youtu.be/uuW9CCPmMlU




　> 信号場なのに, なぜか発車ベルが鳴ります.

　まさに「いつでもアップデートパッチでいきなり変えてもらって問題ないのである。ウエルカムである。」な表現である。（※ここでいう「発車ベル」は「電子電鈴」で、1号線ではATSと密結合しているっぽいですよ。「信号場」は「連動駅」ですから、1号線としては絶対に「電子電鈴」を鳴らさないといけないのではありませんか。本当でしょうか。しかし、これ自体は傍題でした。こういう細かいことを、いちいち説明はしないけれどあたりまえのように表現可能にしておくということが表現というものではありませんか、の意。）

・[3770]
　> 「1：1モード」で「時間拡張３０倍」で最大車両数「１００」というのが、本件ゲームに習熟するときに必要十分な細かさであるとの認識でございます。これまで9年かけて結論を得たわたしがいうんですから本当です！（キリッ

　> つまり最大車両数「２００」を楽しむには「1：2モード」が必須だという理解であります。だから「３００」なんて荒唐無稽なリップサービスの類だ（＝動く保証が甘いまま見せかけの仕様を『盛った』）と思って見下しているんだな。実装するほうもするほうだし要望したほうもしたほうだし、実装されて言葉尻だけで喜んじゃってるほうもアレだよ、の意。

　コストがかかるというのは、例えばいまから224種類を超える列車のテクスチャを描きなおせとか、パンタグラフや幌やヘッドマークや最後尾を示す赤い板などをどういう車両のどういう位置にどういう条件で取り付けるのかというデータをつくって延べ625種類を超える車両の組み合わせとの検証をしろとか、そういうことです。それはゾッとする。色が正しくないものを直していただくことは絶対だと思うけれど、テクスチャが粗く見えるというなら「1：4モード」（[3759]）などと称して列車がもっと小さく見えるようにすればいい。コストをかけて追加すべきものに優先度をつけるなら、それはコストに対してインパクトが非常に大きいものを優先しようということで、それは真っ先に「音」ではないか。踏切の警報音の種類を増やすといっても4種類くらいしかないし、警笛だって種類はあまりないし、いわゆる「ミュージックホーン」は個々の音を録音するのでなく簡易な音源を搭載してプレーヤーに音符を入力させればいいんだ（[3728]）みたいに先述しています。そういうことをいくらでも挙げられるようでないといかんですばい。客も客でひどいよね。（棒読み）

　じゃあ「わたし」は『要望24』の内容がぜんぶ頭に入っているかというと…ギクッ。だからこそ文字で書く。とにかくぜんぶ（と思えるまで）書いてから、次は『カテゴリー24』（[3753]）みたいなことをしていく。それができる人なんて珍しくなくて、探せばいくらでもいるはずだから、見つけていないとすれば探しかたがわるい！（キリッ

※表現は演出です。適任者を探すのがいちばんコストの高いことだ。じぶんで名乗りを上げてくるような人はどうせたいしたことがないという経験則があるから（？）探さないといけないんだけど、探すのが大変なんですよ。…なんだかなぁ。

この記事のURL　https://neorail.jp/forum/3900/

[3914]

要望16（※解説あり）

2020/2/7

[3923]

「A列車 色がおかしい」を越えて進もう（後編）

2020/2/7

[3925]

【快速】「R with Excel」ーん（※訂正あり）

2020/2/7

[3968]

「A列車で行こう9 攻略 ダイヤ」とはいうけれど（増収増益編）

2020/2/29

[4006]

「A列車で行こう9 攻略 ダイヤ」とはいうけれど（食道楽編）【食堂車なし】

2020/4/1

[4013]

きょうは固定ディスクでブロッコリー。

2020/4/1

[4026]

「A列車で行こう9 ゲームオーバー」 ／ 「A列車で行こう9 クリア」

2020/4/1

[4247]

要望ＤＬＥＬ 〜ふぉー！！〜

2020/10/1

[4317]

【情報ドーナツ】「有床道」は「租税公課」から「陸運情報」まで1キロ（再）

2020/11/15

[4388]

【A9V6】USB扇風機とUSBベルとUSBチャイムでナイト！【そしてA10へ】

2021/1/1

[4454]

きょうは根府川で鉄部塗装。

2021/3/1

[4474]

【A9V1】いまこそ「大都市構想Ｒ」のびのびワイド（後編）

2021/3/21

[4516]

乗りものニュース「運搬ルート」を斬る（談）

2021/4/1

[4531]

【A9V2】「村の架け橋鉄道」は「難度Ｅ」だが地形は関係なかった（後編）

2021/5/1

[4676]

実例に見る日英対訳（25） NFT 〜地下鉄訓練室から「太秦の踵返し」をもう1度〜

2021/12/1

[4738]

きょうは西池袋でキープ。

2022/5/1

[4762]

【通快】「R with Excel」ーん

2022/6/1

[4787]

アルティメットなんとかとなんとかアルティメットの違い（談）

2022/6/1

[4812]

【A9・Exp.】さらさらーっ（カッコカリ）

2022/7/1

[4971]

はじまる観光計画はA9の2割 ／ 紙の時刻表が「アウトオブ眼中」 ／ 次の『10』では架線を実装？ ほか

2023/2/1

[4972]

【箇条書きでも9万字ほど】12枚のポストイットの1枚目にタイトルを書くひと（仮）【A列車で行こう9】

2023/2/1

[5038]

【黒いフォグ】「総力を挙げて潰す」とは何か（談・再）【灼熱通勤】

2023/7/7

[5043]

「チェルニー」を「マザー工場」で読み解く（談）

2023/7/7

[5088]

【A9V6】習志野でベセスダを見習え（談）【そしてA10へ】

2023/9/1

[5189]

【知恵袋】「鈴木講談」を『山野料理』で読み解かない（談）

2024/4/4

[5296]

【ゑひもせす】鹿肉と鮮魚の「ひしめきあう街」（ぬみめよらるろわ編）

2025/1/1

関連する記事

鉄のソルフェージュをさがして（探） tht - 2022/6/1

サウンド24 〜とぅえんてぃー？ ふぉー！！〜 tht - 2020/9/1

要望12（試行版） tht - 2020/7/1

試しに「A列車で行こう9とほとんど変わらないくらいに」を斬ってみる（談） tht - 2023/3/3

【A9・Exp.】時間拡張・スケールと進行速度の違い（再） tht - 2024/2/29

【道路16】「交差点名を保持する特殊なアイテム」というアイテム tht - 2020/5/7

いま問う「自分の感情を表すことば」のココロ（後編） tht - 2021/6/1

「A列車で行こう9 テクスチャ」を斬る（再） tht - 2020/9/16